Re: z/OS's basis for TCP/IP
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 +, Lindy Mayfield lindy.mayfi...@sas.com wrote: Interesting, if I am correct, they took long time to implement a resolver. If so, how were hostnames resolved? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
Yes, playing and I get things wrong. Sorry. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Wednesday, December 07, 2011 10:35 AM To: IBM-MAIN@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! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
lindy.mayfi...@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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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.mayfi...@sas.com writes: If so, how were hostnames resolved? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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 lists...@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 On Mon, 5 Dec 2011 22:49:13 -0500, scott svet...@ameritech.net wrote: 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
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 Chris Mason On Tue, 6 Dec 2011 12:07:22 +, Bob Shannon bshan...@rocketsoftware.com wrote: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
Actually, it was OS/390 1.5, not z/OS 1.5. Too long ago. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, December 06, 2011 7:42 AM To: IBM-MAIN@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 Chris Mason On Tue, 6 Dec 2011 12:07:22 +, Bob Shannon bshan...@rocketsoftware.com wrote: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
svet...@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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
LOL! OS/390 TWO dot FIVE (OS/390 2.5 was around 1996 IIRC) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bob Shannon Sent: Tuesday, December 06, 2011 8:01 AM To: IBM-MAIN@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 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, December 06, 2011 7:42 AM To: IBM-MAIN@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 Chris Mason On Tue, 6 Dec 2011 12:07:22 +, Bob Shannon bshan...@rocketsoftware.com wrote: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
On Tue, 6 Dec 2011 08:30:48 -0500, Richards, Robert B. robert.richa...@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-MAIN@bama.ua.edu] On Behalf Of Bob Shannon Sent: Tuesday, December 06, 2011 8:01 AM To: IBM-MAIN@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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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 +, Bob Shannon bshan...@rocketsoftware.com wrote: Actually, it was OS/390 1.5, not z/OS 1.5. Too long ago. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, December 06, 2011 7:42 AM To: IBM-MAIN@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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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.htmllang=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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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.far...@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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, December 06, 2011 10:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS's basis for TCP/IP 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.far...@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. -- This message and any attachments are intended only for the use of the addressee
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 Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@bama.ua.edu Date: 12/06/2011 11:25 AM Subject:Re: z/OS's basis for TCP/IP Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 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-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, December 06, 2011 10:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS's basis for TCP/IP 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.far...@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
Re: z/OS's basis for TCP/IP
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 154,000 207,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
Re: z/OS's basis for TCP/IP
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-ibmm...@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.htmllang=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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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-MAIN@bama.ua.edu] On Behalf Of Steve Conway Sent: Tuesday, December 06, 2011 11:28 AM To: IBM-MAIN@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 From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@bama.ua.edu Date: 12/06/2011 11:25 AM Subject:Re: z/OS's basis for TCP/IP Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 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-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, December 06, 2011 10:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS's basis for TCP/IP 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
Re: z/OS's basis for TCP/IP
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=IBMNEW89ft=MEMO about 5798-DRG from 1984 (i.e. some as wiscnet from wisconsin) ... and was replaced by 5798-FAL april 1987. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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_con...@ao.uscourts.gov From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@bama.ua.edu Date: 12/06/2011 12:22 PM Subject:Re: z/OS's basis for TCP/IP Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 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-MAIN@bama.ua.edu] On Behalf Of Steve Conway Sent: Tuesday, December 06, 2011 11:28 AM To: IBM-MAIN@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 From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@bama.ua.edu Date: 12/06/2011 11:25 AM Subject:Re: z/OS's basis for TCP/IP Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 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-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, December 06, 2011 10:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS's basis for TCP/IP 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
Re: z/OS's basis for TCP/IP
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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
bzeeb-li...@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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
l...@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 -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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.richa...@opm.gov writes: OS/390 TWO dot FIVE (OS/390 2.5 was around 1996 IIRC) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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 chrisma...@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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
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=ind1107L=ibm-mainD=0P=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 efinnel...@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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
In 58fc7f986fcb804286e23b59decf420f334a1...@nwt-s-mbx2.rocketsoftware.com, on 12/06/2011 at 01:00 PM, Bob Shannon bshan...@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) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS's basis for TCP/IP
Interesting, if I am correct, they took long time to implement a resolver. If so, how were hostnames resolved? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bob Shannon Sent: Tuesday, December 06, 2011 2:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS's basis for TCP/IP 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
