Manipulating Systems from the HP3000 Using REMSH

Manipulating Systems from the HP3000 Using REMSH

Integrating today’s disparate computer systems is a frequent task for system administrators. Integration is not just a matter of sharing data; often it means one system controlling another. For example, a common question we field is “How can I script a job to telnet from my HP3000 to run commands on a Unix system?” The implementation of telnet on MPE does not include scripting capabilities such as redirecting input to a file, a common method of automating programs that are designed to be interactive.

The answer to this is to use REMSH, which is short for Remote Shell. REMSH allows a client to execute a command on a remote server. Proper configuration of the server is key to both enabling client access and maintaining security. Once access is obtained you have a powerful method to automate procedures in a very simple way.

REMSH is fairly straightforward. There are simply 3 parameters to pass. The host name or address, the UNIX login ID (designated by the –l) and the command to execute specified with –n. The UNIX setup (in this case HP-UX) controls security and must be set up just right.

Consider the following example:

!job oe501,jobs.acctg;outclass=lp,1
!comment
!comment This job performs the following functions
!comment 1. Extract orders ready to be shipped
!comment 2. Transfer to Unix system
!comment 3. Run data file through
!comment the truck scheduling delivery system.
!comment
!comment Begin step 1
!build oe501a.data;rec=-60,,f,ascii;disc=5000
!run oe501.prog;xl=’xl2’;parm=1
!comment
!comment Begin step 2
!comment Transfer file to Unix system
!ftp
open 192.168.50.32
user trucksch
pass truckschpw
put OE501A.DATA /usr/trucking/data/oe501
quit
!comment Begin step 3
!comment
!comment Use REMSH to execute the uling script
!comment Log on to the unix server at 192.168.50.32
!comment as user ‘trucksch’ and execute the script
!comment /usr/trucking/scripts/oe501u
!comment
!remsh.net.sys "hpux3 –l trucksch –n /usr/trucking/scripts/oe501u"
!comment
:eoj

REMSH Host Setup for HP-UX.

There are several ways to provide REMSH capabilities. Here I will illustrate the most secure method. The reason it is secure is because it grants access based upon the client machine and login. That is, you can deny access unless the REMSH command originated from a specific machine (the HP3000) and a specific logon (i.e. JOBS.ACCTG). All of this is controlled by placing a file named .rhosts in the home directory of the UNIX account you will log in to. In our example this is the account ‘trucksch’. Remember that under Unix a user is called an account.

Each line of the file designates the machine name or IP address to accept connections from and a valid logon ID. The .rhosts file required to permit our sample job looks like this:

$cat /home/trucksch/.rhosts
# syntax for each entry is:
# HostNameOrAddress AuthenticationName
# where the HostNameOrAddress is the remote system we will allow to connect
# and AuthenticationName is the remote user’s login ID
#
# .rhosts for account trucksch
# allow connections from the HP3000 for user MANAGER.SYS or JOBS.ACCT
192.168.50.16 JOBS.ACCTG
hp3000.mycompany.com MANAGER.SYS

Note that 192.168.50.16 and hp3000.mycompany.com are interchangeable. Whenever possible it is best to use the DNS name for a machine rather than its IP address to provide for flexibility. If the IP address for a machine changes you don’t want to have to go back and adjust all of the hardcoded addresses scattered around on different machines. Also note that the MPE user ID must be entered in .rhosts in upper case.

Telamon offered a version of REMSH that uses slightly different syntax and is more fully featured. (If you are interested in Telamon’s version please contact us). The same REMSH command from our sample job looks like this running under Telamon’s program.

:remsh.pub.telamon "hpux3 -l trucksch /usr/trucking/scripts/oe501u"

The .rhosts file on the remote HP-UX machine has an entry that looks like this:

hp3000.mycompany.com jobsacctg

Notice the difference in user authentication name between the .rhosts entry for MPE’s built in REMSH and Telamon’s version. MPE built-in REMSH passes the current USER.ACCOUNT for authentication in upper case, including the dot, whereas Telamon REMSH concatenates the user and account names together and passes them in lower case. Telamon REMSH also behaves differently for users with SM capabilities by supplying “root” as the authentication user name instead of the MPE user and account. To override this option add the “-m” switch. Furthermore, Telamon REMSH includes a “-v” for verbose option, which is very handy for debugging purposes.

When scripting for REMSH processing, there is a difference between logging in directly and using REMSH. You may need to setup environment variables in a script to be able to use them. When a user logs in directly to HPUX, files like /etc/profile and $HOME/.profile are executed, but they will not be executed when REMSH is used. It may be possible to get some of the environment established the same by using csh instead of sh in the /etc/passwd file for the remote user. There are details about this behavior in the man pages for remshd and sh on the UNIX computer. The csh shell uses .cshrc and .local for startup files where as sh uses /etc/profile and $HOME/.profile.

There is no REMSH server for the HP3000, only a client. If you need to provide a technique for a remote server to control processes on the HP one method is the “SITE STREAM JOBNAME” in FTP. A remote user can log on to the HP and stream a job that can perform tasks on the user’s behalf.

As you can see REMSH is a powerful tool you can utilize to automate processing. Use it to take advantage of robust job scheduling capabilities of the HP3000 (such as Maestro or Sleeper) to drive processing of other servers. Or use it to streamline frequently performed or repetitive tasks that ordinarily require you to telnet from one system to another. The possibilities are limitless. Use your imagination.