Model 204 Automated System Monitoring with IODEV=3 Threads
By James Damon
Often a system manager, a database administrator, or an applications programmer needs to look at the history of what was happening in a production Online for a particular time interval or for a specific time of day. The CCAAUDIT file and the AUDIT204 utility provide some information in the form of detailed and statistically summarized reports. However, in many cases problem resolution requires information provided by various real-time displays and reports that can be captured only at the time in question. Output from the VIEW, DISPLAY, and the various MONITOR commands is very useful, but cannot be obtained after the fact. The output must be collected at the time in question for later analysis.
Introducing IODEV=3
With IODEV=3 threads you can perform a variety of functions which are triggered by time or an event that can be detected by the thread, such as a change to a data value in a file. In addition you can use IODEV=3 threads to automatically collect information you might want later. Since it is not possible for you to know in advance at what time or what period of time you might require such information, you can produce it in an automated fashion. IODEV=3 threads can provide input, in the form of commands and User Language programs, to Model 204 exactly like that provided from a terminal and other IODEV threads: 7, 11, 29, 39, 41, and 49. However, the input from IODEV=3 threads comes from a sequential, BSAM dataset rather than from an individual user like yourself.
Tracking Parameters
The output produced by IODEV=3 threads goes to a different sequential or SYSOUT dataset. You can use the following simple example of an IODEV=3 thread definition and the associated input/output datasets by supplying your own parameters.
//I03OT001 DD SYSOUT=A //I03IN001 DD *(or DSN=M204.PROD.IODEV3IN,DISP=SHR) LOGIN SYSMGR PASSWORD *SLEEP 60 (wait for system initialization to complete)
As Model 204 encounters these threads during system initialization, the associated input and output datasets are opened and processed. The input dataset is read as though each record was coming from an individual user. The output data, such as prompts, error messages, and displays, which are generated by these commands and User Language programs, are sent to the output dataset. When end-of-file is reached in the input dataset, the dataset is closed and the thread is terminated. It appears as a DEAD thread in a LOGWHO command output display, for example:
LOGWHO USER 0 SUPERKLUGE USER 2 M204B01 XFTCPIPB USER 5 CCA34 XFTCPIP0 USER 6 JIMDAMON XFTCPIP9 DEAD: 7
Collecting Runtime Information for Later Analysis
The number of IODEV=3 threads you can define is limited by only the NUSERS parameter. Depending on the privileges associated with the logged on user ID, each thread can issue commands, open files, include procedures, allocate datasets, and so on. These threads may also invoke APSY subsystems, which can be designed to issue monitoring commands, sleep or pause some number of seconds, and repeat those monitoring commands for the entire duration of the Online.
In this way, you can automatically collect valuable performance or debugging information and analyze it either while the Online continues to run or after the run is brought down. For the subsystem named IOD3MON, the following APSY-initialization and login procedures are all that are required to accomplish this:
PROCEDURE N.IOD3MON.INIT *---------------------------------------------------------* * RESET PARAMETERS CONTROLLING CCAAUDIT OUTPUT AND OUTPUT * * LINE LENGTH. VIEW ALL PARAMETERS AND EARLY WARNINGS AT * * SUBSYSTEM STARTUP * *---------------------------------------------------------*
RESET LECHO 4, OUTCCC 132, OUTMRL 132 VIEW DISPLAY EW ALL *SLEEP 60 /? PAUSE UNTIL SYSTEM INITIALIZATION IS COMPLETE ?/ END PROCEDURE
PROCEDURE N.IOD3MON.LOGIN *------------------------------------------* * MONITOR EVERYTHING ONCE EVERY 10 MINUTES * *------------------------------------------* MONITOR MONITOR CONFLICT FILES SL MONITOR ENQ MONITOR VTAM MONITOR CHKP USERLIST SL MONITOR STAT *SLEEP 600 END PROCEDURE
The following DD statements (or FILEDEFs or DLBLs) and IODEV=3 thread definition cause the thread to enter subsystem IOD3MON:
//IOD3OUT DD SYSOUT=A //IOD3IN DD * LOGIN AUTOMON PASSWORD IOD3MON //CCAIN DD * your-own-parameters IODEV=3,INPUT=IOD3IN,OUTPUT=IOD3OUT
The procedure N.IOD3MON.LOGIN is executed endlessly, with a 600-second pause, since the NEXT global variable is never reset. The output generated by these commands goes to the IOD3OUT ddname, which is either SYSOUT or a sequential dataset. You can review this output while the Online continues to run or after the Online terminates.
In Summary
You can use multiple IODEV=3 threads to simulate large, multi-user Onlines and the effect a new subsystem, file, or application may have on performance. CCA regularly uses such simulations to measure performance improvements in new releases. This also ensures that the myriad of issues, including record and resource locking conflicts, for example, involved in large, multi-user environments are handled correctly. IODEV=3 threads are easy to define and implement. They can provide a wide range of useful data to a variety of support staff in any organization.
For additional uses for LODEV=3 Threads, see Multiuser Simulations Using LODEV=3 Threads.
System 1032 Query Efficiency: Part 5
By Kevin Fuller Updated by: Tym Stegner
Making Your Queries Go Faster
Knowing how key tables and the commands that use them work empowers you to make informed decisions. These decisions can lead to reduced I/O, which is directly tied to increased efficiency of key oriented commands, which results in a faster response to your query. A faster response is your goal.
Deciding which Operator to Use and When
You can use the following chart to tell you which operators are the fastest for FIND processing:
Figure 1: Relational operators listed in descending order for efficient processing
However, it can be much more beneficial to pick operators based on knowing why each is more or less efficient. If you know the details of your data distribution well, you can formulate a query that operates in a more efficient manner, even if the query itself is more complex. Some basic rules and reasons for them are:
First choice: EQ or NE
Use the EQ or NE operators whenever you can. They are the speed team of the FIND command because of their short, predictable top-down read through the branches of the B-tree structure.
Choose BET over LE AND GE
Try to use the BET operator instead of the (LE AND GE) operator combination. The FIND command breaks down the latter case into three operations: the LE processing, the GE processing, and merging the selections for the final result.
The BET operator goes to the lower value as a starting point, scans to the higher value, and then stops reading the keys. This results in at least a 50 percent saving over the LE and GE processing. If the two values are close together, the time saved can exceed 99 percent.
Choose BEGINS over CT
Use the BEGINS operator over the CT operator, if you can. There is a functional difference between them. The CT operator always scans the entire lower-level key blocks; the BEGINS operator scans only the small section of lower-level key blocks that are applicable. Don't fall into the habit of always using the CT operator, if the BEGINS operator might do the job.
Choose CT over MATCHES
Use the CT operator rather than the MATCHES operator, if you can. Again, there is a functional difference, although it has nothing to do with how the operators read the key tables. Both do exactly the same full scan-across of the lower-level key blocks. However, the MATCHES value processing is a more involved, so more time is spent evaluating each value read in the key tables.
A positive look at NOT
Don't forget the NOT operator, which is often overlooked as a method of formulating efficient queries. Take, for example, an attribute recording credit card account balances:
If you wanted to locate all the records with a positive balance, the obvious query is to specify:
FIND BALANCE GT 0
Works every time. However, the following query works faster for the same result:
FIND NOT (BALANCE LE 0)
The GT operator causes a scan of the majority of the lower-level key blocks. The NOT LE clause executes a FIND LE, which scans only up to the value zero (0). The NOT operator locates the complement set, which is what you want.
Note: MISSING values are included in the NOT LE query, but not in the GT query.
Coordinating the use of the FIND and SEARCH commands
Sometime it is faster to look at the physical records in your dataset than to use the key tables: sometimes not. The following considerations apply as to whether to examine records or the key tables.
Summary
The more you understand about how the key tables work, the more easily you can use them to take the most efficient path to complete your query. This is true for other parts of System 1032, but key table access is probably the most common activity where you have some control and can make a difference.
See the previous four articles for a complete review of the key tables and how they work, FIND command processing, and other commands that rely on key tables.
Part 1 introduced key table internals.
Part 2 described how key tables work.
Part 3 described FIND command internal processing.
Part 4 discussed the other PL1032 commands that use the key blocks the same way that the FIND command uses them.
Copyright © 2003 Computer Corporation of America. All right reserved. Published in the United States of America.
500 Old Connecticut Path, Framingham, MA 01701 Contact CCA Webmaster Copyright 2005
