Converting CMS Files
Converting Disk Formats
Make the programs or EXEC files aware of the difference in format so that
they can properly execute under either system.
Although VM/SP can be run with only the 800-byte file system, as previously dis­
cussed, CMS disk formats and files must be converted to take advantage of the
performance and capacity enhancements of VM/SP.
The conversion of disk formats can be achieved in several ways. The two main
ones are:
Allocate a second minidisk, format it under VM/SP using the FORMAT com­
mand with the desired blocksize, and use the COpy command to copy files
from the old format disk to the extended format disk. The old format disk can
then be deallocated.
Dump the files from the old format disk to tape using the TAPE DUMP com­
mand. Format the disk under VM/SP with the desired blocksize. Load the
files from the tape using the TAPE LOAD command.
Converting MACLIB and TXTLIB Files
Program Conversions
Auxiliary Directories
Program Development
MACLIB and TXTLIB files must be re-created to get them into the new library
formats. Under VM/SP, use the VMFMAC EXEC procedure as described in the VMISP Installation Guide. However, there is no need to do so unless the library
needs the expanded capacity provided by the new format.
Programs that do CMS 110 do not need to be converted (except, as previously dis­
cussed, for those referencing internal control blocks) to be run against files on
extended format disks. All performance advantages are achieved by merely moving
the files to an extended format disk. In addition, the maximum size of the file is
limited only by the 65,533 record limit and not by the old 16,060 block limit.
Existing programs that need to access files larger than 65,533 records must be con­
verted to take advantage of the greater capabilities of the VM/SP file system. See
the VM I SP eMS User's Guide for more information.
Programs that use auxiliary directories must be regenerated when moved to an
extended format disk. This regeneration would be required anyway because of
movement from one disk to another.
The Conversational Monitor System includes commands to create and compile
source programs, to modify and correct source programs, to build test files, to exe­
cute test programs and to debug from the terminal. The commands of CMS are
especially useful for OS and VSE program development, but also may be used in
combination with other operating systems to provide a virtual machine program
development tool.
CMS uses the OS and VSE compilers via interface modules; the compilers them­
selves normally are not changed. In order to provide suitable interfaces, CMS
Introduction To eMS 309

I ABEND Processing
includes a certain degree of as and VSE simulation. For as, the sequential, direct,
and partitioned access methods are logically simulated; the data records are phys­
ically kept in the chained fixed-length blocks, and are processed internally to simu­
late as data set characteristics. For VSE, the sequential access method is sup­
ported. CMS supports VSAM catalogs, data spaces, and files on as and DOS disks using the Access Method Services portion of the VSE/VSAM program prod­
uct. as Supervisor Call functions such as GETMAIN/FREEMAIN and TIME are
simulated. The simulation restrictions concerning what types of as object pro­
grams can be executed under CMS are primarily related to the as/pcP, MFT, and
MVT Indexed Sequential Access Method (ISAM) and the telecommunications
access methods, while functions related to multitasking in as and VSE are ignored
by eMS. For more information, see "aS Macro Simulation under CMS" and "VSE Support under CMS". When CMS abnormally terminates, the following steps are taken:
1. After checking for any SPIE, STXIT PC, STAE, or STXIT AB exits that apply, CMS calls DMSABN, the abend recovery routine.
2. Before typing out any abend message at the terminal, DMSABN checks for
any ABEND exit routines, set via the ABNEXIT macro.
3. If a list of exit routines exists, the current ABEND exit routine (that is, the last
one set) gains control. If no ABEND exit routines exist, CMS abend recovery
occurs.
ABEND Exit Routine Processing
An ABEND exit routine may be establishec intercept abends before CMS abend
recovery begins. An ABEND exit routine receives control with the nucleus protect
key and is disabled for interrupts. Information about the abend is available to the
exit routine in the DMSABW CSECT in DMSNUC. The address of this area is
passed to the exit routine via register 1.
An ABEND exit routine may choose to avoid CMS ABEND recovery and continue
processing normally. To do this, the exit must issue the ABNEXIT RESET macro.
This tells CMS to clear the ABEND condition. The exit routine may also return to CMS to continue ABEND processing.
If the exit routine returns to CMS and another ABEND exit routine exists, it is giv­
en control next. Each exit on the list is given control in sequence until all the exits
have been given control or until an exit chooses to avoid CMS ABEND recovery,
by issuing ABNEXIT RESET, and continues processing.
If a program check occurs in an exit routine, and ABNEXIT RESET was not issued
in this exit routine, DMSABN gives control to the next exit routine on the list. If
no other exit routine exists, CMS abend recovery occurs.
You cannot set or clear ABEND exit routines in an ABEND exit routine. You can
reset an ABEND exit routine only in an exit routine.
310 VM/SP System Programmer's Guide