About Generation

External objects can be generated from Predict objects.

There are basically two types of external objects:

• external objects owned by Predict (usually stored in the FDIC file)

• external objects not owned by Predict (usually stored in the external environment).

This document covers the following topics:

• Concepts of Generation

• Overview of Generation Functions

• Calling Generation Functions

• Generation Defaults

• Storage of External Objects Owned by Predict

• Common Parameters

Concepts of Generation

Data definitions generated from Predict objects are called "external objects". Two types of external objects can be generated:

• external objects owned by Predict

• external objects not owned by Predict.

External Objects Owned by Predict

• 3GL copy/include code (C, COBOL, Assembler, FORTRAN, PL/I)

• Adabas invert, compression and security definitions (ADAINV/ADAWAN/ADAFDU, ADACMP, ADASCR)

• SQL CREATE statements

• Adabas/VSAM transparency table

External objects owned by Predict are used at compile time and have to be copied (punched) to an operating system library before they can be used in the implementation of an application. Copying can be performed by Entire System Server or the Preprocessor.

A variety of parameters determine how these types of external objects are stored. See Parameters Specifying the Form of Output.

External Objects not Owned by Predict

• Databases (Adabas, DB2, IMS/DL/I)

• Vista translation table

• DB2 tablespaces and storagegroups

• DB2 procedures and functions

• Files, tables and views (Adabas, DB2)

• IMS User-Defined Fields (UDFs)

• Natural DDMs (including Natural security definitions and/or Super Natural files).

External objects not owned by Predict are used at run time. Some of these objects are stored directly in the application environment, others are stored in the Predict system file. For objects that are stored in the Predict system file, Predict data must be accessible when an application using the external objects is running.

Connecting External Objects and Documentation Objects

An external object that has been generated from a documentation object is regarded as connected to the documentation object. The connection is established by adding an implementation pointer to the documentation object. External objects and documentation objects that are connected are - to a certain extent - protected from being modified independently from each other.

See also Handling of External and Documentation Objects in this documentation.

Overview of Generation Functions

The following table is sorted by the code used to call a generation function from the Predict main menu.

Calling Generation Functions

Generation functions are called with G in the field Function and the appropriate code in the field Object Type in a Predict main menu or with a command. The following rules apply:

• All generation functions can be executed both online and in batch mode.

• If a system is not installed, the respective generation functions are not available. For example, if DB2 is not installed at your site, no generation functions for DB2 objects are available.

Calling Generation Functions with Commands

• Parameters are entered on the line following the command.

• Parameters can be entered in positional and/or keyword form. See the section Predict Commands in the Predict Reference documentation.

• To use the default parameters defined for the function, enter the command and the object-ID on the same line. This does not apply in batch mode.

• Some generation functions can be called with two or three commands. It makes no difference which command is used.

Generation Condition Codes

Condition codes are described in the section Predict in Batch Mode in the Predict Administration documentation.

Generation Defaults

Default generation values are set at installation. Most default values are displayed in the input screen of the respective generation function and can then be overwritten for temporary use. Changes to default values apply to subsequent generation runs until another Predict function is executed. This does not apply in batch mode.

The following rules apply for the use of default values for generation parameters:

• Default values of generation parameters can be changed with the function Generation Defaults in the Modify Defaults menu or the command DEFAULT object-code. For example: DEFAULT COBOL displays the Modify COBOL Defaults screen shown below.

  13:35:47 ***** P R E D I C T ***** 2007-05-31 - Modify COBOL Defaults - Modified 2007-05-31 at 13:31 by CHD Mark with 'X' the options which may be modified by the user. X Save as member ........... X Save in library .... COBLIB X Overwrite option ......... Y (Y,N) X Op. system member .. X Punch / output ..........* N X List offsets ......* N X List generated code ...... Y (Y,N) X Adabas version ....* I7 X Generate format buffer ..* N X Field name prefix .. X Check field names .......* Y X Field name suffix .. X Start level .............. 1 (0-40) X Validate ........... - X Level number increment.... 1 (1-40) X Truncation ........* R X Level shift increment .... 3 (0-9) X With Cond. names ... Y (Y,N) X Nr. of abstract lines .... 5 (0-16) X Indexed by ........* N X Generate initial value ..* N X Literal delimiter .* S X Synchronized ............* Y X Decimal character .* P X Depending on ............. N (Y,N) X Redefinition name .* S X Record buffer name ....... X Format buffer name ....... Compiler ..........* 7 Preprocessor force ....... N (Y,N) Library system ..... 2

• Generation defaults can be protected by blanking out the "X" preceding the parameter in Modify ... Defaults screens. Protected default values cannot be changed when executing a generation function. The fields of protected parameters are locked in the input screen of the generation function. These fields are skipped when positioning the cursor with the TAB key.

• Some default values are not displayed in the input screen of a generation function and can therefore only be changed using the Modify Generation Defaults function. These parameters are described under Presetting in the descriptions of individual generation functions later in this section.

• For Predict-owned external object types you can specify default values for storing generated code. See Specifying Entire System Server and z/VSE Librarian Options.

For a description of the parameters shown in the previous screen, see the relevant generation functions later in this documentation, the parameter Preprocessor force is described below.

Preprocessor Force

This parameter is used by the Predict Preprocessor and Adabas Native SQL. It can be specified for Assembler, COBOL, FORTRAN, PL/I, and ADA. It can only be defined in the respective Modify Generation Defaults screen.

Valid values:

Storage of External Objects Owned by Predict

There are different options to output/store external objects owned by Predict. The following types of external objects are owned by Predict:

• 3GL copy/include code (C, COBOL, Assembler, FORTRAN, PL/I)

• Adabas invert, compression and security definitions (ADAINV, ADAWAN/ADAFDU/ADACMP, ADASCR)

• Adabas/VSAM transparency table

• SQL CREATE statements.

Output / Storage Options for External Objects

Option 1 - Generating External Objects Temporarily

This option is used to have a first look at the results of a generation function. To generate objects temporarily the parameter Save as member is left blank. The parameter List generated code determines what is displayed.

Option 2 - Storing Generated External Objects as Members in a Natural Library of the Predict System File

If the parameter Member name is specified, the generated external objects are stored in a Natural library in the Predict system file (FDIC). The library must be specified.

For each file you can save up to 30 members per language. For DB2 objects (these are not owned by Predict) a generation protocol can be created and stored in Predict by specifying the parameters Protocol saved in member and Protocol saved in library.

Members in a Natural library that have been created with generation functions can be read by the Preprocessor or written to workfile 1 using the command PUNCH or WRITE. See description of PUNCH/WRITE command in the section Predict Commands in the Predict Reference documentation and section Preprocessor in this documentation.

Option 3 - Storing Generated External Objects Additionally in a Workfile or - with Entire System Server - as an Operating System Member

External objects can additionally be stored by Entire System Server as operating system members. The following rules apply:

• Storage by Entire System Server can only be executed in addition to storage in the Predict system file (Save as member parameter must be specified).

• Storage of generated external objects as operating system members is only possible in a z/OS or z/VSE environment.

• If Library system is set to 3, the external object is stored additionally in a z/VSE Librarian library.

• One operating system member can be stored for each member in a Natural library that has been generated by a generation function.

• External objects are not processed by Entire System Server if errors occur during the generation.

Parameters Specifying the Form of Output

Parameters specifying the form of output of external objects owned by Predict are described below. Each parameter applies to different data storage options.

Storing External Objects with Entire System Server

External objects owned by Predict can be stored directly as a member in an operating system library (partitioned data set) in a z/OS and a z/VSE environment if Entire System Server is available. This option is used by setting the parameter Punch/Output to P or S. If Punch/Output is set to S additional parameters can be specified in a subsequent screen. See Specifying Entire System Server and z/VSE Librarian Options.

Additional storage of generated code with Entire System Server is notified in the generation log of the Predict file object from which the code was generated. The following rules apply:

• In a z/VSE environment
  Members are identified by member name and member type. Members of different types can therefore have the same name. The code is stored as member in a z/VSE library. The following prerequisites must be met:

  • Librarian utility must be installed (z/VSE/SP2 or above)

  • library and sublibrary must be defined in z/VSE

  • member type must be specified.

• In a z/OS environment
  Members are identified by name only. The code is stored as a member in a partitioned data set. The data set must be allocated. It is recommended that the data sets are cataloged. In this case, the VOLUME name need not be specified.

  Note:
  Parameters that have to be specified when storing generated code with Entire System Server are described in the section Specifying Entire System Server and z/VSE Librarian Options.

Using Entire System Server in Networks

Generated code can be stored in operating system libraries residing in remote environments. In this case Entire System Server calls are distributed by Software AG's Entire Net-Work facility.

Prerequisites for Using Entire System Server

• Depending on the setup parameters specified during installation of Entire System Server a LOGON is required.

  • Online, the LOGON is requested if necessary.

  • In batch mode, specify a logon command before the first Entire System Server command:

    NPRLOGON <userid>,<password>,<Entire System Server database-id>

    for example:

    NPRLOGON AZ,XYZ,ENTIRE-SYSTEM-SERVER

    To prevent the password being displayed in SYSOUT in batch mode, enter the terminal command %* before NPRLOGON.

• The database number 148 must be defined as Entire System Server in the Natural Parameter module by the NTDB macro (NTDB PROCESS,148). The Entire System Server node can have a number other than 148, because the node number is always specified when an Entire System Server access is performed in Predict. In this case there must be an additional PROCESS node definition in the Natural parameter module.

• Predict supports multiple Entire System Server nodes. If the generated code is to be written by Entire System Server, the Entire System Server database ID must always be defined and the node number is filled with the logical database number.

Regenerating Code Handled by Entire System Server

When regenerating code that has been processed by Entire System Server, the members stored in a library or partitioned data set must be updated to ensure consistency.

Code can be regenerated with either the same or with different Entire System Server options:

• When regenerating code without changing the operating system member name, the Entire System Server options used for the previous generation are inserted in the generation screen (under the prerequisite that the options are valid according to the relevant defaults). See Specifying Entire System Server and z/VSE Librarian Options.

• To regenerate code with different Entire System Server options, set thePunch/Output option to S. The options can then be changed in the second screen.

  Example: A new Op. system member is specified. As the result the old operating system member is deleted and a new member is created.

If code is regenerated for which an operating system member was generated in a previous generation, and the Punch/Output option is set to N or Y, this will cause the operating system member to be deleted after a warning has been issued. The contents of the member will not be compared.

If code is regenerated and the operating system member documented in the generation log of the Predict file object is not found (this means that the member was deleted by an operating system utility) the code can be written to a new member or the generation log of the file is deleted depending on the Punch/Output option.

If Entire System Server is deinstalled, the generated code can be regenerated and the link in the generation log of the file is deleted. If Entire System Server is temporarily not active (example: response code 5999), the generation function for this member is rejected. If it is necessary under these circumstances to change this generated code (saved with the current member and library name), it must be deleted with the Predict function Administration Implemented File.

The table below shows the effects of different generation settings when working with Entire System Server:

¹⁾ Field Save as member filled with valid value

²⁾ Parameter Punch/output = P or S

Specifying Entire System Server and z/VSE Librarian Options

Additional parameters must be specified if generated external objects are written to an operating system member with Entire System Server (Punch/Output=S) or are written directly as members in an z/VSE librarian library (Punch/Output=Y and Library system=3).

    13:59:30             *****  P R E D I C T  *****                     2007-05-31
                         - Punch / Output Default Options -
                                                       Modified 2007-05-31 at 13:28
                                                             by CHD
    Mark with 'X' the options which may be modified by the user.
   
    X Entire System Server Database ID ..* PROCESS-148
   
    MVS Entire System Server Defaults
    X Data set ...........
    X Volume .............
   
    VSE LIBRARIAN Defaults
    X Library ............
    X Sublibrary .........
    X Member type ........
    X VSAM catalog name ..          ( Required for Entire System Server)
   
    Previous entered default options
      Op. system member ..
      Library system ..... 2
      Punch / output ..... N
   
   

Values for fields which have been locked by your data dictionary administrator cannot be overwritten. These fields are skipped when positioning the cursor with the TAB key. See Generation Defaults.

Specify library system Librarian (z/VSE) by setting option Library system to 3. Generated code written to workfile 1 is prepared for use as input of Librarian (z/VSE) system: ACCESS and CATALOG statements are inserted at the beginning of the generated code.

Common Parameters

The parameters Adabas version and Preprocessor force can be specified with many generation functions. Preprocessor force can only be defined in the respective Modify Generation Defaults screen.

Adabas Version