DLUR Overview and Configuration

Resolving The Problem

DLUR on the IBM OS/400 system supports SNA dependent LU interfaces to upstream applications, and where needed, translates the data stream for our 5250 devices. Our products include 3270 emulation, SNUF, RJE, SNA Passthrough, NRF, DHCF and others. At this time, SPLS is not supported by DLUR.

The architecture works like this. At the node (system) the SLUs are attached to, there is a Dependent LU Requester (DLUR) support. At the node that supports the SSCP, there is a Dependent LU Server support (DLUS). DLUR and DLUS support are connected through a pair of LU 6.2 sessions. The OS/400 system would be the DLUR, IBM VTAM would be the DLUS.

The session which the DLUR node binds to the DLUS node is the conwinner session and the sessions the DLUS node binds is the DLUR's conloser session. Of course one node's conwinner is the other node's conloser. The partners (DLUR and DLUS) send data on the conwinner sessions and receive data on their conloser sessions.

The name given to the pair of LU 6.2 sessions between DLUR and DLUS which transports data is the CP-SVR Pipe. The CP-SVR Pipe is a logical connection and DLUR/DLUS nodes can be multiple systems away from each other.

Both DLUR and DLUS nodes encapsulate SSCP flows into LU6.2 logical records and send them on the CP-SVR Pipe. At the other end, the data is de-encapsulated and processed as SSCP flow request/responses. Again, since this is a logical connection, the DLUS and DLUR nodes can be multiple systems away from each other.

The DLUS node initiates start-up requests to applications based on SSCP data/request (for example, Logons or INIT SELFs) or due to hard coded information in tables and gens. The CP-PLU (application) then will separately establish a bound session to the LU at the DLUS node.

OS/400 DLUR Supported Configurations

OS/400 DLUR support is activated through an OS/400 host controller configuration (CRTCTLHOST) using the linktype parameter of *DLUR. The following devices are supported on a DLUR Host controller configuration:

o	Host devices (CRTDEVHOST)
o	SNA Passthrough upstream devices (CRTDEVSNPT, SNPTCLS= *UP)
o	DHCF Display devices (CRTDEVDSP, Model= *DHCF)
o	NRF Display and printer devices (CRTDEVDSP, Apptype=*NRF)
o	SNUF devices (CRTDEVSNUF)

APPN Routing Requirements for DLUR

Session routing introduces some changes from the traditional SNA subarea flows. While all sessions still flow on a physical media (for example, lines) the DLUR to DLUS connection is a logical one. It consists of a pair of LU 6.2 conversations through which two APPC applications (DLUR and DLUS) exchange dependent SNA SSCP flows by encapsulating them in LU6.2 logical records. The pair of conversations used to transmit encapsulated SNA is called the CP-SVR pipe.

Another difference is that the sessions from upstream applications to the OS/400 system are not tied to the route used by the DLUR/DLUS connection. Nor is that flow encapsulated. The data between application and OS/400 system is known as the LU-LU flow session. Once the application is initiated by the VTAM/SSCP at the DLUS node, it can individually locate the LU that requested it and send its data on the least weight route available between the application and the OS/400 system.

o	Since sessions can flow in from multiple connections to DLUR configuration objects we need a system-wide task to coordinate these sessions. This task is called DLUX.
o	Each dependent host device supported will be registered as a unique dependent local location name through DLUX to OS/400 APPN interfaces.
o	OS/400 users will now configure a host controller and devices without a line description. This reflects the logical (virtual) connection between DLUR and DLUS nodes. The logical connection will flow through a real APPN controller and devices attached to a real line somewhere on the system (becomes known only at activation of the logical connection).
o	OS/400 users of host controllers typically use the WRKCFGSTS command to view the state of host controller and devices. They will still do this with DLUR support.
o	OS/400 users of APPN typically use APPNINFO to visualize APPN session. DLUR users can run APPNINFO against the DLUR host controller to visualize the internal connections between DLUR configurations and real APPC/APPN configurations and other APPN information.

Network Management Fundamentals for DLUR

The normal way for accessing information on host controllers is through WRKCFGSTS screens. This is the case with DLUR host controllers and associated devices as well. Since there is no line description, then the highest level of visualization is at the controller level.

We suggest that the customer use naming conventions to allow them to visualize all controllers to a given remote DLUS node. By assigning the same first characters (for example, DET for a DLUS node in Detroit) to the names of each OS/400 DLUR host controller configured to a DLUS, they can then visualize all DLUR host controllers by running the WRKCFGSTS *CTL DET* command.

As usual, the state of the controller can tell them status information as follows:

o	Varied Off (VOF) End users must vary on the OS/400 controller to begin activation.
o	Vary on Pending (VOP) The OS/400 controller is varied on, but the remote PU definition on the DLUS node has not completed activation.
o	Varied On (VON) The OS/400 controller is varied on and the remote PU definition is active, associated OS/400 devices are varied off or the remote LUs are not active.
o	Active (ACT) The OS/400 controller is varied on, the remote PU definition is active, associated OS/400 devices are varied on and remote LUs are active.

Also, as usual, the state of the devices can tell them status information as follows:

o	Varied Off (VOF) End user must vary on the OS/400 device to begin activation.
o	Vary On Pending (VOP) The OS/400 device is varied on, but the remote LU definition on the DLUS node has not completed activation. The exception to this is a DHCF device, which remains VOP until it is used.
o	Varied On (VON) The OS/400 device is varied on and the remote LU definition is active, but no bound sessions exist to the device yet.
o	Active (ACT) There is a bound session through the device.

Using APPNINFO

The normal way for accessing information on APPN session is through APPNINFO screens. This is the case with DLUR APPN sessions as well. To visualize the endpoint session information (where the OS/400 DLUR host controller is configured), the end user would run DSPAPPNINF INFYTYPE(*SSN) SSNTYPE(*INMSSN) CTL(Name of DLUR host controller). From there, they can select options to see more information (for example, who is at the other end of the wire and what is the real controller the session is running through).

Configuring for DLUR on the OS/400 System

o

Dependent LU Requester uses mode CPSVRMGR. This is created internally as part of the APPN and DLUR support. If CPSVRMGR exists in the Mode Description Table (WRKMODD) on any of the systems in your network, it has to be deleted. Use the WRKMODD command and specify the option to delete CPSVRMGR if it exists in the mode table. If it does not exist, you do not need to do anything with this step.

Automatic Configurations of Sessions

o	If the OS/400 system is configured to initiate sessions to the remote DLUS node, OS/400 DLUR support will send the reply product set identifier (PSID) definitions to the DLUS nodes at activation time based on the device descriptions. This eliminates the need to configure a counterpart object on the DLUS node. It reduces problems associated with mismatch configurations between DLUR and DLUS nodes.
o	Dependent PU Name The Dependent PU name is an APPN local location name for the *DLUR host controller. The Dependent PU name matches the VTAM PU name. If the Dependent PU name is specified, it will be registered with APPN which can then process searches. Note: Make sure that DLUS allows the DLUR node to supply dependent PU names to the DLUS node.
o	DLUR Exchange ID The DLUR exchange ID contains the ID Block/ID Number and Node ID. The configured ID Block and ID Number must match the PU definitions at the remote DLUS node. If the Dependent PU Name is not specified, the Exchange ID is searched.

Configuring Steps for Dependent LU Requester

o	Step 1. Configuring the Host Controller for DLUR Support Use the CRTCTLHOST command to create the controller description. If you have already created a controller description for such functions as 3270EML or NRF, you must change the link type to *DLUR. Retrieve the description, change the link type and run a CL program.
o	Step 2. Configuring the Device or Printer Descriptions

Further information on DLUR can be found in the Remote Workstation Support Version 4 manual, SC41-5402-00.