Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Entity–attribute–value model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Concurrency control wikipedia , lookup
Relational model wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Functional Database Model wikipedia , lookup
ContactPoint wikipedia , lookup
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