IBML VSE to OS/390 Migration Workbook Cliff Bays ** Dave Greenough ** John Hutchinson Dan Janda ** Kevin Jones ** Gilbert Saint-flour 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.
IBML International Technical Support Organization VSE to OS/390 Migration Workbook October 1998 SG24-2043-00
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.
Contents Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Preface . . . . . . . . . . . . . . . . . . . . The Team That Wrote This Redbook . . . Redbook Builders and Key Contributors . Authors and Significant Contributors . . . . . . . . . . . . Comments Welcome Part 1. Planning the Migration - An Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.5 Project Management . . . . . . . . . . 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 Web URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.13 Summary of MVS JCL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Sample VSE JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Sample MVS JCL 4.5.3 Sample VSE plus Carry-Over . . . . . . . . . . . . . . Chapter 5.
6.1.11 CICS UPSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 7. ICCF and TSO . . . . . . . . . . . . . 7.1 Preparing to Use the System . . . . . . . . . 7.1.1 User Profiles . . . . . . . .
.4.1 Network Definitions . . . . . . . . . . . . . . . . . . 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 9.5.
11.5 Other Differences . . . . . . . . . . 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 . . . . . . . . . . 11.6.6 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 14. RPG II . . . . . . . . . . . . 14.1 Migration from VSE to OS/390 14.1.1 Device Information . . . . . . 14.1.2 Print Files . . . . . . . . . . . 14.1.3 Tape Labels . . . . . . . . . . 14.1.4 Extent Exit . . . . . . . . . . . . . . . . 14.1.5 Processing Options . . . . 14.1.6 File Access Methods 14.1.7 Calling COBOL Subprograms . 14.1.8 Calling PL/I Subprograms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.11.1 Storage Management in DOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.11.2 Storage Management in MVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.12 PL/I and CICS 15.12.1 File Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.12.2 Statements not Supported 15.12.3 CALLing DUMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.12.4 Execution Options . . . . . . . . .
18.5 Migration Issues . 18.5.1 REXX and SAA 18.6 REXX Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Part 4. Converting VSE Utilities to OS/390 Utilities . . . . . . . . . . . . . . . . . . . . . . . Chapter 19. SORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.1 JCL Statements 19.2 Control Statements . . . . .
25.2.1 Processor Requirements . . . . . . . . . . . . . 25.2.2 Devices Supported by OS/390 . . . . . . . . . . 25.2.3 DASD Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 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.
28.2.2 Managing Display Consoles . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28.4.1 Displaying the Status of Devices 28.4.
30.7.2 Tasks . . . . . . . . . . . . . 30.7.3 Methodology 30.8 Asset Management . . . . . . . . . 30.8.1 Overview 30.8.2 Tasks . . . . . . . . . . . . . 30.8.3 Methodology 30.9 Accounting Management . . . . . . 30.9.1 Overview 30.9.2 Tasks . . . . . . . . . . . . . 30.9.3 Methodology . . . . . . . . 30.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32.5.1 Program Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.5.2 JCL Conversion . . . . . . . . . . . . 32.5.3 Phase 4: Initial Trial Conversion 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 . . . . . . . . . . . . . .
C.1 Data Set Naming Guidelines . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . C.2.5 Data Set Level . . . . . . . . . . . . . . . . C.3 Things Not to Include in the Data Set Name . . . . . . . . . . . . C.3.1 Department Number C.3.2 Application Location . . . . . . . . . . . . C.3.
Figures 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. Copyright IBM Corp. 1998 VAE with Three Address Spaces . . . . . . . . . . . . . . . . . . . . . . . VAE with Four Address Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VSE/ESA Storage Layout OS/390 Storage Layout . . . . . . . . . . . . . . . . . . . . . . . . . .
46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. xviii Loading a Sequential DAM File under VSE . . . . . . . . . . . . . . . . . . . . . . . Loading a Sequential DAM File under MVS Loading a Random DAM File under MVS . . . . . . . . . . . . . . Loading a DAM File of U. or V. Length Records under MVS . . . . . . . . . . . . . . . . . Processing a DAM file under VSE Loading a Random (Preformatted) DAM File under VSE . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tables 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. Copyright IBM Corp. 1998 Comparison of VSE Functions & Components to OS/390 Replacements . . . . . . . . . . . . . . . . . . . Who′ s Normal Activities are Affected? Nine Month Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CNV Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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.
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
Part 1. Planning the Migration - An Introduction Copyright IBM Corp.
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.
• 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.
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).
┌─────────────────────────────┐ │ │ │ SVA 2,304K │ │ │ ├─────────────────────────────┤ │ F1 - VSE/POWER - 832K │ ├─────────────────────────────┤ │ F2 - ACF/VTAM - 3,648K │ ├─────────────────────────────┤ │ F7 - DATABASE - 2,048K │ ├─────────┬─────────┬─────────┤ │ │ UNUSED │ UNUSED │ │ UNUSED │ 128K │ 64K │ │ 512K ├─────────┤ │ ├─────────┤ ├─────────┤ │ F6 1.5M │F9 1,536K│ │ │ │ │ CICS │ ├─────────┼─────────┤ PROD │ │ F5 1.5M │ CICS │ │ ├─────────┤ PRD1 │ │ │ F4 1.5M │ │ │ ├─────────┤FA 5,504K│ F3 7.
┌───────────────────────────────────────┐ ───── │ │ │ 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.
│ Static │ Dynamic │ │ Partitions │ Partitions │ ├──────────────────────────────────────────────┴───────────────┤ │ │ │ SVA (31-Bit) │ ├──────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┤ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ 16MB │------│-------│-------│-------│-------│-------│-------│-------│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ VSE/ │ CICS/ │ ACF/ │ │ │ │ │ │ │POWER │
┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐ 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.
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.
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.
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.
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.
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.
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.
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. DL/I databases are compatible with IMS databases 1 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.
Table 1 (Page 2 of 3). Comparison of VSE Functions & Components to OS/390 Replacements VSE OS/390 Comment and Reference Languages Languages See Part 3 page 247 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 ...
Table 1 (Page 3 of 3).
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 , GC28-1725 is recommended for a better 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.
• Distributed Computing − − • Distributed Computing Services − − − • − OS/390 UNIX System Services Application Services OS/390 UNIX System Services Shell & Utilities OS/390 UNIX System Services Debugger LAN Services − − − • Domino Go Webserver for OS/390 - NetQuestion - Internet Connection Secure Server IBM BookManager BookServer for World Wide Web UNIX System Services − − − • VTAM (includes the AnyNet function) IBM TCP/IP - CICS Sockets - Host on Demand - IMS Sockets - Domain Name Server and WL
• Systems Management Services − − − − • Application Enablement Services − − − − − − − − − • IBM TCP/IP Kerberos (DES) IBM TCP/IP Kerberos (non-DES) IBM TCP/IP Network Print Facility Network Computing Services − − • DCE User Data Privacy (DES and CDMF) - OSF DCE 1.1 level DCE User Data Privacy (CDMF) - OSF DCE 1.
• 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.
• 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.
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.
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.
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.
5. 6. 7. 8. 9. 10. 11. Security Performance Capacity Planning Testing Backup/Recovery Disaster Planning 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.
• 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.
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.
• 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.
• 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.
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.
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.
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.
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 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.
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.
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.
The purpose here is not to predict or estimate project costs but to identify major cost elements and any relevant financial resource considerations.
2.9.2 Key Documents and Other References • OS/390 V2R5 Planning and Installation , SK2T-2484 • CBIPO (System Pak) Custom Built Offerings Planning • CICS Up and Running • DB2 Release Guide 2.9.3 Web URL http://WWW.S390.IBM.
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 , SB11-8077 describes the planning process for the MVS-MS.
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.
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.
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 The VSE staff is mainly responsible for: • • • • The new OS/390 HW/SW configuration The VSE application inventory Regre
3.2 Plan Components 3.2.1 Approach 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.
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.
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.
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.
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.
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.
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.
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.
• 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.
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.
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.
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.
Task Name ID 1998 Jan Preparation Phases Feb Mar Apr May Jun Jul Aug Sep 01 Oct ↓ Preparation Phases Application Inventory 02 Application Inventory Specifications 03 Specifications Customization 04 Customization Conversion Phases 05 Conversion Phases Trial Conversion 06 Trial Conversion Online Testing 07 Onlne Testing Batch Testing 08 Batch Testing Production Testing 09 Production Testing Implementation Phases 10 Actual Conversion & Switchover 11 Implementation Phase Ini
3.4.2.
ID Task Name Projected Start Actual 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 Conversion 04/26/98 08/23/98 41 Batch Application Conversion 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 Specifications 02/01/98 04/12/98 46 De
ID Task Name Projected Start Actual 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 05/10/98 08/16/98 78 Switchover Preparation 79 File Migration 07/19/98 08/16/98 80 Develop Swi
Task ID 1998 Jan 01 Feb Mar Apr May Jun Jul Aug ♦ Project A p p r o v a l 02 A p p l i c a t i o n Inventory 03 A p p l i c a t i o n Inventory ♦ 04 0 % Missing 05 General Inventory Supply Every 3 Weeks ♦ 06 Less than 2% Missing 07 Project Planning 08 Project Plan 09 Develop Project Plan 10 ♦ Present Project Plan 11 Review & Complete Project Plan 12 Online Test Plan & Scripts 13 ♦ Online Test Orientation 14 Develop Online Test Plan 15 Chapter 3.
62 Task ID 1998 VSE to OS/390 Migration Workbook Jan Feb Mar Apr May Jun Jul Aug Sep Oct ♦ 22 Switchover Test Orientation 23 Refine Switchover Plan 24 Online Application Conversion 25 COBOL Program Conversion 26 COBOL Online Conversion Specifications 27 Automated COBOL Online Conversion 28 Manual COBOL Online Conversion 29 Map, Table, Data Conversion 30 CICS Map Conversion 31 Setup CICS Tables 32 Migrate CICS Files & DB ♦ 33 Online Tests Can Start 34 Online Application Tests &
Task ID 1998 Jan Feb Mar Apr May Jun 43 Install Conversion Software 44 Batch Program Conversion 45 COBOL Batch Conversion Specifications 46 Automated COBOL Batch Conversion 47 Manual COBOL Batch Conversion 48 VSE JCL Conversion 49 JCL Pilot Conversion 50 VSE JCL Conversion Specifications 51 VSE JCL Automated Conversion 52 Manual PCL and JCL Conversion 53 First Mass Conversion 54 OS/390/DFSMS Standards Definition 55 OS/390/DFSMS Standards Recommendation 56 ♦ Present Standards Recommendat
64 Task ID 1998 VSE to OS/390 Migration Workbook Jan Feb Mar Apr May Jun Jul Aug Sep Oct 64 Batch File Migration Procedures 65 Migrate Batch Test Files 66 COBOL VSE Positioning 67 Identify COBOL VSE Positioning 68 Perform & Implement COBOL VSE Positioning 69 ♦ Batch Test Can Start 70 Batch Application Tests & Corrections 71 Sample Batch Tests 72 ♦ Batch Application Tests Can Start 73 Critical Application Batch Tests 74 Non-critical Application Batch Tests 75 Refine MVS/DFSMS Stand
Task ID 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct ↓ 85 Perform Production Tests 86 A c t u a l Conversion 87 Convert Development Code 88 Mass Conversion JCL Supply 89 JCL Mass Conversion 90 ″Fix & Freeze″ JCL 91 Last Program Supply 92 Last Mass Program Conversion 93 94 ″Freeze & Fix″ P r o g r a m s ♦ Switchover Can Start 95 OS/390 S w i t c h o v e r 96 Final Switchover Preparation 97 ♦ Actual Switchover 98 OS/390 Operations 99 ♦ Chapter 3.
66 VSE to OS/390 Migration Workbook
Part 2. Converting the VSE Operating System to the OS/390 Operating System Copyright IBM Corp.
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.
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 describes the concept of a single job or a sequence of jobs which must follow each other in sequence.
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.
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.
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.
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.
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.
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.
// PAUSE mount tape 123456 on an available drive. // ASSGN SYS005,CUU - or // ASSGN SYS005,Drive The operator gets an error message and enters the correct tape assignment, such as: // ASSGN SYS005,481 Another example is TLBL without VOLSER or a known invalid VOLSER. // TLBL 999999 Forcing error conditions in VSE JCL that require operator intervention becomes a simple tape management method. IGNORE, DELETE and NEWTAP are replies that the operator can use to answer the messages.
There is no equivalent function in OS/390. Many users write their own routine to replace the PAUSE function, if needed, or use the existing automation functions of OS/390. 4.3.4 Allocation of Resources The allocation of resources in OS/390 occurs at step initialization time. This is a big difference from VSE where allocation of resources occurs at open time. In OS/390, if the JCL contains DD statements that point to data sets, the data sets are allocated even if they are not opened.
the conversion of the JCL which may have to be converted differently, depending on in which partition the job normally runs. There is no equivalent to standard labels in OS/390. Labels must be spelled out in each step. One way to keep a common set of labels in OS/390 is to use the JCL INCLUDE statement. In rare cases another possibility is to use dynamic allocation to replace standard labels. 4.3.5.
Understanding tool provides a graphical analysis of your VSE/ESA JCL job stream. You can find further details at the following World Wide Web sites: http://www.software.ibm.com/ad/va2000 http://www.software.ibm.com/ad/cobol The JCL Analyzer is shipped as part of VSE Central Functions in VSE/ICCF library 59. It consists of a number of members, including ARDWREAD, which is a detailed description of the JCL Analyzer and its functions. All the other related library member names begin with the characters ARDW.
• For unlabeled tapes - the DEVADDR is the only link between the program and the JCL (there is no TLBL). Either the DEVADDR or the DTFname can be used as DDNAME. • For card devices - the DEVADDR links the DTF to a card reader or puncher; Either the DEVADDR or the DTFname can be used as DDNAME. • For print devices - the DEVADDR is the only link to a printer or a LST card. Either the DEVADDR or the DTFname can be used as DDNAME. 4.3.
In OS/390 the DATE function can be replaced by a control card, a parameter on the EXEC statement, or a date simulation tool. 4.3.9.2 UPSI The UPSI switches that were on the 1401s got a second life in DOS with the System/360. UPSI can be tested in RPG, Assembler and in COBOL. For more information on the manipulation of UPSI with Assembler see Chapter 13, “Assembler” on page 267. In OS/390, COBOL and RPG support UPSI through the PARM= on the EXEC statement. There is no support for UPSI in Assembler or PL/I.
The VSE file-id (the label), which can be up to 17 characters long, is equivalent to the MVS DSname, which can be up to 44 characters long. 4.3.10.4 MTC Statement Magnetic Tape Control statements provide control over tape processing including writing tape marks and unloading tapes. MTC has no direct equivalent in MVS: OPEN automatically positions the tapes based on the LABEL parameter of the DD statement and CLOSE rewinds or unloads volumes, depending on the DISP parameter.
location for these. In OS/390 these duplicate names need to be resolved somehow. Refer to Chapter 5, “Disk and Tape Storage Considerations” on page 97. 4.3.10.9 Conditional JCL VSE/ESA added conditional JCL processing in the early 1980s, with VSE/SP Version 2. This conditional JCL is characterized by several new JCL statements, including // IF, // GOTO, // ON, and /.
COND Parameter on the EXEC Statement To indicate the results of its execution, a program can issue a return code. Using a COND parameter, you can test the return code and, based on the test, either bypass or execute a step. The COND parameter can be specified on either a JOB or EXEC statement. See the JCL User ′ s Guide for explanation and examples. Chapter 4.
4.3.12 Comparison of VSE and MVS JCL - A Summary Below is a summary of VSE JCL statements and possible equivalents in MVS. Table 7 (Page 1 of 2). VSE Job Control Statements Summary 86 VSE Statement Function MVS Equivalent ASSGN Used at execution time to assign a specific device address to the symbolic unit name used. // DD UNIT= CLOSE Closes either a system or a programmer logical unit assigned to tape, disk, or diskette. No equivalent in OS/390.
Table 7 (Page 2 of 2). VSE Job Control Statements Summary VSE Statement Function MVS Equivalent ON Causes specified action to be done if the specified condition is true after any step in the following job stream. // EXEC COND= or //IF/ENDIF OPTION Sets one or more of the job control options. // EXEC PARM= PAUSE Causes a pause immediately after processing this statement, or at the end of the current job step. No equivalent in OS/390.
4.3.13 Summary of MVS JCL Statements Table 8. MVS Job Control Statements 88 JCL Statement Purpose // command Enters an MVS system operator command through the input stream. The command statement is used primarily by the operator. Use the COMMAND statement instead of the JCL command statement. // COMMAND Specifies an MVS or JES command that the system issues when the JCL is converted. Use the COMMAND statement instead of the JCL command statement. //* comment Contains comments.
4.4 JECL JECL is very important in VSE and is commonly used. The difficulty from a conversion standpoint is to determine where the job is due to having two different job cards in JCL. The JECL statement is a POWER job, the DOS Job or VSE Job is the // JOB. The POWER job is like the MVS JOB. This is where the class and priority information is specified. It exists at the beginning of a job stream. JES control statements are not recommended for new applications.
Table 9 (Page 2 of 2). Overview of POWER JECL Statements POWER Statement Function JES2 or MVS Equivalent * $$ FLS Indicates that a VSE/POWER job should be terminated by internal flushing. /*PURGE if INTRDR * $$ JOB Indicates the beginning of a VSE/POWER job and specifies the routing of jobs, output, and notify messages. // JOB * $$ LST Provides handling information for printer output; routes list output to a node.
Table 10 (Page 2 of 2). JES2 Control Statements Statement Purpose Comments /*ROUTE PRT or /*ROUTE PUN Specifies the default print or punch destination for the job. Use the // OUTPUT DEFAULT=YES instead. /*SETUP Requests mounting of volumes needed for the job. Seldom used. (Similar to VSE PAUSE statement) /*SIGNOFF Ends a remote job stream processing session. BSC RJE Workstation use only. /*SIGNON Begins a remote job stream processing session. BSC RJE Workstation use only.
job (all definitions available to all steps). OS/390 operation does not perform this ″carry-over″ (unique to VSE). 4.5.1 Sample VSE JCL This example shows one POWER job containing three VSE jobs.
4.5.2 Sample MVS JCL The task surrounding the conversion of JCL is more than mapping between VSE JCL using this syntax and MVS JCL using that syntax. At the base of these two JCLs are different philosophies. A parameter by parameter comparison is insufficient. Comparing the VSE DLBL/EXTENT to a DD Statement is only part of the story. These examples are meant to give the read only a ″flavor″ for what changes have to take place. It is necessary to look at the two systems at a higher level as well.
A method that used two SYSOUT devices and output two DCBs in the program could also work. 3. PROGRAM2 Changes PROGRAM2 has to change for OS/390 to simulate the imbedded LST cards in the VSE job (for DEST=KCJONES and DEST=HERBERT). PROGRAM1 was OK as far as file assignments. 4.5.3 Sample VSE plus Carry-Over In this example the job cards for JOB2 and JOB3 have been commented out making this a POWER job that contains one VSE job with three jobsteps.
** JOB JOB3 PRINT REPORT // EXEC PROGRAM2,SIZE=300K * $$ LST LST=SYS010,DEST=KCJONES 01 ENDICOTT * $$ LST LST=SYS010,DEST=HERBERT 02 BOEBLINGEN /* /& * $$ EOJ Chapter 4.
96 VSE to OS/390 Migration Workbook
Chapter 5. Disk and Tape Storage Considerations The VSE/SP and VSE/ESA systems and MVS and OS/390 systems have some conceptual similarities and data compatibilities for disk and tape files. This chapter will discuss the similarities and differences between the VSE and OS/390 environments in the following areas: • 5.1, Access Method Similarities and Differences • 5.2, Data Set Naming Considerations • 5.3, Storage and Space Management • 5.4, Tape Similarities and Differences • 5.
DAM (or BDAM) Direct Access Method (or Basic Direct Access Method) -- used for disk devices. Still in some use, but often replaced by VSAM functions in many VSE shops. Generally requires complex application handling for processing, and may be dependent upon physical device characteristics. Not supported on Fixed-Block Architecture disks. In OS/390, BDAM is the functional equivalent. Libraries VSE Librarian should be considered an access method, as it meets all the criteria specified above.
In OS/390, the application program linkage is handled through the SVC interfaces of the operating system. In either case, the application program functional request (GET, PUT, and so on) will cause the next logical record to be retrieved from a buffer or from external media. Channel programs are created, and the operating system will cause the channel programs to be scheduled to perform any physical I/O operations required by the functional request. 5.1.
As it is desirable from both performance and integrity perspectives to separate user data sets into several user catalogs, it is critical that data set names be defined with the above information in mind. If, for example, all data set names begin with CUSTOMER as the first node, then all the data sets will be defined in only one user catalog. If the high order node for some data sets is PAYROLL, and for others INVENTRY, then these data sets could be split between two user catalogs if desired.
functional components as well as RACF and DFSORT. For details, see section 1.3 in the DFSMS/MVS General Information , GC26-4900. • DFSMSdfp is an OS/390 base element and functional component of DFSMS/MVS. It provides the storage, program, data, and device management functions of MVS.
For more information on the benefits of system-managed storage, refer to the following publications: DFSMS/MVS General Information , GC26-4900 Implementing System-Managed Storage , SC26-3123 DFSMS/MVS Planning for Installation , SC26-4919 RACF General Information , GC23-3723 Getting Started with DFSORT , SC26-4109 5.3.
DFSMS FIT is documented in the following IBM International Technical Support Organization publications (Redbooks): Get DFSMS FIT: Fast Implementation Techniques , SG24-2568 DFSMS FIT: Fast Implementation Techniques Process Guide , SG24-4478 DFSMS FIT: Fast Implementation Techniques Installation Examples , SG24-2569 In conjunction with DFSMS FIT, you can use NaviQuest. NaviQuest is a component of DFSMSdfp and is an option from the ISMF panels.
VOL1 HDR1 and HDR2 EOV1 and EOV2 EOF1 and EOF2 UHL1 - UHL8 UTL1 - UTL8 v o l u m e label data set header label data set trailer labels (end of volume) data set trailer labels (end of data set) user header labels user trailer labels Note: UHL and UTL processing are user standard labels.
• • • • • block length record length tape recording technique (seven-track only) tape density record format to the OS/390 system. This information was coded in VSE programs. However, it is strongly recommended that this data be removed from VSE programs as they are being converted to OS/390 versions. Place the above data in the DCB subparameter of the DD JCL statement specifying the tape file. 5.4.2.
statement. If a tapemark might precede the first data set and you specify the LABEL subparameter LTM, OS/390 tests for and bypasses a leading tapemark, if present. If a tapemark precedes the first data set and you do not specify LTM in the LABEL parameter field, you must add one to the data set sequence number. If a multivolume data set has a leading tapemark on one or more of the volumes, OS/390 can process it as an unlabeled multivolume data set if the LABEL subparameter LTM is specified.
A. VSE: With Tapemark Before Data Records ┌─────┬───────────────────┬─────┬─────┐ │ TM │ Data Records 1-n │ TM │ TM │ └─────┴───────────────────┴─────┴─────┘ B. VSE: Without Tapemark Before Data Records ┌───────────────────┬─────┬─────┐ │ Data Records 1-n │ TM │ TM │ └───────────────────┴─────┴─────┘ 1. On input, IOCS can handle files with or without a tapemark preceding the data records. 2. For multivolume files, only one tapemark is written at the end of each volume except the last.
5.5 DASD Similarities and Differences 5.5.1 Volume Interchangeability DASD file label conventions, requirements, and handling techniques differ between VSE and OS/390 systems. However, OS/390 should be able to read and process DASD volumes that have been created on a VSE system. Similarly, VSE systems should be able to read volumes created by OS/390 systems. The following exceptions to this are noted below.
maintaining the accuracy of the Format-5 DSCB. The Format-5 DSCB , sometimes called the ″free space DSCB″, is used only by OS/390. OS/390 keeps track of unallocated space on a volume by creating one or more Format-5 DSCBs; that is, each Format-5 contains up to 26 extents of free space information. VSE, although it doesn′t keep track of free space on a volume, will still be able to process a volume created by OS/390 (and on which a Format-5 DSCB is located).
5.6 VSAM Differences 5.6.1 Introduction This section covers the differences between OS/390 VSAM and VSE/VSAM. In OS/390, the functions of VSAM and other OS/390 access methods are provided by the OS/390 Data Facility Product (DFP). The term ICF refers to the Integrated Catalog Facility. The term AMS refers to Access Method Services and/or the program IDCAMS. All data set references are to VSAM data sets.
• OS CVOL catalogs - these are a carry-over from the past (pre-OS/390) and are non-VSAM in structure. It has also been announced that OS CVOL catalogs will not be supported after December 31st 1999. For these reasons, they should not be implemented in your OS/390 system. 5.6.2.1 Integrated Catalog Facility (ICF) The architecture of an ICF catalog is quite different from that of a VSAM catalog.
If access to a disk volume is lost, DFSMShsm can be used to perform a full-volume restore with update. You specify ICF catalog format by including the ICFCATALOG keyword in the AMS DEFINE MASTERCATALOG or DEFINE USERCATALOG command. ICFCATALOG is the default when defining a catalog in OS/390. VSAM data sets cataloged in ICF catalogs have the UNIQUE attribute -- their space is not owned nor managed by VSAM.
Item G023729 Last updated....: 10/13/1997 Abstract........: WSC FLASH 9741 VSAM CATALOG AND CVOL SUPPORT ENDS IN YR2000 Access to an MVS or OS/390 non-ICF VSAM catalog or CVOL will not be possible after 1999. The following text was taken from the DFSMS/MVS 1.
When the system date is on or after 1/1/2000, the following reason code will be issued: ″34 - Explanation: An attempt was made to open a VSAM catalog for use as a catalog. The request was denied. Programmer Response: VSAM catalogs may not be used beginning Jan 1, 2000.″ Please note that CVOL support will also be removed effective 1/1/2000 but as yet no way to provide warning messages has been identified. Customers running operating environments prior to DFSMS/MVS 1.
IPL unit_address LOADPARM where LOADPARM bytes contain: bytes 1--4 5--6 7 8 ┌──────────────┬────────────┬─────────────┬─────────────┐ │ IODF DASD │ LOADxx │PROMPT FEAT. │ ALT NUCx │ └──────────────┴────────────┴─────────────┴─────────────┘ IODF LOADxx prompt nucleus device suffix feature suffix number See Managing Catalogs , SC26-4914, chapter 2. You must ensure that all OS/390 data sets required for IPL are cataloged in all catalogs that might be used as an alternate master catalog.
The data set names of the user catalogs are contained in the OS/390 master catalog. Information necessary to locate the user catalogs is also defined in the master catalog. The high-level-qualifiers of data sets that are to be cataloged in each user catalog are also identified in the OS/390 master catalog. OS/390 data set names are divided into qualifiers. The data set name consists of up to 44 characters, grouped into qualifiers of up to eight characters each, separated by periods. For example ″DEPT1.
Do not use JOBCAT or STEPCAT statements in OS/390 In predecessors of today′s OS/390 systems, it was not uncommon to use JCL DD statements specifying user catalogs to be used for a job or a step (JOBCAT or STEPCAT). This procedure was obsoleted with the advent of the Integrated Catalog Facility and its ALIAS mechanism, and it should not be used. The OS/390 JOBCAT and STEPCAT DD statements when used in jobstreams, bypass the normal catalog search technique via the ALIAS.
5.6.4.1 Accessing a VSE/VSAM Catalog from an OS/390 System Your migration plan might include the requirement to access VSE/VSAM catalogs from the OS/390 system. Under no circumstances should you attempt to share VSAM catalogs or data sets between OS/390 and VSE/VSAM concurrently. There is no system data integrity provided for concurrent access sharing. Loss of data may occur. If OS/390 access to a VSE/VSAM catalog is necessary, the following procedures should be used: 1.
5.6.4.3 Moving a VSAM Catalog to a Different DASD Type VSE/VSAM provided no facility for moving a catalog to a different device type or volume serial number. OS/390 VSAM provides this facility for ICF catalogs via the AMS REPRO and EXPORT/IMPORT commands. Using the REPRO function, you may specify the old catalog as the input and the new catalog as output. The new catalog must already have been defined but it may be a different DASD device type and it must be a different volume serial number.
• VSE/VSAM-managed SAM files − − − Default models NOALLOCATION data sets Implicit JCL DEFINE • Reusable data sets • Partition independent file names • VSE/VSAM BACKUP/RESTORE and VSE FASTCOPY • IKQVDU - volume cleanup • IKQVCHK - catalog check • Space classes • VSAM SHAREOPTIONS (SHR(4) and SHR(4 4) differences) 5.6.5.2 FBA DASD Fixed Block Architecture (FBA) DASD devices such as the 3370, 3310, 9332, 9335, 9336, and FBA virtual disks are not supported by OS/390.
maintain the ″VSAM Ownership Bit″ in the VTOC, and the list of volumes owned by the catalog. Under VSE, multiple VSAM catalogs can own space on the same DASD volume, as long as only one recoverable catalog owns space on that volume. This support has been provided by adding a VSE unique ″bit map″ in the VSAM catalog, identifying the space that is owned by a particular catalog, on a particular volume. This is not supported with OS/390 VSAM. Only one VSAM catalog can own VSAM space on a volume.
VSE/ESA Version 2.2 included new VSAM support for compression of VSAM data sets. The implementations of the two VSAM systems are not compatible, due to the differences between VSAM catalogs used by VSE, and ICF catalogs used by OS/390. COMPRESSED data sets defined in VSE will have to be unloaded from VSE and reloaded in OS/390. REPRO or EXPORT/IMPORT can be used for this unload/reload function.
VSE SAM/VSAM data sets may also be converted to VSAM ESDS data sets. However, this is not recommended as it requires changes to the programs. Default Models Both VSE and OS/390 VSAM support the MODEL parameter of the DEFINE command. This allows the attributes of an existing file to be used during the define of a new file. VSE/VSAM also supports three types of model data sets through the AMS DEFINE NOALLOCATION command. OS/390 VSAM does not support the NOALLOCATION parameter.
• • acts as an ACB without RESET (add new records to existing file) DISP=OLD overrides IDCAMS REPRO with REUSE To rewrite a reusable data set / / DLBL .....,VSAM,DISP=NEW • • acts as an ACB with RESET (delete old records, add new records) DISP=NEW overrides IDCAMS REPRO with NOREUSE Partition Independent File Names VSE/VSAM partition independent file names start with the character % or characters %%, for example %MY.FILE.
in the VTOC. This equivalent function is performed in OS/390 VSAM by the AMS command ALTER REMOVEVOLUMES. The volume cleanup function of ″ALTER REMOVEVOLUMES″ should only be used when the catalog is not accessible or totally unavailable. This command may also be used to remove candidate volumes as in VSE/VSAM. IKQVCHK - Catalog Check This VSE/VSAM utility does not exist in OS/390 VSAM. The AMS DIAGNOSE and EXAMINE commands provide an equivalent function.
5.6.6.1 Cross-Region Sharing - Single CPU Environment Whenever a VSAM data set (ACB) is opened by more than one control block structure concurrently, data integrity must be considered. OS/390 VSAM offers two levels of protection and/or sharing within a single CPU. 1. OS/390 will prevent concurrent update/update or update/read access to a VSAM data set if DISP=OLD is coded on the JCL DD statement. If DISP=OLD is specified, the shareoptions will be treated as (1 3).
OS/390 VSAM Cross-Region SHR(4) VSE VSAM SHR(4 x) will refresh buffers from disk for every read I/O, and will also lock the record, CI, or CA as appropriate to protect the file and user data from corruption by possible concurrent update activity. SHR(4) data sets can have inserts or updates which may cause CI and CA splits, and secondary allocations can also safely be handled by VSE/VSAM. OS/390 VSAM SHR(4 x) works very differently than VSE/VSAM.
5.6.6.2 Single Region Data Set Sharing Single ACB Open - Multiple String Processing Full write integrity is provided within a single region provided the user uses a single ACB to process the data set. In high level languages an ACB equates to: 1. a SELECT statement in COBOL 2. a file DECLARE in PL/I 3. an ″F″ statement in RPG II If multiple ACBs (or high level language equivalents) are used, the protection of shareoptions must be relied upon unless DSNAME sharing is used (both COBOL and PL/I always use it).
5.6.6.3 Cross-System and DASD Sharing You are in a cross-system sharing environment whenever you allow more than one copy of any operating system to access the same DASD volume concurrently. This includes multiple OS/390 guests running under VM or PR/SM. You must not attempt to update via DASD sharing between VSE and OS/390 systems.
• Planning for Installation • DFSMSdfp Storage Administration Reference • Using Data Sets SHAREOPTIONS (X 4) Cross-system SHR(x 4) provides the same limited protection across systems as cross-region SHR(4). Extensions of the data set′s high-used RBA are prohibited. To provide complete integrity protection it is the user′s responsibility to write Assembler routines using the RESERVE/RELEASE macros in addition to the ENQ/DEQ macros required for cross-region. This is a complex undertaking.
This provides cross address space sharing as well as journaling and recovery for the batch applications. It also allows existing files to be accessed with new application tools such as QMF without having to rewrite existing applications. 5.6.7 Programming Languages and VSAM Support For additional information on program languages and VSAM considerations, see the various language chapters in this publication.
perform a DFSORT COPY function to copy the temporary data set back into the original SORTIN VSAM data set. 2. Sorting multiple VSAM data sets in the same step. VSE SORTs allow multiple inputs through multiple SORTIN(n) DLBL or TLBL statements. DFSORT allows only one input to sort, the SORTIN DD statement. Through OS/390 JCL, multiple sequential data sets may be concatenated, but VSAM data sets may not be concatenated.
Chapter 6. CICS 6.1 Introduction This section is directed to individuals with a working knowledge of both CICS for VSE/ESA and CICS Transaction Server. Without this knowledge, a reader may find this section less fulfilling. Also, you should understand that the scope of this section is to provide general migration tasks and considerations, and should not be considered a replacement for the manuals referenced in this section and/or an individual CICS migration experience.
• • • • • • Enhanced interface to the World Wide Web (WWW) adds support for 3270-based transactions. The CICS Gateway for Java has been ported for execution on OS/390 as an OpenEdition (R) application with CICS TS as the CICS server in a two-tier configuration. REXX for CICS (Development and Runtime) added as two new elements of CICS TS.
Please contact your local IBM Representative for more information on how to access IBM manuals via the INTERNET. Another useful INTERNET location ′http://www.hursley.ibm.com/cics′, is the CICS home page. The CICS Internet Home page provides a service/support segment that allows easy access to a wide range of material that complements the CICS Family of products. As part of the Service and Support segment, user forums are available for CICS migration tidbits and Qs and As.
application programs may be placed above the 16 megabyte line if they are written in VS COBOL II, PL/I, C++ or HLASM. If you have a need to combine systems or you are adding new CICS applications that could introduce additional virtual storage constraints, you should consider the use of CICS Multiple Region Operation (MRO).
to SYSLST, access to CICS system control blocks. You should consider what impact each of the removed service or support will have on your migration. Macro-level programs You need to convert macro-level programs to command level. Please account for and anticipate the additional CPU requirements for the converted programs. BTAM devices and controllers As an alternative consider the supported devices of ACF/VTAM and/or TCP/IP.
Access to CICS system control blocks CICS management modules are provided as pregenerated systems for MVS. All the functional areas in CICS are provided completely in object-code only form (OCO), without licensed source materials. Thus, you can not modify the CICS source as in your present releases.
┌────────────┐ ┌───────────────────┐ ┌───────────────────┐ │ ├────┤ Parameter manager │ │ Application ├────┤ │ │ domain (PA) │ │ domain (AP) │ │ │ └───────────────────┘ └───────────────────┘ │ │ ┌───────────────────┐ ┌───────────────────┐ │ ├────┤ Program manager │ │ CICS catalog ├────┤ │ │ domain (PG) │ │ domains (GC/LC) │ │ │ └───────────────────┘ └───────────────────┘ │ │ ┌───────────────────┐ ┌───────────────────┐ │ Kernel ├────┤ Recovery manager │ │ Directory manager ├────┤ │ │ domain (RM) │ │ domain (
CICS data table services RDO for VSAM files and LSR pools Some EXEC CICS system programming functions Autoinstall terminal model manager Partner resource manager SAA Communications and Resource Recovery Some of the file control functions Recovery manager connectors interfaces. Domains never communicate directly with each other. Calls between domains are routed through kernel linkage routines. Calls can be made only to official interfaces to the domains, and they must use the correct protocols.
Also, you should remove the parameters such as REUSE, RSL, and DEVICE from the DCT specification; these parameter are obsolete. Note: CICS TS provides a facility that allows an extrapartition data set to be used to submit jobs to MVS. FCT Remove the CSD entry from FCT (it is now in the SIT), plus all VSAM entries (VSAM resource entries are autoinstall) from the FCT, then re-assemble the FCT and migrate the table to the CSD. JCT ″INPUT″ JOUROPT and BUFSUV parameters are obsolete.
TCT review the entire table, particularly for BTAM changes. Add CONSLID=console designation for MVS Multiple Console Support (MCS). You must remove any spool parameter associated with CICS/VSE Report Controller Feature (RCF). SIT review all the entries since there are VSE and MVS only parameters. Plus, there are new and different suffixes for the pregenerated CICS/MVS management modules. For example: ABDUMP is removed because of CICS reconstructed dump facilities.
JCT The CICS log manager does not support journal data sets, making the journal control table obsolete. The CICS system log and journals are mapped to MVS system logger log streams (or, for some journals, SMF data sets) by means of JOURNALMODEL resource definitions. JSTATUS CICS log manager does not support journal data sets, on either disk or tape, making this initialization parameter obsolete. PLI removed because DOS PL/I is not supported.
Warning: When you migrate your CSD entries you must ensure that you do not copy over IBM supplied definitions in groups that you have defined. The reason is that some of the groups and resources were changed and/or deleted. Thus, you should see that your user groups with IBM defined resources are copied from the newly defined CSD.
TRANSACTION/RESTART this option now governs restart in two separate types of situation. TYPETERM/RECOVNOTIFY the scope of this parameter is extended to cover VTAM persistent sessions. In CICS/VSE this parameter was meaningful for CICS regions running with XRF only. 6.1.8 CICS System Data Sets Requirements Before you install your CICS data sets you should determine the DASD requirements for all CICS data sets and MVS data used by CICS. Below are the data sets needed to implement CICS TS.
┌───────────┬───────────┬─────────────────────────────────────────────┐ │ Coupling │ OS/390 │ Log stream possibilities │ │ facility? │ Version │ │ │ │ 2.4? │ │ ├───────────┼───────────┼─────────────────────────────────────────────┤ │ Yes │ No │ All must use CF. │ ├───────────┼───────────┼─────────────────────────────────────────────┤ │ No │ Yes │ All must use DASD-only.
6.1.9 CICS System Program Interface and Exits 6.1.9.1 System Programming Commands CICS system programming interface (SPI) commands provide you with the ability to access and modify CICS system information. SPI should be considered for CICS applications that presently modify and/or access CICS internal blocks.
Your program must be in primary-space translation mode when you invoke the XPI. (For information about translation modes, see the IBM ESA/370 Principles of Operation manual.) Notes: 1. You cannot use all of these calls at every global user exit point. You will find an indication of when these calls cannot be used both with the description of each function call, and in the list of exit points in the CICS Customization Guide .
You must rewrite all user-replaceable modules except for DFHACEE, DFHUAKP, DFHXSP and DFHXSE user-replaceable modules, which are obsolete. Also, the DFHNTRY is replaced by a new user-replaceable module DFHREST. Note: VSE/ESA System Package (SP) supplied a number of user exits and user replaceable modules, that are part of the packaging of VSE/ESA. As such these programs may be similar to other CICS supplied sample program, but are unique in what they offer VSE/ESA users.
Bit 0 SYSIPT overrides yes or no. All overrides are passed as execution parameters to DFHSIP. Bit 1 This is no longer required for CICS/OS or CICS/VSE 1.6 or later. Bit 2 Operator prompt for overrides yes or no. The parameter ′CONSOLE′ as the last PARM in the EXEC statement indicates that the operator is to be requested to enter overrides. Bit 3 If Dump returns a nonzero return code when writing to the SYSDUMP data set and an IDUMP will be produced on SYSLST. CICS/MVS DUMP is directed to MVS SYS1.
• RPG II is not a supported language for CICS/OS. RPG II programs should be converted to a supported application language (that is, COBOL, PL/I, C++, and or Assembler). • Programs that directly invoke operating system services. • Programs that directly access operating system control blocks. • Programs that access internal CICS control blocks (DSECTs). • The CICS/VSE Report Controller Feature (RCF) is not supported by CICS/MVS. This includes many suboperands of the EXEC CICS SPOOL commands.
functions are provided by the Application Support Facility for MVS (ASF), 5685-043. Some CICS programs written in assembler language may have to be reworked. These applications are more prone to violate the CICS API restrictions. Also, be sure to review all EXEC CICS commands for changes in VALUES. The name of the CSECT within module DFHECI changed from DFHECI to DFHELII. So, be sure that your LINKEDIT included DFHECI.
programs use CICS macros, which is very useful when you must determine your scope-of-effort. The CICS Application Migration Aid (5695-061), should be used to assist customers migrating macro-level programs to command-level programs. Please review the manual CICS/VSE Application Migration Aid Guide V2 , SC33-1901 for more detail. COBOL and CICS Command Level Conversion Aid for VSE (CCCA) - CCCA assists in the removal of BLL cell processing to ANSI 85 COBOL processing (5785-CCC).
• handling output from CICS dumps. • handling output from CICS trace. • handling output from CICS statistics. • problem determination. • restart and recovery requirements. • security administration. • application of software services. Identify and understand the different IBM and vendors support structures and procedures. You should have available: personal names of your contact points telephone numbers Therefore, you should see that your system management procedures are updated.
Chapter 7. ICCF and TSO DOS/VSE users of the Interactive Computing and Control Facility (ICCF) who migrate to OS/390 will find a very powerful interactive system available via OS/390′s Time Sharing Option (TSO/E) and related products, particularly the Interactive System Productivity Facility (ISPF). This section addresses the TSO/E and ISPF implementation of the common functions used in ICCF. It is not intended to be a complete list of the functions available to the TSO/E user. 7.
You may choose to assign account numbers to your users for accounting or other purposes. This account number can be from 1-40 alphameric characters, not containing a blank, tab, quotation mark, apostrophe, comma, semicolon, or line control character. You use the RACF ACCTNUM resource class to authorize use of account numbers. Please refer to the TSO/E Customization book or the RACF Security Administrator ′ s Guide for more details on account numbers.
7.1.2 LOGON Procedures In ICCF, a logon procedure may be specified in the user profile. This entry references an ICCF procedure or macro used to define the environment for this logon. These optional procedures or macros are normally defined by the user if they are present. In TSO/E, the LOGON procedure is not optional. The LOGON procedure defines the system resources available to a terminal user and defines or allows for dynamic allocation of all data sets used by a terminal user.
ICCF provides another level of security by defining ICCF libraries within DTSFILE as either PUBLIC, PRIVATE, or COMMON. All ICCF users have read access to data stored in the single COMMON library supported by ICCF. However, only ICCF users with a System Administrator level profile have write access to this library. Multiple PUBLIC ICCF libraries are supported in DTSFILE and are normally used to store data that can be read by any ICCF user, but updated only by the originator.
7.2.1 Accessing the System Since LOGON to TSO/E is dependent on the telecommunications access method used with TSO/E, the System Standards implemented by the Systems Programmer, and the related program products installed, you should reference the TSO/E Primer and your Systems Programmer for information on logging on to TSO/E. 7.2.2 Entering and Manipulating Data In ICCF, data is entered and stored as a member of an ICCF library. Data is restricted to 80 byte records in an ICCF library.
Descriptive Qualifier Data Set Contents LOADLIST Output listing from loader OBJ Object module OUTLIST Output listing from OUTPUT command PLI PL/I statements TESTLIST Output listing from TEST command TEXT Uppercase and lowercase text VSEBASIC VSBASIC statements Each field of a data set name consists of 1-8 alphameric characters and begins with an alphabetic or national ($, @, and #) character. The fields must be separated by periods.
7.3 Executing Programs at a Terminal Both ICCF, TSO/E, and ISPF provide commands to compile, link-edit, and execute (or compile and load) your source program at the terminal. They also allow you to use other programs, such as utilities at the terminal. Under ICCF programs that expect input from the console will read input from your terminal.
7.4 Submitting Jobs for Batch Execution ICCF allows users to submit jobs for batch execution through the SUBMIT procedure and an ICCF supplied program, DTSSUBMT. Tailoring of the SUBMIT procedure allows the ICCF System Administrator to provide system standards for execution and list and punch output. Listed output from the batch execution may be viewed at the terminal using the /LISTP command provided that the output is dispatchable and is not presently being printed by VSE/POWER.
7.4.1 Using Command Procedures Both ICCF and TSO/E provide the capability of storing frequently executed commands or lists of commands. In ICCF these stored commands are called Procedures or Macros. They are stored as an ICCF library member. In TSO/E they are called Command Lists (CLIST) or REXX execs. Besides issuing TSO/E commands, CLISTs can perform more complex programming tasks. The CLIST language includes the programming tools needed to write extensive, structured applications.
method over the first would be the total flexibility available in creating the tape input to IEBUPDTE and the JCL necessary to execute this MVS utility. The advantage of the first method is its ease of implementation.
&&IF &&PARAM1 EQ ′′ &&GOTO TAG3 &&SET &&VARBL3 &&PARAM1 &&LABEL TAG3 &&TYPE ENTER THE DESCRIPTIVE QUALIFIER FOR THE PDS TO BE CREATED &&TYPE THE DEFAULT WILL BE &&VARBL4 &&READ &&PARAMS &&IF &&PARAM1 EQ ′′ &&GOTO TAG4 &&SET &&VARBL4 &&PARAM 1 &&LABEL TAG4 &&TYPE ENTER TME DISK TYPE (IE 3350, 3375, 3380) FOR THE PDS &&READ &&PARAMS &&IF &&PARAM1 EQ ′′ &&GOTO -TAG4 &&SET &&VARBL5 &&PARAM1 &&LABEL TAG5 &&TYPE ENTER THE VOLUME SERIAL NUMBER OF THE DISK FOR THE PDS &&READ &&PARAMS &&IF &&PARAM1 EQ ′′ &&GO′ TO -T
&&OPTIONS 1100001 /LIB FULL ALL &&OPTIONS 0010001 /LOAD DTSPROCS /OPTION NOPROMPT &&OPTIONS 0010001 /LIST 1 1 IEBUPDTE &&IF &&RETCOD NE *READY &&GOTO TAG11 /PURGE IEBUPDTE &&LABEL TAG11 /INPUT NOPROMPT DUMMY LINE /END /SAVE IEBUPDTE /EDIT IEBUPDTE NEXT GET $$PUNCH TOP DEL 1 L SYSIN NEXT DEL 2 REPEAT * O XXXXX YYYYYYYYYYYYYYYYYYYYYYYYYYYYYY LUP SYSIN NEXT &&NOP C′ YYYYYYYYYYYYYYYYYYYYYYYYYYYYYY′ , LEVEL=00,SOURCE=0, LUP SYSIN NEXT &&NOP C′ XXXXX′ .
delete the first character of each record, and will delete the END OF MEMBER statements. The last statement placed on the output tape will be the IEBUPDTE statement ./ ENDUP. This tape will then become the input to the IEBUPDTE utility on an MVS system. Information about the PDS to be created will be contained in the MVS JCL used to invoke IEBUPDTE.
168 VSE to OS/390 Migration Workbook
Chapter 8. Databases 8.1 DL/I and IMS/VS DB Differences 8.1.1 Introduction This section addresses differences that exist between DL/I DOS/VS (Data Language/One DOS/VS) Release 1.8 and IMS/ESA (Information Management System/Enterprise Systems Architecture) Versions 5 and 6. In the context of this chapter, references to DL/I may be used interchangeably with DL/I DOS/VS or VSE DL/I. The following matrix highlights the various functions of DL/I that will require attention during conversion.
8.1.2 MVS System Requirements IMS/ESA requires a Type 2 SVC in the MVS nucleus and a Type 4 SVC in LPALIB. IMS/ESA Resource Clean-up Module and ABEND Dump Formatting Routine must be link-edited into SYS1.LPALIB. IMSESA.RESLIB must be APF authorized. 8.1.3 Data Base Descriptor (DBD) 1 Automatic field start calculation Must code START= in the IMS/ESA DBD. 2 Automatic segment length calculation Must code BYTES= in the IMS/ESA DBD.
SEQFLD= SEQVAL= SUPVAL= SUPRTN= SRCH= of XDFLD SUBSEQ= of XDFLD NULLVAL= of XDFLD EXTRTN= of XDFLD The non-ACCESS statement approach consists of an LCHILD and XDFLD following the target segment, SEGM statement, in the data portion of the database. Associated FIELD statements are needed in data DBD if /sx or /ck are used. An index DBD defining the index database with its LCHILD statement referencing the target segment in the database is also required. 8.1.
8.1.5.4 Statement Compatibility All batch programs using the calls, GU - GHU - GN - GHN - GNP - GHNP - ISRT DLET - REPL, are transportable to MVS with no modification to the DLI calls. Of course, these programs may need changes for other reasons and they must be recompiled on the MVS system. VSE JCL is changed to MVS JCL, and the DL/I parameters external to the program (that is, HSBFR and HDBFR bufferpool) are written differently even though they perform the same functions.
8.1.5.10 Assembler Language Calls CALLDLI MF=E is not supported in IMS/ESA. 8.1.6 Utilities Equivalents of all DL/I utility programs exist in IMS/ESA. Their functions are similar, but it is necessary to change the JCL from VSE to MVS and utility control statements from DL/I to IMS/ESA. There are variations in the utilities between DL/I and IMS/ESA that will require procedural changes. • Partial HD Reload is not supported in IMS/ESA. • Selective HD Unload is not supported in IMS/ESA.
8.1.7.2 Backout Utility/Disk Logging IMS/ESA supports both DASD and tape logging in batch. The archive utility DFSUARC0, is used to copy disk logs to tape. Disk is acceptable as input to all IMS/ESA utilities including backout. 8.1.7.3 UPSI The use of the UPSI byte is not supported by MVS. The equivalents for the various bits are: • Bit 0: Reading of parameter statement. This function is replaced with parameters in the EXEC statement of the MVS JCL. • Bits 1-3: Available to the application programmer.
8.1.8 Database Portability There are two fundamental approaches to making your DL/I databases available to IMS/ESA. One is to unload the database using DL/I utilities and reload it using IMS/ESA utilities. The other is to ″position″ your DL/I databases using DL/I and IMS/ESA compatibility options in the DBD during a normal database reorganization under DL/I. Since database reorganization involves considerable processing for large and complex databases, ″positioning″ may offer some advantages.
Recovery of DL/I - IMS/ESA compatible databases require special procedures. Image copy, change accumulation, and log files are not compatible between DL/I and IMS/ESA. The recovering of database changes performed under DL/I must be performed using DL/I image copy, change accumulation, and log files with DL/I utilities; and the recovering of database changes performed under IMS/ESA must be performed using IMS/ESA image copy, change accumulation, and log files with IMS/ESA utilities.
┌───────────┐ │ DL/I DBD │ └─────┬─────┘ ┌───────────┐ │ │ MVS GEN │ │ └─────┬─────┘ │ ┌───────────┐ │ │ UNLOAD DB │ └─────┬─────┘ ┌───────────┐ │ │ IMS GEN │ │ └─────┬─────┘ ┌───────────┐ yes ┌───────────┐ ┌───────────┐ │ IMSCOMP ? ├─────────────── │ DL/I DBD │ │ MVS ADDS │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │no ┌───────────────┐ │ │ VSAM CHANGES │ ┌───────────┐ no │ └───────┬───────┘ │ IMSCOMP ? ├───────────── │ └─────┬─────┘ ┌───────────────┐ │ ┌───────────┐ │ RELOAD DL/I DB│ │
8.1.9 DL/I Multiple Partition Support Conversion to IMS/ESA BMPs (Batch Message Processing programs) running under DBCTL should be considered as an alternative to CICS/OS Shared Data Base or IMS/ESA Data Sharing support. 8.1.10 Additional Information A recently announced Redbook, Interoperability between VSE DL/I and OS/390 IMS DBCTL , SG24-5249, can provide additional conversion information. 8.
systems and security folks. This is not to say that differences do not exist, just that they are minor and should not be perceived by most end users. QMF users should see virtually no differences. The one possible exception is the TRANSLATE scalar function which is not supported by DB2. 8.2.1.2 Application Developers While end users will see little or no differences, application developers can expect to see more differences between the two products.
8.2.1.3 Database Administrators (DBAs) As with the previous two groups discussed, there are really more similarities than differences between the two products for the DBA. The design methodology is the same, whether you prefer normalization or some other technique. The optimizer selects access paths basically the same way, relieving the DBA from making this choice. Differences show up in some of the detail work of database design.
At the physical level, in DB2 each tablespace is stored in a pageset, which consists of one or multiple VSAM ESDS data sets or LDSs. In SQL/DS, data is stored in storage pools that are composed of one or more dbextents. In VSE, a dbextent consists of one VSAM ESDS data set. While this may seem similar, the difference is that in DB2 one VSAM data set is used for only one tablespace. In SQL/DS, one VSAM data set can be used to store data from any or all tables in the system (within one storage group).
• http://www.software.ibm.com/year2000/db2-html SQL/DS Version 5 (proper name is DB2 for VSE Version 5) is Year 2000 compliant. 8.2.2.2 DRDA Considerations DRDA level of functions in SQL/DS are upward compatible to DRDA functions in DB2. DB2 has more DRDA functions than SQL/DS. For the DRDA Remote Unit of Work (RUW) level, DB2 is compliant as an Application Requestor (AR) and Application Server (AS). SQL/DS is only on the AS level for RUW.
7 Migrate the user queries 8 Migrate user profiles and authorizations 9 Change operational procedures to reflect new backup/recovery, problem determination and startup/shutdown procedures Chapter 8.
184 VSE to OS/390 Migration Workbook
Chapter 9. Telecommunications Subsystems VSE and OS/390 platforms rely on the same set of communications products and protocols. Although the product sets are the same, some differences exist in product implementation and usage. The differences are primarily related to the operating systems and their file structures. This chapter will discuss the similarities and differences between VSE and OS/390 environments for the following telecommunications products: • 9.1, ACF/VTAM • 9.2, ACF/NCP • 9.
9.1.1 Product Installation The VTAM installation procedures for OS/390 are very different from those for VSE, since this is the area where the operating system differences are most influential. To install OS/390 VTAM you must perform the following steps: • Allocate data sets for VTAM. OS/390 VTAM can make use of a large number of data sets, depending on the options selected. In 9.1.1.
(from ACF/SSP) and user-written VTAM exits. In our example STEPLIB points to the ACF/SSP library which contains the NCP loader. Any libraries defined by STEPLIB are PDSs containing load modules, and have similar DCB characteristics to SYS1.LINKLIB. 4 VTAMLIB contains VTAM tables which are assembled and linked, such as the subarea Class of Service table and the various mode tables. Again, VTAMLIB is a load module PDS with DCB=(RECFM=U) and an appropriate block size.
The current supported levels of VTAM on VSE are V3R4 and V4R2. VSE VTAM V4R2 is available in three different functional level packages: • Client/Server • MultiDomain • InterEnterprise Packages are priced according to the amount of function provided and are password enabled via the VTAM start procedure. The eNetwork Communications Server for OS/390 is only available in a single flavor, which is the functional equivalent of the high end VSE/VTAM package (InterEnterprise).
The 3174 with a Token-Ring or Ethernet adapter provides direct connection to Token-Ring and Ethernet LANs. The Open Systems Adapter (OSA) on the CMOS processors provides direct connection to Token-Ring, Ethernet and FDDI LANs. It also supports native ATM connections for VTAM V4R4 and above. The 3172 Interconnect Controller provides direct attachment to Token-Ring, Ethernet and FDDI LANs.
without disruption. Sessions are simply taken over by a new copy of the application running in the same, or a different, processor. 9.1.2.1 Resource Definition The OS/390 VTAM resource definitions are stored in the VTAMLST data set. Most of the VSE/VTAM resource definitions (B-books), typically stored in the PRD2.CONFIG VSE library, can be moved directly into the VTAMLST data set without modification.
9.1.3.2 Programming Any coding done under VSE, such as VTAM exits, will almost certainly need rewriting (and will certainly need re-linking) for the OS/390 environment. Also, some VTAM exit routines may be implemented differently under VSE and OS/390. User-written VTAM programs and exits must be reviewed carefully for compatibility. Please refer to the chapter Operating System Facilities in the VTAM Programming manual. 9.1.
9.2 ACF/NCP ACF/NCP in a 37XX controller may itself be completely independent of the operating system in the host, but the generation and loading of such an NCP is very much dependent on the operating system. 9.2.1 Product Installation Differences in the installation procedures of NCP for VSE and OS/390 are basically the same as those for VTAM. The main steps required to implement an NCP under OS/390 are: • Allocate data sets for use by NCP and the generation process.
• On the PCCU statement there are DUMPDS, MDUMPDS and CDUMPDS keywords which refer to various data sets which will contain NCP dumps. Code the names of the DD statements in the VTAM procedure which will point to the actual data sets. • On the BUILD statement, the LOADLIB keyword specifies the DD name of the data set which VTAM will use to find the NCP when the time comes to load it. The name you code must be in the VTAM start procedure (NCPLOAD in the example). 9.2.
One of the reasons why TCP/IP is so popular is that there are many simple and useful standard applications available. The TCP/IP on VSE/ESA for example provides standard applications such as Telnet, FTP, LPR/LPD and the HTTP Web server. Using these standard TCP/IP applications and standard TCP/IP APIs for user written applications also allows an easy migration from one TCP/IP platform to another. The VSE products on which the following migration discussion is based are TCP/IP for VSE/ESA 1.
9.4.2 TCP/IP Configuration First of all, configure the UNIX System Services (part of the OS/390 base product) in order to enable TCP/IP on OS/390. As a second step you will have to customize TCP/IP on OS/390. 9.4.2.1 TCP/IP Customization On VSE/ESA, almost all TCP/IP customization information is located in one file, the IPINIT.L initialization file. It contains all the required TCP/IP definitions such as the physical network, links, routing tables, user IDs, and TCP/IP daemons.
9.4.5.1 TCP/IP Applications using the Sockets API for Assembler VSE/ESA applications based on the SOCKET Assembler macro cannot be used on an OS/390 system. They have to be recoded for the OS/390 TCP/IP. 9.4.5.2 TCP/IP Applications using the Preprocessor API The HLL preprocessor API which is available on VSE/ESA for PL/I, Assembler and COBOL is not compatible with the OS/390 TCP/IP interfaces. Therefore, these programs have to be recoded for the OS/390 system as well. 9.4.5.
9.4.7 Bibliography VSE/ESA SC33-6601 SG24-2041 SG24-2040 SC33-6686 TCP/IP for VSE/ESA User ′ s Guide The Native TCP/IP Solution for VSE VSE/ESA as a Web Server Writing Interlanguage Communication Applications OS/390 SC28-1890 SC28-1906 GC28-1920 SC28-1915 OS/390 OpenEdition MVS Planning OS/390 OpenEdition MVS Communications Server Guide OS/390 Security Server (RACF) Planning: Installation and Migration OS/390 Security Server (RACF) Security Administrator 9.
• your MQSeries based applications. In the next sections each of these topics will be addressed at a general level. No detailed checklists or migration guidelines are given. This would go beyond the scope of this chapter. The purpose of this discussion is to make you aware of the areas which need to be studied in detail when you intend to migrate. Only straight forward migration is considered.
The following list shows the required products with product numbers: • VSE/ESA Version 1.4 (5750-ACD) in ESA mode, with: CICS for VSE/ESA Version 2.3 (5686-026) IBM Language Environment (LE) for VSE Runtime Library (5686-067) ACF/VTAM for VSE/ESA V3.4 (5666-363) or • VSE/ESA Version 2.1 (5690-VSE), with: CICS for VSE/ESA Version 2.3 (5686-026) IBM Language Environment (LE) for VSE Runtime Library (5686-067) ACF/VTAM for VSE/ESA V4.
The following languages and compilers are supported for MQSeries applications: • Assembler Assembler H (5668-962) IBM High level assembler MVS (5696-234) • COBOL VS COBOL II (5668-958) IBM COBOL for MVS & VM Release 2 (5688-197) • C C/370 Release 2.1.0 (with APAR UN37741) (5688-187) IBM SAA AD/Cycle C/370 (5688-216) • PL/I OS PL/I Optimizing Compiler (5668-910) SAA AD/Cycle PL/I Compiler (5688-235) • Java OS/390 Java Development Kit 1.0.2 available at http://ncc.hursley.ibm.
• install required CICS and IMS adapters • define queues • set up distributed queuing Customization is described in detail in the MQSeries for MVS/ESA System Management Guide . Only the steps which are related to migration are discussed in some more detail in the following sections. After the installation and customization has been completed, you can use an installation verification program (IVP) supplied with the product to verify that the installation has been completed successfully.
an MQSeries termination, and automatic resource resynchronization after a restart. The CICS adapter is supplied with MQSeries as the CICS transaction CKQC. 9.5.1.4 Data Sets MQSeries for VSE/ESA uses the following data sets: • the System Setup file: a VSAM ESDS file containing system setup information. It is only used once to initialize the System Configuration file. • the System Configuration file: a VSAM KSDS file.
9.5.2 Networking Definitions You will have some other systems with an MQSeries product installed which are connected to your VSE/ESA to allow MQSeries applications to communicate. When you migrate your VSE/ESA to OS/390 you will have to re-establish connection to those systems. In this section we will discuss the networking considerations. There are also MQSeries definitions which refer to remote MQSeries systems. These are discussed in the next section.
4. namelists 5. process definitions 6. storage classes These objects can be manipulated, that is, defined, deleted, changed, by the MQSeries commands. Commands can be issued from: • the initialization input data sets • the MVS console • the system-command input queue • the COMMAND function of the CSQUTIL utility • the operations and control panels using ISPF. When you migrate to a CICS/ESA environment, your channels are special.
• for channel definitions under CICS/ESA find matching channel attributes in MQSeries Distributed Queuing Guide , SC33-1139 • define the channels using the CKMC CICS transaction. Note: Make sure that you use the same queue names in your OS/390 related definitions which you used under VSE/ESA whenever possible. This will minimize application changes.
No special considerations apply to the compile and link step under VSE/ESA except that the product library which contains MQSeries for VSE/ESA has to be in the library chain during compilation. You have to set up jobs to compile and link the program under OS/390. General considerations how to do this for a CICS COBOL application are described in the respective chapters in this book.
Chapter 10. POWER and JES2 10.1 JES2 Introduction VSE uses POWER as a spooling system. MVS uses either JES2 or JES3 as spooling systems. This chapter only addresses migrations from POWER to JES2. While POWER and JES2 are similar in their overall function, they are very different in design and specific implementations. Because of these differences in processing spool output, you may have to redesign some of your output procedures when migrating to MVS.
10.1.1.2 Time Event Scheduling for Jobs POWER supports the scheduling of job submission based on a one-time or repetitive schedule such as daily, weekly on a given day and time, and so on. JES2 has a primitive ″automatic command scheduling″ facility, but you will probably need an automated job scheduling package in OS/390 to do the same things you were doing with POWER. 10.1.1.
can write your own using JES2 exit 1. (For PSF controlled printers, use PSF exits APSUX01 and APSUX02.) For separators between individual data sets or data set copies, you must specify SEPDS=YES on the PRT(nnnn) statement and provide a JES2 Exit 15 for JES2 controlled printers. (For PSF controlled printers, use PSF exit APSUX03.) 10.1.1.6 End-of-page Sensing POWER, by storing a carriage control tape image, allows a program to ″sense″ channel 12 or end-of-page. This is not supported in JES2.
POWER | ┌──────────────┐ │ │ │ Queue file │ │ │ │ │ └──────────────┘ | | | | JES2 ┌──────────────┐ │ Checkpoint │─┐ │ Data set │ │ │ (Incl.
JES2 initialization options described in Chapter 1 of the OS/390 JES2 Initialization and Tuning Guide . 10.2.2.1 The JES2 Procedure Similar to the POWSTRT procedure, the JES2 member of SYS1.PROCLIB is used to initialize JES2. (It must be in SYS1.PROCLIB, not in any other procedure library.) You must tailor the JES2 proc to include your JES2 load libraries, parameter members, procedure libraries, and other options.
• • • • • Network Job Entry (NJE) Application Programming Interfaces Accounting RAS Characteristics Testing Techniques Note: The comparison is based on the functions provided within VSE/POWER. Therefore, it is not a complete overview of all functions available in JES2. 10.3.1.1 Multiple System Support In POWER, the Spool File can be shared between multiple VSE/POWER systems using the “Shared Spool” feature. Multi-access spool or MAS is a standard feature of JES2.
10.3.3 Job Scheduling POWER and JES2 both manage the job input queue and manage the job selection for execution according to job classes, priority and in the order they were submitted. In addition, OS/390 V2R4 provides additional capability with the workload management of batch jobs according to installation specified performance objectives. Table 12.
10.3.3.2 Serializing Job Execution JES2 does not guarantee that jobs will run in the order they are submitted. If you need to make certain jobs run in order or you need dependent job control, you should submit them one at a time or use an automated job scheduling product such as OPC/A. 10.3.3.3 Time Event Scheduling POWER supports the scheduling of job submission based on a one-time or repetitive schedule such as daily, weekly on a given day and time, and so on.
10.3.4 Output Service As with POWER, JES2 supports line-mode printers, whereas PSF controls AFP Printers. (See Chapter 11, “Advanced Function Printing and Print Services Facility/MVS” on page 235 for AFP printing.) Table 13 (Page 1 of 2). POWER/JES2 Output Service Comparison Output Service Function POWER JES2 Local Line Printer (3211, 4245, 4248) Y Y See 10.3.4.1, “Printers Supported” on page 216 Page Mode Printer (3900, 3820, etc.
Table 13 (Page 2 of 2). POWER/JES2 Output Service Comparison Output Service Function POWER JES2 End-of-Page sensing Y N Counting Line Mode Output Y (Pages = skip to Ch.1) Y (Lines) Counting Page Mode Output Y (Pages) Y (Pages) Restart capability for interrupted output Y (PRESTART) Y JES2 Comments See 10.1.1.6, “End-of-page Sensing” on page 209 Set PRINTDEF NEWPAGE=1 Automatic checkpoint restart 10.3.4.
10.3.4.4 Printer Forms Alignment via PSETUP The PSETUP function is not supported in JES2. See 10.1.1.4, “Printer Forms Alignment via PSETUP” on page 208 for some alternatives. 10.3.4.5 Separator Page Differences The IBM provided separator pages are different with JES2. See 10.1.1.5, “Separator Page Difference” on page 208 for more information. 10.3.4.6 End-of-page Sensing JES2 does not support end-of-page sensing. See 10.1.1.6, “End-of-page Sensing” on page 209 for more information. 10.3.4.
FCB Specification POWER users specify the full eight-character FCB name, whereas OS/390 users only specify the last four characters. POWER supports device-independent specification of FCB-image phases in the * $$ LST statement by allowing ″$$$$″ as the first four characters.
Table 15.
RMT BSC and SNA RJE Workstations R(nn).RD(n) RJE Workstation Readers R(nn).PR(n) RJE Workstation Printers R(nn).PU(n) RJE Workstation Punches See Table 19 on page 228, and Table 20 on page 229 for a comparison of POWER PRMT macros and JES2 RMT parameters. 10.3.6.3 RJE Operations See 28.6.1, “JES2 RJE Operations” on page 452 and JES2 Commands for a description of RJE commands for the host and remote operators. 10.3.6.
10.3.7.1 NJE Definitions Use the following JES2 initialization statements to define your NJE network and networking options: TPDEF BSC & SNA Buffer Sizes, and Number of SNA Sessions NJEDEF Number of Nodes, Transmitters, Receivers, and other NJE options NODE Individual NJE node definitions APPLID VTAM Applid of NJE nodes (if not the same as Node Name) LOGON VTAM Applids of this node LINE BSC, CTC, and SNA communication lines. These are defined in the same way RJE lines are defined.
Job Information Services Current Job Identification If you have code that is called by an MVS application, you can obtain information about the job currently running in an address space with the IAZXJSAB macro. You can retrieve information such as: • • • • • • Name of the subsystem that scheduled the job Job identifier Job name User ID associated with the job Time when the job started running JES status of the job See OS/390 MVS Auth Assm Services Reference ENF-ITT, GC28-1765 for details.
Subsystem Version ID You can obtain version-specific information about a subsystem with SSI function code 54. See Using the Subsystem Interface . Command Interface You can also use the MGCR service to submit JES2 or MVS operator commands to control jobs. See OS/390 MVS Auth Assembler Services Guide , GC28-1763. 10.3.9 Accounting Comparisons 10.3.9.
NJE Network Management Records JES2 records the following information reflecting network events: • • • SMF 55 Network Signon SMF 56 Network Integrity (invalid password) SMF 58 Network Signoff See System Management Facilities for details. NJE Accounting Most NJE related information is carried in the NJE headers as the job is routed from node to node. Here is a summary of the differences between POWER and JES2 accounting records for NJE: Table 16.
• Operator Monitor Spool Utilization • Spool Full Condition - $S SPL upon warning (Output limits minimize this) • An external message-based automation product can also delete, offload or reroute spool files. 10.3.11 JES2 Testing Techniques Just as it is important to test new levels of OS/390 in your environment before using them in production, you should also test any JES2 exits or modifications before using them in production. 10.3.11.
Table 17 (Page 1 of 2). POWER Macro to JES2 Parameter Mapping 226 POWER Parm Description JES2 Parm Comment or Recommendation ACCOUNT Job Accounting Information to be collected/recorded. JOBCLASS TYPE6, TYPE26 SMF records are collected based on SYS(TYPE(nn:nn)) parm in PARMLIB(SMFPRMxx) CLRPRT Clear 3800 page buffer at EOJ N/A Option not supported by JES2. COPYSEP Produce separator pages (or cards) between data sets and copies.
Table 17 (Page 2 of 2). POWER Macro to JES2 Parameter Mapping POWER Parm Description JES2 Parm Comment or Recommendation SECNODE VSE Security ″Zone″ N/A (Use RACF NODES class profiles for security.) SHARED Shared systems and accounting file N/A JES2 always assumes shared systems. Accounting files cannot be shared.
Table 18. PLINE MACRO to JES2 Parameter Mapping PLINE Parameter Description JES2 LINE Parameter Comment ADDR= Unit address of the BSC emulator port or CTC adapter UNIT= ″SNA″ or unit address (4-digit addresses supported) CODE EBCDIC is the only value allowed.
Table 19 (Page 2 of 2).
10.4.1.5 Define NJE Nodes This table shows the conversion of POWER PNODE parameters to JES2 parameters. Table 21. PNODE MACRO to JES2 Parameter Mapping PNODE Parm Description JES2 Parm Comment NODE= Name of the NJE node NODE NAME= LOCAL This is the local node.
Table 23. POWER Exit to JES2 Exits POWER Exit Description JES2 Exit Comment JOBEXIT Job input - Scan JCL & JECL (POWER exits allow access to SYSOUT data.) EXIT(2) EXIT(3) EXIT(4) JOB statement scan JOB accounting field Other JCL & JECL (No access to SYSIN data.) NETEXIT Input from NJE node EXIT(47) NJE Headers Received (No access to SYSIN or SYSOUT data.) OUTEXIT Output to printer or punch (POWER exits allow access to SYSOUT data.
10.4.3.1 Queue Management Commands Table 24. Queue Management Commands POWER Command Code PWR Short Form Function JES2 Command Verb PALTER A Alter processing attributes of a POWER job or a POWER controlled partition $T PDELETE L Delete queue entries $P PDISPLAY D Display the status of jobs, messages, resources, and the network $D PHOLD H Put a job of a queue in hold/leave state $H POFFLOAD O Save or restore entries of a queue.
10.4.3.3 Control Commands Table 26. Control Commands POWER Command Code PWR Short Form Function JES2 Command Verb PACCOUNT J Save account file records. (SMF) PBRDCST B Transmit a message. $DM, $M PINQUIRE I Display the status of a BSC line, SNA logical unit, or a node. $D U,... $D Node PLOAD Load a network definition table. $T Node PRESET Reset active jobs in a shared spooling environment. $E PSETUP U Print a page layout. (see Note) PXMIT X Route commands to another node.
Table 27 (Page 2 of 2).
Chapter 11. Advanced Function Printing and Print Services Facility/MVS 11.1 Introducing PSF/MVS Print Services Facility (PSF) is the Advanced Function printing (AFP) printer-driver program for VSE and OS/390, as well as AIX, OS/2, VM and OS/400. PSF has similar capabilities in all environments, plus differences unique to the operating system on which it is running. This chapter describes the differences between the VSE and OS/390 environments. 11.1.
• 11.2, “Installing and Configuring PSF/MVS” • 11.3, “Setting up AFP Resources” on page 240 • 11.3.4, “Migrating Print Applications” on page 241 • 11.4, “Understanding Operational Differences” on page 242 • 11.5, “Other Differences” on page 243 Other tasks are similar between the two platforms. 11.2 Installing and Configuring PSF/MVS PSF/MVS is an optional feature of OS/390, and is already installed on your SystemPac or part of your ServerPac.
11.2.2.2 TCP/IP Attached Printers Unlike VSE, OS/390 also supports printing to TCP/IP connected printers.
11.2.5 FSS Procedure and PRINTDEV Statements Below is the sample FSS proc shown in the PSF/MVS Systems Programming Guide . //SAMPPROC PROC //STEP01 EXEC PGM=APSPPIEP,REGION=4096K,TIME=1440 //STEPLIB DD DSN=PSF.
Table 30. PRINTDEV Parameter Comparison PSF/VSE PRINTDEF Parameter OS/390 Equivalent Parameter Description and Comment ASA (not necessary) ASA control records do not need conversion CKPTPAGE JES2 parm: PRT(nnnn) CKPTPAGE Number of pages to be printed before a checkpoint is taken. FONTPR PSF APSUX07 Exit (Resource management exit) Whether font pruning will occur.
11.3 Setting up AFP Resources PSF/MVS supports resources in the system libraries defined in the PRINTDEV statement, and dynamically on a per-job basis via the USERLIB JCL statement. 11.3.1 Migrating Resources from VSE to OS/390 11.3.1.1 Defining Resources If you have the source definition files for these resources, you can use the same process to define them on OS/390. The same utilities are used on OS/390 as on VSE to define resources: PPFA for PAGEDEFs and FORMDEFs, and OGL for Overlays.
PSF/MVS utility APSRMARK against these ported VSE resources in order for PSF/MVS to consider these resources ′marked′ for printer residency. (Printer resident fonts shipped with PSF/MVS are already ′marked′ with the APSRMARK program.) 11.3.3 Transferring Print Streams - VSE and OS/390 Coexistence You can use NJE to transmit AFPDS (also known as LIST3820 or MO:DCA) files from VSE to OS/390 or vice versa. Print files created on VSE should print on PSF/MVS, and vice versa.
OS/390 Dynamic Allocation and Output Descriptor Macros Traditional SYSOUT attributes can be specified on the DYNALLOC macro. AFP attributes can be specified on the OUTDES macro. 11.3.4.4 High Level Language Programming Interfaces COBOL Applications Creating AFP in COBOL is essentially the same between MVS and VSE. VSE code will run in MVS unchanged. MVS coding will require changes to FDs and File-Control moving to VSE due to the lack of the ability to specify DCB attributes in VSE JCL.
Table 31 (Page 2 of 2). VSE - OS/390 Command Comparison VSE or POWER Command JES2 Command Comment PSTOP devname [ ,EOJ | RESTART | FORCE. ] $P PRTnnnn $I PRTnnnn F FSSx,FORCE,PRTnnnn Drain the printer - wait for current job to finish - interrupt current job, restart from ckpt - Only use if nothing else works PXMIT devname [, C L A S S = ] [, L O G D E S T = .
11.5.3 Accounting PSF/VSE uses the POWER ACCOUNT=AFP (or =ALL) parameter to capture accounting information about printing through PSF. In OS/390, this data is recorded by SMF in the Type 6 records written by PSF. 11.6 References 11.6.1 PSF/VSE Publications • VSE/ESA Program and Workstation Guide , SC33-6509 (moving VSE files) 11.6.
11.6.5.4 Internet Locations The IBM Printing Systems Company Web Site at http://www.printers.ibm.com/ contains a “Tools” directory along with product support, software solutions and so on. Specifically, the following tools are available from the http://www.printers.ibm.com/tools.html site or FTP from ftp://ftp.software.ibm.com/printers/tools/vseres/. • resmake.assemble − • respunch.assemble − • REXX EXEC to convert VSE LIBR PUNCH phases to AFP resources vseres.
246 VSE to OS/390 Migration Workbook
Part 3. Converting VSE Languages to OS/390 Languages Copyright IBM Corp.
248 VSE to OS/390 Migration Workbook
Chapter 12. COBOL 12.1 Introduction This chapter introduces IBM COBOL for OS/390 and VM (program number 5648-A25), which is the COBOL compiler available with OS/390. It also outlines the differences between the three COBOL compilers that are available on VSE and COBOL for OS/390 and VM. Various strategies for converting your VSE COBOL applications to OS/390 are considered. These strategies depend on the COBOL compiler you use on your VSE system.
12.1.
Under VSE/ESA version 1 release 4, and VSE/ESA version 2 and above, the COBOL compilers available were DOS/VS COBOL, VS COBOL II, and COBOL for VSE/ESA; CCCA/VSE is available to aid the conversion process. Now, only the COBOL for VSE/ESA product is available. If you are running DOS/VS COBOL, you will have to convert your code to a new COBOL compiler level. Section 12.3, “Converting from DOS/VS COBOL” on page 252 outlines the various options open to you, to convert from DOS/VS COBOL. Section 12.
Table 32. Useful COBOL Publications Publication Title Form Number COBOL for OS/390 and VM Compiler and Run-Time Migration Guide GC26-4764 COBOL for OS/390 and VM Language Reference SC26-9046 COBOL for OS/390 and VM Programming Guide SC26-9049 COBOL for VSE/ESA Migration Guide GC26-8070 COBOL for VSE/ESA Programming Guide SC26-8072 OS/390 Language Environment Migration Guide SC28-1944 Taking Advantage of IBM Language Environment for VSE/ESA SG24-4798 12.
12.3.2 DOS/VS COBOL Programs Containing REPORT WRITER Statements COBOL for OS/390 and VM does not support the REPORT WRITER statements. However, you can keep your REPORT WRITER statements by using the COBOL Report Writer Precompiler prior to the new compiler. Alternatively, you can use the COBOL Report Writer Precompiler to convert your REPORT WRITER statements to COBOL code. 12.
For example: 01 RECORD-A PIC X(4). 01 FILLER REDEFINES RECORD-A. 10 RECA-FIRST PIC 9(2). 10 RECA-SECND PIC 9(2). Using COBOL for OS/390 and VM you will receive the message: IGYDS1064-E A ″REDEFINES″ clause was found in the definition of a level-01 item in the ″FILE SECTION″. The clause was discarded. This coding practice is documented as invalid in DOS/VS COBOL, but DOS/VS COBOL did not flag the error.
12.4.2 ENVIRONMENT DIVISION 12.4.2.1 CONFIGURATION SECTION - SPECIAL-NAMES Paragraph UPSI Switch Processing In DOS/VS COBOL and COBOL for OS/390 and VM, program switches can be tested by use of a one-byte switch in the SPECIAL-NAMES paragraph, specified as UPSI-0 through UPSI-7. In VSE, the setting of these program switches at execution time is achieved by the // UPSI job control statement. In OS/390 the // UPSI job control statement is not available.
ASSIGN Clause The format of the ASSIGN clause has become simpler. COBOL for OS/390 and VM may sometimes allow the DOS/VS COBOL format but may produce unexpected results at run-time. Refer to the COBOL for OS/390 and VM Compiler and Run-Time Migration Guide for more information. 12.4.3 DATA DIVISION - FILE DESCRIPTION (FD) BLOCK CONTAINS In OS/390 it is recommended that you specify BLOCK CONTAINS 0 RECORDS or BLOCK CONTAINS 0 CHARACTERS in your program.
12.4.4.1 Program Termination There are three COBOL program termination statements: • • • EXIT PROGRAM GOBACK STOP RUN There are some differences in the effect of these statements between DOS/VS COBOL and COBOL for OS/390 and VM. Table 33 gives a comparison of the behavior of these COBOL program termination statements, for DOS/VS COBOL and COBOL for OS/390 and VM. Table 33.
12.4.5.2 File Attribute Mismatches DOS/VS COBOL file open processing does not always check that the attributes of the file definition in your program exactly match the file attributes of the physical file (for example, as defined for a VSAM file in the LISTCAT). To conform with ANSI 85 requirements, COBOL for OS/390 and VM open processing carries out many detailed checks for consistency between the program and actual file definition before opening the file.
12.5.1 VS COBOL II CICS Programs COBOL for OS/390 and VM and OS/390 do not support CICS macro-level programs. If you have any programs written in macro-level CICS you must convert them to command-level CICS. If you need to change your programs to cater for these differences, you can do so before you migrate them to OS/390. Then, if you prefer, you can transfer the compiled object code to OS/390 for linkediting. See 12.2, “VSE to OS/390 Migration Considerations” on page 250. 12.
12.8 Compiler Options This section discusses some of the compiler option considerations when converting from the various VSE COBOL compilers to COBOL for OS/390 and VM. DOS/VS COBOL has many compiler options that are not available with COBOL for OS/390 and VM. Compiler options with VS COBOL II or COBOL for VSE/ESA are generally the same as COBOL for OS/390 and VM. If you are converting VS COBOL II programs, the most important difference to be aware of is the RES/NORES option. 12.8.
DOS/VS COBOL Option COBOL for OS/390 and VM Equivalent (If Any) BUF=nnn BUFSIZE(nnn) CATALR/NOCATALR NAME/NONAME CLIST/NOCLIST OFFSET/NOOFFSET COUNT/NOCOUNT None FLAGE/FLAGW FLAG(E)/FLAG(W) FLOW/NOFLOW None LANGLVL(1/2) None. COBOL for OS/390 and VM supports only the COBOL 85 Standard and COBOL 74 Standard (if using CMPR2 option) as implemented by VS COBOL II release 2. LVL=A|B|C|D|NOLVL None. COBOL ANSI 74 FIPS is not supported by COBOL for OS/390 and VM. MIGR/NOMIGR None.
COBOL for OS/390 and VM Option Comments PGMNAME(COMPAT) If compiling with COBOL for OS/390 and VM use this option to ensure that COBOL for OS/390 and VM processes program names in a similar manner as VS COBOL II. RMODE(AUTO) Use RMODE(AUTO) or RMODE(24) for COBOL for OS/390 and VM NORENT programs that pass data to programs running in AMODE(24). TEST The syntax of the TEST option is different in COBOL for OS/390 and VM than in VS COBOL II.
VS COBOL II Option Comments FDUMP/NOFDUMP COBOL for OS/390 and VM does not provide the FDUMP compiler option. For existing applications, FDUMP is mapped to the COBOL for OS/390 and VM compiler option TEST(SYM). This provides equivalent function and more. Language Environment generates a better formatted dump than VS COBOL II, regardless of the FDUMP option. But the presence of FDUMP enables Language Environment to include the symbolic dump of information about data items in the formatted dump.
ALPHABET ALPHABETIC-LOWER ALPHABETIC-UPPER ALPHANUMERIC ALPHANUMERIC-EDITED ANY BINARY CANCEL CLASS CLASS-ID COMMON CONTENT CONTINUE CONVERTING DAY-OF-WEEK DBCS DISPLAY-1 EGCS END-ADD END-CALL END-COMPUTE END-DELETE END-DIVIDE END-EVALUATE END-IF END-INVOKE END-MULTIPLY END-PERFORM END-READ END-RETURN END-REWRITE END-SEARCH END-START END-STRING END-SUBTRACT END-UNSTRING END-WRITE EVALUATE EXTERNAL FALSE FUNCTION GLOBAL INHERITS INITIALIZE INVOKE KANJI LENGTH LINAGE-COUNTER LOCAL-STORAGE METACLASS METHOD M
12.9.2 Reserved Word Considerations for VS COBOL II and COBOL for VSE/ESA There are two reserved words in COBOL for OS/390 and VM that are not reserved in VS COBOL II. These are shown in Figure 25. They are reserved in COBOL for VSE/ESA. FUNCTION PROCEDURE-POINTER Figure 25. Reserved Words in COBOL for OS/390 and VM and not in VS COBOL II The following words are reserved in COBOL for OS/390 and VM for the object-oriented COBOL extensions. They are not reserved in VS COBOL II or COBOL for VSE/ESA.
266 VSE to OS/390 Migration Workbook
Chapter 13. Assembler 13.1 Assembler Products In OS/390, the High-Level Assembler for MVS and VM Program Product (5696-234) is required for system generation (SYSGEN) and maintenance activities. It can also be used for application programming projects, and must be used when assembler routines are designed for 31-bit addressing facilities. See High-Level Assembler for MVS and VM General Information , GC26-4943 and OS/390 MVS Extended Addressability Guide , GC28-1769 for more information on this subject.
The selection of a particular option of MVS may require redesigning the application programs. In addition, a program logic change may also be forced by attempting to simulate a VSE function under MVS. Examples of these possibilities include multitasking, interrupt handling, and communication region accessing.
13.2.1.1 Initiation Under VSE, main programs (those programs that are invoked by the operating system directly) are not required to save any registers upon entry. VSE assembly programs are not required to provide a save area unless that program invokes (calls) another program. In MVS, all programs are executed as subroutines including the program that is given control by the operating system.
PROGA START BALR USING . . . Application Program Logic . LA 13,SAVEA CALL PROGB EOJ(Return) SAVEA DC 18F′ 0 ′ END PROGB CSECT (VSE) . . ST 13,SAVEB+4 . Application Program Logic . LA 13,SAVEB CALL PROGC Return(PROGA) SAVEB DC 18F′ 0 ′ END PROGC CSECT (VSE) . . ST 13,SAVEC+4 . Application Program Logic . . . Return(PROGB) SAVEC DC 18F′ 0 ′ END Figure 27.
contained in register 13. Therefore, you must specify a save area to receive the registers. PROGA START PROGB CSECT PROGC CSECT (MVS) (MVS) (MVS) . . . . . . STM 14,12,12(13) STM 14,12,12(13) STM 14,12,12(13) ST 13,SAVEA+4 ST 13,SAVEB+4 ST 13,SAVEC+4 LA 11,SAVEA LA 11,SAVEB LA 11,SAVEC ST 11,8(13) ST 11,8(13) ST 11,8(13) LR 13,11 LR 13,11 LR 13,11 . . . . . . Application Application Application Program Program Program Logic Logic Logic . . . . . .
VSE CALL Entrypoint ,(PARAMETER LIST) (15) MVS CALL Entrypoint ,(ADDRESS),VL (15) ,ID=number Call is used the same way in MVS as it is in VSE, except when it is used with the LOAD macro. For a discussion of this difference, see the topic “LOAD Macro” on page 277 in this section. In addition, if a variable number of parameters may be passed, the VL keyword operand must be added. The parameters of the called module should be checked for VSE and MVS differences.
Under MVS, the RETURN macro returns control to the calling program and signals normal termination of the returning program. Control returns after restoring the address of the calling program′s save area into register 13. The return is made by executing a branch instruction using the address in register 14. You can write the RETURN macro to restore a designated range of registers, provide the proper return code in register 15, and flag the save area used by the returning program.
When this program received control from MVS Reg. 13 contained address of MVS save area. Reg. 14 contained address of MVS return. Reg. 15 contained address of this program′s entry point.
region in register 1. The first eight bytes of the communication region is the date in the form MM/DD//YY (month/day/year) or DD/MM/YY (day/month/year). Job Name The VSE communication region contains the job name that appears in the JOB control statement. This name remains for the duration of the job and can be used in a job by using the COMRG macro to get the address of the communication region and a displacement of 24 to get the job name.
is an explicit request. If a separate module is requested, then the additional virtual storage requirement is implicit in that request. The MVS GETMAIN macro is an explicit request for additional virtual storage. You can use GETMAIN to obtain a single block or multiple blocks of virtual storage. You can specify either a fixed or variable amount of virtual storage.
programs. You can also leave the tests in your program and provide an UPSI constant in your COMRG macro that would always satisfy the tests. • The MVS macro instruction TIME provides the system date (Julian or Gregorian) in a user work area. The date is in packed decimal digits, such as X′19980323′. For details, see the section “GETIME Macro” on page 278.
(MVS) LOAD EP=PROGB LR 15,0 CALL (15),parm1,parm2 LOAD the load-module pass address invoke PROGB FETCH Macro The VSE FETCH macro loads the phase specified in the first parameter and passes control to the address specified by the second. The MVS LINK and XCTL macros pass control to a specified entry point. When modifying programs from VSE to MVS, use LINK when the called phase does not overlay the calling phase. Use XCTL when the called phase does overlay the calling phase.
The MVS TIME macro has an additional operand MIC,address that causes the time of day to be returned in the eight-byte area specified by the address. The time of day is in microseconds, with bit 51 equivalent to one microsecond. Register 0 contains 0, and register 1 contains the date. System Operand Register Content VSE STANDARD H HM MS S MVS DEC HH MM SS th VSE BINARY seconds MVS BIN hundredths of a second VSE TU 1/306 of a second units MVS TU 26 micro second units H = hours M = minutes S = seconds t = 0.
┌─────┬──────┬──────────────────────────────────────────┐ │ VSE │ PDUMP│ address1 , address 2 ,MFG=area │ │ │ │ r1 r2 (S,area) │ │ │ │ r3 │ ├─────┼──────┼──────────────────────────────────────────┤ │ │ │ DCB = dcbaddress ,TCB = address │ │ │ │ (2-12) (2-12) │ │ │ │ ,ID= number ,SDATA = (sysda─a) │ │ │ │ (2-12) │ │ MVS │ SNAP │,PDATA = (probda─a) │ │ │ │,STORAGE = (s─ar─ address,end address) │ │ │ │ (2-12) (2-12) │ │ │ │,STRHDR = (hdr addr) │ │ │ │ hdr lis─ addr │ │ │ │,LIST = address of lis─ │ │ │ │ (2-12)
CANCEL Macro ┌───────┬───────────┬────────────────────────────────┐ │ VSE │ CANCEL │ ALL │ ├───────┼───────────┼────────────────────────────────┤ │ MVS │ ABEND │ comple─ion code │ │ │ │ (1-12) ,DUMP ,STEP │ ├───────┴───────────┴────────────────────────────────┤ │ No─e: Use .STEP wi─h sub─asking. │ └────────────────────────────────────────────────────┘ The VSE CANCEL macro causes the termination of the job. All succeeding job steps within this job are automatically bypassed by job control.
CHKPT Macro ┌─────┬────────┬────────────────────────────────┐ │ │ │ res─ar─ address │ │ │ │ SYSnnn, (r1) │ │ │ │ , end address , ─poin─er │ │ VSE │ CHKPT │ (r2) (r3) │ │ │ │ dpoin─er , filename │ │ │ │ (r4) (r5) │ ├─────┼────────┼────────────────────────────────┤ │ │ │ dcbaddress ,checkid address │ │ │ │ ,checkid leng─h │ │ MVS │ CHKPT │ ,′ S′ │ │ │ │ CANCEL │ └─────┴────────┴────────────────────────────────┘ The MVS CHKPT macro is similar to the VSE CHKPT macro with two minor differences in the checkpoint
13.2.2 Multitasking Macros Under VSE, when you specify asynchronous processing at system generation time, the multitasking group of macros is supported to permit more than one task to execute within each partition. Each subtask must be initiated by the main task: control then passes to the subtask. The storage protection key and priority of the partition remain the same, but the priority of a task within a partition is determined by the sequence of subtasks it attached.
ENTRYPOINT In VSE, it defines the storage address of the entry point of the subtask. The entry point must be in storage before the subtask can be successfully attached. The EP, EPLOC or DE parameter in MVS causes the required module to be loaded into storage (if it is not already in storage) and begins execution at the entry specified. The entry-point name must be a member name or an alias in a directory of a partitioned data set, or it must have been specified in the IDENTIFY macro.
terminate normally. MVS does not permit the subtask to issue its own DETACH. If neither ECB nor ETXR is specified in the ATTACH, the subtask is removed from the system automatically at normal termination. In this case, no DETACH should be issued. 13.2.2.2 WAIT/POST Macros The two operating systems provide macros that synchronize task execution if one task or subtask depends upon the completion of another subtask.
as complete. This number may be less than or equal to the number of ECBs specified in the macro. 13.2.2.3 RCB/ENQ/DEQ Macros This set of macros enables you to protect data files or other resources when processing a multitasking environment. The VSE RCB macro generates an aligned doubleword resource control block that functions much like an ECB. The VSE ENQ and DEQ macros test the status of the resource through the RCB name. MVS does not require or use an RCB macro.
13.2.3 Interrupt Handling Routines Interrupt routines take care of the interval timer, abnormal conditions, and operator communication interrupts. Abnormal condition interrupts will not be addressed in this publication. 13.2.3.1 Interval Timer Interrupts Basically, the two ways of utilizing the interval timer in your programs are routine handling and wait handling. Routine Handling This method allows a branch to your own routine when the interval timer interrupt occurs.
Wait Handling This method of using the interval timer allows you to set the timer and wait for the time to elapse. The job or task is prevented from executing until the interrupt occurs.
The preceding combination of VSE macro instructions allows you to execute a routine when an operator attention interrupt occurs and to return to the program that was being executed before the interruption. MVS has no equivalent function. It is possible, however, to simulate this function by using the WTOR macro. This MVS macro writes a message requiring a reply on the operator console and provides the information required by the control program to relay the reply to the issuing program.
13.2.4.2 RELPAG Macro The MVS PGRLSE and PGSER RELEASE macros have functions similar to the VSE RELPAG macro.
• CATALOG=YES/NO - NO is used if the catalog is to be processed as a normal cluster with normal GET/PUT macros. Programs must be APF-authorized to process a catalog as a data set. • MACRF=( − − − − − − • ICI - Improved-Control-Internal-Processing (ICIP) is to be used. ICIP is a VSAM ″fast-path″ that reduces CPU utilization. However, the functions that can be used are severely restricted. See the VSAM Administration Guide for more details. CFX - Control blocks and buffers are fixed in real storage.
• MSGLEN=length - The length of the MSGAREA specified above. The size of a message is 128 bytes. • OPTCD=( ASY - Asynchronous access; VSAM returns control to the program after scheduling the request so the program can do other processing while the request is earned out. SYN is the default and specifies that VSAM will return to the processing program when the request is complete. WAITX - If ″OPTCD=(..,SYN..)″ and the specifics ″MACRF=(..,LSR or GSR..)″, and ″EXLST ...
13.2.6.1 List and Execute Macro Forms The list and execute forms of data management macro instructions, used together provide the same services available from the standard form of the macro. The list form of the macro provides a parameter list to be passed to either the control program or another problem program, depending on the micro instruction. Use the execute form with one or two parameter lists established by the list form.
13.2.6.4 I/O Error Checking When an input/output error occurs under MVS, a user-written synchronous error routine (SYNAD) can be given control. You can use this routine to analyze exceptional conditions or uncorrectable errors. The error can be skipped or accepted, or processing can be terminated. If an input/output error occurs during data transmission, standard error recovery procedures, provided by the operating system, attempt to correct the error before returning control to your program.
VSE DTFCD MVS DCB DSORG=PS DEVADDR = SYSxxx IOAREA1 = xxxxxxxx or IOAREA1 = xxxxxxxx IOAREA2 = xxxxxxxx ASOCFLE = xxxxxxxx BLKSIZE = nnn CONTROL = YES CTLCHR = YES ASA SSELECT = n DEVICE = nnnn EOFADDR = xxxxxxxx EAROPI = xxxxxxxx FUNC = xxx IOREG =(r) MODE = E O C R RECFORM = xxxxxx RECSIZE = (r) SEPASMB = YES TYPEFLE = INPUT OUTPUT CMBND WORKA = YES DDname (in DD statement) BUFNO = 1 BUFNO = 2 or more UNIT=AFF=ddname (in DD statement) BLKSIZE = nn MACRF = (..C..) for input only RECFM = (...M) (...
VSE CARD MVS CARD OPEN GET . CLOSE DTFCD CARD CARD,WORK OPEN GET . CLOSE DCB CARD CARD,WORK CARD DEVADDR=SYSIPT,IOAREA1=CARDIN1, IOAREA2=CARDIN2,EOFADDR=END, WORKA=YES CDMOD WORKA=YES CARD DSORG=PS,MACRF=(GM), DDNAME=SYSIPT,EODAD=END, RECFM=FB,LRECL=80 C C C C Figure 33. Card File Programs in VSE and MVS 13.2.6.6 LIOCS Printer File Definition The methods of processing printer files are the same in VSE and MVS. Differences exist only in the CNTRL and PRTOV macros.
VSE DTFPR MVS DCB DSORG=PS DEVADDR = SYSxxx IOAREA1 = xxxxxxxx or IOAREA1 = xxxxxxxx 1OAREA2 = xxxxxxxx ASOCFLE = xxxxxxxx BIKSIZE = nnn CONTROL = YES CTLCHR = YES ASA DEVICE = nnnn ERROPT = xxxxxxxx FUNC = xxxx IOREG =(r) PRINTOV = YES RECFORM = xxxxxx RECSIZE = (r) SEPASMB = YES WORKA = YES DDname (in DD statement) BUFNO = 1,MACRF =(..M..) BUFNO = 2 or more UNIT=AFF=ddname (in DD statement) BLKSIZE = nnn MACRF = (PC) RECFM = (..A) (...M) UNIT = (in DD statement ) (1) SYNAD = xxxxxxxx DEVD=(..,..,..
Note: You can specify any number of dcbaddresses and associated options in the OPEN macro instruction. CLOSE Macro VSE CLOSE(R) filename ,... (r1) MVS CLOSE dcbaddress ,option ,... ,TYPE=T (2-12) 1. Options REREAD LEAVE REWIND DISP 2. If you omit the option, the following positioning occurs: If TYPE=T is coded, LEAVE is assumed (BSAM only). If TYPE=T is not coded, DISP Is assumed (BSAM only). 3.
Notes: 1. The codes are as follows: ┌──────┬────────────────────────────────────────────────────────────┐ │ VSE │ MVS (BSAM only) │ ├──────┼────────────────────────────────────────────────────────────┤ │ REW │ No equivalen─. The op─ion specified in ─he DISP │ │ RUN │ parame─er of ─he DD s─a─emen─ is ─aken. Refer │ │ │ also ─o ─he OPEN/CLOSE op─ions.
Notes: 1. VSE: The address is that of a four-byte storage location containing the required record identification in the same form as it is obtained from the NOTE macro. 2. MVS: The blockaddrcss is the address of a fullword on a fullword boundary containing the required record identification in the same form as it is obtained from the NOTE macro. 3. The MVS POINT macro is valid only for BSAM and BPAM. 4.
FEOV Macro VSE FEOV filename (1) MVS FEOV dcbaddress (1-12) , REWIND LEAVE The basic functions of the VSE and MVS FEOV macros are the same. In MVS, volume positioning can be specified by the option operand; if no option is coded, the positioning specified in the OPEN macro is used. The MVS FEOV macro is valid for BSAM and QSAM.
VSE DTFMT MVS DCB DSORG=PS BLKSIZE = nnnnn DEVADDR = SYSxxx EOFADDR = xxxxxxxx FILABL = xxxx IOAREA1 = xxxxxxxx or IOAREA1 = xxxxxxxx IOAREA2 = xxxxxxxx ASCII = YES BUFOFF = nn ERREXT = YES ERROPT = IGNORE SKIP BLKSIZE N/A EODAD = LABEL = BUFNO = ERROPT = xxxxxxxx IOREG =(r) LABADDR = xxxxxxxx (standard labels) NOTEPNT = YES POINTS READ = xxxxxxxx RECFORM = xxxxxx RECSIZE = nnnn = (r) REWIND = xxxxxx SEPASMB = YES TPMARK = NO TYPEFLE = INPUT OUTPUT TYPEFLE =WORK VARBLD = (nn) WLRERR = xxxxxxxx WORKA = Y
OPEN PUT . CLOSE RECORD1 DS TAPE DTFMT TAPE TAPE OPEN LA MVS PUT . CLOSE RECORD1 DS TAPE DCB (TAPE,(OUTPUT,LEAVE)) 5,RECORD1 TAPE,(5) VSE TAPE 2000C DEVADDR=SYS005,TYPEFLE=OUTPUT, FILABL=STD,IOAREA1=RECORD1, HDRINFO=YES,IOREG=(5), RECFORM=FIXBLK,BLKSIZE=2000, RECSIZE=100,REWIND=NORWD MTMOD RECFORM=FIXBLK C C C C (TAPE,(LEAVE)) CL100 DDNAME=TAPEDD,DSORG=PS,MACRF=(PM), RECFM=FB,BLKSIZE=2000,LRECL=100 C Figure 36. Tape File Programs in VSE and MVS 13.2.6.
VSE DTFDI MVS DCB DSORG=PS DEVADDR = SYSxxx DDname (in DD statement) IOAREA1 = xxxxxxxx BUFNO = 1 or IOAREA! = xxxxxxxx BUFNO = 2 or more IOAREA2 = xxxxxxxx EOFADDR = xxxxxxxx EODAD = xxxxxxxx ERROPT = xxxxxxxx SYNAD = xxxxxxxx ERROPI = IGNORE EROPI = ACC SKIP SKP ABE MACRF =(G...) = (p...) RECFM = FA = FM BLKSIZE = nnnn IOREG = (r) MACRF = (..L..) RECSIZE = nnn LRECL = nn SEPASMB = YES User must code the DCB WLERR = xxxxxxxx SYNAD = xxxxxxxx Figure 37. Comparison of DTFDI and DCB macros 13.2.6.
Options QSAM BSAM Option 1 Option 2 INPUT OUTPUT UPDAT EXTEND INPUT EXTEND OUTPUT ,REREAD ,LEAVE ,DISP INOUT UPDAT OUTIN OUTINX ,DISP ,LEAVE ,REREAD Note: Any number of dcbaddresses and associated options may be specified in the OPEN macro instruction. CLOSE Macro VSE CLOSE(R) filename (r1) ,777 MVS CLOSE dcbaddress option ,... ,TYPE=T (2-12) 1. Options REREAD LEAVE FREE DISP 2. If you omit the option, the following positioning occurs: If you code TYPE=T, LEAVE is assumed (BSAM only).
MVS GET PUT dcbaddress (2-12) (1) area address (2-12) (0) CNTRL Macro There is no equivalent for the VSE CNTRL macro. The MVS CNTRL does not support DASD devices. RELSE Macro VSE RELSE filename (1) MVS RELSE dcbaddress (1-12) The VSE and MVS functions of this macro are the same. RELSE causes the remaining records in a buffer to be ignored. TRUNC Macro VSE TRUNC filename (1) MVS TRUNC dcbaddress (1-12) The VSE and MVS functions of this macro are the same.
ACC Specifies that the problem program accepts the block causing the error. This action can be specified when a data set is opened for INPUT, RDBACK, UPDAT, or OUTPUT (OUTPUT applies to printer data sets only). SKP Specifies that the block that caused the error is skipped. Specifying SKP also causes the buffer associated with the data block to be released. This function can be specified when a data set is opened for INPUT, RDBACK, or UPDAT.
Notes: 1. The decbaddress must be the same as used in the READ or WRITE macro (decbname). 2. If the I/O operation did not complete successfully, the error analysis routine (SYNAD) is given control if you have provided one. 3. The following conditions are also handled: • • When the system is reading, volume switching is automatic. The end-of-data-set (EODAD) routine is given control if an input request is made after all the records have been retrieved.
NOTE Macro VSE NOTE filename (1) MVS NOTE dcbaddress (1-12) The MVS NOTE macro is valid only for BSAM and BPAM. NOTE returns the following information: VSE-register 0: 00nn VSE-register 1: CCHR MVS-register 1: TTR0 where nn = Unused space remaining on the track following the end of the identified record. C = Cylinder number. H = Track number. T = Relative track number. R = Block number of that track.
VSE DTFSD MVS DCB DSORG=PS BLKSIZE = nnnn EOFADDR = xxxxxxxx DELETFL = NO DEVADDR = SYSxxx DEVICE = nnnn ERROPT = IGNORE SKIP BLKSIZE = nnnn EODAD = xxxxxxxx DISP = (in DD statement) N/A UNIT = (in DD statement) EROPT = ACC SKP (QSAM only) (in DD stmt) ABE SYNAD = xxxxxxxx SYNAD = xxxxxxxx Not required This function can be implemented using the ENQ/DEQ logic of MVS for a specific resource. DISP=SHR in DD statement.
OPEN SAMFILE . WRITE SAMFILE,SQ,DATA VSE CHECK SAM FILE . CLOSE SAMFILE SAMFILE DTFSD DEVADDR=SYS005,DELETFL=NO, DEVICE=3340,RECFORM=FIXUNB, BLKSIZE=8O,TYPEFLE=WORK,VERIFY=YES SDMODW C C OPEN SAMFILE,(OUTPUT)) . WRITE DECB,SF,SAMFILE,DATA MVS CHECK DECB . CLOSE SAMFILE SAMFILE DCB DDNAME=SAMDD,RECFM=F,DSORG=PS, BLKSIZE=80,MACRF=(W) C Figure 39. Sequential DASD FILE Program in VSE and MVS 13.2.6.
VSE DTFDA MVS DCB DSORG=DA BLKSIZE = nnnn DEVICE = nnnn ERRBYTE = xxxxxxxx IOAREA1 = xxxxxxxx SEEKADR = xxxxxxxx TYPEFLE = xxxxxx AFTER = YES DEVADDR = SYSnnn ERREXT = YES HOLD = YES BLKSIZE = nnnn UNIT = (in DD statement) (See description of SYNAD routine) Area address (READ/WRITE macro) Not required (READ/WRITE macro) OPEN macro option MACRF = (..WA..
ERROR VSE MVS Byte Bit Byte Bit Wrong-length record 0 1 2 1 Nondata transfer error 0 2 2 6 Space not found on track 0 4 2 2 Reference outside extents of data set or file 0 7 3 3 Data check in count area 1 0 2 4 Track overrun 1 1 ** ** End-of-cylinder 1 2 ** ** Data check when reading key or data 1 3 2 4 Record not found 1 4 2 B End-of-file 1 5 2 5 End-of-volume 1 6 Invalid request * 2 3 Uncorrectable error other that I/O * 2 6 Read with exclusive control not preceded by write with exclusive control * 2 7 W
WRITE Macro KEY ID RZERO AFTER AFTER,EOF VSE WRITE filename (1) , MVS WRITE decbname,type, dcbaddress (2-12) length (2-12) ′ S′ key address (2-12) , ′ S′ 0 , , area address, (2-12) ′ S′ block address (2-12) Notes: 1. TYPE = DA, DAF, DI, DIF, DIX, DK, DKF, or DKX. 2. ′ S′ - system supplies the operand if you specify ′ S′. 3. If the key is not written or used as a search argument, zero is specified instead of keyaddress. CNTRL Macro There is no equivalent in MVS BDAM to the VSE CNTRL macro.
13.2.6.12 Track and Record Addressing Track Addressing In VSE and MVS, you can make track references by using either the actual or relative addressing technique. The track reference field for actual addressing in VSE and MVS is of the form MBBCCHHR. The contents of the M byte is different in VSE and MVS. In VSE, M represents volume number, starting with zero for the first volume. This must be increased by one for each subsequent volume.
Record Addressing by KEY Supply the key as follows: VSE READ MVS READ filename,KEY KEYARG and KEYLEN operands are required in the DTFDA macro. decbname, DK,...,keyaddress,blockaddress Keyaddress points to a field containing the key of the record for which you are searching. Blockaddress points to a field containing sufficient information to identify the track on which the search is to begin. Reference Methods The following paragraphs describe record reference by ID and record reference by key.
Reference Method VSE MVS Relative Track Addressing Assumed if DSKXTNT is specified. RELTYPE=HEX (the default) requires the hexadecimal form TTTR. RELTYPE=DEC requires the zoned decimal for TTTTTTTTRR. In both cases, the R byte(s) must contain the actual record number of the record on the track. Assumed if OPTCD does not contain R or A. The field pointed to by blockaddress must contain TTR. There is no equivalent to RELTYPE =DEC in MVS. The form must be converted to hexadecimal.
Reference Method: VSE MVS Relative Track Addressing Assumed if DSKXTNT is specified. RELTYPE=HEX (the default) requires the hexadecimal form TTTR. RELTYPE=DEC requires the zoned decimal form TTITTTTTRR. RR must be 00. Assumed if OPTCD does not contain A. The field specified by blockaddress must contain TT in binary. There is no equivalent to RELTYPE=DEC in MVS. The form must be converted to hexadecimal. Relative Block Addressing No equivalent. OPTCD=R must be specified in the DCB parameter.
OPEN . . WRITE CHECK . . DAMFILE DCB . . (DAMFILE,(OUTPUT)) DECBADD,DI,DAMFILE,DATA,′ S′ , KEY,BLOCKADDRESS DECBADD ..MACRF=(WICS),DSORG=DA,OPTCD=R... Figure 45. Adding to a D A M File under MVS Loading a DAM File (Fixed-Length Records with keys) Figure 46 and Figure 47 on page 320 illustrate an example of sequentially loading a DAM file consisting of fixed-length records with keys.
OPEN (DAMFILE,(OUTPUT),TAPE,(INPUT)) GET TAPE . WRITE DECB1,SF,DAMFILE,(10) CHECK DECB1 . WRITE DECB2,SD,DAMFILE,DUMMYREC CHECK DECB2 . TAPE DCB ....... . DAMFILE DCB DDNAME=OSDAMDD,DSORG=PS, MACRF=(WL),SYNAD=DATRTST, RECFM=F,KEYLEN=3,BLKSIZE=47 GET C C Note: DSORG=PS must be specified in the DCB. However, DSORG=DA must be specified in the DD statement. Figure 47. Loading a Sequential D A M File under MVS Under MVS, you can create a like data set by using the WRITE SF macro.
Notes . OPEN WRITER0 WRITE STC CHECK CLI BE OPENDAM OPEN CLI BE GET GET PACK CVB SR D LTR BNZ BCTR IC STH STC WRITE WRITE WAIT MVC TM BO CHECK B CLOSEDA AH LA STH CH BH CLOSE B BYPASS NOTE B EOF CLOSE CLOSE .
Notes RC WC COUNT THREE * DS DC DC DC CL1 CLI′ 0 ′ H′ 0 ′ H′ 3 ′ R0FILE DCB DDNAME=R0DD, DSORG=PS, MACRF=(WL), SYNAD=OSDAERR1, BLKSIZE=47, KEYLEN=3, RECFM=U (9) C C C C C C DDNAME=DAMDD, DSORG=DA, MACRF=(WAC), OPTCD=F, SYNAD=OSDAERR2 (9) C C C C * DAMFILE DCB * TAPE DCB DDNAME=TAPEDD, DSORG=PS, MACRF=(GM), EODAD=EOF * //GO.TAPEDD DD DSN=OSSAMFIL, // UNIT=3420,VOL=SER=NONE, // LABEL=(5,NL), // DISP=OLD, // DCB=(BLKSIZE=50,RECFM=F) //GO.
4. Since 37 records (blocks) will fit on one 3340 track, the three-byte key (ranging from 001-999) is divided by 37 to get the relative track number and the remainder will be the number of the record on this track. If a remainder of O is computed, this record will still fit on the previous track; therefore TT = n, R = 0 will be reset to TT = n-1, R = 37 since a remainder of 37 may not be evaluated otherwise. A key may not consist of all zeros in this case, as a TT of -1 will result.
To create a file using this method under MVS, you would normally initialize each track by writing a capacity record (R0) and erasing the 2.sp of the track. In VSE, you would do this by using the WRITE RZERO macro; in MVS you use the WRITE SZ macro. However, in MVS, you need not update the track address because this is done automatically by the WRITE SZ macro. By testing register 15 for a non-zero value after each WRITE, you can determine when MVS has initialized all the tracks.
When updating records, it is convenient to use the list and execute forms of READ/WRITE macros rather than the standard forms and to request dynamic buffering. To update a direct access file that was created sequentially, as in Figure 51 on page 325, use coding similar to that of the example in Figure 44 on page 318, which uses the list and execute forms of the READ and WRITE macros.
In MVS, to make a request for feedback, insert the letter F in the type code of a READ/WRITE macro (DIF, DAF and so on). The format of the blockaddress field after feedback, however, is determined by the OPTCD parameter. If the OPTCD parameter does not contain an F, feedback will be in the form of MBBCCHHR. If you code an F in the OPTCD parameter, the format of the feedback depends on the reference method used. Figure 52 provides details on reference methods and feedback formats.
13.2.6.14 PIOCS EXCP is often used in VSE in association with card files (for example, SYSIPT), print files (for example, SYSLST) or the operator console (for example, SYSLOG). In MVS, EXCP can not be used for spool files or to dialog with the operator. VSE programs that use EXCP should be converted to use standard access method such as QSAM or the WTO/WTOR macros.
DTFPH Macro Figure 54 shows the correspondence between the operands of the DTFPH macro and their MVS equivalents: DTFPH OPERAND MVS EQUIVALENT TYPEFLE ASCII CCWADDR DEVICE DEVADDR LABADRR HDRINFO MOUNTED XTNTXIT OPEN macro OPTCD=Q Channel program address field of IOB UNIT parameter of DD statement UNIT parameter of DD statement EXLST parameter in DCB allows for label checking exits No corresponding element DD statement DEB Figure 54.
Chapter 14. RPG II 14.1 Migration from VSE to OS/390 The aim has been to make it easy to convert programs running under VSE to run under OS/390, with the minimum of changes to the source code. In fact, the source programs will run unmodified, except for the following: • The command level interfaces with CICS/VS and DL/I VSE are not supported by OS/390 RPG II.
• • With the device type PRINTER or with a blank entry for device type and symbolic device SYSLST (DOS/VS RPG II only) − LRECL is the record length specified in the file description specification plus 1 (for the machine control character) − The first position of each record contains the machine control character. The RECFM in the DCB is the file format specified in the file description with machine control characters. It cannot be overwritten by JCL.
Direct access method files are processed with BDAM. VSAM files are handled in the same way as under VSE. 14.1.7 Calling COBOL Subprograms In OS/390 RPG II, a CALL statement for a COBOL subprogram must not be preceded by a CALL ′ILBDSET0′. 14.1.8 Calling PL/I Subprograms It is not possible to call PL/I subprograms from an OS/390 RPG II program. Year 2000 For VSE see PTF UN95321 (APAR PN88472). For OS/390 see PTF UN97731 (APAR PN90587). Chapter 14.
332 VSE to OS/390 Migration Workbook
Chapter 15. PL/I The PL/I language compiler implemented on VSE is the DOS PL/I Optimizing Compiler (5736-PL3). In MVS, the PL/I language is implemented by the OS PL/I Optimizing Compiler Version 1 (5734-PL3), and OS PL/I Version 2 Optimizing Compiler (5668-910). As the OS PL/I Version 2 Optimizing Compiler implements more of the PL/I language than Version 1 does, most source programs compiled on the VSE compiler can be compiled on either of the two MVS compilers with a minimum amount of change.
15.1.2 Extended Precision Available with the MVS version of the point allows working with variables of is requested by specifying a precision and 53 for binary float variables. DOS floating point arithmetic. PL/I compiler, extended precision floating two double-words. This extended precision greater than 16 for decimal float variables PL/I does not support extended precision 15.1.3 Multitasking Multitasking support in MVS introduces in PL/I a number of new statements.
15.1.6 Parameters Passed to a Main Program It is possible to pass parameters to a PL/I program having the option MAIN by declaring the entry point as follows: P:PROCEDURE(PARAM) OPTIONS(MAIN); DCL PARAM CHAR(100) VARYING; When control is passed to the program, the character string PARAM will contain the parameter passed from the PARM field of the EXEC statement. The length of the character string will be set to the number of characters passed to the program.
15.2.1.2 DYNBUF In MVS the buffers are always acquired dynamically by the compiler. This option is therefore suppressed. 15.2.1.3 LIMSCONV An option of DOS PL/I to generate strong external references to PL/I conversion library modules only for those conversions deemed ″reasonable″ for the data types of variables that appear in GET DATA and GET LIST statements. Without LIMSCONV the whole PL/I conversion is of much less importance in virtual storage systems. MVS PL/I does not support it. 15.2.1.
15.2.2.5 SMESSAGE or LMESSAGE This option requests the compiler to supply messages in short or long format. This is particularly useful for interactive users using only slow terminals (printers). 15.2.2.6 IMPRECISE This is used for 360/91 and 360/195 only. 15.2.2.7 INTERRUPT This option requests that control be given to an ATTENTION type of ON- UNIT in case of attention at the terminal.
15.2.3.4 SPIE STAE As user-program execution options they authorize PL/I to issue SPIE and STAE macros to intercept program checks and abends. It is possible with NOSPIE and NOSTAE to prevent this and in this case it is no longer certain that the management of errors will be handled by system ABEND or by an interruption handling program. This, therefore, allows an error routine to call PL/I modules and to continue to secure to itself the management of errors. 15.2.
15.4.1 Not Supported in MVS 15.4.1.1 MEDIUM Physical and logical unit type. This option is ignored by the MVS compiler. The error severity is 8 and gives correct execution. In MVS PL/I the name of the DD statement (DDname) is the name of the file as specified in the DCL. If some other name must be used, it can be supplied via the TITLE option on the OPEN statement. 15.4.1.2 FUNCTION This option defines the type of operation to be carried out on a 3525, 2560 or 5425. It is ignored in MVS.
15.4.1.10 NOTAPEMK NOLABEL These are specified in the JCL in the LABEL parameter of the DD statement. 15.4.2 Supported but to be Avoided In OS most of the environment parameters can be specified in the DCB. At OPEN, MVS merges the information from the program, from the label if the file exists already, and from the DCB parameters in the DD statement. It is therefore damaging to specify the physical blocksize in the program, because a re-compilation is involved if the blocking factor is to be changed.
15.5.2.1 SORT FIELDS SORT data: a character string containing an image of the SORT statement. This card image must begin and end with a blank. It will contain the sort criteria and the description of these criteria. 15.5.2.2 RECORD RECORD information: A character string containing a card image of the RECORD control statement. It too must begin and end with a blank. It describes the length and format of the records. 15.5.2.
15.5.2.9 SORT TECHNIQUES The user can specify a particular sort technique: PEER BALN CRCX OSCL POLY Peerage sort Balanced Criss-cross Oscillating Polyphase The sort call is, therefore, little different to that of DOS PL/I. In all cases, reading the Programmers′ Guide for the appropriate version of the sort is recommended. 15.6 Checkpoint-Restart in PL/I 15.6.
15.6.3 PLICANC Another possibility offered in the MVS PL/I optimizer is the ability to annul a request for an automatic restart. The function PLICANC provides this service. In checkpoint-restart MVS PL/I offers more facilities than DOS PL/I. The conversion of PL/I programs poses few syntax problems. On the other hand, to take advantage of automatic restart, some additional work will be necessary in the logic of the program. 15.7 DUMP in PL/I Optimizer 15.7.
15.7.3 Options Specific to MVS The options A, E and 0 are used only in a multitasking environment: A Dump all tasks O Dump only the task requesting the dump E Use of an exit 15.7.4 Compatibility Parameters unsupported by the PL/I dump routines are ignored if they are used when calling dump facilities. 15.8 Return Codes in PL/I 15.8.1 Setting Return Codes It is possible to set return codes in PL/I.
15.9.2 Automatic Restart An automatic restart in the case of an ABEND can only take place if an ABEND is actually detected; it must therefore be forced. This is the role of PLIREST. 15.10 Overlay Structures Overlay structures defined in DOS PL/I optimizer programs can remain valid in MVS PL/I optimizer programs. However, the CALL PLIOVLY statements must be removed. MVS linkage editor facilities (PARM=OVLY, INSERT, and OVERLAY) are used to build the overlay structure as discussed below. 15.10.
large enough ISA to reduce subsequent GETMAINs and FREEMAINs to zero (or some very small number). This is one of the most important things a user can do to improve the performance of a PL/I program. 15.12 PL/I and CICS 15.12.1 File Support The only PL/I file supported by PL/I under CICS is SYSPRINT, and its usage must be limited. The functions LINENO and COUNT are supported under MVS, but give a null value if they are used under DOS.
15.12.7 PL/I Return from ON-units and CICS Transaction Backout If a CICS transaction ABEND begins but is intercepted in a PL/I ON-unit, and the program takes ″normal return″ from the ERROR ON-unit (that is, quits) PL/I will reissue the CICS ABEND. If ERROR was raised without a CICS ABEND and the program takes ″normal return″ from the ERROR ON-unit, PL/I issues the APLS ABEND. (See previous paragraph.
348 VSE to OS/390 Migration Workbook
Chapter 16. FORTRAN 16.1 VS FORTRAN in OS/390 VS FORTRAN is the compiler and library to use on OS/390. VS FORTRAN expands greatly on what you can do with FORTRAN in accessing system services and/or hardware features. If you have used VS FORTRAN on VSE, you may be aware of the extensions that VS FORTRAN provides over DOS FORTRAN, such as execution time dynamic commons, compile-time included source files, asynchronous I/O, and level 66 language compatibility.
350 VSE to OS/390 Migration Workbook
Chapter 17. Language Environment (LE) 17.1 Introduction This chapter introduces OS/390 Language Environment (program number 5645-001). OS/390 Language Environment is the language run-time environment distributed with OS/390. Various strategies for migrating your applications to the Language Environment run-time are considered. These strategies depend on the programming language, the version of VSE you use, and whether you already use LE/VSE.
17.1.2 Conceptual Differences between LE/VSE and OS/390 Language Environment There are some conceptual differences between LE/VSE and OS/390 Language Environment. These differences do not affect the running of your migrated LE/VSE applications in an OS/390 Language Environment but you may want to take advantage of the extra facilities offered by the OS/390 Language Environment.
17.2.2 Useful Publications Table 35 lists some publications that you may find useful when planning your conversion. Table 35. Useful Publications Publication Title Form Number OS/390 Language Environment Migration Guide SC28-1944 OS/390 Language Environment Programming Reference SC28-1940 OS/390 Language Environment Programming Guide SC28-1939 OS/390 Language Environment Concepts Guide GC28-1945 OS/390 Language Environment Customization SC28-1941 OS/390 C/C++ V2R4.
17.3.2 COBOL for VSE/ESA COBOL for VSE/ESA is an LE/VSE-conforming language. If your COBOL applications are written in COBOL/VSE, they can (subject to certain restrictions) be migrated to OS/390 without change. You can transfer the compiled object code from VSE to OS/390, link-edit it with OS/390 Language Environment and run it there. This is discussed in 12.2, “VSE to OS/390 Migration Considerations” on page 250. 17.3.
Table 36. REPORT and ISASIZE Options, C/370 and DOS PL/I REPORT option, C/370 and DOS PL/I The information supplied by the REPORT option in C/370 and DOS PL/I is supplied in LE/VSE by the RPTSTG option. The RPTOPTS option may also be of use in determining storage use. ISASIZE option, PL/I In LE/VSE 1.4 the ISASIZE option maps to the STACK option. In OS/390 Language Environment ISASIZE maps to STACK, NONIPTSTACK and PLITASKCOUNT. DOS 17.4.2 C/370 C/370 is not an LE/VSE-conforming language.
Table 38 on page 356 lists some migration considerations you should be aware of when migrating from VS COBOL II. Table 38. VS COBOL II Migration Considerations Migration Consideration Comments Abends In VS COBOL II, a severe unhandled error condition always resulted in an abend. With OS/390 Language Environment, you use the ABTERMENC run-time option to specify whether a severe unhandled condition results in an abend or a normal termination with a return code and reason code.
Table 40. DOS PL/I Migration Considerations Migration Consideration Comments Dumps The output produced by PLIDUMP is different when running under OS/390 Language Environment. Condition Handling In general, PL/I condition handling continues to function in the same way when running under OS/390 Language Environment; however, you should consider the following: • The ERRCOUNT run-time option specifies how many conditions of severity 2, 3, and 4 can occur before the enclave terminates abnormally.
17.4.6 VS FORTRAN If your VSE applications are currently written in VS FORTRAN, you must convert them to another version of the FORTRAN compiler before you can run them under OS/390. There is currently no LE/VSE-conforming FORTRAN compiler, so you must convert your VS FORTRAN applications to the OS/390 version of VS FORTRAN. You should read the Language Environment V1R5 FORTRAN Migration Guide for information about migrating to Language Environment-enabled FORTRAN. 17.4.
Table 41 (Page 2 of 2). ILC Migration Considerations To Migrate: A phase containing one or more VS COBOL II programs, with calls to or from C/370 You Need To: 1. Upgrade the C/370 source code, and compile with OS/390 C/C++. 2. Transfer the VS COBOL II object code to OS/390. 3. Link-edit the load module with OS/390 Language Environment. 17.4.8 Migrating Assembler Applications The Assembler distributed with OS/390 is the High Level Assembler for MVS & VM & VSE (HLASM).
ABPERC In LE/VSE you can specify the abend code to the option ABPERC in one of three formats. These formats are: • • • Shh I hh Udddd In OS/390 Language Environment you can only specify Shh or Udddd. I hh is not allowed, and if you specify it you will receive an error message similar to: CEE3616I The string ′ I12′ was not a valid suboption of the run-time option ABPERC.
TEST The IBM defaults for the TEST option differ between LE/VSE 1.1, LE/VSE 1.4 and OS/390 Language Environment. They are: LE/VSE 1.1 NOTEST(NONE,*,NOPROMPT,*) LE/VSE 1.4 NOTEST(ALL,*,NOPROMPT,′′) OS/390 Language Environment NOTEST(ALL,*,NOPROMPT,INSPPREF) You should read the OS/390 Language Environment Programming Reference for information about the TEST option in OS/390 Language Environment. Note: If you are migrating from LE/VSE 1.1, you should check your use of the TEST option carefully. In LE/VSE 1.
17.5.1.2 Run-time Options and LE/VSE 1.4 and Later Releases The following options were introduced in LE/VSE 1.4, but their usage in OS/390 Language Environment is sometimes different. They were not available in LE/VSE 1.1. ARGPARSE This option only applies to C and can only be specified with the C #pragma runopts directive. #pragma runopts is not available with C++ so you should change your application to use the C++ ARGPARSE compiler option.
17.5.1.3 Recommended Settings for Options The recommended settings for options for OS/390 Language Environment are described in the OS/390 Language Environment Migration Guide . The recommended settings for options for LE/VSE 1.4 are described in the LE/VSE Run-Time Migration Guide Release 4 . For LE/VSE 1.1, where IBM made recommendations for the setting of options, they are described in the LE/VSE Programming Guide Release 1 , under the description of the option. Note: In LE/VSE 1.
Table 43 (Page 2 of 2). Option Recommendations Differing between LE/VSE 1.4 and OS/390 Language Environment Language Option Recommendation PL/I ABTERMENC RETCODE DEPTHCONDLMT 0 STACK 128K,128K,BELOW,KEEP TERMTHDACT TRACE 17.5.2 User Exits and Abnormal Termination Exits This section discusses migration considerations for user and abnormal termination exits, and the similarities and differences between the exits for OS/390 Language Environment and LE/VSE. 17.5.2.
In OS/390 Language Environment a sample job, CEEWHLLX, is provided that contains an SMP/E USERMOD to replace the IBM-supplied HLL user exit with your HLL user exit. 17.5.2.3 Abnormal Termination Exits Language Environment provides the ability to invoke an abnormal termination exit before it terminates a thread due to an unhandled condition of severity 2 or greater. This allows an abnormal termination exit to collect problem determination data before Language Environment frees the resources it has acquired.
CEE5ABD CEE5CIB CEE5CTY CEE5DMP CEE5GRC CEE5GRN CEE5GRO CEE5LNG CEE5MCS CEE5MDS CEE5MTS CEE5PRM CEE5RPH CEE5SPM CEE5SRC CEE5SRP CEE5USR Figure 56. Callable Services in LE/VSE 1.4 with Differing Names in OS/390 Language Environment Note: Three further callable services are available in LE/VSE releases later than 1.4, and in LE/VSE 1.4 via APAR PQ08538. They are also available in OS/390 Language Environment. They are: • • • CEEMRCE CEE4SRP CEE5GRO 17.5.3.
The recommended settings for run-time options for CICS, are the same for OS/390 Language Environment and for LE/VSE, with the following exceptions, listed in Table 44 on page 367. Table 44. Option Recommendations for CICS Differing between LE/VSE and OS/390 Language Environment Language Option Recommendation COBOL LIBSTACK 1K,1K,FREE TERMTHDACT UADUMP DEPTHCONDLMT 0 ERRCOUNT 0 PL/I 17.6.3 User Exits and Abnormal Termination Exits These are discussed in 17.5.
368 VSE to OS/390 Migration Workbook
Chapter 18. Procedure Language REXX The REstructured eXtended eXecutor language, or REXX language, is a versatile, easy to use structured procedure language that is part of: • • • VM/ESA VSE/ESA TSO/E REXX was designed as a replacement for the EXEC and EXEC2 languages that provided a way to bundle Conversational Monitor System (CMS) commands together.
18.4 Environments The system under which REXX procedures run is assumed to include at least one environment for processing commands. An environment is selected by default on entry to a REXX procedure. You can change the environment by using the ADDRESS instruction: address address address address cms /* VM/ESA CMS environment */ POWER /* VSE/ESA POWER host command environment */ TSO ″ALLOC F(SYSOUT) DSN(my.dsn) SHR″ DOS ′ DIR MDV1.
18.4.3 TSO/E Environment TSO/E provides among others the following host command environments: • • • • • TSO allows you to invoke TSO/E commands and services. CONSOLE allows you to invoke MVS system and subsystem commands during an extended MCS console session. ISPEXEC and ISAREDIT allows you to invoke ISPF commands and services, and ISPF edit macros. CPICOMM, LU62, and APPCMVS allows you to use the SAA common programming interface (CPI) Communications calls.
18.5.1 REXX and SAA Issuing commands to the surrounding environment is an integral part of REXX. REXX is the only procedure language supported by the SAA to help provide cross-system consistency. Procedures written in REXX according to the SAA specifications can be transported to other SAA environments. For example, a REXX exec in CMS can also run in a TSO/E environment if the exec does not use system-specific functions or commands.
Part 4. Converting VSE Utilities to OS/390 Utilities In addition to this part of the book on converting utilities, also see Chapter 29, “Orientation for Utilities” on page 455 which discusses more OS/390 Utilities that you can use. Copyright IBM Corp.
374 VSE to OS/390 Migration Workbook
Chapter 19. SORT This chapter addresses considerations for migrating to the OS/390 Sort product, DFSORT (5740-SM1) from the VSE Sort products: • DOS/VS SORT/MERGE V2 (5746-SM2), referred to as Sort/Merge • DFSORT/VSE V3 (5746-SM3), referred to as DFSORT/VSE DFSORT/VSE is based on and replaces Sort/Merge. It offers additional features not available with Sort/Merge. The migration considerations for Sort/Merge will be discussed first. These considerations also apply to DFSORT/VSE.
//MYJOB JOB ... //SORTIT EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD DSN=... //SORTOUT DD DSN=... //SYSIN DD * SORT FIELDS=(5,4,CH,A) /* The JCL statements you will commonly need when migrating are: JOB: Must be the first statement for a job. EXEC: Must be the first statement for a step. Specifies the program to be executed. For DFSORT steps, use PGM=SORT or PGM=ICEMAN. SYSOUT DD: Defines DFSORT′s message data set.
19.2 Control Statements DFSORT was designed to be functionally compatible with Sort/Merge at the control statement level, and for the most part, the control statement syntax of the two products is compatible. However, there are differences in some of the control statements that you will need to address. Here are the actions, if any, you should consider taking for each Sort/Merge control statement. ALTSEQ: Can be used with no changes. ANALYZE: Must be removed.
• ERASE: Can be used with no changes. DFSORT ignores ERASE. Use a security product, such as RACF, to erase the work data sets. • NOERASE: Can be used with no changes. DFSORT ignores NOERASE. DFSORT does not erase work data sets. • FILNM: Must be removed. DFSORT terminates if this operand is specified. Use DFSORT′s SORTIN, SORTOUT or SORTDD operands to change the input and output ddnames. • LABEL: Must be removed. DFSORT terminates if this operand is specified.
19.3 Additional DFSORT/VSE Migration Considerations DFSORT/VSE is based on and replaces Sort/Merge. It offers additional features not available in Sort/Merge. All of the migration considerations discussed previously for Sort/Merge apply to DFSORT/VSE as well. Migration considerations for additional features of DFSORT/VSE are discussed below. 19.3.1 Control Statements OPTION: DFSORT/VSE has additional OPTION statement operands not found in Sort/Merge.
• p,m,Y2x: Must be removed. DFSORT terminates if this operand is specified. p,m,Y2x can be specified in the OUTREC operand of DFSORT′s OUTFIL statement. • p,m,PZ: Must be removed. DFSORT terminates if this operand is specified. p,m,PZ can be replaced by p,m,PD0,M11 in the OUTREC operand of DFSORT′s OUTFIL statement. • p,m,PSI: Must be removed. DFSORT terminates if this operand is specified. p,m,PSI can be replaced by p,m,PD,M11 in the OUTREC operand of DFSORT′s OUTFIL statement.
Chapter 20. DITTO Data Interfile Transfer, Testing, and Operations Utility (DITTO) is IBM′s best known storage media and data maintenance utility program for the OS/390, MVS, VSE, and VM environments. DITTO is a key resource for data processing professionals due to many versatile functions working with tapes, disks, VTOCs and catalogs, VSAM data, VSE library members, sequential data sets and files, MVS Object Access Method (OAM) objects, and card images.
double asterisk (**) represents any number of characters in any number of qualifiers. Under VSE and CMS, an implicit rewind was previously performed by each function that works with labeled tapes. Labeled tape functions could only work with the first file on a tape. The implicit rewind is no longer performed. This lets you work with multifile standard labeled tapes. 20.
Function Description Replacement SD, SDD Split-Cylinder Disk Dump - SDU SAM to Diskette - SIS SAM File to ISAM File - SP, SPD Split-Cylinder Disk Print - SRS Split-Cylinder Disk Record Scan - TDD Tape Dump Deblocked TP TDU Tape to Diskette - TDV Tape Dump Variable TP TIS Tape to ISAM File - TPD Tape Print Deblocked TP TPV Tape Print Variable TP VDU VSAM to Diskette File - VIS VSAM to ISAM File - 20.
20.4 DITTO Function Code Synonyms The following table lists supported synonyms for DITTO function codes.
20.6 Batch Keywords that are Not Recommended The following table lists obsolete keywords from previous releases of DITTO that are still recognized by DITTO/ESA in batch mode. It is recommended that you use the indicated replacement, if any.
386 VSE to OS/390 Migration Workbook
Chapter 21. VSAM Backup/Restore 21.1 VSAM Backup/Restore The following describes the methods and utilities used in OS/390 as compared to VSE VSAM Backup/Restore procedures. 21.1.1 OS/390 VSAM Backup/Restore There are several tools that can be used in an OS/390 system to back up and restore VSAM files. Considerations for which tool you may want to use can be found in Chapter 4 of DFSMS/MVS Using Data Sets , SC26-4922.
Operations: 1. Handle several VSE/VSAM files with a single command, either with a generic name or as files of one catalog. 2. Restore VSE/VSAM files to locations, volumes, and device types that are different from those where the files were before. 3. Exclude files from a collective backup or restore operation. 4. Tune the performance of VSE/VSAM by specifying the size of the buffer in the BACKUP command, and the number of buffers in both the BACKUP and RESTORE commands.
Chapter 22. Librarian Both VSE and OS/390 have facilities to help you define, organize, and manage libraries of system data. In VSE these system facilities are called the Librarian . In OS/390, the equivalent function is provided by Partitioned Data Sets (PDS) and the newer Partitioned Data Set-Extended (PDSE), and the group of utilities used for their management, including the Partitioned Access Method (PAM) and the Interactive System Productivity Facility (ISPF).
functional enhancements of the VSE Librarian. The Librarian functions can be invoked through a console or through job streams (JCL). In OS/390, each of the different utilities used to create and maintain PDS (or PDSE) data sets and their members has a different set of commands and somewhat different syntactical requirements. Combined with OS/390 JCL, the overall functions available are similar to the functions provided for VSE libraries.
22.1.2 OS/390 Library Management The Software Configuration Library Manager (SCLM), a component of ISPF, introduces an object-oriented approach to library management and software development. The objects SCLM can control are members in partitioned data sets. SCLM keeps track of objects by means of multiple distinct VSAM files containing the accounting information of a member for a specific group. The library management functions of SCLM are intertwined with SCLM′ s configuration management functions.
392 VSE to OS/390 Migration Workbook
Chapter 23. LISTLOG/PRINTLOG - Printing Log Streams Both VSE and OS/390 provide facilities to capture system log data in a hardcopy file, and means to display, print and archive it. There are two utilities in VSE that help you print copies of your system hard-copy file and information about jobs that run in your system: PRINTLOG and LISTLOG. In OS/390, the system hardcopy log can be saved on JES spool or in a log stream managed by the system logger, and printed by JES. 23.
23.3.1 SYSLOG The system log (SYSLOG) is a data set residing in the primary job entry subsystem′s spool space. It can be used by application and system programmers to record communications about problem programs and system functions. The operator can use the LOG command to add an entry to the system log. SYSLOG is queued for printing when the number of messages recorded reaches a threshold specified at system initialization.
23.5 JES2 System Data Sets - Job Log and System Messages The job′s hardcopy log and any system messages related to the job are managed by JES2 as the ″System Messages″ for each job. Based on installation specifications and overridden on the job′s JCL, they can also be saved or not based on the normal or abnormal termination of the job. These can be sent to a SYSOUT class that is held for viewing only and archived for permanent records. 23.
396 VSE to OS/390 Migration Workbook
Chapter 24. VSE/Fast Copy and OS/390 DFSMSdss The following briefly describes VSE/Fast Copy and the comparable OS/390 component, DFSMSdss. 24.1 VSE/Fast Copy (Online and Stand-Alone) In VSE/ESA Version 1, VSE/Fast Copy runs stand-alone only. The on-line functions of VSE/Fast Copy have been incorporated into the program ″VSE/Fast Copy Data Set (VSE/Fast Copy).″ In VSE/ESA Version 2, VSE/Fast Copy (Online and Stand-Alone), was incorporated into the base code, VSE Central Functions.
24.2 DFSMSdss - OS/390 Component DFSMSdss has four functions to help you manage your DASD space: • COMPRESS Compresses your partitioned data sets by taking unused space and consolidating it at the end of the data set. To make the unused space available for other data sets, you must use the RELEASE command. This does not apply to PDSEs. • RELEASE Releases the unused space in sequential and partitioned data sets for use by other data sets.
Part 5. Setting Up the Migration Environment Copyright IBM Corp.
400 VSE to OS/390 Migration Workbook
Chapter 25. Prepare the Migration Environment 25.1 Introduction Setting up the OS/390 environment, similar to setting up the VSE environment, involves installing the prerequisite hardware and software, and tailoring the system for your environment. As an example, we can describe it with the following steps: 1. Install and configure the required hardware. 2. Order and receive the OS/390 software along with all desired features, corequisite products, publications and so on. 3. Install the OS/390 software.
25.2 Install and Configure Required Hardware VSE and OS/390 operating systems both use the same basic S/390 hardware platform, although you will find that OS/390 may require more processor power, storage and DASD resources. On the other hand, OS/390 also provides more function, supports more devices, and is easier to manage as your applications and workload grow. 25.2.
A beginning rule of thumb shows 12 volumes of 3390-3 (or equivalent) DASD, allocated as follows: (Your mileage will vary!) Table 45.
OS/390 through cross-domain resource definitions. They are also useful for data transfer via NetView FTP or NJE. OSA (Open System Adapters) are often the most economical solution. You will want access to other devices in your installation. They can be switchable or connected via a common local area network (LAN). See the OS/390 MVS Recovery and Reconfiguration Guide , GC28-1777 for more configuration planning information. 25.2.
25.2.5.4 Data Transfer and NJE You will want to set up an NJE connection between the two systems for remote job submission and for routing print files or bulk data between the two systems. Use the same communication controllers, real Channel to Channel adapter (CTC) controlled by VTAM or virtual CTCs. You have several choices with ESCON CTCs, virtual CTCs under VM, and 3088s. See 25.5.1.5, “Providing NJE Connection to the OS/390 System” on page 415.
25.3.1.2 SoftwareXcel SystemPac/MVS The SystemPac installation offering is a world-wide offering similar to SIE, but without on-site assistance by IBM. You can use this to tailor OS/390 to your environment (such as DASD layout, migration of MVSCP/IOCP to IODF, and naming conventions) based on information provided to IBM. With this offering, selected non-IBM products can be integrated. This offering can be delivered in IEBCOPY dump-by-data-set format or in full volume dump format.
25.3.2.2 CBPDO Custom-Built Product Delivery Option is a software delivery package consisting of uninstalled products without integrated service. You must use SMP/E to install the individual OS/390 elements and features, and their service, before you can IPL. This method is not recommended for the new OS/390 installation. 25.4 Set Up Standards, Procedures, and Documentation You now have a running system that is tailored to your environment and users.
Related Redbooks Here is a list of DFSMS ″Fast Implementation Techniques″ (FIT) Redbooks: • • • • • DFSMS FIT: Fast Implementation Techniques Process Guide , SG24-4478 Get DFSMS FIT: Fast Implementation Techniques , SG24-2568 DFSMS FIT Forms and Foils , SG24-2570 DFSMS FIT: Fast Implementation Techniques Installation Examples , SG24-2569 DFSMS/MVS V1R4 Technical Guide , SG24-4892 25.4.1.2 MVS Naming Standards The following OS/390 resources are all identified by names.
Other MVS Names There are many other objects which require naming in OS/390. Here is just a sample: • • • • • • • Users (TSO, online, batch, operators) Job names Job step names JCL procedure names and proclibs Application program names WLM service classes WLM resource environments 25.4.1.3 JCL Standards You should set up JCL (job control language) standards for your batch jobs, as well as started tasks and TSO logon procedures.
25.4.2.1 Enforcing Installation Standards You will continue to refine the standards developed above, and should use RACF to protect critical resources. You can also use installation exits to enforce standards not controlled by RACF, but keep in mind that it is often easier to enforce them through other procedures. 25.4.2.2 Implementing System Security OS/390 users have access to all data sets in the system unless specifically restricted via the security product.
25.4.2.5 Setting Up Critical Operations Procedures You should set up, test, and document procedures that are critical to the smooth operation of your system.
25.4.3 Documentation You should already have the following planning publications which are available as part of the OS/390 Installation Planning Kit , GK2T-6710: • OS/390 Planning for Installation , GC28-1726 • OS/390 Introduction and Release Guide , GC28-1725 • OS/390 Information Roadmap , GC28-1727 The Information Roadmap will then list the other publications you may need. 25.4.3.
25.5 Customize Your New OS/390 System Before you start using your new OS/390 system, you must complete the installation and tailoring process by customizing the system for your use. Depending on what method you used to install the software, some of the items listed below may already have been completed for you or you may have contracted for some additional service assistance to perform these items.
IBM′s comprehensive testing does not replace the need for this testing in your own environment. Here are some sample steps copied from the OS/390 Checklist: 1. Initialize the system (IPL) 2. Initialize JES2 3. Log on to TSO/E 4. Run the installation verification programs (IVPs) 5. Submit a job and check its output 6. Sign on to a terminal with CICS or IMS and initialize a region 7. Submit a CICS or IMS transaction and look at the results 8.
25.5.1.4 NetView FTP Access You can also use the same VTAM connections to send bulk data between the two systems with NetView FTP. See NetView FTP V2 MVS Installation, Operation, and Administration , SH12-5657. 25.5.1.5 Providing NJE Connection to the OS/390 System You can connect VSE/POWER and OS/390 JES2 systems together via NJE to route jobs and output from one system to the other.
25.5.2.3 Tailoring Other Components Other features of OS/390, such as JES2 are described in other chapters of this book. The elements of OS/390 are listed below and each has its own set of books on installation and customization. 25.5.3 Other OS/390 Elements OS/390 is made up of base elements and optional features. Here is a list of the pieces you may have with OS/390 Version 2 Release 4.
25.5.3.3 Independent Software Vendor Products If you chose to use ISV (non-IBM) products, you should recognize the additional implementation, customization, maintenance and tuning requirements that accompany them. Chapter 25.
418 VSE to OS/390 Migration Workbook
Chapter 26. Test Environments This chapter describes the different needs for test systems during and after the migration to OS/390. There are many valid test configurations which vary according to your installation′s testing and maintenance philosophies, as well as your environment.
Application Development & Test System A system that is expected to stay up without disruption at least during ″normal working hours″. Understand that any outages to this system will affect your applications conversion and testing activities. This logical image may eventually become your production OS/390 system when you cut-over. Maintenance System The next version of operating system software, or next round of maintenance that will be rolled forward into production.
3 Final System Test on OS/390 Just before you migrate to OS/390, you should run all your important applications in parallel, using the same environment as above. Compare the results of both systems to make certain there are as few surprises as possible. 4 Final Production Cut-Over to OS/390 (″D″ Day?) When you finally migrate your production applications to OS/390, you will need a backup VSE system standing by for emergency rerun of applications that uncover any conversion problems after you go live.
evaluate each of the alternatives mentioned, but that would be beyond the scope of this book, and not necessarily relevant to the task at hand. Since this document is directed toward migration of VSE systems to OS/390 primarily on CMOS processors, we will not consider the choices of physically partitioning one or more processors, since this option is not available on CMOS processors.
Recent advances in the PR/SM LIC have solved some of the real storage management difficulties encountered in the past concerning assigning contiguous storage chunks to LPARs. In addition, ESCON Multi Image Facility (EMIF) channels have reduced the number of physical channels that must be installed to support multiple partitions by allowing for the sharing of physical channels between partitions.
central storage as if it were running natively on the processor. While storage is dedicated to a particular virtual machine, it is unavailable to other virtual machines, and also VM/ESA itself. VM/ESA however, provides much more than simply hypervisor, and virtualization functions. It also provides a full function, interactive, virtual machine operating system, CMS. CMS provides an unmatched interactive environment for program execution, and program development.
installed. This support exists in VM/ESA Version 2 Release 3 on Multiprise 2000, 9672 G3, and G4 processors. If you are currently using VM/ESA as a hypervisor for your production VSE guest(s), as well as for test VSE guests, then proceeding with the migration process involves nothing more than defining additional guest virtual machines for OS/390 images.
VM/ESA distribute that communication capability among the guest images using virtual channel to channel devices. Similarly, any DASD that is shared between the VSE LPAR(s) and the VM/ESA LPAR can be defined through R/O minidisk definitions owned by a place holder virtual machine, and accessed through R/O links from the OS/390 guests. 26.3.3.
new vendor package that runs under AIX. As guests of VM/ESA, all three can run efficiently while sharing one processor. • You have production applications that need to be reworked to comply with Year 2000. With VM/ESA′s Guest Support you can bring up a duplicate of your production system, set the clock to a date and time beyond the year 2000 then perform test and application debugging without disrupting your current production system.
VM/ESA and its customers exclusive technical advantages not available in any other operating system platform. Operations Management With PROP (VM/ESA′s PRogrammable OPerator) you can cut your console traffic substantially. This saves time and reduces errors. Recovery Management You can build guest virtual machines to simulate systems at your organization′ s other sites. So, VM/ESA can become a disaster-recovery backup site.
distributed servers. VSE, OS/390, TPF, AIX and others are discovering the enormous value VM/ESA brings to the table. DB2 Guest Sharing With DB2, VM, VSE and OS/390 users can now share a DB2 database among several VSE and/or OS/390 guests. For most customers, consolidating several guest databases into one DB2 database reduces administrative work, simplifies operation, increases data integrity, and improves performance.
26.3.3.5 OS/390 Guest Considerations The considerations for defining OS/390 guests are no different from those associated with defining VSE guests. From the VM/ESA point of view, the actions taken to maximize the performance of a VSE guest, would be the same as those taken to maximize an OS/390 guest. For example, specifying resource goals is done through the SHARE directory statement.
26.5.1 OS/390 Maintenance Environment Early in the project a test SMP/E environment needs to be designed and built. This process involves ″cloning″ the OS/390 system libraries to provide a new target to apply OS/390 maintenance without compromising the OS/390 production environment. Since OS/390 was installed at the beginning of the project, the maintenance level could be well over a year old by switch-over time. It is highly recommended that a maintenance cycle be performed before switch-over.
26.6 Shared DASD vs. Cloned DASD The issue of whether to share DASD volumes and data sets between systems is decided on the basis of DASD space availability, need for multiple versions of a file, and the ability to manage updates between the two systems. 26.6.1 Shared DASD between OS/390 Test Systems (vs. Cloned DASD) The decision to share data sets and volumes or to make copies of them for each OS/390 system should be thought out carefully.
26.6.2 Shared DASD between VSE and OS/390 (vs. Cloned DASD) As mentioned in the previous section, it is risky to share DASD between VSE and OS/390 because there is no mechanism such as GRS to guarantee serialization between the two systems. If you decide to share, you must strictly control updates from the two systems, or be prepared to restore volumes, files and catalogs should they become corrupted. Chapter 26.
434 VSE to OS/390 Migration Workbook
Part 6. Running Your OS/390 System Copyright IBM Corp.
436 VSE to OS/390 Migration Workbook
Chapter 27. Orienting ICCF Users to TSO/ISPF There are many facets of VSE/ICCF that are done differently in OS/390. TSO along with ISPF and SDSF provide functions that were previously done using VSE/ICCF. 27.1 TSO/ISPF and SDSF ISPF is a dialog manager and runs under TSO on OS/390. ISPF provides a powerful environment that can be used for both development activities along with job submission. SDSF extends this environment by providing facilities that allow for both job monitoring and job output viewing.
also build lists of personal data sets. Personal data set lists are a good way to group (by project, for example) those data sets that you use frequently. • Ability to run foreground and batch processors such as Assembler H, VS COBOL, VS FORTRAN, PL/I optimizing compiler, Binder/Linkage editor, C/370, REXX/370, and C/C++ for MVS/ESA. • Ability to test individual dialog elements and complete dialogs using ISPF′ s Dialog Test option.
• finding specific character strings in the data, changing them to other character strings or to exclude the lines that contain strings, • setting HEX mode on to allow you to display data in hexadecimal format, • using language sensitive coloring, which highlights program constructs based on the programming language, improving readability, • using the HILITE command to change the enhanced coloring and language sensitive coloring options of the editor.
27.1.4 Creating and Executing ISPF Applications Since ISPF is a dialog manager, many other products have written dialogs, connect themselves through the main menu and run as additional ISPF functions. Products such as SDSF, IPCS, RACF, SMP/E and QMF all provide dialogs that run with ISPF. Users or system programmers can also write their own dialogs for specific applications using ISPF′s DM services.
For more information see the OS/390 ISPF Software Configuration and Library Manager Developer ′ s Guide, OS/390 ISPF Software Configuration and Library Manager Project Manager ′ s Guide, and OS/390 ISPF Software Configuration and Library Manager Reference. 27.1.6 Tracking Jobs SDSF allows you to monitor any job in the system or sysplex. Values such as CPU time and I/Os per second are displayed for all of the jobs running in the system.
442 VSE to OS/390 Migration Workbook
Chapter 28. Orientation to OS/390 Console Operation 28.1 Introduction There are enough differences between VSE and OS/390 operations to warrant each operator and systems programmer attending a class on the subject. This chapter is intended only to provide the reader with an overview of OS/390 console operations on a single system. (Multi-system or sysplex operation are not covered here.) It is not intended to replace more formal training which should be given to all OS/390 operators and system programmers.
• • • NetView Consoles TSCF Consoles Programmed Operator Subsystems This chapter will only deal with MCS and SDSF consoles. 28.2.1 Controlling Consoles There is more to operating an OS/390 system than just entering commands and reading the messages. You should also be familiar with various console configuration options.
28.2.2.2 Display Areas These may be handy for operating a console with a lot of traffic, when you want to see a multi-line display without having it roll off the screen. However, operators need to be able to manipulate these display areas for efficient operation. Enter ″K A,NONE″ to get rid of display areas, or ″K A,nn″ to create an area of size ″nn″. An alternative is to use the SDSF ULOG panel which limits the display to just those commands and messages issued for the specific user.
28.2.3.2 Using SDSF for System Operation Below is the Primary Option Menu for SDSF showing you the basic panels you can use as a full-screen system operator.
28.3 Controlling the OS/390 System The OS/390 System commands are only a subset of the commands necessary to operate the system. JES2, VTAM, and many other OS/390 components also have a command language which is used to operate their subsystems. We recommend that systems programmers and operators attend a class on basic OS/390 (MVS) and JES2 facilities. In addition, there are more advanced classes such as the ″CMOS Complex Systems Availability and Recovery″ (five days).
28.3.3 Stopping the System There are several ways to stop or halt the system, and important subsystems.
28.4.3 JES2 Devices Devices such as printers, punches, TP lines, and spool offload tapes can be allocated by JES2 dynamically. The following JES2 command verbs are used to control JES2 devices and are followed by the device name such as PRT1, PUN(12), LINE(5).
28.5.1.1 MVS Commands Use the DISPLAY JOBS, J, A, or TS command to display information about current system activity, including time-sharing users, batch jobs, and started tasks. The MVS ″TRACK″ and ″MONITOR″ commands also provide assistance with periodic updated displays in a display area. 28.5.1.2 JES2 Commands There are many JES2 commands to display the work on your system: $DA Use the $DA command to display information about active jobs, started tasks, and time-sharing users.
28.5.2 Controlling Time Sharing Users TSO/E users logon through terminals controlled by VTAM. You can use MVS or JES2 commands to control TSO users and their output: • Send a ″SEND ″,U = ( will get • Cancel the TSO session with the MVS ″CANCEL U=userid″ command, or the JES2 $C command. Message to a TSO User with the MVS ′message_text′,U = u s e r i d ″ command. Be careful not to omit the )″ operand, or your message will be sent to all TSO users and they aggravated with this if it happens repeatedly.
28.6 Managing Remote Operations As with VSE, remote systems and workstations can communicate through NJE or RJE via commands and messages. Some remote workstations and systems have console operators, while others may not. The remainder of this chapter describes how to communicate via JES2 commands. 28.6.1 JES2 RJE Operations There are many kinds of remote workstations: BSC and SNA, ones with just a reader and printer, and others with consoles, disks and spooling capability.
$D MMn,′Please restart my printer′ Send a message to the operator on member n See JES2 Commands for details. The “Remote Job Entry” section in Chapter 2 has good guidance information for RJE operations, and Chapter 5 has detailed command syntax descriptions. Remotes Without Consoles If you don′t have a console on your remote workstation, you can still submit commands and JES2 control cards through the logical (or physical) card reader.
$D PATH(node_name) Display the path(s) to another node $D Nxx.′$D NODE(yy)′ Send a command to node xx to display the status of node yy $D MNn,′Please drain your session′ Send a message to an operator on another node See JES2 Commands for details. Chapter 4 has good guidance information for NJE operations, and Chapter 5 has detailed command syntax descriptions.
Chapter 29. Orientation for Utilities 29.1 IEBxxx or IEHxxx There are many utilities in OS/390 provided by DFSMS/MVS to assist you in organizing and maintaining data (most of them start with ″IEB″ or ″IEH″). These are simple programs which perform commonly needed functions. See ″Guide to Utility Program Functions″ in Chapter 1 of DFSMS/MVS Utilities , SC26-4926. 29.2 IEBCOPY IEBCOPY is a utility program used to make copies of, and to maintain, partitioned data sets.
• • • Reblock or change the logical record length of a data set. Copy user labels on sequential output data sets. Supply editing facilities and exits for your routines that process labels, manipulate input data, create keys, and handle permanent input/output errors. Information on IEBGENER is provided in DFSMS/MVS Utilities , SC26-4926. 29.5 DFSMSdss DFSMSdss is a direct access storage device (DASD) data and space management tool. DFSMSdss works on DASD volumes only in the MVS environment.
Chapter 30. Systems Management Philosophy and Methodology Many VSE installations have small staff and have mature systems which are changed relatively infrequently. As a user migrates from VSE to OS/390, their entire system -- hardware, software, and connections -- will be subject to more frequent changes. The workloads supported by their system will grow in complexity and criticality to their business.
In many smaller computer installations, where at most a few people are involved in system changes, ad-hoc and informal techniques have often proved adequate. All or us have seen a case where the complaint is lodged: ″It doesn′t work right.″ Oh, what seems to be the problem? ″Payroll doesn′t work right.″ ″What did you change?″ Nothing...
• Places a stronger emphasis on service, as it promotes keeping one′s ″eye on the ball.″ • Provides more effective and productive processes. Challenges in this approach are not just to segment the activities, but also to recognize how the disciplines interrelate and how they cross functional boundaries. Also, all responsibilities must be assigned and understood, and disciplines documented. 30.1.
well, and the disciplines should include those to avoid ″the hole in the boat isn′ t on my side of the ship, so all is well″ syndrome that can develop. 30.1.3 The Role of Automation Automation involves the ability to correct, bypass, or circumvent failed system and network elements and applications, based on defined policies and using hardware or software functions without human intervention. Automation improves availability and reduces operational costs.
• Scheduling - occurs during the planning process, and aids in identifying conflicts and impacts, and determines target dates for changes. • Distributing - this depends on the type of change, for example rolling out new levels of software across several systems. • Installing - the actual installation of changes. Installation should be able to be scheduled for a particular date and time of day. • Backout - reversing a change if it does not meet the installation or test criteria.
30.3.2 Tasks The problem management process includes the following: • Problem determination - the detection of the loss or impending loss of availability of a system resource to its users, and the isolation of the detected problem to the failing hardware, software, or microcode component. • Problem diagnosis - the determination of the specific cause of a problem and the action required to resolve it. Diagnostic data gathered during problem determination provides input to this step.
update and manage problem management records, but use of a searchable database technology, such as DB2 or a custom problem management package such as TME 10 Information Management will be very helpful. 30.4 Performance Management 30.4.1 Overview Performance management addresses the effectiveness with which information system components work together in order to achieve the optimum throughput and responsiveness with a given hardware/software configuration.
⇒ Establishing performance specifications and policies.
Projected trends recorded in this way represent accurate growth measurements. These projections can be used to identify needed changes in system configuration with sufficient lead time to permit orderly procurement and installation of new resources. This will provide the capacity required over time as your system grows. 30.5 Operations Management 30.5.1 Overview Operations management includes tasks for planning distributing, evaluating, and controlling workloads.
• Automated Operations - handles the complex operations job scheduling procedures to ensure that work is completed in a timely manner. ⇒ Verifying that the resources needed for a scheduled workload are available; for example, that the required disk or tape volumes are available for a backup operation. ⇒ Planning to ensure the availability of day-to-day operations items, such as printer paper, tapes, and control center equipment.
the MPF list can be customized to carry this out. For other automation tasks, IBM provides several products to support workload and operational planning and control: • TME 10 NetView, while many think of it as a network management product, is also a robust automated operations product for detecting and reacting to messages and alerts (for a wide variety of platforms), and carrying out automated and monitoring actions.
The following books contain planning information for automation and illustrate sample automated operational scenarios using IBM Systems Management products: • TME 10 NetView Automation Guide , SC31-8225 • Integrated Centralized Automation/Advanced Operation , GG24-2599 Using the products below to support operational tasks will allow you to support growing workloads, as well as growing numbers of OS/390 images, in an efficient manner.
30.6.3 Methodology In VSE, users with security needs frequently use one or another vendor security package, as IBM provides only simple access control and logging security. In the OS/390 environment, in addition to vendor program offerings, IBM provides the OS/390 Security Server (a follow on to the highly regarded RACF product). The Security Server provides system security services to ensure secure access from batch and online user programs to flat files, VSAM files, and databases.
• Configuration creation - building and maintaining a configuration description that is resource-specific. • Updating configuration information - providing vital product data, topology data, and other configuration data when a change is made to the configuration. • Accessing configuration information - providing information on the actual or planned resources, specific resource attributes, paths to or from a target resource, version information for software, and similar data. 30.7.
30.8 Asset Management 30.8.1 Overview Asset management provides for managing the information technology inventory of resources, including both physical and intellectual assets. The components that you will use to support your workloads in the OS/390 environment all have business attributes - just like any asset in your company - that have to be accurately known and tracked. 30.8.
30.9.2 Tasks Accounting management activities include the following: • Measurement - collection of actual usage and service-level data. • Cost allocation - creation of billing and charge-back transactions, including interfaces to other administrative applications or processes. • Allocating and tracking project and other support costs. • Creating and managing billing systems. 30.9.
Chapter 31. Diagnosing System Problems 31.1 Problem Determination Tools Several tools are available under OS/390 to help the system programmer diagnose problems. The majority of these tools are intended for system problems rather than application problems and are often activated under the guidance of the IBM or ISV support center. 31.2 Dumps There are many different types of dumps available in OS/390 for various situations.
• Reduce the size of a stand-alone dump. You can reduce the size of a stand-alone dump as you transfer it from tape to a direct access storage device (DASD) for IPCS processing. 31.3.2 Traces There are a number of traces available in the OS/390 environment: • OS/390 System Trace. A low overhead trace that uses a System 390 architected instruction. The trace provides a summary of system processing and is normally running continuously. This trace is present in all dumps. • Master Trace.
31.4 JES2 Diagnosis There are some JES2 mechanisms that can be used for problem determination. • $TRACE: JES2 internal tracing can be activated via $S TRACE; $T TRACEDEF; $P TRACE commands. These are typically requested by IBM service personnel. • SYMREC: Symptom records are recorded in the LOGREC file for some JES2 internally discovered problems. Use EREP to format these entries. • HASP088 message: When JES2 terminated abnormally, a HASP088 message is generated.
addition, IPCS can be used to format the in-storage LOGREC buffers while analyzing a dump. 31.8 SYSLOG All system and job related messages along with all operator commands are written to the SYSLOG JES spool data set. SDSF (under TSO) can be used to view the SYSLOG to aid in problem determination. 31.9 DFSMS/MVS Diagnosis DFSMS/MVS provides many tools to assist a system programmer diagnose problems. Each component provides its own diagnosis documentation. 31.9.
No matter what utility is used to perform the backup and recovery of a catalog, the process isn′t complete until the catalog is resynchronized with the data sets as they currently exist. Between the time the catalog was backed up and restored, data sets have been deleted and defined and the catalog has to be updated to reflect these changes. These changes to catalogs, or catalog events, are recorded in SMF records.
31.9.3 DFSMSrmm The diagnosis document for DFSMSrmm is the DFSMS/MVS DFSMSrmm Diagnosis Guide , SY27-9615. It documents how to obtain diagnostic information, eliminate common sources of errors, using the DFSMShsm Problem Determination Aid (PDA) trace formatter program, and building keyword search strings. Maintaining the DFSMSrmm control data sets and report creation is documented in the DFSMSrmm Implementation and Customization Guide , SC26-4932. 31.9.
Part 7. Converting your Applications Copyright IBM Corp.
480 VSE to OS/390 Migration Workbook
Chapter 32. Conversion Process Converting a data processing installation from VSE/ESA to OS/390 is a complex process that affects all areas of an installation. Personnel must learn different procedures; operations work changes in many ways and applications that run under VSE require conversion before they run under OS/390. Even managing the migration project, which includes planning, allocating people and resources and tracking the migration process, is a complex job.
• Refer to MVS MS - Production Standards , LB11-8080. 6 Translating the programs, taking into account the differences between VSE and MVS for each programming language. • • • Refer page Refer Refer to Part 3, “Converting VSE Languages to OS/390 Languages” on 247. to the specific program, utility or database section in this book. to 2.7, “Scope of Work and Challenges” on page 32. 7 Converting the job control language.
2 Conversion Phases • Initial Trial Conversion Regression Testing and Repeated Trial Conversions Implementation Phases • Actual Conversion and Switchover • Initial OS/390 Operations • 3 This chapter will address these phases along with the key tasks to be completed in those phases. This chapter has been sectioned as follows: 32.1, “Conversion Process Introduction” on page 482 32.2, “Mass Conversion - Background, Benefits and Method” on page 486 32.3, “Mass Conversion Phase Overview” on page 493 32.
32.1.2 Prerequisites There are two key requirements that need to be satisfied before embarking on a migration: 1. The source code must be available for your applications. If the source code does not exist then it must be rebuilt. 2. A method to transfer the source code to the OS/390 system. 32.1.3 Recommendations The following are recommendations that either apply to all phases of your migration or are not specific to any phase. 32.1.3.
32.1.3.5 Migrate the SNA Network Early If the migration plan includes converting an SNA communications network, then consider migrating ownership of the network from VSE to OS/390 within the two months that precede operating system switchover. At this time, switchover minus two months, the OS/390 system should be positioned for and nearly production ready. Assuming there is connectivity between the systems, the testing phase path has been from VSE to OS/390.
32.1.3.7 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 cost analysis (time, people resources and so on). The cost of a conversion is based on inventory. It also provides information about the effort that may be required to recreate source materials.
32.2.2 Mass Conversion Overview / Benefits Mass conversion is the major distinction of the CORTEX-MS process. It results in a single switchover of the entire VSE application portfolio to OS/390 over a weekend. 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. In the mass conversion, there is no overlap of VSE and OS/390 production.
32.2.2.1 Automated Conversion There are several ways to automate some or all of the conversion. The automation that Cortex-MS provides is unique in that it is a mass conversion. 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.
OS/390. Therefore, it is not required to freeze or follow up development, enhancement, or maintenance of applications during the conversion. 32.2.2.3 Mass Conversion (Switchover) The actual mass conversion, called the switchover, often takes place over a single weekend. Before switchover, the production workload runs under VSE. After switchover, the production workload runs under MVS. The switchover is the key advantage of using Cortex-MS as a conversion tool.
routines must allow users to custom adapt the tools to specific local conversion requirements. These requirements, not addressed by standard processing, are always identified. The conversion tools must be custom modified by positioning execution options, coding exit routines, and possibly developing some ad-hoc pre- or post-processors.
functional descriptions of batch applications (standards and system independent). EZ-PCL (Easy PCL) A PC/MS-Windows based graphic user interface (GUI) to the PDB, which enables definition or modification of batch applications in their flowchart representation. PREP (Preparation) An interactive system of preparation, submission, backout, and restart of OS/390 jobs. SWITCH (Switchover) Transfers VSE files to OS/390 and DFSMS using VSE and OS/390 file information stored in the PDB.
• Inventory Validation • Translate the Languages/Programs • Translate the JCL • File Transfer 32.2.5.1 Inventory Validation The Cortex tool cross references the run JCL, the procs, the FCBs and various includes. Then it cross references the source programs, copy books, macros, subroutines, PSBs, the CICS tables and maps for CICS; basically all the JCL elements. In CICS the CICS PPT and transaction programs and applications are cross referenced.
32.3 Mass Conversion Phase Overview Built on the principles of mass, automated, and repetitive conversion, a mass conversion project is organized in phases, as shown on Figure 58. The figure shows the specific phases and includes an approximate schedule with durations. Figure 58. Project Phases 32.
• Refer to Chapter 3, “Developing the Plan” on page 41 for information on project staffing, assignments and responsibilities. • Refer to Appendix C, “DFSMS Naming Conventions” on page 543 for information on data set naming conventions. • Refer to Appendix A of the MVS-MS Planning Guide for help developing the Migration Plan. • Refer to Appendix B of the MVS-MS Planning Guide for help developing the Conversion Plan.
• At project start • Before the start of online application tests • Before the start of batch application tests • Before switchover During those sessions, the Project Manager and perhaps, hired conversion specialists, provide the conversion team with instructions and guidelines for planning, organization, and implementation of the activities to come. 32.4.2 Phase 1: Application Inventory Before you start any work on a migration you need an inventory.
The key terms associated with determining your application inventory are: 1. 2. 3. 4. Determination Collection Supply Analysis and resolution of exceptions 32.4.2.1 Determination Determination is the task of understanding what runs in production on the VSE side. It includes finding out all the places where the production JCL is stored and determining what is production and what is not production. 32.4.2.
be performed on the VSE side and then sent to OS/390. The determination and collection procedures are developed once and then repeated. The supply is done once per month. Also unique to the Cortex MS environment is that the analysis and resolution work is on going throughout the project. The Cortex tool produces reports listing missing and unreferenced elements to assist with resolving exception conditions. Those exceptions are reviewed and addressed by VSE production support personnel.
names. This is because naming conventions can facilitate or impair the implementation of OS/390 system components (such as DFSMS) and other automated operations tools. It is recommended that you understand how a production item will be stored, used and managed under OS/390 before giving it a name.
and parameters), and library members for control cards. This is because many of the VSE names are syntactically incorrect under OS/390. But the conversion of in-house developed applications doesn′t require changing any of the names associated with the source code. In fact, it is recommended to leave the program, entry-point, copybook, code include and DD names unchanged to avoid confusing application support personnel.
References you can consult for additional information about the conversion specification phases include: • Refer to Appendix C, “DFSMS Naming Conventions” on page 543 for information on data set naming conventions that relate to an DFSMS environment. • Refer to Appendix A of the MVS-MS Planning Guide for help developing the Migration Plan. • Refer to Chapter 3 of the MVS-MS Planning Guide named ″Developing the Conversion Plan″. • Refer to specific product, program or utility migration guides.
32.4.4.2 Design the MVS Target Output All the material in this book, including the charts that show functional comparisons of products, is for aiding the analysis of the VSE system to help determine the target OS/390 system. It is during conversion team meetings that these items are presented, challenged and designed.
• tailoring and custom modifying the conversion tools through installation options and exit routines according to the conversion specifications • performing a pilot conversion of a subset of the conversion inventory after having custom modified the conversion tools • auditing the messages and OS/390 material (source code and JCL) produced by the pilot conversion • performing technical tests on a representative sample The Custom Modification phase is complete when the conversion process automatically
cannot be converted entirely automatically, and for which the unresolved conversion requirement cannot be addressed through VSE positioning. 32.
VSE 2.1 for the EXEC statement), or change the program′s logic to read and process a ″control record″ which would supply any variable information to the program. Additional programming changes and considerations can be found in their respective programming chapters and in the POWER-JES2 differences chapter. The Cortex Migration System can provide conversion assistance in many of the areas where VSE-OS/390 incompatibilities exist. 32.5.1.
work, cataloged temporary, handoff, backup, transmit, master sequential, master VSAM, and so on. File classification is a large JCL-related task done to define the life cycle of all of the data sets. This task does not have a high degree of difficulty but typically involves thousands of files. Each file must be classified and this can be very time consuming.
The first trial conversion starts with a complete fresh supply of the VSE conversion inventory. Every three to four weeks, the mass conversion starts from a fresh copy of the entire conversion inventory, in order to take into account the last VSE maintenance modifications. Between two supplies, additional mass conversions may be executed from the same supply, in whole or in part, in order to take advantage of the latest custom modification improvements.
• Simulated production (or acceptance) tests: in conjunction with batch production tests • Network and performance tests with actual connection to future end users OS/390 batch application tests include: • Unit (or technical) tests: on a representative sample of jobs • System (or Functional) tests are scenarios of chained job executions corresponding to application flows • Simulated Production/Parallel (or acceptance) tests: replicate one day of VSE operations in MVS Batch and online tests are coo
• Application personnel should be made responsible for providing test data, and for evaluating, and approving application test results. (Obtaining test data can be a problem - early plans should be made to define and obtain test data.). Involvement of applications to some degree in the test process can prove beneficial at OS/390 switchover and initial OS/390 production. • Operations personnel should do the operating during testing. This is a vital part of their training.
test phase will have its own test plan. The key application development people at the installation must be involved when the test team is assembled. Testing should not be something that just happens. Testing activities are an integral part of any migration plan and must be designed and controlled. When some plans are drafted, all too often, the word ″testing″ is all that appears on the task list or PERT chart.
• Migrating copies of VSE production files, needed for regression tests, to OS/390 • Migrating copies of VSE production databases, needed for regression tests, to OS/390 The conversion project team meets regularly to review the progress and status of the OS/390 tests. OS/390 tests typically take three to five months. The OS/390 test phase is complete when scheduled tests have been successfully performed. 32.5.4.
The large number of inactive and non-critical or obsolete tape files is not migrated. They are either eliminated, or the VSE volumes are set aside together with a last copy of the VSE tape file catalog at switchover time.
32.5.6.1 Online Unit Testing Prior to this task, an online test plan, and possibly detailed test scripts, have been developed with and presented to the test team, together with organizational instructions, during a pre-test orientation session. CICS testing is an ideal place to begin the testing process. At least in theory, CICS transactions are fairly transparent between OS/390 and VSE/ESA.
the beginning of staggered and overlapping testing. Online system testing may overlap batch unit testing. 32.5.7 System Testing In system testing the goal is to go through the online applications and verify that the outputs from each operating system are similar. In the systems test phase each application is tested in more detail and each application′s output is verified as being close to the production system.
the third job in the sequence is missing due to being treated as a temporary data set. The management of transition files is very different between VSE and OS/390. In OS/390 there are only a couple of possibilities. In VSE it depends on the type of organization, the products used and the traditions followed. These problems don′t show up until the applications are tested together. This is the right time for these to surface.
Job Simulation The goal is to get through as many days as possible. It is a comfort to know at switchover, that a week′s jobs can be processed. There are significantly fewer monthly jobs than weekly jobs. There are significantly fewer yearly jobs than monthly jobs. Plan the cutover to not occur at month end. The final phase of parallel testing is ensuring the output is the same from both systems, where actual production is compared to the test output.
32.6.1.1 Converting the Development Material This is the code that the systems programmers are working on. It is recommended that the conversion of these materials take place as early as possible. This conversion is not normally done at switchover time. It is not production material. This task generally coincides with the transfer of a significant number of application developers to the OS/390 platform. Development under CMS or VSE can continue to a point.
procedure in order to apply jobset maintenance concurrently with maintenance to VSE production. 32.6.2.2 Final Program Conversion There are two key tasks associated with the translation and compilation of all the VSE source materials for the final program conversion. First is the final mass translation with the objective to translate all of the source modules in their current state, overnight, automatically, and without errors. Second is the mass compilation for the final conversion.
32.6.3.2 Additional Switchover Tasks These tasks may also need to be addressed during switchover: • RJE workstation configurations • NJE end users must change their JCL for job submission • Configuration of PC workstations • Migrate the tape manager to MVS • Migrate the database manager to MVS • Migrate the Report Manager database to MVS • Secure on-site assistance from major vendors Preparing for switchover takes about a month. A detailed and timed switchover plan is developed.
Chapter 33. Conversion Services and Tools The actual process of converting JCL and programs from VSE to OS/390 can be a very tedious, time-consuming and labor intensive set of tasks. Fortunately, there are tools available from both IBM and non-IBM sources to help automate most, if not all, of the conversion process. The purpose of this chapter is to discuss some of the more popular conversion tools.
AMS is an IBM Business Partner • • Call 1-800-482-6267 or, Contact AMS through IBM 33.2 Conversion Tools 33.2.1 VSE/ESA Facilities VSE/ESA 2.3 added a new function useful for developing an inventory of a VSE/ESA system′s jobs, including the so-called hidden JCL found in standard label areas and in standard assignments. The VSE/ESA JCL Analyzer is included in ICCF library 59 as a sample source program that can be tailored to extend its functions.
• Program status • Program usage • File cross-referencing • Job cross-referencing 33.2.2.1 Product Highlights IBM OPTI-AUDIT for VSE Version 1.1.0: • Captures and builds an inventory of all programs running on your VSE system • Monitors the execution of batch jobs extracting job/program/file cross-referencing information • Provides a source scanning facility for COBOL • Produces a variety of reports for the year-2000 conversion 33.2.2.
• REPORT 1 - ACTIVE phases (lists all ′executed′ phases by library). • REPORT 2 - INACTIVE phases (lists all ′dormant or yet to be activated′ phases by library). • REPORT 3 - Y2KREADY phases (lists all phases flagged as Y2K ready by library). • REPORT 4 - DUPLICATE phases (lists all ′duplicate′ phases by library).
33.2.3.1 Product Positioning COBOL and CICS Command Level Conversion Aid for VSE Release 1 is positioned as a COBOL migration aid designed to provide: • Automated conversion of most COBOL syntax differences. • Programmer productivity for the migration process. • Reduction of manual conversion errors. • Flexibility through an open converter design. • Generation of conversion management reports.
Driver: This component reads the COBOL source program, extracts copy members from the input source file, and executes the conversion process according to the corresponding compiled LCPs. The driver produces four types of output: • New COBOL source code in new source library (optional). • New COBOL copy module in new copy library (optional). • COBOL source statement diagnostic listing. • Conversion management report data.
33.2.5 Computer Associates 33.2.5.1 CA-Convertor CA-Convertor is a comprehensive system to manage and implement the conversion from VSE to MVS operating systems. CA-Convertor converts VSE COBOL and Assembler language programs and VSE JCL to true MVS programs and JCL, while automatically creating applicable documentation. It performs the burdensome conversion tasks that, under manual control, would be error-prone, tedious and repetitious.
33.2.6.1 Recovery/SRC This is the basic service provided by SRC. The basic recovery utilizes a proprietary technology that generates the source code from the load module supplied by the client. Data names and labels within the programs recovered are generic. 33.2.6.2 Rename/SRC This is a service that is sold in addition to the basic recovery service (Recovery/SRC). The renaming service matches client-provided copybooks to the data definitions generated by the recovery technology.
Part 8. Migration Experience Copyright IBM Corp.
528 VSE to OS/390 Migration Workbook
Chapter 34. Customer Migration Example This chapter describes an actual user experience with migration. Since every customer environment is unique, care should be taken when drawing comparisons, especially in areas of resource and capacity. 34.1 Background Cust1 is a relatively fast growing company that evolved from a small 4341 to a 3-way 9672 in a little more than a decade. The I/S organization was constantly challenged to support new business with very little lead time.
34.3 Inventory • 1500 COBOL programs - mix of DOS/VS COBOL and COBOL II • 2600 RPG programs • 80 Assembler programs • 8000 JCL steps 34.4 Resources In this project it was sometimes hard to get the various groups to focus on the migration when needed. This was because of other priorities with day to day problems and projects. This is not all that uncommon, especially in a growing organization. This however, needs to be monitored closely or delays in the project will result.
34.5 Duration Due to the data sharing requirements, the availability requirements, and, in general, the dynamic environment of the business, it was decided the mass conversion method was the way to migrate to MVS. In the past years of rapid growth not much time was spent defining and enforcing systems management disciplines which resulted in uncertainty of what source code, phases, JCL and so on, were production and which were obsolete or test.
about the same after switchover, with MVS showing a couple of percentage points higher. Since the workload at this installation is not the typical online on prime shift and batch on second and third, it was not as easy to make comparisons on a batch window length. Overall it appeared that throughput was much better. There were other performance benefits realized.
Part 9. Appendixes Copyright IBM Corp.
534 VSE to OS/390 Migration Workbook
Appendix A. Education Information The task of providing the right training, to the right people, at the right time, at the right location is a small project of its own. There are many variables to consider, including costs, not the smallest of which is simply determining if a particular course is available. A good training plan will be the right balance of these elements based on the needs of the installation.
It is recommended that a class on TSO and ISPF, to help navigate through panels, be taken prior to the MVS Installation and SMPE class. The IBM SMPE class is a good and necessary prerequisite to the MVS install class. SMPE is similar to VSE MSHP. It provides key information on installing products and applying PTFs and is good for VSE systems programmers. The focus of the MVS Installation class is for MVS customers installing a new version of MVS. There may be additional considerations for first time users.
A.3 Who will Provide the Training? Hiring a skilled MVS person for the migration, whether temporary or permanent, helps with the skill level of that one person. Don′t assume that the person is a skilled educator or will have time to teach a curriculum to other team members in his/her spare time. It is likely that this person will have a list of responsibilities that may not include being a trainer and may not know VSE at all.
538 VSE to OS/390 Migration Workbook
Appendix B. Mapping ISV Products and Functions This is a frequent topic of discussion with customers considering migrating. How a customer′s ISV products map to those contained in base OS/390 is always discussed. It is a common migration task to ensure there is equality. This equivalent function mapping will grow in importance as coexistence is established. It is also a way customers can reduce their ISV SW stack charges.
Table 46 (Page 2 of 3).
Table 46 (Page 3 of 3).
542 VSE to OS/390 Migration Workbook
Appendix C. DFSMS Naming Conventions This chapter was written by John Tyrrell of IBM′s Storage Systems Division. John is one of the original senior architects of DFSMS. He also invented TMM (Tape Management Methodology) and is the author of the Volume Mount Analyzer program which is part of DFSMSdfp. He is the senior architect/inventor of the DFSMS Optimizer product, one of the major components of DFSMS.
There are two basic pieces of information that one should be able to obtain from the data set name: 1. Who owns it? 2. What is it? The following section will highlight all of the basic components that could potentially be used in a data set naming standard. C.2 Components of a Data Set Name Not all of the following levels of qualification are necessary for naming data sets.
individuals keep a standard LOGON ID, and change the set of filters instead of the IDs. As an example of this set of conventions, consider a common problem of constantly shifting workloads. If the Storage Administrator was always faced with getting the data for a given application and moving it to another system, then it would make good sense to have a naming convention for the HLQ that would allow him to easily accomplish this via filtering techniques.
− − − − E3380D E3380S E3990M3 E3990M2 The above example would allow various filtering techniques the flexibility of recognizing different sets of data easily. Some examples of this follow: • HLQ = E* -- All of the Engineering Data • HLQ = E3090* -- All of the 3090 CPU Family of Designs • HLQ = E3380* -- All of the 3380 DASD Family of Designs C.2.
readable, such as, a file called MASTER.PAYROLL.WEEKLY. This might be just too tempting to your average system hacker. A better choice might be MR.PY.WK. C.2.4 User Name This qualifier should allow the end creator to assign their own unique name to identify the particular set of a certain type of data; for example, with a master circuit file, there would be a distinction between MYPART and YOURPART, or MYPART1 versus MYPART2.
C.3.2 Application Location If this application ever got moved to another site, then all of the data sets would have to be renamed. In some cases, it could be important to name the data by a location name, for example, CHICAGO. This could be perfectly acceptable in certain cases. Suppose there were two telephone directory files, ″TELPHDIR.CHICAGO″ and ″TELPHDIR.PODUNK″. This would be okay. That′ s because it is very unlikely that either Chicago or Podunk would ever move.
C.3.6 Access Method At one point in time, many installations adopted a policy of distinguishing VSAM data from non-VSAM data. The reality behind this standard was that there were many functions that were not supported for VSAM and this was an easy way to recognize that data. The main reason for this distinction was because of old VSAM catalogs and the ″ownership″ of the volume and data by VSAM. In order to avoid these problems, you had to separate the VSAM data from the non-VSAM data by catalog.
usability of the system and the need to manage it differently based on what set of data this actually is. C.4.2 VSAM Data Set Naming Conventions Many companies have decided that it is a good idea to associate all of the VSAM components with the base cluster by some recognition pattern. Some of the reasons behind this have to do with billing, and also with the usability of doing catalog locates and so on, to find all of the associated components easily with available software technology.
within the data set name so that ACS Routines can easily ascertain one piece of data from another. The only alternative to this is to place a very restrictive convention on the qualifiers that can be specified. For example, you could break down the table space name by having positional characters represent different levels of qualification for the data.
552 VSE to OS/390 Migration Workbook
Appendix D. Special Notices This publication is intended to help customers and IBM technical personnel to migrate from VSE to OS/390. The information in this publication is not intended as the specification of any programming interfaces that are provided by VSE or OS/390. See the PUBLICATIONS section of the IBM Programming Announcement for VSE/ESA and OS/390 for more information about what publications are considered to be product documentation.
including these reference numbers is to alert IBM customers to specific information relative to the implementation of the PTF when it becomes available to each customer according to the normal IBM PTF distribution process.
SupportPac System/370 SystemPac SystemView VisualAge VM/ESA VSE/ESA System/360 System/390 Systems Application Architecture Virtual Machine/Enterprise Systems Architecture VisualLift VM/XA VTAM The following terms are trademarks of other companies: 1-2-3 is a trademark of Lotus Development Corporation ADE is a trademark of Loral/Rolm Mil-Spec ATM is a trademark of Adobe Systems, Incorporated C-bus is a trademark of Corollary, Inc.
OMEGAMON is a trademark of Candle Corporation ONC is a trademark of Sun Microsystems, Incorporated Open Software Foundation is a trademark of The Open Software Foundation, Incorporated Oracle is a trademark of Oracle Corporation OSF is a trademark of Open Software Foundation, Incorporated PC Direct is a trademark of Ziff Communications Company and is used by IBM Corporation under license. Pentium, MMX, ProShare, LANDesk, and ActionMedia are trademarks or registered trademarks of Intel Corporation in the U.
Appendix E. Related Publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook. E.1 International Technical Support Organization Publications For information on ordering these ITSO publications see “How to Get ITSO Redbooks” on page 561. E.1.
E.2.
E.3 Other Publications Book Title Publication Number RACF General Information Getting Started with DFSORT Get DFSMS FIT: Fast Implementation Techniques DFSMS FIT: Fast Implementation Techniques Process Guide DFSMS FIT: Fast Implementation Techniques Installation Examples GC23-3723 SC26-4109 SG24-2568 SG24-4478 SG24-2569 E.4 Other Sources E.4.1 Books on the Internet There are several IBM world-wide web sites available with more information: E.4.1.1 Redbooks See http://www.redbooks.ibm.com/ .
560 VSE to OS/390 Migration Workbook
How to Get ITSO Redbooks This section explains how both customers and IBM employees can find out about ITSO redbooks, CD-ROMs, workshops, and residencies. A form for ordering books and CD-ROMs is also provided. This information was current at the time of publication, but is continually subject to change. The latest information may be found at http://www.redbooks.ibm.com/.
How Customers Can Get ITSO Redbooks Customers may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and information about redbooks, workshops, and residencies in the following ways: • Online Orders — send orders to: In United States: I n Canada: Outside North America: • • United States (toll free) Canada (toll free) 1-800-879-2755 1-800-IBM-4YOU Outside North America (+45) 4810-1320 - Danish (+45) 4810-1420 - Dutch (+45) 4810-1540 - English (+45) 4810-1670 - Finnish (+45) 4810-1220
IBM Redbook Order Form Please send me the following: Title First name Order Number Quantity Last name Company Address City Postal code Telephone number Telefax number • Invoice to customer number • Credit card number Credit card expiration date Card issued to Country VAT number Signature We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not available in all countries. Signature mandatory for credit card payment.
564 VSE to OS/390 Migration Workbook
Glossary Numerics 2-digit-year format. A format that provides a year date as two digits only to represent a year within a specific century. The two high-order digits of the year are truncated; for example 1995 is represented as 95. 4-digit-year format. A format that provides a year date as four digits: the two high-order digits represent the century and the two low-order digits represent the year within the century. For example, 1995 represents the year 1995; 2095 represents the year 2095. 20th century.
MO:DCA-P is the strategic AFP interchange data stream, and IPDS is the strategic AFP printer data stream. alphabetic character. Any one of the letters A through Z (uppercase and lowercase). Some licensed programs include as alphabet characters the special characters #, $, and @. alphanumeric. Pertaining to data that consist of letters, digits, and usually other characters, such as punctuation marks. alternate COPY.
B background partition. In VSE, a space of virtual storage in which programs are executed under control of the system. By default, the partition has a processing priority lower than any of the existing foreground partitions. backout. See file and catalog backout. backup copy. A copy of information or data that is kept in case the original is changed or destroyed. base cluster. In systems with VSAM, a key-sequenced or entry-sequenced file over which one or more alternate indexes are built.
CCYY format. A 4-digit-year format that uses two century digits (CC) to indicate the century and two year digits (YY) to indicate the year within the century. The CC representation is provided as either the actual century digits (for example, 18, 19, or 20) or as an encoded value (for example, as 00 to represent 19, 01 to represent 20 as in, 0095 represents the year 1995 and 0195 represents the year 2095.) century.
CP command. In VM, a command by which a terminal user controls his virtual machine. The VM/370 control program commands are called CP commands. The CP commands that perform console simulation are called console functions. Data Language One (DL/I). 1. In IMS/VS, the data manipulation language that provides a common high-level interface between a user application and IMS/VS. 2. A data base access language used under VSE and CICS/VS. cross-domain resource. (1) Deprecated term for other-domain resource.
Device Support Facilities (DSF). An IBM-supplied system control program for performing operations on disk volumes so that they can be accessed by IBM and user programs. Note: Examples of these operations are initializing a disk volume and assigning an alternate track. device-independent. Pertaining to a program that can be executed successfully without regard for the characteristics of particular types of devices. Contrast with device-dependent. DFSMS environment.
features to permit a computing system to execute programs written for another system. F emulator. A combination of programming techniques and special machine features that permits a computing system to execute programs written for a different system. See also integrated emulator, terminal emulator. file. entry-sequenced data set. In OS/390 programs with VSAM, a data set whose records are loaded without respect to their contents, and whose relative byte addresses cannot change.
GRS. global resource serialization. A component of MVS/ESA SP used for sharing system resources and for converting DASD reserve volumes to data set enqueues. Guest Operating System (GOS). A second operating system that runs on the primary operating system. An example the second operating system is VSE and/or OS/390 and/or TPF etc. running on VM/ESA. In this example VSE, OS/390, TPF, etc. are referred to as a second level system or a VSE guest, OS/390 guest, TPF guest and so on. Guest Support.
purpose of modifying or extending the functions of the IBM software product. integer date. A count of days since a specified date. Various IBM software products have defined integer dates as follows: Language/Product Days Since C 1969-Dec-31 COBOL 1600-Dec-31 Language Environment 1582-Oct-14 MVS/CICS/DB2 1899-Dec-31 integrity. The protection of systems, programs, and data from inadvertent or malicious destruction or alteration. See application integrity, data integrity, system integrity.
Job Entry Subsystem. An MVS subsystem that receives jobs into the system, converts them to internal format, selects them for execution, processes their output, and purges them from the system. In an installation with more than one processor, each JES2 processor independently controls its job input, scheduling, and output processing. job step. You enter a program into the operating system as a job step.
link-edit. To create a loadable computer program by means of a linkage editor. load module. An application or routine in a form suitable for execution. The application or routine has been compiled and link-edited; that is, address constants have been resolved. load module library. A partitioned data set used to store and retrieve load modules. See also object module library, source module library. local area network (LAN).
multivolume file. A file contained on more than one storage medium. N NetView DM. IBM NetView Distribution Manager. network definition. In VTAM, the process of defining the identities and characteristics of each node in the network and the arrangement of the nodes in that system. network management. The process of planning, organizing, and controlling a communications-oriented system. network resource.
routines. They can run on different computers with little or no modification. PDS. partitioned data set. A data set in direct access storage that is divided into partitions, called members, each of which can contain a program, part of a program, or data. Contrast with sequential data set. PDSE. partitioned data set extended. A system-managed data set that contains an indexed directory and members that are similar to the directory and members of partitioned data sets.
Q qualified name. (1) A data name explicitly accompanied by a specification of the class to which it belongs in a specified classification system. (2) A name that has been made unique by the addition of one or more qualifiers. R RACF. Resource Access Control Facility.
sequential data set. A data set whose records are organized on the basis of their successive physical positions, such as on magnetic tape. Contrast with direct data set. sequential file. A file in which records are processed in the order in which they are entered and stored in the file. Contrast with direct file, indexed file. sequential processing. (1) The processing of logical records in the order in which they are accessed. (2) The processing of records in the order in which they exist in a file.
Storage Management Subsystem (SMS). A component of MVS/DFP that is used to automate and centralize the management of storage by providing the storage administrator with control over data class, storage class, management class, storage group, and ACS routine definitions. structured programming. A method for constructing programs using only hierarchically nested constructs each having a single entry and a single exit point.
T task. (1) In a multiprogramming or multiprocessing environment, one or more sequences of instructions treated by a control program as an element of work to be accomplished by a computer. (2) In VSE, the basic unit of synchronous program execution. A task competes with other tasks for computer system resources such as processing time and I/O channels. Telnet. In TCP/IP, an application protocol that allows a user at one site to access a remote system as if the user′s display station were locally attached.
V VSAM managed space. A user-defined space on disk that is under the control of VSAM. verification test. A test of a system to prove that it meets all its specified requirements at a particular stage of its development. VSE (Virtual Storage Extended). Any of the VSE operating systems and environments. virtual address. The address of a location in virtual storage. A virtual address must be translated into a real address in order to process the data in processor storage. W virtual address space.
List of Abbreviations ABEND ABnormal END BCS Basic Catalog Structure ACB Access Control Block BDAM Basic Direct Access Method ACF/NCP Advanced Communications Facility/Network Control Program BDT Batch Data Interface BG BackGround BISAM Basic index Sequential Access Method BLL Base Locator for Linkage BLP Bypass Label Processing ACF/SSP Advanced Communications Facility/??? ACIF AFP Conversion and Indexing Facility ACS Automatic Class Selection BOS Basic Operating System ADSTAR AD
CGI Common Gateway Interface DBCS Double Byte Character Set CHKPT CHecKPoinT DBD Data Base Directory CI Control Interval DBRC Data Base Recovery Control CICS Customer Information Control System DBSU Data Base Services Utility DC Data Communication DCB Data Control Block DCE Distributed Computing Environment DCF Document Composition Facility DCT Destination Control Table DD Data Definition, Data Dictionary DDL Data Definition Language CICS/DOS/VS CICS/VS Customer Information C
DSCB Data Set Control Block FILESEC FILE SECurity DSECT Dummy Control SECTion FIPS DSN Data Set Name Federal Information Processing Standard DSNAME Data Set NAME FIT Fast Implementation Techniques DSNX Distributed Systems Node eXecutive FM File Mode DSS Data Set Services FORMDEF FORMat DEFinition DTF Define The File FORTRAN FORmula TRANslation DTL Define The Lock FSA Functional Subsystem Application EBCDIC Extended Binary Coded Decimal Interchange Code FSF Forward Space File
HPR High Performance Routing IPDS Intelligent Printer Data Stream HSM Hierarchical Storage Manager HTML HyperText Markup Language IPF Interactive Productivity Facility HTTP HyperText Transfer Protocol I/O Input/Output IPL Initial Program Load I/S Information Systems ISA Initial Storage Area I/T Information Technology ISAM Indexed Sequential Access Method IBM International Business Machines ISC Integrated Storage Control ICA Integrated Communications Adapter ISMA Information Sy
LPAR Logically PARtitioned mode OCO Object Code Only LRECL Logical RECord Length OE Order Entry LRU Least Recently Used, Line Replaceable Unit OEM Original Equipment Manufacturer LSPR Large Systems Performance Reference OGL Overlay Generation Language OLPD LSR Local Shared Resources On-Line Problem Determination LTM Local Transport Mechanism ONC Open Network Computing LU Logical Unit OPC LUP Logical User Profile Operations, Planning & Control MAPS SNA Network Interconnecting P
PPFA Page Printer Formatting Aid RPM Remote Print Manager PPT Processing Program Table RRDS Relative Record Data Set PR/SM Processor Resource/Systems Manager RSCS Remote Spooling Communications Subsystem PROC PROCedure RSU PROP PRogrammable OPerator Recommended Service Upgrade PS Personal System RTE Remote Terminal Emulator PSB Program Specification Block RU Replaceable Unit PSF Print Service Facility S/360 System/360 PSF/6000 Print Service Facility/6000 S/390 System/390 SA
SPG Service Planning Guide TPF SPI System Programming Interface Transaction Processing Facility TRS Time Recording System TSO Time Sharing Option TSO/E Time Sharing Option Extensions TSO/VTAM Time Sharing Option/Virtual Telecommunications Access Method SPIE Specify Program Interruption Exit SPOOL Simultaneous Peripheral Operation On-Line SPUFI SQL Processor Using File Input SQL Structured Query Language UACC User ACCess SQL/DS Structured Query Language/Data System UCB Universal Ch
VTAM Virtual Telecommunications Access Method WTOR Write To Operator with Reply VTOC Volume Table of Contents WWW World Wide Web VVDS VSAM Volume Data Set XCF Cross-system Coupling Facility VVR VSAM Volume Record XCTL Transfer ConTroL WS Work Station XEDIT eXtended EDITor WSC Washington Systems Center XMT Transmit WTM Write Tape Mark XRF eXtended Recovery Facility WTO Write To Operator 590 VSE to OS/390 Migration Workbook
Index Special Characters * $$ DATA 89 * $$ LST 89 &SYSNAME 115 %INCLUDE 335 Numerics 2-digit-year format definition 20th century definition 565 21st century definition 565 24x7 installations 485 4-digit-year format definition 565 565 A abbreviations 583 ABEND forcing 344 ABEND macro 280 abnormal termination exits 364, 365, 367 ACB additional MVS VSAM parameters 290 macro 290 multiple string processing 128 MVS VSAM parameters 290 single Open 128 access method 97, 549 differences 97 IDCAMS 455 implementat
APSRMARK (MVS) 240 APTRMARK (VSE) 240 APTZPARM macro 241 ASCII subsystem 188 Assembler CALLDLI 173 conversion comments 267 conversion tools 492 general conversion comments 267 initiation 269 migrating applications 359 migration 359 products 267 programming interfaces 241 TCP/IP applications using sockets API termination 269 user exits 364 VSAM support 131 Assembler macros ABEND 280 ACB 290 ATTACH 283 CANCEL 281 CCB 327 CDLOAD 278 CHECK 307 CHKPT 282 CLOSE 298, 305, 314 CNTRL 296, 298, 306, 314 COMRG 277 DEQ
Assembler Products (continued) data management macros (continued) multiple search / feedback 325 NOTE macro 299, 309 OPEN macro 297, 304 overview of programming elements 327 PIOCS 327 POINTS macro 300, 308 POINTW / POINTR macros 299, 308 processing a DAM File under MVS 324 processing a DAM File under VSE 324 PRTOV macro 296 READ macro 307, 313 record addressing 315 record addressing by ID 315 record addressing by KEY 316 record reference by ID 316 record reference by KEY 317 reference methods 316 RELSE macr
batch (continued) TCP/IP 195 unit testing 512 BCP customization 415 B D A M 98 benefits customer migration 532 bibliographies COBOL 251 diagnostic reference 478 Language Environment 353 MQSeries 206 PSF/MVS 244 PSF/VSE 244 REXX 372 bibliography 557 BLKSIZE definition 293 BLL cells 252 book synopsis 3 broadcast data set 157 BSC remotes definition 228 BTAM 137, 193 product installation 193 usage 193 building the initial OS/390 test system 430 maintenance environment 431 test logical partition 431 user librari
CICS (continued) MRO 136 MVS management modules 142 PL/I 346 problem determination considerations 153 programs 252 run-time options 366 shutdown statistics 137 system control blocks 138 data sets requirements 145 initialization parameters 140 program interface 147 programming commands 147 testing considerations 153 transaction attributes 144 backout 347 security 149 se rve r 133 translator option 252 unsupported products 136 UPSI 149 user exits & abnormal termination exits 367 vendor applications 154 virtua
comparing (continued) PSF commands 242 VSE & MVS JCL 86, 91 compatibility 344, 346 compiler option considerations for VS COBOL II 261 compiler options 260, 335 compiler options unavailable with COBOL for OS/390 and VM 260 compiling converted COBOL programs 265 complexity of implementation 51 component terminology for MVS 21 COMPRESS 121 Computer Associates 525 COMREG (DATE and UPSI) 81 COMRG 277 conceptual differences between LE/VSE & OS/390 Language Environment 352 COND parameter 85 conditional JCL 73, 84
conversion phases (continued) unit testing (continued) timing between on-line & batch testing 512 conversion process assumptions 486 introduction 482 prerequisites 484 recommendations 24x7 installations 485 manuals 484 migrate SNA network 485 project management 484 secure OS/390 skills 484 tools & automation 484 two phase approach 486 references 483 conversion services Automated Migration Services (AMS) 519 IBM global services 519 conversion tools 30 Computer Associates CA-Convertor 525 CA-DUO 525 CORTEX-MS
data access 182 driven output segmentation 75 entry 76 integrity 125 management macros 292 management standards 407 manipulation 159 replication 182 sharing 125 TCP/IP related 195 transfer and NJE 405 Data Base Descriptor (DBD) 170 Data Control Block (DCB) 98 DATA DIVISION - FILE DESCRIPTION (FD) 256 data set CICS system requirements 145 editing 438 generation 551 intra-region name sharing 128 level 547 MQSeries 202 names 81, 116 naming considerations 99 naming guidelines 543 naming standards 408 NOALLOCATI
device (continued) control 448 information 329 migration 36 status display 448 supported by OS/390 402 DFDSS 23 DFHMSCAN utility 152 DFHSM 23 DFSDSdss 101 DFSMS FIT 102 DFSMS implementation 102 DFSMS naming conventions 543 DFSMS/MVS diagnosis 476 DFSMSdfp analyzing catalogs for errors and synchronization 476 catalog recovery 476 checking VSAM KSDS for structural errors DFSMSdss 478 DFSMShsm 477 DFSMSrmm 478 DFSMSdfp 101, 387, 476 DFSMSdss 387, 397, 456, 478 DFSMSdss - OS/390 functions 398 DFSMShsm 101, 387,
DOS/VS COBOL (continued) REPORT WRITER statements 253 reserved word considerations 263 DOS/VS COBOL & COBOL for OS/390 and VM language differences Common COBOL Coding Problems 253 DATA DIVISION - FILE DESCRIPTION (FD) 256 ENVIRONMENT DIVISION 255 file handling considerations file attribute mismatches 258 file status codes 257 ISAM 258 PROCEDURE DIVISION - Input/Output program termination 257 DRDA considerations 182 DSCB 108 DSNAME sharing 128 DTFCD operands 294 DTFCN 304 DTFDA operands 311 DTFDI operands 30
functional reasons for migrating to OS/390 (continued) connectivity 11 staff availability 12 systems availability 11 systems management 10 functional RJE differences 219 EXLST macro 291 expanded JCL 76 expiration date 548 extended MCS consoles 445 extended precision 334 extent exit 330 EXTENT statement 83 external side definition 571 G GDG naming standards 408 general Assembler considerations 311 comments on Language Environment compatibility 135 system considerations for CICS 136 generation data groups 4
HLL programming interfaces host operations 452 242 I I/O error checking 294 IBM COBOL & CICS CCCA 522 COBOL compilers - comparison 250 Global Services 519 OPTI-AUDIT for VSE 520 ICCF 155 /CMS/TSO 218 & TSO 155 command procedures 163 library conversion 163 LOGON procedures 157 macros 167 procedures 167 program execution 161 security 157 users′ orientation 437 ICETOOL 380 ICFCATALOG 112 ICKDSF 23 ICVR 142 IDCAMS 455 IEBCOPY 455 IEBGENER 455 IEBxxx or IEHxxx 455 IEFBR14 78 IF statement 84 IF THEN ELSE ENDIF
introducing PSF/MVS (continued) functional comparison (continued) PSF/MVS exclusives 235 migration effort 235 introduction to console operation 443 to DL/I and IMS/VS 169 to sizing 13 to test environments 419 to VSAM differences 110 introductory documentation 39 inventory validation 492 IOREG 293 IPCS analyzing dumps 473 analyzing traces 474 traces 474 using IPCS 474 ISAM 52, 97, 258, 326 ISASIZE 337 ISMF 22 ISPF 22, 161, 390 creating applications 440 executing applications 440 orienting ICCF 437 o v e r v
JCL differences (VSE and MVS) (continued) VSE Job Control statements ASSGN statement 83 C A T = o n D L B L 83 conditional JCL 84 DLBL and EXTENT 83 EXEC statement 82 JOB statement 82 MTC statement 83 RESET statement 83 TLBL statement 82 JCL high level similarities JCL statement & job layout conditional JCL 73 continuation cards 72 EXEC (job step) 72 file definitions 72 imbedded JCL 72 instream data 73 JOB statement (job) 72 nesting procedures 72 return codes 73 variables 73 spooling internal reader 73 JECL
JES2/POWER functional comparison (continued) output service (continued) printers supported 216 separator page differences 217 tape spooling 216 UCS naming conventions 218 RAS characteristics remote job entry functional RJE differences 219 remote workstation definitions 219 RJE exits 220 RJE operations 220 JES3 21, 151 job 70 accounting 223 execution serialization 214 information services 222 input 73 layout 72 log JES2 395 name 275, 549 roles & normal activities 26 schedulers 50 scheduling 213 scheduling fu
loading a DAM File (Fixed-Length Records without keys) 323 loading a DAM File (Undefined or Variable-Length Records) 323 LOCK & UNLOCK macros 281 log manager 145 logical library structure 389 logical partitioning 422 LOGON procedures 157 LOGREC 475 LPAR systems 421 LTM subparameter 105 M macro level programs 137, 148 Macro Resource Definition Table changes 140 macros call 272 data management 292 Define The File (DFT) 98 ICCF 167 linkage 271 multitasking 283 system 268 virtual storage 289 VSAM 290 main prog
migrating from LE/VSE-conforming languages 353 C for VSE/ESA 353 COBOL for VSE/ESA 354 PL/I for VSE/ESA 354 migrating from non-LE/VSE run-time environments 354 C/370 355 DOS PL/I 356 DOS/VS COBOL 356 migrating Assembler applications 359 migrating interlanguage communications applications 358 options mapping 354 VS COBOL II 355 VS FORTRAN 358 migrating from VSE/ICCF to MVS and TSO/E 163 converting ICCF libraries 163 ICCF procedures and macros 167 migrating TCP/IP 193 bibliography 197 network definitions 194
MVS (continued) device addresses 80 DFP 21 DISPLAY command 447 execution overrides 149 exits 415 IEFBR14 78 initialization routine 269 JCL - a summary 88 JCL - sample 93 JCL versus VSE JCL 73 JES2 additional job scheduling functions Job Control statements 84 linkage macros 271 Migration System 486 multitasking macros 283 naming standards 408 overlay 345 RACF 149 register conventions 269 specific options 344 storage management 345 system requirements 170 tools testing 508 virtual storage considerations 135 v
OPTI-AUDIT highlights 521 OPTI-AUDIT product details 521 option setting recommendations 363 optional features for release 4 416 options mapping 354 specific to DOS 343 specific to DOS compiler 335 specific to MVS 344 specific to MVS compiler 336 order and install the OS/390 software 405 ordinal day of year definition 576 orientation for utilities DFSMSdss 456 IDCAMS 455 IEBCOPY 455 IEBGENER 455 IEBxxx or IEHxxx 455 orienting ICCF users to TSO/ISPF 437 OS/390 automated operations tools 510 base elements 19 b
OS/390 documentation resources introduction references 39 key documents & other references 40 Web URL 40 OS/390 hardcopy processing 393 OS/390 software - order and install entitled methods of installing OS/390 CBPDO 407 ServerPac 406 fee-based installation methods 405 installing OS/390 fee-based 405 other offerings 406 SoftwareXcel Installation Express (SIE) SoftwareXcel SystemPac/MVS 406 OS/VS COBOL 131 other components - tailoring 416 differences 243 differences POWER-JES2 209 hardware requirements 403 mo
PL/I (continued) storage management 345 subprograms 331 VSAM support 131 PL/I and CICS 346 calling DUMP 346 CICS transaction backout 347 compatibility 346 execution options 346 file support 346 return from ON-units 347 statements not supported 346 transaction ABEND codes 346 PL/I calling SORT interfaces offered 340 parameters to be passed DDNAME PREFIXES 341 E15 EXIT PROCEDURE 341 EXIT E35 341 RECORD 341 RETURN CODE 341 SORT FIELDS 341 SORT MESSAGES 341 SORT TECHNIQUES 342 STORAGE 341 PL/I compiler options
POWER/JES2 detailed comparisons (continued) POWER/JES2 command equivalences control commands 233 file control 234 network management 233 NJE operator commands 233 queue management commands 232 sending commands & messages 234 task management commands 232 preparation phases 493 OS/390 standards & naming conventions 497 Phase 0: project management & technical leadership project planning & orientation 494 Phase 1: application inventory analysis & resolution of exceptions 496 collection 496 determination 496 sup
project (continued) plan s u m m a r y 56 planning 37 planning & orientation 494 schedule 54 staffing 43 tasks 47 PRTOV macro 296 PSB 171 PSETUP 208, 217 PSF command comparison 242 migrating resources 240 printer definitions 237 remote-resident resources 240 starting and stopping 242 startup procedures 237 supplied utilities 244 PSF/MVS accounting 244 differences 243 exclusives 235 installation 236 installation exits 243 introduction 235 performance 243 publications 244 PSF/MVS operational differences comma
resources (continued) operation 187 remote-resident 240 RESTART with CHKP 173 retrieving output 441 RETURN CODE 341 return codes 73 return codes in PL/I 344 return code values 344 setting return codes 344 RETURN macro 273 reusable data sets 123 Rewind option 173 REXX 163, 242, 369 and SAA 372 and TSO/E 369 and VSE/ESA 369 bibliography 372 CMS sample 371 environments 370 Exec samples 371 migration issues 371 OS/2 sample 371 TSO sample 371 TSO/E 371 VM/ESA 370 VSE/ESA 370 risk management 51 risky VSE coding p
setting up AFP resources (continued) migrating print applications (continued) OS/390 dynamic allocation & output descriptor macros 242 PL/I 242 printing from TSO 241 REXX 242 VSE printer PARM macro 241 migrating resources from VSE to OS/390 defining resources 240 migration without the source 240 remote-resident resources 240 transferring print streams 241 setup JES2 resources 209 shared application code 50 DASD 404, 425 DASD between OS/390 test systems 432 DASD between VSE and OS/390 (vs.
stand-alone systems 421 standard applications 195 standard labels 78, 103 standard user labels 105 standardized conversion deliverables 51 standards 407 standards, procedures, documentation documentation hardcopy library 412 printing softcopy books 412 redbooks 412 softcopy library 412 installation standards DASD and tape volume serials 408 data management standards 407 data sets 408 generation data groups 408 JCL standards 409 MVS naming standards 408 other MVS names 409 related redbooks 408 systems manage
systems management (continued) s u m m a r y 472 Systems Management Recording printing SMF records 395 T tailoring JES2 211 tailoring other components 416 tape differences 103 drives 404 file definition 297 labels 330 similarities 103 spooling 208, 216 storage considerations 97 tape similarities & differences bypass label processing facility in OS/390 106 no labels 105 nonstandard labels 106 standard labels standard user labels 105 volume interchangeability 103 task management commands 232 task quantity 9
U V UCS naming conventions 218 understanding device allocation 448 understanding operational differences 242 understanding the operator interfaces controlling consoles 444 extended MCS consoles using SDSF for system operation 446 using the TSO/E functions 445 managing display consoles console modes 444 display areas 445 PFKeys 445 understanding message formats and Replies unit address 80 unit testing 511 unlabeled tapes 105 UNLOAD 339 unloading database 176 unsupported linkages 338 P/I options in MVS 339
VSAM (continued) managed SAM files 122 managed space 15 moving catalog to different DASD type 119 MVS VSAM CHECK macro 292 NOALLOCATION data sets 123 OS/390 Backup/Restore 387 catalog management 114 cross-region SHR(4) 127 cross-system shareoptions 129 master catalog 114 user catalogs 115 VSE catalog compatibility 117 programming language support 131 reason code compatibility 292 record sizes 122 relocating catalog 119 REPRO function 119 SHAREOPTIONS 125 TCLOSE 292 VSE Backup/Restore 387 VSE TCLOSE macro 29
VSE (continued) virtual storage macros 289 VSAM backup/restore 387 VTAM 188 VSE & MVS JCL comparison 91 sample MVS JCL 93 sample VSE JCL 92 sample VSE plus carry-over 94 VSE/ESA conversion facilities 520 VSE/ESA environment 370 VSE/ESA′s JCL philosophy 70 VSE/Fast Copy 397 VSE/Fast Copy online 397 VSE/ICCF to MVS 163 VSE/ICCF to TSO/E 163 VSE/ICCF vs.
ITSO Redbook Evaluation VSE to OS/390 Migration Workbook SG24-2043-00 Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this questionnaire and return it using one of the following methods: • • • Use the online evaluation form found at http://www.redbooks.ibm.com Fax this form to: USA International Access Code 914 432 8264 Send your comments in an Internet note to redbook@us.ibm.
SG24-2043-00 IBML SG24-2043-00 Printed in the U.S.A.
/XRL/1 Artwork Definitions id File WOLOGO 2043SU WOLOGOS 2043SU TILOGO 2043SU TILOGOS 2043SU Page References i i i i Table Definitions id File COBCMP 2043VARS HDR1 2043VARS LPUBS1R 2043VARS LPUBS1H 2043VARS MAINTB 2043VARS MVSFB 2043VARS MVSFBK 2043VARS ONE 2043VARS PLNBOD1 2043VARS Page i References i, i, i, i, i, 250 i i i, 353 i 353 i i i i PLNBOD2 2043VARS PLNHDR 2043VARS PUBS1R 2043VARS PUBS1H 2043VARS ROW1 2043VARS ROW2 2043VARS ROW3 2043VARS ROW
/XRL/2 R2 REDB$EVA R1 REDB$EVA 621 621 621 621, 621 Figures id File VAE 2043CH01 Page References 6 1 6 VAE4 2043CH01 7 2 7 ESA 2043CH01 8 3 8 OS3 2043CH01 9 4 9 MGTEAM 2043CH03 45 5 45 JMPVMC 2043CH03 49 6 49 F011 2043CH05 107 7 105, 106 WSC9741 2043CH05 113 8 117 F042 2043CH05 F054 2043CH06 116 9 136 11 136 CICSDMS 2043CH06 139 12 138 CICSLSC 2043CH06 146 13 145 CICSDS 2043CH06 146 14 146 F066 2043CH08 F2043A1 2043CH09 177 16 187 17 186, 186 DOS
/XRL/3 274 29 273 F1010 2043CH13 279 30 278 F1011 2043CH13 295 31 294 F1012 2043CH13 295 32 294 F1038 2043CH13 296 33 294 F1013 2043CH13 297 34 296 F1014 2043CH13 302 35 301 F1015 2043CH13 303 36 301 F1016 2043CH13 304 37 303 F1017 2043CH13 310 38 309 F1018 2043CH13 311 39 309 F1019 2043CH13 312 40 311 F1020 2043CH13 313 41 312 F1021 2043CH13 317 42 316, 324 F1022 2043CH13 318 43 317 F1032 2043CH13 318 44 318, 325 F1031 2043CH13 319 45 318 F1023 2043CH13 31
/XRL/4 JMPP 2043CH32 493 58 493 Headings id File REDBCOM REDB$COM PLNG 2043IMBD TREAS FREAS INTSIZ CPS SIZCHGS SIZWHO APMIG MIGSTR OVERV SIZEDU WKSCOPE OCT02 FILEMIG SIZCOST DEVPLAN HMC3OV CVSE390 JCL 1 Part 1, Planning the Migration - An Introduction 3, 3, 3 4 1.2, Traditional Reasons for Migrating 3 10 1.3, Functional Reasons for Migrating to OS/390 3 13 2.1, Introduction to Sizing 13 18 2.2, OS/390 Components/Products/Subsystems 13, 416, 539 24 2.
/XRL/5 JCLFIL JCLHI JCLDIFF 2043CH04 JCLRED 2043CH04 CONJCL2 2043CH04 VSESAM MVSSAM VSECARR TDSTOR DTAMSD DTNAME DTMGT DTTAPE DTDISK IVTOC DTVSAM 73 4.3, JCL Differences Between VSE and MVS 69 76 4.3.2, JCL Expansion 84 4.3.11.3, MVS Conditional JCL 73 89 4.4, JECL 69, 84 91 4.5, VSE and MVS JCL Comparison Example 69 92 4.5.1, Sample VSE JCL 77, 91, 91 93 4.5.2, Sample MVS JCL 91, 91 94 4.5.
/XRL/6 DLIUTIL TELECOM AVTAM H2043A1 H2043A2 TBTAM TCPIP MSERIES PWRJES KEEPJOB TPSPL PSETUP SEPAGE EOPAGE 185 9.1, ACF/VTAM 185 186 9.1.1.1, VTAM Data Sets 186 192 9.2, ACF/NCP 185, 190 193 9.3, B T A M 185 193 9.4, Migrating TCP/IP 185 197 9.5, MQSeries 185 207 Chapter 10, POWER and JES2 73 207 10.1.1.1, KEEP Disposition for Pre-Execution Jobs 213 208 10.1.1.3, Tape Spooling 215, 216 208 10.1.1.4, Printer Forms Alignment via PSETUP 215, 217, 233 208 10.1.1.
/XRL/7 AFPPSF PSFINCN PSFRES PSFAPPL 2043CH11 2043CH11 2043CH11 AFPTOOL 2043CH11 DOSCV VSCB2CV ASMBLR TRM REGCONV COMREG LDMAC GTIME DMPMAC ROUTHDL VSMACS DMMACS RPG PLI STMPLI FORTRAN LE 240 11.3, Setting up AFP Resources 236 241 11.3.4, Migrating Print Applications 236 241 VSE Printer PARM Macro 242 11.4, Understanding Operational Differences 236 243 11.5, Other Differences 236 244 11.6, References 244 11.6.
/XRL/8 17, 17, 258, 259 CONDIF 2043CH17 LVMC 2043CH17 LEVCON 2043CH17 NONLEMG 2043CH17 C370HD 2043CH17 MIGLEV LEVX ABTX4 2043CH17 REXX 2043CH18 SRTJCL SRTCTLS SRTADDS DITTO DTCOMP NLSFUN NRFUN FUNCODE NLSBAT NRBAT DTSEC 352 17.2.1, LE/VSE-conforming Languages 354 17.4, Migrating from Non-LE/VSE Run-time Environments 355 17.4.2, C/370 353 359 17.5, Migrating from LE/VSE 353 364 17.5.2, User Exits and Abnormal Termination Exits 367 364 17.5.2.
/XRL/9 PUTRSU SETERM SETNJE TESTENV RUNSYS TSOISPF 390CNSL OPERRJE OPERNJE UTILS SYM00 SYM01 SYM02 SYM03 SYM04 SYM05 SYM06 SYM07 SYM08 SYM09 DIGPRBS CNVAPLS 414 25.5.1.3, Providing Terminal Access to the OS/390 System 404 415 25.5.1.
/XRL/10 482, 482, 483 IMPF CNVSRVS CNVTOOL MIGEXMP MIGEXP1 APPXS AX2 2043CH32 519 33.1, Conversion Services 519 520 33.
/XRL/11 i C120001 2043VARS C300007 2043VARS C120007 2043VARS C330001 2043VARS C340001 C010001 A030002 A030003 C310009 DITTIND C080001 C120004 C150007 C150004 C010003 C250002 C100002 C110002 C110001 C310003 A020001 C040003 C040002 134, 140, 153, 366, 135, 142, 153, 366, 135, 143, 154, 367, 136, 145, 154, 522, 136, 136, 137, 137, 138, 147, 147, 149, 150, 151, 201, 201, 201, 252, 252, 522 (1) COBOL 131, 251, 256, 259, 331, 131, 252, 256, 259, 351, 131, 252, 257, 260, 354, 24
/XRL/12 72, 73 C040004 C100003 C170001 C150003 C280006 C170005 C170003 C170004 C070005 C090004 C090005 C300005 OPLOIND C290001 C250003 C260004 C300004 C150001 C150012 C150005 C150002 C150009 C150010 C100004 C070001 C300003 C180001 C110005 2043VARS i (1) JECL 89, 89, 89, 90 i (1) JES2/POWER functional comparison 212, 213, 215, 218, 219, 220, 221, 223, 224, 225 i (1) Language Environment (LE) 196, 351, 351, 352, 352, 352, 353, 353, 353, 354, 359, 359, 365, 366 i (1) linkages
/XRL/13 235, 235, 236, 243, 243, 243, 244, 244 C110004 C110006 C120009 C150008 C140001 C300006 C110003 C190001 C080002 C250004 C250005 C050003 C150011 C070004 C040001 C300001 SMFPIND C050004 C260001 A010001 C280002 C070002 C260003 C050006 C040005 C270001 ECH0001 ECH0002 2043VARS i (1) PSF/MVS operational differences 242, 242 i (1) PSF/MVS references 244, 244, 244, 244, 244, 245 i (1) reserved words 263, 265 i (1) return codes in PL/I 344, 344 i (1) RPG II migration to OS
/XRL/14 ECH0003 ECH0004 ECH0005 ECH0006 ECH0007 ECH0008 ECH0009 ECH0010 ECH0011 ECH0013 ECH0014 ECH0015 ECH0016 ECH0017 ECH0018 ECH0019 ECH0020 ECH0021 ECH0022 ECH0023 2043VARS i (1) Assembler 131, 173, 196, 241, 267, 267, 267, 269, 269, 359, 359, 359, 364, 492 i (1) VSAM 15, 81, 110, 110, 110, 112, 114, 118, 118, 118, 118, 119, 119, 119, 119, 119, 121, 122, 122, 122, 123, 123, 123, 124, 125, 129, 130, 130, 131, 131, 290, 292, 292, 292, 292, 292, 292, 292, 387, 387, 455, 477, 477, 550
/XRL/15 3, 3, 4, 4, 10, 10, 13, 18, 27, 28, 29, 35, 35, 35, 36, 39, 42, 43, 44, 134, 163, 182, 193, 205, 235, 241, 250, 251, 329, 352, 353, 354, 358, 359, 371, 401, 420, 485, 529, 529, 531, 531, 532 ECH0024 ECH0025 SYSTIND VIRTIND APPLIND ANALIND AUTIND BATIND CATIND COMMIND COMPIND CONTIND COURIND DATIND CONVIND DATBIND DEFIND DEVIND DIFFIND DISPIND DOSIND DOSCIND EXITIND FCBIND FILIND 2043VARS i (1) SORT 131, 341, 341, 342, 377, 379, 379 i (1) DASD 16, 108, 108, 108, 108, 108,
/XRL/16 GENIND HIGHIND IBMIND ICCFIND INSTIND INTRIND JOBIND 2043VARS i (1) general 135, 136, 311, 351 i (1) high level 72, 242, 364, 544 i (1) I B M 250, 519, 520, 522 i (1) ICCF 155, 157, 157, 161, 163, 163, 167, 167, 218, 437 i (1) installation 200, 211, 243, 402, 405, 407, 410 i (1) introduction 13, 110, 169, 419, 443 i (1) job 2043VARS 2043VARS 2043VARS 2043VARS 2043VARS 2043VARS 26, 50, 70, 70, 72, 72, 73, 208, 213, 213, 214, 214, 222, 223, 275, 395, 439, 441, 515, 549 LEVIN
/XRL/17 PSFIND RECIND REMIND RESIND REXXIND RPGIND SDSFIND SHRIND SNAIND SPLIND STARIND SUMMIND SYSIND TAPIND TCPIND TRANIND TSOIND UNSIND USERIND USGIND VSCIND VSEIND Y2IND C020001 C020002 C020003 i (1) p r o g r a m 33, 171, 192, 257, 503, 517, 526 i (1) PSF 237, 237, 240, 240, 242, 242, 244 i (1) record 315, 315, 316, 316, 317 i (1) remote 219, 219, 229, 240, 452, 452, 453, 453, 454 i (1) resources 37, 78, 78, 187, 187, 190, 240 i (1) REXX 369, 369, 370, 370, 370, 37
/XRL/18 C020005 C020006 C020007 C020009 C030001 C030002 C030003 C030004 C320001 C320002 C320004 C320005 C320006 D010003 D020002 D020004 D030002 D030004 D030016 D030018 D040003 D040004 D040005 D040006 i (1) changes between VSE and OS/390 24, 24, 25, 25, 25, 25 i (1) approaches to migration 27, 27, 27, 28, 29, 29, 29, 30, 30 i (1) education 31, 31, 31, 31, 31 i (1) scope of work challenges 32, 33, 33, 35, 37, 37 i (1) OS/390 documentation resources 39, 40, 40 i (1) plan dev
/XRL/19 D040007 D040008 D040009 D040012 D040013 D040014 D040015 D050011 D050019 VOSIND D050021 D050022 D050023 D050024 CTRIND CSYSIND D080005 D080006 D080007 D080008 D080010 2043CH04 76 (1) JCL differences (VSE and MVS) (2) operator intervention 76, 76, 77, 77 78 (1) JCL differences (VSE and MVS) (2) resource allocation 78 78 (1) JCL differences (VSE and MVS) (2) hidden JCL 78, 79, 79, 79 81 (1) JCL differences (VSE and MVS) (2) JCL partition dependent codes 81, 81 81 (1) JCL d
/XRL/20 D080011 D090001 D090002 D090003 D090011 D090014 D090017 D100001 D100002 D100003 D100004 D100005 D100006 D100007 D100008 D100009 D100010 D100011 D100012 D100013 D100014 D100015 2043CH08 181 (1) SQL/DS to DB2 (2) other comparison areas 181, 182, 182, 182, 182 186 (1) ACF/VTAM (2) product installation 186 187 (1) ACF/VTAM (2) resource definition and operation 190, 190 190 (1) ACF/VTAM (2) customization and programming 190, 191 195 (1) migrating TCP/IP (2) TCP/IP configura
/XRL/21 D100016 D100017 D110001 D110003 D110004 D110007 D110008 D110011 D110021 D120010 D120011 D130001 D130002 D130003 D130004 D130005 D130006 D150001 D150008 2043CH10 230 (1) POWER/JES2 detailed comparisons (2) exit comparisons 231, 231 231 (1) POWER/JES2 detailed comparisons (2) POWER/JES2 command equivalences 232, 232, 233, 233, 233, 234, 234 235 (1) introducing PSF/MVS (2) functional comparison 235, 235, 235 236 (1) installing & configuring PSF/MVS (2) defining channel-attache
/XRL/22 D150009 D150010 D150014 D150019 D170001 D170016 D170017 D170018 C180004 D250005 D250006 D250007 D250008 D250009 D250010 D250013 D250011 D250012 D260005 D280003 D280004 D280017 2043CH15 336 (1) PL/I compiler options (2) options specific to MVS compiler 336, 336, 336, 336, 337, 337, 337, 337 337 (1) PL/I compiler options (2) execution options 337, 337, 337, 338 339 (1) ENVIRONMENT attributes (2) unsupported in MVS 339, 339, 339, 339, 339, 339, 339, 339, 339, 340 340 (1) PL
/XRL/23 D280018 D310005 D320003 D320006 D320009 D320010 D320012 D320015 D320017 D320018 D320023 D320025 D320026 D320027 D320029 D320030 D330004 D330005 D330007 D330008 D340001 452 (1) managing remote operations (2) JES2 RJE operations 452, 452, 453, 453, 453 453 (1) managing remote operations (2) NJE operations 454, 454 476 (1) DFSMS/MVS diagnosis (2) DFSMSdfp 476, 476, 477 484 (1) conversion process (2) recommendations 484, 484, 484, 484, 485, 485, 486 487 (1) mass conversion
/XRL/24 D340002 529 (1) customer migration example (2) environment 529, 529, 530, 530 531 (1) customer migration example (2) duration 531, 531 2043CH34 List Items id File TSK1 2043CH02 Page References 26 1 26 TSK2 2043CH02 26 2 26 TSK3 2043CH02 26 3 26 TSK4 2043CH02 26 4 26 TSK5 2043CH02 27 5 26 TSK6 2043CH02 27 6 26 TSK7 2043CH02 27 7 26 TSK8 2043CH02 27 8 26 TSK9 2043CH02 27 9 26 TSK10 2043CH02 27 10 26 TSK11 2043CH02 27 11 26 JANDS 2043CH04 71 4 78 Footnote
/XRL/25 OSJCL 2043CH04 POWJECL 2043CH04 J2JECL 2043CH04 86 7 88 8 89 9 90 10 89 JESIN 2043CH10 JSCHED 2043CH10 OUTSERV 2043CH10 FCB 2043CH10 TSOFUNC 2043CH10 TABC161 2043CH10 PMACS 2043CH10 212 11 213 12 215 13 217 14 219 15 224 16 226 17 211 PLINE 2043CH10 228 18 219, 221 PRMTB 2043CH10 228 19 220 PRMTS 2043CH10 229 20 220 PNODE 2043CH10 230 21 221 PCPTAB 2043CH10 PEXIT 2043CH10 230 22 231 23 220, 221 NJENM 2043CH10 NJEFCC 2043CH10 NJECM 20
/XRL/26 358 OPTRC1 2043CH17 363 42 363 OPTRC4 2043CH17 363 43 363 CICOPT 2043CH17 367 44 367 TABDLY 2043CH25 403 45 432 VENPS 2043AX02 539 46 Schedules id File JMPFSUM 2043CH03 Page References 56 56 JMPFDET 2043CH03 60 58 Processing Options Runtime values: Document fileid ........................................................................................... Document type ............................................................................................ Document style .
/XRL/27 Print cross reference page numbers ....................................................... Process value ............................................................................................. Punctuation move characters ................................................................... Read cross-reference file .......................................................................... Running heading/footing rule ....................................................................
