Re: Early Release of JES2 SPOOL space for spin-off data sets
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 IIRC, it was around ESA 4.0. -teD Me? A skeptic? I trust you have proof! -- 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
Re: Early Release of JES2 SPOOL space for spin-off data sets
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. NOT true. It is freed after the JOE is printed, now. I remember that ops used to depend on the fact that it wasn't and they could check certain maintenance jobs, even if the output was printed. Then the 'functionality' disappeared. -teD Me? A skeptic? I trust you have proof! -- 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
Re: Early Release of JES2 SPOOL space for spin-off data sets
In [EMAIL PROTECTED], on 11/25/2005 at 03:10 PM, Bruno Sugliani [EMAIL PROTECTED] said: It cannot be freed because what you purge is a JOE ( Job Output Element ) Unfortunately JOE belongs to JQE ( Job Queue Element ) and the allocation (the number of trackgroups used by the JOE's) is written in the JQE . No. What controls it is the IOT. If two SYSOUT data sets are in the same IOT, then JES2 can't purge the space until it has purged every JOE for both data sets. A data set with its own IOT will still pertain to the job's JQE. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Early Release of JES2 SPOOL space for spin-off data sets
We're talking real spin-off data sets here, right? The way I do it is with a started job (in other words: Give the STC a jobcard) and putting JESLOG=(SPIN,'00:00') in the job card. It looks a little strange via SDSF DA and ? and gives me a JESYSMSG and JESMSGLG per day. Comes in mighty handy for STCs that have a lot of system WTOs, though. Regards, Barbara Nitz -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner -- 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
Re: Early Release of JES2 SPOOL space for spin-off data sets
-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 -- 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
Re: Early Release of JES2 SPOOL space for spin-off data sets
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 -- 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
Re: Early Release of JES2 SPOOL space for spin-off data sets
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
Re: Early Release of JES2 SPOOL space for spin-off data sets
On Fri, 25 Nov 2005 14:28:48 -0600, Hank Medler [EMAIL PROTECTED] wrote: 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. Correct It cannot be freed because what you purge is a JOE ( Job Output Element ) Unfortunately JOE belongs to JQE ( Job Queue Element ) and the allocation (the number of trackgroups used by the JOE's) is written in the JQE . So unless you delete all elements ( that means you delete the JQE also ) you do not free the space as it remains allocated by the JQE . This is from memory For free=close i guess it is different and i do not know how it works .I think it came with change in BERTs cleanup but i do not know how. Bruno -- 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
Re: Early Release of JES2 SPOOL space for spin-off data sets
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 SPOOL space is freed for individual SYSOUT Data Sets only when it has been dynamically allocated. All JCL allocated SYSOUT, even with FREE=CLOSE, has SPOOL allocated in the Job's primary IOT. Whan a SYSOUT Data Set is dynamically allocated, it gets its own allocation IOT, so the space can be freed when the Data Set is deleted. All SYSOUT allocated in the Job's primary allocation IOT will be freed only when the entire Job is purged. Keith E. Moe Laid Back Software, Inc. http://www.laidbacksoftware.com [EMAIL PROTECTED] (408) 749-0655 (voice and FAX) (408) 480-2067 (cell) We take our clients seriously, not ourselves. -- 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
