¿ªÔÆÌåÓý


Re: Help with SMSG and RSCS message: NOT AUTHORIZED

 

¿ªÔÆÌåÓý

Hi ´³¨¹°ù²µ±ð²Ô!

Fantastic! I've always been impressed by the talent that is out there. I've got to thank you for all the work you put into the tk4- project. It looks like I will also try your POC. I wonder if it works with JES3 :-) Worked in a JES3 shop for 20 years and for some 2-5 years we had a NJE link with a system in NYC that ran JES2, that was interesting.

Best Regards,

Bill Doughty, N2OCM

On 12/10/2019 3:22 AM, Juergen wrote:

Hi Bill

I am one of those people Peter mentioned ;-)

During the past weeks I created a proof of concept implementation of funetnje targeting at providing an "NJE helper" on the Hercules host that makes an MVS 3.8 system running on that host participate in an NJE network, without needing to make any modifications to JES2. It currently works quite well (RECFM F/FB, LRECL 80 only, by now) on Linux and MacOS hosts (others not yet, simply because I didn't adapt the source). In Peter's inofficial new EARN/Bitnet NJE network my online TK4- system participates as node CZHETH3C using this NJE helper POC. All who are interested can download the POC from? (do so at your own risk, this is a proof of concept, not a production software).
?
Cheers
´³¨¹°ù²µ±ð²Ô
I think several different people are all independently tweaking funetnje
to update it so there is probably a lot of duplicated effort going on :-(

As for MVS, I just hoped that I could at least use RSCS as a RJE station. But that is for future investigation. I know th4- will do RJE as I was able to get the rje80 program to connect and send a job and receive its' printout. I just hope I could get RSCS to do the same.


Re: Networking first needs (was Re: Listserv, Relay, Xyzzy and TCP/IP)

 

Late to this thread, but... I hope I can contribute.? I'm ok at REXX (and EXEC when needed), and would probably be able to code some things in Pascal, and have a strong interest in being able to expand our capabilities with the RSCS + TCPNJE we have (so far).? I may even try to hack in a "default" route to RSCS in assembler, if I get feeling brave enough. (Hints welcome! GETROUTE is in DMTAXS, that's as far as I've gotten.)
Cheers,
Chris Craft.


Re: Networking first needs (was Re: Listserv, Relay, Xyzzy and TCP/IP)

 

Hi Chris,


Late to this thread, but... I hope I can contribute.? I'm ok at REXX (and
EXEC when needed), and would probably be able to code some things in Pascal,
and have a strong interest in being able to expand our capabilities with
the RSCS + TCPNJE we have (so far).? I may even try to hack in a "default"
route to RSCS in assembler, if I get feeling brave enough. (Hints welcome!
GETROUTE is in DMTAXS, that's as far as I've gotten.)
A default route is straightforward enough to add. I'm just not that keen on
doing it on VM/370 RSCS because it makes it very easy to end up with files
and messages stuck going around in loops indefinately. There is provision
in NJE file headers for detecting transit through excessive numbers of nodes
but I haven't implemented this yet in my NJE code. Also, it doesn't look
like message / command (NMR) headers have any similar provision so I don't
know what would stop those going in circles.

Regarding coding, the REXX (and EXEC) we have access to suffers from a lack
of EXECIO functionality making it difficult to read and write files. I'm
very rusty on Pascal so I don't know what would be possible there. If it's
like FORTRAN, I suspect FILEDEFs will be needed to access CMS files unless
file access is done by calling assembler routines maybe?

Regards,
Peter Coghlan.


VM/370 Machine to Machine Communications

 

Is there any facility in VM/CMS R6 (i.e. the six pack)?

I am not looking for TCP/IP (LOL) - but any example would be useful.? I want to call from C - so an assembler stub would be lovely :-)

Is there a message send (and listen facility?) (Was that later?) Or better, a way to share a memory block between two VMs - what did folks do back in the day!?

A bit of shared memory would give me a socket and from that everything is possible (even in user land)

Thanks

Adrian


Re: VM/370 Machine to Machine Communications

 


Is there any facility in VM/CMS R6 (i.e. the six pack)?
If you are talking virtual machine to virtual machine, there is VMCF.


I am not looking for TCP/IP (LOL) - but any example would be useful.? I
want to call from C - so an assembler stub would be lovely :-)

Is there a message send (and listen facility?) (Was that later?) Or better,
a way to share a memory block between two VMs - what did folks do back in
the day!?
It's a little before my time but I suspect they used VMCF (DIAG 68). You
can find details in GC20-1807-7 IBM Virtual Machine Facility/370: System
Programmer's Guide amongst other places.

Regards,
Peter Coghlan.


Re: VM/370 Machine to Machine Communications

 

¿ªÔÆÌåÓý

Adrian,

?

Back in the day folks used VMCF which is documented in the System Programmers Guide (GC20-1807). That¡¯s what the original TCPIP implementation for VM used. If you want it to work in a CMS VM that¡¯s your best choice.

You can also use virtual Channel To Channel adaptors s, SMSG (which you can capture via VMCF) writeable shared segments (not sure of they are in R6 but I think so, but not often used as it needs a sysgen)

?

Dave

?

?

?

From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 30 December 2019 10:44
To: [email protected]
Subject: [h390-vm] VM/370 Machine to Machine Communications

?

Is there any facility in VM/CMS R6 (i.e. the six pack)?

I am not looking for TCP/IP (LOL) - but any example would be useful.? I want to call from C - so an assembler stub would be lovely :-)

Is there a message send (and listen facility?) (Was that later?) Or better, a way to share a memory block between two VMs - what did folks do back in the day!?

A bit of shared memory would give me a socket and from that everything is possible (even in user land)

Thanks

Adrian


Re: VM/370 Machine to Machine Communications

 

I recall putting hooks into HASP under MVT to capture and react to commands sent via SMSG. As I recall, VM fires an external interrupt at the receiving VM...


On Mon, Dec 30, 2019 at 8:20 AM, Dave Wade
<dave.g4ugm@...> wrote:

Adrian,

?

Back in the day folks used VMCF which is documented in the System Programmers Guide (GC20-1807). That¡¯s what the original TCPIP implementation for VM used. If you want it to work in a CMS VM that¡¯s your best choice.

You can also use virtual Channel To Channel adaptors s, SMSG (which you can capture via VMCF) writeable shared segments (not sure of they are in R6 but I think so, but not often used as it needs a sysgen)

?

Dave

?

?

?

From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 30 December 2019 10:44
To: [email protected]
Subject: [h390-vm] VM/370 Machine to Machine Communications

?

Is there any facility in VM/CMS R6 (i.e. the six pack)?

I am not looking for TCP/IP (LOL) - but any example would be useful.? I want to call from C - so an assembler stub would be lovely :-)

Is there a message send (and listen facility?) (Was that later?) Or better, a way to share a memory block between two VMs - what did folks do back in the day!?

A bit of shared memory would give me a socket and from that everything is possible (even in user land)

Thanks

Adrian


Re: VM/370 Machine to Machine Communications

 

Thanks all - that gives me a start :-)


Re: VM/370 Machine to Machine Communications

 

I have read the section. Old school but completely sensible, although the security bit made me smile, as did the publication date of April 1!

Anyway ... has anyone got some assembly examples that I could use to hack something that I could call from C?

Also ... and I appreciate I need to read more ... for the sink machine what do I actually have to do to allow a module to be waiting on a interrupt/message?

Thanks in advance

Adrian


Re: VM/370 Machine to Machine Communications

 

Hi Adrian,


Anyway ... has anyone got some assembly examples that I could use to hack
something that I could call from C?
Sorry, I can't seem to find any. The closest I came was some code that
uses VMCF to receive SMSGs:




Also ... and I appreciate I need to read more ... for the sink machine what
do I actually have to do to allow a module to be waiting on a
interrupt/message?
You have to issue a DIAG 68 with the VMCPAUTH function code and the address
and length of a buffer to receive messages into. Actually, this is the
side that is implemented in the link I quoted above. There isn't any
code provided to send VMCF messages unfortunately, however, it may give
some ideas on how to set up a VMCF control block and call DIAG 68 and how
to deal with the resulting external interrupts when VMCF messages arrive.

Maybe someone else can find a better example?

One thing to note is that your module should not exit back to CMS until
you have turned off ("unauthorised") VMCF. In later versions of VM/CMS,
it is possible to use NUCXLOAD to get around this issue by permanently
loading code and buffers to handle VMCF external interrupts, however,
NUCXLOAD is not available in VM/370. It might be possible to use RESLIB
instead though.

Regards,
Peter Coghlan.


Re: VM/370 Machine to Machine Communications

 

Thanks Peter ... Appreciated!


Re: VM/370 Machine to Machine Communications

 

Hi Adrian,

I found some old files that can be used to demonstrate one way to use VMCF.? These were actually used in production back in the day.? A virtual machine server (VMSINK) would host CMS files used by various applications that were invoked by users running CMS.? Using VMCF, the application programs could request that the server open a file, read or write record(s), and close the file, among other functions.? In this way, multiple userids could access the same file, and with proper coding in the application program even support multiple users writing to the same file.? VMSINK served to serialize the file i/o.? These programs would probably work in VM/370 Sixpack with no changes except that possibly the FORM=E specification should be removed from the FSCB macros.? But the point isn't so much to try to run them as to use them as a guide to setting up VMCF as a sender and a receiver.

I uploaded the programs to the files area, called 'vmsink.zip'.? It contains the server which sets up VMCF, and the requestor which uses VMCF to request services from the server.?? The programs are not large and perhaps they can help you see how to use VMCF, as one example.? There is a README file within to guide you through the components and a bit more detail.

Regards,
Bob


Re: VM/370 Machine to Machine Communications

 

Bob :-) !


Re: VM/370 Machine to Machine Communications

 

Hello,

if you want to use VMCF from a C program, you may find my NICOF package useful: it is a communication facility based on VMCF and written mostly in C. The relevant modules are INTRAPI H for the interface and INTRAPI ASSEMBLE for the implementation for accessing low-level CP/CMS items from C programs.

You can find the installation package (tapes etc.) in the files section of this group (folder "nicof", current version is 0.7) and on github (). The package also has an extensive documentation PDF, which is a lot of reading, but it should have enough information for installing the package in a VM/370 system and writing VMCF programs using the mentioned API, see section 7.1 in NICOF-0.7.0.pdf.

But maybe NICOF already has what you want, as it provides a TCP/IP stack for VM/370-R6 and utilities for transferring files from/to the (Windows or Linux) host environment, including a simple FTP server for CMS, all written in C with INTRAPI.

Greetings, Hans


Re: VM/370 Machine to Machine Communications

 

Thank you for your reply and yes I will certainly build on top of what you have already done! I don't quite know fully what I want ... but a socket between 2 CMS VMs is probably everything I need, and it sounds like you cracked it! I will read the PDF. I am quite interested in how you implemented it. For example did you investigate running PPP over your socket to do all things tcp/ip.?

Thank you for using github to make your source code readily accessible.

Also my congratulations on your fullscreen work!

If I make any changes would you prefer pull requests or are you happy for me to fork?

Cheers

Adrian


Re: VM/370 Machine to Machine Communications

 

Hello Adrian,

forking the whole project is OK, this gives you all liberties. I'm happy if someone continues the work and adds features! So go on...

My focus with NICOF was communicating with the external world from a VM, so no direct "end-program" VM-to-VM sockets or the like, only in the sense of the proxy-VM between a client-VM and the external Java-program providing the main part of the communication.?

And no, i did not think of porting more complex things like PPP to provide a complete stack, as i had the feeling this could bring a 16M machine to the limits. But i did admitedly not even try, so maybe it's easyly possible.

Greetings, Hans


IND$FILE Binary of Module

 

Hello

I get "Trans99 - LRECL > 255 unsupported: file transfer canceled" when trying to receive a module file from the host.

Is there anything I can do or is this a known restriction??

In the end I used a tape - so no issue, just interested :-)

A


GCCLIB

 

So I (with Dave's help) put the 0.6 source here -

However the "without DOSTRAN" tape does not seem to have any source - just 4 files

GCCLIB?? MACLIB?? E1? F??? 80??? 436???? 44? 2012-05-08 17:30? CMS193
GCCLIB?? TEXT???? E1? F??? 80?? 1623??? 163? 2012-05-08 17:34? CMS193
GCCLIB?? TXTLIB?? E1? F??? 80?? 1218??? 122? 2012-05-08 17:34? CMS193
GCCLIB_S TXTLIB?? E1? F??? 80?? 1640??? 164? 2012-05-08 17:34? CMS193

Which I think are intermediate build files ... (am I right?)

Does anyone know if/where the source exists and/or what was the needed change. There seems to be lots and lots of assembler files that reference DOSTRAn :-(

Thoughts anyone?!

Adrian


Re: GCCLIB

 

Hello,

try the file "GCCLIB-without-DOSTRANS-for-VM370-SixPack-1.2.zip" in the files section of this group.

The sources are in the tape "GCCLIB-without-DOSTRANS-modified-src.aws" in the ZIP. (there may be a missing source there, i believe to remember something about it... however, the missing file may be reconstructed by patching the original from the github-repo in analogy to the others...)

The other tapes contain the new binary GCC libraries and the MECAFF binaries using this new libraries. I don't know if you will need these, it depends on what versions were installed in your sixpack version (1.3?).

Good luck, Hans


Re: IND$FILE Binary of Module

 

well, i think i should know. But it's been a long time ago that i wrote this code and i simply don't remember why there is this restriction. Sorry...