RETRIEVE BUFFER SEND is used by HNDIUCV and CM:S ABEND processing to terminate the virtual
machine's lUCY environment. It should not be issued directly by a program.
is issued directly by a program. SETMASK should not be used because this function disables certain lUCY external
interrupts for the entire virtual machine. Thus, other programs running in
the same virtual machine may be affected. SETCMASK should not be used because this function disables certain lUCY external
interrupts for the entire virtual machine. Thus, other programs running in
the same virtual machine may be affected. SEVER is invoked by a program via the CMSIUCV macro. This lUCY function may
be invoked to SEVER all existing paths for the CMS lUCY program that has
issued the HNDIUCV CLR macro. This lUCY function should not be
issued directly by a program. TEST COMPLETION is issued directly by a program. However, the issuer must be careful that a
specified message id or path id is specified in the lUCY parameter list. If it
is not, lUCY completes the first message on the REPLY queue for the entire
virtual machine. This message may not belong to the application that issued
the TEST COMPLETION. TEST MESSAGE should not be used because this function places the entire virtual machine in
a wait state if no incoming messages or replies are pending. Thus, other pro­
grams running in the same virtual machine may be affected. CMS lUCY Support 369

OS Macro Simulation Under eMS When a language processor or a user-written program is executing in the eMS environment and using OS-type functions, it is not executing as code. Instead, eMS provides routines that simulate the as functions required to support as lan­
guage processors and their generated object code. eMS functionally simulates the as macros in a way that presents equivalent results
to programs executing under eMS. The as macros are supported only to the
extent stated in the publications for the supported language processors, and then
only to the extent necessary to successfully satisfy the specific requirement of the
supervisory function.
The restrictions for COBOL and PL/I program execution, listed in "Executing a Program that Uses as Macros" in the VM / SP Planning Guide and Reference, exist
because of the limited CMS simulation of the as macros.
Figure 42 on page 371 shows the as macro functions that are partially or com­
pletely simulated, as defined by SVC number. OS Data Management Simulation
The disk format and data base organization of CMS are different from those of
as. A CMS file produced by an as program running under CMS and written on a CMS disk, has a different format from that of an as data set produced by the same
as program running under as and written on an as disk. The data is exactly the
same, but its format is different. (An as disk is one that has been formatted by an
as program, such as the Device Support Facility.)
Handling Files that Reside on eMS Disks CMS can read, write, or ulJdate any as data that resides on a CMS disk. By simu­
lating as macros, CMS simulates the following access methods so that as data
organized by these access methods can reside on CMS disks:
direct
partitioned
sequential
identifying a record by a key or by its relative position within
the data set.
seeking a named member within the data set.
accessing a record in a sequence in relation to preceding or fol­
lowing items in the data set.
Refer to Figure 42 on page 371 and the "Simulation Notes," then read "Access
Method Support" to see how eMS handles these access methods. Since eMS does not simulate the indexed sequential access method (ISAM), no OS program that uses ISAM can execute under CMS. Therefore, no program can
write an indexed sequential data set on a eMS disk.
Handling Files that Reside on OS or DOS Disks
By simulating as macros, CMS can read, but not write or update, as sequential
and partitioned data sets that reside on as disks. Using the same simulated OS 370 VM/SP System Programmer's Guide