> In a case # 2 situation, you could force the job to be swapped out > unconditionally by quiescing it: E jobname,QUIESCE. This might give you some > time to purge enough unneeded output to be able to login to TSO and perform > further actions. Actions might be to save the output to a data set then > cancel the job or allocate new spool space and let the job continue (E > jobname,RESET), or whatever suits your needs.
Good idea, but have you had only a z/OS console in a 100% spool shortage recently? Problems I encountered in that situation: - Logon not possible - The system's console had an American keyboard layout (on a really stupid 3270 emulation that doesn't know the difference between ctrl and enter, remote login) and my actual keyboard is German: Just issuing the JES2 commands with all its special characters to determine *which* was the offending job became a nightmare. - Cancel command of offending job got accepted, but the job did not terminate (because it needs spool space to terminate - TGSs were at 100%) - Job had to get forced (force arm also didn't work). - I am used to using SDSF, so using the JES2 commands (aside from the keyboard issue) to purge the offending job was a real challenge. The first time I hit these problems, I learned my lesson: 1. Always keep a spare spool volume (or two) around and have written notes on how to activate that. Also, keep in mind that some JES shortages (I forgot which) prevent the addition of new volumes, IIRC because that also needs *some* spool space. (An ADCD system comes with a minuscule spool, and I went through some iterations for increasing check point sizes, too, to accomodate the larger spool.) 2. Always keep some older output around that can be purged so that the TSO logon can succeed (even if I understand the zeal to have the JES2 spool as empty as possible). Always attempt to logon before purging anything. If you're able to logon, first save the offending output (even if it gets a B37) so you have some chance of problem determination. 3. All else failing, have an established procedure for a JES2 cold start, *especially* if you run a monoplex. 4. Have automation procedures in place to cancel a job consuming more than 50% of spool space (I had to change the JES init parms to accomplish that). 5. Have automation procedures in place to report shortages before they hit 100% (jobs are not executed anymore or new address spaces started once you're in 100%). The primary goal in this situation is always to logon to TSO again. Some installations have a local non-SNA TSO user that is always running and never logs off. At least that allows for easier problem analysis (aside from the keyboard issue), but I was unlucky enough having to purge a job that the logged-on userid didn't have RACF access to, and the userid didn't have RACF SPECIAL, either. I firmly believe that Murphy's law applies in any JES2 shortage! :-) Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
