Also check SPOOLDEF TGSPACE(MAX= parameter. If you have actually bumped up against the maximum TGS defined here (as opposed to filling up your spool volumes) then adding another spool volume won't help. This parameter requires a cold start to change, you can't avoid that.
As the JES2 Init and Tuning Ref says: This value should include the track groups for all concurrently mounted spool volumes and for all planned spool additions... SDSF RM (Resource Display) can tell you... if the TGS limit shown is less than what is defined in JES2 parms then you have spare TGS to add spool space. It's always a nice thing to have an emergency IPL-able system laying around to fix another broken system (so you can as to run that job to create another spool volume for the busted one, or edit parmlibs, or whatever). But as Lizette said, you need to be aware of and respond to the warning messages that JES2 issues when it starts running out of a resource. Ant. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, 26 September 2013 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Issue with JES SPOOL One more thought for z/OS V1.13 and above The $S SPOOL command has the ability to allocate a new space $sspl(spool7),space=(cyl,100) $HASP893 VOLUME(SPOOL7) STATUS=INACTIVE,COMMAND=(START) $HASP646 1.3333 PERCENT SPOOL UTILIZATION $HASP423 SPOOL7 IS BEING FORMATTED $HASP630 VOLUME SPOOL7 ACTIVE 0 PERCENT UTILIZATION JES2 starts spool volume SPOOL7. If SPOOL7 is a new volume, a 100 cylinder sized data set is allocated. However, if SPOOL7 is already defined to JES2, the command fails and the HASP003 error message is issued. Now, what I do not know is if the spool volume name being used has to match the SPOOL Name prefix. Maybe someone can clarify that. Because if you are in a 100% TGS condition, can you just add a spool volume without it matching the spool volume names? That would allow for any empty spare volume being used. Or must it match? If it has to match then it would not be helpful during a 100% TGS as you could not start any job do clip the volume. Lizette -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Wednesday, September 25, 2013 5:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Issue with JES SPOOL First, Never panic if jes2 reaches 100% TGS. It can recover Second, hold all INITS, stop TSO LOGONs Third- Breath Review the $POJ command. Very powerful and has lots and lots of options. If you have a queue that you would purge daily, Say OUTPUT CLASS X is output that is not needed longer than a day or two. Then in an emergency you can issue a $POJ1-*,CLASS=X to purge all output in class X $POJ1-*,AGE>3 to purge jobs older than 3 days $POJ1-*,JOBMASK=XX* for a job on the output queue you know as having a large number of outputs. Next, review the OFFLOAD function in JES2. If you have Tape, which I like for this, you just start an offloader for output and just write it all to tape. You can restore it to jes2 later and the SYSLOG will have a listing of all jobs it offloaded. Again this has a lot of functionality that requires practice If you have Sacrifice output classes in JES2, then you just $POJ them. JES2 is still functional when 100% TGS. It just cannot run work or accept jobs. Logons are jobs entering the system You might also have a TSO session up in Operations full time (never logs off) just for such situations. You might also look at the spool volumes $DSPOOL Look to see the % usage. If they are high (80% or more on average) then you might consider adding a new volume Checkout the JES2 Redbook http://www.redbooks.ibm.com/abstracts/redp3940.html Lizette -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of baby eklavya Sent: Wednesday, September 25, 2013 5:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Issue with JES SPOOL Lizette , Thank you for quick response as always ! I"ll look at the settings which you suggested and setup automation alerts . But , am also interested to know if there is a way i could avoid a cold start of JES2 when the TGS utilization reaches 100 % . In our case , we did not have spare spool volumes to add space dynamically . As we had to do a Cold start of JES2 being the last option , am just trying to understand if i had a different option other than that . On Thu, Sep 26, 2013 at 5:18 AM, Lizette Koehler <stars...@mindspring.com>wrote: > One of my favorite things to look at for this situation is > > 1) Put the warning message lower for $HASP050 > 2) Look at your settings for ESTPAGE, ESTLINE, ESTBYTE > 3) Put some automation in place (emails or alerts) > a) Automation of the $P command to purge data based on AGE > 4) Use SDSF to see if Purging is being done > 5) In SDSF turn off any filtering, Use the ST command and SORT on QUEUE. > Then find MASCOMM (MASC works) and scroll back one page. > If there are jobs that have HOLD just above MASCOMM then you > have users issuing a HOLD against running jobs. They never purge > until they are released > > Just a few thoughts. You should not need exits. JES2 has lots of > controlling functions. You can have JES2 abend a job producing too > much output with a S722. Be careful you do not hurt production. > > > Lizette > > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of baby eklavya > Sent: Wednesday, September 25, 2013 4:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Issue with JES SPOOL > > Hello everyone , > > > Is there a different way to come out of the below situation other than > a cold start of JES2 > > *$HASP050 JES2 RESOURCE SHORTAGE OF TGS - 100 % UTILIZATION REACHED * > > Recently , we ended up in a situation where nobody could logon to the > system , and when tried to purge the jobs from console ,it didnt work > either . We are currently tuning the JESPARMS and setting up exits to > avoid such issues in future . But i was wondering if there was > anything else we could have done when the issue really happened . > > > Unfortunately , we didnt have spare spool volumes to start and i felt > that > JES2 was not accepting any commands at that point of time . Any > thoughts ?? > > Thanks in Advance , > Baby > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
