Download Living in Two Worlds: Supporting SAS on CMS and MVS

282
Host Systems and Environments
LIVING IN TWO WORLDS
SUPPORTING SAS ON eMS & MVS
David Clayton
Academic Computing
University of Rhode Island
Kingston, RI 02881
[email protected]
programmer. The first of these is the process of running
SAS itself. Fortunately, this ~ystery is usually handled
by the technical support people and devolves to the
programmer as a one word command with optional
parameters. The panuneters, however, can be a source of
problems and more will be said about them later. The
second aspect of operating system communication
involves getting data from and putting information to
extemal files and this cannot be easily side-stepped. In
general, any user's program written after his or her first
attempts will involve at least the need to use a collection
of data stored in an external file written on either disk or
tape.
It is important to recognize the potential for problems
when discussing the support of multiple platforms and the
need for interplatform code portability. Even the simple
transfer of code between two like machines is all-too-often
a certain way to discover that some critical file was
forgotten or corrupted. Problems multiply and magnify
when taken across operating system boundaries. Doing
the porting of code can be difficult enough; explaining the
process to someone else can be worse. But with the
proliferation of machines combined with the need for
increased mobility of people, it falls to the consultant to
be aware of the problems involved, to advise an increasingly diverse clientele of the potential problems and to
suggest steps that can be taken to reduce the impact on
code portability.
While the problem is not of the user's making we are
faced with it none-the-Iess. The purpose of this paper is
to examine some of the problems encountered in moving
code between SAS running on different operating systems.
Since the number of platforms on which SAS is supported
are many, it would meaningless, let alone impossible, to
discuss all their differences. Instead this paper will
concentrate on moving code between the two major IBM
mainframe operating systems: MVS and VMICMS. Since
both operating systems are the product of the same
vendor, this eliminates a few of the variables. But enough
remain to permit an examination of some of the issues
involving code portability, to point out potential problem
areas and to suggest techniques which will minimize their
impact
Interaction with the Operating System
In general, there are two services provided by the
operating system that are of concern to the SAS
NESUG '92 proceedings
In designing SAS code to be ported between systems,
the principal philosophy is to isolate the SAS code
making it completely system independent Under this
approach, all system dependencies are maintained
externally, in the case of the IBM operating systems
localizing code in a CLIST on TSO, a PROC for MVS
batch, or an EXEC under CMS. This technique will work
satisfactorily for code which is designed initially to be
ported between multiple systems or as a retrofit for code
that will need to be ported repeatedly between systems.
In fact maintaining isolated code will provide the most
readily portable format, placing the system-dependent
coding in the operating system environment However,
the external shell, being completely system specific, often
must be changed with evolving operating system versions
and, obviously, different versions need to be maintained
for each operating system. This approach restricts the
SAS programmer's ability to use numerous SAS features
which improve effectiveness and often requires the
end-user to have a more-than-they-wish knowledge of
operating system specifics. Furthermore, at least in the
University environment, most SAS programs are not
initially designed to be moved between systems; that
comes as an afterthought
An alternative to the pure-code approach is presented
here, one which uses features of SAS to maintain a degree
of system independence and provides for programmer
flexibility. The presentation discusses numerous aspects
of the interaction between SAS and the operating system.
The paper presents some general ideas regarding SAS
Coding which can be incorporated to produce usable and
portable code which, should it need to be ported at a
future date, will require only some-it is hoped--minor
modifications.
Host Systems and Environments
External Data Sets
SAS supports numerous techniques for attaching
such a collection of dara to the SAS code so it can be
processed. Unfortunately the use of external flIes by its
very nature involves interaction with the operating
system. Each operating system dermes a unique set of
commands for identifying and accessing external dara
sets. Under MVS a DD sratement is used in the JCL to
designate a file for jobs run in batch mode while code run
interactively under TSO requires an AlLOC command to
attach the same external data set. For example:
llindara dd dsn=myidmyflIe.mydata,disp=shr
-oralloc f(indata) da('myid.myfile.mydata') she
On CMS information on the external files is supplied
via the FILEDEF statement which contains similar but not
identical information to that contained in the ALLOC or
DD statement. For example:
fIledef indara disk myflIe data al
Each of these statements can be included in SAS
code by prefacing them with the appropriate designator
but doing so makes the SAS program system-specific. If
possible users should be discouraged from coding
inslructions such as the TSO AlLOC, MVS DO, or CMS
FILEDEF statements within the program code. This
recommendation, of course, assumes the code has been
designed for transport and such is not usually the case.
More often the porting is unplanned and changing SAS
code references to external data sets becomes a case of
Seek-and-Switch. In replacing existing code as well as in
developing new code, the need for system-specific
commands can be eliminated through use of the SAS
FILENAME statement. The FILENAME statement
provides a common format for referencing existing data
sets. For example. the following FILENAME statements
reference the data sets identified above:
fuename indata 'myid.myfile.mydata'
-orfilename indata 'myfile data al '
Note, however, that although this SAS statement
does eliminate the need to use system-specific commands
it only affords a degree of system independence. As the
283
examples show, there remains a significant difference in
the format of dara set names on CMS versus MVS/TSO.
CMS fIlenames are of the form:
fIlename filetype filemode
where filename and filetype are limited to eight characters
each and fIlemode to a maximum of two characters. This
is incompatible with the MVS dotted-name notation
which allows multi-level names of up to 44 characters in
length such as:
qual1.qual2.qual3.qual4
As a consequence any porting of code between the two
systems will involve the need to recode all FILENAME
statements to bring the data set names into conformance
with the system requirement. The process can be
simplified by encouraging users to cluster FILENAME
statements at the beginning of the code. In this way,
while the number of statements that must be changed
remains the same at least the necessity of searching the
code is eliminated. Further steps can be taken toward
automating this process if the code is such that it must
regularly be moved between two platforms. Assuming
some simplified data set naming conventions can be
defined, a SAS macro can be used to generate the
FILENAME statements dependent upon system platform.
The problems associated with handling external files
becomes more complex when there is a need for the SAS
program to create new external disk (or tape) fIles to
contain oUlput data produced by SAS processing. The
preceding naming considerations still apply and additional
problems are introduced in specifying the parameters
needed to define the new external files. The FILENAME
statement accommodates the system-specific parameters
to define the size and format of the external file but once
again their inclusion increases the number of items
requiring change when code is ported. Some parameters
are valid only on MVS and their inclusion on a CMS run
will produce errors. There are system default values
defined for each parameter and these can be used if the
default values are acceptable. Their use can eliminate the
specification of additional parameters thus increasing
system independence. Table lbelow presents a brief
summary of the default values for the principal MVSrrSO
and CMS parameters for disk files.
NESUG '92 Proceedings
284
Host Systems and Environments
Table 1 - FILENAME Parameter Values
Parameter
RECFM
LRECL
BLKSIZE
SPACE
DISP
CMSVaI~
MVSVl!!!&li
FB
FB
80
80
System
(CYL,(l,l»
SHR·
960
n/a
n/a
• This parameter indicates the data set already exists.
This is unacceptable for a new data set where the desired
value is (probably) NEW,CATI..G.
Once again, a SAS macro could be written to
generate the two forms of the Fn.ENAME statemenL
And for many external data sets the values for RECFM,
LRECL, and BLKSIZE will be acceptable. But under
MVS the use of the DISP parameter is mandatory when
creating new data sets since the default assumption is that
the data set exists. Furthermore unlike CMS where files
grow based on use, under MVS the user must explicitly
request an amount of space for the data set. If the default
space value providing a maximum of 16 cylinders is too
small (and it may well be for many applications) this
parameter will be required. If these parameters must be
included in any MVSrrsO code they must be removed
when the application is processed under CMS. Optionally,
these values can be set as system options although that
introduces an alternate system specificity problem (see
below).
Though techniques for designating and accessing
data sets differs between MVS and CMS, the data
collections themselves can be readily moved between the
two operating systems either by storing them on external
media such as magnetic tape or by using network
communications facilities such as mail or ftp. Furthermore,
external data sets can be processed by operating system
editors and utilities. In porting code between these two
systems, therefore, the migration of external data sets,
while requiring care for a successful transfer, is not of
great difficulty. Such migrations tend to be tedious but
relatively straight-forward.
SAS Files
Unfortunately the basic data set portability of
external disk data sets between CMS and MVS does not
exist for SAS F'lles, that is, S AS Data Sets, Data Libraries
NESUG '92 Proceedings
and Catalogs. Different rules apply to the transporting
these. A summary overview of techniques is presented
below. The requirement for special handling is evident
when one remembers that SAS Files are created, formatted
and maintained by SAS to store information in an encoding
that is peculiar to SAS and unique to each operating
system. Unlike external data files these data sets are not
directly movable between operating systems nor can they
be processed by native operating system utilities; thus
these data sets are by-and-large operating system specific.
It should also be noted that over the several currently-used
releases of the SAS System there is signifIcant variability
in what and how SAS Files can be moved. This paper
will present the two principal strategies for porting these
data sets between CMS and MVS on SAS 6.06 using
either machine-independent sequential/tape data sets or
the creation of Transport Data Sets. The reader is
directed to Technical Report P-195 for specific information
regarding considerations for other releases.
Sequential Access Data Sets
Through the use of Sequential Access Data Sets SAS
provides a mechanism for creating and processing SAS
Files in a format readable on both CMS and MVS (as well
as VSE) without the necessity of creating an intermediate
Transport Data Set. This is accomplished through the use
of the SAS TAPE Library Engine. The use of this
mechanism for writing the SAS File is specifIed on the
LIBNAME statement using the keyword TAPE. When
using this feature the data set created under MVS or CMS
is directly readable by the other system. This approach
provides the simplest means of transferring SAS Files
between operating systems and is recommended for use in
the sitwition where a limited number of SAS Data Sets
created on one system must be ported to another system
for subsequent sequential processing. The technique
cannot be universally recommended however, since there
are disadvantages associated with sequential processing
including reduced efficiency, the ability to access only
one file at a time on the same tape, and the inability to
randomly access the file. Updating of tape data sets also
presents special problems which limits their usefulness
for permanent storage. Furthermore, even if the data sets
themselves are directly readable, processing of magnetic
tapes varies from system to system. Consequently, when
magnetic tape is to be used it is recommended that the
data sets be written to non-labelled tapes to reduce the
chances of compatability problems.
Example 1 below shows a eMS SAS job which
Host systems and Environments
writes a single SAS Data Set to tape and an associated
MVS(rSO job which then reads it. Mentioned but not
shown in this example are any system specifIC processing
needed to mount tapes on the respective systems.
Example 1 - SAS Tape Data Sets
Create the data set on CMS
LIBNAMEOUTTAPE'TAPI'LABEL=NL;
DATA OUT.MYSTUFF;
SET CMSLIB.MYSTUFF;
RUN;
(Note: there may be local system-specific requirements
regarding tape mounts.)
Read the data set on MVS
ALLOC F(lNLIB) LAB(NL) UNIT(TAPE) +
RECFM(V) BLKSIZE(32760) +
YOL=(TAP999)
(Note: MVS tape allocations MUST be specified externally
and there may be local restrictions or additional
requirements.)
LIBNAME INLIB TAPE TAP1;
PROC PRINT DATA=lNLIB.MYSTUFF;
RUN;
Transport Data Sets
If the use of a tape data set is not practical or desirable,
SAS can be used to create a Transport Data Set. Transpon
Data Sets may be used directly in SAS Procedure or Data
Steps or can be processed on the importing system to
recreate entire SAS Data Libraries or Catalogs. For
complex SAS File structures, Transport Data Sets provide
the only reliable means of porting files.
On the exponing system the Transport Data Set can
be created in a SAS DATA or PROC step, through the use
of PROC COPY (for multiple SAS Data Sets), or through
the use of PROC CPORT (for SAS Catalogs or an entire
SAS Data Library). The Transport Data Set can be
written to either magnetic tape or disk. If written to disk
the Transpon Data Set can be moved via intersystem
networking. If the Transpon Data Set is to be moved via
285
a network the user should specify the BINARY mode of
transfer to a void character translation. If magnetic tape is
used the tape should be non-labelled to avoid
system-to-SYSfem tape processing comparability problems.
In either case, the Transpon Data Set should be created
with FIXed Block records of Record Length 80 and a
Block Size of 8000.
On the impon system the Transport Data Set can be
either processed by PROC COpy (to read multiple SAS
Data Sets), PROC CIMPORT (for SAS Catalogs or an
entire SAS Data Library) or if the Transport Data Set
contains only a single SAS Data Set it can be processed
directly in a DATA step or via aSAS PROC that processes
the data set sequentially.
Example 2 contains a segment of MVS code to create
a Transport Data Set containing three SAS Data Sets and
the CMS code to impon that data.
Example 2 - Using a Transport Data Set
Creating the Transpon Data Set on MVS
FILENAME TOCMS 'MYlD.TOCMS.DATA'
DISP=(NEW,CATLG) SPACE=(TRK,(lO,5»
RECFM=FB LRECL=80 BLKSIZE=8000;
LIBNAME MVSLIB 'MYlD.MVS.SASLIB';
PROC CPORTLIBRARY=MVSLIB FlLE=TOCMS;
RUN;
At this point the Transpon file could be transferred to
CMS. This example assumes the data set on CMS is
named 'FROMMVS DATA AI' to conform withCMS
naming conventions.
Importing the Transpon Data Set on CMS
LIBNAME CMSLIB 'A';
FILENAME INTRAN 'FROMMVS DATA AI';
PROC CIMPORT LIBRARY=CMSLIB
INFlLE=INTRAN;
RUN;
NESUG '92 Proceedings
286
Host Systems and Environments
Complete details on creating, moving, and processing
these data sets can be found in Technical Report P-195.
SAS Options
Yet another potential source of conflicts exists in the
specification of SAS Options, those user-supplied values
which customize the SAS environment Of concern here
are not those options which define internal aspects of SAS
processing but, as with the previous issues, those options
which define or interact with the external environment
such as defining the destination for program output,
influencing progmm efficiency, and defining attributes for
SAS Files.. As demonstrated above, there are significant
differences between MVS and CMS and these differences
can once again be amplified by use of system specific
options.
Options can be specified on the command line in
CMS or TSO or on the MVS EXEC statement at SAS
invocation, specified on an included OPTIONS statement
within the SAS code or included in an external
configuration flle. Among the options available to the
SAS programmer in MVS and CMS, there are a small
number of options exclusive to one system or the other.
There are also some options which are available on both
systems but which recognize different values. Since SAS
does not ignore unrecognized options but instead generates
an error, incompatible option values must be removed to
effect successful execution. The use of a configuration
flle to supply user-defmed options offers the greatest
flexibility in handling code which must be moved. With
the configwation file a data set can be created on each
system which contains those system specific options
applicable to that system. This eliminates the necessity of
modifying the SAS code itself when it is moved. Whereas
CMS provides for a default configuration file of 'CONFIG
SAS *', the MVS code must have the CONFIG= option
specified and the flle identified must be pre-allocated
using either a TSO ALLOC or Ja. DD statement This,
however, again assumes that the possibility of code
porting is an element of initial design, a situation which is
not always the case.
Tables 2 and 3 summarize a subset of available
options. These are abbreviated lists containing options
which are commonly used and would cause problems
when code is moved between CMS and MVS. No
attempt has been made to address all options. The reader
is directed to the SAS Companion for MVS and CMS
volumes (see references) for details on all system-specific
NESUG '92 Proceedings
options. Table 2 options are valid on either MVS or
CMS and are commonly used in that environment
Porting of code to the other environment will require at
least a removal of these options and may require modification of the code. Table 3 includes options which are
common to the two systems but which have different
acceptable values. Of course all difficulty with SAS
options can be eliminated by using only default option
values. That, however, is an acceptable approach only if
there are no options which are critical to the sucessful
execution of the program and as long as any decreases in
processing efflciency is also acceptable.
Table 2 • System·Specific SAS OptiOns
Valid System
CLIST
CPSP
FILESPPRI
FILESPSEC
FILEUNlT
Fn.CLR
NULLEOF
OBS
S
SIODISK
SORTUNlT
SORTWKDD
SORTWKNO
MVS
CMS
MVS*
MVS*
MVS*
CMS
CMS
MVS
MVS
CMS
MVS*
MVS*
MVS*
*These three options control default space allocation for
new external data sets and their use as options may reduce
system specifiCity in allocating external files.
n'hese options affect sorting space and efficiency within
SAS under MVS and are very commonly used. Under
CMS disk space automatically grows to the maximum
available on the selected minidisk; however, the SIODISK
option under CMS to select a work minidisk may fill an
analogous role.
Host Systems and Environments
287
Table 3 - Value-Conmct SAS Options
AL1LOG
AL'IPRINT
CONFIG
LOG
PRINT
CMS Value(s)
MVS Value(g)
D'p,T,FileSpec
D'p,T,FileSpec
'fn ft fin', filename·
D'p,T,FileSpec
D'p,T,FileSpec
Filereft
Filereft
Filereft
Ftlereft
Filereft
D'p,T =DISK,PRlNTER,TERMINAL
FileSpec = For CMS the tiIeref can be from a FILENAME
or FILEDEF statement or a data set name of the form 'fn
ft fm' may be specified.
tFIleref- In the case ofMVS, the indicated file reference
must be to a data set pre-allocated using a TSO ALLOC
or JCL DD statement.
• If only a filename is specified the filetype is SAS.
Conclusion
Migrating SAS code from one operating system
platform to another varies in difficulty in direct proportion
to the amount of dependency the code has on
system-specific features. Even in two operating systems
running on the same bardware--IBM's CMS and
MVS--there are signiftcant incompatibilities which must
be dealt with. In particular, use of external data sets, SAS
Fues, and SAS options which are system-specific will all
increase the complexity of the code porting process. If
consideration can be given in these areas to the potential
for migration when the code is being designed, the
process can be simplified.
References
SAS Companion for the CMS Environment; SAS Institute;
1990.
SAS Companion for the MVS Environment; SAS Institute;
1990.
SAS Language and Procedures; SAS Institute; 1991.
SAS Technical Report P-19S, Transporting Files between
Host Systems; SAS Institute; 1989.
NESUG '92 Proceedings