|
Diana, We have taclked this situation in two different manners, which works depends on your environment. Of course we played with the timer in Telnet that APPEARS to be the solution for this problem that sends a 'keep alive' packet every so often and if it gets no response it supposed to end those sessions, but it didn't ever seem to do anything. SO method A) is to send an entry to a dataqueue during job initiaation including the IP address of the PC signing on. A background job then reads the DQ and attempts to PING the station. If the ping is successfull then the message is placed back on the DQ and the next is tried. If there is no response, the job is ended *IMMED and the DQ entry is discarded. THe only problem here was when there were slow dialup connections involved and large data transfers were in use (downloads or Printing). In this case we had some 'friendly kills'. THis solution does allow for multiple signons for the same individual. This solution does not require the user to do anything for the 'dangling' job to end. Method B) is to lock a data area with the same name as the user profile and hold it until the job ends. In the data area are placed the full job name for use later. The second attemp to sign on also attempts to lock the data area. When it cannot this indicates a previous job still exists. So we read the data area contents and end the job with that name *IMMED. Then we wait until we can lock the data area and then proceed. This solution does not require any background job, but does limit each user to being signed on only once. Also if the user never signs back on the previous job is not automatically ended. Hope this helps. - Larry Diana Hicks wrote: > > Our TCP/IP client access sessions are staying active after an abnormal > reboot (cold or warm) of the PC. Because it requires both the ending of the > active job and a vary off to restore the device, it has become very > inconvenient. As most of you know, it's not unusual for a PC to lock up. > This is happening on both our Windows 95 and 98 PCs. Even using the latest > version of CA (3.2) and service pack (SF53300) does not resolve the problem. > Our AS/400 is at V4R3 (cum level 8349420). All suggestions would be > appreciated. Thanks. > > Diana Hicks > Town of Jupiter > dianah@jupiter.fl.us > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- -- Larry Bolhuis | Arbor Solutions, Inc | Two rules to success in life: (616) 451-2500 | 1. Never tell people everything you know. lbolhui@ibm.net | +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.