... 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
