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. Sending 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 sent. 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: Sending 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 D-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 D-1 Display Screen Ownership
Display Screen Ownership | Display Screen Ownership | How to Change Screen Ownership |
|---|
| Unowned | You have either just opened a device for SNA
IMF communication or just logged off the host. | Send the [SYS REQ] key to transfer screen ownership to the SSCP-LU session
if you have just opened a device. |
| Owned by an SSCP-LU session | You have sent 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, send the [SYS REQ] key to make the screen unowned. If an LU-LU session exists, send
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 send 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 a device is first opened
for SNA IMF communication.
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.
