Model 204 XDM CRAM: Performance Advantages
By James Damon
Version 4.1.1 introduced a new option for the Cross Region Access Method (CRAM): the Cross Region Data Mover or XDM. The XDM option provides usability and performance benefits which make it a far superior choice for customers who perform extensive processing using BATCH2 or IFAM2, or who use the CICS or TSO interfaces to access a Model 204 Online.
MVS or OS/390 customers who enable this option should see significant reductions in CPU consumption on thread types IODEV=11, IODEV=23, and IODEV=29. The XDM CRAM feature is not available in the VSE or CMS environments.
Installing XDM CRAM
Support for XDM CRAM is provided in the M204XSVC object deck. When this object is linked into the ONLINE load module, neither XDM CRAM nor IOS Branch Entry require an SVC for operation. Instead, the load library containing the ONLINE load module must be APF-authorized, because M204XSVC uses restricted system services.
However, since APF authorization is also required for running Model 204 as a nonswappable address space or for customers who have installed one of the CCA security interfaces for ACF2, Security Server (formerly RACF), or TOPSECRET, APF authorization should not change the level of effort required during installation. In fact, avoiding an SVC installation decreases the level of effort.
The non-SVC load module, IGCLM244, must still be generated using the CRAMINS job with the CRAMSVC parameter omitted. In the Version 5.1 installation, setting the INSPARMS parameter CRAM-SVC-NUM=NOSVC generates the correct CRAMINS job.
Documenting Performance Improvements
Table 1 illustrates the performance improvements realized when XDM CRAM is used instead of non-XDM CRAM. The test application, which follows Table 1, is a BATCH2 program that sends a User Language request to the Online, which produces 100,000 lines of output which are returned to the DDNAME—CCAOUT in the BATCH2 job. The six tests were run on an IBM 2003-2C5 with 3 processors each rated at 30-35MIPS:
Table 1. Comparing time usage between XDM CRAM and non-XDM CRAM
CRAM option used
ELAPSED
Seconds
CPU – seconds
UL in ONLINE
BATCH2 JOB
The following application is a complete BATCH2 job that was used to generate the statistics shown in Table 1:
//BATCH2 EXEC PGM=BATCH2,PARM='CRIOPARM' //STEPLIB DD DSN=M204.LOADLIB,DISP=SHR //CCAOUT DD DUMMY //CCAIN DD * LOGIN USER1 USER1 RESET OUTMRL 123 OUTCCC 0 RESET HDRCTL 1 LECHO 5 BEGIN %X IS STRING LEN 50 %Y IS STRING LEN 50 %X='123456781X123456782X123456783X123456784X123456785X' %Y='123456786X123456787X123456788X123456789X123456710X' REPEAT 100000 TIMES PRINT %X WITH %Y END T REQUEST LOGOUT
Enabling XDM CRAM
The XDM CRAM option is enabled in the Online by setting XMEMOPT=X’8X’. For most OS/390 customers, this setting should be X’82’ to enable both XDM CRAM and IOS Branch Entry. If M204XSVC is linked into the ONLINE load module, then you may omit XMEMSVC from the CCAIN parameters. (It is ignored if present.)
One additional requirement for XDM CRAM: a separate XDM job must be up and running prior to initialization of the Online. This job, described in the Model 204 System Manager’s Guide, handles all communication between all BATCH2 and IFAM2 jobs and the target Online. The target Online is determined by:
In Summary
All customers, who make use of CRAM through BATCH2 or IFAM2 processing, should seriously consider converting from non-XDM CRAM to XDM CRAM for performance and ease-of-installation benefits.
To the CCA User Community From the Editor We were so pleased with a recent article written by Tym Stegner that developed ideas and shared some code from Ardie Schneider of Southwest Texas State University and Mike Hammer of STATS, Inc. This seems like the best type of article to present in CCAprint—an article that addresses the on-the-job needs of our user community.
To the CCA User Community From the Editor
We were so pleased with a recent article written by Tym Stegner that developed ideas and shared some code from Ardie Schneider of Southwest Texas State University and Mike Hammer of STATS, Inc. This seems like the best type of article to present in CCAprint—an article that addresses the on-the-job needs of our user community.
Just dash off a quick e-mail message telling us what you would like to share or what you would like to see discussed in print. Send your comments and ideas to us:
System 1032 Locating Dataset Damage
By Tym Stegner
Introduction
In the past two months, this column featured rebuilding datasets for efficiency. (Automating Dataset Rebuilds: Part 1 and Automating Dataset Rebuilds: Part 2). Ideally we rebuild datasets to run efficiently; in reality most datasets are rebuilt because a dataset-damage event occurred.
There are many roads to dataset damage, but as far as System 1032 is concerned, a dataset is damaged if an update is interrupted. It is possible to attempt to isolate user interaction from damaging datasets via disabling Control-C and Control-Y. We can also enable the $DAMAGE_ERROR system variable to make damage events into errors rather than warnings.
But these methods don’t help in those limited cases of internal or fatal errors causing damage. While we have seen that rebuilding datasets helps their efficiency, it would help if we could identify damaged datasets for our automated rebuilding processes.
Identifying a Damaged Dataset
Historically, there is only one way to tell if a dataset is damaged: open the dataset using System 1032.
A subsequent SHOW DAMAGE command reports on the dataset’s damage state. It also tells you what System 1032 logged about damage events: when they happened, what command was executing, and most importantly, which account had the problem.
The output from the OPEN or SHOW DAMAGE commands is generally handled via manual intervention. Often the damage is reported from an outside source, such as a user request, or a program fault from a job stream.
Beginning Automation
The first level of automation to determine dataset damage is a script that tests a dataset for damage and provides notification—either at the terminal, in a log file, or an OpenVMS mail message, as illustrated in the following COM file.
$! Check for damage $! $ if p1 .eqs. "" $ then $ write sys$output "You must specify a dataset name!" $ exit 44 $ endif $! $ xdsdam = "NO" $ s1032 variable dsname text varying init "''p1'" open library s1032_utl in s1032_tools read variable broke logical init false open ds @=dsname if $status eq #X0c089958 or - !-W-DAM $status eq #X0c08995A or - !-E-DAM $status eq #X0c0887A2 or - !-E-DAM_CAT $status eq #X0c0885C8 or - !-W-DAM_KEY $status eq #X0c0885CA - !-E-DAM_KEY then let broke = true end_if if broke then call SET_SYMBOL("XDSDAM","YES",1) end_if close * exit $! $ if xdsdam .eq. "YES" $ then $ mail dsdam.txt ADMIN /sub="Damage alert on ''p1'" $ endif $! $ exit
The previous procedure attempts to open a dataset and checks the OPEN $status value to see if any of the damage status codes are found. If so, a procedure local symbol is set. Outside of System 1032, if the symbol is found to be set, a predetermined notification message is sent to the maintainer.
Multiple Automation
Some sites use a command file to check all the datasets used for a particular task or a class of datasets. Usually the class variation command file passes in a class prefix and prepares the known set of dataset names with the prefix prior to opening them. This might be done as a stand-alone procedure, or as part of a job stream processing the datasets. … $ if p1 .eqs. "" then exit 44 $! $ s1032 var dsclass text varying initially "’’P1’" variable ds1,ds2,ds3 text varying let ds1= dsclass & "_d1", ds2= dsclass & "_d2", ds3= dsclass & "_history" open dataset @=ds1, @=ds2, @=ds3 show dataset * damage …
This type of procedure usually displays notification on a terminal screen. If any messages from either the OPEN or SHOW DAMAGE commands are seen by the operator, then the operator takes corrective action. Alternately, the procedure could prompt for a confirmation response of no damage before proceeding with the task at hand.
Limitations
The limitation of these approaches is the need to perform all the checking from within System 1032 itself with its attendant overhead of startup and such. We need a tool that checks System 1032 datasets for damage, before we get into System 1032 or the applications.
New CHECK_DAMAGE utility
To enhance the capability of scanning datasets for damage, we introduce at this time a new System 1032 utility program, CHECK_DAMAGE. This program opens the dataset file, checks the damage flag, and then reports the dataset's damage state. Opening and checking are done within the program without starting System 1032.
There are two possible responses for the dataset's damage state; either:
"Possible damage detected in dataset file ???." "No damage detected in dataset file ???."
For ease of use, the program should be run via foreign command:
$ DDC :== $S1032_IMAGE:CHECK_DAMAGE $! $ DDC S1032_DEMO:FILMS.DMS No damage detected in dataset file S1032_DEMO:FILMS.DMS. $
Variations on using the CHECK_DAMAGE utility
If you want to check several datasets, you can:
The output might be summarized using the PIPE command:
$! Check particular datasets $! $ DDC :== $S1032_IMAGE:CHECK_DAMAGE $! $ DDC FY02_DS1.DMS $ DDC FY02_DS2.DMS $ DDC FY02_SUMMARY.DMS $! $! Scan file example $! $ DDC :== $S1032_IMAGE:CHECK_DAMAGE $ create/log CHECK_FY02.TXT !summary output file $! $dloop: $ dsx = f$search("DS_LIB:FY02_*.DMS") $ if dsx .eqs. "" $ then $ type/nopage CHECK_FY02.TXT $ exit 1 $ endif $! $ PIPE DDC ‘dsx’ | APPEND SYS$PIPE CHECK_FY02.TXT $ goto dloop $!!
Another approach is to use the interactive interface of CHECK_DAMAGE. If no parameter is provided to the foreign command, or if the program is executed via the RUN command, CHECK_DAMAGE enters its interactive mode. You are repeatedly prompted for a dataset, until you terminate the program via Control-Z or a blank return. (User responses are in red.)
[interactive] $ RUN S1032_IMAGE:CHECK_DAMAGE _Dataset File Spec: fy02_ds1.dms No damage detected in dataset file fy02_ds1.dms. _Dataset File Spec: fy02_ds2.dms No damage detected in dataset file fy02_ds2.dms. _Dataset File Spec: fy02_Summary Possible damage detected in dataset file fy02_Summary. _Dataset File Spec: ^Z $
Using the CHECK_DAMAGE utility gives the benefits of checking for dataset damage without opening System 1032. The CHECK_DAMAGE program image may be downloaded from the CCAPRINT subdirectory of the FOX.CCA-INT.COM FTP site, via anonymous FTP. Look for the file CHKDAM.BKP. (Note: the image for the VAX platform will be available after 03/14/02.)
Note: The CHECK_DAMAGE utility supports only dataset files. If you open another type of file with the utiltiy, you will get a fatal error. No actual harm is done, but you will have to try again. If you open a file currently in use by another user, you will get a lock error.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
