Most Integrated System in the World?

11 12 2009

Basically, the IBM i (OS/400 i5) is the most integrated, some say psychotic, computer system ever built. With it you can set up LPARs from which to independently serve and/or process different types of information and/or address different domain spaces using AIX, Linux and/or native OS/400 images. It allows direct access of centralized data in the native database file system, PC file system, UNIX file system, optical file system, and other file systems from the native OS/400, PASE (AIX bind) or Windows Server interfaces. It provides system access via green screen, graphical interface, web centric interface and others. It allows running legacy and new COBOL and RPG applications along side of JAVA and PHP applications.

What system could be more integrated? The internet! IBM i systems, along with other systems, provide users with unbelievable power, flexibility and interconnectivity and they all integrate via the internet. How can you provide services to and receive services from customers, venders, government agencies, web portals, etc. without compromising your systems integrity? As demonstrated in the news this past week, not even the US Government is immune to compromise.

There is hope and in the coming weeks I plan to provide some helpful insight. Being an IBM i bigot, you can bet that IBM i will be included in the discussions.

Stdio problem when moving non-i5 user to native processes via ssh

3 09 2009

We needed to move non-i5 internal users to native i5 processes. For this to work effectively I set links to processes under the QShell because it provides direct native execution and then set up PASE scripts to run via ssh. A number of IBM documents describe setting up ssh so that users need never see a native i5 screen.

Example application – SSH

OpenSSH: How to Stop SSH from Creating Thousands of Job Logs

IBM Redbook
Securing Communications with OpenSSH on IBM i5/OS, July 2006

‘Qshell and OpenSSH for IBM System i’ by Bob Bittner dated 15-May-2007
Note: This paper is an excellent introduction to the QShell.

The problem is that QP2SHELL does not properly handle stdio for the QShell and QP2TERM cannot be used because the job running under the SSH subsystem is not interactive. Using QSH CMD(‘usr/sbin/sshd’) as described in Bob Bittner’s document in place of ‘CALL PGM(QP2SHELL) PARM(”/QOpenSys/usr/sbin/sshd”)’ – note that ” is two single quotes – , does correctly handle QShell stdio. So, changing the follwing

TEXT(‘Job description for SSHD autostart’) USER(SSHDUSR)
RQSDTA(‘CALL PGM(QP2SHELL) PARM(”/QOpenSys/usr/sbin/sshd”)’)


TEXT(‘Job description for SSHD autostart’) USER(SSHDUSR)
RQSDTA(‘QSH CMD(”/QOpenSys/usr/sbin/sshd”)’)

resolves the problem. The command ‘QSH CMD(”/usr/sbin/sshd”)’ may also be used as both /QOpenSys/usr/sbin/sshd and /usr/sbin/sshd link to the same executable.

One additional problem remains; how to get the stdio from the various environments, native, QSHELL and PASE to all display in the ssh terminal window. This is accomplished via either the .env or .profile file. See and for additional information regarding these files. To obtain the needed environmental variables and their settings, invoke PASE using CALL QP2TERM from a native command line and enter env. Use the output from the env command for the .profile file since the installed ssh client uses the BSH shell. Do not include variables that will result in conflicts with the shell such as the SHELL, LOGNAME, LANG or HOME.

I have implemented and tested this on both V5R3 and V5R4 systems.

It should be noted that there are many instances where the system command from PASE should be used to execute native processes rather than using QShell. In fact, I used both methods in the PASE shells implemented for this project.

Some may also find the following IBM Software Technical document, OpenSSH: Configuring Server / Client, helpful.