Essentially, while operating in this mode, GDDM storage and resources
(except for device query data) are released at the termination of a
particular transaction, and are reinitialized when the next transaction is
reinvoked by CICS to process the next device input.
As no information is retained by GDDM across transactions (other than
device query data), it is the responsibility of the transaction to
maintain the continuity between the initial instance of GDDM and
subsequent instances within the transaction. For example, you need to
ensure that transactions maintain the output to screen and save, at the
end of each instance, information that is require for subsequent ones.
Some call sequences that can help you are described in "Typical call
sequences for transaction-dependent pseudoconversations" in topic E.3.1.1.
GDDM provides the ability for a GDDM application to use CICS
pseudoconversational programming by changing the function of the following
calls, when transaction-dependent mode is being used:
- DSOPEN
- The PSCNVCTL processing option indicates to GDDM whether this mode is in
use, and whether this is the start of it, or a continuation.
- The processing option group code is 25
- The length is 2 full-words
- The values are 0, 1, and 2 corresponding to NO, START, and CONTINUE
respectively
- The default is NO.
The nickname syntax for this processing option is:
(PSCNVCTL,{NO|START|CONTINUE})
- ASREAD
- When the application is in "Continue pseudoconversational" mode
(PSCNVCTL,CONTINUE), the first ASREAD call issued by the application
causes the output transmission to be suppressed, and only the input part
of the ASREAD call functions.
Subsequent ASREAD calls work in the usual way, that is, they result in
output plus a "wait" for input. In this way, transactions can drop into
conversational mode if they need to; see the description of the CLEAR key
handling and line-output errors below.
Only the first ASREAD in CONTINUE pseudoconversational mode performs as a
RECEIVE; subsequent ASREADs work as normal, that is they output, wait, and
receive input.
Note: There is no pseudoconversational support for the GSREAD and MSREAD
calls.
- DSCLS
- If transaction-dependent mode is in use, a DSCLS call always causes the
device keyboard to be unlocked. Also, two options are provided that can
be used by pseudoconversational applications to end the
pseudoconversational mode, and are available to conversational
applications to cause explicit keyboard Unlock.
The complete DSCLS options and their meanings are:
- 0
- Erase the screen; if in transaction-dependent pseudoconversational
mode, unlock the keyboard, and save any changed device data.
- 1
- Do not erase the screen; if in transaction-dependent
pseudoconversational mode, unlock the keyboard, and save any changed
device data.
- 2
- Erase the screen and unlock the keyboard; if in transaction-dependent
pseudoconversational mode, release the saved device data.
- 3
- Do not erase the screen but unlock the keyboard; if in
transaction-dependent pseudoconversational mode, release the saved
device data.
Subtopics:
|
GDDM V3R2 Base Application Programming Guide
Copyright IBM Corporation 1990, 2012