Browse Prior Art Database

Controlling the 3270 Server Function from a Client

IP.com Disclosure Number: IPCOM000123235D
Original Publication Date: 1998-Jul-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 126K

Publishing Venue

IBM

Related People

Harris, R: AUTHOR

Abstract

In a common application of IBM's 3270 device family, a 3270 Client accesses a 3270 server, which is connected to a 3270 Application. The 3270 Server is the intermediate between the backend Application (the Server is it's (virtual) terminal) and the Client (which is displaying or using the 3270 Screen). The 3270 Server could be any generic program that connects to a partner application via LU2 protocols and the client could be a Java Applet or a user-written program.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 46% of the total text.

Controlling the 3270 Server Function from a Client

   In a common application of IBM's 3270 device family, a
3270 Client accesses a 3270 server, which is connected to a 3270
Application.  The 3270 Server is the intermediate between the backend
Application (the Server is it's (virtual) terminal) and the Client
(which is displaying or using the 3270 Screen).  The 3270 Server
could be any generic program that connects to a partner application
via LU2 protocols and the client could be a Java Applet or a
user-written program.

   Situations can arise where the Client needs to send control
information to the Server to be serviced directly by the Server and
not passed to the partner application.  Examples of such situations
are a requirement to fill in a password upon a screen (so that the
password is not known to the Client, which may be untrustworthy), to
change the characteristics of the screen (such as Screen Size,
Display mode, Colour Characteristics), or to end the session with the
partner.  When there is only the standard LU2 protocol available for
the Client to communicate with the Server, the 'Control' request has
to be embedded within the 'Normal' flow from the Client to the Server
AND obey the 3270 protocol.  Consequently, it is difficult to embed a
'Control' within a 'User' flow, as the Server has no way of
distinguishing the 'Control' from the 'User' data.

   The solution described here takes advantage of the fact
that the LU2 protocol includes two 'keys' that are non- displayable -
the FM (X'1E') and DUP (X'1C') keys.  As the User cannot key these
elements themselves, the Client cannot send them to the server.
Thus, if they occur, the Server can use this fact to extract the
Control information from the rest of the (User) flow.

   In the implementation described below:
  -  LU2 and 3270 refer to the protocol defined in GA23-0059
     IBM 3270 Information Display system: Data Stream
     Programmer's Reference.
  -  Partner is defined as the System providing a LU2 Connection
     to the Server.
  -  Application is defined as a program running within the
     Partner that communicates with the Server using the 3270
     protocol.
  -  Server is defined as an intermediate process between the
     Client and the Partner that processes LU2 flows.
  -  Client is defined as a program that communicates with the
     Server using LU2 protocols.
  -  'User' is defined as a 3270 flow which does not contain
     'Control' information.
  -  'Control' is defined as a 3270 flow containing the DUP and
     FM characters (which are defined in GA23-0059).
  -  FM is as defined in GA23-0059 X'1E'.  Field Mark
  -  DUP is as defined in GA23-0059 X'1C', Duplicate

   The general arrangement is:
  Client <-LU2-> Server <-LU2-> Partner, running Application
    The normal 'User' flow from the Client is:
  Aid+CursorPos+Pos+SBApos+SFattr+data+SFattr......
  which would encode (according...