This chapter describes administrative and operational enhancements.
This section contains the following topics:
Enhanced Diagnostic Information
IDD Display Load Modules by Type
LOCKMON Longterm Lock Display Enhancements
New Message Replacement Operand
Online Print Log (OLP) Usability Enhancements
Considerations for running REORG on z/VSE
Support for Large and Extended Format Files
Forcing a Database File into Input Mode
Miscellaneous changes for z/VSE
The linkable RHDCSDEL enhancement allows a user program to clean up security definitions for logically deleted users by linking to RHDCSDEL. To use this feature, you must write a user program that links to RHDCSDEL.
Note: Securing the SDEL task code does not secure usage of the RHDCSDEL program. If you want to limit the use of RHDCSDEL, that program must be secured.
RHDCSDEL LINK Statement The calling program links to program RHDCSDEL, passing the addresses DICTNAME, RETCODE, and OUTAREA as parameters:
#LINK PGM='RHDCSDEL',PARMS=(DICTNAME,RETCODE,OUTAREA)
Parameters
Specifies the dictionary name of the DDLDML and DDLCAT areas to be scanned for security definitions associated with logically deleted users.
This is an 8-character field, left-justified, and padded with blanks. If DICTNAME is set to blanks, DC/UCF processes the DDLDML and DDLCAT areas of the default dictionary for the system. If DICTNAME is set to CL8'*ALL', all updatable DDLDML and DDLCAT areas in the DMCL are processed.
Specifies a fullword in which RHDCSDEL provides a return code. The possible return codes are as follows:
Specifies processing was successful. The OUTAREA contains informational messages DC048004 and DC048008.
Specifies processing was successful but contains warnings. The possible causes are as follows:
Specifies a processing error. The possible causes are as follows:
Specifies the fatal error, the DMCL module is invalid. The OUTAREA contains error message DC048007.
Specifies an area where RHDCSDEL puts messages. The first fullword of the area must be initialized to the area length, which also includes the first full word. Upon return, the first fullword contains the size of the messages. Each message is in the following format:
AL1(L'message),C'message'
Note: The RETCODE is set to 04 if the output area is too small, unless a more severe error occurred.
More Information
The DCMT DISPLAY SEGMENT command is enhanced to include the number of areas in the segment in the output display.
Syntax
►►─── DCMT Display SEGments ───────────────────────────────────────►◄
Example
The following example shows the number of areas for each of the segments displayed.
DCMT DISPLAY SEGMENTS
Segment-Name Schema-Name Type #areas Pg-Grp Radix Datetime-stamp AAA Network 1 25 8 2005-03-29-10.07.59 DAR SQL 3 0 8 2005-03-29-10.07.59 DBCR Network 2 15 8 2005-03-29-10.07.59 EMPDEMO Network 3 0 8 2005-03-29-10.07.59 ETOT Network 1 32 8 2005-03-29-10.07.59 KJM Network 30 35 8 2005-03-29-10.07.59 LRD Network 1 30 8 2005-03-29-10.07.59 QADICT Network 2 0 8 2005-03-29-10.07.59 QAMISC Network 1 0 8 2005-03-29-10.07.59 R120DICT Network 2 0 8 2005-03-29-10.07.59 SYSDAR SQL 3 0 8 2005-03-29-10.07.59 SYSDEF Network 5 0 8 2005-03-29-10.07.59 SYSDICT Network 2 0 8 2005-03-29-10.07.59 SYSLOCAL Network 1 1 8 2005-03-29-10.07.59 SYSMSG Network 1 0 8 2005-03-29-10.07.59 SYSSQL SQL 3 0 8 2005-03-29-10.07.59 SYSUSER Network 1 0 8 2005-03-29-10.07.59 USERDB SQL 3 0 8 2005-03-29-10.07.59 USERDB2 SQL 3 2 8 2005-03-29-10.07.59 VSAMT Network 6 0 8 2005-03-29-10.07.59 V74 ENTER NEXT TASK CODE: CA IDMS release nn.n tape volser node SYSTEM74
More Information
For more information about the DCMT DISPLAY SEGMENT command, see the CA IDMS System Tasks and Operator Commands Guide.
This section describes a number of improvements in the detection and reporting of exceptional conditions in order to facilitate problem diagnosis and correction.
The 32 bytes of data at the PSW (16 bytes before and 16 bytes after) is included in the #ACEDS (TCE ACE) and is displayed for system and task snaps when the abend control element (ACE) control block is formatted and snapped, and the PSW address is a valid storage address.
A GETMAIN command can fail at startup when the system is unable to acquire storage for the database buffers from operating system storage. A new message is issued indicating that the database buffers are being allocated from IDMS storage pools. The message has the following format:
DC205029 Unable to allocate buffer in OPSYS storage. Trying IDMS storage pools.
A new message is issued identifying the transaction that is filling the journal files without issuing commits. This message displays the transaction's program name, subschema name, and the number of BFOR image bytes written on behalf of the transaction. The message has the following format:
DC205030 LID=<Local-Transaction-id> PROG=<Program-Name> SUBS=<Subschema-Name> BFOR=<BFOR-Journal-Space-Usage>
It displays when the existing messages are displayed:
DC205003 Disk Journal is FULL. Submit ARCHIVE JOURNAL for <journal-file-name>
DC205024 Journal Write waiting on full Journal
Note: For more information, see the CA IDMS Messages and Codes Guide.
The IDMSINTC interface is enhanced to issue a new ABNDK007 error message when the CWADISP value is greater than the CWASIZE value. Previously, unpredictable results occurred.
The IDMSINTC interface is enhanced to issue a new ABNDK214 error message when the number of active run units exceeds the value specified in the CICSOPTS USERCNT parameter. Previously, an AKEA abend occurred.
A new warning message is issued at startup when the number of journal area entries is within 10% of the maximum number of areas that the JHDA headers can accommodate. This message identifies the number of used area entries and the number of available area entries that the journal can hold. The message has the following format:
DC205031 Warning - <number of area entries in JHDAs> area entries in journal header nearing max of <total entries>
The following messages are now issued in a data sharing environment to track certain events:
For improved VTAM error reporting, the VTAM feedback code and return code have been added to DC error message DC084109 as follows:
DC084109 PTERM <pterm-id> ON LINE <line-id> : SIMLOGON TO VTAM NODE <vtam-node-name> MODEENT <vtam-modeent-name> FAILED, FDBK <vtam-feedback> SENSE: <vtam-sense-code>
The additional data is returned for all VTAM-SNA lines that fail to open, resulting in the DC084109 error message.
Note: For more information, see the CA IDMS Messages and Codes Guide.
Messages relating to XCF/XES macro requests issued by CA IDMS are now written to the DC log after it has been opened, in addition to being written to the console/system log.
The DC215999 message has the following format:
DC215999 <macro> RC=<retcode> Reason=<reason> name=<sname>
This message indicates that the DC/UCF system has issued the macro request identified in the message text to the IBM Parallel Sysplex system. The IBM Parallel Sysplex system processes the request and returns a return code and reason code for the named structure also identified in the message text.
Note: For more information, see the CA IDMS Messages and Codes Guide.
An external identity represents the end user of an application that uses a generic internal user id to sign on to CA IDMS. The actual end user id is commonly stored as a value but not used to authenticate access to the database. This technique is often used in web applications. The CA IDMS Server r16.1 JDBC driver supports an external identity audit feature that records the external identity in the journal when a database record is updated on the entry CV.
CA IDMS r17 extends this feature by setting the external identity as a session profile attribute and broadcasting it on remote database connections. This makes the external identity visible to customer applications and ensures that it can be audited on all CVs that take part in a transaction.
Note: The external identity is not propagated to or from an r16 CV. All CV's must be r17 or later to successfully audit external identities on remote databases.
The external identity can be set in the following ways:
Journal reports are used to audit external user identities.
The external user identity is set in the EXTIDENT session profile attribute. This attribute is treated as if it were a built-in system profile attribute. EXTIDENT is now a reserved attribute name.
As a profile attribute, the value of EXTIDENT can be established through a signon or user profile or interactively by issuing a DCUF SET command. However, it is most usefully established programmatically in one of the ways described below.
Usage
Java Applications
The session attribute is set by the JDBC driver for Java applications that use CA IDMS Server. This is described in the CA IDMS Server r16.1 User Guide.
CA IDMS/DC Applications
CA IDMS/DC applications can use the IDMSINO1 SETPROF function to set the session profile attribute and can use the IDMSINO1 GETPROF function to get the current value of the attribute.
When this attribute is set in the current user session profile it is also sent to all remote systems that are associated with the user session. The return code is set to the highest error encountered. A nonzero return code indicates that the external identity may not have been set on one or more CVs.
The DBA can disable this feature, either at the system or user level, by setting the EXTIDENT attribute to blank and specifying that it cannot be overridden.
SQL Applications
SQL applications can use the PROFILE scalar function to retrieve the current value of the attribute. SQL called procedures can use the IDMSINO1 GETPROF function to get the current value of the attribute.
The following journal reports are used to audit external user identities.
The area of the report for the BGIN record includes the external user identity. If present, it is included on the line that reports the user id.
---------EVENT--------- --------IDENT-------- ---QUIESCE LVL/USER/EXT ID-- . . . . TIME TYPE DURATION RUN UNIT PROGRAM . . . hh:mm:ss BGIN 1633 JAVAPROG ONL X . . . <user id> <external id>
JREPORT 000 supports a REC card for the external identity field to allow the use the external identity as selection criteria when running existing JREPORTs.
JREPORT 008 displays the external identity information when reporting the BGIN record. The external id heading and value are only printed when available.
BGIN TECHDC30 12/27/05 20.07.13.56 529276 170604 ... ... . USER ID EXTERNAL ID USER01 USER2007
JREPORT 010 lists the user id, external identity, date, time, program name, and run unit id. This information provides a customer with enough information to run 'JREPORT 008' with SELECT criteria to provide details on all activity involving a particular user.
REPORT NO. 10 IDMS JOURNAL REPORTS R16.0 JREPORT 010 EXTERNAL USER IDENTITY JOURNAL REPORT USER EXT TRANSACT PROGRAM LOCAL LOCAL ID ID IDX NAME DATE TIME USER01 USER2006 5 IDMSJDBC 12/22/05 14.19.29.66 USER ID NOT CAPTURED EXT ID NOT CAPTURED 6 IDMSDDDL 12/22/05 14.19.29.67 USER01 EXT ID NOT CAPTURED 7 RHDCRUAL 12/22/05 14.19.29.68 NO USER SIGNON 8 RHDCRUAL 12/22/05 14.19.29.69 USER01 USER123 9 JAVAPROG 12/22/05 14.19.29.70 C750009 RECORDS WRITTEN FOR REPORT 10 -- 8
IDD is enhanced to be able to do a DISPLAY ALL LOAD MODULES WHERE TYPE IS 'load-module-type'. This displays only the load modules for the specified type.
Example
The following example shows only the load modules for load module type SUBSCHEMA:
DISPLAY ALL LOAD MODULES WHERE TYPE IS 'SUBSCHEMA' . *+ DISPLAY LOAD MODULE NAME IS KJMTEST3 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS KJMTEST VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS QA120SS2 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS QA120SS1 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS EMPSS01 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS SS1 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS VSUB01 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS DBCRSSC1 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS TOM2 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS TOM VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS RXMLRF05 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS RXMLRF04 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS EMPL1 VERSION IS 1 . *+ DISPLAY LOAD MODULE NAME IS JPD VERSION IS 1 . 000003*+ I DC601157 NO MORE ENTITY OCCURRENCES FOUND
Note: For more information, see the CA IDMS IDD DDDL Reference Guide.
Index tuning is enhanced in the following areas:
TUNE INDEX is also enhanced in its ability to tune indexes while they remain available to online applications.
The PRINT INDEX utility reports on the structure of an indexed set. Using the PRINT INDEX utility, you can review:
Authorization
|
To |
You Need This Privilege |
On |
|---|---|---|
|
Report on an index |
DBAREAD |
The area containing the index and the area(s) containing records referenced by the index |
Syntax
►►─── PRINT INDEX ─┬─ set-name set-specifications ─┬─────────────────────────► └─ SR8 occurrence-key ──────────┘ ►────┬────────────────────────────────┬──┬──────────────┬───────────────────►◄ ├─ ONLY ◄────────────────────────┤ ├─ DECIMAL ◄───┤ ├─ TREE ─────────────────────────┤ ├─ HEX ────────┤ ├─ FULL ─────────────────────────┤ └─ TERSE ──────┘ ├─ LEG ──────────────────────────┤ ├─ SUMMARY ───┬────────────┬─────┤ │ ├─ ONLY ◄────┤ │ │ └─ DETAILED ─┘ │ └─┬─ NEXT ──┬─┬────────────────┬─┘ ├─ PRIOR ─┤ └─ level-number ─┘ └─ LVL ───┘
Expansion of set-specifications
►►─── SEGMENT segment-name ───────────────────────────────────────────────────► ►─┬─ USING subschema-name ─┬─────────────────────────────┬─────────────────┬─►◄ │ ├─ OWNER ──┬─ occurrence-key ─┘ │ │ └─ MEMBER ─┘ │ │ │ └─ TABLE schema-name.table-id ─┬────────────────────────────────────────┬┘ ├─ REFERENCED ──┬─ ROWID occurrence-key ─┘ └─ REFERENCING ─┘
Expansion of occurrence-key
►►─┬───────────────┬─┬─ X'hex-database-key'──┬────────────────────────────────►◄ └─ page-group: ─┘ └─ page-num:line-num ───┘
Parameters
Requests a summary report for the target index. A summary report consists of three parts:
A summary report on a system-owned index contains parts 1 and 2.
A summary report on a user-owned index always contains parts 1 and 3. Part 2 is included only in a detailed summary report. :parml
Requests a summary report with parts 1 and 3 for the target user-owned index. This parameter is ignored for a system-owned index. ONLY is the default.
Requests a summary report with parts 1, 2, and 3 for the target user-owned index. This parameter is ignored for a system-owned index.
For the named table, directs the PRINT INDEX utility to report on the index occurrence whose owner is the referenced row identified by occurrence-key.
For the named table, directs the PRINT INDEX utility to report on the index occurrence containing the row ID of the referencing row identified by occurrence-key.
How to submit the PRINT INDEX statement
You submit the PRINT INDEX statement by using the batch command facility or the online command facility.
When to use PRINT INDEX
The PRINT INDEX utility can help you determine whether an index needs to be rebuilt. For example, you should consider rebuilding an index when the PRINT INDEX utility report on the index indicates one of the following:
An index can be rebuilt using MAINTAIN INDEX or TUNE INDEX. For more information about index rebuilding and indexing in general, see the CA IDMS Database Administration Guide.
Note: The output of PRINT INDEX without the SUMMARY parameter is proportional to the number of index members that are being reported. If PRINT INDEX is run online or in batch through CV, the output is buffered in scratch. If the scratch area cannot contain all the output, PRINT INDEX fails with a task abend.
Hexadecimal display of symbolic keys
The HEX parameter of the SET/SR8 statement is useful when the symbolic key for the index is a non-displayable data type, such as binary or packed.
Printing a summary report of an index
The following example directs the PRINT utility to report on the DEPT_EMPL index using the SUMMARY option.
PRINT INDEX DEPT_EMPL SEGMENT USERDB TABLE DEMO.DEPT SUMMARY;
Printing a REFERENCING ROWID summary report of an index
The following example directs the PRINT utility to report on the index occurrence containing the row ID of the referencing row identified by X'0013D401'.
PRINT INDEX DEPT_EMPL SEGMENT USERDB TABLE DEMO.DEPT REFERENCING ROWID X'0013D401' SUMMARY;
Printing a summary report of an index
The report below illustrates the use of the SUMMARY option to request the printing of a user-owned index.
PRINT INDEX DEPT_EMPL SEGMENT USERDB TABLE DEMO.DEPT SUMMARY; SET Name: DEPT_EMPL IBC 3 Displacement 2 Sort option SORTED SYM ASC Key length 10 Duplicates FIRST Compression No OWNER: DEPT AREA USERDB.ORG_AREA Low page 5051 Page size 1024 High page 5100 MEMBER: EMPL Set membership Optional Manual Located VIA index No Index is Linked AREA USERDB.EMP_AREA Low page 5001 Page size 1024 High page 5050 Index overview Nr of owner occurrences 5 Nr of empty owners 1 20.0% Nr of displaced top level SR8s 1 20.0% Nr of SR8s: Total 62 Average 12.4 Highest 59 Owner X'0013D401' Min. nr of SR8s: Total 49 Average 9.8 Highest 46 Owner X'0013D401' Nr of levels: Average 1.6 Highest 5 Owner X'0013D401' Min. nr of levels: Average 1.6 Highest 5 Owner X'0013D401' Nr of pages: Average 2.2 Highest 8 Owner X'0013D401' Min. nr of pages: Average 1.8 Highest 6 Owner X'0013D401' Nr of occurrences with orphans 1 Nr of Orphans: Total 42 27.8% Highest 42 Owner X'0013D401' Total size of all SR8s 5784 Size of largest SR8 104 Distribution of Index Levels ....+....20...+....40...+....60...+....80...+.... 6+| 0 0.0% 5 |********** 1 20.0% 4 | 0 0.0% 3 | 0 0.0% 2 | 0 0.0% 1 |****************************** 3 60.0% 0 |********** 1 20.0% Distribution of Minimum Index Levels ....+....20...+....40...+....60...+....80...+.... 6+| 0 0.0% 5 |********** 1 20.0% 4 | 0 0.0% 3 | 0 0.0% 2 | 0 0.0% 1 |****************************** 3 60.0% 0 |********** 1 20.0% Distribution of Number of SR8s ....+....20...+....40...+....60...+....80...+.... 60+| 0 0.0% 56 |********** 1 20.0% 52 | 0 0.0% 48 | 0 0.0% 44 | 0 0.0% 40 | 0 0.0% 36 | 0 0.0% 32 | 0 0.0% 28 | 0 0.0% 24 | 0 0.0% 20 | 0 0.0% 16 | 0 0.0% 12 | 0 0.0% 8 | 0 0.0% 4 | 0 0.0% 1 |****************************** 3 60.0% 0 |********** 1 20.0% Distribution of Number of Index Members ....+....20...+....40...+....60...+....80...+.... 90+| 0 0.0% 85 |********** 1 20.0% 80 | 0 0.0% 75 | 0 0.0% 70 | 0 0.0% 65 | 0 0.0% 60 | 0 0.0% 55 | 0 0.0% 50 | 0 0.0% 45 | 0 0.0% 40 | 0 0.0% 35 | 0 0.0% 30 | 0 0.0% 25 | 0 0.0% 20 | 0 0.0% 15 | 0 0.0% 10 | 0 0.0% 5 | 0 0.0% 1 |****************************** 3 60.0% 0 |********** 1 20.0% Distribution of Estimated IOs for Sequential Bottom Level Access Using 1 Buffer ....+....20...+....40...+....60...+....80...+.... 28+| 0 0.0% 27 |********** 1 20.0% 26 | 0 0.0% 25 | 0 0.0% 24 | 0 0.0% 23 | 0 0.0% 22 | 0 0.0% 21 | 0 0.0% 20 | 0 0.0% 19 | 0 0.0% 18 | 0 0.0% 17 | 0 0.0% 16 | 0 0.0% 15 | 0 0.0% 14 | 0 0.0% 13 | 0 0.0% 12 | 0 0.0% 11 | 0 0.0% 10 | 0 0.0% 9 | 0 0.0% 8 | 0 0.0% 7 | 0 0.0% 6 | 0 0.0% 5 | 0 0.0% 4 | 0 0.0% 3 | 0 0.0% 2 | 0 0.0% 1 |****************************** 3 60.0% 0 |********** 1 20.0% Distribution of Nr of Pages with Intermediate Level SR8s ....+....20...+....40...+....60...+....80...+.... 7+| 0 0.0% 6 |********** 1 20.0% 1+| 0 0.0% 0 |**************************************** 4 80.0% Distribution of Minimum Nr of Pages with Intermediate Level SR8s ....+....20...+....40...+....60...+....80...+.... 4+| 0 0.0% 3 |********** 1 20.0% 1+| 0 0.0% 0 |**************************************** 4 80.0% Distribution of % Displaced Intermediate Level SR8s ....+....20...+....40...+....60...+....80...+.... 48+|********** 1 20.0% 1+| 0 0.0% 0 |**************************************** 4 80.0% Distribution of Nr of Pages with Bottom Level SR8s ....+....20...+....40...+....60...+....80...+.... 7+| 0 0.0% 6 |********** 1 20.0% 5 | 0 0.0% 4 | 0 0.0% 3 | 0 0.0% 2 | 0 0.0% 1 |****************************** 3 60.0% 0 |********** 1 20.0% Distribution of Minimum Nr of Pages with Bottom Level SR8s ....+....20...+....40...+....60...+....80...+.... 4+| 0 0.0% 3 |********** 1 20.0% 2 | 0 0.0% 1 |****************************** 3 60.0% 0 |********** 1 20.0% Distribution of % Displaced Bottom Level SR8s ....+....20...+....40...+....60...+....80...+.... 1+| 0 0.0% 0 |************************************************** 5 100.0% Status = 0 SQLSTATE = 00000
Printing a REFERENCING ROWID summary report of an index
The report below illustrates the use of the REFERENCING ROWID option to request the printing of the index occurrence containing the row ID of the referencing row identified by X'0013D401'.
PRINT INDEX DEPT_EMPL SEGMENT USERDB TABLE DEMO.DEPT REFERENCING ROWID X'0013D401' SUMMARY; SET Name: DEPT_EMPL IBC 3 Displacement 2 Sort option SORTED SYM ASC Key length 10 Duplicates FIRST Compression No OWNER: DEPT AREA USERDB.ORG_AREA Low page 5051 Page size 1024 High page 5100 MEMBER: EMPL Set membership Optional Manual Located VIA index No Index is Linked AREA USERDB.EMP_AREA Low page 5001 Page size 1024 High page 5050 OWNER X'0013D401' on page 5076 Top level SR8 on page 5079 utilization 100.0% Intermediate Level Nr of SR8s 26 17 Minimum Nr of pages with SR8s 6 3 Minimum Nr of displaced SR8s 15 57.6% Nr of entries in use 58 74.3% Nr of Orphans 18 31.0% Total size of all SR8s 2704 Bottom Level Nr of SR8s 33 29 Minimum Nr of pages with SR8s 6 3 Minimum Nr of displaced SR8s 0 0.0% Nr of entries in use 87 87.8% Nr of Orphans 24 27.5% Total size of all SR8s 2844 Index occurrence totals Nr of members 87 Nr of levels 5 5 Minimum Size of largest SR8 104 Nr of SR8s 59 46 Minimum Nr of pages with SR8s 8 5 Minimum Nr of displaced SR8s 15 25.4% Nr of entries in use 145 81.9% Nr of Orphans 42 28.9% Total size of all SR8s 5548 Nr of Buffers versus Estimated IOs for Sequential Bottom Level access ------------- ------------- 1 27 2 21 3 15 4 10 5 8 6 - 20 6 Status = 0 SQLSTATE = 00000
Report Output Description
The report header provides general information on the index definition, the index owner record or SQL table, and the index member record or SQL table.
A detailed report on index run-time data per index occurrence is always output for a system-owned index. For a user-owned index, it is output only when explicitly requested using SUMMARY DETAILED. The report provides the following:
Number of SR8's and its computed minimum value
Number of pages with SR8's and its computed minimum value
Number of displaced SR8's and as a percentage of SR8's
Number of entries in use and as a percentage of available entries
Number of orphans and as a percentage of used entries
Total size of all SR8's
Number of levels in the index and its computed minimum value
Number of members in the index
Size of the largest SR8
Number of SR8's and its computed minimum value
Number of pages with SR8's and its computed minimum value
Number of displaced SR8's and as a percentage of SR8's
Number of entries in use and as a percentage of available entries
Number of orphans and as a percentage of used entries
Total size of all SR8's
A displaced SR8 is a bottom level SR8 located within the index displacement or a non-bottom level SR8 located outside the index displacement.
A computed minimum value is obtained by using the current number of entries in the index, filling SR8's to 100% using the current value of INDEX BLOCK CONTAINS for the index, and assuming that all space on a database page is available to hold the index owner and the associated SR8's.
An index overview provides the following information:
Number of owner occurrences
Number of empty owners and as a percentage of owner occurrences
Number of displaced (not on same page as owner) top level SR8's
Total, average, and highest value of the number of SR8's
Total, average, and highest value of the computed minimum number of SR8's
Average and highest value of the index level
Average and highest value of the computed minimum level
Average and highest value of the number of pages
Average and highest values of the computed minimum number of pages
Number of index occurrences with orphans
Number of orphans: total and as a percentage of the number of entries and highest plus its owner DBKey
Total size of all SR8's
Size of largest SR8
A distribution diagram provides the number and percentage of index occurrences for a certain property in both a numeric and a pseudo-graphical way. Properties for which a distribution diagram is output are:
Index level
Minimum index level
Number of SR8's
Number of members in the index occurrence
Estimated IOs using 1 buffer for sequential bottom level access
Number of pages with intermediate level SR8's
Minimum number of pages with intermediate level SR8's
Percentage displaced intermediate level SR8's
Number of pages with bottom level SR8's
Minimum number of pages with bottom level SR8's
Percentage displaced bottom level SR8's
For more information about the PRINT INDEX utility, see the CA IDMS Utilities Guide.
The TUNE INDEX utility performs the following functions:
Authorization
A user must have DBAWRITE authority on all areas processed by the utility.
Syntax
►►─ TUNE INDEX FOR ─────────────────────────────────────────────────────────────► ►─┬─ AREA sql-area-name ──────────────────────────────────────────────────────┬─► │ │ │ ┌───────────────────────────────,───────────────────────────────┐ │ ├─ TABLE ─▼─┬──────────────┬ table-name ┬────────────────┬┬──────────────┬┴─┤ │ └ schema-name. ┘ └ ix-or-con-spec ┘└ tune-options ┘ │ │ │ └─ DBNAME dbname SUBSCHEMA ss-name ─┬────────────┬──────────────────────────┘ └─ set-spec ─┘ ►─┬─────────────────────────────────────────────┬───────────────────────────────► └─ DEFAULT ─┬────────────────┬─ tune-options ─┘ └─ TUNE OPTIONS ─┘ ►─┬──────────────────────────────────────┬──────────────────────────────────────► └─ COMMIT INTERVAL ─┬─ cmt-interval ─┬─┘ └─ 100 ◄─────────┘ ►─┬──────────────────────────────────────┬─────────────────────────────────────►◄ └─ NOTIFY INTERVAL ─┬─ not-interval ─┬─┘ └─ 1000 ◄────────┘
Expansion of ix-or-con-spec
┌─────────────────────────────────────────────────────────────────────┐ ►►─┴─┬─ CONSTRAINT ─┬─ constraint-name ──────────────────────────────┬─┬─┴─────►◄ │ │ │ │ │ │ ┌──────────────────,─────────────────┐ │ │ │ └─ ( ─▼─ constraint-name ─┬───────────────┬┴─ ) ─┘ │ │ └─ tune-options ┘ │ └─ INDEX ─┬─ index-name ───────────────────────────────┬──────────┘ │ │ │ ┌──────────────,─────────────────┐ │ └─ ( ─▼─ index-name ─┬────────────────┬┴─ ) ─┘ └─ tune-options ─┘
Expansion of set-spec
►►─── SET ─┬─ set-name ──────────────────────────────┬─────────────────────────►◄ │ │ │ ┌───────────────,─────────────┐ │ └─ ( ─▼─ set-name ┬────────────────┬┴─ ) ─┘ └─ tune-options ─┘
Expansion of tune-options
┌───────────────────────────────────────────────────────────────────────┐ ►►──▼─┬─ REBALANCE ─┬─ NO ◄───┬───────────────────────────────────────────┬─┴─►◄ │ └─ YES ───┘ │ │ │ ├─ RESEQUENCE ─┬─ NO ◄───┬──────────────────────────────────────────┤ │ └─ YES ───┘ │ │ │ ├─ TEMPORARY INDEX UTILIZATION ┬────┬─┬ ixutil-pct ┬ PERCENT ─┬─┬───┤ │ └ IS ┘ │ └─ % ──────┘ │ │ │ └─ key-count ─────────────┘ │ │ │ └─ TEMPORARY PAGE RESERVE ┬────┬─┬ page-reserve-pct ┬ PERCENT ─┬─┬──┘ └ IS ┘ │ └─ % ──────┘ │ └─ reserve-character-count ─────┘
Parameters
Specifies whether to rebalance the index. A well-balanced index has the minimum number of index levels and best performance if the index is frequently accessed vertically from top to bottom.
Rebalances the index.
Note: Rebalancing an index can be resource-intensive.
No rebalancing is done.
Specifies whether to resequence the index. A properly sequenced index is important only if the index is frequently accessed sequentially at the bottom level.
Resequences the index for optimum performance.
Note: Resequencing an index can be resource-intensive.
No resequencing is done.
Specifies a temporary override for the operation. If not specified, the current run-time value for INDEX BLOCK CONTAINS is used and index blocks are used at 100%.
Specifies the percentage of the maximum number of entries that each index block should contain after tuning is complete. ixutil-pct is an integer in the range 10 through 100. The number of entries of an index block is computed as index-block-contains * ixutil-pct / 100.
Specifies the maximum number of entries that each index block should contain after tuning is complete. key-count is an integer in the range 3 through 8180.
Specifies a temporary override of the page reserve for the area in which the index resides. If not specified or specified as NULL, the page reserve of the area in which the index resides is used.
Specifies the percentage of each page to leave as free space if it contains a portion of an index being tuned. page-reserve-pct is an integer in the range 0 through 30. The page reserve of the area is computed as area-page-size * page-reserve-pct / 100.
Specifies the number of characters to reserve on each page to accommodate increases in the length of records or rows stored on the page if it contains a portion of an index being tuned. reserve-character-count is an integer with a value not larger than 30% of the page size.
General Considerations
The TUNE INDEX utility has the following usage considerations:
Operating modes
You can execute the TUNE INDEX utility both online (through the online command facility) and in batch through central version or batch local. When index tuning is executed by a central version, TUNE INDEX tries to minimize impact on other online tasks as follows:
Commit interval
You can specify a commit interval that determines the frequency with which the utility will commit. The interval specifies the number of updates that can take place before a commit is issued. You can disable committing and automatic restart by specifying a 0-commit interval. Regardless of the commit interval specified, the utility always issues a COMMIT ALL at the end of the tune process of an index occurrence to release all record locks. It also issues a COMMIT ALL if it detects that another task is waiting on a record lock that it holds and it issues a FINISH if it detects that another task is waiting on an area lock that it holds.
Notify interval
You can specify a time interval in minutes. Each time this interval expires, a message is written indicating the index tuning progress. The message is written to the job log and the operator's console if TUNE INDEX runs in local mode; otherwise, it is written to the IDMS LOG and console. You can disable notification by specifying a 0-notify interval.
The following example directs the TUNE INDEX utility to adopt orphaned index records, rebalance and resequence the index. It also shows how to temporarily override the DMCL or subschema values for PAGE RESERVE and INDEX BLOCK CONTAINS.
TUNE INDEX FOR DBNAME EMPDEMO SUBSCHEMA EMPSS01
SET (EMP-NAME-NDX)
DEFAULT TUNE OPTIONS
REBALANCE YES
RESEQUENCE YES
TEMPORARY INDEX UTILIZATION IS 80 %
TEMPORARY PAGE RESERVE IS 15 PERCENT
NOTIFY INTERVAL 1000;
The following is a sample of a report produced by the TUNE INDEX utility.
TUNE INDEX FOR DBNAME EMPDEMO SUBSCHEMA EMPSS01 SET (EMP-NAME-NDX) DEFAULT TUNE OPTIONS REBALANCE YES RESEQUENCE YES TEMPORARY INDEX UTILIZATION IS 80 % TEMPORARY PAGE RESERVE IS 15 PERCENT NOTIFY INTERVAL 1000; Status = 0 SQLSTATE = 00000 Messages follow: DB002994 C0M333: IDMSTUNE - processing started DB002994 C0M333: IDMSTUNE - Indexes selected for processing: DB002994 C0M333: IDMSTUNE - EMP-NAME-NDX (IBC=32) in area EMPDEMO.EMP-DEMO-REGION (PGRSV=644) DB002994 C0M333: IDMSTUNE - Statistics for area EMP-DEMO-REGION DB002994 C0M333: IDMSTUNE - Orphan adoption read 34 records (of which 6 SR8s) DB002994 C0M333: IDMSTUNE - Orphan adoption adopted 20 index orphans DB002994 C0M333: IDMSTUNE - Rebalancing read 65 records DB002994 C0M333: IDMSTUNE - Resequencing read 35 records DB002994 C0M333: IDMSTUNE - 134 total records read DB002994 C0M333: IDMSTUNE - 20 total index orphans adopted DB002994 C0M333: IDMSTUNE - 1 indexes/sets processed DB002994 C0M333: IDMSTUNE - processing completed
The Lock Monitor (LOCKMON) system task includes the following enhancements:
Syntax
►►── LOCKMON ────────────────────────────────────────────────────────────────►◄
LOCKMON commands
►►─┬─ . . . ──────────────────────────────────────┬──────────────────────────► ├─ Watch ─┬─ . . . ─────────────┬──────────────┤ │ └─ Term ─┬─ * ────────┤ │ │ └─ lte-name ─┘ │ ├─ SEt ─┬─ . . . ────────────────────────────┬─┤ │ ├─ DISplay ─┬─────────┬─┬──────────┬─┤ │ │ │ └─ EQual ─┘ ├─ DBKeys ─┤ │ │ │ │ ├─ KEYs ───┤ │ │ │ │ ├─ AReas ──┤ │ │ │ │ └─ NAmes ──┘ │ │ │ ├─ Filter ─┬─ OFf ─────────────────┬─┤ │ │ │ └┬──────┬─┬─ Current ───┤ │ │ │ │ └─ ON ─┘ ├─ * ─────────┤ │ │ │ │ └─ AREA name ─┘ │ │ │ └────────────────────────────────────┘ │ └──────────────────────────────────────────────┘
Parameters
Displays logical terminals holding longterm locks.
Displays all logical terminals holding longterm locks.
Specifies the name of the logical terminal or a mask that identifies one or more logical terminals. The display can be formatted in dbkeys or area names.
Changes the display format for the terminal detail displays.
Displays locked dbkeys in the detail information.
A synonym for DBKeys.
Displays area names with locked dbkeys in the detail information.
A synonym for AReas.
Specifies a filter change.
Note: Filters are "sticky" items.
Turns off filtering.
Turns on filtering.
Uses the current filter specified in the previous filter command.
Uses all filters previously set.
Sets the filter to an area name or mask, resulting in using one or more area names as the current filter.
This section shows the area name format and DBKey format displays generated by the new WATCH TERMINAL command.
WATCH TERMINAL (Area name format) command
Enter this command to display a report of the terminals holding longterm locks, the longterm lock ids, and the area names for which locks are being held. For each area, a count of the notify, share and exclusive locks is reported.
CA IDMS DB/DC Lock Monitor Version nn.n LTE: * Tape: volser Longterm_Lock_ID Segment.Area_Name__________ Notfy Share Excl Terminal: LTEnnnn User: USER01 LOCK ID 1 EMPDEMO.EMP-DEMO-REGION 0 0 2 LOCK ID 2 EMPDEMO.INS-DEMO-REGION 0 0 2 LOCK ID 3 EMPDEMO.EMP-DEMO-REGION 1 1 0 EMPDEMO.INS-DEMO-REGION 1 1 0 LOCK1 EMPDEMO.EMP-DEMO-REGION 0 0 2 LOCK2 EMPDEMO.INS-DEMO-REGION 0 0 2 LOCK3 EMPDEMO.EMP-DEMO-REGION 1 1 0 EMPDEMO.ins-DEMO-REGION 1 1 0 CA IDMS DB/DC V300 Time: hh:mm:ss
WATCH TERMINAL (DBKey format) command
Enter this command to display a report of the terminals holding longterm locks, the longterm lock ids, the DBKeys associated with the longterm lock id, and the locking level of the lock held for each DBKey.
CA IDMS DB/DC Lock Monitor Version nn.n LTE: * Tape: volser Longterm_Lock_ID PgGrp Lock Mode/DBKey(s)...... Terminal: LTEnnnn User: USER01 LOCK ID 1 00000 EXCL 75007:001 LOCK ID 2 00000 EXCL 75106:001 LOCK ID 3 00000 NTFY 75106:001 75050:004 LOCK1 00000 EXCL 75007:001 LOCK2 00000 EXCL 75106:001 LOCK3 00000 NTFY 75106:001 75050:004 CA IDMS DB/DC V300 Time: hh:mm:ss
This section shows the INFO command screen with the new longterm lock information displayed.
INFO command
Enter this command in the Lock Monitor command field to display information about the version of LOCKMON that you are running.
CA IDMS DB/DC Lock Monitor Version nn.n Info/Status Details Tape: volser System Information CV Number: 300 Generation ID: TECHDC30 Task Information Task Code: LOCKMON Program Name: LOCKMON Program Information Module Name: LOCKMON nn.n Assembled: mm/dd/yy @ hh:mm Current Execution Information Task ID: 76 Line: VTAM Loaded at: 2324CC00 PTerm: PTEnnnn Size: 00009F90 LTerm: LTEnnnn Refresh Interval: 5 DCMT status: Usable Longterm Lock Displays: Format: Area Names Filter Status: Off Filter: * CA IDMS DB/DC V300 Time: hh:mm:ss
For more information about the Lock Monitor, see the CA IDMS System Tasks and Operator Commands Guide.
New LOOK functions report on SQL-defined database attributes and converted time stamps.
A new BIND SQL SEGMENT function has been added to the batch IDMSLOOK utility and online LOOK system task to report on logical and physical attributes for areas, tables, constraints, and indexes for a segment of an SQL-defined database. The output is similar to that of the BIND SUBSCHEMA function.
Syntax
┌──────────────────────────────────────────────────────┐ ►►─▼─ BIND SQL SEGMENT=segment-name,DBNAME=database-name ─┴─────────────────►◄
Parameters
Specifies the segment that contains the SQL database areas.
Specifies the database name that contains the segment where the catalog for the SQL definitions reside.
A new EXTERNAL DATETIME function has been added to the batch IDMSLOOK utility and online LOOK system task to report on the internal value of an external date/time stamp.
Syntax
┌─────────────────────────────────────────────┐ ►►─▼─ EXTERNAL DATETIME=external-datetime-value ─┴──────────────────────────►◄
Parameters
The 26 characters that make up the external representation of the date/time stamp. The format is yyyy-mm-dd-hh.mm.ss.ffffff.
Example
Input
EXTERNAL DATETIME=2006-05-09-11.21.53.677107
Output
Internal datetime stamp=X'0165A2E9FD1A54F3'
A new operand is provided to enable including the volser of the current CA IDMS installation tape in the text of a message.
This section describes only the new operand. For more information, see the CA IDMS IDD DDDL Reference Guide.
Message occurrence structure
|
Operand |
Replacement value |
|---|---|
|
&$9. |
CA IDMS tape volser |
The following startup parameters have been added to CA IDMS and can be coded as freeform or positional parameters:
This section describes the multitasking queue depth, operating system subpool, and zIIP freeform parameters.
In earlier releases, to override the default multitasking queue depth of 2, you had to issue a DCMT VARY MT command after a DC/UCF system had started. You can now set the desired queue depth at startup by using the MTQDEPTH parameter.
Syntax
┌───────────────────────,──────────────────────┐ ►►──▼─┬┬─ MTQDEPTH= ─┬─ multitasking-queue-depth ─┬┴─────────────────────────►◄ │└─ MTQD= ─────┘ │ └── . . . ──────────────────────────────────┘
Parameter
(z/OS systems only) Specifies the multitasking queue depth.
The optimum value for the MT queue depth is dependent on factors outside the control of DC, such as other work on the CPUs, operating system dispatcher parameters, paging rate, etc. Therefore, it is advised to experiment with the value and watch the results. The value must be in a range of 0 to 255; however, the advised value is in a range of 0 to 9. The default is 2.
Note: Specifying a low value causes more usage of subtasks. A too-low value causes subtasks to wake up and go back to sleep again without doing any work because the queue was already emptied by another subtask. A too-high value disables multitasking, and most if not all work is processed by only one subtask.
If you want CA IDMS to use an operating system subpool other than subpool 1 when the GETMAIN requests build the CA IDMS system at startup, you can now specify a different subpool to be used at startup with a new SUBPOOL parameter.
Syntax
┌───────────────────────,─────────────────────┐ ►►──▼─┬┬─ SUBPOOL= ─┬─ operating-system-subpool ─┬┴──────────────────────────►◄ │└─ SP= ──────┘ │ └── . . . ─────────────────────────────────┘
Parameter
(z/OS systems only) Specifies the operating system subpool to use for GETMAIN requests. See your operating system documentation for information on operating system subpools. The valid values for operating system subpools are from 1 to 127. The default is 1.
You can now control use of zIIP processors in z/OS through the new zIIP startup parameter.
Syntax
┌───────────,───────────┐ ►►──▼─┬── ZIIP= ─┬─ Y ──┬─┬─┴────────────────────────────────────────────────►◄ │ └─ N ◄─┘ │ └── . . . ──────────┘
Parameter
(z/OS systems only) Specifies the type of zIIP support to provide in z/OS.
Valid values are the following:
This section describes the positional parameter positions for the operating system subpool, multitasking queue depth, and zIIP values.
Column
0 1 2 3
12345678901234567890123456789012345678
PARM='S=sys#prompt tnnsclll###submqdz
Parameters
Columns 32-34—(z/OS systems only) Specifies the operating system subpool value to use for GETMAIN requests. See your operating system documentation for information on operating system subpools. The valid values for operating system subpools are from 1 to 127. The default is 1.
Columns 35-37—(z/OS systems only) Specifies the multitasking queue depth value.
The optimum value for the MT queue depth is dependent on factors outside the control of DC, such as other work on the CPUs, operating system dispatcher parameters, paging rate, etc. Therefore, it is advised to experiment with the value and watch the results. The value must be in a range of 0 to 255; however, the advised value is in a range of 0 to 9. The default is 2.
Note: Specifying a low value causes more usage of subtasks. A too-low value causes subtasks to wake up and go back to sleep again without doing any work because the queue was already emptied by another subtask. A too-high value disables multitasking, and most if not all work is processed by only one subtask.
Column 38—(z/OS systems only) Specifies the type of zIIP support to provide in z/OS.
Valid values are the following:
OLP enhancements include the following:
Specifies the log messages to be displayed according to the time when the messages were issued.
OLP displays the current FROM/TO times and dates. The following partial screen shows what you would see if you were searching for log records issued between 11:00 and 11:56 p.m. on 1/13/07:
FROM ON TO ON COL PRT SKIP LOG TYPES ROLL STATUS 23:00:00 2007-01-13 23:56:00 2007-01-13 001 OFF 0000 (WT/TR/DU/ ) 040
Specifies the time of the first log message to be displayed.
You can specify begin-time using any one of these formats (where hh specifies hours based on a 24-hour clock, mm minutes, and ss seconds):
The following defaults are defined for begin-time:
Specifies the time of the last log message to be displayed.
You can specify end-time using any one of these formats (where hh specifies hours based on a 24-hour clock, mm minutes, and ss seconds):
The following defaults are defined for end-time:
More Information
For more information about the OLP command, see the CA IDMS System Tasks and Operator Commands Guide.
The REORG utility has been enhanced in the following areas:
Syntax
The following new syntax options have been added:
►►── REORG setup-options ... ───────────────────────────────────────►◄
Expansion of setup-options
►───────────┬─────────────────────────────────────────────────────┬──► ├─── ESTIMATE workfile sizes ─────────────────────────┤ ├─── DELETE old workfiles ────────────────────────────┤ ├─── OVERFLOW PERCENT nnn ────────────────────────────┤ └─── OVERFLOW CACHE nnnnnnnn ───┬──────┬──────────────┘ ├─ KB ─┤ ├─ MB ─┤ └─ GB ─┘ ►►── REORG ESTIMATE workfile sizes ─────┬──────────┬────────────────►◄ └─ SUBMIT ─┘ ►►── REORG CLEANUP ... ──────────────────────────────────────────────► ►───────────┬─────────────┬──────────────────────────────────────────► └─ DELETEALL ─┘
Parameters
Directs REORG to estimate the size of work files by gathering statistics in a separate pass of the database. This option generates estimates for both UNLOAD and RELOAD work files.
By default, statistics are collected during the unload phase that can be used for sizing RELOAD work files only. UNLOAD work files must be sized manually.
If specified together with setup-options, statistics gathering starts as soon as the setup phase is complete and processing stops after the statistics have been gathered. Additional jobs are automatically submitted to help gather statistics and process the database by UNLOAD slice and index.
If specified independently of setup-options, it must be specified in a separate execution of the REORG utility that occurs between the setup and UNLOAD phases. Multiple jobs are submitted to gather statistics only if the SUBMIT option is specified. Processing stops when file estimation is complete.
When file estimation is complete, processing must be restarted by specifying a new STOP AFTER point.
File size estimates are automatically used when dynamically allocating work files if no primary space value is specified for the file's DSMODEL.
Directs REORG setup to delete work files that may be left from a previous run. All existing work files that match the name of a new work file are deleted, including DBKEYS files.
By default, old work files are reused. See "Considerations for running REORG on z/VSE".
Specifies the percentage used to estimate the size of SYSOF2 and SYSOF8 work files and all output work files for the two overflow tasks: RELOAD2 and RELOAD5. The size of these files cannot be predicted, so they are estimated to be a percentage of related work files.
By default, 10% is used.
Specifies a limit on the size of the overflow cache used to temporarily hold records that do not fit on their target page.
nnn is the maximum size of the overflow cache specified in bytes, Kilobytes (2**10), Megabytes (2**20), or Gigabytes (2**30), depending on whether it is followed by no qualifier or by KB, MB, or GB respectively.
A value larger than 2**31-1 is limited to 2**31-1 bytes.
By default, 32 KB is used.
Directs an explicit cleanup job to delete all work files associated with the current control file, including those that were not dynamically allocated by the current REORG operation. This option does not apply to DBKEYS files.
By default, only files dynamically allocated by the current REORG operation are deleted. See "Considerations for running REORG on z/VSE".
This section describes enhancements in the use of the REORG utility.
REORG processing is divided into tasks and grouped into phases. Each phase processes a type of work needed to unload or reload a database or rebuild an index. Each task processes a slice or index group within a phase.
For example, if a database were divided into two UNLOAD slices and had three index groups, the UNLOAD phase could have up to five tasks: one for each slice and possibly one for each index group. All UNLOAD tasks must successfully complete before REORG can begin to process tasks in the RELOAD or REBUILD phases.
RELOAD contains six phases numbered 1 through 6. These phases reload slices, rebuild user indexes, and reconnect pointers. Each RELOAD task in a given phase must successfully complete before processing can move to the next RELOAD phase.
REBUILD can contain up to three phases numbered 1 through 3. Each index group has one task per phase, but each index group can run independently of the others and independently of RELOAD phases 3 through 5.
If a system index related page range conflict exists between tasks in RELOAD and REBUILD or between REBUILD tasks, updates of the page range are serialized.
There is no longer a REBUILD4 phase. The updating of owner and UP pointers for system owned indexes has been merged with the RELOAD6 phase to reduce the number of passes of the database.
Eliminating the REBUILD4 phase also eliminates the SYSX10 and SYSX11 class of work files. Instead, the REBUILD3 phase generates additional SYS010 files to be processed by RELOAD6.
This section contains the REORG enhancements made to the sample output.
REORG Status Report - Section 1
The following example shows the addition of the Overflow Percentage value to the Status Report:
****************************************************************************** * * * REORG Status Report * * Identifying time stamp: 2005-11-17-13.44.06.388141 * * Unload subschema=EMPTSS01 Unload segment=EMPDEMO Unload DMCL=EMPTDMCL * * Reload subschema=EMPTSS01 Reload segment=EMPBDEMO Reload DMCL=EMPBDMCL * * * ****************************************************************************** Options in effect ----------------- Divide processing 3 ways Notify interval=1 Job submission=YES SHARE=YES STOP AFTER CLEANUP CREATE ALL WORKFILES reuse workfiles=NO SORTEXIT=NO Overflow Percentage=10 Concurrent jobs=5 GENERATE DBKEYS FILES=YES Current status -------------- SETUP=completed UNLOAD=completed RELOAD=completed CLEANUP=completed total tasks=23 tasks completed=23 reload areas are not locked
REORG Status Report - Section 6
The following example shows the general-purpose files used during the UNLOAD and RELOAD phases. Other sections show index files, sorted data files, and DBKEYS files.
All work file summary reports show the estimated size of each file and the attributes used in determining those sizes. BPT is Blocks Per Track; TPC is Tracks Per Cylinder; and *3390* indicates that attributes were based on a generic 3390 device, as opposed to a specific volume.
An asterisk (*) following a DDNAME indicates that the file was created by a REORG job executing as part of the current operation and therefore will be deleted automatically during cleanup.
Unload/Reload work file summary ------------------------------- DDname DSN Estimated Size ------ --- -------------- WU00001 * USERA01.EMPDEMO.WORKFILE.WU00001 1 Trk Estimate based on: VOLSER=*3390* BLKSIZE=27998 BPT=02 TPC=15 UNIT=SYSDA SPACE=Trk PRI=1 SEC=1 WU00002 * USERA01.EMPDEMO.WORKFILE.WU00002 1 Trk Estimate based on: VOLSER=*3390* BLKSIZE=27998 BPT=02 TPC=15 UNIT=SYSDA SPACE=Trk PRI=1 SEC=1 &vellip. WU00039 * USERA01.EMPDEMO.WORKFILE.WU00039 1 Trk Estimate based on: VOLSER=*3390* BLKSIZE=27998 BPT=02 TPC=15 UNIT=SYSDA SPACE=Trk PRI=1 SEC=1 Total primary space: 0 Cyl 39 Trk 0 Blk
Database Load Statistics Report
The following example shows standard database statistics as returned from an ACCEPT DATABASE STATISTICS command. The values reflect the processing done by the current RELOAD1 or RELOAD2 task.
UT005002 DATABASE LOAD STATISTICS DATABASE LOADED ON 01/15/08 AT 21:24:53 PAGES READ ................... 62 PAGES WRITTEN ................ 59 PAGES REQUESTED .............. 86 CALC RCDS IN TARGET PAGE ..... 268 CALC RCDS OVERFLOWED ......... 0 VIA RCDS IN TARGET PAGE ...... 3,869 VIA RCDS OVERFLOWED .......... 0 LINES REQUESTED BY IDMS ...... 1,742 RCDS MADE CURRENT OF R/U ..... 4,137 CALLS TO IDMS ................ 4,144 FRAGMENTS STORED ............. 0 RECORDS RELOCATED ............ 0
RELOAD Statistics Report
The following example shows additional statistics produced by REORG when reloading a database. The values reflect the processing done by the current RELOAD1 or RELOAD2 task.
RELOAD STATS RCDS READ .................... 4,380 RCDS STORED IN DATABASE ...... 4,137 RCDS STORED ON TARGET PAGE ... 3,998 RCDS STORED TARGET PERCENT ... 96 RCDS WRITTEN TO OVERFLOW ..... 243 RCDS CACHED .................. 357 RCDS STORED FROM CACHE ....... 139 RCDS OVERFLOW FROM CACHE ..... 218 CACHE STORAGE USED ........... 16,384 CACHE STORAGE LIMIT .......... 16,384
The fields reported are the following:
The total database records read from a work file. This does not include pointer and other work records
The number of database records stored in the database.
The number of database records stored on the intended target page.
The percentage of database records stored on their target page.
The number of database records written to a SYSOF2 file, to be processed by the RELOAD2 overflow task
The number of database records written to the memory cache.
The number of database records that were written to memory cache and then stored in the database.
The number of database records that were written to memory cache and then written to the overflow work file.
The amount of allocated cache storage at the end of task. If this is the same as the storage limit, the cache reached its limit and records may have been written to the overflow file.
The maximum storage allowed for the overflow cache. This can be changed using the OVERFLOW CACHE option.
REORG on z/VSE does not support creating and deleting work files. It will create and delete user labels, but the work files will not be created, a VTOC entry will not be created, until the file is opened for output. When REORG processing is complete, work files must be manually deleted, or overwritten to reclaim the space. The options: DELETE OLD WORKFILES, CREATE WORKFILES, and DELETEALL, only apply to user labels for the current job. Automatic deletion of work files during the CLEANUP phase will only delete user labels.
The extent of a generated label will have a relative starting track of 1 for the number of tracks based on the primary space value. These labels require CA DYNAM/D to convert them to an actual track address at open time.
If CA DYNAM/D is not installed, labels for work files must be coded manually. The recommended procedure in this case, is to use the ESTIMATE FILE SIZES option, which does not use any work files. Code the JCL statements based on the reported file sizes; and include them in all REORG jobs.
REORG requires the RORGCTL and RORGJCL files to be defined in SYSIDMS using FILENAME= parameters.
FILENAME=RORGCTL RECFM=F BLKSIZE=4096 FILENAME=RORGJCL RECFM=F BLKSIZE=NNNN LRECL=80 DLBLMOD=ON
Where NNNN is the block size of the JCL file and must be a multiple of 80.
The SYSIDMS DLBLMOD=ON option must be specified to allow for sequential and random processing of the RORGCTL file. Either a DA or SD label may be used for RORGCTL.
The only options which apply to z/VSE are: DSN; BLKSIZE; the allocation unit value and primary value for the SPACE option; and the first volume of the VOLSER Option. The rest may be coded, but will be ignored.
REORG will generate labels using track sizes. If CYL is codedfor a space allocation unit, the primary value will be converted to tracks, but there will be no cylinder alignment. If a block size is coded for an allocation unit, the coded value will be used to calculate the number of tracks required. The coded value must match the BLKSIZE value, otherwise the calculated number of tracks may not be accurate.
An example of a DSMODEL follows; note that the primary space value was not coded. This allows REORG to generate the value for each file, using file size estimates. If a primary space value had been coded, this value would be used for all files regardless of the estimated size.
CREATE DSMODEL W* DSN 'USERID.EMPDB.WORKFILE.&DD'. BLKSIZE 4096 SPACE TRK VOLSER IDMS05 ;
JCL submitted by REORG is read from the RORGJCL file. This must be a sequential file built on disk and contain all the JECL and JCL statements for the submitted job. However the JECL and some JCL statements can't be directly copied to this file using normal JCL because POWER will try to interpret these statements when the copy job is run. These statements must be "hidden" from power by changing the first characters as follows:
* $$ statements must be coded as $ $$ statements
// JOB statements must be coded as #/ JOB statements
/* coded as #*
/& coded as #&
Any statement starting with a "/" may be coded as starting with a "#".
This is the same method used by the IESINSRT program to hide JCL, which is documented in the IBM z/VSE Administration Guide.
The JCL will get stored on disk in the format it is coded. REORG will convert the hiding characters back to their correct values prior to submitting the job to POWER. For example the JCL to copy a job to the RORGJCL file might look like this:
// DLBL RORGJCL,'USERID.EMPDB.RORGJCL',1,SD
// EXTENT SYS020,CULLD9,,,1,50
// ASSGN SYS020,DISK,VOL=CULLD9,SHR
// EXEC IDCAMS,SIZE=386K
REPRO INFILE(SYSIPT) -
OUTFILE(RORGJCL ENV( BLKSZ(4080) RECFM(FB) RECSZ(80) ) )
$ $$ JOB JNM=RORGJOB,CLASS=B,DISP=D
$ $$ LST CLASS=R,DEST=(,USERID),JSEP=0
$ $$ PUN CLASS=R,DEST=(,USERID)
#/ JOB RORGJOB
* JCL THAT REORG SUBMITS
#/ DLBL SYSIDMS,'#SYSIPT'
#/ EXEC IDMSBCF,SIZE=256K
ECHO=ON JOURNAL=OFF DLBLMOD=ON
DMCL=IDMSDMCL DBNAME=EMPDEMO
FILENAME=RORGCTL RECFM=F BLKSIZE=4096
#*
REORG;
#*
#&
$ $$ EOJ
/* EOF for REPRO
Defining the REORG control file, all jobs and job steps
// DLBL RORGCTL,'user.rorgctl',,SD // EXTENT SYSnnn,vvvvvv,,,sssss,llll // ASSGN SYSnnn,DISK,VOL=vvvvvv,SHR
Defining the REORG JCL file, required when submitting jobs
// DLBL RORGJCL,'user.jclfile',,SD // EXTENT SYSnnn,vvvvvv,,,sssss,llll // ASSGN SYSnnn,DISK,VOL=vvvvvv,SHR
Manual definition of work files, when not using DSMODELs
// DLBL wxnnnnn,'user.workfile',,SD // EXTENT SYSnnn,vvvvvv,,,sssss,llll // ASSGN SYSnnn,DISK,VOL=vvvvvv,SHR
DB File definitions when running the unload phase, if not using dynamic allocation
// DLBL unlddb,'user.unlddb',,DA // EXTENT SYSnnn,vvvvvv // ASSGN SYSnnn,DISK,VOL=vvvvvv,SHR
DB File definitions when running the reload phase, if not using dynamic allocation
// DLBL relddb,'user.relddb',,DA // EXTENT SYSnnn,vvvvvv // ASSGN SYSnnn,DISK,VOL=vvvvvv,SHR
SORT work file assignments when running the reload phase
// DLBL SORTWK1,'sort.work.file' // EXTENT SYSnnn,vvvvvv,,,sssss,llll // ASSGN SYSnnn,DISK,VOL=vvvvvv,SHR
Field Descriptions:
File-ID of the REORG control file containing control information. The block size is 4096 bytes, and must be specified in SYSIDMS using the FILENAME=RORGCTL RECFM=F BLKSIZE=4096 parameters. For a complete description of SYSIDMS parameters, see the CA IDMS Common Facilities Guide.
File-ID of the file containing JCL for automatic job submission. The block size must be a multiple of 80 bytes, and must be specified in SYSIDMS using the FILENAME=RORGJCL RECFM=F BLKSIZE= parameters.
File name of the DLBL for a work file. It must match the name generated in the Unload/Reload Work File Summary report.
File-ID of a work file when manually allocating work files.
File name of the DLBL for an unload database file.
File-ID of the unload database file, this is source database file.
File name of the DLBL for a reload database file.
File-ID of the reload database file, this is the target database file.
The internal run-time DMCL file structures have been enhanced. Storage for information related to dynamic allocation is only allocated when needed. This storage can also be added with DCMT commands even if the DMCL previously contained no dynamic allocation information. Any DSN specified in the DMCL definition or through the JCL is saved when changed with a DCMT VARY FILE command, and is reported by a DCMT DISPLAY FILE command. Additionally, these changes enable dynamic allocation of journal files.
To implement these changes, dynamic allocation information has been removed from the file control block (FCB) and moved to a new FDSA control block. There can be multiple FDSAs chained off the FCB: one representing the data set as it is defined in the JCL, one representing the data set as it is defined in the DMCL, and one representing the data set as defined by a DCMT command.
Snap enhancements include the following:
Use the system generation SYSTEM statement to specify whether to write system or task snap dumps or system or task photo snaps for system or task abends on a DC/UCF system.
Syntax
►►─┬──────────┬─ SYStem dc/ucf-version-number ─ . . . ──────────────────────────► ├─ ADD ────┤ ├─ MODify ─┤ └─ DELete ─┘ ►─┬──────────────────────────┬─────────────────────────────────────────────────► └─ SNAp SYStem is ─┬─ ON ◄─┤ └─ OFF ─┘ ►─┬────────────────────────────────┬───────────────────────────────────────────► └─ SNAp SYStem PHOto is ─┬─ ON ◄─┤ └─ OFF ─┘ ►─┬────────────────────────┬───────────────────────────────────────────────────► └─ SNAp TASk is ─┬─ ON ◄─┤ └─ OFF ─┘ ►─┬──────────────────────────────┬─────────────────────────────────────────────► └─ SNAp TASk PHOto is ─┬─ ON ◄─┤ └─ OFF ─┘
Parameters
Specifies whether to write a system snap dump to the DC/UCF log file. A system snap dump writes a formatted display of the resources allocated to all active tasks.
Enables the writing of a system snap dump. This is the default for the ADD SYSTEM statement.
Disables the writing of a system snap dump.
Specifies whether to write a system photo snap to the DC/UCF log file. A system photo snap provides a summary of resources for all active tasks.
Enables the writing of a system photo snap. This is the default for the ADD SYSTEM statement.
Disables the writing of a system photo snap.
Specifies whether to write a task snap dump to the DC/UCF log file. A task snap dump writes a formatted display of the resources allocated to the task being snapped.
Enables the writing of a task snap dump. This is the default for the ADD SYSTEM statement.
Disables the writing of a task snap dump.
Specifies whether to write a task photo snap to the DC/UCF log file. A task photo snap provides a summary of the resources for the task being snapped.
Enables the writing of a task photo snap. This is the default for the ADD SYSTEM statement.
Disables the writing of a task photo snap.
Usage
Task Snap Dump and System Snap Dump
A task snap dump can provide useful information when developing and debugging user programs. Typically, a task snap dump includes the following areas at a minimum:
If a task photo snap is requested, the following information is included in the beginning of the task snap dump:
For each allocated resource, the following information is included:
A system snap dump provides the same information for all active tasks that a task snap dump provides for a single task. In addition to those areas, a system snap dump includes information for the following areas at a minimum:
If a system photo snap is requested, the following information is included in the beginning of the system snap dump for each active task:
For each allocated resource, the following information is included:
More Information
Use the DCMT VARY PROGRAM command to dynamically enable system or task snap dumps for a DC/UCF program or to disable snaps which have been dynamically enabled.
Syntax
►►─── DCMT ─┬───────────────────┬─────────────────────────────────────────────► └─ broadcast-parms ─┘ ►─── Vary PRogram program-specification ─────────────────────────────────────► ►─┬─ . . . ───────────────────┬──────────────────────────────────────────────►◄ └─ SNAp ─┬─ snap-options ─┬─┘ └─ LIMit nnn ────┘
Expansion of snap-options
►─┬─ SYSTEM ─┬───┬─────────┬───┬─ ON ──┬──┬─────────────┬────────────────────► └─ TASK ───┘ └─ PHOTO ─┘ └─ OFF ─┘ └─ LIMIT nnn ─┘
Parameters
Specifies the type of snap dump or photo snap to write to the DC/UCF log file.
Valid values are the following:
Specifies whether to write a system snap dump for the specified program. A system snap dump writes a formatted display of the resources allocated to all active tasks.
ON Enables the writing of a system snap dump.
OFF Disables the writing of a system snap dump.
Specifies whether to write a system photo snap for the specified program. A system photo snap provides a summary of resources for all active tasks.
ON Enables the writing of a system photo snap.
OFF Disables the writing of a system photo snap.
Specifies whether to write a task snap dump for the specified program. A task snap dump writes a formatted display of the resources allocated to the task being snapped.
ON Enables the writing of a task snap dump.
OFF Disables the writing of a task snap dump.
Specifies whether to write a task photo snap for the specified program. A task photo snap provides a summary of the resources for the task being snapped.
ON Enables the writing of a task photo snap.
OFF Disables the writing of a task photo snap.
Specifies the total snaps allowed for the specified program. When the snap limit is reached, snaps are disabled for the program. The maximum snap limit value is 999.
Example
DCMT VARY PROGRAM program-id SNAP TASK ON LIMIT 5
V PROGRAM ADSOMAIN SNAP TASK ON LIMIT 5 IDMS DC262015 V210 USER:JBC TASK SNAP VARIED ON FOR PROGRAM IDMS DC262016 V210 USER:JBC SNAP LIMIT FOR PROGRAM VARIED FROM 000 TO 005
More Information
Use the DCMT VARY TASK command to dynamically enable system or task snap dumps for a DC/UCF task or to disable snaps which have been dynamically enabled.
Syntax
►►─── DCMT ─┬───────────────────┬─────────────────────────────────────────────► └─ broadcast-parms ─┘ ►─── Vary TAsk task-code ────────────────────────────────────────────────────► ►─┬─ . . . ───────────────────┬──────────────────────────────────────────────►◄ └─ SNAp ─┬─ snap-options ─┬─┘ └─ LIMit nnn ────┘
Expansion of snap-options
►─┬─ SYSTEM ─┬───┬─────────┬───┬─ ON ──┬──┬─────────────┬────────────────────► └─ TASK ───┘ └─ PHOTO ─┘ └─ OFF ─┘ └─ LIMIT nnn ─┘
Parameters
Specifies the type of snap dump or photo snap to write to the DC/UCF log file.
Valid values are the following:
Specifies whether to write a system snap dump for the specified task. A system snap dump writes a formatted display of the resources allocated to all active tasks.
ON Enables the writing of a system snap dump.
OFF Disables the writing of a system snap dump.
Specifies whether to write a system photo snap for the specified task. A system photo snap provides a summary of resources for all active tasks.
ON Enables the writing of a system photo snap.
OFF Disables the writing of a system photo snap.
Specifies whether to write a task snap dump for the specified task. A task snap dump writes a formatted display of the resources allocated to the task being snapped.
ON Enables the writing of a task snap dump.
OFF Disables the writing of a task snap dump.
Specifies whether to write a task photo snap for the specified task. A task photo snap provides a summary of the resources for the task being snapped.
ON Enables the writing of a task photo snap.
OFF Disables the writing of a task photo snap.
Specifies the total snaps allowed for the specified task. When the snap limit is reached, snaps are disabled for the task. The maximum snap limit value is 999.
Example
DCMT VARY TASK ADS SNAP SYSTEM ON LIMIT 3
V TASK ADS SNAP SYSTEM ON LIMIT 3 IDMS DC261020 V209 USER:JBC SYSTEM SNAP VARIED ON FOR TASK IDMS DC261021 V209 USER:JBC SNAP LIMIT FOR TASK VARIED FROM 000 TO 003
More Information
The DCMT D SNAPS command output is modified to include the status of all active snap overrides entered for TASK or PROGRAMS.
Examples
DCMT DISPLAY SNAP
D SNAPS *** DISPLAY SNAP REQUEST *** SYSTEM SNAP STATUS IS OFF (DISABLED) SYSTEM SNAP PHOTO STATUS IS OFF (DISABLED) TASK SNAP STATUS IS OFF (DISABLED) TASK SNAP PHOTO STATUS IS OFF (DISABLED) Snap Overrides Pgm/Task Type Limit Task Task Photo System System Photo JBC1 ASM 12 x x ADSOMAIN ASM 3 x RHDCD0EV ASM x x x JBCABORT ADS 3 x x JBCTASK2 TSK 999 x
DCMT DISPLAY SNAP With No Overrides Found
D SNAPS *** DISPLAY SNAP REQUEST *** SYSTEM SNAP STATUS IS ON (ENABLED) SYSTEM SNAP PHOTO STATUS IS ON (ENABLED) TASK SNAP STATUS IS ON (ENABLED) TASK SNAP PHOTO STATUS IS ON (ENABLED) No Program/Task Overrides Found
More Information
CA IDMS now supports large format single volume files in z/OS for database and journal files and both large and extended format for work files dynamically created by the REORG utility. Both large and extended format files can have more than 65,535 tracks on a single volume. For more information about large and extended format files, see the IBM documentation.
This feature requires z/OS version 1.7 or later.
The ability to allocate large format database and journal files means that fewer files need to be defined, referenced, and managed leading to a reduction in the administrative effort associated with large database environments.
To use this feature, define a database or journal file whose size in tracks exceeds 65,535. When creating the file, specify DSNTYPE=LARGE in your JCL and be sure to allocate the file on a single volume.
If you want to combine existing smaller files into fewer larger files, use the following procedure:
The ability for the REORG utility to dynamically create large and extended format files makes work file allocation easier when reorganizing large databases.
To direct REORG to create large or extended format work files, specify the new DSNTYPE parameter as described below in one or more associated DSMODEL statements.
CREATE DSMODEL Statement
The CREATE DSMODEL utility statement has been extended in r17 to allow the specification of the DSNTYPE parameter as a data set attribute.
Syntax
Expansion of dataset-attribute-spec
►►──┬─ . . . ─────────────────┬─────────────────────────────────────────────►◄ └─ DSNTYPE ─┬─ EXTREQ ──┬─┘ ├─ EXTPREF ─┤ ├─ LARGE ───┤ └─ BASIC ───┘
Parameters
Specifies the type attribute for new SMS-managed data sets. DSNTYPE overrides the DSNTYPE defined in the data class of a new data set. If SMS is not active, DSNTYPE is ignored.
Specifies extended format. This option is valid for VSAM and sequential data sets only.
Specifies extended as the preferred format. The data set will be allocated as extended if it is either VSAM or sequential; otherwise, it will be allocated as a basic format data set.
Specifies large format. This option is valid for sequential non-VSAM data sets only.
Specifies basic format. This option is valid for sequential non-VSAM data sets only.
Usage
Extended and large format files
Large and extended format data sets can have more than 65,535 tracks on a single volume, making them particularly useful for storing large amounts of data. For more information about the characteristics and limitations associated with extended and large format files, refer to the appropriate IBM documentation.
For more information about the REORG and CREATE DSMODEL utility statements, see the CA IDMS Utilities Guide.
This section describes the enhancements made to the SVC.
This feature prevents the unintentional installation of the unsecured version of the SVC on z/OS systems only.
The CVKEY is now a mandatory parameter with no default value in both the SVC and the install procedure. In addition to the existing valid values of 1 through 15, a value of * can be used to indicate that the unsecured SVC should be generated.
The following steps are required prior to performing the install procedure and any subsequent rebuilds of the SVC:
Module IDMSMSVA has been added to the list of modules required to be present when CAIRIM is run to load an r17 SVC.
CAIRIM can now be used to refresh a copy of IDMSMSVA or RHDCSSFM without replacing the SVC by using the following form of the REFRESH parameter:
PRODUCT(CA IDMS) VERSION(GJH0) INIT(GJH0INIT) PARM(REFRESH(module-name))
Note: When a module is refreshed, all CVs and batch IDMS jobs that are using the module being refreshed must be ended prior to the REFRESH. Once the module has been refreshed, CVs and batch jobs can be restarted.
The r17 version of RHDCSSFM is downward compatible. If you are using an earlier release of CA IDMS, the previous version of this module may not have been refreshed when the r17 SVC was installed. This module should be explicitly refreshed.
Note: For more information, see the CA IDMS Installation and Maintenance Guide—z/OS.
When dynamically allocating a data set on z/OS, local jobs and CV startup will now optionally wait for the DSN if it is in use by another job. To enable waiting, you must specify one of the following new SYSIDMS parameters with the appropriate option selected:
Specify ON to force dynamic allocation to do an ENQ wait for the DSN until it becomes available.
Specify OFF to allow the dynamic allocation request to fail when a DSN is not available.
When the DYNALLOC_WAIT_SECONDS option is specified with a non-zero value, this option is ignored.
This option applies to local mode jobs and to CV startup.
Specifies the number of seconds that dynamic allocation waits when a DSN is unavailable. After waiting, the request is retried and if the DSN is still unavailable, the process repeats until it is successful or the job is cancelled.
Specify zero seconds to allow the dynamic allocation request to fail. If specified, the DYNALLOC_WAIT option can override this option.
If this option is specified with a non-zero value, it overrides the DYNALLOC_WAIT option.
This option applies to local mode jobs and to CV startup.
Note: The IDMSMSVA module is required to use this feature. It must beloaded with the r17 SVC. See Load the SVC Using CAIRIM for a description of CAIRIM changes.
Note: For more information about SYSIDMS, see the CA IDMS Common Facilities Guide.
The IDMSIOX2 Pre-Open exit call now supports forcing the database file to input mode by setting a new IOX2INPUT flag. If the Pre-Open exit sets this flag, the database file is opened in input mode and does not get reopened in update mode on a WRITE. If the IDMSIOX2 Pre-Write exit does not intercept a write request, an error is issued.
The IDMSIOX2 Pre-Write exit also supports a new IOX2REOPEN flag that causes the database file to be reopened on the next write call. The file open mode does not change for the current write. If the IDMSIOX2 Pre-Open exit does not force the file to input mode on the reopen, it is opened in update to satisfy the write. This allows the exit to control the open mode for a database file.
The IOX2INPUT and IOX2REOPEN flags are documented in the #IOX2DS copy book.
The JCL LABEL=(,,,IN) option is now honored for EXCP files. When specified, the file is opened in input mode. Any writes to this file result in a write error. This option is not supported by dynamic allocation or preserved if a file is deallocated. This option is independent of the IDMSIOX2 open mode support and overrides options set by the exit.
When CV starts up there will no longer be an automatic outstanding reply on the operator console. This is the way it was prior to CA IDMS r15. If the operator wishes to enter a command they must use the z/VSE MSG XX command in one of two ways.
Issue MSG XX,DATA=ABC where XX is the partition Id and ABC is a DC/UCF operator or task command. The command will be processed and the results displayed. With this form there will never be an outstanding reply id.
Issue MSG XX where is XX is the partition number. DC will respond with a "XX-nnnn REPLY WITH REQUEST TO IDMS VNN" prompt where nnnn is the replid and NN is the DC/UCF system number. The operator can then reply to this number and DC will prompt for another reply. The outstanding reply will be reissued after passing each command to DC/UCF until the operator replies with a null command. At this point the prompt will not be reissued, and there will be no outstanding reply. This allows the operator to enter multiple commands without having to enter MSG XX each time. The operator can leave the outstanding reply on the console for as long as they wish, or can terminate it whenever they wish.
You may now generate one SVC using the most recent release of CA IDMS and use that SVC for previous releases of CA IDMS which are still supported. Generating an SVC for each release is still supported but not recommended.
|
Copyright © 2009 CA.
All rights reserved.
|
|