eMS Interface for Display Terminals CMS has an interface that allows it to display large amounts of data in
a very rapid fashion. This interface for 3270 display terminals (also
3138, 3148, and 3158) is much faster and has less overhead than the
normal write because it displays up to 1760 characters in one operation,
instead of issuing 22 individual writes of 80 characters each (that is
one write per line on a display terminal). Data that is displayed in
the screen output area with this interface is net placed in the console
spool file.
The DISPW macro allows you to use this display terminal interface.
It generates a calling sequence for the CMS display terminal interface
module, DMSGIO. DMSGIO creates a channel program and issues a DIAGNOSE instruction (Code X'58') to display the data. DMSGIO is a TEXT file
which must be loaded in order to use DISPW. The format of the CMS DISPW macro is: .- --------------------------------------------------------------------, I I (label] I I I where: "fa bel bufad
r , I L INE=n I ILINE=OI L J r , I BYTES=bbbb I L J DISPW r ,
bufad "LINE=n I L J r , I,BYTES=bbbbl L J [ERASE=YES] [ CANCEL=YES] I I , I , ________________________ J is an optional macro statement label.
is the address of a buffer containing the data to be
written to the display terminal.
is the number of the line, 0 to 23, on the
display terminal that is to be written. Line
number 0 is the default.
is the
on the
number of bytes
display terminal. (0 to 1760) to be written 1760 bytes is the default. [EHASE=YES] specifies that the display screen is to be erased before
the current data is written. The screen is erased
regardless of the line or number of bytes to be
displayed. Specifying ERASE=YES causes the screen to go
into "MORE" status.
[ CANCEL=YES ] causes the CANCFL oppration to be performed: the output
area is erased. It is advisable for the user to save registers before issuing the tISPW macro and to restore them after the macro, because neither the
macro nor its called modules save the user's registers.
2-34 IBM VM/370 System Logic and Program Determination--Volume 2

OS Macro Simulation Under eMS When a language processor or a user-written program is executing in the CMS environment dnd using Os-type functions, it is not executing os
code. Instead, CMS provides routines that simulate the os functions
required to support as language processors and their generated object
code. CMS functionally simulates the os macros in a way that presents
equivalent results to programs executing under CMS. The as macros are
supported cnly 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 exist because of the limited CMS simulation of
the as macros.
Figure 7 shows the as macro functions that are partially or
completely simulated, as defined by SVC number.
as Data Management Simulation The disk format and data base organization of CMS are different froll
those of as. A CMS file produced by an as program running under eMS 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 os 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
IBCDASDI. )
HANDLING FILES THAT RESIDE ON CMS DISKS CMS can read, write, or update any as data that resides on a eMS disk.
By simulating as macros, CMS simulates the following access methods so
that as data organized by these access methods can reside on eMS 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 following ite.s in the data set.
Refer to Figure 7 and the "Simulation Notes," then read "Access Method Support" to see how CMS handles these access methods. Since CMS does not simulate the indexed sequential access aethod (ISAM), no as program that uses 1SAM can execute under CMS. Therefore,
no program can write an indexed sequential data set on a CftS disk. CMS Introduction 2-35