Migration Processes

Program Migration

Migration of programs, JCL and other related members follows the normal migration process through the MIG option on SPX. Compile and Assembly options for SCT programs that are not DB2 use the 204 through 208 load procs. Options for systems that use DB2 use the 301 through 314 options.

In addition, a semi-foolproof system has been put in place to handle SCT compiles and assemblies. If an SCT load proc is specified, the MGC table is accessed to fetch the appropriate SCT options. Some programs are option-sensitive and others require compiling in both the batch and online environments. This table is intended to make sure options are correctly specified.

Screen and Procedure Migrations

Screen and procedure migrations are initiated using the ZST option under SPX. That screen looks as follows:


------------------  Z-Series Screen/Procedure Transfer  -----------------------
Command ===>

  Type ===> SCREEN         (Screen/Procedure)

Transfer Specifications:
  System ===>              Systems:  000 = ZSS
  Member ===>                        001 = SIS
                                     002 = FRS
                                     003 = HRS
                                     005 = LMS
                                     010 = ZVR
Press END to Exit
-------------------------------------------------------------------------------

The limitation here is that only one screen or procedure can be specified at a time. If you have several screens or procedures, you can do a direct IDCAMS REPRO from the screen file (AUP08V.ZSS.xxxx.ZsFILE) or procedure file (AUP08V.ZSS.xxxx.ZPFILE), where xxxx is TEST, INST or INST2, to the transfer files (AUP08V.ZSS.PROD.ZSTRANS for screens and AUP08V.ZSS.PROD.ZPTRANS for procedures). When doing this, the key on the ZPFILE and ZSFILE is a 6 character field. The first 3 characters represent the system (e.g., 000, 001, 002, 003, 005, 010) and the second 3 characters represent the screen or procedure name.

Then a request must be made to the production scheduling office to schedule the jobs which migrate screens and procedures. AU3101Zx is used to migrate screens and AU3102Zx is used to migrate procedures, where x is the appropriate Z-Version for the system needed. If procedures are being migrated, nothing further needs to be done. If screens are being migrated in conjunction with a DBD process for that system, nothing further needs to be done as long as the AU3101Zx job runs before the DBD process. If a DBD process is not being run, AU3118Zx must be run to force appropriate screen/DBD synchronization.

DBD Migration

When DBD changes are made, the appropriate DBD source members need to be migrated. Once the member(s) is(are) migrated, a DBD process needs to be scheduled through the production scheduling office. Just ask for the DBD process for the desired system. The process consists of AU3115Zx (edit), AU3119Zx (file close), Au3120Zx (update) and AU3121Zx (file open/table load), where x represents the Z-Version for the desired system.

Online Documentation Update

Online documentation updates are somewhat similar to the DBD migration process. A text member is updated, migrated to production, and a production job then appropriately updates the online documentation file. Two sets of members exist. The first is for SCT-supplied online documentation updates. It is ZIDxxx, where xxx is the SCT system number (e.g., 000, 001, 002, 003, 005, 010). The second is ZUDxxx and contains user-supplied documentation updates. When these members are created, they should replace previous contents rather than be added to previous contents.

Once the appropriate member(s) is(are) migrated, the AU3305Zx job should be scheduled to run. It does the actual update of the online documentation system.

OIT Applications Support

Last Modified: Tuesday, 02-Mar-2004 13:51:44 CST