On Fri, 25 Nov 2005 14:28:48 -0600, Hank Medler <[EMAIL PROTECTED]> wrote:
>On Fri, 25 Nov 2005 13:46:16 -0600, Hank Medler <[EMAIL PROTECTED]> >wrote: > >>->For years, JES2 wouldn't release spool space allocated to a given job >>->until all of the job was purged - i.e. freeing SPOOL space seemed to be >>->an all-or-nothing proposition. I learned today that JES2 frees up >>->SPOOL space for spin-OFF SYSOUT data sets (FREE=CLOSE) as soon as >>->they're printed or purged, i.e. JES2 no longer waits for the entire job >>->to get purged in order to free up some of the space allocated to it. >>->Apparently, this isn't something new at all: a quick test on my RESCUE >>->system shows that JES2 already behaved like that on MVS/ESA 5.2.2. >>->When did JES2 start freeing SPOOL space for spin-off data sets? Am I >>->confused again? Thanks. >> >>Gilbert, >> >>I am not entirely sure on this, but functionality for all JES2 SYSOUTs >>seems to have changed with our latest upgrade to z/OS 1.6 (at least this is >>when I started noticing). It appears that the SYSOUT (even without >>FREE=CLOSE) remain independent of each other within the Outgroup number >>groupings and allow rerouting of segments within an OUTGRP to separate >>destinations, classes, etc. For instance, if you run a simple IEBGENER and >>have your SYSUT2 route to the same OUTGRP as your MSGCLASS going to the >>held queue, you can enter the held queue of SDSF, type a '?' next to the >>output, and change it whichever class or destination you like. When you >>perform this, the OUTGRP number gets reassigned for the entry to the next >>sequential number. I believe this new (new to me anyway) ability to >>separate the SYSOUT and keep them independent is what allows JES2 to now >>free up space. If you purge this output from the queue, you should notice >>the space is cleared. As I recall, the SYSOUTs coded with FREE=CLOSE were >>always assigned their own exclusive OUTGRP number and thus space was freed >>when they were purged or printed. I could be wrong there though. When I >>started noticing this behavior recently, I thought I was going crazy and >>wondered if it was always like this. Hope this helps... >> >>Thanks, >>Hank Medler >> > >Hate to reply to myself, but I was wrong and it appears that the space is >truly only freed when a SYSOUT is coded as FREE=CLOSE. Sorry, but even >though it separates the output to another entry, the space is not freed >when purging or printing the output of a non-FREE=CLOSE SYSOUT. Sorry, but >I can't aid any help on the historic beginnings of freeing space on spin- >off datasets... I haven't been around that long. > >Thanks, >Hank Medler > Okay, deja-vu... replying to myself again. While playing with this, I noticed something strange. I coded a simple IEBGENER with no FREE=CLOSE on the SYSOUT. If I take the output from that and purge it from SDSF, the space is not freed and all the DD's can be seen when doing a '?' next to the job in the status queue. However... if I do the '?' next to the job first and perform the 'P' command next to the DD while in the held queue, the space is freed and the job does not show the particular DD from the status queue. You can even purge the JESMSGLG, JESJCL, and JESYSMSG DDs from JES2 as well. Seems odd to me that purging an entire segment from the queue would be different from purging a specific DD, but perhaps I have just been oblivious to this behavior for quite some time. Please let me know if I have... Thanks, Hank Medler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
