Migrating Predict Objects

#### Search Results

Search

# Migrating Predict Objects

Software GmbH's active data dictionary system Predict is used to supply information needed by applications defined to PAC:

- Natural views/DDMs and rules are generated from Predict files, userviews, and verifications to supply the subordinates needed to compile Natural objects.

- Predict cross-reference (Xref) data is created for Natural objects when they are compiled and is used for building and documenting interrelationships among objects.

When migrating objects from development or maintenance status types, the Expand function is valid only if the cross-reference data exists for the object on the Predict file specified for the application status link. The EXP (Expand) command and special options of the SEL (Select) command use cross-reference (Xref) data from Predict for migrations from development, maintenance, and incorporation status types; for all other migrations, cross-reference data from PAC is used.

This document covers the following topics:

- Migrating Predict Data Into and Out of PAC

- Migrating Predict Data Within PAC

- Reports About Versioned Predict Objects

## Migrating Predict Data Into and Out of PAC

Predict objects are migrated or copied into the PAC controlled environment. Predict objects can subsequently be unloaded from PAC into an external Predict file. A PAC administrator can remove Predict objects from PAC when they are no longer needed.

The migration event that loads Predict objects into PAC must be run separately and before the event that migrates the Natural application objects that use the Predict objects.

Notes:

1. To bypass this step, views/DDMs that exist in catalog form external to PAC can be incorporated into PAC without being regenerated. Because views/DDMs are considered Natural objects, this is a Natural migration.
2. You can also bypass this step for views/DDMs that exist in an external versioning tool. These can be incorporated into PAC without being regenerated. This requires an event for a Predict application from External to Control status. The value for SYSDDM utility in the Protection option of the System Defaults must be set to A (Allowed) for this alternative to work. See Protection in the General Defaults section of the Predict Defaults part of the Predict Administration documentation for further details.

The following example PAC jobs migrate only Predict objects:

- Predict_MIGRATE_IN JCL/JCS migrates Predict objects from an external Predict system file (FDIC) into PAC;

- Predict_MIGRATE_OUT JCL/JCS migrates Predict objects from PAC to an external FDIC file.

For Predict migrations into PAC, any objects that require it are generated or regenerated automatically in PAC as part of the migration.

For Predict migrations from PAC to an external FDIC file, such objects are migrated but not automatically generated or regenerated. The objects must be manually generated or regenerated in the external FDIC file after the successful completion of the migration event.

### Origin of Predict Objects

For the reserved Predict application (see Predict Application), PAC acquires the Predict data dictionary information for each status defined to PAC from the Predict system file (FDIC). The FDIC file is identified by a database number (DBnr) and file number (Fnr).

PAC can be populated with any data dictionary information except user-defined entity objects (UDEs).

Certain data dictionary information must be migrated into the PAC controlled environment using the Predict migration utility SYSDICBE (userviews, files, verifications, keywords, help text), while other information is copied into the PAC environment as needed (generation default sets and linked databases).

Sets of generation defaults are used when generating PAC views/DDMs and rules from Predict files, userviews, and verifications. You must log on to Predict to create or maintain the sets of generation defaults, which are then copied into the PAC controlled environment where the actual generation occurs.

You must also log on to Predict to maintain the Predict keyword subsystem. Refer to the Predict documentation for more information. Keywords created in Predict can be migrated to PAC because the PAC keyword system is sufficiently similar. However, keywords defined within PAC for use as selection criteria within the PAC reporting subsystem are maintained separate from the Predict keywords.

Predict help is documented in Predict and stored on the FDIC file; certain applications may require access to this information at execution time.

### Interaction With the PAC System Files

The PAC PCF system file is a work area with the same file structure as a Predict FDIC file. Any Predict files, userviews, and verifications used to generate PAC views/DDMs and rules are migrated to the PCF file from the Predict FDIC file using the Predict migration utility SYSDICBE.

Sets of generation defaults and any linked database information that may be specified for the sets is copied from the Predict FDIC file to the PCF system file by the PAC administrator.

A specific set of generation defaults may be specified for use during the generation phase of a Predict migration, based on the Predict objects being migrated. If no specific set is specified, the generation defaults set named DEFAULTS is used.

PAC views/DDMs and rules are actually generated in the PCF system file. The new versions of the Predict objects that are required during the compilation of Natural objects are stored in the PCF system file.

After the executable code has been generated for the PAC views/DDMs and rules, the versioned source used to generate them is copied to the ACF system file for documentation and reporting purposes.

### Using the Predict Migration Utility SYSDICBE

Predict files, userviews, and verifications are loaded into the PAC controlled environment using the the Predict migration utility SYSDICBE, rather than the PAC migration utilities (MIGUNLD, MIGLOAD).

| Warning: Do not use SYSMAIN, INPL, NATLOAD, or MIGLOAD directly to load views into the PAC environment (PCF file); this will cause a loss of data integrity in PAC.

- When initially invoked from PAC, the Predict SYSDICBE utility unloads Predict objects to a work file from the FDIC file specified on the application status link definition.

- When restarted, it loads

  - those Predict objects used for generation (files, userviews, verifications, databases) from the work file to the PCF system file.

  - all other Predict objects from the work file to the ACF system file where they are labeled as versioned Predict objects.

A defined interface allows PAC to communicate with the Predict migration utilities and vice versa. Using this mechanism, the different requirements for migrating the Predict objects are handled as effectively and consistently as with any Predict migration without PAC.

When using the Predict migration utility to migrate Predict data from the PAC controlled environment, the migration unload from PAC is processed in the same way as the migration load, ensuring consistency with the Predict data whenever the data are migrated from status to status.

During the unloading and loading of Predict objects, control can be given to PAC at specific points to verify the state of the migration and to issue checkpoints. These checkpoints are useful for restarting Predict events because PAC will ensure that each event process restarts from the step that was active during the previous termination.

If Predict incurs any errors while processing the Predict migration load step, it calls PAC to record the information about the error in the event audit report. This information is written at the bottom of the report at the time of termination and can normally be used to help identify problems with Predict migrations.

Note
For the os_PREDICT_MIGRATE_OUT job (where os must be replaced by the corresponding operating system notation, for example MVS_PREDICT_MIGRATE_OUT for the MVS job), workfile 6 is mandatory, if the transfer list contains Predict objects from Predict Version 3.4 or below. If the transfer list contains only Predict objects from Predict Version 4.1 or above, workfile 6 is not required.

### Generating Views/DDMs and Rules

Rules and views/DDMS are the means by which Predict files, userviews, and verifications are linked with Natural objects. Predict objects are the source; rules and views/DDMs are the cataloged objects used as subordinates by the Natural objects.

Although handled as Natural objects, these rules and views/DDMs are still linked to their origin in Predict. They are stored on the FDIC file.

During generation, the information about generations is recorded in the event audit report.

#### Setting Up the Predict Generation Defaults

Defaults for generating views/DDMs and rules are defined and maintained in Predict. Sets of generation defaults (verification and DDM) can be copied to PAC; however, the values for these defaults are not modifiable in PAC and therefore must be changed in Predict before being copied into PAC.

The PAC administrator may copy different sets of Predict generation defaults into PAC. Sets of defaults are assigned specific names for use with migrations of Predict data into PAC. They are saved and stored on the PCF system file. If a list of linked databases has been specified for a specific set of generation defaults, these linked databases will also be included with the defaults as shown in the following diagram:

#####

#### Sets of Generation Defaults

When PAC is initialized, a set of Predict generation defaults called DEFAULTS is automatically defined for use with migrations of Predict data into PAC. The generation defaults copied are those defined in Predict at the time PAC is initialized.

The defaults to be used with a Predict migration event to generate views/DDMs and rules can be specified during authorization by entering the name of a set of defaults previously copied and stored on the PCF system file. If a specific set is not specified for a migration of Predict data into PAC, the default set DEFAULTS is used.

If the specified set or the DEFAULTS set itself cannot be found (that is, has been removed or does not exist) at the time the migration is processed, an error will occur indicating the name of the set that was specified and that it does not exist.

#### Linked Databases

Predict generation defaults for Adabas files may have up to ten (10) databases to which files may be linked. The Adabas Subsystem Specification DB-ID parameter in the stored generation defaults determines whether a linked database is required; if so, a database number (DBnr) is assigned to the generated view/DDM .

Predict determines if a specific database is required for the generation of views/DDMs based on the value of the Specification DB-ID parameter and on the names of databases linked to the specified generation defaults set. Adabas files can be linked to one database, to several databases, or to no database.

The action taken by PAC depends on whether the value of the Specification DB-ID parameter in the stored generation defaults is N or Y:

N(o) | PAC generates a DDM with DBnr=0, even if the file is linked to several databases.
Y(es) | Before the files can be generated, Adabas files must be linked to one or several databases that were previously migrated into PAC (although the required databases may be migrated at the same time as the files as part of the same migration event). PAC generates the views/DDM based on the number of the appropriate linked databases by scanning the linked database list. If the databases required for specific file generations have not been migrated into PAC, Predict terminates the migration.

If the user exit PACEX037 is active, PAC invokes the exit before the generation command is built to determine the linked database to be used for the view/DDM generation. If no linked database is found or the Specification DB-ID=N, a blank is passed to the exit. Depending on the value of Specification DB-ID, the user exit may then verify, override, or reset the appropriate linked database name by scanning the linked database list.

### Predict Object List

The Predict migration event migrates only Predict objects; that is, the object list may contain only Predict objects. Natural objects may not be included in a Predict object list.

Views/DDMs and rules are required during the compile of Natural objects; they are treated as Natural objects and occur on Natural object lists. They may be identified in the Predict object list in terms of files, userviews, and verifications; that is, in terms of the Predict objects used to generate them.

PAC provides specific applymods and user exits for additional customization of the list.

#### Building Object Lists

There are several options for building a list of Predict object types. If you want to migrate only a few objects, it may be more useful to enter the individual objects "manually" in the Object List Editor; however, if you want to migrate large numbers of objects, the generation facilities can be used to avoid the errors that could occur when manually entering objects.

Because of the nature of the Predict migration utility, a single entry in the Predict object list may result in numerous Predict objects being processed. For example, if the Predict type FILE (F or C) is specified for an object in the object list, Predict automatically unloads the file together with all of the verifications and userviews linked to the file, and generates new automatic rules and DDMs for each object.

Note
The conditions required for successful generation of Predict objects and the object types that do or do not require generation are determined by Predict. Refer to the appropriate Predict documentation for more information.

If only userviews and/or verifications are required for the object list, they should be individually placed in the list and the file itself should be omitted. The parent file (F or C) must have been previously migrated into PAC; otherwise, Predict will terminate the generation with an error.

#### Manually Creating the Object List

An object list may be created "manually' by entering each object on the Object List Editor.

To prevent ambiguities, the object name and type must be explicitly specified. The name of an object or a range of objects may be specified. An asterisk (*) or range notation may be used to specify a prefix or range of objects.

#### Selecting and Expanding Objects for the Object List

The Select option (SEL command) and the Expand option (EXP command) can be used on the Object List Editor to build the object list for Predict objects to be migrated into PAC.

You may use the SEL command to add Predict objects to the object list, either alone or when you are specifying objects manually on the Object List Editor. The objects presented for selection will be read directly from the Predict FDIC file specified in the development or maintenance status link definition. Selection is based on the specified object name, type, and range date or the date modified. Range notation or an asterisk (*) may be used to limit the list of objects returned.

The EXP command can be used to include in the object list all files linked to a database. A database can be expanded to include its files using the EXP command. However, files will be expanded to include the userviews and automatic verifications during migration. EXP is valid for databases when they are entering PAC from development or maintenance status types.

#### Generating the Object List

The list of Predict objects may be generated "automatically" using the PAC object list generation facilities either online or in batch. Automatic generation is only possible when the origin is Control, a test, or a production status.

When you are adding a migration event, you may specify a generation option online by providing a GENTYPE value of P in the Generate List field of the Add Event screen.

When you want to generate the object list for an existing migration event or regenerate the object list, use the GENLIST command while modifying the event and specify the desired generation option.

The PACEX037 user exit can be invoked to control the views/DDMs and rules that are to be generated. For example, you may not wish to have an actual view/DDM generated for a file because only the views/DDMs of userviews are to be used by programming objects.

### Overview of Generating and Versioning Predict Objects

The process of generating and versioning Predict objects in PAC is outlined in the following diagram:

#####

#### Explanation of Steps in the Diagram

Step | Action
--- | ---
1 | Generation defaults Predict Predict generation defaults Generation defaults are copied from the Predict FDIC file to the PCF system file; if applicable, the PAC administrator specifies linked databases for some or all sets of generation defaults copied.
2 | SYSDICBE utility The migration event is created; PAC validates the object list and creates unload commands to be processed by the Predict migration utility SYSDICBE. The generation defaults to be used are identified in the migration event; the event is submitted.
3 | The SYSDICBE utility is invoked with the unload commands to create the migrate dataset (work file). With the SYSDICBE utility, one unload command normally results in the unload of several Predict objects (the parent object will be unloaded as well as all of its linked children).
4 | The SYSDICBE utility is restarted to load from the work file to the PCF system file any objects required for the generation of views/DDMs and rules (that is, Predict userviews, files, databases, and verifications).
5 | PAC loads all objects from the work file to the ACF system file as new versions.
6 | For all objects that will require generation, the appropriate Predict SYSDIC generate commands are created and entries are made in the generate list.
7 | Using the specified generation defaults, the generate commands are processed and the views/DDMs and rules are generated in the PCF system file; linked databases are determined. PACEX037 user exit Predict generation exit Predict generation user exit The PACEX037 user exit can be invoked to control the views/DDMs and rules that are to be generated. For example, if programming objects only use the views/DDMs of userviews, the generation of views/DDMs of files can be suppressed.
8 | The generated objects (views/DDms and rules) are copied from the PCF system file to the ACF system file where they are versioned. In versioning the Predict application objects, PAC inherently tracks the state of these objects; that is, whether they have been migrated to other statuses.

## Migrating Predict Data Within PAC

Once Predict data has entered the PAC controlled environment as versioned Predict objects or as Natural objects (views/DDMs and rules), it can be migrated throughout the PAC environment as part of a Natural migration.

### Statuses/Application Status Links

PAC is able to retain an interrelationship between Predict files, userviews, and verifications and the applications that use them.

The origin status of each application status link defined in PAC identifies the physical location of the Predict FDIC file where the Predict objects, cross-reference data, and generated Natural views/DDMs and rules are stored. You can override the location (DBnr/Fnr) specified in the status definition when you define the application status link.

### Locating Predict in Your Environment

You may use a single Predict FDIC system file for all environments or you may have different FDIC files in different environments.

You may locate FDIC files in the development, maintenance, test, and production environments. If you use different FDIC files in different environments and you make changes to the Predict data in any one of these environments, those changes will not be reflected in the other environments.

For example, suppose you have FDIC files in development, maintenance, and test. If you migrate Predict data through PAC, you could override more recent changes made in test or production with earlier data migrated from development or maintenance.

To maintain consistency across environments, it is strongly recommended that you make changes to the Predict data in a centralized location; that is, changes should be made in development or maintenance as required and then distributed to other locations throughout PAC.

Because this may not be possible for some sites, PAC does support a distributed Predict environment; however, PAC itself centralizes all Predict data.

#### Locating Predict in Development and Maintenance

The most likely locations for Predict are development (where the data is initially defined) and maintenance (where the data is maintained).

For instance, maintenance changes to PAC objects may require changes to the Predict userviews, files, and/or verifications needed to generate the views/DDMs and/or rules that must be used to recompile the PAC objects when they are returned from maintenance.

#### Locating Predict in Other Environments

Reasons for locating Predict in other environments are as follows:

- You may need Predict help at execution time for certain applications; this information needs to be readily available to the programs that use it.

- You may need to migrate VSAM DDMs for use at execution time.

- You may want to use Predict directly to generate files, for instance. Once files are defined in Predict, the actual files (FDT) can be generated for loading to the database.

- You may want to use Predict to maintain files using certain Adabas Basic Services functionality.

- You may want to locate Predict in an environment so that it reflects the state of all objects current for that environment; for example, you may locate it in production so that you can determine what the production versions of databases and files look like.

- You may need to have the cross-reference data of all objects in a particular status for deriving various statistical information.

Note
It is no longer possible to migrate Predict objects to a status of type (P). You can now attain the same functionality if you define a status of type (T) to a Predict application specifying the production FDIC as its location.
Creating a migration event for this migration path will ensure that objects of type Predict will be migrated to your production FDIC.

### Migration Path/Event

Predict application objects from development, incorporation, or maintenance must have a destination status of Control. Once the Predict data is in the Control status, it can be migrated directly to other allowed statuses.

### Cross-Reference Data

Cross-reference (Xref) data is available only with Predict Version 3.1 or above when the Predict Active References feature is installed.

The PAC Predict cross-reference sub-function allows you to obtain cross-reference information about application-linked Predict cross-reference objects such as the following:

- Programs

- Data areas

- Userviews

- Copy code

- Retained sets

Predict cross-referencing of Natural objects occurs only in the PAC Control status as part of a Natural migration. Xref information for Natural objects is created at compile time; it may optionally be migrated with Natural objects and stored at the destination as defined in the application status link.

#### Maintaining Cross-Reference Data

A migration event definition specifies whether

- cross-reference data is to be stored within PAC (Local);

- cross-reference data is to be copied to the Predict file specified by the application status link (Remote);

- cross-reference data is to be stored both locally and remotely;

- no cross-reference data is maintained.

The Predict Xref Menu is accessible from the Application Status Reporting Menu. Refer to the Predict User's Guide for more information.

#### Enhanced Predict Object Handling

It is necessary with the handling of Predict objects to correctly separate Predict files and DDMs. This change has resulted in some minor display and storage enhancements now being seen in PAC.

During a migration event of Predict objects, the audit report will show 'double' objects as follows:

    PAC6997: (A) Unload requested for DEMO_FUSER_31_VIEW (ADABAS View)
    PAC6997: (A) Unload requested for DEMO_FUSER_31 (ADABAS File)
    PAC6997: (A) Unload requested for DEMO_DA_164 (Database)
    PAC7057: (A) DEMO_FUSER_31_VIEW.0001 (ADABAS View) created
    PAC7057: (A) DEMO_FUSER_31_VIEW.0001 (User View) created
    PAC7057: (A) DEMO_FUSER_31.0001 (ADABAS File) created
    PAC7057: (A) DEMO_FUSER_31.0001 (User View) created
    PAC7057: (A) DEMO_DA_164.0001 (Database) created

Note that two of the original three objects (DEMO_FUSER_31_VIEW and DEMO_FUSER_31) in the migration list, have had 'double' entries created. This will also be seen when viewing the Predict objects in any of the 'View Objects' sub-functions.

## Reports About Versioned Predict Objects

The Versioned Objects sub-function in PAC allows you to display information about versioned Predict objects.

Specific information about the Predict migration unload invoked to create the Predict object version is available, including the location of the FDIC file from which the object was unloaded and the version of Predict used.

You can review the use of particular Predict objects. For example, you can identify all objects for all applications that actually use the view/DDM of a file as a subordinate at compile time.

PAC allows you to display details about the object in a form similar to those available using the Predict retrieval functions. For example, you can display the following details about a file: file attributes, file elements, and even sub/superdescriptor information in the case of Adabas files. The actual generated view/DDM with the specified database and file may also be displayed.

### On this page

- Migrating Predict Data Into and Out of PAC
- Migrating Predict Data Within PAC
- Reports About Versioned Predict Objects