Very occasional PRG001 failures can occur in CP when using the ECPS:VM assist. A prominent feature of all of these failures is what appears to be an address stored into location 0 real, in the PSA. This address points to a word within a dispatcher parameter list used by the assist. This alteration of word 0 does not itself cause the system to fail. However, there are other storage overlays that are also occurring and sometimes CP code is overlaid resulting in the PRG001 abends.
It turns out that the cause of these overlays are mis-coded C macros in ecpsvm.c in the DISP2 assist. If that assist encounters a problem trying to fret a CPEXBLOK, a special code path is invoked to store some CPEXBLOK values into a dispatcher parameter list so that CP itself can fret the block upon resuming control from the assist. The mis-coded macros cause the CPEXBLOK values to be used as addresses of "where to store", and the parameter list addresses are the values that are splattered all over real storage. One of the CPEXBLOK words contains 0 ( CPEXBKUP[13] ), resulting in the store of a parameter list address at location 0.
The solution is simple. Reverse the operands in the EVM_ST macros. The original code is below, followed by the corrected code.
Other notes about this problem:
Most users that choose to run the ECPS:VM assist as is would not encounter this abend because the FREE/FRET storage trap (HRC0035DK) is enabled in VM 5-pack and in VM Sixpack. When this trap is enabled, several of the ECPS:VM assists are disabled because of incompatibility with the trap. One of these disabled assists is DISP2. Hence, trap users would never invoke the assist DISP2 and would never encounter the storage overlay due to the errors in the assist code.
Very occasional PRG001 failures can occur in CP when using the ECPS:VM assist. A prominent feature of all of these failures is what appears to be an address stored into location 0 real, in the PSA. This address points to a word within a dispatcher parameter list used by the assist. This alteration of word 0 does not itself cause the system to fail. However, there are other storage overlays that are also occurring and sometimes CP code is overlaid resulting in the PRG001 abends.
It turns out that the cause of these overlays are mis-coded C macros in ecpsvm.c in the DISP2 assist. If that assist encounters a problem trying to fret a CPEXBLOK, a special code path is invoked to store some CPEXBLOK values into a dispatcher parameter list so that CP itself can fret the block upon resuming control from the assist. The mis-coded macros cause the CPEXBLOK values to be used as addresses of "where to store", and the parameter list addresses are the values that are splattered all over real storage. One of the CPEXBLOK words contains 0 ( CPEXBKUP[13] ), resulting in the store of a parameter list address at location 0.
The solution is simple. Reverse the operands in the EVM_ST macros. The original code is below, followed by the corrected code.
Original code: EVM_ST(dl+40,CPEXBKUP[12]); EVM_ST(dl+44,CPEXBKUP[13]); EVM_ST(dl+48,CPEXBKUP[14]); EVM_ST(dl+52,EVM_L(F_CPEXB+12)); / DSPSAVE + 12 = CPEXADD / EVM_ST(dl+56,CPEXBKUP[0]); EVM_ST(dl+60,CPEXBKUP[1]);
Corrected Code: EVM_ST(CPEXBKUP[12],dl+40); EVM_ST(CPEXBKUP[13],dl+44); EVM_ST(CPEXBKUP[14],dl+48); EVM_ST(EVM_L(F_CPEXB+12),dl+52); / DSPSAVE + 12 = CPEXADD / EVM_ST(CPEXBKUP[0],dl+56); EVM_ST(CPEXBKUP[1],dl+60);
Other notes about this problem: Most users that choose to run the ECPS:VM assist as is would not encounter this abend because the FREE/FRET storage trap (HRC0035DK) is enabled in VM 5-pack and in VM Sixpack. When this trap is enabled, several of the ECPS:VM assists are disabled because of incompatibility with the trap. One of these disabled assists is DISP2. Hence, trap users would never invoke the assist DISP2 and would never encounter the storage overlay due to the errors in the assist code.