I have to reset user sessions frequently on our iSereis. The job status is usually DSPA. How can I monitor for DSPA job status in QINTER on an iSeries and automatically end the sessions?
Something isn't making sense. You shouldn't be seeing many DSPA jobs. Such jobs normally go to DSPW status rather than staying in DSPA status.
Even so, I wouldn't expect any kind of problem from it. It should only happen when (1) the maximum activity level hasn't yet been reached for that memory pool and (2) the DSPA job hasn't reached its time-slice end. If there are still activity levels available, there's no reason to end a DSPA job -- it's not interfering with anything.
And if it has an excessively large time-slice assigned, then run the job under a class that provides more appropriate values. Why assign a large value if you're going to end a job that uses the value? Just make it smaller and let the system handle it from then on.
Before doing anything as drastic as ending an interactive job, you should determine why a DSPA status happens. Then change it.
If you're running on Power7, you should have a new enough system to qualify for an IBM Support call even if you don't have a normal support contract. Get some IBM advice first. Something seems off with this. Find out what it is, especially if it is causing problems for workstation users.
Ask IBM why your interactive jobs are going into DSPA status and causing you to have to "reset" them (whatever that means).
Tom
Thank you, Tom. I will look into the time-slice scenario. Meanwhile, here's some background on the problem we are experiencing:
Our company has recently replaced thin clients with PCs. Despite training on a windows environment several of the users are not closing sessions properly. They may think they are closing a window for one application when they hit the 'X', but in reality they are closing the Power7 session without properly signing off. The simple solution is to run all windows maximized so they can't accidently shut down a "background" program. The bottom line, it's a USER problem.
To reset a session I end the interactive job, then check whether the device needs to be varied on via wrkcfgsts *dev. 99% of the time ending the job brings the user back to the sign on screen.
Meanwhile, here’s some background...
Can you create the problem on demand? When I go through the sequence you describe, my device goes straight to DSC (disconnected) status. When I start the session again, I reconnect to it. At least, that's what happens with a "named" device.
If I use a generic QPADEV* connection, it simply ends and goes away almost as soon as the window is closed on the PC.
If you can cause the problem on demand, we might locate a reason that might be changed.
Tom
If you see the problem again, please use WRKJOB option 11, then press F21=Include.
The mess that appears might be a fairly lengthy list of procedures. Scroll to the bottom and look up the stack until you see anything that looks like any kind of "wait" function. See if you can copy/paste that line and maybe a half-dozen lines above it here. If copy/pasting a few more lines looks like they'll be useful, include them. You might need to scroll backwards a screen to get the previous lines.
If possible, paste it into a simple text document, then copy/paste from the text document. Paste it into a {code} block here. That will help preserve end-of-line characters (which don't exist on green-screens) and will use a fixed font.
Seeing what procedures are causing the 'A' part of the status could give a major clue.
Tom
Discuss This Question: 4 Replies