MRUN invoked through address ASM on CMS

Edit online
If the address ASM environment is used to invoke the MRUN command (or MSTEP, or any other command which causes immediate execution of the target program) on CMS, then REXX uses a CMSCALL (SVC 204) to invoke the MRUN command. This SVC linkage introduces some potential problems in the execution of the target program:
  1. If the target program obtains GETMAIN storage during execution under the MRUN command, that storage may be implicitly FREEMAIN'ed again, without warning. This occurs because of the default CMS setting of STORECLR ENDSVC, and the fact that a CMSCALL/CMSRET pair was used in the REXX linkage to the MRUN. CMS is working as designed by implicitly freeing any GETMAIN storage that was obtained between the CMSCALL and CMSRET. This can of course lead to unpredictable behavior of the program's further execution.

    The implicit FREEMAIN can be avoided by a CMS SET STORECLR ENDCMD setting, but this in turn introduces another consideration of its own: CMS then honors any STRINIT request. Any MODULE file that is generated with the STR option causes a STRINIT request when that MODULE is executed.

    So switching to STORECLR ENDCMD is not a good solution. It is best to leave the default STORECLR ENDSVC. (IDF does not itself alter the current STORECLR setting.) The only complete solution is to make sure that the LPSW Fastpath linkage is used to invoke the MRUN command.

  2. If the target program does a CMSCALL to another program, and an event occurs to signal completion of the MRUN, then CMSCALL synchronization is destroyed by IDF's attempt to CMSRET back to REXX to complete the MRUN. CMS treats each CMSRET as being paired to the most recent CMSCALL. The most recent CMSCALL in the above scenario is the one from the target program execution. So instead of returning to the MRUN within REXX as intended, this CMSRET actually returns to the next instruction after the target program's CMSCALL.

    IDF cannot compensate for this CMSCALL/CMSRET linkage problem. All it can do is to detect when it is about to happen. This is done by recording the current SVC nesting depth at entry to its address ASM command handling, and checking that the nesting is the same just before it returns from that command handling. If not, another SVC depth was created (or destroyed) while executing the target program, and CMS is hopelessly confused if IDF returns. So instead IDF issues a series of messages about the situation, telling you to consult this section of the documentation for details. A re-IPL of CMS is needed afterwards.

    Exactly the same situation occurs when using LINK or SVC 202 linkage to another program instead of CMSCALL. Again, IDF detects a change in the CMS SVC nesting depth, issues its messages, and needs a re-IPL.

  3. If the target program does a DMSKEY NUCLEUS, DMSKEY USER, or DMSKEY LASTUSER which does not specify the NOSTACK option, and an event occurs to signal completion of the MRUN before the corresponding DMSKEY RESET in the target program, then a CMS ABEND occurs, since the change of key appears to have occurred from within IDF and is not restored before returning to the calling function, in this case REXX.

These considerations apply only to an address ASM invocation on CMS. They are of no concern if you use the default LPSW Fastpath interface to invoke the command. With no SVC linkage used in that path, each of these potential problems is bypassed.