V5R1 - CCAAPSY, APSY Precompiled Procedures in Storage By James Damon
Understanding APSY Precompilation User Language procedures are always compiled prior to evaluation. The compilation is discarded immediately after evaluation. The procedure is recompiled if a subsequent user or the same user includes it again. However, when running under APSY, compilations are saved for future use if they meet all the following requirements:
When a procedure is compiled and that compilation is saved under APSY, subsequent use of that procedure is as precompiled. Users do not incur the overhead and the response time delay of compiling the procedure again. Since the procedure is compiled only once per subsystem class by the first invoking user, significant CPU and I/O resources are saved.
These saved compilations, which consist of entries in NTBL, QTBL, STBL, VTBL, and the FSCB, SCREEN, and IMAGE initial definitions, are saved in CCATEMP pages. Subsequent users of a precompiled procedure incur only the delay required to load those CCATEMP pages into their server. They avoid any delays and resource consumption associated with compilation.
Benefits of Using CCAAPSY The new CCAAPSY feature in V5R1 can further reduce the delays associated with loading precompiled procedures from CCATEMP. To save precompiled ASPY procedures in CCAAPSY, set APSYPAGE to nonzero and DSPOPT to X’00’ (for a dataspace), or X’20’ (for a scrolling hiperspace), or X’60’ (for a cache hiperspace). A scrolling hiperspace is a high-performance dataspace backed by expanded storage and auxiliary storage. A cache hiperspace is backed by only expanded storage. If expanded storage is abundant, a cache hiperspace will provide better performance than a scrolling hiperspace. If you are uncertain, start with a cache hiperspace and monitor the PAGEF statistic in the MONITOR DATASPACE output. An increasingly higher number of page faults in a CCAAPSY cache-hiperspace indicates that expanded storage is limited and that better performance might be provided by a scrolling hiperspace.
Model 204 continues to save all precompiled procedures in CCATEMP, because CCAAPSY might not be large enough to hold all precompiled procedures. However, saved compilations found in CCAAPSY are loaded from that data structure, not from CCATEMP. An APSY load from CCAAPSY is a direct data movement from an in-memory data structure to the user’s server and bypasses the Model 204 disk buffer pool. This reduces pressure on the buffer pool resulting in a system-wide reduction in database and CCATEMP I/O, further improving user response time and overall system performance.
CCAAPSY in Memory On OS operating systems, OS/390 and z/OS, the APSYPAGE parameter specifies the number of 4K-pages to allocate in CCAAPSY to hold all precompiled APSY procedures across all application subsystems. To approximate a value for APSYPAGE use the output from the MONITOR SUBSYS (PROCCT) LIKE * command. The following example is that output for one subsystem.
SUBSYSTEM NAME: TESTER NUMBER OF PRECOMPILABLE PROCEDURES (SAVED): 14NUMBER OF PRECOMPILABLE PROCEDURES (NOT SAVED): 17NUMBER OF NON-PRECOMPILABLE PROCEDURES: 12CCATEMP PAGES USED FOR PRECOMPILED PROCEDURES: 308NUMBER OF REQUESTS MADE RESIDENT: 12 NUMBER OF ELIGIBLE REQUESTS NOT RESIDENT: 0STORAGE USED FOR RESIDENT REQUESTS: 806912 NUMBER OF RESIDENT PROCEDURE EVALS: 1170 NUMBER OF SWITCHES FROM RESIDENT MODE: 70
The following line provides a value to use to approximate the number of 4K-pages required in CCAAPSY to hold these precompiled requests:
CCATEMP PAGES USED FOR PRECOMPILED PROCEDURES: 308
Use the 308 in the following formula, where 6144 represents bytes of data in the CCATEMP page, excluding trailer bytes, and 4096 represents a 4K-page:
(308 * 6144) / 4096 = 462
If this was the only APSY running on your system and this display was done at the end of the day, so that you saw high water marks, then APSYPAGE=500 would be appropriate.
MONITOR DATASPACE Command
Under V5R1, when you allocate CCAAPSY in memory, the MONITOR DATASPACE command can provide additional information concerning memory allocation and the data movements required to support loading precompiled APSY procedures into a user server.
VIEW APSYPAGE,DSPOPT APSYPAGE 500 NUMBER OF APSY PAGES IN HIPERSPACE DSPOPT X'00' DATA SPACE OPTIONS MONITOR DATASPACE04.006 JAN 06 19.16.21 PAGE 11 NAME DATASPACE TYPE 4K PAGES PAGE HWM EXTRA DATASPACES -------- ------------------- ---------- ---------- ----------------- CCAAPSY DATASPACE 500 144 NAME READS WRITES PAGES READ PAGES WRITN SLOWRD SLOWWR PAGEF -------- ---------- ---------- ----------- ----------- ------ ------ ------ CCAAPSY 779 10 12512 129 0 0 0
Use the following table to clarify what the values represent.
Note: These statistics are interpreted differently when the dataspace is CCATEMP or CCASERVR. See the November and December 2003 issues of CCAPRINT for details)
In Summary As I mentioned in last month’s article, most organizations today have added considerable resources in real memory and expanded storage, not available just a few years ago. Allocating CCAAPSY in memory provides yet another way to achieve a return on that investment by effectively using these new resources to improve Model 204 performance. CCA recommends that as you begin experimenting with dataspaces, you should first allocate CCATEMP in a dataspace and CCAAPSY in a dataspace or hiperspace. Then, if sufficient real storage is available and you are looking for additional performance gains, CCASERVR in a dataspace should be considered.
System 1032
Making Bulk Updates with the TRANGEN Utility By Tym Stegner
A Little History of the Transact Process In the beginning, there was System 1022—datasets at hundreds of sites, for thousands of users, and millions of records. To make bulk updates to all those datasets, a System 1022 command, TRANSACT, was used for bulk update processing, which is described in the System 1022 User’s Guide, as:
The TRANSACT command performs changes and additions to a data set, using data in records supplied by the user. The changes are made to the current data set, called the MASTER data set. The transaction records, called TRANSACTIONS, are supplied in another data set, or in a data file.
Transact processing reads sequentially through the transaction dataset, matching the update records to the records in the master dataset, and performing update actions. Actions include ADD, DELETE, and CHANGE. The fields updated in the master dataset are the fields supplied from the transaction dataset.
When System 1022 moved into its sister product, System 1032, the TRANSACT command was emulated with the TRANGEN utility.
Features of Transact Processing Instead of performing direct updates to the master dataset, your application can write changed records to a transaction dataset. Often, each data entry user has their own transaction dataset. You can merge these datasets into a single transaction dataset, or you can process the individual transaction datasets sequentially.
During processing, the generated TRANGEN image sorts and collects the transaction records into groups, then locates the appropriate master record using the specified locators (via attribute matching). The values from the transaction dataset attributes are used to change the master dataset attribute values. Processing continues until all transaction dataset records are processed.
A couple of basic transact processing options from the System 1022 TRANSACT command were incorporated directly into TRANGEN:
Using the TRANGEN utility The TRANGEN utility generates a FORTRAN program that does the work of transact processing between the master and transaction datasets for each master/transaction dataset pair. In addition to the 3GL code, a command file is created that runs the bulk update process.
Creating the Transaction Dataset Before you can use the TRANGEN utility, you must create a transaction dataset to collect the update records. Usually the DMD for the transaction dataset is a copy or subset of the master dataset attributes with its own dataset name.
When you create the transaction dataset you can utilize the ADDITIVE option from the System 1022 TRANSACT command on attributes of data type Numeric. The ADDITIVE option instructs transact processing to add (or subtract) the value of a transaction dataset attribute to the master attribute value, instead of replacing it.
To identify a Numeric transaction dataset attribute with the ADDITIVE option, use the MODIFY TEMPORARY command and apply the TOTAL summary option to the attribute.
For our example we created dataset EMPLOYTRAN as the transaction dataset. It contains the primary locator: in our example, SOCIAL_SECURITY_NO. If the primary locater is inadequate information to locate a specific record, you can specify up to three more attributes as locators.
1032> Open Library TRANGENLIB in S1032_TOOLS 1032> Open Dataset EMPLOYTRAN ! The transaction dataset1032> Modify Temporary 1032> Open Dataset EMPLOY !The master and current dataset1032> Call TRANGEN (“EMPLOYTRAN”,”SOCIAL_SECURITY_NUMBER”)
The master dataset must be the current dataset (via an OPEN or SET DATASET command) prior to the CALL TRANGEN command.
The TRANGEN Utility in Action The TRANGEN procedure generates a number of source files, initiates a batch stream to compile the FORTRAN-based transaction program, compiles a System 1032 library containing the record descriptors and procedure call, and returns to the 1032> prompt. A message that a batch job has been submitted for a job called TX is displayed.
1032> Open library TRANGENLIB in S1032_TOOLS readonly1032> open ds EMPLOYTRANSCurrent dataset is now EMPLOYTRANS1032> modify temporary atr salary total1032> open ds EMPLOYCurrent dataset is now EMPLOY1032> call TRANGEN("EMPLOYTRANS","EMPLOYEE_NUMBER")*** T R A N G E N V2.90-4 ***TRANGEN-I-BEGCRE, Beginning generation of program files.%TRANGEN-I-VMSARCH, Generating VAX-type code.%TRANGEN-I-COMP, Compiling TX_EMPLOYTRANS_EMPLOY program.Job TX (queue ASP_BATCH, entry 850) started on ASP_BATCH%TRANGEN-I-CRELIB, Creating library TX_EMPLOYTRANS_EMPLOY1032>Job TX (queue ASP_BATCH, entry 850) completed1032>
Once the compilation batch job is completed, you can execute the generated COM file from the DCL prompt:
$ @TX_EMPLOYTRAN_EMPLOY
Continuing the Bulk Update Processing When the TRANGEN utility completes processing, you must contine the bulk updates processing by initiating the COM or DMC stream created. In our example use the EMPLOY.COM file.
Modifying the COM File Execution Parameters In our example, we ran the COM file accepting the seven default parameter values, which are described as follows:
1. Transaction Type
Transaction type specifies the type of processing you want, expressed as one of the following integers.
For efficiency, both the master and transaction datasets are sorted prior to processing.
The NO_CHANGE_BLANKS Qualifier The NO_CHANGE_BLANKS qualifier is from the System 1022 TRANSACT command. It specifies that if a transaction attribute value is blank or missing, the corresponding master dataset value is not changed or replaced during update processing.
2. Spooled Keying Switch
To update the keys in bulk mode, key spooling buffers key updates until all record changes are complete. Set the parameter to TRUE to enable key spooling; the default is FALSE.
3. Spool File Specification
Sets the file name and directory of the spooled key file, when Spooled Keying Switch is TRUE. If unspecified, the default spooled key file name is the current disk and directory, the master dataset name, and file type is DMT: for example, EMPLOY.DMT. The spool file is automatically deleted when transact processing finishes.
4. Transaction Buffer
Specifies the array size of the transactions buffer (INBUF). The default number of records is 200.
5. Master Add Buffer
Specifies the array size of the master add buffer (ADDBUF). The default number of records is 200.
6. Master Change Buffer
7. System 1032 $BUF_NUMBER
This system variable controls buffering space for key updates. Set this value by adjusting the default value upward, then comparing subsequent run statistics to minimize I/O operations. The default number of buffers is 96.
You can modify the generated FORTRAN code to make it more suitable for your operating environment. Use the TX_COMPILE.COM procedure in S1032_TOOLS to recompile a modified source.
CCA Support for TRANGEN The System 1032 Tools Guide has a detailed chapter on the TRANGEN utility. If you want a copy of that chapter, make a request to System 1032 Support.
In some cases when you are using TRANGEN, the generated FORTRAN code may not correctly compile on your system. Should this occur, request the TRANGEN update from System 1032 Support.
Announcing V6R1 Product Plan By Chris Ramsdale Director – Strategic Product Planning
The Product Plan for Model 204 V6R1 is now available for download from the CCA web site at: http://www.cca-int.com/prodinfo/prodplan.html
You will find that V6R1 offers more scalability, greater availability, increased flexibility and further extensibility than any previous release.
If you followed the recent correspondence concerning Model 204 value list manipulation, you will be particularly interested in the many new value list manipulation features that will be in V6R1 User Language. A few weeks ago, there was some discussion here about the mainframe market. The V6R1 Product Plan includes an up-to-date discussion on this topic, and - yes - it IS safe to say mainframe again.
Of course, you will also find many other new features--including (naturally) further enhanced performance and new connectivity options.
If you have any difficulty downloading the Plan or you would prefer a printed, bound copy, please send an e-mail message that includes your full postal address to:
Contact CCA Webmaster
Copyright 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
