If you want to save the output, you should issue the command
without the PRINT option and then use the CMS PRINT command to print the LISTING file. CONTROLLING COMMAND LISTINGS The final disposition of the listing, as a printer or disk file, depends
on how you enter the AMSERV command. If you enter the AMSERV command
with no options, you get a file with a filetype of LISTING and a
filename equal to that of the AMSERV input file. This LISTING file is
usually written on your A-disk, but if your A-disk is full or not
accessed, it is written on any other read/write disk you have
accessed.
If there is not enough room on your A-disk or any other disk, the AMSERV command issues an error message saying that it cannot write the
LISTING file. If this happens, the LISTING file created may be
incomplete and you may not be able to tell whether or not access method
services actually completed successfully. In this case, after you have
cleared some space on a read/write disk, you may have to execute an AMSERV PRINT or LISTCAT function to verify the completion of the prior
job.
LISTING files take up considerable disk space, so you should erase
them as soon as you no longer need them.
If you do not want AMSERV to create a disk file from the listing, you
can execute the AMSERV command with the PRINT option:
amserv myfile (print
The listing is spooled to your virtual printer, and no disk file is
created. You might want to use this option if you are executing a PRINT or LISTCAT control statement and expect a very large output listing that
you know cannot be contained on any of your disks. You can also control the filename of the output listing file by
specifying a second name on the command line:
amserv listcat listcat1
In this example, the input file is LISTCAT AMSERV and the output listing
is placed in a file named LISTCAT1 LISTING. A subsequent execution of
this same AMSERV file:
amserv listcat listcat2
creates a second listing file, LISTCAT2 LISTING, so that the listing
created from the first execution is not erased.
184 IBM VM/370 CMS User's Guide

March 30, 1979
Manipulating OS and DOS Disks for Use with AMSERV To use CMS VSAM and AMSERV, you can have OS or DOS disks in your virtual
machine configuration. They can be assigned in your directory entry, or
you can link to them using the CP LINK command. You must have read/write access to them in order to execute any AMSERV function or VSAM program
that requires opening the file for output or update.
Before you can use an OS or DOS disk you must access it with the CMS ACCESS command:
access 200 d
The response from the ACCESS command indicates that the disk is in as or DOS format: D(200) R/ll - OS -- or -- D(200) R/ll - DOS You can write on these disks only through AMSERV or through the
execution of a program writing VSAM data sets. Cnce an as disk is used with AMSERV or VSAM, eMS considers it a DOS disk: so regardless of
whether you are an as user, when you access or request information about
a VSAM disk, CMS indicates that it is a DOS disk. You can still use the
disk in an as or DOS system for VSAM data set processing. Although the
format is not changed, the disk is still subject to any incompatibilities that can currently exist between OS and DOS disks. DATA AND MASTERCATALOG SHARING
There are two meanings of "sharing" that must be defined clearly with
respect to the CMS sUFPort of VSAM. The first is that of the SHAREOPTION parameter found in the DEFINE (and ALTER) command for access
iiiethod services.
The SHAREOPTION keyword enables the VSAM user to define how a
component will be shared across partitions (users). Since eMS is a
single-partition, single-user system and there 1S no data set sharing
capability in the control program (CP), the built-in data sharing in VSAM is of no value under CMS. However, if the VSAM user specifies SHAREOPTION three fewer lines of code will be executed and, therefore,
that option is recommended.
The area of sharing most familar to CMS users is that of disk
(minidisk) read-sharing provided by CP. For the VSAM user under CMS, it
is still possible to share disks in read-only mode in order to
read-share VSAM components. However, there is a restriction with
respect to the VSAM master catalog. That is, only one virtual machine may have the disk containing the master catalog in write status. This
is necessary even if only read functions are being performed during the
session. This is due to the master catalog updating read statistics at
close time and, when necessary, writing a new control record in the
catalog at open time. Under the OS/VS and DOS/VS systems (real) this is
not a consideration because the master catalog is always on a system
pack and, therefore, always in write status by that system and by the VSAM routines. The virtual machines (OS or DOS) cannot share the VSAM catalog since each thinks it is a "real" system and has control of the VSAM master catalog.
Section 10. Using Access Method Services and VSAM 185