This chapter describes the considerations and actions that you must take to upgrade from r16 to r17 of CA IDMS.
This section contains the following topics:
Recompiling User-Written Programs
Increasing Storage and Program Pools
Updating Task and Program Definitions
Updating Dictionary Descriptions
Deprecated and Stabilized Features
New Reserved Profile Attribute
You can upgrade to r17 from CA IDMS Releases 10.x, 12.0, 14.0, 14.1, 15.0, or 16.0. The CA IDMS r17 installation tape contains the conversion utilities needed to upgrade from all releases other than 10.x.
The CA IDMS r17 Release Summary describes the actions required to upgrade from r16 to r17 of CA IDMS. If you are upgrading to CA IDMS r17 from a release prior to CA IDMS r16, we recommend that you review all the intervening CA IDMS Release Summary documents for the cumulative requirements for your upgrade.
The following is a summary of actions required to upgrade the CA IDMS software from r16 to r17:
Follow the instructions documented in the CA IDMS installation guide for your operating system. Also, follow any special installation instructions outlined in the cover letter delivered with the installation tape. Be sure to install the r17 software into a new set of installation libraries. If you install r17 into your existing CA IDMS SMP/E or MSHP libraries, the results can be unpredictable.
A new SVC is delivered with r17. It should be used for all r17 systems. The SVC is downward compatible and can be used with Releases 14.1, 15.0, and 16.0 systems.
The procedure for installing the SVC has changed slightly in r17. For more information, see SVC Enhancements.
The content of journal files is changed slightly in r17. You must initialize the journal files using the r17 FORMAT utility statement before the journal files can be used with an r17 system. At startup, the system verifies that the journal files are in the correct format.
If it is necessary to fall back to an earlier release of the software, the journal files must be reinitialized using the FORMAT utility and runtime libraries from the earlier release, otherwise warmstart fails.
Journal File Changes
The content of disk journal files is changed in r17 in the following ways:
The content of archived journal files is also changed in the following ways:
These changes may impact user and third party software that directly access journal files.
The format of the log file's statistics records is unchanged in r17, although the release identifier in these records is updated and contains the string 'R170'. If CA IDMS encounters a log record with an earlier release identifier, the ARCHIVE LOG utility issues the warning message:
NON 17.0 RECORD HAS BEEN ENCOUNTERED IN THE LOG, RECORD WILL BE BYPASSED
To avoid these messages and to separate logs from prior releases, offload the log file using the ARCHIVE LOG utility before installing r17 or initialize the log file if you do not need the log information.
If it is necessary to fall back to an earlier release of the software, any log file accessed by an r17 system must be offloaded or initialized prior to its use by a pre-r17 system.
This section describes the upgrade requirements for the CICS interfaces.
Before a CICS system can use the r17 CA IDMS runtime library, you must create new IDMSINTC interface modules and UCF front-ends (if applicable) using the r17 source, macro, and object libraries. However, you do not have to create new IDMSCINT or IDMSCINL modules or relink user applications when upgrading to a CA IDMS r17 system.
The CICS IDMSINTL interface has been stabilized at the r16 level. For the applications that use this interface, we recommend using the IDMSINTC interface instead. You do not have to change or relink the application programs that were using IDMSINTL to use IDMSINTC. You can create an IDMSINTC interface module by compiling a CICSOPT with the same invocation parameters as the IDMSINTL interface being replaced.
Starting with r15, the IDMSINTC CICS interface module is delivered as an object module. It is installed using SMP/E and can be maintained using SMP/E. Various exits and parameterized options are provided so that all users can take advantage of this improved delivery method. The IDMSINTC macro is no longer delivered in source form.
In compliance with all current releases of CICS, the r17 version of IDMSINTC no longer supports macro level programs. Should you still have such programs, they must be converted to command level before upgrading to the r17 version of the CICS interface.
Install the CA IDMS r17 entity definitions into the CICS CSD. These definitions are contained in the installed source library members CICSCSD and CICSCSD2. Consult the appropriate IBM documentation to ensure that these definitions take precedence over any previously installed definitions for the corresponding entities.
If you issue SQL requests from CICS applications, ensure that the IBM Language Environment runtime support is available in the CICS region.
If you are upgrading the CICS interface from versions earlier than r16, additional actions may be required, such as establishing a unique identifier for the CICS system and defining a resynchronization task and program.
Note: For more information, see the CA IDMS r16 Release Summary or the CA IDMS System Operations Guide.
Several control block formats are changed in r17. Although in most cases, the only changes are the addition of new fields, we recommend that you recompile all programs, such as user-written exits, that reference CA IDMS control blocks using the r17 library.
Any program that directly accesses the DMCL run-time structures can be impacted by changes in the way data set information is recorded.
Note: For more information, see Run-time DMCL File Management.
Two records in the TCP/IP API interface were modified in CA IDMS release 17. The affected records are:
Recompile all programs making reference to these records (COBOL, PL/I, and ADS) when upgrading to CA IDMS release 17.
It may be necessary to increase the size of the XA storage pool (pool 255) due to increased storage requirements. Transactions that use SQL require about 80 KB additional XA storage in pool 255.
In most cases, no changes are needed to CA IDMS execution JCL. However, the following conditions may require updating this JCL to successfully upgrade to CA IDMS r17:
If the LE runtime library is not in the linklist, it must be added to the execution JCL if it is not already present. For CV and batch, this means adding the LE SCEERUN load library to the CDMSLIB concatenation if CDMSLIB is used; otherwise, adding it to the STEPLIB concatenation. For CICS, this means enabling the CICS LE runtime support as described in the appropriate IBM documentation.
Note: For more information, see Change Tracking.
Note: For more information about creating a SYSIDMS load module, see the CA IDMS Common Facilities Guide.
New CA-supplied task and program definitions are provided for r17. You should update the system definition using the batch sysgen compiler RHDCSGEN and source members provided on the installation tape. This can be accomplished by taking the following steps:
Note: For more information on the UPGRADE install process, see the CA IDMS installation manual for your operating system.
If it is necessary to fall back to an earlier release of the software, you can recreate the earlier versions of the task and program definitions by reinstalling them from the installation tape provided with the earlier release or by restoring the system dictionary from a backup that was taken prior to the upgrade. If returning to r15 or r16, it is not necessary to restore the earlier version of the task and program definitions.
New fields are added to the JOURNAL-1043 record in the IDMSNTWK schema and the IDMSNWKG subschema. You should update the definition of these records in every dictionary containing the IDMSNTWK schema description. To do this, use the IDMSDIRL utility. For more information about executing this utility, see the CA IDMS Utilities Guide.
You should also update each of your application dictionaries using the DLOD members appropriate to your environment. For more information, see the installation materials provided with the r17 installation tape.
CA IDMS Visual DBA and CA IDMS SQL users should take the following steps to update every catalog in which the SYSCA or SYSTEM schemas are defined:
Any catalog, including non-SQL defined catalogs, may require special handling if falling back to an earlier release of CA IDMS. For more information, see Fallback Considerations.
CA IDMS Visual DBA and CA IDMS SQL users should use the CONVERT CATALOG command to update the definitions of system tables in each catalog in which the SYSTEM schema is defined.
When an r16 format catalog is converted, the definitions of the following tables are upgraded to their r17 definition and new columns in associated rows are initialized appropriately:
Changes introduced in earlier releases of the software are applied if they have not already been made. For a description of the changes made in earlier releases of CA IDMS, see the CA IDMS r16 Release Summary.
Note: If IDMSDBAN is run against a newly migrated catalog area it is very possible that numerous 598516 errors indicating a record length different than the subschema length will be found. These conditions are acceptable and will not create any run-time problems for IDMS. These conditions will be rectified the next time the record occurrences are updated by IDMS. Rows associated with the SYSTEM.JOURNAL table are updated by the ALTER JOURNAL statement of the DMCL compiler and rows related to the SYSTEM.TABLE table are altered by the ALTER TABLE command.
The CONVERT CATALOG utility can be invoked using the online command facility (OCF) or the batch command facility (IDMSBCF). If running in local mode or if converting from Release 12.0 or 12.01, you should back up the target catalog before executing this utility.
To convert a catalog to r17 format, enter the following statement:
►►─── CONVERT CATALOG ──────────────────────────────────────────────►
After successful execution, CA IDMS issues one of the following informational messages to indicate the status of the conversion:
CA IDMS Visual DBA and CA IDMS SQL users should update the SYSCA schema definition in each catalog in which the SYSCA schema is defined. This process varies slightly depending on your current release of CA IDMS. For more information about the required steps, see the installation materials provided with the r17 installation tape.
The following new procedures are defined to the SYSCA schema for r17 and are downward compatible with prior releases of CA IDMS:
The changes implemented by the r17 catalog conversion utility are downward compatible with r14 and later releases of CA IDMS. If it is necessary to fall back to one of these earlier releases, no further action needs to be taken regarding the catalog.
Should it be necessary to reorganize (or unload and reload) a catalog updated by r17 CA IDMS after falling back to an earlier release, it may be necessary to do so using the r17 version of the IDMSCATZ subschema rather than the earlier version. This further action is necessary only if the catalog contains disk journal definitions and one of the following actions took place under r17 of CA IDMS:
Important! Converted definitions are not downward compatible with Release 12.0 or 12.01 of the software. For this reason, if you are upgrading from either of these releases, you should retain backup files of the catalog before converting it. Should it be necessary to fall back, you must restore the catalog and any database areas containing tables that were created or altered using the r17 version of the software.
This section describes the impact of r17 on the support of features available in earlier releases of CA IDMS.
Support for CA IDMS agent technology has been dropped on all releases of CA IDMS.
Support for the Fujitsu-Siemens BS2000/OSD operating system has been stabilized at the r16 level.
The CICS IDMSINTL interface has been stabilized at the r16 level. For more information, see Creating New CICS Interface Modules.
The r17 version of IDMSINTC no longer supports macro level programs. For more information, see Deprecated Macro Level Support.
Support for optional APAR OPT00224 has been replaced with the SYSIDMS parameters described in Wait for In-Use Data Set.
Support for optional APAR OPT00135 has been removed. Retaining the offline status of an area across CV shutdowns can instead be achieved by using the PERMANENT option of the DCMT VARY AREA/SEGMENT command. A warning will be issued at CV startup if CA IDMS detects that this APAR is applied.
Support for SYSIDMS parameters TCP/IP_MAXIMUM_SOCKETS and TCP/IP_MAXIMUM_SOCKETS_PER_TASK is replaced with parameters on the new TCP/IP SYSGEN statement described in New TCP/IP System Entity.
The IPINFO option of the DCMT DISPLAY LINE command is no longer supported for a SOCKET LINE. The information can now be obtained using the DCMT DISPLAY TCP/IP ALL command.
Note: For more information, see DCMT DISPLAY LINE Command.
EXTIDENT is now a CA-reserved profile attribute used to represent the external identity for a user session. If you have used this name for a user-defined attribute, you must select another name and update all places in which it is referenced.
Note: For more information about the EXTIDENT profile attribute, see External Identity Auditing.
The way in which CV startup manages the run-time DMCL structures is changed in r17. In earlier releases, CA IDMS builds the run-time DMCL twice: once before warmstart and again during CV startup. The first run-time DMCL is deleted before the second is built.
In r17, the run-time DMCL is built only once. This occurs prior to warmstart, and the resulting structures are retained in memory throughout CV's execution. This change may impact user and third party software that directly access the run-time DMCL.
This change may also require the use of a new CV_STARTUP_XA_REGION_MB SYSIDMS parameter for CVs whose DMCL is extremely large. This new parameter allows for larger XA storage pool allocation during the initial stages of CV startup to hold the run-time DMCL.
Specifies the size of the initial XA storage pool acquired during early CV startup.
Specifies the size in MB (megabytes) of the initial XA storage pool.
32 MB
Note: The XA storage used for CV startup is internally converted to a dynamic extension of XA storage pool 255 that is fully used. This may impact user and third party software that directly access the IDMS storage management control blocks.
|
Copyright © 2009 CA.
All rights reserved.
|
|