>Would this apply to z/vm 4.2? > >Would it fix the following problem? SPXTAPE encountered a tape >error, it hadn't yet cancelled itself and the SPXTAPE CANCEL command >wasn't issued, but the userid was forced off. This happened many >weeks ago and the user is still hung. > > - Tom.
Tom, While the problem could occur on z/VM 4.2 (in the form of an SPO001 soft abend), it is not likely that this APAR is related to your problem. The problem that the APAR fixes is caused by the status of DUMP spool files that are selected to be written to tape by SPXTAPE DUMP. HPC010 abends are new in z/VM 5.2.0, but we have seen several occurrences of the SPO001 abend on earlier releases of z/VM. We used the information from many of these occurrences to find the pattern that led us to the cause of this problem. There are PTFs for this APAR for z/VM 5.2.0, 5.1.0, and 4.4.0. The description of the problem and solution are below. And yes, it WILL be on an RSU. John Franciscovich z/VM Development ------------------------------------------------------------------------- **************************************************************** * USERS AFFECTED: Users of SPXTAPE * **************************************************************** * PROBLEM DESCRIPTION: * **************************************************************** * RECOMMENDATION: APPLY PTF * **************************************************************** ABENDHPC010 HPC010 ABENDSPO001 SPO001 These abends are caused by the interaction of APAR VM62853 and SPXTAPE. VM62853 changed HCPDMQ to turn off SPFOPEN and turn on SPFERRPU when deleting an SPFBK that represents a pre-allocated CP dump file. This occurs when a CP dump file requires more DASD space than is currently allocated. HCPSPK adds files that are open for creation (including pre-allocated CP dump files) to the list of files that meet the specified selection criteria to be dumped (FLSPT). Then HCPSPX checks the SPFOPEN bit to decide if the file should actually be dumped. If SPFOPEN is ON, SPXTAPE will not dump the file. If it is OFF, SPXTAPE will dump it. If HCPDMQ changes the SPFOPEN and SPFERRPU bits between the time when HCPSPK selects the file and HCPSPX decides whether to actually dump it, then HCPSPX sees it as closed (SPFOPEN = OFF) and attempts to dump the file. Since the file has no data pages, the abends occur during SPXTAPE dump processing and resource clean up for the file. This scenario is likely to happen since SPXTAPE uses so many system virtual pages for SPDBK buffers, creating a greater need for pre-allocated dump space. CONCLUSION: Code is added to HCPSPK and HCPSPX to disallow the selection by SPXTAPE of open CP dump files and files with the SPFERRPU bit on. TEMPORARY FIX: FOR RELEASE VM/ESA CP/ESA R440 : PREREQ: NONE CO-REQ: NONE IF-REQ: NONE FOR RELEASE VM/ESA CP/ESA R510 : PREREQ: NONE CO-REQ: NONE IF-REQ: NONE FOR RELEASE VM/ESA CP/ESA R520 : PREREQ: NONE CO-REQ: NONE IF-REQ: NONE
