IBM OS/390 User Manual
is an explicit request. If a separate module is requested, then the additional
virtual storage requirement is implicit in that request.
virtual storage requirement is implicit in that request.
The MVS GETMAIN macro is an explicit request for additional virtual storage.
You can use GETMAIN to obtain a single block or multiple blocks of virtual
storage. You can specify either a fixed or variable amount of virtual storage. At
execution time, the macro provides information to indicate whether the virtual
storage is obtained, and also to pass the address of the beginning of the block
and its size (where variable block sizes are specified). Further points should be
mentioned relating to explicit virtual storage requests.
You can use GETMAIN to obtain a single block or multiple blocks of virtual
storage. You can specify either a fixed or variable amount of virtual storage. At
execution time, the macro provides information to indicate whether the virtual
storage is obtained, and also to pass the address of the beginning of the block
and its size (where variable block sizes are specified). Further points should be
mentioned relating to explicit virtual storage requests.
1. Under MVS, you cannot take available virtual storage within an address
space. MVS must allocate the virtual storage through the GETMAIN macro to
the load module, even though the unused virtual storage is within the
boundaries of the address space. The task will abnormally terminate if you
attempt to reference unallocated virtual storage.
the load module, even though the unused virtual storage is within the
boundaries of the address space. The task will abnormally terminate if you
attempt to reference unallocated virtual storage.
2. Although the allocation of blocks of virtual storage must be from within the
address space, they are not necessarily contiguous.
To dynamically call modules into available virtual storage (make an implicit
request), you should use the set of macros associated with dynamic program
structure. When you use these macros, MVS automatically examines available
virtual storage and loads the module into an open area.
request), you should use the set of macros associated with dynamic program
structure. When you use these macros, MVS automatically examines available
virtual storage and loads the module into an open area.
13.2.1.4 Communications Region Simulation
A COMRG macro can be written to build an area similar to the VSE
communication region and return the address of this area in register 1.
communication region and return the address of this area in register 1.
If your program is not going to use this information immediately, you should load
the address from register 1 into another register (2-12), or store the address into
a fullword in your program. This macro can obtain variable data to simulate the
communications region layout in some of the following ways:
the address from register 1 into another register (2-12), or store the address into
a fullword in your program. This macro can obtain variable data to simulate the
communications region layout in some of the following ways:
•
MVS data can be communicated to a program by means of the PARM field of
the EXEC statement. When control passes to your program from MVS,
register 1 contains the address of a fullword on a fullword boundary in your
area of virtual storage. The high order bit (bit 0) of this word is set to one.
The low-order three bytes of the fullword contain the address of a two-byte
length field on a halfword boundary. The length field contains a binary count
of the number of bytes in the PARM field, which immediately follows the
length field. If you omitted the PARM field in the EXEC statement, the count is
set to zero.
the EXEC statement. When control passes to your program from MVS,
register 1 contains the address of a fullword on a fullword boundary in your
area of virtual storage. The high order bit (bit 0) of this word is set to one.
The low-order three bytes of the fullword contain the address of a two-byte
length field on a halfword boundary. The length field contains a binary count
of the number of bytes in the PARM field, which immediately follows the
length field. If you omitted the PARM field in the EXEC statement, the count is
set to zero.
•
Note that if you specify numbers in the PARM parameter, they are translated
into decimal digits. If you specify PARM=101, the PARM field is x
into decimal digits. If you specify PARM=101, the PARM field is x
′
F1F0F1
′.
•
Data supplied in this manner is available for the duration of a single job step.
If multiple job steps within a job require the data, the PARM field must be
specified in each EXEC card or propagated through all EXEC cards in a job
through procedure variables.
If multiple job steps within a job require the data, the PARM field must be
specified in each EXEC card or propagated through all EXEC cards in a job
through procedure variables.
•
A routine is needed to return a bit string to the byte associated with the
external name UPSI. If an assembler program uses the COMRG macro and
references only date, UPSI and job name as data, then no logic changes are
required with this approach.
external name UPSI. If an assembler program uses the COMRG macro and
references only date, UPSI and job name as data, then no logic changes are
required with this approach.
•
If you use the COND parameter of the EXEC card (instead of UPSI switches)
to control job flow, then the UPSI tests can be simply removed from your
to control job flow, then the UPSI tests can be simply removed from your
276
VSE to OS/390 Migration Workbook