If you need to be in two places at the sametime, Display Station Pass-Through may provide a simple answer to your dilemma.

Brief: Display Station Pass-Through is one of the most common methods used to link two AS/400s together. The reason for such popularity is the simplicity of the basic link. No special programming or convoluted configurations are required-just a few simple CL commands and you're off and running. This article uses a case study approach to walk you through a basic Display Station Pass-Through setup.

It's one of those days that starts out with everything going right to make it all go wrong. As you sit there enjoying a cup of coffee and perusing this month's issue of Midrange Computing, your boss comes in and tells you that the programmer who was maintaining your system in New York has quit. He goes on to appeal to you that, without your help, the folks in New York will be left stranded. Could you figure out a way to support them until a new programmer is hired, while maintaining your current responsibilities with the users here in Pleasant Hill, California?

Of course, you reply, "No problem." Your boss beams a great smile and exits, leaving you with only one minor problem: How in the dickens can you be in two places at the same time? I'm about to show you how to do just that with IBM's Display Station Pass-Through (DSPT).

Lining Up the Ducks

Let's set the stage for this project. In the first place, why DSPT? Well, I've got to believe that you wouldn't want to fly back and forth between California and New York every time one of the programs in New York sneezes. Since you should soon be relieved of this additional responsibility of keeping the New York installation running, you quite naturally would like a simple "off-the- shelf" solution, right? This is only supposed to be program and system maintenance-not the transferring of objects which DSPT can't do but SNADS can-so DSPT seems to be the logical choice. IBM could not have designed it any better with this type of situation in mind. Since its main purpose is to allow users (in this case, the only user is you) on one machine to access programs and data on another, it seems like a perfect fit.

Of course, we need to sort out a few terms and connectivity issues before we can fire up DSPT. First is the actual communications connection between your system in Pleasant Hill and the remote system in New York. In DSPT, your machine is normally referred to as the "source" AS/400 and the remote (New York) machine is called the "target" AS/400, so we'll go with those terms. A quick check with your boss yields the information that each machine has a communications adapter available for your project and both locations are equipped with IBM 7861-015 modems which are capable of Synchronous Data Link Control (SDLC) communications at 9,600 bits per second (bps). So far, so good. In addition, you learn that no one is currently using the leased, point-to- point communications line connecting the two locations. 1 depicts the setup so far.

Of course, we need to sort out a few terms and connectivity issues before we can fire up DSPT. First is the actual communications connection between your system in Pleasant Hill and the remote system in New York. In DSPT, your machine is normally referred to as the "source" AS/400 and the remote (New York) machine is called the "target" AS/400, so we'll go with those terms. A quick check with your boss yields the information that each machine has a communications adapter available for your project and both locations are equipped with IBM 7861-015 modems which are capable of Synchronous Data Link Control (SDLC) communications at 9,600 bits per second (bps). So far, so good. In addition, you learn that no one is currently using the leased, point-to- point communications line connecting the two locations. Figure 1 depicts the setup so far.

If things keep looking this good, you might not have such a bad time with this after all. Now that you've got the physical part of the communications link down (modems, phone line, communications adapters), what about the operating- system portion of this link? DSPT uses Advanced Program-to-Program Communications (APPC) to allow the New York and California machines to communicate with each other, which relieves you of the need to write code to do that. APPC requires an APPC controller description in order to accomplish its job, so that must be set up.

So it looks like all you're missing is the APPC controller description and the SDLC line description for the point-to-point communication line. These descriptions are required at both ends for the communications link. They should be very straightforward and the CL commands to create them are reproduced in 2 and 3. I have included the network attributes for each machine and linked the parameter values that must match between the controllers and lines in order to make a connection.

So it looks like all you're missing is the APPC controller description and the SDLC line description for the point-to-point communication line. These descriptions are required at both ends for the communications link. They should be very straightforward and the CL commands to create them are reproduced in Figure 2 and 3. I have included the network attributes for each machine and linked the parameter values that must match between the controllers and lines in order to make a connection.

For spatial reasons, I have made certain assumptions about your familiarity with CL command parameters in setting up an SDLC line and an APPC controller description. The parameters in Figures 2 and 3 are all you should need to facilitate your connection. If you require more information, refer to the IBM CL Reference under CRTLINSDLC and CRTCTLAPPC.

You will need to create and run the CL program required for the Pleasant Hill- to-New York link in 2 and the AS/400 operator in New York will need to create the CL program required for the New York-to-Pleasant Hill link (see 3). Then you're all set up, from a communications point of view.

You will need to create and run the CL program required for the Pleasant Hill- to-New York link in Figure 2 and the AS/400 operator in New York will need to create the CL program required for the New York-to-Pleasant Hill link (see Figure 3). Then you're all set up, from a communications point of view.

Entering Virtual Reality, Pass-Through Style

A clear comprehension of virtual devices is instrumental to understanding DSPT. On an AS/400 using DSPT, the target system uses virtual devices to direct output to physical devices on the source system. If virtual devices were AS/400 files, they would be logical views that facilitate the routing of information you need where you need it without having to create a whole new physical version of the file (or having to actually add another physical communications controller to the system). Like logical files, virtual devices are pretty hassle-free entities.

At first, handling all these virtual devices may seem daunting, but IBM has come to the rescue by allowing the system to automatically create all the necessary virtual devices. Since we want to keep this particular implementation of DSPT as generic as possible, we'll take advantage of this facility.

When the source system (Pleasant Hill's AS/400) requests automatic device configuration on the target system (New York's AS/400), the target system looks at the virtual devices attached to a virtual controller (imagine a virtual 5494 controller and you'll get the idea). If a device is available, the target system program configures it to match your physical device. But if the target DSPT cannot find an available virtual controller or device, it will create one or both. The controller will be called QPACTLnn and the device will be called QPADEVnnnn where nn is a two-digit sequence number and nnnn is a four-digit sequence number. By the way, these virtual devices I've been talking about are just that-virtual versions of IBM terminals like the 5252 Model 11, the 5291, the 3196 and so on. You don't really have to worry too much about this issue with automatic virtual device configuration though; the system will find something that matches or can be defaulted to about 99 percent of the time.

You'll note that I described the virtual controller above as QPACTLnn. Although you can specify a particular virtual controller it makes more sense to let the system handle this. Each virtual controller handles up to 250 virtual devices; should you need more, automatic configuration will create new virtual controllers named QPACTLn+1, QPACTLn+2, and so forth. You can see the beauty of using automatic virtual device configuration with DSPT: it does all of the work for you!

One small step is required before you can let the automatic virtual device configuration take off. You have to turn this automatic configuration feature ON by checking the AS/400 system value for Autoconfigure Virtual Devices (QAUTOVRT). If you've never used this system value, it will be set to zero. This will not allow for the creation of virtual devices or controllers. When you change this value to anything from 1 to 9,999, the system allows for the creation of that many virtual devices. Don't set it to 9,999 though; the higher the value in a busy DSPT shop, the greater the performance hit your machine will take as it creates all of these virtual devices. Also, DSPT does not delete virtual devices! You'll have to delete these manually.

The target system checks the QAUTOVRT system value when it cannot find an available virtual device for a given DSPT session. If, by virtue of creating the requested device, the number of virtual devices created exceeds the value in QAUTOVRT, the DSPT session will be terminated!

We'll use the Change System Value (CHGSYSVAL) command to set the value of QAUTOVRT to 10 in Pleasant Hill, and we'll instruct the New York operator to do the same on his AS/400. The values don't have to be the same on both machines- in fact, the target machine is the only one you really have to worry about because the New York installation is not going to be passing through to California now-but I'm assuming that your boss will in fact hire a new programmer in New York and that, by that time, DSPT will be a way of life. This just sets everyone to the same values, allowing two-way DSPT to be implemented when it's needed. The CL programs in Figures 2 and 3 are already set up to allow two-way DSPT, so you won't have to change that either.

User Profile? What User Profile?

One of the topics I get asked about most often with DSPT is user profiles. The various ramifications of user profile setup on target systems, security issues and so on could fill another entire article (not a bad idea at that), but I've come down to a fundamental philosophy: keep it simple-don't overthink this issue.

To support New York's AS/400, the only requirement is that you have a user profile on the target machine. However, in general, you should create the required user profiles on both machines (target and source) with an eye toward granting the users on the target machine only as much authority as they need in relation to the tasks they will perform on that system. Many times, the features and systems available on target systems are not available on the source system. Often, generic user profiles on the target system will suffice- things like PGMR for programmers, OPER for operators and so on. In this example, we'll assume that your user profile is identical on both machines and that that's the one you'll use.

The Dash to the Finish Line

We've got the SDLC lines and APPC controllers described. We've set QAUTO-VRT to 10 for virtual device configuration and we're going to use the default virtual controller. We've set up your user profile on both the target and source machines. Now we need to vary on the SDLC line and controller to get the communications link running and we're about ready to get into New York. (I'll assume you know how to do this.)

The next thing to do is to obtain a command line on the source AS/400 and start DSPT, right? Well, it depends! First, you need to answer a question: do you want to see an AS/400 sign-on screen when you pass through to the target system?

AS/400 Pass-Through allows you to request automatic sign-on to the target system! If you ask for automatic sign-on and have the correct security, and if the target system allows automatic sign-on, you'll never have to see a target system sign-on screen again. This is not only a time saver; it can also keep life simple for your users because they won't have to go through another sign- on sequence when they pass through to the target machine. So let's go this route and look at the Start Pass-Through (STRPASTHR) command.

From a command line on the Pleasant Hill AS/400 (the source machine), key in STRPASTHR and press F4 to prompt. When you press F10 for additional parameters, the screen in 4 should appear.

From a command line on the Pleasant Hill AS/400 (the source machine), key in STRPASTHR and press F4 to prompt. When you press F10 for additional parameters, the screen in Figure 4 should appear.

We want to insert the remote location name from the APPC controller description created above, so we would type "NEWYORK" for this value. We're interested in only two other parameters: Remote User Profile (RMTUSER) and Remote Password (RMTPWD).

Use the *CURRENT value to change the value of RMTUSER from the default value of *NONE to your user profile (since it's the same on both machines). Then, by changing the RMTPWD parameter from its default of *NONE to your valid password on the target system, you will have completed this screen. Press Enter. The next thing you know, you should be signed on to the New York AS/400!

Now That I'm In, How Do I Get Out?

Once you've gotten into New York and have completed your work for the day, how do you get back to the Pleasant Hill AS/400? There are two ways to completely terminate a DSPT session and return to the source system. If you're using automatic sign-on (as we are in this example), you may simply key in a standard SIGNOFF command from a command line and the target DSPT session will end. You'll return to your original session on the Pleasant Hill source system.

The other way to end a DSPT session is with the End Pass-Through (ENDPASTHR) command. This command, entered from a command line, works basically like the SIGNOFF command and, in fact, includes the SIGNOFF command as part of its process. They both do the same thing; take your pick. I always use ENDPASTHR because it makes sense to my feeble brain to remind myself that I'm ending a DSPT session, not just signing off.

What if you need to interrupt your DSPT session to get back to your source system, but you don't want to terminate the pass-through? Well, have I got the command for you: Transfer Pass-Through (TFRPASTHR). This command does not end your DSPT session; it merely suspends it and presents the System Request panel. From here you can use option 1, "Display sign-on for alternative job" to obtain a sign-on screen at the source system. Once signed on to the source system, you can toggle between the two systems by using option 11 on the System Request panel which can be accessed at any time via the SysRq key.

By Remote Control

Needless to say, DSPT has a ton of other options, versions and flavors. In future issues, I'll delve into some of the ramifications of DSPT such as manual configuration of virtual devices, System Request options and more. I hope that this introduction to DSPT has been useful to you. If you have questions or suggestions on this topic, feel free to write me here at Midrange Computing and I'll get right on them.

Kris Neely is a system architect, designer, lecturer, writer and programmer with more than 17 years of IBM midrange experience. He may be contacted through Midrange Computing.

The Display Station Pass-Through Connection

Figure 1 The Pleasant Hill-to-New York Link

 *** Not able to reproduce graphic *** 
 
 The Display Station Pass-Through Connection
 
 Figure 2 New York's AS/400
 
 Network Attributes Display Network Attributes System: NEWYORK Current system name . . . . . . . . . . . . . . : NEWYORK Pending system name . . . . . . . . . . . . . : Local network ID . . . . . . . . . . . . . . . . : APPN Local control point name . . . . . . . . . . . . : NEWYORK Default local location . . . . . . . . . . . . . : NEWYORK Default mode . . . . . . . . . . . . . . . . . . : LU62 APPN node type . . . . . . . . . . . . . . . . . : *NETNODE Maximum number of intermediate sessions . . . . : 200 Route addition resistance . . . . . . . . . . . : 128 Server network ID/control point name . . . . . . : *LCLNETID *ANY More... Press Enter to continue. F3=Exit F12=Cancel CL Program to create New York's SDLC Line and APPC Controller PGM CRTLINSDLC LIND(PTP) + RSRCNAME(LIN011) + DUPLEX(*FULL) + TEXT('POINT-TO-POINT LINE TO PLEASANT HILL') CRTCTLAPPC CTLD(PLHILLCTL) + LINKTYPE(*SDLC) + LINE(PTP) + RMTNETID(APPN) + RMTCPNAME(PLHILL) + STNADR(01) + NODETYPE(*NETNODE) + TEXT('APPC/APPN CONTROLLER IN PLEASANT HILL') ENDPGM 
 
 The Display Station Pass-Through Connection
 
 Figure 3 Pleasant Hill's AS/400
 
 Network Attributes Display Network Attributes System: PLHILL Current system name . . . . . . . . . . . . . . : PLHILL Pending system name . . . . . . . . . . . . . : Local network ID . . . . . . . . . . . . . . . . : APPN Local control point name . . . . . . . . . . . . : PLHILL Default local location . . . . . . . . . . . . . : PLHILL Default mode . . . . . . . . . . . . . . . . . . : LU62 APPN node type . . . . . . . . . . . . . . . . . : *NETNODE Maximum number of intermediate sessions . . . . : 200 Route addition resistance . . . . . . . . . . . : 128 Server network ID/control point name . . . . . . : *LCLNETID *ANY More... Press Enter to continue. F3=Exit F12=Cancel CL Program to create Pleasant Hill's SDLC Line and APPC Controller PGM CRTLINSDLC LIND(PTP) + RSRCNAME(LIN041) + DUPLEX(*FULL) + TEXT('POINT-TO-POINT LINE TO NEW YORK') CRTCTLAPPC CTLD(NEWYORKCTL) + LINKTYPE(*SDLC) + LINE(PTP) + RMTNETID(APPN) + RMTCPNAME(NEWYORK) + STNADR(01) + NODETYPE(*NETNODE) + TEXT('APPC/APPN CONTROLLER IN NEW YORK') ENDPGM 
 
 The Display Station Pass-Through Connection
 
 Figure 4 The STRPASTHR Command
 
 Start Pass-Through (STRPASTHR) Type choices, press Enter. Remote location . . . . . . . . ________ Name, *CNNDEV APPC device . . . . . . . . . . *LOC Name, *LOC + for more values __________ Virtual controller . . . . . . . *NONE Name, *NONE Virtual display device . . . . . *NONE Name, *NONE + for more values __________ Mode . . . . . . . . . . . . . . *NETATR Name, *NETATR Local location . . . . . . . . . *LOC Name, *LOC, *NETATR Remote network identifier . . . *LOC Name, *LOC, *NETATR, *NONE System request program . . . . . *SRQMNU Name, *SRQMNU Library . . . . . . . . . . . __________ Name, *LIBL, *CURLIB Additional Parameters User profile . . . . . . . . . . *NONE Name, *NONE, *CURRENT User password . . . . . . . . . *NONE Name, *NONE More... F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys 05-37 SA MW KS IM II S1 S1034786 KB