Generating Mapped Definitions for VISION:Inform

Products

• Vision:Inform

Issue/Introduction

How to generate mapped definitions for VISION:Inform?

Resolution

The Generalized Database Interface -GDBI- can be used to access any non-proprietary database. 

1.  If GDBI is needed to access a third party database, first  create a COBOL copybook definition by creating the record definition from the database dictionary, placing it into a PDS, and eliminate any comment lines from the definition that is now in the PDS.
2.  Run the COBOL Quick Start utility that is documented in the VISION:Inform Utilities section of the SYSTEM ADMINISTRATION manual or logon to the DEFINITION PROCESSOR and select option 19 to execute the on-line import of  the COBOL copybook.  The COBOL Quick Start utility or the on-line import utility will convert the COBOL copybook definition into a Dataview that VISION:Inform can use.
3. Make the appropriate modifications to the Dataview by editing it with the DEFINITION PROCESSOR which is accessed from ISPF.  Logon to TSO and then from the ISPF main menu select the option for the DEFINITION PROCESSOR.
4.  Select option 21 for Dataview access.
5. For GDBI select option 12.
6. If accessing IDMS the subschema name is required in the File Identification field. A number large enough to include the entire root segment, all virtual segments and maximum size of all occurrences of all lower level segments must be entered into the Record Length field.  The name of the INIT Procedure, such as EMPLINIT, must be entered into the Initialization Procedure field and the name of the TERM Procedure, such as EMPLTERM, must be entered into the Termination Procedure field.  The optional field Updater Id can contain a userid or some identifying eight character name while theoptional field Expiration Date can contain the date after which this definition may be dropped from the Background Library.
7. If a single database record, that contains no recurring data, is being defined then only one Segment Name is required and would have a Segment Level of 1 and Segment Number of 1.  If the database record contains recurring data then all of the data, down to the first instance of the recurring data, would be Segment Level 1 and Segment Number 1.  This is known as the Root segment.  Each of the remaining groups of recurring data or non-recurring data are to be defined as separate segments.  The next Segment Level would be 2 and the Segment Number would increase by 1 or more, depending upon your preference, with each segment.  If recurring data itself contains recurring data then the Segment Level is also incremented by one for the subordinate, or CHILD, segment.  That segment would take a Segment Number greater than the number used by the recurring data to which it is subordinate, or its PARENT segment.  (Recurring data is known as a CHILD segment and the data to which the CHILD segment is subordinate to is known as the PARENT segment.)
8. Next place a “Y” in the +Specify Procedures?  column for the first (root) segment to specify the names of the procedures that will be called to control execution of the CALL statements that will retrieve data from the database.  Names such as EMPLFKEY, EMPLFRST, EMPLNEXT and EMPLKEY could be used to identify the data represented and the type of call being issued.  Do this for each of the remaining segments in the Mapped Definition.  The Mapped Procedure names may be the same as those used by the root segment if those Mapped Procedures are set up generically.  (Single Mapped Procedures could handle all functionality or individual Mapped Procedures could handle specific functions.)
9. Next select the first segment and specify which field(s)  make up the key by placing a number, 1 through 9, in the Seg Key Field column for that field.  Repeat this step for each segment.  It can also be helpful to add a field that is defined, such as SEG01, beginning in Field Loc 1 for the length of the entire segment.  This is done for ease of moving the entire segment, or major portions of it, instead of moving each field individually.  If the segment is more than 255 bytes, which is the maximum field size in VISION:Inform, then additional fields will be required to complete the entire length of the segment.
10. 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.
11. The Mapped Procedures can now be set up.  (Please refer to VISION:Inform CONCEPTS, section number 9, of the VISION:Inform SYSTEM ADMINISTRATION manual.)
12. After all Mapped Definitions and Procedures are completed the promote jobs PROMDF1 and PROMDF2 will need to be run.  PROMDF1 updates the appropriate libraries with the Mapped Definition and PROMDF2 updates the appropriate libraries with the Mapped Procedures.  (Please refer to VISION:Inform UTILITIES, sections number 7 and 8 of the VISION:Inform SYSTEM ADMINISTRATION manual.)
13. 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.)
14. The user is now ready to build and submit queries to access data.
15. 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 in 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.
16. During setup of the Background Processor note that there are 4 files that must be unique and pre-allocated for each Background Processor that 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.