Dear All,

We have held back the release of the December 1 release of AllTalk
server due to some Tracking Message issues.

I will post details tomorrow relating to an additional change in the
Tracking database settings. This is to do with the size of the "Mailbox"
property.  This change needs to be made in your ATTrack database before
using the new release.

ATTrack Service update has been completed. Final testing complete in the
next few days.

ATTrack updates have been running on 2 sites for 2 weeks.  All is going
well.  There seems to be a number of minor issues - all of these are
non-critical.

Importantly the new pre-set "Health Message" folder option will be
available - it requires the use of the new-by-download function to work
properly to be released in the new Client.

AllTalk client 2.0.0.5 is now in final testing.  It implements all of
the new changes discussed in earlier postings.  Importantly HL7 message
Acknowledgements can now be easily returned.  An acknowledged tracking
message is also being generated.   We will release this as a beta next
week.

Glen.

Hi Glen,

We are starting to experince 'timeout' errors when using attrack, even
for the simpilest of searches.

The current size of our database is 25GB.

Any suggestions/thoughts.

Rodney

Dear All,

For Sites Sending HL7 data and using AllTalk Tracking.

I am updating the Tracking record default settings to match HB262-2008 and I would appreciate a few examples from each of you so I can see where I can make improvements.  In particular where the the results are requested a copy-to (ie requested by DR A, this copy to Dr B).

In our work from about 18 months ago on Victorian Cytology's Medipath System, we spent a great deal of time generating HL7 messages that were "Generic" ie worked for pretty much every practice software package.  Alas all our previous work making it HB262 compliant had to be undone!  So we understand the reason why there is non-conformance.

Most significant variance is with the managment of Addressee Doctors and Copy-to Doctors.
HB262 says for Unsolicited Results (ie ones without an electronic order) MSH5 should contain the Addresee Doctors details in AUSHIC format eg

MSH|^-&\|QMLPTX|QML^2184^AUSNATA|Dr Harry Green^012345XY.GREEN.HARRY^DR^AUSHICPR|GX32615492^GOLD^L|199710291523+1000||

Most HL7 generators tend to put its Original Intention which is Receiving Application (eg Medical Director etc).

For copy-to information, HB262 (and AS4700) says to use OBR 28 with repeating fields to Identify the doctors that also received a copy (but it is not clear if you are supposed to put the Addressee doctor in this list too...)

Most packages still use a combination of OBR 17 and 18 to manage this.  Most use

OBR16 - Requesting Doctor

OBR17 - Addressee (if not same as OBR16)

occasionally OBR18  for Copy to Doctors  (HL7 Placer field 1)

occasionally OBR20 using value pair format eg  DR=1234567F, CP=Y (indicating the intended doctor's prov num is 1234567F and they are a COPY doctor, not requestor)

If you could send me some de-referenced results for comparison, that would be greatly helpful.

Thanks

Glen.

I probably didnt make this so clear,

But of course DNS resolution is also required.  The server needs
also to be able to resolve the host names to contact the remote
alltalk servers.

Glen.

--- In alltalk-avp@..., "lrs_y_gk_07" <glenk@...>
wrote:
>
>
> Dear AllTalk Server owners,
>
> There is now an important new requirement for network access for
AllTalk
> server to allow AllTalk server intercommunication.
>
> AllTalk server now must be able to access remote Alltalk servers
on port
> 21025. IE AllTalkServer must have outbound access on port 21025
for all
> IP addresses.
>
> Can you please ensure that before the Update on December 1, that
the
> computer hosting your Alltalk server has permissions to access
21025 at
> any IP address.
>
> The reason for this is to allow intercommunication between AllTalk
> servers - Alltalk server must be able to contact other AllTalk
servers
> to verify credentials and send Delivery notifications.  If your
server
> doesn't have permission for outbound 21025 permissions, you wont
be able
> to seemlessly communicate with other AllTalk servers.
>
> A detail explanation of the new services follow.
>
> 1) Remote CERT.
>
> AllTalk server can now return credentials for users on other
servers. IE
> AllTalk clients can now request the encryption certificate for any
other
> AllTalk client regardless of the server on which the account is
held.
>
> The Alltalk server wil respond to the CERT command from an AllTalk
> client by returning the current encryption certificate for the
requested
> address. If the account is not local, the AllTalk server will
attempt to
> connect to the server on which the account is held and if
connection is
> successful, it then replays the CERT command and returns the
response to
> the client.
>
> eg. glen@... <mailto:glen@...>
> connects to the Galkam server and issues "CERT
> abc555@..." . The Galkam server identifies that the
> account is not local and attempts to connect to the LRSupport
server. On
> successful connection, the Galkam server replays the cert
command "CERT
> abc555@...". The LRSupport server returns the
> appropriate response. The Galkam server, then replays the response
back
> to glen@... <mailto:glen@...> .
>
> As far as the glen@...
> <mailto:glen@...>  client is concerned, the response
> is no different than one received directly from its own server.
>
> 2) Remote Authentication.
>
> In keeping with AllTalk's Anti-Spam policy, no message can be
accepted
> unless the sender has been authenticated.
>
> AllTalk (or other SMTP) Clients wishing to send secure messages to
an
> AllTalk server for which it is not a member MUST use remote
> authentication.  Remote authentication works by the allowing the
client
> to request Authentication from the RECIPIENT'S server and that
server
> relaying the request back to the Senders Server.  On receiving a
request
> for remote authentication, the Recipients server makes a
connection back
> to the SENDERs (claimed) server.  The client then authenticates as
> normal and the RECIPIENT's Alltalk server "PROXY's" the
authentication
> process - so in effect, the calling client simply authenticates
against
> its own server. For Example:
>
> The Sender (glen@...
> <mailto:glen@...> ) having already determined the
> encryption details for abc555@...
> <mailto:abc555@...>  from a previous CERT command,
> connects directly to the LRSupport server on the standard AllTalk
> Messenger port (21025). Because the client knows it does not have
an
> account on that server, it issues a request for remote
authentication
> "AUTH RCRAM-MD5 glen@...". The LRSupport server then
> attempts to make a connection to the Galkam server (the Senders'
claimed
> server) and issues the "AUTH CRAM-MD5" command. The Galkam server,
> simply responds with the standard Challenge string which the
LRSupport
> server returns to the client (glen@...
> <mailto:glen@...>  ). The client then authenticates as
> normal using the returned challenge string. The LRSupport server
> monitors the connection for a successful authentication, and once
> satisfied that the Sender is who they claim to be, will then accept
> messages from that client.
>
> Note: There is NO RISK of compromising the sending clients
credentials
> during this process. The CRAM-MD5 authentication protocol is based
on
> MD5 signing and the actual passwords are never sent during the
exchange,
> nor is there any way to derive the password from the exchange.
Further,
> it is not possible to replay the exchange to trick the server into
> providing a logged-on session as the server issues challenges that
can
> never be re-used.
>
> 3) Remote Delivery Notifications
>
> In order that delivery notifications  (ATTrack CSV files) are
returned
> to the Sender regardless of which server the recipients mailbox is
> located, AllTalk server supports Remote Delivery Notifications.
>
> AllTalk server generates delivery notifications at the time the
> recipient downloads a message and indicates a successful
decryption (or
> not as the case may be). For Senders on the same server, the
AllTalk
> server simply writes the tracking record directly into the senders
> mailbox in the tracking folder. For senders who are on a different
> server the Recipients AllTalk server will make a connection to the
> senders server on the Messenger port and issue a NOTIFY command.
The
> Senders AllTalk server on receiving the NOTIFY will write the
tracking
> record in the senders Mailbox. Note: should the Senders server be
> unavailable at the time, the recipients server will store the
tracking
> record for sending later when the Senders server is back up.
>
> 4) Remote Address book
>
> It has been proposed in the past that AllTalk servers will be able
to
> exchange Address book details. This is no longer be required as the
> Remote Authentication process now allows clients wishing to
retreived
> address book details to do so directly from any server they wish.
> Together with the fact address book maintenance might represent
> significant traffic for the Server owners, it is no longer our
intention
> to provide this functionality.
>
> However, for the clients who have elected to publish their Doctor
> details in "Organisations and People" the expectation is that other
> AllTalk clients wanting to communicate with them will be able to
do so
> with no more detail than their Published ID (eg Provider Number).
>
> The ability for AllTalk server to deliver messages based on the
Provider
> number is based on the "Entitiy index" which is automatically
built from
> published details in the address book. This index is quite small
(no
> more than a few Kbytes generally) and contains only the link
between the
> Published ID and the AllTalk mailbox. Alltalk servers will
automatically
> exchange Entity Index details ensuring that the details are always
up to
> date.
>
> This information is used by the CERT function to retreived the
mailbox
> for a given Provider number.
>
> eg. glen@... <mailto:glen@...>
> wants to send a message to a doctor whos provider number is
1234567F.
> The client connects to the Galkam server and issues "CERT
12345678F".
> The Galkam server checks for a mailbox of that name and does not
find
> one. It then checks the Entity Index and finds that the provider
number
> is associated with a malbox on the equery.lrsupport.com.au. It then
> carries on as if the client had requested "CERT
> 12345678F@...
> <mailto:12345678F@...> " and as for the remote CERT
> example above, it connect to the LRSupport server and replays the
CERT
> command, returning the response to the client.
>

Dear AllTalk Server owners,

There is now an important new requirement for network access for AllTalk server to allow AllTalk server intercommunication.

AllTalk server now must be able to access remote Alltalk servers on port 21025. IE AllTalkServer must have outbound access on port 21025 for all IP addresses.

Can you please ensure that before the Update on December 1, that the computer hosting your Alltalk server has permissions to access 21025 at any IP address.

The reason for this is to allow intercommunication between AllTalk servers - Alltalk server must be able to contact other AllTalk servers to verify credentials and send Delivery notifications.  If your server doesn't have permission for outbound 21025 permissions, you wont be able to seemlessly communicate with other AllTalk servers.

A detail explanation of the new services follow.

1) Remote CERT.

AllTalk server can now return credentials for users on other servers. IE AllTalk clients can now request the encryption certificate for any other AllTalk client regardless of the server on which the account is held.

The Alltalk server wil respond to the CERT command from an AllTalk client by returning the current encryption certificate for the requested address. If the account is not local, the AllTalk server will attempt to connect to the server on which the account is held and if connection is successful, it then replays the CERT command and returns the response to the client.

eg. glen@... connects to the Galkam server and issues "CERT abc555@..." . The Galkam server identifies that the account is not local and attempts to connect to the LRSupport server. On successful connection, the Galkam server replays the cert command "CERT abc555@...". The LRSupport server returns the appropriate response. The Galkam server, then replays the response back to glen@....

As far as the glen@... client is concerned, the response is no different than one received directly from its own server.

In keeping with AllTalk's Anti-Spam policy, no message can be accepted unless the sender has been authenticated.

AllTalk (or other SMTP) Clients wishing to send secure messages to an AllTalk server for which it is not a member MUST use remote authentication.  Remote authentication works by the allowing the client to request Authentication from the RECIPIENT'S server and that server relaying the request back to the Senders Server.  On receiving a request for remote authentication, the Recipients server makes a connection back to the SENDERs (claimed) server.  The client then authenticates as normal and the RECIPIENT's Alltalk server "PROXY's" the authentication process - so in effect, the calling client simply authenticates against its own server. For Example:

The Sender (glen@...) having already determined the encryption details for abc555@... from a previous CERT command, connects directly to the LRSupport server on the standard AllTalk Messenger port (21025). Because the client knows it does not have an account on that server, it issues a request for remote authentication "AUTH RCRAM-MD5 glen@...". The LRSupport server then attempts to make a connection to the Galkam server (the Senders' claimed server) and issues the "AUTH CRAM-MD5" command. The Galkam server, simply responds with the standard Challenge string which the LRSupport server returns to the client (glen@... ). The client then authenticates as normal using the returned challenge string. The LRSupport server monitors the connection for a successful authentication, and once satisfied that the Sender is who they claim to be, will then accept messages from that client.

Note: There is NO RISK of compromising the sending clients credentials during this process. The CRAM-MD5 authentication protocol is based on MD5 signing and the actual passwords are never sent during the exchange, nor is there any way to derive the password from the exchange. Further, it is not possible to replay the exchange to trick the server into providing a logged-on session as the server issues challenges that can never be re-used.

In order that delivery notifications  (ATTrack CSV files) are returned to the Sender regardless of which server the recipients mailbox is located, AllTalk server supports Remote Delivery Notifications.

AllTalk server generates delivery notifications at the time the recipient downloads a message and indicates a successful decryption (or not as the case may be). For Senders on the same server, the AllTalk server simply writes the tracking record directly into the senders mailbox in the tracking folder. For senders who are on a different server the Recipients AllTalk server will make a connection to the senders server on the Messenger port and issue a NOTIFY command. The Senders AllTalk server on receiving the NOTIFY will write the tracking record in the senders Mailbox. Note: should the Senders server be unavailable at the time, the recipients server will store the tracking record for sending later when the Senders server is back up.

4) Remote Address book

It has been proposed in the past that AllTalk servers will be able to exchange Address book details. This is no longer be required as the Remote Authentication process now allows clients wishing to retreived address book details to do so directly from any server they wish. Together with the fact address book maintenance might represent significant traffic for the Server owners, it is no longer our intention to provide this functionality.

However, for the clients who have elected to publish their Doctor details in "Organisations and People" the expectation is that other AllTalk clients wanting to communicate with them will be able to do so with no more detail than their Published ID (eg Provider Number).

The ability for AllTalk server to deliver messages based on the Provider number is based on the "Entitiy index" which is automatically built from published details in the address book. This index is quite small (no more than a few Kbytes generally) and contains only the link between the Published ID and the AllTalk mailbox. Alltalk servers will automatically exchange Entity Index details ensuring that the details are always up to date.

This information is used by the CERT function to retreived the mailbox for a given Provider number.

eg. glen@... wants to send a message to a doctor whos provider number is 1234567F. The client connects to the Galkam server and issues "CERT 12345678F". The Galkam server checks for a mailbox of that name and does not find one. It then checks the Entity Index and finds that the provider number is associated with a malbox on the equery.lrsupport.com.au. It then carries on as if the client had requested "CERT 12345678F@..." and as for the remote CERT example above, it connect to the LRSupport server and replays the CERT command, returning the response to the client.  

A new version of AllTalk server has been released AllTalk Server V.1.0.0.169 31-10-2008 

This is a full release and testing has been completed.  To install the update, simply stop the 3 AllTalk services using Windows Management Console.  Replace the existing AllTalksvc.exe with the new one and then restart the services.

This is a replacement for the recent Server update (V1.0.0.159 13 October) which an incomplete fix for the Address.IN file problems.  Users of that version reported that the while the Address file remained small, the temporary address files were not being cleaned up and that the address data was incomplete.  So please ensure that you delete any temporary address files that may be in the  mailboxes folder (there may be hundreds).

Deeper investigation the problem revealed that faulty XML data in the some of the clients address details was causing the Address File re-indexing service to terminate abnormally leaving behind the incomplete Address files.  This new version overcomes the problem by checking the quality of the XML data before trying to apply it.

NOTE: I thought I sent this message before but I couldnt find it anywhere in the group.  So please forgive if it this message is a repeat!

Thanks

Glen.

Dear All,

Two important changes to AllTalk Tracking are about to be released. 

Decrypt Fail

The "Decrypt Failed" notification is a function that has been present for some time in the Server but has not been used in the past (mainly due to the high reliablility of Alltalk Proprietary encryption).  As more clients change over to PKI encryption, the likelyhood of decrypt failures increases due to things like expired/lost certificates etc.  AllTalk will attempt to download files 3 times.  If it is unsuccessful on the 3rd attempt, the message is flagged for deletion with "Decrypt Fail Notify".  Corrupt message are normally skipped by AllTalk (ie wont hold up delivery of other messages)- but on on rare occaions, corrupt files have caused the AllTalk client to crash.  The method for tracking the number of failures is robust and will cope with this situation - ie the message will be flagged for deletion on the 3rd unsuccessful attempt to decrypt regardless of whether the AllTalk has crashed.

The tracking records generated by AllTalk  indicate different status using "Special" Delivery dates.  For example the date used to indicate "Undeliverable" is January 1 1900.  The "Decrypt Fail" date is July 6th 1905.  The reason for using the date as a flag was to allow sorting of Failed messages in a sensible sort order when browsing the database.  Below is a list of the special dates.

      at_track_status_Undeliverable = '1900-01-01';
      at_track_status_download_fail = '1900-04-10';
      at_track_status_server_unreachable = '1904-04-03';
      at_track_status_decrypt_fail =  '1905-07-06';
      at_track_status_signature_fail = '1905-07-03';
      at_track_status_unknown = '1905-07-07';
      at_track_status_email = '2001-01-01';

For ATTrack users:

There will be a new ATTrack released at the same time as 1.1.1.98 to reflect the new status, but in the mean-time, it is important for you to watch for the decrypt Fail date to identify messages that need resending.

For Medipath/MediRad users:

The background process will be updated to manage the dates.  Initially, this will be in the form of a warning

For other systems consuming tracking messages (eg Dorevitch GGG) ,  you will need to update your systems to manage these special dates.

READ Status Flag

The AllTalk server to be released on December 1st, 2008 will support methods for identifying when Health Messages have been "imported" into the practice software.  The flag will be an integer from 1 to (initially) 5.  This is implemented in the tracking data using Field 18 of the tracking record.  The values are:

         1 - Unprocessed.  The message has been received and written into the Health message folder
         2 - Processed. The message no longer appears in the Health message folder (ie processed by the practice software)
         3 - Acknowledged.  The message has been acknowledged by PRACTICE SOFTWARE (ie not AllTalk PIT acknowledgement)
         4 - Folder Moved. The message was written into a folder which no longer exists (ie AllTalk cant tell what happened to it).
         5 - Forwarded By Email .  The file was forwarded by an AllTalk  email forward rule.

AllTalk Client Version 1.1.1.98 already supports READ status flag 2 (Processed) and 4 (Folder moved) and will become active for sites running the new version of December 2008 AllTalk Server.  Flag 1 is the "normal state" and AllTalk client will not be implementing it.  Other applications choosing to access the AllTalk server via SOAP services may choose to implement it.

Medipath/MediRad and even the oldest version of ATTrack will manage the change in field so the changes in the format of the Tracking record should not affect successful importation of the records. 

For Other systems, you will need to check sucessful importation of the new format using the test files at Tracking File changes .  Remember that the design is that the Message ID should always be the LAST Field in the tracking record.   It occurs sometimes in 17, sometimes in 18 and (now) sometimes in 19.  This was for historical backward compatibility reasons  to support the older versions of EQuery Tracking records still in widespread use. 

Dear All,

As mentioned in other threads, the new AllTalk Profile editor now allows the users to pick a list of Providers in order to create a new profile. New By Download Profile Editor View 

If you would like your company names included in the standard download, please send me the names of the company/s you want to appear AND the alltalk server's Host name (or IP address if there no public DNS for it).

On the client site, the details are filled from a text file of Name/Value pairs called AlltalkServers.txt.  Pairs look like this:

Last Resort Support=alltalk.lrsupport.com.au

Royal Womens and Childrens Hospital=alltalk.lrsupport.com.au

You could of course override this file with an custom version of AllTalkServers.txt if you chose to deploy clients yourself.

If for some reason you dont wish your company name to appear (why you would not want that I cant fathom) then please let me know and I will remove it.

I have fudged the entry for ARL and SydPath in this list because I dont know your server address.   Can you guys please contact me to get it corrected before the final release?

Thanks

Glen.

Dear All,

A new alltalk Client beta (Windows) is available for trials.  It is version 1.1.1.98 AllTalk 1.1.1.98 Beta 

Important fixes:

1. Stack Overflow occasionally seen on close fixed.

2. Client Downloads Address Book more than once per day. The client no longer downloads at startup if address book is current

3. Lost Tray icon, but client still running.  If the system tray icon cannot be created due to busy start up process, AllTalk will not minimise.

New Features:

1. Profile Editor "New By Download" feature has been updated.  Clients have had poor sucess with this feature due to issues with DNS entries and poor E-Domain name choices.  The user longer needs to specify the full mailbox name: they can now select the server from a drop down list  see New By Download.  IMPORTANT also see thread entitled "Getting Company Names added to the drop download list of Providers"

2. Corrupted files will be deleted from the server after 3 failed downloads and generate a "Failed Download" notification.  IMPORTANT See message separate thread entitled "New Features in Tracking Data"

5. Extended Notification features support has been added allowing the sender to be notified when Health Message  files have been imported by the server.  The feature is will become active when the server is updated the December 1 2008 release.

6. Updated Insecure Email client features allowing AllTalk profiles connecting to standard Email servers to download and automatically extract all attachments to the appropriate folders.  For emails containing Plain text Bodies only, the text will be extracted into a text file.  For Multipart alternate messages with no attachments, the eml file will be saved unchanged.   (Note: the text body is ignored for all emails with attachments).

-----Original Message-----
From: Warren, Rob  

 Sent: Friday, 24 October 2008 10:12 AM
To: Glen Kleidon
Subject: AllTalk question

Hi Glen

A query on how the AllTalk scheduler works:

We have the schedule set to 8:00;10:00;12:00;13:00;14:00;15:00;16:00;17:00;18:00;19:00 each day but there is
also activity at other times eg:  <<SNIP>> 

I know our client picks up files from \equeryfiles\Pitfiles every 10? seconds but what determines when they go to the LRS Alltalk server?

The reason I ask is because of a report from the Austin that they typically get faxed results before electronic ones.  They download hourly so there shouldn't be much of a delay there and the messages don't seem to be held here for very long.

I don't know if the faxes are being released before the electronics by us but I wouldn't expect that to happen consistently.

Any ideas?

Rob

Just stop All 3 AllTalk services.

Replace the EXE with the new one.

Restart the services.

Glen.


-----Original Message-----
From: Robbins Kerrie (SVHM) Sent: Tuesday, 14 October 2008 9:34 AM
To: Glen Kleidon
Cc: ROSE Mark; BRYANT David (SVHM)
Subject: RE: [alltalk-avp] Re: Client dowloads 'freezing' at address
information


Hi Glen,
do we just need to replace the alltalksvc.exe and restart, or do we
need to uninstall / reinstall the windows service
thanks
kerrie.


--- In alltalk-avp@..., "Glen Kleidon" <glenk@...>
wrote:
>
> Dear All,
>
> We have completed the trials of the latest Version of AllTalk
server.
>
> This release overcomes the increasing size of the the address file
problem.
>
> This release also includes Remote Download notifications - ie
notifies an
> AllTalk remote server of a successful or failed download where the
message
> has originated from a different server from the recipient.
>
> The download is located at
> http://www.lrsupport.com.au/downloads/alltalksvc.exe
>
>   _____
>
> From: alltalk-avp@... [mailto:alltalk-
avp@...]
> On Behalf Of lrs_y_gk_07
> Sent: Wednesday, 27 August 2008 11:31 PM
> To: alltalk-avp@...
> Subject: [alltalk-avp] Re: Client dowloads 'freezing' at address
information
>
>
>
>
> Dear Rodney,
>
> There have been reports of the Address.In file increasing to very
large
> size (many MB). Inspection of the address file reveals many
duplicates
> of the address data.
>
> The root of the problem appears to be stray the temporary
> Address.in.tmp file not being deleted each refresh cycle. This issue
> will be resolved in the next version of the AllTalk server.
>
> For the present we suggest scheduling a batch file to delete daily
the
> Address.in file and ESPECIALLY any address.in.tmp files that may be
> present. Schedule this before the standard first schedule login time
> when most AllTalk clients will request the address data. This should
> keep the address file down to a sensible size. Note though that the
> only reasonable explanation for the temporary address file not being
> delete is that there is a file lock issue. Ie it might be that a
batch
> file will not be able to successful deleting the temporary file
when it
> gets into the faulty state.
>
> The temporary address file should only exist for a minute or two in
any
> case, so if it is older than 3 minutes - it is faulty.
>
> --- In alltalk-avp@ <mailto:alltalk-avp%40yahoogroups.com.au>
> yahoogroups.com.au, rodneyebird <no_reply@> wrote:
> >
> > Hi Glen,
> >
> > We have had three users, over the last day, reporting Alltalk
> downloads
> > freezing at the 'Address file download' entry. They have all now
> > resolved, although one took 48 hours. All three were using version
> > 1.1.92 of the client.
> >
> > Rodney
> >
>

Dear Rodney,

There have been reports of the Address.In file increasing to very large
size (many MB).  Inspection of the address file reveals many duplicates
of the address data.

   The root of the problem appears to be stray the temporary
Address.in.tmp file not being deleted each refresh cycle.  This issue
will be resolved in the next version of the AllTalk server.

For the present we suggest scheduling a batch file to delete daily the
Address.in file and ESPECIALLY any address.in.tmp files that may be
present.   Schedule this before the standard first schedule login time
when most AllTalk clients will request the address data.  This should
keep the address file down to a sensible size.  Note though that the
only reasonable explanation for the temporary address file not being
delete is that there is a file lock issue.  Ie it might be that a batch
file will not be able to successful deleting the temporary file when it
gets into the faulty state.

The temporary address file should only exist for a minute or two in any
case, so if it is older than 3 minutes - it is faulty.






--- In alltalk-avp@..., rodneyebird <no_reply@...> wrote:
>
> Hi Glen,
>
> We have had three users, over the last day, reporting Alltalk
downloads
> freezing at the 'Address file download' entry. They have all now
> resolved, although one took 48 hours. All three were using version
> 1.1.92 of the client.
>
> Rodney
>

Hi Glen,

We have had three users, over the last day, reporting Alltalk downloads
freezing at the 'Address file download' entry. They have all now
resolved, although one took 48 hours. All three were using version
1.1.92 of the client.

Rodney

Just finished reconfiguring profile, moving keys, eqi files etc. with
a client who tells me that SJG pathology visted and changed him from
EQuery to AllTalk.  SJG let him know that St.Vincent's would probably
have to come and fix their downloading after the update.  We faxed him
because he had outstanding files and he contacted us with this info.

It would seem reasonable that if you see other providers' keys in the
EQuery directory, and you are changing the client to AllTalk, or
moving the program etc, that you move all of the keys over.  This doc
had gps and svhm keys that weren't moved.

Just wondering what policies other providers have about this?

Dear All,

I have completed the client updates for AllTalk Java (ATj2)1.2.j.1 and created a new Mac OSX AT2j Installer.  This is a beta release.

Can you please try it and give me any feedback.

This java client provides the following:

a) CRAMMD5 logon support (eliminates EQ2 password algorithm Date problem)

b) Support for EQ2 Servers - Earlier versions of AT2J did not support Logon to Legacy EQ2 servers.

c) Run all profiles on startup.

c) Updated Profile editor allowing Multiple profiles to be created and managed.

Installing the new version.

Go to www.lrsupport.com.au/allTalk_links.htm

The new installer is called "NEW Macintosh AllTalk Java Client Beta"

Download and run this.  The Installer will download the AT2j from the LRS website, Create the /Users/<currentUser>/EQ2j folder if it doesn't exist and create new getresults and getresuts.cron scripts.

The new getresults scripts simply contain a SINGLE AT2j entry which asks it to run all profiles each time, so there is no need to specify a profile name at the outset.

AT2j will start, then you can click on Profiles to add the first profile (next release will automatically start the profile editor when there are no profile specified).

To make a Desktop shortcut, simply make an Alias to AT2j.jar (works on the newer versions of OSX).  For older versions (<10.3) use the old Run All profiles script - this will still work fine.

Updating a site from Older Version

To update, a site on either EQ2j or older versions of AT2j, simply run the new installer and it will overwrite the old getresults scripts and start running immediately.  Just make sure that the old version is not running.

For Linux and Unix Systems

1. In getresults and getresults.cron, remove All but 1 of the java statements

2. Replace the text "EQj2.jar" with "ATj2.jar" in that statement

3. Also remove the Profile Name (eg 'default') in the statement

4. Copy the new AT2j.jar into the folder pointed to by the script.

In the future...

I have also completed the Transmission utility (but this is currently disabled).  Watch for new releases which will provide methods for transmitting from Java to windows clients.

Glen.

Dear All,

It appears that all versions of AllTalk server do not allow mailboxes with 3 letters (eg ABC@alltalk.galkam.com.au)  to be accessed via the web interface!

This problem is isolated to Web App (alltalkwi.exe CGI) as using the 3 Letter Name account works fine with AllTalk and EQ2j/AT2j by copying or emailing the key works fine.

We will rectify this problem in due course.

Glen.

FYI the install you helped me with this morning was to download into Smartrooms on Mac. Their software has a “feature” that doesn’t allow you to specify the result directory. There is also another “feature” that imports all results into the name of whoever is logged on at the time. Example, GK is logged on and we’re downloading GK and DM results into result directory. GK imports files, but all results for GK and DM import under GK’s name! Thought you might be interested to know that one.

>GK>>> Ah, thanks for that  useful tid-bit!! <<

So basically I have to go and move one of the profiles onto another machine. Question, how do I remove an EQ2j profile? Just delete the <profile>.eqi file??

<<snip>>

Regards,

Darius Monaghan

#!/bin/sh

cd /Users/monashstudent/eq2j

date

echo --- Default Profile  ---

java -cp EQj2.jar:. -Dcom.apple.macos.useScreenMenuBar=true eqj.EQ2j default

# Add more profiles here...

# java -cp EQj2.jar:. -Dcom.apple.macos.useScreenMenuBar=true eqj.EQ2j ep2  <<< delete this line

echo --- end of tasks ---

--- In alltalk-avp@..., rodneyebird <no_reply@...> wrote:
Glen,

Sounds good. Another problem I have with the current Mac/Java client is
the creation of a psuedo-destination directory, when the actual
destination directory is unavailable (for whatever reason).

Looking forward to the christmas release of the new client.

Rodney

Glen,

Having ongoing problems with Mac Clients (3 sites reported so far)
where they occasionally fail authentication and then don't download for
the rest of the day. They then pass authentication the next day and
scheduled downloads return to normal.

1. Is it possible to broaden the date/time match required in the
authentication process and would this reduce these failures?

2. If I install a second client on a different Mac, for manual
initiated downloads only (ie when the first client suffers the above
authentication problem), will it also fail authentication?

Rodney

Hi Glen,

I have a customer who is receiving an 'Alltalk Shell not found' error
on startup.

If I want Alltalk to startup via the 'Programs\Startup' what are the
commandline paramaters to startup scheduled and minimized?

regards,

Rodney