APAR status
Closed as canceled.
Error description
5740xyr00 DB2 R410 V4 This APAR documents changes to the DB2 Administration Guide Volume 1 SC26-3265-00 which did not make Version 4.1 GA pubs. Continued in II10229. ============================================================ Version 4 Book Title: Administration Guide, Volume 1 Pages: 2-55 Change Description: The following paragraph will be added before the last paragraph on page 2-55 that starts "To create a type 2 index, use the CREATE INDEX...": The storage space required for an index depends on several factors. See "Chapter 2-2, Estimating DB2 Storage Needs" in the Installation Guide for more information on calculating the estimated space required for a Type 2 index. ============================================================ Version 4 Book Title: Administration Guide, Volume 1 Pages: 2-61 Change Description: Modify the text in Chapter 2-5 'Designing Indexes' under the heading 'Partitioned Indexes' starting with the second paragraph: | "In DB2 Version 3, if you have both a partitioned index and a nonpartitioned index on the same table, you lose some of the benefits of partition-level independence for utility operations. Concurrent utility jobs can operate independently on partitions of the table space and its partitioned index. | However, access to a nonpartitioned index must | be sequential. | In DB2 Version 4, logical partitions of a | nonpartitioned index can usually be accessed by | utilities and SQL applications concurrently. | The index must be type 2. | For more information about utility operations, | nonpartitioned indexes, and impacts of | using Type 1 or Type 2 indexes, see | "Utility Operations with | Nonpartitioned Indexes" on page 5-181. ============================================================ Version 4 Book Title: Administration Guide Volume 1 Pages: 2-146 Change Description: 5. Convert the datasets back to DB2-managed using new DB2 storage group. Use the following SQL ALTER TABLESPACE and ALTER INDEX statements: ALTER TABLESPACE dbname.tsname USING STOGROUP stogroup-name PRIQTY priqty SECQTY secqty; ALTER INDEX index-name USING STOGROUP stogroup-name PRIQTY priqty SECQTY secqty; ============================================================== Version 4 Book Title: Administration Guide, Volume 1 Pages: 2-146 Change description: Add the following information at the end of step 5 on page 2-146: If you specify USING STOGROUP without specifying the PRIQTY and SECQTY clauses, the default values are used. For more information about USING STOGROUP, see "SQL Reference". ============================================================ Version 4 Book Title: Administration Guide, Volume 1 Pages: 2-148 Modify the text for the bullet list item "The DSNTIAUL Program" as follows: "The program unloads a DB2 table into a sequential file and generates statements to allow the LOAD utility to load it elsewhere. | For instructions on using DSNTIAUL, see Section 2 | of Installation Guide." ============================================================ Version 4 Book Title: Administration Guide, Volume I Pages: 3-72, 3-88 Change Description: Page 3-72, Figure 65 (part 2), Step 4 (ID Check for Connections), add the following paragraphs after ..."DB2 rejects the request": In addition, depending on your RACF environment, the following RACF checks may also be performed: 1) If the RACF APPL class is active, RACF will verify that the ID has been given access to the DB2 APPL. The APPL resource that is checked is the LU name that the requester used when the attach request was issued. This will either be the local DB2 logical unit name (LUNAME) or the generic LU name. 2) IF the RACF APPCPORT class is active, RACF will verify that the ID is authorized access to MVS from the port of entry (POE). The POE that is used in the verify call is the requesting LU name. Page 3-72, Figure 65 (part 2), Step 5, add the following paragraph after ..."resources defined to RACF": The RACROUTE macro call will also verify that the user is authorized to use DB2 resources from the requesting system, known as the port of entry (POE); for details, see "Permit Access for Users and Groups" on page 3-88. Page 3-88, a new sub-heading under "Permit Access for Users and Groups: Distributed Data Facility: ========================== The RACF RACROUTE macro that DB2 uses allows access from remote requesters to be governed by the requesting system's logical unit name (LUNAME), the local DB2 server LUNAME, as well as the user ID. Controlling Distributed access based on requesting LUNAME --------------------------------------------------------- There are two methods that can be used to control DB2 distributed access based on the requesting system's LUNAME. The preferred method is to use the DSNR RACF class with a PERMIT specifying a conditional WHEN(APPCPORT(x)) clause. For example, the following RACF command lets subsystem DSN receive DDF requests, from user ALPHA, that originate from any partner in the network: PERMIT DSN.DIST CLASS(DSNR) ID(ALPHA) ACCESS(READ) To limit ALPHA to request coming from the partner with the LUNAME GILROY, use: PERMIT DSN.DIST CLASS(DSNR) ID(ALPHA) ACCESS(READ) + WHEN(APPCPORT(GILROY)) The second method is to use the RACF APPCPORT class instead of the RACF DSNR class. This method requires that you define an APPCPORT resource profile that specifies the requesting LUNAME and then PERMIT users access to that resource. The RACF APPCPORT class may already be active on your system and a resource profile specifying the requesting LUNAME may already exist. If this is the case and you want to use the recommended RACF DSNR class to control access, then it will be necessary to PERMIT READ access to the APPCPORT resource for those userid's that will be used with DB2. Controlling Distributed access based on local DB2 server -------------------------------------------------------- LUNAME ------ Although you can use the RACF APPL resource class to control DB2 Distributed access, it is not recommended. A better solution is to use the RACF DSNR resource class to maintain all of the DB2 access controls under the single RACF DSNR class. The RACF APPL class may already be active on your system and a resource profile restricting access may already exist. If this is the case and you want to use the recommended RACF DSNR class to control access, then it will be necessary to PERMIT READ access to the APPL resource for the userid 's that will be used with DB2. The APPL resource that is checked is the LU name that the requester used when the attach request was issued. This can be either the local DB2 LUNAME or the generic LUNAME. ============================================================ Version 4 Book Title: Administration Guide, Volume 1 Pages: 4-45 Change Description: In Figure 72, DISPLAY THREAD Showing CICS Connections, for all threads with status N, change the token value to 0. ============================================================ Version 4 Book Title: Administration Guide, Volume 1 Page: 4-83 Change Description: Add this text under "Archiving to DASD Volumes": DB2 uses the basic direct access method (BDAM) to read archive logs from DASD. DFSMS/MVS does not support reading of compressed data sets using BDAM. You should not, therefore, use DFSMS/MVS hardware compression on your archive log data sets. ============================================================ Version 4 Book Title: Administration Guide, Volume 1 Pages: 4-98 Change Description under How to Defer Restart Processing: change the bullet from: Leave the object's data sets unready.... to: Vary the device (or volume) on which the objects reside offline. If the data sets containing an object are not available, and the object requires recovery during restart, DB2 flags it as stopped and requiring deferred restart. DB2 then restarts without it. ============================================================ Version 4 Book Title: Administration Guide Volume 1 Pages: 4-120 Change Description: Under "Step 2: Copying the Data," change the second sentence to: "That operation allows only read access to the data while it is copied." ============================================================ Version 4 Book Title: Administration Guide, Volume 1 Pages: 4-121 Change Description: After sentence "Copy SYSLGRNX and SYSCOPY last." add the following sentences. Install job DSNTIJIC creates image copies of the DB2 catalog and directory table spaces. See Chapter 2 of the Install Guide for a description of job DSNTIJIC. ============================================================ Version 4 Book Title: Administration Guide, Volume 1 Page: 4-170 Change Description: Change the paragraph that begins, "If you want to disable down-level detection," to this: How to control down-level detection: Use the subsystem parameter DLDFREQ to control how often the level ID of a page set or partition is updated. DB2 accepts any value between 0 and 65535. For example, to update the level ID after every checkpoint that a page set is open for update activity, set DLDFREQ=1. To update the level ID after every fifth checkpoint that the page set is open for update activity, set DLDFREQ=5. DLDFREQ=5 is the default. To disable down-level detection, set DLDFREQ=0. Consider the following when you choose a value for DLDFREQ: - How often do you use backup and restore methods outside of DB2's control? If you rarely use such methods, you do not need to update the level ID often. - How many page sets are open for update at the same time? If DB2 updates level IDs frequently, you have extra protection against down-level page sets. However, if the level IDs for many page sets must be set at every checkpoint, you might experience a performance degradation. - How often does the subsystem take checkpoints? If the subsystem takes checkpoints frequently, the level ID can be set after a larger number of checkpoints. To activate a new value of DLDFREQ, rerun job DSNTIJUZ and restart DB2. (ref. msgDSNB232I) ============================================================ Version 4 Book Title: Administration Guide, Volume 1 Pages: 4-183 Change Description: Replace the second and third bullets under line 'Recover the BSDS:' with the following bullets. b. To determine the RBA range for this archive log use the print log map utility (DSNJU004) to list the current BSDS contents. Find the most recent archive log in the BSDS listing and add 1 to it's ENDRBA value. Use this as the STARTRBA. Find the active log in the BSDS listing that starts with this RBA and use it's ENDRBA as the ENDRBA. c. Use the change log inventory utility (DSNJU003) to register the latest archive log tape data set in the archive log inventory of the BSDS just restored. This is necessary since the BSDS image on the archive log tape does not reflect the archive log data set residing on that tape. For data sharing, running DSNJU003 is critical. Group buffer pool checkpoint information is stored in the BSDS and needs to be included from the most recent archive log. ============================================================ The documentation changes are continued in II10229.
Local fix
Problem summary
Problem conclusion
Temporary fix
Comments
closed for db2info retention
APAR Information
APAR number
II09139
Reported component name
PB LIB INFO ITE
Reported component ID
INFOPBLIB
Reported release
001
Status
CLOSED CAN
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
1995-12-18
Closed date
1997-05-01
Last modified date
1999-06-08
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
08 June 1999