A Hercules RFC: The status of Remote Job Entry options under
Hercules.
Since Ivan Warren so kindly implemented the 2703 Bisync emulation,
I've been spending some time investigating the various RJE options we
have with Hercules under the "vintage" operating systems DOS, OS/360,
DOS/VS, VM/370, OS/VS1, and MVS. I have very little real life
experience with mainframe bisync communications, and none at all with
RJE in any form. Nor do I have any manuals, beyond the basic
description of the bisync protocol and the 2780 RJE terminal
available at www.bitsavers.org/ibm/datacomm. What I know comes from
reading source code and experimenting. Things I say here could well
be wrong, although I think them to be true and am pretty sure of my
information at this point. Please, anyone who can correct anything,
or who could provide any further information (particularly manuals!)
contact me.
Why bother with RJE at all?
After all, we already have several options for getting JCL to the
various OSes under Hercules, all acceptably easy. But reading the
output is less pleasant, all we generally get is a simulated printout
in a disk file. That's better than wasting the tons of paper we used
to waste in the real world, but it's a bit clumsy. But the real
reason for getting RJE to work isn't practical, it's mainly to learn,
to preserve this part of computer history, and to have geek fun. If
the ultimate result is a pleasant way to submit jobs and recieve the
results so much the better.
Background information.
RJE is a generic term for the various methods of submitting batch
jobs (generally JCL) from remote stations, over a bisync line, to a
host operating system. RJE provides not only for sending jobs, but
for receiving the printed (or punched) output. It's not an
interactive process like using a 3270 terminal. There are in fact
three main types of Remote Job Entry. I'll describe each one briefly
and relate it generally to its availability to us on Hercules.
RJE - This is the "original", vanilla method. Its first
implementation was announced with the first 360 mainframes. That
implementation was 2780 Data Entry Terminal. This is the common
baseline for IBM mainframe RJE. Almost every IBM mainframe OS
provides for connecting to a 2780 or 3780 RJE station. 3780 is just
a slightly more capable elaboration or 2780 protocol and is now the
most commonly used in th real world. In fact this became a de facto
method of data exchange in the business and financial world, and is
still, in the 21th century, used for EDI (Electronic Data
Interchange). 2780/3780 RJE is a simple protocol that provides for
half-duplex (one direction at a time) sending of "card decks" to the
host, and the reception of "printed output" and "punched cards" from
the host. I have verified that OS/360, DOS/VS, OS/VS1, VM/370, and
MVS all have options to configure bisync lines to act as hosts to
2780/3780 RJE stations. DOS/360 almost certainly does also but I
haven't verified this.
MRJE - This is also referred to as "Hasp RJE". It's more
sophisticated than plain RJE, in that it provides for interleaved
streams of data to and from up to 7 readers, printers, and punches
all at the same time. It also provides for special control records,
messages, and commands to be exchanged between the station and host.
MRJE stands for Multileaving Remote Job Entry. It is NOT compatible
with 2780/3780 protocol (I don't think. Could it be?). Among our
operating systems, only VM/370, OS/VS1, and MVS support MRJE. If we
get a version of HASP running under OS/360, we can add it to the list
also. We also have have some options on the station end. VM/370
RSCS will act as a station, and also under MVS there are some
assembler programs to produce standalone JES2/HASP workstation
programs for the System/360, System/3, and 1130.
NJE - Network Job Entry. This is the modern form of RJE, much to be
preferred. However, it requires SNA. Of our operating systems, only
DOS/VS seems to have any code that could support NJE. However, at
the moment, we don't emulate the hardware to support it. SNA won't
work over bisync, only SDLC. So, NJE is out as an option for our
OSes until we do some serious work. As far as I can see, even if we
had an SDLC emulation, VM/370 and MVS 3.8 (not to mention the old
OS/360) don't have any software support for NJE. I could be wrong
about MVS 3.8. I hope so. I'm sure about VM/370 R6.
The status of Hercules-based RJE as I know it at the moment.
First, it's necessary to remember that RJE isn't a peer to peer
idea. There is always a station (the slave) and a host (the
master). Nor is it a generic file exchange system, although it can
be sometimes used as such (particularly in VM/370 RSCS where it can
be used to simply exchange data files between machines across the
link).
Plain 2780/3780 RJE - We have a plethora of hosts, and no stations.
Many masters (OS/360, DOS/VS, MVS, VM/370), but no slaves. There are
many commercial products that emulate a 3780, but they all cost
money, and they are all designed to do so over real bisync hardware.
I long thought that the DMTNPT driver in VM/370 could be a host or a
station, but that was wishful thinking. In fact, it's only a host.
The only way we'll ever use plain RJE with Hercules is to write our
own 3780 emulator that connects to the TCP/IP 2703 device on a
hercules mainframe.
MJRE - This is the version of RJE we can actually play with using the
tools we have. The DMTSML driver with VM/370 RSCS can be either a
host or a station. This allows two RSCS systems to connect to one
another. The limitation of this is that one is a station and the
other the host. Files will flowly nicely up to the host and be
routed to whatever VM user specified by the sender, but I don't know
how to route files back in the other direction over the same link.
Files sent back to the station side seem to wind up on the station's
system printer or system punch. However, flexible bidirectional file
exchange CAN be set up by using two lines between the two VM/370
systems, so each can play the host role on one and the slave role on
the other. Acting as a station, VM/370 *should* (I have not yet
accomplished this due to the difficulty and lack of docs on the MVS
end) be able to submit jobs to a JES2 RJE line under MVS 3.8. It
should also be possible to submit jobs to OS/VS1 RES (its
implementation of MRJE) from RSCS. Another option is to punch out
the standalone card deck that's generated when you assemble HRTPS360
in SYS1.HASPSRC under MVS. I have configured and assembled this but
haven't yet run it. You need to change the configuration because the
default is to run on a model 20. You can change this to a model 30
for hercules. You'll also need to change some of the default unit
record equipment, and probably the default 2703 device address.
NJE - I won't say it can't be done. But, we'll need an SDLC
emulation similar to the 2703 we have now, and we'll need some form
of station emulator. Since VM/370 doesn't have an SDLC/NJE line
driver, there'll be a steep climb to achieve NJE. And so far as I
know, all we'd get is the ability to NJE to DOS/VS. Not all that
attractive, unless we find NJE code somewhere in MVS 3.8. That would
make the work necessary to get NJE up more attractive. Another
option is writing a VM/370 RSCS line driver. Given the size and
complexity of the two current (easier than NJE) line drivers, this is
far from a weekend project.
Bottom line.
My current plan is to write a simple Linux command-line 3780
emulator, and test it with DOS/VS, OS/360, MV/370, and MVS. When
that's done I'll upload it to the Hercules-390 group files section.
No timetable promised :) But hopefully soon.
Following that, it should be possible to write a Windows GUI 3780
emulator that could make job submission to any Hercules based
mainframe OS really nice. You could load and save card decks, or
edit them in a window, submit them with the click of a button, and
see the results appear in your output window automagically without
needing to sort through output from other unrelated jobs. You could
physically print the output on your PC printer, save it, or just
throw it away. This is the ultimate "practical" goal of all this.
There's no reason why this emulator couldn't be expanded to support
MRJE also.
Dutch