I have a client that has users either dropping connection to Ashell or that have a bad habit of NOT logging off their PCs when leaving the desk. This leaves ashell jobs open and the job is actually dropped by the system but the jobtbl.sys entry remains. Eventually the job table becomes full. However, I cannot delete it because it says the file is in use. The KILL command does not seem to clear these and doing KILLing one at a time is a lengthy process (sometimes there are jobs there for weeks and dozens of them).

Is there a method or process I can write to delete the jobtbl.sys file in windows. I was going to research writing a program to clear records but fear I may not do this correctly causing further issues.

Good day -

It is hard to get everyone cleared off windows systems it seems. IMO if it gets so bad that the jobtbl is full, i would get everyone off, reset the windows server (which should kill all active connections), then do your maintenance before putting users back to work. (erase jobtbl.sys and qflock.sys).

If that is not plausible, i use the QUTL utility, and the ZAP option. This always works well to clear out jobs that are active or zombie. It is one at a time but works better than KILL.

Frank is right about the QUTL > ZAP utility - that's one way that will always work. (Doing it on a job that is actually running will cause that job to abort with a "jobtbl zapped" error, but that's the least of your concerns here.)

Disconnecting all the users and then erasing the JOBTBL.SYS and QFLOCK.SYS files will also do it (but may not be practical). Note that merely resetting the server will not remove those files, although it may not be a bad idea to add a command to the startup to do so.

A few other comments which may or may not be helpful...

In some cases, KILL/K will work better than mere KILL, but in all cases, KILL only works if there is actually a process attached to the job. What often happens in P2P environments is that people shut down their PC without logging out of A-Shell, which generally results in one of these orphan JOBTBL.SYS records. In the most typical cases though, since the JOBTBL record contains the machine ID (you can see this with SYSTAT/C), when that same client PC launches another A-Shell session, A-Shell will recognize that there is already a JOBTBL entry for that machine:window# and will reuse it (after displaying the message "%Warning - instance already exists for [machine:##] - over-writing". So in order to accumulate jobs until the job table fills up, you need a larger set of PC's, or perhaps some PC's that occasionally open many sessions and then somehow abandon them. (If that doesn't sound right, we should examine the ashlog.log and/or SYSTAT/C to see what kind of ID's are being generated.)

In the ashlog.log (assuming you have TRACE=INOUT, which you should), you'll see entries like:

That sequence illustrates a session lasting 5 minutes, 22 seconds, on machine JACKT450. The :01 following that indicates that at the time of the launch, it was the first A-Shell session active for that client machine. If you are seeing higher numbers, like :05 and :09, that suggests a user who doesn't realize she already has many minimized sessions already going, and keeps opening new ones. (I myself am frequently guilty of that.) The -2 following that indicates job #2 was assigned. The final entry shows it logging out. Any "in:" entries without matching "out:" entries are going to accumulate. Reviewing the log periodically is a good way to identify a variety of systematic configuration or operational problems.

For telnet or ssh connections, disconnects will usually trigger an event on the server which will be logged in the ashlog.log (provided you have TRACE=SIGHUP set in the MIAME.INI, which you should). But in the Windows P2P case, the problem is that the only process capable of logging such an entry is the instance of A-Shell running on the client, and if you kill it in such a way that it is unable to respond (such as using the Task Manager, or shutting down the PC), then there won't be any record in the ashlog.

Depending on what's really happening, you might benefit from IATIMEOUT . For example, if you set the timeout to 30 minutes, you might succeed in cleanly logging out some of these sessions before the PC goes into hibernation, or the user shuts it off.