Drew Derbyshire wrote:
[snip]
Third, you need a more modern RSCS and its associated tools:
* RSCS server that matches the RSCS V1R3 Program Product documentation
on BitSavers, supporting:
o remote commands
o remote operators
o store and forward of files
o forwarding of messages
o routing to distant systems
also (I had forgotten):
* configuration via file
It's definately configurable by files. It's just that you have to assemble
the files and build a new RSCS nucleus to make permanent changes :-)
More seriously, it is possible to generate lots of spare link and route
entries at nucleus build time and then use DEFINE, ROUTE and DELETE commands
to add new links and make dynamic changes while RSCS is running. This is
actually more flexible than working with a configuration file in some ways.
For example, it is possible to add new links or routes without having to
shut down and reipl RSCS to get it to reread it's configuration file. It is
a lot of fiddly work to make RSCS properly configurable by file for not very
much return so I prefer to spend the time on something else.
* MSGNOH support
Bob has done this one. I had put it on the back burner on the grounds that
on screen MSG overhead on VM/370 does not seem to be as great as in VM/SP
and later, as far as I recall anyway.
* link passwords
There is some support for this but it is not tested much because in most
cases, everyone has enough trouble establishing a link without putting
another obstacle such as passwords in the way.
Go through BitSavers manual for the RSCS PP R3.聽 No need to me to repeat
it all here.聽 (Nor you to have redocument all if you get your support
matching.)
I think that pretty much describes the approach I have been taking, except
I haven't been good at documenting which bits are done and which are not.
I think I've got pretty much all of the above done execpt for remote operators.
It's not released yet but I've given it to anyone who wants to try it out.
Haven't I told you about this already Drew?
I'm aware you're working on it, we got a link up to my test system.�
I was hoping you would use this link to see what works :-)
(It's been down for a while now.)
There are a few other basic items still to do to such as reporting the error
to the sender when a message cannot be delivered due to destination user
not logged on or disconnected for example.
Have you got a CTC driver?聽 (Useful for second level VMs)
Yes but it's not ready for prime time. It's very hard to get it started,
it's quite fragile and I need to find a way to stop it from trying to send
data as fast as it can even when there is nothing to send which consumes as
much CPU as it can get it's hands on...
My fallback solution for second level VM is to use two back to back
TCPNJE devices each using the TCP/IP localhost address 127.0.0.1.
* NAMEFIND
* NAMES
I wouldn't regard these as a priority. We can think about them when we
get to the point of having so many people to communicate with that we
cannot remember who is who. REXX with EXECIO should go a long way to
implementing them.
From prior experience, I tell you that the critical number of avatars
(i.e. real people or even yourself on multiple systems) is about 2.
Typing out out SENDFILE foo exec MAINT AT VERONICA more than once is a
pain, and error prone.
Give people a chance to be grateful for not having to type:
SPOOL D RSCS#TAG DEV D VERONICA MAINT#PUNCH foo exec (NOH
for a while first :-)
* SENDFILE
You forgot to mention RECEIVE. I've done limited hacks for both SENDFILE and
RECEIVE. They need some more work but they are not as cumbersome as
SPOOL PUN / TAG DEV PUN / PUNCH and ORDER / READCARD and they have some
limited NETDATA support too.
I also forgot RDRLIST and PEEK.
Maybe there are volunteers for these?
(I tend to use QUERY RDR ALL for RDRLIST and RECEIVE spid (HOLD followed by
TYPE or EDIT for PEEK - maybe I'm a masochist?)
* NOTE
* BSMTP gateway for mail
I haven't done anything on these yet.
Get the underlying support, I'll write /them/.聽 I was writing BSMTP code
when UUCP was still a thing.
Am I correct in thinking NOTE just does basic outgoing mail? If it is
possible to write CMS files from REXX now, we should have enough for a very
basic implementation - just write out some BSMTP to a temporary CMS file,
SENDFILE it to a configurable remote NJE gateway (or local user if
appropriate) and erase it. If REXX is not quite up to it yet, an
implementation in a compiled language called from an EXEC ought to be not
quite so easy but very doable.
You won't have chat without TCP/IP (below), but I think it would be
worth the wait.
I wouldn't regard it as a priority. I'm very close to be able to do chat
over NJE. I don't see any compelling reason to have TCP/IP based chat from
VM.
Because the server is a pain in the butt.聽 :-)
Fourth, consider TCP/IP and its associated tools:
1. TCP/IP server which uses the API of the IBM TCP/IP V1R2 as much as
possible.
The API is critical because it allows public domain software to be
backported.
MUSIC/SP uses the IUCV form of that API to do TCP/IP so this is what I'm
aiming at implementing for VM/CMS long term. Unfortunately, some public
domain software may also use the VMCF API. It would be easier to
implement the clients with the simpler VMCF interface too. However,
using VMCF means having to implement some sort of TCPIP virtual machine
server to traslate from VMCF into something that can get outside of VM
to a TCP/IP network and that is quite beyond me.
2. The RXSOCKET library adapted for the VM/370 implementation of TCP/IP
and REXX.
Not much use until REXX can do basic stuff like EXECIO.
3. RSCS tools (above) adapted for TCP/IP.
I don't know what you mean here.
I mean NAMES, NOTE, and SENDFILE all playing well with mixed (RSCS |
TCP/IP) networks.
I prefer to concentrate on getting the NJE part working first and
leave the TCP/IP support until later.
4. TELNET server
I'm not sure I see the need for a telnet server when Hercules already has
this built in.
Well, why do /any/// of it?
Actually, this needs logical device support, so it is probably not be
worthwhile.
Bob has done DIAG 7C logical device support a long time ago now.
5. mail gateway
My suggestion is to move the mail off system using NJE to a system which
can gateway it to the SMTP world. I think this was often a preferable way
to do it anyway because IBM's SMTP server implementation for VM was not great.
When I say mail gateway I mean a basic DVM which passes mail between the
VM system and a trusted external (modern) host.聽 IBM's SMTP server
implementation for VM was great ... for 1987.聽 That was a long time
ago.聽 Basically, it's support for the mail client.
The RSCS BSMTP gateway may be sufficient.
It should be possible to SENDFILE a BSMTP format file from a userid on my
VM/370 system to a mail gateway running on my VMS system (which runs HUJI-NJE
and PMDF) and have it pop out on the internet but I don't seem to have mail
going in that direction set up correctly yet. It works going the other way
though. I can send a mail from my VMS system to my VM/370 system and have a
BSMTP formatted email arrive in the reader of my CMS userid. Unfortunately,
I don't have a mail client to read it yet.
6. mail client
I've got some ideas but not done anything. Can't do everything.
Given the base TCP/IP聽 and REXX, I can kick in on that.聽 I once wrote an
mail client with a line mode editor in REXX for Clarkson.
Please proceed. Do you really need TCP/IP? For outgoing, just do as for NOTE
above. Perhaps incoming is bit more difficult? Maybe a useful start would be
something a bit like PEEK which can read given spoolid and in the case of
class M punch files, discard BSMTP headers when present and display the
remaining content?
I have written some runtime support for CMS which enables 3270 panels created
on MUSIC to be used in CMS applications. It's a bit tedious to have to create
the panels on a different system and move them across but in the absence of
XEDIT, it beats manually coding 3270 data streams on CMS for fullscreen user
interfaces. If you want to use this, let me know and I'll provide further
details. It's on my website but I try to avoid quoting urls in mails so that
I don't arouse the suspicions of over zealous spam filters...
Regards,
Peter Coghlan.
