Re: Server Pac Issues with z/OS V1.9 SB37 SYSUT1 and other stuff
Lizette - I'm sorry to see that you're having problems with PDSMAN FastCopy. There is an already existing APAR from January of this year that addresses a FastCopy issue with GIMUNZIP. The CA APAR number is QO95053. Applying this PDSMAN maintenance should resolve your FastCopy problem. Regards, Jeffrey King CA PDSMAN Principle Software Engineer Columbus, Ohio USA tel: +1 614 785 2743 or x62743 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Wednesday, May 21, 2008 4:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Server Pac Issues with z/OS V1.9 SB37 SYSUT1 and other stuff I just wanted to let everyone know of an issue I had with the Serverpac Install. First, YES - I did not read the PSP. So it is not a surprise I made a small miscalculation. In Dec 2007 there was a fix that was release for GIMUNZIP. It has to do with SB37 abends on SYSUT1 during the Unzip of a PDS/E (POE) data set. Apparently IBM has hardcoded in the GIMUNZIP process how much space to dynamically allocate for SYSUT1 when recreating the PDS/E data set from teh archive file. This is what causes the SB37. The SCEEMOD2 data set is much bigger today than under z/OS V1.7. So I had to install the following fixes UO00674 UO00678 and UO00649. Once I had these installed and added (apf' authorized) to the RECEIVE JOBLIB statement, everything is running much better. There are two issues that I will bring up with IBM at the next Share I attend. Why is this hardcoded and not part of an ARCHDEF control card statement? And two, we have FASTCOPY (PDSMAN) in shop. I have to manually add the JCL statement //FCOPYOFF DD DUMMY to all steps before I submit. Otherwise I get bad errors when FASTCOPY tries to work on PDSE data sets. Anyway, so much for not reading. Lizette -- 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 -- 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: Server Pac Issues with z/OS V1.9 SB37 SYSUT1 and other stuff
... Apparently IBM has hardcoded in the GIMUNZIP process how much space to dynamically allocate for SYSUT1 when recreating the PDS/E data set from teh archive file. This is what causes the SB37. The SCEEMOD2 data set is much bigger today than under z/OS V1.7. snip There are two issues that I will bring up with IBM at the next Share I attend. Why is this hardcoded and not part of an ARCHDEF control card statement? And two, we have FASTCOPY (PDSMAN) in shop. I have to manually add the JCL statement //FCOPYOFF DD DUMMY to all steps before I submit. Otherwise I get bad errors when FASTCOPY tries to work on PDSE data sets. No need to wait for SHARE, I can address your first issue now: The space information for SYSUT1 is NOT hardcoded -- it is based on the actual archived data set and is unique for each data set. In more detail, during the GIMUNZIP process SYSUT1 is allocated to contain the IEBCOPY-unloaded form of the PDS(E). GIMUNZIP uses the space information for the actual archived PDS(E) to determine how large to allocate SYSUT1 (this space information is unique for each archived data set). Unfortunately for some PDS(E) data sets, like SCEEMOD2 in your example, the unloaded form is larger than the PDS(E). Therefore, SYSUT1 as allocated is too small, thus SB37. The fix supplied by UO00678 allocates SYSUT1 larger than the archived PDS(E). Kurt Quackenbush -- IBM, SMP/E Development -- 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: Server Pac Issues with z/OS V1.9 SB37 SYSUT1 and other stuff
Jeffrey, Thanks, that is exactly the issue I was having. I will put it on PDSMAN very quickly. Lizette -Original Message- From: King, Jeffrey E [EMAIL PROTECTED] Sent: May 22, 2008 8:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Server Pac Issues with z/OS V1.9 SB37 SYSUT1 and other stuff Lizette - I'm sorry to see that you're having problems with PDSMAN FastCopy. There is an already existing APAR from January of this year that addresses a FastCopy issue with GIMUNZIP. The CA APAR number is QO95053. Applying this PDSMAN maintenance should resolve your FastCopy problem. Regards, Jeffrey King CA PDSMAN Principle Software Engineer Columbus, Ohio USA tel: +1 614 785 2743 or x62743 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Wednesday, May 21, 2008 4:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Server Pac Issues with z/OS V1.9 SB37 SYSUT1 and other stuff I just wanted to let everyone know of an issue I had with the Serverpac Install. First, YES - I did not read the PSP. So it is not a surprise I made a small miscalculation. In Dec 2007 there was a fix that was release for GIMUNZIP. It has to do with SB37 abends on SYSUT1 during the Unzip of a PDS/E (POE) data set. Apparently IBM has hardcoded in the GIMUNZIP process how much space to dynamically allocate for SYSUT1 when recreating the PDS/E data set from teh archive file. This is what causes the SB37. The SCEEMOD2 data set is much bigger today than under z/OS V1.7. So I had to install the following fixes UO00674 UO00678 and UO00649. Once I had these installed and added (apf' authorized) to the RECEIVE JOBLIB statement, everything is running much better. There are two issues that I will bring up with IBM at the next Share I attend. Why is this hardcoded and not part of an ARCHDEF control card statement? And two, we have FASTCOPY (PDSMAN) in shop. I have to manually add the JCL statement //FCOPYOFF DD DUMMY to all steps before I submit. Otherwise I get bad errors when FASTCOPY tries to work on PDSE data sets. Anyway, so much for not reading. Lizette -- 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 -- 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 -- 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
Server Pac Issues with z/OS V1.9 SB37 SYSUT1 and other stuff
I just wanted to let everyone know of an issue I had with the Serverpac Install. First, YES - I did not read the PSP. So it is not a surprise I made a small miscalculation. In Dec 2007 there was a fix that was release for GIMUNZIP. It has to do with SB37 abends on SYSUT1 during the Unzip of a PDS/E (POE) data set. Apparently IBM has hardcoded in the GIMUNZIP process how much space to dynamically allocate for SYSUT1 when recreating the PDS/E data set from teh archive file. This is what causes the SB37. The SCEEMOD2 data set is much bigger today than under z/OS V1.7. So I had to install the following fixes UO00674 UO00678 and UO00649. Once I had these installed and added (apf' authorized) to the RECEIVE JOBLIB statement, everything is running much better. There are two issues that I will bring up with IBM at the next Share I attend. Why is this hardcoded and not part of an ARCHDEF control card statement? And two, we have FASTCOPY (PDSMAN) in shop. I have to manually add the JCL statement //FCOPYOFF DD DUMMY to all steps before I submit. Otherwise I get bad errors when FASTCOPY tries to work on PDSE data sets. Anyway, so much for not reading. Lizette -- 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
