Before using the construction functions to generate an application system, you must define the target environment for the generated application.
Note: For server applications, specify the target operating system, DBMS, generated source language, and TP monitors for each server load module. Construction of server load modules does not use the operating system, generated source language, DBMS, or TP monitor values on this panel. Instead, server load module construction uses the values in the Specify Server Target Environment panel.
Follow these steps:
Specify Target Environment Parameters COMMAND ===> Operating System . . . . . . . . . . MVS_____ (MVS) Generated Source Language . . . . . COBOL___ (COBOL) Database Management System . . . . . DB2_____ (DB2) TP Monitor . . . . . . . . . . . . . CICS____ (CICS,IMS,IEFAE) Screen Format Type . . . . . . . . . BYPASS__ (BYPASS,MFS,MFS/EOF,HSTFAC) Profile Type . . . . . . . . . . . . TSQ Extended Attribute Support . . . . . YES Enforce DM Constraints . . . . . . . NO_ Optimize import view initialization NO_ Restartable Application . . . . . . YES Clear Screen Default Command . . . . RESET__ (RESET,RESTART) DB2 Subsystem . . . . . . . . . . . SSD2 (DB2 only) Dynamically link procedure steps . . NO_ (YES, NO, CMP) Dynamically link action blocks . . . NO_ (YES, NO, CMP) Dynamically link screen managers . . NO_ (YES, NO, CMP) Pseudoconversational Support . . . . NO_ (CICS only) Handle CICS Command Abends . . . . . NO_ (CICS only) XCTL for flows when possible . . . . NO_ (CICS only)
Uses the values only for this CA Gen session. CA Gen displays the following message:
Temporary override of target environment accepted.
Leaves the screen without saving and returns to the previous panel. CA Gen displays the following message:
User exited from function in progress.
Updates the Host Encyclopedia, exits the screen, and displays the previous panel. The system displays the following message:
Target environment saved on encyclopedia.
Always exits without saving and displays the previous panel. CA Gen displays the following message:
User cancelled function in progress.
The operating system on which the generated application executes. Host Encyclopedia Construction supports the z/OS operating system, which is specified in this panel as MVS.
The language in which CA Gen generates the application. Host Encyclopedia Construction supports COBOL generation.
The Database Management system the generated application uses. This must be DB2 for applications that are generated on the Host.
For generated online applications, the Teleprocessing Monitor under which the generated application runs. Support is available for three teleprocessing monitors: CICS, IMS, or IEFAE (TSO).
The types of screen formats available for each TP monitor are:
BYPASS for native 3270 formatting support.
BYPASS for native 3270 formatting support.
MFS (Message Formatting Services) restores the field during input after the erase-end-of-field and erase-input keys.
or
MFS/EOF, a variation of the MFS that erases the field during input after the erase-end-of-field and erase-input keys.
Some considerations affecting performance occur when using this feature due to the extra processing required. Basic Mapping Services (BMS) generation for CICS is not used.
This option controls the storage method for the profile table (stack), which CA Gen uses to retain information for processing and error recovery. For IMS and IEFAE (TSO), use the SQL profile manager. CICS DB2 users have the option of using the SQL or the TSQ profile manager. The SQL profile manager maintains the profile stack on a DB2 database. The TSQ profile manager maintains the profile stack in a CICS temporary storage queue. Use of the TSQ profile manager can improve application performance.
The extended attribute support option identifies if the generated application runs in an environment whose devices, such as terminals or communication devices, support extended attributes. The extended attributes are reverse video, underline, blinking, and color.
When the target environment supports extended attributes, select Y. When the environment does not support extended attributes, select N. The results are unpredictable when a generated application sends extended attributes to a device that does not support them.
In the CICS environment, CICS checks the CICS terminal definition to determine if the device supports extended attributes. The device definition overrides the Extended Attribute Support option. When the Extended Attribute Support is Yes, the generated application checks the definition before sending the attributes and does not send the attributes when the definition shows that the device does not support extended attributes.
In the TSO and IMS environments, the TIRDEV exit responds that the device supports extended attributes even when it may not actually do so. The user must provide a TIRDEV exit that returns a true indication of the devices capabilities, or to select the relevant extended attribute supported characteristic correctly based on the target devices.
The Enforce DM (Data Modeling) Constraints option captures information describing the rules to use in maintaining the integrity of the database. Some rules are enforced by the target DBMS. Other rules are enforced by CA Gen-generated referential integrity triggers when DELETE, TRANSFER, or DISASSOCIATE actions execute.
When you set the Enforce DM Constraints option, CA Gen-generated code enforces four more constraints. This eliminates the need to enforce them with action language in action blocks.
You cannot set these constraints independently of each other. They are selected as a group.
The four more constraints are:
The Enforce DM Constraints option can potentially degrade performance. Therefore, we recommend that you only using this option only during testing to debug. If performance is a serious consideration, regenerate the application with this option set to No before moving into production.
CA Gen checks both ends of the relationship before permitting an ASSOCIATE action to prevent the foreign keys of multiple rows from pointing to the same related row. For example, if A is related to B, and A contains the foreign key, the transaction fails with a fatal error unless the following tests are true:
CA Gen generated code ensures that no ASSOCIATE action violates a defined mutually exclusive constraint. If any member of the mutually exclusive set exists, none of the others are allowed to exist. For example, if A is related to B and to C, in a mutually exclusive set, an action block reads A and attempts to associate it to B. If A is already associated with C, the transaction fails with a fatal error.
CA Gen generated code performs an ASSOCIATE action for each mandatory relationship membership when it creates an entity occurrence. CA Gen enforces this constraint in action blocks with CREATE actions. After executing a CREATE on View A, an attempt to READ into View A or exit the action block without associating A or its mandatory relationship results in a runtime error.
Consider the effect of overlaying the value in a foreign key when an ASSOCIATE action is applied to a one-to-many relationship. If the foreign key is populated and no cascade delete logic is performed, the effect is the same as a DISASSOCIATE action. This is named a quiet disassociation because it executes without performing database integrity checks.
CA Gen generated code checks before performing the ASSOCIATE to see if the attribute on which the foreign key is based is null. If not, the association that is requested must match the existing association. The association exists if the foreign key value equals the value of the attribute on which it is based. The transaction fails with a fatal error when the foreign key is not null and is not the same value as the new key requested.
Indicates to CA Gen that the logic for initializing import views can reside in the named action block. This action reduces the amount of time to initialize import views.
Specifies if a business system is restartable. A restartable application supports screen clear, other transaction execution, and using the RESTART command to return to the application. Setting an application as restartable improves the system performance by reducing use of the runtime profile table.
CA Gen generated applications use a temporary runtime stack, the Profile Database, to maintain execution context. CA Gen maintains one stack for each business system for each user. For example, when working in three CA Gen generated business systems, you have three stacks, one for each business system.
If an application is non-restartable, CA Gen still generates the profile table, but only accesses it to support the following situations:
If the business system is non-restartable, RESTART still works in certain situations. The profile table supports the previous situations regardless of the restartable specification. Therefore, a transaction restarts in these situations:
A business system is always restartable in all situations if it is specified as restartable.
For online transactions, CA Gen supports two clear screen commands: RESET and RESTART. RESET clears the stack, the profile, for the user and business system and begins a new dialog. RESTART continues a dialog using the top entry from the stack. The top entry is always the last active screen for the business system, regardless of the transaction code entered.
The Clear Screen Default Command option specifies the command that the generated application executes when a transaction code is entered without a command on a clear screen. To execute the command that is not the specified default, the user of the generated application must clear the screen and must enter the transaction code followed by the command. The format is:
trancode command
For example, if the default command selected is RESET, when the application user clears the screen and enters a transaction code, the stack is cleared and a new dialog begins. To restart a dialog, the user must enter the clear screen transaction code followed by the RESTART command. The format is:
trancode RESTART
Note: When the application is non-restartable, the clear screen default command is RESET. When you type the transaction code without the RESET command, the table is not cleared because the application is not configured to use a runtime profile table. To clear the table, specifically enter the clear screen transaction code followed by the RESET command.
The DB2 Subsystem is the name of the database location where the generated application runs. CA Gen uses the name to bind packages or plans and when invoking application programs.
CA Gen generates different COBOL code when calling a routine that is statically linked within an executable and when calling a routine that resides in a separate executable. For calls to routines that are statically linked within an executable, CA Gen generates a COBOL CALL literal statement.
For calls to routines that reside in an executable separate from the calling executable, CA Gen generates a COBOL CALL identifier statement that references a variable. The variable contains the name of the routine that is to be dynamically invoked. A program call to a routine that resides in a separate executable is known as dynamic linking.
Dynamic linking is implemented by CA Gen using a z/OS specific packaging option that indicates how a routine is built. How the routine is built determines how it is called. The specific dynamically link packaging property that is associated with each procedure step, screen, or action block (including external action blocks) identifies how that component is resolved during the installation of the CA Gen load module in which it is packaged.
The designation of the dynamically link packaging option for a procedure step, screen, or action block can be set to Default. In this case, the dynamically link packaging option is derived from the dynamically link packaging option that is established in the business system owning the CA Gen load module in which the given procedure step, screen, or action block is defined.
The following values can be explicitly set for each individual procedure step, screen, or action block (or if set to Default, the value is derived from their respective Dynamically Link packaging option that is obtained from the default value that is established in the Business System):
A dynamic program call to a routine that resides in a DLL is invoked directly by the generated COBOL CALL statement. A dynamic program call to a routine that resides in a non-DLL module is indirectly invoked by CA Gen z/OS runtime.
Note: Every module that makes a dynamic program call to a routine marked for Compatibility must be regenerated and reinstalled to incorporate the call to the runtime routine that handles the indirect call processing.
For a module built before AllFusion Gen 7, identifying it for Compatibility allows that module to be dynamically called by a CA Gen routine that resides in a DLL.
It is possible to migrate procedure steps, screens, or action block routines that were built before AllFusion Gen 7 and must continue to reside in a non-DLL executable. CA Gen allows a module that is explicitly set to, or defaulted to, Compatibility to be built as a non-DLL executable. These migrated non-DLL executables use the same CA Gen z/OS runtime as those application routines that reside in DLLs.
The CA Gen Toolset, Client Server Encyclopedia, and Host Encyclopedia each provide an option that indicates if modules marked for Compatibility should be processed, that is generated or installed.
Selecting the Process modules marked for Compatibility option causes the RI Trigger modules and all Action Blocks that are statically linked into a Compatibility module to be compiled twice—once using the NODLL compiler option and again using the DLL compiler option. If the action blocks are External Action Blocks these must also be compiled with the NODLL option to be included in the Compatibility load module.
The Compatibility option is intended to enable a phased migration of an existing application. It allows routines that have been migrated and reside in DLLs to interoperate with routines that reside in non-DLL executables. The non-DLL executables can themselves be migrated and built using the current release of CA Gen or they can remain as is, having been built with a release of AllFusion Gen before Release 7.
Note: Feature enhancements in future CA Gen releases require that routines using this feature reside in a DLL.
When CICS is the target environment, the following options are available:
These options affect the choice of CICS commands that are used by the application system. The default for each of these options is N (No). This allows you to generate with the testing facility as the target and then to reinstall for CICS without having to regenerate the Dialog Manager.
It is possible to have different combinations of options in each load module. You can flow from a load module with any combination of options to a load module with any other combination. However, you can have only one combination of options per load module, even if you have packaged several steps together. This occurs because each load module contains only one Dialog Manager.
While the options are selected on the Target Environment panel, they do not go into effect until the Dialog Manager is generated and installed. When you change an option, change it on the Target Environment panel, regenerate the Dialog Manager, and install.
Choosing Yes for this option prevents terminal users from being able to clear the screen. The CLEAR, PA1, PA2, and PA3 function keys simply refresh the screen. Users are able to execute only the procedure steps that are defined in the Dialog Flow Diagram, or transactions that are called through the NEXTTRAN command.
Choosing Yes is appropriate when you do not want to allow users to clear the screen and enter another transaction code. This option allows you to build systems in which the user is tied to the system (dedicated terminal systems).
The choice is not between conversational or pseudoconversational transactions. All CA Gen generated transactions are pseudoconversational in that they do not remain in memory or wait for a response from the terminal.
If you Click Yes, the generated application behaves differently in two ways.
EXEC CICS RETURN END-EXEC
to the following command:
EXEC CICS RETURN TRANSID trancode END-EXEC
You need to provide a means of logging off the system because users will not have access to a clear screen. No CA Gen log out routine is supplied, but you can create your own. Assign a PF key to a LOGOFF command. Use a CASE OF command to perform a NEXTTRAN to a non-CA Gen procedure. Or, you can write a non-CA Gen procedure to log out the system. It should include a command such as:
EXEC CICS ISSUE DISCONNECT END-EXEC
For greater flexibility, set pseudoconversational support to No when testing. Set it to Yes when you are ready to install, or when you want to see if the option works correctly.
Allows you to define the recovery from CICS command abends. If you specify Yes for this option, HANDLE ABEND and HANDLE CONDITION statements are used. For the commands that fail, the user sees a CA Gen runtime error message rather than a CICS error message.
Specifying No causes the CICS error message to display on the screen. A user could clear the screen and could start over. Set this option to Yes when Pseudoconversational support is set to Yes because Pseudoconversational support is to prevent clear screen access.
Choosing Yes means that the CA Gen abend recovery module TIRFAIL intercepts CICS command abends. If you have written an error recovery exit such as TIRTERM, abends also pass through it. However, you do not get a CICS dump for these abends.
Note: For more information about the user exits, see the User Exit Reference Guide.
Specifies to use EXEC CICS XCTL in place of EXEC CICS START when flowing from one CA Gen procedure to another. An XCTL is quicker and uses fewer the CICS resources.
When the target database management system is DB2, use the Dynamic Plan Selection exit included with CA Gen. When you specify Y for this option, a lengthy online message displays to explain how to use the option.
If you click Yes for the XCTL for Flows when the Possible option, CA Gen uses XCTL for dialog flows when the module being flowed to is in the same CICS region. A START command is issued when flowing to a module in another region.
DB2 can dynamically change plans during the execution of an application. This allows CA Gen to use XCTL, when it can, to implement dialog flows.
When you flow from one CA Gen procedure step to another procedure step that is not located in the same load module, you change plan names. DB2 uses the RCT to associate a transaction name to a plan name. If you have hard-coded plan names in the RCT, you receive the wrong plan name when you attempt to do DB2 calls in the target procedure step. Instead of hard coding plan names, use a dynamic plan selection exit.
CA Gen provides a dynamic plan selection exit, named TIRC$EXT, as part of the installation software. When executed, a CA Gen load module writes a signature record containing the name of the program to a temporary storage queue. The queue name is a combination of the transaction name and the terminal ID. If the terminal ID is not present, the queue name is the task number.
By convention, CA Gen program names and the plan names are the same. DB2 uses the RCT to find the plan name when it encounters the first load module DB2 call. At this point, TIRC$EXT reads the temporary storage queue and returns the program name as the plan name. The temporary storage queue is deleted on exit from the CA Gen load module.
The z/OS Installation Guide has instructions to install TIRC$EXT. The exit is compatible with load modules that use START commands. After installing TIRC$EXT, any combination of modules with XCTL and without XCTL can work together. It is not necessary to change the RCT entry back if you drop the XCTL option.
Note: For more information, see the z/OS Installation Guide.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|