VSE to OS/390 Migration Workbook
Cliff Bays ** Dave Greenough ** John Hutchinson
Dan Janda ** Kevin Jones ** Gilbert Saint-flour
IBML
International Technical Support Organization
http://www.redbooks.ibm.com
This book was printed at 240 dpi (dots per inch). The final production redbook with the RED cover will
be printed at 1200 dpi and will provide superior graphics resolution. Please see “How to Get ITSO
Redbooks” at the back of this book for ordering instructions.
SG24-2043-00
IBML
International Technical Support Organization
SG24-2043-00
VSE to OS/390 Migration Workbook
October 1998
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix D, “Special Notices” on page 553.
First Edition (October 1998)
This edition applies to Version 2 Release 3 of IBM Virtual Storage Extended/Enterprise Systems Architecture
(VSE/ESA), Program Number 5690-VSE, and to all subsequent releases and modifications until otherwise indicated
in new editions. It also applies to Version 2 Release 4 of OS/390 (5647-A01) and to all subsequent releases and
modifications until otherwise indicated in new editions.
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. HYJ Mail Station P099
522 South Road
Poughkeepsie, New York 12601-5400
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 1998. 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.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Tables
Preface
The Team That Wrote This Redbook
Comments Welcome
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
........................ xxi
Redbook Builders and Key Contributors
Authors and Significant Contributors
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
.................... xxi
...................... xxii
Part 1. Planning the Migration - An Introduction ......................... 1
Chapter 1. Why Customers Migrate
1.1 A Synopsis of This Book
............................. 3
1.2 Traditional Reasons for Migrating
1.2.1 Business Consolidation
1.2.2 Mergers/Acquisitions
1.2.3 Capacity Constraints
1.2.4 Image
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Functional Reasons for Migrating to OS/390
1.3.1 Applications Availability
1.3.2 Systems Management
1.3.3 Connectivity
1.3.4 Systems Availability
1.3.5 Staff Availability
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
......................... 3
........................ 4
. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
.................. 10
. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 2. Sizing the Effort
2.1 Introduction to Sizing
2.1.1 Defining the Migration Project Objectives
2.1.2 Areas of VSE and OS/390 Differences
.............................. 13
............................... 13
................. 13
................... 14
2.1.3 Comparison of Basic VSE Functions & Components to OS/390
2.2 OS/390 Components/Products/Subsystems
2.2.1 The OS/390 Operating Environment
2.2.2 Subsystem Level Comparison/Affinity
2.3 What Changes Between VSE and OS/390?
2.3.1 Philosophical Changes
2.4 Who is Affected by This Migration?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
....................... 26
2.4.1 Job Roles and Normal Activities
2.5 Approaches to Migration
2.5.1 Disclaimer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
............................. 27
. . . . . . . . . . . . . . . . . . 18
.................... 19
................... 24
................... 24
...................... 26
2.5.2 OS/390 Conversion and Production Implementation Strategies
2.5.3 VM/ESA Guest Support in Your VSE to OS/390 Migration
2.5.4 Staffing Strategies
2.5.5 Conversion Tools
2.6 Educational Requirements
2.6.1 Introduction
2.7 Scope of Work and Challenges
2.7.1 Application Inventory
2.7.2 Program Conversion
2.7.3 JCL Conversion
2.7.4 File Migration
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
.......................... 32
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
.... 16
.... 27
....... 29
Copyright IBM Corp. 1998 iii
2.7.5 Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.7.6 Automated Operations
2.8 Cost Considerations
2.9 OS/390 Documentation Resources
2.9.1 Introduction References
2.9.2 Key Documents and Other References
2.9.3 W eb UR L
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
....................... 39
. . . . . . . . . . . . . . . . . . . . . . . . . . . 39
.................. 40
Chapter 3. Developing the Plan
3.1 Overview
3.1.1 References
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.2 Recommendations
3.2 Plan Components
3.2.1 Approach
3.2.2 Team
3.2.3 Tasks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.4 Milestone Events
3.2.5 Education
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Progressive versus Mass Conversion
3.3.1 Approach Differences
3.3.2 Historical Perspective
3.3.3 Shared Application Files and Databases
3.3.4 Shared Application Code
3.3.5 Operations Support Staffing
3.3.6 Automated Operations Tools
............................ 41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
...................... 49
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
................. 50
.......................... 50
......................... 50
........................ 50
3.3.7 Standardized Conversion Deliverables and Automation
3.3.8 Risk Management
3.3.9 Complexity of Implementation
3.4 Plan Examples
3.4.1 Project Schedule
3.4.2 Project Plan Example
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
....................... 51
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
............................. 56
........ 51
Part 2. Converting the VSE Operating System to the OS/390 Operating System .. 67
Chapter 4. Job Control Language (JCL) Differences and Considerations
4.1 The Philosophy of JCL in System/390
4.1.1 VSE/ESA′s Job Control Language Philosophy
4.1.2 OS/390′s Job Control Philosophy
4.2 High Level Similarities
............................... 72
4.2.1 JCL Statement and Job Layout
4.2.2 Spooling
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3 JCL Differences Between VSE and MVS
4.3.1 J o b Input
4.3.2 JCL Expansion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.3 Operator Flexibility and Intervention
4.3.4 Allocation of Resources
4.3.5 Hidden JCL
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
........................... 78
4.3.6 Device Address Specifications
4.3.7 Catalogs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.8 Partition Dependent Codes in JCL
4.3.9 Communication Region - DATE and UPSI
4.3.10 VSE Job Control Statements
4.3.11 MVS Job Control Statements
4.3.12 Comparison of VSE and MVS JCL - A Summary
...................... 69
.............. 70
...................... 70
....................... 72
.................... 73
.................... 76
....................... 80
..................... 81
................. 81
........................ 82
....................... 84
............ 86
... 69
iv VSE to OS/390 Migration Workbook
4.3.13 Summary of MVS JCL Statements .................... 88
4.4 JECL
4.4.2 Comparison of POWER and JES2 JECL - A Summary
4.4.3 Summary of JES2 JECL - A Table
4.5 VSE and MVS JCL Comparison Example
4.5.1 S ample VSE JCL
4.5.2 Sample MVS JCL
4.5.3 Sample VSE plus Carry-Over
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
......... 89
..................... 90
.................... 91
................................ 92
............................... 93
........................ 94
Chapter 5. Disk and Tape Storage Considerations
5.1 Access Method Similarities and Differences
5.1.1 Access Methods
5.1.2 Operating System Implementations
5.1.3 Miscellaneous Functions
5.2 Data Set Naming Considerations
5.2.1 VSE Considerations
5.2.2 OS/390 Considerations
5.3 Storage and Space Management
5.3.1 VSE Considerations
5.3.2 OS/390 Considerations
5.3.3 System Managed Storage
5.3.4 Implementing DFSMS
5.4 Tape Similarities and Differences
5.4.1 Volume Interchangeability
5.4.2 Standard Labels
5.4.3 No Labels
5.4.4 Nonstandard Labels
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
.................... 98
. . . . . . . . . . . . . . . . . . . . . . . . . . . 99
........................ 99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
....................... 100
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
. . . . . . . . . . . . . . . . . . . . . . . . . . . 100
......................... 100
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
....................... 103
. . . . . . . . . . . . . . . . . . . . . . . . . 103
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.4.5 Bypass Label Processing Facility in OS/390
5.5 DASD Similarities and Differences
5.5.1 Volume Interchangeability
5.5.2 DASD (VTOC) Processing
...................... 108
. . . . . . . . . . . . . . . . . . . . . . . . . 108
......................... 108
5.5.3 Indexed VTOC Considerations (OS/390)
5.6 VSAM Differences
5.6.1 Introduction
5.6.2 OS/390 Catalogs
5.6.3 OS/390 Catalog Management
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
....................... 114
5.6.4 OS/390 - VSE/VSAM Catalog Compatibility
5.6.5 VSAM Functional Differences
5.6.6 Data Sharing and Integrity
....................... 119
......................... 125
5.6.7 Programming Languages and VSAM Support
5.6.8 VSAM Error and Reason Code Compatibility
5.6.9 DFSORT and VSAM Considerations
................... 131
................ 97
.................. 97
.............. 106
................. 109
............... 117
............. 131
.............. 131
Chapter 6. CICS
6.1 Introduction
6.1.1 Overview CICS Transaction Server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
................... 133
6.1.2 Essential Supplemental Reading and Migration Support Material
6.1.3 General Compatibility Comments
6.1.4 Virtual Storage Considerations for MVS
6.1.5 CICS General System Considerations
6.1.6 CICS Macro Resource Definition Table Changes
6.1.7 CSD and RDO Considerations
6.1.8 CICS System Data Sets Requirements
6.1.9 CICS System Program Interface and Exits
6.1.10 CICS Transaction Security
.................... 135
................. 135
.................. 136
........... 140
...................... 143
................. 145
............... 147
........................ 149
. 134
Contents v
6.1.11 CICS UPSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.1.12 Application Programming
6.1.13 CICS/VSE and TS Coexistence Considerations
6.1.14 Testing and Problem Determination Considerations
6.1.15 Vendor Applications
6.2 CICS with DL/I
................................... 154
. . . . . . . . . . . . . . . . . . . . . . . . 150
............ 153
......... 153
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Chapter 7. ICCF and TSO
7.1 Preparing to Use the System
7.1.1 User Profiles
7.1.2 LOGON Procedures
7.1.3 Message Facilities
7.1.4 Security
7.1.5 Summary
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
................................... 158
7.2 Using the System
7.2.1 Accessing the System
7.2.2 Entering and Manipulating Data
7.3 Executing Programs at a Terminal
7.4 Submitting Jobs for Batch Execution
7.4.1 Using Command Procedures
7.5 Migrating from VSE/ICCF to MVS and TSO/E
7.5.1 Converting ICCF Libraries
7.5.2 ICCF Procedures and Macros
Chapter 8. Databases
8.1 DL/I and IMS/VS DB Differences
8.1.1 Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
8.1.2 MVS System Requirements
8.1.3 Data Base Descriptor (DBD)
8.1.4 Program Specification Block (PSB)
8.1.5 Batch Programming
8.1.6 Utilities
8.1.7 Operations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.1.8 Database Portability
8.1.9 DL/I Multiple Partition Support
8.1.10 Additional Information
.............................. 155
.......................... 155
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
................................. 158
........................... 159
..................... 159
...................... 161
..................... 162
....................... 163
................ 163
......................... 163
....................... 167
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
........................ 169
........................ 170
........................ 170
................... 171
............................. 171
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
...................... 178
. . . . . . . . . . . . . . . . . . . . . . . . . . . 178
8.2 SQL/DS to DB2 for OS/390 Migration Consideration
8.2.1 Descriptions of Users
8.2.2 Other Comparison Areas
8.2.3 Summary of Migration Task
............................ 178
......................... 181
........................ 182
............ 178
Chapter 9. Telecommunications Subsystems
9.1 ACF/VTAM
9.1.1 Product Installation
9.1.2 Resource Definition and Operation
9.1.3 Customization and Programming
9.1.4 Network Configuration
9.2 ACF/NCP
9.2.1 Product Installation
9.2.2 Program Generation
9.2.3 Backlevel Hardware Support
9.3 BTAM
9.3.1 Product Installation
9.3.2 Usage
9.4 Migrating TCP/IP
vi VSE to OS/390 Migration Workbook
. . . . . . . . . . . . . . . . . . 185
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
.................... 187
..................... 190
. . . . . . . . . . . . . . . . . . . . . . . . . . . 191
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
....................... 193
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
..................................... 193
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
9.4.1 Network Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
9.4.2 TCP/IP Configuration
9.4.3 TCP/IP Related User Data
9.4.4 TCP/IP Batch Jobs
9.4.5 User Written TCP/IP Applications
9.4.6 Security
9.4.7 Bibliography
9.5 MQSeries
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
9.5.1 MQSeries in Your Operating System Environment
9.5.2 Networking Definitions
9.5.3 Defining MQSeries Object and Operating
9.5.4 MQSeries-based Applications
9.5.5 Bibliography
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
......................... 195
............................. 195
..................... 195
.......... 198
. . . . . . . . . . . . . . . . . . . . . . . . . . . 203
................ 203
. . . . . . . . . . . . . . . . . . . . . . . 205
Chapter 10. POWER and JES2
10.1 JES2 Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
10.1.1 Major Differences
10.2 Implementing JES2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
10.2.1 Setting Up the Required Resources
10.2.2 Starting JES2
10.2.3 Tailoring JES2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
10.3 JES2-POWER Functional Comparison
10.3.2 Input Service
10.3.3 Job Scheduling
10.3.4 Output Service
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
10.3.5 Interactive User Interfaces (ICCF/CMS/TSO)
10.3.6 Remote Job Entry
10.3.7 Network Job Entry
10.3.8 Application Interfaces
10.3.9 Accounting Comparisons
10.3.10 RAS Characteristics
10.3.11 JES2 Testing Techniques
10.4 POWER/JES2 Detailed Comparisons
10.4.1 Mapping POWER Parameters to JES2 Init Parms
10.4.2 Exit Comparisons
10.4.3 POWER-JES2 Command Equivalences
........................... 207
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
.................. 209
.................... 211
............. 218
............................. 219
............................. 220
. . . . . . . . . . . . . . . . . . . . . . . . . . . 221
. . . . . . . . . . . . . . . . . . . . . . . . . 223
. . . . . . . . . . . . . . . . . . . . . . . . . . . 224
........................ 225
..................... 225
.......... 225
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
................. 231
Chapter 11. Advanced Function Printing and Print Services Facility/MVS
11.1 Introducing PSF/MVS
11.1.1 Functional Comparison between PSF/VSE and PSF/MVS
11.1.2 Migration Effort
11.2 Installing and Configuring PSF/MVS
11.2.1 Defining Channel-attached Printers to MVS
11.2.2 Defining Network Printers
11.2.3 The PSF Startup Procedures
11.2.4 Defining Printers for PSF Printing
11.2.5 FSS Procedure and PRINTDEV Statements
11.3 Setting up AFP Resources
11.3.1 Migrating Resources from VSE to OS/390
11.3.2 Remote-Resident Resources
11.3.3 Transferring Print Streams - VSE and OS/390 Coexistence
11.3.4 Migrating Print Applications
11.4 Understanding Operational Differences
11.4.1 Starting and Stopping PSF
11.4.2 Command Comparison
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
...... 235
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
..................... 236
.............. 236
........................ 236
....................... 237
.................... 237
.............. 238
........................... 240
............... 240
. . . . . . . . . . . . . . . . . . . . . . . 240
..... 241
....................... 241
................... 242
........................ 242
. . . . . . . . . . . . . . . . . . . . . . . . . . 242
.. 235
Contents vii
11.5 Other Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
11.5.1 Performance
11.5.2 Installation Exits
11.5.3 Accounting
11.6 References
11.6.1 PSF/VSE Publications
11.6.2 PSF/MVS Publications
11.6.3 Redbooks
11.6.4 Other Sources
11.6.5 Tools
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
11.6.6 Services
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
. . . . . . . . . . . . . . . . . . . . . . . . . . . 244
........................... 244
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Part 3. Converting VSE Languages to OS/390 Languages .................. 247
Chapter 12. COBOL
12.1 Introduction
12.1.1 General Comments on COBOL for OS/390 and VM
12.1.2 Comparison of IBM COBOL Compilers
12.2 VSE to OS/390 Migration Considerations
12.2.1 Migrating Object Code
12.2.2 Useful Publications
12.3 Converting from DOS/VS COBOL
12.3.1 DOS/VS COBOL CICS Programs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
......... 249
................. 250
.................. 250
.......................... 251
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
...................... 252
.................... 252
12.3.2 DOS/VS COBOL Programs Containing REPORT WRITER
Statements
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
12.4 DOS/VS COBOL and COBOL for OS/390 and VM Language Differences 253
12.4.1 Common COBOL Coding Problems
12.4.2 ENVIRONMENT DIVISION
. . . . . . . . . . . . . . . . . . . . . . . . . 255
12.4.3 DATA DIVISION - FILE DESCRIPTION (FD)
12.4.4 PROCEDURE DIVISION - Input/Output
12.4.5 File Handling Considerations
12.5 Converting from VS COBOL II
......................... 258
12.5.1 V S COBOL II CICS Programs
12.6 Converting from COBOL for VSE/ESA
12.7 Some Conversion Considerations for all VSE COBOL Compilers
12.7.1 VSAM
12.7.2 DISPLAY Statement
12.8 Compiler Options
12.8.1 RES/NORES
12.9 Reserved Words
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
12.9.1 Reserved Word Considerations for DOS/VS COBOL
................... 253
............... 256
................. 256
...................... 257
...................... 259
.................... 259
.... 259
......... 263
12.9.2 Reserved Word Considerations for VS COBOL II and COBOL for
VSE/ESA
12.10 Compiling and Running Your Converted COBOL Programs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
...... 265
Chapter 13. Assembler
13.1 Assembler Products
13.2 General Assembler Conversion Comments
13.2.1 System Interface and Macros
13.2.2 Multitasking Macros
13.2.3 Interrupt Handling Routines
13.2.4 Virtual Storage Macros
13.2.5 VSAM Macros
13.2.6 Data Management Macros
viii VSE to OS/390 Migration Workbook
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
................ 267
...................... 268
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
....................... 287
.......................... 289
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
........................ 292
Chapter 14. RPG II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
14.1 Migration from VSE to OS/390
14.1.1 Device Information
14.1.2 Print Files
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
14.1.3 Tape Labels
14.1.4 Extent Exit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
14.1.5 Processing Options
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
14.1.6 File Access Methods
14.1.7 Calling COBOL Subprograms
14.1.8 Calling PL/I Subprograms
........................ 329
........................... 330
...................... 331
........................ 331
Chapter 15. P L/I
15.1 Functional Differences
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
15.1.1 EGCS (VSE) to DBCS (OS Version 2) Comments
15.1.2 Extended Precision
15.1.3 Multitasking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
15.1.4 Dynamic Loading of Dependent Programs
15.1.5 File Organization
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
15.1.6 Parameters Passed to a Main Program
15.1.7 %INCLUDE
15.2 Compiler Options
15.2.1 Options Specific to the DOS Compiler
15.2.2 Options Specific to the MVS Compiler
15.2.3 Execution Options
15.2.4 The EXEC and PROCESS Cards
15.3 Linkages Between Languages
15.3.1 Linkages Supported
15.3.2 Linkages not Supported
15.4 ENVIRONMENT Attributes
15.4.1 Not Supported in MVS
15.4.2 Supported but to be Avoided
15.4.3 The ″TOTAL″ Option
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
................. 335
................. 336
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
..................... 338
........................ 338
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
.......................... 338
. . . . . . . . . . . . . . . . . . . . . . . . . . . 338
.......................... 339
...................... 340
............................ 340
15.4.4 The SIS Option (Sequential Insert Strategy)
15.5 Calling SORT from PL/I
15.5.1 Interfaces Offered
15.5.2 Parameters to be Passed
15.6 Checkpoint-Restart in PL/I
15.6.1 PLICKPT
15.6.2 PLIREST
15.6.3 PLICANC
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
15.7 DUMP in PL/I Optimizer
15.7.1 Output File
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
15.7.2 Options Specific to DOS
15.7.3 Options Specific to MVS
15.7.4 Compatibility
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
15.8 Return Codes in PL/I
15.8.1 Setting Return Codes
15.8.2 Return Code Values
15.9 Forcing an ABEND
15.9.1 Use of DISP in the JCL
15.9.2 Automatic Restart
15.10 Overlay Structures
15.10.1 Conversion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
15.10.2 Overlay in MVS
15.11 Storage Management in PL/I
............................ 340
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
......................... 340
........................... 342
............................ 343
......................... 343
......................... 344
.............................. 344
........................... 344
............................ 344
............................... 344
.......................... 344
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
.............................. 345
........................ 345
........... 333
.............. 334
................ 335
.............. 340
Contents ix
15.11.1 Storage Management in DOS ..................... 345
15.11.2 Storage Management in MVS
15.12 PL/I and CICS
15.12.1 File Support
................................. 346
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
15.12.2 Statements not Supported
15.12.3 CALLing DUMP
15.12.4 Execution Options
15.12.5 Compatibility
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
15.12.6 PL/I-CICS/VS Transaction ABEND Codes
15.12.7 PL/I Return from ON-units and CICS Transaction Backout
..................... 345
....................... 346
............... 346
.... 347
Chapter 16. FORTRAN
16.1 VS FORTRAN in OS/390
16.2 FORTRAN Conversion Considerations
Chapter 17. Language Environment (LE)
17.1 Introduction
17.1.1 General Comments on Language Environment
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
............................ 349
.................... 349
..................... 351
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
............ 351
17.1.2 Conceptual Differences between LE/VSE and OS/390 Language
Environment
17.2 VSE to OS/390 Migration Considerations
17.2.1 LE/VSE-conforming Languages
17.2.2 Useful Publications
17.3 Migrating from LE/VSE-Conforming Languages
17.3.1 C for VSE/ESA
17.3.2 COBOL for VSE/ESA
17.3.3 PL/I for VSE/ESA
17.4 Migrating from Non-LE/VSE Run-time Environments
17.4.1 Options Mapping
17.4.2 C/370
17.4.3 VS COBOL II
17.4.4 DOS/VS COBOL
17.4.5 DOS PL/I
17.4.6 V S FORTRAN
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
.................. 352
. . . . . . . . . . . . . . . . . . . . . 352
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
.............. 353
............................... 353
............................ 354
.............................. 354
........... 354
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
................................ 355
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
................................... 356
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
17.4.7 Migrating Interlanguage Communications Applications
17.4.8 Migrating Assembler Applications
17.5 Migrating from LE/VSE
17.5.1 Run-time Options
............................. 359
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
17.5.2 User Exits and Abnormal Termination Exits
17.5.3 Callable Services and Math Services
17.5.4 LE/VSE 1.4 Locales
17.6 CICS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
17.6.1 COBOL and CICS
17.6.2 Run-time Options
............................ 366
............................. 366
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
17.6.3 User Exits and Abnormal Termination Exits
................... 359
.............. 364
................. 365
.............. 367
....... 358
Chapter 18. Procedure Language REXX
18.1 REXX and VM/ESA
18.2 REXX and VSE/ESA
18.3 REXX and TSO/E
18.4 Environments
18.4.1 VSE/ESA Environment
18.4.2 VM/ESA Environment
18.4.3 TSO/E Environment
18.4.4 REXX Exec Sample for the OS/2, TSO and CMS Environments
x VSE to OS/390 Migration Workbook
...................... 369
............................... 369
............................... 369
................................ 369
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
. . . . . . . . . . . . . . . . . . . . . . . . . . . 370
. . . . . . . . . . . . . . . . . . . . . . . . . . . 370
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
.. 371
18.5 Migration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
18.5.1 REXX and SAA
18.6 REXX Bibliography
............................... 372
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Part 4. Converting VSE Utilities to OS/390 Utilities ....................... 373
Chapter 19. SORT
19.1 JCL Statements
19.2 Control Statements
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
19.3 Additional DFSORT/VSE Migration Considerations
19.3.1 Control Statements
19.3.2 ICETOOL
Chapter 20. DITTO
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
20.1 Compatibility with Previous Releases of DITTO
20.2 DITTO Functions that are No Longer Supported
20.3 DITTO Functions that are Not Recommended
20.4 DITTO Function Code Synonyms
....................... 384
............... 383
20.5 Batch Keywords that are No Longer Supported
20.6 Batch Keywords that are Not Recommended
20.7 DITTO/ESA Security
Chapter 21. VSAM Backup/Restore
21.1 VSAM Backup/Restore
21.1.1 OS/390 VSAM Backup/Restore
21.1.2 VSE/VSAM Backup/Restore
Chapter 22. Librarian
22.1 Overall Library Support
22.1.1 OS/390 ISPF Overview
22.1.2 OS/390 Library Management
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
. . . . . . . . . . . . . . . . . . . . . . . . 387
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
..................... 387
. . . . . . . . . . . . . . . . . . . . . . . 387
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
............................ 389
.......................... 390
....................... 391
............... 385
............ 379
.............. 381
.............. 382
.............. 384
Chapter 23. LISTLOG/PRINTLOG - Printing Log Streams
23.1 VSE PRINTLOG Utility
23.2 VSE LISTLOG Utility Program
23.3 OS/390 Hardcopy Processing
23.3.1 SYSLOG
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
23.3.2 Printing SYSLOG
23.4 OPERLOG
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
23.4.1 Printing OPERLOG
............................. 393
......................... 393
......................... 393
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
23.5 JES2 System Data Sets - Job Log and System Messages
23.6 Systems Management Recording
23.6.1 Printing SMF Records
........................... 395
...................... 395
Chapter 24. VSE/Fast Copy and OS/390 DFSMSdss
24.1 VSE/Fast Copy (Online and Stand-Alone)
24.2 DFSMSdss - OS/390 Component
....................... 398
.................. 397
........... 393
........ 395
............... 397
Part 5. Setting Up the Migration Environment .......................... 399
Chapter 25. Prepare the Migration Environment
25.1 Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
25.2 Install and Configure Required Hardware
................. 401
.................. 402
Contents xi
25.2.1 Processor Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 402
25.2.2 Devices Supported by OS/390
25.2.3 DASD Requirements
............................ 402
25.2.4 Other Hardware Requirements
25.2.5 Inter-Systems Connectivity
25.3 Order and Install the OS/390 Software
25.3.1 Fee-based Methods of Installing OS/390
25.3.2 Entitled Methods of Installing OS/390
25.4 Set Up Standards, Procedures, and Documentation
25.4.1 Installation Standards
. . . . . . . . . . . . . . . . . . . . . . . . . . . 407
25.4.2 Systems Management Procedures
25.4.3 Documentation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
25.5 Customize Your New OS/390 System
25.5.2 MVS BCP Customization
25.5.3 Other OS/390 Elements
.......................... 416
...................... 402
..................... 403
. . . . . . . . . . . . . . . . . . . . . . . . 404
................... 405
................ 405
.................. 406
........... 407
................... 409
.................... 413
......................... 415
Chapter 26. Test Environments
26.1 Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
26.1.1 Differences in Testing ″Philosophy″
26.1.2 Terminology
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
26.2 Test Systems in the Life of the Migration
26.3 VM, LPAR, or Standalone Systems
26.3.1 Logical Partitioning
26.3.2 Software Partitioning
26.3.3 Our Recommendation
26.3.4 Summary
26.4 Parallel Activities
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
26.4.2 Synchronizing VSE Applications with OS/390 Versions
26.5 Building the Initial OS/390 Test System
26.5.1 OS/390 Maintenance Environment
26.5.2 OS/390 Test Logical Partition
26.5.3 Maintaining Your OS/390 Libraries and SMP/E Zones
26.6 Shared DASD vs. Cloned DASD
26.6.1 Shared DASD between OS/390 Test Systems (vs. Cloned DASD)
26.6.2 Shared DASD between VSE and OS/390 (vs. Cloned DASD)
. . . . . . . . . . . . . . . . . . . . . . . . . . . 419
.................. 419
.................. 420
..................... 421
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
. . . . . . . . . . . . . . . . . . . . . . . . . . . 423
. . . . . . . . . . . . . . . . . . . . . . . . . . . 424
....... 430
................... 430
................... 431
...................... 431
....... 431
....................... 432
. 432
.... 433
Part 6. Running Your OS/390 System ................................ 435
Chapter 27. Orienting ICCF Users to TSO/ISPF
27.1 TSO/ISPF and SDSF
27.1.1 Editing Data Sets
27.1.2 Submitting Jobs
27.1.3 Using ISPF Utilities
.............................. 437
.............................. 438
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
............................ 439
27.1.4 Creating and Executing ISPF Applications
27.1.5 Managing Projects
27.1.6 Tracking Jobs
27.1.7 Retrieving Output
27.1.8 Using SDSF for Operators
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
........................ 441
................. 437
............... 440
Chapter 28. Orientation to OS/390 Console Operation
28.1 Introduction
28.1.1 Operating Hardware Consoles
28.2 Understanding the Operator Interfaces
28.2.1 Controlling Consoles
xii VSE to OS/390 Migration Workbook
............. 443
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
...................... 443
................... 443
. . . . . . . . . . . . . . . . . . . . . . . . . . . 444
28.2.2 Managing Display Consoles ....................... 444
28.2.3 Extended MCS Consoles
28.2.4 Understanding Message Formats and Replies
28.3 Controlling the OS/390 System
28.3.1 Starting the System
28.3.2 Displaying System Status
28.3.3 Stopping the System
28.4 Controlling Devices
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
28.4.1 Displaying the Status of Devices
28.4.2 Understanding Device Allocation
28.4.3 JES2 Devices
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
28.4.4 SDSF Device Panels
28.5 Controlling TSO Users, Jobs and Started Tasks
28.5.1 Displaying Work on Your System
28.5.2 Controlling Time Sharing Users
28.5.3 Controlling Batch Jobs
28.5.4 Controlling Started Tasks
28.6 Managing Remote Operations
28.6.1 JES2 RJE Operations
28.6.2 N JE Operations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
......................... 445
............ 446
........................ 447
............................ 447
......................... 447
........................... 448
.................... 448
.................... 448
............................ 449
.............. 449
.................... 449
..................... 451
.......................... 451
......................... 451
........................ 452
........................... 452
Chapter 29. Orientation for Utilities
29.1 IEBxxx or IEHxxx
29.2 IEBCOPY
29.3 IDCAMS
29.4 IEBGENER
29.5 DFSMSdss
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
................................ 455
........................ 455
Chapter 30. Systems Management Philosophy and Methodology
30.1 The Philosophy of Systems Management
30.1.1 Systems Management Overview
.................. 457
.................... 457
30.1.2 Systems Management Scope - What Needs to be Managed?
30.1.3 The Role of Automation
30.2 Change Management
30.2.1 Overview
30.2.2 Tasks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
30.2.3 Methodology
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
30.3 Problem Management
30.3.1 Overview
30.3.2 Tasks
30.3.3 Methodology
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
30.4 Performance Management
30.4.1 Overview
30.4.2 Tasks
30.4.3 Methodology
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
30.5 Operations Management
30.5.1 Overview
30.5.2 Tasks
30.5.3 Methodology
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
30.6 Security Management
30.6.1 Overview
30.6.2 Tasks
30.6.3 Methodology
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
30.7 Configuration Management
30.7.1 Overview
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
.......................... 460
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
. . . . . . . . . . . . . . . . . . . . . . . . . . 463
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
. . . . . . . . . . . . . . . . . . . . . . . . . . 469
....... 457
... 459
Contents xiii
30.7.2 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
30.7.3 Methodology
30.8 Asset Management
30.8.1 Overview
30.8.2 Tasks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
30.8.3 Methodology
30.9 Accounting Management
30.9.1 Overview
30.9.2 Tasks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
30.9.3 Methodology
30.10 Summary
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
. . . . . . . . . . . . . . . . . . . . . . . . . . . 471
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Chapter 31. Diagnosing System Problems
31.1 Problem Determination Tools
31.2 Dumps
31.3 IPCS
31.3.1 Analyzing Dumps
31.3.2 Traces
31.3.3 Analyzing Traces
31.3.4 Using IPCS
31.4 JES2 Diagnosis
31.5 SLIP
31.6 Performance Tools
31.7 LOGREC
31.8 SYSLOG
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
.............................. 474
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
31.9 DFSMS/MVS Diagnosis
31.9.1 DFSMSdfp
31.9.2 DFSMShsm
31.9.3 DFSMSrmm
31.9.4 DFSMSdss
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
......................... 473
............................. 476
31.10 Diagnostic Reference Publications
.................... 473
..................... 478
Part 7. Converting your Applications .................................479
Chapter 32. Conversion Process
32.1 Conversion Process Introduction
32.1.1 References
32.1.2 Prerequisites
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
32.1.3 Recommendations
32.1.4 Assumptions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
32.2 Mass Conversion - Background, Benefits and Method
32.2.1 IBM MVS Migration System - Background
32.2.2 Mass Conversion Overview / Benefits
32.2.3 Mass Conversion Tools
32.2.4 Automated Conversion Process
32.2.5 CORTEX MS
................................. 490
32.3 Mass Conversion Phase Overview
32.4 Preparation Phases
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
32.4.1 Phase 0: Project Management and Technical Leadership
32.4.2 Phase 1: Application Inventory
32.4.3 OS/390 Standards and Naming Conventions
32.4.4 Phase 2: Conversion Specifications
32.4.5 Phase 3: Customization or Development of Conversion Tools
32.5 Conversion Phases
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
. . . . . . . . . . . . . . . . . . . . . . . . . . 481
....................... 482
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
.......... 486
............... 486
................. 487
.......................... 489
..................... 490
...................... 493
..... 494
..................... 495
............. 497
................... 499
... 501
xiv VSE to OS/390 Migration Workbook
32.5.1 Program Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
32.5.2 JCL Conversion
32.5.3 Phase 4: Initial Trial Conversion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
.................... 505
32.5.4 Phase 5: OS/390 Regression Tests and Repeated Trial
Conversions
32.5.5 Initialization Testing
32.5.6 Unit Testing
32.5.7 System Testing
32.5.8 Parallel/Production Simulation Testing
32.6 Implementation Phases
32.6.2 Phase 6: Actual Conversion and Switchover
32.6.3 Switchover
32.6.4 Phase 7: Initial OS/390 Operations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
................ 514
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
............. 516
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
................... 518
Chapter 33. Conversion Services and Tools
33.1 Conversion Services
33.1.1 IBM Global Services
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
............................ 519
33.1.2 Automated Migration Services (AMS)
33.2 Conversion Tools
33.2.1 VSE/ESA Facilities
33.2.2 IBM OPTI-AUDIT for VSE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
......................... 520
33.2.3 IBM COBOL and CICS Command Level Conversion Aid (CCCA)
33.2.4 SISRO - CORTEX-Migration System (CORTEX-MS)
33.2.5 Computer Associates
. . . . . . . . . . . . . . . . . . . . . . . . . . . 525
33.2.6 The Source Recovery Company
................... 519
................. 519
. 522
......... 524
..................... 525
Part 8. Migration Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Chapter 34. Customer Migration Example
34.1 Background
34.2 Environment
34.3 Inventory
34.4 Resources
34.5 Duration
34.6 Performance
34.7 Benefits
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
..................... 529
Part 9. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Appendix A. Education Information
A.1 What Training is Needed and What Training Courses are Available
A.1.1 OS/390 Classes
A.1.2 Custom Classes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
A.1.3 OEM Product Education
A.2 When are Courses Scheduled and When are they Needed?
A.3 Who will Provide the Training?
A.4 Where will the Training Take Place?
Appendix B. Mapping ISV Products and Functions
B.1 The IBM Software Migration Project Office (SMPO)
B.2 VSE ISV System Management Products and OS/390 Compared
Appendix C. DFSMS Naming Conventions
. . . . . . . . . . . . . . . . . . . . . . . . 535
.. 535
.......................... 536
....... 536
........................ 537
..................... 537
............... 539
............ 539
..... 539
.................... 543
Contents xv
C.1 Data Set Naming Guidelines .......................... 543
C.2 Components of a Data Set Name
C.2.1 High-Level Qualifier (HLQ)
C.2.2 Relative Importance
C.2.3 File Contents
C.2.4 User Name
................................. 546
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
C.2.5 Data Set Level
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
................................ 547
C.3 Things Not to Include in the Data Set Name
C.3.1 Department Number
C.3.2 Application Location
C.3.3 Management Criteria
C.3.4 Output Device Type
C.3.5 Expiration Date
C.3.6 Access Method
C.3.7 Job Name
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
............................ 548
............................. 548
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
C.4 Common Applications - Naming Conventions
C.4.1 TSO Naming Conventions
C.4.2 VSAM Data Set Naming Conventions
C.4.3 DB2 Naming Conventions
C.4.4 Generation Data Sets
........................... 551
....................... 544
........................ 544
................ 547
................ 549
......................... 549
.................. 550
......................... 550
Appendix D. Special Notices
Appendix E. Related Publications
E.1 International Technical Support Organization Publications
E.1.1 OS/390 and MVS Redbooks
E.1.2 Other Redbooks
E.2 OS/390 Product Publications
E.2.1 Planning Books
E.2.2 OS/390 Online Product Library
E.3 Other Publications
E.4 Other Sources
................................... 559
E.4.1 Books on the Internet
E.5 Redbooks on CD-ROMs
How to Get ITSO Redbooks
How IBM Employees Can Get ITSO Redbooks
How Customers Can Get ITSO Redbooks
IBM Redbook Order Form
Glossary
List of Abbreviations
Index
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
................................. 583
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
. . . . . . . . . . . . . . . . . . . . . . . . . 557
........ 557
........................ 557
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
.......................... 557
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
...................... 558
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
........................... 559
............................. 559
............................. 561
.................. 561
..................... 562
.............................. 563
ITSO Redbook Evaluation
xvi VSE to OS/390 Migration Workbook
............................... 593
Figures
1. VAE with Three Address Spaces . . . . . . . . . . . . . . . . . . . . . . . . 6
2. VAE with Four Address Spaces
3. VSE/ESA Storage Layout
4. OS/390 Storage Layout
5. Migration Team
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6. Progressive versus Mass Conversion
7. Nonstandard Labels Supported by VSE
8. Extract from WSC Flash 9741
9. OS/390 Master and User Catalog Structure
10. OS/390 VSAM Integrity Provided by Cross-Region Shareoptions
11. Example of an MVS CICS/OS System using MRO
12. CICS Domains
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
13. Log Stream Choices Resulting from Hardware and Software Used
14. MVS Data Sets used by CICS
15. DL/I Functions Requiring Attention when Migrating to IMS/VS
16. Steps in Migrating DL/I Databases to IMS/ESA
17. VTAM Start Procedure
............................. 187
18. Comparison of IBM COBOLs
. . . . . . . . . . . . . . . . . . . . . . . . . 7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
..................... 49
. . . . . . . . . . . . . . . . . . . 107
. . . . . . . . . . . . . . . . . . . . . . . . . 113
. . . . . . . . . . . . . . . . 116
.... 126
............. 136
.. 146
......................... 146
..... 169
.............. 177
......................... 250
19. Compiler Options Comparison DOS/VS COBOL and COBOL for OS/390
and VM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
20. Recommended COBOL for OS/390 and VM Compiler Options for
Converted VS COBOL II Programs
...................... 262
21. Compiler Options Comparison VS COBOL II and COBOL for OS/390
and VM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
22. Reserved Words in COBOL for OS/390 and VM and not in DOS/VS
COBOL
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
23. Reserved Words in COBOL for OS/390 and VM for Unsupported
Features
24. Compiler Directing Words in COBOL for OS/390 and VM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
........ 264
25. Reserved Words in COBOL for OS/390 and VM and not in VS COBOL II 265
26. Reserved Words in COBOL for OS/390 and VM for Object-Oriented
COBOL Extensions
27. VSE Subroutine Linkage
28. MVS Subroutine Linkage
29. Sample Initiation Termination Coding
30. VSE and MVS Time Degrees of Precision
31. Comparison of the DTFCD and DCB Macros
32. Card File Macros in VSE and MVS
33. Card File Programs in VSE and MVS
34. Comparison of the DTFPR and DCB Macros
35. Comparison of the DTFMT and DCB Macros
36. Tape File Programs in VSE and MVS
37. Comparison of DTFDI and DCB macros
38. Comparison of the DTFSD and DCB Macros
39. Sequential DASD FILE Program in VSE and MVS
40. Comparison of DTFDA and DCB Macros
41. VSE Error Bytes and MVS Exception Code Bits
42. Record Reference by ID in VSE and MVS
43. Record Reference by KEY in VSE and MVS
44. Updating a DAM File under MVS
45. Adding to a DAM File under MVS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
............................ 270
........................... 271
.................... 274
................. 279
................ 295
...................... 295
.................... 296
................ 297
................ 302
.................... 303
................... 304
................ 310
............. 311
.................. 312
.............. 313
.................. 317
................ 318
....................... 318
...................... 319
Copyright IBM Corp. 1998 xvii
46. Loading a Sequential DAM File under VSE ................. 319
47. Loading a Sequential DAM File under MVS
48. Loading a Random DAM File under MVS
49. Loading a DAM File of U. or V. Length Records under MVS
50. Processing a DAM file under VSE
...................... 324
51. Loading a Random (Preformatted) DAM File under VSE
52. MVS Feedback Formats
............................ 326
53. Relationship between CCB operands and MVS Equivalents
54. Relationship between DTFPH Macro and MVS equivalents
55. Comparison VSE and MVS Major Elements
................ 320
.................. 320
...... 321
......... 325
....... 327
....... 328
................ 328
56. Callable Services in LE/VSE 1.4 with Differing Names in OS/390
Language Environment
57. Automated Conversion Process
58. Project Phases
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
....................... 491
xviii VSE to OS/390 Migration Workbook
Tables
1. Comparison of VSE Functions & Components to OS/390 Replacements 16
2. Who′s Normal Activities are Affected?
3. Nine Month Project
4. CNV Responsibilities
5. ABC Responsibilities
6. SER Responsibilities
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7. VSE Job Control Statements Summary
8. MVS Job Control Statements
. . . . . . . . . . . . . . . . . . . . . . . . . . 88
9. Overview of POWER JECL Statements
10. JES2 Control Statements
............................ 90
11. JES2 Input Sources (compared to POWER)
12. POWER/JES2 Job Scheduling Comparison
13. POWER/JES2 Output Service Comparison
14. FCB Name Prefixes
............................... 217
15. POWER/ICCF, VM/CMS, and JES2/TSO Functional Comparison
16. Accounting Records for NJE Activities
17. POWER Macro to JES2 Parameter Mapping
18. PLINE MACRO to JES2 Parameter Mapping
19. PRMT MACRO to JES2 Parameter Mapping
20. PRMT MACRO to JES2 Parameter Mapping
21. PNODE MACRO to JES2 Parameter Mapping
22. PCPTAB MACRO to JES2 Parameter Mapping
23. POWER Exit to JES2 Exits
........................... 231
24. Queue Management Commands
25. Task Management Commands
26. Control Commands
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
........................ 232
27. Network Management Commands
28. File Control Commands
............................ 234
29. Sending Commands and Messages
30. PRINTDEV Parameter Comparison
31. VSE - OS/390 Command Comparison
32. Useful COBOL Publications
.......................... 252
33. Action of COBOL Program Termination Statements
34. COBOL and PL/I: What Runs Where?
35. Useful Publications
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
36. REPORT and ISASIZE Options, C/370 and DOS PL/I
37. C/370 Migration Considerations
38. VS COBOL II Migration Considerations
39. DOS/VS COBOL Migration Considerations
40. DOS PL/I Migration Considerations
41. ILC Migration Considerations
......................... 358
. . . . . . . . . . . . . . . . . . . . 26
. . . . . . . . . . . . . . . . . . . . 86
. . . . . . . . . . . . . . . . . . . . 89
................. 212
................. 213
................. 215
.... 219
................... 224
................ 226
................ 228
................ 228
................ 229
............... 230
.............. 230
....................... 232
...................... 233
..................... 234
...................... 239
.................... 242
........... 257
.................... 351
........... 355
....................... 355
................... 356
................. 356
..................... 357
42. Option Recommendations Differing between LE/VSE 1.1 and OS/390
Language Environment
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
43. Option Recommendations Differing between LE/VSE 1.4 and OS/390
Language Environment
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
44. Option Recommendations for CICS Differing between LE/VSE and
OS/390 Language Environment
45. OS/390 DASD Layout
.............................. 403
46. S/390 Software Product Mapping
........................ 367
....................... 539
Copyright IBM Corp. 1998 xix
xx VSE to OS/390 Migration Workbook
Preface
The purpose of this document is to provide information and guidance to
personnel involved in a VSE to OS/390 operating system change; that is, a VSE
to OS/390 migration.
The primary focus is on VSE program and file conversions, and on operational
differences between the two systems. Chapters on each of the source languages
are included. DB/DC conversions, and operational differences between POWER
and JES2 are also addressed.
Within each chapter, not only are the differences pointed out, but OS/390
implementation and suggested use recommendations are made wherever
possible. These recommendations can help the migrating customer ″better″
design their use of OS/390.
Throughout this document, the term MIGRATION refers to the entire process of
transition from a VSE environment to an OS/390 environment. The term
CONVERSION describes the process of translating and updating VSE applications
and data to meet the requirements of OS/390.
The Team That Wrote This Redbook
This redbook was produced by a team of specialists from around the world
working with the International Technical Support Organization Poughkeepsie
Center.
Our thanks to Judith Jay for bringing a renewed focus to the issues, concerns
and effort required to migrate from VSE to OS/390.
Redbook Builders and Key Contributors
Cliff Bays IBM, Endicott
Bimshire Davis IBM, Chicago
Don Durand IBM, Poughkeepsie
Dan Ebaugh IBM, Gaithersburg
Patrick Fournier Managing Partner, Automated Migration Services, Walnut
Creek, CA
Dave Greenough IBM, Vermont
John Hutchinson IBM, Gaithersburg
Dan Janda IBM, Endicott
Judith Jay IBM, White Plains
Kevin Jones IBM, Endicott
Herbert Kratzer IBM, Germany
Tom Plunkett Senior Director of Systems Engineering, Automatic Data
Processing, Inc., Roseland, NJ
Gilbert Saint-flour Technical Manager, Automated Migration Services,
Livingston, NJ
John Sutera IBM, Endicott
Guenter Weigelt IBM, Germany
Copyright IBM Corp. 1998 xxi
Authors and Significant Contributors
Riaz Ahmad IBM, Gaithersburg
Boris Barth IBM, Germany
Bette Brody IBM, Gaithersburg
Jerzy Buczak IBM, Cary
Charlie Burger IBM, San Jose
John Casey IBM, Dallas
Walt Farrell IBM, Poughkeepsie
Steve Gracin IBM, Endicott
Judson Howard IBM, Los Angeles
Stanley Jones IBM, Endicott
Bill Keene IBM, Dallas
Ulrich Kettner IBM, Germany
Bob Leicht IBM, Endicott
Richard Lewis IBM, Gaithersburg
Jim McCoy IBM, Gaithersburg
Tom Murphy IBM, Endicott
Karl Pesendorfer IBM, Vienna, Austria
Dave Pilcher IBM, Boulder
Linda Richter IBM, Poughkeepsie
Bernd Rueckert IBM, Germany
Liz Rushton IBM, Sydney, Australia
Roger Smith IBM, Poughkeepsie
Howard Turetzky IBM, Boulder
Jon vonWolfersdorf IBM, Endicott
Frank Yaeger IBM, San Jose
Holly Yamamoto-Smith IBM, San Jose
Comments Welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your
comments about this or other redbooks in one of the following ways:
•
•
•
Fax the evaluation form found in “ITSO Redbook Evaluation” on page 593 to
the fax number shown on the form.
Use the electronic evaluation form found on the Redbooks Web sites:
For Internet users
For IBM Intranet users http://w3.itso.ibm.com/
Send us a note at the following address:
http://www.redbooks.ibm.com/
redbook@us.ibm.com
xxii VSE to OS/390 Migration Workbook
Part 1. Planning the Migration - An Introduction
Copyright IBM Corp. 1998 1
2 VSE to OS/390 Migration Workbook
Chapter 1. Why Customers Migrate
This chapter discusses the following topics:
1.2, Traditional Reasons for Migrating
1.3, Functional Reasons for Migrating to OS/390
1.1 A Synopsis of This Book
What do I need to read?
Executives: Read the following:
•
Part 1, “Planning the Migration - An Introduction” on page 1
•
Part 8, “Migration Experience” on page 527
System Programmers: Read the following:
•
Part 1, “Planning the Migration - An Introduction” on page 1
•
Part 2, “Converting the VSE Operating System to the OS/390 Operating
System” on page 67
•
Part 4, “Converting VSE Utilities to OS/390 Utilities” on page 373
•
Part 5, “Setting Up the Migration Environment” on page 399
•
Part 6, “Running Your OS/390 System” on page 435
Operators: Read the following:
•
Part 6, “Running Your OS/390 System” on page 435
Application Programmers: Read the following:
•
Part 3, “Converting VSE Languages to OS/390 Languages” on page 247
•
Part 7, “Converting your Applications” on page 479
This document is divided into nine parts:
•
Part 1, Planning the Migration - An Introduction
The scope of effort required to migrate from VSE to OS/390 will vary from
one organization to another. Many factors must be considered when making
the decision of when and how to migrate. This part discusses the reasons
for migrating, factors to consider when sizing the effort, and developing a
migration plan.
•
Part 2, Converting the VSE Operating System to the OS/390 Operating
System
In this part the conversion of the VSE system including JCL, data storage
methods, CICS, ICCF, telecommunications, spooling, and printing is
discussed. Additionally, a comparison of the use of CMS and TSO is
presented for those currently running VSE under VM.
•
Part 3, Converting VSE Languages to OS/390 Languages
Conversion of the various language compilers to their equivalent OS/390
language is discussed in this part. Also, any execution time differences are
discussed.
Copyright IBM Corp. 1998 3
•
Part 4, Converting VSE Utilities to OS/390 Utilities
Conversion of the VSE utilities to their equivalent OS/390 utilities is
discussed in this part.
•
Part 5, Setting Up the Migration Environment
No two Information Processing environments are alike. Hardware, software,
scheduling, personnel needs will be different in all cases. This part
discusses preparing for and tailoring the test environment, and various
hardware/software combinations and activities that can be performed in
parallel.
•
Part 6, Running Your OS/390 System
The OS/390 environment is much different than the VSE environment. This
part provides an orientation to the use of TSO/ISPF, OS/390 console
operation, and OS/390 utilities. Additionally, the systems management
philosophy with OS/390 and diagnosing problems with OS/390 are discussed.
•
Part 7, Converting your Applications
This part discusses the application program conversion process and some of
the conversion tools available.
•
Part 8, Migration Experience
An example of a migration plan for the ABC company is discussed in this
part.
•
Part 9, Appendixes
The appendixes provide useful information including a list of helpful
publications, education information, and a chart mapping Independent
Software Vendor products to OS/390 products.
1.2 Traditional Reasons for Migrating
Users migrating to MVS and OS/390 over the years have done so for a variety of
reasons. While the purpose of this document is to concentrate on the hows of
migrating and not so much the whys, it is interesting to note some of the more
typical or traditional reasons that customers migrate to OS/390.
1.2.1 Business Consolidation
Corporations, more recently, have found themselves involved in business
consolidation activities. Be it for economic and/or efficiency reasons companies
have been faced with the challenge of effectively addressing this type of change.
Consolidating the Information Technology infrastructure is just one of these
challenges. Many have found that combining the system workloads from various
parts of the newly consolidated organization has produced I/T system
requirements beyond the capacity of the VSE operating system. For example,
attempting to combine multiple VSE images into a single system image has often
created situations where multiple processor (n-way) capacity is needed. Prior to
the Turbo Dispatcher (n-way processor support) in VSE/ESA V2, OS/390 (or
MVS/ESA) provided the only solution. Another issue associated with combining
multiple images into a single system image has been the number of VSE
partitions. Similar to the case of the Turbo Dispatcher, prior to dynamic partitions
in VSE/ESA V1, OS/390 (or MVS/ESA) provided a solution to this issue.
4 VSE to OS/390 Migration Workbook
1.2.2 Mergers/Acquisitions
As with corporate consolidations, mergers and acquisitions present an equal
number of challenges when having to incorporate the I/S organizations of the
companies involved. A challenge that clearly presents itself is when the
organizations involved run different host based operating systems (such as
OS/390 and VSE/ESA). In cases where it has been decided to merge the I/S
organizations rather than run as autonomous entities, the issue of which
operating system should become the single production operating system arises.
It is often decided that because of its robust/enhanced functionality the operating
system be OS/390. This, then, requires that the VSE subsystems and applications
be converted to OS/390.
1.2.3 Capacity Constraints
Users running DOS/VSE and/or VSE/SP encountered system capacity constraints
due to the architectural design limits imposed by VSE. The need for additional
system capacity and resources due to things such as application and end user
growth found many VSE users coming up against these constraints. OS/390
provided the much needed relief for users who found themselves in this
situation. Fortunately, with the introduction of VSE/ESA V1 many of these
constraints were removed.
VSE users now find that many of the reasons, due to architectural limits, that
forced a conversion to OS/390 actually no longer exist. The following sections
describe some of these constraints in greater detail.
1.2.3.1 Virtual Storage
VSE/SP provided 24-bit addressing which supported 16 megabytes of virtual
storage. Users with the requirement for a large CICS partition, for example, were
forced to go to multiple CICS partitions when putting up a single large CICS
partition was not possible. This sometimes caused additional problems as it was
often difficult to split a single CICS application into multiple CICS partitions.
However, where possible, users chose to implement multiple CICS regions using
the CICS Multiple Region Option (MRO). Still, with the addition of multiple CICS
regions (MROs), comes the added expense of managing the MROs. And, as the
MROs numbers increase, you need system management tools, such as CICSPlex
System Manager for MVS/ESA (CICSPlex SM) to ease the system management
burden caused by multiple CICS systems.
MVS, or OS/390, provided users with virtual storage constraint relief through
31-bit addressing capabilities. However, some users found relief with virtual
address extensions (VAE) in VSE/SP V3. VSE/ESA V1 introduced 31-bit
addressing support. This now gives VSE users the ability to address up to 2GB of
virtual storage. Hence, it is now possible for VSE users with large CICS partition
requirements to have this requirement satisfied by VSE.
Chapter 1. Why Customers Migrate 5
┌─────────────────────────────┐ ─────
││
│ SVA - 2,304K │ │
│││
├─────────────────────────────┤ │
│ F1 - VSE/POWER - 832K │ 8,832K Shared Address
├─────────────────────────────┤ │ Space Area
│ F2 - ACF/VTAM - 3,648K │ │
├─────────────────────────────┤ │
│ F7 - DATABASE - 2,048K │
├─────────┬─────────┬─────────┤ ─────
│ │ UNUSED │ UNUSED │
│ UNUSED │ 128K │ 64K │ │
│ 512K ├─────────┤ │ │
├─────────┤ ├─────────┤ │
│ F6 1.5M │F9 1,536K│ │ │
│ │ │ CICS │ │ Private Address
├─────────┼─────────┤ PROD │ 7,168K Space Area
│ F5 1.5M │ CICS │ │ │
├─────────┤ PRD1 │ │ │
│ F4 1.5M │ │ │ │
├─────────┤FA 5,504K│ F3 7.1M │ │
│ BG 1.5M │ │ │
├─────────┴─────────┴─────────┤ ─────
│ SUPERVISOR - 384K │
└─────────────────────────────┘ 0
Figure 1. VAE with Three Address Spaces
Figure 1 depicts a typical VSE virtual storage configuration using Virtual
Addressability Extension (VAE) introduced in VSE/SP V2. In this configuration the
largest possible address space is approximately 7MB. Therefore, a single
partition running in its own address space is limited to 7MB. Initially support was
for only three address spaces. This was later enhanced to nine.
6 VSE to OS/390 Migration Workbook
┌───────────────────────────────────────┐ ─────
││
│ SVA - 2,304K │ │
│││
├───────────────────────────────────────┤ 5,184 K
│ F1 - VSE/POWER - 832K │ │
├───────────────────────────────────────┤ │
│ F7 - DATABASE - 2,048K │
├─────────┬─────────┬─────────┬─────────┤ ─────
│ │ UNUSED │ UNUSED │ UNUSED │
│ UNUSED │ 128K │ 64K │ 3,036K │ │
│ 512K ├─────────┤ ├─────────┤ │
├─────────┤ ├─────────┤ CICS │ │
│ F6 1.5M │F9 1,536K│ │FB 4,096K│ │
│ │ │ CICS │ TOR │ 10,816 K
├─────────┼─────────┤ PROD ├─────────┤ │
│ F5 1.5M │ CICS │ │ACF/VTAM │ │
├─────────┤ PRD1 │ │ │ │
│ F4 1.5M │ │ │ │ │
├─────────┤FA 5,504K│ F3 10.8M│F2 3,684K│ │
│ BG 1.5M │ │ │ │
├─────────┴─────────┴─────────┴─────────┤ ─────
│ SUPERVISOR - 384K │
└───────────────────────────────────────┘
Figure 2. VAE with Four Address Spaces
Figure 2 is an example of how a customer would relieve the limitation of a 7MB
private address space as depicted in the previous diagram. The 7MB limitation
results from cross-system functions (for example, POWER and VTAM) having to
reside in the shared area. Shared area requirements reduce the amount of
virtual storage available for private area address spaces. In the above example
ACF/VTAM is moved to a private address space from the shared area. This
results in an additional 3.5MB for the private area address spaces. When VTAM
is moved it was also necessary to move any VTAM applications into the same
address space as VTAM. In this instance customers would run a CICS Terminal
TOR
Owning Region (
would then communicate with one or multiple CICS Application Owning Regions
AOR
s) running in another address space. The CICS AOR was often the reason
(
for additional private area virtual storage.
) in the same address space with VTAM. The CICS TOR
Chapter 1. Why Customers Migrate 7
│ Static │ Dynamic │
│ Partitions │ Partitions │
├──────────────────────────────────────────────┴───────────────┤
││
│ SVA (31-Bit) │
├──────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┤
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
16MB │------│-------│-------│-------│-------│-------│-------│-------│
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
│ │ VSE/ │ CICS/ │ ACF/ │││││
│ │POWER │ VSE │ VTAM │ ││││
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
│ BG │ F1 │ F2 │ F3 │ .... │ FB │ C1 │ Y1 │
├──────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┤
││
│ SVA (24- Bit) │
├──────────────────────────────────────────────────────────────┤
││
│ SUPERVISOR │
└──────────────────────────────────────────────────────────────┘
VSE/ESA V1 w/ 31-Bit Addressing
Figure 3. VSE/ESA Storage Layout
Figure 3 shows the virtual storage layout with VSE/ESA V1 or V2 exploiting
Enterprise Systems Architecture (ESA) and 31-bit addressing. VSE/ESA V1, with
31-bit virtual (and real) addressing support, provides virtual storage constraint
relief by extending the addressable area within a virtual address space from
16MB up to 2GB. This is a significant amount of constraint relief for both online
and batch applications running in either static or dynamic partitions.
8 VSE to OS/390 Migration Workbook
┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐ 2GB
│ │ │ │ │ │ │ │ │ │
│ J │ C │ D │ R │ T │ V │ U │ B │ B │
│ │ │ │ │ │ │ N │ │ │
│ E │ I │ F │ A │ S │ T │ I │ A │ A │
│ │ │ │ │ │ │ X │ │ │
│ S │ C │ S │ C │ O │ A │ │ T │ T │
│ │ │ │ │ │ │ S │ │ │
│ │ S │ M │ F │ │ M │ R │ C │ C │
│ │ │ │ │ │ │ V │ │ │
│ │ │ S │ │ │ │ C │ H │ H │
│ │ │ │ │ │ │ S │ │ │
├─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┤
││
│ MVS NUCLEUS │
└─────────────────────────────────────────────────────┘ 0
Figure 4. OS/390 Storage Layout
Figure 4 depicts a typical OS/390 system including the various functional
subsystems, each running in its own address space. As in VSE/ESA, each
address space has the ability to address up to 2GB of virtual storage.
1.2.3.2 N-way Processor Support
VSE/SP did not provide support for multiple processors (that is, n-way
machines). Users, for a variety of reasons, exceeding the capacity of a single
engine (Uni-processor) found it necessary to convert to OS/390 for its
multiprocessor support. As was mentioned with virtual storage, typically these
were users with a requirement for multiple CICS and batch partitions. The Turbo
Dispatcher support in VSE/ESA V2 provided support for n-way processors.
However, in the current version of VSE/ESA V2.2 a practical limit of only being
able to support a 3-way processor exists. The number of parallel and
non-parallel tasks that exist within the system workload will determine the actual
number of processors that can be effectively utilized.
1.2.4 Image
1.2.3.3 Task Quantity
As was mentioned in the case of business consolidations, task quantity relates to
the amount of concurrent work in the system. In the consolidations example
several system images (workloads) are combined into a single system image. As
was also mentioned, the previous VSE system limit of 12 partitions severely
limited the ability to run very large workloads; particularly those consolidated
workloads requiring more that 12 partitions. The solution was to run multiple VSE
images. This often created issues of managing multiple images, or deciding to
migrate to OS/390.
One final reason that users have decided to make the conversion to OS/390 is
that of image. This particular reason is little talked about because it is used the
least. But, it is felt that it should at least be mentioned or acknowledged.
It has been felt by some users in the VSE community that VSE is the orphan of
the S/390 operating systems, ranking behind OS/390 and VM/ESA. These
concerns are partly justifiable and stem from the fact that VSE has often lacked
functionality provided in OS/390 and VM/ESA. Even when VSE has provided such
functionality it has not done so, at least from a user perspective, in a timely
Chapter 1. Why Customers Migrate 9
manner. That is, not concurrent with OS/390 and/or VM/ESA. This has lead users
to ponder whether VSE is a viable and strategic S/390 operating system. This
lack of confidence has forced these users to look at OS/390 as a more stable and
strategic operating system with a viable long term outlook. An outlook that often
catches the eye of upper I/S management and spurs the move toward OS/390.
The introduction of VSE/ESA′s exploitation of the ESA/390 platform however has
alleviated some of this doubt. It is fair to say that the focus for VSE/ESA is
support for the entry to medium sized enterprises. With this in mind, it is
reasonable to not expect the full array of functionality and support with VSE/ESA
that one would expect with OS/390. OS/390 will continue to focus on the
intermediate-large to very large ′leading-edge′ environments.
1.3 Functional Reasons for Migrating to OS/390
Besides some of the traditional reasons discussed in the previous section, there
also exist some functional or other practical reasons for migrating to OS/390.
While there are probably other functional reasons for migrating, this section will
cover those that are typically the most common. Particularly, those that relate to
applications and systems management.
1.3.1 Applications Availability
The backbone and primary purpose of any information system is its applications.
This software, often considered mission critical, justifies the whole existence of
information systems. Mission critical applications are those applications that are
seen as most vital and crucial to the running of any business. The choice of
application software is driven by business requirements. The hardware and
software platforms required to support a given application is a secondary
decision. Thus VSE users may find that the choice of a particular application may
require the installation of another hardware and/or software platform. They may
also consider a complete migration to this other software platform. Some S/390
business applications may only support OS/390. These applications may take
advantage of some of the unique characteristics of OS/390 and/or its subsystems
such as CICS Transaction Server, DB/2 or CICSPlex System Manager. A set of
applications requiring a full function (level 2) message queuing manager, as
provided by MQSeries for OS/390, is another example of OS/390 unique
application capabilities.
With the announcement of Open Edition support in OS/390 a whole new set of
application functions are now available to the S/390 user. Specifically,
applications that were formally only available on UNIX type platforms are now
available to the S/390 user. Applications such as Lotus Domino, PeopleSoft, SAP
and full function Web serving bring additional application capability to the S/390
platform under OS/390.
1.3.2 Systems Management
Some of the traditional OS/390 strengths of high availability, systems
management, performance, scalability and capacity have also been great
attractions for the VSE user. OS/390 provides management capabilities that allow
the system to more effectively manage the workload over those capabilities
provided by VSE. Facilities such as OS/390 performance groups and the
Workload manager provide this greater workload management flexibility.
10 VSE to OS/390 Migration Workbook
OS/390 systems managed storage (DFSMS) provide enhanced system resource
allocation and management. The Hierarchical Storage Manager (HSM),
Removable Media Manager (RMM) and basic storage device allocation of
OS/390 provide functions not inherent in the VSE environment. However, some
of these functions are available from independent software vendor (ISV)
products.
1.3.3 Connectivity
Connectivity, that is the ability to connect to other systems, has been one of
those areas where VSE support has lagged behind OS/390 and VM. For example
ACF/VTAM support for channel-to-channel connections between host systems
was not introduced until VSE/AF 2.1.3. Lack of other connectivity support, that is
VTAM APPN, SNI gateway, full function TCP/IP and OSA-2, has only added to the
reasons why VSE users have decided to migrate to OS/390. However, as
mentioned, VSE/ESA has since provided support for some of these capabilities,
namely OSA-2 and VTAM APPN. VSE now enjoys virtually all of the same
communications and connectivity capabilities as OS/390 and VM.
1.3.4 Systems Availability
Systems availability has always been a strong requirement for many information
systems environments. Hardware and software technology enhancements in both
VSE and OS/390 have brought about increased system availability. OS/390,
however, has had at its core key design elements that give it premier system
availability characteristics. Advanced S/390 hardware features coupled with
OS/390 software functions give it this outstanding capability. VSE users have
found the attractiveness of this enhanced systems availability capability, along
with other features, yet another reason to embark on an OS/390 migration.
An example of OS/390 enhanced systems availability is the 3990 Concurrent
Copy function when used along with BWO (Backup-While-Open) by DFSMSdss
which allows backups to be taken with integrity even when control area and
control interval splits and data set additions (new extents or add-to-end) are
occurring for VSAM key sequenced data sets. Backup-while-open for CICS
VSAM files supports SMS managed data sets without the need to close a CICS
VSAM data set or to bring applications down to back up VSAM data sets. This
support for backing up VSAM files while open for update is provided in
conjunction with MVS Data Facility Product (MVS/DFP).
In the Parallel Sysplex environment concurrent coupling link maintenance allows
the replacement of a failing coupling link without powering the CEC down. With
DB2 for OS/390 copies of DB2 tablespaces can be made using DFSMS
concurrent copy, a process that significantly improves data availability by
reducing the time necessary to complete logically consistent copies of
mission-critical data.
Chapter 1. Why Customers Migrate 11
1.3.5 Staff Availability
In recent years S/390 application and system programming resources have
become increasingly more difficult to acquire. This is particularly true for the VSE
user. As the current information systems curriculums focus on the more current
technologies, the traditional VSE system programming, and to some degree
OS/390, skills are not being replenished. This coupled with the current high
demand for year 2000 programming resources has only added to the pile of
reasons that VSE users migrate to OS/390. While some amount of VSE skills are
transferable to OS/390, focus is placed on developing JCL and operational skills.
12 VSE to OS/390 Migration Workbook
Chapter 2. Sizing the Effort
This chapter discusses the following topics:
2.1, Introduction to Sizing
2.2, OS/390 Components/Products/Subsystems
2.3, What Changes Between VSE and OS/390?
2.4, Who is Affected by This Migration?
2.5, Approaches to Migration
2.6, Educational Requirements
2.7, Scope of Work and Challenges
2.8, Cost Considerations
2.1 Introduction to Sizing
When undertaking a project such as migrating from VSE to OS/390 attention
always turns to how much effort is really involved. The sizing effort attempts to
get a fairly reasonable handle on the amount of effort and resources needed for
such a project. It is desired to be able to estimate with some degree of
confidence the human, system and financial resource requirements. This chapter
will discuss some of the key migration activities and issues, highlighting the
considerations that will affect the scope and size of this project. We will first
define two terms that are often used throughout this publication, migration and
conversion.
Migration
is the process which takes the data processing workload, and
operations from the VSE environment to the OS/390 environment. This includes a
planning phase, a preparation phase, a conversion phase and a production
implementation phase.
Conversion
is the process within the migration where programs, data, and JCL
are converted, tested, and cut over to production in the OS/390 environment.
2.1.1 Defining the Migration Project Objectives
Typical migration project objectives for an OS/390 migration project include a
combination of operational needs and cost/benefit requirements.
•
End-user transparency
•
Minimal disruption of operations and applications support
•
No overlap of dual VSE and OS/390 operations
•
Standardized and automated OS/390 applications fit for automated OS/390
operations
Copyright IBM Corp. 1998 13
2.1.2 Areas of VSE and OS/390 Differences
In order to properly assess and size the magnitude of the migration project, it is
first necessary to understand some of the basic differences between the two
operating systems. Once these differences are understood a realistic or more
reasonable project outlook can be determined. The purpose of this section is to
put into perspective these differences.
Even though both VSE and OS/390 support the IBM S/390 architecture, there are
differences that must be considered at both the subsystem and application
program level. When migrating or converting application programs from VSE to
OS/390 it is important to identify these differences. The primary differences can
be categorized as follows:
1. Source Programs
2. Job Control Language (JCL)
3. Files
4. Operations
2.1.2.1 Source Programs
The significance of the differences when dealing with program source code can
vary by many factors. The primary determining factors involved in converting
source programs have to do with the interfaces which provide services to the
application programs. These application interfaces and corresponding protocols
for requesting supervisor services are different in VSE than in OS/390.
The factors involved in converting batch programs that interface directly to the
control program and programs that interface with application subsystems are
different. Consequently, the effort and the techniques used will vary.
Source Program Inventory
The first step in assessing the scope of any application program conversion is
determining the whereabouts of all of the program source code. This task must
not be overlooked and needs to be done early in the conversion project. You will
need to determine that all executable modules have associated source code and
that all source code has associated executable modules. Executable modules
missing source code, for example, will have to somehow be recreated or
alternate plans developed to provide the program function. Conversion tools are
available to assist in this task and are discussed later in this publication.
Customers who have completed or are in the process of Year 2000 compliance
are most likely aware of this issue.
The impact of source program conversion can be reduced by positioning the VSE
production system with source programs compatible with both VSE and OS/390.
For example, moving to the Language Environment for VSE will provide language
compiler compatibility (for COBOL , PL/I and C for VSE/ESA) between VSE and
OS/390.
Batch and Online Program Conversion
The conversion of batch applications must take into account differences in the
application interfaces provided by VSE and OS/390. The significance of the
changes required in the source programs depends a great deal on the source
program language and to some extent the I/O access methods used. This
14 VSE to OS/390 Migration Workbook
document is organized by source language type and goes into great detail at
that level and includes the I/O considerations.
The conversion of the CICS applications consists of two steps. First, the VSE
version of the CICS application subsystem is replaced with an OS/390 version.
The two different versions of CICS contain the interfaces to the respective control
programs. The second step deals with the application source code itself.
In general, the interfaces provided to the applications by the two versions of
CICS are the same, the source programs do not change and need only to be
recompiled with a corresponding OS/390 compiler. However, consideration
should also be given to the fact that certain application level interfaces available
in VSE may not be available in OS/390. The macro level API is one example.
Applications written with this interface will have to be changed to use the
command level API. Any access to system level control blocks should also be
reviewed. Additional considerations will be required if the CICS application
programs are interfacing with more than the CICS subsystem. Also, there are
some source language restrictions. This document contains a section describing
the CICS, DB2 and DL/I subsystems in great detail.
In summary, when comparing online and batch programs, the effort required to
convert batch applications is much greater than online applications using
application subsystems such as CICS and DL/I. By using application subsystems
the differences in control program application interfaces become transparent to
the application programmer. The installation only needs to be concerned with
the common interface provided by the subsystem in situations where a VSE
version and an OS/390 version are both available.
2.1.2.2 Job Control Language
All VSE JCL must be converted to OS/390 JCL. Because VSE and OS/390 differ
significantly in JCL structure and syntax, this is normally one of the most
complex tasks of any migration. As in the case of batch and online source
programs, the considerations are more significant with the batch applications.
There are, however, aids available to reduce the effort required.
2.1.2.3 Files
The impact of file conversion can be reduced by positioning the VSE production
system with file formats and access methods that are compatible with both VSE
and OS/390.
VSAM files are generally compatible files. One section of this document is
dedicated exclusively to VSAM files and VSAM catalogs. Additional information
regarding VSAM file considerations can be found in the different source
language sections.
Direct Access Method (DAM) files require individual evaluation because each
can have unique characteristics. Each of the language sections has a description
on accessing DAM files. It is recommended that these file structures be
converted to relative record VSAM files where possible.
Sequential tape files are compatible between VSE and OS/390. There can be
differences in the format of the labels and how they are processed. There is a
chapter in this publication that deals exclusively with tape files.
Chapter 2. Sizing the Effort 15
Sequential DASD files are compatible between VSE and OS/390. However,
OS/390 does not support sequential (SAM) files located within VSAM managed
space. These files will have to be reloaded to different DASD areas before
OS/390 can process them.
1
DL/I databases are compatible with IMS databases
if the ″IMSCOMP″
parameter was specified during the DL/I DBD generation. If this parameter was
not specified, then reloading of the database will be necessary; that is, a VSE
positioning activity. Similarly, DB2 for OS/390 provides compatibility with DB2 for
VSE. A section on database differences is included in this publication.
Note:
VSE DASD volumes can be read and processed by OS/390. VSE DASD
volumes, when first read by an OS/390 system, will have their free space areas
′
calculated and appropriate entries recorded in the volume
s VTOC. VSE systems
can later process these volumes as required. (Even though OS/390 has written
new records in the VTOC, VSE will ignore them.) Never, however, should both
systems have concurrent access to DASD volumes. Also, all volumes are required
by OS/390 to have unique volume serial numbers.
2.1.2.4 Operations
OS/390 operational procedures and operator commands differ significantly from
those used in VSE. The input/output spooling subsystems (VSE/POWER and
OS/390 JES) are quite different in function and operations also. Some of these
differences are addressed in this publication.
Changing operational procedures and training of operators in the operations of
OS/390 are very important tasks that must be performed during a VSE to OS/390
migration. Training courses are available to assist in this effort.
2.1.3 Comparison of Basic VSE Functions & Components to OS/390
Here is a list of some of the areas or programs that may be affected:
Table 1 (Page 1 of 3). Comparison of VSE Functions & Components to OS/390
Replacements
VSE OS/390 Comment and Reference
VSE Base Functions
IOCP
POWER (w/PNET, RJE)
EREP
MSHP
...
Application Generators
VisualAge
VisualLift
SDF/CICS & SDF II
CSP
DMS/CICS
OS/390 Base Functions
IOCP, HCD *
JES2, JES3 (w/NJE, RJE) *
EREP *
SMP/E *
...
Application Generators
VisualAge
VisualLift *
SDF II
CSP
DMS/CICS
1
IMS databases are the OS/390 equivalent of VSE DL/I databases.
16 VSE to OS/390 Migration Workbook
Table 1 (Page 2 of 3). Comparison of VSE Functions & Components to OS/390
Replacements
VSE OS/390 Comment and Reference
Languages
LE/VSE
HLASM
COBOL
PL/I
RPG II
REXX
FORTRAN
C
AFP Family
PSF/VSE
PPFA
OGL
Font Libraries
...
Network Management
VTAM (APPC, APPN)
NCP
BTAM/ES
TCP/IP
LANRES
MQSeries
NetView - CSF
CICS/VSE
CallPath
DISOSS
...
Console Management
OCCF
Console Automation
(ISV)
Systems Management
MSHP
DSNX
Interactive Interface
Explore (ISV)
VSE/PT
OMEGAMON (ISV)
Development Environment
ICCF
CMS
Programming Library Mgmt:
VSE Librarian,
Panvalet (ISV)
Security Manager
ACLR
ALERT (ISV)
Disk Management
ICKDSF
VSAM
Dump/Restore/Fcopy
CA-Dynam/D (ISV)
Tape Manager
CA-Dynam/T (ISV)
Languages
LE/MVS *
HLASM *
COBOL
PL/I
RPG II
REXX
FORTRAN
C/C++ *
AFP Family
PSF/MVS
PPFA
OGL
Font Libraries
...
eNetwork Comm. Server
VTAM (APPC, APPN) *
NCP *
BTAM/SP
TCP/IP *
LANRES *
MQSeries
NetView
CICS Transaction Server
CallPath
DISOSS
...
Console Management
MCS & MPF*
SDSF *
NetView AOC
NetView
Systems Management
SMP/E *
NetView DM
TSO/ISPF panels *
RMF *
RMF *
RMF *
Development Environment
TSO/E *
ISPF/PDF/SCLM *
ISPF Functions:
DM, PDF, LMF, SCLM *
DM, PDF, LMF, SCLM *
Security Server
RACF *
RACF *
DFSMS Family *
ICKDSF *
DFSMSdfp (VSAM) *
DFSMSdss *
DFSMShsm *
DFSMS Family *
DFSMSrmm *
See Part 3 page 247
Chapter 17 page 351
Chapter 13 page 267
Chapter 12 page 249
Chapter 15 page 333
Chapter 14 page 329
Chapter 18 page 369
Chapter 16 page 349
See Chapter 11 page 235
See Chapter 9 page 185
See Chapter 6 page 133
See Chapter 28 page 443
See Chapter 30 page 457
TSO/ISPF Panels do not
provide the JCL
generation function of the
Interactive Interface
See Chapter 7 page 155
and Chapter 27 page 437
See Chapter 22 page 389
See Chapter 24 page 397
Chapter 2. Sizing the Effort 17
Table 1 (Page 3 of 3). Comparison of VSE Functions & Components to OS/390
Replacements
VSE OS/390 Comment and Reference
ADSM/VSE ADSM/MVS
DITTO/ESA for VSE DITTO/ESA for OS/390 See Chapter 20 page 381
DFSORT/VSE DFSORT * See Chapter 19 page 375
Data Base Management
DL/I
DB2 (SQL/DS)
QMF
GDDM/VSE GDDM/MVS * See Chapter 7 page 155
Dump Analysis
Info/Analysis
(VP)
Job Scheduler (VP) OPC/ESA
Report Manager (VP) RMDS
NetView family
FTP
Key:
(*)
Software Vendor
= Package is an element of OS/390.
Data Base Management
IMS/DB
DB2
QMF
Dump Analysis
IPCS *
NetView family
FTP
(ISV)
= VSE function provided by independent
See Chapter 8 page 169
2.2 OS/390 Components/Products/Subsystems
Note: The terms OS/390 and MVS (including MVS/XA, MVS/SP, and MVS/ESA)
may be used interchangeably throughout this publication. OS/390, with its
integrated components, refers to the current version and all previous versions of
MVS unless otherwise noted.
Another important aspect to consider when sizing the migration is determining
which OS/390 components will be installed. This is basically determined by
assessing which OS/390 components and/or optional products provide functions
comparable to those in VSE. The previous table in this section provided a
comparison chart for this purpose. What follows is a brief description of some of
the key OS/390 components.
There was discussion about including that which is the same between the
operating systems. This can be a big item when customers are also entertaining
ideas of other operating systems. There is more closeness between VSE and
OS/390 than with RISC6000/UNIX to OS/390. The move to UNIX will require a new
start or complete rewrite.
This is a frequent consideration when customers are considering implementing
ERP Applications. They can put these core business integrated packages (for
example SAP R3, Bond, JDEdwards, Oracle) on either a UNIX or OS/390
platform.
18 VSE to OS/390 Migration Workbook
2.2.1 The OS/390 Operating Environment
This section introduces the OS/390 operating environment. A publication entitled
OS/390 Introduction and Release Guide
understanding of OS/390. This book describes the information associated with
OS/390 including OS/390 books and books for participating elements.
2.2.1.1 OS/390 Product Content
The operating system environment that is called OS/390 consists of MVS/ESA SP
and its component products and functions.
Base Elements
As an example, OS/390 Version 2 Release 5 contains the base elements listed
below. Subsequent releases of OS/390 will contain similar components, their
replacements.
•
System Services
− MVS/ESA SP
− Base Control Program (BCP)
− DFSMSdfp
− EREP
− ESCON Director Support
− IBM High Level Assembler for MVS
− ICKDSF
− ISPF
− JES2
− MICR/OCR Support
− MVS/Bulk Data Transfer (BDT Base)
− TSO/E
− 3270 PC File Transfer Program
− FFST
− TIOC
•
Systems Management
, GC28-1725 is recommended for a better
− HCD
− ICSF
− SMP/E
− SystemView for MVS Base
•
Application Enablement
− Language Environment
− DCE Application Support
− Encina Toolkit Executive
− GDDM/MVS (includes PCLK and OS/2 Link)
− OS/390 Application Enabling Technology
− SOMobjects Runtime Library
− VisualLift for OS/390 Runtime Library
− C/C++ IBM Open Class Library
Chapter 2. Sizing the Effort 19
•
Distributed Computing
− UNIX Application Services (Shell, Utilities, and Debugger)
− UNIX System Services (included in the BCP)
•
Distributed Computing Services
− DCE Base Services (OSF DCE level 1.1)
− DCE DFS (OSF DCE 1.2.1 level)
− DFSMS/MVS Network File System
•
eNetwork Communications Server
− VTAM (includes the AnyNet function)
− IBM TCP/IP
- CICS Sockets
- Host on Demand
- IMS Sockets
- Domain Name Server and WLM support (DNS/WLM)
•
Network Computing Services
− Domino Go Webserver for OS/390
- NetQuestion
- Internet Connection Secure Server
− IBM BookManager BookServer for World Wide Web
•
UNIX System Services
− OS/390 UNIX System Services Application Services
− OS/390 UNIX System Services Shell & Utilities
− OS/390 UNIX System Services Debugger
•
LAN Services
− LANRES
− LAN Server
− OSA Support Facility
•
Softcopy Publications Support
− BookManager READ/MVS
− Softcopy Print (includes Softcopy Print for DBCS Languages)
Optional Features
These are priced as well as unpriced features included in OS/390
integration-testing. The host-based features are capable of being dynamically
enabled or disabled. As an example, here is a list of optional features for
OS/390 Version 2 Release 5:
•
System Services
− JES3
− MVS/BDT File-to-File
− MVS/BDT JES3 SNA NJE
•
Security Server
− OS/390 Security Server (RACF and DCE Security Server at OSF DCE level
1.1)
20 VSE to OS/390 Migration Workbook
•
Systems Management Services
− DFSMS/MVS features (DFSMSdss, DFSMSrmm, DFSMShsm)
− HCM
− RMF
− SDSF
•
Application Enablement Services
− DFSORT
− GDDM-PGF
− GDDM-REXX/MVS
− IBM C/C++ Compiler (with debug tool)
− IBM C/C++ Compiler (without debug tool)
− IBM High Level Assembler Toolkit
− Language Environment Data Decryption
− SOMobjects Application Development Environment
− VisualLift Application Development Environment for MVS, VSE, and VM.
•
Distributed Computing Services
− DCE User Data Privacy (DES and CDMF) - OSF DCE 1.1 level
− DCE User Data Privacy (CDMF) - OSF DCE 1.1 level
− OS/390 Print Server (includes IP PrintWay/NetSpool)
•
eNetwork Communications Server
− IBM TCP/IP Kerberos (DES)
− IBM TCP/IP Kerberos (non-DES)
− IBM TCP/IP Network Print Facility
•
Network Computing Services
− Domino Go Webserver for OS/390 Export Security Feature
− Domino Go Webserver for OS/390 North America Secure Feature
•
Softcopy Services
− BookManager BUILD/MVS
See the latest version of the
OS/390 Introduction and Release Guide
for an
up-to-date list of OS/390 features and complete descriptions.
2.2.1.2 MVS Subsystem and Component Terminology
The following are some of the major subsystem programs or functional support
facilities that are provided as integral components of an OS/390 system. They
can help an installation manage and control their MVS operating system
environment.
•
Job Entry Subsystem/2 (JES2)
One of two MVS system facilities for spooling, job queueing, and managing
input and output. This publication will address VSE POWER to MVS JES2
migrations.
•
Job Entry Subsystem/3 (JES3)
The second MVS system facility for spooling, job queueing, and managing
input and output. JES3 will not be addressed in this publication.
Chapter 2. Sizing the Effort 21
•
Data Facility Storage Management Subsystem
Complementary functions of MVS/DFP and other individual products of the
Data Facility family which, together with RACF, provide a system-managed,
administrator-controlled storage environment.
•
Systems Resources Manager (SRM)
A system function that determines which address spaces should be given
access to system resources (for example processor, storage, I/O), and the
rate at which each address space is allowed to consume resources. To a
large degree, an installation′s control over the system is exercised through
the SRM; that is, via SRM tuning parameters.
•
Systems Management Facility (SMF)
A facility that gathers and records job accounting and other system-related
information. By creating analysis and report routines, the collected
information can be used for billing users, for analyzing workloads, and for
profiling system resource usage.
•
Interactive Storage Management Facility (ISMF)
An interactive, online facility for defining and viewing the policy of how the
Storage Management Subsystem manages auxiliary storage.
•
Time Sharing Option Extensions (TSO/E)
TSO/E provides interactive time sharing capabilities.
•
Interactive System Productivity Facility (ISPF)
Dialog manager required for interactive applications; for example ISPF/PDF,
ISMF, and IPCS sessions.
•
Interactive System Productivity Facility/Program Development Facility
(ISPF/PDF)
ISPF/PDF provides enhanced edit and browse facilities for aiding program
development and library management functions.
•
Integrated Catalog Facility (ICF)
The name of the catalog in DFP that is a functional replacement for VSAM
catalogs.
•
Interactive Problem Control System (IPCS)
An interactive, online facility used for diagnosing software failures; that is,
dump viewing.
•
Message Processing Facility (MPF)
The facility that controls console message processing and message display.
Message processing refers to message suppression, message retention, and
the use of installation-supplied exits to control message processing.
•
Global Resource Serialization (GRS)
A component of MVS designed to protect the integrity of resources,
particularly data sets on DASD volumes that are shared by two or more
systems.
22 VSE to OS/390 Migration Workbook
•
System Modification Program Extended (SMP/E)
SMP/E controls software changes to modules and macros in the operating
system, using a standard format and method that help ensure system
integrity. SMP/E is required for installation and service functions.
2.2.1.3 Supporting Products
A typical OS/390 operating system environment also includes several other, both
required and optional, system-related products.
Some of these products are described in alphabetical order below.
•
Data Facility Data Set Services (DFDSS)
DFDSS copies, moves, dumps, and restores data sets and volumes for
backup and recovery. It can be used to migrate data sets from one DASD
device to another. It is the product used to convert data to and from the
Storage Management Subsystem.
•
Data Facility Hierarchical Storage Manager (DFHSM)
DFHSM backs up, recovers, and manages space on volumes.
•
Data Facility Sort (DFSORT)
DFSORT sorts, merges, and copies data set records.
•
MVS/Data Interfile Transfer, Testing, and Operations Utility (DITTO)
DITTO is a general-purpose utility program for tape, disk, and card
input/output devices. Can be used interactively under ISPF.
•
Device Support Facilities (ICKDSF)
Device Support Facilities initializes DASD volumes and recovers data from
defective tracks. It can also be used to migrate to indexed VTOCs. (This is
included in the base OS/390 product.)
•
Resources Access Control Facility (RACF)
RACF controls access to data processing resources.
•
Resource Measurement Facility (RMF)
RMF measures and reports on the performance and availability of the
system.
•
System Display and Search Facility (SDSF)
SDSF helps authorized users monitor and control the operation of an
MVS-JES2 system. SDSF consists of online panels that provide immediate
information about jobs, queues, initiators, and active tasks.
•
TME 10 Information/Management
Implement, enforce, and automate administrative processes and policies in
your enterprise. TME 10 Information/Management offers you an integrated
platform of tools, services, and interfaces to accomplish this. In addition,
TME 10 Information/Management provides a centralized repository capable
of storing up to 400 Gigabyte of data per database on an MVS/ESA or OS/390
platform. It also integrates with many of Tivoli′s TME 10 (Tivoli Management
Environment) software products.
There are of course more system-related products available to support OS/390
installations. The ones listed above are mentioned because of their broad
applicability in many environments. Not all of those listed may have applicability
Chapter 2. Sizing the Effort 23
in your environment. Each should be researched individually for installation
applicability.
2.2.2 Subsystem Level Comparison/Affinity
Various sections in this publication deal with the VSE and OS/390 subsystems
and detail their similarities and differences. Specifically, these subsystems are:
•
DB2/VSE and DB2/MVS
•
DL/I and IMS/DB
•
CICS/VSE and CICS/ESA
•
POWER and JES
•
Telecommunications (VTAM, NCP, BTAM)
•
ICCF and TSO
Refer to these sections for specific details of subsystem level comparison/affinity
and migration issues.
2.3 What Changes Between VSE and OS/390?
The particular items discussed in this section may have some significant impact
as you enter the OS/390 environment. How it is decided to implement the
changes in these key areas will effect the amount of effort and resources that
will be required for the migration and subsequent production environment.
2.3.1 Philosophical Changes
One of the most signification philosophical changes when going from VSE to
OS/390 is that of the design points of the two operating systems. OS/390 has at
its design point a strong focus on systems management, specifically systems
availability. Thousands of lines of operating system code is dedicated to
preventing and/or reducing IPLs, system and program ABENDs and unscheduled
downtime. This may mean a big change for those VSE environments where
frequently scheduled IPLs are a regular occurrence.
2.3.1.1 Security
Customers who have developed security policies and procedures within the VSE
environment will find developing similar policies and procedures under OS/390
fairly straightforward. However, as with many of the products providing
equivalent VSE function in the OS/390 environment actual product
implementation may be different. This applies also to the security product
chosen for OS/390. OS/390 focuses on system integrity, that is, security checking
is done prior to performing any function.
Customers who have chosen to implement little or no security with VSE may find
themselves doing so with OS/390. If this is the case then policies and procedures
will have to be developed and a security package, for example RACF, chosen to
implement these policies and procedures.
24 VSE to OS/390 Migration Workbook
2.3.1.2 Automation
VSE customers who use OCCF and/or ISV products to provide console
automation functions will find enhanced function in the OS/390 environment.
Because of the availability of functions such as DFSMSrmm and DFSMShsm
consideration will have to be given to how to best implement these functions,
starting with the development of storage and media policies. ISV products also
exist in the OS/390 environment to provide additional automation capabilities.
2.3.1.3 Console Operator Interface
VSE console operators tend to have a significant amount of interaction with the
system console. This can be referred as a ′chatty′ interface. Many batch
applications depend upon operator responses to function correctly. For example,
an operator may be required to enter date information and response verification
in order for a program to continue. Such facilities are not provided in OS/390
requiring these type of applications to be redesigned.
OS/390 provides the Message Processing Facility (MPF) which controls console
message processing and message display. MPF is similar in function to VSE
OCCF.
2.3.1.4 JCL Processing
VSE JCL syntax and structure is very forgiving and flexible. Users often exploit
this capability to enhance user productivity. For example, users often
intentionally code invalid JCL statements so that they may appear on the system
console for the correct information to be entered. This, then, provides a
somewhat crude way of creating dynamic JCL decks. This capability exists
because of the manner in which VSE POWER performs JCL processing. POWER
does JCL syntax checking at job execution time. When an invalid statement is
encountered the console operator is given the opportunity to enter the correct
statement. OS/390, however, does not provide such a capability because of the
way JES is designed. With JES, JCL syntax checking is performed at job
submission time. Jobs with invalid statements are rejected at this point and,
therefore, not executed. Consideration will need to be given to POWER
jobstreams that are designed in such a manner.
2.3.1.5 Management Disciplines
Because of OS/390′s enhanced systems management capabilities, thought needs
to be given to system management, and its various disciplines, and how it will
be implemented in the OS/390 environment. OS/390 provides functions and
capabilities in each of the systems management areas. Specifically these are:
•
Change control
•
Problem control
•
Performance management
•
Capacity planning
•
Configuration management
Chapter 2. Sizing the Effort 25
2.4 Who is Affected by This Migration?
2.4.1 Job Roles and Normal Activities
The following table which lists job roles and activities is intended to link specific
activities to the appropriate job role. As such, it is also intended to act as an aid
in determining the impact of the migration project on the various I/S functions.
For example, assigning skills development to application program development
and data center operations is useful when developing the education plan for the
migration project. This will take into account the timing of who will get education
and when.
Table 2. Who′s Normal Activities are Affected?
Roles Activities
Application Program
Development
Applications End-Users *
Auditor *
Data Center Operations * * *
1 2 3 4 5 6 7 8 9 10 11
* * * *
Help Desk *
Management * * *
Network Support Staff *
Performance Analyst *
Production Control * *
Quality and Testing *
RJE End-Users & Operations * *
Systems Programmers * * * * *
Activities
1. Procedures
•
Run Book
2. Standards
•
Coding
•
New Programs
•
Naming Conventions
3. Skills Development
4. New Tools - Application Development
26 VSE to OS/390 Migration Workbook
5. Security
6. Performance
7. Capacity Planning
8. Testing
9. Backup/Recovery
10. Disaster Planning
11. Project Plan Development
2.5 Approaches to Migration
2.5.1 Disclaimer
For the purpose of providing a more effective guide the mass migration method
was adopted as an approach or strategy in migrating. The reasons for the
choice are numerous, but they include:
•
Mass migration provides a project duration that is definable. This allows for
a more accurate migration project cost estimation and sizing.
•
In today′s integrated I/T environments it is more difficult to define discrete
kernels. For example, many applications currently have integrated facilities
that support the integrated nature of many business functions. This can be
found in applications such as Enterprise Resource Planning (ERP). The sales
forecasting function, for example, shares information with certain accounting
functions. This makes it difficult to separate or define discrete kernels to
migrate.
2.5.2 OS/390 Conversion and Production Implementation Strategies
There are two different strategies (or approaches) you can use in migrating
applications to OS/390. They are: (1.) the kernel/progressive approach, and (2.)
the single switchover - mass application migration approach. The decision as to
which approach to take will have a definite impact on the project, particularly on
the manner in which resources are deployed Additionally, the approach decision
will, in most cases, have the greatest impact on sizing the project. The following
discussion presents these two approaches.
2.5.2.1 Kernel/Progressive Approach
Here, an installation defines discrete application sets called kernels2. The
conversion team uses progressive conversions of each defined kernel, placing a
converted kernel into OS/390 production on a ″when ready,″ serial basis. After a
kernel is cutover
converted, and implemented on OS/390. This process goes on until all
applications (kernels) are cutover to the OS/390 environment. Some points to
make about the ″kernel approach″:
3
to OS/390 production, the next defined kernel is worked on,
2
A kernel is usually defined as all the programs and files that are needed to support a business application; for example, the
payroll system.
3
″Cutover″ is a term generally associated with the kernel approach. It is a word used to describe the completed conversion of
a kernel to OS/390; that is, the time when the kernel is placed in OS/390 production.
Chapter 2. Sizing the Effort
27
•
OS/390 production is realized at an early time in the migration.
When the first kernel is completed it is cut over to OS/390 production. This
could be at a very early time in the migration thus providing early OS/390
feedback.
However, this may not be the advantage it appears to be. Dual OS/390 and
VSE production environments exist as VSE production (of unconverted
kernels) is required. This can be a disadvantage operationally as well as
cause problems in resource (I/O) scheduling.
Many times, because of the dual production environment, application bridges
must be built (special procedures) to allow data and catalogs to be
alternately processed by the OS/390 and then the VSE system. Also,
maintenance and development activities must be performed on both
systems, thus potentially slowing down the overall migration.
•
Dedicated and rotating conversion teams are usually involved.
The system programmer contingent of the conversion team is mainly
dedicated to the migration effort. However, application programmers very
often are involved in converting their own applications with this approach.
Rotating application programmers in and out of migration efforts can be
detrimental to development activities. It can also slow down overall
effectiveness of the migration as additional time and training takes place
each time new personnel are assigned to the conversion team.
•
No definite project-end date is likely to be associated with this approach.
Many times with the kernel approach, the conversion effort ″runs out of
steam″ before the project is completed. This happens after the important
bread-and-butter kernels are cutover. Then, priorities often change and the
lesser visible applications stay operational under VSE for long periods of
time. This becomes expensive to a company as additional resources are
involved in maintaining two operating systems and managing two production
environments. This is why the phrase ″it took us 18 months or two years″ is
many times muttered about a VSE to OS/390 migration.
2.5.2.2 Single Switchover - Mass Application Migration Approach
In the single switchover - mass application migration approach, all applications
are cutover to OS/390 production at the same time. (This time is often referred to
as the ″switchover″.) As applications are converted and successfully tested
under OS/390, they are ″shelved″ until switchover.
operations stop in entirety and OS/390 operations commence. A comprehensive
conversion aid tool (that is, product) is almost always used with this approach.
Some of the advantages to the single switchover - mass application migration
approach are:
•
OS/390 operations are deferred until project completion.
The advantage of this is that there is no dual operations. Operators run VSE
production until the conversion is over. Also, there are no special ″bridges″
that have to be built between the two systems since there is no need to
move production data back and forth between VSE and OS/390 systems.
•
A dedicated conversion team is usually associated with this approach.
4
At switchover, VSE
4
Maintenance updates can continue to be made to these ″converted″ VSE applications. The changes should be made to the VSE
source programs. Later these programs will have to be cycled back through the conversion process.
28 VSE to OS/390 Migration Workbook
A conversion team is normally chosen that will be dedicated to the project
until its end. Included with this team will be (perhaps) two application
programmers. Naturally, the number varies with the size and complexity of
the project. The team is responsible for converting all VSE applications. (As
previously mentioned a program conversion aid is normally used with this
approach.) Application programmers, not part of the project team, are not
disrupted during conversion work. They can continue to perform VSE
application development and maintenance activities.
•
The migration project has a visible end.
Because the project is an important one (obviously it wouldn′t have been
undertaken otherwise), and since no applications are cutover until all
applications are ready, the conversion effort will not lose steam. Priorities
will remain very high to complete application conversions, and to implement
OS/390 as the production system. Typically, the duration of realizing total
OS/390 production with this type of approach, is significantly less, (even up
to 50 percent less in duration), then with the kernel approach.
•
Staff is better prepared, trained, and experienced with OS/390 prior to
production operations.
OS/390 skills are developed during all conversion activities; that is,
conversion activities are performed on the OS/390 system. All learning and
hands-on activities are accomplished on a non-production OS/390 system,
thereby lessening future production exposures. Since there is no dual
operations of both VSE and OS/390, operators don′t get confused as to which
system they′re operating on.
2.5.3 VM/ESA Guest Support in Your VSE to OS/390 Migration
VM/ESA′s Guest Support has long been an important part of many VSE and
MVS(OS/390) customers operating environments. As you approach migrating
VSE to OS/390 you should consider the important roll VM/ESA plays in making
the job easier and more cost effective current and long term.
If you already have VM/ESA and you use VM/ESA′s Guest Support for running
your VSE system(s) then you already know the value VM/ESA delivers in this
environment. In migrating VSE to OS/390, VM/ESA continues to play an important
roll delivering as much or more value to your new OS/390 environment. If you
are not familiar with VM/ESA a more complete description of how to implement
multiple VSE and OS/390 images can be found in chapter 26 of this publication.
Chapter 26 also discusses the benefits and consequences of using VM/ESA and
LPAR to support multiple images both during and after the migration. For more
information on VM/ESA obtain a copy of
GC24-5745 and
VM/ESA V2R1.0 Running Guest Operations
VM/ESA V2R2.0 General Information
2.5.4 Staffing Strategies
2.5.4.1 In-House Staff
There are two main strategies involved when deciding how to staff the migration
project. These typically are using existing in-house staff or hiring outside
consultants. Some considerations when using in-house staff are:
,
, SC24-5755.
Chapter 2. Sizing the Effort 29
•
Staff availability
Deciding to use in-house staff as part of the migration makes it difficult to
perform regular job responsibilities while they are involved with the
migration project. This is particularly true of applications staff as current
application development and maintenance has to be put on hold.
•
Staff Skills
When using in-house staff basically the same education requirements exist
as those for outside consultants. These requirements are usually satisfied
through in-house or classroom education. However, using in-house staff for
the migration project also develops migration and conversion skills. These
skills, such as training on the migration method and use of any
migration/conversion tools, may not be of benefit after the migration project.
This may provide a reason to acquire them from an outside source.
2.5.4.2 Outside Consultants
The alternative to using in-house staff is outside consultants. As with in-house
staff, using outside consultants has its considerations. Chiefly this is the fact
that outside consultants already bring with them expert levels of skill and
experience. One of the main benefits of exploiting this skill and experience is
that it tends to shorten the duration of the project. Utilizing outside consultants
also frees existing in-house staff to perform their regular job duties. It may also
be desired to hire new system personnel that already possess OS/390 (MVS)
skills. Lastly, one of the big considerations is the amount of financial resources
that will be required to use outside consultants. The forecasted project length
and number of consultants needed are obviously the major factors. There are
consulting firms that specialize in migrations such as this. While IBM in no way
endorses or warrants their work performance, listed below are a few of the firms
that specialize in migrations:
•
Automated Migration Services
•
CAP-GEMINI
•
IBM Global Services
•
MHT Services
2.5.5 Conversion Tools
There are a number of conversion tools available to assist in the migration
project. Some of the considerations when selecting conversion tools are:
•
Cost
•
Education requirements
•
Technical support
•
Effectiveness
•
Flexibility
Listed are a few of these tools. A chapter in this publication on conversion tools
provides detailed information about these tools.
•
Program Translators (IBM CCCA)
•
Emulation - (Computer Associates CA-DUO)
•
Program Source Recovery - (Source Recovery)
30 VSE to OS/390 Migration Workbook
•
Mass conversion - (Cortex-MS)
•
Program inventory - (IBM OPTI-AUDIT)
2.6 Educational Requirements
2.6.1 Introduction
The educational requirements for the migration project will generally take the
form of developing OS/390 skills; that is, JCL and conversion techniques. With
the latter, strategies will have to be developed to convert things such as VSE
program source and JCL to OS/390. Education can take on the form of
classroom, self-study, on the job training, on-site, or feet to the fire. The latter
being the most undesirable. Consideration should be given to issues such as
the availability, cost, length and appropriateness of each. For example,
classroom course schedules need to be consulted to determine whether they
coincide with project timetables. Cost issues of travel and living expenses need
to be also considered. When considering outside consultants for in-house
training, they can often tailor classes to specific requirements allowing you to
get the most out of this type of education. A list of helpful courses and how to
get more course information has been included in Appendix A, “Education
Information” on page 535 in this publication.
Highlighted are some of the educational requirements for the key functional
areas.
2.6.1.1 System Programming
Education for systems programming personnel will generally include OS/390
installation and tailoring, problem determination and maintenance. Similar
education will be required for those with subsystem (for example, CICS or DB/2)
responsibility. Another source of education is the hands-on education that occurs
when OS/390 is initially installed and before it is put to any kind of productive
use. Such hands-on experience has often proven invaluable.
2.6.1.2 Application Programming
Application programming resources will most likely focus on JCL and program
development tools for the OS/390 environment. Although there is a high degree
of affinity/compatibility between the various programming languages in VSE and
OS/390, some education will be needed to understand the functional and
compatibility differences that do exist.
2.6.1.3 Operations
OS/390 console operations will be the main education requirement for the
operations staff. Courses on OS/390 and JES commands will be the most
crucial. Consideration should also be given to education on any scheduling,
console automation and/or systems management products that will be used.
Operations personnel will also need to be updated on any new procedural
and/or process changes.
Chapter 2. Sizing the Effort 31
2.7 Scope of Work and Challenges
When converting VSE applications to OS/390 several tasks have to be performed.
The following sections describe the most important work items involved and
some of the challenges which can be encountered during the execution of these
tasks:
•
Application inventory
•
Program conversion
•
JCL conversion
•
File migration
•
Automated operations setup
•
Project management
2.7.1 Application Inventory
For a VSE to OS/390 conversion, the application inventory is nearly always
underestimated in both duration and labor.
The main application inventory activities include:
•
Determining what VSE applications must be converted to OS/390
•
Retrieving and collecting the current production version of each application
item
•
Transferring those items to the conversion input libraries on the OS/390
system
•
Verifying that the transferred inventory has no missing or unused items
One of the challenges when establishing an application inventory for a VSE to
OS/390 conversion is that the application programs must be precisely matched
with the JCL streams (for batch applications) and CICS tables (for online
applications) to be converted. This is because of the considerable blending of
application code and VSE JCL streams (see JCL conversion below). Building
these ″work units″ adds work at project start, but it becomes a significant
deliverable at project completion, when the new OS/390 application inventory
used in production is perfectly defined and centrally stored, with no missing or
unused items.
Application inventory tools are used to identify missing and unused items.
Missing items must be retrieved or recoded (if possible from a previous version),
regression tested under VSE, and used in production under VSE before being
converted to OS/390. Unused items must be eliminated or the item using them
must be added to the application inventory. The identification, collection and
transfer of the application inventory are repeated until the verification identifies
no missing or unused items.
The application inventory often leads to a re-organization of the VSE storage.
Unique centralized libraries are defined, allocated and used to store the current
production version of any application item. Obsolete or duplicate versions are
moved to non-production archive libraries.
The application inventory may last two to four months and represent 10 to 15%
of the total application conversion effort.
32 VSE to OS/390 Migration Workbook
2.7.2 Program Conversion
The conversion of VSE application code to OS/390 is often (but falsely) believed
to be the center, most challenging, most labor consuming and most critical part
of the conversion, but it is not. With few exceptions (see VSE positioning), it is a
simple code modification which does not change program logic, and can nearly
always be applied with a simple two-pass translation tool.
VSE COBOL code must also be upgraded to the latest (COBOL for OS/390)
compiler level. But this upgrade too, requires no program logic change, and can
be applied with a simple two-pass translation tool.
In technical terms, these OS/390 and COBOL upgrade modifications are simple
code ″re-engineering″ which fall into one of the following categories:
•
Syntax modification: replace a syntax pattern on one or several statements
by a similar OS/390 compatible syntax pattern.
•
Device independence: eliminate block sizes and other device dependencies
from the converted code. Under OS/390, device dependent file attributes are
either coded in the JCL or determined by the system managed storage
(DFSMS) components of OS/390.
•
Elimination of VSE-only features: features such as COMREG, UPSI, DATE and
USER can be replaced by calls to user-developed ad-hoc subroutines that
simulate the feature under OS/390. Some other VSE-only features, such as
the usage of VSE system macros and VSE supervisor calls from Assembler
may be more complex to convert.
The difficulty level when converting COBOL code to OS/390 is fairly similar from
one VSE installation to another, but it is not so with Assembler. The conversion
of Assembler code can be fairly easy, if VSE standard application coding was
used, or very complex, if system-dependent non-standard coding was used. In
some cases, the conversion of an Assembler program may start with a complete
redesign, in which one must identify what function or feature will still be
performed by the program, and what function or feature will be handled by the
OS/390 system software and utilities. This leads to partial or complete rewrite.
Fortunately, those situations are becoming rarer, as VSE installations
progressively eliminate their non-standard and system-dependent coding
practices.
The conversion of VSE code to OS/390 and COBOL code upgrade may last two to
four months and represent 10 to 15% of the total application conversion effort,
unless there is a significant inventory of technical non-standard Assembler
programming.
2.7.3 JCL Conversion
JCL conversion is nearly always underestimated in both duration and labor. It is
the central, most challenging, most labor consuming and most critical part of the
VSE to OS/390 conversion.
VSE JCL streams alone are not sufficient to define the flow of the associated job
streams. The sequence of steps is evident, but the file references are not always
visible. Some are hidden in the standard or partitioned labels. Some are passed
and reused from one step to the next. File reference statements (TLBL and
DLBL) coded in the JCL are not necessarily used in VSE; the program might not
open that file. It is accepted practice in VSE and doesn′t trigger any syntax or
execution error. The file open mode (input, output) is not visible from the VSE
Chapter 2. Sizing the Effort 33
JCL: it is hidden inside the code (main or sub-program) associated with the step.
Some of the file attributes coded in the VSE JCL are superseded by the disk or
tape manager: the proper file attributes must be retrieved in the tape or disk
manager′s catalog or in the VTOC listings. In short, it is not possible to
understand the flowchart of the job stream without retrieving and analyzing the
file opening inside programs and sub-programs, and without collecting in
formation from standard labels, partitioned labels, the VSE catalogs and VTOC
listings.
Contrary to VSE, OS/390 JCL streams generally reflect exactly the flowchart of
the job streams. All files opened within a step have a file reference (DD
statement) coded in the JCL. There are no unused file references. The mode of
open (input, output, extend) of the file is coded in the OS/390 JCL (disposition).
Therefore, when converting VSE JCL streams to OS/390, whether manually or
automatically, ″reverse engineering″ techniques are first used to rebuild the job
stream flowcharts from:
•
VSE JCL streams
•
program conversion (block sizes, device related information, open mode)
•
standard and partitioned labels
•
VSE catalogs and VTOC listings
This is the most complicated part of the JCL conversion, not only because it
requires you to collect and coordinate file reference information coming from
different origins, but also because understanding the application job stream
requires:
1
Understanding of application data flows (from enterprise-wide
cross-references between files and steps)
2
Classification of data flows (that is, files) according to data life cycles:
•
Permanent
•
Handoff
•
Passed temporary file
•
Work (step-level temporary file)
•
Backup
•
External input or output
•
Edition or report
3
Definition and implementation of file management strategies based on the
file classification, for example:
•
Usage of GDG for permanent, handoff or backup sequential files
•
Cataloging of passed temporary files and their deletion after last usage
•
Usage of OS/390 ″&&″ work files for step-level temporary files
•
and so on
4
Generation of OS/390 JCL, DFSMS constructs and VSE to OS/390 file
migration procedures reflecting the understanding of data flows and their
classification.
To illustrate the complexity of VSE JCL conversion and its underlying
identification and understanding of data flows, many VSE labels and even
physical DASD locations are shared by ″VSE files″ which might (although not
always) have the same record length or record layout, but are true separate data
34 VSE to OS/390 Migration Workbook
flows. For example: You can have hundreds of files with the same name, for
example ″WORK1″. WORK1 can exist in different jobs. Most of the time the
WORK1 files will be different from and unrelated to each other. You can however
have JobA use a file named WORK1 and JobB running at the same time and
also using a file called WORK1. JobA WORK1 gets passed to Job3. Job3 runs
and uses WORK1 at a later time. WORK1 in JobB is local use only. The issue is
to distinguish the differences between the WORK1 file in JobA and JobC. If these
files become intermixed or used by the wrong Job it can be complicated to sort
out. There is no data exchanged through those file references. Only analyzing
the complete file/step cross-references with associated open modes and
attributes allows identifying these situations. When migrating to OS/390, it is
critical to identify those data flows as separate OS/390 files. In the worst case
scenario, it would create execution or JCL errors. In the best case, it would
create unwanted contentions, when concurrent jobs try to access the ″same″ file:
OS/390 will allow more job multi-threading than VSE, if contentions are not an
issue.
Once the steps above are completed, ″Forward engineering″ techniques are
used to generate OS/390 JCL streams that match the application job streams
while complying with new OS/390 standards and naming conventions. This is the
easiest part of the VSE to OS/390 JCL conversion.
The conversion of VSE JCL to OS/390 may last three to five months and
represent 40 to 50% of the total application conversion effort.
2.7.4 File Migration
File migration can only be as good as JCL conversion. This is because the most
challenging parts of the file migration, identifying and classifying all files
according to their life, and the tape to disk device migration, are for the most
part a by-product of JCL conversion.
VSE files and databases can either be migrated ″in-place″ or by copy. Both
techniques can be combined in the overall VSE to OS/390 file migration strategy.
In-place
operations outage). Entire VSE data centers with extremely large application
data pools have been migrated to OS/390 in an hour. But by altering the VSE
production environment, it prevents instant return to VSE. It also complicates,
limits or even prevents the implementation of DFSMS, at least at start: natural
production cycles may be used to replace the sequential files migrated in place
by new DFSMS-controlled versions.
File copy takes longer, but with appropriate configuration and planning, large
VSE installations are routinely migrated in mass in only four to eight hours. If the
VSE disk space is unaltered by the file migration, instant VSE fallback is
possible. This technique facilitates full size DFSMS implementation from the very
start of OS/390 operations.
Developing a file migration strategy and associated procedures (VSE and OS/390
file migration JCL streams) is not very difficult, technically speaking. Migrating
VSE production files to OS/390 for conversion regression tests allows rehearsing
and finalizing the procedures that will later on be used for the actual file
migration and operations switchover.
migration is by far the quickest, therefore the less disruptive (very short
Chapter 2. Sizing the Effort 35
The main challenge is the identification and classification of files for the
migration. All files that will be used as input to a job after the switchover to
OS/390 operations must be migrated. Files recreated by the first OS/390
production cycles do not need to be migrated, and are better off not being
migrated (at least temporary files, cataloged or not).
The task of selecting files for the migration to OS/390 is easier for those files
accessed by online applications. This is because they are in relatively small
numbers (150 to 300), permanently allocated, often uniquely identified (for
example through standard labels), and because their list is fairly stable over
time. CICS tables list all those files, and more. The only challenge with online
applications is to identify and eliminate obsolete CICS table entries.
The real selection challenge is with batch applications. The list of all files
(separate data flows) accessed by batch applications is typically in the hundreds.
These files are usually not monitored or kept current. Identification of their use is
complicated by reuse of the same VSE file name or even disk space for
completely separate data flows. As explained in the JCL conversion section
above, it takes a global enterprise-wide view of the step/file cross references to:
•
Truly understand the VSE data flows,
•
Separate and identify each of them,
•
Classify them according to their life cycle (permanent, handoff, backup,
work),
•
Apply an appropriate OS/390 migration strategy to each one.
Device migration is the second file migration challenge. Many VSE installations
tend to be tape (not disk) oriented. OS/390 should be disk and DFSMS oriented,
not tape oriented. This means that:
•
VSE disk files are migrated to OS/390 disk files
•
Most VSE non-backup tape files are migrated to OS/390 disk files, with the
exception of external (shipped) input or output tapes
•
VSE backup tape files created within application job streams may be
migrated to OS/390 tape files. But with DFSMS, they may be created under
OS/390 on disk by the OS/390 job stream and copied to tape ″out-of-sync″
with job execution by HSM in a technique called ″disk buffering″ (see OS/390
standards).
It takes a prolonged simulated production test to assess the match of the new
OS/390 JCL streams, HSM archival strategies and DFSMS constructs with the
available disk space. Hardware configuration constraints and on-going VSE
operations do not always allow getting a good feel for the performance of future
OS/390 native operations.
The differences in device utilization strategies between VSE and OS/390 greatly
influence the file migration. Those differences are defined by the OS/390
standards′ decisions made while converting the JCL.
The VSE to OS/390 file migration is developed progressively over a period of
three to five months, while performing the regression tests, and assuming that
file identification and device migration are accounted for with JCL conversion, it
represents only 5 to 10% of the total application conversion effort.
36 VSE to OS/390 Migration Workbook
2.7.5 Project Management
As with application inventory or JCL conversion, the management of a VSE to
OS/390 conversion project is nearly always underestimated. The VSE to OS/390
conversion is one of the rare projects that require a coordinated effort from each
of the three data processing departments: applications, technical support and
operations. When it comes to taking inventory and understanding all the
individual items that make up a complete VSE data center, no one has all the
answers. Many global answers are obtained by consolidating smaller
complementary answers. In fact, in some instances, the participation of the
end-users themselves is required.
This is why a VSE to OS/390 conversion must be commissioned, sponsored, and
supported by executive management. The Project Manager must be given his
overall mission statement directly from the top management, and must be given
authority over applications, operations and technical support for this project.
One of the challenges of managing a VSE to OS/390 conversion is project
planning. The conversion of VSE applications (JCL, programs and files),
associated testing and implementation (switchover) are complex in themselves.
It may involve 10 to 20 people. The project plan averages 150 tasks and
sub-tasks, most of them linked through dependencies. It becomes even more
complex, when this plan must be coordinated with the detailed OS/390 software
installation and implementation plan, the staff education plan, the OEM (non IBM)
software installation and implementation plan, and the parallel application
maintenance and development plan. The data center doesn′t come to a stand
still while the VSE to OS/390 migration takes place.
Finally, resource management, both human and configuration-wise, can be a real
challenge. Hiring conversion experts to handle parts of this one-time project can
be part of the solution for human resources constraints. The project still requires
a significant internal human resource investment to handle a number of activities
that are best left to the data center personnel itself. This is true for application
inventory (sorting out duplicate program versions and so on), OS/390 standards
decision that define the key operating processes (naming conventions, device
migration, and so on), and regression testing (test plan and scripts and so on).
Project management represents 10 to 15% of the total application conversion
effort.
2.7.6 Automated Operations
In recent years, the setup (population) and implementation of a job scheduler
and report manager have become a full part of the VSE to OS/390 migration.
Regardless of your VSE implementation of a job scheduler and report manager,
in OS/390 they will be used for the entire production, all jobs, all reports.
Identifying and carrying over the report management instructions from the VSE
JCL (destination, number of copies, FCB, and so on) to the OS/390 report
manager is not very challenging. Neither is carrying over existing job scheduling
or report management instructions from a VSE to an OS/390 product.
The real challenge is to learn not only how the OS/390 product works, but also
how to use it. The OS/390 basic education provided by vendors of OS/390 job
schedulers and report managers is just that: ″basic″. Even with hands-on
exercises, it doesn′t prepare the production control staff who attend it to design
and define on their own how they will use the product to implement operation
Chapter 2. Sizing the Effort 37
procedures. Most will simply try to reproduce with the new OS/390 product what
they were doing in VSE with or without assistance of a product. The challenge is
to:
•
Understand how OS/390 works,
•
Understand how the OS/390 job scheduler or report manager is best used,
•
Define specific local implementation rules and guidelines (standards), and
finally
•
Convert the existing VSE instructions and ways of doing things from VSE to
OS/390.
An additional complication is that it is difficult to test the population of those
products (at least for the report manager) in simulated production mode without
disrupting or confusing the end-users. Test versions of application reports
created under OS/390 cannot be sent to their future recipients using the OS/390
report manager without risking that they be taken as current VSE generated
production versions. It is feasible to verify most of the automated daily job
scheduling by simply running the OS/390 job scheduler in simulated production
mode, although it is never easy to reproduce all actual production size
executions and event triggered executions. But it becomes a real challenge to
mimic lower frequencies such as weekly, biweekly, and monthly, especially when
they are integrated to daily production. In any case, if those products are to be
used in production under OS/390, they must be used when regression testing the
converted applications.
It is atypical that the OS/390 job scheduler and report manager will be:
•
Populated once, just after the vendor′s basic education class
•
Changed partly or totally a few months later, after regression testing has
identified a number of conceptual or implementation flaws
•
Adjusted one more time after switchover, once in OS/390.
This is because production control personnel are often ill prepared to perform
this migration. Participation of hired consultants, experts with the OS/390 product
implementation or an application analyst or technical support staff may be part
of the solution.
The setup of a job scheduler and report manager may last three to four months
and represent 10 to 15% of the total application conversion effort.
2.8 Cost Considerations
It is often thought that OS/390 will require more hardware and staff resources.
While OS/390 may, in some cases, require more overhead and hence CPU, per
unit of work, typically greater system throughput is achieved over that of the VSE
environment. Due to enhanced systems management and automation
capabilities it has been found that OS/390 staff requirements actually do not
increase compared to VSE. In cases where staff increases have been seen, it
has usually resulted from growth in system requirements. That is, application
and end-user growth requirements has spawned the need for additional system
resources. This need for additional system resources, then, sometimes requires
additional human resource support.
While migration project cost projections will vary for each environment and
customer, there are some basic cost elements that are common to all projects.
38 VSE to OS/390 Migration Workbook
The purpose here is not to predict or estimate project costs but to identify major
cost elements and any relevant financial resource considerations.
•
Cost/Benefit Requirements
Reasonable and predictable timeframe
Reduced internal staff participation focused on learning OS/390
No delay/postponement of development and maintenance
Controlled costs turned into investment
Low risk
•
Migration project cost elements
⇒ General
- Education
•
Course fees
•
Travel & living expenses
- Consultants
- Internal human resources (chargebacks)
•
Project manager
•
Team members
⇒ Hardware
- Incremental/interim configuration to support migration
•
LPAR (CTCs, channels, device channel adapters, EMIF)
•
Separate footprint (w/ additional software licenses)
- Final configuration
⇒ Software
- Incremental/interim configuration to support migration
•
VM
•
Conversion Tools
•
VSE & OS/390 licenses
- Final OS/390 configuration (including optional products & ISV
products)
2.9 OS/390 Documentation Resources
OS/390 documentation resources should be consulted as early on in the project
as possible. This should be done in order to get an understanding of some of the
issues associated with installing and implementing the OS/390 environment. For
example, it will be necessary to understand the various OS/390 delivery
mechanisms (that is, CBIPO, ServerPAC, SystemPac) in order to determine the
one most appropriate based upon the given requirements/environment.
2.9.1 Introduction References
•
Key CD-ROM Collections (Bookshelves) for OS/390
•
General Information Manual (Introduction and Release Guide)
Chapter 2. Sizing the Effort 39
2.9.2 Key Documents and Other References
•
OS/390 V2R5 Planning and Installation
•
CBIPO (System Pak) Custom Built Offerings Planning
•
CICS Up and Running
•
DB2 Release Guide
2.9.3 Web UR L
http://WWW.S390.IBM.COM/OS390/
, SK2T-2484
40 VSE to OS/390 Migration Workbook
Chapter 3. Developing the Plan
This chapter discusses the following topics:
3.1, Overview
3.2, Plan Components
3.3, Progressive versus Mass Conversion
3.4, Plan Examples
3.1 Overview
3.1.1 References
These materials provide sources of supplemental information for this chapter.
•
MVS Migration System - Planning Guide
process for the MVS-MS. This guide is for the people who are responsible for
planning and scheduling the migration and fitting the conversion that
MVS-MS performs into the migration schedule. It is the basic book for the
project manager and every technical person involved in planning and
running both the migration and the conversion.
•
MVS Migration System - General Information
overview of the IBM MVS Migration System and is for the people at an
installation who will decide if MVS-MS will work for a particular environment.
It describes both the advantages and limitations of MVS-MS, presents
information on how MVS-MS works, and identifies some specific early
planning concerns.
•
MVS Migration System - Planning Chart
conversion tasks and subtasks relative to their duration and relationship to
each other.
, SB11-8077 describes the planning
, GB11-8074 provides an
, SB11-8090 displays the standard
3.1.2 Recommendations
The following are recommendations for your migration that are not project phase
specific or apply to all phases of migration.
3.1.2.1 Project Management
In some cases it may make sense to hire contractors, temporary personnel or a
service provider to perform tasks that will only be performed once and do not
provide long term payback to the installation. These one time tasks may include
project management, specific conversion activities and use of project specific
tools. There are many tasks to consider during a migration. Careful
consideration should be given to knowing the skills that are available to the
project, the requirements for systems programming, other projects that are
planned or in progress, and how augmenting these skills and personnel may or
may not make sense.
Copyright IBM Corp. 1998 41
3.1.2.2 Take Advantage Of Conversion Tools and Automation
Executing a migration with a mass conversion tool and automated processes can
reduce both the time and people required to migrate from VSE to OS/390. Where
it is not a large task to convert three programs and two strings of JCL, it is a
large and difficult task to increase the scope by one thousand and perform the
same conversion.
The automation provided by the use of a mass conversion tool is unique. After
an extensive period of analysis, which includes running both pilot conversions
and dummy conversions, you can, in a final mass conversion, convert all of your
VSE applications to MVS in a single automated process.
3.1.2.3 Migration Plan - Guide and Outline
Creating a migration plan involves analyzing what a migration requires and
developing a plan to customize the general process to your particular
installation. Developing a comprehensive and detailed migration plan is
important to the success of a migration.
The type of conversion method directly affects the content of your plan. For this
guide we have chosen to follow a mass conversion method using the Cortex MS
processes. Chapter 3, Developing the Conversion Plan, of the
provides information on how to develop a migration plan where a mass
Guide
conversion method is used. Use it as a guide to develop a plan that is specific
to your site.
MVS-MS Planning
Appendix A of the
conversion workbook that you can use to write your conversion plan. The model
workbook contains a checklist and some questions to help you generate ideas
on what to include in your conversion plan.
3.4, “Plan Examples” on page 53 also provides a sample conversion project
plan.
MVS MS Planning Guide
provides the outline of a sample
3.1.2.4 Two Phase Approach
The migration project can be broken into a few logical pieces that may help its
execution. One method that has been successful is to begin with a mini project,
phase 1, to identify and resolve your inventory. Proceeding with a known
inventory will allow more precise pricing. The pricing for a conversion effort is
based on inventory. It also provides information about the effort that may be
required to recreate source materials. There are tools and service providers that
perform these services. The second phase is the actual implementation.
The Phase 1 output is also a standalone deliverable that can be very useful for
Year 2000 preparation.
3.1.2.5 Conversion Method
There are two basic approaches to the migration. One approach, referred to as
the kernel approach, converts a single application or subsystem at a time. The
other, called mass migration, converts all applications, the entire system, at the
same time. The method or approach used will dictate the elements of the project
plan. This chapter will explore the major considerations of using mass migration
as a conversion method and as a conversion tool.
Two tools support or implement the mass migration approach. One of these
tools, the IBM MVS-Migration System (MVS-MS), was previously licensed from
42 VSE to OS/390 Migration Workbook
SISRO and is no longer available, but deserves mentioning. The product
documentation is helpful in that it provides a very good project plan and
description of the mass migration approach. When sold through SISRO, this tool
is know as CORTEX-Migration System (CORTEX-MS) and currently is available.
Although there have been many changes to the MVS and VSE operating systems
and improvements to the conversion tool, the methodology of planning and
execution of the conversion has not changed significantly.
Choosing the appropriate conversion and production implementation strategy is
a very crucial decision. It is important to choose the right strategy and build a
corresponding plan. The mass migration method can provide a project that is
definable and allows for more accurate project cost estimation and sizing. It can
be the most effective strategy in light of today′s I/T structure where integrated
applications are closely tied to the integrated functions of business operations.
3.1.2.6 Project Staffing
It is recommended to use hired conversion specialists to handle the planning
and organization of the overall OS/390 migration, and the conversion of the VSE
applications to OS/390.
The VSE staff and hired conversion specialists work as a single project team.
Each bring their own skills to the project and share the project responsibilities as
follows:
3.1.2.7 Librarian
The librarian helps the project manager follow the migration by recording
events, collecting information about the progress of the migration, drawing up
checklists, and maintaining tables of problems, solutions, and programming
elements affected. The tasks and responsibilities of the librarian include:
•
Controlling the production and updating of the migration workbook
•
Collecting information on the VSE source material
•
Recording migration events
•
Collecting information on program and JCL conversion, and conversion
problems and solutions
3.1.2.8 Migration Responsibilities
The
hired conversion specialists
•
OS/390 applications and operations support
•
OS/390 installation and implementation
•
VSE to OS/390 conversion tools
•
VSE to OS/390 conversion requirements and solutions
•
OS/390 migration planning and project management
VSE staff
The
•
Existing VSE operations
•
Existing VSE applications
•
Existing OS/390 applications (in case of pre-existing dual VSE and OS/390
is experienced with:
operations)
are typically skilled and experienced with:
Chapter 3. Developing the Plan 43
The
hired conversion specialists
can be deployed for converting the in-house
developed applications, and leading the overall migration effort, including:
•
Following the migration methodology and the project plan
•
Identifying and addressing the conversion requirements
•
Converting the VSE applications to OS/390
•
Design and delivery of a state-of-the-art standardized OS/390 environment
VSE staff
The
•
The new OS/390 HW/SW configuration
•
The VSE application inventory
•
Regression testing the converted applications
•
OS/390 migration activity outside the conversion of VSE application code,
is mainly responsible for:
JCL or files
3.1.2.9 Migration Assignments
The
hired conversion specialists
conversion tasks:
•
Manage the overall migration project
•
Manage their own team and responsibilities
•
Provide technical leadership, including project planning
•
Receive and validate the application inventory
•
Develop the conversion specifications
•
Customize the conversion tools to local requirements
•
Develop new conversion tools (if applicable)
•
Perform manual conversion activities, when automation is not possible or not
cost efficient
•
Perform automated mass conversions
•
Assist with setup of OS/390 automated operations tools
•
Participate in online applications tests
•
Participate in batch applications tests
•
Participate in applications switchover to OS/390
•
Support initial OS/390 operations
are typically assigned the following application
VSE staff
The
•
Manage their own team and responsibilities
•
Provide office space and project support tools
•
Participate in project planning
•
Receive OS/390 basic education
•
Provide and install OS/390 HW/SW resources
•
Operate the OS/390 environment
•
Design and implement security
•
Migrate the CICS application tables, and the network
•
Collect and supply the application inventory
•
Assist with the conversion specifications
•
Participate in VSE positioning activities, when automation is not possible or
not cost efficient
•
Install, setup and operate OS/390 automated operations tools
•
Provide, install and test the OS/390 version of purchased applications
•
Modify all interfacing systems (PC-LANs, RJE, NJE, ...) to reflect the OS/390
migration
•
Perform online applications tests
•
Perform batch applications tests
•
Participate in applications switchover to OS/390
•
Run and support initial OS/390 operations
44 VSE to OS/390 Migration Workbook
can be assigned the following application conversion tasks:
3.2 Plan Components
3.2.1 Appro a ch
For the purposes of providing more specific guidance for conversion projects, an
approach to the migration had to be determined. This is also true for the
migration effort itself, an approach must be adopted. In these discussions, we
will describe the environment associated with using the Mass Conversion
methods and tools.
3.2.2 Team
Before the actual project plan is developed, thought needs to be given to the
project/migration team and the functions, responsibilities and composition of this
team. There are many different ways to organize a migration team, the group of
people responsible for planning and executing the migration project. A
recommended organization for the migration team (see Figure 5) consists of the
following people:
•
A project manager, who is responsible for the migration procedure as a
whole - general specifications, planning, coordination, and follow-up.
•
Two systems or applications programmers, or one from each area, who draw
up detailed migration specifications, install and customize any mass
migration/conversion tools.
•
Two operations people to take charge of conversion testing.
•
A librarian to help control and track the migration activity.
┌───────────────────┐
│ Project Manager │
└─────────┬─────────┘
│
┌───────────────────────┼────────────────────┐
│││
│││
┌───────┴───────┐ ┌─────────┴─────┐ ┌───────┴───────┐
│ Systems/Apps │ │ │ │ │
│ programmers │ │ Operations │ │ Librarian │
│ (2 people) │ │ (2 people) │ │ │
└───────────────┘ └───────────────┘ └───────────────┘
Figure 5. Migration Team
The migration team should include people with the following knowledge or skills:
•
Some knowledge of the concepts and facilities of the OS/390 system
•
Knowledge of the current VSE environment and the applications to be
converted
•
Development or systems skills to analyze special situations encountered
during the early phases of the migration
•
Operations skills to test converted applications under OS/390 and to assess
the impact of converted operational procedures on the OS/390 productions
operations environment
Chapter 3. Developing the Plan 45
If a mass migration/conversion tool is used someone will need to become
familiar with the product and the mass migration method. The team members
should consult the product documentation related to their responsibilities and
run the sample conversion.
The functions and responsibilities of each member of the team depend to some
extent on local conditions. The following sections describe, in general terms, the
tasks each member may perform.
3.2.2.1 Project Manager
The project manager manages the project as a whole, selecting the key
resources, both technical and non-technical, required for the project. The project
manager should posses the appropriate project management skills and should
have current knowledge of project management techniques and tools. The
project manager could be a systems programmer or technical manager who is
knowledgeable in:
1. OS/390
2. The mass migration tool
3. The applications to be converted
4. VSE
The project manager′s tasks and responsibilities include:
•
Managing and controlling the migration project
•
Acting as a liaison between the migration team and others within the I/S
organization
•
Drawing up migration specifications
•
Designing migration procedures
•
Tracking migration schedules and assigning necessary resources
•
Determining any conversion tool customization
•
Planning and preparing for the OS/390 production switchover
3.2.2.2 Systems Programmers
The systems programmers help the project manager to design migration
procedures. They must resolve technical problems related to the local
implementation of both VSE and OS/390; therefore, they must be familiar with
both VSE and OS/390. Their tasks and responsibilities include:
•
Helping to design the specifications for the migration
•
Helping the project manager design the migration procedures
•
Installing and customizing any conversions tools
•
Analyzing and solving conversion problems
•
Preparing for the OS/390 production switchover
•
Assisting with OS/390 operations
46 VSE to OS/390 Migration Workbook
3.2.2.3 Applications Programmers
The applications programmers help the project manager to develop migrations
procedures. They also test converted applications. They should be thoroughly
familiar with critical applications (both online and batch) and understand both
VSE and OS/390. Their tasks and responsibilities include:
•
Helping to design the specifications for the migration
•
Analyzing and preparing the VSE source material
•
Developing any conversion tools or specific conversion procedures
•
Manually converting some general purpose user routines and programs
•
Analyzing and solving conversion problems
3.2.2.4 Operations
If a mass migration tool is used, operations personnel will submit and control the
mass migration jobs, complete and check the production database, and test the
converted applications under OS/390. They must understand the operating
procedures of VSE and OS/390, and know how to use the tool. Their tasks and
responsibilities include:
•
Helping to design the specifications for the migration
•
Designing jobstep preparation
•
Preparing VSE files and JCL
•
Implementing conversion and OS/390 operational procedures
•
Testing the converted applications
•
Completing and checking the mass migration tool output
•
Assisting with OS/390 operations
3.2.3 Tasks
It cannot be stressed enough how absolutely important a well thought out and
well documented project plan is to the successful completion of the migration
project. Discussed here will be some of the key essentials in planning for such a
project and some thoughts on how the actual project plan should be developed.
Assistance with developing the conversion plan can be found in Chapter 3 of the
MVS MS Planning Guide
named ″Developing the Conversion Plan″. The checklist
that was used to develop that plan can also be found in Appendix A , ″The
Conversion Workbook″ of that publication. An example of a project plan can be
found in 3.4.2, “Project Plan Example” on page 56.
Listed below are some of the main tasks that are involved in a migration.
1
Defining objectives.
2
Analyzing what the tasks required in a migration are and developing a
well-documented migration plan.
3
Assigning personnel to the conversion team.
4
Deciding on a conversion method and a conversion tool(s).
5
Analyzing the VSE workload and developing a comprehensive list of the
applications to be converted.
6
Planning for and upgrading hardware.
Chapter 3. Developing the Plan 47
7
Training personnel to work with the OS/390 system.
8
Planning and installing the OS/390 system products.
9
Developing standards for application conversion that reflect such things as
naming conventions to be used in the new OS/390 system environment.
10
Collecting all VSE source materials and presenting same to the conversion
process.
11
Translating VSE programs to OS/390 programs.
12
Converting JCL.
13
Transferring data files from VSE to OS/390.
14
Testing each converted application under OS/390.
15
Documenting and preparing run books and operational procedures.
16
Implementing the production workload under OS/390.
3.2.4 Milestone Events
Within each migration, certain activities should be identified as key activities, the
attainment of which can signal significant progress (or the lack of attainment, a
schedule slippage). These activities are typically called milestone events or just
milestones. Each customer should identify the milestones most important in their
migration.
The following are some suggested VSE to OS/390 migration milestones:
Migration Plan completed, reviewed, and approved.
VSE software inventory completed.
All vendor support committed.
Essential education completed.
Necessary hardware installed.
Installation of OS/390 and related products completed.
Initial OS/390 IPL performed.
Pilot conversion completed.
Each major application′s successful conversion.
Stress/Production tests completed.
Operator education and Run Books completed.
Production criteria attained.
Production implementation initiated.
Once milestones are defined, periodic ″checkpoints″ can be scheduled to
monitor successful milestone completion; that is, project progress.
48 VSE to OS/390 Migration Workbook
3.2.5 Education
OS/390, and to some degree migration/conversion skills are crucial factors to the
success of the migration project. Identification of skill requirements and how
these requirements will be satisfied is the main objective of the education plan.
Listed are the key elements to effective education planning:
•
Identify personnel (who)
•
Identify personal needs (what)
•
Set schedules (when)
•
Map a master plan (how)
•
Identify resources/offering dates
3.3 Progressive versus Mass Conversion
3.3.1 Approach Differences
The difference between the progressive and mass conversion approaches is
illustrated on Figure 6.
Figure 6. Progressive versus Mass Conversion
In a progressive conversion, the VSE application portfolio is divided in smaller
application units (or kernels) which are migrated one by one to the target OS/390
environment. The production is divided between VSE and OS/390 operations for
an extended period of time. During that critical period, the OS/390 system
supports simultaneously the new production and the application conversion
including the conversion testing.
The main distinction with the mass conversion approach is that it results in a
single switchover of the entire VSE application portfolio to OS/390 over a
weekend, with no overlap of VSE and OS/390 production. Until the switchover
weekend, all converted applications run in production under VSE. By the end of
the switchover weekend, all converted applications run in production under
OS/390. An OS/390 system is used in parallel with ongoing VSE operations to
support the migration project, but it doesn′t support any OS/390 production until
the switchover weekend.
Chapter 3. Developing the Plan 49
3.3.2 Historical Perspective
The progressive conversion approach was the only solution available until the
early 80s.
More recently modern VSE operations have substantially grown in size,
complexity and integration, making it more difficult to implement a progressive
conversion.
It is also because the mass conversion approach, which was in a pioneer stage
in the early 80s, has matured to become safe and proven alternative. Hundreds
of mass conversions have been successfully completed worldwide in the past 15
years.
3.3.3 Shared Application Files and Databases
With today′s highly integrated VSE application portfolios, it becomes increasingly
difficult to define isolated application kernels for a progressive conversion. Most
applications share access to the same permanent files or databases. If some
files and databases need to be accessed at the same time by some application
kernels running in production under VSE and other application kernels running in
production under OS/390, those files and databases must be duplicated under
VSE and OS/390. The duplicate versions must then be kept in sync, which
requires developing complicated application bridges between VSE and OS/390.
The bridges must constantly be changed, as application kernels are
progressively migrated from VSE to OS/390.
3.3.4 Shared Application Code
A similar challenge exists for reusable code, such as JCL procedures,
subroutines, macros, copybooks and includes. Duplicate versions must be
maintained under VSE and OS/390 while application kernels sharing usage of
those code items run on different operating systems. Duplicate source storage
systems and change control procedures must be maintained during the overlap.
3.3.5 Operations Support Staffing
Supporting and operating dual VSE and OS/390 production environments
requires a larger staff and skill set than for a single production environment.
3.3.6 Automated Operations Tools
The complexity and sophistication of modern VSE operations shows in the
catalog of automated operations tools on which they rely. Those tools often
include a job scheduler, a report manager and a tape manager, which
complicates the organization and implementation of a progressive conversion.
It is very challenging to coordinate the overall job scheduling when two
synchronized and inter-dependent parts of the application portfolio run on two
separate operating systems under the automated control of two separate job
schedulers. Job schedulers are not designed or able to coordinate production
between two separate operating systems. In addition, as discussed above for
shared permanent data file and databases, the on-going progressive migration of
application kernels, forces to constantly change the automated job scheduling on
each side.
A similar challenge awaits progressive conversion teams with the division of
report management instructions between two report managers running on two
50 VSE to OS/390 Migration Workbook
separate operating systems, or the division of tape files and tape volumes
between two tape managers running on two separate operating systems.
3.3.7 Standardized Conversion Deliverables and Automation
A significant objective for today′s VSE or OS/390 mainframe installation is the
standardization of their application components (JCL streams, application code
and data files), associated naming conventions and operation procedures. The
standardization of conversion deliverables is directly related to the degree of
automation used to perform the conversion. The more automation is used, the
more standardized the deliverables will be. Mass conversions are typically more
automated than progressive conversions.
It is also much easier to guarantee complete and consistent compliance with
standards and naming conventions when the entire inventory is converted and
switched from VSE to OS/390 over a single weekend using a single automated
conversion process, as in the mass conversion approach. Contrarily, it is difficult
to guarantee a good compliance with standards and naming conventions when
the conversion of application kernels spans over many months and may be
assigned to separate conversion teams, as in a progressive conversion. The
same conversion requirement may be addressed differently by different people
at different times.
3.3.8 Risk Management
The comparative risk of both conversion approaches has changed over the
years.
The risk of disrupting your production system, when dividing it into dual
operating environments, has increased in proportion with the VSE application
portfolios increase in size, complexity and integration.
With mass conversions, the regimen of performing multiple successful rehearsal
conversions has refined the mass conversion approach and its single switchover
weekend into a mature and predictable, therefore safer solution.
It is today safer to use the mass conversion approach than the progressive one
for large application portfolio, and in some cases of high integration, there is
simply no other way.
3.3.9 Complexity of Implementation
Still, the mass conversion approach requires more skills and experience than
the progressive conversion approach.
The conversion of one single application kernel requires less integrated
automation, therefore less complex (and less expensive) conversion tools. Due
to the reduced size of a kernel, it is fairly easy to recover manually from
automated conversion defects. The migration of a single kernel requires less
planning than the conversion of the entire portfolio. Consequently, the
progressive conversion approach has an easier learning curve, which makes it
easier to implement with internal non-conversion-expert staff only. They learn
while they do it.
Contrarily, the mass conversion approach requires highly integrated automation,
therefore complex and expensive conversion tools. Due to the size of the
conversion inventory, it is difficult or impossible to recover manually from
Chapter 3. Developing the Plan 51
automated conversion defects. The switchover of an entire VSE production to
OS/390 over a weekend cannot be improvised: it requires perfect precision and
planning by experienced conversion specialists. The complexity of powerful
mass conversion tools makes it difficult to staff with internal
non-conversion-expert staff exclusively, because of the learning curve. Hiring
conversion consultants experienced with mass conversions and single weekend
switchovers is highly recommended for users who want to migrate large
integrated VSE production environments to OS/390 over a single weekend.
3.3.9.1 Mass Migration as a Conversion Method
Mass migration uses the single switchover method of migrating a VSE
installation to OS/390. The various conversion tasks that need to be performed
using this methodology are described in the MVS-MS and CORTEX-MS
documentation. The conversion method, or process, consists of running three
conversions:
1. The pilot conversion - a conversion of a small subset of the VSE applications,
usually involving all or part of the most important work. The pilot conversion
educates project team members, provides the time to define OS/390
standards, code any exits deemed necessary for customizing, and overall
prepares the team for the rest of the conversions.
2. The dummy conversion - a conversion of all VSE applications; a process that
is normally repeated many times as changes are made to VSE source
materials over the life of the project. This is why ″freezing″ VSE application
maintenance is not necessary with this methodology.
3. The actual mass conversion (or switchover) - a conversion of all VSE
applications, the switchover of the VSE files and catalogs, followed by OS/390
production operations.
Because MVS-MS and CORTEX-MS documentation guides you in the steps and
tasks to be performed, it helps you develop a comprehensive and detailed
migration plan for your own installation. The documentation also provides the
skeleton migration plan with staffing recommendations - you provide your
installation-specific details.
3.3.9.2 Mass Migration Used as a Conversion Tool
Used interactively, MVS-MS or CORTEX-MS is a set of subsystems that are panel
driven and use TSO terminals to direct all conversion tasks. The tool translates
VSE source programs written in the following languages:
•
Assembler
•
COBOL
•
PL/I Optimizer
•
RPG II
In addition to translating the above VSE programming language programs into
OS/390 source equivalents, MVS-MS or CORTEX-MS, herein after referred to as
the tool, also performs the following:
•
ISAM programs are translated to VSAM; that is, ISAM I/O statements
translated into VSAM statements.
•
COMREG, CNTRL, and PRTOV functions (VSE functions not directly supported
in OS/390) are simulated under OS/390 by the tool′s simulation routines.
52 VSE to OS/390 Migration Workbook
•
Program clauses that restrict device independence are eliminated; that is,
I/O assignment clauses removed from programs, placed in JCL.
•
Program console interactions (for example, COBOL DISPLAY/ACCEPTs) are
removed from being executed at program runtime; rather this input is
requested at job setup time via job preparation panels and prompts.
The tool converts VSE JCL (procedures, standard label definitions) and the
POWER Job Entry Control Language (JECL) - $$LST, $$PRT, $$PUN, $SLI - into
OS/390 JCL jobstreams. VSE uses of standard utilities are translated into OS/390
equivalents - SORT/MERGE, IDCAMS, and IEBGENER utilities.
The tool lists information in cross reference reports that enables the installation
to make sure that the VSE input libraries are complete. The information
provided includes lists of relationships:
•
Between JCL and PROC/SLI books
•
Between JCL (or PROC/SLI books) and programs, PSB, DBD, or FCB
definitions
•
Between programs and called modules
•
Between programs and copied members or macros
The above data can help the project team determine ″what′s missing,″ ″what′s
duplicated,″ and ″what′s not used″ of the VSE source materials. (It can′t help the
team find missing source, however.) Thus, the tool can assist in one of the most
crucial tasks of the migration; that is, reconciling the ″source VSE materials″
needed for the conversion process. This is sometimes referred to as the Data
Analysis Phase.
In addition to source program and JCL translation, the tool also provides:
3.4 Plan Examples
The following is a sample plan for the migration of ABC Company from VSE to
OS/390. ABC Company will be contracting OS/390 services from SER company.
CNV Company has been contracted to provide professional migration services
and will be using CORTEX-MS.
•
OS/390 standards naming convention assistance
•
Testing facilities to help when testing converted programs
•
Operator job preparation and submission panels
•
Exits for the tool customizing purposes
•
Operator job logging facilities
•
Online terminal exercises to help in learning the tool operations
Chapter 3. Developing the Plan 53
3.4.1 Project Schedule
3.4.1.1 Estimated Project Schedule
The following is an estimated schedule for Project 2 - VSE to MVS conversion.
The project may begin upon completion of the Inventory Determination task of
Project 1, estimated to be on or about June 1, 1996, and will last approximately
nine (9) months with a switchover to MVS after approximately eight (8) months.
Table 3. Nine Month Project
Phase 1 - Specifications
Phase 2 - Custom Modifications of CORTEX-MS * ** ** **
Phase 3 - First Trial Conversions: Online and
Batch Appl
Phase 4a - MVS Tests & Repetitive
Conversions : Online
Phase 4b - MVS Tests & Repetitive
Conversions : Batch
Phase 5 - Actual Conversion and Switchover *
Phase 6 - Assisted MVS Operations **
Month Number
Month Initial
1 2 3 4 5 6 7 8 9
J J A S O N D J F
** ** *
**
* *
* ** ** **
* ** ** ** *
3.4.1.2 Estimated Schedule for CNV Responsibilities
The following is an estimated schedule for CNV responsibilities. The actual
schedule will be determined at project start.
Table 4. CNV Responsibilities
Month Number
Month Initial
01 - Manage CNV Conversion Responsibilities ** ** ** ** ** ** ** ** **
02 - Provide Technical Leadership * * * * *
03 - Receive and Validate the Conversion
Inventory
04 - Develop the Conversion Specifications
05 - Custom Modify CORTEX-MS and
Proprietary Tools *
06 - Perform Manual Conversion Activities * * *
07 - Perform Automated Mass Conversions * * * * * * * *
08 - Assist with Setup of MVS Automated
Operations Tools
09 - Participate in Online Applications Testing ** ** ** *
10 - Perform Batch Applications Testing * ** ** ** *
11 - Participate in Applications Switchover to
MVS
12 - Support Initial MVS Operations **
1 2 3 4 5 6 7 8 9
J J A S O N D J F
* * * * * * * * *
** ** ** *
**
** ** ** **
* * *
* **
54 VSE to OS/390 Migration Workbook
3.4.1.3 Estimated Schedule for ABC Responsibilities
The following is an estimated schedule for the ABC responsibilities. The actual
schedule will be determined at project start.
Table 5. ABC Responsibilities
Month Number
Month Initial
01 - Manage ABC Conversion Responsibilities ** ** ** ** ** ** ** ** **
02 - Participate in Project Planning
03 - Operate MVS Environment ** ** ** ** ** ** ** ** **
04 - Provide Office Space and Project Support
Tools
05 - Determine and Supply VSE Material to be
Converted
06 - Assist with Conversion Specifications
07 - Apply Manual Modifications to VSE
Material (If any)
08 - Set up MVS Operations Tools ** ** ** ** **
09 - Perform Online Application Tests ** ** ** **
10 - Perform Batch Application Tests * ** ** ** *
11 - Participate in Applications Switchover to
MVS
12 - Support Initial MVS Operations **
1 2 3 4 5 6 7 8 9
J J A S O N D J F
* * * *
*
*
* * * * * * * *
** **
**
* * *
**
** *
3.4.1.4 Estimated Schedule for SER Responsibilities
The following is an estimated schedule for the SER responsibilities. The actual
schedule will be determined at project start.
Table 6. SER Responsibilities
Month Number
Month Initial
01 - Provide MVS Resources * * * *
02 - Install, Maintain, and Support MVS
Environment
03 - Assist with Conversion Specifications
04 - Participate in Applications Switchover to
MVS
05 - Support Initial MVS Operations **
1 2 3 4 5 6 7 8 9
J J A S O N D J F
** ** ** ** ** ** ** ** **
** **
**
**
** *
Chapter 3. Developing the Plan 55
3.4.2 Project Plan Example
The actual schedule will be determined at Project 2 start, based on the
completion of the Project 1 Inventory Determination completion date, the
expected switchover date, and any potential conflicts with ABC′s processing.
3.4.2.1 Project Plan - Summary
Task Name ID Projected Actual
Start End Start End
Preparation Phases 01 01/09/98 05/10/98
Application Inventory 02 01/09/98 03/10/98
Specifications 03 02/01/98 05/03/98
Customization 04 02/15/98 05/10/98
Conversion Phases 05 04/26/98 09/21/98
Trial Conversion 06 04/26/98 09/21/98
Online Testing 07 04/26/98 07/26/98
Batch Testing 08 05/10/98 09/13/98
Production Testing 09 08/16/98 09/21/98
Implementation Phases 10 09/01/98 10/15/98
Actual Conversion & Switchover 11 09/01/98 10/23/98
Initial MVS Operations 12 09/20/98 10/23/98
Migration Completion 10/23/98 10/23/98
56 VSE to OS/390 Migration Workbook
Chapter 3. Developing the Plan 57
Task Name
Preparation Phases
Application Inventory
Specifications
Customization
Conversion Phases
Trial Conversion
Online Testing
Batch Testing
Production Testing
Implementation Phases
Actual Conversion &
Switchover
Initial MVS Operations
Migration Completion
ID
01
02
03
04
05
06
07
08
09
10
11
12
1998
Jan
Preparation Phases
Application Inventory
Feb Ma r Apr Ma y Jun Jul Aug Sep Oct
Specifications
↓
Customization
Conversion Phases
Trial Conversion
Onlne Testing
Batch Testing
Production Testing
Implementation Phase
Actual Conversion & Switch
Initial MVS Operations
♦
Migration Completion
3.4.2.2 Project Plan - Details
ID Task Name Projected Actual
Start End Start End
01 Project Approval 01/09/98 01/09/98
02 Application Inventory 01/09/98 08/24/98
03 Initial & Inventory Supplies 01/09/98 03/10/98
04 0 % Missing 03/10/98 03/10/98
05 General Inventory Supply Every 3 Weeks 03/10/98 08/24/98
06 Less than 2% Missing 02/01/98 02/01/98
07 Project Planning 01/09/98 09/21/98
08 Project Plan 01/09/98 02/13/98
09 Develop Project Plan 01/09/98 01/23/98
10 Present Project Plan 01/23/98 01/23/98
11 Review & Complete Project Plan 01/23/98 02/13/98
12 Online Test Plan & Scripts 02/14/98 04/26/98
13 Provide Online Test Orientation 02/14/98 02/14/98
14 Develop Online Test Plan & Scripts 02/15/98 04/26/98
15 Review Online Test Plan & Scripts 02/15/98 04/26/98
16 Batch Test Plan & Scripts 03/28/98 06/07/98
17 Provide Batch Test Orientation 03/28/98 03/28/98
18 Develop Batch Test Plan & Scripts 03/29/98 06/07/98
19 Review Batch Test Plan & Scripts 04/12/98 06/07/98
20 Switchover Plan 07/05/98 09/21/98
21 Develop Switchover Plan 07/05/98 07/18/98
22 Provide Switchover Test Orientation 07/19/98 07/19/98
23 Complete & Refine Switchover Plan 07/19/98 09/21/98
24 Online Application Conversion 02/01/98 04/26/98
25 COBOL Program Conversion 02/01/98 04/26/98
26 Develop COBOL Online Conversion
Specifications
27 Develop Automated COBOL Online
Conversion
28 Perform Manual COBOL Online
Conversion
29 Map, Table, Data Conversion 03/01/98 04/26/98
30 Migrate CICS Maps 03/01/98 04/26/98
31 Setup CICS Application Tables 03/29/98 04/26/98
32 Migrate CICS Application Files &
Databases
33 Online Tests Can Start 04/26/98 04/26/98
34 Online Application Tests & Corrections 04/26/98 08/30/98
35 Participate in Online Initialization Tests 04/26/98 05/10/98
36 Perform Online Sample Tests 05/10/98 06/07/98
37 Online Application Tests Can Start 06/07/98 06/07/98
02/01/98 04/26/98
02/15/98 04/26/98
04/12/98 04/26/98
03/29/98 04/26/98
58 VSE to OS/390 Migration Workbook
ID Task Name Projected Actual
Start End Start End
38 Perform Online Application Tests 06/07/98 08/16/98
39 Perform Online Network & Stress Tests 08/16/98 08/30/98
40 Refine & Repeat Online Application
04/26/98 08/23/98
Conversion
41 Batch Application Conversion 01/09/98 05/10/98
42 Install Conversion Tools 01/09/98 01/16/98
43 Install Conversion Software 01/09/98 01/16/98
44 Batch Program Conversion 02/01/98 04/26/98
45 Develop COBOL Batch Conversion
02/01/98 04/12/98
Specifications
46 Develop Automated COBOL Batch
02/15/98 04/26/98
Conversion
47 Perform Manual COBOL Batch Conversion 04/12/98 04/26/98
48 VSE JCL Conversion 02/01/98 05/10/98
49 Perform JCL Pilot Conversion 02/01/98 02/20/98
50 Develop VSE JCL Conversion
02/01/98 04/26/98
Specifications
51 Develop VSE JCL Automated Conversion 02/15/98 05/10/98
52 Perform Manual PCL and JCL Conversion 04/26/98 05/10/98
53 Perform Initial Mass Conversion (JCL +
04/26/98 05/10/98
PCL)
54 OS/390/DFSMS Standards Definition 02/01/98 04/26/98
55 Develop OS/390/DFSMS Standards
02/01/98 04/12/98
Recommendation
56 Present OS/390/DFSMS Standards
02/15/98 02/15/98
Recommendation
57 Explain Current VSE Standards 02/15/98 03/08/98
58 Define New OS/390/DFSMS Standards 02/15/98 04/26/98
59 OS/390 JCL Generation 03/01/98 05/10/98
60 Define OS/390 JCL Generation
03/01/98 04/26/98
Specifications
61 Develop OS/390 JCL Automated
03/15/98 05/10/98
Conversion
62 Batch File Migration 04/05/98 05/10/98
63 Develop Batch File Migration
04/05/98 04/19/98
Specifications
64 Develop Batch File Migration Procedures 04/19/98 05/10/98
65 Migrate Batch Files for Testing 04/26/98 05/10/98
66 COBOL VSE Positioning 04/26/98 08/16/98
67 Identify & Perform COBOL VSE Positioning 04/26/98 07/19/98
68 Perform, Test & Roll-out COBOL VSE
05/24/98 08/16/98
Positioning
69 Batch Test Can Start 05/10/98 05/10/98
70 Batch Application Tests & Corrections 05/10/98 09/21/98
71 Perform Sample Batch Tests 05/10/98 06/05/98
Chapter 3. Developing the Plan 59
ID Task Name Projected Actual
Start End Start End
72 Batch Application Tests Can Start 06/07/98 06/07/98
73 Perform Critical Application Batch Tests 06/07/98 08/16/98
74 Non-critical Application Batch Tests 08/16/98 09/21/98
75 Refine New OS/390/DFSMS Standards 05/10/98 08/16/98
76 Identify Application Interfaces 06/14/98 08/02/98
77 Refine & Repeat Batch Application
Conversion
78 Switchover Preparation 07/19/98 09/21/98
79 File Migration 07/19/98 08/16/98
80 Develop Switchover File Migration Specs 07/19/98 08/02/98
81 Develop Switchover File Migration
Procedures
82 Switch Rehearsal Can Start 08/16/98 08/16/98
83 Rehearse Switchover File Migration 08/16/98 08/17/98
84 Production Tests 08/17/98 09/21/98
85 Perform Production Tests 08/17/98 09/21/98
86 Actual Conversion 08/17/98 09/21/98
87 Convert Development Code 08/17/98 08/30/98
88 JCL Supply For Last Mass Conversion 08/22/98 08/23/98
89 Last Mass JCL Conversion 08/24/98 08/30/98
90 ″Fix & Freeze″ JCL 08/24/98 09/21/98
91 Program Supply for Last Mass Conversion 09/09/98 09/10/98
92 Last Mass Program Conversion 09/11/98 09/12/98
93 ″Freeze & Fix″ Programs 09/11/98 09/21/98
94 Switchover Can Start 09/21/98 09/21/98
95 OS/390 Switchover 09/21/98 10/23/98
96 Final Switchover Preparation 09/21/98 09/26/98
97 Actual Switchover Weekend 09/26/98 09/26/98
98 Assist OS/390 Operations 09/28/98 10/23/98
99 Project End 10/23/98 10/23/98
05/10/98 08/16/98
08/02/98 08/16/98
60 VSE to OS/390 Migration Workbook
Chapter 3. Developing the Plan 61
Task ID
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
1998
Jan
♦
Project Approval
Application Inventory
Application Inventory
Project Planning
Project Plan
Develop Project Plan
♦
Present Project Plan
Review & Complete Project Plan
Feb Ma r Apr May Jun Jul Aug Sep Oct
♦
0% Missing
General Inventory Supply Every 3 Weeks
♦
Less than 2% Missing
Online Test Plan & Scripts
♦
Online Test Orientation
Develop Online Test Plan
Review Online Test Plan
Batch Test Plan & Scripts
♦
Batch Test Orientation
Develop Batch Test Plan
Review Batch Test Plan
Switchover Plan
Develop Switchover Plan
↓
62 VSE to OS/390 Migration Workbook
Task ID
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
1998
Jan
Batch Application Conversion
Install Conversion Tools
Feb Ma r Apr May Jun Jul Aug Sep Oct
♦
Switchover Test Orientation
Refine Switchover Plan
Online Application Conversion
COBOL Program Conversion
COBOL Online Conversion Specifications
Automated COBOL Online Conversion
Manual COBOL Online Conversion
Map, Table, Data Conversion
CICS Map Conversion
Setup CICS Tables
Migrate CICS Files & DB
♦
Online Tests Can Start
Online Application Tests & Corrections
Online Initialization Tests
Sample Tests
♦
Online Application Tests Can Start
Online Application Tests
Online Network & Stress Tests
Refine & Repeat Application Conversion
↓
Chapter 3. Developing the Plan 63
Task ID
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
1998
Jan
Install Conversion Software
Feb Ma r Apr May Jun Jul Aug Sep Oct
Batch Program Conversion
COBOL Batch Conversion Specifications
VSE JCL Conversion
JCL Pilot Conversion
VSE JCL Conversion Specifications
OS/390/DFSMS Standards Definition
OS/390/DFSMS Standards Recommendation
Automated COBOL Batch Conversion
VSE JCL Automated Conversion
♦
Present Standards Recommendation
Explain Existing VSE Standards
Define New Standards
OS/390 JCL Generation
OS/390 JCL Generation Specifications
OS/390 JCL Automated Conversion
Batch File Migration
Batch File Migration Specifications
↓
Manual COBOL Batch Conversion
Manual PCL and JCL Conversion
First Mass Conversion
64 VSE to OS/390 Migration Workbook
Task ID
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
1998
Jan
Feb Ma r Apr May Jun Jul Aug Sep Oct
Batch File Migration Procedures
Migrate Batch Test Files
COBOL VSE Positioning
Identify COBOL VSE Positioning
Perform & Implement COBOL VSE Positioning
♦
Batch Test Can Start
Batch Application Tests & Corrections
Sample Batch Tests
♦
Batch Application Tests Can Start
Critical Application Batch Tests
Non-critical Application Batch Tests
Refine MVS/DFSMS Standards
Identify Application Interfaces
Refine & Repeat Batch Conversion
Switchover Preparation
File Migration
Switchover File Migration Specifications
Switchover File Migration Procedures
♦
Switch Rehearsal Can Start
Rehearse Switchover File Migration
Production Tests
↓
Chapter 3. Developing the Plan 65
Task ID
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
1998
Jan
Feb Ma r Apr May Jun Jul Aug Sep Oct
Perform Production Tests
Actual Conversion
Convert Development Code
Mass Conversion JCL Supply
JCL Mass Conversion
″Fix & Freeze″ JCL
Last Program Supply
Last Mass Program Conversion
″Freeze & Fix″ Programs
♦
Switchover Can Start
OS/390 Switchover
Final Switchover Preparation
♦
Actual Switchover
OS/390 Operations
↓
♦
Project End
66 VSE to OS/390 Migration Workbook
Part 2. Converting the VSE Operating System to the OS/390
Operating System
Copyright IBM Corp. 1998 67
68 VSE to OS/390 Migration Workbook
Chapter 4. Job Control Language (JCL) Differences and Considerations
The following sections describe the major tasks and considerations involved in
converting VSE JCL to MVS JCL and the differences between them. These
sections are divided into the following categories:
•
4.1, The Philosophy of JCL in System/390
•
4.2, High Level Similarities
•
4.3, JCL Differences Between VSE and MVS
•
4.4, JECL
•
4.5, VSE and MVS JCL Comparison Example
While this chapter describes the differences and conversion tasks, we
recommend that you take a class on MVS JCL. See Appendix A, “Education
Information” on page 535.
4.1 The Philosophy of JCL in System/390
Often, before discussing JCL systems and schemes, it is valuable to understand
why the System/390 (originally the System/360) operating systems incorporated
Job Control.
In the era of the predecessor computer systems, for example the IBM 1400, 7080,
and 7090 systems, the concept of job control was just beginning. Application
program coding included explicit references to files and other system resources.
If a given program could be used with another file, the program often required
changes. Flexibility and the beginnings of resource reuse led to the concept of a
system facility that externalized the references from programs to other system
resources, whether they were other programs or data files.
Job Control Language was developed as part of the System/360 architecture, to
address the requirement for reuse. The ability to use one program with different
files, and with different predecessor and successor programs, makes computer
programs much more usable. This ability to create jobs and steps is crucial to
the development of today′s ″Industrial Strength″ information processing
technology.
As OS/390′s predecessors were being developed, it became obvious that the
smaller customers′ needs required smaller systems. With the economics in the
information processing over 30 years ago, the smaller systems were too small in
terms of internal and external storage and processor power to provide the
minimum environment needed for OS/360.
VSE/ESA′s predecessors were developed to permit smaller customers′
requirements to be met with the smaller systems then available. BOS (Basic
Operating System), TOS (Tape Operating System), DOS (Disk Operating System),
DOS/VS, VSE, and now VSE/ESA are the progression of operating systems
designed to ″fill the hole″ left by small processor requirements that could not
meet the minimum resource requirements of the OS/390 predecessors.
Copyright IBM Corp. 1998 69
OS/360 (PCP, MFT, MVT), the predecessors to MVS, and OS/390, specified Job
Control Language but when JCL was needed for BOS and TOS, a much smaller
implementation was required. Different JCL philosophies developed from this
background.
4.1.1 VSE/ESA′s Job Control Language Philosophy
Within the VSE/ESA philosophy for Job Control Language, several concepts are
required:
•
A
Job Stream
which must follow each other in sequence. These will run in a single address
space or partition of the VSE/ESA system. They are delimited by ″Job Entry
Control Language″, or JECL, which is interpreted by the VSE job spooling
subsystem, POWER.
Generally, sequencing of job streams is performed by the operator or by a
job scheduling subsystem.
•
A
Job
describes the concept of one or more job steps which relate the
sequence of programs to be executed, together with the files and other
system resources those job steps require for their successful execution. A
job can be composed of one or more steps.
Each job will have a known system initial state in terms of system resources,
and at the end of the job, those resource assignments will be reset to their
initial conditions. Thus, well-formed jobs can run independently with the
exception of any input or output data files that they use.
describes the concept of a single job or a sequence of jobs
Execution of job steps is generally sequential, but the VSE conditional JCL
facilities permit status checking and conditional or absolute GOTO
capabilities, thus a given job will be able to modify its own processing
sequence depending on results from earlier steps in that job.
•
A
Job Step
is the smallest unit of job control from a scheduling perspective.
Job steps receive the state as established by their predecessor steps, in
terms of system resource assignment. Job steps are, for practical purposes,
an instance of the execution of a single program, and specify the system
resources needed by that program. They can affect resource assignment
and state variables such as condition codes and parameter values for
successor job steps, as well.
VSE Job Control is processed as job steps are executed. That is, no VSE system
functions preprocess job control statements for syntax or resource availability
checking before the actual execution of the statements. In addition, VSE provides
for standard resource assignments and file definitions through the concepts
implemented as ″Permanent ASSGNs″ and ″Standard Labels″, which can be
used by any job or step without any specific inclusion in the JCL defining that job
or step. These capabilities make VSE JCL less complex to code, but more
complex to understand, as it is interpreted at step execution time in the context
of the permanent ASSGN and standard label environment in place at that time.
4.1.2 OS/390′s Job Control Philosophy
The concept of a job stream, that is a collection of related jobs, does not exist in
OS/390 and JES2. If a group of jobs is to flow in a particular sequence, you can
create a single new job with the same sequence of job steps. You can also use a
job scheduling product such as OPC which can control the flow and sequencing
of multiple jobs.
70 VSE to OS/390 Migration Workbook
Because there is no concept of permanent ASSGN or specification of standard
label facilities, all resource requirements for each job step must be included
explicitly in each job step. In OS/390, these definitions can be included as
procedures which can reduce the repetitive coding of JCL statements
(specifically DD statements).
To understand the structure and philosophy of MVS job control language, you
must first understand the workflow process for batch jobs. With OS/390, there
are separate phases for each of the following:
1
Input Service
The job′s JCL and any instream data sets are read by JES and stored on
spool as related spool files. No procedures or included JCL statements are
referenced or verified at this time.
JES control statements (JECL) are read, validated and attributes are
recorded for later processing. (These are converted to JCL comment cards
so the subsequent stages do not process them.)
2
JCL Conversion
The job control statements are “converted” into structured text units, and
most (but not all) syntax checking is performed. This step usually takes
place immediately after input service, and any JCL errors result in the job
being queued for output processing, bypassing execution, with a JCL error
message being sent to the submitter.
3
Job Scheduling
After conversion, the job is queued for initiation, and selected by either a
JES2 or WLM managed initiator on a priority, class, and first-come,
first-served basis.
4
Job and Step Initiation
When the job is selected for initiation, the converter-interpreter text units
are read and any data set references are resolved. Any errors such as
“data set not found” are determined at this point and the job is flushed queued for output processing - and the programmer is notified.
Once the interpreted control blocks are read into memory, each job step is
given control one at a time based on the conditional JCL processing
options. At step initiation time, all data sets referenced by JCL statements
are allocated. This is unlike VSE when data sets are allocated when they
are opened.
5
Output and Hardcopy Processing
There are actually two steps here with JES2. When the job finishes
execution, the output created on JES spool is grouped into output elements
according to destination and similar attributes, and queued for hardcopy
processing.
These output elements are then individually scheduled for printing,
punching, online viewing, or transmission to another node.
6
Purge Processing
After all the output for a job is disposed of, the job is deleted from the JES
queues and the spool space is freed up.
Chapter 4. Job Control Language (JCL) Differences and Considerations 71
Unlike VSE, the operator does not manipulate elements within a job stream, nor
is he given the opportunity to correct JCL errors. The processes are much more
automated in OS/390 under the theory that the system will be better utilized and
jobs run more efficiently without operator intervention.
4.2 High Level Similarities
A high level comparison of JCL in the VSE and OS/390 environments reveals
many similar functions and purposes. A comparison of the mechanics in both
environments reveals significant differences.
4.2.1 JCL Statement and Job Layout
VSE and MVS JCL are similar in the basic layout for the card images in that both
use 80 Column Card Images, and both use // in columns one and two. Both
operating systems also use the basic layout of a job with one or more steps per
job as described in the philosophical discussion above.
4.2.1.1 Continuation Cards
Both use ASM-type continuation, but the basic layout differs in that:
•
VSE JCL statements are continued by placing a non-blank character in
column 72, and JCL continuation cards must start in column 16 with blanks in
columns 1 - 15.
•
MVS JCL statements are continued by placing a trailing comma in the
parameter field, and JCL continuation cards may start in any column from 4
to 16, with ″//″ in columns 1 and 2, and a blank in column 3.
4.2.1.2 JOB Statement Starts a Job
In OS/390 there is only one JOB statement as opposed to the VSE POWER and
VSE JOB statements. Much of the time the POWER job will equate to the MVS
job.
4.2.1.3 EXEC Defines Job Step
The EXEC statement defines the job step in both VSE and MVS.
4.2.1.4 File Definitions
File definitions are required by both operating systems (TLBL, DLBL/EXTENT,
DD).
4.2.1.5 Imbedded JCL from Procedures and Libraries
Both operating systems support “canned JCL” and JCL procedures. In VSE, this
is done through procedures (using PROC=procname in the EXEC card) and with
the POWER * $$ SLI JECL statement (Source Library Inclusion). In OS/390, the
same thing can be done with the PROC or INCLUDE JCL statements,
respectively.
4.2.1.6 Nesting Procedures
Both operating systems allow for multiple levels of nested procedures. (MVS
allows up to 15 levels while VSE allows up to 16 levels.)
72 VSE to OS/390 Migration Workbook
4.2.1.7 Instream Data
Both operating systems allow Instream Data in the middle of the JCL. This is
data that will be processed by the executing program.
4.2.1.8 Variables
The JCL in both operating systems will accept variables. These variables are set
with the // SET statement in MVS, or SETPARM in VSE.
4.2.1.9 Conditional JCL
Conditional JCL exists in both environments and allows performing IF and GOTO
statements. Loops are prohibited. In MVS, the IF statements are all processed at
converter time. Although the mechanics are very different, functionally, the IFs
are the same in both environments.
4.2.1.10 Return Codes
Return codes from previous steps can also be tested during execution in both
environments. Program steps can be bypassed based on the result of testing for
a condition (a return code or a parameter value). For example, if in a statement,
the return code was more than zero, then bypass the next statement. In MVS,
this is handled by the COND parameter on the // EXEC statement.
See also 4.3.11.3, “MVS Conditional JCL” on page 84.
4.2.2 Spooling
Spooling exists in both environments. POWER for VSE and JES for OS/390.
POWER and JES provide similar input and output capabilities and a similar
system of classes and priorities.
4.2.2.1 Internal Reader
The internal reader facility exists in both environments. An application program
can pass jobs to the spool, right into the input queue, just by writing to a pseudo
punch device. RJE and NJE also exist in both environments.
Further discussion of spooling can be found in Chapter 10, “POWER and JES2”
on page 207.
4.3 JCL Differences Between VSE and MVS
In part because of the differences in philosophy discussed in 4.1, “The
Philosophy of JCL in System/390” on page 69, there are differences in the
processing of JCL that lead to Job Control Language differences between the
two environments.
4.3.1 Job Input
In VSE systems, job input consisting of JCL statements and instream data,
whether spooled through the POWER spooling system or directly read in a
partition, is processed in a strictly sequential process. That is, a program can
only read one input statement at any one time, and this is a sequential process.
A programming or JCL error in VSE can cause the VSE Job Control program to
read a user data statement, or a user program to read a JCL statement, with
unpredictable results.
Chapter 4. Job Control Language (JCL) Differences and Considerations 73
Instream data will always follow an EXEC statement, and it is the responsibility of
the executing program which is reading the instream data to recognize the end
of that data. By default, the instream data delimiter is the ″/*″ statement,
although an application program can choose its own delimiter. This allows
programs other than JCL to read and process JCL statements, for example,
when the librarian program stores JCL as library members or procedures.
This same capability was often used to control the flow of jobs -- for example, a
program could decide to skip the next job step, and then just read and ignore (or
″swallow″) the JCL statements for that step. With the advent of VSE conditional
JCL in the mid-1980s, the use of this technique has greatly declined, but its use
is found in perhaps 25% of shops converting from VSE to OS/390.
In MVS systems, in contrast, JCL statements and instream data are separated
during the JCL Conversion processing, so that user programs cannot ″see″ JCL
statements, and JCL processing is simplified.
Instream data sets in the OS/390 environment can be read in any sequence, and
can be read multiple times. Thus, an OS/390 job that reads the same instream
input at three different times could simply open and process that data set three
times.
4.3.1.1 Multiple Instream Data Set Input
A VSE job step that reads one input card file under two different program DTFs
requires that the input statements be properly sequenced, whereas in OS/390,
the two input files could appear as two separate instream files.
VSE Example OS/390 Example
// EXEC MYPROG... //FILE1 DD *
FILE 1 CARD 1 FILE 1 CARD 1
FILE 1 CARD 2 FILE 1 CARD 2
FILE 2 CARD 1 FILE 1 CARD 3
FILE 1 CARD 3 FILE 1 CARD 4
FILE 1 CARD 4 FILE 1 CARD 5
FILE 2 CARD 2 FILE 1 CARD 6
FILE 1 CARD 5 /*
FILE 1 CARD 6 //FILE2 DD *
FILE 2 CARD 3 FILE 2 CARD 1
/* FILE 2 CARD 2
FILE 2 CARD 3
/*
// EXEC PGM=MYPROG...
For this processing to work correctly in VSE, it is clearly dependent upon the
program logic and the setup of the instream data. This would be much simpler in
the OS/390 environment. If the MVS example attempts to use just one instream
data set, with two program files being read, each program file will find the same
input data. That is, the first read (from file 1) would read the first record, and the
second read (from file 2) would also read the same first record, as it is the first
read for that file.
74 VSE to OS/390 Migration Workbook
4.3.1.2 Data Driven Segmentation of Output
An artifact of this sequential processing in VSE is that the spooling system
extracts its control statements (JECL) from the input as it is being spooled. When
the input processing crosses the input stream position where the JECL statement
was located, the spooling system will take the action specified by the JECL
statement. The JECL statement can change the output destination of printed or
punched data, or other characteristics, such as special forms requirements.
VSE Example
* $$ JOB JNM=DJANDA,CLASS=A
* $$ LST CLASS=A,DEST=*
// JOB DJANDA
// EXEC MYPROG
INPUT DATA CARD 1
INPUT DATA CARD 2
INPUT DATA CARD 3
INPUT DATA CARD 4
INPUT DATA CARD 5
* $$ LST CLASS=J,DEST=DANJ,DISP=H
INPUT DATA CARD 6
INPUT DATA CARD 7
INPUT DATA CARD 8
INPUT DATA CARD 9
INPUT DATA CARD 10
INPUT DATA CARD 11
/*
/&
* $$ EOJ
The result would be that output printed by this job and program would be sent to
the default system printer, up to the point when the program read INPUT DATA
CARD 6. Output generated from that point forward (including that of cards 6
through 11) would be sent to a specific user ID, DANJ, rather than the default
printer, and it will be in the HOLD disposition state.
A second type of input segmentation appears when a given program will open
an instream data file, read some of its records and close the file. Later, it will
open the same instream data file and read additional records. In VSE, the
records read in the second group will follow the first group in the input stream. A
simple conversion to OS/390 will result in the second file open re-reading the
same records read by the first file!
A method to circumvent this problem is to change the program logic or to write
a subroutine which traps all the reads on the two input streams and which has
one single DCB, so there is only one DDNAME and then the behavior would be
similar to the VSE case.
4.3.1.3 JCL Parameter Handling
Another difference seen because of the philosophy and architecture changes
between VSE and OS/390 is the fact that VSE JCL parameters and JCL handling
can depend on values that are changed at execution time. VSE conditional JCL
can test return codes, as MVS JCL can, but in addition, VSE can test parameter
values as well.
Also, in VSE, procedure expansion and parameter substitution is done at
execution time, so the results of previous job step execution can affect the
Chapter 4. Job Control Language (JCL) Differences and Considerations 75
expansion for subsequent steps. In general, this is not possible in MVS JCL in
the OS/390 environment.
4.3.2 JCL Expansion
In VSE, JCL is expanded at execution time. The most current changes, even
those changed two seconds before the job begins execution are included. The
first step could change a procedure that is used by the third step.
In OS/390, JCL is expanded all at once when the job is submitted. This may be
hours or days before it is executed. All the procedures, all of the jobs, all of the
includes that are required are expanded at the same time. You can not change
variables during execution in OS/390 using symbolic names in JCL.
If a job is submitted today to be run tomorrow and overnight one of the included
members is changed and not reflected in the original JCL that was submitted,
the job will fail.
4.3.2.1 Early Error Detection
An advantage of expanding the JCL when the job is read in OS/390 is that many
of the JCL errors will be detected early and the job will fail. This removes the
ability to correct the job on the fly as in VSE. In OS/390 many errors are
detected before the job starts. In VSE a card has to be processed before errors
are found and the operator can act on it. However, because of this, you must
have a syntactically correct JOB statement to get JCL errors from OS/390.
4.3.2.2 Overrides
The OS/390 ′Overrides′ occur at the step level. A procedure can only be
overridden in OS/390 through the addition of a DD Statement to a specified step.
This is different from VSE, where statements in PROCs and SLIs are overridden
using each statement′s sequence number in positions 73-80.
4.3.3 Operator Flexibility and Intervention
Another difference between VSE and MVS JCL is the flexibility created by
requiring operator intervention. For example, the operator may correct invalid
JCL syntax.
4.3.3.1 Correcting Invalid Syntax
A syntax error in a JCL statement will cause a message to be posted on the
operator console. The operator will respond to the message by typing in the
correct JCL statement and processing will continue. This facility is not available
with OS/390. The job will fail with a JCL error, and must be corrected and
resubmitted.
4.3.3.2 Operator Data Entry
From a VSE point of view this flexibility is a feature. Installations depend on this
flexibility to address situations where it is necessary to have the operator retype
the JCL or command. For example, a programmer may purposely put in a
syntax error in the JCL to ensure it comes to the operator′s attention. The
experienced operator retypes the string and allows the job to continue.
This technique is illustrated in the following example, where the syntax of the
ASSGN statement is invalid and causes the operator to be prompted for action:
76 VSE to OS/390 Migration Workbook
Loading...