1. The first step in setting up Dataviews is to determine if existing definitions are available in other forms such as COBOL copy books and DB/2 catalogues. Also any existing VISION:Builder, VISION:Inquiry or VISION:Results definitions can be used. These existing definitions can be converted on-line, under ISPF, via the Definition Processor. (If you prefer to complete the DB2 definition or COBOL copybook conversions in batch then proceed with step 2 below.) Now logon to TSO and start ISPF. From ISPF select the option to enter the Definition Processor. Choose option 19 from the main menu of the Definition Processor, select the type of definitions to be converted to Dataviews and complete the conversions. Skip to step 3 below.
2. In lieu of using the on-line import utility for DB2 definitions and COBOL copybooks, the appropriate Quick Start utility may be run for definition conversion. These utilities are documented in the VISION:Inform Utilities section of the SYSTEM ADMINISTRATION manual. The Quick Start utilities will convert the definitions into Dataviews that VISION:Inform can use.
3. The next step is to make the appropriate modifications to the Dataviews by editing them with the Definition Processor.
4. Select option 21 for Dataview access. After choosing which Dataview to edit and which file type it represents you are presented with the list of segments. (If the file type chosen is GDBI then review knowledge document TEC1073884 “Generating Mapped Definitions”.)
5. Select the first segment and specify which field(s) make up the key placing a number, 1 through 9, in the Seg Key Field column for that field. If the fields are more than the maximum field size of 255 bytes then additional fields will be required to define the bytes greater than the maximum. Repeat this step for each segment.
6. The Field Names generated by the COBOL Quick Start utility are named for internal use but can be modified if desired. The Alternate Field Names, which are found by selecting the field name, are created from the COBOL field names and can be modified if desired.
7. After all Dataviews have been set up the promote job PROMDF1 will need to be executed. PROMDF1 updates the appropriate VISION:Inform libraries with the specified Dataviews. Please refer to VISION:Inform Utilities section of the VISION:Inform SYSTEM ADMINISTRATION manual. PROMDF1 is found in sub-section 7 on page 7-1. If Logical Data Views (LDV) are being defined with attached Procedures the PROMDF2 job must also be executed. PROMDF2 is found in sub-section 8 on page 8-1 VISION:Inform Utilities section of the VISION:Inform SYSTEM ADMINISTRATION manual.
8. After the promote process is complete the user(s) must be given access to the Dataviews they require. This is done on-line via the TP Monitor under which VISION:Inform has been installed, CICS or IMS. The system administrator initiates the appropriate transaction and logs onto VISION:Inform to setup or modify the user PROFILE information. (Please refer to VISION:Inform SYSTEM ADMINISTRATOR’S GUIDE, section 3, of the VISION:Inform SYSTEM ADMINISTRATION manual.)
9. The user is now ready to build and submit queries to access data.
10. Before queries can be executed the Background Processor must be prepared including JCL and run parameter customization. (Sample JCL is provided via the EXECOS or EXECDLI members in the VISION:Inform JCL library created during the installation. Choose the appropriate member by checking with Appendix A in the VISION:Inform INSTALLATION AND SUPPORT manual.) Make any required changes to the run parameters in the OSCNTL member of the SRCLIB library created during system installation. These processes are documented in the VISION:Inform SYSTEM ADMINISTRATOR’S GUIDE, section number 4, of the VISION:Inform SYSTEM ADMINISTRATION manual.
11. During setup of the Background Processor note that there are 4 files that must be unique and pre-allocated for each Background Processorthat is created. These are the files associated with the M4REPO, M4REPI, M4SORT, ASVLOG DD statements and the SRCLIB member OSCNTL. Also, if Background Processors will be run simultaneously, then the SRCLIB member which contains the run parameters must be unique. The OSCNTL member contains the control statements that are input into each Background Processor for specific control of its query processing and must contain a unique name for each Background Processor.