This chapter describes the performance enhancements.
This section contains the following topics:
CA IDMS is enhanced with CICS threadsafe support that allows threadsafe application programs to use multiple open TCBs while accessing CA IDMS.
CICS Transaction Server for z/0S (CTS) provides a method for multiple CTS transactions to run simultaneously on separate TCBs. Application programs that are eligible to run in this mode are described as threadsafe. For more information about the CTS threadsafe operation, see the appropriate IBM documentation. A brief overview of this IBM feature as it relates to the CA IDMS interface is described in the next section.
Historically, all CICS application programs ran on the same TCB, which allowed only one program task to execute at any given instant. While multiple tasks could be active, only one task could execute instructions on a CPU. Under CTS, IBM has introduced the concept of threadsafe application programs that can be run on open TCBs, thus allowing multiple programs to execute simultaneously on different CPUs.
A program that is declared with the CONCURRENCY(THREADSAFE) attribute is considered to be eligible to run on an open TCB, but this attribute alone is not enough to cause the program to do so. Various conditions exist that cause a threadsafe program to execute on an open TCB. Three of the most common cases are the following:
When a task begins to run on an open TCB, it continues to run until one of the following occurs:
A threadsafe command is one which can be executed on an open TCB. A program defined as threadsafe can issue a non-threadsafe command. However, issuing a non-threadsafe command causes the task to be switched to run on the QR (single-threaded) TCB. This can cause performance degradation, particularly if a lot of TCB switching is done.
If a threadsafe program defined with API(CICSAPI) is switched to the QR TCB, it stays there unless another OPENAPI TRUE exit is invoked. If a threadsafe program defined with API(OPENAPI) is switched to the QR TCB, it switches back to the open TCB when control is returned to the application program after execution of the non-threadsafe command.
The CA IDMS interface modules that run in a CTS region have been enhanced to be threadsafe. Threadsafe application programs, that is, programs defined with the CONCURRENCY(THREADSAFE) attribute can use this enhancement to obtain increased throughput.
An application program that is running on an open TCB can access CA IDMS without switching to the single-threaded QR TCB. A new option, TRUEAPI, is provided to allow the first CA IDMS access by a task to force a switch to an open TCB. If the interface has been called by a program defined as threadsafe, the program continues to run on the open TCB after return from the CA IDMS call. For more information about the TRUEAPI option, see IDMSINTC Interface Considerations.
CTS has rules and guidelines on whether an application program can or should be defined with CONCURRENCY(THREADSAFE) or API(OPENAPI) attributes or both. Before defining your own programs as THREADSAFE or OPENAPI, be sure to consult the appropriate IBM documentation.
The use of CA IDMS with an otherwise threadsafe program does not cause integrity problems and can provide significant performance improvement. Depending on the nature of the application, however, it may not improve performance and could conceivably cause performance degradation. In addition, if a client-written application program is declared to be threadsafe and the program itself violates the rules for threadsafe programs, the results are unpredictable.
Note: A few cases exist where the CA IDMS interface issues CICS commands that force a switch to the QR TCB. For more information, see IDMSINTC Interface Considerations.
You can enter the IDMSINTC interface program using one of the following methods:
Except for a few cases, discussed in Non-threadsafe Instructions, the IDMSINTC interface does not issue any non-threadsafe commands. Therefore, if IDMSINTC is entered on an open TCB, it stays on the open TCB throughout its execution and return to the application program.
When a task makes its first CA IDMS call, IDMSINTC invokes the CA IDMS TRUE exit. This exit is always enabled with the THREADSAFE attribute. The TRUEAPI=OPEN parameter is provided on the CICSOPT macro that causes the exit to also be enabled with the OPENAPI attribute. For more information about the TRUEAPI parameter, see New CICSOPT Parameters.
If TRUEAPI=OPEN is specified, the first CA IDMS call in each task causes a switch to an open TCB. If the application program is defined as threadsafe, the interface continues to execute on that open TCB through its return to the application program.
Non-threadsafe Instructions
A few cases exist where invocation of the CA IDMS interface from an application program causes a non-threadsafe instruction to be issued. If the application program is defined as THREADSAFE, but not OPENAPI, the interface continues to execute on the QR TCB through return to the application program. If the application program is defined as OPENAPI, CICS switches to the QR TCB during execution of the non-threadsafe instruction and back to the open TCB after completion of the instruction. The interface continues to run on the open TCB through return to the application program.
The following cases can cause a non-threadsafe instruction to be issued:
The UCF Front-end program does not violate any threadsafe rules and can be declared as a THREADSAFE or OPENAPI program. It does, however, issue various non-threadsafe commands, such as terminal I/O commands. Therefore, for best performance, it should be defined with CONCURRENCY(QUASIRENTRANT).
The distributed processing program created with the #UDASCIC macro rarely issues a non-threadsafe command and is a good candidate to declare as a THREADSAFE or OPENAPI program. However, this program does issue a non-threadsafe command when a 1473 Error-Status is received from the CA IDMS interface because of a MAXERUS condition on the CA IDMS Central Version. In this case, the program waits by continuing to issue EXEC CICS DELAY INTERVAL(1) commands until the condition is alleviated or 100 attempts have been made.
The CICS Abort Session Program is created by compiling the #UCFCICZ program and can be declared as a THREADSAFE and OPENAPI program.
The #UCFCICZ macro generates some code that is not compliant with the recommended usage with CICS Transaction Server. This code can cause problems with applications that are associated with a bridge facility. To provide compatibility with previous methods of calling #UCFCICZ from CICS error programs, two new parameters are added to the #UCFCICZ macro: PASSVAL and BRIDGE. To prevent the #UCFCICZ macro from issuing non-threadsafe commands, we recommend that you compile it with the PASSVAL=TERMID parameter.
Note: For more information, see CICS Abort Session Program.
The #UCFCICZ macro is enhanced to provide compatibility with previous methods of calling #UCFCICZ from CICS error programs with two new parameters: PASSVAL and BRIDGE.
The #UCFCICZ macro can be assembled to create an abort program to request UCF to abort the session for any terminal that disconnects or goes out of service. You can call the abort program by any combination of the following methods:
By using #UCFCICZ, you can assure the timely release of back-end resources when a front-end abort occurs. You can also prevent the following scenario from occurring:
A user signs onto CICS through a bridge facility or onto a VTAM terminal through a multisession manager. During a terminal-read request from UCF, the user loses the connection or terminates the CICS session from the multisession manager. A second user simultaneously connects and is assigned to the same terminal identifier. The second user invokes the UCF front-end program and is placed in the middle of the session started by the first user.
Syntax
►►─── #UCFCICZ ───────────────────────────────────────────────────────────────► ►─── BRIDGE= ─┬─ YES ──┬─────────────────────────────────────────────────────► └─ NO ◄──┘ ►─── PASSVAL= ─┬─ TERMID ───┬────────────────────────────────────────────────► └─ TCTADDR ◄─┘ ►─── . . . ──────────────────────────────────────────────────────────────────►
Parameters
Specifies whether the module generated by this #UCFCICZ macro will be called from a program invoked by the bridge facility exit point XFAINTU. If NO is specified, the UCF abort session program assumes that the aborted session is associated with a permanent terminal. If UCFCICS had modified the UCTRANST value associated with the terminal, the UCF abort session program attempts to restore the original UCTRANST value. Therefore, this parameter has no effect if the associated UCFCICS macro specifies UCTRAN=TCT. The default is NO.
Specifies the format and value of the COMMAREA parameter that is passed to the UCF abort session program. PASSVAL=TCTADDR indicates that the COMMAREA contains a fullword address pointing to the Terminal Control table. PASSVAL=TERMID indicates that the COMMAREA contains the 4-byte identifier of the terminal or bridge facility associated with the aborted session.
How to Use the UCF CICS Abort Session Program
One or two UCF CICS abort sessions are needed for each UCFCICS program created with a #UCFUFT macro that specifies the corresponding NTID. One program is needed for persistent terminals. A separate one may be needed for sessions associated with a bridge facility. A single program can be used if both the following conditions are true:
Note: The default is PASSVAL=TCTADDR for compatibility with previous site-created versions of DFHZNEP or DFHTEP.
For each UCF CICS abort session program you create, perform the following steps:
DEFINE PROGRAM(ucfcicz)
GROUP(groupnam) LANGUAGE(ASSEMBLER) CEDF(NO)
EXECKEY(CICS)
Modify DFHTEP/DFHZNEP/XFAINTU to link to UCFCICZ
Modify the error programs or bridge facility tidy up program or both to link to the appropriate UCF session abort programs.
Note: For more information about DFHTEP, DFHZNEP, and XFAINTU,refer to the CICS system documentation.
The following examples illustrate one approach to the modification of error and tidy up programs.
For DFHTEP and DFHZNEP, insert the instructions immediately before the DFHTEP/DFHZNEP exit. The logic states that if the error action codes indicate that the application task (if any) is to abend, a link is made to two UCF CICS session abort programs.
DFHTEP instructions when PASSVAL=TERMID
The following statements add instructions to DFHTEP when the #UCFCICZ macro specifies PASSVAL=TERMID:
TM TCTLEECB+1,X'04' ABEND TASK?
BZ NOCICZ NO
LA 10,TCTLEPTE POINTER TO TCTTE
L 10,0(,10) TCTTETI
EXEC CICS LINK PROGRAM('UCFCICZ1')
COMMAREA( 0(10) )
LENGTH( 4).
EXEC CICS LINK PROGRAM('UCFCICZ2')
COMMAREA( 0(10) )
LENGTH( 4).
NOCICZ DS 0H
DFHTEP instructions when PASSVAL=TCTADDR
The following statements add instructions to DFHTEP when the #UCFCICZ macro specifies PASSVAL=TCTADDR. This method is provided for compatibility with earlier versions. PASSVAL=TERMID is recommended.
TM TCTLEECB+1,X'04' ABEND TASK?
BZ NOCICZ NO
LA 10,TCTLEPTE POINTER TO TCTTE
EXEC CICS LINK PROGRAM('UCFCICZ1')
COMMAREA( 0(10) )
LENGTH( 4).
EXEC CICS LINK PROGRAM('UCFCICZ2')
COMMAREA( 0(10) )
LENGTH( 4).
NOCICZ DS 0H
DFHZNEP instructions when PASSVAL=TERMID
The following statements add instructions to DFHZNEP when the #UCFCICZ macro specifies PASSVAL=TERMID:
TM TWAROPT2,TWAOAT ABEND TASK?
BZ NOCICZ NO
L 7,TWATCTA
EXEC CICS LINK PROGRAM('UCFCICZ1')
COMMAREA(0(7))
LENGTH( 4).
*
EXEC CICS LINK PROGRAM('UCFCICZ2')
COMMAREA(0(7))
LENGTH( 4).
NOCICZ DS 0H
DFHZNEP instructions when PASSVAL=TCTADDR
The following statements add instructions to DFHZNEP when the #UCFCICZ macro specifies PASSVAL=TCTADDR. This method is provided for compatibility with earlier versions. PASSVAL=TERMID is recommended.
TM TWAROPT2,TWAOAT ABEND TASK?
BZ NOCICZ NO
EXEC CICS LINK PROGRAM('UCFCICZ1')
COMMAREA(TWATCTA)
LENGTH( 4).
*
EXEC CICS LINK PROGRAM('UCFCICZ2')
COMMAREA(TWATCTA)
LENGTH( 4).
NOCICZ DS 0H
XFAINTU instructions when UEPFAREQ=UEPFATU
The following statements illustrate how to modify XFAINTU. The code should be executed only if UEPFAREQ contains the value UEPFATU on entry to XFAINTU.
EXEC CICS LINK PROGRAM('UCFCICZ1')
COMMAREA(UEPFANAM)
LENGTH( 4).
*
EXEC CICS LINK PROGRAM('UCFCICZ2')
COMMAREA(UEPFANAM)
LENGTH( 4).
IDMSRSYN is threadsafe, but because it issues non-threadsafe commands, it should not be defined as OPENAPI.
This section describes the new and enhanced CICSOPT parameters.
Syntax
►►──── CICSOPT ─ . . . ───────────────────────────────────────────────────────► ►─┬───────────────────────────┬──────────────────────────────────────────────► └─ ,DEBUG= ─ ( ┬─ YES ─┬ ) ─┘ ├─ NO ◄─┤ └─ QTS ─┘ ►─┬────────────────────────────────────────┬─────────────────────────────────► └─ ,DBUGDCT= ( ┬─ DBUG ◄────────────┬ ) ─┘ └─ destination-name ─┘ ►─┬────────────────────────────┬─────────────────────────────────────────────► └─ ,TRUEAPI= ( ┬─ CICS ─┬ ) ─┘ └─ OPEN ─┘
Parameters
Specifies whether IDMSINTC produces extra debugging information about internal processing.
Specifies that IDMSINTC produces extra information. This information is written using WRITEQ TD to the destination specified on the DBUGDCT parameter.
Specifies that IDMSINTC does not produce debugging information. This is the default. You should always use DEBUG=NO unless otherwise requested by CA Technical Support to resolve a system problem.
Specifies that IDMSINTC produces extra information. This information is written using WRITEQ TS to the queue specified on the DBUGDCT parameter.
Identifies the CICS transient data or temporary storage destination to use as the target for error messages produced if DEBUG=YES or DEBUG=QTS is specified.
The default destination-name is DBUG. Use another destination if you want to route diagnostic messages to another CICS destination. If DEBUG=YES is specified, the DCT entry should be defined with a variable length record of at least 136 characters. We recommend that you use the values provided in source library member CICSCSD2.
Specifies whether to enable the IDMS TRUE exit with the OPENAPI attribute.
Specifies to enable the exit with the THREADSAFE attribute.
Specifies to enable the exit with the THREADSAFE and OPENAPI attributes.
More Information
For more information about the CICSOPT macro, see IDMSINTC in the "TP-Monitor Considerations" chapter in the CA IDMS System Operations Guide.
A new FAST parameter on the FORMAT JOURNAL utility statement provides a method of quickly reformatting already existing and formatted journal files rather than completely reinitializing entire journal files.
Syntax
►►─── FORMAT ─────────────────────────────────────────────────────────────────► ┌─────────────────────────────────────┐ ►─ JOURNAL ─┬─ journal-file-name ─┬▼─┬──────────────────────────────────┬┴─►◄ └─ ALL ───────────────┘ ├─ MAX AREA nnnn ──────────────────┤ ├┬──────┬─ STORAGE ─┬──────┬─ nnn ─┤ │└ DATA ┘ └ SIZE ┘ │ └─ FAST ───────────────────────────┘
Parameters
Formats only the journal header blocks of already existing and formatted journal files. If MAX AREA is specified, the number of JHDA entries are recalculated and the number formatted may change. If the STORAGE clause is specified, the number of JHD2 entries are recalculated and the number formatted may change.
More Information
For more information about the FORMAT utility statement, see the CA IDMS Utilities Guide.
CA IDMS is enhanced to allow database procedures, SQL-invoked routines, and TCP/IP generic listener programs to execute in system mode if they are written in COBOL or PL/I and compiled with an LE-compliant compiler.
Note: The CA IDMS stack usage increases when the system is extended with applications that run in system mode. You might need to increase the system generation STACKSIZE parameter, depending on its current value. These applications include numbered exits, database procedures, SQL-invoked routines (defined with SYSTEM MODE), and TCP/IP generic listeners (defined with MODE IS SYSTEM).
In prior releases, a database procedure written in COBOL or PL/I had to be invoked using a stub module as described in Coding Database Procedures in the "Writing Database Procedures" chapter in the CA IDMS Database Administration Guide. This requirement disappears if the database procedure is compiled with an LE-compliant COBOL or PL/I compiler. If no stub module is used and standard program linking is done, the database procedure executes in system mode, resulting in better performance.
Note: For more information about database procedures, see the CA IDMS Database Administration Guide.
To execute an SQL-invoked routine in system mode, define it with the SYSTEM MODE attribute.
Note: For more information about SQL-invoked routines, see the CA IDMS SQL Reference Guide.
To execute a TCP/IP generic listener program in system mode, define it with the SYSTEM MODE attribute.
Note: For more information about how to define a TCP/IP generic listener, see the CA IDMS System Generation Guide.
With this release, more IDMS structures and programs can reside in XA storage. This increases XA storage requirements, but it frees up 24-bit storage for other uses. For example, the amount of file related storage that must reside below the line has been reduced. This will benefit 24-bit storage constrained systems that access a large number of database files. The need for below the line storage is further reduced by enabling IDMSDBIO to reside in XA storage.
The IDMSINTC interface is also enhanced to allocate RCA and additional IDMS control blocks above the line.
CA IDMS is enhanced to exploit zIIP processors on the z9 series and above for the z/OS operating system. This feature enables offloading computing cycles to zIIPs, thereby increasing overall CPU throughput at lower operational costs. The zIIP feature is not dependent on any other CA IDMS feature, including multitasking.
z/OS software feature HBB7709 is required to use the zIIP feature.
The default mode of operation is to not use zIIP processors unless specifically requested at runtime. A new ZIIP startup parameter is available to enable or disable the use of these processors by CA IDMS. To facilitate analysis of the potential benefit, the feature can be enabled even if no zIIP processors are available. For more information, see New Startup Parameters.
If this feature is enabled, CA IDMS uses Workload Manager to create a dependent enclave for each OS task capable of servicing work type IDMS (see DCMT DISPLAY SUBTASK in the CA IDMS System Tasks and Operator Commands Guide.) It then schedules a separate preemptable SRB into each such enclave.
The following sections discuss topics related to zIIP exploitation:
Note: On systems utilizing zIIP processors, CPU time in CA IDMS statistics includes time on the zIIP processor normalized to standard processor speed.
Most CA IDMS system code is eligible to run on a zIIP processor. However, user exits, database procedures, SQL-invoked routines, and application programs are not eligible to run on a zIIP processor. CA IDMS runtime processing ensures that a non-zIIP processor is selected to run non-eligible routines.
To ensure that only eligible modules are selected to be run on a zIIP processor, some load modules must be loaded from one of the following secured locations:
Note: For more information about authorized libraries, the LPA, and the linklist, see the IBM documentation.
The specific rules for load module residence for zIIP processing are as follows:
Modules that consist of non-executable code or code that is never eligible to run on a zIIP processor do not have to come from a secured location. Most modules which are supplied by a client or which are modifiable at a client site are in this category. This category includes the following:
The IDMSDBIO load module can be modified at a client site by linking a DB user exit with it. It is a nucleus module containing executable code, and it must be loaded from a secured location for zIIP eligibility regardless of whether it is modified.
Individual nucleus members in a load library do not have to be authorized and should not be linked with SETCODE AC(1). The startup module (RHDCOMVS or site-linked startup module) must be linked with SETCODE AC(1) if and only if the AUTHREQ parameter is specified for the CA IDMS SVC. For more information about the AUTHREQ parameter, see Generating the SVC for z/OS in the Setting Up Interpartition Communication and the SVC chapter in the CA IDMS System Operations Guide.
Note that not every load library in the CA IDMS startup STEPLIB and CDMSLIB needs to be authorized; only those libraries from which nucleus modules are loaded must be authorized. Appropriate startup error messages are provided to assist in this effort.
To ensure that all nucleus modules are loaded from an authorized library, it is recommended that one of the following actions be taken:
When CA IDMS is used with a batch program, no modules are made zIIP-eligible. There are, however, considerations that arise from the use of an authorized load library. The z/OS operating system enforces certain rules for programs that are loaded from a set of authorized load libraries. In particular, any program that is linked with the RENT attribute cannot be modified at runtime. If this rule is violated, an S0C4 program check occurs. Application programs linked with the CA IDMS interface module will be modified at runtime by Computer Associates. Therefore, the batch STEPLIB concatenation should contain at least one non-authorized load library, or such user programs should be linked without the RENT attribute.
Computer Associates-supplied application programs (such as IDDSDDDL) are linked appropriately in the SMP/E target load library, so no special action is required for these programs.
The DCMT DISPLAY SUBTASK command is enhanced to produce additional output when zIIP support is activated.
The following example illustrates a CA IDMS system running in multitasking mode with zIIP support enabled. The display was obtained on hardware that contained two CPs and no zIIP.
DCMT DISPLAY SUBTASK 0003
*** Display Subtask details *** Name SUBT0002 Number 03 Status BUSY Work type IDMS Count wakeups 80,836,576 Count task dispatches 96,549,679 User mode CPU time 00:00:00.0251 System mode CPU time 00:17:10.3946 CPU effectiveness (%) 27 Count times fast posted 10,451,388 Count times OS posted 00 Count found work pass 1 96,256,979 Count found work pass 2 292,700 Count times POSTEXIT resumed 80,639,015 *** Enclave Info *** zIIP time 00:00:00.0000 zIIP on CP time 00:05:39.9737 CPU effectiveness (%) 41 Count swap attempts 60,356 Count actual swaps 60,336
The following series of examples illustrate a CA IDMS system running in multitasking mode with zIIP support enabled. The displays were obtained on hardware that contained five CPs and one zIIP.
DCMT DISPLAY SUBTASK 0001
*** Display Subtask details *** Name MAINTASK Number 01 Status IDLE Work type IDMS Count wakeups 1,445 Count task dispatches 1,597 User mode CPU time 00:00:00.0000 System mode CPU time 00:00:01.3376 CPU effectiveness (%) 14 Count times fast posted 21 Count times OS posted 00 Count found work pass 1 1,478 Count found work pass 2 119 Count times POSTEXIT resumed 1,445 *** Enclave Info *** zIIP time 00:00:00.0304 zIIP on CP time 00:00:00.0000 CPU effectiveness (%) 173 Count swap attempts 3,397 Count actual swaps 3,397
DCMT DISPLAY SUBTASK 0006
The following example illustrates the additional information provided for the preferred subtask:
*** Display Subtask details *** Name SUBT0005 Number 06 Status BUSY Work type IDMS Count wakeups 11,308,085 Count task dispatches 30,029,342 User mode CPU time 00:00:00.0137 System mode CPU time 00:05:15.0039 CPU effectiveness (%) 57 Count times fast posted 9,261,458 Count times OS posted 00 Count found work pass 1 29,728,572 Count found work pass 2 300,770 Count times POSTEXIT resumed 11,234,399 *** Enclave Info *** zIIP time 00:01:44.4525 zIIP on CP time 00:00:00.1209 CPU effectiveness (%) 113 Count swap attempts 35,029 Count actual swaps 35,008
DISPLAY SUBTASK EFFECTIVENESS
The following example illustrates whether zIIP support is active by subtask. It includes CPU statistics for each subtask and associated SRB, and percentage comparison of CPU effectiveness.
DISPLAY SUBTASK EFFECTIVENESS *** Subtask display *** Subtask Elapsed time Total CPU time % CPU SRB Name TCB SRB TCB SRB TCB SRB -------- -------------- -------------- -------------- -------------- --- --- MAINTASK 00:00:08.7635 00:00:00.0182 00:00:01.3060 00:00:00.0316 14 173 Y SUBT0001 00:00:00.0069 00:00:00.0003 00:00:00.0053 00:00:00.0002 76 66 Y SUBT0002 00:00:00.0067 00:00:00.3827 00:00:00.0060 00:00:00.4328 89 113 Y SUBT0003 00:00:00.0117 00:00:18.2373 00:00:00.0117 00:00:20.5911 100 112 Y SUBT0004 00:00:00.1378 00:01:16.6358 00:00:00.0723 00:01:26.6610 52 113 Y SUBT0005 00:00:00.2610 00:04:38.2176 00:00:00.1506 00:05:14.8743 57 113 Y -------- -------------- -------------- -------------- -------------- --- --- Totals 00:00:09.1876 00:06:13.4919 00:00:01.5519 00:07:02.5910 16 113
DCMT DISPLAY SUBTASK 000n
(z/OS systems only) Displays the following CPU statistics under Enclave Info when zIIP support is active:
|
Field |
Value |
|---|---|
|
zIIP time |
The CPU time consumed while physically executing on a zIIP processor. |
|
zIIP on CP time |
The CPU time used on a CP, such as the time of scheduling the zIIP processor use and contention for a zIIP processor. |
|
CPU effectiveness |
The percentage comparison of CPU time to wall-clock time while the subtask was executing. A subtask is considered to be executing if it has not been put into a WAIT state by the CA IDMS system. An executing subtask can lose effective CPU time due to paging or to other tasks being given a higher priority by the operating system. Reported CPU effectiveness can exceed 100% due to pro-rating techniques used by the operating system to compensate for relative speed differences between the CP and zIIP. |
DCMT DISPLAY SUBTASK EFFECTIVENESS
Displays whether zIIP support is active by subtask and displays the following fields for each TCB and SRB:
|
Field |
Value |
|---|---|
|
Name |
The name of each subtask. |
|
Elapsed time |
The length of time the subtask or SRB has been running. |
|
Total CPU time |
The amount of CPU time the subtask or SRB has used. |
|
CPU effectiveness |
The percentage comparison of CPU time to wall-clock time while the subtask was executing. A subtask is considered to be executing if it has not been put into a WAIT state by the CA IDMS system. An executing subtask can lose effective CPU time due to paging or to other tasks being given a higher priority by the operating system. Reported CPU effectiveness can exceed 100% due to pro-rating techniques used by the operating system to compensate for relative speed differences between the CP and zIIP. |
Efficiency of the reorganized database
The database resulting from a REORG operation should be as efficient as one reorganized through UNLOAD and RELOAD even though the two may not be identical.
A database processed by RELOAD is loaded back to front. CALC and VIA records that overflow are usually written to pages that have already been loaded and have room. A database processed by REORG is loaded from front to back. CALC and VIA records that overflow are saved in a memory cache so that they do not displace records targeting later pages. If the cache is not large enough, the records are written to an overflow file and loaded in a later step.
The resulting databases should be similar in terms of the number of records that are stored on their intended target page and the number of records that overflow, but the two databases will not be exactly the same.
You can use the IDMSDBAN utility to obtain a report of the number of page changes needed to traverse all occurrences of each CALC and VIA set. By executing this utility before and after reorganization, you can determine the effect that REORG has had on these statistics and therefore the relative efficiency of the resulting database.
DCMT VARY PERMANENT considerations
If you run the REORG utility to change an area's low page number and Change Tracking is not used, it is recommended that you remove any permanent status on the affected area before making the new DMCL active within the CV.
When Change Tracking is not used, the PERMANENT feature is implemented by carrying the area's low page number in the journals across cycles of the CV. Changing an area's low-page prohibits future cycles of the CV from properly identifying the area once the new page range is implemented.
If a DCMT VARY SEGMENT/AREA PERMANENT command is still in effect when the new page range is implemented, the area's usage-mode at startup is determined by the value specified in the DMCL. The entry in the journals for the old area's page range remains until the next format of the journals.
The journal entry for the old starting page can be removed without formatting the journal by doing a non-permanent DCMT VARY AREA command against the area prior to changing the DMCL definition in the CV.
Work file creation
REORG can create work files dynamically, or you can manually create them prior to beginning the UNLOAD and/or RELOAD phases of REORG execution. Regardless of how the files are created, it is a good idea to halt execution after setup to determine what work files are needed by examining the report produced by REORG.
If using dynamic work file creation, you must specify the attributes of the work files using one or more CREATE DSMODEL statements. REORG creates the files as directed by the CREATE WORKFILE clause or at the time they are first accessed. Dynamically created work files, other than DBKEYS files, are deleted automatically during the cleanup phase.
If you want to use REORG's size estimates to create a file, code a DSMODEL without a primary SPACE allocation. You can code a SPACE parameter with just a unit type (TRK, CYL, or blksize) and no value for primary allocation.
You must code a primary space allocation value or delay creating work files until estimates are available. This means, for example, that you cannot direct REORG to create RELOAD work files during the setup phase unless the DSMODEL contains a primary allocation value.
If you code a zero primary space allocation value and a non-zero secondary value, the secondary value is replaced by a value derived from the estimated primary value. See "Considerations for running REORG on z/VSE".
Work file deletion
By default during the cleanup phase, REORG deletes all work files created during the current operation other than DBKEYS files. It deletes only those files for which a matching data set model was specified at setup or when the file was created. If a matching model is detected, REORG attempts to dynamically allocate the file, thereby determining its data set name which may be derived from the model or overridden by a DD statement in the JCL. Regardless of how the data set name is determined, if the file is created during the execution of a REORG statement, it is deleted during the cleanup phase of the operation unless the file is subsequently overridden with a different data set name in some later job. You can determine which files cleanup will delete by examining the work file summary sections of the REORG Status Report.
Should it be necessary to restart a REORG operation from the beginning, you should first execute a REORG statement that specifies CLEANUP in order to delete any work files created by the interrupted operation. If you do not do this, none of the work files created during the first operation execution will be deleted by REORG even if they are reused during the second execution.
If REORG is restarted without first cleaning up the old work files, you can still direct REORG to delete them using one of the following methods:
Sizing work files
The simplest way to size work files is to let REORG do it for you. REORG automatically estimates the size of all files after making a pass of the database and gathering statistics. This occurs by default when the data is unloaded. While this does not require an extra pass of the data, the estimates that are generated can only be used for allocating RELOAD work files because the UNLOAD files have already been created and used.
To use REORG-generated estimates for allocating UNLOAD work files, use the ESTIMATE WORKFILE SIZES option. This directs REORG to make a preliminary pass of the data without opening or writing to any work files. The generated file estimates are stored in the control file and can be used to allocate both UNLOAD and RELOAD work files when the REORG operation is resumed.
For REORG to more accurately estimate the size of overflow files, it may be necessary to specify an OVERFLOW PERCENT parameter. REORG assumes that 10% of the records to be stored in the database will overflow. If this assumption is not valid for a particular database, you may need to specify a different overflow percent value so that REORG can generate better estimates for the size of overflow files.
While REORG attempts to accurately estimate the size needed for work files, it may not always be able to do so. In certain cases, it may be necessary to manually estimate the size needed for one or more work files.
Estimating the size needed for work files is difficult for two reasons: many classes of files contain different types of records, and the number of records written to each file within a class varies depending on how REORG chooses to divide the page ranges into slices. Consequently, there are no simple formulas that can be used to estimate work file sizes. There are however, some techniques that can be used to facilitate file sizing and allocation.
In planning for a reorganization, do one or more trial runs to determine the actual file sizes needed for a given n-WAY value. This can be done during a non-critical time against a copy of the source database. This is the easiest way to obtain accurate size estimates. If it is impractical to do a trial reorganization on a full copy of the database, do it on a reasonably-sized sample that is representative of the original and then scale up the work file sizes proportionately. Be sure that the sample database is large enough relative to the n-WAY parameter so that the slicing algorithm does not reduce the number of slices due to their small size. Size estimates determined using a sample database are not as accurate as those determined using a full copy of the database and so should be increased to account for this.
The following is a list of additional techniques that may prove helpful in allocating work files:
Under z/VSE it is recommended to not specify a primary space value, and let REORG calculate one. If this value is not large enough, or will not fit on the specified volume, a DLBL and EXTENT for the individual file should be manually coded to override the generated label.
For more information about the DCMT DISPLAY SUBTASK command, see the CA IDMS System Tasks and Operator Commands Guide.
The OPERATING SYSTEM display of the DCPROFIL system task is enhanced to display whether the CA IDMS system is eligible to run on a zIIP processor.
Example
TAPE: volser NUMBER OF SCTS: 0008 TOOLS TAPE: volser SYSTEM TRACE: YES OPERATING SYSTEM: z/OS ZIIP=N CWA SIZE: 0000000504 DMCL TABLE: CVDMCL PRIMARY STORAGE SCRATCH HWM 0000000176 PROTECT KEY: 04 SIZE OF XA ACTIVE TRANSACTION STORAGE AREA: 0049381376 COUNT: 0009 QUEUE AREA LOW PAGE: 0007999951 HIGH PAGE: 0008001950 DC VERSION ID: 0210 SVC NUMBER: 173 NUMBER OF USER GETMAIN SUBPOOL: 001 TRACE BUFFERS: 0250 PAGE 00001 - NEXT PAGE:
More Information
For more information about the DCPROFIL system task, see the CA IDMS System Tasks and Operator Commands Guide.
Evaluation of the zIIP feature requires neither zIIP processors nor even hardware that is capable of supporting zIIP processors.
Several easy steps are used to determine the benefits that can be achieved by using the zIIP feature as follows:
The SRB column from Step 4 is proportional to the number of MIPs of zIIP processing power that will be required to achieve these cost reductions
Examples
The following displays indicate that each run used between 93 and 98 CPU seconds of total normalized CPU. The second run shows that 91.1222 CPU seconds out of a total of 93.5108 CPU seconds were offloaded to an SRB. Approximately one third of this SRB CPU time can be offloaded to a zIIP processor. For this particular application mix, this means that approximately one third of the total CV CPU could be offloaded to zIIP processors.
Since a zIIP processor was present, the actual offloaded CPU can then be confirmed from the JES LOG Step End messages, IEF374I, which, in this case, indicates a total CPU reduction of 31.68 seconds.
Step 2 Output with ZIIP=N
*** Subtask display *** Subtask Elapsed time Total CPU time % CPU SRB Name TCB SRB TCB SRB TCB SRB -------- -------------- -------------- -------------- -------------- --- --- MAINTASK 00:00:14.0505 00:00:00.0000 00:00:02.3699 00:00:00.0000 16 N/A N SUBT0001 00:00:00.0122 00:00:00.0000 00:00:00.0104 00:00:00.0000 85 N/A N SUBT0002 00:00:00.0175 00:00:00.0000 00:00:00.0131 00:00:00.0000 74 N/A N SUBT0003 00:00:00.2348 00:00:00.0000 00:00:00.0398 00:00:00.0000 16 N/A N SUBT0004 00:00:00.2175 00:00:00.0000 00:00:00.0240 00:00:00.0000 11 N/A N SUBT0005 00:01:42.0081 00:00:00.0000 00:01:35.8538 00:00:00.0000 93 N/A N -------- -------------- -------------- -------------- -------------- --- --- Totals 00:01:56.5406 00:00:00.0000 00:01:38.3110 00:00:00.0000 84 N/A
JES LOG Step End Message
IEF374I STEP/DCV /STOP 2008242.0425 CPU 1MIN 39.53SEC SRB 0MIN 11.73SEC VIRT 7840K SYS 552K EXT 56072K SYS 11460K
Step 4 Output with ZIIP=Y
*** Subtask display *** Subtask Elapsed time Total CPU time % CPU SRB Name TCB SRB TCB SRB TCB SRB -------- -------------- -------------- -------------- -------------- --- --- MAINTASK 00:00:12.9116 00:00:00.0434 00:00:02.1387 00:00:00.0525 16 120 Y SUBT0001 00:00:00.0125 00:00:00.0000 00:00:00.0111 00:00:00.0000 88 N/A Y SUBT0002 00:00:00.0118 00:00:00.0002 00:00:00.0103 00:00:00.0000 87 00 Y SUBT0003 00:00:00.1643 00:00:00.0014 00:00:00.0624 00:00:00.0016 37 114 Y SUBT0004 00:00:00.0276 00:00:00.0004 00:00:00.0239 00:00:00.0008 86 200 Y SUBT0005 00:00:00.3849 00:01:17.1037 00:00:00.1422 00:01:31.0673 36 118 Y -------- -------------- -------------- -------------- -------------- --- --- Totals 00:00:13.5127 00:01:17.1491 00:00:02.3886 00:01:31.1222 17 118
JES LOG Step End Message
IEF374I STEP/DCV /STOP 2008242.0400 CPU 1MIN 01.60SEC SRB 0MIN 17.98SEC VIRT 7840K SYS 552K EXT 56080K SYS 11500K
More Information
For more information about the DCMT DISPLAY SUBTASK command, see the CA IDMS System Tasks and Operator Commands Guide.
|
Copyright © 2009 CA.
All rights reserved.
|
|