This section describes the data structures used within CA Gen. The following table describes the structures used by program modules and the data structures used in a user-written requester process environment (if it included all the capabilities as supported by the IDS Requester). The last two columns are the EABs, which must be written to extract non-screen information from the generated servers. Some data structures can be eliminated altogether if there are other ways by which certain functions can be handled, such as error logging, statistics, and replay.
This structure is only used between the initial requester and IEFREQ so that IEFREQ can perform initialization. If IEFREQ is not being used, you must fill the appropriate structures that use information out of this field.
Sample CONFIGURATION-PARAMETERS Structure:
01 CONFIGURATION-PARAMETERS. 02 Display-Terminal PIC X(16). 02 Display-Terminal-Type PIC 9. 02 Display-Terminal-Subtype PIC 9. 02 Debug-Terminal PIC X(24). 02 Debug-Terminal-Type PIC 9. 02 Debug-Terminal-Subtype PIC 9. 02 Initial-TID PIC X(8). 02 User-Id PIC X(16). 02 Commands PIC X(78). 02 User-Error-Handler PIC X(16). 02 Exit-Key PIC X. 02 Trace-Flag PIC 9. 88 Trace-Flag-ON VALUE 1. 88 Trace-Flag-Off VALUE 0. 02 Test-Flag PIC 9. 88 Test-Flag-ON VALUE 1. 88 Test-Flag-Off VALUE 0. 02 Statistics-Flag PIC 9. 88 Statistics-On VALUE 1. 88 Statistics-Off VALUE 0. 02 FILLER PIC X. 02 Flag-Capture-Replay PIC 9. 88 Flag-Capture-On VALUE 1. 88 Flag-Replay-On VALUE 2. 88 Flag-Capture-Replay-Off VALUE 0. 02 capture-file PIC X(8). 02 sequence-number PIC 9(5) COMP. 02 replay-delay PIC 9(4) COMP. 02 capture-option PIC 9. 88 Flag-Append-On VALUE 1. 88 Flag-Append-Off VALUE 0. 02 Log-Errors-Flag PIC 9. 88 Log-All-Errors VALUE 1. 02 Trace-Level PIC 9(4) COMP. 02 Idle-Timeout PIC 9(9) COMP. 02 Max-Retry-Modem PIC 9(4) COMP. 02 Modem-Delay PIC 9(4) COMP.
This is a required field for screen devices. Checking the value of DISPLAY-TERMINAL-TYPE determines how a program receives the data—whether to use 6530 or 3270 SEND MESSAGE calls.
The DISPLAY-TERMINAL-TYPE value is sent to several servers and to the IDS-CALLER requester. It is also moved to the field CRTerminal-type of the structure CAPT-TO-SERV.
Values:
This is a required field for screen devices. For a true or native 6530 device or one of the 3270 devices that do not support extended attributes, use a value of 1. If the device is a PC running emulation software, or if the 3270 device supports extended attributes, use a value of 2.
The value of DISPLAY-TERMINAL-SUBTYPE is sent to several servers and to the IDS-CALLER requester. This value is also moved to the field CRTerminal-Subtype in the structure CAPT-TO-SERV.
Values:
This field is obsolete and is no longer used.
This field is obsolete and is no longer used.
This field is obsolete and is no longer used.
The transaction identification value is sent to the MSGRT server to determine the server class name for the initial transaction ID. In typical online applications, this is the transaction identifier for the initial menu screen or the initial logon screen. This value must exist in the TMT table.
This field must receive a unique value for each user. Although this field is 16 characters long, only the last eight non-space characters are used. To prevent multiple operators from appearing to be the same to the system, these eight character positions must be unique. If the field contains spaces, IEFREQ uses the Pathway LOGICAL-TERMINAL-NAME for the AEF as its value.
The commands RESET or RESTART can be sent to the MSGRT server with the initial transaction identifier. The message router currently does not make use of this information.
For use with IDS and 6530 devices, this field is set to spaces. You can send commands such as RESET or RESTART to the runtime. This allows the runtime to restart an application at the point where it ended the last time it was invoked, or to reset the application.
This field is obsolete and is no longer used.
This field lets you return control to the initial requester. When IEFREQ identifies the function key that is pressed as the one you specified, it terminates execution and returns control to the initial requester program (the call to IEFREQ completes). There are specialized values available for 6530 and 3270 devices. Move the appropriate value to this field so that IEFREQ can check for that key.
This value is not used in IEFREQ. It is moved to the field TRACE-FLAG in the CA Gen generated servers. You can use this parameter to determine whether or not the runtime logic in the CA Gen generated server can perform trace. If you set the value to ON, then you need to set an appropriate trace level value in the field TRACE-LEVEL.
Limits: 0 through 255
Values:
This field is obsolete and is no longer used.
If you set this flag, IEFREQ obtains timestamps after transaction receipt, just before sending to the CA Gen generated server, and just after receiving a reply from the CA Gen generated server. This information is formatted and sent to the statistics server, RECSERV. One timestamp is sent to the statistics server for every transaction processed.
Values:
This field is moved to the IEFSERV portion of the generated application servers. The FLAG-SWITCH-MESSAGE field determines whether the application servers use flow optimization or not.
Typically, when an application server wants to dialog flow to another transaction ID, the application server returns the information back to IEFREQ. The requester issues an END-TRANSACTION verb, starts another transaction with a BEGIN-TRANSACTION verb, and then forwards the transaction to the next appropriate server class. This is how flow optimization OFF works.
If you package multiple transaction identifiers into the same server class or if both transactions are contained within the same TMF transaction, you can set flow optimization on. If the new transaction identifier is packaged into the same server class, nothing is returned to IEFREQ. Instead, the server queues up the transaction to the same server. If a new server class is to be used, the flow comes back to the requester, but no new TMF transaction is initiated. To denote flow optimization, use a value of 1.
Values:
You can capture and replay transactions using the following fields:
The field FLAG-CAPTURE-RELAY determines if this feature will be engaged or not. If you do not want to capture or replay, set this field to 0; values in other fields can then be ignored.
To capture transactions, set FLAG-CAPTURE-REPLAY to 1. You must fill in the CAPTURE-FILE field, which tags your capture session with a logical name (this name will be used as the RECAP SQL identifier for a replay session). You also need to place a value in the field CAPTURE-OPTION. If you have already captured some transactions, and you want to add more transactions to the capture file, specify a value of 1. The capture facility then appends additional transactions into the capture session.
To delete any current transactions for a particular user within the capture table, specify a value of 0. This turns append off and causes the Replay server to delete any existing records within the table and starts with a sequence number of 1.
To replay transactions, set FLAG-CAPTURE-REPLAY to 2. You must fill in the CAPTURE-FILE field with the logical name given to an already existing capture session. You must also place a value in the field SEQUENCE-NUMBER to denote the sequence number starts from 1 and increments by 1 from there when captured.
You must specify a value in the REPLAY-DELAY field. This value specifies the number of one-second units to delay before beginning each successive transaction from the capture table. You can ignore the other fields.
Values:
Use this name to uniquely identify a capture-replay session.
This field denotes which capture-replay sequence to use. This occurs only during initialization of the REPLAY mode. This field is not used within the capture mode. Capture appends to the end of the file by determining the current highest-sequence number or by deleting all records for the user and starting again from one.
During REPLAY mode, this value is used in the SCOBOL verb DELAY to provide a delay time between the replay of transactions. The value specified in this field is based on one-second units.
This field is used during initialization of the CAPTURE mode. This flag is not otherwise used within the requester. If append ON is designated, additional capture records will be added to the capture file. If append is set to OFF, any records for the current user will be deleted before adding more capture records.
Values:
Use this field to force all error conditions that IEFREQ is aware of to be written by the LOGSERV server.
Values:
The numeric value in this field is used to determine the level of tracing carried by the runtime.
Note: Use this field with caution as this will impose a severe performance penalty on the application.
This field specifies the maximum number of retries that a SEND MESSAGE operation will be performed in case there is a communication I/O error (error 140) during a read/write operation to a terminal device.
This field specifies the amount of delay between SEND-MESSAGE operations.
This field is obsolete and is no longer used.
ERROR-LINK is a structure used to pass error information back to the main requester or entry point into the application.
01 ERROR-LINK.
03 GAEF-ERROR PIC 9(4) COMP VALUE 0.
03 T-STATUS PIC 9(4) COMP VALUE 0.
03 T-SUBSTATUS PIC 9(5) COMP VALUE 0.
GAEF-ERROR
Error messages that are recognized by IEFREQ are placed in GAEF-ERROR and returned to caller requester (the one that called the IDS Requester).
Displays the Pathway TERMINATION-STATUS value, if any.
Displays the Pathway TERMINATION-SUBSTATUS value, if any.
This structure is used to log statistical information. A write to the RECSERV server occurs for each transaction processed.
Receives the value contained in the Pathway register, LOGICAL-TERMINAL-NAME.
Receives the transaction identifier returned from the message router.
Receives the server class name returned from the message router.
IEFREQ populates this field with the current time before performing the SEND to the application server call.
IEFREQ populates this field with the current time just after receiving reply from the SEND to the application server.
The IDS Requester populates this field with the combined data lengths from the fields DATA-LENGTH and DIAGNOSTIC-LENGTH before performing the SEND to the application server.
The IDS Requester populates this field with the combined lengths from the fields DATA-LENGTH and DIAGNOSTIC-LENGTH after receiving the reply to the SEND to the application server.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|