David I'm sorry for the late response here. Although I responded swiftly after the original post of 14 Sept questioning how the Communications Server (CS) IP component could possibly communicate to the "outside world" without the aid of OSA features, I merely indicated that quite a lot concerning this thorny topic could be discovered actually by opening the relevant manual. If only ...
I referred to the long and glorious history of the predecessor product, "TCP/IP for MVS" - not forgetting *its* predecessor product "TCP/IP for VM" which of course continues a parallel and equally glorious existence. The period of this history incorporates some time when there was no such thing as an OSA feature and so there really must have been other ways that the IP product could communicate with the "outside world". I also recalled - not too difficult! - that many - actually I incorrectly assumed *all* - never assume anything! - of these other interface "technologies" were still documented - in the CS IP Configuration Reference manual - and indicated that's where the answer to the original question could easily be found.[1] You have now given us what you describe as a subset of the interfaces which have been available to this family of products over the last 20 years or so but you also suggested that some may have fallen by the wayside: > The stack still has the code to support most of these devices, but IBM (and the other vendors) probably don't support them officially any more. Thus it seemed that an interesting project, supported purely by a web browser, a wireless connection and a durable laptop battery while paying just a little attention to some not particularly riveting films - obviously, was to review the documented interfaces. Using the online bookshelves, the furthest I was - easily - able to go back was TCP/IP for MVS V2R2.1. This is actually not a bad starting point because this release lies in the period when I was teaching TCP/IP for MVS as an introductory half day in the week-long hands-on "TCP/IP" class. I had a section in my class notes which covered interfaces. Because of my background, I mostly investigated those interfaces with which I was able to work in my test/education systems, namely, those based on SNA and the 3745 Communication Controller and virtual (VM-based) channel to channel, and I taught them, it would seem, in the following sequence: - X25NPSI: SNA/X.25 using GATE - X25NPSI: SNA/X.25 using GATE "fast-connect" - SNALU62: SNA using LU type 6.2 - SNAIUCV: SNA using LU type 0[Story 2] - CTC: Channel-to-channel I note that one I could have taught - and had implemented for testing purposes - but probably reckoned to be just too obscure for the audience was SNA/X.25 using DATE,[Story 1] yet another flavour of "X25NPSI". Those for which I did not have the requisite hardware available and so, not having actually made the interface work, I didn't feel entitled to do more than simply refer the students to the manual, are the following: - LCS: 8232 or 3172 to Ethernet - LCS: 8232 or 3172 to Token-Ring - LCS: 3172 to FDDI - HIPPI: High Performance Parallel Interface - HCH: HYPERchannel A220 - ELANS: CETI to Ethernet - IUCV: "Inter-user Communication Vehicle" to adjacent address space - CLAW: 3172-3 and RS/6000 also support "offload" I guess I could have covered "IUCV". Maybe I didn't see much point! In order to remove any ambiguity, I have here added a prefix which is the code used in the DEVICE statement in order to indicate the "type" of interface. It was actually most regrettable that I did not have a "playpen" 3172 since that was the most popular device in order to gain access to the "outside world". I verified that all the interface "types" identified above were documented in the "TCP/IP for MVS" V2R2.1 manual. Today, z/OS V1R12, the following interface "types" are documented in the CS IP Configuration Reference manual: - ATM - CDLC - CLAW - CTC - HCH - LCS - MPCIPA/IPAQENET (QDIO) - MPCIPA/IPAQIDIO (IQDIO) - MPCOSA - MPCPTP - SNAIUCV - SNALU62 - VIRTUAL - X25NPSI Thus we can see that, actually, we have *lost* the ELANS (CETI), HIPPI and IUCV interface "types" and we have *gained* the ATM, CDLC, MPCIPA, MPCOSA, MPCPTP and VIRTUAL "types". I tracked the loss of "types" back to the change from "TCP/IP for MVS" V3R2 to the OS/390 Communications Server IP component. The details can be found in the following manual: OS/390 V2R5 eNetwork Communications Server IP Planning and Migration Guide, SC31-8512-00, Chapter 4, "Migrating from TCP/IP Version 3 Release 2", "Device Driver Support" and "subtopics". http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1AF9000/4.6 Full honesty compels me to mention that the "offload" flavour of the CLAW "type" was also abandoned. This manual also happens to describe the introduction of a couple of new "types" and there are two "types" which had been introduced earlier than the switch from "TCP/IP for MVS" V3R2 to the Communications Server IP component with OS/390 V2R5. Thus, in order to be complete, it now remains only to list which release of OS/390 or z/OS Communications Server - with dates - each of the "types" introduced since "TCP/IP for MVS" V2R2.1 appeared. - ATM - OS/390 V2R5 (1998) - CDLC - Maintenance to "TCP/IP for MVS" V3R1 (1996) - MPCIPA/IPAQENET (QDIO) - OS/390 V2R7 (early 1999) - MPCIPA/IPAQIDIO (IQDIO) - Maintenance to z/OS V1R2 (APAR OW49475) (2001) - MPCOSA - OS/390 V2R8 (late 1999) - MPCPTP - OS/390 V2R5 (1998) - VIRTUAL - Maintenance to "TCP/IP for MVS" V3R1 (1996) As I said in my original post in this thread, there is a *wealth* of information to be gleaned from the online manuals. It is interesting to note the usual IBM marketing folk twisting the arm of the developers for the purposes of claiming that, when a function is removed, an equivalent or preferably better function immediately replaces it. It is claimed that the IUTSAMEH flavour of MPCPTP ("SAMEHOST") replaces the function of the IUCV "type". Also, by offering "SAMEHOST" as a replacement for "IUCV" "protocol code" in the LINK statement for those "types" which depend on subsidiary address spaces, namely SNAIUCV, SNALU62 and X25NPSI, and knowing that the "SAMEHOST" capability otherwise supported as the IUTSAMEH flavour of MPCTPTP removes the need for IUCV, are we to assume that these "types" no longer rely on IUCV for communication between the main CS IP address space and the subsidiary address space? - confusion worse confounded! I recently reviewed the IUCV/VMCF/TNF topic in the IBMTCP-L list and it did *not* mention that there was still a dependency with these interface "types" - but that conclusion requires that one trusts the CS developers to be thorough in their description of such dependencies, a trust unfortunately somewhat forfeit in the review. - Before turning to your reminiscences, it's worth recalling that the original poster was interested in communicating with the "outside world" and so we should whittle the list of interface "types" down to those of a non-incestuous nature. With this principle in mind, all of the following - in principle - deserve no further comment: - CTC - channel-to-channel usually implies a connection within the "glass- house" - IUCV - address space to address space under the same operating system - MPCIPA/IPAQIDIO (IQDIO) - is restricted to a single "Central Electronic Complex" (CEC) - MPCPTP - channel-to-channel but also supported by devices such as the 2216 (now not offered) - VIRTUAL - useful only when there are also *real* interfaces available - Finally with all the necessary background in place I can review your comments on the various devices and which interface "types" support them. > The stack still has the code to support most of these devices, but IBM (and the other vendors) probably don't support them officially any more. I can now say with confidence that, apart from the "offload" capability of the CLAW "type", ELANS (CETI) and HIPPI, all previously available interface "types" are still documented as available and, one must assume, supported by z/OS CS IP development - assuming any associated "hardware" can still be considered "supported" by the responsible vendor. > 7170 (basically a parallel channel interface to a DEC Unibus card cage, with a DEC DELNI network card in it, controlled by an original IBM PC with (wait for it!) 64K of RAM!), Genned as a CTC. Very temperamental, but it got bits on the wire. Are we to understand that "Genned as a CTC." means that it is defined as a CTC interface "type" or that that is how the operating system is presented with the device? I did a bit of Googling and found that the 7170 is described as a Direct Access Control Unit (DACU). It also looks as if it might be some tricky device supported esoterically by "TCP/IP for VM" and may have nothing whatsoever to do with "TCP/IP for MVS". So I guess it was a bit of fun to mention it! > 8232 (a channel attached PC/AT that came with a Ungermann/Bass 10mbit Ethernet card that jammed easily on networks with lots of collisions) also genned as a CTC. I think this resolves the "genned as" question since an 8232, to give it its full name, is an IBM 8232 LAN Channel Station, the original device supporting the interface "type" LCS - and the associated "protocol" I expect - and documented as such. Also "as such", this is the device which the 3172 and, using channel type OSE, the OSA feature emulates. > 3172 (aka LAN Channel Station, or LCS) genned as 3088, could support up to 3 network adapters (TR, Ethernet, ATM), although you were sad if you had the ATM adapter and tried to add anything else to it). This is the most common "emulated" adapter, and was available internally on the MP3K, FlexES and now zPDT. Came in parallel and ESCON versions, I think. > ... (aka LAN Channel Station, or LCS) ... Not strictly true since your 8232 lays the original claim to "LAN Channel Station" - and you know how keen I am to support original claims! - as just explained. Strictly the 3172 glorifies under the name of "Interconnect Controller". > ... (TR, Ethernet, ATM) ... The 3172 also supported FDDI. <quote> This LINK statement is used to define the Fiber Distributed Data Interface (FDDI) link to the LCS (IBM 3172 Models 002 and 003) defined by the LCS DEVICE statement. </quote> > BusTech BTI 1, 2 and 3: very popular with universities, as they were about a quarter to half the price of a 8232 or 3172 and took up a LOT less space (4 RU vs a half-height cabinet for a 3172). V1 required a special driver, but later models emulated a 3088. Supported Ethernet, TR, and ATM in various forms, and you could get one unit to support up to 4 adapters (the vendor sold only 3, but there was plenty horsepower for 10 Mbit Ethernet. It would appear to be implied that this "BusTech" supports the LCS "type". > ATI Hyperchannel -- did 10 and 100mbit Ethernet direct from the channel interface. Expensive, usually used when you had a Cray to do computing and the Z system was just playing smart I/O device to the Cray. Is this supported as what the documents describe as the HCH "type", usually mentioning "HYPERchannel A220" as the "device"? If so it looks as if, when IBM thinks it is dealing with token-ring, your device sneakily substitutes Ethernet! > X25IPI -- IP over X.25. You needed a FEP for this thing, or the internal X.25 interface in a 4361. Evil. Pure Evil. This looks like a case of the reaction of primitive people on first encountering civilization! I think the first point might be that, with X25IPI,[2] we may be dealing with an exclusively "TCP/IP for VM" interface "type"[3] and not the "TCP/IP for MVS" interface which, for X.25, has the "type" name X25NPSI and it is X25NPSI which uses NCP - along with the X.25 NPSI extension product - in Communication Controllers - which you inappropriately describe as "FEP".[4] Thus I can see that maybe X25IPI relates to the integrated X.25 support in a 4361 but has nothing to do with Communication Controllers, certainly for "TCP/IP for MVS". It may also be that you have some experience with X25IPI and that it was not pleasant. Lack of familiarity with the oddities of X.25 may have had something to do with that experience. Note that the original Subject line - now inexplicably lost but to be reinstated - implies that the original poster was interested only in z/OS support. > SNA LU - IP over SNA. VTAM set up a LU-LU session, and the IP stack used it like a serial line. Weird, but it worked. Again, I sense a culture clash! Actually there are two flavours of SNA support, mapping to two interface "types", based on whether LU type 6.2 or LU type 0 is used. I was almost tempted to place the LU type 0 interface "type" in the "incestuous" category since it would be used - I think - only between "TCP/IP for MVS" or "TCP/IP for VM" implementations - but they could be geographically separated. The LU type 6.2 interface "type" was however supported by other platforms such as OS/2 and so has a wider applicability. Note that all these three interface "types", required an associated address space and this may have encouraged the use of dismissive descriptions such as "evil" and "weird". > Cisco CIP - channel attached 75xx Cisco router. Parallel and ESCON versions, genned as a 3088. Fast (for the day) and very flexible. Could drive dozens of interfaces, offload 3270 traffic, deal with up to SONET speeds, bridge Ethernet and TR and ATM networks. The channel interface was the real bottleneck. Too bad there never was a FICON version. And how is the wonderful Cisco CIP presented to CS IP? I believe I've had to deal with a weird - since the word is popular - implementation of an "outboard" TN3270 server which requires something in the CIP to appear as an SNA peripheral node with SSCP-dependent devices. > Cisco CPA - channel attached 72xx Cisco router. Similar to a CIP, but designed for the smaller 7200 series routers. Also had a parallel and ESCON version. Presumably the way the CPA is supported is very similar to identical to the way the CIP is supported. > Real CTC/CNCs -- if you had a 3088, you could use it to connect to other Z hosts and do IP over the channel. Fast, for the day, but not very useful unless you were VERY visionary and fought the SNA Wars well. The lockstep nature of the channel protocol was the big bottleneck. I'm not sure I understand whatever point may be being made here. In any case I exclude CTC and later probably "improved" according to your criteria "types" such as MPCPTP from the discussion because they don't pass the "outside world" test. > About that point was where the OSAs appeared. If the availability of the MPCOSA "type" is any guide - somewhat tenuous - the date may be late 1999. However, if the earliest data associated with the "Planning for the S/390 Open Systems Adapter (OSA-1, OSA-2) Feature" manual, GC23-3870, is used, the date is 1995. This restricts the list of interface "types" to those available with "TCP/IP for MVS" V2R2.1 which goes back to 1992 and is replaced by V3R1 only in 1996. Chris Mason [1] On review, I realised that the most popular of the older techniques used by "TCP/IP for MVS" to access the "outside world" had been the 3172. It may be that it had been assumed that, since one of the OSA feature channel types subsumed the capabilities of the 3172, there was some sort of replacement for *all* using the OSA feature. One can only speculate! [2] Before posting I reviewed my presentation notes on these topics upon which I expanded and noticed why the characters "X25IPI" were not totally unfamiliar. The DD-statement which identifies the parameters of the subsidiary started task procedure for the X25NPSI address space is called X25IPI - wouldn't you know? [3] Confirmed with the first Google "hit" for "X25IPI TCP/IP": http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp? topic=/com.ibm.zvm.v53.kill0/x25ipi.htm [4] If the Communication Controller (CC) is condemned to support only channel-attachment in any particular role, then there is some justification for the term "Front End Processor" (FEP). On the other hand, if there is an SNA path from the LPAR operating system to the CC - as is the case with interface "type" X25NPSI, there is no need for a direct channel connection and it may suit the network design to connect the CC to the LPAR indirectly through other CCs. This more flexible use is quite disgracefully denied by the ridiculous abbreviation FEP. Note that the abbreviation FEP may have had some validity in the era of the 270x,[5] necessarily "channel" on one "side" and "lines" on the other, but since then, in other words, since the period of the mid-60s to the mid-70s - really an awful long time ago now! - it must be considered thoroughly archaic designation for a CC. [5] Around 1970, the definition of a "teleprocessing" (TP) specialist was someone who could configure a 2701 without needing to check the "Sales Manual"! [Story 1] Before I knew very much at all about this "TCP/IP" thing, I used to teach a number of protocols, namely, SNA, X.25 and OSI, and the associated "MVS" products. There is a range of capabilities in the X.25 NPSI product which are described as "Logical Link Controls" (LLCs), some related to SNA end-to-end communication where an X.25 network is used to support logical SNA connections - similar to the way an IP network is used to support SNA connections with Enterprise Extender - and others where the SNA session ends in X.25 NPSI logic called the "LU simulator". It is possible to rank the techniques used for the latter category going from the "LU simulation" logic providing least control over X.25 "bits and pieces" to that providing most control. The technique offering most control still within the confines of the "virtual circuit" is GATE - which means "Generalized Access to X.25 Transport Extension" - which explanation provides no assistance with understanding whatsoever at all - some Frenchman who probably spent a lot of time on his yacht in the Mediterranean dreamed it up! (I won't bother adding to the likely confusion by explaining the "fast connect" variant of GATE.) If you are prepared to remove the restriction of working within the "virtual circuit" and to take on the whole "physical" circuit, you can extend your control to using the technique called DATE, "Dedicated Access to X.25 Transport Extension" since you are now in charge of RESTART packets - IMMSMC. I used to pretend to talk knowledgeably about all these matters in my X.25 hands-on class - but, although I had exercised the GATE technique with the aid of the GTM/CSFI product, I had never had access to an "off-the-shelf" product which implemented the DATE technique - until ... Being somewhat of a magpie -- and not only because I had a lingering attachment from the early '50s with - some geographical justification - to Newcastle United football club, I had acquired the manuals for "TCP/IP for VM" and "TCP/IP for MVS" PRPQ as it then was - IIRC. Idly looking through I happened to notice that one of the options for the X.25 interface support employed the DATE technique - Bingo - "TCP/IP for MVS" PRPQ was an "off- the -shelf" product. I was going to have to set this product up so that I could get some familiarity with DATE and talk about it with some authority when presenting the "LLC" topic in my X.25 class! Who knows - strictly "who knew" - this "TCP/IP" thing might have a smidgen of interest as well! Well, indeed, a new plaything with so many avenues to explore is a bit addictive! As I was setting up all the interfaces between my VM guest MVS systems, CTC, SNA LU type 0, SNA LU type 6.2 and all the X.25 NPSI flavours, just "ping"ing got a bit boring so I tried this TELNET thing - some new 3270 stuff to get my teeth into after all - I still had teeth in those days! - and this FTP thing - and this SMTP thing - not forgetting to get NetView involved with SNMP. The peculiarities of dealing with this set of products which leaned so heavily on dynamic data set allocation grated so much that an encounter I had with one of the developers particularly over the vagaries of SMTP led to a somewhat acrimonious exchange - nothing new there then! Finally, late one afternoon, when I had just got to a point where I felt I had implemented as much of the "TCP/IP for MVS" PRPQ as I felt was necessary for the time being and I could get on with something else, my colleague who ran the "TCP/IP" week-long hands-on class opened my office door - note this is Europe, technicians get respect and have offices, none of your cubicles thank you very much! - and asked if I knew anything about "TCP/IP for MVS" as some of the students, although no doubt thoroughly fascinated by "TCP/IP for OS2" which was the vehicle of the hands-on portion of the class, actually had to install "TCP/IP for MVS" and could I help? Well, the best I could do "then and there" was take them to an empty "terminal room" and go through my definitions using ISPF EDIT. For the next class a few weeks later I had been allocated half a day to teach and half a day to go through exercises. I worked up my presentation material which, based on the needs of my first set of students and rather easily putting myself in the position of having to deal with this weird - there's that word again! - product was actually very heavily biased towards explaining the installation steps. This experience may also have meant that my soul would be at risk if I dared to try to cover any topic for which I did not have direct - and traumatic - experience. Thus LCS/3172 - although extremely relevant - was never covered. Conclusion: the most obscure "corner" (X.25 NPSI DATE) of the "evil" X.25 support was what got me started with IP and its related protocols. I leave the reader to judge whether that was a "bad" thing or a "good" thing! [Story 2] I believe I've told this story before so if you've already heard about how I invented "Virtual IP Addresses" before I knew they were supposed to be called such, you needn't bother reading further. The key point is that this "invention" was possible because of the SNA interface "type", weird though it supposedly is! Although the interface "types" with which I mainly played about were the special, much derided SNA and X.25 ones, I concentrated on the connections between CTC interfaces since these could create a mesh of all 5 of the virtual MVS systems with which I normally juggled. There were in addition connections running through Communication Controllers but, NCP being a time- consuming product - despite NCP (and NPSI) generation being totally covered by TSO clists - but that's another story, I tended to concentrate on just my two 3745s. I had taken the trouble to set up RIP dynamic routing covering all of the systems but it irritated me that I needed always to manage to discover a working IP interface to ping when the IP nodes themselves were essentially in good health and any service they might happen to offer was available; you just had to find the right "door"![2-1] It was around now I appreciated that RIP running on any one IP node will always know about active IP interfaces on *adjacent* IP nodes but can't offer any information about active IP interfaces on the same IP node. Time for lateral thinking - literally! How about we set up a connection to an *adjacent* IP node which happens actually to be the same IP node? We can then use the IP address of this IP interface as the target of requests to servers on the node. In addition to the IP address being associated with an IP interface, we have created an IP address which, in effect, represents the IP node itself. The connection itself is implemented as an U-shaped SNA - LU type 0, in fact - session. In fact, there is not just one but two IP addresses associated with the two IP interfaces between which there is an SNA session - although the second IP address doesn't offer any additional benefits. Since this is an SNA session implemented entirely within the LPAR, there are no "exposed" parts which the "slings and arrows" can attack. Thus we have two, in fact, very reliable IP addresses associated with the IP node which RIP will "assume" are IP addresses belonging to adjacent nodes and will advertise as such. And it worked - this was 1994-5 - but along came the VIPA function and the technique passed its "sell-by" date! There was a rumour about VIPAs around April 1995 and I was in Raleigh at the time. I described my technique to the ITSO resident responsible for matters relating to "TCP/IP" and suggested my "trick" might be something similar to this rumour I had heard. Unfortunately he didn't seem to have the first clue what I was talking about, I think because the idea of an U-shaped SNA session was way, way outside his "comfort zone".[2-2] [2-1] In fact, if you happened to be using a name rather than a specific IP address and your client application had the expected structure that involved trying the connect() call with each of a list of IP addresses which a name server function could return when asked to resolve a name, as long as you were sufficiently patient, your client program should be able to locate a working IP interface. [2-2] The gentleman involved was not without some intellectual capability. I overheard him talking to one of his residents and he used the expression "warts and all", presumably because what needed to be described wasn't perfect. Being in an environment where all were English speakers but each had his or her own national culture, he was obliged to explain the expression. Probably his resident was Dutch! On Mon, 20 Sep 2010 23:36:06 -0500, David Boyes <dbo...@sinenomine.net> wrote: >> No real issue, just thought I would ask. I couldn't think of anything >> other than an OSA for TCP/IP communication. I had forgotten about the >> CIPS from CISCO. > >There are a fair number of devices that work with IBM TCPIP (both for VM and for MVS). Some other fun ones: > >7170 (basically a parallel channel interface to a DEC Unibus card cage, with a DEC DELNI network card in it, controlled by an original IBM PC with (wait for it!) 64K of RAM!), Genned as a CTC. Very temperamental, but it got bits on the wire. > >8232 (a channel attached PC/AT that came with a Ungermann/Bass 10mbit Ethernet card that jammed easily on networks with lots of collisions) also genned as a CTC > >3172 (aka LAN Channel Station, or LCS) genned as 3088, could support up to 3 network adapters (TR, Ethernet, ATM), although you were sad if you had the ATM adapter and tried to add anything else to it). This is the most common "emulated" adapter, and was available internally on the MP3K, FlexES and now zPDT. Came in parallel and ESCON versions, I think. > >BusTech BTI 1, 2 and 3: very popular with universities, as they were about a quarter to half the price of a 8232 or 3172 and took up a LOT less space (4 RU vs a half-height cabinet for a 3172). V1 required a special driver, but later models emulated a 3088. Supported Ethernet, TR, and ATM in various forms, and you could get one unit to support up to 4 adapters (the vendor sold only 3, but there was plenty horsepower for 10 Mbit Ethernet. > >ATI Hyperchannel -- did 10 and 100mbit Ethernet direct from the channel interface. Expensive, usually used when you had a Cray to do computing and the Z system was just playing smart I/O device to the Cray. > >X25IPI -- IP over X.25. You needed a FEP for this thing, or the internal X.25 interface in a 4361. Evil. Pure Evil. > >SNA LU - IP over SNA. VTAM set up a LU-LU session, and the IP stack used it like a serial line. Weird, but it worked. > >Cisco CIP - channel attached 75xx Cisco router. Parallel and ESCON versions, genned as a 3088. Fast (for the day) and very flexible. Could drive dozens of interfaces, offload 3270 traffic, deal with up to SONET speeds, bridge Ethernet and TR and ATM networks. The channel interface was the real bottleneck. Too bad there never was a FICON version. > >Cisco CPA - channel attached 72xx Cisco router. Similar to a CIP, but designed for the smaller 7200 series routers. Also had a parallel and ESCON version. > >Real CTC/CNCs -- if you had a 3088, you could use it to connect to other Z hosts and do IP over the channel. Fast, for the day, but not very useful unless you were VERY visionary and fought the SNA Wars well. The lockstep nature of the channel protocol was the big bottleneck. > > >About that point was where the OSAs appeared. The stack still has the code to support most of these devices, but IBM (and the other vendors) probably don't support them officially any more. ---------------------------------------------------------------------- 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
