Implementing a PC-to-other host File Relay

The main goal of this facility is to provide an easy way for a PC user to submit jobs to a remote host and obtain output from a remote host, without the PC user having to connect or logon to that remote host. All of the file transfer exchanges appear to be local to the PC user. This eliminated the need for the PC user to stop what they are doing, initiate an FTP process to the remote host, and then issue one or more commands to send or receive a file. Occasionally, a login or telnet session would also be required to obtain the desired output. All they need to do now is to copy a file from or to two network drives (remote Samba server ``shares''), and everything else is done automatically.

While this particular facility was developed for use with an IBM mainframe and NetBIOS/Windows PCs, it can be equally used for other hosts where a remote job could be executed and file transference is accomplished by FTP (or some other suitable function). Implementing NetaTalk[21], the UNIX-based AppleTalk file system, this file relay is also available to Macintosh hosts. Again, while the remote host details will be specific to a mainframe in this project report, the process is not limited to such a host. The same is true for the user side. In the remainder of this section, the terms ``PC user'' and ``PC host'' are interchangeable with other user-based scenarios using different types of computers.

The key mechanisms used for this file relay are FTP and user workstation file copy. The remote host is expected to be an IP host which provides an FTP server to allow files to be sent to it. In the case of the IBM mainframe, a special FTP command (SITE) was used to direct the incoming file to the ``job queue'' of the remote host. To obtain remote host output, the user would add several FTP commands to their ``job'' which executed on the remote host. This would send the output data to the Samba server. To obtain a local copy of the output data, the user simply copies the file from their Samba server ``output share'' to a local folder.

Figure 6: User to remote host via FTP and telnet
User does all of the work

Figure 7: User to Samba server
Samba server does all of the work

It should be noted that the LDAP service was chosen to store the user's remote host FTP/login password, but the same data can be supplied in the user's job file. In general, however, it is simpler to ask an LDAP server for a data entry than to parse a job file, looking for the same data even if a fixed scheme is applied and expected in locating said data. The LDAP mechanism also allows more data to be stored for the given user, such as a ``notify'' field intended to be used to send a notification to the user in certain situations. Again, this same information could be incorporated into the job file to be submitted, which then must be parsed and properly extracted. The LDAP mechanism helps to reduce the multiple possibilities of user data entry errors, though it certainly does not eliminate all possible user errors.

Figure 6 and Figure 7 illustrate the before and after affects of providing this service.

In Figure 6, the user must manually go to the remote host to submit a job or retrieve job output. This may or may not require a telnet session to find the job output information. The user must be familiar with the FTP process including all special commands such as the SITE command required in our situation. They must also be familiar with finding their output data files and how to move them to where they want them, most likely using an FTP session. For some users this process may be counterintuitive and time consuming.

In Figure 7 the user has established two network drives available to them from the Samba server, which appear as folders on their local system. They can then copy files in to and out of these network drives as easily as they would with any other local folders. This provides a well understood mechanism for the user once they understand which files go into or can be found in which remote folder. They also are free to use whatever local tools they desire to do the file transference required.

The job to be run is copied into the remote submit folder on the Samba server. An automatic process added to the Samba server, using Expect, then sends the job file to the remote host for execution via FTP. Two log files are maintained: one in the user's submit folder which shows the submission process result, and one in the server's log directory which shows a count of all jobs submitted per user.

A special ``job step'' can be used to transfer output data to the user's remote output folder on the Samba server. This can be added to a job file placed in the submit folder, or can be a job that the user has permanently stored on the remote job execution host. Upon execution of this special job step, the remote host deposits the specified output file into the user's output folder. The user can then copy the output file to their PC.

Using this process, the user never has to logon or connect to the remote host.