Special Notes for Upgrades

The upgrade process consists of the upgrade itself, fall back, and fall forward. Each of these processes has a highly customized defined MUF. The communication protocol is only LOCAL for the upgrade processes. Therefore, no XCF or CCI is configured for support during these upgrade processes. All the jobs run on the same LPAR.
The upgrade process consists of the upgrade itself, fall back, and fall forward. Each of these processes has a highly customized defined MUF. The communication protocol is only LOCAL for the upgrade processes. Therefore, no XCF or CCI is configured for support during these upgrade processes. All the jobs run on the same LPAR.
Review the following information before performing an upgrade.
Before You Begin
You must have adequate backups of your SMP/E and 
CA Datacom®
 environments before beginning the upgrade. If there is a problem at any point, these backups are available for use.
CA Datacom®/DB
 at Version 15.0 supports the CXX set as Version 14.0 at Level 1. Version 15.0 CXX does not exist. Even an INIT using the Version 15.0 code line initializes the CXX as Version 14.0. Therefore, it is much easier upgrading from Version 14.0 to Version 15.0 and any possible downgrade or fall back from Version 15.0 to Version 14.0. The Version 15.0 code line accepts as input to a LOAD AREA=CXX or CXXCLONE backups produced by Versions 15.0 downward through Version 10.0 backup. A Version 15.0 backup is also accepted as input to a Version 14.0 LOAD AREA=CXX or CXXCLONE. However, older versions do not support it.
CA Datacom®/DB
 at Version 15.0 uses a database format in the CXX of 3 whereas Version 14.0 uses a database format of 2. If Version 15.0 opens a format 2 database, it automatically converts it to format 3 and issues a message. If Version 14.0 opens a format 3 database, it automatically converts it to format 2 and issues a message.
 Use DATCOMIN as a short form of DATACOM-INSTALL USER. If your site has a user ID length restriction of eight (8) characters or less, use DATCOMIN instead of the longer name. DATACOM-INSTALL is the user name for the 
CA Datacom® Datadictionary™
 -USR statement.
New Installation Requires SIMPLIFY
The new install process uses the Simplify feature of 
CA Datacom®/DB
. To use the full Simplify feature, the same MUF data set naming standards are required. The naming conventions for your site can be different.
Before starting your new installation, see the Simplify Feature and Simplify Considerations pages
CAI.NEWHLQ.9CXX_NAME.V150.* where asterisk (*) defines CUSLIB, CUSMAC, and CUSPROC. CAI.NEWHLQ.9CXX_NAME.* defines all the database areas and MUF control data sets except the PXX. The install process controls the last node for these data sets. 9CXX_NAME and MUF name are the same value in this dialog. The CAI.NEWHLQ can be a user-defined length of 19 bytes. Due to data sharing requirements, the CXX name should only be a maximum value of 7 bytes. V150 is 4 bytes and sometimes, the last node uses all 8 bytes. For example, CAI.NEWHLQ2.9CXX_NAME.AREANAMEDBID. CAI.NEWHLQ can be one node or as many nodes as you can use within the 19-byte restriction.
The following examples show what you see if the CXXNAME is PRODMUFA:
Once the customization is done, this new installation process performs loads for all bases. Every possible base is loaded on this installation. After completing the loads, the CICS portion that builds the VLS files are generated in the next job. No MUF is used during the new installation process. The IVP process requires you to bring up a MUF to verify that the installation was successful. A sample MUF member, MUFSTRTS, in the **.INSTJCL is provided for your use. The libraries must be APF authorized for the MUF. Make any required changes to the DBDATIN2 member before attempting to use this MUF.
DQ backup from the new install loads functional 
CA Dataquery™ for CA Datacom®
 systems through DBUTLTY LOAD. To modify the 
CA Dataquery™ for CA Datacom®
 options, refer to **.CABDSAMP in member DQSIM01. Copy it to another place to modify it. SMP/E controls **.CABDSAMP so this PDS is not an appropriate place to edit or save.
The System Identification Block (SID) assembly assumes the full implementation for Simplify and all its protections. Do not remove any of the SID options that deal with Simplify. 
This naming standard is a recommended best practice. With this fully implemented feature, MUF and DBUTLTY no longer need the DD cards for CXX/LXX/FXX. When the Simplify feature is installed, the primary benefit is that the DB RC 46/51 should be eliminated. Another benefit is that the MUF has full ownership of the CXX except for a few DBUTLTY functions that can run with MUF down. Your MUFs have more protection against a database outage by init/load going to the wrong CXX/MUF after implementing this feature.
Upgrade Process Key Points
The upgrade process uses its own specially configured MUF. Use the MUF startup as it is defined. The System Identification Block (SID) uses a MUF name of UPGRMUF that helps to identify the SID for this process. Once the upgrade process is complete, modify the SID to be a unique name for your location. This upgrade process assumes Simplify is not defined or used. The CXX name is not changed during this upgrade.
To change the CXX name, change it before you start the upgrade process under Version 14.0. Or, you can wait for completion of the upgrade process and no chance for fall back to Version 14.0. if your site needs the change after you upgrade to Version 15.0, the DBUTLTY CXX clone functions help with the changeover to a new CXX NAME. Until fall back to Version 14.0 is fully eliminated or possible, do not use any new 
CA Datacom®
 Version 15.0 product family features.
Fall back and fall forward actions use soft fall back and soft fall forward processes for Version 14.0. If you have any issues with the fall back process and SQL objects or 
CA Datacom® Datadictionary™
 changes are no longer needed after upgrading to Version 15.0, use the BDUPG03R to perform a hard fall back. However, any changes to the CXX, DD, and DDD can be lost. Also, SQL DEFAULT DBID (typically base 16) is not captured as part of this process. If you use the SQL DEFAULT base, you can add this base to the backup JOB BDUPG03.
 Hard fall back is not recommended for SQL sites except as a last resort to return to Version 14.0 for 
CA Datacom®/DB
If the standard product DBIDs are not used at your site, upgrade the process at your site to accommodate that level of change. The base upgrade assumes the DBIDs are the ones that CA recommends for use as delivered by a new product installation.
The following information is provided for sites that are not using the standard defaults:
  • URT suffix (DBID),
    URT prefix (DBURT) for example, DBURT002
    CA Datacom® Datadictionary™
     module name DDURT002
    DBID 2 for 
    CA Datacom® Datadictionary™
    • See members BDUPG02/BDUPG06/BDFBK02/BDFFW02 SYSIN for step DBMUFPR for the DICTIONARY option
    • Modify all URTS for 
      CA Datacom® Datadictionary™
    • See members BDUPG02/BDUPG06/BDFBK02/BDFFW02
      SYSIN for step DBMUFPR for DICTIONARY option
    • Modify all URTS for the DDD
DBID 1 and 10 impact the related URTs. Modification is required but only impacts the IVPs.
Review the following members for CUSMAC members to alter. If user-defined entities have been defined, update the "USRENTY" parameter on the DDSYSTBL macro assembly and the ENTFILS parameter on the DDURTBL macro assembly.
Members being moved from *.CABDSAMP to *.CUSMAC:
  • DDFILE CICS Sample DD VLS File Names
  • DBDATIN2 MUF Startup Option
  • DBDATIN4 PXX Formatting Syntax
  • DBLSTPR Master List
  • DDURTPR DD URT for Batch
  • VPEDDOFT MACRO for DD usage in Roscoe
  • DBF10PR CICS URT for DBID 10
  • DRDLIMOD Data Reporter Customization
  • DBURSPR Batch URT for part of DBID 1
  • DBURPPR SQL URT for Batch (DD/DDD)
    CA Dataquery™ for CA Datacom®
    CA Dataquery™ for CA Datacom®
    CA Dataquery™ for CA Datacom®
 These members are being moved to *.CUSMAC where any future changes can be made. However, no changes can be made to *.CABDSAMP because it is under SMP/E control.
CA Dataquery™ for CA Datacom®
 Panels Translated Versions
To keep the translated version of your 
CA Dataquery™ for CA Datacom®
 panels when you upgrade to this version, run the DQLANGMT utility with the SYSIN RUNTYPE=UNLOAD,LANG=xx to back up the translated panels. After the upgrade, run the DQLANGMT again with SYSIN RUNTYPE=LOAD and the file from the previous UNLOAD as input to put the translated panels, literals, and vocabulary on the new version files. This is the only way to migrate the translated files to this version.
To see which panels do not have translated versions, select Language Maintenance from the Administration Menu. Display lists of panels, vocabulary, or literals online to see which do not have translated versions. The online displays list the AE (American English) version first, followed by the 
 version, unless 
 happens to sort higher in the list than AE. In any case, they are together on the lists, so new ones can be easily seen.
For more information about the DQLANGMT utility, see Language Maintenance Facility Overview.
APF Authorized Libraries
The MUF 
 be run as an APF authorized job or task in Version 15.0.
Change Data Capture (CDC)
The Change Data Capture feature is still optional in Version 15.0, but if you want to implement Change Data Capture, use INSTJCL job BDCDC01. With the new installation process, the base is automatically built.
DD Comparator Process before Upgrades
CA Datacom® Datadictionary™
 has a comparator tool that can be used for Versions 14.0 and 15.0. INSTJCL member ADSDC14 is for Version 14.0 and ADSDC15 is for Version 15.0. Before you upgrade, we recommend that you run the comparator in Version 14.0 to see if your 
CA Datacom® Datadictionary™
 is a good candidate. We also recommend that you run the comparator tool for each 
CA Datacom® Datadictionary™
 that you have and for all MUF instances before attempting an upgrade. Plan at least a minimum of one month before an upgrade to perform this process. Once the MUF is at Version 14.0, you can run this tool at any time.
Contact Broadcom Support Level 1 if you have any questions or concerns about the comparator report being generated or about each MUF instance that you run.
History Database 
History Database (DBID 1007) added a new area/table to this database. With the addition of this table, all MUF instances 
 have BDHST01 and BDHST02 members executed against each MUF instance. Because of the design, if any areas for this database are missing, your definition is brought current and the missing areas will INIT/NULL load.
  • BDHST01 performs the close process to allow the BTG member BTG1007 from CABDSAMP to be cataloged to the CXX which is done in BDHST02. 
  • BDHST02 has special processes that  test specific return codes. This Job/Member can return a max return code of 00, 04 or 08 and is considered a good completion.  
All the types for creation of **.INSTJCL have these two members created as part of the process. If you have completed the upgrade to 15.1 and have no need to regenerate the **.INSTJCL PDS, you 
 copy both of these members to a private PDS where you can modify the members. Read the special instructions in each member prior to starting this process for these two members. The following PTFs were delivered for member BTG1007:
  • Change (SO06768) 
  • Functionality (SO07262)  
After you define and null load this new table, add a MUF startup option HISTORY_EVENT_TABLE set to YES  to each MUF instance. This task can 
 be done at MUF startup and not through console.
 The data in the Event History table is available for all types of access for query or reporting.
For more information, see Release Notes and Product Information.