CA-UFO° Support Package User Guide Release 3.0 *a) Computer Associates» ROosUFS0SUP—PROPRIETARY AND CONFIDENTIAL INFORMATION — ‘THIS MATERIAL CONTAINS, AND IS PART OF A COMPUTER SOFTWARE PROGRAM WHICH IS, PROPRIETARY AND CONFIDENTIAL INFORMATION OWNED BY COMPUTER ASSOCIATES: INTERNATIONAL, INC. THE PROGRAM, INCLUDING THIS MATERIAL, MAY NOT BE DUPLICATED, DISCLOSED OR REPRODUCED IN WHOLE OR IN PART FOR ANY PURPOSE WITHOUT THE EXPRESS WRITTEN AUTHORIZATION OF COMPUTER ASSOCIATES. ALL AUTHORIZED REPRODUCTIONS MUST BE MARKED WITH THIS LEGEND. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the United States Government ("the Government’) is subject to restrictions as set forth in A) subparagraph (€)2) of the Commercial Computer Software ~ Restricted Rights clause at FAR 52.227-19, and/or B) subparagraph (OCG ofthe Rights in Technical Data and Computer Software clause of DEAR 25227-7013. This software is distributed to the Government by: ‘Computer Associates Intemational, Ine. ‘One Computer Associates Plaza Islandia, NY 11788-7000 ‘Unpublished copyrighted work — all rights reserved under the copyright laws ofthe United States. “This material may be reproduced by or forthe United States Government pursuant tothe copyright license under the clause at DFAR 252.227-7013 (OCTOBER 1988), Copyright ©1999 Computer Associates International, Inc., ‘One Computer Associates Plaza, Islandia, NY 11788-7000 All rights reserved. All product names and service names referenced herein are trademarks of their respective companies. Call Computer Associates technical services for any information not covered in this manual or the related publications. In North America, see your Computer Associates Product Support Directory for the appropriate telephone number to call for direct support, or you may call 1-800-645-3042 or 1-516-342-4683 and your call will be returned as soon as possible. Outside North America, contact your local Computer Associates technical support center for assistance.osPuGi287 Release 3.0 December, 1987 MEMO TO: UFO Productivity System Users SUBJECT: On-Line Software International Product Documentation & Structure This is the Operational Support Package User Guide, file OSPUG1287 for UFO Productivity System Release 3.0. Product Structure ‘The UFO Productivity System and COBOL/XE are two application development systems available from On-Line Software International. The UFO Productivity System allows you to choose between an interactive forms-based development facility and a 4GL procedural facility. The UFO Productivity System and COBOL/XE are supported by many common utilities, including a sereen painting facility (PAINT) and a common data catalog (CAT). Underlying the development software are the IOX access method and the system interface code (LLOSSP). UFO Productivity System COBOL/XE Development Systems PAINT caT Development Tools 10x TOX Access Method LLOSSP ‘System Interface Code MVS VSE CMS TSO CICS Operating System/TP Monitor Application programs written with the developrient systems shown at the top of the chart operate at the highest logical level, and depend on all the software shown running below them. Similarly, products shown at each lower level depend on the products below them, and provide support for the products above. Everything ultimately depends on the operating system or teleprocessing ‘monitor running in the host. iiiRelease 3.0 December, 1987 OsPUG1287 Education & Consulting Services Your regional On-Line Software International sales office will be happy to provide educational and consulting services for your system. Technical Support For technical support, contact your local representative or the central customer support offices located in Princeton Junction, New Jersey or London, England. The addresses are: On-Line Software International, Inc. 34-40 Washington Road Princeton Junction, New Jersey 08550 800-257-9426 - OR On-Line Software International, Inc. Tenterden House 3 Tenterden Street Hanover Square London W1R 9AH England 44-163 1-3696 Supported oper: IBM. environments are limited to system software releases currently supported by We encourage your comments on both the product and its documentation. Send your suggestions for future enhancements to the UFO Productivity System product line or documentation to: ‘On-Line Software International, Inc. 455 The Embarcadero San Francisco, CA 94111 iv Operational Support Package User GuideRelease 3.0 December, 1987 OsPUG1287 CONTENTS 1.1 The LLOSSP 5 1.1.1 Altering LLOSSP Performance. 1.2 System Data Spaces ..... 1.2.1 Internal Files 1.3 Manual Organization . SECTION 2: The CICS Simulation Utility ........ 2-1 Invoking The CICS Simulation Utity 2.1.1 From CMS . 2.1.2 From TSO 2.2 Simulated CICS Session For Online Users. 2.3 Running Online Programs In BATCH-TEST .4 SCL Considerations 2.4.1 DOS Batch . 2.4.1.1 Sample Jobstream » 2.4.2 0S Batch ...... 2.4.2.1 Sample Jobstream . 2.4.3 CMS .. paReS 2.4.3.1 Running Batch Util 2.4.4 TSO 2.4.4.1 Running Batch Utilities Interactively ..... Sea oobae owen SECTION 3: The Data Capture Utility . . 3.1 Invoking The Online Data Capture Utility . 3.1.1 From CICS . 3.1.2 From CMS - 3.1.3 From TSO coer none 3.2 Using The Online Data Capture Utility... SECTION 4: The Component Format Utility ............ 4.1 Control Card Syntax... peeereer eat eeeeeee Taal} vi Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 4.1.1 Global Cards... 4.1.2 Action Cards - 4.1.3 Control Card Examples 4.2 Passing Parameters To OXFORMAT . 4.3 JCL Considerations . . . . eee 4.3.1 Running OXFORMAT In A'CMS Environment - 4.3.1.1 Passing Parameters To OXFORMAT . 4.3.2 Running OXFORMAT In A DOS Environment . 4.3.2.1 Passing Parameters To OXFORMAT. 4.3.3 Running OXFORMAT In An OS Environment. 4.3.3.1 Passing Parameters To OXFORMAT . 4.3.4 Running OXFORMAT In A TSO Environment . 4.3.4.1 Passing Parameters To OXPORMAT . 4.10 4.10 41 aan SECTION 5: The Export/Import Utilities .. BA 5.1 Control Card Syntax . 8. 8.1.1 Global Cards 5. 5.1.2 Action Cards . . . 5: 5.1.3 Control Card Examples 5: 5.2 Passing Parameters .. 5.2.1 Passing Parameters To OXEXPORT 5.2.2 Passing Parameters To OXIMPORT . 5.3 JCL Considerations............... 5.3.1 Running OXEXPORT In A CMS Environment 5.3.1.1 Passing Parameters To OXEXPORT .. .. 5.3.2 Running OXIMPORT In A CMS Environment 5.3.2.1 Passing Parameters To OXIMPORT . 8.3.3 Running OXEXPORT In A DOS Environment 5.3.3.1 Passing Parameters To OXEXPORT ....... 5.3.3.2 OXEXPORT: DOS To CMS For VM Users. 5.3.4 Running OXIMPORT In A DOS Environment ... |. 5.3.4.1 Passing Parameters To OXIMPORT ....... 5.3.5 Running OXEXPORT In An OS Environment»... - 5.3.5.1 Passing Parameters To OXEXPORT . 8.3.6 Running OXIMPORT In An OS Environment 5.3.6.1 Passing Parameters To OXIMPORT . 5.3.7 Running OXEXPORT In A TSO Environment 5.3.7.1 Passing Parameters To OXEXPORT . 5.3.8 Running OXIMPORT In A TSO Environment 5.3.8.1 Passing Parameters To OXIMPORT . BSESROUESSRASESGESEESSOARS SECTION 6: The Source Library Utility . . . 3 6.1 Control Card Syntax . Contents vilRelease 3.0 December, 1987 OSPUG1287 6.1.1 Global Cards . 6.2 6.1.2 Action Cards - 64 6.1.3 Control Card Examples. 67 6.2 Passing Parameters To OXBOOK 69 6.3 JCL Considerations . 6.10 6.3.1 Running OXBOOK In A CMS Environment. 6.10 6.3.1.1 Passing Parameters To OXBOOK . .. 6.11 6.3.2 Running OXBOOK In A DOS Environment. 6.12 6.3.2.1 Passing Parameters To OXBOOK . 6.12 6.3.3 Running OXBOOK In An OS Environment - 6.13 6.3.3.1 Passing Parameters To OXBOOK 6.13 6.3.4 Running OXBOOK In A TSO Environment 6.13 6.3.4.1 Passing Parameters To OXBOOK . 6.14 SECTION 7: UFO-CAT conversion program . 7.1 Conversion Strategies . 7.2 Control Cards And JCL 7.2.1 Space Cards 7.2.2 View Cards . 7.2.3 Sample JCL 7.2.8.1 Sample VSE JCL 7.2.3.2 Sample OS JCL . 7.2.4 Sample CMS Command Statements .- 7.3 UFO/Forms-CAT Compatibility . 7.8.1 Groups ..... : 7.3.2 Access Method Type 7.3.3 Field Type .. 7.3.4 Field Length - 7.3.5 UFO/Forms ISC Option 7.3.6UOSIZE........ 7.3.1 UFO/Forms Security Codes 7.3.8 Automatic Field Initialization - 7.3.9 Field Start Positions ....... 7.3.10 Field Level Validation... 7.3.11 User Dictionary Exit . 7.4 Conversion Examples .... meee -1 UFO/Forms View: Example 1 .2 Input Cards... -3 Conversion Output. .4 Converted View... .5 Interpreting the Output .6 Updating the View 7.10 7.10 TAL TAL 7:12 7:12 713 7:13 Ta 718 7 UFO/Forms View: Example 2 AT 8 Input Card . ; 7aT 9 Conversion Output - 7.18 viii Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 7.4.10 Converted View . 18 7.4.11 Interpreting the Output . 7:19 7.4.12 Updating the View .. 20 SECTION 8: CICS Operation BL 8.1 XA Support ...... 8.2 Remote File Access . 8.3 Temp Storage SECTION 9: CMS Operation 9.1 SYSIPT Input .... 9.2 SYSLST Output... , 91 9.3 CMS Terminal Considerations 9.2 9.4 CMS Temp Storage File Simulation 9.2 9.4.1 TSLEVEL1........ 9.2 9.4.2 TSLEVEL 2 , 9.3 9.5 CMS Transient Data File Simulation . ; 9.3 9.5.1 Standard Sequential Transient Data File 9.3 9.5.2 IOX Transient Data Files . 9.3 9.6 Passing Parameters To CMS Programs 9.7 Return Codes . SECTION 10: Batch Operation . 10.1 10.1 SYSIPT Input 10.1 10.1 + 101 sees 10.2 10.2 10.2 10.2 10.2 10.2 10.3 10.3 10.3 10.3 10.3 10.4 10.4 10.4 Batch Transient Data File Simulation 4.1 Standard Sequential Transient Data File . 10.4.2 IOX Transient Data File .... 10.5 Passing Parameters To Batch Programs Contents ixRelease 3.0 December, 1987 OSPUG1287 SECTION 11: TSO Operation .. . econ SeeeeeremLenT| 11.1 SYSIPT Input ALL 11.2 SYSLST Output La 11.3 Terminal Considerations . ut 11.3.1 TSO/TCAM vs TSO/VTAM 12 11.4 TSO Temp Storage File Simulation . 12 11.5 TSO Transient Data File Simulation 12 11.5.1 Standard Sequential Transient Data File 1.2 11.5.2 IOX Transient Data File ........... 113 11.6 Passing Parameters cote 113 11.7 Return Codes . . 13 SECTION 12: LLOSSP Control Cards... 6... 0.0.0... e eee eee ee eee eee ceeee WR 12.1 System Option Cards ...... 12.2 12.2 Test Control Cards . . 12.9 12.3 SYSIPT Input Stream Examples . 12.10 SECTION 13: Reserved File Names ........ eee 13.1 x Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 Contents xiosPuG: FIGURES 2.1 CICS Simulation Utility Menu Screen . . 2.2 CICS Simulation Utility Abbreviated Screen . . 2.3 Sample DOS Jobstream 2.4 Sample OS Jobstream . 2.5 Sample CMS LLXXCICS EXEC . 2.6 Sample TSO LLXXCICS CLIST ... 3.1 Data Capture Utility Screen 3.1 OXFORMAT Control Card Example 1 4.1 OXFORMAT Control Card Example 2 4.2 OXFORMAT Control Card Example 3. 4.3 OXFORMAT Control Card Example 4. 5.1 OXEXPORT and OXIMPORT Control Card Example 1 . . 5.2 OXEXPORT and OXIMPORT Control Card Example 2 .. 5.3 OXEXPORT Control Card Example 3 . . 6.1 Control Card Example: OS . . 6.2 Control Card Example: CMS .. 6.3 Control Card Example: DOS ... 7.1 Sample VSE JCL Beene) 7.2 Sample OS JCL . . pene 7.3 UFO/Forms Access Method Type Conversion ... 7.4 UFO/Forms Field Type Conversion... .. Contents 1287 Release 3.0 December, 1987 = 22 2.3 25 - 26 - 27 2.9 34 45 - 46 46 - 46 - 5.9 - 59 5.9 67 - 67 - 68 14 14 11 78 xiiiRelease 3.0 December, 1987 OSPUG1287 18 7.6 1 78 19 7.10 112 UFOMPorms View #10... oe ee eee eee eee Seno eee eee eee 712 Conversion Output for View #1 6.2... e eee eee ee eee ee ee eee sence 713 Converted CAT View #1. See eee eee eee 714 Updated CAT View #1........... eee See eee ees wee a Seeeeeeeeee Bo TAT Conversion Output for View #1 oe... eee cece eee eeeeeee sees vee TAB Converted CAT View #2 Updated CAT View #2. . Operational Support Package User GuideosPUuGi287 Release 3.0 December, 1987 SECTION 1. INTRODUCTION ‘The Operational Support Package is a collection of software products that support and enhance the OSI application development languages. Within the Support Package are two major develop- ment tools: PAINT, a screen painting facility, and CAT, a data catalog. ‘The IOX Access Method and its utilities support file creation and maintenance. PAINT, CAT, and IOX have individual manuals that document and describe the products and their functions. This document describes the collection of utilities and products that make up the remainder of the Support Package. 1.1 The LLOSSP The fundamental component of the Support Package is the system interface software, the Low- Level Operating System Support Package (LLOSSP). Every product and utility depends on the LLOSSP. In general, users can remain blissfully unaware of the LLOSSP’s existence, but it has an effect on the operation of products within each environment. This effect may be subtle, but it is nonetheless important. By specifying different LLOSSP options, you can alter operational char- acteristics of a product or series of products. Its also true that the effect of the LLOSSP may be to slightly alter the operation of the same product across differing environments. This would be of interest and importance in shops where ‘migration and portability are required, e.g., where production and test are different environments. 1.1.1 Altering LLOSSP Performance Certain operating characteristics of the LLOSSP are governed by parameters specified in the LLMAGBL macro during DTR installation. You can override some of these options by using LLOSSP system option control cards. References will be made to these cards throughout the rest of this manual. For a complete discussion of all the LLOSSP system option control cards and how they operate, consult "Section 12". For a discussion of the LLMAGBL macro, consult the Opera~ tional Support Package Customization Manual. Introduction LlRelease 3.0 December, 1987 OSPUG1287 1.2 System Data Spaces In order for the Operational Support Package to operate correctly, it requires certain system data spaces to contain necessary files. The primary system data space is the OSPACE. ‘The OSPACE can also function as a CATSPCE (repository of CAT views) and PNTSPCE (repository of PAINT panels). However, both the CATSPCE and PNTSPCE can exist independently of the OSPACE. ‘The OSPACE, CATSPCE, and PNTSPCE are designated at DTR installation in the LLMAGBL macro. However, individual users in batch, CMS, or TSO can use LLOSSP control cards to over- ride the designations for a particular job or user. See "Section 12" for a complete discussion of LLOSSP control cards. For a more complete discussion of system data soaces, consult the Operational Support Package Customization Manual. 1.2.1 Internal Files Whether you specify an individual PNTSPCE or CATSPCE, or find the OSPACE sufficient for your needs, each time you use PAINT to create panels, they are stored in a file called PNTPNL. Likewise, when you use CAT to create views, they are stored in a file called CATVIEW. Both panels and views, as products of the Support Package, can be called components. Whenever you access a component, the Support Package assumes that the data space (library) you are searching contains the appropriate file, and that the component resides therein. If you are using PAINT or CAT to create a component, and the appropriate file does not exist, the Sup- Port Package creates the file before it creates the component. When any of the Support Package utilities mentions the files in which components reside, the ref- erence is to PNTPNL or CATVIEW. The Support Package is responsible for all aspects of the c ation of these files, with no user intervention necessary. See “Section 13" for a complete list of reserved file names. Lez Operational Support Package User GuideosPuGi287 Release 3.0 December, 1987 1.3 Manual Organization ‘The Operational Support Package User Guide discusses the following topics: ‘The CICS Simulation Utility: discussed in "Se:tion 2", provides a simulated CICS session for CMS, TSO, and batch users, In addition, for online users in CMS and TSO, the CICS Simulation Utility is the only way to invoke PAINT and CAT. ‘The Data Capture Utility: discussed in "Section 3", allows users to capture data in an online ses- sion for use with batch programs run online through the CICS Simulation Utility. ‘The Component Format Utility: discussed in “Section 4", is a batch program that allows users to print formatted listings of PAINT panels and CAT views, among others. ‘The Export/Import Utilities: discussed in "Section 5", are batch programs that allow users to move components (PAINT panels and CAT views) from one file to another. ‘The Source Library Utility: discussed in "Section 6", converts CAT views into COBOL copybooks, ‘The UFO-CAT conversion program: discussed in "Section 7”, is a batch program that converts UFO/Forms views from UFO/Forms Data Dictionary format to CAT format, Operational Considerations: “Section 8” through “Section 11" discuss the differences in product operation by environment (OS, DOS, CMS, and TSO). ‘The LLOSSP: "Section 12" discusses LLOSSP control cards, which allow you to tailor the opera- tion of the LLOSSP in your environment. Reserved File Names: are discussed in “Section 13", Introduction 13Release 3.0 December, 1987 La OSPUG1287 Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 SECTION 2. THE CICS SIMULATION UTILITY The CICS Simulation Utility provides a simulated CICS session for online users in TSO and CMS, and batch users in OS or DOS. Under CMS and TSO, the Operational Support Package online utilities (PAINT, CAT, IOXUTIL, and the Data Capture Utility) are always invoked via the CICS Simulation Utility. In addition, OXFORMAT, IOXMAINT, UFO/Forms, and UFO/4GL can be invoked from this utility. And you can tailor the CICS Simulation Utility with ->TRANSACTION= control cards so that the COBOL/XE Maintenance Transaction, as well as any COBOL/XE applications that you have developed, can be run under the utility. Under OS or DOS batch, the CICS Simulation Utility provides a means of debugging online appli- cations using facilities available in batch-test mode. See "Section 2.3” for additional information about batch-test mode. 2.1 Invoking The CICS Simulation Utility You invoke the CICS Simulation Utility differently in CMS and TSO. 2.1.1 From CMS To invoke the CICS Simulation Utility from CMS, simply issue the command: LLXXCICS 2.1.2 From TSO To invoke the CICS Simulation Utility from TSO, simply issue the command: CALL 'loadlibname(LLXXCICs}' where loadlibname is the name of the loadlib determined during DTR installation. The CICS Simulation Utility 24Release 3.0 December, 1987 OSPUG1287 2.2 Simulated CICS Session For Online Users When you invoke the CICS Simulation Utility from either TSO or CMS, the system will display the CICS Simulation Utility Menu Screen, pictured in Figure 2.1. LLxxcrcs Simulated CICS Session 3.0.0 From this screen you can invoke any on-line program exactly as you would under CICS. Use the blank window below to enter all initial input, beginning with a transaction code (1 to 8 characters), When the transaction ends, you will return to this screen. Hit to end the session. The following transaction codes have been defined for this session: PAINT «= CAT. TOXMAINT IOXUTIL UFO UPO/4CL OXFORMAT CAPTURE COPYRIGHT On-Line Software International, Inc. 1987, ALL RIGHTS RESERVED. Figure2.1 CICS Simulation Utility Menu Screen This menu screen allows you to choose from among a set of transactions whose transaction IDs appear on the screen. Shown here are the predefined transactions that are always available under the CICS Simulation Utility. If you code any -> TRANSACTION cards, the transaction IDs ‘you assign them will also appear on the CICS Simulation Utility Menu screen. Follow the instructions on the screen to invoke the transaction you wish to use. When you exit the transaction, you will still be in the CICS Simulation Utility. The screen will look like the one pictured in Figure 2.2. To re-display the menu screen, type MENU and press . To terminate the utility, press . 22 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 Lixxcres Simulated CICS Se: 3.0.0 Enter transaction code, "MENU", or COPYRIGHT On-Line Software International, Inc. 1987, ALL RIGHTS RESERVED. Figure 22 CICS Simulation Utility Abbreviated Screen ‘The advantages to using the CICS Simulation Utility are reduced response time and improved per- formance. Once you have loaded a particular program by issuing its transaction ID, it becomes available to you much more quickly than if it had to be loaded each time you wanted to use it. In addition, the CICS Simulation Utility reduces system overhead incurred through initialization and termination of programs. ‘Thus, you can use the CICS Simulation Utility to develop applications more quickly, passing from UFO/Forms to PAINT to CAT with greater speed than if you had to invoke each separately from the console. 2.3 Running Online Programs In BATCH-TEST Mode Users can take advantage of the CICS Simulation Utility and the Data Capture Utility (discussed in “Section 3") to run online applications in a batch environment. This batch-test mode may prove useful in producing hardcopy documentation of problems you encounter while running the applica- tions at a terminal. The CICS Simulation Utility 2.3Release 3.0 December, 1987 OSPUG1287 When you run a program in batch-test mode, the LLOSSP internally maintains a simulated termi- nal buffer. For each terminal write request issued by the transaction program, a representation of this screen (a screen image) is written to the SYSLST file. Terminal input is provided by using the online Data Capture utility to capture actual operator-entered data. The LLOSSP writes out the screen image with all input data in response to each terminal input request issued by the transaction. By including test control cards in the SYSIPT input stream, you can produce formatted dumps at certain strategic points in the run of a transaction in batch-test mode. To run a program in batch-test mode, you must: L Run the application online in CICS, CMS, or TSO, using the Data Capture Utility to save all operator-entered data to an IOX file. See "Section 3” for details on using the Data Capture Utility. 2. Code a ->TERMINPUT= system option card specifying the name of the IOX file and data space in which your operator-entered input was saved. 3. Code a -> TRANSACTION control card, specifying the transaction code and the name of the program to be run in bateh-test mode. ->TRANSACTION=TRN1 , PROGRAML NOTE ‘You need code a -> TRANSACTION = card only if the transaction you used to trap data with the Data Capture Utility is not one of the predefined transactions dis- played on the Menu screen shown in Figure 2.1. Execute the CICS Simulation Utility. 2.4 JCL Considerations ‘You must code appropriate JCL statements for the CICS Simulation Utility, according to the envi- ronment in which you operate. 24 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 2.4.1 DOS Batch You need the following statements to successfully execute the CICS Simulation utility in a DOS batch environment: » An ASSGN statement for SYSIPT. The SYSIPT file must contain all control cards as described above. » An ASSGN statement for SYSLST. » LBL statements for both the index and repository components of the IOX data space desig- nated as the OSPACE, or the IOX data space named in the ->OSPACE card, and for any other IOX data spaces that may be accessed by the application program. » An EXEC PGM=LLXXCICS statement. 2.4.1.1 Sample Jobstream Figure 2.3 illustrates a sample DOS jobstream that runs a transaction in bateh-test mode under the CICS Simulation Utility. The data for this transaction was previously captured using the Data Capture Utility. 7/ JOB JOBNAME // DLBL USRIOXI, 'IOX.USRIOXI', 99/365, VSAM 7/7 DLBL USRIOXR, 'IOX.USRIOXR', 99/365, VSAM // EXEC PGM=LLXXCICS ~>TERMINPUT=TESTDATA, USRIOX => TRANSACTION=TRN1 , PGM1 7* le Figure 2.3 Sample DOS Jobetream, The CICS Simulation Utility 2.5Release 3.0 December, 1987 OSPUG1287 2.4.2 OS Batch ‘You need the following statements to successfully execute the CICS Simulation utility in an OS batch environment: = ADD statement for SYSIPT. The SYSIPT file must contain all control cards as described above. ~ ADD statement for SYSLST. + DD statements for both the index and repository components of the IOX data space desig- nated as the OSPACE, or the IOX data space named in the ->OSPACE card, and for any other IOX data spaces that may be accessed by the application program. » An EXEC PGM=LLXXCICS statement. 2.4.2.1 Sample Jobstream Figure 2.3 illustrates a sample OS jobstream that runs a transaction in batch-test mode under the CICS Simulation Utility. The data for this transaction was previously captured using the Data Capture Utility. //JOBNAMEJOB . . . 7/JOBLIB_ —_DD_DSN=OSP.LOADLIB, DISP=SER 7/JOBSTEP EXEC PGM=LLXXCICS 7/SYSPRINT DD SYSOUT=A 7/SYSLST_ DD -S¥SOUT=A 7/OSRIOXI DD OSP.USRIOXI, DISP=OLD 7/USRIOXR DD OSP.USRIOXR, DISP=OLD 7/SXSIN Dp * * As 7/SXSIPT DD * ~>TERMINPUT=TESTDATA, USRIOX >> TRANSACTION=TRN1 , PGM1 7* Figure 2.4 Sample 08 Jobstream 2.6 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 2.4.3 CMS ‘You need the following commands to successfully execute the CICS Simulation utility under CMS: * AFILEDEF command for SYSIPT. The SYSIPT file must contain all control cards as described above. You need not code a FILEDEF if you have placed your cards in a file called FILE SYSIPT A * A FILEDEF command for SYSLST. You need not code a FILEDEF if you wish all print output routed to a file called FILE SYSLST A. + FILEDEF commands for SYSIN and SYSPRINT. (These files will probably be assigned to TERMINAL.) » You need no FILEDEFS for IOX data spaces in a CMS environment, but the IOX data space designated as the OSPACE, or the IOX data space named in the ->OSPACE card, and any other IOX data spaces that may be accessed by the application program must be available on a currently accessed disk. » Issue the command LLXXCICS from the CMS console. 2.4.3.1 Running Batch Utilities Interactively ‘You can run batch utilities like OXFORMAT and IOXMAINT interactively online with the CICS ‘Simulation Utility under CMS. To do this, assign SYSIN and SYSPRINT to your terminal. Fig- ure 2.5 illustrates a sample EXEC that does this. FILEDEF SYSIPT DISK FILE S¥SIPT A FILEDEF SYSLST PRINTER FILEDEF SYSIN TERMINAL PILEDEF SYSPRINT TERMINAL LLXXCICS (€1 Figure 2.5 Sample CMS LLXXCICS EXEC The CICS Simulation Utility 2.7Release 3.0 December. 1987 OSPUG1287 NOTE By coding the EXEC exactly as shown, you will be able to pass parameter data to the CICS Simulation Utility, which will allow you to bypass the CICS Simulation Utility Menu Screen, You can invoke the batch utility from the command line by coding: EXEC LLXXCICS utlname where utlname —_is the name of the batch utility you wish to run interactively under the CICS Simu- lation Utility. 24.4 TSO ‘You need the following commands to successfully execute the CICS Simulation Utility under TSO: + An ALLOCATE command for SYSIPT. The SYSIPT file must contain all control cards as described above. = An ALLOCATE command for SYSLST. = ALLOCATE commands for SYSIN and SYSPRINT. (These files will probably be assigned toa terminal dataset DATASET (*).) = An ALLOCATE command for both the index and repository components of the IOX data space designated as the OSPACE, or the [OX data space named in the ->OSPACE card, and for any other [OX data spaces that may be accessed by the application program. Issue the command CALL "loadlibname(LLXXCICS)' from the TSO terminal. For loadlibname, code the name of the load library into which the Support Package was installed. 28 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 2.4.4.1 Running Batch Utilities Interactively You can run batch utilities like OXFORMAT and IOXMAINT interactively online with the CICS. Simulation Utility under TSO. To do this, assign SYSIN and SYSPRINT to your terminal. Fig- uure 2.6 illustrates a sample CLIST that does this. Note that the PROC statement in the sample LLXXCICS.CLIST allows you to invoke the batch utility you wish to run directly from the termi- nal. You can do this by substituting the utility name for MENU. If you do not specify a different keyword variable, the CICS Simulation Utility will display the menu screen. PROC 0 TRAN(MENU) ALLOCATE FILE (S¥SIPT) DATASET (SYSIPT.DATA) ALLOCATE FILE (SYSLST) DATASET (SYSLST.DATA) NEW BLOCK (121) + LRECL (121) RECFM (F) SPACE (1000,500) ALLOCATE FILE (SYSIN) DATASET (*) REUSE ALLOCATE FILE (SYSPRINT) DATASET (*) REUSE ALLOCATE FILE (USRIOXR) DATASET (USRIOXR.DATA) SHR ALLOCATE FILE (USRIOXI) DATASET (USRIOXI.DATA) SHR CALL 'loadlibname(LLXXCICs)' Figure 2.6 Sample TSO LLXXCICS CLIST You can invoke the batch utility explicitly from the command line by coding: EXEC LLXXCICS 'TRAN(utlname)' where uutlname —_is the name of the batch utility you wish to run interactively under the CICS Simu- lation Utility. The CICS Simulation Utility 2.9Release 3.0 December, 1987 2.10 OsPUG1287 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 SECTION 3. THE DATA CAPTURE UTILITY The online Data Capture Utility allows you to trap all terminal input data entered by an operator, and write it to an IOX file. You can use this file to provide terminal input to your application when you run it in batch-test mode, causing the online scenario to be duplicated exactly. Once you have invoked the Data Capture Utility (as discussed below), the next transaction you Tun at that terminal will execute in data capture mode, which continues until the entire application conversation is ended. At this point, the [OX file is ready to be used as input to the same applica. tion in batch-test mode. 3.1 Invoking The Online Data Capture Utility The Data Capture Utility is invoked differently from CICS than from CMS or TSO. 3.1.1 From CICS To invoke the Data Capture Utility from CICS: 1 Press . Type CAPTURE ‘Your systems programmer may have altered the transaction ID for your installa- tion. a. Press . ‘The Data Capture Utility 3aRelease 3.0 December, 1987 OsPUG1287 3.1.2. From CMS In CMS, the Data Capture Utility is invoked through the CICS Simulation Utility. You invoke the CICS simulation utility by issuing the command: LLXXCICS The CICS Simulation Utility Menu screen will be displayed. You then invoke the Data Capture Utility by typing the Data Capture Utility transaction ID, which is predefined as CAPTURE. Alternatively, you can bypass the menu screen by issuing the command: LLXXCICS (CAPTURE Consult “Section 2" for additional information about the CICS Simulation Utility. 3.1.3 From TSO In TSO, the Data Capture Utility is invoked through the CICS Simulation Utility. You invoke the CICS Simulation Utility by issuing the command: CALL 'loadlibname(LLXXCICS) ' where loadlibname is the name of the loadlib determined during DTR installation. The CICS Simulation Utility Menu screen will be displayed. You then invoke the Data Capture Utility by typing the Data Capture Utility transaction ID, which is predefined as CAPTURE. Alternatively, you can bypass the menu screen by issuing the command: CALL 'loadlibname(LLXXCICS)' 'CAPTURI 3.2 Operational Support Package User GuideOsPuG1287 Release 3.0 December, 1987 3.2 Using The Online Data Capture Utility ‘Once you invoke the Data Capture Utility, the system will display the Data Capture screen, pic- tured in Figure 3.1. The screen displays the default data space USRIOX, and prompts you for the names of the file to which you wish your terminal input to be written. You must supply the file name, and you can change the data space designation if you wish. Ifthe file you specify already exists, you will be offered the opportunity to do one of the following: ~ extend the existing file, by pressing + delete the existing file, by pressing » create a new file, by changing the file name and pressing If the file you specify does not exist, it will be allocated. (The data space you specify must already exist.) When your IOX file has been successfully allocated, a message to this effect will be dis- played. You must then press and proceed to invoke the transaction that you intend to run in data capture mode. If you press at any time before the IOX file has been successfully allocated, data cap- ‘ture mode will not be in effect for the next transaction. The Data Capture Utility 3.3Release 3.0 December, 1987 OsPUGi287 CAPTURE Terminal Input Data Capture Utility 3.0.0 TOX File Name: TOX Data Space Name: USRIOX Enter the 10K file name an¢ data space name to which you wish the terminal input data to be written. COPYRIGHT On-Line Software International, Inc. 1987, ALL RIGHTS RESERVED. Figure 3.1 Data Capture Utility Screen 34 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 SECTION 4. THE COMPONENT FORMAT UTILITY ‘The Component Format Utility (OXFORMAT) is a batch program that allows users to print for- ‘matted listings of components such as CAT views, PAINT panels, and UFO/Forms DDs. Input to OXFORMAT consists of two types of control cards: Global Cards: are used to set processing options. These options remain in effect until changed by another global card, or until end of job. ‘Action Cards: are used to specify the specific component(s) to be formatted. Each action card is Processed in order, and has no effect on subsequent processing. 4.1 Control Card Syntax Each OXFORMAT control card consists of a keyword identifying the control card type and at least ‘one parameter. Control card syntax rules are: + The keyword must be coded beginning in column 1 on the input card. » The keyword is always followed immediately by an equal sign. Parameter values must be coded beginning in the position immediately following the equal sign. * Parameters are delimited by commas. > Parameters containing embedded blanks must be delimited by apostrophes. > Parameter data may continue to column 71 on the input card. The Component Format Utility 4aRelease 3.0 December, 1987 OsPUGi287 4.1.1 Global Cards ‘The following global cards are recognized by OXFORMAT: LIBRARY =data-space-nameffilename, VSAM ‘This card specifies the source of the components to be for- matted. LIBRARY =data-space-name specifies the [OX data space in which the components to be formatted reside. You can code LIBRARY cards at any point in the job stream, but OXFORMAT considers only the most recent LIBRARY as current. If you do not code a valid LIBRARY card before attempting to format a component, an error message will be issued and the current action will be terminated. LIBRARY = filename, VSAM is an option for compiled com- ponents that reside in a VSAM file. This option is valid only for the STAGE= action. PASSWORD=control-password This card enables you to specify a control password. This parameter is meaningful only when formatting UFO/Forms ‘components. If you code this parameter, it must agree with the value specified for CNTRLPW in the UFOINIT macro. SUFFIX=UFOINIT-suffix This card specifies the suffix by which a customized version of the UFOINIT table is to be accessed. ‘The UFOINIT-suffix is a 2-character value that replaces the release number as the last 2 characters of the UFO/Forms table identifier. This allows you to differentiate between multiple versions of customized UFO/Forms tables. If you do not supply the correct suffix, the default copy of the UFOINIT table will be loaded instead of the customized version. See the UFO/Forms Customization and Operation Guide for additional details. 42 Operational Support Package User GuideosPUuG1287 Release 3.0 December, 1987 4.1.2 Action Cards ‘The first (or only) parameter on all action cards is name-range. A name-range may be specific or generic. ‘You can request generic processing by coding a slash (/ ) in place of one or more characters in the name-range parameter. The slash means that any character can occupy this position in the name. = For example, the name-range ABCIiii/ represents all names that begin with ABC. » The name-range //DEFI represents all names that contain DEF in the third, fourth and fifth positions. » The entire range of names for a component can be requested by coding the name-range mint. NOTE The number of positions coded in the name-range parameter is significant: the name-range // will result in the formatting of only those components whose name is two letters or fewer. In most cases, you will wish to specify all positions in the name when when you code the name-range. ‘When the value specified for the name-range is shorter than the length of the name, the name-range is padded with spaces at the end. ‘When the value specified for the name-range is longer than the length of the name, it is considered an error. You can request specific processing by coding a name-range with no slashes. This will format only that component, if any, whose name exactly matches the name-range value. For example, if you code the value ABCDEF for name-range, only a component called ABCDEF would be formatted; a component with with the name ABCDEFGH would not be formatted. The following action cards are recognized by OXFORMAT. The value of the name-range must be from 1 to 8 characters in length, except where noted. PANEL=name-range This card causes the specified PAINT Panel(s) to be format- ted. VIEW=name-range ‘This card causes the specified CAT View(s) to be formatted. The Component Format Utility: 43Release 3.0 December, 1987 ACB=name-range DDS=name-range, DSD=name-range, 44 OsPUG1287 This card causes the specified UFO/Forms Application Con- trol Block(s), along with any continuations, to be formatted. This card causes the specified UFO/Forms Display Defini- tion(s), along with any continuations, to be formatted. For this card, can have the following values: blank (the default value): This option causes the specified UFO/Forms Display Definition(s), with all continuations, to be formatted. NOCONT: This option causes the specified UFO/Forms Dis- play Definition(s), without any continuations, to be for- matted. This card causes the specified UFO/Forms Data Structure Definition(s) to be formatted. For this card, can have the following values: blank (the default value): This option causes the fields to be sorted in alphabetical order by field name within a DSD. SORT: This option causes the fields to be sorted in order of starting position, within a DSD, only if an alternate index has been built for this file. This card causes the specified UFO/Forms DDX(s) to be for- matted. ‘This card causes the specified UFO/Forms FLV record(s) to be formatted. This card causes the specified UFO/Forms HELP record(s) to be formatted. This card causes the specified UFO/Forms Menu(s) to be for- matted. Operational Support Package User GuideOSPUG1287 PDS=name-range, RUN=name-range 4.1.3 Control Card Examples Release 3.0 December, 1987 This card causes the specified UFO/Forms Procedure(s), along with any continuations, to be formatted. For this card, can have the following values: blank (the default value): This option causes the specified UFO/Forms Procedure, with all continuations, to be for- matted. NOCONT: This option causes the specified UFO/Forms Procedure, without any continuations, to be formatted. This card causes the specified UFO/Forms Run-Time Requesi(s) to be formatted. The name-range for the RUN card consists of a 3-character operator ID and an S-character name. This cad causes a directory of the specified UFO/Forms Compiled Componentis) to be produced. The name-range consists of an 8-character component name, followed by a 1- to 4-character component type. Valid component types are: ACB DDx DsD DDS PDS Figure 3.1 illustrates the control cards you would need to include in a jobstream to format a PAINT panel and an associated CAT LIBRARY=PNTIOX PANEL=PANEL1 LIBRARY=CATIOX VIEW=VIEWL view in the data spaces identified by the LIBRARY cards. Figure 3.1 OXFORMAT Control Cand The Component Format Utility Example 1 45Release 3.0 December, 1987 OSPUG1287 Figure 4.1 illustrates the control cards you would need to include in a jobstream to format all PAINT panels from "UFO _' to 'UFO999", and all CAT views from "UFO ’ to 'UFO999", inclu- sive, that reside in the UFOIOX data space. LIBRARY=UFOIOX PANEL=UFO/// VIEW=UFO/// Figure 4.1 OXFORMAT Control Card Example 2 Figure 4.2 illustrates the control cards you would need to include in a jobstream to format the ACB UFOACBI on the data space UFOIOX. LIBRARY=UFOIOX ACB=UFOACB1 Figure 42 OXFORMAT Control Card Example 3 Figure 4.3 illustrates the control cards you would need to include in a jobstream to format the ACB UFOACB? on the data space UFOIOX. In addition, these cards specify formatting for the DDS UFOSAMP?, every DSD from ’S_ UFO’ to ‘S9999UFO’, and every DDX on the UFOIOX data space. LIBRARY=UFOIOX OXFORMAT Control Card Example 4 46 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 4.2 Passing Parameters To OXFORMAT ‘You can pass parameter data, via the JCL, to control error processing and/or establish initial val- ues for certain global control cards. These initial control card values are overridden by any actual control cards you might have coded, however. The following parameter values can be coded: ALLOW=nn This parameter sets the maximum allowable error severity level that OXFORMAT will tolerate without terminating a job. The values for nn can be: ©: Any error will cause the job to be terminated. 4: The specified component was not found. This is the default value. In cases where generic processing was specified by coding slashes, this value indicates that no component satisfied the processing specifications. No errors will terminate the job. ‘See the discussion of the LIBRARY = global control card in “Section 4.1.1" for details. SYSTRACE ‘This parameter is used as an aid in debugging. It causes internal OXFORMAT functions to be entered in the trace table that is printed along with OXFORMAT dumps. The following discussion of JCL considerations by environment contains subsections dealing with the methods of passing parameter data to OXFORMAT. 4.3 JCL Considerations In order that OXFORMAT run correctly in OS, DOS, or CMS, you must tailor JCL (for OS and DOS) or issue the appropriate commands (CMS or TSO). ‘The Component Format Utility 47Release 3.0 December, 1987 osPUuGi287 4.3.1 Running OXFORMAT In A CMS Environment Before you can execute the Format Utility under CMS, you must issue FILEDEF commands for the following files: SYSIN This file will contain all OXFORMAT control cards. You can assign SYSIN to a reader, a terminal, or a CMS disk file. If a disk file is used, it must consist of fixed-length 80-byte records. By default, SYSIN will be assigned to a file named SYSIN FILE A. SYSPRINT This file will receive the formatted print output. You can assign SYSPRINT to a printer, a terminal, or a CMS disk file. SYSLST _This file will receive any abend dumps that may be produced, as well as any IOX messages issued. You can assign SYSLST to a printer, a terminal, or CMS disk file. By default, SYSLST will be assigned to a file named FILE SYSLST A. To invoke the format utility, issue the following CMS command: OXFORMAT NOTE You can also run this utility interactively from the CICS Simulation Utility if you assign SYSIN and SYSPRINT to TERM. In CMS, simply issue the following FILEDEFS: FILEDEF SYSIN TERM FILEDEF SYSPRINT TERM 4.3.1.1 Passing Parameters To OXFORMAT You can pass parameter data to OXFORMAT in a CMS environment as options on the CMS com- mand line. (CMS options consist of any data that follows the first left parenthesis on the com- mand line.) When you run OXFORMAT from within the CICS Simulation Utility, you pass parameters on the initial screen input, as below: OXFORMAT ALLOW=8 48 Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 4.3.2 Running OXFORMAT In A DOS Environment Before you can execute the Format Utility under DOS, you must assign the following files: SYSIPT _This file will contain all OKFORMAT control cards. SYSLST This file will receive the formatted print output, as well as any abend dumps or TOX messages that may be produced. In addition, you must code a DLBL/EXTENT card for the files contained in any IOX data spaces referenced in the job. To invoke the format utility, code the following statement: // EXEC OXFORMAT 4.3.2.1 Passing Parameters To OKFORMAT You can pass parameter data to OXFORMAT in a DOS environment via the SYSPARM parame- ter on the OPTION card in the JCL. However, SYSPARM allows a maximum of 8 bytes of data, to be passed. If you desire to pass more than 8 bytes of parameter data to OXFORMAT and if your shop runs VSEISP release 1.3 or higher, you can use the PARM parameter on the EXEC card to pass parameter data. If you use both SYSPARM and PARM, the values you pass on the PARM parameter of the EXEC card will override the SYSPARM values. ‘The Component Format Utility 49Release 3.0 December, 1987 OSPUG1287 4.3.3 Running OXFORMAT In An OS Environment Before you can execute the Format Utility under OS, you must code DD statements for the follow- ing files: SYSIN This file will contain all OXFORMAT control cards. SYSPRINT This file will receive the formatted print output. SYSLST This file will receive any abend dumps that may be produced, as well as any IOX error messages issued. In addition, you must code DD statements for the files contained in any IOX data spaces refer- enced in the job. To invoke the format utility, code the following statement: // EXEC PGM=OXFORMAT 4.3.3.1 Passing Parameters To OXFORMAT You can pass parameter data to OXFORMAT in an OS environment via the PARM parameter of the EXEC card in the JCL. 4.10 Operational Support Package User GuideospuGi287 Release 3.0 December, 1987 4.3.4 Running OXFORMAT In A TSO Environment Before you can execute the Format Utility under TSO, you must issue ALLOCATE commands for the following files: SYSIN This file will contain all OXFORMAT control cards. You can assign SYSIN to a reader, a terminal, or a disk file. If a disk file is used, it must consist of fixed- length 80-byte records. SYSPRINT This file will receive the formatted print output. You can assign SYSPRINT to a printer, a terminal, or a disk file. SYSLST —_This file will receive any abend dumps that may be produced, as well as any IOX messages issued. You can assign SYSLST to a printer, a terminal, or a disk file. To invoke the format utility, issue the following TSO command: CALL 'loadlibname(OXFORMAT)' where loadlibname is the name of the loadlib determined during DTR installation. NOTE You can also run this utility interactively from the CICS Simulation Utility if you assign SYSIN and SYSPRINT to TERM. In TSO, simply issue the following ALLOCATE commands: ALLOCATE FILE (SYSIN) DATASET (*) ALLOCATE FILE (SYSPRINT) DATASET (*) 4.3.4.1 Passing Parameters To OXFORMAT You can pass parameter data to OXFORMAT in a TSO environment via the CALL command. When you run OXFORMAT from within the CICS Simulation Utility, you pass parameters on the initial screen input, as below: OXFORMAT ALLOW=8 ‘The Component Format Utility 4atRelease 3.0 December, 1987 OSPUG1287 4.12 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 SECTION 5. THE EXPORT/IMPORT UTILITIES ‘The Component Export and Import Utilities (ONEXPORT and OXIMPORT) are batch programs that allow users to move components from one file to another. These utilities can be run in either LOCAL or REMOTE mode. You select between these modes by specifying a format of the OPTION= global control card, discussed in "Section 5.1.1". OPTION=LOCAL: Specifies LOCAL mode. This control card allows you to accomplish the exportimport task in one step, within the same CPU. OPTION=REMOTE: Specifies REMOTE mode. This control card requires that these util- ities be run together as paired utilities. Information specified in the export jobstream controls the subsequent import job. The export routine punches 80-byte card images to an intermediate file, which later provides input to the import job. ‘The import job accepts no control cards. All decisions (e.g., the target destination and Processing options) are decided at export time. The benefit of running OXEXPORT and OXIMPORT in REMOTE mode is that you can export components between CPUs and/or operating environments. Each utility produces an audit trail upon completion. When the export/import jobs are accom- plished in one step, only one audit trail is produced. Input to OXEXPORT consists of two types of control cards: Global Cards: are used to set processing options. These options remain in effect until changed by another global card, or until end of job. ‘Action Cards: are used to specify the specific component(s) to be exported. Each action card is Processed in order, and has no effect on subsequent processing. The Export/Import Utilities 5.1Release 3.0 December, 1987 OSPUG1287 5.1 Control Card Syntax Each OXEXPORT control card consists of a keyword identifying the control card type and at least one parameter. Control card syntax rules are: > The keyword must be coded beginning in column 1 on the input card. » The keyword is always followed immediately by an equal sign. Parameter values must be coded beginning in the position immediately following the equal sign. > Parameters are delimited by commas, when more than one parameter is required for a con- trol card. = Parameters containing embedded blanks must be delimited by apostrophes. > Parameter data may continue to column 71 on the input card. 5.1.1 Global Cards The following global cards are recognized by OXEXPORT: LIBRARY =data-space-nameffilename, VSAM. ‘This card specifies the source of the components to be exported. LIBRARY=data-space-name specifies the IOX data space in which the components to be exported reside. You can code LIBRARY cards at any point in the job stream, but OXEXPORT considers only the most recent LIBRARY as current. If you do not code a valid LIBRARY card before attempting to export a component, an error message will be issued and the current action will be terminated. LIBRARY=filename,VSAM is an option for compiled com- ponents that reside in a VSAM file. These components ‘must be further identified by the appropriate action card(s) for compiled components, as discussed in "Section 5.1.2", 5.2 Operational Support Package User GuideOSPUG1287 AUDIT=BRIEF/EXTENDED The Export/Import Utilities Release 3.0 December, 1987 This card specifies the destination to which exported compo- nents will be written. You need not code a TARGET card if you specify the OPTION=LISTONLY card described below. TARGET =data-space-name specifies the name of the data space where the subsequent import job will put the compo- nents punched as the export job output. TARGET =file-name,VSAM is an option for compiled compo- nents that reside in a VSAM file. These components must be further identified by the appropriate action card(s) for compiled components, as discussed in "Section 5.1.2". This card enables you to optionally print a listing of the exported components. AUDIT=BRIEF indicates that only the names of the export- ‘ed components are printed. (In the case of VIEW or DSD components, only the names of the VIEW or DSD are print- ed.) AUDIT=BRIEF is the default value. AUDIT=EXTENDED indicates that in the case of VIEW or DSD components, the names of the VIEW orDSD and the ‘names of all all constituent fields are printed. 5.3Release 3.0 December, 1987 OPTION=CREATE|NOCREATE 54 OsPUG1287 JREMOTE|LISTONLY This card specifies how the job operates within the data space identified by the TARGET card. Each of the three lines of possible values is a mutually exclusive set. If you code more than one value from any set, the last value coded will be recognized by OXEXPORT. You can, however, code a combination of any one value from each of the three sets, separating each value by commas. OPTION=LOCAL specifies that all exported components are immediately imported during the execution of the OXEXPORT jobstream. No subsequent OXIMPORT job is required. This is the default value for the first set of OPTION= cards (OPTION =LOCAL|REMOTE|LISTONLY). OPTION=REMOTE specifies that all exported components are immediately written to a PUNCH file. This PUNCH file must then be used as input to a subsequent OXIMPORT job to write the components to the destination identified by the TARGET = card. OPTION=LISTONLY specifies that nothing is written, either immediately or subsequently, to an intermediate file. The OPTION=LISTONLY card produces only an audit trail, and can be useful to determine the constituent compo- nents of any data space prior to running OXEXPORT. It requires neither a TARGET= card, nor a subsequent OXIMPORT job. OPTION=MERGE specifies that if the component exists on the TARGET destination, it will not be replaced by the ‘exported component. This is the default value for the second set of OPTION= cards (OPTION = MERGE|PURGE). OPTION=PURGE specifies that if the component exists on the TARGET destination, it will be deleted and replaced by the exported component. OPTION=CREATE specifies that if the IOX file in which the exported component is to reside does not exist on the TARGET destination, it will be created. OPTION=NOCREATE specifies that if the IOX file in which the exported component is to reside does not exist on the TARGET destination, an [OX error will be generated. Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 This is the default value for the third set of OPTION= cards (OPTION = CREATE|NOCREATE). 5.1.2 Action Cards The first (or only) parameter on all action cards is name-range. A name-range may be specific or generic. NOTE ‘The JCL= action card is an exception. Its first and only parameter is the JCL that you code, and it is the only action card that does not allow a name-range. ‘You can request generic processing by coding a slash (/) in place of one or more characters in the name-range parameter. The slash means that any character can occupy this position in the key. > For example, the name-range ABCI/il/ represents all keys that begin with ABC. = The name range //DEFI/ represents all keys that contain DEF in the third, fourth and fifth positions. » The entire range of keys for a component can be requested by coding the name-range /I/!l. NOTE ‘The number of positions coded in the name-range parameter is significant: the ‘name-range // will result in the export of only those components whose key is two letters or fewer. In most cases, you will wish to specify all positions in the key ‘when coding the name-range. When the value specified for the name-range is shorter than the length of the key, the name-range is padded with spaces at the end. When the value specified for the name-range is longer than the length of the key, it is considered an error. ‘You can request specific processing by coding a name-range with no slashes. This will export only that component, if any, whose key exactly matches the name-range value. » For example, if you code the value ABCDEF for name-range, only a component called ABCDEF would be exported; a component with the name ABCDEFGH would not be export- ed. ‘The Export/Import Utilities 5.5Release 3.0 December, 1987 OsPUG1287 The following action cards are recognized by OXEXPORT. The value of the name-range must be from 1 to 8 characters in length, except where noted. DDS=name-range, DSD=name-range, 5.6 This card causes the specified PAINT Panel(s) to be export- ed. ‘This card causes the specified CAT View(s) to be exported, This card causes the specified UFO/Forms Application Con- trol Block(s), along with any continuations, to be exported. For this cerd, can have the following values: blank (the default value): This option causes all elements associaced with this ACB (e.g., DDX, PDS, and DDS/PANEL) to be exported with the ACB. NOEXP: This option causes only the specified ACB, without any expansions, (DDS, DDX, PDS, DSD, FLV) to be exported (written to the intermediate file). This card causes the specified UFO/Forms Display Defini- tion(s), along with any continuations, to be exported. For this card, can have the following values: blank (the default value): This option causes the specified UFO/Forms Display Definitions), with all continuations, to be exported (written to the intermediate file). NOCONT: This option causes the specified UFO/Forms Dis- play Definition(s), without any continuations, to be exported (written to the intermediate file). This card causes the specified UFO/Forms File Definition(s) to be exported. For this card, can have the following values: blank (the default value): This option causes the fields to be sorted in alphabetical order by field name within a DSD. NOFLV: This option inhibits the export of any FLV entries associated with the DSD. Operational Support Package User GuideOsPUG1287 DDX=name-range - HELP=name-range MENU=name-range PDS=name-range, RUN=name-range OACB=name-range ODDS=name-range ODSD=name-range The Export/Import Utilities Release 3.0 December, 1987 This card causes the specified UFO/Forms DDX(s) to be exported. This card causes the specified UFO/Forms HELP record(s) to be exported. This card causes the specified UFO/Forms Menu(s) to be exported. This card causes the specified UFO/Forms Procedure(s), along with any continuations, to be exported. For this card, can have the following values: blank (the default value): This option causes the specified UFO/Forms Procedure, with all continuations, to be exported. NOCONT: This option causes the specified UFO/Forms Procedure, without any continuations, to be exported. ‘This card causes the specified UFO/Forms Run-Time Request(s) to be exported. The name-range for the RUN card can be from 3 to 11 characters in length. Although the actual name of the RUN is 8 characters, it must be preceded by the operator-ID of the person who cre- ated the run. In order to export the correct run, you must code this 3-character operator-ID as the first 3 characters in your name-range. If you are unsure as to what those characters should be, execute OXEXPORT with the LISTONLY option, and code your RUN= card with the first 3 name-range positions rep- resented by slashes (), followed by the name of the run you wish to export. The resultant audit listing will specify exactly the run(s) you need to export. This card causes the specified UFO/Forms Compiled ACB to be exported. This card causes the specified UFO/Forms Compiled DDS to be exported. This card causes the specified UFO/Forms Compiled DSD to be exported. 5.7Release 3.0 December, 1987 ODDX=name-range 58 OsPUG1287 This card causes the specified UFO/Forms Compiled DDX to be exported, This card causes the specified UFO/Forms Compiled PDS to be exported, This card causes the specified UFO/4GL Compiled PANEL to be exported. This card causes the specified UFO/4GL Compiled VIEW to be exported, This card causes the specified UFO/4GL Compiled PROGRAM to be exported. This optional card allows you to wrap JCL around the Punched 80-byte output. You can code a JCL= card at any point in the job stream. The JCL data on the JCL= card must be delimited by single ‘quotes when it contains embedded blanks. You can code a single quote within the JCL data, as long as it is not fol- lowed by a blank. The sequence “quote + blank" is inter- preted as a terminal delimiter. The JCL data is never printed, but written to the SYSPCH file as is. NOTE Any JCL= cards are ignored when you spec- ify OPTION=LISTONLY. Operational Support Package User GuideOsPUGi287 Release 3.0 December, 1987 5.1.3 Control Card Examples Figure 5.1 illustrates the control cards you would need to include in a jobstream to initiate a one- step exportiimport. These cards specify that all panels residing in the data space PNTIOX, and whose names begin with PANEL, are to be written to the IOX data space TSTIOX. The OPTION card indicates that if the component (in this case, the panel) already exists in TSTIOX, it will be overwritten. (Also, because the OPTION card specifies CREATE, in the event that the Paint file on TSTIOX does not exist, it will be created.) Because the OPTION card specifies LOCAL, this Job creates no punched output, and thus necessitates no subsequent import utility job. LIBRARY=PNTIOX TARGET=TSTIOX OPTION=LOCAL , PURGE, CREATE PANEL=PANEL/// Figure 5.1 OXEXPORT and OXIMPORT Control Card Example 1 Figure 5.2 illustrates the control cards you would need to include in a jobstream to initiate a job that creates an audit trail of the CAT views residing in the data space CATIOX, with names beginning with VIEWA. LIBRARY=CATIOX VIEW=VIEWA/ OPTION=LISTONLY Figure52 — OXEXPORT and OXIMPORT Control Card Example 2 Figure 5.3 illustrates the control cards you would need to include in a jobstream to export from the data space PNTIOX all panels whose names begin with PANEL. This job results in 80-byte card image output being punched to the intermediate file, which the subsequent import job will attempt to write to the data space TSTIOX. The OPTION card indicates that if the component (in this case, the panel) does not already exist in TSTIOX, it will be written. If the component does already exist, it will not be overwritten. In the event that the Paint file does not already exist on TSTIOX, it will not be created. LIBRARY=PNTIOX TARGET=TSTIOX OPTION=MERGE PANEL=PANEL/// Figure 5.3. OXEXPORT Control Card Example 3 The ExportImport Utilities 5.9Release 3.0 December, 1987 osPuGi287 5.2 Passing Parameters You can pass parameter data, via the JCL, to control error processing and/or establish initial val- ues for certain global control cards. These initial control card values are overridden by any actual control cards you might have coded, however. ‘The discussion of JCL considerations by environment ("Section 5.3") contains subsections dealing with the methods of passing parameter data to OXEXPORT and OXIMPORT. 5.2.1 Passing Parameters To OKEXPORT ‘You can pass the following parameter values to OXEXPORT: ALLOW=nn This parameter sets the maximum allowable error severity level that OXEXPORT will tolerate without terminating a job. The values for nn can be: ©: Any error will cause the job to be terminated, 4: The specified component was not found. This is the default value. In cases where generic processing was specified by coding slashes, this value indicates that no component satisfied the processing specifications. & No errors will terminate the job, LIBRARY =libname ‘See the discussion of the LIBRARY = global control card in "Section 5.1.1" for details. TARGET=libname See the discussion of the TARGET = global control card in “Section 5.1.1" for details. OPTION=LOCAUJREMOTEJLISTONLY OPTION=MERGE|PURGE See the discussion of the OPTION= global control card in "Section 5.1.1" for details. AUDIT=BRIEFIEXTENDED See the discussion of the AUDIT= global control card in "Section 5.1.1" for details. SYSTRACE This parameter is used as an aid in debugging. It causes internal OXEXPORT functions to be entered in the trace table that is printed along with OXEXPORT dumps. 5.10 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 5.2.2 Passing Parameters To OXIMPORT. ‘You can pass the following parameter values to OXIMPORT: ALLOW=nn SYSTRACE 5.3 JCL Considerations ‘This parameter sets the maximum allowable error severity level that OXEXPORT will tolerate without terminating a job. The values for nn can be: 0: Any error will cause the job to be terminated. 4: One or more components that were exported with OPTION MERGE were found already to exist on the TARGET data space, and so were not imported. & No errors will terminate the job. ‘This parameter is used as an aid in debugging. It causes internal OXIMPORT functions to be entered in the trace table that is printed along with OXIMPORT dumps. In order that OXEXPORT and OXIMPORT run correctly in OS, DOS, or CMS, you must tailor ICL (for OS and DOS) or issue the appropriate commands (CMS or TSO). The following subsections discuss each job individually with respect to the different environments in which they can be run. The Export/Import UtilitiesRelease 3.0 December, 1987 ospuGi287 5.3.1 Running OXEXPORT In A CMS Environment Before you can execute OXEXPORT under CMS, you must issue FILEDEF commands for the fol- lowing files: SYSIN This file will contain all OXEXPORT control cards. You can assign SYSIN to a reader, a terminal, or a CMS disk file. If a disk file is used, it must consist of fixed-length 80-byte records. SYSPRINT This fle will receive the exported print output. You can assign SYSPRINT to a printer, a terminal, or a CMS disk file. file will receive any abend dumps that may be produced, as well as any 1OX messages issued. You can assigr. SYSLST to a printer, a terminal, or CMS disk file. By default, SYSLST will be assigned to a file named FILE SYSLST A. SYSPCH This file will receive formatted 80-byte punched output. To invoke OXEXPORT, issue the following CMS command: OXEXPORT NOTE You can also run this utility interactively from the CICS Simulation Utility if you assign SYSIN and SYSPRINT to TERM. In CMS, simply issue the following FILEDEFS: FILEDEF SYSIN TERM PILEDEF SYSPRINT TERM Since OXEXPORT is not one of the predefined transactions for LLXXCICS (the CICS Simulation Utility), you need to code a LLOSSP ->TRANSACTION control card in the SYSIPT file to identify to LLXXCICS both the transaction ID and the Program it invokes. (You also need to issue a FILEDEF for SYSIPT.) Code the LLOSSP ->TRANSACTION card as follows, beginning in Column 1: 5.12 Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 5.3.1.1 Passing Parameters To OXEXPORT You can pass parameter data to OXEXPORT in a CMS environment as options on the CMS com- mand line. (CMS options consist of any data that follows the first left parenthesis on the com- mand line.) When you run OXEXPORT from within the CICS Simulation Utility, you pass parameters on the initial screen input, as below: OXEXPORT ALLOW=8 5.3.2 Running OXIMPORT In A CMS Environment Before you can execute OXIMPORT under CMS, you must issue FILEDEF commands for the fol- lowing files: SYSIN This file will contain the 80-byte fixed-length records produced as formatted Punched output from the OXEXPORT jb. SYSPRINT This file will receive the imported print output. You can assign SYSPRINT to a printer, a terminal, or a CMS disk file. SYSLST _This file will receive any abend dumps that may be produced, as well as any [OX messages issued. You can assign SYSLST to a printer, a terminal, or CMS disk file. By default, SYSLST will be assigned to a file named FILE SYSLST A. To invoke OXIMPORT, issue the following CMS command: OXIMPORT : 5.3.2.1 Passing Parameters To OXIMPORT You can pass parameter data to OXIMPORT in a CMS environment as options on the CMS com- mand line. (CMS options consist of any data that follows the first left parenthesis on the com- ‘mand line.) When you run OXIMPORT from within the CICS Simulation Utility, you pass parameters on the initial sereen input, as below: OXIMPORT ALLOW=8 ‘The Export/import Utilities 5.13Release 3.0 December. 1987 OSPUG1287 5.3.3 Running OXEXPORT In A DOS Environment Before you can execute OXEXPORT under DOS, you must assign the following files: SYSIPT —_This file will contain all OXEXPORT control cards. SYSLST _This file will receive the exported print output, as well as any abend dumps or IOX messages that may be produced SYSPCH This file will receive formatted 80-byte punched output. In addition, you must code a DLBL/EXTENT card for the files contained in any IOX data spaces referenced in the job. To invoke OXEXPORT, code the following statement: // EXEC OXEXPORT 5.3.3.1 Passing Parameters To OXEXPORT You can pass parameter data to ONEXPORT in a DOS environment via the SYSPARM parame- ter on the OPTION card in the JCL. However, SYSPARM allows a maximum of 8 bytes of data to be passed. If you desire to pass more than 8 bytes of parameter data to OXEXPORT and if your shop runs VSEISP release 1.3 or higher, you can use the PARM parameter on the EXEC card to pass parameter data. If you use both SYSPARM and PARM, the values you pass on the PARM parameter of the EXEC card will override the SYSPARM values. 5.14 . Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 5.3.3.2 OXEXPORT: DOS To CMS For VM Users Users in installations that run DOS as a guest cperating system under VM may encounter a uunique set of circumstances when using OXEXPORT. If, in this situation, you export a compo- nent to your CMS reader via a PUNCH class, you may get an extra blank line at the end of your OXEXPORT SYSPCH output. This will cause an error when you attempt to run OXIMPORT against this file. One way to circumvent this problem is to: + receive the file to your CMS mini-disk » _ XEDIT the file and delete the blank line at the end » run OXIMPORT, using the CMS file as your input (SYSIN) A better solution is to request that your system programmer define the virtual punch in the DOS machine as a device type of 2520B2 (VSE/SP users may also require the operand "EML’). If you do this, you can import directly from your reader by issuing the following: FILEDEF SYSIN READER 5.3.4 Running OXIMPORT In A DOS Environment Before you can execute OXIMPORT under DOS, you must assign the following files: SYSIPT —_—_This file will contain the 80-byte card images produced by the OXEXPORT job. SYSLST —_This file will receive the imported print output, as well as any abend dumps or [OX messages that may be produced. In addition, you must code a DLBL/EXTENT card for the files contained in any IOX data spaces referenced in the job. To invoke OXIMPORT, code the following statement: // EXEC OXIMPORT ‘The Expor/Import Utilities 5.18Release 3.0 December, 1987 OSPUG1287 5.3.4.1 Passing Parameters To OXIMPORT You can pass parameter data to OXIMPORT in a DOS environment via the SYSPARM parame- ter on the OPTION card in the JCL. However, SYSPARM allows a maximum of 8 bytes of data to be passed. If you desire to pass more than 8 bytes of parameter data to OXIMPORT and if your shop runs VSEISP release 1.3 or higher, you can use the PARM parameter on the EXEC card to pass parameter data. If you use both SYSPARM and PARM, the values you pass on the PARM parameter of the EXEC card will override the SYSPARM values. 5.3.5 Running OXEXPORT In An OS Environment Before you can execute OXEXPORT under OS, you must code DD statements for the following files: SYSIN This file will contain all OXEXPORT control cards. SYSPRINT This file will receive the exported frint output. SYSLST This file will receive any abend dumps that may be produced, as well as any IOX error messages issued. SYSPCH This file will receive formatted 80-byte punched output. In addition, you must code DD statements for the files contained in any IOX data spaces refer- enced in the job. To invoke OXEXPORT, code the following statement: // EXEC PGM=OXEXPORT 5.3.5.1 Passing Parameters To OXEXPORT You can pass parameter data to OXEXPORT in an OS environment via the PARM parameter of the EXEC card in the JCL. 5.16 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 5.3.6 Running OXIMPORT In An OS Environment Before you can execute OXIMPORT under OS, you must code DD statements for the following files: SYSIN ‘This file will contain the 80-byte card images produced by the OXEXPORT job. SYSPRINT This file will receive the imported print output. SYSLST —_This file will receive any abend dumps that may be produced, as well as any IOX error messages issued. In addition, you must code DD statements for the files contained in any IOX data spaces refer- ‘enced in the job. To invoke OXIMPORT, code the following statement: 5.3.6.1 Passing Parameters To OXIMPORT ‘You can pass parameter data to OXIMPORT in an OS environment via the PARM parameter of the EXEC card in the JCL. ‘The Export/Import Utilities 5.17Release 3.0 December, 1987 5.3.7 Before OSPUG1287 Running OXEXPORT In A TSO Environment you can execute OXEXPORT under TSO, you must issue ALLOCATE commands for the following files: SYSIN This file will contain all OXEXPORT control cards. You can assign SYSIN to a reader, a terminal, or a disk file. Ifa disk file is used, it must consist of fixed- length 80-byte recor SYSPRINT This file will receive the exported print output. You can assign SYSPRINT to a printer, a terminal, or a disk file. SYSLST This file will receive any abend dumps that may be produced, as well as any IOX messages issued. You can assign SYSLST to a printer, a terminal, or a disk file. SYSPCH This file will receive formatted 80-byte punched output. To invoke OXEXPORT, code the following statement: CALL 'loadlibname(OXEXPORT) ' where loadlibname is the name of the loadlib determined during DTR installation. NOTE You can also run this utility interactively from the CICS Simulation Utility if you assign SYSIN and SYSPRINT to TERM. In TSO, simply issue the following ALLOCATE commands: ALLOCATE FILE (SYSIN) DATASET (*) ALLOCATE FILE (SYSPRINT) DATASET (*) ‘Since OXEXPORT is not one of the predefined transactions for LLXXCICS (the CICS Simulation Utility), you need to code a LLOSSP -> TRANSACTION control card in the SYSIPT file to identify to LLXXCICS both the transaction ID and the program it invokes. (You also need to issue an ALLOCATE command for SYSIPT.) Code the LLOSSP -> TRANSACTION card as follows, beginning in Col- umn 1: ~>TRANSACTION=OXEXPORT , LLASEP30 5.18 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 5.3.7.1 Passing Parameters To OKEXPORT You can pass parameter data to OXEXPORT in a TSO environment via the CALL command. When you run OXEXPORT from within the CICS Simulation Utility, you pass parameters on the initial screen input, as below: OXEXPORT ALLOW=! 5.3.8 Running OXIMPORT In A TSO Environment Before you can execute OXIMPORT under TSO, you must issue ALLOCATE commands for the following files: SYSIN This file will contain the 80-byte card images produced by the OXEXPORT job. You can assign SYSIN to a reader, a terminal, or a disk file. If a disk file is used, it must consist of fixed-length 80-byte records. SYSPRINT This file will receive the imported print output. You can assign SYSPRINT to a printer, a terminal, or a disk file, SYSLST This file will receive any abend dumps that may be produced, as well as any [OX messages issued. You can assign SYSLST to a printer, a terminal, or a disk file. To invoke OXIMPORT, code the following statement: CALL 'loadlibname(OXIMPORT)' where loadlibname is the name of the loadlib determined during DTR installation. 5.3.8.1 Passing Parameters To OXIMPORT ‘You can pass parameter data to OXIMPORT in a TSO environment via the CALL command. When you run OXIMPORT from within the CICS Simulation Utility, you pass parameters on the initial sereen input, as below: OXIMPORT ALLOW=8 The Export/Import Utilities 5.19Release 3.0 December, 1987 OSPUG1287 5.20 * Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 SECTION 6. THE SOURCE LIBRARY UTILITY ‘The Source Library Utility (OXBOOK) is a batch program that converts CAT views into COBOL copybooks, written in standard ANSI COBOL format. You can also use OXBOOK to process source modules, created with the UFO Productivity System UFO/4GL facility, that have been stored as OTM members. OXBOOK punches (and, optionally, allows the user to print) the output, which is suitable for placement in source-statement libraries (DOS) or maclibs (OS and CMS). Input to OXBOOK consists of two types of control cards: Global Cards: are used to set processing options. These options remain in effect until changed by another global card, or until end of job. Action Cards: are used to specify the specific component(s) to be converted. Each action card is processed in order, and has no effect on subsequent processing. 6.1 Control Card Syntax Each OXBOOK control card consists of a keyword identifying the control card type and at least one parameter. Control card syntax rules are: + The keyword must be coded beginning in column 1 on the input card. + The keyword is always followed immediately by an equal sign. Parameter values must be coded beginning in the position immediately following the equal sign. > Parameters containing embedded blanks must be delimited by apostrophes. Parameter data may continue through column 71 on the input card. The Source Library Utility 61Release 3.0 December, 1987 6.1.1 Global Cards OSPUG1287 ‘The following global cards are recognized by OXBOOK: LIBRARY =data-space-name AUDIT=BRIEF/EXTENDED 6.2 This card specifies the IOX data space in which the compo- nent to be converted resides. You can code LIBRARY cards at any point in the job stream, but OXBOOK considers only the most recent LIBRARY as current. If you do not code a valid LIBRARY card before attempting to convert a compo- nent, an error message will be issued and the current action will be terminated. ‘This card enables you to optionally print the converted com- ponents in copybook format. AUDIT=BRIEF indicates that only the names of the con- verted components are printed. AUDIT=BRIEF is the default value. AUDIT=EXTENDED indicates that a listing of the COBOL ‘copybooks converted during the run is produced. Regardless of which option is selected, the utility always Punches the copybooks that are produced. Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 PROLOGn="prolog’ This optional card allows you to specify data to be written to the SYSPCH file before each view or member processed within the run. You can code up to five (5) PROLOGa= cards, numbered PROLOG1=, PROLOG2=, ete. ‘The data on the PROLOGn card must be delimited by single quotes when it contains embedded blanks. You can code a ‘single quote within the prolog data, as long as it is not fol- lowed by a blank. The sequence “quote + blank” is inter- preted es a terminal delimiter. All PROLOGn= cards remain in effect until cancelled by a blank card. To cancel the third PROLOG card, simply code PROLOG3=' ' ‘As all PROLOG cards are sequential, cancelling one PROLOG card effectively cancels all those that follow it. Likewise, if you specify a PROLOG card (other than PROLOG1=) that has no predecessor, it will be ignored. OXBOOK allows you to substitute within the prolog data. If you wish, for example, to include the specific view-name or member-name within a PROLOGn= card, simply code ee The view-name or member-name being processed will be substituted for &&NAME exactly, with no leading or trail- ing blanks inserted into the prolog data. The Source Library Utility 63Release 3.0 December, 1987 EPILOGn="epilog’ 6.1.2 Action Cards OSPUG1287 This optional card allows you to specify data to be written to the SYSPCH file after each view or member processed with- in the run. You can code up to five (5) EPILOGn= cards, numbered EPILOG1=, EPILOG2=, etc. ‘The data on the EPILOGn card must be delimited by single quotes when it contains embedded blanks. You can code a single quote within the epilog data, as long as it is not fol- lowed by a blank. The sequence “quote + blank" is inter- preted as a terminal delimiter, All EPILOGn= cards remain in effect until cancelled by a blank card. To cancel the third EPILOG card, simply code EPILOG3=' ' As all EPILOG cards are sequential, cancelling one EPILOG card effectively cancels all those that follow it. Likewise, if you specify a EPILOG card (other than EPILOG1=) that hhas no predecessor, it will be ignored. OXBOOK allows you to substitute within the epilog data. If you wish, for example, to include the specific view-name or ‘member-name within a EPILOGn= card, simply code ‘The view-aame or member-name being processed will be substituted for &&NAME exactly, with no leading or trail- ing blanks inserted into the epilog data. The first (and only) parameter on all action cards is name-range. A name-range may be specific or generic, and cannot exceed eight characters in length. NOTE The JCL= action card is an exception. Its first and only parameter is the JCL that you code, and it is the only action card that does not allow a name-range. 64 Operational Support Package User GuideOsPuG1287 Release 3.0 December, 1987 You can request generic processing by coding a slash ( /) in place of one or more characters in the name-range parameter. The slash means that any character can occupy this position in the name. » For example, the name-range ABCIII/ represents all names that begin with ABC. » The name range /DEFI/ represents all names that contain DEF in the third, fourth and fifth positions. The entire range of names for a component can be requested by coding the name-range au. NOTE ‘The number of positions coded in the rame-range parameter is significant: the name-range // will result in the conversion of only those components whose name is two letters or fewer. In most cases, you will wish to specify all positions in the name when coding the name-range. When the value specified for name-range is shorter than the length of the name, the name-range is padded with spaces at the end. When the value specified for name-range is longer than the length of the name, it is considered an error. ‘You can request specific processing by coding a name-range with no slashes. This will convert only that component, if any, whose name exactly matches the name-range value. » For example, if you code the value ABCDEF for name-range, only a component called ABCDEF would be processed; a component with with the name ABCDEFGH would not be Processed. The following action cards are recognized by OXBOOK: VIEW =name-range This card causes the specified CAT view to be converted. You can code as many VIEW cards as you wish. When the OXBOOK job is completed, a message will be produced on SYSPRINT (or SYSLST for DOS users) indicating the number of views converted. If views were bypassed because they were in use and unaccessible to the OXBOOK job, they will not be included in the count message, even if they met the processing criteria for name-range. The Source Library Utility 65Release 3.0 December, 1987 MEMBER =name-range JCL="SCL’ 66 OSPUG1287 This card causes the specified OTM member to be processed. You can code as many MEMBER cards as you wish, When the OXBOOK job is completed, a message will be produced on SYSPRINT (or SYSLST for DOS users) indicating the number of members processed. If members were bypassed because they were in use and unaccessible to the OXBOOK job, they will not be includ- ‘ed in the count message, even * they met the processing criteria for name-range. NOTE Only members whose type is OPL4 will be processed by OXBOOK. This optional card allows you to wrap JCL around the punched ‘eopybook output. You can code a JCL= card at any point in the job stream, The JCL data on the JCL= card must be delimited by single quotes when it contains embedded blanks. You can code a single quote within the JCL data, as long as itis not followed by a blank. The sequence "quote + blank” is interpreted as a terminal delimiter. The JCL data is never printed, but written to the SYSPCH file as is. Operational Support Package User GuideosPuGi287 Release 3.0 December, 1987 6.1.3 Control Card Examples Figure 6.1 illustrates control cards you could code in the SYSIN file to be included in an OS job- stream. LIBRARY=OSPIOX PROLOGI='./ ADD NAME=64NAME, LIST=ALL" PROLOG2='./ | NUMBER NEW1=100, INCR=10' JCL="//YOURJOB JOB (9999, XXXXXXXXX, 12), 'USER NAME' , CLASS=G,MSGCLASS=A JCL='//YOURSTEP EXEC PGM=IEBUPDTE' JCL='//SYSPRINT DD SY¥SOU' JCi= //SYSUTL DD DSN=YOUR.COB.MACLIB, DIS! 7/SYSUT2 DD _DSN=YOUR.COB.MACLIB, DIS! Z/SYSIN DD ** VIEW=PROJ1/// VIEW=TESTAAAA JCL='./ ENDUP' Figure 6.1 Control Card Example: 0S Figure 6.2 illustrates control cards you could code in the SYSIN file to run OXBOOK under CMS. Control Card Example: CMS The Source Library Utility 67Release 3.0 December, 1987 OsPUG1287 Figure 6.3 illustrates control cards you could code in the SYSIPT file to be included in a DOS job- stream, LIBRARY=OSPIOX PROLOG1="' CATALS C.&&NAME,0.0' PROLOG2=' BKEND' EPILOGI=' BKEND' JCL='// JOB CATALS' JCL='// LIBDEF SL, TO=YOURSL' SCL='// EXEC MAINT! VIEW=PROJ1/// VIEW=TESTAAAA JCL=/* ICL=/& Figure 6.3 Control Card Example: DOS 68 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 6.2 Passing Parameters To OXBOOK You can pass parameter data, via the JCL, to control error processing and/or establish initial val- ues for certain global control cards. (These initial control card values are overridden by any actual control cards you might have coded, however.) The following parameter values can be coded: ALLOW=nn LIBRARY =data-space-name AUDIT=BRIEF|EXTENDED SYSTRACE ‘This parameter sets the maximum allowable error severity level that OXBOOK will tolerate without terminating a job. ‘The velues for nn can be: 0: Any error will cause the job to be terminated. The specified component was not found. This is the default value. In cases where generic processing was specified by coding slashes, this value indicates that no component satisfied the processing specifications. & Noerrors will terminate the job. See the discussion of the LIBRARY = global control card in "Section 6.1.1" for details. See the discussion of the AUDIT= global control card in "Section 6.1.1" for details. This parameter is used as an aid in debugging. It causes internal OXBOOK functions to be entered in the trace table that is printed along with OXBOOK dumps. ‘The following discussion of JCL considerations by environment contains subsections dealing with the methods of passing parameter data to OXBOOK. The Source Library Utility 6.9Release 3.0 December, 1987 OSPUG1287 6.3 JCL Considerations In order that the OXBOOK job run correctly in an OS, DOS, or CMS environment, you must tai- lor JCL (for OS and DOS) or issue the appropriate commands, as described below. 6.3.1 Running OXBOOK In A CMS Environment Before you can execute the OXBOOK Conversion Utility under CMS, you must issue FILEDEF ‘commands for the following files: SYSIN This file will contain all OXBOOK control cards. You can assign SYSIN to a read- er, a terminal, or a CMS disk file. If a disk file is used, it must consist of fixed- length 80-byte records. By default, SYSIN will be assigned to a file named SYSIN FILE A. SYSPRINT This file will receive the processed print output. You can assign SYSPRINT to a printer, a terminal, or a CMS disk file. SYSLST This file will receive any abend dumps that may be produced, as well as any IOX messages issued. You can assign SYSLST to a printer, a terminal, or CMS disk file. By default, SYSLST will be assigned to a file named FILE SYSLST A. SYSPCH This file will receive the processed punched output produced by OXBOOK. You can assign SYSPCH to a printer, a terminal, or a CMS disk file. If you intend to place the processed SYSPCH output in a CMS maclib, we suggest that you issue the following FILEDEF: FILEDEF SYSPCH DISK MYSYSPCH COPY A This allows you to add all the copybooks written to the SYSPCH file at the comple- tion of the OXBOOK job by entering the MACLIB command: MACLIB ADD MYMACLI3 MYSYSPCH To invoke the format utility, issue the following CMS command: ‘OXBOOK 6.10 Operational Support Package User GuideOsPUuGi287 Release 3.0 December, 1987 NOTE You can also run this utility interactively from the CICS Simulation Utility if you assign SYSIN and SYSPRINT to TERM. In CMS, simply issue the following FILEDEFs: FILEDEF SYSIN TERM FILEDEF SYSPRINT TERM ‘Since OXBOOK is not one of the predefined transactions for LLXXCICS (the CICS. Simulation Utility), you need to code a LLOSSP ->TRANSACTION control card in the SYSIPT file to identify to LLXXCICS both the transaction ID and the program. it invokes. (You also need to issue a FILEDEF for SYSIPT.) Code the LLOSSP -> TRANSACTION card as follows, beginning in Column 1: >TRANSACTION=OXBOOK , LLASBK30 6.3.1.1 Passing Parameters To OXBOOK, You can pass parameter data to OXBOOK in a CMS environment as options on the CMS com- mand line. (CMS options consist of any data that follows the first left parenthesis on the com- mand line.) When you run OXBOOK from within the CICS Simulation Utility, you pass parameters on the initial screen input, as below: OXBOOK ALLOW=8 ‘The Source Library Utility 6.1LRelease 3.0 December, 1987 OSPUG1287 6.3.2 Running OXBOOK In A DOS Environment Before you can execute the OXBOOK Conversion Utility under DOS, you must assign the follow- ing files: SYSIPT _This file will contain all OXBOOK control cards. SYSLST This file will receive the processed print output, as well as any abend dumps or IOX messages that may be produced. SYSPCH This file will receive the processed punch output produced by OKBOOK. In addition, you must code a DLBL/EXTENT card for the files contained in any IOX data spaces referenced in the job. To invoke the OXBOOK utility, code the following statement: //_ EXEC OXBOOK 6.3.2.1 Passing Parameters To OXBOOK ‘You can pass parameter data to OXBOOK in a DOS environment via the SYSPARM parameter on the OPTION card in the JCL. However, SYSPARM allows a maximum of 8 bytes of data to be passed. If you desire to pass more than 8 bytes of parameter data to OXBOOK and if your shop runs VSE/SP release 1.3 or higher, you can use the PARM parameter on the EXEC card to pass Parameter data. If you use both SYSPARM and PARM, the values you pass on the PARM Parameter of the EXEC card will override the SYSPARM values. 6.12 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 6.3.3 Running OXBOOK In An OS Environment Before you can execute the OXBOOK Conversion Utility under OS, you must code DD statements for the following files: SYSIN This file will contain all OXBOOK control cards. SYSPRINT This file will receive the processed print output, log messages, and statistics. SYSLST This file will receive any abend dumps that may be produced, as well as any IOX error messages issued. SYSPCH This file will receive the fixed-length 80-byte punched record output. In addition, you must code DD statements for the files contained in any IOX data spaces refer- enced in the job. To invoke the format utility, code the following statement: // EXEC PGM=OXBOOK 6.3.3.1 Passing Parameters To OXBOOK ‘You can pass parameter data to OXBOOK in an OS environment via the PARM parameter of the EXEC card in the JCL. 6.3.4 Running OXBOOK In A TSO Environment Before you can execute the OXBOOK Conversion Utility under TSO, you must issue ALLOCATE ‘commands for the following files: ‘SYSIN ‘This file will contain all OXBOOK control cards. You can assign SYSIN to a read- er, a terminal, or a disk file. If a disk file is used, it must consist of fixed-length 80-byte records. SYSPRINT This file will receive the processed print output. You can assign SYSPRINT to a printer, a terminal, or a disk file. SYSLST —_This file will receive any abend dumps that may be produced, as well as any IOX messages issued. You can assign SYSLST to a printer, a terminal, or disk file. SYSPCH This file will receive the processed punched output produced by OXBOOK. You can assign SYSPCH to a printer, a terminal, or a disk file. ‘The Source Library Utility 6.13Release 3.0 December, 1987 OsPUG1287 To invoke the format utility, issue the following TSO command: CALL 'loadlibname(OXBOOK) * where loadlibname is the name of the loadlib determined during DTR installation. NOTE You can also run this utility interactively from the CICS Simulation Utility if you assign SYSIN and SYSPRINT to TERM. In TSO, simply issue the following ALLOCATE commands: ALLOCATE FILE (SYSIN) DATASET (*) ALLOCATE FILE (SYSPRINT) DATASET (*) ‘Since OXBOOK is not one of the predefined transactions for LLXXCICS (the CICS Simulation Utility), you need to code a LLOSSP -> TRANSACTION control card in the SYSIPT file to identify to LLXXCICS both the transaction ID and the program it invokes. (You also need to issue an ALLOCATE command for SYSIPT.) Code the LLOSSP ->TRANSACTION card as follows, beginning in Column 1: ~> TRANSACTION=OXBOOK , LLASBK30 6.3.4.1 Passing Parameters To OXBOOK ‘You can pass parameter data to OXBOOK in a TSO environment via the CALL command. When you run OXBOOK from within the CICS Simulation Utility, you pass parameters on the initial screen input, as below: OXBOOK ALLOW=8 6.14 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 SECTION 7. UFO-CAT CONVERSION PROGRAM The UFO-CAT conversion program (UFO2CAT) is a batch utility. Use this program to convert your UFO/Forms views and FLV records from UFO/Forms Data Dictionary format to CAT for- ‘mat, This document uses the term "UFO/Forms view" to refer to a DSD and its associated FD records. ‘The UFO-CAT conversion program uses control cards to define: the IOX data spaces to be used > the views to be converted During conversion processing, the program produces an audit report on SYSLST (for VSE), and SYSPRINT (for OS or CMS). The audit report lists the UFO/Forms views converted, and gives informatory messages about the conversion of the views; for example, messages that note certain fields that cannot be converted, and why. The audit report also lists any error conditions encountered, such as a view card speci- fied for a view that already exists in CAT. If the conversion program incurs an error which causes it to terminate conversion processing, it issues an explanatory message, and sets the operating system return code to 12. 7.1 Conversion Strategies Before converting, you should be aware of the differences between CAT and the UFO/Forms Data Dictionary. These differences are documented in "Section 7.3". Differences between the two data dictionaries are great enough that conversion is actually a two- step process: L Run the UFO-CAT conversion program. 2. Manually update the resulting CAT view to correct any discrepancies flagged by the con- version program. UFO-CAT conversion program ThRelease 3.0 December, 1987 OSPUG1287 7.2 Control Cards And JCL For input the UFO-CAT conversion program uses two kinds of control cards: space cards: define the IOX data spaces to be used for input and output sw cards: define the views to be converved 7.2.1 Space Cards ‘Space cards must begin in column 1, The UFO-CAT conversion program recognizes the following space cards: UFOSPACE=date-space-name This optional card specifies the input data space from which the UFO-CAT conversion program attempts to read UFO/ Forms views and FLV records. The data-space-name you code must be exactly six characters in length. If you omit the UFOSPACE= card, the default value is UFOIOX. CATSPACE=data-space-name This optional card specifies the output data space to which the CAT views (the conversion program output) are written. ‘The data-space-name you code must be exactly six charac- ters in length. If you omit the CATSPACE= card, the default value is CATIOX. If you specify space cards, they must precede any view cards in the input stream. NOTE For IOX integrity, you should give the data spaces the same names as those you assigned in your online system. If you want to use the same data space for input, and output, you must assign the same name for both spaces. 7.2.2 View Cards View cards follow the space cards in the input stream, and define the UFO/Forms views (DSDs) to be converted to CAT format. FLV records associated with a view are automatically converted at the same time. 1.2 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 Use as many view cards as is necessary to name all the views you need to convert. You can spec: ify multiple DSD names on a single view card, separated by commas, or you can use one view card for each DSD. To specify a view card, simply code the name of the DSD; there is no preceding parameter as with the space card. DSD names may start in any column, as in the following example. VIEW], VIEW2,VIEW3, VIEWS VIEWS VIEWS To convert all the DSDs in the UFO/Forms Data Dictionary (UFODICTM file), code SSALL (in any column) as the only input. Subsequent view names will be ignored. 7.2.3 Sample JCL This section gives a VSE JCL example and an OS JCL example. Refer to the IOX Reference Manual for more information on specifying IOX data spaces. UFO-CAT conversion program 13Release 3.0 December, 1987 osPuGi287 7.2.3.1 Sample VSE JCL Figure 7.1 shows sample VSE JCL for the UFO-CAT conversion program. It converts VIEW1, VIEW2, VIEWS, and VIEW on the UFO/Forms data space UFOIOX to CAT views on the CAT data space CATIOX. 1] 3OB ~ 7/ BSSGN SYSLST 7/ DLBL CATIOXI, '----: 7/ DLBL CATIOXR, 7/ DLBL UFOIOXI, '----: 7/ DLBL UFOIOXR, '-- 7/ EXEC UFO2CAT, SIZE=i CATSPACE=CATIOX UFOSPACE=UFOIOX VIEW1 , VIEW2 VIEW3, VIEWS y* /& Figure 7.1 Sample VSEJCL 7.2.3.2 Sample OS JCL Figure 7.2 shows sample OS JCL for the UFO-CAT conversion program. Note that the $$ALL Parameter is used here instead of individual view cards to convert all the views in the UFO/Forms Data Dictionary. Note also that space cards are not used, because the default data space nam¢ are specified. //JOBNAME JOB 7/STEPNAME EXEC PGM=UFO2CAT //STEPLIB DD +DIs: //SEOIOXI DD +DISP=SER 7/SEOIOXR DD /DISP=SER Z/CATIOXI DD /DISP=SER 7/CBTIOXR DD /DISP=SER 7/S¥SPRINT DD SYSOUT=A * 7/SXSIN DD SSALL y* Figure 7.2 Sample OS JCL 14 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 7.2.4 Sample CMS Command Statements Before you can run the UFO-CAT conversion program in a CMS environment, you must issue FILEDEF commands for the following files SYSIN This file will contain all the control cards. You can assign SYSIN to a terminal or a CMS disk file. If a disk file is used, it must consist of fixed-length 80-byte records. By default, SYSIN will be assigned to a file named SYSIN FILE A. SYSPRINT This file will receive the formatted print output. You can assign SYSPRINT to a printer, a terminal, or a CMS disk file. SYSLST —_—_This file will receive any abend dumps that may be produced, as well as any [OX messages issued. You can assign SYSLST to a printer, a terminal, or a CMS disk . file. By default, SYSLST will be assigned to a file named SYSLST FILE A. SYSPCH This file will receive the formatted punched output produced by the UFO-CAT con- version program. You can assign SYSPCH to a printer, a terminal, or a CMS disk file. UFO-CAT conversion program 18Release 3.0 December, 1987 OSPUG1287 7.3 UFO/Forms-CAT Compatibility This section highlights some of the differences between CAT and the UFO/Forms Data Dictionary. For complete details on CAT, consult the CAT Reference Manual. 7.3.1 Groups The most significant area in which the two dictionaries differ is in the way they handle groups. ‘You must be familiar with the CAT rules concerning the definition of groups and arrays to fully understand the consequences of converting from UFO/Forms groups to CAT groups. When the UFO-CAT conversion program encounters a UFO/Forms group, it converts it to a CAT detail record with the lowest level in that hierarchy. It considers any field in the UFO/Forms view that fits within the range of one occurrence of that group to be a member of that group, and will assign the field a higher level number on the CAT view. For this reason, groups or fields which redefine the same area may not yield the expected conversion results. CAT considers a group to end when it encounters a detail with a level number less than or equal to the level number of the group. Be aware that when the conversion program encounters non-contiguous or overlapping fields, it must create a new start position. When CAT encounters a new start position, it assumes that the ‘current group is terminated. Subsequent fields will not be factored in the group length calcula- tions, even though they would fit into the group range. The conversion program does not allow you to explicitly set group lengths. Instead, it calculates the group length by adding the lengths of the subordinate items in the group. Each field with a level number higher than the group item is considered a subordinate item in the group. However, remember that any intervening start position on the CAT view will terminate the group and thus affect your group length calculations. Also, CAT defines the group length for group arrays as the total length of all occurrences of the ‘group instead of a single occurrence, as does UFO/Forms. The maximum total length of any field ‘or group (including all occurrences) is 65535. In addition, the program does not support variable length occurs (type "O" groups on the UFO/ Forms Data Dictionary). The UFO-CAT conversion program converts them to CAT groups with a fixed occurs, the same number of occurs as the maximum you specified on the UFO/Forms Data Dictionary. 1.6 Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 1.3.2 Access Method Type The following UFO/Forms access method types are not supported by CAT: M R v x Views containing one of these access method types will not be converted. If this is the case, the UFO-CAT conversion program issues a message telling you that the view cannot be converted, ‘and continues with the next view to be processed. Also, when converting a view with an IOX access method type (E, F, I, J), the conversion pro- gram requires that the view specify the name of the [OX data space in which the file is found, ‘The program initializes that name to the data space name specified on the UFOSPACE= control card (or the default, UFOIOX). If this is unacceptable, you may want to update the converted view. Figure 7.3 shows how UFO/Forms access method types are converted into CAT access method types. ACCESS METHOD TYPE CONVERSION UFO/Forms Access Method Type | CAT Access Method Type A,B,C/K,L VSAM D DL/1 E,P,I,d Tox G,P NONE RV AY Not Supported Figure 7.3 UFO/Forms Access Method Type Conversion NOTE UFO/Forms views with no access method specified will be converted to CAT access method type NONE. UFO-CAT conversion program 1Release 3.0 December, 1987 OSPUG1287 7.3.3 Field Type Figure 7.4 shows how UFO/Forms field types are converted into CAT field types. PIELD TYPE CONVERSION UFO/Forms Field Type (TYP F) | CAT Field Type and Indicator A - Alpha Only Character c B - Binary Bs C - Character c F - Filler c G - Group No Type H - Hexadecimal q © - Group No Type P - Packed F Sign Pu S - Packed C Sign PSs T - Bit BS ¥ - Zoned C Sign zs Z - Zoned F Sign zu Figure 74 UFO/Forms Field Type Conversion UFO/Forms field type T (bit) has no direct equivalent in UFO-CAT conversion program, and is converted to a signed binary field on the CAT view. Therefore UFO/Forms applications that subsequently use CAT-converted views will not be able to display data in bit format. When the UFO-CAT conversion program encounters T field types in a UFO/Forms view, it issues “a message informing you that the field type was changed to signed binary. UFO/Forms field types M, L, R, and X represent UFO/Forms control fields, and will not be con- verted to the CAT view. In this event, the UFO-CAT conversion program issues a message informing you that the field was dropped, and continues conversion processing. 1.3.4 Field Length On the UFO/Forms Data Dictionary, "field length” is the display length of the field; that is, the number of character positions that the field occupies on the screen. This length may or may not be the same as the field's actual length in bytes. In CAT, however, field length is the actual length of the field in bytes. This means that the UFO-CAT conversion program cannot provide a display length for those field types where the display length and the actual field length may differ. This affects field types B (binary), P and S (packed), H (hexadecimal), and T (bit). 78 Operational Support Package User GuideosPuGi287 Release 3.0 December, 1987 7.3.5 UFO/Forms ISC Option IBM's ISC (Inter Systems Communication) feature permits CICS systems to communicate with ‘one another within and across computer configurations. If you have coded "Y" for the ISC option on the DSD, UFO/Forms accesses that file through command-level CICS. This specification is not available on the CAT view, and thus the field is not converted, Be aware of this fact. when converting views that reference a file which must be accessed with command- level CICS. The UFO-CAT conversion program issues an informatory message when it converts a UFO/Forms view with the ISC option specified. 7.3.6 VO SIZE The conversion program calculates an U/O size for the CAT view by determining the maximum start position plus the field/group length (including occurrences). If a value has been coded in the UFO/Forms DSD's U/O SIZE specification, and this value is less than the value the program calculated, the UFO/Forms value is ignored. If the value coded on the DSD is larger than the one the conversion program calculated, it pads the CAT view with an unnamed filler field to create a view of the appropriate length. The maxi- mum total view length (or UO size) for CAT is 16M. 7.3.1 UFO/Forms Security Codes Security codes assigned to UFO/Forms Data Dictionary viewsifields through the UFOFSCTY utili- ty are stored in UFO/Forms Data Dictionary records. Security codes are not available on CAT views, and the security code field is not converted. When the UFO-CAT conversion program encounters a security code, it issues an informatory message, and continues processing. As a result, UFO/Forms applications which access the file using the CAT-converted view can spec- ify security at the DSD level, but not the field level. 7.3.8 Automatic Field Initialization The UFO/Forms DSD INITIALIZE specification allows you to request that a record associated with your UFO/Forms view be automatically initialized according to its UFO/Forms data type specification (TYP F). ‘This specification is not available on the CAT view, and is not converted. In this event, the UFO-CAT conversion program issues an informatory message. UFO-CAT conversion program 19Release 3.0 December, 1987 OsPUG1287 7.3.9 Field Start Positions In CAT all field start positions are defined relative to zero. In UFO/Forms, on the other hand, field start positions are defined relative to one. And in the case of IOX files, an additional two positions are added to account for the length field at the beginning of the record. The conversion program converts UFO/Forms’ one-relative views to CAT's zero-relative views by removing one byte from the start positions. If the view being converted describes an IOX file, the program removes an additional two bytes from the the start position. The program calculates the start position of the next field by adding the length of the current field to its start position. In the course of converting a UFO/Forms view, the UFO-CAT conversion program may encounter a non-contiguous field, which means that the sum of the start position and the field length, does not equal the start position of the next UFO/Forms field. In this event, the program does one of the following: L If the UFO/Forms start position is greater than the CAT start position, the conversion program adds an unnamed filler field to the CAT view to position it forward to the proper start position. 2 If the UFO/Forms start position is less than the CAT start position, the program adds a START POSITION entry to the CAT view to position it back to the proper start position. This is important to group processing under CAT, because according to CAT rules, a new start position terminates a group. 7.3.10 Field Level Validation ‘The conversion program automatically converts any FLV records associated with a given UFO/ Forms view. The names assigned to the CAT-converted FLV records consist of the field name, prefixed by “FLV,” as in FLVFIELD. 7.10 Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 7.3.11 User Dictionary Exit If the conversion program encounters a UFO/Forms view that has a user dictionary exit specified, it will not convert that view because the field information is contained on an external data diction. ary. In this case, the program issues an informatory message and skips to the next view. NOTE If you plan to use UFO/Forms with the converted view, do not insert “%%SPCNME" in the USER DICTIONARY EXIT field of the DSD until after the view is converted. 7.4 Conversion Examples This section contains two conversion examples. Remember that the conversion process requires that you: L Run the UFO-CAT conversion program. 2 Manually update the resulting CAT views (as per the messages the utility produces as output) to correct any discrepancies. Each example consists of: + a UFO/Forms view to be converted = the input card(s) + the conversion output the converted CAT view + user updates to the CAT view UFO-CAT conversion program TALRelease 3.0 December, 1987 osPuG1287 7.4.1 UFO/Forms View: Example 1 Figure 7.5 shows the UFO/Forms view that wil be run through the UFO-CAT conversion pro- gram. FILE DEFINITION NAME- > CUSIVIEW ACCESS METHOD-~~------> 1 ACTUAL FILE (OR SEGMENT) NAME--> CUSIFILE ISC OPTION ("Y","N")--> KEYGROUP HEADER NAME--~--. > CUSTKEY USER DICTIONARY EXIT > FOR DL/1 ONLY: INITIALIZE? (¥ OR N)=-> PSB NAME ~~~. DBD NAME > DaD POSITION---> SHIAME}* toeeeADESCRIPTION*HHKHKt TYP LEN START FR ATT D EDIT OC T Fu ##PDP CDRS F 01 cusTADDR © 40 230080000 1 02 cusTINFO Gu42 210080000 1 03 cusTKEY GN 20 10080000 1 04 CUSTNAME c¢ 20 10080000 1 05 cusTNO ¢ 2 210080000 1 06 cUSTNUM Zz 2 210080000 1 Figure 75 UFO/Forms View #1 7.4.2 Input Cards The input cards for the UFO-CAT conversion program are: UFOSPACE=XFOIOX CUSTVIEW This will convert the UFO/Forms view CUSTVIEW from IOX data space XFOIOX to a CAT view on [OX data space CATIOX. Tag Operational Support Package User GuideosPUG1287 Release 3.0 December, 1987 7.4.3 Conversion Output Figure 7.6 shows the the output the program produces on SYSLST when it converts the view in Figure 7.1. UCOS VIEW CUSTVIEW IS BEING CONVERTED UC12 IOX DATA SPACE NAME FOR VIEW CUSTVIEW HAS BEEN INITIALIZED TO XFOIOX UC16 GROUP CUSTINFO START= 20 UFO LEN= 42 CONTAINS CAT START POSITION; RESULTING CAT GROUP LEN MAY BE INCORRECT UC14 VIEW CUSTVIEW WAS SUCCESSFULLY CONVERTED Figure 7.8 Conversion Output for View #1 7.4.4 Converted View Figure 7.7 shows the resulting CAT detail entries. Notice that several items in the figure are marked with bracketed letters. These items are referred to in "Section 7.4.5” below. UFO-CAT conversion program 7.13Release 3.0 December, 1987 OSPUG1287 cat Data Dictionary Definition Facility R3.0.0 Command? View: CUSIVIEW Library: CATIOX Level Tr or yo Start Pield-Wame pd Len Scl Occur —FLV-Name 02 cUSTKEY ( A ) 03 CUSTNAME © 20 02 CUSTINFO (B) 03 cusTNO c 2 00020 (c) 03 cusTNUK 2 v2 0 oc c 40 COPYRIGHT On-Line Software International, Inc. 1987, ALL RIGHTS RESERVED Figure 7.7 Converted CAT View #1 7.4.5 Interpreting the Output This section explains what happened when the view was converted. It lists and describes each flagged screen item in Figure 7.7. 7.14 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 8) © The UFO/Forms group CUSTKEY, lengtli 20, became CAT group CUSTKEY, with a level number of 02. The CAT group CUSTKEY has a detail field called CUSTNAME, which hhas a length of 20 and a level number of 03, The group CUSTKEY terminates at CUSTINFO (level 02), because CUSTINFO's level number is the same as its own. In CAT, a group ends when it is followed by a detail which has a level number greater than or equal to the level number of the group. See "Section 7.3.1" for more information on groups. The conversion program created this start position to redefine CUSTNO, because the fields CUSTNO and CUSTNUM start in the same position. However, according to CAT rules, a start position terminates a group. And in fact, message UC16 (Figure 7.2) warns that the length the program calculated for CUSTINFO may be wrong. UFO/Forms defined CUSTINFO’s length as 42, but the conversion program calculates it as 2, because CUSTINFO terminates at start position entry 00020. Since CUSTINFO. terminates, it has lost the detail fields CUSTNUM and CUSTADDR. 7.4.6 Updating the View Figure 7.8 shows the updated view. The length of the group CUSTINFO was corrected so that it is the length originally defined by UFO/Forms, 42. The flagged screen items are referred to in the discussion which follows the figure. UFO-CAT conversion program 7:18Release 3.0 December, 1987 OsPUG287 cat Data Dictionary Definition Facility R3.0.0 Command: View: CUSTVIEW Library: CATIOX Level Tr Current Position: 1 or yo Start Field-Name pd Len Scl Occur —FLV-Name 02 ~~ cUSTKEY 03 CUSTNAME c 20 02 cUuSTINFO 03 cUSTNO c 2 03 cUSTADDR (A) c 40 20 (B) 03° cusTWUX zs 2 COPYRIGHT On-Line Software International, Inc. 1987, ALL RIGHTS RESERVED Figure 78 Updated CAT View #1 The following is an explanation of each flagged screen item. (A) To correct CUSTINFO’s length, CUSTADDR was moved to its proper start position, fol- lowing CUSTNO. (B) The start position 20 terminates the group, but now all positions in the group have been defined by CUSTNO and CUSTADDR. The UFO-CAT conversion program now correctly calculates the group length of CUSTINFO as 42. 7.16 Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 7.4.7 UFO/Forms View: Example 2 Figure 7.9 shows the UFO/Forms view which will be run through the UFO-CAT conversion pro- gram. As a work file, the view does not have an access method specified. FILE DEFINITION NAME-. > CUSTADDR ACTUAL FILE (OR SEGMENT) NAME--> KEYGROUP HEADER NAME~- USER DICTIONARY EXIT-- FOR DL/1 ONLY: PSB NAME ----~-> DBD NAME - DaD PosrTIoI FANAMES® ttOreeADESCRIPTIONMHKHEE TYP LEN START F R ATT D EDIT OC T Fu ##PFDPCD # F (01 ADDRESS GN 35 1 0008000 3 02 cITY ¢ 2 1 0008000 1 03 st ¢ 221 0008000 1 04 STATE € 10 21 0008000 1 05 21P cS 31 0008000 1 Figure 79 UFO/Forms View #2 7.4.8 Input Card The input card is: CUSTADDR This will convert UFO/Forms view CUSTADDR from IOX data space UFOIOX to a CAT view on IOX data space CATIOX. UFO-CAT conversion program TaqRelease 3.0 December, 1987 OsPUG1287 7.4.9 Conversion Output Figure 7.10 shows the output the program produces on SYSLST when it converts the view in Fig- ure 7.9. UCOS VIEW CUSTADDR IS BEING CONVERTED UC16 GROUP ADDRESS START= 0 LEN= 35 CONTAINS CAT START POSITION; RESULTING CAT GROUP LEN MAY BE INCORRECT. UC17 FIELDS IN GROUP ADDRESS DEFINED FOLLOWING CAT START POSITION MAY HAVE INCORRECT CAT OCCURS/STRIDE VALUES UC14 VIEW CUSTADDR WAS SUCCESSFULLY CONVERTED Figure 7.10 Conversion Output for View #1 7.4.10 Converted View Figure 7.11 shows the resulting CAT detail entries. Notice that several items in the figure are flagged with bracketed letters. ‘These flagged items are referred to in "Section 7.4.11" below. 7.18 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 cat Data Dictionary Definition Facility 23.0.0 Command: View: CUSTADDR Library: CATIOX Level Tr Current Position: 1 or ya Start Field-Wame Pd Len Scl Occur —_FLV-Hame 02 ADDRESS (A) 3 03° crTy c 20 03° STATE c 10 20 (8) 030 sT c 2 03 (cc). c 8 03° zIP c 5 COPYRIGHT On-Line Software International, Inc. 1987, ALL RIGHTS RESERVED Converted CAT View #2 Figure 7.11 7.4.11 Interpreting the Output This section describes what happened when the view was converted. It lists and describes each flagged screen item in Figure 7.11. (A) The UFO/Forms group ADDRESS has a length of 35, and 3 occurrences. After conver- sion, it became a CAT group with a length of 30 and 3 occurrences. (B) Start position 20 terminates the group. The group length the program calculated is wrong, because the sum of the fields subordinate to it is only 30, and the desired UFO/Forms. group length is 35. (See message UC16 in Figure 7.6.) (©) For groups with multiple occurrences, CAT carries occurs/stride information for each field in that group. Since the group was prematurely terminated, ZIP and ST do not inherit the appropriate oceurs information from that group. Accordingly, the conversion program added a dummy character field as a filler to give ZIP the proper start position, UFO-CAT conversion program 7:19Release 3.0 December, 1987 OsPUG1287 7.4.12 Updating the View Figure 7.12 shows the updated view. The flagged screen items are referred to in the discussion which follows the figure. cat Data Dictionary Definition Facility R3.0.0 Command: View: CUSTADDR — Library: CATIOK Level Tr or yo Start Field-Mame pd Len Scl Occur FLV-Wame 02 © ADDRESS 3 03° scrTy ¢ 20 03° STATE c 10 03 ZIP (A) cs 00000 (B) 02 (c) 3 03 (p) c 20 03 ST c 2 COPYRIGHT On-Line Software International, Inc. 1987, ALL RIGHTS RESERVED Figure 7.12 Updated CAT View #2, ‘The following is an explanation of each flagged screen item. (A) ZIP was moved to its natural start position following STATE, in order to correct the group length of ADDRESS. This also corrects the problem of ZIP not inheriting the appropriate occurs/stride information, because ZIP is now a member of ADDRESS. (B) You can’t correct ST the same way you corrected ZIP. ST can’t become a member of ADDRESS, since ST is a redefinition of another group member, STATE. To gain the occurrence and stride information it needs as a member of a CAT group occurs, ST requires a dummy group to redefine ADDRESS. Start position 00000 was entered to redefine the dummy group at the same position as ADDRESS. (©) The dummy group was defined with 3 occurrences. 7.20 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 @) A dummy field positions ST at the proper start position. (©) A dummy field pads out the group so it has the same length as an occurrence of the origi- nal group ADDRESS. Now, ST inherits the same group occurs and stride information that it would if it were defined to ADDRESS. UFO-CAT conversion program 121Release 3.0 December, 1987 OsPUG1287 7.22 Operational Support Package User GuideosPUuG1287 Release 3.0 December, 1987 SECTION 8. CICS OPERATION Within a CICS environment, OSI products have two LLOSSPs available: the Command-Level LLOSSP, and the High-Performance LLOSSP. UFO/Forms, COBOL/XE, and UFO/4GL offer their users a choice between using one or the other. The Support Package online utilities (PAIN’ CAT, IOXUTIL, and Data Capture Utility) always make use of the Command-Level LLOSSP when running under CICS. ‘The Command-Level LLOSSP uses a standard command-level interface in issuing calls to CICS. The High-Performance LLOSSP predominantly uses the macro-level interface in calling CICS, although some command-level calls are also issued. This LLOSSP, then, avoids most of the over- head incurred by any command-level CICS application. 8.1 XA Support ‘The Command-Level LLOSSP and the High-Performance LLOSSP differ in the extent to which they support MVS/XA. Both the Command-Level LLOSSP and the High-Performance LLOSSP: + Allow programs to reside above the 16-megabyte line. + Allocate operating system storage above the 16-megabyte line. This storage consists of OSCORE storage (OS) or GETVIS storage (DOS). + Allow DL/I access from programs residing above the 16-megabyte line. However, as neither the Command-Level LLOSSP nor the High-Performance LLOSSP uses the High Level Pro- ‘gramming Interface (HLPD, any DL/I parameters residing above the 16-megabyte line are automatically copied to storage below the 16-megabyte line before the LLOSSP calls DL/I. Only the Command-Level LLOSSP: Acquires CICS storage above the 16-megabyte line. CICS Operation 81Release 3.0 December, 1987 OSPUG1287 8.2 Remote File Access The Command-Level LLOSSP offers complete remote file acess. The High-Performance LLOSSP does not offer remote file access. However, UFO/Forms itself does provide remote file access, so that UFO/Forms applications running under the High- Performance LLOSSP can access remote files. 8.3 Temp Storage ‘The Command-Level LLOSSP simulates single-element temp storage records as temp storage queues. ‘The High-Performance LLOSSP processes both single-element temp storage records and temp storage queues. Generally, application programs will execute properly under either LLOSSP. However, a poten- tial probiem exists if single-element temp storage files created by applications running under the High-Performance LLOSSP will be processed subsequently under the Command-Level LLOSSP, or vice versa. For complete portability, you must use temp storage queues. a2 Operational Support Package User GuideOsPuGi287 Release 3.0 December, 1987 SECTION 9. CMS OPERATION CMS LLOSSP operations are detailed in this section. Native batch programs such as IOXMAINT, or the COBOL/XE or UFO/4GL compilers, use the CMS LLOSSP as an environmen- tal interface when running in a VM/SP or VMPC environment. The Support Package online utili ties (PAINT, CAT, IOXUTIL, and Data Capture Utility), the OSI spreadsheet program MAXICALC, and the development languages UFO/Forms, COBOL/XE, and UFO/4GL also use the CMS LLOSSP when running under VM/SP or VM/PC. 9.1 SYSIPT Input The CMS LLOSSP accepts control cards that modify its operating characteristics in some respects. If you wish, you can override some CMS LLOSSP defaults by coding control cards in the SYSIPT file. In general, however, most users will not find this necessary. If no control cards will be submitted to override LLOSSP defaults, the SYSIPT file is not required. Native batch programs may read the SYSIPT file as data; the file need not contain any control cards. See “Section 12" for details about using LLOSSP control cards. ‘You can issue a FILEDEF assigning SYSIPT to any file or device. However, if the input cards are contained in a CMS file named FILE SYSIPT A, no FILEDEF is necessary. The SYSIPT file is not required under CMS. If no control cards or input data are to be read, the file need not exist. The SYSIPT file, if it exists, must consist of fixed-length 80-byte unblocked records. 9.2 SYSLST Output ‘The SYSLST file consists of fixed-length 121-byte unblocked records. The LLOSSP ordinarily pro- duces a formatted dump on the SYSLST file when one of the programs running under it termi- nates abnormally. Additionally, some of the messages the LLOSSP issues are written to the SYSLST file, a3 are diagnostic traces, screen images, and so forth. Native batch programs may write data to the SYSLST file. LLOSSP output, if any, will be inter- leaved with program output. You can issue a FILEDEF assigning SYSLST to any file or device. If no FILEDEF is issued, any SYSLST output will be written to a CMS file called FILE SYSLST A. CMS Operation atRelease 3.0 December, 1987 osPUuGi287 9.3 CMS Terminal Considerations CMS imposes certain restrictions on terminal use. If you are running an application in a CMS ter- minal session and you press (by design or accident), your terminal will be placed into CP mode. This allows you to enter CP commands, if you wish. To return to your interrupted CMS terminal session, do one of the followin, » Type BEGIN on the screen and press = Press again. ‘Your terminal will re-display the screen that was interrupted by pressing . However, if you had entered any input data to this screen, it will be lost. 9.4 CMS Temp Storage File Simulation Under the CMS LLOSSP, there are two methods cf simulating CICS temp storage files. Each installation sets the global default for all users with the TSLEVEL parameter of the LLMAGBL. macro in the LLASGB22 module. However, individual users can override this by coding a ->TSLEVEL= system option card. You can chocse to set the TSLEVEL at 1 or 2. 9.4.1 TSLEVEL 1 When you select TSLEVEL= 1, all temp storage files are maintained as discrete CMS files on your A-disk. The file-names of these temp storage files are composed of the temp storage data ID land the file types of TSMAIN, TSDISK, TSQMAIN, or TSQDISK. Since native CMS file LO is used, this option requires little system overhead, and thus provides quicker response time. How- ‘ever, you cannot update records in these files with records of a different length. In addition, the data IDs of temp storage queues that exist as CMS files are restricted to characters that are valid for CMS file names, such as: + all alphabetic characters > all numeric characters = the following special characters: 9.2 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 9.4.2 TSLEVEL 2 When you select TSLEVEL=2, all temp storage files are maintained in an IOX file named LLXXSTSQ on the OSPACE system data space. This option requires significantly more system overhead, and correspondingly longer response time. Also, temp storage files that reside on an IOX data space are not directly available or modifiable by CMS commands such as COPY and XEDIT. On the other hand, TSLEVEL=2 allows a complete simulation of CICS temp storage files: records may be updated by records of a different length, and data IDs are not restricted to a particular character set. 9.5 CMS Transient Data File Simulation Under the CMS LLOSSP, you can choose to simulate transient data files in either of two ways: as standard sequential files, or as IOX ESDS files. 9.5.1 Standard Sequential Transient Data File Transient data files may be read from, or written to, standard sequential files. These sequential files can be either native CMS files or VSAM ESDS files. These files have the advantage of being directly accessible via normal CMS or VSAM commands and programs. If you wish to use a standard sequential file as a transient data file, issue a FILEDEF command or DLBL statement for the 4-character transent data destination ID, and assign this name to the desired CMS or VSAM file. (If the destination file is an output file, specify all necessary file char- acteristics, such as RECFM, LRECL, and BLKSIZE.) These transient data files are treated similarly to CICS extrapartition transient data queues: they are read or written sequentially, but never updated. In addition, records are not erased from the queue once they are read. 9.5.2 IOX Transient Data Files You can maintain transient data files as discrete [OX files on the current OSPACE system data space. The name of any such file will be XXXX.TDQ, where XXXX is the 4-character transient data destination ID. If you do not issue a FILEDEF command or DLBL statement for the transient data queue ID, this option will be chosen by default. ‘These transient data files are treated similariy to CICS intrapartition transient data queues: records once read are deleted from the queue, so that any record can be processed just once and never again. CMS Operation 9.3Release 3.0 December, 1987 OsPUG1287 9.6 Passing Parameters To CMS Programs When you issue a CMS command that results in the execution of a program, every character to the right of the first left parenthesis is considered parameter data. In the example below, we are beginning execution of IOXMAINT, and using parameter data to specify that syntax or [OX errors will not cause the job to terminate. IOXMAINT (ALLOW=8 9.7 Return Codes The CMS LLOSSP passes return codes to CMS upon completion of each program. The return code is displayed on the terminal as part of the READY message (R;), and is always a positive value. A return code of 256 indicates an abend. 9.4 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 SECTION 10. BATCH OPERATION Batch LLOSSP operations are detailed in this section. Native batch programs, such as IOXMAINT, or the COBOL/XE or UFO/4GL compilers, use the Batch LLOSSP as an environ- mental interface when running in OS or DOS. Online applications developed using the develop- ment languages UFO/Forms, COBOL/XE, and UFO/4GL can be executed in “batch test" mode under the Batch LLOSSP in order to document online problems for On-Line Software Technical Support. (This should not be confused with actual batch support for the development languages, however.) ‘The development languages do not support the development of native batch applications; ie., pro- grams that read cards and produce reports. Batch test mode, referred to above, is provided only for the purpose of debugging applications tha: will ultimately run in other environments. 10.1 SYSIPT Input ‘The Batch LLOSSP accepts control cards that modify its operating characteristics in some respects. If you wish, you can override some Batch LLOSSP defaults by coding control cards in the SYSIPT file. In general, however, most users will not find this necessary. If no control cards will be submitted to override LLOSSP defaults, the SYSIPT file is not required. Native batch programs such as IOXMAINT or the UFO/4GL compiler may read the SYSIPT file as data; the file need not contain any control cards. See “Section 12” for details about using LLOSSP control cards. 10.1.1 OS ‘The SYSIPT file is not required under OS. If no input cards are to be read, the file need not exist. ‘You must code a DD statement for the SYSIPT file if control cards are to be read. The SYSIPT file must consist of fixed-length 80-byte records, and may be blocked or unblocked. 10.1.2 DOS In DOS, you must always code an ASSGN statement for SYSIPT. If you do not, an abend will result when the LLOSSP attempts to read the file. The SYSIPT file must consist of fixed-length 80-byte unblocked records. Batch Operation 10.1Release 3.0 December. 1987 OsPUG1287 10.2 SYSLST Output ‘The SYSLST file consists of fixed-length 121-byte unblocked records. The Batch LLOSSP ordinar- ily produces a formatted dump on the SYSLST file when one of the programs running under it ter- minates abnormally. Additionally, any messages the LLOSSP issues are written to the SYSLST file, as are diagnostic traces, screen images, and so forth. Native batch programs may write data to the SYSLST file. LLOSSP output, if any, will be inter- leaved with program output. 10.2.1 OS In OS, you must code a DD statement for the SYSLST file in order to receive LLOSSP dumps and messages. 10.2.2 DOS In DOS, you must always code an ASSGN statement for SYSLST. If you do not, an abend will result when the LLOSSP attempts to write to the file. 10.3 Batch Temp Storage File Simulation Under the Batch LLOSSP, all temp storage files are maintained in an IOX file named LLXX$TSQ on the OSPACE system data space. Thus, temp storage files are not directly available for retriev- al by other programs using standard VSAM or QSAM access. 10.4 Batch Transient Data File Simulation Under the Batch LLOSSP, you can choose to simulate transient data files in either of two ways: as standard sequential files, or as IOX ESDS files. 10.4.1 Standard Sequential Transient Data File Transient data files may be read from, or written to, standard sequential QSAM (OS only) or VSAM ESDS files. These files have the advantage of being directly accessible via normal QSAM. or VSAM access. If you wish to use a standard sequential file as a transient data file, code a DD or DLBL card for the 4-character transient data destination [D, and assign this name to the desired QSAM or VSAM file. (If the destination file is an output file, specify all necessary file characteristics, such as RECFM, LRECL, and BLKSIZE.) 10.2 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 These transient data files are treated similarly to CICS extrapartition transient data queues: they are read or written sequentially, but never updated. In addition, records are not erased from the queue once they are read. 10.4.2 IOX Transient Data File You can maintain transient data files as discrete IOX files on the current OSPACE system data space. The name of any such file will be XXXX.TDQ, where XXXX is the 4-character transient data destination ID. If you do not code a DD or DLBL card for the transient data queue ID, this option will be chosen by default. These transient data files are treated similarly to CICS intrapartition transient data queues: records once read are deleted from the queue, so that any record can be processed just once and never again. 10.5 Passing Parameters To Batch Programs You pass parameter data to OS batch programs in a manner slightly different from the manner in which you pass parameter data to DOS batch programs. 10.5.1 OS Generally, you pass parameter data on the PARM= parameter of the EXEC statement in your JCL. “However, you can code a ->PARM= system option card that will allow you to override JCL specifications. 10.5.2 DOS Parameter data is generally passed in your JCL. The primary method of doing this is by using the OPTION SYSPARM parameter to pass parameter data. In VSE/SP release 1.3 or higher, you can also pass parameter data with the EXEC card. In this case, the parameter data on the EXEC card overrides SYSPARM parameter specifications, if any exist. 10.6 Return Codes Return codes are passed back upon termination or completion of a program. Return codes are always positive. A return code of 256 indicates an abend. Batch Operation 10.3Release 3.0 December, 1987 osPUuG1287 10.6.1 OS ‘The Batch LLOSSP passes a standard OS return code in register 15. 10.6.2 DOS ‘The Batch LLOSSP always passes the return code in the UPSI byte. Return codes higher than 255 are set to 255 in the UPSI byte. In VSEVSP release 2.1 or higher, a standard return code is passed in register 15 by the Batch LLOSSP. 10.4 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 SECTION 11. TSO OPERATION TSO LLOSSP operations are detailed in this section. Native batch programs such as IOXMAINT, or the COBOL/XE or UFO/4GL compilers, use the TSO LLOSSP as an environmental interface when running under TSO, The Support Package online utilities (PAINT, CAT, IOXUTIL, and Data Capture Utility), the OSI spreadsheet program MAXICALEC, and the development languages UFO/Forms, COBOL/XE, and UFO/4GL also use the TSO LLOSSP when running under TSO. 11.1 SYSIPT Input The TSO LLOSSP accepts control cards that modify its operating characteristics in some respects. If you wish, you can override some TSO LLOSSP defaults by coding control cards in the SYSIPT file. In general, however, most users will no: find this necessary. If no control cards will be sub- mitted to override LLOSSP defaults, the SYSIPT file is not required. If you require a SYSIPT file, you must issue an ALLOCATE command. The SYSIPT file must consist of fixed-length 80-byte records, and may be blocked or unblocked. Native batch programs may read the SYSIPT file as data; the file need not contain any control cards. See "Section 12" for details about using LLOSSP control cards. 11.2 SYSLST Output ‘The LLOSSP ordinarily produces a formatted dump on the SYSLST file when one of the programs running under it terminates abnormally. Additionally, some of the messages the LLOSSP issues are written to the SYSLST file, as are diagnostic traces, screen images, and so forth. In TSO, you must issue an ALLOCATE command for the SYSLST file, which consists of fixed- length 121-byte unblocked records with ASA characters. Native batch programs may write data to the SYSLST file. LLOSSP output, if any, will be inter- leaved with program output. 11.3 Terminal Considerations ‘TSO operation imposes certain restrictions on terminal use. TSO uses as its “reshow key". If you are running an application in a TSO terminal session, pressing requests the rogram to redisplay the most recent complete screen. This may be useful when the screen dis- play has been destroyed, e.g., by messages from another TSO user. However, this means that ‘ is not available for ordinary use by the product or application program. TSO Operation walRelease 3.0 December, 1987 OSPUG1287 11.3.1 TSO/TCAM vs TSO/VTAM TSO terminals can operate under either TCAM or VTAM. Whichever one governs the terminal may also affect the operating characteristics of programs running under the TSO LLOSSP. For example, TSO/TCAM does not automatically clear the screen at the end of a program, while TSO/VTAM does. TSO/VTAM also provides a screen-protection feature, which is unavailable under TSO/TCAM. Under TSO/VTAM screen-protection, when the screen is in use by an online program under the TSO LLOSSP, no messages from other TSO users or from the system will be displayed until the user presses one of the following keys: = == Pressing one of these keys causes all messages to be displayed, followed by three asterisks at the bottom of the screen. After reading all the messages, the user presses to return to the online program display. With TSO/TCAM, however, after the asterisks are displayed, the user must press , and then press (the TSO reshow key). to return to the online program display. 11.4 TSO Temp Storage File Simulation Under the TSO LLOSSP, all temp storage files are maintained in an IOX file named LLXX$TSQ on the OSPACE system data space. Thus, temp storage files are not directly available to you for editing or other modification, nor are they available for retrieval by programs using standard QSAM or VSAM access. 11.5 TSO Transient Data File Simulation Under the TSO LLOSSP, you can choose to simulate transient data files in either of two ways: as standard sequential files, or as IOX ESDS files. 11.5.1 Standard Sequential Transient Data File Transient data files may be read from, or written to, standard sequential QSAM files or VSAM ESDS files. These files have the advantage of being directly accessible via programs using normal QSAM or VSAM access. If you wish to use a standard sequential file as a transient data file, issue an ALLOCATE com- mand for the 4-character transient data destination ID, and assign this name to the desired VSAM file. (If the destination file is an output file, specify all necessary file characteristics, such as RECFM, LRECL, and BLKSIZE.) 12 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 These transient data files are treated similarly to CICS extrapartition transient data queues: they are read or written sequentially, but never updated. In addition, records are not erased from the queue once they are read. 11.5.2 [OX Transient Data File You can maintain transient data files as discrete IOX files on the current OSPACE system data space. The name of any such file will be XXXX.TDQ, where XXXX is the 4-character transient data destination ID. If you do not issue an ALLOCATE command for the transient data queue ID, this option will be chosen by default. ‘These transient data files are treated similarly to CICS intrapartition transient data queues: records once read are deleted from the queue, so that any record can be processed just once and never again. 11.6 Passing Parameters You pass parameters to programs on the command line. In the following example, we are calling the IOXMAINT utility, and passing a parameter that specifies that syntax and IOX errors will ‘not terminate the program. CALL 'LOADLIBNAME(IOXMAINT)' 'ALLOW=8' 11.7 Return Codes ‘The TSO LLOSSP passes a standard OS return code to register 15 upon completion or termina- tion of the program. TSO Operation 11.3Release 3.0 December, 1987 1.4 OSPUG1287 Operational Support Package User GuideOSPUG1287 Release 3.0 December, 1987 SECTION 12. LLOSSP CONTROL CARDS ‘The LLOSSP accepts control cards that can be used to influence various operating characteristics. ‘These control cards are always read from the SYSIPT file. LLOSSP control cards have the following characteristics: Column(s) Contents Lo Hyphen (-) 2 Greater Than Symbol ( > ) Bton Card Identifier Keyword a+1t71 Parameter data 2 Blank (reserved) 73 to 80 Optional sequence/identification number. There are two special cards whose function is described below: Separator Card: contains a slash in column 3, and an asterisk in column 4. This card instructs ‘the LLOSSP that all the control cards for a given transaction have been read. =>/* Comment Card: contains an asterisk in column 3. The entire card image, beginning with the asterisk, is printed on the SYSLST file. ->* LLOSSP Control Cards 121Release 3.0 December, 1987 osPuGi287 Alll other control cards are of two types: System Option Cards, and Test Cards. The LLOSSP reads these cards differently depending on whether the program being tested is an online or batch program. If you are testing an online program, the LLOSSP will read the cards until it encounters the first separator card. It will then perform any requested terminal UO operation, after which it will resume reading the control cards. If you are testing a batch program, the LLOSSP will read the cards until it encounters the first separator card. It will not resume reading the cards until the application attempts to read the SYSIPT file. If no attempt is made to read the SYSIPT file, the LLOSSP does not resume reading ‘System option cards, if present, must always precede the first separator card. 12.1 System Option Cards The LLOSSP allows you to develop and test, in non-CICS environments, OSI applications that will ultimately run under CICS. In order to provide support for CICS features that have no equivalent in other environments (e.g., use of the TWA), the LLOSSP requires system option cards to specify the optional features to be simulated. ‘System option cards can also be used to modify certain operational characteristics of the LLOSSP tw facilitate problem determination and reporting. ‘System option cards, if present, must be read before the first transaction begins. The presence of a separator card determines the beginning of the first transaction. ‘These system option cards are recognized by the LLOSSP: ‘System Option Card ‘Meaning/Parameters ->STRINGS=nn, This card governs the number of VSAM strings to be gener- ated for each VSAM file the program will access. The value coded as nn must be a number between 1 and 36. The default is 2. 12.2 Operational Support Package User GuideOSPUG1287 ->OSPACE=data-space-name ->PNTSPCE=data-space-name ->CATSPCE=data-space-name ->PARM="data’ LLOSSP Control Cards Release 3.0 December, 1987 This card specifies the name of the IOX data space to be used by the LLOSSP for system access. The name must be six alphameric characters in length, with no embedded blanks. This parameter, if specified, overrides the OSPACE specifi- ation cn the LLMAGBL installation macro. The default is the data space defined on the LLMAGBL. macro as the OSPACE parameter. This card specifies the name of the IOX data space to be used as the default PAINT library name. The name must be six alphameric characters in length, with no embedded blanks. This parameter, if specified, overrides the PNTSPCE specifi- cation on the LLMAGBL installation macro. ‘The default is the data space defined on the LLMAGBL macro as the PNTSPCE parameter. This card specifies the name of the IOX data space to be used as the default CAT library name. The name must be six alphameric characters in length, with no embedded blanks. This parameter, if specified, overrides the CATSPCE specifi- cation on the LLMAGBL installation macro. The default is the data space defined on the LLMAGBL ‘macro as the CATSPCE parameter. This card passes the LLOSSP data that will be presented to the application program as the initial terminal input. This data overrides any parameters actually entered on the ‘command-line that invoked the transaction, Up to 62 char- acters of data can be entered. The data must be delimited by apostrophes, and may not contain any embedded apos- trophes. By default, parameters are taken from the command-line that invoked the transaction. 12.3Release 3.0 December, 1987 ->TRTSIZE=nnnn ->CONSOLE=ONOFF ->IPTMODE=TEST|NOTEST ->TERMID = terminal-id ->OPERATOR=operator-id OsPUG1287 This card governs the size of the internal trace table main- tained by the LLOSSP. The value coded as .nann must be a number between 128 and 4000. The default is 128. This card determines whether the LLOSSP will allow CMS console output. CONSOLE=ON means that all CMS mes- ‘sages will be displayed. CONSOLE=OFF means that CMS console output will not be permitted. The default is CONSOLE=OFF. This card governs the processing of LLOSSP control cards. IPTMODE=TEST means that all LLOSSP control cards will be honored. IPTMODE=NOTEST means that any subsequent LLOSSP control cards will be ignored. The default is IPTMODE=TEST. This card governs the 8-byte ID that will represent the ter- minal. This name may never begin with an asterisk, The default is the user ID in CMS or TSO. For batch envi- ronments, a unique default value will be assigned by the LLOssP. This card governs the 8-byte ID that will represent the oper- ator. ‘The default is the user ID (in CMS or TSO). For batch envi- ronments, the default operator is the jobname. -> TERMFEAT= MOD 1,MOD2,MOD3,MOD4,MOD5,COLOR,PSS, HILITE,DBCS 12.4 This card specifies the features of the simulated terminal during batch-test mode, and describes the characteristics of the real terminal used in a TSO session. In CMS, only the DBCS parameter is ordinarily needed. MODI: The terminal is a 3278 model 1. MOD2: The terminal is a 3278 model 2. MODS: The terminal is a 3278 model 3. MOD4: The terminal is a 3278 model 4. Operational Support Package User GuideosPUuGi287 ->START=COLD|WARM|HOT ->TRIGGER=PFn,program-name LLOSSP Control Cards Release 3.0 December, 1987 MODS: The terminal is a 3278 model 5. COLOR: The terminal will have extended color support. PSS: The terminal will have Program Symbol Support (ss). HILITE: The terminal will have extended highlight support. DBCS: The terminal will support DBCS (Double-Byte Char- acter Set) fields. This feature is necessary for running programs that require KANJI support. ‘This parameter ia required in all environments for those programs that use DBCS fields. ‘The default is MOD2, without the extended features of COLOR, PSS, HILITE, or DBCS. ‘This card determines whether temporary storage files are purged before the first transaction is invoked. COLD: All temp storage files will be purged. WARM: Main temp storage files will be purged. HOT: No temp storage files will be purged. START=HOT is the default. ‘This card defines a program to be called when the specified PF key is pressed. When the called program completes, con- trol is returned to the point in the calling program at which the PF key was pressed. 12.5Release 3.0 December, 1987 OSPUG1287 ->TRANSACTION=TRANSID, program-name . This card allows you to define a transaction ID and associat- ed program to be invoked under the CICS Simulation Utility ("Section 2"), TRANSID: a 1-8 character name that you will use to invoke a transaction within the CICS Simulation Utility, Program-name: a 1-8 character name that identifies a load ‘module or phase to be invoked via the transaction ID. You can code as many ->TRANSACTION= cards as you wish. The LLOSSP recognizes each transid as being unique. If you code the same transid for more than one program, each successive card will overlay the previous card, and the LLOSSP will acknowledge only the last card in the deck. -> TERMINPUT = OPERATORNONEIIOX file-name, This card determines the source of terminal input to an online application. When TERMINPUT=IOX-file-name, the application is running in batch-test mode. ‘TERMINPUT=OPERATOR specifies that the operator will supply the terminal input from the keyboard. TERMINPUT=IOX-file-name,data-space-name specifies the name of an IOX file that contains records to be read as ter- minal inpu:. The name of the data space in which the file resides is optional, and defaults to the data space specified as the current OSPACE. IOX-file-name may be from 1 to 8 characters in length. Data-space-name is 6 characters in length. ‘TERMINPUT=NONE means that no terminal input will be provided. ‘TERMINPUT=OPERATOR is the default in TSO and CMS. ‘TERMINPUT=NONE is the default in batch. 12.6 Operational Support Package User GuideOsPuGi287 Release 3.0 December, 1987 -> TERMOUTPUT = CONSOLES YSLIST|BOTH, IMAGE|BUFF! ->TSLEVEL=2/1 LLOSSP Control Cards This card determines how the LLOSSP will process terminal output. TERMOUTPUT=CONSOLE means that LLOSSP will write terminal output to the user’s screen. TERMOUTPUT=SYSLST means that LLOSSP will write terminal output to the SYSLST file. TERMOUTPUT=BOTH means that the LLOSSP will write terminal output to both the screen and the SYSLST file. TERMOUTPUT=IMAGE specifies that a hardcopy of the screen image be printed. TERMOUTPUT=BUFFER specifies that a hardcopy of the simulated buffer be printed. This is the only way to ascer- tain the field attributes of the screen's fields with SYSLST terminal output. TERMOUTPUT=ALL specifies that hardcopies of both the screen image and the simulated terminal buffer be printed. ‘TERMOUTPUT=CONSOLE is the default in CMS and TSO. TERMOUTPUT=SYSLST, IMAG! is the default in batch. This card determines the way in which CICS temp storage files are simulated in a CMS environment. You can use this card to override the TSLEVEL specification set by the LLMAGBL macro, as described in the Operational Support Package Customization Manual. If you specify TSLEVEL=2, all temp storage files are con- tained in the file LLXX$TSQ on the IOX data space defined as the current OSPACE. However, temp storage files that reside on an IOX data space are not directly accessible by CMS commands, such as XEDIT. If you specify TSLEVEL=1, all temp storage files are main- tained as discrete CMS files on your A-disk, with file names equal to the temp storage data [D, and file types of TSMAIN, TSDISK, TSQMAIN, or TSQDISK. However, the data IDs of temp storage files that reside in CMS files are restricted to valid CMS file names. In addition, records in such files may not be updated with records of a different length. 12.7Release 3.0 December, 1987 ->TRANSCR=NO|YES ->TRANPRT=NOJYES 12.8 OSPUG1287 This parameter regulates the translation of screen literals, from lowercase to uppercase. It is necessary only in certain locales where lowercase characters are translated into a particular character set (e.g., KATAKANA in Japan). Use it to override the TRANSCR specification set by the LLMAGBL macro, as described in the Operational Support Package Customization Manual. TRANSCR=YES translates the lowercase sereen literals, into uppercase characters. It has no affect on data entered by the terminal operator. TRANSCR=NO performs no such translation on screen lit- erals. TRANSCR=NO is the default. This parameter operates similarly to the TRANSCR= parameter, regulating the translation of literals from lower- case to uppercase in printouts. It is necessary only in cer- tain locales where lowercase ¢ characters are translated into a particular character set (e.g., KATAKANA in Japan. Use it to override the TRANPRT specification set by the LLMAGBL macro, as described in the Operational Support Package Customization Manual. TRANPRT= YES translates the lowercase literals into uppercase characters. TRANPRT=NO performs no such translation on literals. TRANPRT=NO is the default. Operational Support Package User GuideOsPUG1287 Release 3.0 December, 1987 12.2 Test Control Cards : Test control cards allow the user to control certain functions during the run of a transaction. ‘The LLOSSP recognizes the following test control cards: ‘Test Control Card Meaning/Parameters ->TWASIZE=nnnan This card governs the size of the TWA to be used by the transaction. The value coded as mann must be a number between 0 and 32247. ‘The default is 0. ->IOXTRACE=ON|OFF This card governs whether full LLOSSP tracing will be in effect during calls to TOX. The default is IOXTRACE=OFF. ->ABEXIT=ONjOFF ‘This card determines whether the LLOSSP will trap pro- ‘gram checks and abends. ABEXIT=ON: Program checks and abends will be inter- cepted. ABEXIT=OFF: Program checks and abends will be not intercepted. The default is ABEXIT=ON. ->DUMP=TRACE{TRANS|ABEND This card requests that a dump be produced on the SYSLST file. DUMP=TRACE: The dump displays only the trace table. DUMP=TRANS: The dump displays all transaction-related storage areas. DUMP=ABEND: The transaction is terminated. Dumps are issued at the end of a transaction, not immedi- ately when the LLOSSP reads the card. ->TRACE=TERMHOX (,SUPERJOFF This card activates or resets the LLOSSP extended trace facility. TRACE=TERM: This card causes the LLOSSP to provide an extended trace of all terminal input and output to be written to the SYSLST file. LLOSSP Control Cards 12.9Release 3.0 December, 1987 OSPUG1287 TRACE=IOX [,SUPERI: This card causes the LLOSSP to provide an extended trace of all IOX files. For more information, specify the SUPER option. TRACE=OFF: This card causes the trace facility. It is the default. 12.3 SYSIPT Input Stream Examples ‘The following examples of valid SYSIPT input streams are presented to clarify the correct use of LLOSSP control cards. ‘These cards would be appropriate for debugging a native batch application program that reads the SYSIPT file for data. ->ABEXIT=OFF (Don't trap program checks) ++. input data cards ... ->DUMP=TRANS (dump without abending program) ++. input data cards ... ~>DUMP=ABEND (dump ané abend program) EOF These cards might be used to debug an online application program in batch-test mode. ~>TWASIZE=32 (option card required for simulation of CICS TWA) ~>TRANSACTION=TRN1,PROGRAM1 (defines transaction captured online) —>/* (separator card required to defer reading of next card until start of second transaction) ->DUMP=TRACE (dump will be produced after second transaction) =>/* (not required - no more test cards follow) EOF ->TERMINPUT=TESTDATA,OSPIOX (defines terminal input captured online) 12.10 Operational Support Package User GuideosPuGi287 Release 3.0 December, 1987 SECTION 13. RESERVED FILE NAMES The IOX file names listed below are used internally by the Support Package. Users should never modify or allocate these files. PNTPNL: Contains OSI-supplied PAINT panels. CATVIEW: Contains OSI-supplied CAT views. LLXX$TSQ Contains all OSI simulated temp storage file Reserved File Names 13.1Release 3.0 December, 1987 OSPUG1287 13.2 Operational Support Package User GuideOSPUG1287 INDEX, S$ALL... 7.3 access method type conversion ... 7.7 IOX data space ... 7.7 types unsupported by CAT ... 7.7 UFO/Forms types H and T... 7.7 array handling conversion example . group length in CAT ... 7. cceursistride information ... 7.19 UFO/Forms variable length occurs ... 7.6 automatic field initialization ... 7.9 Batch LLOSSP. SYSIPT ... 10.1 SYSLST ... 10.2 ‘Operation batch-test mode ... 10.1 LLOSSP ... 10.1 temp storage file simulation ... 10.2 transient data file simulation ... 10.2 batch-test mode ... 2.1 CAT... 10.1 CICS Simulation Utility ... 2.3, 2.1 COBOLKXE ... 10.1 Data Capture Utility ... 2.4, 2.3, 3.1 LLOSSP ... 2.4, 10.1 PAINT ... 10.1 running programs ... 2.4 CICS Simulation Utility ... 2.4 ‘control cards ... 2.4 Data Capture Utility ... 2.4 UFO/Forms ... 10.1 UFOMGL ... 10.1 bit conversion ... 7.7 CAT. LA batch-test mode ... 10.1 CMS ... 9.1 OXBOOK ... 6.1 OXFORMAT ... 4.1 TSO... 1.1 UFO-CAT conversion program ... 7.1 INDEX Release 3.0 December, 1987 CAT views CATSPCE ... 1.2 CATSPCE internal files CATVIEW ... 1.2 LLMAGBL macro DTR installation ... 1.2 system data space ... 1.2 control cards ... 1.2 CATVIEW ... 13.1 CATSPCE internal files ... 1.2 cics ‘Operation ... 8.1 COBOLXE ... 8.1 Command-Level LLOSSP ... 8.1 High-Performance LLOSSP ... 8.1 LLOSSP ... 8.1 81 XA Support LiRelease 3.0 December, 1987 CICS Simulation Utility ... 2.1, see also LLXXCICS Abbreviated Sereen ... 2.2 image ... 2.3 batch-test mode ... 2.1, 2.3 CAT... 2.1 control cards TRANSACTION ... 2.1 Data Capture Utility ... 2.1 Invocation ... 2.1 CMS ... 2.1 TSO... 2.1 IOXUTIL ... 2.1 ICL considerations ... 2.4 CMS ... 2.7 DOS batch OS batch .. TSO... 2.8 UFOMGL... 2.1 cms LLOSSP LLOSSP.... 9.1 temp storage file simulation terminal considerations ... 9.2 n.. 9.3 9.2 transient data file simul: 12 OSPUG1287 CMS commands CICS Simulation Utility ... 2.7 OXBOOK ... 6.10 OXEXPORT ... 5.12 OXIMPORT ... 5.13 SYSIN CICS Simulation Utility ... 2.7 OXBOOK .... 6.10 OXEXPORT ... 5.12 OXFORMAT ... 4.8 OXIMPORT .... 5.13, SYSIPT CICS Simulation Utility ... 2.7 SYSLST CICS Simulation Utility ... 2.7 OXBOOK ... 6.10 OXEXPO! OXFORMAT OXIMPORT SYSPCH OXBOOK ... 6.10 OXEXPORT ... 5.12 SYSPRINT| CICS Simulation Utility ... 2.7 OXBOOK ... 6.10 OXEXPORT ... 5.12 OXFORMAT ... 4.8 OXIMPORT ... 5.13 CMS LLOSSP CAT... 9.1 COBOLIXE ... 9.1 PAINT... 9.1 UFO/Forms ... 9.1 UFO/GL... 9.1 COBOL/KE batch-test mode ... 10.1 CICS ... 8.1 MS ... 9.1 TSO... LLL Component Export Utility ... 5.1, see OXEXPORT Component Format Utility ... 4.1, see OXFORMAT Component Import Utility ... 5.1, see OXIMPORT INDEXosPuGi287 control cards ABEXIT ... 12.9 ACB. ‘OXEXPORT OXFORMAT batch-test mode running programs ... 2.4 CATSPCE ... 12.3 124 44 OXEXPORT ... 5.7 OXFORMAT... 4.4 IOXTRACE ... 12.9 IPTMODE ... 12.4 JCL ‘OXBOOK ... 6.6 OXEXPORT .... 5.8 LIBRARY OXBOOK ... 6.2 OXEXPORT ... 5.2 OXFORMAT .... 4.2 LLOSSP ... 12.1 comment ... 12.1 separator ... 12.1 INDEX Release 3.0 December, 1987 system option ... 12.2 system option cards .. 1.1 test... 12.2, 12.9 MEMBER OXBOOK ... 6.5 MENU OXEXPORT ... 5.7 OXFORMAT ... 4.4 ACB OXEXPORT ... 5.7 opps OXEXPORT.... 5.7 oppx OXEXPORT ... 5.8 opsp OXEXPORT ... 5.7 OPANEL OXEXPORT ... 5.8 opps OXEXPORT ... 5.8 OPERATOR ... 12.4 OPTION OXEXPORT ... 5.4 OSPACE ... 12.3, 2.5-2.8 CICS Simulation Utility .. 2.5 oviEW OXEXPORT ... 5.8 OXBOOK ... 6.1 examples ... 6.7 OXEXPORT examples ... 5.9 O4GL OXEXPORT ... 5.8 PANEL OXEXPORT ... 5.6 OXFORMAT.... 4.3 PARM... 12.3 PASSWORD OXFORMAT.... 4.2 PDS OXEXPORT ... 5.7 OXFORMAT... 4.5 PNTSPCE ... 12.3 PROLOG OXBOOK RUN OXEXPORT . OXFORMAT 6.3 13Release 3.0 December, 1987 space ... 7.2 default... 7.2 example... 7.12, 7.17 format ... 7.2 specifying ... 7.2 UFO-CAT conversion program ... 7.2 STAGE OXFORMAT .... 4.5 START... 12.5 STRINGS ... 12.2 SUFFIX ‘OXFORMAT ... 4.2 syntax OXBOOK ... 6.1 OXEXPORT .... 6.2 OXFORMAT... 4.1 TARGET OXEXPORT ... 5.1, 5.3 OXIMPORT ... 5.1 TERMFEAT ... 12.4 TERMID ... 12.4 TERMINPUT ... 12.6, 2.4 CICS Simulation Utility ... 2.4 TERMOUTPUT ... 12.7 TRACE... 12.9 TRANPRT=NO|YES TRANSACTION ... 12. 12.8 temp storage simulation ... 9.2 TSLEVEL=2[1 ... 12.7 UFO-CAT conversion program ... 7.1 VIEW ... 7.2 example ... 7.12, 7.17 OXBOOK ... 6.5 OXEXPORT ... 5.6 OXFORMAT... 4.3, specifying ... 7.3, UFO-CAT conversion program ... 7.2 La OSPUG1287 Data Capture Utility ... 3.1 batch-test mode ... 2. Invocation ... 3.1 CICS .. CICS Simulation Utility ... 2.5 OXBOOK ... 6.12 OXEXPORT ... 5.14 SYSIPT CICS Simulation Utility ... 2.5 OXBOOK ... 6.12 OXIMPORT SYSLST CICS Simulation Utility ... 2.5 OXBOOK ... 6.12 field start positions conversion example ... 7.15 ‘group processing ... 7.15, 7.19 how CAT calculates ... 7.6 UFO/Forms vs. CAT ... 7.10 field type conversion, UFO/Forms ... 7.8 FLV conversion ... 7.10 group conversion occurs/stride information ... 7.20 group length and CAT arrays ... 7.6 conversion example ... 7.15, 7.19-7.20 explicit ... 7.6 hexadecimal conversion ... 7.7 INDEXOSPUG1287 UO size calculation ... 7.9 INITIALIZE feature ... 7.9 ISC option ... 7.9 JCL CMS ... 7.5 OS ... 7.4 VSE ... 7.4 JCL considerations CICS Simulation Utility ... 2.4 OXBOOK ... 6.10 OXEXPOR’ OXFORMAT ... 4.7 OXIMPORT ... 5.11 LLMAGBL macro ‘TSLEVEL parameter temp storage file simulation ... 9.2 LLOSSP.... 1.1 altering performance ... 1.1, see control 12.1 12.2 ‘TERMINPUT ... 2.4 test ... 2.4, 12.2, 12.9 TRANSACTION ... 2.2, 2.4 DTR installation ... 1.1 1.2, 11.2, 12.7, 18.1 INDEX Release 3.0 December, 1987 LLXXCICs CICS Simulation Utility invocation CMS ... 2.1 TSO... 2.1 MS command ... 2.7 Data Capture Utility CMS ... 3.2 TSO... 3.2 OS JCL... 2.6 running batch utilities interactively CMS... 2.8 TSO... 2.9 MVSKA CICS... 8.1 Operation Batch ... 10.1 batch-test mode ... 10.1 temp storage file simulation ... 10.2 transient data file simulation ... 10.2 CMS... 9.1 temp storage file simulation ... 9.2 transient data file simulation ... 9.3 TSO... 1.1 temp storage file simulation ... 11.2 terminal considerations ... 11.1 transient data file simulation ... 11.2 TSO/TCAM vs TSO/VTAM ... 11.2 LsRelease 3.0 December, 1987 0s JCL CICS Simulation Utility ... 2.6 OXBOOK ... 6.13 SYSIN OXBOOK ... 6.13 OXEXPORT ... 5.16 OXFORMAT OXIMPORT .. SYSIPT CICS Simulation Utility ... 2.6 SYSLST CICS Simulation Utility ... 2.6 OXBOOK ... 6.13 OXEXPORT ... 5.16 OXFORMAT ... 4.10 OXIMPORT ... 5.17 SYSPCH OXBOOK ... 6.13 OXEXPORT ... 5.16 4.10 5.17 SYSPRINT, OXBOOK ... 6.13 OXEXPORT ... 5.16 OXFORMAT ... 4.10 OXIMPORT ... 5.17 OSPACE ... 9.3, 10.2, 11.2 LLMAGBL macro DTR installation ... 1.2 system data space ... 1.2 control cards ... 1.2 OXBOOK ... 6.1 CAT... 6.1 control cards ... 6.1 . 6.13 UFOMGL... 6.1 Lé OSPUG1287 OXEXPORT ... 5.1 control cards action ... 5.1, 5.5 slobal ... 5.15.2 SCL Considerations ... 5.11 CMS ... 5.12 DOS... 5.14 OS... 5.16 TSO... 8.18 YM Considerations DOS ... 5.15 OXFORMAT ... 4.1 CAT... 4.1 control cards action .. 4.1, 4.3 examples ... 4.5, global .. 4.1-4.2 JCL Considerations ... 4.7 CMS ... 4.8 ‘ICL Considerations ... 5.11 CMS ... 5.13 DOS ... 5.15 PAINT... 1.1 bateh-test mode ... 10.1 CMS ... 9.1 OXFORMAT... 4.1 TSO... 11.1 PAINT panels PNTSPCE ... 1.2 PNTPNL ... 13.1 PNTSPCE internal files ... 1.2 PNTSPCE internal files PNTPNL ... 1.2 LLMAGBL macro DTR installation system data space control cards .. INDEXosPuGi287 remote file access UFO/Forms High-Performance LLOSSP ... 8.2 security codes UFO/Forms ... 7.9 Source Library Utility ... 6. start positions CAT group processing ... 7.10 see OXBOOK sySIPT LLOSSP CMS ... 9.1 TSO... 11.1 SYSLST.... 2.4 batch-test mode Data Capture Utility ... 2.4 LLOSSP CMS ... 9.1 TSO... 11.1 system data space CATSPCE ... 1.2 TCAM vs VTAM TSO ... 11.2 temp storage ... 8.2, 9.2, 10.2, 11.2 CICS... 8. file simulation ... 11.2 batch ... 10.2 CMS ... 9.2 LLMAGBL macro ... 9.2 TSLEVEL parameter... 9.2 TSO... 11.2 terminal considerations TSO Operation ... 11.1 transient data ... 9.3, 10.2, 11.2 file simulation ... 9.3, 10.2, 11.2 batch ... 10.2 9.3 12 INDEX Release 3.0 December, 1987 TSO LLOSSP SYSIPT... 11.1 SYSLST.... 11.1 Operation ... 11.1 CAT... 11 COBOLXE ... 11.1 LLOSSP ... 11.1 PAINT... 11.1 temp storage file simulation ... 11.2 terminal considerations ... 11.1 transient data file simulation ... 11.2 TSO/TCAM vs TSO/VTAM ... 11.2 UFO/Forms ... 11.1 UFOMGL ... 11.1 TSO commands CICS Simulation Utility ... 2.8 OXBOOK ... 6.13 OXEXPORT ... 5.18 OXFORMAT OXIMPORT SYSIN CICS Simulation Utility ... 2.8 OXBOOK ... 6.13, OXEXPORT ... 5.18 OXFORMAT ... 4.11 OXIMPORT ... 5.19 SYSIPT CICS Simulation Utility ... 2.8 SYSLST CICS Simulation Utility ... 2.8 OXBOOK ... 6.13, OXEXPORT ... 5.18 OXFORMAT ... 4.11 OXIMPORT ... 5.19 SYSPCH OXBOOK ... 6.13 OXEXPORT ... 5.18 SYSPRINT CICS Simulation Utility ... 2.8 TWASIZE ... 12.9 L7Release 3.0 December, 1987 UFO-CAT conversion program ... 7.1 CAT... 7.1 control cards ... 7.1 space ... 7.2 view ... 7.2 UFO/Forms ... 7.1 UFO-CAT interface ... 7.11 UFO/Forms remote file access High-Performance LLOSSP ... 8.2 TSO... 11.1 UFO-CAT conversion program ... 7.1 18 OsPUG1287 UFO/4GL. batch-test mode ... 10.1 CICS ... 8.1 CMS ... 9.1 OXBOOK ... 6.1 TSO... 1.1 user dictionary exit ... 7.11 XA Support, CICS... 8.1 INDEX