>We just migrated from 4.4 to 5.2 RSU 0601 and we saw a similar >condition. The spool filled up prematurely while migrating 50,000 spool >files to 5.2 using SPXTAPE. The spool area completely filled, and when >we purged out all the visible spool files, not SDFs, utilization still >showed 17%. When we reIPLed, utilization dropped to 2%. One 3390 mod-9 >should have given us enough space when compared to the 4.4 system which >used 5 mod-2s (2226 cyl. each). We had to scramble and set up 2 more >mod-9s to finish the cutover. Since we had only a 2 hour window, >needless to say things got a little challenging! > >We didn't have time to IPL again after the SPXTAPE LOAD. Should we >anticipate a big reduction in spool usage stats after the next outage?
This is a problem that has been fixed by APAR VM63961 (PTF UM31725 on z/VM 5.2.0).There are also PTFs for z/VM 5.1.0 and 4.4.0 (UM31724 and UM31723, respectively), but the problem is much less likely to occur there. Here is the APAR closing text. It is scheduled to be on the next RSU for z/VM 5.2.0. **************************************************************** * USERS AFFECTED: Users of SPXTAPE LOAD * **************************************************************** * PROBLEM DESCRIPTION: * **************************************************************** * RECOMMENDATION: APPLY PTF * **************************************************************** HCPSPN incorrectly checks the results of a call to HCPPAGSW by testing the condition code. HCPPAGSW does not set the condition code. HCPSPN should be checking the return code in R15 when control is returned from HCPPAGSW. This incorrect test causes HCPSPN to believe that the DASD write of a SPOOL data page failed when it actually worked. HCPSPN then attempts to recover by allocating a new DASD slot and trying again. Since the condition code was not specifically set by HCPPAGSW, it is sometimes zero and sometimes non-zero. Every time a non-zero condition code is returned, HCPSPN allocates another SPOOL DASD slot, wasting the slot that was previously allocated. This causes many more slots to be allocated than necessary. Eventually, enough random zero condition codes are returned that SPXTAPE LOAD completes. On releases prior to 5.2.0, HCPPAGSW always returns condition code 0 even though it is not a documented interface. On those releases, HCPSPN works when the page write succeeds but does not detect the error when the page write fails. CONCLUSION: Code is added to test the return code from HCPPAGSW in R15 instead of the condition code. John Franciscovich z/VM Development
