Mainframe Manual

Migrating Applications
from Vendor Libraries

to SCLM
Document Number GG24-4021-00
June 1993
International Technical Support Center

San Jose
Take Note!
Before using this information and the product it supports, be sure to read the general information
under “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 form
has been removed, comments may be addressed to:
IBM Corporation, International Technical Support Center

Dept. 471, Building 098
5600 Cottle Road
San Jose, California 95193-0001
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information 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 or
disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Abstract
This book describes and documents the process used to migrate two customer applications
from 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 the
techniques used and the experience gained during our project to migrations from any
vendor library system to SCLM.
The book is intended for project leaders, library administrators, system programmers, and
application developers involved in migrating applications from vendor libraries to SCLM. It
assumes 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Why Migrate to SCLM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Objectives and Scope of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Project Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Sample Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Vendor Library Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
CA-LIBRARIAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
ENDEVOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Chapter 2. Preparing for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Develop Migration Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Define Organizational and Administrative Structure . . . . . . . . . . . . . . . . . . . . . . . 10
Select Pilot Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Sample Application 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Release Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Sample Application 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Release Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Extract Data for the Sample Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Application 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Application 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapter 3. Defining SCLM Project Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Partitioned Data Set High-Level Qualifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Version and Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Accounting Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Technical Setup Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Chapter 4. Migrating the Control Information . . . . . . . . . . . . . . . . . . . . . . . 29

Languages and Translators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
SCLM Languages Used in the Migration Project . . . . . . . . . . . . . . . . . . . . . . . 33
Compilers Used in the Old Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Compiler Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Compiler Options in SCLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Finding VS COBOL II Compiler Options for Application 1 . . . . . . . . . . . . . . . . . . 37
Other Information about Compiler Options for Application 1 . . . . . . . . . . . . . . . . 40
Information about Compiler Options for Application 2 . . . . . . . . . . . . . . . . . . . . 40
Control Information for the Linkage Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Creating LEC and CC Architecture Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 44
DB2CLIST Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
 Copyright IBM Corp. 1993 v

Chapter 5. Migrating the Bulk Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Standard Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Nonstandard Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
COBOL Copy Statements with Leading Data Names . . . . . . . . . . . . . . . . . . . . . 52
COBOL Copy Statements with Prefix Replacement . . . . . . . . . . . . . . . . . . . . . . 54
− INC CA-LIBRARIAN Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Completeness and Correctness Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
SCLM Architecture Reports for Completeness Checks . . . . . . . . . . . . . . . . . . . . 58
Check Correctness Using SCLM BUILDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Chapter 6. Creating High-Level Application Structure . . . . . . . . . . . . . . . . . . 61

Sources of Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Application Structure Information in Your Old Library System . . . . . . . . . . . . . . . 62
Structure Information from Dictionary Reports . . . . . . . . . . . . . . . . . . . . . . . . . 63
Information from Application Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Scan of Source Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Creating the Architecture Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
BUILD and PROMOTE Using the Architecture Definitions . . . . . . . . . . . . . . . . . . . 69
Chapter 7. Post-Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Promote Migrated Application to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Handle Nonmigrated Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Appendix A. Data Extraction from CA-LIBRARIAN . . . . . . . . . . . . . . . . . . . . 73

Copy Selected Members between CA-LIBRARIANs . . . . . . . . . . . . . . . . . . . . . . . 73
Extract Programs and Remove Included Members . . . . . . . . . . . . . . . . . . . . . . . 74
Unload from CA-LIBRARIAN to Partitioned Data Set . . . . . . . . . . . . . . . . . . . . . . 75
Appendix B. Methods and Tools for Analyzing Existing Applications . . . . . . . . 77

Application 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Compiler Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
VS COBOL II Compiler Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Extracting Compile and Link Edit Information . . . . . . . . . . . . . . . . . . . . . . . . . 88
Application 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Find Information for Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Extract Control Information from ENDEVOR Archive File . . . . . . . . . . . . . . . . . . . 97
Appendix C. SCLM Project Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

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

LEC and CC Architecture Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
HL Architecture Definitions and DB2CLISTs . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Appendix E. Tools for Bulk Data Migration . . . . . . . . . . . . . . . . . . . . . . . . 139

Changing Old COBOL COPY Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Handling COPY Prefix Replacement in COBOL Programs . . . . . . . . . . . . . . . . . . 141
Changing 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
Figures
1. Release Procedure for Sample Application 1: General Flow . . . . . . . . . . . . . . 14
2. Release Procedure for Sample Application 1: Data Flow . . . . . . . . . . . . . . . . 15
3. Release Procedure Using ENDEVOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Extraction of Program Sources for Application 1 . . . . . . . . . . . . . . . . . . . . . 20
5. Project Hierarchy for Our Migration Project . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Extraction and Use of Control Information . . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Extraction of Information from Load Modules . . . . . . . . . . . . . . . . . . . . . . . 32
8. Formatted File before Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Formatted File after Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10. Sample Job to Run the IBM AMBLIST Utility . . . . . . . . . . . . . . . . . . . . . . . . 43
11. AMBLIST Output for Assembler Load Module P92N041 . . . . . . . . . . . . . . . . . 43
12. Input Records to Create LEC and CC Architecture Definitions for COBOL Programs 45
13. LEC and CC Architecture Definitions for OS/VS COBOL Program P92N002 . . . . . 45
14. LEC Architecture Definition for VS COBOL II Program P92N046 . . . . . . . . . . . . 46
15. Input Records to Create LEC and CC Architecture Definitions for PL/I Programs . . 46
16. LEC and CC Architecture Definitions for PL/I Program P94N353 . . . . . . . . . . . . 46
17. Input Records to Create LEC and CC Architecture Definitions for Assembler
Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
18. LEC Architecture Definition for Assembler Program P92N041 . . . . . . . . . . . . . . 47
19. HL Architecture Definition Created by the MIGR0050 Program . . . . . . . . . . . . . 48
20. Overview of Bulk Data Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
21. SCLM Migration Utility Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
22. COBOL Copy Book without 01 Level Data Name . . . . . . . . . . . . . . . . . . . . . 53
23. COBOL Copy Book with 01 Level Data Name . . . . . . . . . . . . . . . . . . . . . . . 53
24. COBOL Error Messages for Duplicate 01 Level Data Names . . . . . . . . . . . . . . 54
25. COPY REPLACING: Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
26. COPY REPLACING: Example 2a (COBOL Standard) . . . . . . . . . . . . . . . . . . . 55
27. COPY REPLACING: Example 2b (CA-LIBRARIAN Standard) . . . . . . . . . . . . . . . 56
28. COPY REPLACING: Example 2c (COBOL ANSI 85 Standard) . . . . . . . . . . . . . . 56
29. Partial SCLM Architecture Report for Member #COB2 . . . . . . . . . . . . . . . . . . 59
30. HL Architecture Definition #P1010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
31. HL Architecture Definition #P1100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
32. HL Architecture Definition #C1100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
33. HL Architecture Definition #P92N200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
34. Partial SCLM Architecture Report for Application 1 . . . . . . . . . . . . . . . . . . . . 66
35. HL Architecture Definition @X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
36. HL Architecture Definition @L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
37. Partial SCLM Architecture Report for Application 2 . . . . . . . . . . . . . . . . . . . . 68
38. Job to Copy Members from CA-LIBRARIAN to CA-LIBRARIAN . . . . . . . . . . . . . 73
39. Job to Extract Programs from One CA-LIBRARIAN to Another CA-LIBRARIAN . . . 74
40. Job to Unload All Members from CA-LIBRARIAN to PDS . . . . . . . . . . . . . . . . 75
41. PL/I Program MIGU001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
42. Sample Job to Run Program MIGU001 . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
43. Output Records from Analysis of Load Modules with Program MIGU001 . . . . . . . 81
44. Sorted Output Records from Load Module Analysis . . . . . . . . . . . . . . . . . . . 81
45. VS COBOL II Program MIGU002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
46. Sample Job to Run Program MIGU002 . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
 Copyright IBM Corp. 1993 ix

47. Output from Program MIGU002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
48. Examples of First Lines in Released Program Source Code . . . . . . . . . . . . . . 89
49. ISPF EDIT Macro MIGE0040 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
50. ISPF EDIT Macro MIGE0000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
51. Control Information Extracted with EDIT Macro MIGE0040 . . . . . . . . . . . . . . . . 91
52. Input for REXX Procedure MIGR0040 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
53. Output from REXX Procedure MIGR0040 . . . . . . . . . . . . . . . . . . . . . . . . . . 92
54. REXX Procedure MIGR0040 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
55. ISPF Input Panel Definition for MIGP0040 . . . . . . . . . . . . . . . . . . . . . . . . . . 96
56. SCL for Action B37 and Statement B3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
57. SCL for Statement B3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
58. REXX Procedure MIGR0030 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
59. SCLM Project Definition SCLM3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
60. Authorization Codes for Project SCLM3: ASCLM3 . . . . . . . . . . . . . . . . . . . 102
61. Project Control for Project SCLM3: CSCLM3 . . . . . . . . . . . . . . . . . . . . . . . 102
62. Flexible Database Specification for Project SCLM3: FSCLM3 . . . . . . . . . . . . . 103
63. Type Definitions for Project SCLM3: TSCLM3 . . . . . . . . . . . . . . . . . . . . . . 103
64. Language Definitions for Project SCLM3: LSCLM3 . . . . . . . . . . . . . . . . . . . 104
65. Horizontal Versioning for Project SCLM3: VSCLM3 . . . . . . . . . . . . . . . . . . . 104
66. Language Definition F@ASMH for Assembler H . . . . . . . . . . . . . . . . . . . . . 104
67. Language Definition F@L370 for the Linkage Editor . . . . . . . . . . . . . . . . . . 106
68. Language Definition F@COBL for OS/VS COBOL . . . . . . . . . . . . . . . . . . . . 108
69. Language Definition F@COB2 for VS COBOL II . . . . . . . . . . . . . . . . . . . . . 110
70. Language Definition F@COB22 for VS COBOL II with CMPR2 . . . . . . . . . . . . 112
71. Language Definition F@PLIO for OS PL/I V2 . . . . . . . . . . . . . . . . . . . . . . . 114
72. Language Definition F@AD2 for Assembler H with DB2 . . . . . . . . . . . . . . . . 116
73. Language Definition F@SCMD for DB2 DDL Subcommands . . . . . . . . . . . . . 119
74. Language Definition F@PANELS for ISPF Panels . . . . . . . . . . . . . . . . . . . . 120
75. Language Definition F@@SKEL for ISPF Skeletons . . . . . . . . . . . . . . . . . . . 121
76. Language Definition F@MSGS for ISPF Messages . . . . . . . . . . . . . . . . . . . 122
77. ISPF Panel MIGP0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
78. ISPF Help Panel MIGH0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
79. REXX Procedure MIGR0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
80. ISPF Panel MIGP0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
81. ISPF Help Panel MIGH0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
82. ISPF Skeleton MIGS0010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
83. ISPF Skeleton MIGS0011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
85. ISPF EDIT Macro MIGE0030 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
86. Handling COPY Statements with REPLACING Clause: Overview . . . . . . . . . . . 142
87. COPY Statements and Text for Copy Book S92U905C . . . . . . . . . . . . . . . . . 143
88. Sample Statements Referring to Data Names from Copy Book S92U905C . . . . . 143
89. Sample Job to Run Program MIGU003 . . . . . . . . . . . . . . . . . . . . . . . . . . 144
90. COBOL Program MIGU003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
95. Sample Job to Run MIGR0020 in Batch Mode . . . . . . . . . . . . . . . . . . . . . . 159
x Library Migration
Tables
1. SCLM Types Used in the Migration Project . . . . . . . . . . . . . . . . . . . . . . . . 26
2. SCLM Languages Used in the Migration Project . . . . . . . . . . . . . . . . . . . . . 33
3. VS COBOL II Compile-Time Options in Effect . . . . . . . . . . . . . . . . . . . . . . . 37
 Copyright IBM Corp. 1993 xi

xii Library Migration
Special Notices
This publication is intended to help people who are planning or are involved in a migration
to SCLM. The information in this publication is not intended as the specification of any
programming interfaces that are provided by SCLM. See the PUBLICATIONS section of the
IBM Programming Announcement for ISPF/PDF 3.5 for more information about what
publications are considered to be product documentation.
References in this publication to IBM products, programs or services do not imply that IBM
intends to make these available in all countries in which IBM operates. Any reference to an
IBM 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 not
infringe 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 this
document. 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, IBM
Corporation, Purchase, NY 10577.
The information contained in this document has not been submitted to any formal IBM test
and is distributed AS IS. The information about non-IBM (VENDOR) products in this manual
has been supplied by the vendor and IBM assumes no responsibility for its accuracy or
completeness. The use of this information or the implementation of any of these techniques
is a customer responsibility and depends on the customer's ability to evaluate and integrate
them into the customer's operational environment. While each item may have been
reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or
similar results will be obtained elsewhere. Customers attempting to adapt these techniques
to their own environments do so at their own risk.
The following terms, which are denoted by an asterisk (*) in this publication, are trademarks
of the International Business Machines Corporation in the United States and/or other
countries:
AD/Cycle BookMaster CICS

CICS/ESA DB2 IBM
MVS/ESA OS/2 RACF
SAA
The following terms, which are denoted by a double asterisk (**) in this publication, are
trademarks of other companies:
ENDEVOR LEGENT Corp.

CA-LIBRARIAN Computer Associates, Inc.
PANVALET Computer Associates, Inc.
 Copyright IBM Corp. 1993 xiii

xiv Library Migration
Preface
This book describes and documents how two customer applications from a CA-LIBRARIAN
and ENDEVOR environment were migrated to SCLM. The book also describes the tools
developed to support the migration. The tools can be used as is or modified to suit a
particular customer environment. The migration process and some of the tools and
techniques used during the migration can be applied to application migrations from other
than the two described library systems to SCLM.
This book is intended for project leaders, library administrators, system programmers, and
application 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 are
not should read the manuals listed in the Related Publications section of this document.
Those manuals explain SCLM concepts, provide details about specific commands, and
discuss various uses of SCLM.
How This Document Is Organized

The 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 brief
introduction to the library systems used by the customers who provided us with the
sample applications.
Chapter 2, “Preparing for Migration” discusses general preparation steps and explains
the considerations involved when deciding on a migration strategy. The sample
applications for our migration and how we extracted the data for those applications are
explained.
Chapter 3, “Defining SCLM Project Setup” describes the SCLM project setup used for
the project.
Chapter 4, “Migrating the Control Information” explains the steps performed during the
migration of the control information.
Chapter 5, “Migrating the Bulk Data” describes the steps performed during the bulk
data migration.
Chapter 6, “Creating High-Level Application Structure” explains the considerations we
applied to create SCLM architecture definitions that reflect the structure of our sample
applications.
Chapter 7, “Post-Migration Steps” explains some of the considerations that need to be
addressed after migrating an application, such as promotion to production and handling
of nonmigrated information.
 Copyright IBM Corp. 1993 xv

Appendix A, “Data Extraction from CA-LIBRARIAN” shows sample jobs used to extract
data from CA-LIBRARIAN.
Appendix B, “Methods and Tools for Analyzing Existing Applications” shows the
methods and tools we used to extract control information for our sample applications.
Appendix C, “SCLM Project Definition” contains the project definition for our project and
the language definitions that were either created or modified during the project.
Appendix D, “Generation of Architecture Definitions” contains the tools we used to
create architecture definitions.
Appendix E, “Tools for Bulk Data Migration” describes tools for bulk data migration and
technical details about required changes to source modules from the CA-LIBRARIAN
environment.
Related Publications
The following publications are considered particularly suitable for a more detailed discussion
of 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 Publications

A complete list of International Technical Support Center publications, with a brief
description of each, may be found in:
Bibliography of International Technical Support Centers Technical Bulletins, GG24-3070.
Acknowledgments
The advisor for this project was:
Christian Peterhans
International Technical Support Center - San Jose
The authors of this document are:
xvi Library Migration

Marc Dumas
IBM France
Walther Fitz
IBM Germany
This publication is the result of a residency conducted at the International Technical Support
Center, San Jose.
Thanks to the following people who reviewed this document and made technical
contributions:
Ron Blackwell
IBM Canada
Claude Bourrec
IBM France
Ralph Naegeli
IBM Switzerland
Ueli Wahli
Thanks are also due to the many other collaborators and reviewers who contributed to
improve this document.
Preface xvii
xviii Library Migration
Executive Summary
The objective of our project was to migrate applications from vendor library systems to
SCLM and to document the migration in an ITSC Redbook.
The basic steps of our migration strategy can be applied to other migrations, even though
the approaches used to address the issues may vary from installation to installation. Our
migration can be viewed as an example that shows the conceptual steps of a migration from
a vendor library to SCLM. Understanding the methodology we used to succeed with the
migration, rather than simply reusing the tools developed, should prove beneficial.
We selected two applications from two different vendor library systems, CA-LIBRARIAN and
ENDEVOR, for our project. These two library systems offer different levels of functionality.
CA-LIBRARIAN is a library management system with no software configuration support
functions. ENDEVOR is a software configuration and library management system. We
wanted to show the different considerations that apply depending on how sophisticated your
existing environment is.
We did not install either of the vendor library systems in our environment. We extracted all
data deemed useful from the source environments before we started our project, and we
had no access to additional information during the project. A customer migration should be
easier and may require fewer intermediate steps.
We did not try to clone the existing environment because we believe that cloning does not
give 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 as
general-purpose tools. You may want use the tools as a starting point for developing your
own tools or modify them to suit your environment.
It turned out during the project that the most critical factor for a successful migration to
SCLM is the availability of control information from the existing environment and information
about the application structure. Of lesser importance is whether the vendor library provides
this control information or whether the information is available elsewhere in your
environment. This book shows examples for both situations. The less information about
your application and its structure that is available from the existing environment, the more
you have to invest during the migration, but the benefits from maintaining the application
under SCLM will pay off even more.
The total cost of a migration to SCLM depends on the existing environment and on whether
you want to clone the existing environment with SCLM. The cost for the actual migration
might be small compared to the investment to introduce software management discipline in
your environment. However, proper software management pays off big in the future in terms
of reduced development cost, management of configuration changes, software auditability,
application reliability, and production stability.
 Copyright IBM Corp. 1993 1

2 Library Migration
Chapter 1. Introduction
Software Configuration and Library Manager (SCLM) is the IBM* software configuration and
library management system for AD/Cycle*. Many customers who want to migrate to SCLM
today have installed library systems, such as CA-LIBRARIAN**, PANVALET**, or ENDEVOR**.
In addition they may have an in-house developed system to control their software
development and production environment.
Because SCLM is both a software configuration and library manager, migration to SCLM
does not only consist of moving the application code under SCLM control. The more
challenging part of the migration is the handling of information controlling the software
configuration.
This book shows how information from existing library systems can be migrated to SCLM
and presents the results of such a migration with sample applications used during our
project.
Why Migrate to SCLM?

SCLM is a software configuration and library management system. Most of the existing
library systems provide only the library management component. After you have migrated
to SCLM you can control all of your software throughout the development life cycle.
SCLM implements a structured concept for software development and maintenance. The
SCLM project definition describes the organizational structure of the project, sometimes
referred to as the promotion hierarchy. The SCLM architecture definitions describe the
structure of the applications. These architecture definitions allow the SCLM build process to
automatically rebuild part or all of an application when dependencies have changed.
Software developers no longer have to figure out by themselves which modules might be
affected by a change.
The product's ease of use will more than pay for the investment made in the migration
process. New people joining a development group can better understand existing
applications that are clearly structured and become productive quickly. SCLM also helps
experienced people avoid errors and keep the application software consistent.
SCLM allows you to control a wide range of software types. SCLM offers language
definitions for the standard programming languages, such as COBOL, PL/I, Assembler, C,
FORTRAN, and Pascal. SCLM also has language definitions that handle the preprocessors
for target environments like CICS* or DB2*. SCLM supports the DB2 BIND mechanism, CSP
generation for all target environments, BookMaster* documents, interpreter modules like
TSO CLISTs or REXX procedures, and the like.
Screen Definition Facility II (SDF II) Release 3 provides an interface that enables you to use
SCLM to control your screen definitions for all SDF II target environments from the very first
development step. Other library systems can only control output from such products as SDF
II, 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 production
libraries into the map generation tool.
The modular design of SCLM allows you to easily modify, or add new, language definitions
without impacting the development environment.
SCLM is more than a tool to administer your software. You can bring all of your application
documentation under SCLM control. Using the Workstation Interactive Test Tool (WITT), you
can add test cases to your software architecture definition. Thus, you can promote
documentation and test cases together with your basic software modules through your
project hierarchy. In addition, using SCLM's versioning function, you can keep track of the
history of your documentation.
If you split your SCLM accounting data set into several data sets (which is possible since
SCLM Release 3.4), you can RACF* protect not only your bulk data sets to match your
administration structure but also your SCLM control data. You can define separate SCLM
accounting data sets for different groups of the project to prevent unauthorized access to
SCLM control data.
SCLM is part of ISPF/PDF and is therefore available in any ISPF/PDF installation and can be
used immediately. That availability not only saves money but also eliminates the need to
maintain an additional software product all the time.
If you migrate to SCLM, you get the benefits of a product that has a strong software
development concept but also gives you the flexibility to meet your individual requirements.
New preprocessors and compilers can be supported by just adding new language
definitions. User exits allow you to integrate additional functions required in your
environment, and the project definitions can reflect your organizational structures.
Objectives and Scope of the Project

The objectives of the project were to migrate a customer's library data to an SCLM
environment and describe the required migration steps.
Some preparation of the migration was performed before the project began to bring a
complete set of data from the customer environment to the project. The project duration
was 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.5
installed. A vendor library was not installed on the system, so we had to start with data
unloaded 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 customer
environment before the project started. We did not perform postmigration steps, such as
deleting migrated modules in the old library system, and, outside the real customer
environment, we could do only limited regression testing.
The migration process is quite host-bound, and we did not use the workstation interface of
the 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 library
systems. We expect that the lessons learned from this project are applicable to migrations
from other vendor tools.
“Sample Application 1” on page 12 and “Sample Application 2” on page 16 contain a
detailed description of the applications and the use of the library systems in the customer
environments 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 deliverables
that are input to the physical migration. This step also defines the project structure and
identifies 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 SCLM
environment.
3. Migrating the Control Information
This step covers the detailed analysis of the existing control information and the
transformation 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 the
high-level application structure to SCLM. The deliverable is the complete application
built under control of SCLM.
6. Post-Migration
This step brings our application into production and provides test and validation. It
includes cleaning up the old environment.
Vendor Library Systems

This section contains a short description of the two library systems used by the customers
who provided us with the sample applications. The two library systems are:
CA-LIBRARIAN
ENDEVOR.
Chapter 1. Introduction 5
CA-LIBRARIAN
CA-LIBRARIAN is a storage medium for modules that can be represented in 80-byte
card-image format records. CA-LIBRARIAN is most useful for source programs and offers
features for auditing and control.
The basic component of CA-LIBRARIAN is the master file, which is a direct-access data set
with 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. First
you must initialize archiving for a master file, and then you can specify archiving for
individual modules.
CA-LIBRARIAN started out as a batch tool. Now, online interfaces are available for some
environments, for instance, the ELIPS interface for a TSO/ISPF environment.
Batch CA-LIBRARIAN operations are activated by control statements. These control
statements can carry special options. There are seven basic types of CA-LIBRARIAN control
statements:
Execution control statements that govern general execution of CA-LIBRARIAN for the
whole 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 or
include another module
Utility control statements.
Processing options can be specified after the commands in a control statement. Processing
options can control processing, such as handling of archiving levels, sequence numbering,
invoking expansion of CA-LIBRARIAN COBOL COPY verbs, invoking the group processing
option (GPO), and generating a master file index listing. Not all processing options can be
used 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 status
values designate the degree of protection.
ENDEVOR
ENDEVOR is a family of software products that provides automation and control of the
software development life cycle. ENDEVOR's function spans from initial system design and
development through implementation and ongoing maintenance. In the case of
vendor-supplied software, ENDEVOR supports installation and maintenance, including
upgrades. 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 partitioned
data sets (PDSs), library management systems (PANVALET and CA-LIBRARIAN), and
executable libraries.
To manage the inventory, ENDEVOR uses a concept of logically and physically separate
structures. An inventory item (element) is identified to the ENDEVOR Inventory Manager
by 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 the
inventory's physical structure.
ENDEVOR manages multiple data sets with different data set organizations and
characteristics to store the physical objects independent of their logical classification.
A base/delta technology is used to store the source elements within the application
inventory. The base/delta files can be PDSs, VSAM files, or BDAM files. ENDEVOR
provides an interface to read directly from and write directly to PANVALET and
CA-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 change
event.
Control of the process and procedures that translate sources into executables. The
procedures are called processors and are written in job control language (JCL)
statements. The appropriate processor is determined by the type and element name
information of the logical inventory classification.
A link between the source code and its related executable forms. The technique used is
called footprinting. ENDEVOR places an encrypted audit stamp (footprint) in the output
source, object, or load modules created.
Control of the movement of software release packages. ENDEVOR provides a software
control language (SCL) to manipulate and move objects or portions of an application
system through the predefined levels (stages) of ENDEVOR. There are two predefined
stages per ENDEVOR environment: STAGE 1 and STAGE 2.
For software distribution, the TRANSFER utility extracts objects from one ENDEVOR site
in a format that allows the transfer to another ENDEVOR site.
An ARCHIVE function to back up an entire environment. This function extracts objects
and related control information from an ENDEVOR environment and writes them to an
archive file. This file is input to the RESTORE function.
A set of standard reports that provide information about the inventory of software
objects:
− 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 seven
reports you want in the standard report JCL.
Chapter 1. Introduction 7
The standard ENDEVOR reports are not the only way to find information about software
objects. 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 to
be migrated.
A batch or interactive interface for all functions and actions. For example, we could
have used the interactive interface to get the same information that we have in our
report listings.
8 Library Migration
Chapter 2. Preparing for Migration
In this chapter we explain how to develop a migration strategy, define your project
organization, and select a pilot application. We describe the sample applications for our
migration and show how we extracted the data for those applications.
Develop Migration Strategy

The 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 to
answer two questions:
What to do?
How to do it?
Many factors influence the migration strategy, such as the size and organizational structure
of 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 a
phase of heavy maintenance.
Normally, in a large enterprise, a number of different applications work more or less
independently. Therefore, before migrating to SCLM you must identify the applications in
your enterprise in order to know which to migrate.
Not all applications should be migrated simultaneously. We recommend that you migrate
one application in a pilot project and then migrate application by application. Therefore, you
must select the application for the pilot project first.
The above considerations should lead you to formulate a migration strategy comparable to
the following:
1. Create or use an application inventory of the enterprise to determine characteristics of
the 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 and
which 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 of
the project, selection of a project leader, and setting up a project plan. We give more
details 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” on
page 12.
4. Migrate the pilot application.
During migration of the pilot application you will find the best method for migration of
the remaining applications in your enterprise. You can customize existing, and perhaps
develop new, tools that make migration easier.
After migrating the pilot application you will know your specific organizational and
technical problems and how they can be solved. You will know the benefits of using
SCLM for the enterprise and you can better estimate time and costs for the migration of
the remaining applications. The skills required for the migration project are established
and 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 and
refine 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 the
following 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 to
create 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 environment
without tricky user exits for additional customer-specific functions.
We would build one SCLM project only and separate the two applications using different
SCLM authorization codes.
We would play the roles of all people involved in a migration project and therefore not
set up dedicated RACF profiles.
Our primary objective would not be to develop general-purpose migration tools.
Define Organizational and Administrative Structure

We recommend that you perform the migration as a project and follow a process that
includes several steps. First you define the project organization and identify the people
involved and their roles in the migration project. We defined the following four roles for the
migration:
10 Library Migration
Project leader
SCLM support person
Library administrator
Application developers.
The project leader coordinates migration steps and evaluates the cost of the project. The
project leader is responsible for setting up a project plan, proposing this plan to information
systems (IS) management for approval, and ensuring that the project plan is followed during
the 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 technical
aspects of the migration. The SCLM support person is also responsible for educating the
library administrator during the migration and the developers who will use SCLM after the
migration. The SCLM support person must be experienced in implementing SCLM.
The library administrator has a working knowledge of the existing library system and
performs the migration together with the SCLM support person. One objective of the library
administrator is to develop his or her SCLM skills during the migration.
The application developers know the applications to be migrated. They assist the SCLM
support 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 not
necessarily correspond one-to-one to the people required. You can combine several roles in
one person if appropriate. That is, application developers, SCLM support, and library
administrator may be one or several persons. However, for the project to be successful, you
should have a separate project leader.
The degree of involvement in the project of the different roles varies. You should expect it to
be about 90% (workload) for the SCLM support person and the library administrator and
about 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 test
phase, especially if code integrity problems are discovered during the migration.
To evaluate the amount of effort required to migrate an application to SCLM we recommend
that 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 Application
The following criteria influence the selection of a pilot application:
Importance As with any other migration, you should not select one of the
most critical business applications for the pilot project.
Rather, you should select a less critical application, which will
result in a safe and quick migration. You can then apply the
results of the pilot migration to the more critical business
applications.
Application technology The pilot application should not be too simple compared to
other applications of the enterprise, but it should be simple
enough to prevent too many simultaneous problems. Module
types and translator languages should match those of other
important applications.
Size We do not recommend that you select an application with
thousands of modules for the pilot project. However, the pilot
should be large enough to provide relevant information for the
mass migration. Should you select a pilot application with
only a few modules of one type, you should handle them as
you would many modules. This approach will make the
experiences of the pilot project more applicable to the mass
migration.
Knowledge of Application People working on the pilot project should have a reasonable
working knowledge of the pilot application.
Stability The application selected for migration should not undergo
maintenance at the same time as it is migrated.
We recommend that you establish a short, frozen zone for the
duration of the migration and that you only migrate and test
the production version of the application. From a technical
point of view it is possible to migrate development and test
levels too, but this will require a sophisticated change
management process for the project.
Code stability Only a stable application status allows you to distinguish
between problems that result from errors in the migration
process and those that result from existing instabilities and
errors in the application.
Our pilot project consists of two different applications to show a wide range of potential
considerations and problems encountered in a migration to SCLM, but by no means does it
cover the whole range of module types and languages you can handle with SCLM. Our pilot
project shows how a migration can look conceptually. Even though individual technical
details may differ from installation to installation, the general concepts of our pilot migration
are generally applicable.
Sample Application 1
This section describes sample application 1, its function, its implementation in the old
environment, and its use of functions of the old library system.
Description
Application 1 originates from a customer's IS method and tools department. The application
controls the existing release procedure from development to production for programs and
for other software modules, such as CICS BMS macros; IMS database control blocks (DBDs),
program specification blocks (PSBs), and message format service (MFS) macros; TSO
CLISTs; REXX procedures; and ISPF modules.
The application provides a dialog user interface to support the release procedures, keeps
track of intermediate and final module status, provides logging of important activities, and
offers utility functions for reporting and cleanup.
The customer wants to maintain use of the release procedures until all other business
applications are migrated to SCLM and therefore wants to migrate application 1 to SCLM
first.
The application is a TSO/ISPF application with programs written in COBOL, Assembler, and
PL/I. The TSO/ISPF pieces consist of TSO CLISTs, ISPF panels, skeletons, and message
members. The whole application consists of:
168 programs
129 macros and included members
99 CLISTs
113 ISPF panels
36 message members
260 skeletons.
The application is handled like all other business applications at that customer site; that is, it
is maintained and released to production with its own functionality.
Release Process
The customer uses the CA-LIBRARIAN library system for program source files. Our sample
application 1 controls the release of modules to the so-called R-Test and production
environments.
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 load
modules—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 DP
processes 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-LIBRARIAN
control data set for all module types.
Interpreted modules, such as TSO CLISTs or ISPF panels, are copied from one PDS to
another 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, are
stored as individual members in CA-LIBRARIAN.
Special copy book handling features of the CA-LIBRARIAN COPY option are used for COBOL
programs. Please refer to “Nonstandard Source Code” on page 52 for more details. All
COBOL COPY statements are replaced with the actual copy code from the same source
CA-LIBRARIAN using the CA-LIBRARIAN COPY option. A user program resolves nested VS
COBOL II copy books because the CA-LIBRARIAN COPY option does not support nested
copy books.
For Assembler and PL/I source code the CA-LIBRARIAN − INC statement is used instead of
the compiler standard statements %INCLUDE and COPY, respectively. The included
members replace the − INC statements.
A source program is then presented as one single file to the compiler and stored as one
single file in the CA-LIBRARIAN data set of the target environment. Special leading and
trailing 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 are
stored 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 from
development to production. The release from development to R-Test works the same way.
1A Copy source file by replacing COPY and − INC
statements with the full text of the included members and
adding 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 release
procedure from test to production corresponding to the DP path in Figure 1. The application
developers (1A + 1B) move the modules into “wait” libraries. The production
administrators (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 load
modules 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 the
source code is copied to an archive file that is later saved to tape by a separate
archiving system.
Released modules are deleted from the development libraries; only the included members
remain in their last-used state. Source modules can be copied back from the production
CA-LIBRARIAN to the development CA-LIBRARIAN for maintenance purposes. This process
reduces the source code and reintroduces the original COPY and − INC statements.

Sample Application 2
This section describes sample application 2, its function, its implementation in the old
environment, and its use of functions of the old library system.
Description
Application 2 originates from a customer's IS production department. The application was
developed by the production department because of the special functionality it provides.
The application extracts information from the library system used and stores that information
in relational tables. Therefore, this application extends the functionality of the library
system.
Application 2 is a DB2 application written in Assembler and consists of:
20 programming objects
Data definition language (DDL) statements
DB2 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 development
department does not use any tool to provide software configuration and library management
functions.
All customer applications in production are under ENDEVOR control. ENDEVOR is used to
manage a preproduction test and to handle distribution to various production environments
on separate MVS systems.
When developing a new application, developers manage application objects (configuration
and library management) without tool support. After coding and testing, they give their
“package” to the production administrator, who belongs to the IS production management
organization.
The package must contain the information required for compile and link edit. The production
administrator 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 the
process involved between the development and production departments.
The MOVE action provides for promotion from preproduction to production. When the
package is ready to be distributed to the target sites, the production administrator prepares
the 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 to
ENDEVOR to get the object. After they change the object and test it, they must give it back
to ENDEVOR. The action to put the object back into the ENDEVOR system is REPLACE with
the same information as required by the ADD action plus a CCID.
ENDEVOR uses different file organizations depending on the type of data. Control and
attribute 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 data
sets, or BDAM data sets. The customer uses BDAM data sets to store the base and delta
sources. Load modules are stored in PDSs.
Figure 3. Release Procedure Using ENDEVOR. Application coding and testing are not under control of
the ENDEVOR system. The production department translates the sources into executables,
tests the application in the preproduction environment, and moves the application to up to
six different production sites.
Extract Data for the Sample Applications

Because the vendor library systems were not implemented in our environment, we extracted
the data at the customer sites and installed it in our environment.
This section describes the extraction process for the two sample applications and shows the
data 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 a
software configuration tool you must use other methods to identify all modules of an
application. The following information sources may help:
Application documentation
Naming conventions
Listings from source code scans (for copy books)
Dictionary reports
Control information created during the release process.

2. Extract the modules to tape. CA-LIBRARIAN utilities are required to unload modules
from CA-LIBRARIAN data sets to PDSs. For copy books you have to build member lists
using the output from the first step.
Step 1: Identify all Modules

Dictionary information in the customer environment was only available for dependent
members of COBOL modules. However, most of the modules follow rigid naming
conventions.
We primarily used the naming conventions to find all modules of the application. For all TSO
CLISTs and ISPF modules the three-character prefix FUA identifies the application. The
fourth character identifies the module type as follows:
FUAC.... for TSO CLISTs
FUAP.... for ISPF panels
FUAS.... for ISPF skeletons
FUAM.... for ISPF message members.
Some other ISPF message members, for example, ALLG...., were also used and the
members were extracted too. The programs for this application use the prefix P92N followed
by a three-digit number. For example:
P92N0..
P92N2..
P92N3.. .
Some subroutines with different naming conventions are called by the programs. To find
these additional programs, scans of the source modules were performed. We used the
CA-LIBRARIAN utility with the − SCAN option. Another possibility is to extract the already
identified 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. The
CA-LIBRARIAN data set for production contains the program source with the expanded
text of the included member. The names of the included members can be extracted
from the comment lines inserted when the included member was expanded in the
source program (refer to “Release Process” on page 13). Because all Assembler user
macros are included with − INC statements and expanded in the program source for
archiving 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 do
not 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 per
module 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 Assembler
macros
Load modules from the production link library
TSO CLISTs, ISPF panels, skeletons, and message members from the corresponding
PDSs
A report for all the selected program modules from the CA-LIBRARIAN file that holds
module control information.
Source code for programs, copy books, and Assembler macros: Figure 4 on page 20 shows
this source code extraction graphically. The extraction was performed as follows:
Modules were copied from the source CA-LIBRARIAN to a temporary CA-LIBRARIAN
using member lists created when we identified all modules in step 1.
This task separated the modules of the sample application from thousands of modules
in the enterprise. Appendix A, “Data Extraction from CA-LIBRARIAN” on page 73
contains sample jobs for this task.
Modules were unloaded from the temporary CA-LIBRARIAN to a PDS. Because all
members were copied, no member list was required as input to this job. “Unload from
CA-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 the
development CA-LIBRARIAN are identical to those released to production. Such a
procedure is available but we do not describe it here because it is not of common interest
and 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 analysis
of the included control information. For details see Chapter 4, “Migrating the Control
Information” on page 29 and Appendix B, “Methods and Tools for Analyzing Existing
Applications” on page 77.
Load modules: Load modules were copied directly from the load library PDSs using
member lists from step 1. These load modules were used to extract information. Refer to
Chapter 4, “Migrating the Control Information” on page 29 for details on the information that
can be extracted from load modules.
TSO CLISTs and ISPF modules: These modules were copied directly from their PDSs using
member 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-LIBRARIAN
in their last used state.
P Programs with COPY (or − INC) statements.
The reduction to this original form is done by a customer-written
program.
PP Programs with full text of included members and
information 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 are
direct 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 information
Source data
ENDEVOR reports.
Source Data with Control Information

We used the ENDEVOR ARCHIVE function to extract both source code and control
information from the ENDEVOR environment to a single sequential file. This archive file
contained all objects of application 2 (source code, macros, DDL, DB2 BIND statements) and
attribute information (date/time for creation and last change, member version, and so on) for
each object.
The archive file can be used to import an application and the application-specific
environment into another ENDEVOR system using the RESTORE function. Therefore, the file
created 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 data
control 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 to
extract the source code because the TRANSFER utility extracts data directly into PDS
members. Using the archive file would require a tool to extract the source code into PDS
members. Only the control information from the archive file was used.
We could not provide a direct extraction from the ENDEVOR environment to SCLM PDSs
because ENDEVOR was not available in our environment. We used the TRANSFER utility to
extract 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 Source
Code” 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 LIST
action with processor as the selection criterion in the WHERE clause. The resulting list can
be used to drive the TRANSFER process.
ENDEVOR Reports
We created all the reports (listings) that were thought to be helpful for the analysis of the
application; that is, all seven standard reports and an SCL PRINT report for all objects to be
migrated.
Refer to “ENDEVOR” on page 6 for a description of the ARCHIVE and TRANSFER functions
and the standard reports.

Chapter 3. Defining SCLM Project Setup
Before migrating to SCLM you should know whether you want to implement an environment
that matches your existing environment as closely as possible or an environment that takes
the best advantage of all the functions SCLM provides.
If you clone your existing environment in SCLM, you can minimize the number of changes in
your existing organization and procedures. If you decide to take advantage of all of the good
functions SCLM provides, you may need to change your existing organization and
procedures but you will greatly improve your software development and configuration
management processes. The kind of environment you decide to implement will influence the
setup of your SCLM project for migration.
We decided to set up the project definition manually for two main reasons. First, there was
no one-to-one correlation between each environment. Second, we evaluated all options
specified in the existing environment to find out how those options could be adapted to the
SCLM target environment. In this chapter we explain the choices we made and where to
find 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 same
project database. The main reason for that decision was that we had only one application
per vendor library environment to migrate. The migration approach will not be affected if
you decide to use multiple projects or different high-level qualifiers for the groups in your
environment.
Partitioned Data Set High-Level Qualifier

Finding the best solution for the high-level qualifiers is not easy because you are not starting
from scratch. Therefore, you must take into account existing information when selecting the
most appropriate choice for the PDS high-level qualifiers. For example, some configuration
management systems, such as ENDEVOR, keep information that could affect your high-level
qualifier selection (refer to “Set Up High-Level Qualifier with Information from ENDEVOR” on
page 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 business
domain.
Naming conventions for the PDS high-level qualifiers are another example of existing
information you must consider. Before you decide to change the existing naming
conventions you should understand why they were chosen in the first place.
You may want to conduct a study with the library administrator and application developers
before starting the migration project to compare advantages and disadvantages of different
solutions and to choose the most appropriate. The solution must be valid for all applications
that will be migrated after the pilot project.
Since release 3.4, SCLM allows for complete customization of its PDS names using the
FLMALTC 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 to
combine those projects into an enterprise project (enterprise high-level qualifier). This
subject is specifically discussed in the ITSC Redbook AD/Cycle: SCLM 3.4 New Functions
Usage Guide, GG24-3833.
In our migration project, we did not have access to customer representatives who could
answer questions for both applications, so we decided to use one common PDS high-level
qualifier. 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 information

in CA-LIBRARIAN that can be directly correlated to the SCLM high-level qualifier because
most customers do not use separate CA-LIBRARIANs for different applications. We
recommend that you develop new naming conventions for SCLM project names and use
those names as high-level qualifiers for the PDSs.
If you have an existing naming convention where one (or more) character identifies an
application, you can include those characters in the high-level qualifier. For example, an
application now identified by “92” could lead to an SCLM project and PDS high-level
qualifier of “S9200.”
Set Up High-Level Qualifier with Information from ENDEVOR: ENDEVOR supports the
concept of application domains by keeping system and subsystem information (refer to
“ENDEVOR” on page 6). A system represents a logical grouping of inventory elements as
they apply to major applications, departments, or work areas within the organization. For
example, system could represent applications, such as Finance or Personnel. A subsystem
is a logical subclassification within a system. For example, the system finance application
might 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 the
application 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-level
qualifier.
Groups
Because we mixed our two applications in the migration process, we set up a common
project. Therefore we did not use a naming convention for promotion hierarchies from the
existing environments.
We built a simple project hierarchy with three layers and two development groups, one for
each application to be migrated.
In the development groups we received modules from external files during the SCLM
migration and created architecture definitions to handle them. Then we built the
components and promoted them to the TEST layer. Figure 5 on page 25 shows the project
hierarchy 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 from
CA-LIBRARIAN to SCLM, and MIG2 is used to migrate application 2 from ENDEVOR to
SCLM. Authorization codes are shown beneath each group.
Even if your final project structure is sophisticated, we recommend that you create a simple
structure for the migration. You can use alternate project definitions to define your final
project structure in parallel. This approach is particularly useful when you migrate on an
application domain basis with many applications in a single SCLM project. So, while some
applications are being controlled by SCLM, you can migrate other applications through the
special migration hierarchy. To build a more complex project structure that takes advantage
of flexible naming conventions for PDSs refer to the ITSC Redbook AD/Cycle: SCLM 3.4 New
Functions Usage Guide, GG24-3833.
We used authorization codes to separate our two applications: FUA for application 1 and
NDV for application 2 (see Figure 5). Appendix C, “SCLM Project Definition” on page 101
shows our project definition.
Set Up Groups with Information from CA-LIBRARIAN: There is no information in

CA-LIBRARIAN that can be directly correlated to the SCLM group.
If you use separate CA-LIBRARIANs for different test and production levels that represent a
promotion hierarchy, one part of the CA-LIBRARIAN data set names that identifies these
levels can be reused as the SCLM group qualifier.
Set Up Groups with Information from ENDEVOR: ENDEVOR keeps information related to
levels or phases of the development process. These levels or phases are called stages and
are provided in the logical structure of ENDEVOR. Therefore, stages do not affect the
naming 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 either
the standard name (STAGE1 and STAGE2), an identifier (A and B), or a name (TEST and
PROD).
Chapter 3. Defining SCLM Project Setup 25

There is a strong correlation between SCLM groups and ENDEVOR stages, but we also have
to keep in mind ENDEVOR's environment information. It is not easy to translate the notion of
an ENDEVOR environment to SCLM directly. One way to handle that information is to mix it
with stage information in the SCLM groups; that is, both environment and stage information
become part of the group names. Because group names are restricted to eight characters
in SCLM, environment and stage names must be truncated to four characters if they are
longer than four characters in the existing environment.
ENDEVOR provides MOVE processors to promote objects from stage to stage. This implies
that objects are physically moved between the stages, which corresponds to specifying the
KEY option in the SCLM group definition.
Types
We 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. All
variations within one language, such as with or without DB2, and different releases of a
single 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 in
that case, you should use a naming convention that allows you to differentiate by name
between source code written in different programming languages.
You may have to review the type definitions during the migration of the application control
information.
Table 1. SCLM Types Used in the Migration Project

Type Name Members Included Used for
Application
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 differentiate
between 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 as
ASM, DBRM, LOAD. You can also use customer standards that deviate from the IBM
SCLM proposed names. What is important here is to take the opportunity of the
migration to implement a new, or enforce an existing, naming convention.
Types not provided by the existing environment but required by SCLM, such as
ARCHDEF, DB2CLIST, DB2OUT.
New types implemented in SCLM, such as OBJ, LIST, LMAP. SCLM provides code
integrity between all kinds of related data, and you may want to keep compile and link
edit listings synchronized with your source code and load modules.
In an ENDEVOR environment you can find information about type names in ENDEVOR report
1 (System Inventory Profile). This report should be executed using the following selection
parameters:
Environment
System
Subsystem
Stage.
You may want to use the existing type names especially if your migration objective is to
clone the existing environment.
The CA-LIBRARIAN library system only stores source files. The term “type” is not used by
CA-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 the
naming conventions.
Version and Audit

We decided to collect version and audit information for all types containing source members
in the top layer, PROD.
Set Up Version and Audit with Information from ENDEVOR: Versioning and auditing are set
up in the existing ENDEVOR environment for application 2. You can create an element
report using option “HIS” (for History) to show the ENDEVOR information related to
versioning.
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 used
was the fact that the customer had ENDEVOR collect version and audit information for
application 2. Therefore, we had to implement versioning and auditing in our target SCLM
environment.
Chapter 3. Defining SCLM Project Setup 27

Languages
Ask 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 and
language name ( L A N G = 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 language
definitions for the migration. This subject is discussed in “Languages and Translators” on
page 33.
Accounting Data Set

We decided to split the SCLM accounting data set for our project. We defined an accounting
data set for each layer in our project hierarchy.
Technical Setup Steps

The technical setup has no special requirements in the context of migration. We must follow
the 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 ISPF
installation data sets, for example, to prevent editing of SCLM members from outside
SCLM.
You can find general information about the technical SCLM setup in the ITSC Redbook
Software Configuration and Library Manager WorkStation Platform/2 Usage Guide,
GG24-3538.
Chapter 4. Migrating the Control Information
Migration 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 the
new SCLM environment, keeping the application itself unchanged.
If your old library system does not provide a real software configuration component, as is
the case for CA-LIBRARIAN, you must find all the required information by analyzing the
existing modules and/or by looking into control information files that have been filled by
customer-specific procedures during the release process. Therefore, migration of control
information may vary considerably from one installation to another. In this chapter we show
how we migrated the control information for the two selected sample applications and
describe 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 steps
required to extract and use control information. Figure 6 shows the basic flow for handling
control information in our migration project. The steps are discussed in more detail in the
sections that follow; technical details are listed in Appendix B, “Methods and Tools for
Analyzing Existing Applications” on page 77.

Figure 6. Extraction and Use of Control Information. The numbers in the figure are explained in the
text.
The following remarks refer to the numbers in the figure:
(1) PDS with released programs extracted from CA-LIBRARIAN. This corresponds to file
PP in Figure 4 on page 20. Formatted control information is stored in leading
comment records. These comments were added by the customer's release
procedure.
(2) EDIT macro MIGE0040 separates the comment records from the source code for each
program. A PDS member is created for the comment records of one program. All the
PDS members are copied together into one single file.
(3) Control information records are sorted by module type (COBOL/ASM/PLI). For some
very old modules the module type was added manually. The information about the
translator options is used to select defaults for the SCLM language definitions.
(4) REXX procedure MIGR0040 converts the information into a common format for
application 1 and application 2. All previously specified options that are defaults in
the 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—compilation
control (CC) architecture definitions.
(10) REXX procedure MIGR0010 creates the LEC and CC architecture definitions. It can be
used unchanged in other environments, or it can be easily adjusted to other input
formats.
(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 load
modules. Two types of information are extracted:
Compiler product and release information
For VS COBOL II modules, COBOL information bytes that contain information about the
compiler release and the options used at compile time.
You can use the methods presented here in other environments. They are based on the
structure of the load modules. You will find it particularly useful to apply these methods if
you cannot extract the required control information elsewhere. We found most of the
required information to create the LEC and CC architecture definitions from the steps shown
in Figure 6 on page 30.
The information extracted from load modules helped us to decide which SCLM languages to
use in our project and to identify where old compiler releases were used in the old
environment. The statistics on VS COBOL II compiler options served as a basis for setting
up the SCLM translator defaults for VS COBOL II. The resulting files of this extraction
process contain the module names that we used to create member lists for copying in the
bulk data migration.
Chapter 4. Migrating the Control Information 31

Figure 7. Extraction of Information from Load Modules. The numbers in the figure are explained in
the text.
(1) Load modules from the customer's production environment for the two sample
applications.
(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 option
CMPR2/NOCMPR2 was used to split into SCLM languages. Reformatting means
removing everything except the module names and adding “SELECT MEMBER=” in
front of the module name to create input files for IEBCOPY.
(7) The member lists are used during bulk data migration (refer to Chapter 5, “Migrating
the Bulk Data” on page 49).
All steps are discussed in more detail in the sections that follow. Technical details are listed
in Appendix B, “Methods and Tools for Analyzing Existing Applications” on page 77.
Languages and Translators
SCLM offers a wide range of language definitions, many more than you normally need in
one project or even in the whole enterprise. You must find out which of these language
definitions are required in your environment, whether some customization needs to be done,
or whether additional language definitions must be developed—because you use a special
preprocessor 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 still
some old OS/VS COBOL programs. You must find out which preprocessors (CICS, SQL) are
used 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 option
CMPR2 for Release 2 source compatibility
OS/VS COBOL Release 2 with option LANGLVL(2) for ANSI 74 or with option
LANGLVL(1) for ANSI 68 standard support
OS PL/I Version 2 with option CMPAT(V2) or option CMPAT(V1) for source compatibility
with 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 normally
uses a set of compiler options either by using the defaults or by explicit specification of
the options in the build translator definition.
For modules that need other compiler options, those options must be specified in a CC
architecture definition. Overriding of compiler options specified in a translator definition
must be allowed by specifying OPTFLAG=Y in the FLMTRNSL macro and OPTOVER=Y
in the FLMCNTRL macro (default value).
Have two different SCLM language definitions for the same compiler. Each language
definition works with a different set of compiler options.
If all modules with a particular language use the same set of compiler options, you may
want to inhibit overriding of compiler options by specifying OPTFLAG=N in the
FLMTRNSL 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 the
language definitions listed in Table 2 for our project.
Table 2 (Page 1 of 2). SCLM Languages Used in the Migration Project. Member names
with FLM@... refer to the original IBM-supplied language definitions in
the ISR.V3R5M0.ISRMACS library of ISPF/PDF Version 3 Release 5.
Member names with F@... are customized language definitions for this
project.
Member Language Language Definition for Used for
Name Name Appl.
FLM@ARCH ARCHDEF SCLM architecture definition language 1+ 2

Table 2 (Page 2 of 2). SCLM Languages Used in the Migration Project. Member names
with FLM@... refer to the original IBM-supplied language definitions in
the ISR.V3R5M0.ISRMACS library of ISPF/PDF Version 3 Release 5.
Member names with F@... are customized language definitions for this
project.
Member Language Language Definition for Used for
Name Name Appl.
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
Because many COBOL modules in application 1 were compiled with VS COBOL II Release 1
or Release 2 or with VS COBOL II Release 3 using the CMPR2 option, we decided to use two
translators for VS COBOL II. (Migration of these modules to the latest COBOL standard is
planned 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 “ o l d ”
modules that reside in the same library as the “ n e w ” modules. You can use the SCLM
DBUTIL service with “LANGUAGE” as a selection criterion for this purpose.
Because our sample applications contained a limited number of OS/VS COBOL modules that
require option LANGLVL(1) and PL/I modules that require option CMPAT(V1), we used only
one language definition for those two compilers and specified compatibility options as part of
CC architecture definitions for the modules affected. Details on compiler options and CC
architecture definitions are discussed in “Compiler Options” on page 36 and “Creating LEC
and CC Architecture Definitions” on page 44.
Languages for CLISTs, ISPF panels, message members, and skeletons have only a PARSE
and no BUILD translator. Panels and message members are parsed like TEXT. For
skeletons 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, like
COBOL copy books for COBOL programs. Therefore, only the main skeletons have to be
referenced in the architecture definitions (refer to Figure 75 on page 121).
Compilers Used in the Old Environment
Depending on the library system used and/or additional functions added on top of the old
library system, you may have a detailed knowledge of which compiler version was used to
produce the load module now in production.
Find Compiler Used with CA-LIBRARIAN: In an environment with a CA-LIBRARIAN library

system 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 its
language. CA-LIBRARIAN itself only stores this information, and it is up to the customer
to use rigid conventions for this information field. We did not use this information
because 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-LIBRARIAN
control file (see “Release Process” on page 13). For old modules compiled before
introducing 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, the
sources just described might be the only place where you can find which preprocessor was
used for which module.
The product numbers of the compilers used can be found in the load module. For sample
application 1 we extracted the information from the load modules using a simple PL/I
program, MIGU001. The source for this program and a description of its use and restrictions
can be found in “Compiler Information” on page 77. The output of the program includes one
record 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 the
proper 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 discussed
in “Compiler Options” on page 36, together with how you can extract VS COBOL II compiler
options.
Find Compiler Used with ENDEVOR: ENDEVOR is not only a library management system but
a software configuration management system. It manages relationships between objects
and therefore is capable of managing the process of transforming source code into load
modules.
This point is important to keep in mind when trying to find the compilers used in the existing
environment. 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 a
CA-LIBRARIAN environment.
ENDEVOR stores information about so-called processors. There is a one-to-one relationship
between 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. The
processor used for each object can be found by using browse dialogs provided by ENDEVOR
or by using ENDEVOR report listings.
As we did not have an ENDEVOR system available in our environment, we used ENDEVOR
report listings to find all our information. Specify PRINT in the SCL used to create an
element report. Refer to the sample SCL for element GNDV0050 in “Find Information for
Languages” 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 run
against 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 existing
environment in SCLM. In that case you may also want to use the processor name as the
name of the language definition member.
We decided to use a new naming convention for the language definition member and
language names. This naming convention is explained in “SCLM Languages Used in the
Migration Project” on page 33.
Once the processor name is found, it is easy to find the related JCL and therefore the
compiler used.
For each element and each processor, you can find the compiler options and SYSLIB
libraries used. The SYSLIB libraries information is contained in the “Input components” part
of the report. Compiler options are discussed in “Compiler Options.”
Compiler Options
Most compilers offer different ways of specifying compiler options and have different rules
for the order in which these options are processed. The “Programming Guide” manuals
usually contain information about compiler options.
For VS COBOL II, you find the compiler options in Part 4 of the VS COBOL II Application
Programming Guide for MVS and CMS, SC26-4045. The order of precedence for VS COBOL
II compiler options is as follows:
1. Fixed installation defaults
Options that are fixed for an installation cannot be overridden for an individual
compilation. These options are not affected by the migration process.
2. Options specified on a COBOL PROCESS (or CBL) statement at the beginning of the
source module
This is the method you can use to keep specific compiler options together with the
source code without using a software configuration tool. The use of the PROCESS (or
CBL) statement can be disallowed for an installation with the default options module of
the COBOL compiler.
If you use this method of specifying compiler options, you should decide whether you
want to:
Stay with these PROCESS (or CBL) statements
Specify the options in CC architecture definitions and remove the PROCESS (or
CBL) statements from the source code.
We do not recommend that you use both—PROCESS statements and compiler PARM
specifications in CC architecture definitions—simultaneously.
3. Options specified with P A R M = 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 software
configuration management in your installation. Some options may have been coded in
standard procedures.
4. Nonfixed installation defaults
These defaults are used if an option is not specified elsewhere. In a given installation
these defaults remain unchanged during the migration.
Because our environment was not identical to the customer environments from where
the applications came, we had to override some installation defaults to meet the
customers' installation defaults. We did this by customizing the SCLM language
definitions.
Similar rules apply to PL/I programs: *PROCESS statements at the beginning of the source
code override the options given as PARMs on the EXEC statement of the compile job, and
these again override the installation defaults. For more details see the OS PL/I Version 2
Programming Guide, SC26-4307.
Compiler Options in SCLM

The compiler options that can be specified in SCLM correspond to those that can be
specified in the PARMs of the EXEC statement for a batch compile job. There are two
different 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 the
translator. If you have a common set of compile options for all modules with the same
SCLM language, you do not need CC architecture definitions at all. Therefore, it is important
to find the set of the most commonly used options for each language in order to reduce the
number of CC architecture definitions to a minimum.
All specifications in SCLM are overridden by COBOL PROCESS (or CBL) or PL/I *PROCESS
statements in the source code. If you use such statements, you should consider changing
this information to PARM information in CC architecture definitions. Our sample applications
did 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 program
initialization 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 can
find a detailed description of the VS COBOL II program initialization code in VS COBOL II
Application Programming: Debugging, SC26-4049.
For application 1 we extracted the information from the load modules using a COBOL
program, MIGU002. The source for this program and a description of its use and restrictions
can be found in “VS COBOL II Compiler Options” on page 82. The output of the program
includes one record per module that contains the bit pattern of the compiler options in the
load module mapped to a byte pattern. Therefore, for each compiler option a “ 1 ” indicates
that the option is on, and a “ 0 ” indicates that the option is off. Table 3 summarizes results
of the analysis for application 1.
Table 3 (Page 1 of 3). VS COBOL II Compile-Time Options in Effect. This information is

taken from the COBOL information bytes for the 114 VS COBOL II
modules of application 1. NoM is the number of modules that use the
option, InD indicates whether this option is an installation default in our
environment, 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 in 0 No Default DDNAME for All Yes
OUTDD option will be OUTDD will be used
used
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 reserved 0 No Installation default All Yes
word list reserved word list
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
TRUNC(BIN) 20 No (6)
Based on the information in Table 3 on page 37 we applied the following rules for our
project:
If an option is used for all modules and the option is an installation default, the option
does not have to be specified.
If an option is used for all modules and the option is not an installation default, the
option must be specified in the OPTIONS= parameter of the FLMTRNSL macro in the
SCLM 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 macro
in 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 numbers
refer to the Rem column in Table 3 on page 37):
(1) According to the above rules, modules with option DATA(31) require CC architecture
definitions.
(2) NOLIB was always used in the old environment because the existing compile
procedure 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 no
longer 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). We
therefore specified TRUNC(BIN) for all modules.
(7) The NOCMPR2/CMPR2 (compatibility with Release 2) options are only relevant for
modules compiled with Release 3. All Release 2 modules must use CMPR2. As
mentioned earlier, we decided to use two different SCLM language definitions for VS
COBOL II, one with option CMPR2, and one with option NOCMPR2. This option
therefore determines which language must be assigned to a module during the source
code migration (see Chapter 5, “Migrating the Bulk Data” on page 49).
(8) This option can be specified only at installation time. The four NUMCLASS modules
were compiled during a month when different VS COBOL II installation options were in
effect. This was probably not done on purpose. Our default NONUMCLASS matches
the standard customer default.

Other Information about Compiler Options for Application 1
The previous analysis was restricted to VS COBOL II modules. Other compilers do not store
information about compiler options in this way. Therefore, you have to look for more
general information sources at least for other than COBOL compilers.
The need to know the correct compiler options for the migration to SCLM corresponds to the
need to know these options for compilation of a module in the old environment for
maintenance reasons. If you know how to get the correct options for maintenance, you also
know how to extract it for migration purposes.
In a CA-LIBRARIAN environment there is no standard way to store this information, and the
analysis is therefore very customer-specific.
In our application 1 environment all the final compilations were performed under control of
the existing program release procedure (see “Release Process” on page 13). The compile
jobs are dynamically created from skeletons when the release process is initiated by the
developers. Options that are fix coded in the skeletons cannot be changed by application
developers.
Some other options are allowed to differ from the standards. These options are specified on
language-specific panels within the interactive dialog of the release process, and they are
stored in special comment records as part of the source code. The last used options are
always 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 source
code.
The detailed analysis procedure for non-VS COBOL II programs of application 1 is described
in “Extracting Compile and Link Edit Information” on page 88. The result of this analysis is
handled following the same guidelines as described for VS COBOL II. Together with the
control information for the linkage editor (refer to “Control Information for the Linkage
Editor” on page 41), this analysis provides the input for creating the low-level architecture
definitions. The automated generation of these members is described in “Creating LEC and
CC 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 for
Languages” on page 96, you find the information about compiler options under “Symbol
information” 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 reexecuted
to store the output in a data set.
Creating the input file for tool MIGR0010 manually from the report listings was not
efficient.
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 option
information from an ENDEVOR archive file and to create the input file required for tool
MIGR0010. The MIGR0030 extraction tool is described in “Extract Control Information from
ENDEVOR Archive File” on page 97.
After running MIGR0030 you may have to edit the formatted file to remove compiler options
that are either defaults or handled in the SCLM language definition. Figure 8 shows the
formatted file before editing.
GNDV0050 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 the
third column contains the compiler options. The last column in the formatted file contains
the 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 (linkage
edit control option A C = 1 is not visible).
Figure 9 shows the formatted file after editing.
GNDV0050 ASM AC=1

GNDV0100 ASM AC=1
GNDV0200 ASM AC=1
GNDV0300 ASM AC=1
GNDV0400 ASM AC=1
GNDV0500 ASM AC=1
Figure 9. Formatted File after Editing
All compiler options are removed during editing because they are either common or default
options (except linkage edit control option AC=1).
Control Information for the Linkage Editor

This section explains how to find the linkage editor control information used to create the
load modules in the existing environment and how to migrate this information to the SCLM
environment. Linkage editor control information includes:
Attributes like RENT or REUS.
As for the compiler options, the most commonly used options should be used as the
defaults for the linkage editor SCLM language definition. Only nondefault options are
specified 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 AMODE
and/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 AUTOCALL
facility 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 the
case 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 the
following 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 as
part of the released source code (refer to “Release Process” on page 13). The
customer's standard is to use dynamic calls to subroutines. Only a few modules are
linked to main programs, and this is always done with explicit linkage editor INCLUDE
statements 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 information
required for migration. The extraction of data from this file with our extraction tool
MIGR0030 is described in “Extract Control Information from ENDEVOR Archive File” on
page 97.
All extracted linkage editor control information required to build the correct LEC architecture
definitions was put into input files for the common tool to create the low-level SCLM
architecture definition members (see “Creating LEC and CC Architecture Definitions” on
page 44).
If you do not have information about link edit options, we recommend that you extract it from
the output of the IBM AMBLIST utility. This utility takes the information from the load
module and presents it in a formatted way. Figure 10 on page 43 shows a sample job to
run 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-TEST
4 NOT-OL 5 BLOCK 6 EXEC 7 MULTI-RCD
8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 RLD
12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR
------------------------------------------------------------------------------------------------------------------------
MODULE SSI: 00841126
APFCODE 00000000
RMODE 24
*****LOAD MODULE PROCESSED BY VS LINKAGE EDITOR
NUMERICAL MAP AND CROSS-REFERENCE LIST OF LOAD MODULE P92N041 PAGE 0001
CONTROL SECTION ENTRY

LMOD LOC NAME LENGTH TYPE LMOD LOC CSECT LOC NAME
00 P92N041 434 SD
438 P92N010 1BDA SD
2018 P92N011 856 SD
------------------------------------------------------------------------------------------------------------------------
LMOD LOC CSECT LOC IN CSECT REFERS TO SYMBOL AT LMOD LOC CSECT LOC IN CSECT
3CC 3CC P92N041 P92N010 438 00 P92N010
3D0 3D0 P92N041 P92N011 2018 00 P92N011
LENGTH OF LOAD MODULE 2870
ALPHABETICAL MAP OF LOAD MODULE P92N041 PAGE 0002
CONTROL SECTION ENTRY

NAME LMOD LOC LENGTH TYPE NAME LMOD LOC CSECT LOC CSECT NAME
P92N010 438 1BDA SD
P92N011 2018 856 SD
P92N041 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 CSECT
P92N010 438 00 P92N010 3CC 3CC P92N041
P92N011 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 attributes
NOT-RENT, NOT-REUS, AMODE=24, RMODE=24, and so on. The listing of CONTROL SECTIONs
indicates that modules P92N010 and P92N011 are linked to P92N041.

Creating LEC and CC Architecture Definitions
We 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 the
normal way to set up language definitions in SCLM.
When you have a separate SCLM language for the linkage editor, you must have an LEC
architecture definition for each program. As long as you use the default compile options of
the 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 compiler
options (see “Compiler Options” on page 36). The LEC architecture definition looks different
if you use a CC architecture definition for a program.
We automated the generation of LEC and—if necessary—CC architecture definitions for our
migration. The tool to generate these members is described in “LEC and CC Architecture
Definitions” on page 123 together with a complete source listing. Our REXX procedure
MIGR0010 read an input file that resulted from extracting control information for compile and
link 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 and
group 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 these
members. You should specify “ * ” for MEMBER and “ARCHDEF” for LANGUAGE in the SCLM
migration 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 migration
utility 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 members
of a program.
The LEC architecture definition member name was identical to the name of the source
program.
The CC architecture definition member name was built from the name of the source
program prefixed with “C.” This CC naming rule was possible because all program
names in application 1 had no more than seven digits. Application 2 had eight-digit
program names, but no CC architecture definition members were required for those
programs.
For environments with other naming conventions our generation tool must be modified to
meet customer requirements. The input record for each module contains:
Name
Type
and optional:
Nondefault compiler options
Nondefault linkage editor options
Names 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 our
tool and of the generated output members.
If you want to use the same name for CC and LEC architecture definitions, you can define
two 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 records
for 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 in
Figure 13 on page 45 for program P92N002 and in Figure 14 on page 46 for program
P92N046.
For P92N002 the CC architecture definition was required to specify the nondefault
LANGLVL(1) compiler option with the PARM1 keyword. Use of the PARM1 keyword (instead
of PARM) allows you to direct the options to a specific BUILD translator within the SCLM
language definition. In the FLMTRNSL macro for the compiler you then have to code
PARMKWD=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 language
definition, for example, preprocessor and compiler. We recommend that you handle
parameter input for translators in a uniform way for all languages. We decided to use
PARM1 for all compiler options. The source code reference to program P92N002 was made
with the SINC keyword in the CC architecture definition member.
Program P92N046 uses the common compiler options assigned to its language. No CC
architecture definition was required. The source code reference was made with the INCLD
keyword.
P92N000 COBOL
P92N002 COBOL LANGLVL(1)
P92N005 COBOL RENT,AMODE=24
P92N008 COBOL RENT
..
.
P92N044 COBOL RENT
P92N045 COBOL
P92N046 COBOL RENT
P92N047 COBOL RENT
P92N049 COBOL RENT
..
.
P92N349 COBOL RENT
P92N362 COBOL DATA(31) RENT
P92N363 COBOL RENT
P92N399 COBOL DATA(31) RENT
Figure 12. Input Records to Create LEC and CC Architecture Definitions for COBOL Programs
* LEC ARCHDEF FOR PGM P92N002

LKED LE370 * TRANSLATOR FOR LINK EDIT
LOAD P92N002 LOAD * LOAD MODULE
LMAP P92N002 LMAP * LINKAGE EDITOR OUTPUT
INCL CP92N002 ARCHDEF * CC ARCHDEF MEMBER
* CC ARCHDEF FOR PGM P92N002

OBJ P92N002 OBJ * OBJECT MODULE
LIST P92N002 LIST * COMPILER LISTING
SINC P92N002 COBOL * SOURCE MODULE
PARM1 LANGLVL(1)
Figure 13. LEC and CC Architecture Definitions for OS/VS COBOL Program P92N002

INCLD P92N046 COBOL * SOURCE MODULE
PARM 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 input
file is shown in Figure 16 for program P94N353.
The LEC architecture definition for P94N353 had the nondefault option AMODE=24 coded
with the PARM keyword. The CC architecture definition was required to specify the
nondefault compiler options with the PARM1 keyword. The source code reference was
made with the SINC keyword in the CC architecture definition.
P92N065 PLI CMPAT(V1) AMODE=24

P94N353 PLI OPT(0),CMPAT(V1) AMODE=24
Figure 15. Input Records to Create LEC and CC Architecture Definitions for PL/I Programs

INCL CP94N353 ARCHDEF * CC ARCHDEF MEMBER
PARM AMODE=24
* CC ARCHDEF FOR PGM P94N353

OBJ P94N353 OBJ * OBJECT MODULE
LIST P94N353 LIST * COMPILER LISTING
SINC P94N353 PLI * SOURCE MODULE
PARM1 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 generated
output 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 CC
architecture definition was required. The source code reference was made with the INCLD
keyword. Two modules (P92N010 and P92N011) are linked to this program. The reference to
these modules was made with the INCL keyword referring to their LEC architecture
definitions.
KR00030 ASM
P03N905 ASM
P92N001 ASM
P92N003 ASM
P92N006 ASM
P92N022 ASM
----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
P92N041 ASM
(line continued:) -+----9----+----0----+----1----+----2----+----3--<COLS
P92N010 P92N011
P92N219 ASM
P92N242 ASM
..
.
P94N053 ASM REUS
P94N066 ASM
P94N115 ASM REUS
Figure 17. Input Records to Create LEC and CC Architecture Definitions for Assembler Programs

INCLD P92N041 ASM * SOURCE MODULE
INCL P92N010 ARCHDEF * STATIC LINKED MODULE
INCL 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 the
PROM keyword. We could use either an HL or LEC architecture definition. In most cases it
is better to reference the DDL member in an HL architecture definition, because DB2 tables
are very often used by many programs within one application, or even by more than one
application. For our project, because we had only five DDL members and each one was
related to only one program, we decided to reference the DDL members in LEC architecture
definitions.
DB2CLIST Considerations
SCLM manages the relationship between a program and its DB2 plan through a proxy
member, the DB2CLIST. The DB2CLIST is a TSO CLIST that contains the required BIND and
FREE PLAN statements. When executed during a build process, the CLIST executes the
BIND PLAN statement and writes a copy of itself, the DB2OUT CLIST, as output. This
DB2OUT CLIST is used during promote processes and executes the BIND and FREE PLAN
statements.
In our project definition, we set up the DB2CLIST type to hold the DB2CLIST members and
the DB2OUT type to hold the DB2OUT members. We do not discuss creation of the DB2OUT
members 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 HL
architecture definitions containing DB2CLIST members:
If the DB2CLIST member is related to a single program represented by a single LEC
architecture definition, the HL architecture definition that ties the LEC architecture
definition and DB2CLIST together uses “ @ ” as the first character, and the remaining
seven characters correspond to the name of the LEC architecture definition.
If the DB2CLIST member is related to more than one program represented by more than
one LEC architecture definition, the HL architecture definition that ties the LEC
architecture definitions and DB2CLIST together uses “ @ ” as the first character and the
remaining seven characters correspond to the name of the ENDEVOR member that
contains the BIND statements. For example, if the member containing the BIND
statements in ENDEVOR is called GNDV0000, the name of the HL architecture definition
member in SCLM is @GNDV000. In some cases the name following the prefix “ @ ” has
to be truncated to seven characters, which is actually the case in application 2 where
member names are eight characters long. You must decide which character you can
drop 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 the
contents, 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 an
automated approach for creating DB2CLIST members because there are more DB2
applications 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 was
developed in a previous ITSC project. Its name is G621HLA, and you can find details about it
in 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 is
still the same. The name of the modified REXX procedure is MIGR0050 and is shown in “HL
Architecture Definitions and DB2CLISTs” on page 129. This program creates DB2CLISTs
and HL architecture definitions from user input. Refer to Figure 19 for a sample HL
architecture definition created by the tool.
INCL GNDV0100 ARCHDEF

INCLD @GNDV000 DB2CLIST * BIND DB2 plan
Figure 19. HL Architecture Definition Created by the MIGR0050 Program. The five LEC architecture
definitions were previously created by the MIGR0010 program. A BUILD of this
architecture definition provoked a BUILD of each LEC architecture definition and the
execution of the @GNDV000 CLIST.
We recommend that you create DB2CLIST members and related HL architecture definitions
after you create the LEC architecture definitions and before you create “higher level” HL
architecture definitions.
After you have created the DB2CLIST and HL architecture definitions, you have to migrate
these new members with the SCLM migration utility. We recommend that you use the
SUBMIT command for migration.
Chapter 5. Migrating the Bulk Data
Because our target system for the migration was not identical to the source systems of the
vendor libraries, the extraction of source data and the migration of that data were really
separate steps. The extraction of source data from the vendor library systems is described
in “Extract Data for the Sample Applications” on page 17; additional details are provided in
Appendix A, “Data Extraction from CA-LIBRARIAN” on page 73.
This chapter describes the migration of source data on the SCLM target system. Migration
of 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 your
source code migration will have additional steps.
If you migrate within a single MVS environment, that is, the vendor library and SCLM
installed on the same system, and you do not need to adjust your source code, you do not
need intermediate data sets. You can extract the source code from the old library system
directly into SCLM PDSs.
Figure 20 on page 50 gives an overview of bulk data migration including modifications of
source code for programs from CA-LIBRARIAN. The following remarks refer to the numbers
in 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 bulk
data migrations. Then we discuss special steps that may or may not be required depending
on the type of the old library system and the standards used.
Standard Source Code

The 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 PDS
with the same SCLM language in one step. Specify '*' for MEMBER.
If you leave the AUTHORIZATION CODE field blank, the default authorization code for the
group will be assigned. MIGRATE MODE = CONDITIONAL will migrate only those members
that do not have valid SCLM accounting information.
à ------------------- SCLM MIGRATION UTILITY - ENTRY PANEL ---------------------

ð
COMMAND ===> sub (Enter EXECUTE or SUBMIT)
SELECTION CRITERIA:
PROJECT ===> SCLM3
GROUP ===> MIG1
TYPE ===> PLI
MEMBER ===> * (Pattern may be used)
MEMBER INFORMATION:
AUTHORIZATION CODE ===>
CHANGE CODE ===>
LANGUAGE ===> PLIO
MIGRATE 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 carefully
consider the order of the bulk data migration steps. Copy and migrate only members with
the 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 the
members by language (refer to Table 2 on page 33). Therefore, we first copied and
migrated all VS COBOL II modules conforming to ANSI 85 standard (option NOCMPR2) into
the PDS and assigned language COB2. Then we copied and migrated the remaining VS
COBOL 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 the
languages 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 for
the members of different languages and copy all members. We used member lists created
during the analysis of the control information.
Consider all types of source data for the migration, such as source programs, included
members, panels, skeletons, CLISTs, and DDL. SQL BIND statements cannot be migrated
directly; they must be included in DB2CLIST members (refer to “DB2CLIST Considerations”
on page 47).
Nonstandard Source Code

Some of the source code in application 1 did not conform to compiler standards and needed
adjustment. Changes were required for the proper handling of COBOL COPY statements
and 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 language
used. Only source code of the same programming language was handled at a time with its
language-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 DATA
DIVISION copy book by prefixing the COPY statement in the main program with a different 01
level data name. If the copy book does not contain a 01 level data name, the 01 level data
name preceding the COPY statement followed by a period is inserted. COBOL standards
ANSI 74 and ANSI 85 do not support 01 level data name replacement in this way. The
REPLACING clause in the COPY statement is used for that purpose. The 01 level data name
in the COPY statement must end in a period and is therefore treated like any other COBOL
statement in the program.
CA-LIBRARIAN treats all COBOL copy books according to the ANSI 68 standard rules
regardless 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 name
specification; the 01 level data name preceding the COPY statement is inserted. The
difference between ANSI 68 and ANSI 74 or ANSI 85 standard COBOL coding in the example
in 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 to
insert 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 not
sufficient to insert a missing period. You will end up with two 01 level data name
specifications 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 change
the 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. In
programs that previously included this copy book without a 01 level data name specification
you 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 best
tool to identify errors. We inserted only the missing periods automatically before migrating
the programs and copy books.
The VS COBOL II compiler gives an IGYDS1159-E error message if two 01 level data names
precede 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 on
page 54).
IGYDS1159-E A "PICTURE" clause was not found for elementary item "AAA". "PICTURE
X(1)" was assumed.
IGYPS0037-S "AAA" was not a uniquely defined name. The definition to be used could
not be determined from the context. The reference to the name was
discarded.
Figure 24. COBOL Error Messages for Duplicate 01 Level Data Names
We made the remaining corrections manually. Only a few old programs were affected, as
the 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 SCLM
architecture reports (see “Completeness and Correctness Checks” on page 58) to identify
all 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 the
program.
The COBOL compiler and CA-LIBRARIAN handle COPY statements with the REPLACING
clause 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, as
coded 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 and
is found as a prefix string in the copy book.
This function does not correspond to any COBOL standard, even if the coding itself
conforms to the COBOL language rules. The COBOL compiler will not replace anything
during copy book expansion.
COBOL standard ANSI 85 supports partial replacement of data names if proper
delimiters are used. CA-LIBRARIAN does not support this.
A full description of COBOL COPY syntax can be found in VS COBOL II Application
Programming: 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 data
names 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 partial

replacement of a data name.

COPY ABCCOPY REPLACING ABC- BY XYZ-. 05 ABC-1 PIC X.
05 ABC-2 PIC X.
.....
.....
Copy book ABCCOPY:
³ ³
³ 05 ABC-1 PIC X. ³
³ 05 ABC-2 PIC X. ³
³ ..... ³
³ ..... ³
Figure 26. COPY REPLACING: Example 2a (COBOL Standard). No replacement takes place because
the string in the REPLACING clause does not match a data name in the copy book.

COPY ABCCOPY REPLACING ABC- BY XYZ-. 05 XYZ-1 PIC X.
05 XYZ-2 PIC X.
.....
.....
Copy book ABCCOPY:
³ ³
³ 05 ABC-1 PIC X. ³
³ 05 ABC-2 PIC X. ³
³ ..... ³
³ ..... ³
Figure 27. COPY REPLACING: Example 2b (CA-LIBRARIAN Standard). The data name prefixes are
replaced.

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 the
delimiters 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 the
copy book and remove the REPLACING clause. You must consider other COPY statements
referencing the copy book.
A similar problem arises if you use the ANSI 85 standard as shown in Figure 28. Not only
do the colon delimiters have to be inserted into the copy books, but also all the COPY
statements in all programs using the copy book must be changed. Furthermore, for
programs that include such a copy book without a REPLACING clause, a dummy REPLACING
clause must be added to eliminate the colons in the copy book from the expanded text. Two
solutions remain:
1. Remove the REPLACING clause from the COPY statement, change all references to the
affected data names within the program to the original names in the copy book, and use
the 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 used
multiple times within one program with different prefixes assigned by different
REPLACING clauses.
2. Change the REPLACING clause in the COPY statement from prefix replacement to
replacement of matching names. For the example, in Figure 27 on page 56, replacing
the CA-LIBRARIAN syntax
COPY ABCCOPY REPLACING ABC- BY XYZ-.
with COBOL syntax would give you
COPY ABCCOPY REPLACING ABC-1 BY XYZ-1

ABC-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 the
source code harder to understand, because data names in the DATA DIVISION copy books
and data names in the PROCEDURE DIVISION do not match. In “Handling COPY Prefix
Replacement in COBOL Programs” on page 141 we describe the tools we used to help
automate the required changes.
− INC CA-LIBRARIAN Statements

The CA-LIBRARIAN − INC statement is a directive statement for CA-LIBRARIAN to include
the 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 member

GETPARM. The − INC always starts in column 1. Application 1 Assembler and PL/I
programs used − INC statements.
− INC in Assembler Programs: The text for user-written Assembler macros was included in
program 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 the
Assembler 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 these
macros automatically in the PDSs allocated through FLMALLOC macros in the SCLM
language definitions. The SCLM parser detects the names of the macros, and new or
changed macros are promoted together with the program.
We changed the − INC statements in application 1 Assembler programs into comment
statements. The automated procedure for these changes is described in “Changing
CA-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 %INCLUDE
statements. The automated procedure for these changes is described in “Changing
CA-LIBRARIAN − INC Statements” on page 156.

Completeness and Correctness Checks
After migrating your application you may want to verify that all required members are
properly migrated and available in the SCLM environment. We used the SCLM architecture
report utility (SCLM option 3.5) to perform a completeness check.
Furthermore, you may want to know whether all modules can be built successfully under
SCLM control even before you create all high-level (HL) architecture definitions required to
define the high-level structure of your application. If you changed source code during the
bulk data migration, this step may be of special interest.
Some changes discussed in “COBOL Copy Statements with Leading Data Names” on
page 52 may require additional manual intervention. BUILD error listings for modules that
require additional changes and cross-reference information in SCLM architecture reports will
help you to complete the task.
SCLM Architecture Reports for Completeness Checks

We created temporary architecture definitions—one for each SCLM language—that contain
INCL statements for all LEC architecture definitions for programs with the same SCLM
language. Member lists for each language were already used during bulk data migration. If
you edit these member lists you can easily reformat them using editor change commands to
create temporary architecture definitions. Remember, our naming convention called for the
same names for programs and LEC architecture definitions.
You can create SCLM architecture reports for the temporary architecture definitions. Use
SCLM option 3.5 and select REPORT CUTOFF = NONE. If not all included members are
found, the missing members will be marked with an E* in the report, as shown in Figure 29
on 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 copied
to the ASMMACS PDS because of nonconformance to naming conventions.
You must copy the missing members to the SCLM PDS of the appropriate type and migrate
them with the correct SCLM language. Use the SCLM library utility (SCLM option 3.1) to
delete 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 P92N203
D P92N203
T P92N203
I S92C001C
I S92C002C
I S92U299C
E* S92U250C <--- E* indicates missing member
I S92U251C
I 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 were
made or that some inconsistencies still exist. “COBOL Copy Statements with Leading Data
Names” on page 52 shows a typical example where duplicate data names are to be
removed.
It is very useful to get a list of all the remaining problems. If you perform a conditional
SCLM BUILD using an HL architecture definition for the whole application, BUILD stops after
encountering the first error. You might have to step from one error to the next without
knowing how much work is still to be done.
We did the basic correctness checks with BUILDs on a module-by-module basis. We
developed a REXX procedure (MIGR0020) that uses the SCLM command interface. This
REXX procedure calls the BUILD command for each LEC architecture definition in the input
stream 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 Mass
BUILDs” on page 158.
The advantage of using the SCLM command interface is that you can work with simple
member lists to create the input stream. The SCLM dialog interface (SCLM option 4 for
BUILD) would require you to type in each member name.
If the modules are built successfully in this step, a later BUILD for an HL architecture
definition 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. Possible
changes required are discussed in “COBOL Copy Statements with Leading Data Names” on
page 52.
Perform all editing using SCLM EDIT now to keep the accounting information for the
members updated.
Chapter 6. Creating High-Level Application Structure
Unlike other library systems, SCLM allows you to structure your application in a multilevel
hierarchy. This structuring is achieved by creating related HL architecture definitions that
reflect the structure of your application. You can think of this system of related architecture
definitions as the blueprint of your application. The HL architecture definitions reference the
CC, 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 architecture
definitions is not an easy task, but one of the major advantages of SCLM is that the structure
of 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 your
programs based on their LEC architecture definitions, you may not need any HL architecture
definitions at all. However, such an approach would not take advantage of SCLM's
extensive software configuration functions. Even a single HL architecture definition that
includes all lowest-level architecture definitions gives you advantages. You can build and
promote the whole application by specifying that HL architecture definition on the SCLM
BUILD and PROMOTE panels.
Real structuring requires a multilevel hierarchy. You make a trade-off between the
investments during the migration phase and the benefits you will gain for your application
under SCLM control. Well-structured applications are easier to maintain and will pay back
your 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/I
includes, embedded skeletons) is stored by SCLM parsers in the SCLM accounting data
set
Statically linked programs are included in the LEC architecture definitions during
migration 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 your
application, 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 Information
Possible 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 a
simple library management system or a sophisticated library management and software
configuration system. A library system that provides software configuration functions, such
as ENDEVOR, provides more input for this part of the migration process. CA-LIBRARIAN is a
library management system only and does not provide application structure information.
The library management functions of both systems keep attribute information for members
or objects. The software configuration functions in ENDEVOR keep attribute information for
applications. To understand how to build the high-level structure of an application during
migration, we have to explain the meaning of attribute information for applications.
Attribute information is about all kinds of relationships between application objects and
between applications in an application domain. Relationships between objects within one
application 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 versioning
facility.
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 such
relationships with its parsers.
A source program with a derived object (object module or load module). When a source
program is compiled and link edited to produce a load module, the configuration
management system keeps information about the relationship between the two objects.
SCLM handles this relationship with CC and LEC architecture definitions and through
the language that is tightly linked to the source program.
A source program with another source program that is not included. Two source
programs can produce one load module. Two source programs can be grouped
together with an LEC architecture definition.
A derived object with another derived object; for example, a load module with a static
call to another load module. You can use the LINK parameter in an LEC architecture
definition to specify such a relationship.
An object with an application. Each application consists of multiple objects. SCLM
handles 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 the
relationships between objects and applications.
One application can have a relationship with itself if other configurations or versions of
the same application exist. Relationships between different applications are handled
with 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 structure
from the object to the enterprise level. HL architecture definitions provide the possibility to
build application structures that take into account domains and subdomains of the
enterprise.
Structure Information from Dictionary Reports
Dictionary reports are a very useful information source for the application structure. The
completeness of the information useful for defining the application structure in SCLM will
depend on the amount of information and links in the dictionary.
The program-subprogram structure is a typical dictionary report output. Well-maintained
dictionaries also provide higher-level structure information. It is important to understand
which information, required to build your architecture definitions, is not available in the
dictionary.
Because dictionary reports have well-known formats, simple tools can be written to
transform the report information into SCLM architecture definitions. We had no dictionary
information available for our project and therefore we do not provide tools to extract
information from dictionary reports. The general concept for such a tool is similar to our
tool for creating LEC and CC architecture definitions (see “LEC and CC Architecture
Definitions” 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 your
architecture definition and complement data from other sources.
In most cases such documentation cannot be used as machine-readable input to an
automated tool. You can use the information as input to a tool like MIGR0050 (see “HL
Architecture Definitions and DB2CLISTs” on page 129) to create the architecture definitions
with a minimal typing effort.
Scan of Source Modules

Scanning of source modules typically gives you the relationship between calling and called
modules. A typical relationship would be a program to subprogram relationship. In a
TSO/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) are
examples of such relationships.
Creating the Architecture Definitions

Before you start creating any HL architecture definitions, you should establish a naming
convention. We used the following naming convention for the lowest-level architecture
definition members:
Program name for LEC members
Program name prefixed with C for CC members
DB2CLIST name for HL members referring to DB2CLISTs.
Refer to “Creating LEC and CC Architecture Definitions” on page 44 and “DB2CLIST
Considerations” on page 47. We decided to have all HL architecture definition member
names start with # for application 1 and with @ for application 2.
Create HL Architecture Definitions Using CA-LIBRARIAN Information: CA-LIBRARIAN does

not 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 have
batch 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, all
modules belonging to one transaction are grouped at the level directly above the LEC
architecture definitions.
Application 1, which is a TSO/ISPF application, is started from a CLIST. The different
functions and subfunctions are selected from ISPF selection panels. The control flow of the
application depends on the user input data.
We scanned the modules to find all relationships between calling and called modules. We
used the ISPF Search-For utility (ISPF option 3.14) to scan application 1. For example, a
search for the word CALL in your COBOL source PDS provides you with a list containing all
calls to subprograms. Depending on the module types you are analyzing it may be useful to
consider naming conventions and coding style in your application.
You can reduce the output of the scan to the required information using simple EDIT
commands (like excluding and deleting lines) or EDIT macros containing such commands.
We used this information to create HL architecture definitions. We generated the names for
the HL architecture definition members for TSO and ISPF modules by replacing the common
three-character prefix for the application by #, and for programs by prefixing the program
name 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, the
INCLD keyword specifying the source module name and type is coded. For programs, the
INCL keyword specifying the LEC architecture definition is coded.
In a first approach all “called” modules were referenced by INCLuding the HL architecture
definition. Our analysis of the calling modules did not consider nesting of calls to
subroutines. Therefore, we did not know whether the dependent modules would again have
dependents. 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 for
the HL architecture definition. Be sure to migrate all architecture definitions before you start
the 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 for
modules that have dependents.
You could create architecture definitions for the lowest-level modules with only one line
referring to the source, but those architecture definitions provide no additional benefit. We
decided to replace the reference to the nonexisting HL architecture definition members with
a reference to the modules directly (INCL LEC member for programs, INCLD source for
modules not to be translated).
If you rerun the SCLM architecture report now, it should end with no errors, provided you
previously migrated all the source modules.
INCLD FUAP1010 PANELS
INCL #P1100 ARCHDEF
INCL #P1300 ARCHDEF
INCL #P1600 ARCHDEF
INCL #P1690 ARCHDEF
INCL #P1800 ARCHDEF
INCL #P3010 ARCHDEF
INCL #C1050 ARCHDEF
INCL #C9000 ARCHDEF
INCL #C9100 ARCHDEF
INCL #P9900 ARCHDEF
Figure 30. HL Architecture Definition #P1010. #P1010 is the HL architecture definition for ISPF
selection panel FUAP1010. #P1100 is the HL architecture definition for panel FUAP1100,
which represents one of the selections on panel FUAP1010.

INCL #C1100 ARCHDEF
Figure 31. HL Architecture Definition #P1100. #P1100 is the HL architecture definition for ISPF
selection panel FUAP1100. The only possible selection on this panel selects CLIST
FUAC1100 represented by the HL architecture definition member #C1100.
INCLD FUAC1100 CLIST

INCL #C1140 ARCHDEF
INCLD FUAC1110 CLIST
INCL #C1200 ARCHDEF
INCL #C1290 ARCHDEF
INCL #P92N200 ARCHDEF
Figure 32. HL Architecture Definition #C1100. #C1100 is the HL architecture definition for CLIST
FUAC1100. This HL architecture definition contains references to source modules (panels)
and to other HL architecture definition members, such as #P92N200.
INCL P92N200 ARCHDEF

* CALLED SUBROUTINES:
Figure 33 (Part 1 of 2). HL Architecture Definition #P92N200

Figure 33 (Part 2 of 2). HL Architecture Definition #P92N200. #P92N200 is the HL architecture

definition for program P92N200. This HL architecture definition contains
references to LEC architecture definition members for called subroutines at
the lowest level, to ISPF panels, and to other HL architecture definition
members, such as #P92N258 for subroutines that call other subroutines.
Figure 34 shows a partial SCLM architecture report for application 1. The report refers to
the architecture definition members shown in Figure 30 on page 65 through Figure 33 on
page 65.
..
.
H #P1010 *
D FUAP1010 | H = HIGH LEVEL
T FUAP1010 | L = LINKEDIT CONTROL
H #P1100 | C = COMPILATION CONTROL
D FUAP1100 | G = GENERIC
T FUAP1100 | T = TOP SOURCE
H #C1100 | I = INCLUDED
D FUAC1100 | E = ERROR
T FUAC1100 | D = DEFAULT
H #C1140 *
..
.
..
.
H #P92N200
L P92N200
D P92N200
T P92N200
I S92C001C
I S92U299C
I S92U250C
I S92U251C
I S92U253C
I S92U254C
I S92U258C
I S92U259C
I S92U262C
I S92U290C
I S92U291C
I S92D290C
D FUAP0100
T FUAP0100
D FUAP1110
Figure 34 (Part 1 of 2). Partial SCLM Architecture Report for Application 1
T FUAP1110
D FUAP1120
T FUAP1120
D FUAP1620
T FUAP1620
L P92N250
D P92N250
T P92N250
I S92U011C
I S92U010C
I S92D250C
I S92U003C
I S92U004C
I S92U005C
I S92U299C
..
.
Figure 34 (Part 2 of 2). Partial SCLM Architecture Report for Application 1. The partial report for
application 1 refers to the architecture definition members in Figure 30 on
page 65 through Figure 33 on page 65. No CUTOFF is used and all included
members are listed.
Create HL Architecture Definitions Using ENDEVOR Information: ENDEVOR supports the

notion of system and subsystem in its logical structure. Both system and subsystem
describe logical groupings of ENDEVOR inventory elements and provide input to the creation
of HL architecture definitions that reflect the application structure.
We used the system name (X) from ENDEVOR for the highest-level architecture definition
and the subsystem name (L), which is a subclassification of system, for the
intermediate-level architecture definition for application 2. ENDEVOR provides no other
information that can be used to create HL architecture definitions. We could not find
intermediate “logical” levels between subsystem (HL architecture definition) and element
name (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 a
migration from ENDEVOR to SCLM you must create such intermediate-level architecture
definitions 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 name
from ENDEVOR. However, we created the HL architecture definitions using the MIGR0050
tool (see “HL Architecture Definitions and DB2CLISTs” on page 129).
* HL SYSTEM ARCHDEF
INCL @L ARCHDEF * SUB-SYSTEM
Figure 35. HL Architecture Definition @X. This architecture definition only makes sense in a real
environment if many subsystems are related to one system.
* HL SUB-SYSTEM ARCHDEF
INCL GNDV0050 ARCHDEF * LEC ARCHDEF
INCL @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 HL
architecture 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 @X
H @L
L GNDV0050
D GNDV0050
T GNDV0050
I DEFREG
I SQLUDSCT
I NDVSQL01
H @GNDV000
L GNDV0100
D GNDV0100
T GNDV0100
I SQLUDSCT
I DEFREG
I NDVTBHIS
I NDVSQL01
L GNDV0200
D GNDV0200
T GNDV0200
I SQLUDSCT
I DEFREG
I NDVTBDIS
I NDVSQL01
L GNDV0300
D GNDV0300
T GNDV0300
I SQLUDSCT
I DEFREG
I NDVTBPRM
I NDVSQL01
L GNDV0400
D GNDV0400
T GNDV0400
I SQLUDSCT
I DEFREG
I NDVTBDES
I NDVSQL01
L GNDV0500
D GNDV0500
T GNDV0500
I SQLUDSCT
I DEFREG
I NDVTBSTS
I NDVSQL01
Figure 37. Partial SCLM Architecture Report for Application 2
BUILD and PROMOTE Using the Architecture Definitions
We performed BUILDs for all programs during bulk data migration (see “Completeness and
Correctness Checks” on page 58). Therefore, SCLM does not initiate recompiles for the
programs when you build the newly created HL architecture definitions. Our HL architecture
definitions 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 “from” group (MIG2) and the DB2 BIND for
the “ t o ” group (TEST).
If the promotion is successful but some modules remain in the PDSs of the development
group, 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 are
systematic errors in your method to create the HL architecture definition structure. If there
are systematic errors, you should improve your method. This is particularly important if you
work in a pilot project and want to migrate other applications using the methods developed
in the pilot project.
If you find modules that are not used, use the SCLM Library utility (SCLM option 3.1) to
delete these modules and their accounting information from your SCLM project. Unused
modules 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 application
before you finally promote to the production layer.

Chapter 7. Post-Migration Steps
This chapter explains some of the considerations you need to address after you have
migrated an application. The following topics are covered:
Promote migrated application to production
Handle nonmigrated information.
Promote Migrated Application to Production

After thorough testing, you are ready to promote the migrated application to production. We
invoked the SCLM PROMOTE function to move all application objects from group TEST to
group 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 transition
period. You will avoid unpleasant surprises in production if, despite all the testing, an
application module should be missing in the new libraries.
After you have migrated all of your applications you can delete all product data sets for the
old library system.
Handle Nonmigrated Information

Control 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 information
for the sample applications in our project. We did not migrate as much control information
as 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 SCLM
environment.
For object control information: We used (migrated) the existing type information, which
became the input to create the SCLM types.
For application control information: We migrated the relationships between objects, which
were used as input to create SCLM architecture definitions. This information is as important
as the object data because it describes how the objects fit together. For example, a
compiler 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 the
migration 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 and
too expensive to migrate that information, which is conceptually identical in the old and new
environment but very different in the technical implementation. However, nonmigrated
source code belonging to old versions must be taken into account.
You can classify control information according to how difficult it is to migrate. This is
particularly useful if you want to clone your existing environment.
List 1 contains control information that is difficult or impossible to migrate either for
technical 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/time
Predecessor date/time
Translator version
Change date/time
Access key.
You cannot migrate time stamps because they are internally managed by SCLM. For
example, create date/time is set when the member is first identified to SCLM, and there is
no 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 userid
Change userid
Change group
Change code.
It is possible to migrate information from list 2. Change code is an input parameter for the
SCLM migration that can be derived from the ENDEVOR CCID. CA-LIBRARIAN does not
support change codes. If you do not change userids during the migration, you can keep the
change userids the same as they were in the old environment.
To keep a record of all nonmigrated control information, we recommend that you run
reports, such as the CA-LIBRARIAN index listing or ENDEVOR standard reports and SCL
PRINT 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 might
not be an acceptable option in a real-life environment and you must be careful not to lose
this 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 a
promote exit during the migration. If such a file does not exist but versioning is used in the
old environment, you can load the old versions into a file kept outside SCLM.
Appendix A. Data Extraction from CA-LIBRARIAN
This appendix shows the jobs used to extract data for application 1 from the CA-LIBRARIAN
data sets in the customer environment.
Copy Selected Members between CA-LIBRARIANs

We used the CA-LIBRARIAN utility to copy members unchanged from one CA-LIBRARIAN to
another CA-LIBRARIAN. We extracted Assembler macros, COBOL copy books, and PL/I
include members from the development CA-LIBRARIAN (file C in Figure 4 on page 20) and
full-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 program
in 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)
//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 the
Assembler macros and COBOL copy books. Specified members are unloaded from one
CA-LIBRARIAN to an intermediate file and then added to another CA-LIBRARIAN.

Extract Programs and Remove Included Members
We used a customer program that uses the CA-LIBRARIAN utility to copy programs from one
CA-LIBRARIAN to another while removing included members and establishing the original
COPY or CA-LIBRARIAN − INC statements (file P in Figure 4 on page 20). Figure 39 shows
the 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)),
//LUCIIPT DD UNIT=SYSDA,SPACE=(TRK,(10,6)),
//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----------------------------------------------------------**
P92N000
P92N001
.
.
P92N399
/*
//*=====================================================================
Figure 39. Job to Extract Programs from One CA-LIBRARIAN to Another CA-LIBRARIAN. The
DDSE01 DD file contains the list of members selected.
Unload from CA-LIBRARIAN to Partitioned Data Set
Figure 40 shows a sample job that unloads a complete CA-LIBRARIAN to a PDS. Because
the extraction from the original CA-LIBRARIAN was done previously (see “Copy Selected
Members between CA-LIBRARIANs” on page 73), our temporary CA-LIBRARIAN contained
only 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'
//OSJOB DD DISP=(,PASS),DSN=&&OSJOB1,
// UNIT=SYSDA,SPACE=(TRK,(25,10),RLSE),
// DCB=(RV.PATTERN,LRECL=80,BLKSIZE=6080,RECFM=FB)
//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'
//OSJOB DD DISP=OLD,DSN=SFITZ.LIBRA.MIGCOPY
//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 Existing
Applications
The methods and tools you use to analyze an existing application will depend on the
information available in the old library system and in other files of the old environment. This
appendix shows the methods and tools we used to extract control information for the two
applications in our project.
Application 1
Because 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 and
may be used unchanged in other environments.
We also extracted control information from comment records added to the source code
during the release process. The technical details of this analysis are specific to the
environment of application 1, but the concept might be of interest for other environments as
well.
Compiler Information
In a CA-LIBRARIAN environment, all the source code is typically stored in one file. In SCLM
you want to set up different data sets for different source types, such as COBOL, PLI, or
ASM. You have to extract your source code according to its programming language to store
it in different data sets under SCLM. We analyzed the load modules of application 1 to find
the compiler information.
Compilers place their own IDs into the object modules they produce. Therefore, you can find
these compiler IDs (which normally are the product numbers) in the load modules. Program
MIGU001 (listed in Figure 41 on page 78) analyzes load modules. Program MIGU001 has
the 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) in
position 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 not
true 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 same
record. 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/I
Optimizing Compiler) or “5668-910” (OS PL/I Version 2 Compiler).
Old OS/VS COBOL modules show “40CB1” instead of “5740CB1” at the indicated
position in the load module. These old OS/VS COBOL modules should be compiled
using compiler option LANGLVL(1) with the OS/VS COBOL Release 2 compiler. It is
therefore useful to find old OS/VS COBOL modules so that the correct compiler options
can 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
/*=============================================================== ***/00260000
DCL PARM CHAR(100) VARYING; 00270000
DCL ADDR BUILTIN; 00280000
DCL INDD FILE; /* INPUT FILE */00290000
DCL OUTDD FILE; /* OUTPUT FILE */00300000
DCL EOF CHAR(1); /* EOF-INDD SWITCH */00310000
DCL INF CHAR(1); /* INFO-RECORD SWITCH */00320000
/*-------------------------------------------------------------------*/00330000
DCL PROGRAM_RECORD CHAR(19069); /* FOR LOAD MODULE RECORD */00340000
DCL 1 DFPX_RECORD BASED(ADDR(PROGRAM_RECORD)), 00350000
2 I_FILLER3 CHAR(3), 00360000
2 I_DFPX, 00370000
3 I_DFPX_1 CHAR(4), 00380000
3 I_DFPX_2 CHAR(3); 00390000
DCL 1 COMP_RECORD BASED(ADDR(PROGRAM_RECORD)), 00400000
2 C_FILLER6 CHAR(6), 00410000
2 I_COMP, 00420000
3 I_COMP_1 CHAR(4), 00430000
3 I_COMP_2 CHAR(3); 00440000
Figure 41 (Part 1 of 3). PL/I Program MIGU001
/*-------------------------------------------------------------------*/00450000
DCL 1 OUTDD_RECORD UNALIGNED, /* */00460000
2 O_PGMNAME CHAR(08), /* PROGRAM NAME */00470000
2 O_DFPX_TEXT CHAR(14), 00480000
2 O_DFPX, 00490000
3 O_DFPX_1 CHAR(4), 00500000
3 O_DFPX_1A CHAR(1), 00510000
3 O_DFPX_2 CHAR(3), 00520000
2 O_COMP_TEXT CHAR(16), 00530000
2 O_COMP, 00540000
3 O_COMP_1 CHAR(4), 00550000
3 O_COMP_1A CHAR(1), 00560000
3 O_COMP_2 CHAR(3), 00570000
2 O_FILLER26 CHAR(26); 00580000
/***============================================================= ***/00590000
/*** ON ENDFILE SET EOF-SWITCH ***/00600000
/*-------------------------------------------------------------------*/00610000
ON ENDFILE(INDD) BEGIN; 00620000
O_FILLER26 = '## PREMATURE EOF FOUND. ##'; 00630000
WRITE FILE(OUTDD) FROM(OUTDD_RECORD); 00640000
GOTO FINIS; 00650000
END; 00660000
/***------------------------------------------------------------- ***/00670000
/*** OPEN DATEIEN ***/00680000
/*-------------------------------------------------------------------*/00690000
OPEN FILE(INDD) SEQUENTIAL RECORD INPUT, 00700000
FILE(OUTDD) SEQUENTIAL RECORD OUTPUT; 00710000
/***------------------------------------------------------------- ***/00720000
/*** INITIALIZATIONS ***/00730000
/*-------------------------------------------------------------------*/00740000
EOF = ' '; /* EOF-SWITCH */00750000
INF = ' '; /* NOT RECORD WITH LKED ID */00760000
PROGRAM_RECORD = ' '; 00770000
/***------------------------------------------------------------- ***/00780000
/*** READ LOAD MODULE RECORDS UNTIL PROD.NO. FOR DFP FOUND ***/00790000
/*-------------------------------------------------------------------*/00800000
DO WHILE (INF = ' '); 00810000
READ FILE(INDD) INTO(PROGRAM_RECORD); 00820000
IF (I_DFPX_1 ='5665') THEN INF = 'I'; /* 5665-284 = MVS/XA DFP */00830000
IF (I_DFPX_1 ='5752') THEN INF = 'I'; 00840000
END; /* */00850000
/***------------------------------------------------------------- ***/00860000
/*** TRANSFER INFO INTO OUTPUT RECORD ***/00870000
/*-------------------------------------------------------------------*/00880000
OUTDD_RECORD = ''; 00890000
O_PGMNAME = PARM; /* PROGRAM NAME FROM EXEC CARD */00900000
O_DFPX_TEXT = ' (PGM MGMT:) '; 00910000
O_DFPX_1A = '-'; 00920000
O_COMP_TEXT = ' COMPILED WITH '; 00930000
O_COMP_1A = '-'; 00940000
O_DFPX_1 = I_DFPX_1; 00950000
O_DFPX_2 = I_DFPX_2; 00960000
READ FILE(INDD) INTO(PROGRAM_RECORD); 00970000
O_COMP_1 = I_COMP_1; /* COMPILER PRODUCT NR. */00980000
O_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
/*-------------------------------------------------------------------*/01030000
WRITE FILE(OUTDD) FROM(OUTDD_RECORD); 01040000
/***------------------------------------------------------------- ***/01050000
/*** CLOSE FILES ***/01060000
/*-------------------------------------------------------------------*/01070000
FINIS: 01080000
CLOSE FILE(INDD), 01090000
FILE(OUTDD); 01100000
/*-------------------------------------------------------------------*/01110000
END; 01120000
/*=============================================================== ***/01130000
Figure 42 shows the sample job to run MIGU001. You need to know the names of the
modules you want to analyze for the EXEC statements in the job. A list of all programs to be
migrated is developed during the preparation for migration (refer to “Extract Data for the
Sample 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
..
.
Figure 42. Sample Job to Run Program MIGU001
Members of a PDS are the primary output of program MIGU001. Each member contains only
one 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 on
page 81 shows this file with the output records from program MIGU001.
KR00030 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1
P03N905 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1
P92N000 (PGM MGMT:) 5665-284 COMPILED WITH 5740-CB1
P92N002 (PGM MGMT:) 5752-SC1 COMPILED WITH 40CB-1 <== old COBOL
P92N004 (PGM MGMT:) 5752-SC1 COMPILED WITH 40CB-1 <== old COBOL
P92N005 (PGM MGMT:) 5665-284 COMPILED WITH 5668-958
..
.
P92N065 (PGM MGMT:) 5665-284 COMPILED WITH ....-³.. <== PL/I
P92N066 (PGM MGMT:) 5665-284 COMPILED WITH .Ø..-573 <== PL/I
..
.
Figure 43. Output Records from Analysis of Load Modules with Program MIGU001. The old OS/VS
COBOL compiler does not record the full product number 5740-CB1. Because of the
restrictions for MIGU001, the product number output field for PL/I programs contains
garbage and manual correction is required.
The summary file in Figure 43 was sorted by compiler product number, the correct number
for the PL/I modules was inserted, and for the old OS/VS COBOL programs the number was
shifted 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 a
base to create member lists that can be used when an action for one type or one language
should be performed (for example, to copy all source modules of a given type into the
corresponding 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-CB1
..
.
* ---------------------------------------------------- VS COBOL II:
..
.
* ------------------------------------------------- ASSEMBLER H V2:
..
.
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-PL1
* ---------------------------------------------------- OS/VS COBOL:
..
.
* -------------------------------------------------- OLD ASSEMBLER:
KR00030 (PGM MGMT:) 5752-SC1 COMPILED WITH 5741-SC1
..
.
* ----------------------------------------------------------------*
Figure 44 (Part 2 of 2). Sorted Output Records from Load Module Analysis. The primary file (see
Figure 43 on page 81) was corrected for old OS/VS COBOL programs and
for 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. The
format of this information is described in VS COBOL II Application Programming: Debugging,
SC26-4049. We developed program MIGU002 to extract this control information (see
Figure 45 on page 83).
Program MIGU002 assumes that the VS COBOL II program is the first CSECT in the load
module or that it is preceded only by the CICS interface module DFHECI. The different
lengths of DFHECI for CICS Version 1 and 2 and for CICS/ESA* (Version 3) are taken into
account.
One output member is created for each load module. We used the member name of the
load module for the output member. Figure 46 on page 87 shows a sample job to run
MIGU002.
An empty member is created for programs not recognized as VS COBOL II programs. For
VS COBOL II programs the output member contains one record. The first eight bytes in this
record contain the program name that comes from the PROGRAM-ID statement in the
source code. We used an ISPF EDIT macro to verify that the program name in the source
member and the load module name are identical. We found one PROGRAM-ID that was not
identical to the load module name (resulting from a typing error in the source program) and
corrected the output file manually.
The output record has a length of 255 bytes and contains all the data from the COBOL
information bytes. We used only the information about the compiler release (modules
compiled with VS COBOL II Release 1 or 2 need option CMPR2 when compiled with VS
COBOL II Release 3) and the compiler options used.
000100*=================================================================00010000
000200 IDENTIFICATION DIVISION. 00020000
000300 PROGRAM-ID. MIGU002. 00030000
000400*=================================================================00040000
000500*** PURPOSE.....: READ LOAD MODULE FROM FILE EINGABE AND EXTRACT 00050000
000600*** VS COBOL II INFORMATION BYTES (IF VS COBOL II) 00060000
000700*** INTO OUTPUT FILE AUSGABE. 00070000
000800*** VS COBOL II MUST BE FIRST CSECT IN LOAD 00080000
000900*** MODULE OR SECOND AFTER DFH... MODULE FROM 00090000
001000*** CICS V1 / V3 OR CICS/ESA V3. 00100000
001100*** RETURN CODE: 0 = ALL OK *** 00110000
001200*** 4 = NOT RECOGNIZED AS VS COBOL II PROGRAM *** 00120000
001300*** DATE WRITTEN: 02/22/93-FITZ 00130000
001400*=================================================================00140000
001500 ENVIRONMENT DIVISION. 00150000
001600*=================================================================00160000
001700 CONFIGURATION SECTION. 00170000
001800*-----------------------------------------------------------------00180000
001900 SOURCE-COMPUTER. IBM-370. 00190000
002000 OBJECT-COMPUTER. IBM-370. 00200000
002100 SPECIAL-NAMES. 00210000
002200 DECIMAL-POINT IS COMMA. 00220000
002300 INPUT-OUTPUT SECTION. 00230000
002400 FILE-CONTROL. 00240000
002500 SELECT EINGABE 00250000
002600 ASSIGN INDD 00260000
002700 FILE STATUS IO-STATUS. 00270000
002800 SELECT AUSGABE 00280000
002900 ASSIGN OUTDD. 00290000
003000 DATA DIVISION. 00300000
003100 FILE SECTION. 00310000
003200 FD EINGABE 00320000
003300 LABEL RECORDS OMITTED 00330000
003400 RECORDING MODE IS U. 00340000
003500*-----------------------------------------------------------------00350000
003600*-- RECORD LAYOUT OF FIRST CHARACTERS OF THE INPUT RECORD ---00360000
003700*-- CONTAINING COBOL INFORMATION BYTES. ---00370000
003800*-----------------------------------------------------------------00380000
003900 01 EINGABE-SATZ. 00390000
004000 05 FILLER PIC X(04). 00400000
004100 88 E-KENNUNG-INFO VALUE X'47F0F070'. 00410000
004200 05 FILLER PIC X(72). 00420000
004300 05 FILLER PIC X(72). 00430000
004400 01 EINGABE-SATZ-CICS2. 00440000
004500 05 FILLER PIC X(06). 00450000
004600 88 E-KENNUNG-INFO-CICS1 VALUE 'DFHYC1'. 00460000
004800 05 FILLER PIC X(66). 00480000
004900 05 EINGABE-SATZ-2. 00490000
005000 10 FILLER PIC X(04). 00500000
005100 88 E-KENNUNG-INFO-2 VALUE X'47F0F070'. 00510000
005200 10 FILLER PIC X(72). 00520000
005300 01 EINGABE-SATZ-CICS3. 00530000
005400 05 FILLER PIC X(06). 00540000
005600 05 FILLER PIC X(50). 00560000
Figure 45 (Part 1 of 5). VS COBOL II Program MIGU002

005700 05 EINGABE-SATZ-3. 00570000
005800 10 FILLER PIC X(04). 00580000
005900 88 E-KENNUNG-INFO-3 VALUE X'47F0F070'. 00590000
006000 10 FILLER PIC X(72). 00600000
006100*----------------------------- 00610000
006200 FD AUSGABE 00620000
006300 BLOCK 0 RECORDS 00630000
006400 LABEL RECORDS OMITTED 00640000
006500 RECORDING MODE IS F. 00650000
006600 01 AUSGABE-SATZ PIC X(255). 00660000
006700*-----------------------------------------------------------------00670000
006800 WORKING-STORAGE SECTION. 00680000
006900*-----------------------------------------------------------------00690000
007000 01 IO-STATUS PIC X(02). 00700000
007100 88 OK VALUE '00', '04'. 00710000
007200 01 SCHALTER-1 PIC X(01). 00720000
007300 88 LESEN VALUE 'L'. 00730000
007400 88 OPEN-ERROR VALUE 'O'. 00740000
007500 88 READ-ERROR VALUE 'R'. 00750000
007600 88 EOF VALUE 'E'. 00760000
007700 01 SCHALTER-2 PIC X(01). 00770000
007800 88 GEFUNDEN VALUE 'G'. 00780000
007900 88 NICHT-VS-COBOL-2 VALUE 'N'. 00790000
008000*-----------------------------------------------------------------00800000
008100*-- RECORD LAYOUT FOR BEGIN OF INPUT RECORD ---00810000
008200*-- WITH THE COBOL INFORMATION BYTES. ---00820000
008300*-----------------------------------------------------------------00830000
008400* 00840000
008500 01 MODUL-ANFANG. 00850000
008600 05 FILLER PIC X(05). 00860000
008700 05 E-PGMNAME PIC X(08). 00870000
008800 05 E-COMPILER-KENNUNG PIC X(04). 00880000
008900 88 E-VS-COBOL-2 VALUE ' C2 '. 00890000
009000 05 E-COMPILER-V-R-M PIC X(06). 00900000
009100 05 E-COMPILE-DATE PIC X(08). 00910000
009200 05 FILLER PIC X(01). 00920000
009300 05 E-COMPILE-TIME PIC X(08). 00930000
009400 05 FILLER PIC X(04). 00940000
009500 05 E-INFO-BYTES OCCURS 24. 00950000
009600 10 E-INFO-BYTE PIC X(01). 00960000
009700 05 E-DATA-DIV-STMTS PIC S9(8) COMP. 00970000
009800 05 E-PROC-DIV-STMTS PIC S9(8) COMP. 00980000
009900* 00990000
010000 01 I PIC S9(4) COMP. 01000000
010100 01 J PIC S9(4) COMP. 01010000
010200 01 FILLER REDEFINES J. 01020000
010300 05 FILLER PIC X. 01030000
010400 05 J2 PIC X. 01040000
010500* 01050000
010600*** -------------------------------------------------------- ***01060000
010700*** VARIABLES FOR OUTPUT RECORD ***01070000
010800*** -------------------------------------------------------- ***01080000
010900* 01090000
011000 01 VARLIST. 01100000
011100 05 INFONAME PIC X(08). 01110000
011200 05 INFO-VRM PIC X(08). 01120000
011300 05 INFODATE PIC X(08). 01130000
011400 05 INFOTIME PIC X(08). 01140000
011500 05 INFO-DD PIC X(08). 01150000
011600 05 INFO-DD-NUM REDEFINES INFO-DD 01160000
011700 PIC 9(08). 01170000
011800 05 INFO-PD PIC X(08). 01180000
011900 05 INFO-PD-NUM REDEFINES INFO-PD 01190000
012000 PIC 9(08). 01200000
012100 05 FILLER OCCURS 24. 01210000
012200 10 INFO-I PIC X(08). 01220000
012300 05 INFEHLER PIC X(08). 01230000
012400 88 KEIN-FEHLER VALUE SPACE. 01240000
012500* 01250000
012600*-----------------------------------------------------------------01260000
012700*--- TABLE FOR BIT-BYTE-CONVERSION ---01270000
012800*-----------------------------------------------------------------01280000
012900* 01290000
013000 01 B-B-TABLE. 01300000
013100* 01310000
013200 05 FILLER PIC X(08) VALUE '00000000'. 01320000
014800* 01480000
..
.
..
.
040300* 04030000
040400 01 FILLER REDEFINES B-B-TABLE. 04040000
040500 05 B-B-TABLE-J PIC X(08) OCCURS 256. 04050000
040600* 04060000
040700*=================================================================04070000
040800 PROCEDURE DIVISION. 04080000
040900*=================================================================04090000
041000* 04100000
041100******************************************************************04110000
041200*** MAIN CONTROL FLOW. ***04120000
041300******************************************************************04130000
041400* 04140000

041500 STEUERUNG SECTION. 04150000
041600*-----------------------------------------------------------------04160000
041700 SET KEIN-FEHLER TO TRUE 04170000
041800 SET LESEN TO TRUE 04180000
041900 MOVE SPACE TO VARLIST. 04190000
042000* 04200000
042100 OPEN INPUT EINGABE. 04210000
042200 OPEN OUTPUT AUSGABE. 04220000
042300 IF NOT OK 04230000
042400 SET OPEN-ERROR TO TRUE 04240000
042500 MOVE 'OPENERR' TO INFEHLER 04250000
042600 ELSE 04260000
042700 PERFORM UNTIL NOT LESEN 04270000
042800 READ EINGABE AT END 04280000
042900 SET EOF TO TRUE 04290000
043000 END-READ 04300000
043100 IF (NOT EOF) AND (NOT OK) 04310000
043200 SET READ-ERROR TO TRUE 04320000
043300 MOVE 'READERR' TO INFEHLER 04330000
043400 END-IF 04340000
043500 IF LESEN AND ((E-KENNUNG-INFO OR 04350000
043600 (E-KENNUNG-INFO-CICS3 AND 04360000
043700 E-KENNUNG-INFO-3) OR 04370000
043900 E-KENNUNG-INFO-2) OR 04390000
044100 E-KENNUNG-INFO-2))) 04410000
044200 SET GEFUNDEN TO TRUE 04420000
044300 EVALUATE TRUE 04430000
044400 WHEN E-KENNUNG-INFO 04440000
044500 MOVE EINGABE-SATZ TO MODUL-ANFANG 04450000
044600 WHEN E-KENNUNG-INFO-CICS3 04460000
044700 MOVE EINGABE-SATZ-3 TO MODUL-ANFANG 04470000
045200 END-EVALUATE 04520000
045300 IF E-VS-COBOL-2 04530000
045400 PERFORM PREPARE-AUSGABE 04540000
045500 MOVE VARLIST TO AUSGABE-SATZ 04550000
045600 WRITE AUSGABE-SATZ 04560000
045700 END-IF 04570000
045800 END-IF 04580000
045900 END-PERFORM 04590000
046000 CLOSE EINGABE 04600000
046100 CLOSE AUSGABE 04610000
046200 END-IF. 04620000
046300 IF NOT GEFUNDEN 04630000
046400 MOVE 4 TO RETURN-CODE 04640000
046500 END-IF. 04650000
046600* 04660000
046700 STEUERUNG-EXIT. 04670000
046800 GOBACK. 04680000
046900* 04690000
047000******************************************************************04700000
047100*** PREPARE-AUSGABE SECTION. ***04710000
047200*** MOVE DATA FROM EINGABE-SATZ TO VARLIST ***04720000
047300*** CONVERTING BITS OF COBOL INFO BYTES TO BYTES. ***04730000
047400*** ***04740000
047500******************************************************************04750000
047600* 04760000
047700 PREPARE-AUSGABE SECTION. 04770000
047800* 04780000
047900 MOVE E-PGMNAME TO INFONAME. 04790000
048000 MOVE E-COMPILER-V-R-M TO INFO-VRM. 04800000
048100 MOVE E-COMPILE-DATE TO INFODATE. 04810000
048200 MOVE E-COMPILE-TIME TO INFOTIME. 04820000
048300 MOVE E-DATA-DIV-STMTS TO INFO-DD-NUM. 04830000
048400 MOVE E-PROC-DIV-STMTS TO INFO-PD-NUM. 04840000
048500* 04850000
048600 PERFORM WITH TEST BEFORE 04860000
048700 VARYING I FROM 1 BY 1 UNTIL I > 24 04870000
048800 MOVE ZERO TO J 04880000
048900 MOVE E-INFO-BYTE(I) TO J2 04890000
049000 ADD 1 TO J 04900000
049100 MOVE B-B-TABLE-J(J) TO INFO-I(I) 04910000
049200 END-PERFORM. 04920000
049300* 04930000
049400 PREPARE-AUSGABE-EXIT. 04940000
049500 EXIT. 04950000
049600*=================================================================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
..
.
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 88
shows the file with the output records from program MIGU002
The output was analyzed using the description of the COBOL information bytes in VS COBOL
II Application Programming: Debugging, SC26-4049. Table 3 on page 37 shows the results of
our 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 first
part of the records, which contains the COBOL information flags for the compiler options, is
shown. 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 source
code. 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 the
program release procedure (refer to “Release Process” on page 13). The extraction was
performed 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 architecture
definitions (refer to “LEC and CC Architecture Definitions” on page 123).
The process described here is specific to the application 1 environment. You may have
similar environments, for instance if you use PROCESS (or CBL) statements in your COBOL
and/or *PROCESS statements in your PL/I programs. However, even if your situation is
different, 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 production
CA-LIBRARIAN to this PDS (refer to file PP in Figure 4 on page 20). Figure 48 shows
examples of the first lines of released program source code for different programming
languages.
VS COBOL II program P92N046:
000100**MZI*CP******RES DYN RENT DATA(24)NOSSR

000200**MZI*LP******RENT AMODE=31RMODEANY
000300**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 the
language-specific comment delimiter to a language type keyword (COBOL, PLI, or ASM).
If leading control information records are not found, the macro creates one dummy
record with “???” instead of the language type keyword.
To apply the EDIT macro to all members of a PDS, we used the general-purpose EDIT
macro MIGE0000 listed in Figure 50 on page 91. Figure 51 on page 91 shows the
resulting members.
Copy all members into one file (sequential data set or member of a PDS) and sort by
type. The records with type “???” need manual correction. We used the information
about the compiler used from the corresponding load modules (refer to “Compiler
Information” on page 77) to insert the correct type. This was only required for a few old
OS/VS COBOL and Assembler modules with release dates before 1984. Default compile
options 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 00120000
ISREDIT NUMBER STD 00130000
ISREDIT UNNUM 00140000
ISREDIT FIND LAST P'=' 00150000
ISREDIT (MLINE,MCOL) = CURSOR /* OLD LAST LINE */00160000
00170000
ISREDIT FIND FIRST 9 'MZI*XX******ENDE MODUL-ZUSATZINFO' 00180000
ISREDIT (FCOUNT) = FIND_COUNTS 00190000
IF (&FCOUNT GT 0) THEN DO 00200000
ISREDIT (FLINE,FCOL) = CURSOR 00210000
ISREDIT DELETE &FLINE &MLINE 00220000
END 00230000
ELSE DO 00240000
ISREDIT DELETE 2 &MLINE 00250000
ISREDIT LINE 1 = &STR('&STR( MZI*CP******)') 00260000
END 00270000
ISREDIT (MLINE,MCOL) = CURSOR /* NEW LAST LINE */00290000
00300000
ISREDIT (LINE1) = LINE 1 00310000
SET COMM18 = &SUBSTR(1:8,&STR(&LINE1)&STR(XXXXXXXX) 00320000
SET COMM78 = &SUBSTR(7:8,&STR(&LINE1)&STR(XXXXXXXX) 00330000
SELECT 00340000
WHEN (&STR(&COMM18) = &STR(* *)) SET TYPE = ASM 00350000
WHEN (&STR(&COMM18) = &STR( /* *)) SET TYPE = PLI 00360000
WHEN (&STR(&COMM78) = &STR(**)) SET TYPE = COBOL 00370000
OTHERWISE SET TYPE = &STR(???) 00380000
END 00390000
00400000
SET X01 = &SUBSTR(1:10,&MEMBER&STR( *)) 00410000
SET X11 = &SUBSTR(1:10,&TYPE&STR( *)) 00420000
SET X = 1 00430000
DO WHILE (&X LE &MLINE) 00440000
ISREDIT (LINEX) = LINE &X 00450000
SET X21 = &SUBSTR(9:60,&LINEX) 00460000
ISREDIT LINE &X = &STR('&STR(&X01)&STR(&X11)&STR(&X21)') 00470000
SET X = &EVAL(&X + 1) 00480000
END 00490000
ISREDIT END 00500000
EXIT 00510000
Figure 49. ISPF EDIT Macro MIGE0040
Figure 50 on page 91 shows the general-purpose EDIT macro MIGE0000. This EDIT macro
allows you to execute another EDIT macro—specified as a parameter—for all members of a
PDS. To apply an EDIT macro, for example, MIGE0040, to all members of a PDS, edit a new
member, $$$ say, and type MIGE0000 MIGE0040 on the command line. Wait until * END OF
MEMBER 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
/***============================================================== ***/00090000
ISREDIT (DATA1) = DATAID 00100000
ISREDIT (CURMBR) = MEMBER 00110000
ISPEXEC LMOPEN DATAID(&DATA1) OPTION(INPUT) 00120000
SET MEMBER = 00130000
SET LCC = &LASTCC 00140000
DO WHILE (&LCC = 0) 00150000
ISPEXEC LMMLIST DATAID(&DATA1) OPTION(LIST) MEMBER(MEMBER) STATS(NO) 00160000
IF (&LCC = 0) THEN DO 00180000
IF (&MEMBER NE &CURMBR) THEN + 00190000
ISPEXEC EDIT DATAID(&DATA1) MEMBER(&MEMBER) MACRO(&MACRO2) 00200000
END 00210000
IF (&LCC = 8) THEN DO 00220000
WRITE &STR( * END OF MEMBER LIST *) 00230000
END 00240000
END 00250000
ISPEXEC LMMLIST DATAID(&DATA1) OPTION(FREE) 00260000
ISPEXEC LMCLOSE DATAID(&DATA1) 00270000
EXIT 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)NOSSR

P92N046 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 compiler
options, MZI*LP lines contain linkage editor options, and MZI*IC lines contain names of
linked 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 a
common format that is input to the automated generation of LEC and CC architecture
definitions. The generation process for architecture definitions is described in “LEC and CC
Architecture Definitions” on page 123.
Input to this reformatting is the output of the previous step. The input format is shown in
Figure 52; the resulting output is shown in Figure 53.
KR00030 ASM MZI*CP******

P92N000 COBOL MZI*CP******RES DYN
P92N002 COBOL MZI*CP******
P92N005 COBOL MZI*CP******RES DYN NORENT DATA(24)NOSSR
P92N005 COBOL MZI*LP****** AMODE=24
P92N006 ASM MZI*LP****** AMODE=24RMODE=24
P92N008 COBOL MZI*CP******NOCMPR2 DYN RENT DATA(24)NOSSR
P92N008 COBOL MZI*LP******RENT AMODE=31RMODEANY
P92N010 COBOL MZI*CP******RES DYN
..
.
..
.
Figure 52. Input for REXX Procedure MIGR0040
KR00030 ASM
P03N905 ASM
P92N000 COBOL
P92N001 ASM
P92N003 ASM
P92N006 ASM
P92N008 COBOL RENT
P92N010 COBOL
..
.
..
.
Figure 53. Output from REXX Procedure MIGR0040
The reformatting was done with the REXX procedure MIGR0040 listed in Figure 54 on
page 93. Input and output data set names for this procedure were entered in panel
MIGP0040. Figure 55 on page 96 shows the panel definition for MIGP0040.
MIGR0040 also considers the control information discussed in “Compiler Options” on
page 36 and “Control Information for the Linkage Editor” on page 41. Only the nondefault
options 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
/* ------------------------------------------------------------------ */00060000
ADDRESS ISPEXEC 00070000
"DISPLAY PANEL(MIGP0040)" /* GET DSNAMES FROM PANEL */ 00080000
IF RC = 0 THEN DO 00090000
CINNAME = "'"CINNAME"'" 00100000
COUNAME = "'"COUNAME"'" 00110000
ADDRESS TSO 00120000
"ALLOC FILE(INPFILE) DATASET("CINNAME") SHR REUSE" 00130000
"ALLOC FILE(OUTFILE) DATASET("COUNAME") OLD REUSE" 00140000
PGMPREV = ' ' 00150000
MOREINP = 1 00160000
DO WHILE MOREINP = 1 00170000
"EXECIO 1 DISKR INPFILE" 00190000
IF RC ¬= 0 THEN DO 00200000
MOREINP = 0 00210000
IF (PGMPREV ¬= ' ') THEN DO /* IF NOT FIRST INPUT MBR:*/ 00220000
/* WRITE RECORD PREV. MBR.*/ 00230000
QUEUE PGMPREV || CPINFO || LPINFO || ICINFO 00240000
"EXECIO 1 DISKW OUTFILE" 00250000
END 00260000
END 00270000
ELSE DO 00280000
PULL RECORD /* LRECL=80 EXPECTED */ 00290000
PGMINFO = SUBSTR(RECORD,1,20) /* MODULE NAME AND TYPE */ 00300000
PGMTYPE = SUBSTR(RECORD,11,10) /* MODULE TYPE */ 00310000
PGMTYPE = STRIP(PGMTYPE) 00320000
MZITYPE = SUBSTR(RECORD,25,2) /* TYPE OF CONTROL INFO */ 00330000
IF (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 00390000
PGMPREV = PGMINFO 00400000
LPINFO = LEFT(' ',40) /* DEFLT., IF NO LP INPUT */ 00410000
ICINFO = LEFT(' ',40) /* DEFLT., IF NO IC INPUT */ 00420000
END 00430000
/* CONTROL DATA IN INPUT REC = 5 * 8 CHAR */ 00440000
XX1 = SUBSTR(RECORD,33,8) 00450000
SELECT 00500000
/*------------------------------------- COMPILER OPTIONS */ 00510000
WHEN MZITYPE = 'CP' THEN DO 00520000
SELECT 00530000
WHEN PGMTYPE = 'COBOL' THEN DO 00540000
/* ----- TYPE = COBOL --------------------------*/ 00550000
SELECT 00560000
Figure 54 (Part 1 of 3). REXX Procedure MIGR0040

WHEN SUBSTR(XX4,1,4) ¬= 'DATA' THEN DO 00570000
/* ---- OS/VS COBOL ----------------------*/ 00580000
LANG = COBOL 00590000
IF XX1 = '' THEN /* WITHOUT INFO */ 00600000
XX1 = 'LANGLVL(1)' /* = OLD MODULES*/ 00610000
IF XX1 = 'RES' THEN 00620000
XX1 = ' ' /* DEFAULT "RES"*/ 00630000
IF XX2 = 'DYN' THEN 00640000
XX2 = ' ' /* DEFAULT "DYN"*/ 00650000
END 00660000
WHEN XX1 = 'NOCMPR2' THEN DO 00670000
/* ---- VS COBOL II WITH NOCMPR2 ---------*/ 00680000
LANG = COB2 00690000
/* USE "NOCMPR2"*/ 00700000
XX1 = ' ' /* FOR ALL COB2 */ 00710000
IF XX2 = 'DYN' THEN 00720000
XX2 = ' ' /* DEFAULT "DYN"*/ 00730000
/* USE "RENT" */ 00740000
XX3 = ' ' /* FOR ALL COB2 */ 00750000
IF XX4 = 'DATA(24)' THEN 00760000
XX4 = ' ' /* DEF. "DATA(24)"*/ 00770000
/* USE "NOSSR" */ 00780000
XX5 = ' ' /* FOR ALL COB2 */ 00790000
END 00800000
OTHERWISE DO 00810000
/* ---- VS COBOL II WITH CMPR2 -----------*/ 00820000
LANG = COB22 00830000
/* USE "CMPR2" */ 00840000
XX1 = ' ' /* FOR ALL COB22*/ 00850000
IF XX2 = 'DYN' THEN 00860000
XX2 = ' ' /* DEFAULT "DYN"*/ 00870000
/* USE "RENT" */ 00880000
XX3 = ' ' /* FOR ALL COB22*/ 00890000
IF XX4 = 'DATA(24)' THEN 00900000
XX4 = ' ' /* DEF. "DATA(24)"*/ 00910000
/* USE "NOSSR" */ 00920000
XX5 = ' ' /* FOR ALL COB22*/ 00930000
END 00940000
END 00950000
END 00960000
WHEN PGMTYPE = 'PLI' THEN DO 00970000
/* ----- TYPE = PLI ----------------------------*/ 00980000
LANG = PLIO 00990000
XX1 = ' ' /* IGNORE CP1, USE DEFAULT "MACRO" */ 01000000
IF XX2 = 'OPT(2)' THEN 01010000
XX2 = ' ' /* IGNORE DEFAULT "OPT(2)"*/ 01020000
IF XX5 = '' THEN /* WITHOUT INFO */ 01030000
XX5 = 'CMPAT(V1)' /* = OLD MODULES*/ 01040000
END 01050000
WHEN PGMTYPE = 'ASM' THEN DO 01060000
/* ----- TYPE = ASM ----------------------------*/ 01070000
LANG = ASMH 01080000
END 01090000
OTHERWISE 01100000
END 01110000
/*--------------------------*/ 01120000
CPINFO = STRIP(XX1) 01130000
IF XX2 ¬= ' ' THEN 01140000
CPINFO = CPINFO || ',' || STRIP(XX2) 01150000
IF XX3 ¬= ' ' THEN 01160000
IF XX4 ¬= ' ' THEN 01180000
IF XX5 ¬= ' ' THEN 01200000
CPINFO = STRIP(CPINFO,,',') 01220000
CPINFO = LEFT(CPINFO,40) 01230000
END 01240000
/*------------------------------- LINKAGE EDITOR OPTIONS */ 01250000
WHEN MZITYPE = 'LP' THEN DO 01260000
LPINFO = '' 01270000
IF ((LANG = 'COB2') | (LANG = 'COB22')) THEN DO 01280000
XX1 = 'RENT' 01290000
IF XX2 = 'AMODE=31' THEN 01300000
XX2 = ' ' 01310000
IF XX3 = 'RMODEANY' THEN 01320000
XX3 = ' ' 01330000
END 01340000
IF (LANG = 'ASMH') THEN DO /* USE CODED VALUES */ 01350000
XX2 = ' ' 01360000
XX3 = ' ' 01370000
END 01380000
IF XX2 = 'AMODEANY' THEN 01390000
XX2 = 'AMODE=ANY' 01400000
IF XX3 = 'RMODEANY' THEN 01410000
XX3 = 'RMODE=ANY' 01420000
/*--------------------------*/ 01430000
LPINFO = STRIP(XX1) 01440000
IF XX2 ¬= ' ' THEN 01450000
LPINFO = LPINFO || ',' || STRIP(XX2) 01460000
IF XX3 ¬= ' ' THEN 01470000
LPINFO = LPINFO || ',' || STRIP(XX3) 01480000
LPINFO = STRIP(LPINFO,,',') 01490000
LPINFO = LEFT(LPINFO,40) 01500000
END 01510000
/*-------------------------------- STATIC LINKED MODULES */ 01520000
WHEN MZITYPE = 'IC' THEN DO 01530000
ICINFO = SUBSTR(RECORD,33,40) 01540000
END 01550000
/*------------------------------------------------------ */ 01560000
OTHERWISE 01570000
END 01580000
END 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
/* ------------------------------------------------------------------ */01660000
EXIT 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
/**********************************************************************/
)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 2
All the information required for the migration to SCLM can be found in ENDEVOR control
information. You can use PRINT software control language (SCL) or an ENDEVOR archive
file to find compiler and linkage editor information.
Find Information for Languages

The SCL PRINT action allows you to generate software configuration lists based on different
selection criteria. You can reference other SCL statements in your action statement to
create the parameters for the requested action. Referenced statements are added to the
action statement.
We used the PRINT action B37 (see Figure 56 on page 97) which refers to statement B3 (see
Figure 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 elements
satisfying the where clause.
ACTION B37 / STMT B3

PRINT ELEMENT GNDV0050
FROM ENVIRONMENT: EMET SYSTEM: X SUBSYSTEM: L TYPE: ASM
TO FILE: C1PRINT
OPTIONS: BROWSE, COMPONENTS, NOSEARCH
WHERE CCID EQUALS SPECIFIED
Figure 56. SCL for Action B37 and Statement B3. One action must be specified. The WHERE clause
refers to the change code identifier (CCID) specification in STMT B3.
STMT B3
PRINT ELE *
FROM ENV EMET SYS X SUB L STA NUM 1 TYPE *
TO C1PRINT
WHERE CCID OF CURRENT EQ (MRWSCLM,MRWSCLM1)
OPT COMP
.
Figure 57. SCL for Statement B3. This statement provides the list of all elements that meet the
following selection parameters: environment EMET, system X, subsystem L, stage number
1, 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 editor
options 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, and
linkage editor options. This file becomes the input for tool MIGR0010 that creates CC and
LEC 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 Marc
Modifications : -------------------
****************************************************************
Comments : N/A
Instructions : N/A
***********************************************************************/
trace "n"
/**************************/
/* MAIN PROC */
/**************************/
call input
do forever
"execio 1 diskr inp "
if rc¬=0 then leave
pull record
parse value record with line
if substr(line,2,1)=x2c('58') & substr(line,54,7)¬=process then
do
element = substr(line,44,8)
type = substr(line,54,8)
if element¬=element1 then
do forever
pull record
if substr(line,2,1)=h & substr(line,28,4)=parm then
do
ccparm = substr(line,37,39)
call search_lkparm
queue element '' type '' ccparm lkparm
"execio 1 diskw outp"
leave
end
end
element1=element
end
end
exit
/**************************/
/* 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 fqnamein
fqnamein = "'"fqnamein"'"
"alloc da("fqnamein") f(inp) shr reus"
if rc¬=0 then call error fqnamein
say '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 fqnameout
return rc
/**************************/
/* SEARCH_LKPARM PROC */
/**************************/
search_lkparm:
do forever
pull record
if substr(line,2,1)=h & substr(line,25,7)=lnkparm then
do
lkparm = substr(line,37,50)
leave
end
end
return rc
/**************************/
/* ERROR PROC */
/**************************/
error:
parse upper arg filename
say 'file 'filename' does not exist'
exit rc

Appendix C. SCLM Project Definition
Figure 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
*********************************************************************** 00070000
SCLM3 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
*********************************************************************** 00270000
PROD FLMGROUP AC=(PAG),KEY=Y,ALTC=SCLM3P 00280000
TEST FLMGROUP AC=(TAG),KEY=Y,PROMOTE=PROD,ALTC=SCLM3T 00290000
MIG1 FLMGROUP AC=(MAG1),KEY=Y,PROMOTE=TEST,ALTC=SCLM3D 00300000
MIG2 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
*********************************************************************** 00030000
PAG FLMAGRP AC=(FUA,NDV) 00040000
TAG FLMAGRP AC=(FUA,NDV) 00050000
MAG1 FLMAGRP AC=(FUA) 00060000
MAG2 FLMAGRP AC=(NDV) 00070000
Figure 60. Authorization Codes for Project SCLM3: ASCLM3
*********************************************************************** 00010000
** PROJECT CONTROLS 00020000
*********************************************************************** 00030000
* 00040000
FLMCNTRL ACCT=SCLM3.ACCOUNT.FILE, C00050000
LIBID=SCLM3, C00060000
MAXVIO=10000, C00070000
OPTOVER=Y, C00080000
VERPDS=@@FLMPRJ.@@FLMGRP.@@FLMTYP.VERSION, C00090000
VERS=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
* 00050000
SCLM3P FLMALTC ACCT=STLPROD.SCLM3.ACCOUNT.FILE, C00060000
VERS=STLPROD.SCLM3.AUDIT.FILE 00070000
* 00080000
SCLM3T FLMALTC ACCT=STLTEST.SCLM3.ACCOUNT.FILE 00090000
* 00100000
SCLM3D FLMALTC ACCT=STLDEV.SCLM3.ACCOUNT.FILE 00110000
* 00120000
Figure 62. Flexible Database Specification for Project SCLM3: FSCLM3
*********************************************************************** 00010000
** DEFINE THE TYPES 00020000
*********************************************************************** 00030000
ARCHDEF FLMTYPE 00040000
* 00050000
ASM FLMTYPE EXTEND=ASMMACS 00060000
ASMMACS FLMTYPE 00070000
COBCOPY FLMTYPE 00080000
COBOL FLMTYPE EXTEND=COBCOPY 00090000
DB2CLIST FLMTYPE EXTEND=DBRM 00100000
DB2OUT FLMTYPE 00110000
SQL FLMTYPE 00120000
PLI FLMTYPE 00130000
* 00140000
DBRM FLMTYPE 00150000
OBJ FLMTYPE 00160000
LIST FLMTYPE 00170000
LMAP FLMTYPE 00180000
LOAD FLMTYPE 00190000
* 00200000
CLIST FLMTYPE 00210000
PANELS FLMTYPE 00220000
SKELS FLMTYPE 00230000
MSGS 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 -- 00080000
COPY F@COBL -- OS/VS COBOL -- 00090000
COPY F@COB2 -- VS COBOL II -- 00100000
COPY F@COB22 -- VS COBOL II WITH CMPR2 -- 00110000
COPY F@PLIO -- PL/I OPTIMIZER -- 00120000
COPY F@AD2 -- DB2 + ASSEMBLER H -- 00130000
COPY FLM@BD2 -- FOR DB2 BIND -- 00140000
COPY FLM@BDO -- FOR DB2 BIND -- 00150000
COPY F@SCMD -- FOR DB2 DDL SUBCOMMANDS -- 00160000
COPY F@L370 -- LINKAGE EDITOR -- 00170000
* 00180000
COPY FLM@CLST -- TSO CLIST -- 00190000
COPY F@PANELS -- ISPF PANELS -- 00200000
COPY F@@SKEL -- ISPF SKELETONS -- 00210000
COPY 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 Definitions
Figure 66 through Figure 76 on page 122 show the SCLM language definitions that we either
created or modified for the project. Modifications for our project are marked with @@ in
positions 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
*********************************************************************** 00440000
ASMH FLMSYSLB SYS1.MACLIB 00450000
* 00460000
FLMLANGL LANG=ASMH,VERSION=ASMHV2.1 00470000
* 00480000
* PARSER TRANSLATOR 00490000
* 00500000
FLMTRNSL CALLNAM='SCLM ASM H PARSE', C00510000
FUNCTN=PARSE, C00520000
COMPILE=FLMLPGEN, C00530000
PORDER=1, C00540000
OPTIONS=(SOURCEDD=SOURCE, C00550000
STATINFO=@@FLMSTP, C00560000

LISTINFO=@@FLMLIS, C00570000
LISTSIZE=@@FLMSIZ, C00580000
LANG=A) *** THIS IS ASSEMBLER ONLY *** 00590000
* (* SOURCE *) 00600000
FLMALLOC IOTYPE=A,DDNAME=SOURCE 00610000
FLMCPYLB @@FLMDSN(@@FLMMBR) 00620000
* 00630000
* BUILD TRANSLATOR(S) 00640000
* 00650000
* --ASSEMBLER 'H' INTERFACE-- 00660000
FLMTRNSL CALLNAM='ASM H', C00670000
FUNCTN=BUILD, C00680000
COMPILE=IEV90, C00690000
VERSION=2.1, C00700000
GOODRC=4, @@C00710000
PORDER=1, C00720000
PARMKWD=PARM1, @@C00730000
OPTIONS=(XREF(SHORT), @@C00740000
NODECK,OBJECT) @@ 00750000
* 00760000
* DDNAME ALLOCATIONS 00770000
* 00780000
FLMALLOC IOTYPE=S,DDNAME=SYSIN,KEYREF=SINC,RECNUM=9000 00790000
FLMALLOC IOTYPE=W,DDNAME=SYSUT1,RECNUM=15000 00800000
FLMALLOC IOTYPE=O,DDNAME=SYSLIN,KEYREF=OBJ,RECNUM=9000,DFLTTYP=OBJ 00810000
FLMALLOC IOTYPE=A,DDNAME=SYSTERM 00820000
FLMCPYLB NULLFILE 00830000
FLMALLOC IOTYPE=A,DDNAME=SYSPUNCH 00840000
FLMALLOC IOTYPE=I,DDNAME=SYSLIB,KEYREF=SINC 00860000
* ADD ONE FLMCPYLB FOR EACH FLMSYSLB 00870000
FLMCPYLB SYS1.MACLIB 00880000
FLMALLOC 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', C
FUNCTN=BUILD, C
COMPILE=IEWL, C
VERSION=F64, C
GOODRC=0, C
PORDER=3, C
OPTIONS=(DCBS,LET,LIST,XREF) @@
*
* 1 (* SYSLIN *)
FLMALLOC IOTYPE=S,KEYREF=INCL,RECFM=FB,LRECL=80, C
RECNUM=20000,DDNAME=SYSLIN
*
* 2 (* LOAD MODULE NAME *)
FLMALLOC IOTYPE=L,KEYREF=LOAD
*
* 3 (* SYSLMOD *)
FLMALLOC IOTYPE=P,KEYREF=LOAD,RECFM=U,LRECL=0, C
RECNUM=500,DIRBLKS=20,DDNAME=SYSLMOD
*
* 4 (* SYSLIB *)
FLMALLOC IOTYPE=A,DDNAME=SYSLIB
FLMCPYLB 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, C
RECNUM=2500,PRINT=Y,DDNAME=SYSPRINT

*
* 7 (* N/A *)
FLMALLOC IOTYPE=N
*
* 8 (* SYSUT1 *)
FLMALLOC IOTYPE=W,RECFM=U,LRECL=0,RECNUM=5000, C
DDNAME=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=SYSTERM
FLMCPYLB 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
*@@ -- DSNAME parameter inserted for IFKCBL00 @@* 00000600
*@@ -- GOODRC=0 --> GOODRC=4 @@* 00000700
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
* * 00001900
* * 00002100
* EXAMPLE: * 00002500
* COBL FLMSYSLB XXXXX.XXXXX.XXXXX * 00002600
* * 00002800
* * 00003100
* * 00003300
* * 00003500
* INVOKED. * 00003800
* * 00003900
* * 00004200
*********************************************************************** 00004300
* * 00004500
* * 00004600
*********************************************************************** 00004700
FLMLANGL LANG=COBOL,VERSION=COBLV1.0, C00004800
TSLINL=80, C00004900
TSSEQP='S 1 6 S 73 80' 00005000
* 00005100
* 00005300
FLMTRNSL CALLNAM='SCLM COBOL PARSE', C00005400
COMPILE=FLMLPCBL, C00005600
PORDER=1, C00005700
OPTIONS=(@@FLMLIS,@@FLMSTP,@@FLMSIZ,) 00005800
* (* SOURCE *) 00005900
* 00006200
* 00006400

* --COBOL INTERFACE-- 00006500
FLMTRNSL CALLNAM='COBOL', C00006600
COMPILE=IKFCBL00, C00006800
DSNAME=VSCOBOL.V1R2M4.VSCOLIB, @@C00006900
VERSION=1.2, @@C00007000
GOODRC=4, @@C00007100
PORDER=1, C00007200
OPTIONS=(DMA,PRI,SIZE=512K,APOS,CNT=60,BUF=30K,OPT, @@C00007400
LIB,RES,DYN,ENDJOB,NOADV,NOSEQ,XREF) @@ 00007500
* 00007600
* 00007800
FLMALLOC IOTYPE=A,DDNAME=SYSUT5 00008600
FLMALLOC IOTYPE=A,DDNAME=SYSUT6 00008800
FLMALLOC IOTYPE=O,DDNAME=SYSPRINT,KEYREF=LIST,RECFM=FBA,LRECL=121, C00009400
RECNUM=50000,PRINT=Y,DFLTTYP=LIST @@ 00009500
* 00009600
F@COB2 for VS COBOL II
*********************************************************************** 00000100
* COBOL II LANGUAGE DEFINITION FOR SCLM * 00000200
*@@ for ANSI85 Standard (NOCMPR2) @@* 00000300
*@@*****************************************************************@@* 00000400
*@@ -- DSNAME parameter inserted for IGYCRCTL @@* 00000600
*@@ -- GOODRC=0 --> GOODRC=4 @@* 00000700
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
* * 00001700
* * 00001900
* EXAMPLE: * 00002300
* COB2 FLMSYSLB XXXXX.XXXXX.XXXXX * 00002400
* * 00002600
* * 00002900
* * 00003100
* * 00003300
* INVOKED. * 00003600
* * 00003700
* * 00004000
* THIS LANGUAGE DEFINITION IS COMPATIBLE WITH THE AD/CYCLE COBOL * 00004100
* COMPILER. * 00004200
* * 00004300
*********************************************************************** 00004400
* * 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, C00005400
TSLINL=80, C00005500
TSSEQP='S 1 6 S 73 80' 00005600
* 00005700
* 00005900
PORDER=1, C00006300
CALLMETH=LINK, C00006400

* (* SOURCE *) 00006600
* 00006900
* 00007000
* --COBOL II INTERFACE-- 00007100
* 00007200
FLMTRNSL CALLNAM='COBOL II COMPILER', C00007300
COMPILE=IGYCRCTL, C00007500
DSNAME=COBOL.V1R3M2.COB2COMP, @@C00007600
VERSION=1.3.2, @@C00007700
GOODRC=4, @@C00007800
PORDER=1, C00007900
OPTIONS=(NOADV,APOST,DATA(24),DYN,LIB,MAP, @@C00008100
FLAG(I,W), @@C00008200
OFFSET,OPT,RENT,RES,NOSEQ,TRUNC(BIN),XREF,ZWB) @@ 00008300
* 00008400
* DDNAME ALLOCATION 00008500
* 00008600
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
*@@ -- 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
*@@ -- Compile options completely customized @@* 00001300
*@@ -- DEFLTTYP for IGYCRCTL SYSPRINT COMPLIST --> LIST @@* 00001400
*@@ @@* 00001500
********************** GENERAL NOTES ******************************** 00001600
* * 00001700
* * 00002100
* * 00002300
* EXAMPLE: * 00002700
* COB2 FLMSYSLB XXXXX.XXXXX.XXXXX * 00002800
* * 00003000
* * 00003300
* * 00003500
* * 00003700
* INVOKED. * 00004000
* * 00004100
* * 00004400
* THIS LANGUAGE DEFINITION IS COMPATIBLE WITH THE AD/CYCLE COBOL * 00004500
* COMPILER. * 00004600
* * 00004700
*********************************************************************** 00004800
* * 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, @@C00005800
TSLINL=80, C00005900
TSSEQP='S 1 6 S 73 80' 00006000
* 00006100
* 00006300

PORDER=1, C00006700
* (* SOURCE *) 00007000
* 00007300
* 00007400
* --COBOL II INTERFACE-- 00007500
* 00007600
FLMTRNSL CALLNAM='COBOL II COMPILER', C00007700
COMPILE=IGYCRCTL, C00007900
DSNAME=COBOL.V1R3M2.COB2COMP, @@C00008000
VERSION=1.3.2, @@C00008100
GOODRC=4, @@C00008200
PORDER=1, C00008300
OPTIONS=(NOADV,APOST,DATA(24),DYN,LIB,MAP, @@C00008500
CMPR2,FLAGMIG,FLAG(I,W), @@C00008600
OFFSET,OPT,RENT,RES,NOSEQ,TRUNC(BIN),XREF,ZWB) @@ 00008700
* 00008800
* DDNAME ALLOCATION 00008900
* 00009000
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

*@@ -- 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
* * 00001700
* * 00001900
* EXAMPLE: * 00002300
* PLIO FLMSYSLB XXXXX.XXXXX.XXXXX * 00002400
* * 00002600
* * 00002900
* * 00003100
* * 00003300
* INVOKED. * 00003600
* * 00003700
* * 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
* * 00004700
* * 00004800
*********************************************************************** 00004900
FLMLANGL LANG=PLIO,VERSION=PLIOV4.0 00005000
* 00005100
* 00005300
FLMTRNSL CALLNAM='SCLM PL/I PARSE', C00005400

PORDER=1, C00005700
LANG=I) 00006200
* (* SOURCE *) 00006300
* 00006600
* 00006800
* --PL/I OPTIMIZER INTERFACE-- 00006900
FLMTRNSL CALLNAM='PL/I OPTIMIZER', C00007000
COMPILE=IEL0AA, C00007200
DSNAME=PLI.V2R3M0.PLICOMP, @@C00007300
VERSION=4.0, C00007400
GOODRC=4, @@C00007500
PORDER=1, C00007600
OPTIONS=(FLAG(I),MACRO, @@C00007700
MAP,NUM,OBJECT,OFFSET,OPT(2),OPTIONS,SOURCE,XREF) @@ 00007800
* 00007900
* 00008100
FLMALLOC IOTYPE=S,DDNAME=SYSCIN,KEYREF=SINC,RECNUM=2000 00008500
FLMALLOC IOTYPE=A,DDNAME=SYSIN 00008600
FLMALLOC IOTYPE=O,DDNAME=SYSPRINT,KEYREF=LIST,DFLTTYP=LIST, C00009000
PRINT=Y,RECNUM=5000 00009100
* 00009200
F@AD2 for Assembler H with DB2
*********************************************************************** 00010000
* FLM@AD2 - ASMH/DB2 PREPROCESS AND ASSEMBLE * 00020000
* * 00030000
*@@*****************************************************************@@* 00040000
*@@ -- FLMSYSLB/FLMCPYLB DCB.V3R3M0.CSPBD2 not used (no CSP) @@* 00060000
*@@ -- GOODRC=0 --> GOODRC=4 @@* 00070000
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
* * 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
*********************************************************************** 00270000
ASMDB2 FLMSYSLB SYS1.MACLIB 00280000
* FLMSYSLB DCB.V3R3M0.CSPDB2 @@ 00290000
* 00300000
FLMLANGL LANG=ASMDB2 00310000
* 00320000
* 00340000
FLMTRNSL CALLNAM='SCLM ASM H PARSE', C00350000
PORDER=1, C00380000
LANG=A) *** THIS IS ASSEMBLER ONLY *** 00430000
* (* SOURCE *) 00440000
* 00470000
* BUILD TRANSLATORS 00480000
* 00490000
* --DB2 PREPROCESSOR INTERFACE-- 00500000
FLMTRNSL CALLNAM='ASMDB2 PREPROC', C00510000
COMPILE=DSNHPC, C00530000
VERSION=1.0, C00540000
GOODRC=4, C00550000
PORDER=3, C00560000
OPTIONS=(HOST(ASM)) 00590000
* 1 -- N/A -- 00600000
FLMALLOC IOTYPE=N 00610000
* 2 -- N/A -- 00620000
* 3 -- N/A -- 00640000

* 4 -- SYSLIB -- 00660000
FLMALLOC IOTYPE=I,KEYREF=SINC 00670000
* 5 -- SYSIN -- 00680000
FLMALLOC IOTYPE=S,KEYREF=SINC,RECFM=FB,LRECL=80, C00690000
RECNUM=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, C00770000
RECNUM=9000,PRINT=I 00780000
******* The preceding lines added for APAR OY39985 ******************** 00790000
* 7 -- N/A -- 00800000
* 8 -- SYSUT1 -- 00820000
FLMALLOC IOTYPE=W,RECFM=FB,LRECL=800,RECNUM=9000 00830000
* 9 -- SYSUT2 -- 00840000
* 10 -- SYSUT3 -- 00860000
* 11 -- N/A -- 00880000
* 12 -- SYSTERM -- 00900000
FLMALLOC IOTYPE=A 00910000
* 13 -- N/A -- 00930000
* 14 -- SYSCIN -- 00950000
FLMALLOC IOTYPE=W,RECFM=FB,LRECL=80, C00960000
RECNUM=9000,DDNAME=SYSCIN 00970000
* 15 -- N/A -- 00980000
* 16 -- DBRMLIB-- 01000000
FLMALLOC IOTYPE=P,DDNAME=DBRMLIB,MEMBER=@@FLMONM, C01010000
DFLTTYP=DBRM,KEYREF=OUT1, C01020000
RECFM=FB,LRECL=80,RECNUM=5000,DIRBLKS=1 01030000
* 01040000
* --ASSEMBLER 'H' INTERFACE-- 01050000
FLMTRNSL CALLNAM='ASMDB2 ASSEM', C01060000
COMPILE=IEV90, C01080000
GOODRC=4, @@C01090000
PORDER=3, C01100000
OPTIONS=(XREF(SHORT), @@C01120000
NODECK,OBJECT) @@ 01130000
* 1 --SYSLIN-- 01140000
FLMALLOC IOTYPE=O,KEYREF=OBJ,RECFM=FB,LRECL=80, C01150000
RECNUM=9000,DFLTTYP=OBJ 01160000
* 2 --N/A-- 01170000
* 3 --N/A-- 01190000

* 4 --SYSLIB-- 01210000
FLMALLOC IOTYPE=I,KEYREF=SINC 01220000
FLMCPYLB 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, C01280000
RECNUM=20000,PRINT=I,DFLTTYP=LIST 01290000
* 7 --SYSPUNCH-- 01300000
* 8 --SYSUT1-- 01330000
* 9 --SYSTERM-- 01350000
* 01380000
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
* * 00001400
*********************************************************************** 00001500
* * 00001600
* CUSTOMIZATION IS NOT REQUIRED. * 00001700
*********************************************************************** 00001800
* * 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

* 00002600
FLMTRNSL CALLNAM='SCLM SCMD PARSE', @@C00002700
PORDER=1, C00003000
LANG=T) 00003500
* (* SOURCE *) 00003600
* 00003900
* 00004100
Figure 73 (Part 2 of 2). Language Definition F@SCMD for DB2 DDL Subcommands
F@PANELS for ISPF Panels
*********************************************************************** 00000100
* * 00000300
*@@*****************************************************************@@* 00000400
*@@ -- FLMLANGL und CALLNAM modified for PANELS @@* 00000600
*@@ @@* 00000700
********************** GENERAL NOTES ******************************** 00000800
* * 00000900
* * 00001300
*********************************************************************** 00001400
* * 00001500
*********************************************************************** 00001700
* * 00001900
* * 00002000
*********************************************************************** 00002100
FLMLANGL LANG=PANELS,VERSION=V1.0 @@ 00002200
* 00002300
Figure 74 (Part 1 of 2). Language Definition F@PANELS for ISPF Panels

* 00002500
FLMTRNSL CALLNAM='SCLM PANELS PARSE', @@C00002600
PORDER=1, C00002900
LANG=T) 00003400
* (* SOURCE *) 00003500
* 00003800
* 00004000
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
* 00080000
FLMTRNSL CALLNAM='SCLM SKEL PARSER', C00090000
COMPILE=PSKELS, C00110000
DSNAME=SCLM3.RESI.LOAD, C00120000
PORDER=1, C00130000
GOODRC=0, C00140000
VERSION-V1R1M0, C00150000
OPTIONS='/@@FLMSTP,@@FLMLIS,@@FLMSIZ,' 00160000
* (* SOURCE *) 00170000
FLMALLOC IOTYPE=A,DDNAME=SSOURCE 00180000
* (* LISTING *) 00200000
FLMALLOC IOTYPE=W,DDNAME=ERROR, C00210000
RECFM=VBA,LRECL=133,RECNUM=6000,PRINT=Y 00220000
* (* LISTING *) 00230000
FLMALLOC IOTYPE=W,DDNAME=SYSPRINT, C00240000
RECFM=VBA,LRECL=133,RECNUM=6000,PRINT=Y 00250000
* 00260000
Figure 75. Language Definition F@@SKEL for ISPF Skeletons. For information about the parser, refer
to SCLM Guide and Reference, SC34-4254. The parser looks for embedded skeletons and
stores the names for these included members in the accounting file.

F@MSGS for ISPF Messages
*********************************************************************** 00000100
* * 00000300
*@@*****************************************************************@@* 00000400
*@@ -- FLMLANGL und CALLNAM modified for MSGS @@* 00000600
*@@ @@* 00000700
********************** GENERAL NOTES ******************************** 00000800
* * 00000900
* * 00001300
*********************************************************************** 00001400
* * 00001500
*********************************************************************** 00001700
* * 00001900
* * 00002000
*********************************************************************** 00002100
FLMLANGL LANG=MSGS,VERSION=V1.0 @@ 00002200
* 00002300
* 00002500
FLMTRNSL CALLNAM='SCLM MSGS PARSE', @@C00002600
PORDER=1, C00002900
LANG=T) 00003400
* (* SOURCE *) 00003500
* 00003800
* 00004000
Figure 76. Language Definition F@MSGS for ISPF Messages

Appendix D. Generation of Architecture Definitions
Architecture definitions are an important concept in SCLM, and as part of the migration you
might have to create many new architecture definition members. We used tools to automate
the creation of architecture definitions, and this appendix describes our tools.
LEC and CC Architecture Definitions

We developed a tool to create LEC and CC architecture definitions. The tool consists of the
following modules:
REXX procedure MIGR0010
ISPF panel MIGP0010
ISPF help panel MIGH0010
ISPF skeletons MIGS0010 and MIGS0011.
The tool is started in a TSO/ISPF environment by entering: TSO %MIGR0010. After the tool
is started, it prompts you for the input and output data set names with panel MIGP0010 (refer
to Figure 77 on page 124).
The accompanying help panel MIGH0010 explains the format of the input record (refer to
Figure 78 on page 124). A maximum of 180 bytes of the input record are interpreted. If the
records are shorter, they will be padded with blanks. Sample input and output files and the
naming conventions for architecture definitions used in our project are shown in “Creating
LEC and CC Architecture Definitions” on page 44.
For each input record an LEC architecture definition member is created. The LEC member
name is the program name. If the input record contains compiler options, a CC member is
created in addition. The CC member name is “ C ” plus the first seven characters of the
program name. If a CC member is to be created for a program with an eight-digit name, the
CC 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 ARCHDEF

members 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 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
á ñ
Figure 78. ISPF Help Panel MIGH0010. This help panel explains the required record layout for the
input file.
Figure 79 on page 125 through Figure 83 on page 129 show the listings of all modules
belonging to this tool.

/***** REXX ***********************************************************/00010000
/* PURPOSE.....: CREATE LEC (AND CC) ARCHDEF FROM INPUT LIST */00020000
/**********************************************************************/00040000
/* TRACE R */ 00050002
/* ------------------------------------------------------------------ */00060000
"DISPLAY PANEL(MIGP0010)" 00080000
IF RC = 0 THEN DO 00090000
LENAME = "LE370" /* NAME OF TRANSLATOR FOR LINK EDIT */00100000
INPNAME = "'"INPNAME"'" 00110000
OUTNAME = "'"OUTNAME"'" 00120000
"ALLOC FILE(INPFILE) DATASET("INPNAME") SHR REUSE" 00140000
"ALLOC FILE(ISPFILE) DATASET("OUTNAME") SHR REUSE" 00150000
MOREINP = 1 00160000
IF RC ¬= 0 THEN DO 00200000
MOREINP = 0 00210000
END 00220000
ELSE DO 00230000
PULL RECORD /* MAX. LRECL=180 EXPECTED */00240009
PGMNAME = SUBSTR(RECORD,1,8) 00250000
PGMTYPE = SUBSTR(RECORD,11,8) 00260000
LECNAME = PGMNAME /* LEC MBR = SOURCE NAME */ 00270009
CCPARM = SUBSTR(RECORD,21,40) 00290001
LEPARM = SUBSTR(RECORD,61,40) /* NON-DEFAULT COMP. OPT. */ 00291009
ICPARM = SUBSTR(RECORD,101,80) /* FOR MAX. 10 STAT. LKED.*/ 00291109
/* CREATE CC ARCHDEF ONLY IF COMPILER OPTION(S) SUPPLIED */ 00293005
IF CCPARM ¬= ' ' THEN DO 00360001
PGMNAM7 = SUBSTR(RECORD,1,7) 00360101
CCNAME = "C"PGMNAM7 00360201
IF SUBSTR(RECORD,8,1) ¬= ' ' THEN DO 00360301
T1 = "*** CC ARCHDEF NAME FOR PGM" 00360401
T2 = "TRUNCATED TO" 00360501
T3 = "***" 00360601
SAY 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 00401107
ICPAR0 = SUBSTR(ICPARM,01,8) 00401208
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 00410000
END 00420000
"EXECIO 0 DISKR INPFILE (FINIS" 00440000
"FREE FILE(INPFILE)" 00450000
"FREE FILE(ISPFILE)" 00460000
END 00470000
/* ------------------------------------------------------------------ */00480000
EXIT 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
/**********************************************************************/
)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
/**********************************************************************/
)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 41
LKED!&LENAME! !* TRANSLATOR FOR LINK EDIT
LOAD!&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 = &Z
INCLD!&PGMNAME!&PGMTYPE!* SOURCE MODULE
)ENDSEL
)CM ..........................IF CC ARCHDEF GENERATED, TOO:
)SEL &CCPARM NE &Z
INCL!&CCNAME!ARCHDEF!* CC ARCHDEF MEMBER
)ENDSEL
)CM -------------------------------------------------------------------
)CM ..........................IF PARM OPTIONS REQUIRED:
)SEL &LEPARM NE &Z
PARM &LEPARM
)ENDSEL
)CM -------------------------------------------------------------------
)CM ..........................IF OTHER MODULES ARE STATIC LINKED:
)SEL &ICPARM NE &Z
)SEL &ICPAR0 NE &Z
INCL!&ICPAR0!ARCHDEF!* STATIC LINKED MODULE
)ENDSEL
)SEL &ICPAR1 NE &Z
)ENDSEL
)SEL &ICPAR2 NE &Z
)ENDSEL
)SEL &ICPAR3 NE &Z
)ENDSEL
)SEL &ICPAR4 NE &Z
)ENDSEL
)SEL &ICPAR5 NE &Z
)ENDSEL
)SEL &ICPAR6 NE &Z
)ENDSEL
)SEL &ICPAR7 NE &Z
)ENDSEL
)SEL &ICPAR8 NE &Z
)ENDSEL
)SEL &ICPAR9 NE &Z
)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 41
OBJ!&PGMNAME!OBJ!* OBJECT MODULE
LIST!&PGMNAME!LIST!* COMPILER LISTING
SINC!&PGMNAME!&PGMTYPE!* SOURCE MODULE
)CM ..........................IF COMPILER PARM OPTIONS REQUIRED:
)CM ..........................BUILD TRANSLATOR MUST HAVE PARMKWD=PARM1
)SEL &CCPARM NE &Z
PARM1 &CCPARM
)ENDSEL
)CM *******************************************************************
Figure 83. ISPF Skeleton MIGS0011
HL Architecture Definitions and DB2CLISTs

When a DB2 program is under SCLM control, a BUILD action against its related LEC
architecture definition calls the DB2 precompiler, compiler, and linkage editor. The DB2 plan
for the program is bound by building the DB2CLIST member. An HL architecture definition
should be created to synchronize these two build processes.
REXX program MIGR0050 provides an automatic way of creating the HL architecture
definition and DB2CLIST members. “Creating LEC and CC Architecture Definitions” on
page 44 describes how MIGR0010 creates LEC architecture definitions. We can also use
MIGR0050 to create HL architecture definitions that refer to other HL or LEC architecture
definitions without a relationship to a DB2CLIST.
/* REXX */ 00010002
/***********************************************************************00020002
MIGR0050 : 00030002
Purpose : 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 00160002
Modifications : ------------------- 00170002
**************************************************************** 00180002
Comments : N/A 00190002
Instructions : Outputs are to be migrated after program run 00200002
: (SCLM migration). 00210002
***********************************************************************/00220002
trace "n" 00230002
/**************************/ 00240002
/* MAIN PROC */ 00250002
/**************************/ 00260002
00270002
call init /* first initialization */ 00280002
call init_default /* default initialization */ 00290002
call input /* get all the input parameters */ 00300002
call getok /* get go confirmation */ 00310002
call hlaproc /* processing */ 00320002
exit 00330002
/**************************/ 00340002
/* INIT PROC */ 00350002
/**************************/ 00360002
init: 00370002
Proj = ' ' 00380002
qual = ' ' 00390002
Grp = ' ' 00400002
hla = ' ' 00410002
db2req = ' ' 00420002
db2plan = ' ' 00430002
dsys = ' ' 00440002
appl1 = ' '; appl2 = ' '; appl3 = ' '; appl4 = ' '; appl5 = ' ' 00450002
appl6 = ' '; appl7 = ' '; appl8 = ' '; appl9 = ' '; appl10 = ' ' 00460002
mod1 = ' '; mod2 = ' '; mod3 = ' '; mod4 = ' '; mod5 = ' ' 00470002
mod6 = ' '; mod7 = ' '; mod8 = ' '; mod9 = ' '; mod10 = ' ' 00480002
return rc 00490002
/**************************/ 00500002
/* INIT_DEFAULT PROC */ 00510002
/**************************/ 00520002
init_default: 00530002
dftdsys = 'DBP1' 00540002
bparm1 = 'VALIDATE (BIND)' 00550002
bparm2 = 'ISOLATION (CS)' 00560002
bparm3 = ' ' 00570002
bparm4 = ' ' 00580002
bparm5 = ' ' 00590002
bparm6 = ' ' 00600002
bparm7 = ' ' 00601002
bparm8 = ' ' 00602002
bparm9 = ' ' 00603002

bparm10 = ' ' 00604002
return rc 00605002
/**************************/ 00606002
/* INPUT PROC */ 00607002
/**************************/ 00608002
input: 00609002
/*----- get project name -------------------*/ 00610002
do forever 00611002
Call pmsg 1 /* ask for project name */ 00612002
Parse upper pull proj 00613002
if proj /= ' ' then leave 00614002
end 00615002
/*----- get 1st qualifier name -------------*/ 00616002
Call pmsg 2 /* ask for 1st qualifier*/ 00617002
Parse upper pull qual 00618002
if qual = ' ' then qual=proj 00619002
/*----- get group name -------------------*/ 00620002
Call pmsg 3 /* ask for group name */ 00630002
Parse upper pull grp 00640002
/*----- get hl archdef name ---------------*/ 00650002
Call pmsg 4 /* ask for HLA name */ 00660002
Parse upper pull hla 00670002
/*----- get DB2 include appl names --------*/ 00680002
Call pmsg 5 /* ask for appl names*/ 00690002
Parse 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*/ 00730002
Parse 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 */ 00770002
Parse upper pull db2req 00780002
if db2req = ' ' | db2req = 'NO' then db2req = 'N' 00790002
/*----- get db2 plan name -----------------*/ 00800002
if db2req /= 'N' 00810002
then do 00820002
Call pmsg 8 /* ask for DB2 plan name*/ 00830002
Parse upper pull db2plan 00840002
end 00850002
/*----- get db2 subsystem name ------------*/ 00860002
if db2req /= 'N' 00870002
then do 00880002
Call pmsg 9 /* ask for DB2 subsyst */ 00890002
Parse upper pull dsys 00900002
if dsys = ' ' then dsys = dftdsys 00910002
end 00920002
return rc 00930002
/**************************/ 00940002
/* GETOK PROC */ 00950002
/**************************/ 00960002
getok: 00970002
Say '_______________________________________________' 00980002
Say ' you are about to create the following : ' 00990002
Say ' ' 01000002
Say ' High Level Architecture ....:'hla 01010002

Say ' for project ................:'proj 01020002
Say ' in data sets ...............:'qual'.'grp'.xxxx ' 01030002
Say ' including DB2 applications .:'appl1 appl2 appl3 01040002
Say ' :'appl4 appl5 appl6 01050002
Say ' :'appl7 appl8 appl9 01060002
Say ' :'appl10 01070002
if mod1 /= ' ' 01080002
then do 01090002
Say ' and non DB2 applications .:'mod1 mod2 mod3 01100002
Say ' :'mod4 mod5 mod6 01110002
Say ' :'mod7 mod8 mod9 01120002
Say ' :'mod10 01130002
end 01140002
if db2req /= 'N' then 01150002
do 01160002
Say ' DB2 clist with plan name ....:'db2plan 01170002
Say ' DB2 sub-system name..........:'dsys 01180002
end 01190002
if db2req /= 'N' then 01200002
do 01210002
if bparm1 /= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm1 01220002
if bparm10/= ' ' then Say ' DB2 DEFAULT BIND parameter...:'bparm10 01301002
end 01302002
Say ' ' 01302102
Say '_______________________________________________' 01302202
Say ' type Y to confirm or A to abort ' 01302302
Say '_______________________________________________' 01302402
parse upper pull confirm 01302502
if confirm = 'Y' then return rc 01302602
if confirm = 'A' then exit 01302702
exit 01302802
/**************************/ 01302902
/* HLAPROC PROC */ 01303002
/**************************/ 01304002
hlaproc: 01305002
/*----- create db2clist --*/ 01306002
call ARCHOPE hla 01307002
call clist 01308002
/*----- create qual.group.ARCHDEF(hla)--*/ 01309002
call ARCHOPE hla 01310002
newstack 01320002
count=0 01330002
if appl1 /='' then queue 'INCL' appl1 'ARCHDEF' 01340002

if appl10/='' then queue 'INCL' appl10 'ARCHDEF' 01430002
if mod1 /='' then queue 'INCL' mod1 'ARCHDEF' 01440002
if mod10/='' then queue 'INCL' mod10 'ARCHDEF' 01530002
if db2req/='N' then queue 'INCLD' hla 'DB2CLIST * BIND DB2 plan' 01540002
call ARCHWR 01550002
delstack 01560002
call ENDMSG 01570002
hla=' ' 01580002
return rc 01590002
/**************************/ 01600002
/* ARCHOPE PROC */ 01610002
/**************************/ 01620002
archope: 01630002
parse upper arg xmember 01640002
/*----open ARCHDEF member -------------start----------*/ 01650002
arch = "'"||qual||'.'||grp||'.ARCHDEF('||xmember||")'" 01660002
"alloc da("arch") fi(archdef) shr reuse" 01670002
Return rc 01680002
/**************************/ 01690002
/* ARCHWR PROC */ 01700002
/**************************/ 01710002
archwr: 01720002
/*----write ARCHDEF member -------------start----------*/ 01730002
do while queued() > 0 01740002
"execio 1 diskw archdef" 01750002
end 01760002
"execio 0 diskw archdef (Finis" 01770002
Return rc 01780002
/**************************/ 01790002
/* PMSG PROC */ 01800002
/**************************/ 01810002
pmsg: 01820002
Parse upper arg $msg 01830002
Select 01840002
When $msg=1 then 01850002
$msg='Enter the alternate project definition name (non blank):' 01860002
$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
$msg='Enter the group name where you want to create members:' 01920002
$msg='Enter the HL ARCHDEF member name:' 01940002

$msg='Enter the ARCHDEF member names related to DB2', 01960002
'to include into HL ARCHDEF', 01970002
'(max 10), separated with a blank:' 01980002
$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
$msg='Do you want to create the DB2CLIST member ? (Y/N)' 02040002
$msg='Enter the DB2 plan name:' 02060002
$msg='Enter the DB2 subsystem name. Leave blank if you', 02080002
' want to use the default, which is 'dftdsys 02090002
Otherwise $msg=0 02100002
End 02110002
If $msg/=0 then say $msg 02120002
Return rc 02130002
/**************************/ 02140002
/* CLIST PROC */ 02150002
/**************************/ 02160002
clist: 02170002
call GETGRPS 02180002
/*----- create qual.group.DB2CLIST(hla)--*/ 02190002
db2cl = "'"||qual||'.'||grp||'.DB2CLIST('||hla||")'" 02200002
"alloc da("db2cl") fi(cl) shr reuse" 02210002
newstack 02220002
queue'PROC 0 OPTION() GROUP() ' 02230002
queue'CONTROL MSG FLUSH ' 02240002
queue'/* -------------------------------------------------------*/' 02250002
queue'/* DBRM PROXY DSN CLIST FOR DB2 PROGRAM */ ' 02260002
queue'/* */ ' 02270002
queue'/* INPUT PARAMETERS: */ ' 02280002
queue'/* OPTION() BIND|FREE */ ' 02290002
queue'/* GROUP() GROUP-NAME-FOR BIND OR FREE */ ' 02300002
queue'/* */ ' 02310002
queue'/* RETURN CODES: */ ' 02320002
queue'/* 0 SUCCESS */ ' 02330002
queue'/* 4 WARNING */ ' 02340002
queue'/* 8 ERROR */ ' 02350002
queue'/* 16 FATAL ERROR */ ' 02360002
queue'/* 312 INVALID GROUP */ ' 02370002
queue'/* 316 INVALID OPTION */ ' 02380002
queue'/* ----------------------------------------------------*/ ' 02390002
queue'/* INSTRUCTIONS FOR CUSTOMIZATION: */ ' 02400002
queue'/* SPECIFY VARIABLES: */ ' 02410002
queue'/* ----------------------------------------------------*/ ' 02420002
queue'/* SPECIFY A DBRM INCLUDE STATEMENT FOR EACH DBRM: */ ' 02430002
queue'/* */ ' 02440002
/*----*/ 02450002
if appl1 /=' ' then 02460002
queue'/* %INCLUDE 'appl1' */ ' 02470002
else 02480002
queue'/* */ ' 02490002
/*----*/ 02500002
if appl2 /=' ' then 02510002

else 02530002
queue'/* */ ' 02540002
/*----*/ 02550002
if appl3 /=' ' then 02560002
else 02580002
queue'/* */ ' 02590002
/*----*/ 02600002
if appl4 /=' ' then 02610002
else 02630002
queue'/* */ ' 02640002
/*----*/ 02650002
if appl5 /=' ' then 02660002
else 02680002
queue'/* */ ' 02690002
/*----*/ 02700002
if appl6 /=' ' then 02710002
else 02730002
queue'/* */ ' 02740002
/*----*/ 02750002
if appl7 /=' ' then 02760002
else 02780002
queue'/* */ ' 02790002
/*----*/ 02800002
if appl8 /=' ' then 02810002
else 02830002
queue'/* */ ' 02840002
/*----*/ 02850002
if appl9 /=' ' then 02860002
else 02880002
queue'/* */ ' 02890002
/*----*/ 02900002
if appl10/=' ' then 02910002
else 02930002
queue'/* */ ' 02940002
/*----*/ 02950002
queue'/* ----------------------------------------------------*/ ' 02960002
queue'SET &RCODE = 0 ' 02970002
queue'/* ----------------------------------------------------*/ ' 02980002
queue'/* SPECIFY A DBRMS FOR BIND MEMBER LIST */ ' 02990002
queue'/* ----------------------------------------------------*/ ' 03000002
queue'SET &DBRMS = &STR('appl1','appl2','appl3','appl4', +' 03010002
queue' 'appl5','appl6','appl7','appl8', +' 03020002
queue' 'appl9','appl10') ' 03030002
queue'/* -------------------------------------------------------*/' 03040002
queue'/* SPECIFY PLAN NAME, BIND PARMS, AND SYSTEM */' 03050002
queue'/* FOR EACH GROUP */' 03060002
queue'/* -------------------------------------------------------*/' 03070002

queue'SELECT (&GROUP) ' 03080002
i=1 03090002
do until i=m 03100002
call COMP g.i 03110002
queue' WHEN ('||compout||') DO ' 03120002
queue' SET &PLAN ='db2plan' ' 03130002
queue' SET &SYS ='dsys' ' 03140002
queue' SET &BPARM = &STR('bparm1' + ' 03150002
queue' 'bparm2' + ' 03160002
queue' 'bparm3' + ' 03170002
queue' 'bparm4' + ' 03180002
queue' 'bparm5' + ' 03190002
queue' 'bparm6' + ' 03200002
queue' 'bparm7' + ' 03210002
queue' 'bparm8' + ' 03220002
queue' 'bparm9' + ' 03230002
queue' 'bparm10') ' 03240002
queue' END ' 03250002
i=i+1 03260002
end 03270002
queue' OTHERWISE SET &RCODE = 312 ' 03280002
queue'END ' 03290002
queue'/* -------------------------------------------------------*/' 03300002
queue'/* INVOKE DSN COMMAND PROCESSOR TO BIND OR FREE */ ' 03310002
queue'/* -------------------------------------------------------*/' 03320002
queue'SET &ENDDSN = END ' 03330002
queue'IF &RCODE = 0 THEN + ' 03340002
queue' SELECT (&OPTION) ' 03350002
queue' WHEN (BIND) DO ' 03360002
queue' DSN SYSTEM(&SYS) ' 03370002
queue' BIND PLAN(&PLAN) MEMBER(&DBRMS) &BPARM ' 03380002
queue' &ENDDSN ' 03390002
queue' SET &RCODE = &MAXCC ' 03400002
queue' END ' 03410002
queue' WHEN (FREE) DO ' 03420002
queue' DSN SYSTEM(&SYS) ' 03430002
queue' FREE PLAN(&PLAN) ' 03440002
queue' &ENDDSN ' 03450002
queue' SET &RCODE = &MAXCC ' 03460002
queue' END ' 03470002
queue' OTHERWISE SET &RCODE = 316 ' 03480002
queue'END ' 03490002
queue'EXIT CODE(&RCODE) ' 03500002
do while queued() > 0 03510002
"execio 1 diskw cl" 03520002
end 03530002
"execio 0 diskw cl (Finis" 03540002
delstack 03550002
return rc 03560002
/**************************/ 03570002
/* GETGRPS PROC */ 03580002
/**************************/ 03590002
getgrps: 03600002
/*----open PROJDEFS member project ----start----------*/ 03610002
projet= "'"||qual||'.PROJDEFS.SOURCE('||proj||")'" 03620002
"alloc da("projet") fi(pjt) shr reuse" 03630002

newstack 03640002
g = 'g' 03650002
i=1 03660002
do until rc/=0 03670002
"execio 1 diskr pjt" 03680002
if rc =0 then do 03690002
pull rec 03700002
inter=pos('FLMGROUP',rec) 03710002
if substr(rec,1,1) /='*' & inter /=0 then 03720002
do 03730002
g.i=substr(rec,1,8) 03740002
i=i+1 03750002
end 03760002
end 03770002
end 03780002
m=i 03790002
delstack 03800002
return rc 03810002
/**************************/ 03820002
/* COMP PROC */ 03830002
/**************************/ 03840002
comp: 03850002
parse upper arg compin 03860002
blank=pos(' ',compin) 03870002
long = blank-1 03880002
compout=substr(compin,1,long) 03890002
return rc 03900002
/**************************/ 03910002
/* ENDMSG PROC */ 03920002
/**************************/ 03930002
endmsg: 03940002
Say '_______________________________________________' 03950002
Say ' Processing completed for application :'hla 03960002
Say ' ' 03970002
Say ' When the members have been created, you have to ' 03980002
Say ' use the SCLM migrate function to the lowest level' 03990002
Say ' of the project to let SCLM accounting file know ' 04000002
Say ' about these members. ' 04010002
Say '_______________________________________________' 04020002
return rc 04 0002

Appendix E. Tools for Bulk Data Migration
This appendix describes tools for bulk data migration and presents technical details about
required changes to source modules from the CA-LIBRARIAN environment. The reasons for
those modifications are discussed in “Nonstandard Source Code” on page 52.
Changing Old COBOL COPY Syntax

Figure 85 lists the ISPF EDIT macro used for inserting missing periods in front of COPY
statements in COBOL programs (refer to “COBOL Copy Statements with Leading Data
Names” on page 52). The general-purpose EDIT macro MIGE0000 (see Figure 50 on
page 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
/***============================================================== ***/00120000
SET CSUM = 0 00130000
ISREDIT (MEMBER) = MEMBER 00140000
ISREDIT NUMBER COBOL 00150000
ISREDIT BOUNDS 7 72 00170000
ISREDIT (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 00250000
ISREDIT EXCLUDE ALL 00260000
ISREDIT FIND ALL '*' 7 00270000
ISREDIT FIND X FIRST 'DATA DIVISION' 00280000
IF (&FCOUNT GT 0) THEN ISREDIT (DLINE,DCOL) = CURSOR 00300000
ISREDIT LABEL &DLINE = .D 00310000
ISREDIT FIND X FIRST 'PROCEDURE DIVISION' 00320000
IF (&FCOUNT GT 0) THEN ISREDIT (PLINE,PCOL) = CURSOR 00340000
ISREDIT LABEL &PLINE = .P 00350000
ISREDIT FIND X ALL ' COPY ' .D .P 00360000
ISREDIT EXCLUDE ALL '*' 7 00370000
ISREDIT EXCLUDE FIRST 'DATA DIVISION' 00380000
ISREDIT EXCLUDE FIRST 'PROCEDURE DIVISION' 00390000
ISREDIT CURSOR = 1 1 00400000
/***-------------------------------------------------------------- ***/00410000
/*** LOOP: CHANGE ' COPY ' TO '. COPY ' IF TEXT WITHOUT '.' ***/00420000
/*** PRECEDES 'COPY' IN SAME NON-COMMENT LINE ***/00430000
/***-------------------------------------------------------------- ***/00440000
COP: ISREDIT FIND NX ' COPY ' 00450000
ISREDIT (FLINE,FCOL) = CURSOR 00480000
ISREDIT LABEL &FLINE = .F 00490000
ISREDIT (OLINE) = LINE &FLINE 00500000
ISREDIT FIND .F .F 7 &FCOL P'¬' FIRST 00510000
ISREDIT (ALINE,ACOL) = CURSOR 00540000
ISREDIT FIND .F .F 7 &FCOL '.' LAST 00550000
IF (&FCOUNT EQ 0) THEN DO 00570000
ISREDIT CHANGE .F .F &FCOL ' COPY' '. COPY' 00580000
IF (&LASTCC NE 0) THEN DO 00590000
WRITE &STR(@@@ CHANGE ERROR IN &MEMBER LINE &FLINE @@@)00600000
GOTO ENDX 00610000
END 00620000
ISREDIT (NLINE) = LINE &FLINE 00630000
IF (&SHOWCHG = ALL) THEN DO 00640000
WRITE &STR(** MEMBER &MEMBER LINE &FLINE (OLD/NEW):) 00650000
WRITE &SUBSTR(1:72,&STR( )&OLINE) 00660000
WRITE &SUBSTR(1:72,&STR( )&NLINE) 00670000
END 00680000
SET CSUM = &EVAL(&CSUM + 1) 00690000
END 00700000
END 00710000
ISREDIT CURSOR = &FLINE 72 00720000
GOTO COP 00730000
END 00740000
/***-------------------------------------------------------------- ***/00750000
IF (&CSUM = 0) THEN ISREDIT CANCEL 00760000
ELSE DO 00770000
IF ((&SHOWCHG = ALL) OR (&SHOWCHG = SUM)) THEN DO 00780000
WRITE &STR(********** &CSUM LINES CHANGED IN MEMBER &MEMBER )00790000
WRITE 00800000

END 00810000
ISREDIT END 00830000
END 00840000
/***-------------------------------------------------------------- ***/00850000
ENDX: EXIT 00860000
/***============================================================== ***/00870000
Handling COPY Prefix Replacement in COBOL Programs

The basic rules governing COBOL COPY statements with a REPLACING clause in
CA-LIBRARIAN and in COBOL standards are described in “COBOL Copy Statements with
Prefix Replacement” on page 54. We decided to remove all REPLACING clauses and to
adjust the program source statements referring to the data names affected. This section
shows how we adjusted the CA-LIBRARIAN specific coding to COBOL standards and lists the
tools we used to perform this part of the source code migration.
Application 1 contained only one COBOL program with COPY ... REPLACING statements to
replace data name prefixes, but we decided to develop a mostly automated procedure as
this particular problem potentially applies to many applications to be migrated after the pilot
project. You may want to automate this process even more if you have to migrate many
COBOL applications that use COPY ... REPLACING statements. Our procedure is shown in
Figure 86 on page 142:
1. Start with COBOL programs already corrected with MIGE0030 for missing periods in
COPY statement lines (refer to “COBOL Copy Statements with Leading Data Names” on
page 52 and “Changing Old COBOL COPY Syntax” on page 139). First you have to find
where COPY ... REPLACING is used. You can use the ISPF Search-For utility and search
for REPLACING in your COBOL source data set.
2. Run program MIGU003 for each COPY ... REPLACING statement. Input for program
MIGU003 are the prefixes specified in the REPLACING clause of the COPY statements
and the text of the copy book. Output is an ISPF EDIT macro that corresponds to one
COPY ... REPLACING statement and contains the CHANGE commands for the source
code of the program.
3. Apply EDIT macro MIGE0050 to the program source code. MIGE0050 requires two
parameters:
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 data
name usually precedes the COPY statement.
If no parameters are supplied, you will be prompted for input. MIGU0050 calls the
macro with the CHANGE commands to modify the source code.
4. Remove the REPLACING clause from the COPY statement. This finishes the corrected
COBOL 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 remarks
pertain 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 on
page 143 and Figure 88 on page 143.
A sample job to run MIGU003 is listed in Figure 89 on page 144. The source code for
MIGU003 is listed in Figure 90 on page 144. ISPF EDIT macro MIGE0050 is listed in
Figure 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 THEN
MOVE 'D' TO S92N-ST-KZ
MOVE ZWI-BUFF TO S92N-MASCH-DAT
CALL 'P03N905' USING PARM-OBUFF905
Adjusted program statements to match the adjusted COPY statement:
IF RETURN-CODE = 0 THEN
MOVE 'D' TO SAWX-ST-KZ IN PARM-OBUFF905
MOVE ZWI-BUFF TO SAWX-MASCH-DAT IN PARM-OBUFF905
CALL '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 book
data names; S92N- is the prefix previously used in the program source code.
000100*=================================================================00010000
000200 IDENTIFICATION DIVISION. 00020000
000300 PROGRAM-ID. MIGU003. 00030000
000400*=================================================================00040000
000500*** PURPOSE.....: *** 00050000
000600*** UTILITY TO CREATE AN EDIT MACRO IN ORDER TO CHANGE *** 00060000
000700*** A PROGRAM TOGETHER WITH REMOVAL OF A REPLACING CLAUSE *** 00070000
000800*** FROM A COBOL COPY STATEMENT. *** 00080000
000900*** THE PROGRAM USES THE INFO FROM THE REPLACING CLAUSE *** 00090000
001000*** (IN A FORMATTED FORM) AND THE TEXT OF THE COPY BOOK *** 00100000
001100*** AS INPUT. *** 00110000
001200*** THE CREATED EDIT MACRO WILL HAVE THE PROPER CHANGE *** 00120000
001300*** COMMANDS TO REPLACE THE USED NAMES FOR VARIABLES *** 00130000
001400*** AFTER REPLACING BY THE ORIGINAL ONES FROM THE COPY *** 00140000
001500*** BOOK (TOGETHER WITH AN OPTIONAL HIGH LEVEL QUALIFIER). *** 00150000
001600*** *** 00160000
Figure 90 (Part 1 of 10). COBOL Program MIGU003

001700*** RETURN CODE: 0 = ALL OK *** 00170000
001800*** 8 = I/O ERROR *** 00180000
001900*** *** 00190000
002000*** DATE WRITTEN: 03/12/93-FITZ *** 00200000
002100*=================================================================00210000
002200 ENVIRONMENT DIVISION. 00220000
002300*=================================================================00230000
002400 CONFIGURATION SECTION. 00240000
002500 SOURCE-COMPUTER. IBM-9000. 00250000
002600*-----------------------------------------------------------------00260000
002700 INPUT-OUTPUT SECTION. 00270000
002800*-----------------------------------------------------------------00280000
002900 FILE-CONTROL. 00290000
003000* 00300000
003100*--- INPUT PREFIX NAMES 00310000
003200* 00320000
003300 SELECT PREF 00330000
003400 ASSIGN TO DA-S-DDPREF 00340000
003500 FILE STATUS IS IO-STATUS. 00350000
003600* 00360000
003700*--- INPUT COPY BOOK TEXT 00370000
003800* 00380000
003900 SELECT BOOK 00390000
004000 ASSIGN TO DA-S-DDBOOK 00400000
004200* 00420000
004300*--- OUTPUT EDIT MACRO 00430000
004400* 00440000
004500 SELECT EDMAC 00450000
004600 ASSIGN TO DA-S-DDMACRO 00460000
004800* 00480000
004900*-----------------------------------------------------------------00490000
005000 EJECT 00500000
005100*=================================================================00510000
005200 DATA DIVISION. 00520000
005300 FILE SECTION. 00530000
005400*-----------------------------------------------------------------00540000
005500* 00550000
005600*--- INPUT PREFIX NAMES 00560000
005700* 00570000
005800 FD PREF 00580000
005900 BLOCK CONTAINS 0 RECORDS 00590000
006000 LABEL RECORD OMITTED. 00600000
006100* 00610000
006200 01 PREF-REC. 00620000
006300 05 PREF-ORIG PIC X(32). 00630000
006400 05 FILLER REDEFINES PREF-ORIG. 00640000
006500 10 PREF-ORIG-I PIC X OCCURS 32. 00650000
006600 05 FILLER PIC X(08). 00660000
006700 05 PREF-REPL PIC X(32). 00670000
006800 05 FILLER REDEFINES PREF-REPL. 00680000
006900 10 PREF-REPL-I PIC X OCCURS 32. 00690000
007000 05 FILLER PIC X(08). 00700000
007100* 00710000
007200*--- INPUT COPY BOOK TEXT 00720000

007300* 00730000
007400 FD BOOK 00740000
007700* 00770000
007800 01 BOOK-REC. 00780000
007900 05 FILLER PIC X(06). 00790000
008000 05 BOOK-TEXT PIC X(66). 00800000
008100 05 FILLER REDEFINES BOOK-TEXT. 00810000
008200 10 FILLER PIC X(01). 00820000
008300 88 COMMENT VALUE '*'. 00830000
008400 10 FILLER PIC X(65). 00840000
008500 05 FILLER PIC X(08). 00850000
008600* 00860000
008700*--- OUTPUT EDIT MACRO 00870000
008800* 00880000
008900 FD EDMAC 00890000
009200* 00920000
009300 01 EDMAC-REC. 00930000
009400 05 EDMAC-STMT PIC X(72). 00940000
009500 05 FILLER PIC X(08). 00950000
009600* 00960000
009700*-----------------------------------------------------------------00970000
009800 EJECT 00980000
009900*-----------------------------------------------------------------00990000
010000 WORKING-STORAGE SECTION. 01000000
010100*-----------------------------------------------------------------01010000
010200* 01020000
010300*--- IO STATUS FIELD AND TYPE 01030000
010400* 01040000
010500 01 IO-STATUS PIC X(02). 01050000
010600 01 IO-TYP PIC X(06). 01060000
010700* 01070000
010800*--- END-OF-FILE - SWITCH: 01080000
010900* 01090000
011000 01 EOF-KZ PIC X. 01100000
011100 88 NICHT-EOF VALUE SPACE. 01110000
011200 88 EOF VALUE 'E'. 01120000
011300* 01130000
011400*--- WORK AREAS: 01140000
011500* 01150000
011600 01 VAR0 PIC X(80). 01160000
011700 01 VAR1 PIC X(66). 01170000
011800 01 VAR2 PIC X(66). 01180000
011900 01 FILLER REDEFINES VAR2. 01190000
012000 05 VAR2-I PIC X OCCURS 66. 01200000
012100 01 I PIC S9(4) COMP. 01210000
012200 01 ISTART PIC Z9. 01220000
012300 01 L-VAR2-1 PIC S9(4) COMP. 01230000
012400 01 L-PREF-ORIG PIC S9(4) COMP. 01240000
012500 01 L-PREF-ORIG-1 PIC S9(4) COMP. 01250000
012600 01 L-PREF-REPL-1 PIC S9(4) COMP. 01260000
012700* 01270000
012800*--- FIXED EDIT MACRO LINES 01280000

012900* 01290000
013000 01 M1 PIC X(20) VALUE 01300000
013100 'ISREDIT MACRO (QUAL)'. 01310000
013200 01 MC. 01320000
013300 05 FILLER PIC X(36) VALUE 01330000
013400 '/***--------------------------------'. 01340000
013600 '--------------------------------***/'. 01360000
013700 01 MC0. 01370000
013900 '/*** MAIN STRUCTURE NAME FOR QUALIF'. 01390000
014100 'ICATION - IF REQUIRED: ---------***/'. 01410000
014200 01 MC1. 01420000
014400 '/*** ORIGINAL PREFIX IN COPY BOOK: '. 01440000
014600 '--------------------------------***/'. 01460000
014700 01 MC2. 01470000
014900 '/*** PREFIX VIA REPLACING IN PGM: -'. 01490000
015100 '--------------------------------***/'. 01510000
015200 01 M2 PIC X(24) VALUE 01520000
015300 ' SET QUAL = &STR(&QUAL)'. 01530000
015400 01 M3 PIC X(40) VALUE 01540000
015500 ' IF (&STR(&QUAL) = ) THEN SET INQUAL = '. 01550000
015600 01 M4 PIC X(55) VALUE 01560000
015700 ' ELSE SET INQUAL = &STR( IN &QUAL)'. 01570000
015800 01 M5 PIC X(23) VALUE 01580000
015900 ' ISREDIT BOUNDS 7 72'. 01590000
016000 01 MI PIC X(27) VALUE 01600000
016100 ' ISREDIT CHANGE ALL 7 72 +'. 01610000
016200 01 MI1 PIC X(21) VALUE 01620000
016300 ' ISREDIT CHANGE ALL '. 01630000
016400 01 MI2 PIC X(05) VALUE 01640000
016500 ' 72 +'. 01650000
016600 01 ME PIC X(28) VALUE 01660000
016700 ' ISREDIT LOCATE FIRST ERROR'. 01670000
016800 01 MV PIC X(42) VALUE 01680000
016900 ' ISPEXEC VPUT (REPLPREF ORIGPREF) SHARED'. 01690000
017000 01 MX PIC X(04) VALUE 01700000
017100 'EXIT'. 01710000
017200* 01720000
017300*-----------------------------------------------------------------01730000
017400 EJECT 01740000
017500*=================================================================01750000
017600 PROCEDURE DIVISION. 01760000
017700*=================================================================01770000
017800 DECLARATIVES. 01780000
017900*-----------------------------------------------------------------01790000
018000* 01800000
018100 PREFERR SECTION. 01810000
018200 USE AFTER ERROR PROCEDURE ON PREF. 01820000
018300 PREFERR-BEARB. 01830000
018400 DISPLAY 'FILE "PREF", IO-TYP ' IO-TYP 01840000

018500 ', IO-STATUS ' IO-STATUS 01850000
018700 STOP RUN. 01870000
018800* 01880000
018900 BOOKERR SECTION. 01890000
019000 USE AFTER ERROR PROCEDURE ON BOOK. 01900000
019100 BOOKERR-BEARB. 01910000
019200 DISPLAY 'FILE "BOOK", IO-TYP ' IO-TYP 01920000
019500 STOP RUN. 01950000
019600* 01960000
019700* 01970000
019800 EDMACERR SECTION. 01980000
019900 USE AFTER ERROR PROCEDURE ON EDMAC. 01990000
020000 EDMACERR-BEARB. 02000000
020100 DISPLAY 'FILE "EDMAC", IO-TYP ' IO-TYP 02010000
020400 STOP RUN. 02040000
020500* 02050000
020600 END DECLARATIVES. 02060000
020700* 02070000
020800*-----------------------------------------------------------------02080000
020900 EJECT 02090000
021000*************************************************************** 02100000
021100*** MAIN SECTION. *** 02110000
021200*************************************************************** 02120000
021300 STEUERUNG SECTION. 02130000
021400*-----------------------------------------------------------------02140000
021500* 02150000
021600 MOVE SPACE TO EOF-KZ. 02160000
021700* 02170000
021800*** -------------------------------- *** 02180000
021900* 02190000
022000 DATEI-OPEN. 02200000
022100* 02210000
022200 MOVE 'OPEN' TO IO-TYP. 02220000
022300* 02230000
022400 OPEN INPUT PREF. 02240000
022500 IF IO-STATUS NOT = '00' 02250000
022600 DISPLAY 'FILE "PREF", IO-TYP ' IO-TYP 02260000
022900 STOP RUN 02290000
023000 END-IF. 02300000
023100* 02310000
023200 OPEN INPUT BOOK. 02320000
023300 IF IO-STATUS NOT = '00' 02330000
023400 DISPLAY 'FILE "BOOK", IO-TYP ' IO-TYP 02340000
023700 STOP RUN 02370000
023800 END-IF. 02380000
023900* 02390000
024000 OPEN OUTPUT EDMAC. 02400000

024100 IF IO-STATUS NOT = '00' 02410000
024200 DISPLAY 'FILE "EDMAC", IO-TYP ' IO-TYP 02420000
024500 STOP RUN 02450000
024600 END-IF. 02460000
024700*** -------------------------------- *** 02470000
024800*** READ PREFIXES AND COMPUTE LENGTHS *** 02480000
024900*** -------------------------------- *** 02490000
025000* 02500000
025100 LESEN-PREF. 02510000
025200 MOVE 'READ ' TO IO-TYP. 02520000
025300 READ PREF. 02530000
025400 MOVE ZERO TO L-PREF-REPL-1. 02540000
025500 PERFORM VARYING I FROM 1 BY 1 02550000
025600 UNTIL L-PREF-REPL-1 > 0 OR I > 32 02560000
025700 IF PREF-REPL-I (I) = SPACE 02570000
025800 MOVE I TO L-PREF-REPL-1 02580000
025900 END-IF 02590000
026000 END-PERFORM. 02600000
026100 MOVE ZERO TO L-PREF-ORIG-1. 02610000
026300 UNTIL L-PREF-ORIG-1 > 0 OR I > 32 02630000
026400 IF PREF-ORIG-I (I) = SPACE 02640000
026500 MOVE I TO L-PREF-ORIG-1 02650000
026600 END-IF 02660000
026700 END-PERFORM. 02670000
026800 SUBTRACT 1 FROM L-PREF-ORIG-1 GIVING L-PREF-ORIG. 02680000
026900* 02690000
027000*** -------------------------------- *** 02700000
027100*** WRITE EDIT MACRO HEADER *** 02710000
027200*** -------------------------------- *** 02720000
027300* 02730000
027400 SCHREIB-HDR. 02740000
027500 MOVE 'WRITE' TO IO-TYP. 02750000
027600 WRITE EDMAC-REC FROM M1. 02760000
027700* 02770000
027800 WRITE EDMAC-REC FROM MC. 02780000
027900 WRITE EDMAC-REC FROM MC0. 02790000
028300* 02830000
028500 MOVE SPACE TO EDMAC-REC. 02850000
028600 STRING ' SET ORIGPREF = &STR(' DELIMITED BY SIZE 02860000
028700 PREF-ORIG DELIMITED BY SPACE02870000
028800 ')' DELIMITED BY SIZE 02880000
028900 INTO EDMAC-REC. 02890000
029000 WRITE EDMAC-REC. 02900000
029200 MOVE SPACE TO EDMAC-REC. 02920000
029300 STRING ' SET REPLPREF = &STR(' DELIMITED BY SIZE 02930000
029400 PREF-REPL DELIMITED BY SPACE02940000
029500 ')' DELIMITED BY SIZE 02950000
029600 INTO EDMAC-REC. 02960000

029700 WRITE EDMAC-REC. 02970000
029800 WRITE EDMAC-REC FROM MV. 02980000
029900 WRITE EDMAC-REC FROM MC. 02990000
030000* 03000000
030200* 03020000
030300*** -------------------------------- *** 03030000
030400*** LOOP: READ RECORD. IF REQUIRED *** 03040000
030500*** WRITE 2 RECORDS F. EDIT MACRO. *** 03050000
030600*** -------------------------------- *** 03060000
030700* 03070000
030800 ARBEITS-SCHLEIFE. 03080000
030900 PERFORM UNTIL EOF 03090000
031000 MOVE 'READ ' TO IO-TYP 03100000
031100 READ BOOK 03110000
031200 AT END SET EOF TO TRUE 03120000
031300 END-READ 03130000
031400 IF NOT EOF AND NOT COMMENT 03140000
031500 UNSTRING BOOK-TEXT DELIMITED BY ALL SPACE OR '.' 03150000
031600 INTO VAR0 VAR1 VAR2 03160000
031700 ON OVERFLOW CONTINUE 03170000
031800 END-UNSTRING 03180000
031900 IF VAR2(1:L-PREF-ORIG) = PREF-ORIG(1:L-PREF-ORIG) 03190000
032000* 03200000
032100*--- START POS. FOR CHANGE, IF VARIABLE ENDS IN COL. 72 03210000
032200* 03220000
032300 MOVE ZERO TO L-VAR2-1 03230000
032500 UNTIL L-VAR2-1 > 0 OR I > 32 03250000
032600 IF VAR2-I (I) = SPACE 03260000
032700 MOVE I TO L-VAR2-1 03270000
032800 END-IF 03280000
032900 END-PERFORM 03290000
033000 COMPUTE ISTART ROUNDED 03300000
033100 = 74 - L-VAR2-1 03310000
033200 + L-PREF-ORIG-1 03320000
033300 - L-PREF-REPL-1 03330000
033400 END-COMPUTE 03340000
033500* 03350000
033600 MOVE 'WRITE' TO IO-TYP 03360000
033700* 03370000
033800*--- VARIABLE AT END OF LINE 03380000
033900* 03390000
034000 MOVE SPACE TO EDMAC-REC 03400000
034100 STRING MI1 DELIMITED BY SIZE 03410000
034200 ISTART DELIMITED BY SPACE 03420000
034300 MI2 DELIMITED BY SIZE 03430000
034400 INTO EDMAC-REC 03440000
034500 END-STRING 03450000
034600 WRITE EDMAC-REC 03460000
034800 STRING ' "' DELIMITED BY SIZE 03480000
034900 PREF-REPL DELIMITED BY SPACE 03490000
035000 VAR2(L-PREF-ORIG-1:31) DELIMITED BY SPACE 03500000
035100 '" +' DELIMITED BY SIZE 03510000

035300 END-STRING 03530000
035700 VAR2 DELIMITED BY SPACE 03570000
035800 '&INQUAL"' DELIMITED BY SIZE 03580000
036000 END-STRING 03600000
036200* 03620000
036300*--- VARIABLE FOLLOWED BY BLANK 03630000
036400* 03640000
036500 WRITE EDMAC-REC FROM MI 03650000
037000 ' " +' DELIMITED BY SIZE 03700000
037200 END-STRING 03720000
037700 '&INQUAL "' DELIMITED BY SIZE 03770000
037900 END-STRING 03790000
038100* 03810000
038200*--- VARIABLE FOLLOWED BY PERIOD 03820000
038300* 03830000
038900 '." +' DELIMITED BY SIZE 03890000
039100 END-STRING 03910000
039600 '&INQUAL.."' DELIMITED BY SIZE 03960000
039800 END-STRING 03980000
040000* 04000000
040100*--- VARIABLE FOLLOWED BY COMMA 04010000
040200* 04020000
040800 '," +' DELIMITED BY SIZE 04080000

041000 END-STRING 04100000
041500 '&INQUAL.,"' DELIMITED BY SIZE 04150000
041700 END-STRING 04170000
041900* 04190000
042000*--- VARIABLE FOLLOWED BY CLOSING BRACKET 04200000
042100* 04210000
042700 ')" +' DELIMITED BY SIZE 04270000
042900 END-STRING 04290000
043400 '&INQUAL.)"' DELIMITED BY SIZE 04340000
043600 END-STRING 04360000
043800* 04380000
043900*--- VARIABLE FOLLOWED BY OPENING BRACKET 04390000
044000* 04400000
044600 '(" +' DELIMITED BY SIZE 04460000
044800 END-STRING 04480000
045300 '&INQUAL.("' DELIMITED BY SIZE 04530000
045500 END-STRING 04550000
045700* 04570000
045800 END-IF 04580000
045900 END-IF 04590000
046000 END-PERFORM. 04600000
046100* 04610000
046200*** -------------------------------- *** 04620000
046300*** WRITE EDIT MACRO TRAILER *** 04630000
046400*** -------------------------------- *** 04640000

046500* 04650000
046600 SCHREIB-END. 04660000
046700 MOVE 'WRITE' TO IO-TYP. 04670000
046800 WRITE EDMAC-REC FROM ME. 04680000
046900 WRITE EDMAC-REC FROM MX. 04690000
047000* 04700000
047100*** -------------------------------- *** 04710000
047200* 04720000
047300 DATEI-CLOSE. 04730000
047400 MOVE 'CLOSE' TO IO-TYP. 04740000
047500 CLOSE PREF. 04750000
047600 CLOSE BOOK. 04760000
047700 CLOSE EDMAC. 04770000
047800* 04780000
047900*** -------------------------------- *** 04790000
048000* 04800000
048100 MOVE ZERO TO RETURN-CODE. 04810000
048200* 04820000
048300 ENDE. 04830000
048400 STOP RUN. 04840000
048500*=================================================================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
/***============================================================== ***/00200000
SET COPYNAME = &COPYNAME 00210000
CN: IF (&COPYNAME = ) THEN DO 00220000
WRITE 00230000
WRITE &STR( NAME EDIT MACRO (NORMALLY = NAME OF COPY BOOK)) 00240000

WRITENR &STR( OR ENTER "X" TO QUIT ............ ===> ) 00250000
READ &COPYNAME 00260000
IF (&COPYNAME = X) THEN DO 00270000
WRITE &STR( "X" = FUNCTION CANCELLED.) 00280000
WRITE 00290000
EXIT 00300000
END 00310000
IF (&COPYNAME = ) THEN DO 00320000
WRITE &STR( INPUT REQUIRED, "X" = QUIT.) 00330000
GOTO CN 00340000
END 00350000
END 00360000
SET QUAL = &STR(&QUAL) 00370000
IF (&STR(&QUAL) = ) THEN DO 00380000
WRITE 00390000
WRITE &STR( QUALIFIER FOR DATA NAMES TO BE CHANGED) 00400000
WRITE &STR( BLANK = OHNE QUALIFIER,) 00410000
WRITENR &STR( (NORMALLY 01 LEVEL NAME).... ===> ) 00420000
READ &QUAL 00430000
SET 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) 00510000
ISPEXEC VGET (ORIGPREF REPLPREF) SHARED 00520000
/***-------------------------------------------------------------- ***/00530000
/*** REQUEST FOR USER CONFIRMATION. IF NOT Y (YES), ***/00540000
/*** THEN CANCEL AND EXIT ***/00550000
/***-------------------------------------------------------------- ***/00560000
WRITE 00570000
SET W = &STR( MACRO "&COPYNAME." WILL BE USED) 00580000
WRITE &STR(&W TO CHANGE NAMES OF) 00590000
SET W = &STR( "&REPLPREF...." VARIABLES) 00600000
WRITE &STR(&W INTO NAMES LIKE) 00610000
IF (&STR(&QUAL) NE ) THEN DO 00620000
SET W = &STR( "&ORIGPREF.... IN &QUAL") 00630000
WRITE &STR(&W, I.E. SAME NAMES AS USED IN COPYBOOK,) 00640000
WRITE &STR( BUT WITH ADDITIONAL QUALIFIER "&QUAL".) 00650000
END 00660000
ELSE DO 00670000
SET W = &STR( "&ORIGPREF....") 00680000
WRITE &STR(&W, I.E. SAME NAMES AS USED IN COPYBOOK,) 00690000
WRITE &STR( AND W I T H O U T ADDITIONAL QUALIFIER.) 00700000
END 00710000
WRITE 00720000
WRITENR &STR( OK ? (Y/N) ===> ) 00730000
READ &ANTWORT 00740000
IF (&SUBSTR(1:1,&ANTWORT&STR(NEIN)) NE Y) THEN DO 00750000
WRITE 00760000
WRITE &STR( EXECUTION NOT CONFIRMED.) 00770000
WRITE &STR( EDIT WILL BE CANCELLED.) 00780000
WRITE 00790000
ISREDIT CANCEL 00800000

EXIT /*** ===============> EXIT ***/00810000
END 00820000
WRITE 00830000
/***-------------------------------------------------------------- ***/00840000
/*** CALCULATE INCREASE IN LEGTH FOR VARIABLES NAMES (LL). ***/00850000
/***-------------------------------------------------------------- ***/00860000
SET LQ = &LENGTH(&STR(&QUAL)) 00870000
SET LO = &LENGTH(&STR(&ORIGPREF)) 00880000
SET LR = &LENGTH(&STR(&REPLPREF)) 00890000
SET LL = &EVAL(&LO + &LQ + 4 - &LR) 00900000
IF (&LL < 0) THEN SET LL = 0 00910000
/***-------------------------------------------------------------- ***/00920000
/*** INITIALIZATION, SET BOUND AND NUMBER MODE. ***/00930000
/***-------------------------------------------------------------- ***/00940000
SET ANZERR = 0 00950000
ISREDIT UP MAX 00960000
/***-------------------------------------------------------------- ***/01000000
/*** LOOP TO HANDLE ALL ERROR LINES ***/01010000
/*** (NOT ENOUGH SPACE TO DO THE CHANGE IN ONE LINE). ***/01020000
/***-------------------------------------------------------------- ***/01030000
ERR: ISREDIT LOCATE ERROR NEXT 01040000
ISREDIT (ELINE,BLINE) = DISPLAY_LINES 01060000
/*---------------------------------------------------------*/ 01070000
/*-- LOCATE MAKES ERROR LINE TO FIRST LINE, --*/ 01080000
/*-- THIS LINE-PTR GOES VIA DISPLAY_LINES TO &ELINE. --*/ 01090000
/*---------------------------------------------------------*/ 01100000
IF (&LCC = 0) THEN DO 01110000
ISREDIT LABEL &ELINE = .E 01120000
SET ANZERR = &EVAL(&ANZERR + 1) 01130000
ISREDIT FIND .E .E &REPLPREF FIRST 8 72 01140000
ISREDIT (ELINE,PREFCOL) = CURSOR 01150000
/*------------------------------------------------------*/ 01160000
/*-- SPLIT LINE AT BLANK LAEDING OR TRAILING TO NAME --*/ 01170000
/*-- TO BE CHANGED. DEPENDS ON POSITION IN LINE. --*/ 01180000
/*------------------------------------------------------*/ 01190000
SET SPLITLIM = 35 01200000
IF (&PREFCOL > &SPLITLIM) THEN + 01210000
ISREDIT FIND .E .E 12 &PREFCOL ' ' LAST 01220000
ELSE ISREDIT FIND .E .E &PREFCOL 72 ' ' FIRST 01230000
ISREDIT (ELINE,SPLITCOL) = CURSOR 01260000
ISREDIT TSPLIT &ELINE &SPLITCOL 01270000
/*---------------------------------------------------*/ 01280000
/*-- SHIFT SPLITTED PART OF LINE TO LEFT, --*/ 01290000
/*-- IF NECESSARY. --*/ 01300000
/*---------------------------------------------------*/ 01310000
IF (&PREFCOL > &SPLITLIM) THEN DO 01320000
SET FLINE = &EVAL(&ELINE + 1) 01330000
ISREDIT LABEL &FLINE = .F 01340000
ISREDIT FIND .F .F 8 72 P'¬' FIRST 01350000

ISREDIT (FLINE,NBCOL) = CURSOR 01370000
SET LF = &EVAL(&SPLITCOL + 1 - &NBCOL) 01380000
SET LS = &EVAL(&LL - &LF) 01390000
IF (&LS GT 0) THEN DO 01400000
ISREDIT SHIFT < &FLINE &LS 01420000
END 01440000
END 01450000
ISREDIT LABEL &FLINE = &STR(' ') 01460000
END 01470000
END 01480000
ISREDIT LABEL &ELINE = &STR(' ') 01490000
GOTO 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 01560000
ISREDIT RESET ERROR 01570000
ISREDIT &COPYNAME &STR(&QUAL) 01580000
END 01590000
/***-------------------------------------------------------------- ***/01600000
/*** SET BOUNDS AND NUMBERING BACK TO COBOL STANDARDS. ***/01610000
/***-------------------------------------------------------------- ***/01620000
ISREDIT RENUM 01650000
/***-------------------------------------------------------------- ***/01660000
/*** MACRO WILL BE EXITED WITHOUT SAVE. ***/01670000
/*** USER MAY SAVE OR CANCEL. ***/01680000
/***-------------------------------------------------------------- ***/01690000
WRITE 01700000
WRITE &STR( FUNCTION EXECUTED.) 01710000
WRITE 01720000
SET W = &STR( DON'T FORGET TO REMOVE THE REPLACING CLAUSE) 01730000
WRITE &STR(&W FROM THE COPY STATEMENT.) 01740000
WRITE 01750000
WRITE &STR( SAVE CHANGES WITH WITH "END" OR CANCEL EDIT.) 01760000
WRITE 01770000
ISREDIT LOCATE ERROR FIRST 01780000
IF (&LCC = 4) THEN ISREDIT FIND &COPYNAME FIRST 01800000
EXIT 01810000
/***============================================================== ***/01820000
Changing CA-LIBRARIAN − INC Statements

Figure 92 on page 157 and Figure 93 on page 157 list the ISPF EDIT macros used to change
CA-LIBRARIAN − INC statements in application 1 Assembler and PL/I programs.
Modules of different types were stored in different PDSs, which allowed us to perform
actions specific for one language. The general-purpose EDIT macro MIGE0000 (see
Figure 50 on page 91) allowed us to apply these macros to all members in a PDS.

/***============================================================== ***/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
/***============================================================== ***/00001200
ISREDIT CHANGE ALL 1 '-INC' '*@@-INC' 00001400
ISREDIT (CCOUNT) = CHANGE_COUNTS 00001500
SELECT 00001600
WHEN (&CCOUNT = 0) ISREDIT CANCEL 00001700
WHEN (&LASTCC = 0) ISREDIT END 00001800
END 00001900
/***-------------------------------------------------------------- ***/00002000
EXIT 00002100
Figure 92. ISPF EDIT Macro MIGE0010. This EDIT macro was used to convert CA-LIBRARIAN − INC
statements in Assembler programs into comment lines.

/***============================================================== ***/00000200
/*** PURPOSE.....: CONVERT LIBRARIAN -INC STATEMENTS TO ***/00000300
/*** PLI %INCLUDE STMTS IN PL/I PGMS ***/00000400
/*** -INC WAS A LIBRARIAN SPECIFIC STATEMENT ***/00000500
/***============================================================== ***/00000700
ISREDIT UP MAX 00000900
ISREDIT CURSOR = 1 1 00001000
SET CSUM = 0 00001100
/***-------------------------------------------------------------- ***/00001200
/*** LOOP: CHANGE -INC IN COL.1 ***/00001300
/*** TO %INCLUDE IN COL.2 AND ADD SEMICOLON AFTER NAME. ***/00001400
/***-------------------------------------------------------------- ***/00001500
INC: ISREDIT CHANGE 1 '-INC' ' %INCLUDE' 00001600
ISREDIT (CCOUNT) = CHANGE_COUNTS 00001700
SELECT 00001900
WHEN (&LCC NE 0) GOTO ENDINC 00002000
WHEN (&CCOUNT = 0) GOTO ENDINC 00002100
OTHERWISE DO 00002200
SET CSUM = &EVAL(&CSUM + 1) 00002300
ISREDIT FIND NEXT P'¬' 00002400

ISREDIT CHANGE NEXT ' ' ';' 00002500
GOTO INC 00002600
END 00002700
END 00002800
/***-------------------------------------------------------------- ***/00002900
ENDINC: SELECT 00003000
WHEN (&CSUM = 0) ISREDIT CANCEL 00003100
WHEN (&LCC = 0) ISREDIT END 00003200
END 00003300
/***-------------------------------------------------------------- ***/00003400
EXIT 00003500
Figure 93 (Part 2 of 2). ISPF EDIT Macro MIGE0020. This EDIT macro was used to convert
CA-LIBRARIAN − INC statements in PL/I programs into PL/I %INCLUDE
statements.
Using SCLM Command Interface for Mass BUILDs

REXX procedure MIGR0020 issues multiple calls to the SCLM command interface to perform
mass BUILDs using FLMCMD BUILD... . Mass BUILDs were performed for correctness
checks during bulk data migration (refer to “Check Correctness Using SCLM BUILDs” on
page 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 part
of the listing name.
Existing old listings with the same name are deleted. New listings are only kept in case of
BUILD errors. Figure 94 shows REXX procedure MIGR0020 and Figure 95 on page 159
shows 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
/**********************************************************************/00070000
/* TRACE R */ 00080000
/* ------------------------------------------------------------------ */00090000
MOREINP = 1 00110000
IF RC ¬= 0 THEN DO /* EOF REACHED */ 00140000
MOREINP = 0 00150000
END 00160000

ELSE DO 00170000
PULL RECORD /* DATA FROM INPUT RECORD OR DEFAULTS: */00180000
MEMBNAME = SUBSTR(RECORD,01,8) 00190000
MEMBNAME = STRIP(MEMBNAME) 00200000
TYPENAME = SUBSTR(RECORD,11,8) 00210000
IF TYPENAME = ' ' THEN TYPENAME = 'ARCHDEF' 00220000
ELSE TYPENAME = STRIP(TYPENAME) 00230000
GROUNAME = SUBSTR(RECORD,21,8) 00240000
IF GROUNAME = ' ' THEN GROUNAME = 'MIG1' 00250000
ELSE GROUNAME = STRIP(GROUNAME) 00260000
ALTPNAME = SUBSTR(RECORD,31,8) 00270000
ALTPNAME = STRIP(ALTPNAME) 00280000
PROJNAME = SUBSTR(RECORD,41,8) 00290000
IF PROJNAME = ' ' THEN PROJNAME = 'SCLM3' 00300000
ELSE PROJNAME = STRIP(PROJNAME) 00310000
00320000
IF MEMBNAME ¬= '' THEN DO 00330000
00340000
LISTNAME = 'BUILDLST.'MEMBNAME 00350000
XXX = SYSDSN(LISTNAME) /* DELETE OLD LISTING, IF ANY: */ 00360000
IF (XXX = 'OK') THEN "DELETE" LISTNAME "NONVSAM" 00370000
/* ALLOC LISTING DS: */ 00380000
ALLOC1 = 'RECFM(V,B,A) LRECL(137) BLKSIZE(3120) UNIT(SYSDA)' 00390000
ALLOC2 = 'TRACKS SPACE(5,5) MOD CATALOG REUSE' 00400000
"ALLOC FILE(DDLIST) DATASET("LISTNAME")" ALLOC1 ALLOC2 00410000
00420000
IF RC ¬= 0 THEN SAY 'ALLOC ERROR' LISTNAME 'RC =' RC 00430000
ELSE DO 00440000
/* PERFORM BUILD: */ 00450000
FLMCMD1 = 'BUILD,'PROJNAME','ALTPNAME','GROUNAME','TYPENAME 00460000
FLMCMD2 = MEMBNAME',,N,C,Y,N,,,,DDLIST,,' 00470000
"FLMCMD" FLMCMD1','FLMCMD2 00480000
BRC = RC 00490000
SAY '* BUILD FOR >'TYPENAME MEMBNAME'< ENDED WITH RC =' BRC 00500000
IF BRC = 0 THEN "DELETE" LISTNAME "NONVSAM" 00510000
"FREE FILE(DDLIST)" 00520000
END 00530000
END 00540000
END 00550000
END 00560000
/* ------------------------------------------------------------------ */00570000
EXIT 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 member
name starting in column 1 in each record.

Glossary
accounting data set. SCLM term. A VSAM data set development group. The bottom or base set of
containing SCLM control information. For every groups within the hierarchy of a project.
member the data set contains at least an
accounting record. Information stored in the key group. SCLM term. A group into which data is
accounting record of a member includes the moved (as opposed to copied) during promotion.
language assigned to the member, its creation and Key groups are always allocated when you work
change dates and times, whether the member has with an SCLM hierarchy.
been built, and statistical and dependency
language definition. SCLM term. Languages in
information. Another type of record in the
SCLM must be specified in the project definition.
accounting data set consists of the build map.
They define the processes that source members
AD/Cycle. IBM's application development will undergo during build.
framework for Systems Application Architecture
layer. A given tier of the hierarchy, made up of
(SAA).
groups of equivalent rank.
alternate project definition. SCLM term. The
library management. SCLM uses hierarchies for
alternate project definition can be used in place of
library management. Members are moved between
a project definition. It is the member name of a
different hierarchy layers by SCLM's promote and
load module in the project.PROJDEFS.LOAD data
drawdown.
set. The name of this module must be explicitly
specified if you are referring to it. nonkey group. SCLM term. A group in the SCLM
hierarchy into which data is copied (as opposed to
architecture definition. SCLM term. An
moved) during promotion. Nonkey groups are not
architecture definition specifies the relationship
always allocated by SCLM. An example is the Edit
between software components of an application.
panel of SCLM where nonkey groups never show
authorization code. SCLM term. Authorization up. A nonkey group results in duplication of code
codes are a property of a member under SCLM after promotion.
control. They are used to restrict promotions.
parse. Synonym for analyzing in a formal way. In
build. SCLM term. Build usually involves compile SCLM, parsing means to gather statistics of a
or link. Build means to apply the language stored member and determine include relationships.
in the member's accounting record (and defined in
part. Part is another word for member when used
the project definition) to the member. You can
in conjunction with SCLM.
build individual source members or whole
applications consisting of multiple source members partitioned data set. All SCLM-controlled members
referenced by an architecture definition. Building a are stored in partitioned data sets.
linkage edit control architecture definition means
compiling and link-editing the referenced members. project. An SCLM project consists of a set of
partitioned data sets whose members are
COBOL information bytes. Part of the VS COBOL II controlled by a project definition. The project
program initialization code, where you also find definition specifies a hierarchy.
other information, such as program-ID, version,
release, and modification of the compiler, time project definition. SCLM term. The project
stamps, and number of statements. VS COBOL II definition describes the project hierarchy, project
stores information about the compiler options used database, languages defined, and control options.
to create the load module in the COBOL The project definition is the member name of the
information bytes. load module “project” in data set

project.PROJDEFS.LOAD. In all cases where no is the movement from one hierarchy layer to the
project definition name is specified, SCLM assumes next. You can promote selected source members
that this load module is being referred to. that may be architecture definitions or you may
promote architecture definitions. Everything
promote. SCLM term. In SCLM, promote signifies referenced will be moved to the higher layer
copying a member of a PDS in the project database (includes output members such as listings or
to a higher layer in the project hierarchy. Usually, objects).
the member at the lower layer is purged. Promote

List of Abbreviations
BMS basic mapping support ITSC International Technical
Support Center
CC compilation control
ITSO International Technical
CCID change control identifier Support Organization
CICS Customer Information Control LEC link edit control
System
MCD management code
DB2 IBM DATABASE 2
MFS message format service
DBD database control block
PDS partitioned data set
DDL data definition language
PSB program specification block
FAIR file access interface routine
RACF Resource Access Control
GPO group processing option Facility
HL high level SCL software control language
(ENDEVOR)
IBM International Business
Machines Corporation SCLM Software Configuration and
Library Manager
ISPF/PDF Interactive System
Productivity Facility/Program SDF II Screen Definition Facility II
Development Facility
WITT Workstation Interactive Test
Tool

Index
Special Characters C
-INC statement 14, 15, 18, 20, 57, 156 CA-LIBRARIAN
*PROCESS statement 37, 88 -INC statement 14, 15, 18, 20, 57, 156
%INCLUDE statement 57, 62 archiving facility 6
control statements 6
COPY option 14
A ELIPS 6
group processing option 6
accounting data set 4, 28, 61 index listing 72
ADD action 16 jobs 73
ALIAS 42 LANG information 35
alternate project definitions 25 management code 6
AMBLIST utility 42 master file 6
AMODE 41 processing options 6
application 1 SCAN option 18
data extraction 17 utility 73, 74
naming convention 18 CBL statement 36, 37, 88
programs 13 CC architecture definition 33, 34, 36, 37, 44, 62
release procedures 13 naming conventions 44
application inventory 9 P92N002 45
application structure 61 CCID 7, 16, 72
architecture definition 3, 24 change control identifiers
architecture report 58, 64 See CCID
archive file 42, 97 CMPAT(V1) 33
ARCHIVE function 7, 21 CMPAT(V2) 33
audit information 27 CMPR2 33, 39
auditing 27 COBOL
authorization code 25, 51 01 level data name 52, 53
AUTOCALL 42 CBL statement 36, 37, 88
COPY statement 52, 53, 54, 56, 57, 141
PROCESS statement 36, 37, 88
REPLACING clause 52, 54, 56, 57, 141
B compiler ID 77
compiler options 36, 37, 82
build 3, 59, 61, 158 SCLM 37
bulk data migration control information 29, 72
standard source code 51 application 71
migration 29
object 71
COPY option 14
COPY statement 52, 53, 54, 56, 57, 141

D F
DATA(31) 39 FLMALLOC macros 57
DB2 BIND 16 FLMALTC macro 23
DB2CLIST 47, 48, 52, 129 FLMCNTRL macro 33
DB2OUT 47 FLMGROUP macro 23
DBUTIL service 34 FLMLANGL macro 36
DFHECI 82 FLMTRNSL macro 33, 37, 39, 45
dictionary report 63 footprint 7
E G
EDIT macro GENERATE action 16
MIGE0000 89, 90, 139, 156 group 24, 25
MIGE0030 139
MIGE0040 31, 89
MIGE0050 141, 143 H
ELIPS 6
ENDEVOR high-level qualifier 23, 24
ADD action 16 HL architecture definition 58, 59, 61, 62, 64, 67, 69,
archive file 21, 31, 42, 97 129
ARCHIVE function 7, 21 naming conventions 48, 63
attribute information 21
auditing 27
CCID 7, 16, 72
environment 26 I
footprint 7
GENERATE action 16 IEBCOPY utility 32, 52
inventory item 7 IGYDS1159-E 53
LIST action 21 IGYPS0037-S 54
master control file 16 INCLUDE 42
MOVE action 16 information bytes 31, 32, 37
MOVE processors 26 ISPF help panel
PRINT action 8, 35, 96 MIGH0010 123
processor 7, 21, 35 ISPF panel
REPLACE action 16 MIGP0010 123
report 7, 27, 72 MIGP0040 92
RESTORE function 7, 21 ISPF search-for utility 18, 64, 141
SCL 7, 16 ISPF skeleton
software objects 7 MIGS0010 123
stages 7, 25 MIGS0011 123
subsystem 24, 67
system 24, 67
TRANSFER utility 7, 21 J
enterprise project 24
ENTRY 42 jobs 73
error message
IGYDS1159-E 53
IGYPS0037-S 54
L
LANG information 35
LANGLVL(1) 33

LANGLVL(2) 33 MOVE action 16
language definition 3, 4, 28, 33, 39, 104 MOVE processors 26
LEC architecture definition 44, 62, 123
naming conventions 44
P92N041 46 N
P94N353 46
LIB 39 NOCMPR2 33, 39
linkage edit control options NOLIB 39
ALIAS 42 NONUM 39
AMODE 41 NONUMCLASS 39
AUTOCALL 42 NORENT 39
ENTRY 42 NOSSRANGE 39
INCLUDE 42 NOTRUNC 39
RENT 41 NUM 39
REUS 41 NUMCLASS 39
RMODE 41
LIST action 21
O
M OS/VS COBOL options
LANGLVL(1) 33
master control file 16 LANGLVL(2) 33
master file 6
MIGE0000 89, 90, 139, 156
MIGE0030 139, 141
MIGE0040 31, 89 P
MIGE0050 141, 143
MIGH0010 123 P92N002
MIGP0010 123 CC architecture definition 45
MIGP0040 92 P92N041
MIGR0010 31, 44, 97, 123 LEC architecture definition 46
MIGR0020 59, 158 P94N353
sample job 158 LEC architecture definition 46
MIGR0030 31, 42, 97 PANVALET 7
MIGR0040 31, 92 pilot application
MIGR0050 48, 63, 129 considerations 12
migration selection 12
application developers 11 pilot project 9
control information 29 PL/I
library administrator 11 *PROCESS statement 37, 88
preparation 5, 9 %INCLUDE statement 57, 62
project leader 11 PL/I options
project organization 10 CMPAT(V1) 33
SCLM support 11 CMPAT(V2) 33
strategy 9 post-migration 5
migration utility 51 PRINT action 8, 35, 96
MIGS0010 123 PROCESS statement 36, 37, 88
MIGS0011 123 processor 35
MIGU001 32, 35, 77 project definition 3, 23, 28, 101
output 80 project organization 10
sample job 80 promote 4, 61, 71
MIGU002 32, 37, 82 promotion hierarchy 3, 25
output 87
sample job 82
MIGU003 141
sample job 143
Index 169
R SCLM (continued)
project 5, 23, 25
RACF 4, 6, 28 project definition 3, 4, 23, 28, 101
release procedures promote 4, 61, 71
audit information 14 types 26, 27
RENT 39, 41 version information 27
REPLACE action 16 versioning 4, 27
REPLACING clause 52, 54, 56, 57, 141 software control language
RESTORE function 7, 21 See SCL
REUS 41 software objects 7
REXX procedure SSRANGE 39
G621HLA 48 stages 25
MIGR0010 31, 44, 123
MIGR0020 59, 158
MIGR0030 31, 42, 97 T
MIGR0040 31, 92
MIGR0050 48, 129 TRANSFER utility 7, 21
RMODE 41 translator options 28
TRUNC(BIN) 39
types 26, 27
S
SCAN option 18 U
SCL 7, 16
SCLM utility
accounting data set 4, 28, 61 AMBLIST 42
alternate project definitions 25 CA-LIBRARIAN 73, 74
architecture definition 3, 24 IEBCOPY 32, 52
architecture report 58, 64 ISPF search-for 18, 64, 141
audit information 27 migration 51
auditing 27 TRANSFER 7, 21
authorization code 25, 51
build 3, 59, 61, 158
CC architecture definition 33, 34, 36, 37, 44, 62 V
command interface 158
compiler options 37 version information 27
data sets 28 versioning 4, 27
DB2CLIST 47, 48, 52, 129 VS COBOL II 77
DB2OUT 47 compiler options 31, 82
DBUTIL service 34 information bytes 31, 32, 37
enterprise project 24 modules 31
FLMALLOC macros 57 VS COBOL II options
FLMALTC macro 23 CMPR2 32, 33, 39
FLMCNTRL macro 33 DATA(31) 39
FLMGROUP macro 23 LIB 39
FLMLANGL macro 36 NOCMPR2 32, 33, 39
FLMTRNSL macro 33, 37, 39, 45 NOLIB 39
group 24, 25 NONUM 39
high-level qualifier 23, 24 NONUMCLASS 39
HL architecture definition 58, 59, 61, 62, 64, 67, NORENT 39
69, 129 NOSSRANGE 39
language definition 3, 4, 28, 33, 39, 104 NUM 39
LEC architecture definition 44, 62, 123 NUMCLASS 39
migration utility 51 RENT 39
parser 61 SSRANGE 39

VS COBOL II options (continued)
TRUNC(BIN) 39
Index 171
ITSC Technical Bulletin Evaluation RED000
Migrating Applications
from Vendor Libraries
to SCLM
Publication No. GG24-4021-00
Your feedback is very important to us to maintain the quality of ITSO redbooks. Please fill out this
questionnaire 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 mailing
Fax 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 book ____ Grammar/punctuation/spelling ____

Accuracy of the information ____ Ease of reading and understanding ____
Relevance of the information ____ Ease of finding information ____
Completeness of the information ____ Level of technical detail ____
Value of illustrations ____ Print 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 RED000
GG24-4021-00 
Fold and Tape Please do not staple Fold and Tape
NO POSTAGE
NECESSARY
IF MAILED IN THE
UNITED STATES
BUSINESS REPLY MAIL

FIRST CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK
POSTAGE WILL BE PAID BY ADDRESSEE
IBM International Technical Support Center

Department 471, Building 098
5600 COTTLE ROAD
SAN JOSE CA
USA 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

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Mainframe Manual

Enviado por

Direitos autorais:

Formatos disponíveis

Migrating Applications

from Vendor Libraries

Document Number GG24-4021-00

International Technical Support Center

First Edition (June 1993)

IBM Corporation, International Technical Support Center

 Copyright International Business Machines Corporation 1993. All rights reserved.

 Copyright IBM Corp. 1993 iii

Chapter 2. Preparing for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 3. Defining SCLM Project Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 4. Migrating the Control Information . . . . . . . . . . . . . . . . . . . . . . . 29

 Copyright IBM Corp. 1993 v

Chapter 6. Creating High-Level Application Structure . . . . . . . . . . . . . . . . . . 61

Chapter 7. Post-Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Appendix A. Data Extraction from CA-LIBRARIAN . . . . . . . . . . . . . . . . . . . . 73

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

Appendix C. SCLM Project Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Appendix D. Generation of Architecture Definitions . . . . . . . . . . . . . . . . . . 123

Appendix E. Tools for Bulk Data Migration . . . . . . . . . . . . . . . . . . . . . . . . 139

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

 Copyright IBM Corp. 1993 ix

 Copyright IBM Corp. 1993 xi

AD/Cycle BookMaster CICS

ENDEVOR LEGENT Corp.

 Copyright IBM Corp. 1993 xiii

How This Document Is Organized

 Copyright IBM Corp. 1993 xv

International Technical Support Center Publications

The authors of this document are:

xvi Library Migration

International Technical Support Center - San Jose

 Copyright IBM Corp. 1993 1

Why Migrate to SCLM?

 Copyright IBM Corp. 1993 3

Objectives and Scope of the Project

Vendor Library Systems

Develop Migration Strategy

 Copyright IBM Corp. 1993 9

Define Organizational and Administrative Structure

Chapter 2. Preparing for Migration 11

Chapter 2. Preparing for Migration 13

DR Release from development to R-Test

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

Chapter 2. Preparing for Migration 15

Extract Data for the Sample Applications

Chapter 2. Preparing for Migration 17

Step 1: Identify all Modules

Step 2: Extract the Modules

Chapter 2. Preparing for Migration 19

Source Data with Control Information

Chapter 2. Preparing for Migration 21

Partitioned Data Set High-Level Qualifier

 Copyright IBM Corp. 1993 23

Set Up High-Level Qualifier with Information from CA-LIBRARIAN: There is no information

Set Up Groups with Information from CA-LIBRARIAN: There is no information in

Chapter 3. Defining SCLM Project Setup 25

Table 1. SCLM Types Used in the Migration Project

Version and Audit

Chapter 3. Defining SCLM Project Setup 27

Accounting Data Set

Technical Setup Steps

 Copyright IBM Corp. 1993 29

The following remarks refer to the numbers in the figure: