You can run EDF by invoking either the CEDF or CEDX transaction.
If you are testing a non-terminal transaction, use the CEDX transaction, which enables you to specify the name of the transaction.
If you are testing a transaction that is associated with a terminal, you can run EDF in the following ways:
Generally, you can use whichever method you prefer, but there are a few situations in which one or the other is required. You must use single-screen mode for remote transactions. See Restrictions when using EDF for other conditions which affect your choice.
The power of EDF lies in what you can do at each of the intercept points. For example, you can:
The first two types of changes are made by overtyping values in the body of the command displays. Overtyping to make changes tells you how to do this. You use the function keys in the menu for the others; Using EDF menu functions tells you exactly what you can do and how to go about it.
TRANSACTION: DLID PROGRAM: DLID TASK: 00049 APPLID: IYAHZCIB DISPLAY:00 ADDRESS: 00000000 WORKING STORAGE IS NOT AVAILABLE ENTER: CURRENT DISPLAY PF1 : UNDEFINED PF2 : BROWSE TEMP STORAGE PF3 : UNDEFINED PF4 : EIB DISPLAY PF5 : INVOKE CECI PF6 : USER DISPLAY PF7 : SCROLL BACK HALF PF8 : SCROLL FORWARD HALF PF9 : UNDEFINED PF10: SCROLL BACK FULL PF11: SCROLL FORWARD FULL PF12: REMEMBER DISPLAY
When you use EDF with just one terminal, the EDF inputs and outputs are interleaved with those from the transaction. This sounds complicated, but works quite easily in practice. The only noticeable peculiarity is that when a SEND command is followed by a RECEIVE command, the display sent by the SEND command appears twice: once when the SEND is executed, and again when the RECEIVE is executed. It is not necessary to respond to the first display, but if you do, EDF preserves anything that was entered from the first display to the second.
You start EDF by:
Next, you start the transaction to be tested by:
When both EDF and the user transaction are sharing the same terminal, EDF restores the user transaction display at the following times:
To enable restoration, user displays are remembered at the following times:
If CEDF is used with an application program that has been translated with option NOEDF, or one that has NO specified for CEDF in its resource definition:
Similarly, in these circumstances:
These considerations apply to any screen I/O operation performed by the application program.
When EDF restores the transaction display, it does not sound the alarm or affect the keyboard in the same way as the user transaction. The effect of the user transaction options is seen when the SEND command is processed, but not when the screen is restored. When you have NOEDF specified in single-screen mode, you should take care that your program does not send and receive data because you will not see it.
When EDF restores the transaction display on a device that uses color, programmed symbols, or extended highlighting, these attributes are no longer present and the display is monochrome without the programmed symbols or extended highlighting. Also, if the inbound reply mode in the application program is set to "character" to enable the attribute-setting keys, EDF resets this mode, causing these keys to be disabled. If these changes prevent your transaction from executing properly, you should test in a dual-screen mode.
If you end your EDF session part way through the transaction, EDF restores the screen with the keyboard locked if the most recent RECEIVE command has not been followed by a SEND command; otherwise, the keyboard is unlocked.
EDF makes a special provision for testing pseudoconversational transactions from a single terminal. If the terminal came out of EDF mode between the several tasks that make up a pseudoconversational transaction, it would be very hard to do any debugging after the first task. So, when a task terminates, EDF asks the operator whether EDF mode is to continue to the next task. If you are debugging a pseudoconversational task, press enter, as the default is "yes". If you have finished, reply "no".
In dual-screen mode, you use one terminal for EDF interaction and another for sending input to, and receiving output from, the transaction under test.
You start by entering, at the EDF terminal, the transaction CEDF tttt, where tttt is the name of the terminal on which the transaction is to be tested.
The message that CEDF gives in response to this depends on whether there is already a transaction running on the second terminal. If the second terminal is not busy, the message displayed at the first terminal is:
TERMINAL tttt: EDF MODE ON
and nothing further happens until a transaction is started on the second terminal, when the PROGRAM INITIATION display appears.
You can also use EDF in dual-screen mode to monitor a transaction that is already running on the second terminal. If, for example, you believe a transaction at a specific terminal to be looping, you can go to another terminal and enter a CEDF transaction naming the terminal at which this transaction is running. The message displayed at the first terminal is:
TERMINAL tttt: TRANSACTION RUNNING: EDF MODE ON
EDF picks up control at the next EXEC CICS command executed, and you can then observe the sequence of commands that are causing the loop, assuming that at least one EXEC CICS command is executed.
You cannot use EDF in dual-screen mode if the transaction under test, or the terminal that invokes it, is owned by another CICS region.
Furthermore, if the remote CICS region is earlier than CICS/ESA 3.1.1, you cannot run the transaction directly under EDF by invoking CEDF in the TOR. In this situation, you must use the routing transaction, CRTE. You enter CEDF at the terminal, clear the screen, and then enter CRTE followed by the system identifier (SYSIDNT) of the remote CICS region. This action causes CICS to route subsequent inputs to the remote region, and you can then enter the transaction identifier of the transaction you want to test. The CICS Supplied Transactions manual explains how to use CRTE.
If a remote transaction abends while under EDF using a CRTE routing session, EDF displays the abnormal task termination screen, followed by message DFHAC2206 for the user transaction. The CRTE session is not affected by the user task abend. Also, if you opted to continue with EDF after the abend, your terminal remains in EDF mode within the CRTE routing session.
There is a difference in execution as well. For remote transactions, EDF purges its memory of your session at the termination of each transaction, whether EDF is to be continued or not. This means that any options you have set and any saved screens are lost between the individual tasks in a pseudoconversational sequence.
You can use EDF to test transactions that execute without a terminal: for example, transactions started by an EXEC CICS START command, or transactions initiated by a transient data trigger-level. To test non-terminal transactions, use the CEDX trnx command, where trnx is the transaction identifier.
To test a transaction using CEDX:
When you use CEDX to debug a transaction, CICS controls the EDF operation by modifying the definition of the transaction specified on the CEDX command, to reference a special transaction class, DFHEDFTC. When you switch off EDF (using CEDX tranid,OFF) CICS modifies the transaction definition back to its normal transaction class.
You can also test a transaction that is using distributed transaction processing across a remote link by telling EDF to monitor the session on the link. You can do this on either (or both) of the participating systems that are running under CICS and has EDF installed. (You cannot do this if the transaction has been routed from another CICS region because you must use single-screen mode for remote transactions.)
For APPC and MRO links, you can name the system identifier (sysid) of the remote system:
CEDF sysid
This causes EDF to associate itself with any transaction attached across any session belonging to the specified system.
For APPC, MRO, and LU6.1 links, you can use the session identifier (sessionid) that the transaction is using:
CEDF sessionid
You can determine the session identifier with the CEMT INQUIRE TERMINAL transaction, but this means that the transaction must be running and have reached the point of establishing a session before you start EDF.
If a transaction using distributed transaction processing also has a terminal associated with it, or if you can invoke it from a terminal (even though it does not use one), you can use EDF to test it in the ordinary way from that terminal.
When you have finished testing the transaction on the remote system, you should turn off EDF on that SYSID or sessionid before logging off from CICS with CESF. For example:
CEDF sysid,OFF
Failure to do this could cause another transaction using a link to that system to be suspended.
You can use EDF, in single- or dual-terminal mode, to test a transaction that includes a distributed program link (DPL) command. However, EDF displays only the DPL command invocation and response screens. CICS commands issued by the remote program are not displayed, but a remote abend, and the message a remote abend has occurred is returned to the EDF terminal, along with the SYSID of the system from which the abend was received. After control is returned to your local program, EDF continues to test as normal, but the PSW is not displayed if the abend is in a remote program.
If you want to end EDF control of a terminal, the method you use depends on where you are in the testing. If the transaction under test is still executing and you want it to continue, but without EDF, press the END EDF SESSION function key. If you have reached the task termination intercept, EDF asks if you want to continue. If you do not, overtype the reply as NO (YES is the default). If no transaction is executing at the terminal, clear the screen and enter:
CEDF ,OFF
(The space and comma are required.)
If you are logging off from dual-screen mode, clear the screen and enter CEDF tttt,OFF.
In all these cases, the message THIS TERMINAL: EDF MODE OFF is displayed at the top of an empty screen.
[[ Contents Previous Page | Next Page Index ]]