z/OS's basis for TCP/IP

[scott]

Just was wondering where TCP/IP stack came from for use in z/OS? Did it
originate from the University of Berkley?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Chris Mason]

Scott - I assume

> ... TCP/IP stack came from for use in z/OS ...

> Did it originate from the University of Berkley?

You will get a more comprehensive answer by asking on the following list:

For IBMTCP-L subscribe / signoff / archive access instructions, send email to LIST...@VM.MARIST.EDU with the message: INFO IBMTCP-L

I believe that the "TCP/IP for VM" product which was ported to become the "TCP/IP for MVS" product which became incorporated into the Communications Server product as the IP component follows what is described as the "Berkeley Software Distribution (BSD" flavour of an implementation of the Internet Protocol and related protocols such as TCP and UDP and so on. Other than that vague association I would have to rely on others for greater precision - such as the denizens of the IBMTCP-L list!

As for as where the original "TCP/IP for VM" product was actually "written", I am led to understand that it was indeed a University but the University of Wisconsin.

http://en.wikipedia.org/wiki/Internet_protocol_suite

Is any of that what you wanted to know?>

Chris Mason

[Bob Shannon]

>I believe that the "TCP/IP for VM" product which was ported to become the "TCP/IP for MVS" >product which became incorporated into the Communications Server product as the IP component >follows what is described as the "Berkeley Software Distribution (BSD" flavour of an >implementation of the Internet Protocol and related protocols such as TCP and UDP and so on.

However, TCP/IP was re-written for z/OS 1.5. I don't know how much of the original port remains.

Bob Shannon
Rocket Software

[Chris Mason]

Bob

Would you care to supply some evidence for your contention? I find no trace of such an upheaval in the z/OS V1R5 Communications Server IP Migration and Exploitation manual:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B130/

On the other hand, while there are still components of the system which require the functions associated with Step 3, "Configure VMCF and TNF", of the configuration tasks. related to the dreaded Pascal API, you know you are still in the grip of the original ivory tower authors!

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B3B0/1.2.21.5

Chris Mason

[Bob Shannon]

Actually, it was OS/390 1.5, not z/OS 1.5. Too long ago.

Bob

[Anne & Lynn Wheeler]

sve...@AMERITECH.NET (scott) writes:
> Just was wondering where TCP/IP stack came from for use in z/OS? Did
> it originate from the University of Berkley?

I hadn't followed the recent.

The original mainframe tcp/ip stack product was implemented on vm370 in
(mainframe) vs/pascal ... purely IBM implementation. A side-effect, is
that it had none of the buffer length exploits that are common in
C-language implementations. It was ported to MVS by implementing
simulation of some of the vm370 features.

recent discussion in linkedin mainframe group about doing the rfc1044
for the implementation and getting possibly 500 times improvement in the
bytes moved per instruction executed.
http://www.garlic.com/~lynn/2011p.html#36 Has anyone successfully migrated off mainframes
misc. other posts mentioning having done rfc1044 support for the
mainframe implementation
http://www.garlic.com/~lynn/subnetwork.html#1044

this was approx. the same time that Berkeley released 4.3 Reno & Tahoe
implementations that show up as the TCP/IP stack on lots of other
platforms. Some trivia ... we were doing ha/cmp and using ip-address
take-over for some of the recovery procedures
http://www.garlic.com/~lynn/subtopic.html#hacmp

and find a "bug" in the 4.3 ARP cache code (translates ip-address to
LAN/MAC) that was being used on large number of clients ... which
creates problems for the ip-address take-over recovery strategy.

another trivia ... after we leave ... two of the people mentioned
in the old post about jan92 meeting in Ellison's conference room ...
also leave and show up at a small client/server startup responsible
for something called the "commerce server". We are brought in as
consultants because they want to do payment transactions on the
server; the small startup has also invented this technology called
"SSL" they wanted to use. As part of availability for what is called
the "payment gateway" ... sits on the internet and is gateway
between webservers and the payment networks ... some past posts
http://www.garlic.com/~lynn/subnetwork.html#payment

we have multiple connections in different parts of internet backbone and
use multiple A-record support. I try and convince the browser group that
they need to be supporting multiple A-record also ... as part of
availability for client/server to webservers. They say it is too
complicated. I provide them examples from 4.3 Reno clients ... they
still stay it is too complicated. It takes another year to get multiple
A-record support into the browser.

later the communication group hires a subcontractor to do a tcp/ip stack
implementation in VTAM. the initial implementation had tcp performing
significantly better than lu6.2. He was told that everybody knows that a
proper tcp/ip implementation would be slower than lu6.2 and they weren't
going to be paying for anything other than a "proper" implementation.

--
virtualization experience starting Jan1968, online at home since Mar1970

[Richards, Robert B.]

LOL!

OS/390 "TWO" dot FIVE (OS/390 2.5 was around 1996 IIRC)

[Norbert Friemel]

On Tue, 6 Dec 2011 08:30:48 -0500, Richards, Robert B. <Robert....@OPM.GOV> wrote:

>LOL!
>
>OS/390 "TWO" dot FIVE (OS/390 2.5 was around 1996 IIRC)
>
>Bob
>
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Bob Shannon
>Sent: Tuesday, December 06, 2011 8:01 AM
>To: IBM-...@bama.ua.edu
>Subject: Re: z/OS's basis for TCP/IP
>
>Actually, it was OS/390 1.5, not z/OS 1.5. Too long ago.
>
>Bob
>

"IBM eNetwork Communications Server for OS/390 V2R5", March 1998


Norbert Friemel

[Chris Mason]

Bob

> Actually, it was OS/390 1.5, not z/OS 1.5. Too long ago.

Not too long ago for the IBM manuals web sites!

Indeed there was an upheaval in OS/390 V1R5 ("VEE" "ONE" "AR" "FIVE") occasioned by the incorporation of OpenEdition function.

It may be that - on close reading of what can be gleaned from the relevant "shelf", "OS/390 V2R5.0 eNetwork Communications Server":

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/F1A0BK01

- evidence of the extent of the upheaval (possible "rewrite") can be determined.

A particular initial reference would be the "OS/390 V2R5 eNetwork Communications Server IP Planning and Migration Guide":

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1AF9000/

I wonder however if the idea there had been a full "rewrite" was some sort of false echo of the fact that the FTP server had famously been rewritten:

<quote>

6.0 Chapter 6. Migrating the FTP Server and Client

...

This chapter describes the new FTP server and client in CS for OS/390. The new server is written to take advantage of OpenEdition sockets. The new client has the same functions as the Pascal client. However, it runs under the OpenEdition shell and the TSO environment. In addition, it supports Hierarchical File System (HFS) files. The new server and client replace the legacy Pascal and C servers and the Pascal client.

</quote>

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1AF9000/6.0

Chris Mason

On Tue, 6 Dec 2011 13:00:33 +0000, Bob Shannon <BSha...@ROCKETSOFTWARE.COM> wrote:

>Actually, it was OS/390 1.5, not z/OS 1.5. Too long ago.
>
>Bob

[Farley, Peter x23353]

Chris,

Thanks for those interesting links. I had not realized that the z/OS Comm. Server implemented some form of VMCF and IUCV.

The small amount of RTFM I just did based on your links seems to indicate that the Comm. Server SMSG command is only supported to communicate with SMTP and LPD. Is there any chance that there is a z/OS equivalent of these z/VM commands for the general (non-authorized) user?

From userid1:

SMSG userid2 'message text'

And in userid2, waiting for a message from SMSG from any other user:

WAKEUP (SMSG

Or any equivalent inter-user communications commands of course. I'm not expecting on an *exact* equivalent of the z/VM facilities, just an equal capability for short message sending and reception invokable as commands by regular non-authorized TSO users.

TIA for any enlightenment you can provide.

Peter

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of Chris Mason
> Sent: Tuesday, December 06, 2011 7:42 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: z/OS's basis for TCP/IP
>

> Bob
>
> Would you care to supply some evidence for your contention? I find no
> trace of such an upheaval in the z/OS V1R5 Communications Server IP
> Migration and Exploitation manual:
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B130/
>
> On the other hand, while there are still components of the system which
> require the functions associated with Step 3, "Configure VMCF and TNF", of
> the configuration tasks. related to the dreaded Pascal API, you know you
> are still in the grip of the original ivory tower authors!
>
> http://publibz.boulder.ibm.com/cgi-
> bin/bookmgr_OS390/BOOKS/F1A1B3B0/1.2.21.5

--


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Tom Marchant]

On Tue, 6 Dec 2011 08:48:40 -0600, Chris Mason wrote:

>Indeed there was an upheaval in OS/390 V1R5 ("VEE" "ONE" "AR" "FIVE")

That's V2R5, as you noted below. The new Communications Server component was introduced in V2R4, but only for Unix applications. IIRC, the CS included VTAM and TCP/IP and they were pretty tightly integrated.

The announcement of 2.4 and preview of 2.5 is here:
http://www-01.ibm.com/common/ssi/ShowDoc.jsp?docURL=/common/ssi/rep_ca/6/877/ENUSZP97-0486/index.html&lang=en

<quote>
CS OS/390 adds a new, completely redesigned,TCP/IP stack, which exploits
native OS/390 services and multiprocessing capability, for significantly
improved performance, reliability, availability, serviceability, and scalability.
</quote>

This agrees with my memory of SHARE sessions from the era.

--
Tom Marchant

[Chris Mason]

Peter

I'm very sorry to be disappointing you!

> Is there any chance that there is a z/OS equivalent of these z/VM commands for the general (non-authorized) user?

We're on the "down slope", not the "up slope"! In other words, the direction in the IP component of z/OS Communications Server is to get rid of these entrails of the VM heritage. The most recent to go - although not strictly replaced one-for-one - is the old Pascal SMTP server to be "replaced" by the CSSMTP server.

The other major server written in Pascal surviving from the old "TCP/IP for VM" days - see my first response in this thread - is the LPD server. I believe there is a product which replaces this with a number of additional capabilities - someone can no doubt jump in with what that is - so, in effect, the LPD server has already been replaced.

Although not pretending to be comprehensive, this list from the configuration step I mentioned shows that what remains dependent on VMCF/TNF are a few scraps at the bottom of the barrel that nobody cares much about:

<quote>

1.2.21.5 Step 3: Configure VMCF and TNF

The Pascal socket interface uses the IUCV/VMCF services for a limited set of inter-address space communication flows. As a result, if you are using any applications (provided by IBM or others) that use the Pascal socket API, you must ensure that the Virtual Machine Communication Facility (VMCF) and Termination Notification Facility (TNF) subsystems are active before the applications are started. TCP/IP provides the following applications and commands that use the Pascal socket interface:

- SMTP and LPD servers

- TSO HOMETEST, LPQ, LPR, LPRM, LPRSET, TELNET, and TESTSITE commands

If you are using any of these applications or commands, you need to set up VMCF and TNF.

</quote>

That word "limited" is a bit of a hint that the author - in tune with most of his or her readers - rather wishes there were none!

Unfortunately, rather too strict an application of the rule "If it ain't broke, don't fix it!" much beloved by the "suits" in charge of manual authors, has meant that, the text - which has by now gathered much dust - surrounding the suggestion that the installation should be "verified" by use of the HOMETEST and TESTSITE utility commands has not been deprecated in some way. Thus novices still get the impression that the use of these commands is technically de rigeur as part of checking definitions when they should just have overlooked them. In any case, in an era when only VIPAs need names, they are well out of date!

That said, it was only when one presumed novice in a recent thread complained that his checking with HOMETEST was failing that I discovered - very late! - that the generically named TCPIP.DATA data set HOSTNAME statement applied to the data set for the main address spaces when the sockets API gethostname call was used while it applied to the data set for the program address space when the Pascal API GetIdentity call was used in order to extract the "host name" value.

My excuse for not appreciating this point for all the years I have been working with "TCP/IP for MVS" and is successor is that I have always used a common dynamically allocated data set. As a teacher of "hands-on" classes, I always used to have to rely on students probing unusual definition techniques - typically by accident - revealing the previously unknown!

Chris Mason

On Tue, 6 Dec 2011 09:58:58 -0500, Farley, Peter x23353 <Peter....@BROADRIDGE.COM> wrote:

>Chris,
>
>Thanks for those interesting links. I had not realized that the z/OS Comm. Server implemented some form of VMCF and IUCV.
>
>The small amount of RTFM I just did based on your links seems to indicate that the Comm. Server SMSG command is only supported to communicate with SMTP and LPD. Is there any chance that there is a z/OS equivalent of these z/VM commands for the general (non-authorized) user?
>
>From userid1:
>
>SMSG userid2 'message text'
>
>And in userid2, waiting for a message from SMSG from any other user:
>
>WAKEUP (SMSG
>
>Or any equivalent inter-user communications commands of course. I'm not expecting on an *exact* equivalent of the z/VM facilities, just an equal capability for short message sending and reception invokable as commands by regular non-authorized TSO users.
>
>TIA for any enlightenment you can provide.
>
>Peter

[Farley, Peter x23353]

Chris,

Well, I can't say I'm surprised by your answer, but thanks for your insights anyway.

I haven't searched around the web yet (especially the CBT site) for some equivalent facility, but perhaps it's time I did so. Now, where did I put those darned round tuits... :)

Peter

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of Chris Mason
> Sent: Tuesday, December 06, 2011 10:42 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: z/OS's basis for TCP/IP
>

--


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Steve Conway]

Peter,

Sounds like you want TSO SEND. Do TSO HELP SEND for syntax and usage.


Cheers,,,Steve

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_...@ao.uscourts.gov

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2011p.html#42 z/OS's basis for TCP/IP

this talks about bsd 4.3 tahoe (june 1988) and reno (early 1990)
distributions ... I've still got original source distribution
backed up someplace
http://en.wikipedia.org/wiki/Berkeley_Software_Distribution

All the BSD stuff was done in C language and tahoe and reno
distributions were picked up and used by large number of different
platforms. As previously mentioned, IBM mainframe was done in
vs/pascal.

attached from summer 1988 (R1L2 about the same time as 4.3 tahoe)
... part of announce includes reference to adding support to the product
that I had done for RFC1044.

The basic support had been doing approx. 44kbytes/sec. using nearly 3090
processor. For rfc1044, some tuning tests I did at Cray Research, got
mbyte/sec channel media sustained throughput using only modest amount of
4341 (nearly 500 times improvement in bytes transferred per instruction
executed). misc. past posts mentioning doing rfc1044
http://www.garlic.com/~lynn/subnetwork.html#1044


NUMBER 288-396
DATE 880726
CATEGORY LS00, LS60, AS20
TYPE Programming
TITLE IBM TCP/IP FOR VM (TM) RELEASE 1 MODIFICATION LEVEL 2 WITH ADDITIONAL
FUNCTION AND NEW NETWORK FILE SYSTEM FEATURE
ABSTRACT IBM announces Transmission Control Protocol/Internet Protocol
(TCP/IP) for VM (5798-FAL) Release 1 Modification Level 2.
Release 1.2 contains functional enhancements and a new optional
Network File System (NFS) (1) feature. VM systems with the NFS
feature installed may act as a file server for AIX (TM) 2.2, UNIX (2)
and other systems with the NFS 3.2 client function installed.
Additional functional enhancements in Release 1.2 include: support
for 9370 X.25 Communications Subsystem, X Window System (3) client
function, the ability to use an SNA network to link two TCP/IP
networks, and a remote execution daemon (server).
Charges
Graduated Monthly
Program Processor One-Time License
Number Group Charge Charge
5798-FAL 10 $ 3,000 $ 335
15 4,000
20 7,000
30 10,000
40 16,000
50 21,670
Planned Availability Date: September 30, 1988
(Refer to the External Ordering Information for shipment
dates.)
(TM) Trademarks of the International Business Machines Corporation.
(1) Trademark of Sun Microsystems, Inc.
(2) Registered trademark of American Telephone and Telegraph.
(3) Trademark of Massachusetts Institute of Technology.
PRODNO 5798-FAL IBM Transmission Control Protocol/Internet
Protocol for VM
IMKTG MARKETING INFORMATION
MARKETING CHANNELS
o NCMD
o SWMD
PRODUCT POSITIONING
There is a rapid increase in the number of workstations used
for engineering/scientific computing as well as increased use by many
other industries. The Network File System is popular as a file
server to support these workstations. The Network File System on
IBM TCP/IP for VM allows the IBM systems running VM to act as a file
server for the engineering/scientific workstations. The DASD and
associated VM programming support provide a high quality system for
use as a file server in this environment. Systems of other vendors
with the NFS 3.2 client protocols implemented may access files on the
VM system using TCP/IP and the NFS feature. The IBM AIX Network File
Systems provide client function that will access these files. The
IBM Personal Computer feature of TCP/IP for VM does not contain NFS
client function and cannot access NFS files on the VM system.
MARKETING STRATEGY
IBM TCP/IP for VM and the Network File System should be
marketed to customers with VM systems and engineering/scientific
workstations with NFS 3.2 installed.
MARKETING FOCUS
SALES COMPENSATION PLAN: Normal provisions apply.
MEASUREMENT VALUE (MV): MV is available on HONE for all programs by
keying the command POINTS 5798-FAL at the entry prompt arrow of the
selection screen. MV is also available on AAS under the mnemonic
QSLM.
HONE INFORMATION
Proposal material will not be available through HONE.
The configuration aids CFPROGS will be available through HONE
on September 30, 1988, and will be available to customers eligible to
use IBMLink. The fast path name is CFPROGS.
IADMIN ADMINISTRATIVE INFORMATION
ORDERING INFORMATION
The HONE configuration aid CFPROGS may be used to determine
ordering information. The HONE aid SYSLINK may be used to transmit
the ordering information from HONE to AAS.
PROCESSOR GROUP-TO-PROCESSOR GROUP UPGRADES The program in this
announcement is eligible for processor group upgrades (e.g., Group 20
to Group 40) when notification is received that the customer has
changed the processor (designated machine) on which the licensed
program is running. For special administrative information, refer to
ADMININFO Item Number DVG33.
PROGRAMMING RPQS
Requests for PRPQs will not be accepted.
SPONSORING EXECUTIVE
S. J. Palmisano
Group Director
Mid-Range Systems Management
OVERVIEW HIGHLIGHTS
o Network File System Feature
o 9370 integrated X.25 support (driver)
o X Window System client function
o Remote execution daemon
o SNA network link
o HYPERchannel (4) support (driver).
(4) Trademark of Network Systems Corporation.
DESCRIPTION
NETWORK FILE SYSTEM FEATURE
The Network File System (NFS) feature provides file server support
for the NFS 3.2 protocols developed by Sun Microsystems, Inc. This
support enables the VM system to act as a file server for vendor
systems with the NFS 3.2 client function installed. NFS has been
implemented on the IBM AIX systems as well as many other vendor's
systems. Optional encryption of file handles requires
IBM Information Protection System Cryptographic programs for VM/CMS
(5796-PPK) or a customer-supplied encryption procedure. The NFS
feature does not include the Network File System client function.
The Network File System feature uses the *BLOCKIO CP system
service, and can reference CMS-format minidisks on any DASD supported
by *BLOCKIO. Special formatting of the CMS minidisk by the RESERVE
command is not required.
The Network File System feature includes Remote Procedure
Call. The RPC function of the Network File (RPC) System makes remote
procedures appear as if they were local. Both the NFS and RPC
protocols adhere to the External Data Representation (XDR)
specification, which allows the protocols to be independent of
machine internal format.
The RPC is implemented as a library of procedures. The
customer who wishes to write applications using RPC will require
IBM C for System/370 (5713-AAH) and the IBM VS Pascal Library
(5668-717).
OTHER TCP / IP FOR VM FUNCTIONAL ENHANCEMENTS IN VERSION 1.2
9370 X.25 Communications Subsystem Support
A driver is provided to support connection of the IBM TCP/IP for VM
program offering to an X.25 network using the 9370 X.25
Communications Subsystem.
REMOTE EXECUTION DAEMON
A remote execution daemon (server) (REXECD) is provided to allow
remote execution of VM EXECs and CP/CMS commands. Systems with the
Remote Execution (REXEC) client function installed may initiate
execution of VM EXECs and CP/CMS commands from the remote system.
IBM AIX/RT (TM) and IBM TCP for the Personal System/2 (R) (PS/2 (R))
have the client REXEC function available.
(TM) Trademark of the International Business Machines Corporation.
(R) Registered trademarks of the International Business Machines
Corporation.
SNA NETWORK LINK
IBM TCP/IP for VM installed on a VM system with IBM ACF/VTAM for
VM/SP (5664-280) may interconnect the TCP/IP network via SNA to
another TCP/IP network attached to a remote VM system with IBM TCP/IP
for VM and IBM ACF/VTAM for VM/SP installed on the remote system.
The SNA LU-0 protocol is used to link the two systems.
CMS X WINDOW SYSTEM (VERSION X.11)
The CMS X Window System is an application program interface (API)
which allows a CMS program access to a bit-mapped, high-resolution
display connected to system running an X Window System (Version X.11)
server program. The IBM AIX/RT X Window System Version 2.1 offers
the required X Window System server function. The X Window System
API allows the development of code portable across operating systems
and displays. The CMS application using the X Window System client
function communicates with the X Window System server function on the
AIX system. The CMS applications using the X Window System function
will be written in C and require the IBM C for System/370 program
offering (5713-AAH) and the IBM VS Pascal Library (5668-717). TCP/IP
is used as the communication protocol between the VM system and the X
Window System server system.
HYPERCHANNEL SUPPORT (DRIVER)
A driver is provided to support connection of the IBM TCP/IP for VM
program to a NSC HYPERchannel network using a NSC IBM channel
adapter. Support conforms to specifications outlined in RFC1044 for
16-bit address configuration.
NOTE: Customer application programs that interface to IBM TCP/IP for
VM and written in IBM C for System/370 Program Offering (5713-AAH)
require the IBM VS Pascal Library (5668-717) for execution.
For additional information on TCP/IP for VM, refer to
Programming Announcement 287-165, dated April 21, 1987.

... snip ...

[Chris Mason]

Tom

> That's V2R5

Quite correct, OS/390 V2R5 ("VEE" "TWO" "AR" "FIVE")

-

> The new Communications Server component was introduced in V2R4,

I don't find this really quite so correct! This appears to refer to some "quick fix" called the "Outboard Communications Server" (OCS) which allowed a LAN- or channel-attached RS/6000 running AIX to act as some sort of "front-end processor" for an OS/390 system. It doesn't have much to do with the "Communications Server" I cover below.

> ... but only for Unix applications.

That is, for the benefit of OpenEdition running IP-based applications.

OS/390 OpenEdition Communications Server Guide

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXBE03/

Note that this is the only reference to "Communications Server" I find on an OS/390 V2R4 "shelf".

-

The evidence that V2R5 is the release where "TCP/IP for MVS" and "VTAM" got into bed together as "Communications Server" - and what the original post presumably had in mind - is contained in the following references:

From "OS/390 V2R5 eNetwork Communications Server IP Planning and Migration Guide":

<quote>

PREFACE About This Book

The purpose of this book is to provide an overview of eNetwork Communications Server for OS/390 Version 2 Release 5 (CS for OS/390), including a comprehensive survey of the differences between it and the following previous releases of IBM's TCP/IP product:

- TCP/IP Version 2 Release 2.1
- TCP/IP Version 3 Release 1
- TCP/IP Version 3 Release 2
- TCP/IP Version 3 for OpenEdition MVS Applications Feature, which was available with TCP/IP Version 3
- TCP/IP OpenEdition Feature

</quote>

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1AF9000/PREFACE

From "OS/390 V2R5 eNetwork Communications Server SNA Planning and Migration Guide":

<quote>

PREFACE About This Book

This book explains how to install IBM eNetwork Communications Server for OS/390 V2R5 (hereafter known as CS for OS/390 V2R5) and how to upgrade VTAM(*) V4R4, V4R3, V4R2, V4R1, or V3R4.2 to CS for OS/390 V2R5.

</quote>

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1AF6000/PREFACE

-

> IIRC, the CS included VTAM and TCP/IP and they were pretty tightly integrated.

Not really. The key area of integration is that creating the logic for new types of interface was handed to the VTAM developers, hence TRLEs, and the QDIO interface implementation could be shared between the two "upper level protocols".[1]

Also of course, there was a certain interaction between the two teams required in order to provide Enterprise Extender. However, even here, VTAM takes on the appearance of a "same host" instance of the Communications Server IP component, the "seams" tend to "show"!

-

I'm reminded of a phrase from a song in a play I performed at school "The founts of quotation when meeting in fray!". It was a translation of Aristophanes, "The Frogs" of course!

-

[1] One of the rather limited cases of "tight integration":

7.2 Defining an OSA-Express device to z/OS Communications Server using QDIO

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b5b0/7.2

-

Chris Mason

On Tue, 6 Dec 2011 09:23:39 -0600, Tom Marchant <m42tom-...@YAHOO.COM> wrote:

>On Tue, 6 Dec 2011 08:48:40 -0600, Chris Mason wrote:
>
>>Indeed there was an upheaval in OS/390 V1R5 ("VEE" "ONE" "AR" "FIVE")
>
>That's V2R5, as you noted below. The new Communications Server component was introduced in V2R4, but only for Unix applications. IIRC, the CS included VTAM and TCP/IP and they were pretty tightly integrated.
>
>The announcement of 2.4 and preview of 2.5 is here:
>http://www-01.ibm.com/common/ssi/ShowDoc.jsp?docURL=/common/ssi/rep_ca/6/877/ENUSZP97-0486/index.html&lang=en
>
><quote>
>CS OS/390 adds a new, completely redesigned,TCP/IP stack, which exploits
>native OS/390 services and multiprocessing capability, for significantly
>improved performance, reliability, availability, serviceability, and scalability.
></quote>
>
>This agrees with my memory of SHARE sessions from the era.
>
>--
>Tom Marchant

[Farley, Peter x23353]

Well, I certainly thought of TSO SEND, but it is the "WAKEUP" part of the process (i.e., the receiving end) that I don't see a way to accomplish. How could a program running in a TSO user's address space wait for and then receive a message sent via TSO SEND?

And as an extension of such a capability, how would a batch TSO process (i.e., an IKJEFTxx batch step) receive and process such a message?

Peter

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of Steve Conway
> Sent: Tuesday, December 06, 2011 11:28 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: z/OS's basis for TCP/IP
>

> Peter,
>
> Sounds like you want TSO SEND. Do TSO HELP SEND for syntax and usage.
>
>
> Cheers,,,Steve

<Snipped>

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2011p.html#42 z/OS's basis for TCP/IP
http://www.garlic.com/~lynn/2011p.html#43 z/OS's basis for TCP/IP

this is post here on ibm-main last april
http://www.garli.com/~lynn/2011f.html#29 TCP/IP Available on MVS When?
http://www.garli.com/~lynn/2011f.html#30 TCP/IP Available on MVS When?
http://www.garli.com/~lynn/2011f.html#31 TCP/IP Available on MVS When?

quotes from ibmnew89 memo on vmshare
http://vm.marist.edu/~vmshare/browse?fn=IBMNEW89&ft=MEMO

about 5798-DRG from 1984 (i.e. some as wiscnet from wisconsin) ... and
was replaced by 5798-FAL april 1987.

[Steve Conway]

Hi, Peter.

My apologies. I should have read your requirements more carefully, and
actually checked what the SMSG(WAKEUP) was all about.

Cheers,,,Steve

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_...@ao.uscourts.gov

[Bjoern A. Zeeb]

On 6. Dec 2011, at 17:05 , Anne & Lynn Wheeler wrote:

> re:
> http://www.garlic.com/~lynn/2011p.html#42 z/OS's basis for TCP/IP
>
> this talks about bsd 4.3 tahoe (june 1988) and reno (early 1990)
> distributions ... I've still got original source distribution
> backed up someplace

Otherwise you can probably still get them from a friend or a more
complete (source) history from here (for a small fee):
http://www.mckusick.com/csrg/index.html

> http://en.wikipedia.org/wiki/Berkeley_Software_Distribution
>
> All the BSD stuff was done in C language and tahoe and reno
> distributions were picked up and used by large number of different
> platforms. As previously mentioned, IBM mainframe was done in
> vs/pascal.

--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.

[Anne & Lynn Wheeler]

bzeeb...@LISTS.ZABBADOZ.NET (Bjoern A. Zeeb) writes:
> Otherwise you can probably still get them from a friend or a more
> complete (source) history from here (for a small fee):
> http://www.mckusick.com/csrg/index.html

re:
http://www.garlic.com/~lynn/2011p.html#42 z/OS's basis for TCP/IP

http://www.garlic.com/~lynn/2011p.html#43 z/OS's basis for TCP/IP
http://www.garlic.com/~lynn/2011p.html#45 z/OS's basis for TCP/IP

i saw him last month at conference ... we were both wearing the same
tshirt.

--
virtualization experience starting Jan1968, online at home since Mar1970

[Anne & Lynn Wheeler]

ly...@GARLIC.COM (Anne & Lynn Wheeler) writes:
> IADMIN ADMINISTRATIVE INFORMATION
> ORDERING INFORMATION
> The HONE configuration aid CFPROGS may be used to determine
> ordering information. The HONE aid SYSLINK may be used to transmit
> the ordering information from HONE to AAS.
> PROCESSOR GROUP-TO-PROCESSOR GROUP UPGRADES The program in this
> announcement is eligible for processor group upgrades (e.g., Group 20
> to Group 40) when notification is received that the customer has
> changed the processor (designated machine) on which the licensed
> program is running. For special administrative information, refer to
> ADMININFO Item Number DVG33.
> PROGRAMMING RPQS
> Requests for PRPQs will not be accepted.
> SPONSORING EXECUTIVE
> S. J. Palmisano
> Group Director
> Mid-Range Systems Management

re:
http://www.garlic.com/~lynn/2011p.html#43 z/OS's basis for TCP/IP

in the mid-70s the US HONE datacenters were consolidated at 1501
(although the bldg now has another occupant). Recent references are to
Facebook hdqtrs "new" building next door at 1601. However, this is
reference to Facebook moving from 1601 to "1 Hacker Way"
http://www.zdnet.com/blog/facebook/facebooks-new-headquarters-is-located-at-1-hacker-way/5831

this is Facebook moving into the old Sun campus. I had spent a lot of
time in 1501 ... although I wasn't in anyway part of the HONE
infrastructure ... but HONE was one of my hobbies. misc. past posts
mentioning HONE
http://www.garlic.com/~lynn/subtopic.html#hone

[Ed Finnell]

It was still pretty buggered up with PASCAL components scattered about, so
much so it violated Software Manufacturing's policies and was only
orderable as a separate product.


In a message dated 12/6/2011 7:46:59 A.M. Central Standard Time,

Robert....@OPM.GOV writes:

OS/390 "TWO" dot FIVE (OS/390 2.5 was around 1996 IIRC)

[Roger Bolan]

Chris,

I think you're referring to the Infoprint Server LPD server.

See the latest bookshelf for details:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/aopbk380?FS=TRUE

--Roger

On Tue, Dec 6, 2011 at 8:41 AM, Chris Mason <chris...@belgacom.net> wrote:

>
> The other major server written in Pascal surviving from the old "TCP/IP
> for VM" days - see my first response in this thread - is the LPD server. I
> believe there is a product which replaces this with a number of additional
> capabilities - someone can no doubt jump in with what that is - so, in
> effect, the LPD server has already been replaced.
>
>

[Chris Mason]

Ed

> It was still pretty buggered up with PASCAL components scattered about, ...

I believe the position today is the list I included in a post to Peter Farley, which I will post again for your convenience:

<quote>

- SMTP and LPD servers

- TSO HOMETEST, LPQ, LPR, LPRM, LPRSET, TELNET, and TESTSITE commands

</quote>

Note that the HOMETEST and TESTSITE utilities are way past their sell-by date in terms of usefulness and, in some circumstances HOMETEST can be downright dangerous in terms of retention of sanity![1]

The point about this list is that you may very well not need to bother with any of these residual components and your system can be Pascal-free.

This will have two benefits:

1. No need for configuration Step 3, "Configure VMCF and TNF"[2][3] so no more worrying about VMCF and TNF.

2. No need to ensure that the HOSTNAME statement specifies the same value in the generically named TCPIP.DATA data set associated with the Communication Server IP main address space (gethostname call) and the generically named TCPIP.DATA data set associated with any address space running a Pascal program (GetIdentity call).[1]

and one consideration:

- If you allow the value of the HOSTNAME parameter to default to the "parameter" set in step 3, beware that the default will become the IEASYSxx member SYSNAME value.

So each user of the IP component of z/OS Communications Server can hang out the bunting, order up the champagne and invite all his colleagues to a party when the great day comes that the shadow of Pascal is lifted from his or her system!

-

[1] http://www.aime.ua.edu/cgi-bin/wa?A2=ind1107&L=ibm-main&D=0&P=1121604

[2] http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B3B0/1.2.21.5

I know it falls under "Required steps before starting TCP/IP"

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B3B0/1.2.21

but who ever claimed that the manual authors always got their efforts 100% correct!

[3] VMCF = Virtual Machine Communication Facility, TNF = Termination Notification Facility

-

Chris Mason

On Tue, 6 Dec 2011 14:48:40 -0500, Ed Finnell <Efinn...@AOL.COM> wrote:

>It was still pretty buggered up with PASCAL components scattered about, so
>much so it violated Software Manufacturing's policies and was only
>orderable as a separate product.

[Shmuel Metz , Seymour J.]

In
<58FC7F986FCB804286E2...@nwt-s-mbx2.rocketsoftware.com>,
on 12/06/2011

at 01:00 PM, Bob Shannon <BSha...@ROCKETSOFTWARE.COM> said:

>Actually, it was OS/390 1.5, not z/OS 1.5. Too long ago.

There was no OS/390 1.5. OS/390 V2R5 sounds about right, although the
old version would still run.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

[Lindy Mayfield]

Interesting, if I am correct, they took long time to implement a resolver. If so, how were hostnames resolved?

[Chris Mason]

Lindy

> ... they took long time to implement a resolver.

There has always been a "resolver" function in "TCP/IP for VM", "TCP/IP for MVS" and the IP component of z/OS Communications Server (CS) (CS IP). What you may have in mind is the introduction of the "resolver" *address space* in z/OS V1R2 CS IP.

Since it is the responsibility of the manuals to explain such developments - maybe also the responsibility of folk playing the role of system programmers to discover such explanations! - here is what the z/OS V1R2 Communications Server IP Migration manual says about the introduction of the "resolver" *address space*:

<quote>

4.2 Resolver Enhancements

...

Prior to z/OS V1R2, the resolver function was implemented as part of the various socket APIs (Application Programming Interfaces) available on the z/OS platform. As a result, multiple versions of the resolver function were available, one for each type of socket API supporting resolver calls. All of these resolver libraries were quite similar in their support of
resolver functions but had slight differences from an administrative and configuration perspective. For example, the resolver search logic to locate its configuration file (TCPIP.DATA file) varied depending on whether the application was using the TCP/IP provided Socket APIs or the C/C++ Socket API provided by the LE (Language Environment) component of z/OS.

In z/OS V1R2, the various resolver libraries supported by the TCP/IP and LE APIs are now consolidated into a single resolver component. This allows consistent name resolution processing across all applications using the TCP/IP and LE socket APIs. The new consolidated resolver is automatically enabled on z/OS V1R2 and requires a new system address space that is automatically started during UNIX System Services initialization. The consolidated resolver offers several enhancements over previous releases:

...

</quote>

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b110/4.2

> If so, how were hostnames resolved?

Well, it's not so and so the question becomes immaterial!

Chris Mason

On Wed, 7 Dec 2011 06:30:12 +0000, Lindy Mayfield <Lindy.M...@SAS.COM> wrote:

>Interesting, if I am correct, they took long time to implement a resolver. If so, how were hostnames resolved?

[Lindy Mayfield]

Yes, "playing" and I get things wrong. Sorry.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Chris Mason
Sent: Wednesday, December 07, 2011 10:35 AM
To: IBM-...@bama.ua.edu
Subject: Re: z/OS's basis for TCP/IP

Since it is the responsibility of the manuals to explain such developments - maybe also the responsibility of folk playing the role of system programmers to discover such explanations!

[Anne & Lynn Wheeler]

Lindy.M...@SAS.COM (Lindy Mayfield) writes:
> Interesting, if I am correct, they took long time to implement a
> resolver. If so, how were hostnames resolved?

re:
http://www.garlic.com/~lynn/2011p.html#42 z/OS's basis for TCP/IP
http://www.garlic.com/~lynn/2011p.html#43 z/OS's basis for TCP/IP
http://www.garlic.com/~lynn/2011p.html#45 z/OS's basis for TCP/IP
http://www.garlic.com/~lynn/2011p.html#46 z/OS's basis for TCP/IP
http://www.garlic.com/~lynn/2011p.html#47 z/OS's basis for TCP/IP

trivia ... person that invented DNS had a decade prior did stint working
at the cambridge science center (while at MIT) ... related to cms
multi-level source update process (this was after gml had been invented
at science center and before cp67 morphed into vm370).

old posts with reference to somebody being semi-facetious
http://www.garlic.com/~lynn/aepay11.htm#43 Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
http://www.garlic.com/~lynn/aepay11.htm#45 Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)

wiki reference:
http://en.wikipedia.org/wiki/Paul_Mockapetris

another trivia from above wiki entry, jon postel used to let me do part
of std1 ... referenced in this recent linkedin post
http://www.garlic.com/~lynn/2011o.html#17 Ancient Internet History

--
virtualization experience starting Jan1968, online at home since Mar1970

[Ed Finnell]

Point it to a DNS that worked. We ran ours on an RS/6000 for many moons.


In a message dated 12/7/2011 12:34:12 A.M. Central Standard Time,

Lindy.M...@SAS.COM writes:

If so, how were hostnames resolved?