User application programs that are to be debugged using EDF must be assembled
(or compiled) with the translator option EDF, which is the default. If you
specify NOEDF, the program cannot be debugged using EDF. There is no performance
advantage in specifying NOEDF, but the option can be useful to prevent commands
in well debugged subprograms appearing on EDF displays.
Application programs that are to be debugged using EDF must also
have the attribute CEDF(YES) in their resource definition, which is the default.
If a program is defined with CEDF(YES) and compiled with the translator option
EDF, EDF diagnostic screens are displayed for the program. If the program
is defined with CEDF(YES) but compiled with the translator option NOEDF, only
the program initiation and termination screens are displayed. If CEDF(NO)
is specified, no EDF screens are displayed.
If a program with the attribute CEDF(NO) links to a program with
the attribute CEDF(YES), it might not be possible to use EDF for the transaction.
For example, if the CICSPlex SM dynamic transaction routing program EYU9XLOP
is defined with the attribute CEDF(NO), and the user-replaceable program EYU9WRAM
(for workload management processing) is defined with the attribute CEDF(YES),
you cannot use EDF to debug EYU9WRAM. For successful debugging of multiple
programs within a transaction, ensure that all the programs are defined with
CEDF(YES).
There are some restrictions on the use of EDF that make it preferable or
even necessary to use one particular screen mode:
- EDF can be used only in single-screen mode when running a remote transaction.
- VM PASSTHRU is not supported by EDF when testing in single-screen mode.
- In single-screen mode, neither the user transaction nor CEDF should specify
message journaling, because the messages interfere with the EDF displays.
Message journaling is controlled by the profile definition for each transaction.
- In single screen mode, the CEDF transaction should not specify PROTECT=YES
in its profile definition. If this option is specified, message protection
for the CEDF transaction is ignored. The user transaction can still specify
the PROTECT=YES option even when running under CEDF. This restriction does
not apply to dual-screen mode.
- If a SEND LAST command is issued, EDF is ended before the command is processed
if you are using single-screen mode.
- If you want to test an application program that uses screen partitions,
or that does its own request unit (RU) chaining, you must run in dual-screen
mode.
- In single-screen mode, if the profile for the user transaction specifies
INBFMH=ALL or INBFMH=DIP, the profile for CEDF must have the same INBFMH value.
Otherwise the user transaction abends ADIR. Dual-screen mode does not require
the profiles to match in this respect.
- If the inbound reply mode is
set to "character" to enable the attribute setting keys, EDF disables
the keys in single-screen mode.
- When using CECI under EDF in dual-screen mode, you should be aware that
certain commands (for example, ASSIGN and ADDRESS) are issued against the
EDF terminal and not the transaction terminal. See INVOKE CECI for
information about how to invoke CECI from CEDF.
- TCAM terminals are supported by EDF, but only in dual-screen mode, and
provided that the terminals are not pooled.
Note:
In CICS TS 3.1, local TCAM terminals are not supported. The only TCAM
terminals supported are remote terminals connected to a pre-CICS TS 3.1 terminal-owning
region by the DCB (not ACB) interface of TCAM.

- When using EDF in dual-screen mode, you should avoid starting a second
task at the EDF terminal, for example by issuing a START command. Because
EDF is a pseudoconversational transaction, it does not prevent a second task
from starting at the terminal it is using. This may lead to a deadlock in
certain circumstances.
- When using EDF screen suppression in dual screen mode, commands that
cause a long wait, such as DELAY, WAIT, or a second RECEIVE, may cause EDF
to appear as if it had finished. If the task is ABENDed, EDF is reactivated
at the monitoring terminal.
Other restrictions apply to both screen modes:
- If a transaction issues the FREE command, EDF is switched off without
warning.
- To test a user transaction executing on a remote CICS® at a release
level earlier than CICS/ESA 3.1.1, you must run the transaction under control
of CRTE, as explained in EDF and remote transactions.
- EDF does not intercept calls to the CPI Communications interface (CPI-C)
or the SAA Resource Recovery interface (CPI-RR). You can test transactions that
use CPI calls under EDF, but you cannot see EDF displays at the call points.
- When processing a SIGNON command, CEDF suppresses display of the password
value to reduce the risk of accidental disclosure.
Even if your program would normally run using an OPEN TCB (L8,
L9, X8, or X9) CEDF forces the program to run on the QR TCB,
because CEDF itself is not threadsafe.
CEDF only has one level of stacking for its copies of the EXEC CICS parameter
list. This means that if an application calls an EXEC-capable global user
exit or user-replaceable module (URM), the parameter list for the EXEC CICS
commands issued by the global user exit or URM may overlay the parameter list
for EXEC CICS commands issued by the main program.
EDF is such a powerful tool that
your installation may restrict its use with attach-time security. (The external
security manager used by your installation defines the security attributes
for the EDF transaction.) If this has been done, and you are not authorized
to use CEDF, you cannot initiate the transaction.
For guidance on using security, see your system programmer or the CICS RACF Security Guide.
[[ Contents Previous Page | Next Page Index ]]