Using Generic IBM i Sign-ons for Reaching a Second System

Let’s say you have the following IBM i partitions at your location:

PROD1 = Production machine (system 1)

DEV1 = Development machine (system 2)

Everyone has to log on to PROD1 but only selected people need to log on to DEV1 (mostly programmers but sometimes testers). With this setup, you need to configure IBM i Access for Windows PC5250 sessions for system 1 (PROD1) on each desktop but you don’t want to configure PC5250 sessions for system 2 (DEV1) on each desktop.

How do you configure your user desktops so they can sign on to both system 1 and system 2 without putting a second system 2 session on each desktop?

You can solve this problem by configuring a generic user profile on your system 1 partition  that automatically launches a system 2 sign-on screen without requiring a separate IBM i Access for Windows PC5250 session.

By doing this, users can log on to system 1 with their PC5250 session and when needed, launch a system 2 sign-on without putting a separate system 2 PC5250 session on each desktop.

Here’s how to do it.

There are three steps for allowing users to sign on to a second system while attached to another system’s PC5250 session..

1. Make sure both your systems are set up to use display station pass-through to other systems. To determine whether you can do this, check out the i/OS Configuration section in my IT Jungle article on setting up the poor manager’s Single-Sign system. This will show you which system parameters to configure to enable display station pass-through on your systems.
2. Set up a CL program on system 1 to create a pass-through session on system 2 whenever the program is called. This program should be accessible by anyone and it would only contain the following statements.

PGM
STRPASTHR  RMTLOCNAME(system2) PASTHRSCN(*NO)
SIGNOFF
ENDPGM

Where system2 equals the remote system name you want to reach from the system 1 IBM i partition.  Cal this program REMOTE.

3. Set up a user profile with the following parameters on system 1.



The keys here are to correctly set up the Initial program to call (INLPGM), the Initial Menu (INLMNU) , and User password (PASSWORD) parameters of the user profile . They should be set to these values:

• INLPGM should equal the name of the REMOTE program you created in step two. Whenever a user signs on with the REMOTE user profile from system 1, the system will start a pass-through session to system 2 and show a system 2 sign-on screen.
• INLMNU should equal *SIGNOFF so that this user profile can only be used as a gateway to system 2. It cannot be used to sign-on to system 1.
• Set the REMOTE PASSWORD to something  that’s easy to remember for your users. In many cases, shops will set the REMOTE password to the word remote . This may or may not constitute an audit violation so consult with your auditing group before setting this up. However, since the REMOTE user profile can never sign on to system 1, it may not be an issue.

Once this configuration is in place, any user on system 1 can get to system 2 just by signing on with the REMOTE user profile.