This page last updated: 2003-06-11 jmm MVS38J TCP/IP - Overview The MVS38j TCP/IP project is an attempt to provide the public domain MVS 3.8J operating system with TCP/IP support; it is very much a Work In Progress.   There is nothing suitable for end users to run at this time.   As currently implemented, MVS38j TCP/IP is composed of two main components: the MVS38j TCP/IP subsystem (STCP370) and a MVS38j port of PC-Xinu (MVS-Xinu).   PC-Xinu is derived from Xinu as detailed in several books by Dr. Douglas E. Comer . Surf the mvs38j-ip Links section for further info. To run MVS38j TCP/IP, you'll need an MVS38j system.  Fortunately a Turnkey MVS system containing MVS38j is available from Volker Bandke or the CBT crew , or you can build your own using one of the sets of instructions from the H390-MVS links . Volker's usually great about rolling new MVS38j facilities into the Turnkey system, so once the project is worth installing he'll probably make it available there. Currently, the MVS38j TCP/IP code is a roll-your-own affair. The MVS38j TCP/IP project is tailored to operate under the Hercules emulator which provides software emulation (under Linux, Windows, and other platforms) of the IBM S/360, S/370, S/390, and z/Architecture hardware platforms. For the initial release, there will only be C language bindings.   No date has been designated for a functional MVS38j TCP/IP initial release; this is an entirely volunteer effort, so it won't be ready until it's ready.  Development snapshots are periodically posted as there seem to be a fair number of people interested in following the project's progress. The project is an outgrowth of the XMIT370 and RECV370 work I did, so it's a little hard to say exactly when work on it was started; for the sake of argument call it sometime between June and August 2002. MVS38J TCP/IP - Current Status 2003-06-11 Posted mvs38j-ip-0003.tar.gz as well as a summary description of current processing  as an ICMP ping packet enters the MVS-Xinu TCP/IP stack. Posted mvs38j-ip-console.txt which is the MVS console listing that goes with the summary description. Most of my recent activities have been centered around the Hercules CTCI adapter, in particular the code needed to read from it, which now seems to be working pretty well. Jason Winter wrote both an MVS38j FTP server, and modifications to Hercules which provide a Hercules-only TCPIP instruction.  The Hercules developers are currently experimenting with DLL support as a means to provide Jason's efforts to the Hercules community.  You can get Jason's code from Greg Price's site ... M38jftp.zip. Jason asks for a modest donation, which I hope many of us will send him. There's actually more to his code than just FTP.  Well worth looking into, although it does currently require the user have the ability to rebuild Hercules.  My expectation is that a Hercules build with the necessary ingredients should appear publicly in the not too distant future. 2003-02-14 New longname to shortname map for LKED sysprint, process management initial implementation ready to test, dasdseq and Hercules convert_tt() bugs fixed. The most recent public release of the TCP/IP MVS subsystem source is at CBT tape in file 571 , last updated approximately late August, 2002.  From time to time, I post more recent source at ftp://ensose.com/mvs38j with a corresponding announcement in the Yahoo H390-MVS group and the mvs38j-ip group. Some thought is being given to a CVS repository somewhere, but thus far nothing has been done in that regard.  It's not a high priority. 2003-01-04 There is a new Yahoo MVS38j TCP/IP group dedicated to the discussion of project issues.  If you are interested in following (or contributing to) the MVS38j TCP/IP effort, please feel free to join the mvs38j-ip group.  I'm a little better about posting there than updating this page, so act accordingly. Installation instructions for the MVS38j TCP/IP subsystem are provided in the $INSTALL member of CBT file 571.  The instructions will install XMIT370, RECV370, and STCP370 (the MVS38j TCP/IP subsystem) along with various other support modules. In addition to the subsystem, you'll need the MVS-Xinu code which is more frequently posted since that is the main current activity. Interested parties can build the MVS subsystem load modules from CBT file 571 using the MVS38j IFOX00 assembler, place the STC JCL in SYS1.PROCLIB, initialize the subsystem, bring up the TCP/IP service address space, and interact with (shut down) the service AS. Not much more than that happens with the subsystem at this time, although there are some fairly nice debugging facilities with which to fool around, and the infrastructure support code isn't too shabby.  Although IFOX00 currently builds all the assembler source code, I'm not sure exactly how long that will continue.   If the developers decide to switch to a more recent assembler, object decks and/or load modules for the TCP/IP code will be provided in the CBT file.   Currently, MVS38j TCP/IP (the subsystem and MVS-Xinu) requires the following facilities to build the source code: IFOX00 S/370 assembler (free with MVS38j), Dignus Systems/C (or any other compiler which will build C code that runs on MVS38j), perl, my dasdseq command (available from ensose.com, or in current Hercules CVS), Malcolm Beattie's hercsub script, the Hercules emulator (or a real S/370 system), and a running MVS38j system (available from Volker Bandke or otherwise). It is probably best to ignore some of the specifics mentioned in the NOTETCP member of file 571, that's what I was thinking about back in August 2002.  Recent circumstances (see Current Activities, below) have obsoleted some of those plans. If you promise not to hurt yourself, it's not too horrid for a component breakdown. Best regards, Jim Morrison MVS38j TCP/IP - MVS Memory Overview Current as of 2003-06-11 jmm SQA MVS Other PLPA MVS TCP/IP subsystem support code (skeleton only; development version stub code resides in CSA) TCP/IP SVC (no initial implementation planned; development version stub code resides in CSA) Other CSA MVS, including SSCVT & SSCT control blocks TCP/IP Control Blocks, including SSCVT extensions (SGD) and MVS-Xinu control block (XGD) TCP/IP Queue Headers (currently allocated but not used; reserved for API) TCP/IP Buffers (not currently allocated or used) Other Private Area TCP/IP Client Address Space(s) Client Application TCP/IP API TCP/IP Control Blocks TCP/IP Buffers TCP/IP Subsystem Address Space TCP/IP Main Task, Task Manager, infrastructure support TCP/IP Operator Interface Subtask TCP/IP Control Blocks TCP/IP Buffers MVS-Xinu Address Space Kernel Support Processes, TCP/IP stack CTCI (3088) Device Drivers Buffers TCP/IP Server Address Space(s) Server Application TCP/IP API TCP/IP Control Blocks TCP/IP Buffers Nucleus MVS S/370 Low Storage (PSWs, etc.) There is a reasonably strong possibility the MVS-Xinu code will be incorporated into the TCP/IP Subsystem AS.  The above diagram reflects the current layout, which makes the debugging environment a little friendlier.  Sadly, MVS38j TSO TEST has no tolerance for debugging APF authorized code so everything is being done in batch. However, things aren't quite as bad as they sound, as Hercules offers some nice debugging facilities itself. MVS38j TCP/IP - Current Activities 2003-06-11 jmm I'm about to start writing the CTCI device driver write process code.  Jim Pierson, Hercules developer, proved instrumental in helping me understand the read side of the CTCI adapter. Thanks, Jim! I've been playing with various checksum algorithms, including the S/390 and z/Arch CKSM instruction (enabled in S/370 mode with a minor Hercules mod).  For some reason the algorithm given in z/Arch POPs doesn't work for me.  The broken code is in arch/s370/mvs/ibmcksum.c if anyone is so inclined.  No idea why I find checksum algorithms interesting.  Seems like some kind of character flaw. <g>  I can hardly restrain myself from writing a version in pure S/370 assembler and flinging STCKs around.  BTW, I think I mistakenly removed an "& 0xffff" from comer_cksum.c; I recently noticed it was returning 0xffff in the high half of the return value but I'm too lazy to rebuild the snapshot right now.  In general, the checksum code is still up in the air. I've got a fair amount of Xinu code to read since we're now passing through code paths I've not yet examined (hence the hand waving in my recent Ping post).  There are notable differences between the PC-Xinu code and the code published in Dr. Comer's books. The ethernet interfaces are probably not correctly initialized at this stage of the game, and there are likely ugly repercussions.  Routing may be about to undergo a fairly significant pruning because MVS-Xinu is currently configured for only one network interface and it's point-to-point at that.  But there's more reading to be done before that happens.  For all I know, everything's just fine the way it is. There's an MVS IOS issue with, I guess, the MIH (Missing Interrupt Handler).  After an unsatisfied CTCI read has been outstanding for awhile, IOS issues some messages complaining but I've not looked into them. From time to time I seem to lock up the TSO 3270s; haven't looked into it but I usually run CVS Hercules where there's a rumored 3270 bug.  OTOH, MVS-Xinu sometimes runs key0, so I could be causing it. MVS38j TCP/IP - Inactive Tasks Last updated: 2003-06-11 jmm This list is not all-inclusive, but is intended to give potential contributors some idea of the main tasks which aren't currently being addressed above and beyond Current Activities. Subsystem function code Definitely required for an initial release. Best deferred until the API is specified, hopefully not too much longer.  BSD, EZASOKET, or something else?  Opinions? TCP/IP SVC Not strictly necessary for an initial release.   Having an SVC will remove the requirement that all TCP/IP applications run APF authorized.  The initial TCP/IP API implementation will require APF authorization. Dual Address Space (DAS) MVS38j support Not strictly necessary, long range goal.   Fairly involved, fairly high MVS sysprog skill requirements. I've done a fair amount of initial research on this, and will be happy to pass along my notes to interested parties.  With the provision of this facility (probably an MVS usermod), more than one address space in the MVS machine can use DAS without clobbering other DAS applications that aren't running disabled. I've not looked into what changes are necessary to MVS paging services, but it would be nice if paged out pages in the secondary AS were resolved.  Provision of this facility would likely also be of benefit to Greg Price's IMON offering. MVS38j Binder-like facility Not strictly necessary, but would make the developers' lives easier. Not as great a need for this exists now that I've written the LKED sysprint annotation perl script, but it still would be nice to have someday. MVS38j TCP/IP - Miscellaneous MVS38j TCP/IP - Contributors Jeffrey Barnard, Barnard Software, Inc. who offer TCP/IP Tools for VSE. David Bond Laddie Hanus Jim Keohane Jim Pierson Greg Price Mike Rayborn David Rivers Somitcw A Great Big Thank You to everyone who has already contributed to the effort!   Some of you might try denying your contribution, but if you're listed above you've done something I think was helpful for the MVS38j TCP/IP project. Please let me know if I'm inadvertently omitted anyone.  Also, if you'd like me to designate a corporate affiliation I'll be happy to do so (nothing wrong with a little free advertising).  Spam-hungry contributors can have their email addresses listed if they so choose. Jim Morrison