When you use IMF/3000, you need not be aware of who owns the display
screen at any particular time. With SNA IMF, however, knowing who
owns the display screen at a particular time can help you determine
the state of your session and which keys or commands you should
enter.
SNA IMF |
 |
To use SNA IMF, you need to be aware of how screen ownership
is handled.
A session is the logical connection between Network Addressable
Units (NAUs). Three types of NAU sessions exist: SSCP-PU, SSCP-LU,
and LU-LU. During session initiation, display screen ownership passes through
three stages: (1) unowned; (2) owned by an SSCP-LU session; and
(3) owned by the LU-LU session.
For example, if you are using the Time Sharing Option (TSO),
you will receive four different types of screens before completing
your logon to the host:
An unowned screen. After
the first RECV3270 intrinsic call, you receive an unowned screen
that contains the SNA IMF banner. Send the [SYS REQ] key now. Sending the [SYS REQ] key affects screen ownership. Pressing the [SYS REQ] key also clears the screen image and sets the cursor to
the top of the screen.
A blank SSCP screen. This
screen appears after the [SYS REQ] key is pressed. The blank screen is produced internally
by SNA IMF. Screen ownership switches to the SSCP-LU session. After
receiving this screen, enter your logon to the host.
An LU-LU owned BIND screen. The
host receives this screen after TSO determines that your LU will
be permitted to start a TSO session.
An unowned screen. This screen
is produced by SNA IMF whenever an UNBIND is received. TSO sends
a BIND-UNBIND-BIND sequence when establishing a session. The unowned
screen appears immediately after the SSCP-LU BIND screen and before
your TSO session is created.
An LU-LU owned screen. This
screen contains three items: logon messages from the host, an indication
of whether logon was successful, and the READY message.
 |
 |  |
 |
 | NOTE: Pressing the [SYS REQ] key while using a full screen-oriented application destroys
the integrity of your screen image. Once this happens, the host
application must recover the screen image. |
 |
 |  |
 |
Table F-1 “Display Screen Ownership” lists the three states of display
screen ownership, what each state means, and how you can change
display screen ownership.
Table F-1 Display Screen Ownership
Display Screen Ownership | Meaning | How to Change Screen Ownership |
---|
Unowned | Either Pass Thru has just come up or
you have logged off the host. | Press the [SYS REQ] key to transfer screen ownership to the SSCP-LU session
if Pass Thru has just come up. |
Owned by an SSCP-LU session | You have pressed the [SYS REQ] key, which changes the screen ownership from unowned (the
previous screen) to SSCP-LU ownership (the current screen). You
can now log on to the system. | If there is no LU-LU session, press the [SYS REQ] key to make the screen unowned. If an LU-LU session exists, press
the [SYS REQ] key to transfer screen ownership back to the LU-LU session. |
Owned by an LU-LU session | An SSCP-LU session was the owner of the
previous screen. Logon was completed successfully | Either press the [SYS REQ] key to transfer screen ownership to the SSCP-LU session
or log off to make the screen unowned. |
The display screen is unowned when Pass Thru is first started.
The SSCP-LU session enables you to create an LU-LU session,
which allows communication between two end users (application programs, devices,
or people). Once you enter the logon message followed by the [SYS REQ] key, the newly created LU-LU session allows you to exchange data
with the IBM host through 3270-type screen images.
When a terminal receives a BIND from the host, the terminal's
screen is put into an LU-LU session. Receipt of an UNBIND from the
host puts the screen into an unowned state.