This switch causes the AMOS subroutine to execute most commands (anything except CMD and DO files) as true subroutines within the current process, rather than in another process, as would otherwise be the normal behavior for A-Shell. For example, XCALL AMOS,"RUN XYZ" would run the XYZ program within the current process, using the current job environment. This is how most versions of AMOS.SBR worked under the old AMOS operating system. CMD and DO files cannot (currently) be executed within the current process, so they will run in a separate process regardless of the AMOS_RUNSBR switch.
Aside from making the A-Shell version of the AMOS subroutine act more like most AMOS versions of AMOS.SBR, the other advantage of the AMOS_RUNSBR switch is that it is much more efficient. We recommend that you use this switch, and would have made it the default behavior, except for historical compatibility. There may be situations where the use of a separate process is actually better, particularly when you don’t want side effects from the subroutine process to linger, either on the screen or in the job’s current environment. For example, any screen output generated by the subroutine will remain on the screen after return to the caller if the subroutine executes within the current job/process. Otherwise, the screen output of the subroutine will appear in a different window, or in a different virtual screen, which will be discarded when it returns. Similarly, any changes to the job’s environment, such as the current PPN or other status settings will be discarded if the subroutine executes in a separate process, but will be retained if the subroutine executes within the current process. For example, consider:
xcall AMOS,"LOG DSK1:100,2"
xcall AMOS,"SET HEX"
The commands above make no sense if OPTIONS=AMOS_RUNSBR is not specified, since the effect of the command (changing the ppn or a job status setting) would otherwise be lost as soon as the command completed, since it would be taking place in a separate job and process from the caller.
When XCALL AMOS runs a command within the current job, it guarantees the child process will have a certain amount of memory, even if it has to be specifically allocated on the fly. The amount defaults to 360K, but can be specified with the second argument to the MEMORY parameter in miame.ini.
