Download SYSTEM 2000 Data Management Software Release 12 Enhancements and Why SYSTEM 2000 Software Is the Best Place to Maintain Your Production SAS Data

SYSTEM 2000' Data Management Software Release 12 Enhancements and Why SYSTEM 2000'
Software Is the Best Place to Maintain Your Production SAS' Data
David W. Pitts, SAS Institute Inc., Austin, TX
Clarence C. Talley Jr., SAS Institute Inc., Austin, TX
ABSTRACT
database was 16,777,215 (2*'""24). The maximum byte count of all
data recorded in File 6 was 1,073,741,823 bytes or (2"*30).
A detailed review of the latest release of SYSTEM 2000" software
enhancements and new features is shown. Major features include
expansion of the database file limits for the number of records and
Definition and Index Tables
The Definition Table (File 1) changed to allow 10,000 components
per database. Minor changes were made to the Index Tables (Files
2 and 4) and Overflow Table (File 3) to account for the increased
number of records in a database.
components, dynamic file allocation for MVS, ccmplete CIGS C0mmand level support, and full 31-bit addressing support. These fea·
tures are viewed along with the SAS/ACCESS· interface to
SYSTEM 2000 Data Management Software and the future plans
for the engine that make SYSTEM 2000 software a logical storage
methodology to be used for production SAS applications.
Hierarchical Table
The Hierarchical Table (File 5) contains the hierarchical relationships
of the records in the database. There is one entry for each
data record. Entries are fixed length and the entry size grew from
14 to 18 bytes. The maximum size of the Hierarchical Table is
119,304,647 records.
INTRODUCTION
SYSTEM 2000 Data Management Software is a hierarchical database management system (DBMS) for mainframe computer systems running under MVS and eMS operating systems that offers
fast data access, concurrent updates, flexible data query, data item
security, and Coordinated Recovery. The SAse System offers the
powers of data analysis, presentation capabilities, ease of use, and
familiarity. The SASfACCESS interface to SYSTEM 2000 Data Management Software is the product that makes it all possible.
Data Table
The Data Table (File 6) contains the actual data for a database, collected together by schema record type and structured by potnters
in the Hierarchical Table. The only change to File 6 is that each
record begins on a word boundary. Depending on the size of the
schema record, there may be 0 to 3 slack bytes per record. The
size for each schema record equals the sum of the picture size for
all items in that schema record.
SYSTEM 2000 software and the SAS System can help with the four
primary data-driven tasks common to any application: data access,
data management, data analysis, and data presentation. Using the
SAS System's programmability with the power of SYSTEM 2000
software, you can meet the wide range of needs that exist in your
organization. There are virtually no limitations on access to data
stored in a SYSTEM 2000 database with the SAS System. The
SASfACCESS product enables you to view a SYSTEM 2000 database just as you would when using SAS data files. This allows you
to write SAS programs that take full advantage of the powers of
SYSTEM 2000 software, but at the same time does not require you
to learn the DBMS's programming concepts.
The maximum number of tracks that may be used for database File
6 is 65,535 (X'FFFF'). Thus, the maximum number of bytes for File
6 depends on the block size and disk device. For example, a 3380
disk using a block size of 23,464 (two blocks per track) could use
up to 131.071 blocks or 3,075,426.480 bytes.
DYNAMIC FILE ALLOCATIONS
One of the main goals of dynamic file allocation is the reduction and
elimination of JCL or ALLOC statements for your batch jobs or TSO
clists, respectively. That goal is now achieved. By using all defaults,
the only statement needed is the JCL EXEC or TSO CALL statement. The minimum JCL and CLIST needed to access the library
database is
This paper describes enhancements to SYSTEM 2000 Data Management Software Release 12.0 and explains how these enhancements combined with Version 6 of SAS software form an ideal
partnership.
IISC!'
IISTEPLIB
INCREASED DATABASE FILE LIMITS
SYSTEM 2000 software Release 12.0 allows a Significant increase
in the number of records in a database, the capacity of data, and
the number of components allowed in a single database. In general,
the maximum record count is approximately seven times greater,
byte count for data is approximately three times greater, and the
number of allowed components is ten times greater.
EXEC PGK=SYSllt,PARJI='PRBFIX=Sllt'
DD DSN=S2lt.R120.LOAD,DISP"SHR
CALL 'Sllt.Rll0.LOAD(SYSlK)'
IlSBR,LIB:
DBN IS, LIBRARY:
EXIT:
You can now have 10,000 components in a database definition, and
a database can have up to 119,304,647 data records. The byte
count for the Data Table also increased substantially, with the
capacity depending on disk type and block size. For example, on
a 3380 disk with a block size of 23464, the maximum byte count
for Rle 6 is 3,075.426,480 (131.070 blocks).
New PREFIX Execution Parameter
The PREFIX execution parameter is used for Multi-User~ jobs,
Multi-User dependent region batch jobs, and single-user batch jobs.
This prefix becomes the first high-level qualifier for the data set
name unless the ALlOC command provides the database data set
name in quotes. If you want to allocate permanent disk files for the
work files, the PREFIX is also the high-level qualifier for the
S2KPADnn, SFnn, S2KDBCNT, and 82KPARMS data set names.
Prior to Release 12.0 the maximum number of items in a database
definition was 1,000. The maximum number of records in a single
504
UNIT
You must use the PREFIX parameter on the EXEC statement if you
want it to dynamically allocate the S2KPARMS file.
UNTo.
For TSO users, the TSO prefix specified in the PROFilE is always
used. The PREFIX execution parameter is ignored. You can easily
change the TSO prefix with the PROFilE command before entering
SYSTEM 2000 software. The syntax for the PREFIX parameter is
valid
valid
vaUd
vaUd
unit for your site
unit for your sUe
vol ser
vol ser
SISDA
scratch
VOL
VOLn
FILES
FILES
FILES
ALL
SPACE
SKALL Ot LARGE
spen
(TRlt or CYL, <primary>, <secondary>)
1,2,3,ij,5,6,7, or 8
omitted
all eiqht files
that file only
Files 1 throuqh 6 only
'MALL
PREFIX .. <va 1i d-mal t ipl e-level-pre t ir>
Database file
Dynamic Allocation of Database Files
Files I, 3, ~
Files 2, 5, 6, 7,8
SYSTEM 2000 software Release 12.0 gives you several ways to
allocate the necessary database files. You can continue to use JCl,
CLlST, or user exits as you have with prior releases. Release 12.0
introduces the new ALLOC command to give you complete control
for allocating existing or new database files. There is a new
S2KDBCNT table available for both single-user and Multi-User jobs
to allocate database files, or SYSTEM 2000 software automatically
allocates the database files if you use the default name.
('1'RK,(30,50))
(CYL,(IO,50))
A new execution parameter FREE determines whether SYSTEM
2000 software unallocates the database file when a physical close
is done. The default is FREE = NO that means the files stay alloca~ed. This is most useful in the SAS software environment when
you use PROC QUEST or PROC DBlOAD to allocate and define
a new database, then switch to another procedure that uses the
SAS/ACCESS interface to SYSTEM 2000 software. If FREE = YES,
then at EXIT or CLOSE time, SYSTEM 2000 software unallocates
database files that were dynamically allocated.
Anytime you issue an SCF DATA BASE IS (DBN) command or
PLEX OPEN <database> command, SYSTEM 2000 software
automatically dynamically allocates all the database files if you use
the default name. SYSTEM 2000 software attempts to allocate all
eight files of the database, but File 7 and File 8 are optional and are
not required useless you enabled the Update log or Coordinated
You can explicitly unallocate the database with the new FREE command. The FREE command closes the database and dynamically
unallocates all database files.
Recovery.
FREE <database-name>:
default
data
set
naming
convention
is
S2KDBCNT Database Allocation Table
DSN=<prefix>.<database-name>n, where n is a value 1
SYSTEM 2000 software Release 12.0 has another alternative to
through 8 appended to the database name.
using \he delouft name or the ALLOC command. The S2KDBCNT
file is used to control access to database files. This file contains one
record for each database that has the database name, the data set
name and disposition. The S2KDBCNT table is available for both
Multi-User and single--user environments and is used based on the
new execution parameter AllOC.
You can use the ALLOC command to give SYSTEM 2000 software
the information for allocating the database fiies anytime before you
open the database. You use the AlLOC command when you want
to use existing database files and the data set names do not conform to DSN = <prefix>. <database-name>, or you want to spec-
ify
(TRK, 13,5))
(CYL, (1 ,S))
LARGE
Unallocation of Database Files
Dynamic Allocation for Existing Database Files
The
SHALL
DISP~SHR.
New AlLOC Execution Parameter
Dynamic Allocation of New Database Files
The AllOC execution parameter determines the level of control you
want with dynamic file allocation and the S2KDBCNT table.
When you want to create new database files, use the ALlOC
command with the DISP = NEW option to dynamically allocate
the requested database files. An example of a new database
allocation is
• ALLOC = YES is the default and allows the AllOC and
FREE commands to be used at any time. You must use
ALlOC=YES to allocate a new database file. Additionally,
you can use the S2KDBCNT table in conjunction with the
AllOC commands to dynamically allocate database files
based on infonnation in the table. However, if you use the
DSN or DISP option on the ALlOC command, it overrides
any table specifICation for the same database name option.
YES is the most flexible.
USER,NEW:
ALLoe NEWDB,DISP=NEW:
NOB IS NEWDB:
The above commands produce the six new database files with the
following characteristics:
OS.
<pref ix> .NrwDB I
<pref iz> .NBWDD2
<pre! ix> .NEWDB3
<pref ix> .NEHDB4
<pref ix) .NEWDBS
<pre! ix>. NKWDB6
BLKSIZE
6216
6216
6216
6216
6216
6216
SPACE
3,5TRK
1, S C'lL
3,5 TRK
3,5 1'RK
1,5 cn
1,5 CYL
UtiIT
SISDA
S'lSDA
SYSDA
S'lSDA
SYSDA
SYSDA
DSORG
0.
,.
• AllOC= TBl allows for dynamic allocation only for
databases defined in the database table. This option is
useful for Multi-User environments where you want to have
strict control of the databases in that Multi-User job. Note
that with AlLOC = TBl you cannot use the AllOC
command to allocate any new databases or override the
information within the S2KDBCNT table.
0'
0.
OA
OA
ALLOC Options for New Database Files
Here are the options for dynamically allocating new database files
if you want to change any attributes in the above chart. Note that
you can change the default for all the files or you can change only
a specific file by appending the number of the file you want to
change. These options have meaning only when you use
DISP= NEW. ALlOC options needed for new database files follow:
PARK
DESCRIPTION
BLKn
valid S2K blkshe
valid S2K blkshe
• AllOC=NO disallows all ALlOe and FREE commands and
disallows the use of the S2KDBCNT file. This means aU JCl
for your database files must be in the start-up job stream,
or your user exits must dynamically allocate the files.
ALLOC=NO means that SYSTEM 2000 software performs
the same as prior releases.
DEFAULT
6216
505
The Multi-User environment is the most appropriate place to use
the S2KDBCNT table and to run with the execution parameter
ALLOC = TBL This gives the database administrator and systems
programmer the best control of the databases that are allowed in
this Multi-User job and still allow for dynamic file allocation.
Dynamic Allocation of SYSTEM 2000 Savefiles and Keepfiles
SYSTEM 2000 software Release 12.0 can dynamically allocate the
Savefiles or Keepfiles anytime you issue a SAVE, RESTORE, KEEP,
or APPLY command.
Beginning with Release 12.0, the DDname for the Savefile is the first
seven characters of the database name with an'S' appended to
the end. Note that DDname TAPES2K is no longer valid.
SAVB DATA BASB ON
The main difference in a Multi-User environment is that multiple
users can be using the same database at the same time. For you
to issue the FREE command. you must have exclusive use of the
database to ensure no one else is using the database.
UlnT~device volume list DSN~ •••
IUHITedevice voltlllelist DSNw ••• :
Multi-User software also gives the console operator the VARY command. VARY <database-name> OFFLINE will set a pending flag
to tell Multi-User software to dynamically unalk>cate the database
files when the last user closes the database. You can only vary
offline databases that were dynamically allocated. The OFFLINE
option also prevents any new users from accessing the database.
Once a database is taken offline with the VARY command. you must
use the VARY <database-name> ONLINE command to make it
available again.
Examples:
SAVi:
SAVI DATA
SAVB DATA
SAVB DATA
SAVB DATA
BASB:
BASB/:
BASB ON DSN=NBW. DISIt:. SAVE:
BASB ON UNIT-TAPB voltlllelist
IUIIIT_TAPi volumelist
SAVB DATA BASB ON UNIT .. CART volomelist
IUNI'1'=CAlI.T volume list
DSN= •••
OSN..... :
DSN- .••
DSN ..... :
If you do not specify the DSN option, the default data set name is
DSN= <prefix>. <database-name>S.
Dynamic Allocation of SYSTEM 2000 Work Files
If it is the SAVE command and an existing data set is not found,
the following data set is created using the attributes described
below:
DSN=<prefi:r>.<database name>S
VOL-SBR=<default for SYSDA>
UNIT=SYSDA
or
DSN specified with the SAVB cOllllland.
LRBCL",larqest block size + II
BLKSUB=depends of type of disk (The 3380 default is 231172)
SPACB"primary space larqe enough to save database
(SYSTBM 2000 software knows total pages in use)
Dynamic allocation of at! required SYSTEM 2000 work files is even
easier than that of database files. Most jobs can use the default attributes and temporary data sets. You may want to make your
S2KPADOO file permanent to save initial formatting time and create
a permanent S2KPARMS file to allow for more buffers. Dynamic
allocation of SYSTEM 2000 work files occurs only if the files are
not already allocated viaJCL Dynamic allocation first looks for permanent files, then allocated temporary files.
S2KDBCNT
S2KPARXS
S2KPADu file
SFu files
If UNIT is CART or TAPE, the attributes are
DSN=<prefix>.<database name>S or DSN speclfied with the SAVE cODlllland.
VOL .. Sgp,=<volumelist or default for TAPE>
UNIT .. device
RBCYH=VB
LRBCL=32,756
BLKSIZB .. n,760
For the permanent data sets not found, allocate the following temporary data set:
S2.KPADOO file
SFOn files
S2KHSG
S2KCOMD
S2KSNAP
S2KPARHS
The Keepfile is much like the Savefile except it has the letter 'K'
appended to the database name. Note that the DDname KEEPFILE
is no longer valid. AU information that follows the slash on the SAVE
or RESTORE command defines the Keepfile. The Keepfile can be
a different device from the Savefile.
DSN"<prefix>. S2KDBCHT, DISp .. SHR
DSH"<prefix>. S21PARMS ,OISP-SHR
DSH=<prefi:r>.S2KPADU,DISP",OLD
DSII=<pref i:r> .SF:rx, DIsP ..OLD
unit(sysda) space{1,1) cyUnder
tmit{sysda) space(1,1) cyUnder
where n .. l throuqh 6
DA(.) or SYSOUT=A
DA{.) or SYUII DO •
SYSOUT(A) HOLD
POOLO.6216/1Q/B
New Execution Parameters for Work Files
If you want SYSTEM 2000 software to allocate temporary files, here
are the new execution parameters that you can use to control the
dynamic aHocation of those work files. You can specify all the
parameters or just the ones you want to alter. The SYSTEM 2000
work files execution parameters are
If you do not specify the DSN option for the Keepfile, the default
data set name is DSN=<prefix>.<database-name>K.
The Keepfile data set is allocated when the KEEP command is
issued, not when the SAVE command is issued. If it is the first KEEP
command and an existing data set is not found, the following data
set is created using the attributes described below:
S2KPARH
DSN=<prefi:r>.<database name>K or DSN specified on the SAVE command
VOL-SBR=<volamelist or default for SISDA>
UNIT=SYSDA
or
UNIT=device
RBCFM=F
LR£CL=same as File 7
BLKSIZB=same as File 7
SPACE is large enouqh to do the lEEP in prillary space
and secondary space of the same sile to allow subsequent KBBPs
Dynamic File Allocation and Multi-User Software Consideration
DEFAULT
SFPRI"n
SFSI.C",n
SFUNI'1'=x
SFSPACB=y
PADPRI_n
PADSEC_n
PADUNIT.. :r
PADSPACE.=y
MIN-VALUE
)(AX-VALUB
32757
32767
SISDA
CYL
1
SYSDA
CYL
32767
32767
DESCRIPTION
Sort file prillary space
Sort file secondary space
Sort file UNIT
Sort file Space Unit
S2KPAD file primary space
S2KPAD file secondary space
S2KPAD UNIT
S2KPAD Space unit
where n is any valid numeric value for the parm
where :r is any valid UNIT
where y is CYL/TRK
Dynamic file allocation in a Multi-User environment perfonns ttle
same way as single-user batch. The execution parameter PREFIX
in the Multi-User job is used for all work files and database files
untess the data set name is entered with single quotes on the
ALLOC command or the data set name comes from the S2KDBCNT
table.
506
31-BIT ADDRESSING
Self Contained Facility (SCF) Processing
SYSTEM 2000 software Release 12.0 can now take advantage of
The S2KU and S20P transactions look exactly the same from the
user's perspective. There are no changes in the presentation of the
transaction.
a
MVSfESA and VMIESA technok>gy to use memory above the
16-megabyte fine.
Procedural Language Extension (PLEX) Processing
Addressing Mode and Residency Mode
The Release 12.0 precompilers generate only Command Level compatible code within your PLEX program. An additional PLEX Common Block (PLXCOMM) is generated in-line in your application
program working storage area. A new module, PLXPBLO is linked
with your COBOL or PU1 programs and the interface is called via
a Command Level UNK.
Every program that executes in MVS/ESA or MVSlXA is assigned
two program attributes. addressing mode (AMOOE) and residency
~ (RMODE). For programs that do not have AMODE and
M
RMOOE specified, the default attributes are AMODE(24) and
RMODE(24).
How Does This Affect Me?
For Release 12.0 only, both the Macro Level and the Command
Level interface are supported, but then support for Macro Level will
be dropped. Your existing CICS PlEX application programs will
continue to use the Macro Level interface until you re-precompile
your programs using Release 12.0 precompilers. Once you use the
Release 12.0 precompilers, you are using the Command Level interface. Therefore, you can begin a conversion of existing applications
to the new Command Level interface on a gradual basis, If your
CICS application program uses Macro Level, you must continue to
use the Release 11.6 precompilers until you convert your program
to Command Level.
The conversion of SYSTEM 2000 software to use 31-bit addressing
will have little or no effect on the way you use SYSTEM 2000
software. Most of SYSTEM 2000 code that was below the
16-megabyte line is now above the line. Here are some anticipated
questions and answers.
Q: How does this affect SAS/ACCESS software for Version 6?
A: It makes it even better. Sinoe Version 6 runs in addressing mode
31, special changes were needed for SYSTEM 2000 software
Release 11.6 to switch back and forth from 24-bit mode to 31-bit
mode. Now with Release 12.0, SYSTEM 2000 software is running
above the 16-megabyte line and is in the same addressing mode
as Version 6 of SAS software.
PLXPBLD Module
Most of the application level changes are handled automatically by
the precompiler. The link-edit process causes an include of the module PLXPBLD in the link-edit step for your COBOL and PU1 programs. This routine takes the place of the S2KPLC module that was
formerly linked with your applications. There will be a slight increase
in the size of the application program due to the inclusion of the
PLXCOMM control block, but the increased size is minimal and
should not cause any probtems.
Q: 00 I have to change existing PLEX programs for Release 12.0?
A: No. Even though your existing PLEX programs are most likely
24,-bit mode, they will work with Rel.ease 12.0 in slngle user or
Multi-User environments without changes. All communications
between your program and SYSTEM 2000 software is via S2KPLR
and it ensures the correct addressing mode.
Q: 00 SYSTEM 2000 user exits need to be concerned with 31-bit
In the Command Level environment, you cannot pass a string of
parameters with a regular CALL statement. Only one parameter is
allowed and is identified with the COMMAREA parameter on a Command Level UNK command. With this limitation, the application program makes a call to the PLXPBLD routine. The parameters passed
to the PLXPBLD routine are refonnatted into the PLXCOMM control
block that is passed as the COMMAREA in successive Command
Level LINK commands to module PLXFRMT to process the PLEX
command.
addressing mode?
A: Yes. Your user exit program is entered in the same addressing
mode as SYS2K or S2KPLI. In 31-bit mode, you should not clutter
the high..order byte of a register or word that contains an address
with flags since all 31 bits are used as the address. Also, the
addresses that are passed to your user exit program are likely to
be above the line and you must be in 31-bit mode to reference them.
Q: Can my PLEX program take advantage of 31-bit addressing?
A: Yes, although it is not necessary. The SYSTEM 2000 control
Abend Handling
blocks within your programs may reside above the 16-megabyte line
along with the rest of your code. Now your application programs
can reside above the 16-megabyte line that allows you to have more
memory to define your data areas and in-memory tables.
Abend handling for the Command Level interface is done byactivating a HANDLE ABEND command in the module PLXFRMT. Since
PLXFRMT links to all other programs in the interface, the same
HANDLE ABEND command traps any abend that occurs while in
the interface code. The abend processing eventually percolates up
to the level of the application program.
CICS COMMAND LEVEL
The SYSTEM 2000 CICS interface was rewritten to be full CICS
Command Level compatible. CICS Release 3.1 removes aU Macro
Level support except for assembler language. The next release of
CICS will have no Macro Level support. In the process of converting
the CICS Interface from a Macro Level to Command Level, the
Institute considered several compatibility issues. SCF users will not
see any changes. PLEX programs have many changes, but those
changes are handled by the Release 12.0 precompilers. They are
other enhancements in the abnormal tennination logic that are also
transparent to the users.
When the application program does not issue a STOP S2K command, the Command Level interface provides a task-oriented user
exit that is linked at task termination time. At that time, the software
checks for the presence of PLEX user programs that have not
issued STOP S2K commands. This processing works basically like
the Task Control Program exit (XKCREQ).
The Task Control Program (XKCREQ) exit and the Program Error
Program (DFHPEP) exit are still required to handle abnonnal condition for the Macro Level interface.
507
allows you to convert individual databases as needed off line. The
conversion is a one-way conversion, thus it cannot be used to create
a Release 11.6 database from a Release 12.0 Savefile.
Application Program Handle Abend Conditions
Your application program can establish program interrupt handling
using the HANDLE ABEND command. The interface establishes its
own abend handling in the PLXFRMT module. The interface issues
a HANDLE ABEND command to get control in case a program
abends. This allows the interface to clear the interface resources
that are associated with the abending task. The interrupt handling
is stackable, and after the interface interrupt handler completes its
processing, CICS allows your application program interrupt code to
In addition to creating a Release 12.0 database, the conversion program also has the ability to change the block size of any database
file by using the REBLOCK option on the parameter card. This
reblock feature can also be used to reblock a Release 12.0 database.
get control.
Special Considerations
Due to the intricate data structures for indexes, the convert program
is not able to do a file to file conversion of the index table. Therefore,
all key components are changed to non-key. To aid in restoring
these components back. to keys, a KEYS file is written that contains
the appropriate CREATE INDEX commands that can be used as an
input Command File to an SCF job to re-create all the key components.
New Ust and Termination Transactions
There are several new transactions that replace the functions of the
Macro Level interface TERM transaction. The basis format of the
new transactions is
ftUft USBRID '" ctserid
I userid1, ctserid2, .•• )
ACTIVE
ALL
where
xxxx is
Also during conversion, a check is made for the Update Log or Coordinated Recovery. If either of these features were enabled, they are
turned off and must be requested using Release 12.0. Again to aid
in the conversion, appropriate commands are written to the KEYS
file to re-establish the Update Log and Coordinated Recovery.
LALL, LSCF, LPLX, TALL, TSCF, or TPLX.
The list transactions LALL, LSCF, and LPLX obtain status information about any users, only SCF users, or only PLEX users, respectively. You can request the status of a single user by adding the
parameter USERID=xxxxxxxx. You can request the status of all
active users by adding the parameter USERID=ACTIVE. You can
request the status of all users by specifying the parameter
USERID=ALL. The LALL and LSCF transactions show the userids
of all active users and shows all inactive users that have not executed the EXIT command.
Input 10 the Conversion Program
Input to the conversion program consists of a SYSTEM 2000 Savefile and a parameter file. The Savefile is any existing Savefile created
with Release 10.1,11.0,11.5, or 11.6. Note that Release 11.6 could
write two different Savefile formats; either format is acceptable.
The parameter file indicates which databases are to be converted
or reblocked. For a Release 12.0 database, only the REBLOCK
option is valid. For a database bu~t prior to Release 12.0, you can
specify both CONVERT and REBLOCK at the same time. When you
use the REBLOCK option, the conversion program looks at the DCB
block size of each database file to determine the new size. If it is
not zero, then that becomes the new block size. Otherwise the new
file has the same block size that is specified on the Savefile.
The output from the nst transactions has been enhanced over the
TERMLIST transaction output. The output screen has informative
headings and the explanations of the bit settings in word format,
rather than numerical values.
The termination transactions TALL, TSCF, and TPLX terminate any
users, only SCF users, or only PLEX users, respectively. You can
terminate a single user by adding the parameter
USERID=xxxxxxxx. You can terminate all users by specifying the
parameter
The following are some sample parameter entries:
USERID~ALL
EMPLOYEE (CONVERT ,REBLOCK)
MANUFACTURE (CONVERT)
TEST (REeLOCK)
DATABASE CONVERSION
If no options are specified, CONVERT is assumed. If the block sizes
of the database files are different than those specified on the Savefile and you do not specify the REBLOCK parameter, an error message is issued. More than one parameter entry can be present in
the input file in a single run. This allows you to convert multiple databases in one run of the conversion program.
Databases created by SYSTEM 2000 software Release 12.0 are
not downward compatible with prior releases and databases created with a prior release are not upward compatible with Release
12.0. Therefore, you must convert all databases before accessing
the databases with Release 12.0. There are three ways to convert
your existing database to Release 12.0.
Output from the Conversion Program
• Use SC~ to UNLOAD the database with Release 11.6, then
define and load the database with Release 12.0. This is an
acceptable method for smaller databases.
Output from the conversion program consists of database Files 1
through 6 and the KEYS file. The six database files have been converted to Release 12.0 format and can be accessed by Release
12.0. The database files do not need to be formatted prior to the
conversion job.
• Write a PLEX program that unloads ~e database with
Release 11.6. Use Release 12.0 to define the,new database
and then perform a PLEX optimized load. Both the SCF
unload and load and the PLEX unload and load give you a
new Release 12.0 database with no skewness.
The KEYS file contains information concerning which components
were keys before the conversion and information concerning the
Update Log and Coordinated Recovery. This KEYS file contains the
CREATE INDEX command appropriate to re-establish allot the keys
and Coordinated Recovery. This file can be used as an input Command File to a Release 12.0 SCF job to re-create all the key components. An advantage in using this process is that you can edit the
Command File prior to execution to either remove items from the
key list or add items that were not key but need to be key. This is
• The third method is to use the conversion program provided
with Release 12.0.
Conversion Program
Release 12.0 conversion program uses an existing SYSTEM 2000
Savefile as input to create the Release 12.0 database files. The conversion process is designed to run in stand-alone batch mode. This
508
The one new restriction with this enhancement is that all component
names must be uppercase when you define your database. Prior
to Release 12.0 uppercase ~C3" referred to component number 3,
but lowercase "c3~ referred to comjXlnent name 03. Therefore. it
was possible for component number 1 to have a component name
of "c3~. With Release 12.0, lowercase "c3" will always be recognized as component number 3.
a simple 8O-byte sequential file. The follOWing is an example of the
KEYS file:
CONTROL:
DBR IS EMPLOYEB:
CORTROL:
CilIATE INDBX Cl,C2,C),Cl00,Cl0l:
PRINT SIZE:
EHABLE ROLLBACK:
SAVE DATA BAS! I:
ACCESS:
COMMAND FILE IS INPUT:
IN PREDICATE
Release 12.0 provides two new SCF where-clause operators, IN
and CTNSIN. These operators allow for several values enclosed in
parentheses to be used for a single component. The values specified in parentheses are treated as EQ conditions connected with the
OR operator.
Steps in the Conversion Process
• Allocate Release 12.0 database Files 1 through 6 with the
DDname using the first 7 characters of the database file.
• Allocate a data set for use as the output Command File
KEYS with the DDname of KEYS.
An additional benefit of this enhancement is that the values within
parentheses do not require the use of the where-clause delimiter
when the values contain an SCF keyword. Once IN or CTNSIN is
given, the values within parentheses are considered to be data values separated with commas.
• Provide one parameter entry for each database being
converted in this execution using the DDname of
CNVPARM.
• Execute the conversion program.
Example: These commands
• Execute an SCF job using the KEYS data set as the input
Command File.
PRINT el, C2, C) KH CII EQ AAA OR CII EQ BBB OIl. Cij CCC:
PRINT Cl, C2, C3 KH Cij CONTAINS A OR CII CONTAINS 8 OR CII CONTAINS C:
PRINT Cl, C2, C3 liB CII EQ ITOK AND KAlI.Yl OR C4 EQ IJOHN AND SALtY!:
A sample job control to convert the employee database follows:
can now be expressed
IICOItVBRT JOB ......... .
IICONVBRT EXEC PGH=CNVRTI2
IISTEPLIB DO DISP=SHR, DSH=USBlI;. LOAD
IISYSPRINT DO SYSOtfT.. A
IISISUDUHP DO SYSOUT"A
IIEMPLOYil DO DISP=OLD,DSN"USER.R120.BKPLOn:l
IIEMPLOYB2 DO OISP=OLO ,OSH"USER. R120. BKPLOYB2
IIIMPLOYiJ DO OISP=OLO,DSN.. USBR.RI20.EKPLOYE3
IIBMPLOn:~ DO DISp .. OLO ,OSH=USBR. R120. EKPLOYEq
IIEMPLOYBS DO OISP-OLD ,OSN=USER. R120. BMPLOYES
IIEMPLOYE6 DO DISP",OLD,DSH=USER.R120 .BKPLOYE6
IIEMPLOYES DO DISP:OLO,OSN"USBR.Rt 16 .SAVEFILB
IIKEYS
DO DISP=OLD,DSH-USER.KEYFILE
IICNVPARH DO •
EKPLOYEE (CONVERT, REBLOCK)
/.
PRINT
PRINT
PRINT
PRINT
Cl,
Cl,
Cl,
Cl,
C2,
C2,
Cl,
C2,
C3
CJ
C3
c3
KH
KH
WH
lIH
as
CII
ell
CII
01
IN (AAA,BBB,CCC):
CTNSIN (A,B,C):
IN (TOH AND IlA1I.Y, JOHN AND SALLY):
IN (lTOK Aim KARY/, IJOHN AND SALLY!):
DATABASE READ ONLY
Most MVS installations have security packages that provide the
basic READ, UPDATE, and ALTER authorities. SYSTEM 2000 software controls access to data at the component level with secondary
passwords established by the master password. This means that
SYSTEM 2000 software opens aU database files with update intent
and uses passwords to control access.
The purpose of this enhancement is to allow SYSTEM 2000 singleuser software to determine the intent of the user and open the database files READ-ONLY or REAOIWRITE as appropriate.
MIXED-CASE DATA
SYSTEM 2000 software has atways allowed for lowercase data, but
made it difficult by demanding that all the syntactical keywords be
entered in uppercase. This enhancement to Release 12.0 allows the
SCF syntax parser to accept and recognize keywords and component names entered in lowercase.
• SYSTEM 2000 single-user software first checks the
disposition of File 1 and opens the database files
READ-DNLY DtSP~SHR.
n
• If OISP=OLO is specified, the password is checked. The
database files are opened READ-ONLY when a secondary
password is used that has no update authority for any
component. Even a single component with update authority
is enough to prevent READ-ONLY.
This enhancement is used in conjunction with execution parameter
OPT043 that instructs SYSTEM 2000 software to disable uppercase translation. By default, SYSTEM 2000 software translates
data to aIf uppercase before processing except when the data come
from an alternate Command File or Data File.
• Master, DBA, and secondary passwords that have update
authority cause the database files to be opened
READIWRITE. Multi-User will always open the database files
READ/WRITE.
Here are the situations where you can specify OPT043=YES:
• SYS2KTPI for Multi-User TP processing
• SYS2KJOB for Multi-User batch or TSO processing
3390 DISK SUPPORT
• SYS2K for single-user batch or TSO processing
IBM" has been shipping 3390 disks for the past year, and many of
our customers already have them. For Release 11.6 and Release
• For CICS SCF users, the CtCS Terminal Control Table
dictates if the input from the tenninal is translated to
uppercase.
509
11.5, a zap is available to support 3390 disks with current block
sizes.
• 00 your data sets contain redundant data that take up too
much storage in your system?
Release 12.0 fully supports 3390 disks. Additionally a new half-track
block size of 27,972 is now available.
• Does your site have difficulty in coordinating updates of
multiple users?
USER EXITS
• Does your site experience data integrity problems due to a
lack of security? Could you use security on a variable-byvariable basis?
Many customers have taken advantage of the user exits provided
in SYSTEM 2000 software to perform specialized processing, such
as dynamic database file allocation, additional security checking,
and so forth.
• Do your users need access to data through CICS?
Eliminating Data Redundancy
In nondatabase systems each application has its own private files.
That fact can often lead to considerable redundancy in stored data,
with resultant waste in storage space. For example, a personnel
application and an education application may each own a file that
includes department information for employees. These two files can
be integrated and the redundancy eliminated by using the hierarchical design of a SYSTEM 2000 database. Hierarchies occur naturally
in many data systems. Corporations have companies, companies
have departments, and departments have employees.
SYSTEM 2000 software takes advantage of these hierarchies and
stores data once for each level of a hierarchy.
In Release 12.0, user exit 42 is added for termination processing.
Exit 42 is the final user exit called and it provides the opportunity
for you to clean up any resources that your exits may have obtained,
such as freeing any getmained areas and closes any DCB that you
opened.
In addition to user exit 42, internal changes were made to allow up
to 150 user exits for future growth.
The 31-bit addressing enhancement to Release 12.0 that provides
for full 31-bit addressing may have an impact on your user exit code.
When SYSTEM 2000 software is running in 31-bit mode, your userexit routine will be entered in 31-bit mode. Some of the addresses
passed to your user exits require your exits to be in AMODE(31).
Unless your user exit is doing 110 processing, minimal change
should be required for your exits to run in 31-bit mode. If you have
any questions concerning 31-bit addressing, please contact the
Technical Support Hotline in Austin at 512-250-9170.
Here is an example of direct access disk space savings that occurs
when you have hierarchical data and you put that data into a
SYSTEM 2000 database. A survey of 36,000 companies was taken
about their hardware and software products. Each company has
one or more machines, each machine has one or more software
products installed. Here is the breakdown of each record type:
• Number of companies: 36,000
CONCLUSION OF RELEASE 12.0 ENHANCEMENTS
• Number of machines: 124,000
That concludes a brief description of the enhancements made to
SYSTEM 2000 software with a schedule production release during
the second quarter of 1991.
• Number of products installed: 606,000
Since Version 6 of the SAS System offers many options in how to
store the data in a data file, we choose two scenarios to define the
SAS data files. First, the data was stored in one flat data file in that
each observation contained all variables for each software product.
The second was to store the data in three SAS data files with key
variables used for value-based joins. All of these data files could be
stored in a compressed format, allowing SAS software to remove
all occurrences of 3 or more identical bytes. This data collection
lends itself to the hierarchical structure. A single SYSTEM 2000
database was built with those three records in a single path tree.
The following shows disk space utilization in cylinders:
Now I want to address the issue of why SYSTEM 2000 software
is an excellent place to maintain your production SAS data. With
Version 6 of the SAS System and SAS/ACCESS interface to
SYSTEM 2000 software, you can manipulate data using a
SAS/ACCESS view in the fashion you can access a SAS data file.
WHY PUT YOUR DATA IN A SYSTEM 2000
DATABASE?
SYSTEH 2000 database
Flat data set
Flat compressed data set
Company only data set
Hachine only data set
Softwate only data set
Three data sets combined
The main reason to choose a heirarchy to represent information is
to gain perfomance benefits and save disk storage space by eliminating duplicate information and allowing the hierarchical structure
to maintain relationships between records. Anytime your application
deals with several different types of records that are related in a
one-to-many relationship, you can gain many advantages by storing
that data in a hierarchical database. If each record type was a separate file, there would be duplicate information so that you could join
data back together.
117
633
460
22
38
1611
224
As you can see, even when the flat file is compressed, the SAS data
file required 4 times the amount of disk space as the SYSTEM 2000
database. This is due to the fact that the company data and hardware data was repeated for each software product. When the
SYSTEM 2000 database was populated, the need to duplicate
570,000 company records and 482,000 hardware records was eliminated .
Here are several questions you should ask about your data and your
applications usage of that data.
• Do you have multiple data sets for one application that you
must frequently merge and preprocess in order to do your
work?
Much of the disk space was recovered when the information was
put into three separate data sets, thus eliminating the need for duplicate information. But there still is a need to carry extra data values
in each record so that the records could be joined back together.
• Do you have large data sets that cause slow retrieval and
updating?
510
Update and Retrieval Comparison
• Data redundancy and overhead of separate files (data and
work) reduced.
For both retrievals and updates, the comparison between one flat
file versus three smaller flat files versus the SYSTEM 2000 database
varied. Updates were done using SASIAP application programs
that read transaction files that use the company site number to
locate records and then update various information concerning the
company, hardware. and software data. SAS/AF software and
transaction files were used to take advantage of index processing
and to simulate an on..tine environment. Retrievals were done using
the Sal procedure.
• Eliminates the need to have multiple copies of the same
database.
• Resources between users (buffers, threads, data) shared.
• One copy of SYSTEM 2000 software code for all users.
SYSTEM 2000 SOFTWARE BACKUP AND RECOVERY
SYSTEM 2000 software Coordinated Recovery is the mechanism
that is automatically invoked when necessary, thereby preventing
a loss of downtime for recovery. When an error condition occurs
or a damaged database is opened, the recovery process is automatically invoked. In many cases you will not even know it happened,
unless you examine the job log.
When data were in three separate files and updates were isolated
to a single data set, updating the single flat file was faster. A problem occured when the values you were updating was the primary
key since you then must update the other files. A second problem
occurred when you wanted to update the data based on joined
tables. The biggest problem occurred when you joined the multiple
data sets. Once Sal processing has joined multiple data sets.
indexes are lost for the resultant table. This was the best case for
maintaining your data in a SYSTEM 2000 database; you still have
index capability.
Updating a database using the SAS System takes advantage of
Coordinated Recovery if it is enabled. If you have Coordinated
Recovery enabled, there will be no partial updates caused by database error, transaction abend, or the CANCEL command.
When data were in a single flat data set. the results varied based
on the level of the record and the amount of data being retrieved.
SYSTEM 2000 software was better when the requested record was
in the higher favel records. The main reason for the improvement
was the elimination of duplicate and redundant data. Any updates
to company data had to be repeated for each software record.
Updates at the software record level were better using the SAS data
file. Retrievals were better with SYSTEM 2000 software when 10
percent of the data being processed was subsetted and sorted.
Batch type updates and retrievals that require a full pass or a large
percentage of the data are best handled with SAS data files.
Coordinated Recovery offers the best protection in a Multi-User
environment by coordinating all the update activity of all users on
the same database. Only the updates for the user that caused Coordinated Recovery to be invoked are removed from the database.
All other user's updates remain. For those users who write their own
PlEX programs, updates to multiple databases are protection.
Unless the updates are committed, updates to all databases are
removed that occurred within a single logical unit of work.
CICS Access to Your Data
Primary access to your data is from CICS, TSO, or batch. For many
OS/MVS installations, CICS is the main interactive method to
access your data. SYSTEM 2000 software offers a solution with its
CICS interface and Multi-User software products. You have complete access to your databases from all of those environments when
you put them into a Multi-User environment.
If the user environment consists of small- to medium-sized data
sets with little or no redundancy, then the SAS base engine is the
best format. If data redundancy is an issue or if the data sets are
large, a SYSTEM 2000 database is the best storage methodology
for your data.
For the CICS environment, you can write application programs in
PU1, COBOL, or Assembler language using PLEX to access your
databases in a Multi-User environment. Updates performed by CICS
transaction are immediately available to your SAS software application running in TSO or batch.
Advantages Using Multi-User Software
Multi-User software allows many users to access, retrieve, and
update SYSTEM 2000 databases simultaneously in a real-time environment. There are many applications where it is critical to have
access to the latest information. The Multi-User software automatically ensures data protection during concurrent updates to the same
record, and automatically guards the database against conflicting
tasks. With the record locking feature used by Multi-User software.
you always have the latest copy of an observation regardless of how
many users are attempting access or updating the database.
CONCLUSION
SYSTEM 2000 Data Management System software offers the storing of data that allows for fast data access, flexible data query, full
security at the schema item level, automatic Coordinated Recovery,
Multi-User software, PlEX. and the Self-Contained Facility. The
enhancements to Release 12.0 give you even more flexibility with
dynamic file allocation, 31-bit addressing, larger database capacity,
and more components.
This means one user could be updating the database with the
FSEDIT procedure and another user would have the latest update
for a report or to use as criteria for updating other values.
Multi-User software can also reduce the need for multiple data sets.
Instead of several users updating different data sets, then combining them back into a single SAS data file, you can use Multi-User
software to control the simultaneous updates from several users.
Beginning with Version 6 of the SAS System, the SAS/ACCESS
interface to SYSTEM 2000 software allows any SAS procedure to
use a view of a database just as you would use a SAS data file.
This gives the SAS user the full advantages of SYSTEM 2000 software and still allows you to use the SAS System tools that are familiar to you.
Here is a list of some advantages using Multi-User software.
• All users have simultaneous access to current data.
• Data integrity ensured by Multi-User software for all
updates.
SAS, SAS/ACCESS, SAS/AF, SAS/FSP, and SYSTEM 2000 are
registered trademarks and Multi-User is a trademark of SAS Institute Inc., Cary, NC, U.S.A.
• Multi-threading overlaps input/output operations with CPU
processing.
IBM is a registered trademark and MVS/ESA and MVS/XA are
trademarks of International Business Machines Corporation.
511