On 5/22/18 4:35 AM, Peter Coghlan ***@beyondthepale.ie
[H390-VM] wrote:
>> > If IBM would allow to run a modern
>> > VM version, from VM/SP to Z/VM, would
>> > be possible to rebuild an hobbyist VNET
>> > like network?
>>
>> TLDR: Why would you need a modern VM?
>>
>> IBM had peer to peer connections for 239 systems in 1979, per
>> https://en.wikipedia.org/wiki/RSCS#Background. Those would have been
>> VM/370 R6 systems or older. The basic concept of store and forward via
>> the RSCS and the VM spool really didn't change in 20 years.
>>
>> The Wiki link above has a comment about how the public released version
>> of RSCS had stubs for store & forward functionality. That makes me
>> wonder how hard it would be to add peer-to-peer store & forward to the
>> VM/370 R6 RSCS version.
>>
> I can confirm that it is possible and it has been done (mostly). The
> peer-to-peer store and forward of files part is pretty much complete but
> the processing of messages and commands is not quite there yet.
Messages are sort of important because they also provide file forward
status.
>> Even now you could probably take VM/SP RSCS Version
>> 1 R3 and get run it running on from anything from VM/370 R6 up through
>> z/VM. (Note that I have /not/ tried this.)
>>
> Quite possibly. However, I am not in a position to try this either.
>
>> A useful reference for RSCS behavior under later VM versions would be
>> https://archive.org/details/bitsavers_ibm370RSCSlingCommunicationsSubsystemNetworkingPro_13960888.
>>
>> I can't seem to find a definition of the actual RSCS protocols, but
>> foreign programs like JNET (VMS) and UREP (UNIX)Â implemented them, so
>> it must be possible. Or implement a Hercules specific BSC driver (VMH?).
>>
> There are various publications available such as SA22-7539-02 and SC23-0070-03,
> both titled "Network Job Entry Formats and Protocols". I think I downloaded
> them from the IBM website.
SC23-0070-03 looks more applicable.
>> Now, to answer the obvious question before it's asked ... how does one
>> invite MVS 3.8 to the party:
>>
>> That's harder.
>>
> Someone who knows MVS much better that I do looked into this and agrees that
> it is harder.
>
>> The NJE protocol */is/* documented:
>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasa600/toc.htm
>>
>> Doing Store & Forward under VM requires a single virtual machine that
>> supports RSCS protocols and a spool that already supports tagging. There
>> is not anything break outside the reader queue of the RSCS machine,
>> Compare this to NJE store & forward support on MVS, which requires you
>> get into the guts of JES2. If (when?) you screw up and your spool is toast.
>>
> There are two other possibilities.
>
> Firstly, RSCS can exchange VM spool files with MVS running in a virtual
> machine. Probably not very satisfactory but should work as a last resort.
>
> Secondly, RSCS can do RJE to a BSC line using the DMTSML driver and I am told
> MVS can also do RJE to a BSC line. It should be possible to use a BSC line
> emulated by Hercules as the last leg to link MVS to an RSCS NJE store and
> forward network. Some horrible kludges may be necessary to allow MVS to
> communicate with nodes more than one hop away but it should be a lot easier
> than implementing full NJE in MVS. It can also be used as a stepping stone
> to doing it "properly".
It comes down to so long is MVS 3.8 is leaf node, it's easier. Then it
can say "ever node I don't know, go HERE". This would actually be
better than the NJE enabled MVS/SP, which simply dropped all unknown
nodes on the floor.
Of course, NJE enabled MVS/SP had other issues, like no native support
to message off node, and hacks to support it tended to generate your
entire chat transcript in the system log -- not good for young college
students in love in the BitNET era. (TUCC's VM/XA box did this).
I think in summary, it is best to put simply MVS aside until VM works.
>> p.s. Is the non-store & forward RSCS on the six pack?
>>
> Yes. All the source is there. It includes the DMTSML driver which can do
> some variants of RJE over a BSC line.
>
> From reading "NJE Formats and Protocols", it becomes clear that NJE is mostly
> just another layer of protocol placed on top of RJE. The lower levels of both
> are pretty much identical. I have written an update for the DMTSML link
> driver that turns it into an NJE link driver. The latent support for routing
> present in the base RSCS allows store and forward to work using the VM spool.
> It is less clear to me how to handle routing of NMRs (NJE messages and
> commands) in a way that is compatible with handling RJE messages and commands
> so I am stalled on that part at the moment.
>
> It turns out that the BSC lines emulated by Hercules are not quite ideal
> for NJE links between RSCS nodes. I have a modified Hercules device which
> looks like a 2703 on the inside and implements NJE over IP to the outside
> world. The NJE over IP protocol (also known as VMNET but not to be confused
> with something different in Hercules which was also called VMNET) was
> developed to allow the BITNET network to operate over TCP/IP. IBM adopted
> the same protocol for it's implementation of NJE over TCP/IP so using this
> protocol has the added advantage that it is possible to interoperate with
> later versions of RSCS and MVS which are natively capable of NJE over IP,
> as well as JNET and UREP as mentioned previously. There is also the freely
> available HUJI-NJE which was designed to implement NJE on VMS and Unix.
> With a fair bit of work (by someone other than me), it should be possible
> to use this to implement NJE on Linux.
I hope you also kept the original device (or that the new one is
compatible with the original on the other end), as there will be people
like me who need to rely on the stock behavior.
> Ps: I think this project is somewhere around state 1b on the list below :-)
That was a random selection, but seemed accurate. I wondered who would
notice.
Today's is less random.
>> The six stages of a project:
>> 1. Unbounded enthusiasm 4. Frantic Search for the Guilty
>> 2. Total disillusionment 5. Punishment of the Innocent
>> 3. Panic 6. Reward of the non-participants
--
Drew Derbyshire
Google Voice Telephone: 425-318-4350 (NOT for text messages!)
P-1 CUR ALLOC 20193.....5804M CALL GREGORY