mainframe manual

Migrating Applicationsfrom Vendor Libraries

to SCLM

Document Number GG24-4021-00

June 1993

International Technical Support CenterSan Jose

Take Note!

Before using this information and the product it supports, be sure to read the general informationunder “Special Notices” on page xiii.

First Edition (June 1993)

This edition applies to Version 3 Release 5 of ISPF/PDF Software Configuration and Library Manager,Program Number 5665-402 for use with MVS Version 2 Release 2 or later and TSO/E Version 2 Release 1.

Order publications through your IBM representative or the IBM branch office serving your locality.Publications are not stocked at the address given below.

An ITSC Technical Bulletin Evaluation Form for readers' feedback appears facing Chapter 1. If the formhas been removed, comments may be addressed to:

IBM Corporation, International Technical Support CenterDept. 471, Building 0985600 Cottle RoadSan Jose, California 95193-0001

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute theinformation in any way it believes appropriate without incurring any obligation to you.

Copyright International Business Machines Corporation 1993. All rights reserved.Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication ordisclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

AbstractThis book describes and documents the process used to migrate two customer applicationsfrom CA-LIBRARIAN and ENDEVOR to ISPF/PDF Software Configuration and Library Manager(SCLM). The tools developed to support the migration are included. Readers can apply thetechniques used and the experience gained during our project to migrations from anyvendor library system to SCLM.

The book is intended for project leaders, library administrators, system programmers, andapplication developers involved in migrating applications from vendor libraries to SCLM. Itassumes that users are familiar with the basic concepts of SCLM.

AD LS (171 pages)

Copyright IBM Corp. 1993 iii

iv Library Migration

Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Why Migrate to SCLM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Objectives and Scope of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Project Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Sample Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Vendor Library Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5CA-LIBRARIAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6ENDEVOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2. Preparing for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Develop Migration Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Define Organizational and Administrative Structure . . . . . . . . . . . . . . . . . . . . . . . 10Select Pilot Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Sample Application 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Release Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Sample Application 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Release Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Extract Data for the Sample Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Application 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Application 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 3. Defining SCLM Project Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 23Partitioned Data Set High-Level Qualifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Version and Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Accounting Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Technical Setup Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Chapter 4. Migrating the Control Information . . . . . . . . . . . . . . . . . . . . . . . 29Languages and Translators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

SCLM Languages Used in the Migration Project . . . . . . . . . . . . . . . . . . . . . . . 33Compilers Used in the Old Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Compiler Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Compiler Options in SCLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Finding VS COBOL II Compiler Options for Application 1 . . . . . . . . . . . . . . . . . . 37Other Information about Compiler Options for Application 1 . . . . . . . . . . . . . . . . 40Information about Compiler Options for Application 2 . . . . . . . . . . . . . . . . . . . . 40

Control Information for the Linkage Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Creating LEC and CC Architecture Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 44DB2CLIST Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Copyright IBM Corp. 1993 v

Chapter 5. Migrating the Bulk Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Standard Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Nonstandard Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

COBOL Copy Statements with Leading Data Names . . . . . . . . . . . . . . . . . . . . . 52COBOL Copy Statements with Prefix Replacement . . . . . . . . . . . . . . . . . . . . . . 54− INC CA-LIBRARIAN Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Completeness and Correctness Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58SCLM Architecture Reports for Completeness Checks . . . . . . . . . . . . . . . . . . . . 58Check Correctness Using SCLM BUILDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 6. Creating High-Level Application Structure . . . . . . . . . . . . . . . . . . 61Sources of Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Application Structure Information in Your Old Library System . . . . . . . . . . . . . . . 62Structure Information from Dictionary Reports . . . . . . . . . . . . . . . . . . . . . . . . . 63Information from Application Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 63Scan of Source Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Creating the Architecture Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63BUILD and PROMOTE Using the Architecture Definitions . . . . . . . . . . . . . . . . . . . 69

Chapter 7. Post-Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Promote Migrated Application to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Handle Nonmigrated Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Appendix A. Data Extraction from CA-LIBRARIAN . . . . . . . . . . . . . . . . . . . . 73Copy Selected Members between CA-LIBRARIANs . . . . . . . . . . . . . . . . . . . . . . . 73Extract Programs and Remove Included Members . . . . . . . . . . . . . . . . . . . . . . . 74Unload from CA-LIBRARIAN to Partitioned Data Set . . . . . . . . . . . . . . . . . . . . . . 75

Appendix B. Methods and Tools for Analyzing Existing Applications . . . . . . . . 77Application 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Compiler Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77VS COBOL II Compiler Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Extracting Compile and Link Edit Information . . . . . . . . . . . . . . . . . . . . . . . . . 88

Application 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Find Information for Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Extract Control Information from ENDEVOR Archive File . . . . . . . . . . . . . . . . . . . 97

Appendix C. SCLM Project Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Language Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

F@ASMH for Assembler H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104F@L370 for the Linkage Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106F@COBL for OS/VS COBOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108F@COB2 for VS COBOL II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110F@COB22 for VS COBOL II with CMPR2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 112F@PLIO for OS PL/I V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114F@AD2 for Assembler H with DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116F@SCMD for DB2 DDL Subcommands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119F@PANELS for ISPF Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120F@@SKEL for ISPF Skeletons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121F@MSGS for ISPF Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Appendix D. Generation of Architecture Definitions . . . . . . . . . . . . . . . . . . 123LEC and CC Architecture Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123HL Architecture Definitions and DB2CLISTs . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Appendix E. Tools for Bulk Data Migration . . . . . . . . . . . . . . . . . . . . . . . . 139Changing Old COBOL COPY Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Handling COPY Prefix Replacement in COBOL Programs . . . . . . . . . . . . . . . . . . 141Changing CA-LIBRARIAN − INC Statements . . . . . . . . . . . . . . . . . . . . . . . . . . 156

vi Library Migration

Using SCLM Command Interface for Mass BUILDs . . . . . . . . . . . . . . . . . . . . . . 158

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Contents vii

viii Library Migration

Figures1. Release Procedure for Sample Application 1: General Flow . . . . . . . . . . . . . . 142. Release Procedure for Sample Application 1: Data Flow . . . . . . . . . . . . . . . . 153. Release Procedure Using ENDEVOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174. Extraction of Program Sources for Application 1 . . . . . . . . . . . . . . . . . . . . . 205. Project Hierarchy for Our Migration Project . . . . . . . . . . . . . . . . . . . . . . . . 256. Extraction and Use of Control Information . . . . . . . . . . . . . . . . . . . . . . . . . 307. Extraction of Information from Load Modules . . . . . . . . . . . . . . . . . . . . . . . 328. Formatted File before Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419. Formatted File after Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

10. Sample Job to Run the IBM AMBLIST Utility . . . . . . . . . . . . . . . . . . . . . . . . 4311. AMBLIST Output for Assembler Load Module P92N041 . . . . . . . . . . . . . . . . . 4312. Input Records to Create LEC and CC Architecture Definitions for COBOL Programs 4513. LEC and CC Architecture Definitions for OS/VS COBOL Program P92N002 . . . . . 4514. LEC Architecture Definition for VS COBOL II Program P92N046 . . . . . . . . . . . . 4615. Input Records to Create LEC and CC Architecture Definitions for PL/I Programs . . 4616. LEC and CC Architecture Definitions for PL/I Program P94N353 . . . . . . . . . . . . 4617. Input Records to Create LEC and CC Architecture Definitions for Assembler

Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4718. LEC Architecture Definition for Assembler Program P92N041 . . . . . . . . . . . . . . 4719. HL Architecture Definition Created by the MIGR0050 Program . . . . . . . . . . . . . 4820. Overview of Bulk Data Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 5021. SCLM Migration Utility Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5122. COBOL Copy Book without 01 Level Data Name . . . . . . . . . . . . . . . . . . . . . 5323. COBOL Copy Book with 01 Level Data Name . . . . . . . . . . . . . . . . . . . . . . . 5324. COBOL Error Messages for Duplicate 01 Level Data Names . . . . . . . . . . . . . . 5425. COPY REPLACING: Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5526. COPY REPLACING: Example 2a (COBOL Standard) . . . . . . . . . . . . . . . . . . . 5527. COPY REPLACING: Example 2b (CA-LIBRARIAN Standard) . . . . . . . . . . . . . . . 5628. COPY REPLACING: Example 2c (COBOL ANSI 85 Standard) . . . . . . . . . . . . . . 5629. Partial SCLM Architecture Report for Member #COB2 . . . . . . . . . . . . . . . . . . 5930. HL Architecture Definition #P1010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6531. HL Architecture Definition #P1100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6532. HL Architecture Definition #C1100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6533. HL Architecture Definition #P92N200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6534. Partial SCLM Architecture Report for Application 1 . . . . . . . . . . . . . . . . . . . . 6635. HL Architecture Definition @X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6736. HL Architecture Definition @L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6737. Partial SCLM Architecture Report for Application 2 . . . . . . . . . . . . . . . . . . . . 6838. Job to Copy Members from CA-LIBRARIAN to CA-LIBRARIAN . . . . . . . . . . . . . 7339. Job to Extract Programs from One CA-LIBRARIAN to Another CA-LIBRARIAN . . . 7440. Job to Unload All Members from CA-LIBRARIAN to PDS . . . . . . . . . . . . . . . . 7541. PL/I Program MIGU001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7842. Sample Job to Run Program MIGU001 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8043. Output Records from Analysis of Load Modules with Program MIGU001 . . . . . . . 8144. Sorted Output Records from Load Module Analysis . . . . . . . . . . . . . . . . . . . 8145. VS COBOL II Program MIGU002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8346. Sample Job to Run Program MIGU002 . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Copyright IBM Corp. 1993 ix

47. Output from Program MIGU002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8848. Examples of First Lines in Released Program Source Code . . . . . . . . . . . . . . 8949. ISPF EDIT Macro MIGE0040 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9050. ISPF EDIT Macro MIGE0000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9151. Control Information Extracted with EDIT Macro MIGE0040 . . . . . . . . . . . . . . . . 9152. Input for REXX Procedure MIGR0040 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9253. Output from REXX Procedure MIGR0040 . . . . . . . . . . . . . . . . . . . . . . . . . . 9254. REXX Procedure MIGR0040 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9355. ISPF Input Panel Definition for MIGP0040 . . . . . . . . . . . . . . . . . . . . . . . . . . 9656. SCL for Action B37 and Statement B3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9757. SCL for Statement B3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9758. REXX Procedure MIGR0030 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9759. SCLM Project Definition SCLM3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10160. Authorization Codes for Project SCLM3: ASCLM3 . . . . . . . . . . . . . . . . . . . 10261. Project Control for Project SCLM3: CSCLM3 . . . . . . . . . . . . . . . . . . . . . . . 10262. Flexible Database Specification for Project SCLM3: FSCLM3 . . . . . . . . . . . . . 10363. Type Definitions for Project SCLM3: TSCLM3 . . . . . . . . . . . . . . . . . . . . . . 10364. Language Definitions for Project SCLM3: LSCLM3 . . . . . . . . . . . . . . . . . . . 10465. Horizontal Versioning for Project SCLM3: VSCLM3 . . . . . . . . . . . . . . . . . . . 10466. Language Definition F@ASMH for Assembler H . . . . . . . . . . . . . . . . . . . . . 10467. Language Definition F@L370 for the Linkage Editor . . . . . . . . . . . . . . . . . . 10668. Language Definition F@COBL for OS/VS COBOL . . . . . . . . . . . . . . . . . . . . 10869. Language Definition F@COB2 for VS COBOL II . . . . . . . . . . . . . . . . . . . . . 11070. Language Definition F@COB22 for VS COBOL II with CMPR2 . . . . . . . . . . . . 11271. Language Definition F@PLIO for OS PL/I V2 . . . . . . . . . . . . . . . . . . . . . . . 11472. Language Definition F@AD2 for Assembler H with DB2 . . . . . . . . . . . . . . . . 11673. Language Definition F@SCMD for DB2 DDL Subcommands . . . . . . . . . . . . . 11974. Language Definition F@PANELS for ISPF Panels . . . . . . . . . . . . . . . . . . . . 12075. Language Definition F@@SKEL for ISPF Skeletons . . . . . . . . . . . . . . . . . . . 12176. Language Definition F@MSGS for ISPF Messages . . . . . . . . . . . . . . . . . . . 12277. ISPF Panel MIGP0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12478. ISPF Help Panel MIGH0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12479. REXX Procedure MIGR0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12580. ISPF Panel MIGP0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12681. ISPF Help Panel MIGH0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12782. ISPF Skeleton MIGS0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12783. ISPF Skeleton MIGS0011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12984. REXX Procedure MIGR0050 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12985. ISPF EDIT Macro MIGE0030 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13986. Handling COPY Statements with REPLACING Clause: Overview . . . . . . . . . . . 14287. COPY Statements and Text for Copy Book S92U905C . . . . . . . . . . . . . . . . . 14388. Sample Statements Referring to Data Names from Copy Book S92U905C . . . . . 14389. Sample Job to Run Program MIGU003 . . . . . . . . . . . . . . . . . . . . . . . . . . 14490. COBOL Program MIGU003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14491. ISPF EDIT Macro MIGE0050 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15392. ISPF EDIT Macro MIGE0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15793. ISPF EDIT Macro MIGE0020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15794. REXX Procedure MIGR0020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15895. Sample Job to Run MIGR0020 in Batch Mode . . . . . . . . . . . . . . . . . . . . . . 159

x Library Migration

Tables1. SCLM Types Used in the Migration Project . . . . . . . . . . . . . . . . . . . . . . . . 262. SCLM Languages Used in the Migration Project . . . . . . . . . . . . . . . . . . . . . 333. VS COBOL II Compile-Time Options in Effect . . . . . . . . . . . . . . . . . . . . . . . 37

Copyright IBM Corp. 1993 xi

xii Library Migration

Special NoticesThis publication is intended to help people who are planning or are involved in a migrationto SCLM. The information in this publication is not intended as the specification of anyprogramming interfaces that are provided by SCLM. See the PUBLICATIONS section of theIBM Programming Announcement for ISPF/PDF 3.5 for more information about whatpublications are considered to be product documentation.

References in this publication to IBM products, programs or services do not imply that IBMintends to make these available in all countries in which IBM operates. Any reference to anIBM product, program, or service is not intended to state or imply that only IBM's product,program, or service may be used. Any functionally equivalent program that does notinfringe any of IBM's intellectual property rights may be used instead of the IBM product,program or service.

Information in this book was developed in conjunction with use of the equipment specified,and is limited in application to those specific hardware and software products and levels.

IBM may have patents or pending patent applications covering subject matter in thisdocument. The furnishing of this document does not give you any license to these patents.You can send license inquiries, in writing, to the IBM Director of Commercial Relations, IBMCorporation, Purchase, NY 10577.

The information contained in this document has not been submitted to any formal IBM testand is distributed AS IS. The information about non-IBM (VENDOR) products in this manualhas been supplied by the vendor and IBM assumes no responsibility for its accuracy orcompleteness. The use of this information or the implementation of any of these techniquesis a customer responsibility and depends on the customer's ability to evaluate and integratethem into the customer's operational environment. While each item may have beenreviewed by IBM for accuracy in a specific situation, there is no guarantee that the same orsimilar results will be obtained elsewhere. Customers attempting to adapt these techniquesto their own environments do so at their own risk.

The following terms, which are denoted by an asterisk (*) in this publication, are trademarksof the International Business Machines Corporation in the United States and/or othercountries:

The following terms, which are denoted by a double asterisk (**) in this publication, aretrademarks of other companies:

AD/Cycle BookMaster CICSCICS/ESA DB2 IBMMVS/ESA OS/2 RACFSAA

ENDEVOR LEGENT Corp.CA-LIBRARIAN Computer Associates, Inc.PANVALET Computer Associates, Inc.

Copyright IBM Corp. 1993 xiii

xiv Library Migration

PrefaceThis book describes and documents how two customer applications from a CA-LIBRARIANand ENDEVOR environment were migrated to SCLM. The book also describes the toolsdeveloped to support the migration. The tools can be used as is or modified to suit aparticular customer environment. The migration process and some of the tools andtechniques used during the migration can be applied to application migrations from otherthan the two described library systems to SCLM.

This book is intended for project leaders, library administrators, system programmers, andapplication developers involved in migrating applications from vendor libraries to SCLM.The book assumes that users are familiar with the basic concepts of SCLM. Users who arenot should read the manuals listed in the Related Publications section of this document.Those manuals explain SCLM concepts, provide details about specific commands, anddiscuss various uses of SCLM.

How This Document Is OrganizedThe document is organized as follows:

“Executive Summary” contains our experiences and conclusions in a condensed form.

Chapter 1, “Introduction” describes our project environment and gives a briefintroduction to the library systems used by the customers who provided us with thesample applications.

Chapter 2, “Preparing for Migration” discusses general preparation steps and explainsthe considerations involved when deciding on a migration strategy. The sampleapplications for our migration and how we extracted the data for those applications areexplained.

Chapter 3, “Defining SCLM Project Setup” describes the SCLM project setup used forthe project.

Chapter 4, “Migrating the Control Information” explains the steps performed during themigration of the control information.

Chapter 5, “Migrating the Bulk Data” describes the steps performed during the bulkdata migration.

Chapter 6, “Creating High-Level Application Structure” explains the considerations weapplied to create SCLM architecture definitions that reflect the structure of our sampleapplications.

Chapter 7, “Post-Migration Steps” explains some of the considerations that need to beaddressed after migrating an application, such as promotion to production and handlingof nonmigrated information.

Copyright IBM Corp. 1993 xv

Appendix A, “Data Extraction from CA-LIBRARIAN” shows sample jobs used to extractdata from CA-LIBRARIAN.

Appendix B, “Methods and Tools for Analyzing Existing Applications” shows themethods and tools we used to extract control information for our sample applications.

Appendix C, “SCLM Project Definition” contains the project definition for our project andthe language definitions that were either created or modified during the project.

Appendix D, “Generation of Architecture Definitions” contains the tools we used tocreate architecture definitions.

Appendix E, “Tools for Bulk Data Migration” describes tools for bulk data migration andtechnical details about required changes to source modules from the CA-LIBRARIANenvironment.

Related PublicationsThe following publications are considered particularly suitable for a more detailed discussionof the topics covered in this document:

Software Configuration and Library Manager WorkStation Platform/2 Usage Guide,GG24-3538

AD/Cycle: SCLM 3.4 New Functions Usage Guide, GG24-3833

AD/Cycle: Using SCLM to Manage CSP/AD and CSP/AE Libraries, GG24-3621

ISPF/PDF Software Configuration and Library Manager (SCLM) Guide and Reference,SC34-4254

VS COBOL II Application Programming Guide for MVS and CMS, SC26-4045

VS COBOL II Application Programming: Language Reference, SC26-4047

VS COBOL II Application Programming: Debugging, SC26-4049

OS PL/I Version 2 Programming Guide, SC26-4307.

International Technical Support Center PublicationsA complete list of International Technical Support Center publications, with a briefdescription of each, may be found in:

Bibliography of International Technical Support Centers Technical Bulletins, GG24-3070.

AcknowledgmentsThe advisor for this project was:

Christian PeterhansInternational Technical Support Center - San Jose

The authors of this document are:

xvi Library Migration

Marc DumasIBM France

Walther FitzIBM Germany

This publication is the result of a residency conducted at the International Technical SupportCenter, San Jose.

Thanks to the following people who reviewed this document and made technicalcontributions:

Ron BlackwellIBM Canada

Claude BourrecIBM France

Ralph NaegeliIBM Switzerland

Ueli WahliInternational Technical Support Center - San Jose

Thanks are also due to the many other collaborators and reviewers who contributed toimprove this document.

International Technical Support Center - San Jose

Preface xvii

xviii Library Migration

Executive SummaryThe objective of our project was to migrate applications from vendor library systems toSCLM and to document the migration in an ITSC Redbook.

The basic steps of our migration strategy can be applied to other migrations, even thoughthe approaches used to address the issues may vary from installation to installation. Ourmigration can be viewed as an example that shows the conceptual steps of a migration froma vendor library to SCLM. Understanding the methodology we used to succeed with themigration, rather than simply reusing the tools developed, should prove beneficial.

We selected two applications from two different vendor library systems, CA-LIBRARIAN andENDEVOR, for our project. These two library systems offer different levels of functionality.CA-LIBRARIAN is a library management system with no software configuration supportfunctions. ENDEVOR is a software configuration and library management system. Wewanted to show the different considerations that apply depending on how sophisticated yourexisting environment is.

We did not install either of the vendor library systems in our environment. We extracted alldata deemed useful from the source environments before we started our project, and wehad no access to additional information during the project. A customer migration should beeasier and may require fewer intermediate steps.

We did not try to clone the existing environment because we believe that cloning does notgive you all the benefits of SCLM and increases considerably the cost of the migration.

The tools developed during the project and described in this book are not designed asgeneral-purpose tools. You may want use the tools as a starting point for developing yourown tools or modify them to suit your environment.

It turned out during the project that the most critical factor for a successful migration toSCLM is the availability of control information from the existing environment and informationabout the application structure. Of lesser importance is whether the vendor library providesthis control information or whether the information is available elsewhere in yourenvironment. This book shows examples for both situations. The less information aboutyour application and its structure that is available from the existing environment, the moreyou have to invest during the migration, but the benefits from maintaining the applicationunder SCLM will pay off even more.

The total cost of a migration to SCLM depends on the existing environment and on whetheryou want to clone the existing environment with SCLM. The cost for the actual migrationmight be small compared to the investment to introduce software management discipline inyour environment. However, proper software management pays off big in the future in termsof reduced development cost, management of configuration changes, software auditability,application reliability, and production stability.

Copyright IBM Corp. 1993 1

2 Library Migration

Chapter 1. IntroductionSoftware Configuration and Library Manager (SCLM) is the IBM* software configuration andlibrary management system for AD/Cycle*. Many customers who want to migrate to SCLMtoday have installed library systems, such as CA-LIBRARIAN**, PANVALET**, or ENDEVOR**.In addition they may have an in-house developed system to control their softwaredevelopment and production environment.

Because SCLM is both a software configuration and library manager, migration to SCLMdoes not only consist of moving the application code under SCLM control. The morechallenging part of the migration is the handling of information controlling the softwareconfiguration.

This book shows how information from existing library systems can be migrated to SCLMand presents the results of such a migration with sample applications used during ourproject.

Why Migrate to SCLM?SCLM is a software configuration and library management system. Most of the existinglibrary systems provide only the library management component. After you have migratedto SCLM you can control all of your software throughout the development life cycle.

SCLM implements a structured concept for software development and maintenance. TheSCLM project definition describes the organizational structure of the project, sometimesreferred to as the promotion hierarchy. The SCLM architecture definitions describe thestructure of the applications. These architecture definitions allow the SCLM build process toautomatically rebuild part or all of an application when dependencies have changed.Software developers no longer have to figure out by themselves which modules might beaffected by a change.

The product's ease of use will more than pay for the investment made in the migrationprocess. New people joining a development group can better understand existingapplications that are clearly structured and become productive quickly. SCLM also helpsexperienced people avoid errors and keep the application software consistent.

SCLM allows you to control a wide range of software types. SCLM offers languagedefinitions for the standard programming languages, such as COBOL, PL/I, Assembler, C,FORTRAN, and Pascal. SCLM also has language definitions that handle the preprocessorsfor target environments like CICS* or DB2*. SCLM supports the DB2 BIND mechanism, CSPgeneration for all target environments, BookMaster* documents, interpreter modules likeTSO CLISTs or REXX procedures, and the like.

Screen Definition Facility II (SDF II) Release 3 provides an interface that enables you to useSCLM to control your screen definitions for all SDF II target environments from the very firstdevelopment step. Other library systems can only control output from such products as SDFII, which creates the CICS basic mapping support (BMS) macros and COBOL copy books.Without SCLM, maintenance of screen maps thus must begin from an unprotected


development status or requires additional steps to reimport members from the productionlibraries into the map generation tool.

The modular design of SCLM allows you to easily modify, or add new, language definitionswithout impacting the development environment.

SCLM is more than a tool to administer your software. You can bring all of your applicationdocumentation under SCLM control. Using the Workstation Interactive Test Tool (WITT), youcan add test cases to your software architecture definition. Thus, you can promotedocumentation and test cases together with your basic software modules through yourproject hierarchy. In addition, using SCLM's versioning function, you can keep track of thehistory of your documentation.

If you split your SCLM accounting data set into several data sets (which is possible sinceSCLM Release 3.4), you can RACF* protect not only your bulk data sets to match youradministration structure but also your SCLM control data. You can define separate SCLMaccounting data sets for different groups of the project to prevent unauthorized access toSCLM control data.

SCLM is part of ISPF/PDF and is therefore available in any ISPF/PDF installation and can beused immediately. That availability not only saves money but also eliminates the need tomaintain an additional software product all the time.

If you migrate to SCLM, you get the benefits of a product that has a strong softwaredevelopment concept but also gives you the flexibility to meet your individual requirements.New preprocessors and compilers can be supported by just adding new languagedefinitions. User exits allow you to integrate additional functions required in yourenvironment, and the project definitions can reflect your organizational structures.

Objectives and Scope of the ProjectThe objectives of the project were to migrate a customer's library data to an SCLMenvironment and describe the required migration steps.

Some preparation of the migration was performed before the project began to bring acomplete set of data from the customer environment to the project. The project durationwas limited to two months.

Project Environment

For all the migration work we used an MVS/ESA* (SP 4.2.2) system with ISPF/PDF 3.5installed. A vendor library was not installed on the system, so we had to start with dataunloaded at the customer site.

The project dealt mainly with the migration steps. Premigration steps, for example,selection of the sample applications, were partly carried out in the original customerenvironment before the project started. We did not perform postmigration steps, such asdeleting migrated modules in the old library system, and, outside the real customerenvironment, we could do only limited regression testing.

The migration process is quite host-bound, and we did not use the workstation interface ofthe IBM SAA* AD/Cycle WorkStation Platform/2 during the migration.

4 Library Migration

Sample Applications

We used two different applications for the migration from two different vendor librarysystems. We expect that the lessons learned from this project are applicable to migrationsfrom other vendor tools.

“Sample Application 1” on page 12 and “Sample Application 2” on page 16 contain adetailed description of the applications and the use of the library systems in the customerenvironments from where these applications are taken.

Migration Steps

We defined the following migration steps for our project:

1. Preparing for Migration

This step includes the definition of a migration strategy and provides the deliverablesthat are input to the physical migration. This step also defines the project structure andidentifies the project personnel. It also determines all education required.

The pilot application is selected during the preparation step.

2. Defining SCLM Project Setup

This step covers the collection and study of the information required to set up an SCLMenvironment.

3. Migrating the Control Information

This step covers the detailed analysis of the existing control information and thetransformation of that information into a format that can be used as input to SCLM.

4. Migrating the Bulk Data

This step includes the physical migration of bulk data.

5. Creating High-Level Application Structure

This step covers the creation of the required architecture definitions to define thehigh-level application structure to SCLM. The deliverable is the complete applicationbuilt under control of SCLM.

6. Post-Migration

This step brings our application into production and provides test and validation. Itincludes cleaning up the old environment.

Vendor Library SystemsThis section contains a short description of the two library systems used by the customerswho provided us with the sample applications. The two library systems are:

CA-LIBRARIANENDEVOR.

Chapter 1. Introduction 5

CA-LIBRARIAN

CA-LIBRARIAN is a storage medium for modules that can be represented in 80-bytecard-image format records. CA-LIBRARIAN is most useful for source programs and offersfeatures for auditing and control.

The basic component of CA-LIBRARIAN is the master file, which is a direct-access data setwith fixed-length blocks. This preallocated area of space contains an index and a data area.Data records can be stored in compressed format.

The archiving facility allows previous versions of an updated module to be recreated. Firstyou must initialize archiving for a master file, and then you can specify archiving forindividual modules.

CA-LIBRARIAN started out as a batch tool. Now, online interfaces are available for someenvironments, for instance, the ELIPS interface for a TSO/ISPF environment.

Batch CA-LIBRARIAN operations are activated by control statements. These controlstatements can carry special options. There are seven basic types of CA-LIBRARIAN controlstatements:

Execution control statements that govern general execution of CA-LIBRARIAN for thewhole control stream

Module control statements for processing a particular module

Editing control statements

Updating control statements

Documentary control statements that can record control information about a module

Miscellaneous control statements that can, for instance, add records from another file orinclude another module

Utility control statements.

Processing options can be specified after the commands in a control statement. Processingoptions can control processing, such as handling of archiving levels, sequence numbering,invoking expansion of CA-LIBRARIAN COBOL COPY verbs, invoking the group processingoption (GPO), and generating a master file index listing. Not all processing options can beused in online environments.

File access interface routines (FAIRs) allow read-only access to a CA-LIBRARIAN master file.Any modifications to a master file must be made through the CA-LIBRARIAN@ program.

In addition to external security systems, such as RACF, a CA-LIBRARIAN management code(MCD) can be used to restrict access to selected members. Four different member statusvalues designate the degree of protection.

ENDEVOR

ENDEVOR is a family of software products that provides automation and control of thesoftware development life cycle. ENDEVOR's function spans from initial system design anddevelopment through implementation and ongoing maintenance. In the case ofvendor-supplied software, ENDEVOR supports installation and maintenance, includingupgrades. The components of the ENDEVOR family are ENDEVOR/MVS, ENDEVOR/DB,ENDEVOR/DB2, ENDEVOR/CSP, ENDEVOR for DOS, and ENDEVOR for OS/2*.

ENDEVOR/MVS provides the following functions:

6 Library Migration

An inventory of software objects (sources and executables) that reside in partitioneddata sets (PDSs), library management systems (PANVALET and CA-LIBRARIAN), andexecutable libraries.

To manage the inventory, ENDEVOR uses a concept of logically and physically separatestructures. An inventory item (element) is identified to the ENDEVOR Inventory Managerby a five-part name consisting of:

− I/S location− System− Subsystem− Type− Element name.

This logical classification provides a view of the inventory that is separated from theinventory's physical structure.

ENDEVOR manages multiple data sets with different data set organizations andcharacteristics to store the physical objects independent of their logical classification.

A base/delta technology is used to store the source elements within the applicationinventory. The base/delta files can be PDSs, VSAM files, or BDAM files. ENDEVORprovides an interface to read directly from and write directly to PANVALET andCA-LIBRARIAN files.

Control and history of changes that occurred to the source. Change control identifiers(CCIDs) provide a means for grouping and manipulating related change activity.ENDEVOR tracks all source changes by creating a unique delta to record each changeevent.

Control of the process and procedures that translate sources into executables. Theprocedures are called processors and are written in job control language (JCL)statements. The appropriate processor is determined by the type and element nameinformation of the logical inventory classification.

A link between the source code and its related executable forms. The technique used iscalled footprinting. ENDEVOR places an encrypted audit stamp (footprint) in the outputsource, object, or load modules created.

Control of the movement of software release packages. ENDEVOR provides a softwarecontrol language (SCL) to manipulate and move objects or portions of an applicationsystem through the predefined levels (stages) of ENDEVOR. There are two predefinedstages per ENDEVOR environment: STAGE 1 and STAGE 2.

For software distribution, the TRANSFER utility extracts objects from one ENDEVOR sitein a format that allows the transfer to another ENDEVOR site.

An ARCHIVE function to back up an entire environment. This function extracts objectsand related control information from an ENDEVOR environment and writes them to anarchive file. This file is input to the RESTORE function.

A set of standard reports that provide information about the inventory of softwareobjects:

− Report 01: System Inventory Profile− Report 02: System Inventory Summary− Report 03: Element Catalog− Report 04: Element Activity Profile− Report 05: Element Activity Summary− Report 06: Element Catalog by CCID− Report 07: System Definition Profile.

These reports are available only in batch mode. You specify which one of the sevenreports you want in the standard report JCL.

Chapter 1. Introduction 7

The standard ENDEVOR reports are not the only way to find information about softwareobjects. You can also use SCL specifying the PRINT action (action is an SCL command).See “Find Information for Languages” on page 96 for a detailed description.

In our project we used both standard reports (01 to 07) and PRINT SCL for all objects tobe migrated.

A batch or interactive interface for all functions and actions. For example, we couldhave used the interactive interface to get the same information that we have in ourreport listings.

8 Library Migration

Chapter 2. Preparing for MigrationIn this chapter we explain how to develop a migration strategy, define your projectorganization, and select a pilot application. We describe the sample applications for ourmigration and show how we extracted the data for those applications.

Develop Migration StrategyThe migration strategy describes the plan of action for performing the migration to SCLM.This migration strategy must be defined before starting any other activity; its purpose is toanswer two questions:

What to do?

How to do it?

Many factors influence the migration strategy, such as the size and organizational structureof the enterprise, the availability of people with the proper skills to perform the migration,and the stability of the applications. You should not start migrating an application during aphase of heavy maintenance.

Normally, in a large enterprise, a number of different applications work more or lessindependently. Therefore, before migrating to SCLM you must identify the applications inyour enterprise in order to know which to migrate.

Not all applications should be migrated simultaneously. We recommend that you migrateone application in a pilot project and then migrate application by application. Therefore, youmust select the application for the pilot project first.

The above considerations should lead you to formulate a migration strategy comparable tothe following:

1. Create or use an application inventory of the enterprise to determine characteristics ofthe applications, such as:

Function of an application and its use in the enterprise

Size of the application

Components of the application

Application technology, that is, which subsystems and languages are used andwhich module types belong to the application

Interaction with other applications

Use of common enterprisewide modules

Maintenance status and stability.


2. Define an organizational structure.

We recommend that you perform the migration as a project. This requires staffing ofthe project, selection of a project leader, and setting up a project plan. We give moredetails on this topic in “Define Organizational and Administrative Structure.”

3. Select a pilot application and define the migration steps for the pilot project.

We discuss selection criteria for the pilot application in “Select Pilot Application” onpage 12.

4. Migrate the pilot application.

During migration of the pilot application you will find the best method for migration ofthe remaining applications in your enterprise. You can customize existing, and perhapsdevelop new, tools that make migration easier.

After migrating the pilot application you will know your specific organizational andtechnical problems and how they can be solved. You will know the benefits of usingSCLM for the enterprise and you can better estimate time and costs for the migration ofthe remaining applications. The skills required for the migration project are establishedand built during the pilot project.

5. Decide about proceeding further.

This is the time to make a final decision about an enterprisewide migration to SCLM andrefine your technical and organizational structure.

You should develop a timetable for the migration on an application-by-application basis.

6. Migrate all other applications.

Our project was comparable to a pilot project in a customer environment. We made thefollowing decisions:

Two professionals would work under the guidance of a project leader.

Modules coming from two different library systems would be migrated.

We would only migrate source objects and then build them under control of SCLM tocreate the derived objects (object and load modules).

We would not install vendor library systems in our environment.

We would unload the data from the existing library systems at the customer sites.

We would concentrate on the migration steps and use a simple SCLM environmentwithout tricky user exits for additional customer-specific functions.

We would build one SCLM project only and separate the two applications using differentSCLM authorization codes.

We would play the roles of all people involved in a migration project and therefore notset up dedicated RACF profiles.

Our primary objective would not be to develop general-purpose migration tools.

Define Organizational and Administrative StructureWe recommend that you perform the migration as a project and follow a process thatincludes several steps. First you define the project organization and identify the peopleinvolved and their roles in the migration project. We defined the following four roles for themigration:

10 Library Migration

Project leaderSCLM support personLibrary administratorApplication developers.

The project leader coordinates migration steps and evaluates the cost of the project. Theproject leader is responsible for setting up a project plan, proposing this plan to informationsystems (IS) management for approval, and ensuring that the project plan is followed duringthe project. The project leader has overall responsibility for the project (cost, time,deliverables, and so on) and reports directly to IS management.

The SCLM support person is responsible for the SCLM implementation and the technicalaspects of the migration. The SCLM support person is also responsible for educating thelibrary administrator during the migration and the developers who will use SCLM after themigration. The SCLM support person must be experienced in implementing SCLM.

The library administrator has a working knowledge of the existing library system andperforms the migration together with the SCLM support person. One objective of the libraryadministrator is to develop his or her SCLM skills during the migration.

The application developers know the applications to be migrated. They assist the SCLMsupport person in all steps of the migration and during testing of the migrated applications.

These roles are defined in terms of activities and responsibilities in the project and do notnecessarily correspond one-to-one to the people required. You can combine several roles inone person if appropriate. That is, application developers, SCLM support, and libraryadministrator may be one or several persons. However, for the project to be successful, youshould have a separate project leader.

The degree of involvement in the project of the different roles varies. You should expect it tobe about 90% (workload) for the SCLM support person and the library administrator andabout 25% for application developers and the project leader.

Our approach did not involve the application owners and end users in the migration process.However, application owner and end-user participation might be required during the testphase, especially if code integrity problems are discovered during the migration.

To evaluate the amount of effort required to migrate an application to SCLM we recommendthat you take the following criteria into account:

Application technology

Knowledge of application

Size of application

Code integrity

Vendor library system

Interface with other tools

Particular customer environment.

You can also use some of these criteria to select the pilot application, as described below.

Chapter 2. Preparing for Migration 11

Select Pilot ApplicationThe following criteria influence the selection of a pilot application:

Importance As with any other migration, you should not select one of themost critical business applications for the pilot project.Rather, you should select a less critical application, which willresult in a safe and quick migration. You can then apply theresults of the pilot migration to the more critical businessapplications.

Application technology The pilot application should not be too simple compared toother applications of the enterprise, but it should be simpleenough to prevent too many simultaneous problems. Moduletypes and translator languages should match those of otherimportant applications.

Size We do not recommend that you select an application withthousands of modules for the pilot project. However, the pilotshould be large enough to provide relevant information for themass migration. Should you select a pilot application withonly a few modules of one type, you should handle them asyou would many modules. This approach will make theexperiences of the pilot project more applicable to the massmigration.

Knowledge of Application People working on the pilot project should have a reasonableworking knowledge of the pilot application.

Stability The application selected for migration should not undergomaintenance at the same time as it is migrated.

We recommend that you establish a short, frozen zone for theduration of the migration and that you only migrate and testthe production version of the application. From a technicalpoint of view it is possible to migrate development and testlevels too, but this will require a sophisticated changemanagement process for the project.

Code stability Only a stable application status allows you to distinguishbetween problems that result from errors in the migrationprocess and those that result from existing instabilities anderrors in the application.

Our pilot project consists of two different applications to show a wide range of potentialconsiderations and problems encountered in a migration to SCLM, but by no means does itcover the whole range of module types and languages you can handle with SCLM. Our pilotproject shows how a migration can look conceptually. Even though individual technicaldetails may differ from installation to installation, the general concepts of our pilot migrationare generally applicable.

Sample Application 1This section describes sample application 1, its function, its implementation in the oldenvironment, and its use of functions of the old library system.


Description

Application 1 originates from a customer's IS method and tools department. The applicationcontrols the existing release procedure from development to production for programs andfor other software modules, such as CICS BMS macros; IMS database control blocks (DBDs),program specification blocks (PSBs), and message format service (MFS) macros; TSOCLISTs; REXX procedures; and ISPF modules.

The application provides a dialog user interface to support the release procedures, keepstrack of intermediate and final module status, provides logging of important activities, andoffers utility functions for reporting and cleanup.

The customer wants to maintain use of the release procedures until all other businessapplications are migrated to SCLM and therefore wants to migrate application 1 to SCLMfirst.

The application is a TSO/ISPF application with programs written in COBOL, Assembler, andPL/I. The TSO/ISPF pieces consist of TSO CLISTs, ISPF panels, skeletons, and messagemembers. The whole application consists of:

168 programs129 macros and included members99 CLISTs113 ISPF panels36 message members260 skeletons.

The application is handled like all other business applications at that customer site; that is, itis maintained and released to production with its own functionality.

Release Process

The customer uses the CA-LIBRARIAN library system for program source files. Our sampleapplication 1 controls the release of modules to the so-called R-Test and productionenvironments.

Several test levels are available for the developers before they use the release procedures.Production and each test level have separate sets of libraries for source and loadmodules—CA-LIBRARIANs and PDSs.

Figure 1 on page 14 shows the release procedure that applies to all module types.


ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ ³

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³³ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÁ¿ ³ R-Test ³³³ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÁ¿ DR ³ ³ RP ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³³³ ÃÄÄÄÄÄÄH³ ÃÄÄÄÄÄÄH³ ³³³³ Development ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³³³³ and Test ³ ³ Production ³À́ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄH³ ³À́ ³ DP ³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Under control of release procedure

DR Release from development to R-Test

RP Release from R-Test to production

DP Direct release from development to production

Figure 1. Release Procedure for Sample Application 1: General Flow. For programs, the DR and DPprocesses involve compiles and link edits of the modules. RP is essentially a copy process.Details of the direct release of programs to production are shown in Figure 2 on page 15.

Audit information and other module attributes are stored in a separate CA-LIBRARIANcontrol data set for all module types.

Interpreted modules, such as TSO CLISTs or ISPF panels, are copied from one PDS toanother under control of the release procedure.

The first step for programs is to get the modules out of the CA-LIBRARIAN source data set.At the development level, programs and included members, such as COBOL copy books, arestored as individual members in CA-LIBRARIAN.

Special copy book handling features of the CA-LIBRARIAN COPY option are used for COBOLprograms. Please refer to “Nonstandard Source Code” on page 52 for more details. AllCOBOL COPY statements are replaced with the actual copy code from the same sourceCA-LIBRARIAN using the CA-LIBRARIAN COPY option. A user program resolves nested VSCOBOL II copy books because the CA-LIBRARIAN COPY option does not support nestedcopy books.

For Assembler and PL/I source code the CA-LIBRARIAN − INC statement is used instead ofthe compiler standard statements %INCLUDE and COPY, respectively. The includedmembers replace the − INC statements.

A source program is then presented as one single file to the compiler and stored as onesingle file in the CA-LIBRARIAN data set of the target environment. Special leading andtrailing comment lines mark the beginning and end of an included member in the source file.Compile and linkage edit control options that are allowed to deviate from the defaults arestored as special comment lines at the beginning of the source code.

Figure 2 on page 15 shows the release procedure for the direct release of programs fromdevelopment to production. The release from development to R-Test works the same way.


1A Copy source file by replacing COPY and − INCstatements with the full text of the included members andadding comment lines with compile and link information.

1B Compile and link edit the source code.

2A Save old source file to archive.

2B Move new files to production libraries.

Figure 2. Release Procedure for Sample Application 1: Data Flow. This is the direct releaseprocedure from test to production corresponding to the DP path in Figure 1. The applicationdevelopers (1A + 1B) move the modules into “wait ” libraries. The productionadministrators (2A + 2B) move the modules into final libraries.

The direct release procedure in the existing environment is a two-step process:

The first step is performed by the application developer. Modules end up in “wait ”libraries: program source code in CA-LIBRARIAN data sets, the corresponding loadmodules and interpreter modules in PDSs.

The second step is performed by the administrator for the production environment.Modules are moved into CA-LIBRARIAN data sets and PDSs of the target environment.Before a changed module is moved to the production libraries, the old version of thesource code is copied to an archive file that is later saved to tape by a separatearchiving system.

Released modules are deleted from the development libraries; only the included membersremain in their last-used state. Source modules can be copied back from the productionCA-LIBRARIAN to the development CA-LIBRARIAN for maintenance purposes. This processreduces the source code and reintroduces the original COPY and − INC statements.


Sample Application 2This section describes sample application 2, its function, its implementation in the oldenvironment, and its use of functions of the old library system.

Description

Application 2 originates from a customer's IS production department. The application wasdeveloped by the production department because of the special functionality it provides.The application extracts information from the library system used and stores that informationin relational tables. Therefore, this application extends the functionality of the librarysystem.

Application 2 is a DB2 application written in Assembler and consists of:

20 programming objectsData definition language (DDL) statementsDB2 BIND statements.

Release Process

The software configuration and library management system used is ENDEVOR. However,only the production department in the IS organization uses ENDEVOR. The developmentdepartment does not use any tool to provide software configuration and library managementfunctions.

All customer applications in production are under ENDEVOR control. ENDEVOR is used tomanage a preproduction test and to handle distribution to various production environmentson separate MVS systems.

When developing a new application, developers manage application objects (configurationand library management) without tool support. After coding and testing, they give their“package” to the production administrator, who belongs to the IS production managementorganization.

The package must contain the information required for compile and link edit. The productionadministrator uses ENDEVOR SCL to put objects into the ENDEVOR system.

The first SCL action is ADD, which actually puts one object with processing options(languages) into an ENDEVOR environment. The GENERATE action submits processors(written in JCL) that translate sources into executables. Figure 3 on page 17 shows theprocess involved between the development and production departments.

The MOVE action provides for promotion from preproduction to production. When thepackage is ready to be distributed to the target sites, the production administrator preparesthe SCL to be executed and all required parameters for the target environment.

The process for maintenance is similar. First, developers have to make a request toENDEVOR to get the object. After they change the object and test it, they must give it backto ENDEVOR. The action to put the object back into the ENDEVOR system is REPLACE withthe same information as required by the ADD action plus a CCID.

ENDEVOR uses different file organizations depending on the type of data. Control andattribute information used by ENDEVOR is stored in a VSAM file, the Master Control File.For source programs (base and delta), ENDEVOR provides a choice of PDSs, VSAM datasets, or BDAM data sets. The customer uses BDAM data sets to store the base and deltasources. Load modules are stored in PDSs.


Figure 3. Release Procedure Using ENDEVOR. Application coding and testing are not under control ofthe ENDEVOR system. The production department translates the sources into executables,tests the application in the preproduction environment, and moves the application to up tosix different production sites.

Extract Data for the Sample ApplicationsBecause the vendor library systems were not implemented in our environment, we extractedthe data at the customer sites and installed it in our environment.

This section describes the extraction process for the two sample applications and shows thedata that was taken from the customer environment.

Application 1

Data extraction for application 1 was a two-step process:

1. Identify all modules that belong to the application. Because CA-LIBRARIAN is not asoftware configuration tool you must use other methods to identify all modules of anapplication. The following information sources may help:

Application documentationNaming conventionsListings from source code scans (for copy books)Dictionary reportsControl information created during the release process.


2. Extract the modules to tape. CA-LIBRARIAN utilities are required to unload modulesfrom CA-LIBRARIAN data sets to PDSs. For copy books you have to build member listsusing the output from the first step.

Step 1: Identify all Modules

Dictionary information in the customer environment was only available for dependentmembers of COBOL modules. However, most of the modules follow rigid namingconventions.

We primarily used the naming conventions to find all modules of the application. For all TSOCLISTs and ISPF modules the three-character prefix FUA identifies the application. Thefourth character identifies the module type as follows:

FUAC.... for TSO CLISTsFUAP.... for ISPF panelsFUAS.... for ISPF skeletonsFUAM.... for ISPF message members.

Some other ISPF message members, for example, ALLG...., were also used and themembers were extracted too. The programs for this application use the prefix P92N followedby a three-digit number. For example:

P92N0..P92N2..P92N3.. .

Some subroutines with different naming conventions are called by the programs. To findthese additional programs, scans of the source modules were performed. We used theCA-LIBRARIAN utility with the − SCAN option. Another possibility is to extract the alreadyidentified modules to a PDS and use the ISPF search-for utility.

We scanned the program source code for:

Included members

These members are included with COPY or with CA-LIBRARIAN − INC statements. TheCA-LIBRARIAN data set for production contains the program source with the expandedtext of the included member. The names of the included members can be extractedfrom the comment lines inserted when the included member was expanded in thesource program (refer to “Release Process” on page 13). Because all Assembler usermacros are included with − INC statements and expanded in the program source forarchiving reasons, you can find the names of these macros in the same step.

CALL statements

These provided us with the names of all subroutines. We added the subroutines that donot follow the naming convention to the list of programs for the application.

After finishing this first step in the extraction process we had a list of all modules permodule type that needed to be migrated.

Step 2: Extract the Modules

We extracted the following data at the customer site:

Source code from CA-LIBRARIAN data sets for programs, copy books, and Assemblermacros

Load modules from the production link library


TSO CLISTs, ISPF panels, skeletons, and message members from the correspondingPDSs

A report for all the selected program modules from the CA-LIBRARIAN file that holdsmodule control information.

Source code for programs, copy books, and Assembler macros: Figure 4 on page 20 showsthis source code extraction graphically. The extraction was performed as follows:

Modules were copied from the source CA-LIBRARIAN to a temporary CA-LIBRARIANusing member lists created when we identified all modules in step 1.

This task separated the modules of the sample application from thousands of modulesin the enterprise. Appendix A, “Data Extraction from CA-LIBRARIAN” on page 73contains sample jobs for this task.

Modules were unloaded from the temporary CA-LIBRARIAN to a PDS. Because allmembers were copied, no member list was required as input to this job. “Unload fromCA-LIBRARIAN to Partitioned Data Set” on page 75 shows a sample job for this task.

PDSs were unloaded to tape.

This customer environment requires a check that the included members taken from thedevelopment CA-LIBRARIAN are identical to those released to production. Such aprocedure is available but we do not describe it here because it is not of common interestand not important for the general migration concept.

We used files C and P for the migration of the source members and file PP for the analysisof the included control information. For details see Chapter 4, “Migrating the ControlInformation” on page 29 and Appendix B, “Methods and Tools for Analyzing ExistingApplications” on page 77.

Load modules: Load modules were copied directly from the load library PDSs usingmember lists from step 1. These load modules were used to extract information. Refer toChapter 4, “Migrating the Control Information” on page 29 for details on the information thatcan be extracted from load modules.

TSO CLISTs and ISPF modules: These modules were copied directly from their PDSs usingmember lists from step 1.


LIBRA.MASTER LIBRA.PRODÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ PGM A ³ ³ PGM A ³³ ÚÄ Ä Ä Ä Ä Ä Ä Ä¿ ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³³ ³ ³ ³*****INFO******³ ³³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ́ ³³ COPY XX ³ ³ ³ ³ ³³ ³ ³ ³ ³ ³****COPY XX****³ ³³ COPY YY ³ ³ ³ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ ³³ ÀÄ Ä Ä Ä Ä Ä Ä ÄÙ ³ ³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ³ ³³ ³ ³ ³ ³ ³³ XX ³ ³ ³ ³ ³³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ³ ³³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ³ ³³ ³ ³ ³****COPY YY****³ ³³ YY ³ ³ ³ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ ³³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³³ ³³ ³³ ³ ³ ³ ³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ³ ³³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

³ ³³ ³³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄ¿³ ³ ³↓ ↓ ↓

XX PGM A PGM AÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³*****INFO******³

³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ́YY ³ COPY XX ³ ³ ³ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³****COPY XX****³³ ³ ³ COPY YY ³ ³ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ³

³ ³ ³ ³³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³****COPY YY****³³ ³ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿|³ ³ ³³ ³|³ ³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ³³ ³ ³ ³³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ³ ³ ³↓ ↓ ↓

file C file P file PP

C Copy books (and macros) from the development level CA-LIBRARIANin their last used state.

P Programs with COPY (or − INC) statements.The reduction to this original form is done by a customer-writtenprogram.

PP Programs with full text of included members andinformation about nondefault compile and linkage edit control options.

Figure 4. Extraction of Program Sources for Application 1. Three PDSs are created. Files C and P aredirect input to the migration. Only the control information is used from file PP.


Application 2

We extracted three types of information from the customer environment:

Source data with control informationSource dataENDEVOR reports.

Source Data with Control Information

We used the ENDEVOR ARCHIVE function to extract both source code and controlinformation from the ENDEVOR environment to a single sequential file. This archive filecontained all objects of application 2 (source code, macros, DDL, DB2 BIND statements) andattribute information (date/time for creation and last change, member version, and so on) foreach object.

The archive file can be used to import an application and the application-specificenvironment into another ENDEVOR system using the RESTORE function. Therefore, the filecreated by the ARCHIVE function contains additional information, such as environment,system, subsystem, type, and stage.

The archive file was transferred to diskette and installed in our environment. The datacontrol block for the output file is RECFM = VB, LRECL = 1021, BLKSIZE = 6130.

Source Data

Even though the archive file contains the source code, we used the TRANSFER utility toextract the source code because the TRANSFER utility extracts data directly into PDSmembers. Using the archive file would require a tool to extract the source code into PDSmembers. Only the control information from the archive file was used.

We could not provide a direct extraction from the ENDEVOR environment to SCLM PDSsbecause ENDEVOR was not available in our environment. We used the TRANSFER utility toextract the source data into intermediate PDSs and copied all members to diskette.

To avoid any additional steps during the migration of bulk data (see “Standard SourceCode” on page 51), we recommend that you run the TRANSFER utility using processor(language) as the selection criterion. Create a software release list using the SCL LISTaction with processor as the selection criterion in the WHERE clause. The resulting list canbe used to drive the TRANSFER process.

ENDEVOR Reports

We created all the reports (listings) that were thought to be helpful for the analysis of theapplication; that is, all seven standard reports and an SCL PRINT report for all objects to bemigrated.

Refer to “ENDEVOR” on page 6 for a description of the ARCHIVE and TRANSFER functionsand the standard reports.


Chapter 3. Defining SCLM Project SetupBefore migrating to SCLM you should know whether you want to implement an environmentthat matches your existing environment as closely as possible or an environment that takesthe best advantage of all the functions SCLM provides.

If you clone your existing environment in SCLM, you can minimize the number of changes inyour existing organization and procedures. If you decide to take advantage of all of the goodfunctions SCLM provides, you may need to change your existing organization andprocedures but you will greatly improve your software development and configurationmanagement processes. The kind of environment you decide to implement will influence thesetup of your SCLM project for migration.

We decided to set up the project definition manually for two main reasons. First, there wasno one-to-one correlation between each environment. Second, we evaluated all optionsspecified in the existing environment to find out how those options could be adapted to theSCLM target environment. In this chapter we explain the choices we made and where tofind information in the existing environment that influenced our choices.

For our project, we decided to put the objects of application 1 and application 2 in the sameproject database. The main reason for that decision was that we had only one applicationper vendor library environment to migrate. The migration approach will not be affected ifyou decide to use multiple projects or different high-level qualifiers for the groups in yourenvironment.

Partitioned Data Set High-Level QualifierFinding the best solution for the high-level qualifiers is not easy because you are not startingfrom scratch. Therefore, you must take into account existing information when selecting themost appropriate choice for the PDS high-level qualifiers. For example, some configurationmanagement systems, such as ENDEVOR, keep information that could affect your high-levelqualifier selection (refer to “Set Up High-Level Qualifier with Information from ENDEVOR” onpage 24 for more information). An SCLM project might include more than one application,such as a group of applications belonging to a domain of applications or to a businessdomain.

Naming conventions for the PDS high-level qualifiers are another example of existinginformation you must consider. Before you decide to change the existing namingconventions you should understand why they were chosen in the first place.

You may want to conduct a study with the library administrator and application developersbefore starting the migration project to compare advantages and disadvantages of differentsolutions and to choose the most appropriate. The solution must be valid for all applicationsthat will be migrated after the pilot project.

Since release 3.4, SCLM allows for complete customization of its PDS names using theFLMALTC macro and the ALTC keyword on the FLMGROUP macro.


One possible approach is to handle the high-level qualifiers on a project basis and then tocombine those projects into an enterprise project (enterprise high-level qualifier). Thissubject is specifically discussed in the ITSC Redbook AD/Cycle: SCLM 3.4 New FunctionsUsage Guide, GG24-3833.

In our migration project, we did not have access to customer representatives who couldanswer questions for both applications, so we decided to use one common PDS high-levelqualifier. We chose SCLM3, our SCLM project name, as the high-level qualifier for the PDSs.

Set Up High-Level Qualifier with Information from CA-LIBRARIAN: There is no informationin CA-LIBRARIAN that can be directly correlated to the SCLM high-level qualifier becausemost customers do not use separate CA-LIBRARIANs for different applications. Werecommend that you develop new naming conventions for SCLM project names and usethose names as high-level qualifiers for the PDSs.

If you have an existing naming convention where one (or more) character identifies anapplication, you can include those characters in the high-level qualifier. For example, anapplication now identified by “92” could lead to an SCLM project and PDS high-levelqualifier of “S9200.”

Set Up High-Level Qualifier with Information from ENDEVOR: ENDEVOR supports theconcept of application domains by keeping system and subsystem information (refer to“ENDEVOR” on page 6). A system represents a logical grouping of inventory elements asthey apply to major applications, departments, or work areas within the organization. Forexample, system could represent applications, such as Finance or Personnel. A subsystemis a logical subclassification within a system. For example, the system finance applicationmight be divided into logical subsystems, such as Accounts Receivable, Accounts Payable,and so on.

System and subsystem information can impact the architecture definitions required for theapplication as well as the selection of the PDS high-level qualifier. In fact, application name,system name, and subsystem name are all good candidates for becoming the PDS high-levelqualifier.

GroupsBecause we mixed our two applications in the migration process, we set up a commonproject. Therefore we did not use a naming convention for promotion hierarchies from theexisting environments.

We built a simple project hierarchy with three layers and two development groups, one foreach application to be migrated.

In the development groups we received modules from external files during the SCLMmigration and created architecture definitions to handle them. Then we built thecomponents and promoted them to the TEST layer. Figure 5 on page 25 shows the projecthierarchy for our project.


ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ ³³ PROD ³³ ³ÀÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÙ

³ AC=FUA,NDV³³

ÚÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄ¿³ ³³ TEST ³³ ³ÀÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÙ

³ AC=FUA,NDV³³

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ ³

ÚÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄ¿³ ³ ³ ³³ MIG1 ³ ³ MIG2 ³³ ³ ³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

AC=FUA AC=NDV

Figure 5. Project Hierarchy for Our Migration Project. MIG1 is used to migrate application 1 fromCA-LIBRARIAN to SCLM, and MIG2 is used to migrate application 2 from ENDEVOR toSCLM. Authorization codes are shown beneath each group.

Even if your final project structure is sophisticated, we recommend that you create a simplestructure for the migration. You can use alternate project definitions to define your finalproject structure in parallel. This approach is particularly useful when you migrate on anapplication domain basis with many applications in a single SCLM project. So, while someapplications are being controlled by SCLM, you can migrate other applications through thespecial migration hierarchy. To build a more complex project structure that takes advantageof flexible naming conventions for PDSs refer to the ITSC Redbook AD/Cycle: SCLM 3.4 NewFunctions Usage Guide, GG24-3833.

We used authorization codes to separate our two applications: FUA for application 1 andNDV for application 2 (see Figure 5). Appendix C, “SCLM Project Definition” on page 101shows our project definition.

Set Up Groups with Information from CA-LIBRARIAN: There is no information inCA-LIBRARIAN that can be directly correlated to the SCLM group.

If you use separate CA-LIBRARIANs for different test and production levels that represent apromotion hierarchy, one part of the CA-LIBRARIAN data set names that identifies theselevels can be reused as the SCLM group qualifier.

Set Up Groups with Information from ENDEVOR: ENDEVOR keeps information related tolevels or phases of the development process. These levels or phases are called stages andare provided in the logical structure of ENDEVOR. Therefore, stages do not affect thenaming convention of the physical files as SCLM groups do with the second-level qualifier.ENDEVOR provides two predefined stages per environment that can be identified by eitherthe standard name (STAGE1 and STAGE2), an identifier (A and B), or a name (TEST andPROD).

Chapter 3. Defining SCLM Project Setup 25

There is a strong correlation between SCLM groups and ENDEVOR stages, but we also haveto keep in mind ENDEVOR's environment information. It is not easy to translate the notion ofan ENDEVOR environment to SCLM directly. One way to handle that information is to mix itwith stage information in the SCLM groups; that is, both environment and stage informationbecome part of the group names. Because group names are restricted to eight charactersin SCLM, environment and stage names must be truncated to four characters if they arelonger than four characters in the existing environment.

ENDEVOR provides MOVE processors to promote objects from stage to stage. This impliesthat objects are physically moved between the stages, which corresponds to specifying theKEY option in the SCLM group definition.

TypesWe decided to put all objects coded in different languages into separate types; for example,Assembler source programs into type ASM, PL/I source programs into type PLI. Allvariations within one language, such as with or without DB2, and different releases of asingle language are put into the same type. Table 1 lists the types for our two applications.

SCLM allows you to store members of different languages in the same type. For example,you could store all your source code in an SCLM type SOURCE. However, for ease of use inthat case, you should use a naming convention that allows you to differentiate by namebetween source code written in different programming languages.

You may have to review the type definitions during the migration of the application controlinformation.

Table 1. SCLM Types Used in the Migration Project

Type Name Members Included Used forApplication

ARCHDEF Architecture definitions 1 + 2

ASM Assembler and Assembler DB2 source programs 1 + 2

ASMMACS Assembler macros and included members 1 + 2

COBOL All types of COBOL source programs 1

COBCOPY COBOL COPY members 1

DB2CLIST CLISTs for BIND 2

DB2OUT CLISTs for BIND/FREE during promote 2

SQL DDL members 2

PLI PL/I includes and source programs 1

DBRM DBRM members 2

OBJ Object modules 1 + 2

LIST Compile listings 1 + 2

LMAP Link edit listings 1 + 2

LOAD LOAD modules 1 + 2

CLIST CLISTs 1

PANELS ISPF panels 1

SKELS ISPF skeletons 1

MSGS ISPF message members 1


Table 1 shows the naming convention we used for the type names. We did not differentiatebetween members according to whether they belong to application 1 or 2.

We used the following approach to define our types:

Types provided by the existing environment that follow IBM proposed names, such asASM, DBRM, LOAD. You can also use customer standards that deviate from the IBMSCLM proposed names. What is important here is to take the opportunity of themigration to implement a new, or enforce an existing, naming convention.

Types not provided by the existing environment but required by SCLM, such asARCHDEF, DB2CLIST, DB2OUT.

New types implemented in SCLM, such as OBJ, LIST, LMAP. SCLM provides codeintegrity between all kinds of related data, and you may want to keep compile and linkedit listings synchronized with your source code and load modules.

In an ENDEVOR environment you can find information about type names in ENDEVOR report1 (System Inventory Profile). This report should be executed using the following selectionparameters:

EnvironmentSystemSubsystemStage.

You may want to use the existing type names especially if your migration objective is toclone the existing environment.

The CA-LIBRARIAN library system only stores source files. The term “ type” is not used byCA-LIBRARIAN. You can reuse the qualifiers from the existing data sets for member types,such as LOAD, CLIST, and PANELS, that are stored in PDSs if you do not want to change thenaming conventions.

Version and AuditWe decided to collect version and audit information for all types containing source membersin the top layer, PROD.

Set Up Version and Audit with Information from ENDEVOR: Versioning and auditing are setup in the existing ENDEVOR environment for application 2. You can create an elementreport using option “HIS” (for History) to show the ENDEVOR information related toversioning.

Auditing in ENDEVOR is defined using the environment definition table (SMF activity = YES)and provides an activity report that includes system management facility (SMF) data.

No actual version or audit data was migrated in our project. The only information we usedwas the fact that the customer had ENDEVOR collect version and audit information forapplication 2. Therefore, we had to implement versioning and auditing in our target SCLMenvironment.

Chapter 3. Defining SCLM Project Setup 27

LanguagesAsk the following questions to decide which SCLM language definitions you need:

Which language is to be associated with each source program?

Does SCLM provide the language definition?

If the language definition has to be modified or created, which member name andlanguage name (LANG= parameter) are to be used?

What are the SYSLIB libraries?

What are the translator options?

Finding the translator options is the most challenging part when setting up languagedefinitions for the migration. This subject is discussed in “Languages and Translators” onpage 33.

Accounting Data SetWe decided to split the SCLM accounting data set for our project. We defined an accountingdata set for each layer in our project hierarchy.

Technical Setup StepsThe technical setup has no special requirements in the context of migration. We must followthe steps below:

Compile and link the project definition.

Set up RACF profiles. We did not use RACF protection for the data sets in our project.In a real customer environment you want to protect all your data sets using RACF.

Allocate data sets. This allocation includes project definition PDSs, VSAM data sets,and application PDSs.

Customize ISPF/PDF; that is, customize skeletons for SCLM batch processing and ISPFinstallation data sets, for example, to prevent editing of SCLM members from outsideSCLM.

You can find general information about the technical SCLM setup in the ITSC RedbookSoftware Configuration and Library Manager WorkStation Platform/2 Usage Guide,GG24-3538.


Chapter 4. Migrating the Control InformationMigration of control information is the most challenging part of the whole migration process.You must find all parameters used in the existing environment and use them to build thenew SCLM environment, keeping the application itself unchanged.

If your old library system does not provide a real software configuration component, as isthe case for CA-LIBRARIAN, you must find all the required information by analyzing theexisting modules and/or by looking into control information files that have been filled bycustomer-specific procedures during the release process. Therefore, migration of controlinformation may vary considerably from one installation to another. In this chapter we showhow we migrated the control information for the two selected sample applications anddescribe some tools that may be useful to you.

Figure 6 on page 30 and Figure 7 on page 32 present an overview of the basic stepsrequired to extract and use control information. Figure 6 shows the basic flow for handlingcontrol information in our migration project. The steps are discussed in more detail in thesections that follow; technical details are listed in Appendix B, “Methods and Tools forAnalyzing Existing Applications” on page 77.


Figure 6. Extraction and Use of Control Information. The numbers in the figure are explained in thetext.

The following remarks refer to the numbers in the figure:


(1) PDS with released programs extracted from CA-LIBRARIAN. This corresponds to filePP in Figure 4 on page 20. Formatted control information is stored in leadingcomment records. These comments were added by the customer's releaseprocedure.

(2) EDIT macro MIGE0040 separates the comment records from the source code for eachprogram. A PDS member is created for the comment records of one program. All thePDS members are copied together into one single file.

(3) Control information records are sorted by module type (COBOL/ASM/PLI). For somevery old modules the module type was added manually. The information about thetranslator options is used to select defaults for the SCLM language definitions.

(4) REXX procedure MIGR0040 converts the information into a common format forapplication 1 and application 2. All previously specified options that are defaults inthe SCLM language definition of the migration environment are eliminated.Compatibility options for old modules are added automatically.

(5) This is the ENDEVOR archive file extracted from the environment of application 2.(6) REXX procedure MIGR0030 extracts information about translator options from the

ENDEVOR archive file.(7) This control information file already has the common format of file 9 but contains all

options extracted from the old environment.(8) All previously specified options that are defaults in the SCLM language definition of

the migration environment are eliminated manually.(9) This is the common format file used for both sample applications. This file contains

all information needed to create link edit control (LEC) and—if required—compilationcontrol (CC) architecture definitions.

(10) REXX procedure MIGR0010 creates the LEC and CC architecture definitions. It can beused unchanged in other environments, or it can be easily adjusted to other inputformats.

(11) The architecture definitions can be directly created in the SCLM ARCHDEF PDS.(12) Because the members are created outside SCLM, they must be migrated.(13) The migrated architecture definition members are now ready for use.

Figure 7 on page 32 shows the extraction of complementary control information from loadmodules. Two types of information are extracted:

Compiler product and release information

For VS COBOL II modules, COBOL information bytes that contain information about thecompiler release and the options used at compile time.

You can use the methods presented here in other environments. They are based on thestructure of the load modules. You will find it particularly useful to apply these methods ifyou cannot extract the required control information elsewhere. We found most of therequired information to create the LEC and CC architecture definitions from the steps shownin Figure 6 on page 30.

The information extracted from load modules helped us to decide which SCLM languages touse in our project and to identify where old compiler releases were used in the oldenvironment. The statistics on VS COBOL II compiler options served as a basis for settingup the SCLM translator defaults for VS COBOL II. The resulting files of this extractionprocess contain the module names that we used to create member lists for copying in thebulk data migration.

Chapter 4. Migrating the Control Information 31

Figure 7. Extraction of Information from Load Modules. The numbers in the figure are explained inthe text.

(1) Load modules from the customer's production environment for the two sampleapplications.

(2) Program MIGU001 checks for compiler product numbers in the load modules.(3) Output from MIGU001 is a PDS with each member containing one record per load

module. The members are copied into one file for further use.(4) Program MIGU002 checks for VS COBOL II information bytes in the load modules.(5) Output from MIGU002 is a PDS with one member per load module. The members are

copied into one file for further use.(6) Separate lists are created for the different SCLM types, and for COBOL, for the

different languages. Information about VS COBOL II release and optionCMPR2/NOCMPR2 was used to split into SCLM languages. Reformatting meansremoving everything except the module names and adding “SELECT MEMBER= ” infront of the module name to create input files for IEBCOPY.

(7) The member lists are used during bulk data migration (refer to Chapter 5, “Migratingthe Bulk Data” on page 49).

All steps are discussed in more detail in the sections that follow. Technical details are listedin Appendix B, “Methods and Tools for Analyzing Existing Applications” on page 77.


Languages and TranslatorsSCLM offers a wide range of language definitions, many more than you normally need inone project or even in the whole enterprise. You must find out which of these languagedefinitions are required in your environment, whether some customization needs to be done,or whether additional language definitions must be developed—because you use a specialpreprocessor for a programming language, for example.

It is not sufficient to know that COBOL and Assembler programs exist in your application.You should also know if all COBOL programs are written in VS COBOL II or if there are stillsome old OS/VS COBOL programs. You must find out which preprocessors (CICS, SQL) areused together with which compilers.

Other module types, such as TSO CLISTs or DB2 DDL statements, must be considered.

Some compilers support different language levels, for instance:

VS COBOL II Release 3 with option NOCMPR2 for the ANSI 85 standard or with optionCMPR2 for Release 2 source compatibility

OS/VS COBOL Release 2 with option LANGLVL(2) for ANSI 74 or with optionLANGLVL(1) for ANSI 68 standard support

OS PL/I Version 2 with option CMPAT(V2) or option CMPAT(V1) for source compatibilitywith Version 1.

If you have source code at different language levels you have two solutions:

Use one SCLM language definition for the compiler. This language definition normallyuses a set of compiler options either by using the defaults or by explicit specification ofthe options in the build translator definition.

For modules that need other compiler options, those options must be specified in a CCarchitecture definition. Overriding of compiler options specified in a translator definitionmust be allowed by specifying OPTFLAG=Y in the FLMTRNSL macro and OPTOVER=Yin the FLMCNTRL macro (default value).

Have two different SCLM language definitions for the same compiler. Each languagedefinition works with a different set of compiler options.

If all modules with a particular language use the same set of compiler options, you maywant to inhibit overriding of compiler options by specifying OPTFLAG=N in theFLMTRNSL macro.

SCLM Languages Used in the Migration Project

The types of modules in an application determine the SCLM language definitions you need.You may choose to have more than one language definition for one compiler. We used thelanguage definitions listed in Table 2 for our project.

Table 2 (Page 1 of 2). SCLM Languages Used in the Migration Project. Member nameswith FLM@... refer to the original IBM-supplied language definitions inthe ISR.V3R5M0.ISRMACS library of ISPF/PDF Version 3 Release 5.Member names with F@... are customized language definitions for thisproject.

MemberName

LanguageName

Language Definition for Used forAppl.

FLM@ARCH ARCHDEF SCLM architecture definition language 1 + 2


Because many COBOL modules in application 1 were compiled with VS COBOL II Release 1or Release 2 or with VS COBOL II Release 3 using the CMPR2 option, we decided to use twotranslators for VS COBOL II. (Migration of these modules to the latest COBOL standard isplanned as a separate project by the customer and is outside the scope of our project.)

Using two languages for the same compiler allows for easy identification of the “old ”modules that reside in the same library as the “new ” modules. You can use the SCLMDBUTIL service with “LANGUAGE” as a selection criterion for this purpose.

Because our sample applications contained a limited number of OS/VS COBOL modules thatrequire option LANGLVL(1) and PL/I modules that require option CMPAT(V1), we used onlyone language definition for those two compilers and specified compatibility options as part ofCC architecture definitions for the modules affected. Details on compiler options and CCarchitecture definitions are discussed in “Compiler Options” on page 36 and “Creating LECand CC Architecture Definitions” on page 44.

Languages for CLISTs, ISPF panels, message members, and skeletons have only a PARSEand no BUILD translator. Panels and message members are parsed like TEXT. Forskeletons we used the skeleton parser listed in the SCLM Guide and Reference, SC34-4254.This parser traces embedded skeletons and handles them as included members, likeCOBOL copy books for COBOL programs. Therefore, only the main skeletons have to bereferenced in the architecture definitions (refer to Figure 75 on page 121).

Table 2 (Page 2 of 2). SCLM Languages Used in the Migration Project. Member nameswith FLM@... refer to the original IBM-supplied language definitions inthe ISR.V3R5M0.ISRMACS library of ISPF/PDF Version 3 Release 5.Member names with F@... are customized language definitions for thisproject.

MemberName

LanguageName

Language Definition for Used forAppl.

F@ASMH ASMH Assembler H 1 + 2

F@COBL COBOL OS/VS COBOL 1

F@COB2 COB2 VS COBOL II ANSI 85 standard 1

F@COB22 COB22 VS COBOL II with option CMPR2 1

F@PLIO PLIO OS PL/I Version 2 1

F@AD2 ASMDB2 Assembler H with DB2 preprocessor 2

FLM@BD2 DB2CLIST DB2 BIND/FREE CLIST 2

FLM@BDO DB2OUT DB2 BIND/FREE CLIST output 2

F@SCMD SCMD DB2 DDL subcommands 2

F@L370 LE370 Linkage editor 1 + 2

FLM@CLST CLIST TSO CLISTs 1

F@PANELS PANELS ISPF panels 1

F@@SKEL SKELS ISPF skeletons 1

F@MSGS MSGS ISPF message members 1


Compilers Used in the Old Environment

Depending on the library system used and/or additional functions added on top of the oldlibrary system, you may have a detailed knowledge of which compiler version was used toproduce the load module now in production.

Find Compiler Used with CA-LIBRARIAN: In an environment with a CA-LIBRARIAN librarysystem you may want to look at:

The CA-LIBRARIAN LANG information

This is a code (one to three characters) that can be assigned to a module to identify itslanguage. CA-LIBRARIAN itself only stores this information, and it is up to the customerto use rigid conventions for this information field. We did not use this informationbecause the naming conventions were not consistently used for application 1.

Control information stored by in-house developed release procedures.

Such information was available for sample application 1 in the extra CA-LIBRARIANcontrol file (see “Release Process” on page 13). For old modules compiled beforeintroducing the release concept, this information was taken from the load modules.

If some of the modules in your application need to be processed by preprocessors, thesources just described might be the only place where you can find which preprocessor wasused for which module.

The product numbers of the compilers used can be found in the load module. For sampleapplication 1 we extracted the information from the load modules using a simple PL/Iprogram, MIGU001. The source for this program and a description of its use and restrictionscan be found in “Compiler Information” on page 77. The output of the program includes onerecord per module that contains the product number of the compiler used for compilation.We used the resulting list as the basis for grouping the source modules and assigning theproper SCLM language (see Chapter 5, “Migrating the Bulk Data” on page 49).

For VS COBOL II you should also know which compiler release was used. This is discussedin “Compiler Options” on page 36, together with how you can extract VS COBOL II compileroptions.

Find Compiler Used with ENDEVOR: ENDEVOR is not only a library management system buta software configuration management system. It manages relationships between objectsand therefore is capable of managing the process of transforming source code into loadmodules.

This point is important to keep in mind when trying to find the compilers used in the existingenvironment. Although ENDEVOR stores information about compilers differently from SCLM,the information exists and there is no need to analyze load modules as you do in aCA-LIBRARIAN environment.

ENDEVOR stores information about so-called processors. There is a one-to-one relationshipbetween a processor and a JCL member. The job in the JCL member calls the compiler.Each time the processor is called, the related JCL is submitted in background. Theprocessor used for each object can be found by using browse dialogs provided by ENDEVORor by using ENDEVOR report listings.

As we did not have an ENDEVOR system available in our environment, we used ENDEVORreport listings to find all our information. Specify PRINT in the SCL used to create anelement report. Refer to the sample SCL for element GNDV0050 in “Find Information forLanguages” on page 96. The processor name for a particular element can be found in the“Element information” part of the report.

We recommend that you direct the output of the report to a data set for reports that you runagainst a large number of elements.


The processor name is eight characters long and can be used directly as the language(LANG=) parameter in the FLMLANGL macro of SCLM if you want to clone your existingenvironment in SCLM. In that case you may also want to use the processor name as thename of the language definition member.

We decided to use a new naming convention for the language definition member andlanguage names. This naming convention is explained in “SCLM Languages Used in theMigration Project” on page 33.

Once the processor name is found, it is easy to find the related JCL and therefore thecompiler used.

For each element and each processor, you can find the compiler options and SYSLIBlibraries used. The SYSLIB libraries information is contained in the “Input components” partof the report. Compiler options are discussed in “Compiler Options.”

Compiler OptionsMost compilers offer different ways of specifying compiler options and have different rulesfor the order in which these options are processed. The “Programming Guide” manualsusually contain information about compiler options.

For VS COBOL II, you find the compiler options in Part 4 of the VS COBOL II ApplicationProgramming Guide for MVS and CMS, SC26-4045. The order of precedence for VS COBOLII compiler options is as follows:

1. Fixed installation defaults

Options that are fixed for an installation cannot be overridden for an individualcompilation. These options are not affected by the migration process.

2. Options specified on a COBOL PROCESS (or CBL) statement at the beginning of thesource module

This is the method you can use to keep specific compiler options together with thesource code without using a software configuration tool. The use of the PROCESS (orCBL) statement can be disallowed for an installation with the default options module ofthe COBOL compiler.

If you use this method of specifying compiler options, you should decide whether youwant to:

Stay with these PROCESS (or CBL) statements

Specify the options in CC architecture definitions and remove the PROCESS (orCBL) statements from the source code.

We do not recommend that you use both—PROCESS statements and compiler PARMspecifications in CC architecture definitions—simultaneously.

3. Options specified with PARM= on EXEC statements of compile jobs

You may use this method to override enterprise standards or to add additional options.Knowing if and where these options are stored will depend on the softwareconfiguration management in your installation. Some options may have been coded instandard procedures.

4. Nonfixed installation defaults

These defaults are used if an option is not specified elsewhere. In a given installationthese defaults remain unchanged during the migration.


Because our environment was not identical to the customer environments from wherethe applications came, we had to override some installation defaults to meet thecustomers' installation defaults. We did this by customizing the SCLM languagedefinitions.

Similar rules apply to PL/I programs: *PROCESS statements at the beginning of the sourcecode override the options given as PARMs on the EXEC statement of the compile job, andthese again override the installation defaults. For more details see the OS PL/I Version 2Programming Guide, SC26-4307.

Compiler Options in SCLM

The compiler options that can be specified in SCLM correspond to those that can bespecified in the PARMs of the EXEC statement for a batch compile job. There are twodifferent places to specify compiler options in SCLM:

The OPTIONS parameter of the FLMTRNSL macro

A PARM (or PARMx) record in a CC architecture definition for an individual module.

The PARM specification in the CC architecture definition overrides the OPTIONS of thetranslator. If you have a common set of compile options for all modules with the sameSCLM language, you do not need CC architecture definitions at all. Therefore, it is importantto find the set of the most commonly used options for each language in order to reduce thenumber of CC architecture definitions to a minimum.

All specifications in SCLM are overridden by COBOL PROCESS (or CBL) or PL/I *PROCESSstatements in the source code. If you use such statements, you should consider changingthis information to PARM information in CC architecture definitions. Our sample applicationsdid not use PROCESS or *PROCESS statements in the source code.

Finding VS COBOL II Compiler Options for Application 1

VS COBOL II stores information about the compiler options used in each load module in the“COBOL Information Bytes.” This information is part of the VS COBOL II programinitialization code, where you also find other information, such as PROGRAM-ID, version,release, and modification of the compiler, time stamps, and number of statements. You canfind a detailed description of the VS COBOL II program initialization code in VS COBOL IIApplication Programming: Debugging, SC26-4049.

For application 1 we extracted the information from the load modules using a COBOLprogram, MIGU002. The source for this program and a description of its use and restrictionscan be found in “VS COBOL II Compiler Options” on page 82. The output of the programincludes one record per module that contains the bit pattern of the compiler options in theload module mapped to a byte pattern. Therefore, for each compiler option a “1 ” indicatesthat the option is on, and a “0 ” indicates that the option is off. Table 3 summarizes resultsof the analysis for application 1.

Table 3 (Page 1 of 3). VS COBOL II Compile-Time Options in Effect. This information istaken from the COBOL information bytes for the 114 VS COBOL IImodules of application 1. NoM is the number of modules that use theoption, InD indicates whether this option is an installation default in ourenvironment, and Rem gives a reference to special remarks in the text.

Option On NoM InD Option Off NoM InD Rem

ADV 0 Yes NOADV All No

APOST All No QUOTE 0 Yes




DATA(31) 3 Yes DATA(24) 111 No (1)

DECK 0 No NODECK All Yes

DUMP 0 No NODUMP All Yes

DYNAM All No NODYNAM 0 Yes

FASTSRT 0 No NOFASTSRT All Yes

FDUMP 0 No NOFDUMP All Yes

LIB 0 No NOLIB All Yes (2)

LIST 0 No NOLIST All Yes

MAP All No NOMAP 0 Yes

NUM 18 No NONUM 96 Yes (3)

OBJ All Yes NOOBJ 0 No

OFFSET All No NOOFFSET 0 Yes

OPTIMIZE All No NOOPTIMIZE 0 Yes

DDNAME supplied inOUTDD option will beused

0 No Default DDNAME forOUTDD will be used

All Yes

NUMPROC(PFD) 0 No NUMPROC(NOPFD) All Yes

RENT 90 No NORENT 24 Yes (4)

RES All No NORES 0 Yes

SEQUENCE 0 Yes NOSEQUENCE All No

SIZE(MAX) All Yes SIZE(value) 0 No

SOURCE All Yes NOSOURCE 0 No

SSRANGE 14 No NOSSRANGE 100 Yes (5)

TERM 0 No NOTERM All Yes

TEST 0 No NOTEST All Yes

TRUNC(STD) 0 Yes TRUNC(OPT) All Yes (6)

User-supplied reservedword list

0 No Installation defaultreserved word list

All Yes

VBREF 0 No NOVBREF All Yes

XREF All No NOXREF 0 Yes

ZWB All Yes NOZWB 0 No

NAME 0 No NONAME All Yes

CMPR2 7 No NOCMPR2 107 Yes (7)

NUMPROC(MIG) 0 No

NUMCLASS 4 No NONUMCLASS 110 Yes (8)

DBCS 0 No NODBCS All Yes

AWO 0 No NOAWO All Yes


Based on the information in Table 3 on page 37 we applied the following rules for ourproject:

If an option is used for all modules and the option is an installation default, the optiondoes not have to be specified.

If an option is used for all modules and the option is not an installation default, theoption must be specified in the OPTIONS= parameter of the FLMTRNSL macro in theSCLM language definition.

If an option is not common for all modules, the following approach is used:

− If the option is used for many modules and the option is not an installation default,the option must be specified in the OPTIONS= parameter of the FLMTRNSL macroin the SCLM language definition.

− For the remaining modules the complementary option must be specified in a PARM(or PARMx) statement in a CC architecture definition.

Here are some special considerations for some of the VS COBOL II options (the numbersrefer to the Rem column in Table 3 on page 37):

(1) According to the above rules, modules with option DATA(31) require CC architecturedefinitions.

(2) NOLIB was always used in the old environment because the existing compileprocedure passes the source code as one single file to the compiler. With SCLM,option LIB is required because the compiler will take the copy books from PDSs.

(3) New customer standard is NONUM; NUM will not be specified.

(4) New customer standard is RENT; NORENT will not be specified.

(5) All modules in production must be compiled with NOSSRANGE; SSRANGE will nolonger be specified.

(6) For Release 3 modules TRUNC(BIN) is equivalent to NOTRUNC for Release 2 modules.All our Release 2 modules use NOTRUNC, all Release 3 modules use TRUNC(BIN). Wetherefore specified TRUNC(BIN) for all modules.

(7) The NOCMPR2/CMPR2 (compatibility with Release 2) options are only relevant formodules compiled with Release 3. All Release 2 modules must use CMPR2. Asmentioned earlier, we decided to use two different SCLM language definitions for VSCOBOL II, one with option CMPR2, and one with option NOCMPR2. This optiontherefore determines which language must be assigned to a module during the sourcecode migration (see Chapter 5, “Migrating the Bulk Data” on page 49).

(8) This option can be specified only at installation time. The four NUMCLASS moduleswere compiled during a month when different VS COBOL II installation options were ineffect. This was probably not done on purpose. Our default NONUMCLASS matchesthe standard customer default.



TRUNC(BIN) 20 No (6)


Other Information about Compiler Options for Application 1

The previous analysis was restricted to VS COBOL II modules. Other compilers do not storeinformation about compiler options in this way. Therefore, you have to look for moregeneral information sources at least for other than COBOL compilers.

The need to know the correct compiler options for the migration to SCLM corresponds to theneed to know these options for compilation of a module in the old environment formaintenance reasons. If you know how to get the correct options for maintenance, you alsoknow how to extract it for migration purposes.

In a CA-LIBRARIAN environment there is no standard way to store this information, and theanalysis is therefore very customer-specific.

In our application 1 environment all the final compilations were performed under control ofthe existing program release procedure (see “Release Process” on page 13). The compilejobs are dynamically created from skeletons when the release process is initiated by thedevelopers. Options that are fix coded in the skeletons cannot be changed by applicationdevelopers.

Some other options are allowed to differ from the standards. These options are specified onlanguage-specific panels within the interactive dialog of the release process, and they arestored in special comment records as part of the source code. The last used options arealways the defaults for the next release of the same program.

The following information was available:

Skeletons for the JCL of compile steps with the fixed options for program release

Module-specific compiler options as comment records in the released module sourcecode.

The detailed analysis procedure for non-VS COBOL II programs of application 1 is describedin “Extracting Compile and Link Edit Information” on page 88. The result of this analysis ishandled following the same guidelines as described for VS COBOL II. Together with thecontrol information for the linkage editor (refer to “Control Information for the LinkageEditor” on page 41), this analysis provides the input for creating the low-level architecturedefinitions. The automated generation of these members is described in “Creating LEC andCC Architecture Definitions” on page 44.

Information about Compiler Options for Application 2

Compiler options are kept in ENDEVOR for each processor and therefore for each element.When using the report created by executing the SCL described in “Find Information forLanguages” on page 96, you find the information about compiler options under “Symbolinformation” in the report.

Using the ENDEVOR reports was not the best solution in our case for the following reasons:

We did not have the report output in machine-readable form.

ENDEVOR was not installed in our environment, and the reports could not be reexecutedto store the output in a data set.

Creating the input file for tool MIGR0010 manually from the report listings was notefficient.

The information about compiler options is also available in the ENDEVOR archive file.However, the format of this file is not easy to read for manual analysis.


For all these reasons we decided to create a tool (MIGR0030) to extract compiler optioninformation from an ENDEVOR archive file and to create the input file required for toolMIGR0010. The MIGR0030 extraction tool is described in “Extract Control Information fromENDEVOR Archive File” on page 97.

After running MIGR0030 you may have to edit the formatted file to remove compiler optionsthat are either defaults or handled in the SCLM language definition. Figure 8 shows theformatted file before editing.

GNDV0050 ASM OBJECT,NODECK,XREF(SHORT) AMODE=24,RMODE=24,CAGNDV0100 ASM OBJECT,NODECK,XREF(SHORT) AMODE=24,RMODE=24,CAGNDV0200 ASM OBJECT,NODECK,XREF(SHORT) AMODE=24,RMODE=24,CAGNDV0300 ASM OBJECT,NODECK,XREF(SHORT) AMODE=24,RMODE=24,CAGNDV0400 ASM OBJECT,NODECK,XREF(SHORT) AMODE=24,RMODE=24,CAGNDV0500 ASM OBJECT,NODECK,XREF(SHORT) AMODE=24,RMODE=24,CA

Figure 8. Formatted File before Editing

The first column contains the element name, the second column contains the type, and thethird column contains the compiler options. The last column in the formatted file containsthe linkage edit control options. Use of linkage edit control options is discussed below under“Control Information for the Linkage Editor.” The records in Figure 8 are truncated (linkageedit control option A C = 1 is not visible).

Figure 9 shows the formatted file after editing.

GNDV0050 ASM AC=1GNDV0100 ASM AC=1GNDV0200 ASM AC=1GNDV0300 ASM AC=1GNDV0400 ASM AC=1GNDV0500 ASM AC=1

Figure 9. Formatted File after Editing

All compiler options are removed during editing because they are either common or defaultoptions (except linkage edit control option AC=1).

Control Information for the Linkage EditorThis section explains how to find the linkage editor control information used to create theload modules in the existing environment and how to migrate this information to the SCLMenvironment. Linkage editor control information includes:

Attributes like RENT or REUS.

As for the compiler options, the most commonly used options should be used as thedefaults for the linkage editor SCLM language definition. Only nondefault options arespecified in LEC architecture definitions for individual programs.

AMODE and RMODE parameter.

Defaults for these parameters come from the input to the linkage editor, for example:

− VS COBOL II modules will get AMODE=31, RMODE=ANY by default

− OS/VS COBOL modules will get AMODE=24, RMODE=24 by default


− Assembler modules will get AMODE=24, RMODE=24, if explicit Assembler AMODEand/or RMODE statements are not coded in the program.

ENTRY and ALIAS statements.

Names of modules that are statically linked to the program.

This may have been done by linkage editor INCLUDE statements or with the AUTOCALLfacility of the linkage editor.

You may find this linkage editor control information:

In your existing library system if it has a software configuration component, as is thecase for ENDEVOR

In files filled by in-house developed program release procedures

By analyzing the load modules

By analyzing the output of the IBM AMBLIST utility. The AMBLIST utility provides thefollowing functions:

− Produces formatted listings of object and load modules− Creates load module maps and cross-reference listings− Creates load module summary− Lists data stored in load module CSECT identification records− Creates a map of the system nucleus or link pack area.

In our migration project we extracted linkage editor control information as follows:

For application 1 from information stored by the in-house developed release procedure.

This information is stored together with the compiler options in comment records aspart of the released source code (refer to “Release Process” on page 13). Thecustomer's standard is to use dynamic calls to subroutines. Only a few modules arelinked to main programs, and this is always done with explicit linkage editor INCLUDEstatements to keep track of these included modules in the release procedure.

The extraction of this linkage editor control information for application 1 is described in“Extracting Compile and Link Edit Information” on page 88.

For application 2 from an ENDEVOR archive file.

This archive file (refer to “Application 2” on page 21) contains the control informationrequired for migration. The extraction of data from this file with our extraction toolMIGR0030 is described in “Extract Control Information from ENDEVOR Archive File” onpage 97.

All extracted linkage editor control information required to build the correct LEC architecturedefinitions was put into input files for the common tool to create the low-level SCLMarchitecture definition members (see “Creating LEC and CC Architecture Definitions” onpage 44).

If you do not have information about link edit options, we recommend that you extract it fromthe output of the IBM AMBLIST utility. This utility takes the information from the loadmodule and presents it in a formatted way. Figure 10 on page 43 shows a sample job torun AMBLIST, and Figure 11 on page 43 presents the AMBLIST output from this job.


//....... JOB ................, 00010000// ..................... 00020000//*==================================================================== 00030000//AMBLIST EXEC PGM=AMBLIST 00040000//SYSLIB DD DISP=SHR,DSN=STADE5.RUV.LOAD 00050000//SYSIN DD * 00070000

LISTLOAD OUTPUT=XREF,MEMBER=P92N041 00080000/* 00090000//SYSPRINT DD SYSOUT=T 00091000//*==================================================================== 00100000

Figure 10. Sample Job to Run the IBM AMBLIST Utility

LISTLOAD OUTPUT=XREF,MEMBER=P92N041 00080000***** M O D U L E S U M M A R Y *****

MEMBER NAME P92N041 MAIN ENTRY POINT 000000 AMODE OF MAIN ENTRY POINT 24** ALIASES ** ALIAS ENTRY POINT AMODE OF ALIAS ENTRY POINT

------------------------------------------------------------------------------------------------------------------------**** LINKAGE EDITOR ATTRIBUTES OF MODULE ****

** BIT STATUS BIT STATUS BIT STATUS BIT STATUS **0 NOT-RENT 1 NOT-REUS 2 NOT-OVLY 3 NOT-TEST4 NOT-OL 5 BLOCK 6 EXEC 7 MULTI-RCD8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 RLD12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR

------------------------------------------------------------------------------------------------------------------------MODULE SSI: 00841126APFCODE 00000000RMODE 24

*****LOAD MODULE PROCESSED BY VS LINKAGE EDITORNUMERICAL MAP AND CROSS-REFERENCE LIST OF LOAD MODULE P92N041 PAGE 0001

CONTROL SECTION ENTRYLMOD LOC NAME LENGTH TYPE LMOD LOC CSECT LOC NAME

00 P92N041 434 SD438 P92N010 1BDA SD

2018 P92N011 856 SD------------------------------------------------------------------------------------------------------------------------

LMOD LOC CSECT LOC IN CSECT REFERS TO SYMBOL AT LMOD LOC CSECT LOC IN CSECT3CC 3CC P92N041 P92N010 438 00 P92N0103D0 3D0 P92N041 P92N011 2018 00 P92N011

LENGTH OF LOAD MODULE 2870ALPHABETICAL MAP OF LOAD MODULE P92N041 PAGE 0002

CONTROL SECTION ENTRYNAME LMOD LOC LENGTH TYPE NAME LMOD LOC CSECT LOC CSECT NAME

P92N010 438 1BDA SDP92N011 2018 856 SDP92N041 00 434 SD

ALPHABETICAL CROSS-REFERENCE LIST OF LOAD MODULE P92N041 PAGE 0003

SYMBOL AT LMOD LOC CSECT LOC IN CSECT IS REFERRED TO BY LMOD LOC CSECT LOC IN CSECTP92N010 438 00 P92N010 3CC 3CC P92N041P92N011 2018 00 P92N011 3D0 3D0 P92N041

** END OF MAP AND CROSS-REFERENCE LISTING

Figure 11. AMBLIST Output for Assembler Load Module P92N041. This output shows that P92N041 has attributesNOT-RENT, NOT-REUS, AMODE=24, RMODE=24, and so on. The listing of CONTROL SECTIONsindicates that modules P92N010 and P92N011 are linked to P92N041.


Creating LEC and CC Architecture DefinitionsWe used SCLM language definitions with BUILD translators for the precompile (if required)and the compile step only. We used a separate language for the linkage editor. This is thenormal way to set up language definitions in SCLM.

When you have a separate SCLM language for the linkage editor, you must have an LECarchitecture definition for each program. As long as you use the default compile options ofthe BUILD translator, you do not need to create a CC architecture definition for a program.A CC architecture definition is only required if you want to specify nonstandard compileroptions (see “Compiler Options” on page 36). The LEC architecture definition looks differentif you use a CC architecture definition for a program.

We automated the generation of LEC and—if necessary—CC architecture definitions for ourmigration. The tool to generate these members is described in “LEC and CC ArchitectureDefinitions” on page 123 together with a complete source listing. Our REXX procedureMIGR0010 read an input file that resulted from extracting control information for compile andlink edit from the existing applications as described in “Compiler Options” on page 36 and“Control Information for the Linkage Editor” on page 41.

We generated the architecture definitions directly into the SCLM PDSs of type ARCHDEF andgroup MIG1 (for application 1) and MIG2 (for application 2). The SCLM migration utility(Option 3.3 within SCLM) was used to create the SCLM accounting information for thesemembers. You should specify “ * ” for MEMBER and “ARCHDEF” for LANGUAGE in the SCLMmigration utility panel to migrate all new architecture definition members in one PDS.Because of the large number of members, we recommend that you execute the migrationutility in batch mode using the SUBMIT command on the SCLM migration utility panel.

We used the following naming conventions:

The same name was used for source, object, and load module and for all list membersof a program.

The LEC architecture definition member name was identical to the name of the sourceprogram.

The CC architecture definition member name was built from the name of the sourceprogram prefixed with “C. ” This CC naming rule was possible because all programnames in application 1 had no more than seven digits. Application 2 had eight-digitprogram names, but no CC architecture definition members were required for thoseprograms.

For environments with other naming conventions our generation tool must be modified tomeet customer requirements. The input record for each module contains:

NameType

and optional:

Nondefault compiler optionsNondefault linkage editor optionsNames of modules that must be linked to the program.

Figure 12 on page 45 through Figure 18 on page 47 show examples of the input files for ourtool and of the generated output members.

If you want to use the same name for CC and LEC architecture definitions, you can definetwo separate SCLM types for CC and LEC architecture definition members.

Figure 12 on page 45 shows input for COBOL programs. This input file contains the recordsfor the OS/VS COBOL modules, the VS COBOL II modules with CMPR2, and the VS COBOL II


modules with NOCMPR2. Samples of the generated output from this input file are shown inFigure 13 on page 45 for program P92N002 and in Figure 14 on page 46 for programP92N046.

For P92N002 the CC architecture definition was required to specify the nondefaultLANGLVL(1) compiler option with the PARM1 keyword. Use of the PARM1 keyword (insteadof PARM) allows you to direct the options to a specific BUILD translator within the SCLMlanguage definition. In the FLMTRNSL macro for the compiler you then have to codePARMKWD=PARM1 (refer to language definitions in “Language Definitions” on page 104).This coding is required only if you have more than one BUILD translator in your languagedefinition, for example, preprocessor and compiler. We recommend that you handleparameter input for translators in a uniform way for all languages. We decided to usePARM1 for all compiler options. The source code reference to program P92N002 was madewith the SINC keyword in the CC architecture definition member.

Program P92N046 uses the common compiler options assigned to its language. No CCarchitecture definition was required. The source code reference was made with the INCLDkeyword.

P92N000 COBOLP92N002 COBOL LANGLVL(1)P92N004 COBOL LANGLVL(1)P92N005 COBOL RENT,AMODE=24P92N008 COBOL RENTP92N009 COBOL LANGLVL(1)...P92N044 COBOL RENTP92N045 COBOLP92N046 COBOL RENTP92N047 COBOL RENTP92N048 COBOL RENT,AMODE=24P92N049 COBOL RENT...P92N349 COBOL RENTP92N362 COBOL DATA(31) RENTP92N363 COBOL RENTP92N399 COBOL DATA(31) RENT

Figure 12. Input Records to Create LEC and CC Architecture Definitions for COBOL Programs

* LEC ARCHDEF FOR PGM P92N002LKED LE370 * TRANSLATOR FOR LINK EDITLOAD P92N002 LOAD * LOAD MODULELMAP P92N002 LMAP * LINKAGE EDITOR OUTPUTINCL CP92N002 ARCHDEF * CC ARCHDEF MEMBER

* CC ARCHDEF FOR PGM P92N002OBJ P92N002 OBJ * OBJECT MODULELIST P92N002 LIST * COMPILER LISTINGSINC P92N002 COBOL * SOURCE MODULEPARM1 LANGLVL(1)

Figure 13. LEC and CC Architecture Definitions for OS/VS COBOL Program P92N002


* LEC ARCHDEF FOR PGM P92N046LKED LE370 * TRANSLATOR FOR LINK EDITLOAD P92N046 LOAD * LOAD MODULELMAP P92N046 LMAP * LINKAGE EDITOR OUTPUTINCLD P92N046 COBOL * SOURCE MODULEPARM RENT

Figure 14. LEC Architecture Definition for VS COBOL II Program P92N046

Figure 15 shows input for PL/I programs. A sample of the generated output from this inputfile is shown in Figure 16 for program P94N353.

The LEC architecture definition for P94N353 had the nondefault option AMODE=24 codedwith the PARM keyword. The CC architecture definition was required to specify thenondefault compiler options with the PARM1 keyword. The source code reference wasmade with the SINC keyword in the CC architecture definition.

P92N065 PLI CMPAT(V1) AMODE=24P92N066 PLI CMPAT(V1) AMODE=24P92N343 PLI CMPAT(V1) AMODE=24P94N353 PLI OPT(0),CMPAT(V1) AMODE=24

Figure 15. Input Records to Create LEC and CC Architecture Definitions for PL/I Programs

* LEC ARCHDEF FOR PGM P94N353LKED LE370 * TRANSLATOR FOR LINK EDITLOAD P94N353 LOAD * LOAD MODULELMAP P94N353 LMAP * LINKAGE EDITOR OUTPUTINCL CP94N353 ARCHDEF * CC ARCHDEF MEMBERPARM AMODE=24

* CC ARCHDEF FOR PGM P94N353OBJ P94N353 OBJ * OBJECT MODULELIST P94N353 LIST * COMPILER LISTINGSINC P94N353 PLI * SOURCE MODULEPARM1 OPT(0),CMPAT(V1)

Figure 16. LEC and CC Architecture Definitions for PL/I Program P94N353

Figure 17 on page 47 shows input for Assembler programs. A sample of the generatedoutput from this input file is shown in Figure 18 on page 47 for program P92N041.

This program used the common compiler options assigned to its language. No CCarchitecture definition was required. The source code reference was made with the INCLDkeyword. Two modules (P92N010 and P92N011) are linked to this program. The reference tothese modules was made with the INCL keyword referring to their LEC architecturedefinitions.


KR00030 ASMP03N905 ASMP92N001 ASMP92N003 ASMP92N006 ASMP92N022 ASM----+----1----+----2----+----3----+----4----+----5----+----6----+----7--P92N041 ASM

(line continued:) -+----9----+----0----+----1----+----2----+----3--<COLSP92N010 P92N011

P92N219 ASMP92N242 ASM...P94N053 ASM REUSP94N066 ASMP94N115 ASM REUS

Figure 17. Input Records to Create LEC and CC Architecture Definitions for Assembler Programs

* LEC ARCHDEF FOR PGM P92N041LKED LE370 * TRANSLATOR FOR LINK EDITLOAD P92N041 LOAD * LOAD MODULELMAP P92N041 LMAP * LINKAGE EDITOR OUTPUTINCLD P92N041 ASM * SOURCE MODULEINCL P92N010 ARCHDEF * STATIC LINKED MODULEINCL P92N011 ARCHDEF * STATIC LINKED MODULE

Figure 18. LEC Architecture Definition for Assembler Program P92N041

For application 2, we had to reference DDL members in the architecture definitions using thePROM keyword. We could use either an HL or LEC architecture definition. In most cases itis better to reference the DDL member in an HL architecture definition, because DB2 tablesare very often used by many programs within one application, or even by more than oneapplication. For our project, because we had only five DDL members and each one wasrelated to only one program, we decided to reference the DDL members in LEC architecturedefinitions.

DB2CLIST ConsiderationsSCLM manages the relationship between a program and its DB2 plan through a proxymember, the DB2CLIST. The DB2CLIST is a TSO CLIST that contains the required BIND andFREE PLAN statements. When executed during a build process, the CLIST executes theBIND PLAN statement and writes a copy of itself, the DB2OUT CLIST, as output. ThisDB2OUT CLIST is used during promote processes and executes the BIND and FREE PLANstatements.

In our project definition, we set up the DB2CLIST type to hold the DB2CLIST members andthe DB2OUT type to hold the DB2OUT members. We do not discuss creation of the DB2OUTmembers in this book because SCLM creates them automatically.

Application 2 is an Assembler DB2 application and therefore includes SQL BIND statements.The BIND statements are stored with type SDB in the existing ENDEVOR environment.During the migration, these BIND statements must be included in DB2CLIST members.


We used the following naming convention for the DB2CLIST members and for HLarchitecture definitions containing DB2CLIST members:

If the DB2CLIST member is related to a single program represented by a single LECarchitecture definition, the HL architecture definition that ties the LEC architecturedefinition and DB2CLIST together uses “ @ ” as the first character, and the remainingseven characters correspond to the name of the LEC architecture definition.

If the DB2CLIST member is related to more than one program represented by more thanone LEC architecture definition, the HL architecture definition that ties the LECarchitecture definitions and DB2CLIST together uses “ @ ” as the first character and theremaining seven characters correspond to the name of the ENDEVOR member thatcontains the BIND statements. For example, if the member containing the BINDstatements in ENDEVOR is called GNDV0000, the name of the HL architecture definitionmember in SCLM is @GNDV000. In some cases the name following the prefix “ @ ” hasto be truncated to seven characters, which is actually the case in application 2 wheremember names are eight characters long. You must decide which character you candrop in your environment if you use eight-character member names.

The DB2CLIST member has the same name as the HL architecture definition member.

To create DB2CLIST members you can either copy an existing member and change thecontents, or you can use a tool that automatically creates those members.

Even though application 2 had only four Assembler DB2 programs, we wanted to provide anautomated approach for creating DB2CLIST members because there are more DB2applications to be migrated during migration of the remaining applications for the customer.

A tool (that is, a REXX procedure) to create DB2CLISTs and HL architecture definitions wasdeveloped in a previous ITSC project. Its name is G621HLA, and you can find details about itin the ITSC Redbook AD/Cycle: Using SCLM to Manage CSP/AD and CSP/AE Libraries,GG24-3621.

Because this tool did not quite meet our special requirements we modified it, but the base isstill the same. The name of the modified REXX procedure is MIGR0050 and is shown in “HLArchitecture Definitions and DB2CLISTs” on page 129. This program creates DB2CLISTsand HL architecture definitions from user input. Refer to Figure 19 for a sample HLarchitecture definition created by the tool.

INCL GNDV0100 ARCHDEFINCL GNDV0200 ARCHDEFINCL GNDV0300 ARCHDEFINCL GNDV0400 ARCHDEFINCL GNDV0500 ARCHDEFINCLD @GNDV000 DB2CLIST * BIND DB2 plan

Figure 19. HL Architecture Definition Created by the MIGR0050 Program. The five LEC architecturedefinitions were previously created by the MIGR0010 program. A BUILD of thisarchitecture definition provoked a BUILD of each LEC architecture definition and theexecution of the @GNDV000 CLIST.

We recommend that you create DB2CLIST members and related HL architecture definitionsafter you create the LEC architecture definitions and before you create “higher level” HLarchitecture definitions.

After you have created the DB2CLIST and HL architecture definitions, you have to migratethese new members with the SCLM migration utility. We recommend that you use theSUBMIT command for migration.


Chapter 5. Migrating the Bulk DataBecause our target system for the migration was not identical to the source systems of thevendor libraries, the extraction of source data and the migration of that data were reallyseparate steps. The extraction of source data from the vendor library systems is describedin “Extract Data for the Sample Applications” on page 17; additional details are provided inAppendix A, “Data Extraction from CA-LIBRARIAN” on page 73.

This chapter describes the migration of source data on the SCLM target system. Migrationof source data is very simple if the source data:

Conforms to compiler standards

Does not contain library-specific coding.

If you have nonstandard code to migrate, changes to the source code are required, and yoursource code migration will have additional steps.

If you migrate within a single MVS environment, that is, the vendor library and SCLMinstalled on the same system, and you do not need to adjust your source code, you do notneed intermediate data sets. You can extract the source code from the old library systemdirectly into SCLM PDSs.

Figure 20 on page 50 gives an overview of bulk data migration including modifications ofsource code for programs from CA-LIBRARIAN. The following remarks refer to the numbersin the figure:

(1) Programs extracted from CA-LIBRARIAN for all languages.(2) Copy (IEBCOPY) using member lists, provided by the analysis of control information,

for each SCLM type.(3) Insert missing periods using MIGE0030, and (*) handle COPY ... REPLACING as

described later.(4) Change − INC to %INCLUDE using MIGE0010.(5) Delete − INC using MIGE0020.(6) ENDEVOR programs are extracted separately for different languages.(7) Copy modules with the same language. The member lists mentioned in (2) are used.(8) Migrate all modules with the same language in one step.


Figure 20. Overview of Bulk Data Migration Steps


In the sections that follow we describe the basic steps that must be performed for all bulkdata migrations. Then we discuss special steps that may or may not be required dependingon the type of the old library system and the standards used.

Standard Source CodeThe basic steps for migrating standard source code are simple:

Copy members into SCLM PDSs.

Migrate the members.

We recommend that you use the SCLM dialog interface to start the SCLM Migration Utility(SCLM option 3.3; see Figure 21). This allows you to migrate all members in an SCLM PDSwith the same SCLM language in one step. Specify '* ' for MEMBER.

If you leave the AUTHORIZATION CODE field blank, the default authorization code for thegroup will be assigned. MIGRATE MODE = CONDITIONAL will migrate only those membersthat do not have valid SCLM accounting information.

à ð------------------- SCLM MIGRATION UTILITY - ENTRY PANEL ---------------------COMMAND ===> sub (Enter EXECUTE or SUBMIT)

SELECTION CRITERIA:PROJECT ===> SCLM3GROUP ===> MIG1TYPE ===> PLIMEMBER ===> * (Pattern may be used)

MEMBER INFORMATION:AUTHORIZATION CODE ===>CHANGE CODE ===>LANGUAGE ===> PLIOMIGRATE MODE ===> CONDITIONAL (CONDITIONAL, UNCONDITIONAL,

or FORCED)OUTPUT CONTROL:

MESSAGES ===> PRINTER (TERMINAL, PRINTER, DATASET, or NONE)LISTINGS ===> DATASET (TERMINAL, PRINTER, DATASET, or NONE)PRINTER ===> T (Printer output class)VOLUME ===> (If blank, the default volume is used)

JOB STATEMENT INFORMATION:===> //STADE5Z JOB ,'............',===> // MSGCLASS=T,CLASS=A,NOTIFY=STADE5

á ñ

Figure 21. SCLM Migration Utility Panel

If you put members with different languages into one SCLM PDS, you must carefullyconsider the order of the bulk data migration steps. Copy and migrate only members withthe same language into the SCLM PDS, then proceed with the next language.

We used the same SCLM PDS (type COBOL) for all COBOL programs and distinguished themembers by language (refer to Table 2 on page 33). Therefore, we first copied andmigrated all VS COBOL II modules conforming to ANSI 85 standard (option NOCMPR2) intothe PDS and assigned language COB2. Then we copied and migrated the remaining VSCOBOL II modules (option CMPR2) into the same PDS and assigned language COB22.Finally we copied and migrated the OS/VS COBOL modules and assigned language COBOL.

A similar stepwise process was used for Assembler programs, where we assigned thelanguages ASMH and ASMDB2.

Chapter 5. Migrating the Bulk Data 51

You can use language-based member lists for IEBCOPY, or you can use different PDSs forthe members of different languages and copy all members. We used member lists createdduring the analysis of the control information.

Consider all types of source data for the migration, such as source programs, includedmembers, panels, skeletons, CLISTs, and DDL. SQL BIND statements cannot be migrateddirectly; they must be included in DB2CLIST members (refer to “DB2CLIST Considerations”on page 47).

Nonstandard Source CodeSome of the source code in application 1 did not conform to compiler standards and neededadjustment. Changes were required for the proper handling of COBOL COPY statementsand for the removal of CA-LIBRARIAN-specific handling of included members (refer to“Release Process” on page 13).

We separated the source code into different PDSs according to the programming languageused. Only source code of the same programming language was handled at a time with itslanguage-specific procedure.

We performed the following steps during the migration of nonstandard source code:

1. Copied data to separate PDSs according to their SCLM language

2. Brought source code to compiler standards

3. Copied data to the SCLM PDSs

4. Executed the SCLM migration utility

5. Checked the completeness of the migrated data

6. Checked the formal correctness with test BUILDs

7. Made final corrections and rebuilt.

If your source code complies with compiler standards, you may not need to perform steps 2,6, and 7.

COBOL Copy Statements with Leading Data Names

COBOL standard ANSI 68 allows you to replace the 01 level data name coded in a DATADIVISION copy book by prefixing the COPY statement in the main program with a different 01level data name. If the copy book does not contain a 01 level data name, the 01 level dataname preceding the COPY statement followed by a period is inserted. COBOL standardsANSI 74 and ANSI 85 do not support 01 level data name replacement in this way. TheREPLACING clause in the COPY statement is used for that purpose. The 01 level data namein the COPY statement must end in a period and is therefore treated like any other COBOLstatement in the program.

CA-LIBRARIAN treats all COBOL copy books according to the ANSI 68 standard rulesregardless of the COBOL standard used in your program.

Figure 22 on page 53 shows a copy book that does not contain a 01 level data namespecification; the 01 level data name preceding the COPY statement is inserted. Thedifference between ANSI 68 and ANSI 74 or ANSI 85 standard COBOL coding in the examplein Figure 22 on page 53 is the missing period between 01 ABC and COPY ABCCOPY. In“Changing Old COBOL COPY Syntax” on page 139 we describe an automated procedure toinsert missing periods into COBOL main programs.


Code in main program: Resulting expanded code:

01 ABC COPY ABCCOPY. 01 ABC.05 ABC-1 PIC X.05 ABC-2 PIC X......

Copy book ABCCOPY: .....

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ ³³ 05 ABC-1 PIC X. ³³ 05 ABC-2 PIC X. ³³ ..... ³³ ..... ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 22. COBOL Copy Book without 01 Level Data Name

Figure 23 illustrates replacement of the 01 level data name. In such a situation it is notsufficient to insert a missing period. You will end up with two 01 level data namespecifications after the copy book is resolved by the compiler. Two solutions are possible:

Remove the line with the 01 level data name specification in the copy book

Remove the 01 level data name specification preceding the COPY statement and changethe 01 level data name in the copy book.

Other programs that use the copy book may be affected by the changes.

We recommend that you remove the 01 level data name specification from the copy book. Inprograms that previously included this copy book without a 01 level data name specificationyou must insert the 01 level data name preceding the COPY statement.


01 AAA COPY XYZCOPY. 01 AAA.05 XYZ-1 PIC X.05 XYZ-2 PIC X......

Copy book XYZCOPY: .....

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ ³³ 01 XYZ. ³³ 05 XYZ-1 PIC X. ³³ 05 XYZ-2 PIC X. ³³ ..... ³³ ..... ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 23. COBOL Copy Book with 01 Level Data Name

How can you find where changes are required? We consider the COBOL compiler the besttool to identify errors. We inserted only the missing periods automatically before migratingthe programs and copy books.

The VS COBOL II compiler gives an IGYDS1159-E error message if two 01 level data namesprecede a data structure. If the 01 level data name inside and outside the copy book are


identical, you may receive IGYPS0037-S error messages in addition (see Figure 24 onpage 54).

IGYDS1159-E A "PICTURE" clause was not found for elementary item "AAA". "PICTUREX(1)" was assumed.

IGYPS0037-S "AAA" was not a uniquely defined name. The definition to be used couldnot be determined from the context. The reference to the name wasdiscarded.

Figure 24. COBOL Error Messages for Duplicate 01 Level Data Names

We made the remaining corrections manually. Only a few old programs were affected, asthe customer normally used copy books without a 01 level data name specification.

When you change copy books you may want to use the cross reference listing from SCLMarchitecture reports (see “Completeness and Correctness Checks” on page 58) to identifyall affected programs.

COBOL Copy Statements with Prefix Replacement

The REPLACING clause in a COBOL COPY statement enables you to change data names,COBOL words, and text strings in a copy book whenever the copy book is expanded in theprogram.

The COBOL compiler and CA-LIBRARIAN handle COPY statements with the REPLACINGclause differently:

COBOL uses an exact match of a word if explicit delimiters are not used.

Therefore, COBOL performs the replacement only when the string to be replaced, ascoded in the COPY statement, is found in the copy book delimited by blanks.

CA-LIBRARIAN uses a fuzzy match if the string to be replaced ends with a hyphen andis found as a prefix string in the copy book.

This function does not correspond to any COBOL standard, even if the coding itselfconforms to the COBOL language rules. The COBOL compiler will not replace anythingduring copy book expansion.

COBOL standard ANSI 85 supports partial replacement of data names if properdelimiters are used. CA-LIBRARIAN does not support this.

A full description of COBOL COPY syntax can be found in VS COBOL II ApplicationProgramming: Language Reference, SC26-4047.

Let us look at the examples shown in Figure 25 on page 55 through Figure 28 on page 56.Figure 25 on page 55 shows the simple case of replacing a matching data name.CA-LIBRARIAN and COBOL compiler give the same results. Replacement of matching datanames was not used in application 1.



01 ABCDEF. 01 ABCDEF.COPY ABCCOPY REPLACING ABC BY XYZ. 05 XYZ PIC X.

05 ABC-2 PIC X...........

Copy book ABCCOPY:

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ ³³ 05 ABC PIC X. ³³ 05 ABC-2 PIC X. ³³ ..... ³³ ..... ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 25. COPY REPLACING: Example 1. A matching data name is replaced.

Figure 26 through Figure 28 on page 56 illustrate the different behaviors of partialreplacement of a data name.


01 ABCDEF. 01 ABCDEF.COPY ABCCOPY REPLACING ABC- BY XYZ-. 05 ABC-1 PIC X.

05 ABC-2 PIC X...........

Copy book ABCCOPY:


Figure 26. COPY REPLACING: Example 2a (COBOL Standard). No replacement takes place becausethe string in the REPLACING clause does not match a data name in the copy book.



01 ABCDEF. 01 ABCDEF.COPY ABCCOPY REPLACING ABC- BY XYZ-. 05 XYZ-1 PIC X.

05 XYZ-2 PIC X...........

Copy book ABCCOPY:


Figure 27. COPY REPLACING: Example 2b (CA-LIBRARIAN Standard). The data name prefixes arereplaced.


01 ABCDEF. 01 ABCDEF.COPY ABCCOPY 05 XYZ-1 PIC X.

REPLACING ==:ABC:== BY ==XYZ==. 05 XYZ-2 PIC X...........

Copy book ABCCOPY:

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ ³³ 05 :ABC:-1 PIC X. ³³ 05 :ABC:-2 PIC X. ³³ ..... ³³ ..... ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 28. COPY REPLACING: Example 2c (COBOL ANSI 85 Standard). The text between thedelimiters is replaced.

Application 1 contained COPY statements with REPLACING clauses as shown in Figure 27.If a copy book is used more than once, you cannot simply change the data names in thecopy book and remove the REPLACING clause. You must consider other COPY statementsreferencing the copy book.

A similar problem arises if you use the ANSI 85 standard as shown in Figure 28. Not onlydo the colon delimiters have to be inserted into the copy books, but also all the COPYstatements in all programs using the copy book must be changed. Furthermore, forprograms that include such a copy book without a REPLACING clause, a dummy REPLACINGclause must be added to eliminate the colons in the copy book from the expanded text. Twosolutions remain:

1. Remove the REPLACING clause from the COPY statement, change all references to theaffected data names within the program to the original names in the copy book, and usethe high-level data name as qualifier in all these references.


The qualification with the high-level data name is required if a copy book is usedmultiple times within one program with different prefixes assigned by differentREPLACING clauses.

2. Change the REPLACING clause in the COPY statement from prefix replacement toreplacement of matching names. For the example, in Figure 27 on page 56, replacingthe CA-LIBRARIAN syntax

COPY ABCCOPY REPLACING ABC- BY XYZ-.

with COBOL syntax would give you

COPY ABCCOPY REPLACING ABC-1 BY XYZ-1ABC-2 BY XYZ-2.

For large copy books this might result in extended COPY statements.

We decided to use the first solution. We believe that using REPLACING clauses makes thesource code harder to understand, because data names in the DATA DIVISION copy booksand data names in the PROCEDURE DIVISION do not match. In “Handling COPY PrefixReplacement in COBOL Programs” on page 141 we describe the tools we used to helpautomate the required changes.

− INC CA-LIBRARIAN Statements

The CA-LIBRARIAN − INC statement is a directive statement for CA-LIBRARIAN to includethe text of the CA-LIBRARIAN member specified in the − INC statement, for example:

−INC GETPARM

CA-LIBRARIAN replaces this statement with the contents of CA-LIBRARIAN memberGETPARM. The − INC always starts in column 1. Application 1 Assembler and PL/Iprograms used − INC statements.

− INC in Assembler Programs: The text for user-written Assembler macros was included inprogram source code using − INC statements for the following two reasons:

To retrieve the macro code from CA-LIBRARIAN data sets to make it available to theAssembler compiler

To include the user macros in the source code for archiving.

This is no longer required in an SCLM environment. The Assembler compiler finds thesemacros automatically in the PDSs allocated through FLMALLOC macros in the SCLMlanguage definitions. The SCLM parser detects the names of the macros, and new orchanged macros are promoted together with the program.

We changed the − INC statements in application 1 Assembler programs into commentstatements. The automated procedure for these changes is described in “ChangingCA-LIBRARIAN − INC Statements” on page 156.

− INC in PL/I Programs: CA-LIBRARIAN − INC statements were used instead of PL/I%INCLUDE statements.

We changed the − INC statements in application 1 PL/I programs to PL/I %INCLUDEstatements. The automated procedure for these changes is described in “ChangingCA-LIBRARIAN − INC Statements” on page 156.


Completeness and Correctness ChecksAfter migrating your application you may want to verify that all required members areproperly migrated and available in the SCLM environment. We used the SCLM architecturereport utility (SCLM option 3.5) to perform a completeness check.

Furthermore, you may want to know whether all modules can be built successfully underSCLM control even before you create all high-level (HL) architecture definitions required todefine the high-level structure of your application. If you changed source code during thebulk data migration, this step may be of special interest.

Some changes discussed in “COBOL Copy Statements with Leading Data Names” onpage 52 may require additional manual intervention. BUILD error listings for modules thatrequire additional changes and cross-reference information in SCLM architecture reports willhelp you to complete the task.

SCLM Architecture Reports for Completeness Checks

We created temporary architecture definitions—one for each SCLM language—that containINCL statements for all LEC architecture definitions for programs with the same SCLMlanguage. Member lists for each language were already used during bulk data migration. Ifyou edit these member lists you can easily reformat them using editor change commands tocreate temporary architecture definitions. Remember, our naming convention called for thesame names for programs and LEC architecture definitions.

You can create SCLM architecture reports for the temporary architecture definitions. UseSCLM option 3.5 and select REPORT CUTOFF = NONE. If not all included members arefound, the missing members will be marked with an E* in the report, as shown in Figure 29on page 59. Possible reasons for missing members are:

Members were not extracted from the old library system.

Members were copied to the wrong PDS type, for instance, COBOL copy books copiedto the ASMMACS PDS because of nonconformance to naming conventions.

You must copy the missing members to the SCLM PDS of the appropriate type and migratethem with the correct SCLM language. Use the SCLM library utility (SCLM option 3.1) todelete members already migrated with either the wrong language or the wrong type.


************************************************************************************************************************************************************** **** SOFTWARE CONFIGURATION AND LIBRARY MANAGER (SCLM) **** **** ARCHITECTURE REPORT **...** PROJECT: SCLM3 **** GROUP: MIG1 **** TYPE: ARCHDEF **** MEMBER: #COB2 **** CUTOFF: NONE **...==============================================================================* ** ARCHITECTURE REPORT ** ** H = HIGH LEVEL C = COMPILATION CONTROL T = TOP SOURCE E = ERROR ** L = LINKEDIT CONTROL G = GENERIC I = INCLUDED D = DEFAULT ** *==============================================================================

CODE: H MEMBER: #COB2

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+---

H #COB2...

L P92N203D P92N203T P92N203I S92C001CI S92C002CI S92U299CE* S92U250C <--- E* indicates missing memberI S92U251CI S92U253C...

Figure 29. Partial SCLM Architecture Report for Member #COB2

Check Correctness Using SCLM BUILDs

If changes to the source code are required, it may be that not all necessary changes weremade or that some inconsistencies still exist. “COBOL Copy Statements with Leading DataNames” on page 52 shows a typical example where duplicate data names are to beremoved.

It is very useful to get a list of all the remaining problems. If you perform a conditionalSCLM BUILD using an HL architecture definition for the whole application, BUILD stops afterencountering the first error. You might have to step from one error to the next withoutknowing how much work is still to be done.

We did the basic correctness checks with BUILDs on a module-by-module basis. Wedeveloped a REXX procedure (MIGR0020) that uses the SCLM command interface. ThisREXX procedure calls the BUILD command for each LEC architecture definition in the inputstream and creates separate error listings for those (and only for those) modules that are


not built successfully. MIGR0020 is listed in “Using SCLM Command Interface for MassBUILDs” on page 158.

The advantage of using the SCLM command interface is that you can work with simplemember lists to create the input stream. The SCLM dialog interface (SCLM option 4 forBUILD) would require you to type in each member name.

If the modules are built successfully in this step, a later BUILD for an HL architecturedefinition will not redo all the compilations but only create new SCLM BUILD maps.

If errors occur, you have to repeat the correctness check after correcting the code. Possiblechanges required are discussed in “COBOL Copy Statements with Leading Data Names” onpage 52.

Perform all editing using SCLM EDIT now to keep the accounting information for themembers updated.


Chapter 6. Creating High-Level Application StructureUnlike other library systems, SCLM allows you to structure your application in a multilevelhierarchy. This structuring is achieved by creating related HL architecture definitions thatreflect the structure of your application. You can think of this system of related architecturedefinitions as the blueprint of your application. The HL architecture definitions reference theCC, LEC, and HL architecture definitions for DB2CLISTs created at the lowest level.

To create the HL architecture definitions and link them to the low-level architecturedefinitions is not an easy task, but one of the major advantages of SCLM is that the structureof your application can be explicitly described using architecture definitions. Nevertheless,there is no real technical need to structure your application. If you build and promote yourprograms based on their LEC architecture definitions, you may not need any HL architecturedefinitions at all. However, such an approach would not take advantage of SCLM'sextensive software configuration functions. Even a single HL architecture definition thatincludes all lowest-level architecture definitions gives you advantages. You can build andpromote the whole application by specifying that HL architecture definition on the SCLMBUILD and PROMOTE panels.

Real structuring requires a multilevel hierarchy. You make a trade-off between theinvestments during the migration phase and the benefits you will gain for your applicationunder SCLM control. Well-structured applications are easier to maintain and will pay backyour investment in a short time.

At this point of the migration some structuring already has been done:

Information about included members (COBOL copy books, Assembler macros, PL/Iincludes, embedded skeletons) is stored by SCLM parsers in the SCLM accounting dataset

Statically linked programs are included in the LEC architecture definitions duringmigration of control information (refer to “Creating LEC and CC Architecture Definitions”on page 44).

When creating the HL architecture definitions required to describe the structure of yourapplication, you might ask the following questions:

Where can I find information about the application structure?

How do I create the HL architecture definitions from the information available?

Sources of InformationPossible sources of information for application structuring are:

Application structure information in your old library system

Structure information from dictionary reports


Information from application documentation

Scan of existing source modules.

Application Structure Information in Your Old Library System

The information you can find in the old library system depends on whether the system is asimple library management system or a sophisticated library management and softwareconfiguration system. A library system that provides software configuration functions, suchas ENDEVOR, provides more input for this part of the migration process. CA-LIBRARIAN is alibrary management system only and does not provide application structure information.

The library management functions of both systems keep attribute information for membersor objects. The software configuration functions in ENDEVOR keep attribute information forapplications. To understand how to build the high-level structure of an application duringmigration, we have to explain the meaning of attribute information for applications.

Attribute information is about all kinds of relationships between application objects andbetween applications in an application domain. Relationships between objects within oneapplication are between:

An object with itself. This situation occurs when multiple versions of an object exist.SCLM manages relationships between a source object and itself through its versioningfacility.

A source program with an included member; for example, a PL/I source program with a%INCLUDE statement to reference a PL/I include structure. SCLM keeps track of suchrelationships with its parsers.

A source program with a derived object (object module or load module). When a sourceprogram is compiled and link edited to produce a load module, the configurationmanagement system keeps information about the relationship between the two objects.SCLM handles this relationship with CC and LEC architecture definitions and throughthe language that is tightly linked to the source program.

A source program with another source program that is not included. Two sourceprograms can produce one load module. Two source programs can be groupedtogether with an LEC architecture definition.

A derived object with another derived object; for example, a load module with a staticcall to another load module. You can use the LINK parameter in an LEC architecturedefinition to specify such a relationship.

An object with an application. Each application consists of multiple objects. SCLMhandles this kind of relationship with HL architecture definitions.

Relationships between application are:

One object of an application can have relationships with objects of another application.To manage such a situation, a software configuration manager must know therelationships between objects and applications.

One application can have a relationship with itself if other configurations or versions ofthe same application exist. Relationships between different applications are handledwith notions, such as application groups and activity domains of the enterprise(business domain).

We can relate applications to domains or subdomains of the enterprise and build a structurefrom the object to the enterprise level. HL architecture definitions provide the possibility tobuild application structures that take into account domains and subdomains of theenterprise.


Structure Information from Dictionary Reports

Dictionary reports are a very useful information source for the application structure. Thecompleteness of the information useful for defining the application structure in SCLM willdepend on the amount of information and links in the dictionary.

The program-subprogram structure is a typical dictionary report output. Well-maintaineddictionaries also provide higher-level structure information. It is important to understandwhich information, required to build your architecture definitions, is not available in thedictionary.

Because dictionary reports have well-known formats, simple tools can be written totransform the report information into SCLM architecture definitions. We had no dictionaryinformation available for our project and therefore we do not provide tools to extractinformation from dictionary reports. The general concept for such a tool is similar to ourtool for creating LEC and CC architecture definitions (see “LEC and CC ArchitectureDefinitions” on page 123), even if input and output formats differ.

Information from Application Documentation

Information from application documentation can be useful for the construction of yourarchitecture definition and complement data from other sources.

In most cases such documentation cannot be used as machine-readable input to anautomated tool. You can use the information as input to a tool like MIGR0050 (see “HLArchitecture Definitions and DB2CLISTs” on page 129) to create the architecture definitionswith a minimal typing effort.

Scan of Source Modules

Scanning of source modules typically gives you the relationship between calling and calledmodules. A typical relationship would be a program to subprogram relationship. In aTSO/ISPF application, such as application 1 in our migration project, CLIST to ISPF skeleton(using ISPF FTINCL service) or ISPF panel to program (using ISPF SELECT service) areexamples of such relationships.

Creating the Architecture DefinitionsBefore you start creating any HL architecture definitions, you should establish a namingconvention. We used the following naming convention for the lowest-level architecturedefinition members:

Program name for LEC membersProgram name prefixed with C for CC membersDB2CLIST name for HL members referring to DB2CLISTs.

Refer to “Creating LEC and CC Architecture Definitions” on page 44 and “DB2CLISTConsiderations” on page 47. We decided to have all HL architecture definition membernames start with # for application 1 and with @ for application 2.

Create HL Architecture Definitions Using CA-LIBRARIAN Information: CA-LIBRARIAN doesnot provide information that helps structure the application into HL architecture definitions.You can use the guidelines given in the SCLM Guide and Reference, SC34-4254. If you havebatch and online parts, you may want to split the application according to those criteria first.

Chapter 6. Creating High-Level Application Structure 63

Sublevels correspond to subapplications, and, in a transaction-oriented application, allmodules belonging to one transaction are grouped at the level directly above the LECarchitecture definitions.

Application 1, which is a TSO/ISPF application, is started from a CLIST. The differentfunctions and subfunctions are selected from ISPF selection panels. The control flow of theapplication depends on the user input data.

We scanned the modules to find all relationships between calling and called modules. Weused the ISPF Search-For utility (ISPF option 3.14) to scan application 1. For example, asearch for the word CALL in your COBOL source PDS provides you with a list containing allcalls to subprograms. Depending on the module types you are analyzing it may be useful toconsider naming conventions and coding style in your application.

You can reduce the output of the scan to the required information using simple EDITcommands (like excluding and deleting lines) or EDIT macros containing such commands.

We used this information to create HL architecture definitions. We generated the names forthe HL architecture definition members for TSO and ISPF modules by replacing the commonthree-character prefix for the application by #, and for programs by prefixing the programname with #.

Four sample members are shown in Figure 30 on page 65 through Figure 33 on page 65.The first record always refers to the calling module. For modules that are not translated, theINCLD keyword specifying the source module name and type is coded. For programs, theINCL keyword specifying the LEC architecture definition is coded.

In a first approach all “called” modules were referenced by INCLuding the HL architecturedefinition. Our analysis of the calling modules did not consider nesting of calls tosubroutines. Therefore, we did not know whether the dependent modules would again havedependents. Some of the called modules might already be on the bottom of the hierarchy,for instance, subprograms that are called and return directly to the caller, or output panels.

The best way of finding these lowest-level modules is to run an SCLM architecture report forthe HL architecture definition. Be sure to migrate all architecture definitions before you startthe reporting. The lowest-level members will be marked with an error flag in the report(compare Figure 29 on page 59), because we created HL architecture definitions only formodules that have dependents.

You could create architecture definitions for the lowest-level modules with only one linereferring to the source, but those architecture definitions provide no additional benefit. Wedecided to replace the reference to the nonexisting HL architecture definition members witha reference to the modules directly (INCL LEC member for programs, INCLD source formodules not to be translated).

If you rerun the SCLM architecture report now, it should end with no errors, provided youpreviously migrated all the source modules.


INCLD FUAP1010 PANELSINCL #P1100 ARCHDEFINCL #P1300 ARCHDEFINCL #P1600 ARCHDEFINCL #P1690 ARCHDEFINCL #P1800 ARCHDEFINCL #P3010 ARCHDEFINCL #C1050 ARCHDEFINCL #C9000 ARCHDEFINCL #C9100 ARCHDEFINCL #P9900 ARCHDEF

Figure 30. HL Architecture Definition #P1010. #P1010 is the HL architecture definition for ISPFselection panel FUAP1010. #P1100 is the HL architecture definition for panel FUAP1100,which represents one of the selections on panel FUAP1010.

INCLD FUAP1100 PANELSINCL #C1100 ARCHDEF

Figure 31. HL Architecture Definition #P1100. #P1100 is the HL architecture definition for ISPFselection panel FUAP1100. The only possible selection on this panel selects CLISTFUAC1100 represented by the HL architecture definition member #C1100.

INCLD FUAC1100 CLISTINCL #C1140 ARCHDEFINCLD FUAC1110 CLISTINCL #C1200 ARCHDEFINCL #C1290 ARCHDEFINCLD FUAP1150 PANELSINCLD FUAP1170 PANELSINCLD FUAP1190 PANELSINCL #P92N200 ARCHDEFINCL #P92N201 ARCHDEF

Figure 32. HL Architecture Definition #C1100. #C1100 is the HL architecture definition for CLISTFUAC1100. This HL architecture definition contains references to source modules (panels)and to other HL architecture definition members, such as #P92N200.

INCL P92N200 ARCHDEFINCLD FUAP0100 PANELSINCLD FUAP1110 PANELSINCLD FUAP1120 PANELSINCLD FUAP1620 PANELS* CALLED SUBROUTINES:INCL P92N250 ARCHDEFINCL P92N251 ARCHDEF

Figure 33 (Part 1 of 2). HL Architecture Definition #P92N200


INCL P92N253 ARCHDEFINCL P92N254 ARCHDEFINCL #P92N258 ARCHDEFINCL P92N259 ARCHDEFINCL #P92N262 ARCHDEFINCL #P92N290 ARCHDEFINCL #P92N291 ARCHDEFINCL P92N299 ARCHDEF

Figure 33 (Part 2 of 2). HL Architecture Definition #P92N200. #P92N200 is the HL architecturedefinition for program P92N200. This HL architecture definition containsreferences to LEC architecture definition members for called subroutines atthe lowest level, to ISPF panels, and to other HL architecture definitionmembers, such as #P92N258 for subroutines that call other subroutines.

Figure 34 shows a partial SCLM architecture report for application 1. The report refers tothe architecture definition members shown in Figure 30 on page 65 through Figure 33 onpage 65.

...H #P1010 *D FUAP1010 | H = HIGH LEVELT FUAP1010 | L = LINKEDIT CONTROLH #P1100 | C = COMPILATION CONTROLD FUAP1100 | G = GENERICT FUAP1100 | T = TOP SOURCEH #C1100 | I = INCLUDEDD FUAC1100 | E = ERRORT FUAC1100 | D = DEFAULTH #C1140 *......

H #P92N200L P92N200D P92N200T P92N200I S92C001CI S92U299CI S92U250CI S92U251CI S92U253CI S92U254CI S92U258CI S92U259CI S92U262CI S92U290CI S92U291CI S92D290CD FUAP0100T FUAP0100D FUAP1110

Figure 34 (Part 1 of 2). Partial SCLM Architecture Report for Application 1


T FUAP1110D FUAP1120T FUAP1120D FUAP1620T FUAP1620L P92N250D P92N250T P92N250I S92U011CI S92U010CI S92D250CI S92U003CI S92U004CI S92U005CI S92U299C...

Figure 34 (Part 2 of 2). Partial SCLM Architecture Report for Application 1. The partial report forapplication 1 refers to the architecture definition members in Figure 30 onpage 65 through Figure 33 on page 65. No CUTOFF is used and all includedmembers are listed.

Create HL Architecture Definitions Using ENDEVOR Information: ENDEVOR supports thenotion of system and subsystem in its logical structure. Both system and subsystemdescribe logical groupings of ENDEVOR inventory elements and provide input to the creationof HL architecture definitions that reflect the application structure.

We used the system name (X) from ENDEVOR for the highest-level architecture definitionand the subsystem name (L), which is a subclassification of system, for theintermediate-level architecture definition for application 2. ENDEVOR provides no otherinformation that can be used to create HL architecture definitions. We could not findintermediate “ logical” levels between subsystem (HL architecture definition) and elementname (LEC architecture definition). The only levels we could find are “technological” ones,such as grouping by types or languages. That point is important because it means that in amigration from ENDEVOR to SCLM you must create such intermediate-level architecturedefinitions manually without any help from the old library system. We only used the @X and@L HL architecture definitions in Figure 35 and Figure 36 for application 2.

For so little information we did not develop a tool to extract the system and subsystem namefrom ENDEVOR. However, we created the HL architecture definitions using the MIGR0050tool (see “HL Architecture Definitions and DB2CLISTs” on page 129).

* HL SYSTEM ARCHDEFINCL @L ARCHDEF * SUB-SYSTEM

Figure 35. HL Architecture Definition @X. This architecture definition only makes sense in a realenvironment if many subsystems are related to one system.

* HL SUB-SYSTEM ARCHDEFINCL GNDV0050 ARCHDEF * LEC ARCHDEFINCL @GNDV000 ARCHDEF * HL ARCHDEF FOR DB2 PGM AND BIND

Figure 36. HL Architecture Definition @L

Figure 37 on page 68 shows a partial SCLM architecture report for application 2 with all HLarchitecture definitions, LEC architecture definitions, source code, and included members.


==============================================================================* ** ARCHITECTURE REPORT ** ** H = HIGH LEVEL C = COMPILATION CONTROL T = TOP SOURCE E = ERROR ** L = LINKEDIT CONTROL G = GENERIC I = INCLUDED D = DEFAULT ** *==============================================================================

H @XH @LL GNDV0050D GNDV0050T GNDV0050I DEFREGI SQLUDSCTI NDVSQL01H @GNDV000L GNDV0100D GNDV0100T GNDV0100I SQLUDSCTI DEFREGI NDVTBHISI NDVSQL01L GNDV0200D GNDV0200T GNDV0200I SQLUDSCTI DEFREGI NDVTBDISI NDVSQL01L GNDV0300D GNDV0300T GNDV0300I SQLUDSCTI DEFREGI NDVTBPRMI NDVSQL01L GNDV0400D GNDV0400T GNDV0400I SQLUDSCTI DEFREGI NDVTBDESI NDVSQL01L GNDV0500D GNDV0500T GNDV0500I SQLUDSCTI DEFREGI NDVTBSTSI NDVSQL01

Figure 37. Partial SCLM Architecture Report for Application 2


BUILD and PROMOTE Using the Architecture DefinitionsWe performed BUILDs for all programs during bulk data migration (see “Completeness andCorrectness Checks” on page 58). Therefore, SCLM does not initiate recompiles for theprograms when you build the newly created HL architecture definitions. Our HL architecturedefinitions all built successfully.

Promotion to the TEST layer checks the consistency of your migration process. For example,we had to check the DB2 BIND/FREE process for application 2. During this first PROMOTE,SCLM must invoke the DB2 FREE process for the “ f rom ” group (MIG2) and the DB2 BIND forthe “ to ” group (TEST).

If the promotion is successful but some modules remain in the PDSs of the developmentgroup, you may have one of the following situations:

The HL architecture definition structure is incomplete.

Some source modules are not used in your application.

In the first case you have to complete your structure. Carefully evaluate whether there aresystematic errors in your method to create the HL architecture definition structure. If thereare systematic errors, you should improve your method. This is particularly important if youwork in a pilot project and want to migrate other applications using the methods developedin the pilot project.

If you find modules that are not used, use the SCLM Library utility (SCLM option 3.1) todelete these modules and their accounting information from your SCLM project. Unusedmodules may be old “safety copies” or parts of an application no longer used.

It is important to use more than two layers in the SCLM project for the migration (refer to“Groups” on page 24). This allows you to promote to a test layer and test the applicationbefore you finally promote to the production layer.


Chapter 7. Post-Migration StepsThis chapter explains some of the considerations you need to address after you havemigrated an application. The following topics are covered:

Promote migrated application to productionHandle nonmigrated information.

Promote Migrated Application to ProductionAfter thorough testing, you are ready to promote the migrated application to production. Weinvoked the SCLM PROMOTE function to move all application objects from group TEST togroup PROD using the highest-level architecture definition.

We strongly recommend that you keep the old production libraries for a transition period.You may want to concatenate the old libraries to the new libraries during the transitionperiod. You will avoid unpleasant surprises in production if, despite all the testing, anapplication module should be missing in the new libraries.

After you have migrated all of your applications you can delete all product data sets for theold library system.

Handle Nonmigrated InformationControl information can be divided into two groups:

Object control information, such as creation date or change userid

Application control information, such as version or relationship to other applications.

We migrated some object control information and most of the application control informationfor the sample applications in our project. We did not migrate as much control informationas possible because we did not want to clone the existing environment under SCLM.Therefore, we migrated only the control information that was useful to set up our SCLMenvironment.

For object control information: We used (migrated) the existing type information, whichbecame the input to create the SCLM types.

For application control information: We migrated the relationships between objects, whichwere used as input to create SCLM architecture definitions. This information is as importantas the object data because it describes how the objects fit together. For example, acompiler option is part of the relationship between source code and object module.

Consider that the more control information you want to migrate, the higher the cost of themigration will be. For instance, we decided not to migrate versions of data objects (version


is a relationship between one object and itself) because it was considered too difficult andtoo expensive to migrate that information, which is conceptually identical in the old and newenvironment but very different in the technical implementation. However, nonmigratedsource code belonging to old versions must be taken into account.

You can classify control information according to how difficult it is to migrate. This isparticularly useful if you want to clone your existing environment.

List 1 contains control information that is difficult or impossible to migrate either fortechnical reasons or because the information is not provided in the existing environment.List 2 contains control information that is easier to migrate.

List 1: difficult to migrate

Accounting status (editable, ...)Create date/timePredecessor date/timeTranslator versionChange date/timeAccess key.

You cannot migrate time stamps because they are internally managed by SCLM. Forexample, create date/time is set when the member is first identified to SCLM, and there isno way to change it easily during the SCLM migration. Another example is access key,which has no real meaning in the old environments.

List 2: possible to migrate

Promote useridChange useridChange groupChange code.

It is possible to migrate information from list 2. Change code is an input parameter for theSCLM migration that can be derived from the ENDEVOR CCID. CA-LIBRARIAN does notsupport change codes. If you do not change userids during the migration, you can keep thechange userids the same as they were in the old environment.

To keep a record of all nonmigrated control information, we recommend that you runreports, such as the CA-LIBRARIAN index listing or ENDEVOR standard reports and SCLPRINT for all elements, for the current and latest versions of all programs.

Even though we decided not to migrate information about versions of data objects, this mightnot be an acceptable option in a real-life environment and you must be careful not to losethis information. The way to handle version data depends on the existing situation.

If you have, for example for a legal reason, an archiving file outside the old library system,you can keep working with this file under SCLM. In this case, you may have to develop apromote exit during the migration. If such a file does not exist but versioning is used in theold environment, you can load the old versions into a file kept outside SCLM.


Appendix A. Data Extraction from CA-LIBRARIANThis appendix shows the jobs used to extract data for application 1 from the CA-LIBRARIANdata sets in the customer environment.

Copy Selected Members between CA-LIBRARIANsWe used the CA-LIBRARIAN utility to copy members unchanged from one CA-LIBRARIAN toanother CA-LIBRARIAN. We extracted Assembler macros, COBOL copy books, and PL/Iinclude members from the development CA-LIBRARIAN (file C in Figure 4 on page 20) andfull-text programs from the production CA-LIBRARIAN (file PP in Figure 4 on page 20).Figure 38 shows the JCL for the job. AFLBPROG is the name of the CA-LIBRARIAN programin the customer installation.

//........ JOB .............,// .............//*=====================================================================//* UNLOAD COPY BOOKS FROM LIBRA.MASTER TO TEMP. DATA SET//*--------------------------------------------------------------------*//COPY EXEC PGM=AFLBPROG,PARM='NRJS,NJTA'//MASTER DD DISP=SHR,DSN=LIBRA.MASTER//OSJOB DD DISP=(,PASS),DSN=&&OSJOB3,SPACE=(CYL,(20,20),RLSE),// UNIT=SYSDA,DCB=(RV.PATTERN,LRECL=80,BLKSIZE=6080,RECFM=FB)//SYSPRINT DD SYSOUT=Y,DCB=RECFM=FBA//SYSIN DD *-OPT UTILITY-COPY S92B000C-COPY S92B250C..

-COPY S92D000C-COPY S92D220C-END//*=====================================================================//* ADD MEMBERS FROM TEMP. DATA SET TO LIBRA.MIGCOPY//*--------------------------------------------------------------------*//ADD EXEC PGM=AFLBPROG,PARM='NRJS,NJTA',COND=(0,NE)//MASTER DD DISP=SHR,DSN=LIBRA.MIGCOPY//OSJOB DD DUMMY,DCB=(RV.PATTERN,LRECL=80,BLKSIZE=6080,RECFM=FB)//SYSPRINT DD SYSOUT=Y,DCB=RECFM=FBA//SYSIN DD DISP=(OLD,PASS),DSN=&&OSJOB3//*=====================================================================

Figure 38. Job to Copy Members from CA-LIBRARIAN to CA-LIBRARIAN. This is the job to copy theAssembler macros and COBOL copy books. Specified members are unloaded from oneCA-LIBRARIAN to an intermediate file and then added to another CA-LIBRARIAN.


Extract Programs and Remove Included MembersWe used a customer program that uses the CA-LIBRARIAN utility to copy programs from oneCA-LIBRARIAN to another while removing included members and establishing the originalCOPY or CA-LIBRARIAN − INC statements (file P in Figure 4 on page 20). Figure 39 showsthe JCL for the job.

//........ JOB .............,// .............//*=====================================================================//* COPY MODULES FROM LIBRARIAN TO LIBRARIAN//* WITH REMOVING INCLUDED COPY BOOKS AND//* ESTABLISHING ORIGINAL COPY STATEMENTS//*--------------------------------------------------------------------*//LCOPY EXEC PGM=P92N049,PARM='RSFITZ *'//* R =REDUCE BOOKS TO COPY STMTS//* SFITZ =USERID//* *=FILLER//LIBFROM DD DSN=LIBRA.PROD,DISP=SHR//LIBTO DD DSN=LIBRA.MIGPGMS,DISP=SHR//LUCIJCL DD UNIT=SYSDA,SPACE=(TRK,(1,1)),// DCB=(LRECL=80,BLKSIZE=6080,RECFM=FB,DSORG=PS)//LUCIOPT DD UNIT=SYSDA,SPACE=(TRK,(10,6)),// DCB=(LRECL=80,BLKSIZE=6080,RECFM=FB,DSORG=PS)//LUCIIPT DD UNIT=SYSDA,SPACE=(TRK,(10,6)),// DCB=(LRECL=80,BLKSIZE=6080,RECFM=FB,DSORG=PS)//LUCIINDX DD DUMMY//LUCILIST DD DUMMY//LUCIMSGS DD SYSOUT=*//SYSOUT DD SYSOUT=*//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//DDSE01 DD ***-------------------------------------------------------------------**** COL. 1 - 2: BLANK (** IF COMMENT RECORD) **** COL. 3 - 10: NAME IN SOURCE LIBRARIAN **** COL. 11 - 18: NAME IN TARGET LIBRARIAN (BLANK=SAME LIKE IN SOURCE)****V-------V----------------------------------------------------------**

P92N000P92N001..P92N399

/*//*=====================================================================

Figure 39. Job to Extract Programs from One CA-LIBRARIAN to Another CA-LIBRARIAN. TheDDSE01 DD file contains the list of members selected.


Unload from CA-LIBRARIAN to Partitioned Data SetFigure 40 shows a sample job that unloads a complete CA-LIBRARIAN to a PDS. Becausethe extraction from the original CA-LIBRARIAN was done previously (see “Copy SelectedMembers between CA-LIBRARIANs” on page 73), our temporary CA-LIBRARIAN containedonly members of the sample application and no member list was needed as input to this job.

//........ JOB .............,// .............//*=====================================================================//* UNLOAD MODULES FROM LIBRARIAN TO PARTITIONED DATA SET//*====================================================================*//* 1. GENERATE LIBRARIAN -SEL STATEMENTS WITH LIBRARIAN GPO *//* INTO TEMP. DATA SET (DDNAME=OSJOB) *//*--------------------------------------------------------------------*//SELGPO EXEC PGM=AFLBPROG,PARM='NRJS,NJTA'//MASTER DD DISP=SHR,DSN=LIBRA.MIGCOPY//OSJOB DD DISP=(,PASS),DSN=&&OSJOB1,// UNIT=SYSDA,SPACE=(TRK,(25,10),RLSE),// DCB=(RV.PATTERN,LRECL=80,BLKSIZE=6080,RECFM=FB)//SYSPRINT DD SYSOUT=Y,DCB=RECFM=FBA//SYSIN DD *-OPT GPO-OPT TEMPS-SEL NAME=,EXEC-END//*//*--------------------------------------------------------------------*//* 2. UNLOAD ALL MEMBERS SPECIFIED IN SYSIN FILE *//* FROM LIBRARIAN TO PDS (DDNAME=OSJOB) *//*--------------------------------------------------------------------*//UNLOAD EXEC PGM=AFLBPROG,PARM='NRJS,NJTA'//MASTER DD DISP=SHR,DSN=LIBRA.MIGCOPY//OSJOB DD DISP=OLD,DSN=SFITZ.LIBRA.MIGCOPY//SYSPRINT DD SYSOUT=Y,DCB=RECFM=FBA//SYSIN DD DISP=(OLD,PASS),DSN=&&OSJOB1//*====================================================================*

Figure 40. Job to Unload All Members from CA-LIBRARIAN to PDS

Appendix A. Data Extraction from CA-LIBRARIAN 75

Appendix B. Methods and Tools for Analyzing ExistingApplications

The methods and tools you use to analyze an existing application will depend on theinformation available in the old library system and in other files of the old environment. Thisappendix shows the methods and tools we used to extract control information for the twoapplications in our project.

Application 1Because CA-LIBRARIAN does not supply all the information required for migration to SCLM,we looked for other sources of information. We analyzed the load modules to find:

Information about the compiler used

Compiler options for programs compiled with VS COBOL II.

The methods used and the tools developed for the analysis of load modules are general andmay be used unchanged in other environments.

We also extracted control information from comment records added to the source codeduring the release process. The technical details of this analysis are specific to theenvironment of application 1, but the concept might be of interest for other environments aswell.

Compiler Information

In a CA-LIBRARIAN environment, all the source code is typically stored in one file. In SCLMyou want to set up different data sets for different source types, such as COBOL, PLI, orASM. You have to extract your source code according to its programming language to storeit in different data sets under SCLM. We analyzed the load modules of application 1 to findthe compiler information.

Compilers place their own IDs into the object modules they produce. Therefore, you can findthese compiler IDs (which normally are the product numbers) in the load modules. ProgramMIGU001 (listed in Figure 41 on page 78) analyzes load modules. Program MIGU001 hasthe following restrictions:

MIGU001 looks for the first load module record with a character string of “5665”(5665-284 stands for MVS/XA DFP) or “5752” (you find 5752-SC1 in some old modules) inposition 4 and uses this record as an anchor point.

The next record is assumed to contain the compiler ID starting in position 7. This is nottrue for PL/I modules. If you do not find a proper product number in the output listing,you can check the load module and find the PL/I product number elsewhere in the samerecord. We used this simple approach because we had only four PL/I programs in our


application. The sample program may be enhanced to look for “5734-PL1” (PL/IOptimizing Compiler) or “5668-910” (OS PL/I Version 2 Compiler).

Old OS/VS COBOL modules show “40CB1” instead of “5740CB1” at the indicatedposition in the load module. These old OS/VS COBOL modules should be compiledusing compiler option LANGLVL(1) with the OS/VS COBOL Release 2 compiler. It istherefore useful to find old OS/VS COBOL modules so that the correct compiler optionscan be specified.

MIGU001: PROC(PARM) OPTIONS(MAIN); 00010000/***============================================================== ***/00020000/*** PURPOSE.....: READ LOAD MODULE FROM FILE INDD AND EXTRACT ***/00030000/*** COMPILER PRODUCT-NO. INTO OUTPUT FILE OUTDD ***/00040000/*** TOGETHER WITH PROGRAM NAME. ***/00050000/*** ***/00060000/*** PARAMETER: ***/00070000/*** - NAME OF ANALYZED PGM IS EXPECTED AS PARM ***/00080000/*** PROGRAM DESCRIPTION: ***/00090000/*** - OPEN INDD (= LOAD MODULE, LRECL=19069, RECFM=U) ***/00100000/*** - OPEN OUTDD (= OUTPUT DATA SET, LRECL=80) ***/00110000/*** - READ INDD RECORD UNTIL '5665' OR '5752' ***/00120000/*** FOUND AS 4TH CHAR IN RECORD ***/00130000/*** - READ INDD RECORD NEXT AND TRANSFER INFO INTO ***/00140000/*** OUTDD RECORD ***/00150000/*** - WRITE OUTDD RECORD ***/00160000/*** - CLOSE OUTDD ***/00170000/*** - CLOSE INDD ***/00180000/*** ***/00190000/*** DATE WRITTEN: 02/24/93-FITZ ***/00200000/*** MODIFICATIONS: ***/00210000/***============================================================== ***/00220000/*** ***/00230000/***============================================================= ***/00240000/*** DECLARATIONS ***/00250000/*=============================================================== ***/00260000DCL PARM CHAR(100) VARYING; 00270000DCL ADDR BUILTIN; 00280000DCL INDD FILE; /* INPUT FILE */00290000DCL OUTDD FILE; /* OUTPUT FILE */00300000DCL EOF CHAR(1); /* EOF-INDD SWITCH */00310000DCL INF CHAR(1); /* INFO-RECORD SWITCH */00320000/*-------------------------------------------------------------------*/00330000DCL PROGRAM_RECORD CHAR(19069); /* FOR LOAD MODULE RECORD */00340000DCL 1 DFPX_RECORD BASED(ADDR(PROGRAM_RECORD)), 00350000

2 I_FILLER3 CHAR(3), 003600002 I_DFPX, 00370000

3 I_DFPX_1 CHAR(4), 003800003 I_DFPX_2 CHAR(3); 00390000

DCL 1 COMP_RECORD BASED(ADDR(PROGRAM_RECORD)), 004000002 C_FILLER6 CHAR(6), 004100002 I_COMP, 00420000

3 I_COMP_1 CHAR(4), 004300003 I_COMP_2 CHAR(3); 00440000

Figure 41 (Part 1 of 3). PL/I Program MIGU001


/*-------------------------------------------------------------------*/00450000DCL 1 OUTDD_RECORD UNALIGNED, /* */00460000

2 O_PGMNAME CHAR(08), /* PROGRAM NAME */004700002 O_DFPX_TEXT CHAR(14), 004800002 O_DFPX, 00490000

3 O_DFPX_1 CHAR(4), 005000003 O_DFPX_1A CHAR(1), 005100003 O_DFPX_2 CHAR(3), 00520000

2 O_COMP_TEXT CHAR(16), 005300002 O_COMP, 00540000

3 O_COMP_1 CHAR(4), 005500003 O_COMP_1A CHAR(1), 005600003 O_COMP_2 CHAR(3), 00570000

2 O_FILLER26 CHAR(26); 00580000/***============================================================= ***/00590000/*** ON ENDFILE SET EOF-SWITCH ***/00600000/*-------------------------------------------------------------------*/00610000ON ENDFILE(INDD) BEGIN; 00620000

O_FILLER26 = '## PREMATURE EOF FOUND. ##'; 00630000WRITE FILE(OUTDD) FROM(OUTDD_RECORD); 00640000GOTO FINIS; 00650000

END; 00660000/***------------------------------------------------------------- ***/00670000/*** OPEN DATEIEN ***/00680000/*-------------------------------------------------------------------*/00690000OPEN FILE(INDD) SEQUENTIAL RECORD INPUT, 00700000

FILE(OUTDD) SEQUENTIAL RECORD OUTPUT; 00710000/***------------------------------------------------------------- ***/00720000/*** INITIALIZATIONS ***/00730000/*-------------------------------------------------------------------*/00740000EOF = ' '; /* EOF-SWITCH */00750000INF = ' '; /* NOT RECORD WITH LKED ID */00760000PROGRAM_RECORD = ' '; 00770000/***------------------------------------------------------------- ***/00780000/*** READ LOAD MODULE RECORDS UNTIL PROD.NO. FOR DFP FOUND ***/00790000/*-------------------------------------------------------------------*/00800000DO WHILE (INF = ' '); 00810000

READ FILE(INDD) INTO(PROGRAM_RECORD); 00820000IF (I_DFPX_1 ='5665') THEN INF = 'I'; /* 5665-284 = MVS/XA DFP */00830000IF (I_DFPX_1 ='5752') THEN INF = 'I'; 00840000

END; /* */00850000/***------------------------------------------------------------- ***/00860000/*** TRANSFER INFO INTO OUTPUT RECORD ***/00870000/*-------------------------------------------------------------------*/00880000OUTDD_RECORD = ''; 00890000O_PGMNAME = PARM; /* PROGRAM NAME FROM EXEC CARD */00900000O_DFPX_TEXT = ' (PGM MGMT:) '; 00910000O_DFPX_1A = '-'; 00920000O_COMP_TEXT = ' COMPILED WITH '; 00930000O_COMP_1A = '-'; 00940000O_DFPX_1 = I_DFPX_1; 00950000O_DFPX_2 = I_DFPX_2; 00960000READ FILE(INDD) INTO(PROGRAM_RECORD); 00970000O_COMP_1 = I_COMP_1; /* COMPILER PRODUCT NR. */00980000O_COMP_2 = I_COMP_2; /* COMPILER PRODUCT NR. */00990000

/* */01000000


Appendix B. Methods and Tools for Analyzing Existing Applications 79

/***------------------------------------------------------------- ***/01010000/*** WRITE OUTPUT RECORD INTO FILE OUTDD ***/01020000/*-------------------------------------------------------------------*/01030000WRITE FILE(OUTDD) FROM(OUTDD_RECORD); 01040000/***------------------------------------------------------------- ***/01050000/*** CLOSE FILES ***/01060000/*-------------------------------------------------------------------*/01070000FINIS: 01080000CLOSE FILE(INDD), 01090000

FILE(OUTDD); 01100000/*-------------------------------------------------------------------*/01110000END; 01120000/*=============================================================== ***/01130000


Figure 42 shows the sample job to run MIGU001. You need to know the names of themodules you want to analyze for the EXEC statements in the job. A list of all programs to bemigrated is developed during the preparation for migration (refer to “Extract Data for theSample Applications” on page 17).

//....... JOB ...................., 00000100// ......................... 00000200//*========================================================== 00000300//PRODINF PROC PGMNAME= 00000400//MIGU001 EXEC PGM=MIGU001,PARM='/&PGMNAME' 00000500//STEPLIB DD DISP=SHR,DSN=SCLM3.RESI.LOAD 00000600// DD DISP=SHR,DSN=PLI.V2R3M0.PLILINK 00000700// DD DISP=SHR,DSN=PLI.V2R3M0.SIBMLINK 00000800//INDD DD DISP=SHR,DSN=STADE5.RUV.LOAD(&PGMNAME) 00000900//OUTDD DD DISP=OLD,DSN=STADE5.PRODNO.DATA(&PGMNAME) 00001000//SYSOUT DD SYSOUT=* 00001100//SYSPRINT DD SYSOUT=* 00001200// PEND 00001300//*========================================================== 00001400//S EXEC PRODINF,PGMNAME=KR00030 00001500//S EXEC PRODINF,PGMNAME=P03N905 00001600//S EXEC PRODINF,PGMNAME=P92N000 00001700//S EXEC PRODINF,PGMNAME=P92N001 00001800//S EXEC PRODINF,PGMNAME=P92N002 00001900...

Figure 42. Sample Job to Run Program MIGU001

Members of a PDS are the primary output of program MIGU001. Each member contains onlyone record. If the anchor point is not found, you will get an empty member.

We copied all members into one single file for the subsequent migration steps. Figure 43 onpage 81 shows this file with the output records from program MIGU001.


KR00030 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1P03N905 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1P92N000 (PGM MGMT:) 5665-284 COMPILED WITH 5740-CB1P92N001 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1P92N002 (PGM MGMT:) 5752-SC1 COMPILED WITH 40CB-1 <== old COBOLP92N003 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1P92N004 (PGM MGMT:) 5752-SC1 COMPILED WITH 40CB-1 <== old COBOLP92N005 (PGM MGMT:) 5665-284 COMPILED WITH 5668-958P92N006 (PGM MGMT:) 5665-284 COMPILED WITH 5668-962P92N008 (PGM MGMT:) 5665-284 COMPILED WITH 5668-958...P92N058 (PGM MGMT:) 5665-284 COMPILED WITH 5668-958P92N064 (PGM MGMT:) 5665-284 COMPILED WITH 5668-958P92N065 (PGM MGMT:) 5665-284 COMPILED WITH ....-³.. <== PL/IP92N066 (PGM MGMT:) 5665-284 COMPILED WITH .Ø..-573 <== PL/I...

Figure 43. Output Records from Analysis of Load Modules with Program MIGU001. The old OS/VSCOBOL compiler does not record the full product number 5740-CB1. Because of therestrictions for MIGU001, the product number output field for PL/I programs containsgarbage and manual correction is required.

The summary file in Figure 43 was sorted by compiler product number, the correct numberfor the PL/I modules was inserted, and for the old OS/VS COBOL programs the number wasshifted to the right to conform with the other output records.

Figure 44 shows the sorted file as the final result of this analysis step. This file serves as abase to create member lists that can be used when an action for one type or one languageshould be performed (for example, to copy all source modules of a given type into thecorresponding SCLM PDS from a common source file that contains all types of modules).

* ------------------------------------------------ OLD OS/VS COBOL:* USE OS/VS COBOL COMPILER OPTION LANGLVL(1) !P92N002 (PGM MGMT:) 5752-SC1 COMPILED WITH ..40-CB1P92N004 (PGM MGMT:) 5752-SC1 COMPILED WITH ..40-CB1P92N009 (PGM MGMT:) 5752-SC1 COMPILED WITH ..40-CB1...* ---------------------------------------------------- VS COBOL II:P92N005 (PGM MGMT:) 5665-284 COMPILED WITH 5668-958P92N008 (PGM MGMT:) 5665-284 COMPILED WITH 5668-958P92N016 (PGM MGMT:) 5665-284 COMPILED WITH 5668-958...* ------------------------------------------------- ASSEMBLER H V2:P92N006 (PGM MGMT:) 5665-284 COMPILED WITH 5668-962P92N041 (PGM MGMT:) 5665-284 COMPILED WITH 5668-962P92N219 (PGM MGMT:) 5665-284 COMPILED WITH 5668-962...

Figure 44 (Part 1 of 2). Sorted Output Records from Load Module Analysis


* ------------------------------------------------- PL/I OPTIMIZER:* USE OS PL/I V2 COMPILER OPTION CMPAT(V1) !P92N065 (PGM MGMT:) 5665-284 COMPILED WITH 5734-PL1P92N066 (PGM MGMT:) 5665-284 COMPILED WITH 5734-PL1P92N343 (PGM MGMT:) 5665-284 COMPILED WITH 5734-PL1P94N353 (PGM MGMT:) 5665-284 COMPILED WITH 5734-PL1* ---------------------------------------------------- OS/VS COBOL:P92N000 (PGM MGMT:) 5665-284 COMPILED WITH 5740-CB1P92N010 (PGM MGMT:) 5665-284 COMPILED WITH 5740-CB1P92N011 (PGM MGMT:) 5665-284 COMPILED WITH 5740-CB1...* -------------------------------------------------- OLD ASSEMBLER:KR00030 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1P03N905 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1P92N001 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1...* ----------------------------------------------------------------*

Figure 44 (Part 2 of 2). Sorted Output Records from Load Module Analysis. The primary file (seeFigure 43 on page 81) was corrected for old OS/VS COBOL programs andfor PL/I programs and sorted by product number.

VS COBOL II Compiler Options

VS COBOL II compiler option information is stored in all VS COBOL II load modules. Theformat of this information is described in VS COBOL II Application Programming: Debugging,SC26-4049. We developed program MIGU002 to extract this control information (seeFigure 45 on page 83).

Program MIGU002 assumes that the VS COBOL II program is the first CSECT in the loadmodule or that it is preceded only by the CICS interface module DFHECI. The differentlengths of DFHECI for CICS Version 1 and 2 and for CICS/ESA* (Version 3) are taken intoaccount.

One output member is created for each load module. We used the member name of theload module for the output member. Figure 46 on page 87 shows a sample job to runMIGU002.

An empty member is created for programs not recognized as VS COBOL II programs. ForVS COBOL II programs the output member contains one record. The first eight bytes in thisrecord contain the program name that comes from the PROGRAM-ID statement in thesource code. We used an ISPF EDIT macro to verify that the program name in the sourcemember and the load module name are identical. We found one PROGRAM-ID that was notidentical to the load module name (resulting from a typing error in the source program) andcorrected the output file manually.

The output record has a length of 255 bytes and contains all the data from the COBOLinformation bytes. We used only the information about the compiler release (modulescompiled with VS COBOL II Release 1 or 2 need option CMPR2 when compiled with VSCOBOL II Release 3) and the compiler options used.


000100*=================================================================00010000000200 IDENTIFICATION DIVISION. 00020000000300 PROGRAM-ID. MIGU002. 00030000000400*=================================================================00040000000500*** PURPOSE.....: READ LOAD MODULE FROM FILE EINGABE AND EXTRACT 00050000000600*** VS COBOL II INFORMATION BYTES (IF VS COBOL II) 00060000000700*** INTO OUTPUT FILE AUSGABE. 00070000000800*** VS COBOL II MUST BE FIRST CSECT IN LOAD 00080000000900*** MODULE OR SECOND AFTER DFH... MODULE FROM 00090000001000*** CICS V1 / V3 OR CICS/ESA V3. 00100000001100*** RETURN CODE: 0 = ALL OK *** 00110000001200*** 4 = NOT RECOGNIZED AS VS COBOL II PROGRAM *** 00120000001300*** DATE WRITTEN: 02/22/93-FITZ 00130000001400*=================================================================00140000001500 ENVIRONMENT DIVISION. 00150000001600*=================================================================00160000001700 CONFIGURATION SECTION. 00170000001800*-----------------------------------------------------------------00180000001900 SOURCE-COMPUTER. IBM-370. 00190000002000 OBJECT-COMPUTER. IBM-370. 00200000002100 SPECIAL-NAMES. 00210000002200 DECIMAL-POINT IS COMMA. 00220000002300 INPUT-OUTPUT SECTION. 00230000002400 FILE-CONTROL. 00240000002500 SELECT EINGABE 00250000002600 ASSIGN INDD 00260000002700 FILE STATUS IO-STATUS. 00270000002800 SELECT AUSGABE 00280000002900 ASSIGN OUTDD. 00290000003000 DATA DIVISION. 00300000003100 FILE SECTION. 00310000003200 FD EINGABE 00320000003300 LABEL RECORDS OMITTED 00330000003400 RECORDING MODE IS U. 00340000003500*-----------------------------------------------------------------00350000003600*-- RECORD LAYOUT OF FIRST CHARACTERS OF THE INPUT RECORD ---00360000003700*-- CONTAINING COBOL INFORMATION BYTES. ---00370000003800*-----------------------------------------------------------------00380000003900 01 EINGABE-SATZ. 00390000004000 05 FILLER PIC X(04). 00400000004100 88 E-KENNUNG-INFO VALUE X'47F0F070'. 00410000004200 05 FILLER PIC X(72). 00420000004300 05 FILLER PIC X(72). 00430000004400 01 EINGABE-SATZ-CICS2. 00440000004500 05 FILLER PIC X(06). 00450000004600 88 E-KENNUNG-INFO-CICS1 VALUE 'DFHYC1'. 00460000004700 88 E-KENNUNG-INFO-CICS2 VALUE 'DFHYC2'. 00470000004800 05 FILLER PIC X(66). 00480000004900 05 EINGABE-SATZ-2. 00490000005000 10 FILLER PIC X(04). 00500000005100 88 E-KENNUNG-INFO-2 VALUE X'47F0F070'. 00510000005200 10 FILLER PIC X(72). 00520000005300 01 EINGABE-SATZ-CICS3. 00530000005400 05 FILLER PIC X(06). 00540000005500 88 E-KENNUNG-INFO-CICS3 VALUE 'DFHYC3'. 00550000005600 05 FILLER PIC X(50). 00560000

Figure 45 (Part 1 of 5). VS COBOL II Program MIGU002


005700 05 EINGABE-SATZ-3. 00570000005800 10 FILLER PIC X(04). 00580000005900 88 E-KENNUNG-INFO-3 VALUE X'47F0F070'. 00590000006000 10 FILLER PIC X(72). 00600000006100*----------------------------- 00610000006200 FD AUSGABE 00620000006300 BLOCK 0 RECORDS 00630000006400 LABEL RECORDS OMITTED 00640000006500 RECORDING MODE IS F. 00650000006600 01 AUSGABE-SATZ PIC X(255). 00660000006700*-----------------------------------------------------------------00670000006800 WORKING-STORAGE SECTION. 00680000006900*-----------------------------------------------------------------00690000007000 01 IO-STATUS PIC X(02). 00700000007100 88 OK VALUE '00', '04'. 00710000007200 01 SCHALTER-1 PIC X(01). 00720000007300 88 LESEN VALUE 'L'. 00730000007400 88 OPEN-ERROR VALUE 'O'. 00740000007500 88 READ-ERROR VALUE 'R'. 00750000007600 88 EOF VALUE 'E'. 00760000007700 01 SCHALTER-2 PIC X(01). 00770000007800 88 GEFUNDEN VALUE 'G'. 00780000007900 88 NICHT-VS-COBOL-2 VALUE 'N'. 00790000008000*-----------------------------------------------------------------00800000008100*-- RECORD LAYOUT FOR BEGIN OF INPUT RECORD ---00810000008200*-- WITH THE COBOL INFORMATION BYTES. ---00820000008300*-----------------------------------------------------------------00830000008400* 00840000008500 01 MODUL-ANFANG. 00850000008600 05 FILLER PIC X(05). 00860000008700 05 E-PGMNAME PIC X(08). 00870000008800 05 E-COMPILER-KENNUNG PIC X(04). 00880000008900 88 E-VS-COBOL-2 VALUE ' C2 '. 00890000009000 05 E-COMPILER-V-R-M PIC X(06). 00900000009100 05 E-COMPILE-DATE PIC X(08). 00910000009200 05 FILLER PIC X(01). 00920000009300 05 E-COMPILE-TIME PIC X(08). 00930000009400 05 FILLER PIC X(04). 00940000009500 05 E-INFO-BYTES OCCURS 24. 00950000009600 10 E-INFO-BYTE PIC X(01). 00960000009700 05 E-DATA-DIV-STMTS PIC S9(8) COMP. 00970000009800 05 E-PROC-DIV-STMTS PIC S9(8) COMP. 00980000009900* 00990000010000 01 I PIC S9(4) COMP. 01000000010100 01 J PIC S9(4) COMP. 01010000010200 01 FILLER REDEFINES J. 01020000010300 05 FILLER PIC X. 01030000010400 05 J2 PIC X. 01040000010500* 01050000010600*** -------------------------------------------------------- ***01060000010700*** VARIABLES FOR OUTPUT RECORD ***01070000010800*** -------------------------------------------------------- ***01080000010900* 01090000011000 01 VARLIST. 01100000011100 05 INFONAME PIC X(08). 01110000011200 05 INFO-VRM PIC X(08). 01120000



011300 05 INFODATE PIC X(08). 01130000011400 05 INFOTIME PIC X(08). 01140000011500 05 INFO-DD PIC X(08). 01150000011600 05 INFO-DD-NUM REDEFINES INFO-DD 01160000011700 PIC 9(08). 01170000011800 05 INFO-PD PIC X(08). 01180000011900 05 INFO-PD-NUM REDEFINES INFO-PD 01190000012000 PIC 9(08). 01200000012100 05 FILLER OCCURS 24. 01210000012200 10 INFO-I PIC X(08). 01220000012300 05 INFEHLER PIC X(08). 01230000012400 88 KEIN-FEHLER VALUE SPACE. 01240000012500* 01250000012600*-----------------------------------------------------------------01260000012700*--- TABLE FOR BIT-BYTE-CONVERSION ---01270000012800*-----------------------------------------------------------------01280000012900* 01290000013000 01 B-B-TABLE. 01300000013100* 01310000013200 05 FILLER PIC X(08) VALUE '00000000'. 01320000013300 05 FILLER PIC X(08) VALUE '00000001'. 01330000013400 05 FILLER PIC X(08) VALUE '00000010'. 01340000013500 05 FILLER PIC X(08) VALUE '00000011'. 01350000013600 05 FILLER PIC X(08) VALUE '00000100'. 01360000013700 05 FILLER PIC X(08) VALUE '00000101'. 01370000013800 05 FILLER PIC X(08) VALUE '00000110'. 01380000013900 05 FILLER PIC X(08) VALUE '00000111'. 01390000014000 05 FILLER PIC X(08) VALUE '00001000'. 01400000014100 05 FILLER PIC X(08) VALUE '00001001'. 01410000014200 05 FILLER PIC X(08) VALUE '00001010'. 01420000014300 05 FILLER PIC X(08) VALUE '00001011'. 01430000014400 05 FILLER PIC X(08) VALUE '00001100'. 01440000014500 05 FILLER PIC X(08) VALUE '00001101'. 01450000014600 05 FILLER PIC X(08) VALUE '00001110'. 01460000014700 05 FILLER PIC X(08) VALUE '00001111'. 01470000014800* 01480000014900 05 FILLER PIC X(08) VALUE '00010000'. 01490000015000 05 FILLER PIC X(08) VALUE '00010001'. 01500000015100 05 FILLER PIC X(08) VALUE '00010010'. 01510000......040000 05 FILLER PIC X(08) VALUE '11111101'. 04000000040100 05 FILLER PIC X(08) VALUE '11111110'. 04010000040200 05 FILLER PIC X(08) VALUE '11111111'. 04020000040300* 04030000040400 01 FILLER REDEFINES B-B-TABLE. 04040000040500 05 B-B-TABLE-J PIC X(08) OCCURS 256. 04050000040600* 04060000040700*=================================================================04070000040800 PROCEDURE DIVISION. 04080000040900*=================================================================04090000041000* 04100000041100******************************************************************04110000041200*** MAIN CONTROL FLOW. ***04120000041300******************************************************************04130000041400* 04140000



041500 STEUERUNG SECTION. 04150000041600*-----------------------------------------------------------------04160000041700 SET KEIN-FEHLER TO TRUE 04170000041800 SET LESEN TO TRUE 04180000041900 MOVE SPACE TO VARLIST. 04190000042000* 04200000042100 OPEN INPUT EINGABE. 04210000042200 OPEN OUTPUT AUSGABE. 04220000042300 IF NOT OK 04230000042400 SET OPEN-ERROR TO TRUE 04240000042500 MOVE 'OPENERR' TO INFEHLER 04250000042600 ELSE 04260000042700 PERFORM UNTIL NOT LESEN 04270000042800 READ EINGABE AT END 04280000042900 SET EOF TO TRUE 04290000043000 END-READ 04300000043100 IF (NOT EOF) AND (NOT OK) 04310000043200 SET READ-ERROR TO TRUE 04320000043300 MOVE 'READERR' TO INFEHLER 04330000043400 END-IF 04340000043500 IF LESEN AND ((E-KENNUNG-INFO OR 04350000043600 (E-KENNUNG-INFO-CICS3 AND 04360000043700 E-KENNUNG-INFO-3) OR 04370000043800 (E-KENNUNG-INFO-CICS2 AND 04380000043900 E-KENNUNG-INFO-2) OR 04390000044000 (E-KENNUNG-INFO-CICS1 AND 04400000044100 E-KENNUNG-INFO-2))) 04410000044200 SET GEFUNDEN TO TRUE 04420000044300 EVALUATE TRUE 04430000044400 WHEN E-KENNUNG-INFO 04440000044500 MOVE EINGABE-SATZ TO MODUL-ANFANG 04450000044600 WHEN E-KENNUNG-INFO-CICS3 04460000044700 MOVE EINGABE-SATZ-3 TO MODUL-ANFANG 04470000044800 WHEN E-KENNUNG-INFO-CICS2 04480000044900 MOVE EINGABE-SATZ-2 TO MODUL-ANFANG 04490000045000 WHEN E-KENNUNG-INFO-CICS1 04500000045100 MOVE EINGABE-SATZ-2 TO MODUL-ANFANG 04510000045200 END-EVALUATE 04520000045300 IF E-VS-COBOL-2 04530000045400 PERFORM PREPARE-AUSGABE 04540000045500 MOVE VARLIST TO AUSGABE-SATZ 04550000045600 WRITE AUSGABE-SATZ 04560000045700 END-IF 04570000045800 END-IF 04580000045900 END-PERFORM 04590000046000 CLOSE EINGABE 04600000046100 CLOSE AUSGABE 04610000046200 END-IF. 04620000046300 IF NOT GEFUNDEN 04630000046400 MOVE 4 TO RETURN-CODE 04640000046500 END-IF. 04650000046600* 04660000046700 STEUERUNG-EXIT. 04670000046800 GOBACK. 04680000046900* 04690000047000******************************************************************04700000



047100*** PREPARE-AUSGABE SECTION. ***04710000047200*** MOVE DATA FROM EINGABE-SATZ TO VARLIST ***04720000047300*** CONVERTING BITS OF COBOL INFO BYTES TO BYTES. ***04730000047400*** ***04740000047500******************************************************************04750000047600* 04760000047700 PREPARE-AUSGABE SECTION. 04770000047800* 04780000047900 MOVE E-PGMNAME TO INFONAME. 04790000048000 MOVE E-COMPILER-V-R-M TO INFO-VRM. 04800000048100 MOVE E-COMPILE-DATE TO INFODATE. 04810000048200 MOVE E-COMPILE-TIME TO INFOTIME. 04820000048300 MOVE E-DATA-DIV-STMTS TO INFO-DD-NUM. 04830000048400 MOVE E-PROC-DIV-STMTS TO INFO-PD-NUM. 04840000048500* 04850000048600 PERFORM WITH TEST BEFORE 04860000048700 VARYING I FROM 1 BY 1 UNTIL I > 24 04870000048800 MOVE ZERO TO J 04880000048900 MOVE E-INFO-BYTE(I) TO J2 04890000049000 ADD 1 TO J 04900000049100 MOVE B-B-TABLE-J(J) TO INFO-I(I) 04910000049200 END-PERFORM. 04920000049300* 04930000049400 PREPARE-AUSGABE-EXIT. 04940000049500 EXIT. 04950000049600*=================================================================04960000


//....... JOB ....................., 00010000// .......................... 00020000//*========================================================== 00030000//PRODINF PROC PGMNAME= 00040000//MIGU002 EXEC PGM=MIGU002 00050000//STEPLIB DD DISP=SHR,DSN=SCLM3.RESI.LOAD 00060000// DD DISP=SHR,DSN=COBOL.V1R3M2.COB2LIB 00070000//INDD DD DISP=SHR,DSN=STADE5.RUV.LOAD(&PGMNAME) 00080000//OUTDD DD DISP=OLD,DSN=STADE5.COBINFO.DATA(&PGMNAME) 00090000//SYSOUT DD SYSOUT=* 00100000//SYSPRINT DD SYSOUT=* 00110000// PEND 00120000//*========================================================== 00130000//S EXEC PRODINF,PGMNAME=KR00030 00140000//S EXEC PRODINF,PGMNAME=P03N905 00150000//S EXEC PRODINF,PGMNAME=P92N000 00160000//S EXEC PRODINF,PGMNAME=P92N001 00170000//S EXEC PRODINF,PGMNAME=P92N002 00180000...

Figure 46. Sample Job to Run Program MIGU002. The OUTDD file is a PDS with LRECL=255.

We copied the output members into a single file for further analysis. Figure 47 on page 88shows the file with the output records from program MIGU002

The output was analyzed using the description of the COBOL information bytes in VS COBOLII Application Programming: Debugging, SC26-4049. Table 3 on page 37 shows the results ofour analysis.


----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+---Program V.R.M Date Time DataDiv ProcDiv COBOL_Information_Bytes_________________Name of_Compilation Stmts. Stmts. 1 2 3 4 5

1234567812345678123456781234567812345678

P92N005 1.2.0 07/20/9016.50.1800000031000000740100010000101110001011000000110000000000...P92N008 1.3.2 11/17/9217.09.2300000029000000520100010000101110011011000000110000001000...P92N016 1.2.0 05/07/9111.57.4100000100000002910100010000101110011011000000110000000000...P92N035 1.2.0 03/14/9013.17.3400000010000000380100010000101110001011000000110000000000...P92N036 1.2.0 06/17/9113.58.3000000038000000890100010000101110011011000000110000000000...P92N037 1.2.0 09/08/8911.52.4500000152000001320100010000111110001011100000110000000000...P92N038 1.2.0 02/21/8916.51.0200000121000000670100010000111110001011100000110000000000...P92N039 1.2.0 03/14/9013.15.4800000010000000380100010000101110001011000000110000000000...P92N040 1.2.0 06/21/9116.31.0600000266000004140100010000101110011011000000110000000000...P92N044 1.3.2 04/08/9209.19.4200000152000001650100010000101110011011000000110000001000...P92N046 1.3.2 10/24/9116.53.2600000260000002800100010000101110011011000000110101001000...P92N047 1.3.2 02/03/9212.20.3900000259000002900100010000101110011011000000110100001000...P92N048 1.2.0 04/27/9013.22.2400000144000001550100010000101110001011000000110000000000...P92N049 1.3.2 04/08/9209.21.2000000167000001640100010000101110011011000000110000001000......----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+---

Figure 47. Output from Program MIGU002. The full output record length is 255 bytes. Only the firstpart of the records, which contains the COBOL information flags for the compiler options, isshown. V.R.M indicates compiler version, release, and modification level.

Extracting Compile and Link Edit Information

This section describes the steps for extracting control information from program sourcecode. The control information consists of:

Compiler options that are not fixed for the release procedure

Linkage editor options that are not fixed for the release procedure

Names of statically linked modules.

This data is added as leading comment records to the released program source code by theprogram release procedure (refer to “Release Process” on page 13). The extraction wasperformed in two steps:

1. Extract the records from the program source code

2. Reformat the records to input records for our tool to create LEC and CC architecturedefinitions (refer to “LEC and CC Architecture Definitions” on page 123).

The process described here is specific to the application 1 environment. You may havesimilar environments, for instance if you use PROCESS (or CBL) statements in your COBOLand/or *PROCESS statements in your PL/I programs. However, even if your situation isdifferent, the basic approach you use for such an extraction could be similar.


Step 1: Extract Records from Program Source Code

To extract the records from program source code perform the following actions:

Allocate a PDS and copy the source modules extracted from the customer's productionCA-LIBRARIAN to this PDS (refer to file PP in Figure 4 on page 20). Figure 48 showsexamples of the first lines of released program source code for different programminglanguages.

VS COBOL II program P92N046:

000100**MZI*CP******RES DYN RENT DATA(24)NOSSR000200**MZI*LP******RENT AMODE=31RMODEANY000300**MZI*XX******ENDE MODUL-ZUSATZINFO****************************...

Assembler program P92N041:

* *MZI*CP****** 00000100* *MZI*IC******P92N010 P92N011 00000200* *MZI*XX******ENDE MODUL-ZUSATZINFO**************************** 00000300...

PL/I program P94N353:

/* *MZI*CP******MACRO OPT(0) */00000100/* *MZI*LP****** AMODE=24 */00000200/* *MZI*XX******ENDE MODUL-ZUSATZINFO**************************** */00000300

...

Figure 48. Examples of First Lines in Released Program Source Code

Delete all leading comment lines except the lines that contain the control information(called “MZI records” in application 1). A delimiter record (with string “MZI*XX******”)indicates the end of the valid control information records.

We used ISPF EDIT macro MIGE0040 (see Figure 49 on page 90) for this data reduction.This macro inserts the member name in front of each record and converts thelanguage-specific comment delimiter to a language type keyword (COBOL, PLI, or ASM).If leading control information records are not found, the macro creates one dummyrecord with “???” instead of the language type keyword.

To apply the EDIT macro to all members of a PDS, we used the general-purpose EDITmacro MIGE0000 listed in Figure 50 on page 91. Figure 51 on page 91 shows theresulting members.

Copy all members into one file (sequential data set or member of a PDS) and sort bytype. The records with type “???” need manual correction. We used the informationabout the compiler used from the corresponding load modules (refer to “CompilerInformation” on page 77) to insert the correct type. This was only required for a few oldOS/VS COBOL and Assembler modules with release dates before 1984. Default compileoptions are assumed for these modules.

The resulting file is the input for “Step 2: Reformat Extracted Records” on page 92.


ISREDIT MACRO 00010000/*--------------------------------------------------------------------*/00020000/* THIS MACRO: REDUCES SOURCE PROGRAM MEMBER */00030000/* FROM APPLICATION 1 TO LEADING LINES */00040000/* WITH CONTROL INFO FOR COMPILE AND LINK ("MZI"), */00050000/* SHIFTS ALL 12 CHAR TO RIGHT, */00060000/* PLACES MODULE NAME IN COL 1 AND */00070000/* MODULE TYPE IN COL 11 (IF KNOWN BY TYPE OF COMMENT).*/00080000/* ONE MZI*CC****** LINE IS CREATED WITH TYPE ???, */00090000/* IF NO LEADING MZI-LINES ARE FOUND. */00100000/*--------------------------------------------------------------------*/00110000

ISREDIT (MEMBER) = MEMBER 00120000ISREDIT NUMBER STD 00130000ISREDIT UNNUM 00140000ISREDIT FIND LAST P'=' 00150000ISREDIT (MLINE,MCOL) = CURSOR /* OLD LAST LINE */00160000

00170000ISREDIT FIND FIRST 9 'MZI*XX******ENDE MODUL-ZUSATZINFO' 00180000ISREDIT (FCOUNT) = FIND_COUNTS 00190000IF (&FCOUNT GT 0) THEN DO 00200000

ISREDIT (FLINE,FCOL) = CURSOR 00210000ISREDIT DELETE &FLINE &MLINE 00220000

END 00230000ELSE DO 00240000

ISREDIT DELETE 2 &MLINE 00250000ISREDIT LINE 1 = &STR('&STR( MZI*CP******)') 00260000

END 00270000ISREDIT FIND LAST P'=' 00280000ISREDIT (MLINE,MCOL) = CURSOR /* NEW LAST LINE */00290000

00300000ISREDIT (LINE1) = LINE 1 00310000SET COMM18 = &SUBSTR(1:8,&STR(&LINE1)&STR(XXXXXXXX) 00320000SET COMM78 = &SUBSTR(7:8,&STR(&LINE1)&STR(XXXXXXXX) 00330000SELECT 00340000

WHEN (&STR(&COMM18) = &STR(* *)) SET TYPE = ASM 00350000WHEN (&STR(&COMM18) = &STR( /* *)) SET TYPE = PLI 00360000WHEN (&STR(&COMM78) = &STR(**)) SET TYPE = COBOL 00370000OTHERWISE SET TYPE = &STR(???) 00380000

END 0039000000400000

SET X01 = &SUBSTR(1:10,&MEMBER&STR( *)) 00410000SET X11 = &SUBSTR(1:10,&TYPE&STR( *)) 00420000SET X = 1 00430000DO WHILE (&X LE &MLINE) 00440000

ISREDIT (LINEX) = LINE &X 00450000SET X21 = &SUBSTR(9:60,&LINEX) 00460000ISREDIT LINE &X = &STR('&STR(&X01)&STR(&X11)&STR(&X21)') 00470000SET X = &EVAL(&X + 1) 00480000

END 00490000ISREDIT END 00500000

EXIT 00510000

Figure 49. ISPF EDIT Macro MIGE0040

Figure 50 on page 91 shows the general-purpose EDIT macro MIGE0000. This EDIT macroallows you to execute another EDIT macro—specified as a parameter—for all members of aPDS. To apply an EDIT macro, for example, MIGE0040, to all members of a PDS, edit a newmember, $$$ say, and type MIGE0000 MIGE0040 on the command line. Wait until * END OFMEMBER LIST * is displayed and cancel the new member, $$$ in this case.


ISREDIT MACRO (MACRO2) 00010000/***============================================================== ***/00020000/*** PURPOSE.....: THIS EDIT MACRO IS TO BE CALLED FROM ***/00030000/*** AN EDITED MEMBER OF A PDS. ***/00040000/*** IT EXECUTES AN OTHER MACRO (NAME GIVEN AS A ***/00050000/*** PARAMETER) FOR ALL OTHER MEMBERS OF THE PDS) ***/00060000/*** ***/00070000/*** DATE WRITTEN: 03/06/93-FITZ ***/00080000/***============================================================== ***/00090000ISREDIT (DATA1) = DATAID 00100000ISREDIT (CURMBR) = MEMBER 00110000ISPEXEC LMOPEN DATAID(&DATA1) OPTION(INPUT) 00120000SET MEMBER = 00130000SET LCC = &LASTCC 00140000DO WHILE (&LCC = 0) 00150000

ISPEXEC LMMLIST DATAID(&DATA1) OPTION(LIST) MEMBER(MEMBER) STATS(NO) 00160000SET LCC = &LASTCC 00170000IF (&LCC = 0) THEN DO 00180000

IF (&MEMBER NE &CURMBR) THEN + 00190000ISPEXEC EDIT DATAID(&DATA1) MEMBER(&MEMBER) MACRO(&MACRO2) 00200000

END 00210000IF (&LCC = 8) THEN DO 00220000

WRITE &STR( * END OF MEMBER LIST *) 00230000END 00240000

END 00250000ISPEXEC LMMLIST DATAID(&DATA1) OPTION(FREE) 00260000ISPEXEC LMCLOSE DATAID(&DATA1) 00270000EXIT CODE(&MAXCC) 00280000/***============================================================== ***/00290000

Figure 50. ISPF EDIT Macro MIGE0000

Extracted information from VS COBOL II program P92N046:

P92N046 COBOL MZI*CP******RES DYN RENT DATA(24)NOSSRP92N046 COBOL MZI*LP******RENT AMODE=31RMODEANY

Extracted information from Assembler program P92N041:

P92N041 ASM MZI*CP******P92N041 ASM MZI*IC******P92N010 P92N011

Extracted information from PL/I program P94N353:

P94N353 PLI MZI*CP******MACRO OPT(0)P94N353 PLI MZI*LP****** AMODE=24

Figure 51. Control Information Extracted with EDIT Macro MIGE0040. MZI*CP lines contain compileroptions, MZI*LP lines contain linkage editor options, and MZI*IC lines contain names oflinked modules. At least the MZI*CP line is always present.


Step 2: Reformat Extracted Records

In this second step we reformatted the extracted data from the customer format to acommon format that is input to the automated generation of LEC and CC architecturedefinitions. The generation process for architecture definitions is described in “LEC and CCArchitecture Definitions” on page 123.

Input to this reformatting is the output of the previous step. The input format is shown inFigure 52; the resulting output is shown in Figure 53.

KR00030 ASM MZI*CP******P03N905 ASM MZI*CP******P92N000 COBOL MZI*CP******RES DYNP92N001 ASM MZI*CP******P92N002 COBOL MZI*CP******P92N003 ASM MZI*CP******P92N004 COBOL MZI*CP******P92N005 COBOL MZI*CP******RES DYN NORENT DATA(24)NOSSRP92N005 COBOL MZI*LP****** AMODE=24P92N006 ASM MZI*CP******P92N006 ASM MZI*LP****** AMODE=24RMODE=24P92N008 COBOL MZI*CP******NOCMPR2 DYN RENT DATA(24)NOSSRP92N008 COBOL MZI*LP******RENT AMODE=31RMODEANYP92N009 COBOL MZI*CP******P92N010 COBOL MZI*CP******RES DYN......

Figure 52. Input for REXX Procedure MIGR0040

KR00030 ASMP03N905 ASMP92N000 COBOLP92N001 ASMP92N002 COBOL LANGLVL(1)P92N003 ASMP92N004 COBOL LANGLVL(1)P92N005 COBOL RENT,AMODE=24P92N006 ASMP92N008 COBOL RENTP92N009 COBOL LANGLVL(1)P92N010 COBOL......

Figure 53. Output from REXX Procedure MIGR0040

The reformatting was done with the REXX procedure MIGR0040 listed in Figure 54 onpage 93. Input and output data set names for this procedure were entered in panelMIGP0040. Figure 55 on page 96 shows the panel definition for MIGP0040.

MIGR0040 also considers the control information discussed in “Compiler Options” onpage 36 and “Control Information for the Linkage Editor” on page 41. Only the nondefaultoptions for the SCLM target environment appear in the output.


/***** REXX ***********************************************************/00010000/* PURPOSE.....: EXTRACT COMPILE AND LINK INFO FROM APPL.1 RECORDS */00020000/* DATE WRITTEN: 03/22/93-FITZ */00030000/**********************************************************************/00040000/* TRACE R */ 00050000/* ------------------------------------------------------------------ */00060000ADDRESS ISPEXEC 00070000"DISPLAY PANEL(MIGP0040)" /* GET DSNAMES FROM PANEL */ 00080000IF RC = 0 THEN DO 00090000

CINNAME = "'"CINNAME"'" 00100000COUNAME = "'"COUNAME"'" 00110000ADDRESS TSO 00120000"ALLOC FILE(INPFILE) DATASET("CINNAME") SHR REUSE" 00130000"ALLOC FILE(OUTFILE) DATASET("COUNAME") OLD REUSE" 00140000PGMPREV = ' ' 00150000MOREINP = 1 00160000DO WHILE MOREINP = 1 00170000

ADDRESS TSO 00180000"EXECIO 1 DISKR INPFILE" 00190000IF RC ¬= 0 THEN DO 00200000

MOREINP = 0 00210000IF (PGMPREV ¬= ' ') THEN DO /* IF NOT FIRST INPUT MBR:*/ 00220000

/* WRITE RECORD PREV. MBR.*/ 00230000QUEUE PGMPREV || CPINFO || LPINFO || ICINFO 00240000"EXECIO 1 DISKW OUTFILE" 00250000

END 00260000END 00270000ELSE DO 00280000

PULL RECORD /* LRECL=80 EXPECTED */ 00290000PGMINFO = SUBSTR(RECORD,1,20) /* MODULE NAME AND TYPE */ 00300000PGMTYPE = SUBSTR(RECORD,11,10) /* MODULE TYPE */ 00310000PGMTYPE = STRIP(PGMTYPE) 00320000MZITYPE = SUBSTR(RECORD,25,2) /* TYPE OF CONTROL INFO */ 00330000IF (PGMPREV ¬= PGMINFO) THEN DO /* IF INPUT FOR NEW MBR.: */ 00340000

IF (PGMPREV ¬= ' ') THEN DO /* IF NOT FIRST INPUT MBR:*/ 00350000/* WRITE RECORD PREV. MBR.*/ 00360000

QUEUE PGMPREV || CPINFO || LPINFO || ICINFO 00370000"EXECIO 1 DISKW OUTFILE" 00380000

END 00390000PGMPREV = PGMINFO 00400000LPINFO = LEFT(' ',40) /* DEFLT., IF NO LP INPUT */ 00410000ICINFO = LEFT(' ',40) /* DEFLT., IF NO IC INPUT */ 00420000

END 00430000/* CONTROL DATA IN INPUT REC = 5 * 8 CHAR */ 00440000

XX1 = SUBSTR(RECORD,33,8) 00450000XX2 = SUBSTR(RECORD,41,8) 00460000XX3 = SUBSTR(RECORD,49,8) 00470000XX4 = SUBSTR(RECORD,57,8) 00480000XX5 = SUBSTR(RECORD,65,8) 00490000SELECT 00500000

/*------------------------------------- COMPILER OPTIONS */ 00510000WHEN MZITYPE = 'CP' THEN DO 00520000

SELECT 00530000WHEN PGMTYPE = 'COBOL' THEN DO 00540000

/* ----- TYPE = COBOL --------------------------*/ 00550000SELECT 00560000

Figure 54 (Part 1 of 3). REXX Procedure MIGR0040


WHEN SUBSTR(XX4,1,4) ¬= 'DATA' THEN DO 00570000/* ---- OS/VS COBOL ----------------------*/ 00580000LANG = COBOL 00590000IF XX1 = '' THEN /* WITHOUT INFO */ 00600000

XX1 = 'LANGLVL(1)' /* = OLD MODULES*/ 00610000IF XX1 = 'RES' THEN 00620000

XX1 = ' ' /* DEFAULT "RES"*/ 00630000IF XX2 = 'DYN' THEN 00640000

XX2 = ' ' /* DEFAULT "DYN"*/ 00650000END 00660000WHEN XX1 = 'NOCMPR2' THEN DO 00670000

/* ---- VS COBOL II WITH NOCMPR2 ---------*/ 00680000LANG = COB2 00690000

/* USE "NOCMPR2"*/ 00700000XX1 = ' ' /* FOR ALL COB2 */ 00710000IF XX2 = 'DYN' THEN 00720000

XX2 = ' ' /* DEFAULT "DYN"*/ 00730000/* USE "RENT" */ 00740000

XX3 = ' ' /* FOR ALL COB2 */ 00750000IF XX4 = 'DATA(24)' THEN 00760000

XX4 = ' ' /* DEF. "DATA(24)"*/ 00770000/* USE "NOSSR" */ 00780000

XX5 = ' ' /* FOR ALL COB2 */ 00790000END 00800000OTHERWISE DO 00810000

/* ---- VS COBOL II WITH CMPR2 -----------*/ 00820000LANG = COB22 00830000

/* USE "CMPR2" */ 00840000XX1 = ' ' /* FOR ALL COB22*/ 00850000IF XX2 = 'DYN' THEN 00860000

XX2 = ' ' /* DEFAULT "DYN"*/ 00870000/* USE "RENT" */ 00880000

XX3 = ' ' /* FOR ALL COB22*/ 00890000IF XX4 = 'DATA(24)' THEN 00900000

XX4 = ' ' /* DEF. "DATA(24)"*/ 00910000/* USE "NOSSR" */ 00920000

XX5 = ' ' /* FOR ALL COB22*/ 00930000END 00940000

END 00950000END 00960000WHEN PGMTYPE = 'PLI' THEN DO 00970000

/* ----- TYPE = PLI ----------------------------*/ 00980000LANG = PLIO 00990000XX1 = ' ' /* IGNORE CP1, USE DEFAULT "MACRO" */ 01000000IF XX2 = 'OPT(2)' THEN 01010000

XX2 = ' ' /* IGNORE DEFAULT "OPT(2)"*/ 01020000IF XX5 = '' THEN /* WITHOUT INFO */ 01030000

XX5 = 'CMPAT(V1)' /* = OLD MODULES*/ 01040000END 01050000WHEN PGMTYPE = 'ASM' THEN DO 01060000

/* ----- TYPE = ASM ----------------------------*/ 01070000LANG = ASMH 01080000

END 01090000OTHERWISE 01100000

END 01110000/*--------------------------*/ 01120000



CPINFO = STRIP(XX1) 01130000IF XX2 ¬= ' ' THEN 01140000

CPINFO = CPINFO || ',' || STRIP(XX2) 01150000IF XX3 ¬= ' ' THEN 01160000



CPINFO = CPINFO || ',' || STRIP(XX5) 01210000CPINFO = STRIP(CPINFO,,',') 01220000CPINFO = LEFT(CPINFO,40) 01230000

END 01240000/*------------------------------- LINKAGE EDITOR OPTIONS */ 01250000WHEN MZITYPE = 'LP' THEN DO 01260000

LPINFO = '' 01270000IF ((LANG = 'COB2') | (LANG = 'COB22')) THEN DO 01280000

XX1 = 'RENT' 01290000IF XX2 = 'AMODE=31' THEN 01300000

XX2 = ' ' 01310000IF XX3 = 'RMODEANY' THEN 01320000

XX3 = ' ' 01330000END 01340000IF (LANG = 'ASMH') THEN DO /* USE CODED VALUES */ 01350000

XX2 = ' ' 01360000XX3 = ' ' 01370000

END 01380000IF XX2 = 'AMODEANY' THEN 01390000

XX2 = 'AMODE=ANY' 01400000IF XX3 = 'RMODEANY' THEN 01410000

XX3 = 'RMODE=ANY' 01420000/*--------------------------*/ 01430000LPINFO = STRIP(XX1) 01440000IF XX2 ¬= ' ' THEN 01450000

LPINFO = LPINFO || ',' || STRIP(XX2) 01460000IF XX3 ¬= ' ' THEN 01470000

LPINFO = LPINFO || ',' || STRIP(XX3) 01480000LPINFO = STRIP(LPINFO,,',') 01490000LPINFO = LEFT(LPINFO,40) 01500000

END 01510000/*-------------------------------- STATIC LINKED MODULES */ 01520000WHEN MZITYPE = 'IC' THEN DO 01530000

ICINFO = SUBSTR(RECORD,33,40) 01540000END 01550000/*------------------------------------------------------ */ 01560000OTHERWISE 01570000

END 01580000END 01590000

END 01600000"EXECIO 0 DISKR INPFILE (FINIS" 01610000"EXECIO 0 DISKW OUTFILE (FINIS" 01620000"FREE FILE(INPFILE)" 01630000"FREE FILE(OUTFILE)" 01640000

END 01650000/* ------------------------------------------------------------------ */01660000EXIT 01670000



)ATTR DEFAULT(%$_) /* TEXT HIGH / TEXT LOW / INPUT HIGH CAPS LEFT */# TYPE(INPUT) INTENS(HIGH) CAPS(ON) JUST(LEFT) PAD('.')< TYPE(OUTPUT) INTENS(LOW) CAPS(OFF)

/**********************************************************************//* INPUT PANEL TO SPECIFY INPUT AND OUTPUT DSNAMES OF PDSS FOR */00020000/* HANDLING CONTROL INFO FROM APPLICATION 1 */00020000/* WITH REXX MIGR0040 */00020000/* DATE WRITTEN: 03/22/93-FITZ */00030000/**********************************************************************/)BODY$MIGP0040 ------------+-% Extract FUA Control Info $-+-----------------------%===>_ZCMD $+---------------------------------+ <ZDATE <ZTIME$$$Input data set (Sequential data set or PDS with member specification),$which contains the control information in original format:$$ INPUT DSNAME%===>#CINNAME $$$$Output data set (Sequential data set or PDS with member specification),$for the common format file (LRECL>=160):$$OUTPUT DSNAME%===>#COUNAME $$$$$press ENTER to execute, END to cancel function.)INIT /****************************************************************/

&ZCMD = ' '.CURSOR = CINNAME

)PROC /****************************************************************/VER(&CINNAME DSNAME)VER(&COUNAME DSNAME)VPUT (CINNAME COUNAME) PROFILE

)END

Figure 55. ISPF Input Panel Definition for MIGP0040

Application 2All the information required for the migration to SCLM can be found in ENDEVOR controlinformation. You can use PRINT software control language (SCL) or an ENDEVOR archivefile to find compiler and linkage editor information.

Find Information for Languages

The SCL PRINT action allows you to generate software configuration lists based on differentselection criteria. You can reference other SCL statements in your action statement tocreate the parameters for the requested action. Referenced statements are added to theaction statement.

We used the PRINT action B37 (see Figure 56 on page 97) which refers to statement B3 (seeFigure 57 on page 97) for our project. Action B37 prints information for element GNDV0050


and refers to statement B3, which is more general and prints information for all elementssatisfying the where clause.

ACTION B37 / STMT B3PRINT ELEMENT GNDV0050

FROM ENVIRONMENT: EMET SYSTEM: X SUBSYSTEM: L TYPE: ASMTO FILE: C1PRINTOPTIONS: BROWSE, COMPONENTS, NOSEARCH

WHERE CCID EQUALS SPECIFIED

Figure 56. SCL for Action B37 and Statement B3. One action must be specified. The WHERE clauserefers to the change code identifier (CCID) specification in STMT B3.

STMT B3PRINT ELE *FROM ENV EMET SYS X SUB L STA NUM 1 TYPE *TO C1PRINTWHERE CCID OF CURRENT EQ (MRWSCLM,MRWSCLM1)OPT COMP.

Figure 57. SCL for Statement B3. This statement provides the list of all elements that meet thefollowing selection parameters: environment EMET, system X, subsystem L, stage number1, all types, and CCID MRWSCLM or MRWSCLM1.

Extract Control Information from ENDEVOR Archive File

The REXX tool MIGR0030 provides automatic extraction for compiler and linkage editoroptions from an ENDEVOR archive file to the common formatted file (see Figure 58).

The records in the output file are sorted by element name, type name, compiler options, andlinkage editor options. This file becomes the input for tool MIGR0010 that creates CC andLEC architecture definitions.

/* REXX *//***********************************************************************

MIGR0030 :Purpose : To extract information from ENDEVOR Archive file

:Description : This program read the ENDEVOR archive file and

: writes all compiler and link edit options related: to Element/Type in the common formatted file.



:Date Written : 03/03/93-DUMAS MarcModifications : -------------------****************************************************************Comments : N/AInstructions : N/A

***********************************************************************/trace "n"

/**************************//* MAIN PROC *//**************************/

call inputdo forever

"execio 1 diskr inp "if rc¬=0 then leavepull recordparse value record with lineif substr(line,2,1)=x2c('58') & substr(line,54,7)¬=process thendo

element = substr(line,44,8)type = substr(line,54,8)if element¬=element1 thendo forever

"execio 1 diskr inp "pull recordparse value record with lineif substr(line,2,1)=h & substr(line,28,4)=parm thendo

ccparm = substr(line,37,39)call search_lkparmqueue element '' type '' ccparm lkparm"execio 1 diskw outp"leave

endend

element1=elementend

endexit

/**************************//* INPUT PROC *//**************************/

input:fqnamein=''fqnameout=''say 'Enter the name of the Archive file (PDS or SEQ, and without quote

s)'say 'ex: A.B.C or A.B.C(D)'Parse upper pull fqnameinfqnamein = "'"fqnamein"'""alloc da("fqnamein") f(inp) shr reus"if rc¬=0 then call error fqnameinsay 'Enter the name of the output file (PDS or SEQ, and without quotes

)'say 'ex: A.B.C or A.B.C(D)'Parse upper pull fqnameout



fqnameout = "'"fqnameout"'""alloc da("fqnameout") f(outp) shr reus"

if rc¬=0 then call error fqnameoutreturn rc

/**************************//* SEARCH_LKPARM PROC *//**************************/

search_lkparm:do forever

"execio 1 diskr inp "pull recordparse value record with lineif substr(line,2,1)=h & substr(line,25,7)=lnkparm thendo

lkparm = substr(line,37,50)leave

endendreturn rc

/**************************//* ERROR PROC *//**************************/

error:parse upper arg filenamesay 'file 'filename' does not exist'exit rc



Appendix C. SCLM Project DefinitionFigure 59 through Figure 65 on page 104 show the main parts of our project definition.

*********************************************************************** 00010000**** SCLM3 PROJECT DEFINITION - PDF 3.5 00020000*********************************************************************** 00030000

PRINT NOGEN 00040000*********************************************************************** 00050000*** START THE PROJECT DEFINITION FOR PROJECT SCLM3 00060000*********************************************************************** 00070000SCLM3 FLMABEG 00080000* 00090000*********************************************************************** 00100000** DEFINE GROUPS OF AUTHORIZATION CODES (FLMAGRP) 00110000*********************************************************************** 00120000

COPY ASCLM3 00130000* 00140000*********************************************************************** 00150000** PROJECT CONTROLS (FLMCNTRL) 00160000*********************************************************************** 00170000

COPY CSCLM3 00180000* 00190000*********************************************************************** 00200000** FLEXIBLE DATABSE (FLMALTC) 00210000*********************************************************************** 00220000

COPY FSCLM3 00230000* 00240000*********************************************************************** 00250000** DEFINE THE PROJECT HIERARCHY (FLMGROUP) 00260000*********************************************************************** 00270000PROD FLMGROUP AC=(PAG),KEY=Y,ALTC=SCLM3P 00280000TEST FLMGROUP AC=(TAG),KEY=Y,PROMOTE=PROD,ALTC=SCLM3T 00290000MIG1 FLMGROUP AC=(MAG1),KEY=Y,PROMOTE=TEST,ALTC=SCLM3D 00300000MIG2 FLMGROUP AC=(MAG2),KEY=Y,PROMOTE=TEST,ALTC=SCLM3D 00310000* 00320000*********************************************************************** 00330000** DEFINE THE TYPES (FLMTYPE) 00340000*********************************************************************** 00350000

COPY TSCLM3 00360000* 00370000*********************************************************************** 00380000** LANGUAGE DEFINITION TABLES (FLMLANGL,FLMTRNSL) 00390000*********************************************************************** 00400000

Figure 59 (Part 1 of 2). SCLM Project Definition SCLM3


COPY LSCLM3 00410000* 00420000*********************************************************************** 00430000** HORIZONTAL VERSIONING (FLMATVER) 00440000*********************************************************************** 00450000

COPY VSCLM3 00460000* 00470000*********************************************************************** 00480000*** END THE PROJECT DEFINITION 00490000*********************************************************************** 00500000

FLMAEND 00510000* 00520000*********************************************************************** 00530000

Figure 59 (Part 2 of 2). SCLM Project Definition SCLM3

*********************************************************************** 00010000** DEFINE GROUPS OF AUTHORIZATION CODES 00020000*********************************************************************** 00030000PAG FLMAGRP AC=(FUA,NDV) 00040000TAG FLMAGRP AC=(FUA,NDV) 00050000MAG1 FLMAGRP AC=(FUA) 00060000MAG2 FLMAGRP AC=(NDV) 00070000

Figure 60. Authorization Codes for Project SCLM3: ASCLM3

*********************************************************************** 00010000** PROJECT CONTROLS 00020000*********************************************************************** 00030000* 00040000

FLMCNTRL ACCT=SCLM3.ACCOUNT.FILE, C00050000LIBID=SCLM3, C00060000MAXVIO=10000, C00070000OPTOVER=Y, C00080000VERPDS=@@FLMPRJ.@@FLMGRP.@@FLMTYP.VERSION, C00090000VERS=SCLM3.AUDIT.FILE 00100000

* 00110000

Figure 61. Project Control for Project SCLM3: CSCLM3


*********************************************************************** 00010000** FLEXIBLE DATABASE SPECIFICATIONS 00020000** NO FLEXIBLE PDS NAMING USED (ALL STANDARD NAMES) 00030000*********************************************************************** 00040000* 00050000SCLM3P FLMALTC ACCT=STLPROD.SCLM3.ACCOUNT.FILE, C00060000

VERS=STLPROD.SCLM3.AUDIT.FILE 00070000* 00080000SCLM3T FLMALTC ACCT=STLTEST.SCLM3.ACCOUNT.FILE 00090000* 00100000SCLM3D FLMALTC ACCT=STLDEV.SCLM3.ACCOUNT.FILE 00110000* 00120000

Figure 62. Flexible Database Specification for Project SCLM3: FSCLM3

*********************************************************************** 00010000** DEFINE THE TYPES 00020000*********************************************************************** 00030000ARCHDEF FLMTYPE 00040000* 00050000ASM FLMTYPE EXTEND=ASMMACS 00060000ASMMACS FLMTYPE 00070000COBCOPY FLMTYPE 00080000COBOL FLMTYPE EXTEND=COBCOPY 00090000DB2CLIST FLMTYPE EXTEND=DBRM 00100000DB2OUT FLMTYPE 00110000SQL FLMTYPE 00120000PLI FLMTYPE 00130000* 00140000DBRM FLMTYPE 00150000OBJ FLMTYPE 00160000LIST FLMTYPE 00170000LMAP FLMTYPE 00180000LOAD FLMTYPE 00190000* 00200000CLIST FLMTYPE 00210000PANELS FLMTYPE 00220000SKELS FLMTYPE 00230000MSGS FLMTYPE 00240000* 00250000

Figure 63. Type Definitions for Project SCLM3: TSCLM3

Appendix C. SCLM Project Definition 103

*********************************************************************** 00010000** LANGUAGE DEFINITION TABLES 00020000** FLM@.... = UNCHANGED FROM ISR LIBRARY 00030000** F@...... = CUSTOMIZED LANGUAGE DEFINITIONS 00040000*********************************************************************** 00050000

COPY FLM@ARCD -- ARCHITECTURE DEF. LANGUAGE -- 00060000* 00070000

COPY F@ASMH -- ASSEMBLER H -- 00080000COPY F@COBL -- OS/VS COBOL -- 00090000COPY F@COB2 -- VS COBOL II -- 00100000COPY F@COB22 -- VS COBOL II WITH CMPR2 -- 00110000COPY F@PLIO -- PL/I OPTIMIZER -- 00120000COPY F@AD2 -- DB2 + ASSEMBLER H -- 00130000COPY FLM@BD2 -- FOR DB2 BIND -- 00140000COPY FLM@BDO -- FOR DB2 BIND -- 00150000COPY F@SCMD -- FOR DB2 DDL SUBCOMMANDS -- 00160000COPY F@L370 -- LINKAGE EDITOR -- 00170000

* 00180000COPY FLM@CLST -- TSO CLIST -- 00190000COPY F@PANELS -- ISPF PANELS -- 00200000COPY F@@SKEL -- ISPF SKELETONS -- 00210000COPY F@MSGS -- ISPF MESSAGES -- 00220000

* 00230000

Figure 64. Language Definitions for Project SCLM3: LSCLM3

*********************************************************************** 00010000** VERSIONING AND AUDITIBILITY 00020000*********************************************************************** 00030000

FLMATVER GROUP=PROD,TYPE=*,VERSION=YES 00040000* 00050000

Figure 65. Horizontal Versioning for Project SCLM3: VSCLM3

Language DefinitionsFigure 66 through Figure 76 on page 122 show the SCLM language definitions that we eithercreated or modified for the project. Modifications for our project are marked with @@ inpositions 70 to 71.

F@ASMH for Assembler H

*********************************************************************** 00010000* OS/VS ASSEMBLER 'H' LANGUAGE DEFINITION FOR SCLM * 00020000

Figure 66 (Part 1 of 3). Language Definition F@ASMH for Assembler H


* * 00030000*@@*****************************************************************@@* 00040000*@@ Modifications for ITSC Migration Project: @@* 00050000*@@ -- NO DSNAME PARAMETER FOR IEV90 @@* 00060000*@@ -- GOODRC=0 --> GOODRC=4 @@* 00070000*@@ -- PARMKWD parameter added to build translator(s) @@* 00080000*@@ -- Assembler options customized (RENT not specified) @@* 00090000*@@ @@* 00100000********************** GENERAL NOTES ******************************** 00110000* * 00120000* THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A * 00130000* REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE * 00140000* DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. * 00150000* * 00160000********************* CUSTOMIZATION NOTES ***************************** 00170000* * 00180000* LIST EACH "STATIC" COPY DATASET UNDER THE FLMSYSLB MACRO. * 00190000* USE THE LANGUAGE NAME (VALUE OF THE LANG KEYWORD) FOR THE LABEL * 00200000* ON THE FIRST FLMSYSLB MACRO. * 00210000* EXAMPLE: * 00220000* ASMH FLMSYSLB XXXXX.XXXXX.XXXXX * 00230000* FLMSYSLB YYYYY.YYYYY.YYYYY * 00240000* * 00250000* FOR EACH DATASET UNDER THE FLMSYSLB MACRO, ADD IT WITH A FLMCPYLB * 00260000* MACRO UNDER THE FLMALLOC WITH DDNAME=SYSLIB. * 00270000* * 00280000* CUSTOMIZE THE 'OPTIONS' AND 'GOODRC' FIELDS TO YOUR STANDARDS. * 00290000* * 00300000* ADD THE 'DSNAME' FIELD IF THE TRANSLATOR IS IN A PRIVATE LIBRARY. * 00310000* * 00320000* CHANGING THE VERSION FIELD ON FLMLANGL WILL CAUSE ALL MEMBERS TO BE * 00330000* OUT OF DATE. EACH MEMBER WILL BE RE-BUILT THE NEXT TIME BUILD IS * 00340000* INVOKED. * 00350000* * 00360000* IF YOU DON'T WANT A COMPILER LISTING, CHANGE THE DDNAME=SYSPRINT * 00370000* TO AN IOTYPE=W AND REMOVE THE UNNECESSARY PARAMETERS. * 00380000* * 00390000*********************************************************************** 00400000* CHANGE ACTIVITY: * 00410000* * 00420000* * 00430000*********************************************************************** 00440000ASMH FLMSYSLB SYS1.MACLIB 00450000* 00460000

FLMLANGL LANG=ASMH,VERSION=ASMHV2.1 00470000* 00480000* PARSER TRANSLATOR 00490000* 00500000

FLMTRNSL CALLNAM='SCLM ASM H PARSE', C00510000FUNCTN=PARSE, C00520000COMPILE=FLMLPGEN, C00530000PORDER=1, C00540000OPTIONS=(SOURCEDD=SOURCE, C00550000STATINFO=@@FLMSTP, C00560000



LISTINFO=@@FLMLIS, C00570000LISTSIZE=@@FLMSIZ, C00580000LANG=A) *** THIS IS ASSEMBLER ONLY *** 00590000

* (* SOURCE *) 00600000FLMALLOC IOTYPE=A,DDNAME=SOURCE 00610000FLMCPYLB @@FLMDSN(@@FLMMBR) 00620000

* 00630000* BUILD TRANSLATOR(S) 00640000* 00650000* --ASSEMBLER 'H' INTERFACE-- 00660000

FLMTRNSL CALLNAM='ASM H', C00670000FUNCTN=BUILD, C00680000COMPILE=IEV90, C00690000VERSION=2.1, C00700000GOODRC=4, @@C00710000PORDER=1, C00720000PARMKWD=PARM1, @@C00730000OPTIONS=(XREF(SHORT), @@C00740000NODECK,OBJECT) @@ 00750000

* 00760000* DDNAME ALLOCATIONS 00770000* 00780000FLMALLOC IOTYPE=S,DDNAME=SYSIN,KEYREF=SINC,RECNUM=9000 00790000FLMALLOC IOTYPE=W,DDNAME=SYSUT1,RECNUM=15000 00800000FLMALLOC IOTYPE=O,DDNAME=SYSLIN,KEYREF=OBJ,RECNUM=9000,DFLTTYP=OBJ 00810000FLMALLOC IOTYPE=A,DDNAME=SYSTERM 00820000FLMCPYLB NULLFILE 00830000

FLMALLOC IOTYPE=A,DDNAME=SYSPUNCH 00840000FLMCPYLB NULLFILE 00850000

FLMALLOC IOTYPE=I,DDNAME=SYSLIB,KEYREF=SINC 00860000* ADD ONE FLMCPYLB FOR EACH FLMSYSLB 00870000

FLMCPYLB SYS1.MACLIB 00880000FLMALLOC IOTYPE=O,DDNAME=SYSPRINT,KEYREF=LIST,PRINT=Y,DFLTTYP=LIST, C00890000

RECNUM=20000 00900000* 00910000* 5665-402 (C) COPYRIGHT IBM CORP 1980, 1989 00920000


F@L370 for the Linkage Editor

************************************************************************ 370/LINKAGE EDITOR LANGUAGE DEFINITION FOR SCLM ** **@@*****************************************************************@@**@@ Modifications for ITSC Migration Project: @@**@@ -- Link options LIST,LET,XREF added @@**@@ -- FLMCPYLB customized @@**@@ @@*

Figure 67 (Part 1 of 3). Language Definition F@L370 for the Linkage Editor


********************** GENERAL NOTES ********************************* ** THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A ** REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE ** DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. ** ********************** CUSTOMIZATION NOTES ****************************** ** ADD FLMCPYLB MACROS FOR EACH 'STATIC' INPUT DATASET FOR LINKEDIT ** PROCESSING, TO THE 'SYSLIB' FLMALLOC MACRO. ** MAKE SURE PORDER=3. THE LINK EDIT USES DD NAME LIST SUBSTITUTION. ** CUSTOMIZE THE 'OPTIONS' AND 'GOODRC' FIELDS TO YOUR STANDARDS. ** ** ************************************************************************

FLMLANGL LANG=LE370,CANEDIT=N,VERSION=L370V1.0*

FLMTRNSL CALLNAM='LKED/370', CFUNCTN=BUILD, CCOMPILE=IEWL, CVERSION=F64, CGOODRC=0, CPORDER=3, COPTIONS=(DCBS,LET,LIST,XREF) @@

** 1 (* SYSLIN *)

FLMALLOC IOTYPE=S,KEYREF=INCL,RECFM=FB,LRECL=80, CRECNUM=20000,DDNAME=SYSLIN

** 2 (* LOAD MODULE NAME *)

FLMALLOC IOTYPE=L,KEYREF=LOAD** 3 (* SYSLMOD *)

FLMALLOC IOTYPE=P,KEYREF=LOAD,RECFM=U,LRECL=0, CRECNUM=500,DIRBLKS=20,DDNAME=SYSLMOD

** 4 (* SYSLIB *)

FLMALLOC IOTYPE=A,DDNAME=SYSLIBFLMCPYLB PLI.V2R3M0.PLIBASE @@FLMCPYLB PLI.V2R3M0.SIBMBASE @@FLMCPYLB COBOL.V1R3M2.COB2LIB @@FLMCPYLB ISP.V3R5M0.ISPLOAD @@FLMCPYLB ISP.V3R5M0.ISPLPA @@FLMCPYLB ISR.V3R5M0.ISRLOAD @@FLMCPYLB ISR.V3R5M0.ISRLPA @@FLMCPYLB SYSC.DBP1.DSN220.DSNLOAD @@FLMCPYLB IMSESA.RESLIB @@FLMCPYLB CICS320.LOADLIB @@FLMCPYLB SYS1.LINKLIB @@

** 5 (* N/A *)

FLMALLOC IOTYPE=N** 6 (* SYSPRINT *)

FLMALLOC IOTYPE=O,KEYREF=LMAP,RECFM=FBA,LRECL=121, CRECNUM=2500,PRINT=Y,DDNAME=SYSPRINT



** 7 (* N/A *)

FLMALLOC IOTYPE=N** 8 (* SYSUT1 *)

FLMALLOC IOTYPE=W,RECFM=U,LRECL=0,RECNUM=5000, CDDNAME=SYSUT1

** 9 (* N/A *)

FLMALLOC IOTYPE=N** 10 (* N/A *)

FLMALLOC IOTYPE=N** 11 (* N/A *)

FLMALLOC IOTYPE=N** 12 (* SYSTERM *)

FLMALLOC IOTYPE=A,DDNAME=SYSTERMFLMCPYLB NULLFILE

** (* PARSER - PARSER LOAD LIBRARY FOR NEW SCLM LANGUAGES *)* FLMALLOC IOTYPE=A,DDNAME=PARSER* FLMCPYLB SCLM.PARSER.LOAD************************************************************************ CHANGE ACTIVITY: ** ** OY34273 - 900810 - CHANGED LRECL=6144 TO LRECL=0 FOR SYSLMOD AND ** SYSUT1. GT4045 - AAB ** ************************************************************************ 5665-402 (C) COPYRIGHT IBM CORP 1980, 1989


F@COBL for OS/VS COBOL

*********************************************************************** 00000100* OS/VS COBOL LANGUAGE DEFINITION FOR SCLM * 00000200* * 00000300*@@*****************************************************************@@* 00000400*@@ Modifications for ITSC Migration Project: @@* 00000500*@@ -- DSNAME parameter inserted for IFKCBL00 @@* 00000600*@@ -- GOODRC=0 --> GOODRC=4 @@* 00000700*@@ -- PARMKWD parameter added to build translator(s) @@* 00000800

Figure 68 (Part 1 of 3). Language Definition F@COBL for OS/VS COBOL


*@@ -- Compiler options customized @@* 00000900*@@ -- SYSPRINT LRECL 133 -> 121 for IFKCBL00 @@* 00001000*@@ @@* 00001100*@@ ==> OLd OS/VS pgms. may need additional option LANGLVL(1) <== @@* 00001200*@@ @@* 00001300********************** GENERAL NOTES ******************************** 00001400* * 00001500* THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A * 00001600* REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE * 00001700* DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. * 00001800* * 00001900********************* CUSTOMIZATION NOTES ***************************** 00002000* * 00002100* LIST EACH "STATIC" COPY DATASET UNDER THE FLMSYSLB MACRO. * 00002200* USE THE LANGUAGE NAME (VALUE OF THE LANG KEYWORD) FOR THE LABEL * 00002300* ON THE FIRST FLMSYSLB MACRO. * 00002400* EXAMPLE: * 00002500* COBL FLMSYSLB XXXXX.XXXXX.XXXXX * 00002600* FLMSYSLB YYYYY.YYYYY.YYYYY * 00002700* * 00002800* FOR EACH DATASET UNDER THE FLMSYSLB MACRO, ADD IT WITH A FLMCPYLB * 00002900* MACRO UNDER THE FLMALLOC WITH DDNAME=SYSLIB. * 00003000* * 00003100* CUSTOMIZE THE 'OPTIONS' AND 'GOODRC' FIELDS TO YOUR STANDARDS. * 00003200* * 00003300* ADD THE 'DSNAME' FIELD IF THE TRANSLATOR IS IN A PRIVATE LIBRARY. * 00003400* * 00003500* CHANGING THE VERSION FIELD ON FLMLANGL WILL CAUSE ALL MEMBERS TO BE * 00003600* OUT OF DATE. EACH MEMBER WILL BE RE-BUILT THE NEXT TIME BUILD IS * 00003700* INVOKED. * 00003800* * 00003900* IF YOU DON'T WANT A COMPILER LISTING, CHANGE THE DDNAME=SYSPRINT * 00004000* TO AN IOTYPE=W AND REMOVE THE UNNECESSARY PARAMETERS. * 00004100* * 00004200*********************************************************************** 00004300* CHANGE ACTIVITY: * 00004400* * 00004500* * 00004600*********************************************************************** 00004700

FLMLANGL LANG=COBOL,VERSION=COBLV1.0, C00004800TSLINL=80, C00004900TSSEQP='S 1 6 S 73 80' 00005000

* 00005100* PARSER TRANSLATOR 00005200* 00005300

FLMTRNSL CALLNAM='SCLM COBOL PARSE', C00005400FUNCTN=PARSE, C00005500COMPILE=FLMLPCBL, C00005600PORDER=1, C00005700OPTIONS=(@@FLMLIS,@@FLMSTP,@@FLMSIZ,) 00005800


* 00006200* BUILD TRANSLATOR(S) 00006300* 00006400



* --COBOL INTERFACE-- 00006500FLMTRNSL CALLNAM='COBOL', C00006600

FUNCTN=BUILD, C00006700COMPILE=IKFCBL00, C00006800DSNAME=VSCOBOL.V1R2M4.VSCOLIB, @@C00006900VERSION=1.2, @@C00007000GOODRC=4, @@C00007100PORDER=1, C00007200PARMKWD=PARM1, @@C00007300OPTIONS=(DMA,PRI,SIZE=512K,APOS,CNT=60,BUF=30K,OPT, @@C00007400LIB,RES,DYN,ENDJOB,NOADV,NOSEQ,XREF) @@ 00007500

* 00007600* DDNAME ALLOCATIONS 00007700* 00007800FLMALLOC IOTYPE=O,DDNAME=SYSLIN,KEYREF=OBJ,RECNUM=5000,DFLTTYP=OBJ 00007900FLMALLOC IOTYPE=I,DDNAME=SYSLIB,KEYREF=SINC 00008000FLMALLOC IOTYPE=S,DDNAME=SYSIN,KEYREF=SINC,RECNUM=2000 00008100FLMALLOC IOTYPE=W,DDNAME=SYSUT1,RECNUM=5000 00008200FLMALLOC IOTYPE=W,DDNAME=SYSUT2,RECNUM=5000 00008300FLMALLOC IOTYPE=W,DDNAME=SYSUT3,RECNUM=5000 00008400FLMALLOC IOTYPE=W,DDNAME=SYSUT4,RECNUM=5000 00008500FLMALLOC IOTYPE=A,DDNAME=SYSUT5 00008600FLMCPYLB NULLFILE 00008700

FLMALLOC IOTYPE=A,DDNAME=SYSUT6 00008800FLMCPYLB NULLFILE 00008900

FLMALLOC IOTYPE=A,DDNAME=SYSTERM 00009000FLMCPYLB NULLFILE 00009100


FLMALLOC IOTYPE=O,DDNAME=SYSPRINT,KEYREF=LIST,RECFM=FBA,LRECL=121, C00009400RECNUM=50000,PRINT=Y,DFLTTYP=LIST @@ 00009500

* 00009600* 5665-402 (C) COPYRIGHT IBM CORP 1980, 1989 00009700


F@COB2 for VS COBOL II

*********************************************************************** 00000100* COBOL II LANGUAGE DEFINITION FOR SCLM * 00000200*@@ for ANSI85 Standard (NOCMPR2) @@* 00000300*@@*****************************************************************@@* 00000400*@@ Modifications for ITSC Migration Project: @@* 00000500*@@ -- DSNAME parameter inserted for IGYCRCTL @@* 00000600*@@ -- GOODRC=0 --> GOODRC=4 @@* 00000700*@@ -- PARMKWD parameter added to build translator(s) @@* 00000800

Figure 69 (Part 1 of 3). Language Definition F@COB2 for VS COBOL II


*@@ -- Compile options completely customized @@* 00000900*@@ -- DEFLTTYP for IGYCRCTL SYSPRINT COMPLIST --> LIST @@* 00001000*@@ @@* 00001100********************** GENERAL NOTES ******************************** 00001200* * 00001300* THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A * 00001400* REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE * 00001500* DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. * 00001600* * 00001700********************* CUSTOMIZATION NOTES ***************************** 00001800* * 00001900* LIST EACH "STATIC" COPY DATASET UNDER THE FLMSYSLB MACRO. * 00002000* USE THE LANGUAGE NAME (VALUE OF THE LANG KEYWORD) FOR THE LABEL * 00002100* ON THE FIRST FLMSYSLB MACRO. * 00002200* EXAMPLE: * 00002300* COB2 FLMSYSLB XXXXX.XXXXX.XXXXX * 00002400* FLMSYSLB YYYYY.YYYYY.YYYYY * 00002500* * 00002600* FOR EACH DATASET UNDER THE FLMSYSLB MACRO, ADD IT WITH A FLMCPYLB * 00002700* MACRO UNDER THE FLMALLOC WITH DDNAME=SYSLIB. * 00002800* * 00002900* CUSTOMIZE THE 'OPTIONS' AND 'GOODRC' FIELDS TO YOUR STANDARDS. * 00003000* * 00003100* ADD THE 'DSNAME' FIELD IF THE TRANSLATOR IS IN A PRIVATE LIBRARY. * 00003200* * 00003300* CHANGING THE VERSION FIELD ON FLMLANGL WILL CAUSE ALL MEMBERS TO BE * 00003400* OUT OF DATE. EACH MEMBER WILL BE RE-BUILT THE NEXT TIME BUILD IS * 00003500* INVOKED. * 00003600* * 00003700* IF YOU DON'T WANT A COMPILER LISTING, CHANGE THE DDNAME=SYSPRINT * 00003800* TO AN IOTYPE=W AND REMOVE THE UNNECESSARY PARAMETERS. * 00003900* * 00004000* THIS LANGUAGE DEFINITION IS COMPATIBLE WITH THE AD/CYCLE COBOL * 00004100* COMPILER. * 00004200* * 00004300*********************************************************************** 00004400* CHANGE ACTIVITY: * 00004500* * 00004600* * 00004700*********************************************************************** 00004800* 00004900* THE LINE LENGTH IS 80 CHARACTERS AND SEQUENCE NUMBERS ARE PLACED 00005000* IN COLUMNS 1 TO 6 AND 73 TO 80. THESE ARE ONLY USED BY WSP/2 1.2 00005100* AND HIGHER. SCLM IGNORES THESE PARAMETERS. 00005200* 00005300

FLMLANGL LANG=COB2, C00005400TSLINL=80, C00005500TSSEQP='S 1 6 S 73 80' 00005600


FLMTRNSL CALLNAM='SCLM COBOL PARSE', C00006000FUNCTN=PARSE, C00006100COMPILE=FLMLPCBL, C00006200PORDER=1, C00006300CALLMETH=LINK, C00006400



OPTIONS=(@@FLMLIS,@@FLMSTP,@@FLMSIZ,) 00006500* (* SOURCE *) 00006600

FLMALLOC IOTYPE=A,DDNAME=SOURCE 00006700FLMCPYLB @@FLMDSN(@@FLMMBR) 00006800

* 00006900* 00007000* --COBOL II INTERFACE-- 00007100* 00007200

FLMTRNSL CALLNAM='COBOL II COMPILER', C00007300FUNCTN=BUILD, C00007400COMPILE=IGYCRCTL, C00007500DSNAME=COBOL.V1R3M2.COB2COMP, @@C00007600VERSION=1.3.2, @@C00007700GOODRC=4, @@C00007800PORDER=1, C00007900PARMKWD=PARM1, @@C00008000OPTIONS=(NOADV,APOST,DATA(24),DYN,LIB,MAP, @@C00008100FLAG(I,W), @@C00008200OFFSET,OPT,RENT,RES,NOSEQ,TRUNC(BIN),XREF,ZWB) @@ 00008300

* 00008400* DDNAME ALLOCATION 00008500* 00008600FLMALLOC IOTYPE=O,DDNAME=SYSLIN,KEYREF=OBJ,RECNUM=5000,DFLTTYP=OBJ 00008700FLMALLOC IOTYPE=I,DDNAME=SYSLIB,KEYREF=SINC 00008800FLMALLOC IOTYPE=S,DDNAME=SYSIN,KEYREF=SINC,RECNUM=2000 00008900FLMALLOC IOTYPE=W,DDNAME=SYSUT1,RECNUM=5000 00009000FLMALLOC IOTYPE=W,DDNAME=SYSUT2,RECNUM=5000 00009100FLMALLOC IOTYPE=W,DDNAME=SYSUT3,RECNUM=5000 00009200FLMALLOC IOTYPE=W,DDNAME=SYSUT4,RECNUM=5000 00009300FLMALLOC IOTYPE=W,DDNAME=SYSUT5,RECNUM=5000 00009400FLMALLOC IOTYPE=W,DDNAME=SYSUT6,RECNUM=5000 00009500FLMALLOC IOTYPE=W,DDNAME=SYSUT7,RECNUM=5000 00009600FLMALLOC IOTYPE=A,DDNAME=SYSTERM 00009700

FLMCPYLB NULLFILE 00009800FLMALLOC IOTYPE=A,DDNAME=SYSPUNCH 00009900

FLMCPYLB NULLFILE 00010000FLMALLOC IOTYPE=O,DDNAME=SYSPRINT,KEYREF=LIST,RECFM=FBA,LRECL=133, C00010100

RECNUM=50000,PRINT=Y,DFLTTYP=LIST @@ 00010200


F@COB22 for VS COBOL II with CMPR2

*********************************************************************** 00000100* COBOL II LANGUAGE DEFINITION FOR SCLM * 00000200*@@ for interpreting source code @@* 00000300*@@ like VS COBOL II Release 2 @@* 00000400*@@ (i.e. with options CMPR2,FLAGMIG) @@* 00000500*@@*****************************************************************@@* 00000600*@@ Modifications for ITSC Migration Project: @@* 00000700*@@ -- LANG=COB22 (this language will disappear after @@* 00000800

Figure 70 (Part 1 of 3). Language Definition F@COB22 for VS COBOL II with CMPR2


*@@ complete COBOL migration of appl.) @@* 00000900*@@ -- DSNAME parameter inserted for IGYCRCTL @@* 00001000*@@ -- GOODRC=0 --> GOODRC=4 @@* 00001100*@@ -- PARMKWD parameter added to build translator(s) @@* 00001200*@@ -- Compile options completely customized @@* 00001300*@@ -- DEFLTTYP for IGYCRCTL SYSPRINT COMPLIST --> LIST @@* 00001400*@@ @@* 00001500********************** GENERAL NOTES ******************************** 00001600* * 00001700* THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A * 00001800* REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE * 00001900* DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. * 00002000* * 00002100********************* CUSTOMIZATION NOTES ***************************** 00002200* * 00002300* LIST EACH "STATIC" COPY DATASET UNDER THE FLMSYSLB MACRO. * 00002400* USE THE LANGUAGE NAME (VALUE OF THE LANG KEYWORD) FOR THE LABEL * 00002500* ON THE FIRST FLMSYSLB MACRO. * 00002600* EXAMPLE: * 00002700* COB2 FLMSYSLB XXXXX.XXXXX.XXXXX * 00002800* FLMSYSLB YYYYY.YYYYY.YYYYY * 00002900* * 00003000* FOR EACH DATASET UNDER THE FLMSYSLB MACRO, ADD IT WITH A FLMCPYLB * 00003100* MACRO UNDER THE FLMALLOC WITH DDNAME=SYSLIB. * 00003200* * 00003300* CUSTOMIZE THE 'OPTIONS' AND 'GOODRC' FIELDS TO YOUR STANDARDS. * 00003400* * 00003500* ADD THE 'DSNAME' FIELD IF THE TRANSLATOR IS IN A PRIVATE LIBRARY. * 00003600* * 00003700* CHANGING THE VERSION FIELD ON FLMLANGL WILL CAUSE ALL MEMBERS TO BE * 00003800* OUT OF DATE. EACH MEMBER WILL BE RE-BUILT THE NEXT TIME BUILD IS * 00003900* INVOKED. * 00004000* * 00004100* IF YOU DON'T WANT A COMPILER LISTING, CHANGE THE DDNAME=SYSPRINT * 00004200* TO AN IOTYPE=W AND REMOVE THE UNNECESSARY PARAMETERS. * 00004300* * 00004400* THIS LANGUAGE DEFINITION IS COMPATIBLE WITH THE AD/CYCLE COBOL * 00004500* COMPILER. * 00004600* * 00004700*********************************************************************** 00004800* CHANGE ACTIVITY: * 00004900* * 00005000* * 00005100*********************************************************************** 00005200* 00005300* THE LINE LENGTH IS 80 CHARACTERS AND SEQUENCE NUMBERS ARE PLACED 00005400* IN COLUMNS 1 TO 6 AND 73 TO 80. THESE ARE ONLY USED BY WSP/2 1.2 00005500* AND HIGHER. SCLM IGNORES THESE PARAMETERS. 00005600* 00005700

FLMLANGL LANG=COB22, @@C00005800TSLINL=80, C00005900TSSEQP='S 1 6 S 73 80' 00006000


FLMTRNSL CALLNAM='SCLM COBOL PARSE', C00006400



FUNCTN=PARSE, C00006500COMPILE=FLMLPCBL, C00006600PORDER=1, C00006700CALLMETH=LINK, C00006800OPTIONS=(@@FLMLIS,@@FLMSTP,@@FLMSIZ,) 00006900


* 00007300* 00007400* --COBOL II INTERFACE-- 00007500* 00007600

FLMTRNSL CALLNAM='COBOL II COMPILER', C00007700FUNCTN=BUILD, C00007800COMPILE=IGYCRCTL, C00007900DSNAME=COBOL.V1R3M2.COB2COMP, @@C00008000VERSION=1.3.2, @@C00008100GOODRC=4, @@C00008200PORDER=1, C00008300PARMKWD=PARM1, @@C00008400OPTIONS=(NOADV,APOST,DATA(24),DYN,LIB,MAP, @@C00008500CMPR2,FLAGMIG,FLAG(I,W), @@C00008600OFFSET,OPT,RENT,RES,NOSEQ,TRUNC(BIN),XREF,ZWB) @@ 00008700

* 00008800* DDNAME ALLOCATION 00008900* 00009000FLMALLOC IOTYPE=O,DDNAME=SYSLIN,KEYREF=OBJ,RECNUM=5000,DFLTTYP=OBJ 00009100FLMALLOC IOTYPE=I,DDNAME=SYSLIB,KEYREF=SINC 00009200FLMALLOC IOTYPE=S,DDNAME=SYSIN,KEYREF=SINC,RECNUM=2000 00009300FLMALLOC IOTYPE=W,DDNAME=SYSUT1,RECNUM=5000 00009400FLMALLOC IOTYPE=W,DDNAME=SYSUT2,RECNUM=5000 00009500FLMALLOC IOTYPE=W,DDNAME=SYSUT3,RECNUM=5000 00009600FLMALLOC IOTYPE=W,DDNAME=SYSUT4,RECNUM=5000 00009700FLMALLOC IOTYPE=W,DDNAME=SYSUT5,RECNUM=5000 00009800FLMALLOC IOTYPE=W,DDNAME=SYSUT6,RECNUM=5000 00009900FLMALLOC IOTYPE=W,DDNAME=SYSUT7,RECNUM=5000 00010000FLMALLOC IOTYPE=A,DDNAME=SYSTERM 00010100

FLMCPYLB NULLFILE 00010200FLMALLOC IOTYPE=A,DDNAME=SYSPUNCH 00010300

FLMCPYLB NULLFILE 00010400FLMALLOC IOTYPE=O,DDNAME=SYSPRINT,KEYREF=LIST,RECFM=FBA,LRECL=133, C00010500

RECNUM=50000,PRINT=Y,DFLTTYP=LIST @@ 00010600


F@PLIO for OS PL/I V2

*********************************************************************** 00000100* OS PL/I OPTIMIZING COMPILER LANGUAGE DEFINITION FOR SCLM * 00000200* * 00000300*@@*****************************************************************@@* 00000400

Figure 71 (Part 1 of 3). Language Definition F@PLIO for OS PL/I V2


*@@ Modifications for ITSC Migration Project: @@* 00000500*@@ -- DSNAME parameter customized for IEL0AA @@* 00000600*@@ -- GOODRC=0 --> GOODRC=4 @@* 00000700*@@ -- Compiler options customized @@* 00000800*@@ @@* 00000900*@@ ==> OLd PL/I programs may need additional option CMPAT(V1) <== @@* 00001000*@@ @@* 00001100********************** GENERAL NOTES ******************************** 00001200* * 00001300* THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A * 00001400* REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE * 00001500* DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. * 00001600* * 00001700********************* CUSTOMIZATION NOTES ***************************** 00001800* * 00001900* LIST EACH "STATIC" COPY DATASET UNDER THE FLMSYSLB MACRO. * 00002000* USE THE LANGUAGE NAME (VALUE OF THE LANG KEYWORD) FOR THE LABEL * 00002100* ON THE FIRST FLMSYSLB MACRO. * 00002200* EXAMPLE: * 00002300* PLIO FLMSYSLB XXXXX.XXXXX.XXXXX * 00002400* FLMSYSLB YYYYY.YYYYY.YYYYY * 00002500* * 00002600* FOR EACH DATASET UNDER THE FLMSYSLB MACRO, ADD IT WITH A FLMCPYLB * 00002700* MACRO UNDER THE FLMALLOC WITH DDNAME=SYSLIB. * 00002800* * 00002900* CUSTOMIZE THE 'OPTIONS' AND 'GOODRC' FIELDS TO YOUR STANDARDS. * 00003000* * 00003100* ADD THE 'DSNAME' FIELD IF THE TRANSLATOR IS IN A PRIVATE LIBRARY. * 00003200* * 00003300* CHANGING THE VERSION FIELD ON FLMLANGL WILL CAUSE ALL MEMBERS TO BE * 00003400* OUT OF DATE. EACH MEMBER WILL BE RE-BUILT THE NEXT TIME BUILD IS * 00003500* INVOKED. * 00003600* * 00003700* IF YOU DON'T WANT A COMPILER LISTING, CHANGE THE DDNAME=SYSPRINT * 00003800* TO AN IOTYPE=W AND REMOVE THE UNNECESSARY PARAMETERS. * 00003900* * 00004000* THE PL/I COMPILER GIVE OUT A NUMBER OF WARNINGS OFTEN RESULTING * 00004100* IN A RETURN CODE OF 4. YOU MIGHT WANT TO ADJUST YOUR GOODRC=0 TO * 00004200* GOODRC=4 TO ACCOUNT FOR THIS. * 00004300* * 00004400*********************************************************************** 00004500* CHANGE ACTIVITY: * 00004600* * 00004700* * 00004800*********************************************************************** 00004900

FLMLANGL LANG=PLIO,VERSION=PLIOV4.0 00005000* 00005100* PARSER TRANSLATOR 00005200* 00005300

FLMTRNSL CALLNAM='SCLM PL/I PARSE', C00005400FUNCTN=PARSE, C00005500COMPILE=FLMLPGEN, C00005600



PORDER=1, C00005700OPTIONS=(SOURCEDD=SOURCE, C00005800STATINFO=@@FLMSTP, C00005900LISTINFO=@@FLMLIS, C00006000LISTSIZE=@@FLMSIZ, C00006100LANG=I) 00006200


* 00006600* BUILD TRANSLATOR(S) 00006700* 00006800* --PL/I OPTIMIZER INTERFACE-- 00006900

FLMTRNSL CALLNAM='PL/I OPTIMIZER', C00007000FUNCTN=BUILD, C00007100COMPILE=IEL0AA, C00007200DSNAME=PLI.V2R3M0.PLICOMP, @@C00007300VERSION=4.0, C00007400GOODRC=4, @@C00007500PORDER=1, C00007600OPTIONS=(FLAG(I),MACRO, @@C00007700MAP,NUM,OBJECT,OFFSET,OPT(2),OPTIONS,SOURCE,XREF) @@ 00007800

* 00007900* DDNAME ALLOCATIONS 00008000* 00008100FLMALLOC IOTYPE=O,DDNAME=SYSLIN,KEYREF=OBJ,RECNUM=5000,DFLTTYP=OBJ 00008200FLMALLOC IOTYPE=I,DDNAME=SYSLIB,KEYREF=SINC 00008300FLMALLOC IOTYPE=W,DDNAME=SYSUT1,RECNUM=5000 00008400FLMALLOC IOTYPE=S,DDNAME=SYSCIN,KEYREF=SINC,RECNUM=2000 00008500FLMALLOC IOTYPE=A,DDNAME=SYSIN 00008600FLMCPYLB NULLFILE 00008700


FLMALLOC IOTYPE=O,DDNAME=SYSPRINT,KEYREF=LIST,DFLTTYP=LIST, C00009000PRINT=Y,RECNUM=5000 00009100



F@AD2 for Assembler H with DB2

*********************************************************************** 00010000* FLM@AD2 - ASMH/DB2 PREPROCESS AND ASSEMBLE * 00020000* * 00030000*@@*****************************************************************@@* 00040000*@@ Modifications for ITSC Migration Project: @@* 00050000*@@ -- FLMSYSLB/FLMCPYLB DCB.V3R3M0.CSPBD2 not used (no CSP) @@* 00060000*@@ -- GOODRC=0 --> GOODRC=4 @@* 00070000*@@ -- PARMKWD parameter added to build translator(s) @@* 00080000

Figure 72 (Part 1 of 4). Language Definition F@AD2 for Assembler H with DB2


*@@ -- Assembler options customized (RENT not specified) @@* 00090000*@@ @@* 00100000********************** GENERAL NOTES ******************************** 00110000* * 00120000* THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A * 00130000* REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE * 00140000* DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. * 00150000* * 00160000*********************************************************************** 00170000* * 00180000* Change activity = * 00190000* Pn = Reason Release Date Origin Comment * 00200000* -- -------- -------- ------ ------ : ------------------- * 00210000* $L0 = OY29671 M320 900730 432273 : SCLM CSP/DB2 SPE * 00220000* * 00230000* OY39985 - 910219 - DB2 BUILD DOES UNNECCESSARY STEPS. CHANGED * 00240000* FLMALLOC FOR SYSPRINT DD. ADDED CALLMETH=LINK * 00250000* TO FLMTRNSL OPTIONS. GT4045 -AAB * 00260000*********************************************************************** 00270000ASMDB2 FLMSYSLB SYS1.MACLIB 00280000* FLMSYSLB DCB.V3R3M0.CSPDB2 @@ 00290000* 00300000

FLMLANGL LANG=ASMDB2 00310000* 00320000* PARSER TRANSLATOR 00330000* 00340000

FLMTRNSL CALLNAM='SCLM ASM H PARSE', C00350000FUNCTN=PARSE, C00360000COMPILE=FLMLPGEN, C00370000PORDER=1, C00380000OPTIONS=(SOURCEDD=SOURCE, C00390000STATINFO=@@FLMSTP, C00400000LISTINFO=@@FLMLIS, C00410000LISTSIZE=@@FLMSIZ, C00420000LANG=A) *** THIS IS ASSEMBLER ONLY *** 00430000


* 00470000* BUILD TRANSLATORS 00480000* 00490000* --DB2 PREPROCESSOR INTERFACE-- 00500000

FLMTRNSL CALLNAM='ASMDB2 PREPROC', C00510000FUNCTN=BUILD, C00520000COMPILE=DSNHPC, C00530000VERSION=1.0, C00540000GOODRC=4, C00550000PORDER=3, C00560000CALLMETH=LINK, C00570000PARMKWD=PARM0, @@C00580000OPTIONS=(HOST(ASM)) 00590000

* 1 -- N/A -- 00600000FLMALLOC IOTYPE=N 00610000


* 3 -- N/A -- 00640000



FLMALLOC IOTYPE=N 00650000* 4 -- SYSLIB -- 00660000

FLMALLOC IOTYPE=I,KEYREF=SINC 00670000* 5 -- SYSIN -- 00680000

FLMALLOC IOTYPE=S,KEYREF=SINC,RECFM=FB,LRECL=80, C00690000RECNUM=2000 00700000

* 6 -- SYSPRINT -- 00710000******* The following lines deleted for APAR OY39985 ****************** 00720000*** FLMALLOC IOTYPE=O,KEYREF=OUT2,RECFM=FBA,LRECL=121, *** 00730000*** RECNUM=9000,PRINT=I,DFLTTYP=LIST *** 00740000******* The preceding lines deleted for APAR OY39985 ****************** 00750000******* The following lines added for APAR OY39985 ******************** 00760000

FLMALLOC IOTYPE=W,RECFM=FBA,LRECL=121, C00770000RECNUM=9000,PRINT=I 00780000

******* The preceding lines added for APAR OY39985 ******************** 00790000* 7 -- N/A -- 00800000

FLMALLOC IOTYPE=N 00810000* 8 -- SYSUT1 -- 00820000

FLMALLOC IOTYPE=W,RECFM=FB,LRECL=800,RECNUM=9000 00830000* 9 -- SYSUT2 -- 00840000

FLMALLOC IOTYPE=W,RECFM=FB,LRECL=800,RECNUM=9000 00850000* 10 -- SYSUT3 -- 00860000

FLMALLOC IOTYPE=W,RECFM=FB,LRECL=800,RECNUM=9000 00870000* 11 -- N/A -- 00880000

FLMALLOC IOTYPE=N 00890000* 12 -- SYSTERM -- 00900000

FLMALLOC IOTYPE=A 00910000FLMCPYLB NULLFILE 00920000


* 14 -- SYSCIN -- 00950000FLMALLOC IOTYPE=W,RECFM=FB,LRECL=80, C00960000

RECNUM=9000,DDNAME=SYSCIN 00970000* 15 -- N/A -- 00980000

FLMALLOC IOTYPE=N 00990000* 16 -- DBRMLIB-- 01000000

FLMALLOC IOTYPE=P,DDNAME=DBRMLIB,MEMBER=@@FLMONM, C01010000DFLTTYP=DBRM,KEYREF=OUT1, C01020000RECFM=FB,LRECL=80,RECNUM=5000,DIRBLKS=1 01030000

* 01040000* --ASSEMBLER 'H' INTERFACE-- 01050000

FLMTRNSL CALLNAM='ASMDB2 ASSEM', C01060000FUNCTN=BUILD, C01070000COMPILE=IEV90, C01080000GOODRC=4, @@C01090000PORDER=3, C01100000PARMKWD=PARM1, @@C01110000OPTIONS=(XREF(SHORT), @@C01120000NODECK,OBJECT) @@ 01130000

* 1 --SYSLIN-- 01140000FLMALLOC IOTYPE=O,KEYREF=OBJ,RECFM=FB,LRECL=80, C01150000

RECNUM=9000,DFLTTYP=OBJ 01160000* 2 --N/A-- 01170000

FLMALLOC IOTYPE=N 01180000* 3 --N/A-- 01190000

FLMALLOC IOTYPE=N 01200000



* 4 --SYSLIB-- 01210000FLMALLOC IOTYPE=I,KEYREF=SINC 01220000FLMCPYLB SYS1.MACLIB 01230000

* FLMCPYLB DCB.V3R3M0.CSPDB2 @@ 01240000* 5 --SYSIN-- 01250000

FLMALLOC IOTYPE=U,DDNAME=SYSCIN 01260000* 6 --SYSPRINT-- 01270000

FLMALLOC IOTYPE=O,KEYREF=LIST,RECFM=FBA,LRECL=121, C01280000RECNUM=20000,PRINT=I,DFLTTYP=LIST 01290000

* 7 --SYSPUNCH-- 01300000FLMALLOC IOTYPE=A 01310000FLMCPYLB NULLFILE 01320000

* 8 --SYSUT1-- 01330000FLMALLOC IOTYPE=W,RECFM=FB,LRECL=80,RECNUM=15000 01340000

* 9 --SYSTERM-- 01350000FLMALLOC IOTYPE=A 01360000FLMCPYLB NULLFILE 01370000



F@SCMD for DB2 DDL Subcommands

*********************************************************************** 00000100* UNTRANSLATED TEXT LANGUAGE DEFINITION FOR SCLM * 00000200* * 00000300*@@*****************************************************************@@* 00000400*@@ Modifications for ITSC Migration Project (FLM@TEXT): @@* 00000500*@@ -- FLMLANGL und CALLNAM modified for SCMD @@* 00000600*@@ (DB2 subcommands for generation of DDL) @@* 00000700*@@ @@* 00000800********************** GENERAL NOTES ******************************** 00000900* * 00001000* THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A * 00001100* REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE * 00001200* DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. * 00001300* * 00001400*********************************************************************** 00001500* * 00001600* CUSTOMIZATION IS NOT REQUIRED. * 00001700*********************************************************************** 00001800* CHANGE ACTIVITY: * 00001900* * 00002000* * 00002100*********************************************************************** 00002200

FLMLANGL LANG=SCMD,VERSION=V1.0 @@ 00002300* 00002400

Figure 73 (Part 1 of 2). Language Definition F@SCMD for DB2 DDL Subcommands


* PARSER TRANSLATOR 00002500* 00002600

FLMTRNSL CALLNAM='SCLM SCMD PARSE', @@C00002700FUNCTN=PARSE, C00002800COMPILE=FLMLPGEN, C00002900PORDER=1, C00003000OPTIONS=(SOURCEDD=SOURCE, C00003100STATINFO=@@FLMSTP, C00003200LISTINFO=@@FLMLIS, C00003300LISTSIZE=@@FLMSIZ, C00003400LANG=T) 00003500


* 00003900* BUILD TRANSLATOR(S) 00004000* 00004100* 5665-402 (C) COPYRIGHT IBM CORP 1980, 1989 00004200

Figure 73 (Part 2 of 2). Language Definition F@SCMD for DB2 DDL Subcommands

F@PANELS for ISPF Panels

*********************************************************************** 00000100* UNTRANSLATED TEXT LANGUAGE DEFINITION FOR SCLM * 00000200* * 00000300*@@*****************************************************************@@* 00000400*@@ Modifications for ITSC Migration Project (FLM@TEXT): @@* 00000500*@@ -- FLMLANGL und CALLNAM modified for PANELS @@* 00000600*@@ @@* 00000700********************** GENERAL NOTES ******************************** 00000800* * 00000900* THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A * 00001000* REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE * 00001100* DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. * 00001200* * 00001300*********************************************************************** 00001400* * 00001500* CUSTOMIZATION IS NOT REQUIRED. * 00001600*********************************************************************** 00001700* CHANGE ACTIVITY: * 00001800* * 00001900* * 00002000*********************************************************************** 00002100

FLMLANGL LANG=PANELS,VERSION=V1.0 @@ 00002200* 00002300* PARSER TRANSLATOR 00002400

Figure 74 (Part 1 of 2). Language Definition F@PANELS for ISPF Panels


* 00002500FLMTRNSL CALLNAM='SCLM PANELS PARSE', @@C00002600

FUNCTN=PARSE, C00002700COMPILE=FLMLPGEN, C00002800PORDER=1, C00002900OPTIONS=(SOURCEDD=SOURCE, C00003000STATINFO=@@FLMSTP, C00003100LISTINFO=@@FLMLIS, C00003200LISTSIZE=@@FLMSIZ, C00003300LANG=T) 00003400



Figure 74 (Part 2 of 2). Language Definition F@PANELS for ISPF Panels

F@@SKEL for ISPF Skeletons

*@@*****************************************************************@@* 00010000*@@ LANGUAGE DEFINITION FOR SKELETONS (PARSE ONLY) @@* 00020000*@@ (WITH SKEL PARSER FROM SCLM 3.4 GUIDE & MANUAL) @@* 00030000*@@*****************************************************************@@* 00040000

FLMLANGL LANG=SKELS,VERSION=V1.0,BUFSIZE=100 00050000* 00060000* PARSER TRANSLATOR 00070000* 00080000

FLMTRNSL CALLNAM='SCLM SKEL PARSER', C00090000FUNCTN=PARSE, C00100000COMPILE=PSKELS, C00110000DSNAME=SCLM3.RESI.LOAD, C00120000PORDER=1, C00130000GOODRC=0, C00140000VERSION-V1R1M0, C00150000OPTIONS='/@@FLMSTP,@@FLMLIS,@@FLMSIZ,' 00160000

* (* SOURCE *) 00170000FLMALLOC IOTYPE=A,DDNAME=SSOURCE 00180000FLMCPYLB @@FLMDSN(@@FLMMBR) 00190000

* (* LISTING *) 00200000FLMALLOC IOTYPE=W,DDNAME=ERROR, C00210000

RECFM=VBA,LRECL=133,RECNUM=6000,PRINT=Y 00220000* (* LISTING *) 00230000

FLMALLOC IOTYPE=W,DDNAME=SYSPRINT, C00240000RECFM=VBA,LRECL=133,RECNUM=6000,PRINT=Y 00250000

* 00260000

Figure 75. Language Definition F@@SKEL for ISPF Skeletons. For information about the parser, referto SCLM Guide and Reference, SC34-4254. The parser looks for embedded skeletons andstores the names for these included members in the accounting file.


F@MSGS for ISPF Messages

*********************************************************************** 00000100* UNTRANSLATED TEXT LANGUAGE DEFINITION FOR SCLM * 00000200* * 00000300*@@*****************************************************************@@* 00000400*@@ Modifications for ITSC Migration Project (FLM@TEXT): @@* 00000500*@@ -- FLMLANGL und CALLNAM modified for MSGS @@* 00000600*@@ @@* 00000700********************** GENERAL NOTES ******************************** 00000800* * 00000900* THIS LANGUAGE DEFINITION IS AN EXAMPLE THAT CAN SERVE AS A * 00001000* REFERENCE IN THE CONSTRUCTION AND CUSTOMIZATION OF LANGUAGE * 00001100* DEFINITIONS FOR A PARTICULAR APPLICATION AND ENVIRONMENT. * 00001200* * 00001300*********************************************************************** 00001400* * 00001500* CUSTOMIZATION IS NOT REQUIRED. * 00001600*********************************************************************** 00001700* CHANGE ACTIVITY: * 00001800* * 00001900* * 00002000*********************************************************************** 00002100

FLMLANGL LANG=MSGS,VERSION=V1.0 @@ 00002200* 00002300* PARSER TRANSLATOR 00002400* 00002500

FLMTRNSL CALLNAM='SCLM MSGS PARSE', @@C00002600FUNCTN=PARSE, C00002700COMPILE=FLMLPGEN, C00002800PORDER=1, C00002900OPTIONS=(SOURCEDD=SOURCE, C00003000STATINFO=@@FLMSTP, C00003100LISTINFO=@@FLMLIS, C00003200LISTSIZE=@@FLMSIZ, C00003300LANG=T) 00003400



Figure 76. Language Definition F@MSGS for ISPF Messages


Appendix D. Generation of Architecture DefinitionsArchitecture definitions are an important concept in SCLM, and as part of the migration youmight have to create many new architecture definition members. We used tools to automatethe creation of architecture definitions, and this appendix describes our tools.

LEC and CC Architecture DefinitionsWe developed a tool to create LEC and CC architecture definitions. The tool consists of thefollowing modules:

REXX procedure MIGR0010ISPF panel MIGP0010ISPF help panel MIGH0010ISPF skeletons MIGS0010 and MIGS0011.

The tool is started in a TSO/ISPF environment by entering: TSO %MIGR0010. After the toolis started, it prompts you for the input and output data set names with panel MIGP0010 (referto Figure 77 on page 124).

The accompanying help panel MIGH0010 explains the format of the input record (refer toFigure 78 on page 124). A maximum of 180 bytes of the input record are interpreted. If therecords are shorter, they will be padded with blanks. Sample input and output files and thenaming conventions for architecture definitions used in our project are shown in “CreatingLEC and CC Architecture Definitions” on page 44.

For each input record an LEC architecture definition member is created. The LEC membername is the program name. If the input record contains compiler options, a CC member iscreated in addition. The CC member name is “C ” plus the first seven characters of theprogram name. If a CC member is to be created for a program with an eight-digit name, theCC member name is truncated to eight characters, and a warning message is issued.

The REXX procedure MIGR0010 is kept simple; no extended error handling is provided.


à ðMIGP0010 ------------+- Create SCLM ARCHDEF members -+-----------------------===> +---------------------------------+ 93/03/18 17:58

Input data set (Sequential data set or PDS with member specification),which contains the formatted module information:

INPUT DSNAME ===> SCLM3.STADE5.DATA160(MZI$COB)...............

Output data set (must be a partitioned dataset), where the ARCHDEFmembers will be created:

OUTPUT DSNAME ===> SCLM3.MIG1.ARCHDEF..........................

press HELP for info, ENTER to execute, END to cancel function.

á ñ

Figure 77. ISPF Panel MIGP0010. Data set names for input and output must be specified.

à ðMIGH0010 ------------+- Create SCLM ARCHDEF members -+-----------------------===> +-----------Help Info-------------+ 93/03/18 18:28

Required format of input record:

col. 01 - 08: program name (same name for source and loadassumed, should be only 7 char.)

col. 11 - 18: SCLM type (3rd qualifier of PDS, e.g. COBOL, ASM)assumed, should be only 7 char.)

(*) col. 21 - 60: module-specific compiler options to overide defaults(separated by commas, no intervening blanks)

(*) col. 61 -100: module-specific linkage options to overide defaults(separated by commas, no intervening blanks)

(*) col.101 -180: names of (max. 10) modules, that have to be linkedto the program (starting incols. 101/109/117/125/133/141/149/157/165/173)

(*) = optional

Output data set for ARCHDEF members should have LRECL=80.

LEC archdefs will be created with member name = program nameCC archdefs will be created with member name = C + program name

á ñ

Figure 78. ISPF Help Panel MIGH0010. This help panel explains the required record layout for theinput file.

Figure 79 on page 125 through Figure 83 on page 129 show the listings of all modulesbelonging to this tool.


/***** REXX ***********************************************************/00010000/* PURPOSE.....: CREATE LEC (AND CC) ARCHDEF FROM INPUT LIST */00020000/* DATE WRITTEN: 03/03/93-FITZ */00030001/**********************************************************************/00040000/* TRACE R */ 00050002/* ------------------------------------------------------------------ */00060000ADDRESS ISPEXEC 00070000"DISPLAY PANEL(MIGP0010)" 00080000IF RC = 0 THEN DO 00090000

LENAME = "LE370" /* NAME OF TRANSLATOR FOR LINK EDIT */00100000INPNAME = "'"INPNAME"'" 00110000OUTNAME = "'"OUTNAME"'" 00120000ADDRESS TSO 00130000"ALLOC FILE(INPFILE) DATASET("INPNAME") SHR REUSE" 00140000"ALLOC FILE(ISPFILE) DATASET("OUTNAME") SHR REUSE" 00150000MOREINP = 1 00160000DO WHILE MOREINP = 1 00170000

ADDRESS TSO 00180000"EXECIO 1 DISKR INPFILE" 00190000IF RC ¬= 0 THEN DO 00200000

MOREINP = 0 00210000END 00220000ELSE DO 00230000

PULL RECORD /* MAX. LRECL=180 EXPECTED */00240009PGMNAME = SUBSTR(RECORD,1,8) 00250000PGMTYPE = SUBSTR(RECORD,11,8) 00260000LECNAME = PGMNAME /* LEC MBR = SOURCE NAME */ 00270009CCPARM = SUBSTR(RECORD,21,40) 00290001LEPARM = SUBSTR(RECORD,61,40) /* NON-DEFAULT COMP. OPT. */ 00291009ICPARM = SUBSTR(RECORD,101,80) /* FOR MAX. 10 STAT. LKED.*/ 00291109ADDRESS ISPEXEC 00292004

/* CREATE CC ARCHDEF ONLY IF COMPILER OPTION(S) SUPPLIED */ 00293005IF CCPARM ¬= ' ' THEN DO 00360001

PGMNAM7 = SUBSTR(RECORD,1,7) 00360101CCNAME = "C"PGMNAM7 00360201IF SUBSTR(RECORD,8,1) ¬= ' ' THEN DO 00360301

T1 = "*** CC ARCHDEF NAME FOR PGM" 00360401T2 = "TRUNCATED TO" 00360501T3 = "***" 00360601SAY T1 PGMNAME T2 CCNAME T3 00360701

END 00360801"FTOPEN" 00370000"FTINCL MIGS0011" 00380000"FTCLOSE NAME("CCNAME")" 00390000

END 00400000/* EXTRACT MODULES FOR STATIC LINK, IF ANY (MAX. 10): */ 00401008

IF ICPARM ¬= ' ' THEN DO 00401107ICPAR0 = SUBSTR(ICPARM,01,8) 00401208ICPAR1 = SUBSTR(ICPARM,09,8) 00401308ICPAR2 = SUBSTR(ICPARM,17,8) 00401408ICPAR3 = SUBSTR(ICPARM,25,8) 00401508ICPAR4 = SUBSTR(ICPARM,33,8) 00401608ICPAR5 = SUBSTR(ICPARM,41,8) 00401708ICPAR6 = SUBSTR(ICPARM,49,8) 00401808ICPAR7 = SUBSTR(ICPARM,57,8) 00401908ICPAR8 = SUBSTR(ICPARM,65,8) 00402008ICPAR9 = SUBSTR(ICPARM,73,8) 00402108

END 00402207


Appendix D. Generation of Architecture Definitions 125

/* CREATE LEC ARCHDEF FOR MEMBER FROM EACH INPUT RECORD */ 00402308"FTOPEN" 00402403"FTINCL MIGS0010" 00403003"FTCLOSE NAME("LECNAME")" 00404003

END 00410000END 00420000ADDRESS TSO 00430000"EXECIO 0 DISKR INPFILE (FINIS" 00440000"FREE FILE(INPFILE)" 00450000"FREE FILE(ISPFILE)" 00460000

END 00470000/* ------------------------------------------------------------------ */00480000EXIT 00490000



/**********************************************************************//* INPUT PANEL TO SPECIFY INPUT AND OUTPUT DSNAMES OF PDSS FOR */00020000/* CREATING LEC (AND CC) ARCHDEF FROM INPUT LIST */00020000/* WITH REXX MIGR0010 */00020000/* DATE WRITTEN: 03/03/93-FITZ */00030000/**********************************************************************/)BODY$MIGP0010 ------------+-% Create SCLM ARCHDEF members $-+-----------------------%===>_ZCMD $+---------------------------------+ <ZDATE <ZTIME$$$Input data set (Sequential data set or PDS with member specification),$which contains the formatted module information:$$ INPUT DSNAME%===>#INPNAME $$$$Output data set (must be a partitioned dataset), where the ARCHDEF$members will be created:$$OUTPUT DSNAME%===>#OUTNAME $$$$$$press HELP for info, ENTER to execute, END to cancel function.)INIT /****************************************************************/

&ZCMD = ' '.CURSOR = INPNAME.HELP = MIGH0010

)PROC /****************************************************************/VER(&INPNAME DSNAME)VER(&OUTNAME DSNAME)VPUT (INPNAME OUTNAME) PROFILE

)END

Figure 80. ISPF Panel MIGP0010



/**********************************************************************//* HELP PANEL FOR MIGP0010 */00020000/* DATE WRITTEN: 03/03/93-FITZ */00030000/**********************************************************************/)BODY$MIGH0010 ------------+-% Create SCLM ARCHDEF members $-+-----------------------%===>_ZCMD $+-----------Help Info-------------+ <ZDATE <ZTIME$$Required format of input record:$$ col. 01 - 08: program name (same name for source and load$ assumed, should be only 7 char.)$ col. 11 - 18: SCLM type (3rd qualifier of PDS, e.g. COBOL, ASM)$ assumed, should be only 7 char.)$ (*) col. 21 - 60: module-specific compiler options to overide defaults$ (separated by commas, no intervening blanks)$ (*) col. 61 -100: module-specific linkage options to overide defaults$ (separated by commas, no intervening blanks)$ (*) col.101 -180: names of (max. 10) modules, that have to be linked$ to the program (starting in$ cols. 101/109/117/125/133/141/149/157/165/173)$ (*) = optional$$Output data set for ARCHDEF members should have LRECL=80.$$ LEC archdefs will be created with member name = program name$ CC archdefs will be created with member name = C + program name$)INIT /****************************************************************/

&ZCMD = ' ')PROC /****************************************************************/)END

Figure 81. ISPF Help Panel MIGH0010

)CM *******************************************************************)CM SKEL FOR LEC ARCHDEF MEMBER)CM DATE WRITTEN: 03/03/93-FITZ)CM ******************************************************************** LEC ARCHDEF FOR PGM &PGMNAME)TB 9 18 41LKED!&LENAME! !* TRANSLATOR FOR LINK EDITLOAD!&PGMNAME!LOAD!* LOAD MODULE

Figure 82 (Part 1 of 2). ISPF Skeleton MIGS0010


LMAP!&PGMNAME!LMAP!* LINKAGE EDITOR OUTPUT)CM ..........................IF NO CC ARCHDEF TO BE GENERATED:)SEL &CCPARM = &ZINCLD!&PGMNAME!&PGMTYPE!* SOURCE MODULE)ENDSEL)CM ..........................IF CC ARCHDEF GENERATED, TOO:)SEL &CCPARM NE &ZINCL!&CCNAME!ARCHDEF!* CC ARCHDEF MEMBER)ENDSEL)CM -------------------------------------------------------------------)CM ..........................IF PARM OPTIONS REQUIRED:)SEL &LEPARM NE &ZPARM &LEPARM)ENDSEL)CM -------------------------------------------------------------------)CM ..........................IF OTHER MODULES ARE STATIC LINKED:)SEL &ICPARM NE &Z)SEL &ICPAR0 NE &ZINCL!&ICPAR0!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)SEL &ICPAR1 NE &ZINCL!&ICPAR1!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)SEL &ICPAR2 NE &ZINCL!&ICPAR2!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)SEL &ICPAR3 NE &ZINCL!&ICPAR3!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)SEL &ICPAR4 NE &ZINCL!&ICPAR4!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)SEL &ICPAR5 NE &ZINCL!&ICPAR5!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)SEL &ICPAR6 NE &ZINCL!&ICPAR6!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)SEL &ICPAR7 NE &ZINCL!&ICPAR7!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)SEL &ICPAR8 NE &ZINCL!&ICPAR8!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)SEL &ICPAR9 NE &ZINCL!&ICPAR9!ARCHDEF!* STATIC LINKED MODULE)ENDSEL)ENDSEL)CM *******************************************************************

Figure 82 (Part 2 of 2). ISPF Skeleton MIGS0010


)CM *******************************************************************)CM SKEL FOR CC ARCHDEF MEMBER)CM DATE WRITTEN: 03/03/93-FITZ)CM ******************************************************************** CC ARCHDEF FOR PGM &PGMNAME)TB 9 18 41OBJ!&PGMNAME!OBJ!* OBJECT MODULELIST!&PGMNAME!LIST!* COMPILER LISTINGSINC!&PGMNAME!&PGMTYPE!* SOURCE MODULE)CM ..........................IF COMPILER PARM OPTIONS REQUIRED:)CM ..........................BUILD TRANSLATOR MUST HAVE PARMKWD=PARM1)SEL &CCPARM NE &ZPARM1 &CCPARM)ENDSEL)CM *******************************************************************

Figure 83. ISPF Skeleton MIGS0011

HL Architecture Definitions and DB2CLISTsWhen a DB2 program is under SCLM control, a BUILD action against its related LECarchitecture definition calls the DB2 precompiler, compiler, and linkage editor. The DB2 planfor the program is bound by building the DB2CLIST member. An HL architecture definitionshould be created to synchronize these two build processes.

REXX program MIGR0050 provides an automatic way of creating the HL architecturedefinition and DB2CLIST members. “Creating LEC and CC Architecture Definitions” onpage 44 describes how MIGR0010 creates LEC architecture definitions. We can also useMIGR0050 to create HL architecture definitions that refer to other HL or LEC architecturedefinitions without a relationship to a DB2CLIST.

/* REXX */ 00010002/***********************************************************************00020002

MIGR0050 : 00030002Purpose : To create HL architecture definition member and 00040002

: DB2CLIST member. 00050002: 00060002

Description : This program creates HL ARCHDEF member or DB2CLIST 00070002: member or both. Inputs comes from user. Defaults 00080002: are coded into this program, and can be changed 00090002: (see init_default part). 00100002: 00110002

Inputs : Alternate project definition name 00111002: PDS High Level Qualifier name 00112002: Group name 00113002: HL architecture definition name 00114002: Architecture definition name (link with DB2) 00115002



: Other architecture definition name (no link with DB2)00116002: Y or N for generation of DB2CLIST 00117002: DB2 plan name 00118002: DB2 subsystem name 00119002: 00120002

Defaults parms: DB2 subsystem name 00130002: DB2 BIND parameters 00140002: 00150002

Date Written : 03/03/93-DUMAS Marc 00160002Modifications : ------------------- 00170002**************************************************************** 00180002Comments : N/A 00190002Instructions : Outputs are to be migrated after program run 00200002

: (SCLM migration). 00210002***********************************************************************/00220002trace "n" 00230002

/**************************/ 00240002/* MAIN PROC */ 00250002/**************************/ 00260002

00270002call init /* first initialization */ 00280002call init_default /* default initialization */ 00290002call input /* get all the input parameters */ 00300002call getok /* get go confirmation */ 00310002call hlaproc /* processing */ 00320002exit 00330002

/**************************/ 00340002/* INIT PROC */ 00350002/**************************/ 00360002

init: 00370002Proj = ' ' 00380002qual = ' ' 00390002Grp = ' ' 00400002hla = ' ' 00410002db2req = ' ' 00420002db2plan = ' ' 00430002dsys = ' ' 00440002appl1 = ' '; appl2 = ' '; appl3 = ' '; appl4 = ' '; appl5 = ' ' 00450002appl6 = ' '; appl7 = ' '; appl8 = ' '; appl9 = ' '; appl10 = ' ' 00460002mod1 = ' '; mod2 = ' '; mod3 = ' '; mod4 = ' '; mod5 = ' ' 00470002mod6 = ' '; mod7 = ' '; mod8 = ' '; mod9 = ' '; mod10 = ' ' 00480002return rc 00490002

/**************************/ 00500002/* INIT_DEFAULT PROC */ 00510002/**************************/ 00520002

init_default: 00530002dftdsys = 'DBP1' 00540002bparm1 = 'VALIDATE (BIND)' 00550002bparm2 = 'ISOLATION (CS)' 00560002bparm3 = ' ' 00570002bparm4 = ' ' 00580002bparm5 = ' ' 00590002bparm6 = ' ' 00600002bparm7 = ' ' 00601002bparm8 = ' ' 00602002bparm9 = ' ' 00603002



bparm10 = ' ' 00604002return rc 00605002

/**************************/ 00606002/* INPUT PROC */ 00607002/**************************/ 00608002

input: 00609002/*----- get project name -------------------*/ 00610002

do forever 00611002Call pmsg 1 /* ask for project name */ 00612002Parse upper pull proj 00613002if proj /= ' ' then leave 00614002

end 00615002/*----- get 1st qualifier name -------------*/ 00616002

Call pmsg 2 /* ask for 1st qualifier*/ 00617002Parse upper pull qual 00618002if qual = ' ' then qual=proj 00619002

/*----- get group name -------------------*/ 00620002Call pmsg 3 /* ask for group name */ 00630002Parse upper pull grp 00640002

/*----- get hl archdef name ---------------*/ 00650002Call pmsg 4 /* ask for HLA name */ 00660002Parse upper pull hla 00670002

/*----- get DB2 include appl names --------*/ 00680002Call pmsg 5 /* ask for appl names*/ 00690002Parse upper pull appl1 appl2 appl3 appl4 appl5 appl6, 00700002

appl7 appl8 appl9 appl10 00710002/*----- get non DB2 include app/mod names --*/ 00720002

Call pmsg 6 /* ask for non appl names*/ 00730002Parse upper pull mod1 mod2 mod3 mod4 mod5 mod6, 00740002

mod7 mod8 mod9 mod10 00750002/*----- DB2 plan association ?? ------------*/ 00760002

Call pmsg 7 /* ask for plan assoc */ 00770002Parse upper pull db2req 00780002if db2req = ' ' | db2req = 'NO' then db2req = 'N' 00790002

/*----- get db2 plan name -----------------*/ 00800002if db2req /= 'N' 00810002

then do 00820002Call pmsg 8 /* ask for DB2 plan name*/ 00830002Parse upper pull db2plan 00840002end 00850002

/*----- get db2 subsystem name ------------*/ 00860002if db2req /= 'N' 00870002

then do 00880002Call pmsg 9 /* ask for DB2 subsyst */ 00890002Parse upper pull dsys 00900002if dsys = ' ' then dsys = dftdsys 00910002end 00920002

return rc 00930002/**************************/ 00940002/* GETOK PROC */ 00950002/**************************/ 00960002

getok: 00970002Say '_______________________________________________' 00980002Say ' you are about to create the following : ' 00990002Say ' ' 01000002Say ' High Level Architecture ....:'hla 01010002



Say ' for project ................:'proj 01020002Say ' in data sets ...............:'qual'.'grp'.xxxx ' 01030002Say ' including DB2 applications .:'appl1 appl2 appl3 01040002Say ' :'appl4 appl5 appl6 01050002Say ' :'appl7 appl8 appl9 01060002Say ' :'appl10 01070002if mod1 /= ' ' 01080002

then do 01090002Say ' and non DB2 applications .:'mod1 mod2 mod3 01100002Say ' :'mod4 mod5 mod6 01110002Say ' :'mod7 mod8 mod9 01120002Say ' :'mod10 01130002

end 01140002if db2req /= 'N' then 01150002do 01160002Say ' DB2 clist with plan name ....:'db2plan 01170002Say ' DB2 sub-system name..........:'dsys 01180002end 01190002if db2req /= 'N' then 01200002do 01210002if bparm1 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm1 01220002if bparm2 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm2 01230002if bparm3 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm3 01240002if bparm4 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm4 01250002if bparm5 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm5 01260002if bparm6 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm6 01270002if bparm7 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm7 01280002if bparm8 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm8 01290002if bparm9 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm9 01300002if bparm10/= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm10 01301002end 01302002Say ' ' 01302102Say '_______________________________________________' 01302202Say ' type Y to confirm or A to abort ' 01302302Say '_______________________________________________' 01302402

parse upper pull confirm 01302502if confirm = 'Y' then return rc 01302602if confirm = 'A' then exit 01302702exit 01302802

/**************************/ 01302902/* HLAPROC PROC */ 01303002/**************************/ 01304002

hlaproc: 01305002/*----- create db2clist --*/ 01306002call ARCHOPE hla 01307002call clist 01308002/*----- create qual.group.ARCHDEF(hla)--*/ 01309002call ARCHOPE hla 01310002newstack 01320002count=0 01330002if appl1 /='' then queue 'INCL' appl1 'ARCHDEF' 01340002if appl2 /='' then queue 'INCL' appl2 'ARCHDEF' 01350002if appl3 /='' then queue 'INCL' appl3 'ARCHDEF' 01360002if appl4 /='' then queue 'INCL' appl4 'ARCHDEF' 01370002if appl5 /='' then queue 'INCL' appl5 'ARCHDEF' 01380002if appl6 /='' then queue 'INCL' appl6 'ARCHDEF' 01390002



if appl7 /='' then queue 'INCL' appl7 'ARCHDEF' 01400002if appl8 /='' then queue 'INCL' appl8 'ARCHDEF' 01410002if appl9 /='' then queue 'INCL' appl9 'ARCHDEF' 01420002if appl10/='' then queue 'INCL' appl10 'ARCHDEF' 01430002if mod1 /='' then queue 'INCL' mod1 'ARCHDEF' 01440002if mod2 /='' then queue 'INCL' mod2 'ARCHDEF' 01450002if mod3 /='' then queue 'INCL' mod3 'ARCHDEF' 01460002if mod4 /='' then queue 'INCL' mod4 'ARCHDEF' 01470002if mod5 /='' then queue 'INCL' mod5 'ARCHDEF' 01480002if mod6 /='' then queue 'INCL' mod6 'ARCHDEF' 01490002if mod7 /='' then queue 'INCL' mod7 'ARCHDEF' 01500002if mod8 /='' then queue 'INCL' mod8 'ARCHDEF' 01510002if mod9 /='' then queue 'INCL' mod9 'ARCHDEF' 01520002if mod10/='' then queue 'INCL' mod10 'ARCHDEF' 01530002if db2req/='N' then queue 'INCLD' hla 'DB2CLIST * BIND DB2 plan' 01540002call ARCHWR 01550002delstack 01560002call ENDMSG 01570002hla=' ' 01580002return rc 01590002

/**************************/ 01600002/* ARCHOPE PROC */ 01610002/**************************/ 01620002

archope: 01630002parse upper arg xmember 01640002

/*----open ARCHDEF member -------------start----------*/ 01650002arch = "'"||qual||'.'||grp||'.ARCHDEF('||xmember||")'" 01660002

"alloc da("arch") fi(archdef) shr reuse" 01670002Return rc 01680002

/**************************/ 01690002/* ARCHWR PROC */ 01700002/**************************/ 01710002

archwr: 01720002/*----write ARCHDEF member -------------start----------*/ 01730002do while queued() > 0 01740002

"execio 1 diskw archdef" 01750002end 01760002

"execio 0 diskw archdef (Finis" 01770002Return rc 01780002

/**************************/ 01790002/* PMSG PROC */ 01800002/**************************/ 01810002

pmsg: 01820002Parse upper arg $msg 01830002Select 01840002

When $msg=1 then 01850002$msg='Enter the alternate project definition name (non blank):' 01860002

When $msg=2 then 01870002$msg='Enter the first qualifier of the data sets where', 01880002

'you want the members to be created, if it is not', 01890002'the same as the project definition name:' 01900002

When $msg=3 then 01910002$msg='Enter the group name where you want to create members:' 01920002

When $msg=4 then 01930002$msg='Enter the HL ARCHDEF member name:' 01940002

When $msg=5 then 01950002



$msg='Enter the ARCHDEF member names related to DB2', 01960002'to include into HL ARCHDEF', 01970002'(max 10), separated with a blank:' 01980002

When $msg=6 then 01990002$msg='Enter the other ARCHDEF member names', 02000002

'(no relation with DB2) to include into HL ARCHDEF', 02010002'(max 10), separated with a blank:' 02020002

When $msg=7 then 02030002$msg='Do you want to create the DB2CLIST member ? (Y/N)' 02040002

When $msg=8 then 02050002$msg='Enter the DB2 plan name:' 02060002

When $msg=9 then 02070002$msg='Enter the DB2 subsystem name. Leave blank if you', 02080002

' want to use the default, which is 'dftdsys 02090002Otherwise $msg=0 02100002

End 02110002If $msg/=0 then say $msg 02120002Return rc 02130002

/**************************/ 02140002/* CLIST PROC */ 02150002/**************************/ 02160002

clist: 02170002call GETGRPS 02180002

/*----- create qual.group.DB2CLIST(hla)--*/ 02190002db2cl = "'"||qual||'.'||grp||'.DB2CLIST('||hla||")'" 02200002"alloc da("db2cl") fi(cl) shr reuse" 02210002

newstack 02220002queue'PROC 0 OPTION() GROUP() ' 02230002queue'CONTROL MSG FLUSH ' 02240002queue'/* -------------------------------------------------------*/' 02250002queue'/* DBRM PROXY DSN CLIST FOR DB2 PROGRAM */ ' 02260002queue'/* */ ' 02270002queue'/* INPUT PARAMETERS: */ ' 02280002queue'/* OPTION() BIND|FREE */ ' 02290002queue'/* GROUP() GROUP-NAME-FOR BIND OR FREE */ ' 02300002queue'/* */ ' 02310002queue'/* RETURN CODES: */ ' 02320002queue'/* 0 SUCCESS */ ' 02330002queue'/* 4 WARNING */ ' 02340002queue'/* 8 ERROR */ ' 02350002queue'/* 16 FATAL ERROR */ ' 02360002queue'/* 312 INVALID GROUP */ ' 02370002queue'/* 316 INVALID OPTION */ ' 02380002queue'/* ----------------------------------------------------*/ ' 02390002queue'/* INSTRUCTIONS FOR CUSTOMIZATION: */ ' 02400002queue'/* SPECIFY VARIABLES: */ ' 02410002queue'/* ----------------------------------------------------*/ ' 02420002queue'/* SPECIFY A DBRM INCLUDE STATEMENT FOR EACH DBRM: */ ' 02430002queue'/* */ ' 02440002/*----*/ 02450002if appl1 /=' ' then 02460002queue'/* %INCLUDE 'appl1' */ ' 02470002else 02480002queue'/* */ ' 02490002/*----*/ 02500002if appl2 /=' ' then 02510002



queue'/* %INCLUDE 'appl2' */ ' 02520002else 02530002queue'/* */ ' 02540002/*----*/ 02550002if appl3 /=' ' then 02560002queue'/* %INCLUDE 'appl3' */ ' 02570002else 02580002queue'/* */ ' 02590002/*----*/ 02600002if appl4 /=' ' then 02610002queue'/* %INCLUDE 'appl4' */ ' 02620002else 02630002queue'/* */ ' 02640002/*----*/ 02650002if appl5 /=' ' then 02660002queue'/* %INCLUDE 'appl5' */ ' 02670002else 02680002queue'/* */ ' 02690002/*----*/ 02700002if appl6 /=' ' then 02710002queue'/* %INCLUDE 'appl6' */ ' 02720002else 02730002queue'/* */ ' 02740002/*----*/ 02750002if appl7 /=' ' then 02760002queue'/* %INCLUDE 'appl7' */ ' 02770002else 02780002queue'/* */ ' 02790002/*----*/ 02800002if appl8 /=' ' then 02810002queue'/* %INCLUDE 'appl8' */ ' 02820002else 02830002queue'/* */ ' 02840002/*----*/ 02850002if appl9 /=' ' then 02860002queue'/* %INCLUDE 'appl9' */ ' 02870002else 02880002queue'/* */ ' 02890002/*----*/ 02900002if appl10/=' ' then 02910002queue'/* %INCLUDE 'appl10' */ ' 02920002else 02930002queue'/* */ ' 02940002/*----*/ 02950002queue'/* ----------------------------------------------------*/ ' 02960002queue'SET &RCODE = 0 ' 02970002queue'/* ----------------------------------------------------*/ ' 02980002queue'/* SPECIFY A DBRMS FOR BIND MEMBER LIST */ ' 02990002queue'/* ----------------------------------------------------*/ ' 03000002queue'SET &DBRMS = &STR('appl1','appl2','appl3','appl4', +' 03010002queue' 'appl5','appl6','appl7','appl8', +' 03020002queue' 'appl9','appl10') ' 03030002queue'/* -------------------------------------------------------*/' 03040002queue'/* SPECIFY PLAN NAME, BIND PARMS, AND SYSTEM */' 03050002queue'/* FOR EACH GROUP */' 03060002queue'/* -------------------------------------------------------*/' 03070002



queue'SELECT (&GROUP) ' 03080002i=1 03090002do until i=m 03100002call COMP g.i 03110002queue' WHEN ('||compout||') DO ' 03120002queue' SET &PLAN ='db2plan' ' 03130002queue' SET &SYS ='dsys' ' 03140002queue' SET &BPARM = &STR('bparm1' + ' 03150002queue' 'bparm2' + ' 03160002queue' 'bparm3' + ' 03170002queue' 'bparm4' + ' 03180002queue' 'bparm5' + ' 03190002queue' 'bparm6' + ' 03200002queue' 'bparm7' + ' 03210002queue' 'bparm8' + ' 03220002queue' 'bparm9' + ' 03230002queue' 'bparm10') ' 03240002queue' END ' 03250002i=i+1 03260002end 03270002queue' OTHERWISE SET &RCODE = 312 ' 03280002queue'END ' 03290002queue'/* -------------------------------------------------------*/' 03300002queue'/* INVOKE DSN COMMAND PROCESSOR TO BIND OR FREE */ ' 03310002queue'/* -------------------------------------------------------*/' 03320002queue'SET &ENDDSN = END ' 03330002queue'IF &RCODE = 0 THEN + ' 03340002queue' SELECT (&OPTION) ' 03350002queue' WHEN (BIND) DO ' 03360002queue' DSN SYSTEM(&SYS) ' 03370002queue' BIND PLAN(&PLAN) MEMBER(&DBRMS) &BPARM ' 03380002queue' &ENDDSN ' 03390002queue' SET &RCODE = &MAXCC ' 03400002queue' END ' 03410002queue' WHEN (FREE) DO ' 03420002queue' DSN SYSTEM(&SYS) ' 03430002queue' FREE PLAN(&PLAN) ' 03440002queue' &ENDDSN ' 03450002queue' SET &RCODE = &MAXCC ' 03460002queue' END ' 03470002queue' OTHERWISE SET &RCODE = 316 ' 03480002queue'END ' 03490002queue'EXIT CODE(&RCODE) ' 03500002

do while queued() > 0 03510002"execio 1 diskw cl" 03520002

end 03530002"execio 0 diskw cl (Finis" 03540002delstack 03550002return rc 03560002

/**************************/ 03570002/* GETGRPS PROC */ 03580002/**************************/ 03590002

getgrps: 03600002/*----open PROJDEFS member project ----start----------*/ 03610002projet= "'"||qual||'.PROJDEFS.SOURCE('||proj||")'" 03620002

"alloc da("projet") fi(pjt) shr reuse" 03630002



newstack 03640002g = 'g' 03650002i=1 03660002

do until rc/=0 03670002"execio 1 diskr pjt" 03680002if rc =0 then do 03690002

pull rec 03700002inter=pos('FLMGROUP',rec) 03710002if substr(rec,1,1) /='*' & inter /=0 then 03720002do 03730002

g.i=substr(rec,1,8) 03740002i=i+1 03750002

end 03760002end 03770002

end 03780002m=i 03790002delstack 03800002

return rc 03810002/**************************/ 03820002/* COMP PROC */ 03830002/**************************/ 03840002

comp: 03850002parse upper arg compin 03860002blank=pos(' ',compin) 03870002long = blank-1 03880002compout=substr(compin,1,long) 03890002return rc 03900002

/**************************/ 03910002/* ENDMSG PROC */ 03920002/**************************/ 03930002

endmsg: 03940002Say '_______________________________________________' 03950002Say ' Processing completed for application :'hla 03960002Say ' ' 03970002Say ' When the members have been created, you have to ' 03980002Say ' use the SCLM migrate function to the lowest level' 03990002Say ' of the project to let SCLM accounting file know ' 04000002Say ' about these members. ' 04010002Say '_______________________________________________' 04020002return rc 04 0002



Appendix E. Tools for Bulk Data MigrationThis appendix describes tools for bulk data migration and presents technical details aboutrequired changes to source modules from the CA-LIBRARIAN environment. The reasons forthose modifications are discussed in “Nonstandard Source Code” on page 52.

Changing Old COBOL COPY SyntaxFigure 85 lists the ISPF EDIT macro used for inserting missing periods in front of COPYstatements in COBOL programs (refer to “COBOL Copy Statements with Leading DataNames” on page 52). The general-purpose EDIT macro MIGE0000 (see Figure 50 onpage 91) allows you to apply macro MIGE0030 to all members in a PDS.

ISREDIT MACRO (SHOWCHG) 00010000/***============================================================== ***/00020000/*** PURPOSE.....: FOR COBOL PGMS WITH ANSI68 STANDARD ***/00030000/*** LEVEL NAME BEFORE COPY STMT WITHOUT '.' ***/00040000/*** '.' WILL BE INSERTED. ***/00050000/*** ==> COMPILER ERROR WILL OCCUR, IF SAME <== ***/00060000/*** ==> LEVEL INSIDE & OUTSIDE COPY BOOK ! <== ***/00070000/*** PARAMETER...: SHOWCHG = ALL: WRITE MSG FOR ALL CHANGED LINES ***/00080000/*** SUM: WRITE ONLY NO. OF CHANGED LINES ***/00090000/*** OTHERWISE NO OUTPUT ***/00100000/*** DATE WRITTEN: 03/10/93-FITZ ***/00110000/***============================================================== ***/00120000

SET CSUM = 0 00130000ISREDIT (MEMBER) = MEMBER 00140000ISREDIT NUMBER COBOL 00150000ISREDIT UNNUM 00160000ISREDIT BOUNDS 7 72 00170000ISREDIT FIND LAST P'=' 00180000ISREDIT (MLINE,MCOL) = CURSOR 00190000

/***-------------------------------------------------------------- ***/00200000/*** EXCLUDE ALL THAT CANNOT BE A COPY STATEMENT ***/00210000/*** IN DATA DIVISION ***/00220000/***-------------------------------------------------------------- ***/00230000

SET DLINE = 1 00240000

Figure 85 (Part 1 of 3). ISPF EDIT Macro MIGE0030


SET PLINE = &MLINE 00250000ISREDIT EXCLUDE ALL 00260000ISREDIT FIND ALL '*' 7 00270000ISREDIT FIND X FIRST 'DATA DIVISION' 00280000ISREDIT (FCOUNT) = FIND_COUNTS 00290000IF (&FCOUNT GT 0) THEN ISREDIT (DLINE,DCOL) = CURSOR 00300000ISREDIT LABEL &DLINE = .D 00310000ISREDIT FIND X FIRST 'PROCEDURE DIVISION' 00320000ISREDIT (FCOUNT) = FIND_COUNTS 00330000IF (&FCOUNT GT 0) THEN ISREDIT (PLINE,PCOL) = CURSOR 00340000ISREDIT LABEL &PLINE = .P 00350000ISREDIT FIND X ALL ' COPY ' .D .P 00360000ISREDIT EXCLUDE ALL '*' 7 00370000ISREDIT EXCLUDE FIRST 'DATA DIVISION' 00380000ISREDIT EXCLUDE FIRST 'PROCEDURE DIVISION' 00390000ISREDIT CURSOR = 1 1 00400000

/***-------------------------------------------------------------- ***/00410000/*** LOOP: CHANGE ' COPY ' TO '. COPY ' IF TEXT WITHOUT '.' ***/00420000/*** PRECEDES 'COPY' IN SAME NON-COMMENT LINE ***/00430000/***-------------------------------------------------------------- ***/00440000COP: ISREDIT FIND NX ' COPY ' 00450000

ISREDIT (FCOUNT) = FIND_COUNTS 00460000IF (&FCOUNT GT 0) THEN DO 00470000

ISREDIT (FLINE,FCOL) = CURSOR 00480000ISREDIT LABEL &FLINE = .F 00490000ISREDIT (OLINE) = LINE &FLINE 00500000ISREDIT FIND .F .F 7 &FCOL P'¬' FIRST 00510000ISREDIT (FCOUNT) = FIND_COUNTS 00520000IF (&FCOUNT GT 0) THEN DO 00530000

ISREDIT (ALINE,ACOL) = CURSOR 00540000ISREDIT FIND .F .F 7 &FCOL '.' LAST 00550000ISREDIT (FCOUNT) = FIND_COUNTS 00560000IF (&FCOUNT EQ 0) THEN DO 00570000

ISREDIT CHANGE .F .F &FCOL ' COPY' '. COPY' 00580000IF (&LASTCC NE 0) THEN DO 00590000

WRITE &STR(@@@ CHANGE ERROR IN &MEMBER LINE &FLINE @@@)00600000GOTO ENDX 00610000

END 00620000ISREDIT (NLINE) = LINE &FLINE 00630000IF (&SHOWCHG = ALL) THEN DO 00640000

WRITE &STR(** MEMBER &MEMBER LINE &FLINE (OLD/NEW):) 00650000WRITE &SUBSTR(1:72,&STR( )&OLINE) 00660000WRITE &SUBSTR(1:72,&STR( )&NLINE) 00670000

END 00680000SET CSUM = &EVAL(&CSUM + 1) 00690000

END 00700000END 00710000ISREDIT CURSOR = &FLINE 72 00720000GOTO COP 00730000

END 00740000/***-------------------------------------------------------------- ***/00750000

IF (&CSUM = 0) THEN ISREDIT CANCEL 00760000ELSE DO 00770000

IF ((&SHOWCHG = ALL) OR (&SHOWCHG = SUM)) THEN DO 00780000WRITE &STR(********** &CSUM LINES CHANGED IN MEMBER &MEMBER )00790000WRITE 00800000



END 00810000ISREDIT NUMBER COBOL 00820000ISREDIT END 00830000

END 00840000/***-------------------------------------------------------------- ***/00850000ENDX: EXIT 00860000/***============================================================== ***/00870000


Handling COPY Prefix Replacement in COBOL ProgramsThe basic rules governing COBOL COPY statements with a REPLACING clause inCA-LIBRARIAN and in COBOL standards are described in “COBOL Copy Statements withPrefix Replacement” on page 54. We decided to remove all REPLACING clauses and toadjust the program source statements referring to the data names affected. This sectionshows how we adjusted the CA-LIBRARIAN specific coding to COBOL standards and lists thetools we used to perform this part of the source code migration.

Application 1 contained only one COBOL program with COPY ... REPLACING statements toreplace data name prefixes, but we decided to develop a mostly automated procedure asthis particular problem potentially applies to many applications to be migrated after the pilotproject. You may want to automate this process even more if you have to migrate manyCOBOL applications that use COPY ... REPLACING statements. Our procedure is shown inFigure 86 on page 142:

1. Start with COBOL programs already corrected with MIGE0030 for missing periods inCOPY statement lines (refer to “COBOL Copy Statements with Leading Data Names” onpage 52 and “Changing Old COBOL COPY Syntax” on page 139). First you have to findwhere COPY ... REPLACING is used. You can use the ISPF Search-For utility and searchfor REPLACING in your COBOL source data set.

2. Run program MIGU003 for each COPY ... REPLACING statement. Input for programMIGU003 are the prefixes specified in the REPLACING clause of the COPY statementsand the text of the copy book. Output is an ISPF EDIT macro that corresponds to oneCOPY ... REPLACING statement and contains the CHANGE commands for the sourcecode of the program.

3. Apply EDIT macro MIGE0050 to the program source code. MIGE0050 requires twoparameters:

Name of the EDIT macro with the CHANGE commands created in the previous step

High-level data name to be used to qualify the data names. This high-level dataname usually precedes the COPY statement.

If no parameters are supplied, you will be prompted for input. MIGU0050 calls themacro with the CHANGE commands to modify the source code.

4. Remove the REPLACING clause from the COPY statement. This finishes the correctedCOBOL source program. Copy books remain unchanged.

Appendix E. Tools for Bulk Data Migration 141

Figure 86. Handling COPY Statements with REPLACING Clause: Overview. The following remarkspertain to the numbers in the figure:

(1) Programs already corrected for missing periods with MIGE0030(2) ISPF Search-For utility used to find all REPLACING clauses(3) The search result is not handled automatically(4) Input to program MIGU003 are copy book text and the strings from the replacing

clause(5) One EDIT macro for each REPLACING clause. Default name for the EDIT macro is

the copy book name. Macros may be deleted after use in (6).(6) Changes refer to one REPLACING clause at a time. The EDIT macro from (5) and the

high-level data name from (3) are used.(7) All statements using data names from the copy book are now modified to use the

original names from the copy book with additional qualification(8) The REPLACING clauses are deleted manually.


The actions performed on the source code for a sample program are shown in Figure 87 onpage 143 and Figure 88 on page 143.

A sample job to run MIGU003 is listed in Figure 89 on page 144. The source code forMIGU003 is listed in Figure 90 on page 144. ISPF EDIT macro MIGE0050 is listed inFigure 91 on page 153.

Old CA-LIBRARIAN COPY statement for copy book S92U905C:

01 PARM-OBUFF905 COPY S03U905C REPLACING SAWX- BY S92N-.

Adjusted COBOL COPY statement for S92U905C:(period inserted with MIGE0030, REPLACING clause removed):

*01 PARM-OBUFF905. COPY S03U905C REPLACING SAWX- BY S92N-.01 PARM-OBUFF905. COPY S03U905C.

Text of copy book S92U905C (remains unchanged):

05 SAWX-ST-KZ PIC X(01).88 SAWX-RUV-MASCH VALUE 'M'.88 SAWX-MASCH-RUV VALUE 'D'.

05 SAWX-DAT-RUV PIC S9(07).05 SAWX-FILLER REDEFINES SAWX-DAT-RUV.

10 SAWX-DAT-RUV-JH PIC S9(01).10 SAWX-DAT-RUV-JJ PIC S9(02).10 SAWX-DAT-RUV-MM PIC S9(02).10 SAWX-DAT-RUV-TT PIC S9(02).

05 SAWX-MASCH-DAT.10 SAWX-DAT-JJ PIC S9(02).10 SAWX-DAT-TTT PIC S9(03).

Figure 87. COPY Statements and Text for Copy Book S92U905C

Old program statements in CA-LIBRARIAN environment:

IF RETURN-CODE = 0 THENMOVE 'D' TO S92N-ST-KZMOVE ZWI-BUFF TO S92N-MASCH-DATCALL 'P03N905' USING PARM-OBUFF905

Adjusted program statements to match the adjusted COPY statement:

IF RETURN-CODE = 0 THENMOVE 'D' TO SAWX-ST-KZ IN PARM-OBUFF905MOVE ZWI-BUFF TO SAWX-MASCH-DAT IN PARM-OBUFF905CALL 'P03N905' USING PARM-OBUFF905

Figure 88. Sample Statements Referring to Data Names from Copy Book S92U905C


//....... JOB .........................,// ..............................//*============================================================//CREMACL PROC COPYDSN=,COPYNAME=,MACDSN=,MACNAME=&COPYNAME//E EXEC PGM=MIGU003//STEPLIB DD DISP=SHR,DSN=SCLM3.STADE5.LOAD// DD DISP=SHR,DSN=SCLM3.RESI.LOAD// DD DISP=SHR,DSN=COBOL.V1R3M2.COB2LIB//DDBOOK DD DISP=SHR,DSN=&COPYDSN(&COPYNAME)//DDMACRO DD DISP=OLD,DSN=&MACDSN(&MACNAME)//SYSOUT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*// PEND//*===========================================================*//* INPUT RECORD FORMAT (DDNAME DDPREF) FOR CREATING THE *//* EDIT MACRO TO TRANSFORM DATA NAMES IN A PROGRAM *//* THAT CONTAINED THE FOLLOWING LIBRARIAN COPY CLAUSE *//* "REPLACING AAA- BY BBB-": *//* AAA- IN COL. 01 *//* BBB- IN COL. 41 *//*=====================================V=====================*//S1 EXEC CREMACL,COPYNAME=S03U905C,// COPYDSN=SCLM3.MIG1.COBCOPY,MACDSN=SCLM3.STADE5.CLIST//DDPREF DD *SAWX- S92N-/*//*===========================================================*

Figure 89. Sample Job to Run Program MIGU003. SAWX- is the prefix in the S92U905C copy bookdata names; S92N- is the prefix previously used in the program source code.

000100*=================================================================00010000000200 IDENTIFICATION DIVISION. 00020000000300 PROGRAM-ID. MIGU003. 00030000000400*=================================================================00040000000500*** PURPOSE.....: *** 00050000000600*** UTILITY TO CREATE AN EDIT MACRO IN ORDER TO CHANGE *** 00060000000700*** A PROGRAM TOGETHER WITH REMOVAL OF A REPLACING CLAUSE *** 00070000000800*** FROM A COBOL COPY STATEMENT. *** 00080000000900*** THE PROGRAM USES THE INFO FROM THE REPLACING CLAUSE *** 00090000001000*** (IN A FORMATTED FORM) AND THE TEXT OF THE COPY BOOK *** 00100000001100*** AS INPUT. *** 00110000001200*** THE CREATED EDIT MACRO WILL HAVE THE PROPER CHANGE *** 00120000001300*** COMMANDS TO REPLACE THE USED NAMES FOR VARIABLES *** 00130000001400*** AFTER REPLACING BY THE ORIGINAL ONES FROM THE COPY *** 00140000001500*** BOOK (TOGETHER WITH AN OPTIONAL HIGH LEVEL QUALIFIER). *** 00150000001600*** *** 00160000

Figure 90 (Part 1 of 10). COBOL Program MIGU003


001700*** RETURN CODE: 0 = ALL OK *** 00170000001800*** 8 = I/O ERROR *** 00180000001900*** *** 00190000002000*** DATE WRITTEN: 03/12/93-FITZ *** 00200000002100*=================================================================00210000002200 ENVIRONMENT DIVISION. 00220000002300*=================================================================00230000002400 CONFIGURATION SECTION. 00240000002500 SOURCE-COMPUTER. IBM-9000. 00250000002600*-----------------------------------------------------------------00260000002700 INPUT-OUTPUT SECTION. 00270000002800*-----------------------------------------------------------------00280000002900 FILE-CONTROL. 00290000003000* 00300000003100*--- INPUT PREFIX NAMES 00310000003200* 00320000003300 SELECT PREF 00330000003400 ASSIGN TO DA-S-DDPREF 00340000003500 FILE STATUS IS IO-STATUS. 00350000003600* 00360000003700*--- INPUT COPY BOOK TEXT 00370000003800* 00380000003900 SELECT BOOK 00390000004000 ASSIGN TO DA-S-DDBOOK 00400000004100 FILE STATUS IS IO-STATUS. 00410000004200* 00420000004300*--- OUTPUT EDIT MACRO 00430000004400* 00440000004500 SELECT EDMAC 00450000004600 ASSIGN TO DA-S-DDMACRO 00460000004700 FILE STATUS IS IO-STATUS. 00470000004800* 00480000004900*-----------------------------------------------------------------00490000005000 EJECT 00500000005100*=================================================================00510000005200 DATA DIVISION. 00520000005300 FILE SECTION. 00530000005400*-----------------------------------------------------------------00540000005500* 00550000005600*--- INPUT PREFIX NAMES 00560000005700* 00570000005800 FD PREF 00580000005900 BLOCK CONTAINS 0 RECORDS 00590000006000 LABEL RECORD OMITTED. 00600000006100* 00610000006200 01 PREF-REC. 00620000006300 05 PREF-ORIG PIC X(32). 00630000006400 05 FILLER REDEFINES PREF-ORIG. 00640000006500 10 PREF-ORIG-I PIC X OCCURS 32. 00650000006600 05 FILLER PIC X(08). 00660000006700 05 PREF-REPL PIC X(32). 00670000006800 05 FILLER REDEFINES PREF-REPL. 00680000006900 10 PREF-REPL-I PIC X OCCURS 32. 00690000007000 05 FILLER PIC X(08). 00700000007100* 00710000007200*--- INPUT COPY BOOK TEXT 00720000



007300* 00730000007400 FD BOOK 00740000007500 BLOCK CONTAINS 0 RECORDS 00750000007600 LABEL RECORD OMITTED. 00760000007700* 00770000007800 01 BOOK-REC. 00780000007900 05 FILLER PIC X(06). 00790000008000 05 BOOK-TEXT PIC X(66). 00800000008100 05 FILLER REDEFINES BOOK-TEXT. 00810000008200 10 FILLER PIC X(01). 00820000008300 88 COMMENT VALUE '*'. 00830000008400 10 FILLER PIC X(65). 00840000008500 05 FILLER PIC X(08). 00850000008600* 00860000008700*--- OUTPUT EDIT MACRO 00870000008800* 00880000008900 FD EDMAC 00890000009000 BLOCK CONTAINS 0 RECORDS 00900000009100 LABEL RECORD OMITTED. 00910000009200* 00920000009300 01 EDMAC-REC. 00930000009400 05 EDMAC-STMT PIC X(72). 00940000009500 05 FILLER PIC X(08). 00950000009600* 00960000009700*-----------------------------------------------------------------00970000009800 EJECT 00980000009900*-----------------------------------------------------------------00990000010000 WORKING-STORAGE SECTION. 01000000010100*-----------------------------------------------------------------01010000010200* 01020000010300*--- IO STATUS FIELD AND TYPE 01030000010400* 01040000010500 01 IO-STATUS PIC X(02). 01050000010600 01 IO-TYP PIC X(06). 01060000010700* 01070000010800*--- END-OF-FILE - SWITCH: 01080000010900* 01090000011000 01 EOF-KZ PIC X. 01100000011100 88 NICHT-EOF VALUE SPACE. 01110000011200 88 EOF VALUE 'E'. 01120000011300* 01130000011400*--- WORK AREAS: 01140000011500* 01150000011600 01 VAR0 PIC X(80). 01160000011700 01 VAR1 PIC X(66). 01170000011800 01 VAR2 PIC X(66). 01180000011900 01 FILLER REDEFINES VAR2. 01190000012000 05 VAR2-I PIC X OCCURS 66. 01200000012100 01 I PIC S9(4) COMP. 01210000012200 01 ISTART PIC Z9. 01220000012300 01 L-VAR2-1 PIC S9(4) COMP. 01230000012400 01 L-PREF-ORIG PIC S9(4) COMP. 01240000012500 01 L-PREF-ORIG-1 PIC S9(4) COMP. 01250000012600 01 L-PREF-REPL-1 PIC S9(4) COMP. 01260000012700* 01270000012800*--- FIXED EDIT MACRO LINES 01280000



012900* 01290000013000 01 M1 PIC X(20) VALUE 01300000013100 'ISREDIT MACRO (QUAL)'. 01310000013200 01 MC. 01320000013300 05 FILLER PIC X(36) VALUE 01330000013400 '/***--------------------------------'. 01340000013500 05 FILLER PIC X(36) VALUE 01350000013600 '--------------------------------***/'. 01360000013700 01 MC0. 01370000013800 05 FILLER PIC X(36) VALUE 01380000013900 '/*** MAIN STRUCTURE NAME FOR QUALIF'. 01390000014000 05 FILLER PIC X(36) VALUE 01400000014100 'ICATION - IF REQUIRED: ---------***/'. 01410000014200 01 MC1. 01420000014300 05 FILLER PIC X(36) VALUE 01430000014400 '/*** ORIGINAL PREFIX IN COPY BOOK: '. 01440000014500 05 FILLER PIC X(36) VALUE 01450000014600 '--------------------------------***/'. 01460000014700 01 MC2. 01470000014800 05 FILLER PIC X(36) VALUE 01480000014900 '/*** PREFIX VIA REPLACING IN PGM: -'. 01490000015000 05 FILLER PIC X(36) VALUE 01500000015100 '--------------------------------***/'. 01510000015200 01 M2 PIC X(24) VALUE 01520000015300 ' SET QUAL = &STR(&QUAL)'. 01530000015400 01 M3 PIC X(40) VALUE 01540000015500 ' IF (&STR(&QUAL) = ) THEN SET INQUAL = '. 01550000015600 01 M4 PIC X(55) VALUE 01560000015700 ' ELSE SET INQUAL = &STR( IN &QUAL)'. 01570000015800 01 M5 PIC X(23) VALUE 01580000015900 ' ISREDIT BOUNDS 7 72'. 01590000016000 01 MI PIC X(27) VALUE 01600000016100 ' ISREDIT CHANGE ALL 7 72 +'. 01610000016200 01 MI1 PIC X(21) VALUE 01620000016300 ' ISREDIT CHANGE ALL '. 01630000016400 01 MI2 PIC X(05) VALUE 01640000016500 ' 72 +'. 01650000016600 01 ME PIC X(28) VALUE 01660000016700 ' ISREDIT LOCATE FIRST ERROR'. 01670000016800 01 MV PIC X(42) VALUE 01680000016900 ' ISPEXEC VPUT (REPLPREF ORIGPREF) SHARED'. 01690000017000 01 MX PIC X(04) VALUE 01700000017100 'EXIT'. 01710000017200* 01720000017300*-----------------------------------------------------------------01730000017400 EJECT 01740000017500*=================================================================01750000017600 PROCEDURE DIVISION. 01760000017700*=================================================================01770000017800 DECLARATIVES. 01780000017900*-----------------------------------------------------------------01790000018000* 01800000018100 PREFERR SECTION. 01810000018200 USE AFTER ERROR PROCEDURE ON PREF. 01820000018300 PREFERR-BEARB. 01830000018400 DISPLAY 'FILE "PREF", IO-TYP ' IO-TYP 01840000



018500 ', IO-STATUS ' IO-STATUS 01850000018600 MOVE 8 TO RETURN-CODE 01860000018700 STOP RUN. 01870000018800* 01880000018900 BOOKERR SECTION. 01890000019000 USE AFTER ERROR PROCEDURE ON BOOK. 01900000019100 BOOKERR-BEARB. 01910000019200 DISPLAY 'FILE "BOOK", IO-TYP ' IO-TYP 01920000019300 ', IO-STATUS ' IO-STATUS 01930000019400 MOVE 8 TO RETURN-CODE 01940000019500 STOP RUN. 01950000019600* 01960000019700* 01970000019800 EDMACERR SECTION. 01980000019900 USE AFTER ERROR PROCEDURE ON EDMAC. 01990000020000 EDMACERR-BEARB. 02000000020100 DISPLAY 'FILE "EDMAC", IO-TYP ' IO-TYP 02010000020200 ', IO-STATUS ' IO-STATUS 02020000020300 MOVE 8 TO RETURN-CODE 02030000020400 STOP RUN. 02040000020500* 02050000020600 END DECLARATIVES. 02060000020700* 02070000020800*-----------------------------------------------------------------02080000020900 EJECT 02090000021000*************************************************************** 02100000021100*** MAIN SECTION. *** 02110000021200*************************************************************** 02120000021300 STEUERUNG SECTION. 02130000021400*-----------------------------------------------------------------02140000021500* 02150000021600 MOVE SPACE TO EOF-KZ. 02160000021700* 02170000021800*** -------------------------------- *** 02180000021900* 02190000022000 DATEI-OPEN. 02200000022100* 02210000022200 MOVE 'OPEN' TO IO-TYP. 02220000022300* 02230000022400 OPEN INPUT PREF. 02240000022500 IF IO-STATUS NOT = '00' 02250000022600 DISPLAY 'FILE "PREF", IO-TYP ' IO-TYP 02260000022700 ', IO-STATUS ' IO-STATUS 02270000022800 MOVE 8 TO RETURN-CODE 02280000022900 STOP RUN 02290000023000 END-IF. 02300000023100* 02310000023200 OPEN INPUT BOOK. 02320000023300 IF IO-STATUS NOT = '00' 02330000023400 DISPLAY 'FILE "BOOK", IO-TYP ' IO-TYP 02340000023500 ', IO-STATUS ' IO-STATUS 02350000023600 MOVE 8 TO RETURN-CODE 02360000023700 STOP RUN 02370000023800 END-IF. 02380000023900* 02390000024000 OPEN OUTPUT EDMAC. 02400000



024100 IF IO-STATUS NOT = '00' 02410000024200 DISPLAY 'FILE "EDMAC", IO-TYP ' IO-TYP 02420000024300 ', IO-STATUS ' IO-STATUS 02430000024400 MOVE 8 TO RETURN-CODE 02440000024500 STOP RUN 02450000024600 END-IF. 02460000024700*** -------------------------------- *** 02470000024800*** READ PREFIXES AND COMPUTE LENGTHS *** 02480000024900*** -------------------------------- *** 02490000025000* 02500000025100 LESEN-PREF. 02510000025200 MOVE 'READ ' TO IO-TYP. 02520000025300 READ PREF. 02530000025400 MOVE ZERO TO L-PREF-REPL-1. 02540000025500 PERFORM VARYING I FROM 1 BY 1 02550000025600 UNTIL L-PREF-REPL-1 > 0 OR I > 32 02560000025700 IF PREF-REPL-I (I) = SPACE 02570000025800 MOVE I TO L-PREF-REPL-1 02580000025900 END-IF 02590000026000 END-PERFORM. 02600000026100 MOVE ZERO TO L-PREF-ORIG-1. 02610000026200 PERFORM VARYING I FROM 1 BY 1 02620000026300 UNTIL L-PREF-ORIG-1 > 0 OR I > 32 02630000026400 IF PREF-ORIG-I (I) = SPACE 02640000026500 MOVE I TO L-PREF-ORIG-1 02650000026600 END-IF 02660000026700 END-PERFORM. 02670000026800 SUBTRACT 1 FROM L-PREF-ORIG-1 GIVING L-PREF-ORIG. 02680000026900* 02690000027000*** -------------------------------- *** 02700000027100*** WRITE EDIT MACRO HEADER *** 02710000027200*** -------------------------------- *** 02720000027300* 02730000027400 SCHREIB-HDR. 02740000027500 MOVE 'WRITE' TO IO-TYP. 02750000027600 WRITE EDMAC-REC FROM M1. 02760000027700* 02770000027800 WRITE EDMAC-REC FROM MC. 02780000027900 WRITE EDMAC-REC FROM MC0. 02790000028000 WRITE EDMAC-REC FROM M2. 02800000028100 WRITE EDMAC-REC FROM M3. 02810000028200 WRITE EDMAC-REC FROM M4. 02820000028300* 02830000028400 WRITE EDMAC-REC FROM MC1. 02840000028500 MOVE SPACE TO EDMAC-REC. 02850000028600 STRING ' SET ORIGPREF = &STR(' DELIMITED BY SIZE 02860000028700 PREF-ORIG DELIMITED BY SPACE02870000028800 ')' DELIMITED BY SIZE 02880000028900 INTO EDMAC-REC. 02890000029000 WRITE EDMAC-REC. 02900000029100 WRITE EDMAC-REC FROM MC2. 02910000029200 MOVE SPACE TO EDMAC-REC. 02920000029300 STRING ' SET REPLPREF = &STR(' DELIMITED BY SIZE 02930000029400 PREF-REPL DELIMITED BY SPACE02940000029500 ')' DELIMITED BY SIZE 02950000029600 INTO EDMAC-REC. 02960000



029700 WRITE EDMAC-REC. 02970000029800 WRITE EDMAC-REC FROM MV. 02980000029900 WRITE EDMAC-REC FROM MC. 02990000030000* 03000000030100 WRITE EDMAC-REC FROM M5. 03010000030200* 03020000030300*** -------------------------------- *** 03030000030400*** LOOP: READ RECORD. IF REQUIRED *** 03040000030500*** WRITE 2 RECORDS F. EDIT MACRO. *** 03050000030600*** -------------------------------- *** 03060000030700* 03070000030800 ARBEITS-SCHLEIFE. 03080000030900 PERFORM UNTIL EOF 03090000031000 MOVE 'READ ' TO IO-TYP 03100000031100 READ BOOK 03110000031200 AT END SET EOF TO TRUE 03120000031300 END-READ 03130000031400 IF NOT EOF AND NOT COMMENT 03140000031500 UNSTRING BOOK-TEXT DELIMITED BY ALL SPACE OR '.' 03150000031600 INTO VAR0 VAR1 VAR2 03160000031700 ON OVERFLOW CONTINUE 03170000031800 END-UNSTRING 03180000031900 IF VAR2(1:L-PREF-ORIG) = PREF-ORIG(1:L-PREF-ORIG) 03190000032000* 03200000032100*--- START POS. FOR CHANGE, IF VARIABLE ENDS IN COL. 72 03210000032200* 03220000032300 MOVE ZERO TO L-VAR2-1 03230000032400 PERFORM VARYING I FROM 1 BY 1 03240000032500 UNTIL L-VAR2-1 > 0 OR I > 32 03250000032600 IF VAR2-I (I) = SPACE 03260000032700 MOVE I TO L-VAR2-1 03270000032800 END-IF 03280000032900 END-PERFORM 03290000033000 COMPUTE ISTART ROUNDED 03300000033100 = 74 - L-VAR2-1 03310000033200 + L-PREF-ORIG-1 03320000033300 - L-PREF-REPL-1 03330000033400 END-COMPUTE 03340000033500* 03350000033600 MOVE 'WRITE' TO IO-TYP 03360000033700* 03370000033800*--- VARIABLE AT END OF LINE 03380000033900* 03390000034000 MOVE SPACE TO EDMAC-REC 03400000034100 STRING MI1 DELIMITED BY SIZE 03410000034200 ISTART DELIMITED BY SPACE 03420000034300 MI2 DELIMITED BY SIZE 03430000034400 INTO EDMAC-REC 03440000034500 END-STRING 03450000034600 WRITE EDMAC-REC 03460000034700 MOVE SPACE TO EDMAC-REC 03470000034800 STRING ' "' DELIMITED BY SIZE 03480000034900 PREF-REPL DELIMITED BY SPACE 03490000035000 VAR2(L-PREF-ORIG-1:31) DELIMITED BY SPACE 03500000035100 '" +' DELIMITED BY SIZE 03510000035200 INTO EDMAC-REC 03520000



035300 END-STRING 03530000035400 WRITE EDMAC-REC 03540000035500 MOVE SPACE TO EDMAC-REC 03550000035600 STRING ' "' DELIMITED BY SIZE 03560000035700 VAR2 DELIMITED BY SPACE 03570000035800 '&INQUAL"' DELIMITED BY SIZE 03580000035900 INTO EDMAC-REC 03590000036000 END-STRING 03600000036100 WRITE EDMAC-REC 03610000036200* 03620000036300*--- VARIABLE FOLLOWED BY BLANK 03630000036400* 03640000036500 WRITE EDMAC-REC FROM MI 03650000036600 MOVE SPACE TO EDMAC-REC 03660000036700 STRING ' "' DELIMITED BY SIZE 03670000036800 PREF-REPL DELIMITED BY SPACE 03680000036900 VAR2(L-PREF-ORIG-1:31) DELIMITED BY SPACE 03690000037000 ' " +' DELIMITED BY SIZE 03700000037100 INTO EDMAC-REC 03710000037200 END-STRING 03720000037300 WRITE EDMAC-REC 03730000037400 MOVE SPACE TO EDMAC-REC 03740000037500 STRING ' "' DELIMITED BY SIZE 03750000037600 VAR2 DELIMITED BY SPACE 03760000037700 '&INQUAL "' DELIMITED BY SIZE 03770000037800 INTO EDMAC-REC 03780000037900 END-STRING 03790000038000 WRITE EDMAC-REC 03800000038100* 03810000038200*--- VARIABLE FOLLOWED BY PERIOD 03820000038300* 03830000038400 WRITE EDMAC-REC FROM MI 03840000038500 MOVE SPACE TO EDMAC-REC 03850000038600 STRING ' "' DELIMITED BY SIZE 03860000038700 PREF-REPL DELIMITED BY SPACE 03870000038800 VAR2(L-PREF-ORIG-1:31) DELIMITED BY SPACE 03880000038900 '." +' DELIMITED BY SIZE 03890000039000 INTO EDMAC-REC 03900000039100 END-STRING 03910000039200 WRITE EDMAC-REC 03920000039300 MOVE SPACE TO EDMAC-REC 03930000039400 STRING ' "' DELIMITED BY SIZE 03940000039500 VAR2 DELIMITED BY SPACE 03950000039600 '&INQUAL.."' DELIMITED BY SIZE 03960000039700 INTO EDMAC-REC 03970000039800 END-STRING 03980000039900 WRITE EDMAC-REC 03990000040000* 04000000040100*--- VARIABLE FOLLOWED BY COMMA 04010000040200* 04020000040300 WRITE EDMAC-REC FROM MI 04030000040400 MOVE SPACE TO EDMAC-REC 04040000040500 STRING ' "' DELIMITED BY SIZE 04050000040600 PREF-REPL DELIMITED BY SPACE 04060000040700 VAR2(L-PREF-ORIG-1:31) DELIMITED BY SPACE 04070000040800 '," +' DELIMITED BY SIZE 04080000



040900 INTO EDMAC-REC 04090000041000 END-STRING 04100000041100 WRITE EDMAC-REC 04110000041200 MOVE SPACE TO EDMAC-REC 04120000041300 STRING ' "' DELIMITED BY SIZE 04130000041400 VAR2 DELIMITED BY SPACE 04140000041500 '&INQUAL.,"' DELIMITED BY SIZE 04150000041600 INTO EDMAC-REC 04160000041700 END-STRING 04170000041800 WRITE EDMAC-REC 04180000041900* 04190000042000*--- VARIABLE FOLLOWED BY CLOSING BRACKET 04200000042100* 04210000042200 WRITE EDMAC-REC FROM MI 04220000042300 MOVE SPACE TO EDMAC-REC 04230000042400 STRING ' "' DELIMITED BY SIZE 04240000042500 PREF-REPL DELIMITED BY SPACE 04250000042600 VAR2(L-PREF-ORIG-1:31) DELIMITED BY SPACE 04260000042700 ')" +' DELIMITED BY SIZE 04270000042800 INTO EDMAC-REC 04280000042900 END-STRING 04290000043000 WRITE EDMAC-REC 04300000043100 MOVE SPACE TO EDMAC-REC 04310000043200 STRING ' "' DELIMITED BY SIZE 04320000043300 VAR2 DELIMITED BY SPACE 04330000043400 '&INQUAL.)"' DELIMITED BY SIZE 04340000043500 INTO EDMAC-REC 04350000043600 END-STRING 04360000043700 WRITE EDMAC-REC 04370000043800* 04380000043900*--- VARIABLE FOLLOWED BY OPENING BRACKET 04390000044000* 04400000044100 WRITE EDMAC-REC FROM MI 04410000044200 MOVE SPACE TO EDMAC-REC 04420000044300 STRING ' "' DELIMITED BY SIZE 04430000044400 PREF-REPL DELIMITED BY SPACE 04440000044500 VAR2(L-PREF-ORIG-1:31) DELIMITED BY SPACE 04450000044600 '(" +' DELIMITED BY SIZE 04460000044700 INTO EDMAC-REC 04470000044800 END-STRING 04480000044900 WRITE EDMAC-REC 04490000045000 MOVE SPACE TO EDMAC-REC 04500000045100 STRING ' "' DELIMITED BY SIZE 04510000045200 VAR2 DELIMITED BY SPACE 04520000045300 '&INQUAL.("' DELIMITED BY SIZE 04530000045400 INTO EDMAC-REC 04540000045500 END-STRING 04550000045600 WRITE EDMAC-REC 04560000045700* 04570000045800 END-IF 04580000045900 END-IF 04590000046000 END-PERFORM. 04600000046100* 04610000046200*** -------------------------------- *** 04620000046300*** WRITE EDIT MACRO TRAILER *** 04630000046400*** -------------------------------- *** 04640000



046500* 04650000046600 SCHREIB-END. 04660000046700 MOVE 'WRITE' TO IO-TYP. 04670000046800 WRITE EDMAC-REC FROM ME. 04680000046900 WRITE EDMAC-REC FROM MX. 04690000047000* 04700000047100*** -------------------------------- *** 04710000047200* 04720000047300 DATEI-CLOSE. 04730000047400 MOVE 'CLOSE' TO IO-TYP. 04740000047500 CLOSE PREF. 04750000047600 CLOSE BOOK. 04760000047700 CLOSE EDMAC. 04770000047800* 04780000047900*** -------------------------------- *** 04790000048000* 04800000048100 MOVE ZERO TO RETURN-CODE. 04810000048200* 04820000048300 ENDE. 04830000048400 STOP RUN. 04840000048500*=================================================================04850000


ISREDIT MACRO (COPYNAME,QUAL) 00010000/***============================================================== ***/00020000/*** PURPOSE.....: INITIATE USE OF SECOND MACRO THAT PERFORMS ***/00030000/*** CHANGES TO SOURCE THAT GO ALONG WITH THE ***/00040000/*** REMOVAL OF A REPLACING CLAUSE IN A COBOL COPY ***/00050000/*** STATEMENT FOR LIBRARIAN PREFIX REPLACING. ***/00060000/*** THE CALLED EDIT MACRO HAS TO BE CREATED IN ***/00070000/*** BEFORE FROM THE TEXT OF THIS COPY BOOK. ***/00080000/*** * ***/00090000/*** PARAMETERS..: COPYNAME = NAME OF THE INNER MACRO (SHOULD BE ***/00100000/*** THE NAME OF THE COPY BOOK) ***/00110000/*** (ENTER "X" TO QUIT EXECUTION) ***/00120000/*** QUAL = HIGH LEVEL QUALIFIER FOR DATA NAMES ***/00130000/*** (NORMALLY 01 LEVEL NAME), MAY BE ***/00140000/*** OMITTED (BLANK), NOT RECOMMENDED. ***/00150000/*** * ***/00160000/*** IF PARAMETERS ARE NOT SUPPLIED,YOU WILL BE PROMPTED FOR INPUT.***/00170000/*** * ***/00180000/*** DATE WRITTEN: 03/10/93-FITZ ***/00190000/***============================================================== ***/00200000

SET COPYNAME = &COPYNAME 00210000CN: IF (&COPYNAME = ) THEN DO 00220000

WRITE 00230000WRITE &STR( NAME EDIT MACRO (NORMALLY = NAME OF COPY BOOK)) 00240000



WRITENR &STR( OR ENTER "X" TO QUIT ............ ===> ) 00250000READ &COPYNAME 00260000IF (&COPYNAME = X) THEN DO 00270000

WRITE &STR( "X" = FUNCTION CANCELLED.) 00280000WRITE 00290000EXIT 00300000

END 00310000IF (&COPYNAME = ) THEN DO 00320000

WRITE &STR( INPUT REQUIRED, "X" = QUIT.) 00330000GOTO CN 00340000

END 00350000END 00360000SET QUAL = &STR(&QUAL) 00370000IF (&STR(&QUAL) = ) THEN DO 00380000

WRITE 00390000WRITE &STR( QUALIFIER FOR DATA NAMES TO BE CHANGED) 00400000WRITE &STR( BLANK = OHNE QUALIFIER,) 00410000WRITENR &STR( (NORMALLY 01 LEVEL NAME).... ===> ) 00420000READ &QUAL 00430000SET QUAL = &STR(&QUAL) 00440000

END 00450000/***-------------------------------------------------------------- ***/00460000/*** EXECUTE INNER MACRO ***/00470000/*** (THIS MACRO HAS TO BE CREATED WITH PROGRAM MIGU003 ***/00480000/*** USING THE TEXT OF THE COPY BOOK AS INPUT DATA). ***/00490000/***-------------------------------------------------------------- ***/00500000

ISREDIT &COPYNAME &STR(&QUAL) 00510000ISPEXEC VGET (ORIGPREF REPLPREF) SHARED 00520000

/***-------------------------------------------------------------- ***/00530000/*** REQUEST FOR USER CONFIRMATION. IF NOT Y (YES), ***/00540000/*** THEN CANCEL AND EXIT ***/00550000/***-------------------------------------------------------------- ***/00560000

WRITE 00570000SET W = &STR( MACRO "&COPYNAME." WILL BE USED) 00580000WRITE &STR(&W TO CHANGE NAMES OF) 00590000SET W = &STR( "&REPLPREF...." VARIABLES) 00600000WRITE &STR(&W INTO NAMES LIKE) 00610000IF (&STR(&QUAL) NE ) THEN DO 00620000

SET W = &STR( "&ORIGPREF.... IN &QUAL") 00630000WRITE &STR(&W, I.E. SAME NAMES AS USED IN COPYBOOK,) 00640000WRITE &STR( BUT WITH ADDITIONAL QUALIFIER "&QUAL".) 00650000

END 00660000ELSE DO 00670000

SET W = &STR( "&ORIGPREF....") 00680000WRITE &STR(&W, I.E. SAME NAMES AS USED IN COPYBOOK,) 00690000WRITE &STR( AND W I T H O U T ADDITIONAL QUALIFIER.) 00700000

END 00710000WRITE 00720000WRITENR &STR( OK ? (Y/N) ===> ) 00730000READ &ANTWORT 00740000IF (&SUBSTR(1:1,&ANTWORT&STR(NEIN)) NE Y) THEN DO 00750000

WRITE 00760000WRITE &STR( EXECUTION NOT CONFIRMED.) 00770000WRITE &STR( EDIT WILL BE CANCELLED.) 00780000WRITE 00790000ISREDIT CANCEL 00800000



EXIT /*** ===============> EXIT ***/00810000END 00820000WRITE 00830000

/***-------------------------------------------------------------- ***/00840000/*** CALCULATE INCREASE IN LEGTH FOR VARIABLES NAMES (LL). ***/00850000/***-------------------------------------------------------------- ***/00860000

SET LQ = &LENGTH(&STR(&QUAL)) 00870000SET LO = &LENGTH(&STR(&ORIGPREF)) 00880000SET LR = &LENGTH(&STR(&REPLPREF)) 00890000SET LL = &EVAL(&LO + &LQ + 4 - &LR) 00900000IF (&LL < 0) THEN SET LL = 0 00910000

/***-------------------------------------------------------------- ***/00920000/*** INITIALIZATION, SET BOUND AND NUMBER MODE. ***/00930000/***-------------------------------------------------------------- ***/00940000

SET ANZERR = 0 00950000ISREDIT UP MAX 00960000ISREDIT NUMBER COBOL 00970000ISREDIT UNNUM 00980000ISREDIT BOUNDS 1 72 00990000

/***-------------------------------------------------------------- ***/01000000/*** LOOP TO HANDLE ALL ERROR LINES ***/01010000/*** (NOT ENOUGH SPACE TO DO THE CHANGE IN ONE LINE). ***/01020000/***-------------------------------------------------------------- ***/01030000ERR: ISREDIT LOCATE ERROR NEXT 01040000

SET LCC = &LASTCC 01050000ISREDIT (ELINE,BLINE) = DISPLAY_LINES 01060000/*---------------------------------------------------------*/ 01070000/*-- LOCATE MAKES ERROR LINE TO FIRST LINE, --*/ 01080000/*-- THIS LINE-PTR GOES VIA DISPLAY_LINES TO &ELINE. --*/ 01090000/*---------------------------------------------------------*/ 01100000IF (&LCC = 0) THEN DO 01110000

ISREDIT LABEL &ELINE = .E 01120000SET ANZERR = &EVAL(&ANZERR + 1) 01130000ISREDIT FIND .E .E &REPLPREF FIRST 8 72 01140000ISREDIT (ELINE,PREFCOL) = CURSOR 01150000/*------------------------------------------------------*/ 01160000/*-- SPLIT LINE AT BLANK LAEDING OR TRAILING TO NAME --*/ 01170000/*-- TO BE CHANGED. DEPENDS ON POSITION IN LINE. --*/ 01180000/*------------------------------------------------------*/ 01190000SET SPLITLIM = 35 01200000IF (&PREFCOL > &SPLITLIM) THEN + 01210000

ISREDIT FIND .E .E 12 &PREFCOL ' ' LAST 01220000ELSE ISREDIT FIND .E .E &PREFCOL 72 ' ' FIRST 01230000ISREDIT (FCOUNT) = FIND_COUNTS 01240000IF (&FCOUNT GT 0) THEN DO 01250000

ISREDIT (ELINE,SPLITCOL) = CURSOR 01260000ISREDIT TSPLIT &ELINE &SPLITCOL 01270000/*---------------------------------------------------*/ 01280000/*-- SHIFT SPLITTED PART OF LINE TO LEFT, --*/ 01290000/*-- IF NECESSARY. --*/ 01300000/*---------------------------------------------------*/ 01310000IF (&PREFCOL > &SPLITLIM) THEN DO 01320000

SET FLINE = &EVAL(&ELINE + 1) 01330000ISREDIT LABEL &FLINE = .F 01340000ISREDIT FIND .F .F 8 72 P'¬' FIRST 01350000IF (&FCOUNT GT 0) THEN DO 01360000



ISREDIT (FLINE,NBCOL) = CURSOR 01370000SET LF = &EVAL(&SPLITCOL + 1 - &NBCOL) 01380000SET LS = &EVAL(&LL - &LF) 01390000IF (&LS GT 0) THEN DO 01400000

ISREDIT BOUNDS 12 72 01410000ISREDIT SHIFT < &FLINE &LS 01420000ISREDIT BOUNDS 1 72 01430000

END 01440000END 01450000ISREDIT LABEL &FLINE = &STR(' ') 01460000

END 01470000END 01480000ISREDIT LABEL &ELINE = &STR(' ') 01490000GOTO ERR 01500000

END 01510000/***-------------------------------------------------------------- ***/01520000/*** IF THERE ARE ERRORS, REDO INNER MACRO ***/01530000/*** PREVIOUS SPLIT NOW SHOULD ALLOW TO DO ALL REMAINING CHANGES. ***/01540000/***-------------------------------------------------------------- ***/01550000

IF (&ANZERR GT 0) THEN DO 01560000ISREDIT RESET ERROR 01570000ISREDIT &COPYNAME &STR(&QUAL) 01580000

END 01590000/***-------------------------------------------------------------- ***/01600000/*** SET BOUNDS AND NUMBERING BACK TO COBOL STANDARDS. ***/01610000/***-------------------------------------------------------------- ***/01620000

ISREDIT BOUNDS 7 72 01630000ISREDIT NUMBER COBOL 01640000ISREDIT RENUM 01650000

/***-------------------------------------------------------------- ***/01660000/*** MACRO WILL BE EXITED WITHOUT SAVE. ***/01670000/*** USER MAY SAVE OR CANCEL. ***/01680000/***-------------------------------------------------------------- ***/01690000

WRITE 01700000WRITE &STR( FUNCTION EXECUTED.) 01710000WRITE 01720000SET W = &STR( DON'T FORGET TO REMOVE THE REPLACING CLAUSE) 01730000WRITE &STR(&W FROM THE COPY STATEMENT.) 01740000WRITE 01750000WRITE &STR( SAVE CHANGES WITH WITH "END" OR CANCEL EDIT.) 01760000WRITE 01770000ISREDIT LOCATE ERROR FIRST 01780000SET LCC = &LASTCC 01790000IF (&LCC = 4) THEN ISREDIT FIND &COPYNAME FIRST 01800000

EXIT 01810000/***============================================================== ***/01820000


Changing CA-LIBRARIAN − INC StatementsFigure 92 on page 157 and Figure 93 on page 157 list the ISPF EDIT macros used to changeCA-LIBRARIAN − INC statements in application 1 Assembler and PL/I programs.

Modules of different types were stored in different PDSs, which allowed us to performactions specific for one language. The general-purpose EDIT macro MIGE0000 (seeFigure 50 on page 91) allowed us to apply these macros to all members in a PDS.


ISREDIT MACRO 00000100/***============================================================== ***/00000200/*** PURPOSE.....: CONVERT LIBRARIAN -INC STATEMENTS TO ***/00000300/*** COMMENT LINES IN ASSEMBLER PGMS ***/00000400/*** (-INC --> *@@-INC). ***/00000500/*** -INC WAS A LIBRARIAN SPECIFIC STATEMENT ***/00000600/*** ONLY USED TO INCLUDE MACRO SOURCE ***/00000700/*** INTO MAIN SOURCE ***/00000800/*** 1) IN ORDER TO GET IT OUT OF LIBRARIAN ***/00000900/*** 2) TO GET IT ARCHIVED TOGETHER W. PGM. ***/00001000/*** DATE WRITTEN: 03/08/93-FITZ ***/00001100/***============================================================== ***/00001200

ISREDIT BOUNDS 1 72 00001300ISREDIT CHANGE ALL 1 '-INC' '*@@-INC' 00001400ISREDIT (CCOUNT) = CHANGE_COUNTS 00001500SELECT 00001600

WHEN (&CCOUNT = 0) ISREDIT CANCEL 00001700WHEN (&LASTCC = 0) ISREDIT END 00001800

END 00001900/***-------------------------------------------------------------- ***/00002000EXIT 00002100

Figure 92. ISPF EDIT Macro MIGE0010. This EDIT macro was used to convert CA-LIBRARIAN − INCstatements in Assembler programs into comment lines.

ISREDIT MACRO 00000100/***============================================================== ***/00000200/*** PURPOSE.....: CONVERT LIBRARIAN -INC STATEMENTS TO ***/00000300/*** PLI %INCLUDE STMTS IN PL/I PGMS ***/00000400/*** -INC WAS A LIBRARIAN SPECIFIC STATEMENT ***/00000500/*** DATE WRITTEN: 03/10/93-FITZ ***/00000600/***============================================================== ***/00000700

ISREDIT BOUNDS 1 72 00000800ISREDIT UP MAX 00000900ISREDIT CURSOR = 1 1 00001000SET CSUM = 0 00001100

/***-------------------------------------------------------------- ***/00001200/*** LOOP: CHANGE -INC IN COL.1 ***/00001300/*** TO %INCLUDE IN COL.2 AND ADD SEMICOLON AFTER NAME. ***/00001400/***-------------------------------------------------------------- ***/00001500INC: ISREDIT CHANGE 1 '-INC' ' %INCLUDE' 00001600

ISREDIT (CCOUNT) = CHANGE_COUNTS 00001700SET LCC = &LASTCC 00001800SELECT 00001900

WHEN (&LCC NE 0) GOTO ENDINC 00002000WHEN (&CCOUNT = 0) GOTO ENDINC 00002100OTHERWISE DO 00002200

SET CSUM = &EVAL(&CSUM + 1) 00002300ISREDIT FIND NEXT P'¬' 00002400



ISREDIT CHANGE NEXT ' ' ';' 00002500GOTO INC 00002600

END 00002700END 00002800

/***-------------------------------------------------------------- ***/00002900ENDINC: SELECT 00003000

WHEN (&CSUM = 0) ISREDIT CANCEL 00003100WHEN (&LCC = 0) ISREDIT END 00003200

END 00003300/***-------------------------------------------------------------- ***/00003400EXIT 00003500

Figure 93 (Part 2 of 2). ISPF EDIT Macro MIGE0020. This EDIT macro was used to convertCA-LIBRARIAN − INC statements in PL/I programs into PL/I %INCLUDEstatements.

Using SCLM Command Interface for Mass BUILDsREXX procedure MIGR0020 issues multiple calls to the SCLM command interface to performmass BUILDs using FLMCMD BUILD... . Mass BUILDs were performed for correctnesschecks during bulk data migration (refer to “Check Correctness Using SCLM BUILDs” onpage 59).

Architecture definition member names for the BUILD command are read from an input file.Listing files are created for each BUILD using the member name from the input file as partof the listing name.

Existing old listings with the same name are deleted. New listings are only kept in case ofBUILD errors. Figure 94 shows REXX procedure MIGR0020 and Figure 95 on page 159shows a sample job to run MIGR0020 in batch mode.

/***** REXX ***********************************************************/00010000/* PURPOSE.....: START SCLM BUILD WITH FLMCMD BUILD */00020000/* FOR ARCHDEFS NAMED IN AN INPUT LIST */00030000/* *** BATCH VERSION: FI(INPFILE) HAS TO */00040000/* BE ALLOCATED */00050000/* DATE WRITTEN: 03/23/93-FITZ */00060000/**********************************************************************/00070000/* TRACE R */ 00080000/* ------------------------------------------------------------------ */00090000

ADDRESS TSO 00100000MOREINP = 1 00110000DO WHILE MOREINP = 1 00120000

"EXECIO 1 DISKR INPFILE" 00130000IF RC ¬= 0 THEN DO /* EOF REACHED */ 00140000

MOREINP = 0 00150000END 00160000



ELSE DO 00170000PULL RECORD /* DATA FROM INPUT RECORD OR DEFAULTS: */00180000MEMBNAME = SUBSTR(RECORD,01,8) 00190000

MEMBNAME = STRIP(MEMBNAME) 00200000TYPENAME = SUBSTR(RECORD,11,8) 00210000IF TYPENAME = ' ' THEN TYPENAME = 'ARCHDEF' 00220000

ELSE TYPENAME = STRIP(TYPENAME) 00230000GROUNAME = SUBSTR(RECORD,21,8) 00240000IF GROUNAME = ' ' THEN GROUNAME = 'MIG1' 00250000

ELSE GROUNAME = STRIP(GROUNAME) 00260000ALTPNAME = SUBSTR(RECORD,31,8) 00270000

ALTPNAME = STRIP(ALTPNAME) 00280000PROJNAME = SUBSTR(RECORD,41,8) 00290000IF PROJNAME = ' ' THEN PROJNAME = 'SCLM3' 00300000

ELSE PROJNAME = STRIP(PROJNAME) 0031000000320000

IF MEMBNAME ¬= '' THEN DO 0033000000340000

LISTNAME = 'BUILDLST.'MEMBNAME 00350000XXX = SYSDSN(LISTNAME) /* DELETE OLD LISTING, IF ANY: */ 00360000IF (XXX = 'OK') THEN "DELETE" LISTNAME "NONVSAM" 00370000

/* ALLOC LISTING DS: */ 00380000ALLOC1 = 'RECFM(V,B,A) LRECL(137) BLKSIZE(3120) UNIT(SYSDA)' 00390000ALLOC2 = 'TRACKS SPACE(5,5) MOD CATALOG REUSE' 00400000"ALLOC FILE(DDLIST) DATASET("LISTNAME")" ALLOC1 ALLOC2 00410000

00420000IF RC ¬= 0 THEN SAY 'ALLOC ERROR' LISTNAME 'RC =' RC 00430000ELSE DO 00440000

/* PERFORM BUILD: */ 00450000FLMCMD1 = 'BUILD,'PROJNAME','ALTPNAME','GROUNAME','TYPENAME 00460000FLMCMD2 = MEMBNAME',,N,C,Y,N,,,,DDLIST,,' 00470000"FLMCMD" FLMCMD1','FLMCMD2 00480000BRC = RC 00490000SAY '* BUILD FOR >'TYPENAME MEMBNAME'< ENDED WITH RC =' BRC 00500000IF BRC = 0 THEN "DELETE" LISTNAME "NONVSAM" 00510000"FREE FILE(DDLIST)" 00520000

END 00530000END 00540000

END 00550000END 00560000

/* ------------------------------------------------------------------ */00570000EXIT 00580000


//....... JOB .........................., 00000100// ............................... 00000200//*========================================================== 00000300//BUILD0 EXEC PGM=IKJEFT01,REGION=4096K,TIME=1439,DYNAMNBR=200 00120000//STEPLIB DD DSN=ISR.V3R5M0.ISRLPA,DISP=SHR 00180000// DD DSN=ISR.V3R5M0.ISRLOAD,DISP=SHR 00190000// DD DSN=ISP.V3R5M0.ISPLPA,DISP=SHR 00200000// DD DSN=ISP.V3R5M0.ISPLOAD,DISP=SHR 00210000

Figure 95 (Part 1 of 3). Sample Job to Run MIGR0020 in Batch Mode


...//****************************************************************** 00370000//* ISPF/PDF LIBRARIES 00380000//****************************************************************** 00390000//ISPMLIB DD DSN=ISR.V3R5M0.ISRMENU,DISP=SHR ISPF/PDF MSGS 00410000// DD DSN=ISP.V3R5M0.ISPMENU,DISP=SHR ISPF MESSAGES 00420000...//ISPSLIB DD DSN=ISR.V3R5M0.ISRSENU,DISP=SHR PDF SKELS 00470000// DD DSN=ISP.V3R5M0.ISPSLIB,DISP=SHR ISPF SKELS 00480000...//ISPPLIB DD DSN=ISR.V3R5M0.ISRPENU,DISP=SHR PDF PANELS 00530000// DD DSN=ISP.V3R5M0.ISPPENU,DISP=SHR ISPF PANELS 00540000...//ISPTLIB DD DSN=ISR.V3R5M0.ISRTLIB,DISP=SHR PDF TABLES 00590000// DD DSN=ISP.V3R5M0.ISPTENU,DISP=SHR ISPF TABLES 00600000...//ISPTABL DD UNIT=VIO,DISP=(NEW,PASS),SPACE=(CYL,(1,1,5)), 00640000// DCB=(LRECL=80,BLKSIZE=19040,DSORG=PO,RECFM=FB), 00650000// DSN=&&TT TEMPORARY TABLE LIBRARY 00660000//* 00670000//ISPPROF DD UNIT=VIO,DISP=(NEW,PASS),SPACE=(CYL,(1,1,5)), 00680000// DCB=(LRECL=80,BLKSIZE=19040,DSORG=PO,RECFM=FB), 00690000// DSN=&&PP 00700000//* 00710000//ISPLOG DD SYSOUT=*, 00720000// DCB=(LRECL=120,BLKSIZE=2400,DSORG=PS,RECFM=FB) 00730000//*-------------------------------------------------------------------- 00750000//SYSPROC DD DSN=ISR.V3R5M0.ISRCLIB,DISP=SHR @@ 00790000// DD DSN=SCLM3.STADE5.REXX,DISP=SHR @@ 00801000// DD DSN=SCLM3.RESI.REXX,DISP=SHR @@ 00810000//* 00820000//*-------------------------------------------------------------------- 00840000//* BUILD USER EXIT OUTPUT FILE 00850000//*-------------------------------------------------------------------- 00860000//BLDEXIT DD DSN=NULLFILE, 00870000// DISP=(NEW,DELETE,DELETE),SPACE=(TRK,(5,10),RLSE), 00880000// DCB=(LRECL=160,BLKSIZE=3200,RECFM=FB),UNIT=SYSALLDA 00890000//*-------------------------------------------------------------------- 00900000//* OUTPUT CARD 00920000//*-------------------------------------------------------------------- 00930000//BLDREPT DD DUMMY 00940000//BLDMSGS DD SYSOUT=(T), 00990000// DCB=(LRECL=80,BLKSIZE=80,RECFM=F) 01000000//SYSPRINT DD SYSOUT=(*) 01010000//*-------------------------------------------------------------------- 01020000//* NLS TABLE AND TRANSLATION TABLE NAME FILE 01030000//*-------------------------------------------------------------------- 01040000//ZFLMDD DD * 01050000//*-------------------------------------------------------------------- 01060000//* SCLMCMD FILES 01070000//*-------------------------------------------------------------------- 01080000//FLMMSGS DD SYSOUT=(*) 01090000//*-------------------------------------------------------------------- 01100000//* TSO OUTPUT FILE 01110000//*-------------------------------------------------------------------- 01120000//SYSTSPRT DD SYSOUT=(*) 01130000



//*-------------------------------------------------------------------- 01140000//* TSO INPUT FILE 01150000//*-------------------------------------------------------------------- 01160000//SYSTSIN DD * 01170000

ISPSTART CMD(MIGR0020) 01180000/* 01190000//*-------------------------------------------------------------------- 01191000//* INPUT FILE FOR REXX MIGR0020: 01192000//*-------------------------------------------------------------------- 01193000//INPFILE DD DISP=SHR,DSN=SCLM3.STADE5.DATA(BUICOBOL) 01199000//*==================================================================== 01200000


Because we used all the defaults coded in MIGR0020, the input file only had an LEC membername starting in column 1 in each record.


Glossaryaccounting data set. SCLM term. A VSAM data setcontaining SCLM control information. For everymember the data set contains at least anaccounting record. Information stored in theaccounting record of a member includes thelanguage assigned to the member, its creation andchange dates and times, whether the member hasbeen built, and statistical and dependencyinformation. Another type of record in theaccounting data set consists of the build map.

AD/Cycle. IBM's application developmentframework for Systems Application Architecture(SAA).

alternate project definition. SCLM term. Thealternate project definition can be used in place ofa project definition. It is the member name of aload module in the project.PROJDEFS.LOAD dataset. The name of this module must be explicitlyspecified if you are referring to it.

architecture definition. SCLM term. Anarchitecture definition specifies the relationshipbetween software components of an application.

authorization code. SCLM term. Authorizationcodes are a property of a member under SCLMcontrol. They are used to restrict promotions.

build. SCLM term. Build usually involves compileor link. Build means to apply the language storedin the member's accounting record (and defined inthe project definition) to the member. You canbuild individual source members or wholeapplications consisting of multiple source membersreferenced by an architecture definition. Building alinkage edit control architecture definition meanscompiling and link-editing the referenced members.

COBOL information bytes. Part of the VS COBOL IIprogram initialization code, where you also findother information, such as program-ID, version,release, and modification of the compiler, timestamps, and number of statements. VS COBOL IIstores information about the compiler options usedto create the load module in the COBOLinformation bytes.

development group. The bottom or base set ofgroups within the hierarchy of a project.

key group. SCLM term. A group into which data ismoved (as opposed to copied) during promotion.Key groups are always allocated when you workwith an SCLM hierarchy.

language definition. SCLM term. Languages inSCLM must be specified in the project definition.They define the processes that source memberswill undergo during build.

layer. A given tier of the hierarchy, made up ofgroups of equivalent rank.

library management. SCLM uses hierarchies forlibrary management. Members are moved betweendifferent hierarchy layers by SCLM's promote anddrawdown.

nonkey group. SCLM term. A group in the SCLMhierarchy into which data is copied (as opposed tomoved) during promotion. Nonkey groups are notalways allocated by SCLM. An example is the Editpanel of SCLM where nonkey groups never showup. A nonkey group results in duplication of codeafter promotion.

parse. Synonym for analyzing in a formal way. InSCLM, parsing means to gather statistics of amember and determine include relationships.

part. Part is another word for member when usedin conjunction with SCLM.

partitioned data set. All SCLM-controlled membersare stored in partitioned data sets.

project. An SCLM project consists of a set ofpartitioned data sets whose members arecontrolled by a project definition. The projectdefinition specifies a hierarchy.

project definition. SCLM term. The projectdefinition describes the project hierarchy, projectdatabase, languages defined, and control options.The project definition is the member name of theload module “project” in data set


project.PROJDEFS.LOAD. In all cases where noproject definition name is specified, SCLM assumesthat this load module is being referred to.

promote. SCLM term. In SCLM, promote signifiescopying a member of a PDS in the project databaseto a higher layer in the project hierarchy. Usually,the member at the lower layer is purged. Promote

is the movement from one hierarchy layer to thenext. You can promote selected source membersthat may be architecture definitions or you maypromote architecture definitions. Everythingreferenced will be moved to the higher layer(includes output members such as listings orobjects).


List of AbbreviationsBMS basic mapping support

CC compilation control

CCID change control identifier

CICS Customer Information ControlSystem

DB2 IBM DATABASE 2

DBD database control block

DDL data definition language

FAIR file access interface routine

GPO group processing option

HL high level

IBM International BusinessMachines Corporation

ISPF/PDF Interactive SystemProductivity Facility/ProgramDevelopment Facility

ITSC International TechnicalSupport Center

ITSO International TechnicalSupport Organization

LEC link edit control

MCD management code

MFS message format service

PDS partitioned data set

PSB program specification block

RACF Resource Access ControlFacility

SCL software control language(ENDEVOR)

SCLM Software Configuration andLibrary Manager

SDF II Screen Definition Facility II

WITT Workstation Interactive TestTool


Index

Special Characters

-INC statement 14, 15, 18, 20, 57, 156*PROCESS statement 37, 88%INCLUDE statement 57, 62

A

accounting data set 4, 28, 61ADD action 16ALIAS 42alternate project definitions 25AMBLIST utility 42AMODE 41application 1

data extraction 17naming convention 18programs 13release procedures 13

application inventory 9application structure 61architecture definition 3, 24architecture report 58, 64archive file 42, 97ARCHIVE function 7, 21audit information 27auditing 27authorization code 25, 51AUTOCALL 42

B

build 3, 59, 61, 158bulk data migration

standard source code 51

C

CA-LIBRARIAN-INC statement 14, 15, 18, 20, 57, 156archiving facility 6control statements 6COPY option 14ELIPS 6group processing option 6index listing 72jobs 73LANG information 35management code 6master file 6processing options 6SCAN option 18utility 73, 74

CBL statement 36, 37, 88CC architecture definition 33, 34, 36, 37, 44, 62

naming conventions 44P92N002 45

CCID 7, 16, 72change control identifiers

See CCIDCMPAT(V1) 33CMPAT(V2) 33CMPR2 33, 39COBOL

01 level data name 52, 53CBL statement 36, 37, 88COPY statement 52, 53, 54, 56, 57, 141PROCESS statement 36, 37, 88REPLACING clause 52, 54, 56, 57, 141

compiler ID 77compiler options 36, 37, 82

SCLM 37control information 29, 72

application 71migration 29object 71

COPY option 14COPY statement 52, 53, 54, 56, 57, 141


D

DATA(31) 39DB2 BIND 16DB2CLIST 47, 48, 52, 129DB2OUT 47DBUTIL service 34DFHECI 82dictionary report 63

E

EDIT macroMIGE0000 89, 90, 139, 156MIGE0030 139MIGE0040 31, 89MIGE0050 141, 143

ELIPS 6ENDEVOR

ADD action 16archive file 21, 31, 42, 97ARCHIVE function 7, 21attribute information 21auditing 27CCID 7, 16, 72environment 26footprint 7GENERATE action 16inventory item 7LIST action 21master control file 16MOVE action 16MOVE processors 26PRINT action 8, 35, 96processor 7, 21, 35REPLACE action 16report 7, 27, 72RESTORE function 7, 21SCL 7, 16software objects 7stages 7, 25subsystem 24, 67system 24, 67TRANSFER utility 7, 21

enterprise project 24ENTRY 42error message

IGYDS1159-E 53IGYPS0037-S 54

F

FLMALLOC macros 57FLMALTC macro 23FLMCNTRL macro 33FLMGROUP macro 23FLMLANGL macro 36FLMTRNSL macro 33, 37, 39, 45footprint 7

G

GENERATE action 16group 24, 25

H

high-level qualifier 23, 24HL architecture definition 58, 59, 61, 62, 64, 67, 69,

129naming conventions 48, 63

I

IEBCOPY utility 32, 52IGYDS1159-E 53IGYPS0037-S 54INCLUDE 42information bytes 31, 32, 37ISPF help panel

MIGH0010 123ISPF panel

MIGP0010 123MIGP0040 92

ISPF search-for utility 18, 64, 141ISPF skeleton

MIGS0010 123MIGS0011 123

J

jobs 73

L

LANG information 35LANGLVL(1) 33


LANGLVL(2) 33language definition 3, 4, 28, 33, 39, 104LEC architecture definition 44, 62, 123

naming conventions 44P92N041 46P94N353 46

LIB 39linkage edit control options

ALIAS 42AMODE 41AUTOCALL 42ENTRY 42INCLUDE 42RENT 41REUS 41RMODE 41

LIST action 21

M

master control file 16master file 6MIGE0000 89, 90, 139, 156MIGE0030 139, 141MIGE0040 31, 89MIGE0050 141, 143MIGH0010 123MIGP0010 123MIGP0040 92MIGR0010 31, 44, 97, 123MIGR0020 59, 158

sample job 158MIGR0030 31, 42, 97MIGR0040 31, 92MIGR0050 48, 63, 129migration

application developers 11control information 29library administrator 11preparation 5, 9project leader 11project organization 10SCLM support 11strategy 9

migration utility 51MIGS0010 123MIGS0011 123MIGU001 32, 35, 77

output 80sample job 80

MIGU002 32, 37, 82output 87sample job 82

MIGU003 141sample job 143

MOVE action 16MOVE processors 26

N

NOCMPR2 33, 39NOLIB 39NONUM 39NONUMCLASS 39NORENT 39NOSSRANGE 39NOTRUNC 39NUM 39NUMCLASS 39

O

OS/VS COBOL optionsLANGLVL(1) 33LANGLVL(2) 33

P

P92N002CC architecture definition 45

P92N041LEC architecture definition 46

P94N353LEC architecture definition 46

PANVALET 7pilot application

considerations 12selection 12

pilot project 9PL/I

*PROCESS statement 37, 88%INCLUDE statement 57, 62

PL/I optionsCMPAT(V1) 33CMPAT(V2) 33

post-migration 5PRINT action 8, 35, 96PROCESS statement 36, 37, 88processor 35project definition 3, 23, 28, 101project organization 10promote 4, 61, 71promotion hierarchy 3, 25

Index 169

R

RACF 4, 6, 28release procedures

audit information 14RENT 39, 41REPLACE action 16REPLACING clause 52, 54, 56, 57, 141RESTORE function 7, 21REUS 41REXX procedure

G621HLA 48MIGR0010 31, 44, 123MIGR0020 59, 158MIGR0030 31, 42, 97MIGR0040 31, 92MIGR0050 48, 129

RMODE 41

S

SCAN option 18SCL 7, 16SCLM

accounting data set 4, 28, 61alternate project definitions 25architecture definition 3, 24architecture report 58, 64audit information 27auditing 27authorization code 25, 51build 3, 59, 61, 158CC architecture definition 33, 34, 36, 37, 44, 62command interface 158compiler options 37data sets 28DB2CLIST 47, 48, 52, 129DB2OUT 47DBUTIL service 34enterprise project 24FLMALLOC macros 57FLMALTC macro 23FLMCNTRL macro 33FLMGROUP macro 23FLMLANGL macro 36FLMTRNSL macro 33, 37, 39, 45group 24, 25high-level qualifier 23, 24HL architecture definition 58, 59, 61, 62, 64, 67,

69, 129language definition 3, 4, 28, 33, 39, 104LEC architecture definition 44, 62, 123migration utility 51parser 61

SCLM (continued)project 5, 23, 25project definition 3, 4, 23, 28, 101promote 4, 61, 71types 26, 27version information 27versioning 4, 27

software control languageSee SCL

software objects 7SSRANGE 39stages 25

T

TRANSFER utility 7, 21translator options 28TRUNC(BIN) 39types 26, 27

U

utilityAMBLIST 42CA-LIBRARIAN 73, 74IEBCOPY 32, 52ISPF search-for 18, 64, 141migration 51TRANSFER 7, 21

V

version information 27versioning 4, 27VS COBOL II 77

compiler options 31, 82information bytes 31, 32, 37modules 31

VS COBOL II optionsCMPR2 32, 33, 39DATA(31) 39LIB 39NOCMPR2 32, 33, 39NOLIB 39NONUM 39NONUMCLASS 39NORENT 39NOSSRANGE 39NUM 39NUMCLASS 39RENT 39SSRANGE 39


VS COBOL II options (continued)TRUNC(BIN) 39

Index 171

ITSC Technical Bulletin Evaluation RED000Migrating Applicationsfrom Vendor Librariesto SCLM

Publication No. GG24-4021-00

Your feedback is very important to us to maintain the quality of ITSO redbooks. Please fill out thisquestionnaire and return it using one of the following methods:

Mail it to the address on the back (postage paid in U.S. only)Give it to an IBM marketing representative for mailingFax it to: Your International Access Code + 1 914 432 8246

Please rate on a scale of 1 to 5 the subjects below.(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)

Overall Satisfaction ____

Organization of the bookAccuracy of the informationRelevance of the informationCompleteness of the informationValue of illustrations

____________________

Grammar/punctuation/spellingEase of reading and understandingEase of finding informationLevel of technical detailPrint quality

____________________

Please answer the following questions:

a) Are you an employee of IBM or its subsidiaries? Yes____ No____

b) Are you working in the USA? Yes____ No____

c) Was the Bulletin published in time for your needs? Yes____ No____

d) Did this Bulletin meet your needs? Yes____ No____

If no, please explain:

What other topics would you like to see in this Bulletin?

What other Technical Bulletins would you like to see published?

Comments/Suggestions: ( THANK YOU FOR YOUR FEEDBACK! )

Name Address

Company or Organization

Phone No.

ITSC Technical Bulletin Evaluation RED000GG24-4021-00

Fold and Tape Please do not staple Fold and Tape

NO POSTAGENECESSARYIF MAILED IN THEUNITED STATES

BUSINESS REPLY MAILFIRST CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK

POSTAGE WILL BE PAID BY ADDRESSEE

IBM International Technical Support CenterDepartment 471, Building 0985600 COTTLE ROADSAN JOSE CAUSA 95193-0001

Fold and Tape Please do not staple Fold and Tape

GG24-4021-00

Printed in U.S.A.

GG24-4021-00

mainframe manual

Documents