Re: IBM 3174 C 6.4 Microcode Disks?
On 03/05/2019 02:18 PM, Kevin Monceaux via cctalk wrote: Our RS/6000 running DirectTalk/6000 had one VTAM LU for each voice channel so that each call had its own dedicated 3270 session. Under the "3270 Operations" display it would show the list of LUs, and which, if any, scripts were running on them. Interesting. Was that some sort of requirement from the mainframe side that each voice channel had a VTAM LU definition? Or was it simply to ensure that there was a large enough pool to not have any contention when the RS/6000 needed to make connections 3270 to the mainframe for each voice channel at the same time? -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
Grant, On Fri, Feb 22, 2019 at 04:02:33PM -0700, Grant Taylor via cctalk wrote: > Why do there need to be 10 VTAM/SNA nodes defined for the RS/6000? > Wouldn't it be one node unto itself, much like a 3174, with the 10 > VTAM/SNA nodes for the terminals behind it? Our RS/6000 running DirectTalk/6000 had one VTAM LU for each voice channel so that each call had its own dedicated 3270 session. Under the "3270 Operations" display it would show the list of LUs, and which, if any, scripts were running on them. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
Re: IBM 3174 C 6.4 Microcode Disks?
> On Feb 23, 2019, at 3:01 AM, Grant Taylor via cctalk > wrote: > > On 2/22/19 6:15 PM, Paul Koning via cctalk wrote: >> SNAP as a way of encoding bridged Ethernet II frames applies only to >> non-Ethernet LANs, all of which have larger MTU. > > Nope. I'm quite sure that NetBIOS used SNAP on Ethernet. > > I'm betting that 3174's Ethernet interfaces also used DLC / LLC2 via SNAP. > > IPX could run over SNAP on Ethernet if you wanted to. Yes, but that's not what I was trying to say, apparently not very clearly. There is a translation of Ethernet 2 frames into SNAP (by using an OUI of 00-00-00 or 00-00-F8 followed by the Ethentype). Those particular SNAP values are meant to be used only on LANs different from Ethernet, and bridges connecting those to Ethernet would look for those SNAP values and convert to the corresponding Ethernet 2 format. >> SNAP covers more than encoding bridged Ethernet II. It was intended as a >> way to carry protocols in 802 format for which you couldn't get a SSAP/DSAP >> code point (such as private protocols). DEC did this in various places, >> it's perfectly straightforward. > > *nod* > >> Perhaps some implementations make it hard to support both simultaneously, >> but there is no technical reason to make such a mistake. > > I feel like putting TCP/IP in SNAP on Ethernet is a mistake in that most OSs > will not know how to work with TCP in a SNAP frame as they will be expecting > Ethernet II frames. > > I don't know that there's a technical reason per say. I do think that there > is a market reason. A specific case of the general point above: on Ethernet you'd use 08-00 and 08-06; on non-Ethernet you'd apply RFC 1042 which gives the SNAP equivalents using the 00-00-00 prefix. >> The pretense that broadcast is different from multicast is just a confusion. >> The description says that it is used for traffic that every station wants >> to get. If you take that literally, no protocol should use broadcast, >> because there isn't any protocol that every station on every LAN wants to >> see. For example, ARP should have used multicast for the same reason DECnet >> does: it is traffic that is interesting to stations which speak that >> protocol, and only to those stations. > > Flip things on their head. I think it's that the sender wants every > receiving station to see. Yes, but no sender and no protocol has a valid expectation that this is the right thing. >> I think that's right. For 802.5, that is. > > ACK > >> In FDDI the frames are "stripped" by the sending station, which allows >> things like network monitors in promiscuous mode to work just like on >> Ethernet > > Intriguing. > >> The claim of collapse under load -- meaning throughput goes down beyond a >> certain load level -- is valid for ALOHA and similar networks, but not on >> Ethernet because it uses carrier sense and collision detect. Under overload >> it runs at close to full utilization. > > Okay. So you weren't saying that Token Ring had problems as much as you were > saying that Ethernet can work at close to capacity. > > I remember seeing references to Ethernet would start to have problems with > increasing backouts as the number of stations wanting to transmit at the same > time would grow. > > Though that may be that the average throughput of a given station may go down > while the network segment itself is closer to saturation. That's necessarily true for any sharing system. If you're not sharing you can get up to 100%, give or take how well the scheduling works. Two equal clients each get 50%, and so on. The merit of a sharing system is in how well it approaches 100% total throughput, and how well it delivers the desired split of service among the competing clients. Ethernet and 802.5 and FDDI all do it differently, and all do it pretty well. IBM once put out a marketing document full of FUD about Ethernet, and DEC, Intel, and 3Com (I think) put out a joint rebuttal going point by point (I participated in that effort). I have it in stored away somewhere; should look for it next time I'm in the right spot. paul
Re: IBM 3174 C 6.4 Microcode Disks?
Al, that was actually a quote from a message I wrote - I am the one with the 3274 floppies. Let me know what you are looking for. I am not at all familiar with what makes a "set", though I suppose I could just send the latest version I can find with each of the different sorts (SYST - which I took to be System, FEAT which I could to be Feature, and LANGUAGE that match your model. I found this in the IBM announcement letter: "One Feature Diskette and two System Diskettes are shipped with each 3274. For Models 31A, 31C, 31D, or 51C that are upgraded to Configuration Support D, a Language Diskette is also shipped. " If your 3274 does not have configuration support D, these might not work? Or maybe it was just a matter of needing to install the right Configuration support for the attached devices? I dunno (shrugs shoulders). Looking at the manuals on bitsavers, none of them mention this higher level of configuration support. I did find mention of it in an IBM announcement letter online, at https://www.argecy.com/3274 And it says this: "Configuration Support D (#9124): (Models 31A, 31C, 31D, 51C) Provides support for all 3270 functions included in Configuration Support C plus support for:" And "Configuration Support: The Configuration support required for the 3274 must be determined before ordering special features or attaching certain terminals. Refer to the 3274 Control Storage Requirements Tables under "Special Feature" Extended Function Store (EFS) for a detailed listing of the functions supports by each option. Field Installation: Yes. (Configuration Support D #9124 is field installation only for Models 31A, 31C, and 31D.) Customer Setup: Yes. Limitations: Certain functions require host software support in order to be utilized. Refer to host programming support descriptions to determine the levels of software required." So, unless yours is a 31A, 31C, 31D or 51C maybe these won't work? Let me know. JRJ On 2/20/2019 12:42 PM, Al Kossow via cctalk wrote: > > > On 2/19/19 7:39 PM, Jim Stefanik via cctalk wrote: > >> Well, it turns out my floppies are for *3274* rather than 3174. But, >> that said, if anyone needs any of them, let me know: just shipping cost. > > I can use them. I ended up with one w/o media > > >
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/22/19 6:15 PM, Paul Koning via cctalk wrote: SNAP as a way of encoding bridged Ethernet II frames applies only to non-Ethernet LANs, all of which have larger MTU. Nope. I'm quite sure that NetBIOS used SNAP on Ethernet. I'm betting that 3174's Ethernet interfaces also used DLC / LLC2 via SNAP. IPX could run over SNAP on Ethernet if you wanted to. SNAP covers more than encoding bridged Ethernet II. It was intended as a way to carry protocols in 802 format for which you couldn't get a SSAP/DSAP code point (such as private protocols). DEC did this in various places, it's perfectly straightforward. *nod* Perhaps some implementations make it hard to support both simultaneously, but there is no technical reason to make such a mistake. I feel like putting TCP/IP in SNAP on Ethernet is a mistake in that most OSs will not know how to work with TCP in a SNAP frame as they will be expecting Ethernet II frames. I don't know that there's a technical reason per say. I do think that there is a market reason. The pretense that broadcast is different from multicast is just a confusion. The description says that it is used for traffic that every station wants to get. If you take that literally, no protocol should use broadcast, because there isn't any protocol that every station on every LAN wants to see. For example, ARP should have used multicast for the same reason DECnet does: it is traffic that is interesting to stations which speak that protocol, and only to those stations. Flip things on their head. I think it's that the sender wants every receiving station to see. I think that's right. For 802.5, that is. ACK In FDDI the frames are "stripped" by the sending station, which allows things like network monitors in promiscuous mode to work just like on Ethernet Intriguing. The claim of collapse under load -- meaning throughput goes down beyond a certain load level -- is valid for ALOHA and similar networks, but not on Ethernet because it uses carrier sense and collision detect. Under overload it runs at close to full utilization. Okay. So you weren't saying that Token Ring had problems as much as you were saying that Ethernet can work at close to capacity. I remember seeing references to Ethernet would start to have problems with increasing backouts as the number of stations wanting to transmit at the same time would grow. Though that may be that the average throughput of a given station may go down while the network segment itself is closer to saturation. I'm trying to reconstruct what exactly the difference is, but I never knew 802.5 well and my FDDI brain cells are all from around 1986... Fair. -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
> On Feb 22, 2019, at 6:21 PM, Grant Taylor via cctalk > wrote: > > On 02/21/2019 07:43 AM, Paul Koning via cctalk wrote: > ... >> The mapping from Ethernet to 802.2 SNAP is trivial, but yes, you do need >> that mapping. > > I'm still pontificating how trivial the mapping between Ethernet II and 802.2 > SNAP is. I guess as long as you translate the Ethernet Frame Type to the > SNAP Protocol ID (and vice versa) and the Ethernet frame payload would fit in > the upper layer data area, things would be okay. There might be some > payloads that would fit in an Ethernet II frame that wouldn't fit in an 802.2 > SNAP frame on Ethernet. Fortunately Token Ring had bigger MTUs. > > You would probably only be going between Ethernet II and 802.2 SNAP if you > were going from Ethernet (802.3) to a different 802 network. Which means > that other things on that non-Ethernet 802 network would already understand > the same protocol(s) in 802.2 SNAP frames. SNAP as a way of encoding bridged Ethernet II frames applies only to non-Ethernet LANs, all of which have larger MTU. > The idea of using a mixture of Ethernet II and 802.2 SNAP on an Ethernet > seems odd. (en0 vs et0 interfaces in AIX come to mind.) SNAP covers more than encoding bridged Ethernet II. It was intended as a way to carry protocols in 802 format for which you couldn't get a SSAP/DSAP code point (such as private protocols). DEC did this in various places, it's perfectly straightforward. Perhaps some implementations make it hard to support both simultaneously, but there is no technical reason to make such a mistake. > >> Broadcast is just a special case of multicast. ... > Was one functional address used in lieu of the broadcast? Meaning that all > stations would receive it, look at it, and decide if they needed to act on it > or not. Much like traditional 10Base5 / 10Base2 / hubs? The pretense that broadcast is different from multicast is just a confusion. The description says that it is used for traffic that every station wants to get. If you take that literally, no protocol should use broadcast, because there isn't any protocol that every station on every LAN wants to see. For example, ARP should have used multicast for the same reason DECnet does: it is traffic that is interesting to stations which speak that protocol, and only to those stations. >> The ring passes through all stations of a LAN segment, just as the Ethernet >> bus (in the original version) passes through all stations of the segment. > > I think there's a minutia difference. I don't know if it's germane or not. > > To me, Ethernet (10Base5 / 10Base2 / Hubs) are functionally a broadcast that > every station hears without any action on other stations behalf. Conversely, > Token Ring each frame is actively passed station to station by each station. > It's also my understanding that the station will not pass the frame on to the > next station in the ring if the incoming frame was destined to the local > station. Thus, not all stations would necessarily hear every frame like they > would on Ethernet. I think that's right. For 802.5, that is. In FDDI the frames are "stripped" by the sending station, which allows things like network monitors in promiscuous mode to work just like on Ethernet > ... >> One example of this is the behavior under high load. At one time, token >> ring marketeers claimed it was better because it wouldn't "collapse" under >> load "like Ethernet". That is actually false, but in any event, > > Please elaborate on why it's false. The claim of collapse under load -- meaning throughput goes down beyond a certain load level -- is valid for ALOHA and similar networks, but not on Ethernet because it uses carrier sense and collision detect. Under overload it runs at close to full utilization. >> 802.5 worst case latency is incredibly large for large rings. > > Ya, I can see that. > >> 802.4 and FDDI with their "timed token protocol" have far lower worst case >> latency. > > I effectively don't know anything about 802.4 or FDDI. I'm trying to reconstruct what exactly the difference is, but I never knew 802.5 well and my FDDI brain cells are all from around 1986... paul
Re: IBM 3174 C 6.4 Microcode Disks?
On 02/21/2019 07:43 AM, Paul Koning via cctalk wrote: "raw 802.3" is a bug, caused by a programmer not understanding how the specs work. I thought people started using 802.3 /before/ the 802.2 specification was finished. Thus it's hard to follow what doesn't exit. Or at least that's what I've read multiple places. The mapping from Ethernet to 802.2 SNAP is trivial, but yes, you do need that mapping. I'm still pontificating how trivial the mapping between Ethernet II and 802.2 SNAP is. I guess as long as you translate the Ethernet Frame Type to the SNAP Protocol ID (and vice versa) and the Ethernet frame payload would fit in the upper layer data area, things would be okay. There might be some payloads that would fit in an Ethernet II frame that wouldn't fit in an 802.2 SNAP frame on Ethernet. Fortunately Token Ring had bigger MTUs. You would probably only be going between Ethernet II and 802.2 SNAP if you were going from Ethernet (802.3) to a different 802 network. Which means that other things on that non-Ethernet 802 network would already understand the same protocol(s) in 802.2 SNAP frames. The idea of using a mixture of Ethernet II and 802.2 SNAP on an Ethernet seems odd. (en0 vs et0 interfaces in AIX come to mind.) Broadcast is just a special case of multicast. My point was that 802.5, at least as IBM thinks of it, doesn't have proper multicast addresses (low bit set plus 47 bits to say what the address is). Instead, it has "functional addresses" which have a fixed beginning plus one of 32 bits that is set. So instead of 2^47 possible values, you have 32. Interesting. Thank you for explaining it. I don't know why this was done. Perhaps their chip designers thought hash or CAM address matching was too hard? ¯\_(ツ)_/¯ So if you have a protocol that uses multicast, like DECnet, you have to translate the real multicast address to the corresponding "functional" address in an Ethernet-802.5 bridge. And you have to make up a functional address, since the address space of 32 values is too small to have globally assigned multicast addresses as you do with other LANs. Was one functional address used in lieu of the broadcast? Meaning that all stations would receive it, look at it, and decide if they needed to act on it or not. Much like traditional 10Base5 / 10Base2 / hubs? The ring passes through all stations of a LAN segment, just as the Ethernet bus (in the original version) passes through all stations of the segment. I think there's a minutia difference. I don't know if it's germane or not. To me, Ethernet (10Base5 / 10Base2 / Hubs) are functionally a broadcast that every station hears without any action on other stations behalf. Conversely, Token Ring each frame is actively passed station to station by each station. It's also my understanding that the station will not pass the frame on to the next station in the ring if the incoming frame was destined to the local station. Thus, not all stations would necessarily hear every frame like they would on Ethernet. The point of multicast is that it recognized by multiple stations, not just one. But multicast matters to bridges because they have to forward it differently than individual addresses: individual is forwarded according to the address database entry if there is one, while multicast is not learned and always flooded along the spanning tree. ACK One example of this is the behavior under high load. At one time, token ring marketeers claimed it was better because it wouldn't "collapse" under load "like Ethernet". That is actually false, but in any event, Please elaborate on why it's false. I've heard of stations locking up and breaking the ring. But I suspect that you're talking about something else. 802.5 worst case latency is incredibly large for large rings. Ya, I can see that. 802.4 and FDDI with their "timed token protocol" have far lower worst case latency. I effectively don't know anything about 802.4 or FDDI. -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
On 02/21/2019 04:02 AM, Dave Wade wrote: I think we have a layer disconnect here. There is a PHYSICAL connection, but logically the SNA traffic just passes through the box. You define the MAC addresses of the end points in the 3174 but it knows nothing of the traffic passing through. As far as the end points are concerned its just a router like the one in my wardrobe that links to the VDSL that’s passing my traffic TCPIP traffic through Except that my router has to do NAT. These are all in the same SNA Domain and have unique SNA addresses. When doing SNA the terminal on the remote 3174 connects the VTAM... Okay. I'll have to ponder this. That’s just like IP routing. If we are doing SNA then each terminal has an SNA address that’s defined on the host. Its kind of like IP routing. My workstation knows that to route IP traffic to a specified non-local IP address it has to send it to my router. Same with SNA. The SNA connection is between the terminal and the mainframe. The 3174 simply routes traffic Okay. I'm starting to see a pattern as I re-read your email, pontificate, and reply. Yes, precisely. SNA is a layered protocol just like TCPIP. SNA connections Sit on top of other protocols. ACK Admittedly I had not thought about SNA being a layered protocol, much less what that means. But it does make perfect sense. My limited understanding has come from very few discussions about SNA over the years (prior to this and related threads) with people who treated it like a black box. Theoretically VTAM has application layers. In practice it’s a mess... ~chuckle~ Yes, the VTAM documentation is a good place to start (well perhaps not). ;-) But basically VTAM (used to, I haven't looked for a while) have huge tables that list every device on the network. I'm starting to get the impression that the tables are even larger than I might have originally suspected. So if you want to use 10 SNA 3270 terminals concurrently on an RS6000 There must be a VTAM/SNA node defined for the RS6000, and 10 VTAM/SNA nodes for the terminals. Why do there need to be 10 VTAM/SNA nodes defined for the RS/6000? Wouldn't it be one node unto itself, much like a 3174, with the 10 VTAM/SNA nodes for the terminals behind it? This lead to PC type gate products like Microsoft SNA server where you had TN3270 sessions to SNA server then connected via SDLC/Token Ring/X.25 to SNA on the host. So would Microsoft's SNA server (or the likes) have it's own VTAM node definition (terminology?) and a VTAM node definition for each (virtual) terminal that that was behind it? Where each virtual terminal was quite literally a logical representation of a state machine for the terminal and the TN3270 traffic would be the communications between the virtual terminal and the TN3270 terminal emulator running on the down stream IP client(s). Would VTAM still see the (virtual) terminals instantiated by SNA server, even when downstream clients were disconnected? Thus ultimately would timeout and logout / disconnect clients from ""idle terminals. Am I in the correct ball park? If you wanted 20 concurrent session, you defined 20 nodes in VTAM and SNA server. SNA Server would assign in bound TN3270 sessions SNA addresses from its pool and associate them with the terminal... Sort of like old school modem pools, you got the first one that's available (assuming one was available), and it would have it's hardwired / defined node configuration in VTAM. Thus you could get different terminal IDs depending on which virtual terminal you got out of the pool. Now I have remembered something nasty. There are SNA management sessions, so if he is feeling nasty, the VTAM operator can disable any terminal on any 3174, or any 3174 . ... so yes there may be SNA sessions between 3174s for management purposes. Would s/he be disabling something on the 3174 itself? Or the logical VTAM entity (LU?) in the mainframe, thus disabling anything on the downstream end. Sort of like putting a phone call on hold at the receiving end functionally renders the phone at the calling end unusable. I also haven't considered LU6.2 but LU6.2 is SNA app to SNA app so I can't see and SNA LU6.2 session terminating within a 3174. I know of LU type 6.2, but not much else about them. Token/Ring and Ethernet yes. I don't know of a way to have SDLC <-> to SDLC. But again its not an SNA end point to end point. The 3174 is merely routing SNA Frames. It sounds like the 3174 is conceptually routing or perhaps actually switching SNA frames between connections based on endpoints the 3174's portion of the big table of who's connected where. Everything has a path in the tree back to the host. I believe here it means "route SNA traffic". I guess that there may also be SNA management sessions. I see that 3174's also support SNMP so there might be SNMP sessions... TCP/IP support improved over the years, yes..
Re: IBM 3174 C 6.4 Microcode Disks?
> On Feb 20, 2019, at 11:31 PM, Grant Taylor via cctalk > wrote: > > On 2/20/19 12:23 PM, Paul Koning via cctalk wrote: >> Please note that among LANs, there is Token Ring (802.5) and there is >> everything else. > > I think it really depends on how you look at them. > > From a frame formatting point of view, Ethernet is the odd ball when looking > at how TCP/IP is carried. > > Everything other than Ethernet (802.3) uses 802.2 or a medium specific > varient of 802.2. Then there's Ethernet which predominantly uses either > Ethernet II for TCP/IP or 802.3 (a.k.a. "Raw") Ethernet frames for IPX. "raw 802.3" is a bug, caused by a programmer not understanding how the specs work. The mapping from Ethernet to 802.2 SNAP is trivial, but yes, you do need that mapping. >> FDDI is like Ethernet and like 802.4. Token Ring is the oddball because (a) >> it doesn't have proper multicast addresses, and (b) for some reason IBM >> invented source-routed bridging and tied that to Token Ring. > > Does it actually need a broadcast address like Ethernet when the ring passes > through all the stations? Or is that functionally comparable to a multicast? Broadcast is just a special case of multicast. My point was that 802.5, at least as IBM thinks of it, doesn't have proper multicast addresses (low bit set plus 47 bits to say what the address is). Instead, it has "functional addresses" which have a fixed beginning plus one of 32 bits that is set. So instead of 2^47 possible values, you have 32. I don't know why this was done. Perhaps their chip designers thought hash or CAM address matching was too hard? So if you have a protocol that uses multicast, like DECnet, you have to translate the real multicast address to the corresponding "functional" address in an Ethernet-802.5 bridge. And you have to make up a functional address, since the address space of 32 values is too small to have globally assigned multicast addresses as you do with other LANs. The ring passes through all stations of a LAN segment, just as the Ethernet bus (in the original version) passes through all stations of the segment. The point of multicast is that it recognized by multiple stations, not just one. But multicast matters to bridges because they have to forward it differently than individual addresses: individual is forwarded according to the address database entry if there is one, while multicast is not learned and always flooded along the spanning tree. >> FDDI is in no way at all like Token Ring. The only thing the two have in >> common is "token" and "ring". The MAC protocol is utterly different; the >> closest relative is 802.4 Token Bus. One example of this is the behavior under high load. At one time, token ring marketeers claimed it was better because it wouldn't "collapse" under load "like Ethernet". That is actually false, but in any event, 802.5 worst case latency is incredibly large for large rings. 802.4 and FDDI with their "timed token protocol" have far lower worst case latency. paul
RE: IBM 3174 C 6.4 Microcode Disks?
> > I'll give you that a "gateway", as in a network layer gateway or router, does > have network protocols that it routes / bridges between. (They may be on a > single interface, a la one-armed-router.) > > > The 3174 NEVER accepts any sort of incoming connections. Just physical > > terminals. > > Um … what do you consider the connections from remote 3174s (physically / > logically) connecting to a local 3174 via Token Ring / Ethernet / SDLC to be > if > not connections to the local 3174? > I think we have a layer disconnect here. There is a PHYSICAL connection, but logically the SNA traffic just passes through the box. You define the MAC addresses of the end points in the 3174 but it knows nothing of the traffic passing through. As far as the end points are concerned its just a router like the one in my wardrobe that links to the VDSL that’s passing my traffic TCPIP traffic through Except that my router has to do NAT. These are all in the same SNA Domain and have unique SNA addresses. When doing SNA the terminal on the remote 3174 connects the VTAM... > I'm using IBM's definition for "local" and "remote" in this context. > > I can see some wiggle room for the connections from the remote 3174 being > to the mainframe via the local 3174 and not actually to the local 3174. > > That being said I still think that the 3270 connection from the RS/6000 are > addressed /to/ the local 3174's Token Ring (MAC) address. Or is this the > above wiggle room too? > That’s just like IP routing. If we are doing SNA then each terminal has an SNA address that’s defined on the host. Its kind of like IP routing. My workstation knows that to route IP traffic to a specified non-local IP address it has to send it to my router. Same with SNA. The SNA connection is between the terminal and the mainframe. The 3174 simply routes traffic > > When used to connect network traffic to a mainframe the 3174 does not > > terminate the TCPIP connection., it passes the frames across to the > > channel. I may be wrong its been a long time since I did this and I > > don't want to go delving into the VTAM documentation. > > The reading that I've done since the start of this thread makes me think that > the connections from the RS/6000 would be SNA over Token Ring. As I > understand it, this means that they are 802.2 LLC SNAP frames carrying > something other than TCP/IP. > > Perhaps the 3174 is receiving those frames and passing them on to the > mainframe via some form of routing or bridging. > Yes, precisely. SNA is a layered protocol just like TCPIP. SNA connections Sit on top of other protocols. > Or perhaps the 3174 is extracting the SNA data off of the Token Ring frames > and passing just the SNA application layer data to the mainframe. > Theoretically VTAM has application layers. In practice it’s a mess... > I suspect that VTAM documentation is in my future if I truly want to > understand this. Or maybe I'll get lucky and someone can answer my > pointed questions. > Yes, the VTAM documentation is a good place to start (well perhaps not). But basically VTAM (used to, I haven't looked for a while) have huge tables that list every device on the network. So if you want to use 10 SNA 3270 terminals concurrently on an RS6000 There must be a VTAM/SNA node defined for the RS6000, and 10 VTAM/SNA nodes for the terminals. This lead to PC type gate products like Microsoft SNA server where you had TN3270 sessions to SNA server then connected via SDLC/Token Ring/X.25 to SNA on the host. If you wanted 20 concurrent session, you defined 20 nodes in VTAM and SNA server. SNA Server would assign in bound TN3270 sessions SNA addresses from its pool and associate them with the terminal... Now I have remembered something nasty. There are SNA management sessions, so if he is feeling nasty, the VTAM operator can disable any terminal on any 3174, or any 3174 . ... so yes there may be SNA sessions between 3174s for management purposes. I also haven't considered LU6.2 but LU6.2 is SNA app to SNA app so I can't see and SNA LU6.2 session terminating within a 3174. > > Its kind of odd. RS232 (so X.25/SDLC/HDLC/Bi-Sync) connections can > > only be used to connect to a Mainframe, not another 3174. > > That's contrary to what I have been reading this week. > > Based on the reading that I've done (I can dig for sources if you want me to), > a remote 3174 can connect to a local 3174 via Token Ring / Ethernet / SDLC. > > This implies that the remote 3174 is connecting to another 3174. (See > additional comments below.) > Token/Ring and Ethernet yes. I don't know of a way to have SDLC <-> to SDLC. But again its not an SNA end point to end point. The 3174 is merely routing SNA Frames. > > The Token Ring or Ethernet interface can be used to connect traffic to > > the mainframe But from what I remember the 3174 isn't too involved at > > this level it is acting as a network router/bridge. > > "too involved" is crit
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/20/19 12:23 PM, Paul Koning via cctalk wrote: Please note that among LANs, there is Token Ring (802.5) and there is everything else. I think it really depends on how you look at them. From a frame formatting point of view, Ethernet is the odd ball when looking at how TCP/IP is carried. Everything other than Ethernet (802.3) uses 802.2 or a medium specific varient of 802.2. Then there's Ethernet which predominantly uses either Ethernet II for TCP/IP or 802.3 (a.k.a. "Raw") Ethernet frames for IPX. FDDI is like Ethernet and like 802.4. Token Ring is the oddball because (a) it doesn't have proper multicast addresses, and (b) for some reason IBM invented source-routed bridging and tied that to Token Ring. Does it actually need a broadcast address like Ethernet when the ring passes through all the stations? Or is that functionally comparable to a multicast? FDDI is in no way at all like Token Ring. The only thing the two have in common is "token" and "ring". The MAC protocol is utterly different; the closest relative is 802.4 Token Bus. And as far as addressing is concerned, FDDI is like 802.4 and Ethernet, with real multicast and general use of normal transparent bridges. The only complication with FDDI (and 802.4, if you could find it) is that it only has 802.2 frames, not classic-Ethernet (with 16 bit protocol types). So an FDDI to Ethernet bridge has to translate Ethernet frames to an 802.2 based encapsulation. That is done by converting them to SNAP frames, as described in RFC 1042. Intriguing. $ReadingList++ Bridges like the DECbridge 500 and DECbridge 900 will do that; I assume Cisco does likewise. FDDI didn't live all that long because 100 Mb Ethernet replaced it, but while it was out there it made a fine backbone for Ethernet-based LANs. :-) -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/20/19 12:13 PM, Ken Seefried via cctalk wrote: re: Cisco and IBM protocols If you're really interested, all of this is exhaustively documented under the umbrella of Cisco's "IBM Feature Set". Thank you Ken. That's the type of information I'm wanting to figure out. There's a *lot* here under the hood, but the last time I looked (admittedly, a while) a number of folks had web sites that documented the correct incantations for Hercules and common hardware. You can bridge between TR (and FDDI) and ethernet on a Cisco, generally for non-routable protocols (e.g. NetBIOS); see: 'translational bridging'. That meshes with what I think I've managed to figure out. Both SNA and NetBIOS use 802.2 LLC frames with SNAP headers. Token Ring and Ethernet are able to carry that without any problem. Hence why they can be relatively bridged bridged without extensively modifying the frames. If you're trying to get these protocols across an intermediary 'alien' network (like the corp FDDI backbone, or the Internet), there are things like DLSw. I learned that while reading this week. Now I want to see if DLSw can be used to connect two Windows machines using NetBIOS across an intermediary 'alien' network running TCP/IP. }:-) If you're trying to get TCP/IP from TR to ethernet and vice versa, routing generally works better/is simpler (IME), ACK Bridging between TCP/IP on 802.2 LLC frames with SNAP on Token Ring to Ethernet II frames on Ethernet is not nearly as simple. Especially when routing inherently handles it. Even Proxy ARP is a form of routing. but Cisco has all sorts of bizarre encapsulation/translation features for different use cases should you need them. *nod* I'm sure I'll find more information than is healthy for me to learn. You can also make the router look like an SNA concentrator (PU?). ~whimper~ I don't need to think about that. I'd love to get a pair of mainframe (VMs?) running in a (non-Parallel) sysplex between a couple of Hercules instances. The idea of using a router as an SNA PU is … intriguing. -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/20/19 4:24 PM, Kevin Monceaux via cctalk wrote: I have the 2513 now. I'm new to Cisco router commands and configuration. If you could give me a crash course on the commands that would display the parts of the configuration that would settle things for your curiosity, I'll see what it has. Cool. I've replied directly. I have no idea how complex this will get, especially if we have to bypass the password, and don't want to get even further into the weeds. I look forward to seeing what we can find out. -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/18/19 1:20 AM, Dave Wade via cctalk wrote: So the 3174 does not do this. 3270 terminals don't talk SNA/3270 to the 3174 as defined in the IBM 3270 data streams. They are usually pretty dumb and from what I can gather all keystrokes go to the 3174 just as for an ASCII terminal. It only becomes a 3270 protocol when it exits the 3174. Okay. So I misunderstood ~> misspoke about the protocol on the coax side of the 3174. You get dumb terminals, either ASCII or 3270 Screens in, and at the other side you connect 3270 over SNA/SDLC, SNA/Token Ring, BiSync, X.25 or whatever. But it sounds like the 3174 is functioning as an application layer gateway in some capacity in that it translates from one thing / protocol to another. That’s exactly what a 3174 does. IBM calls it a Terminal Controller. ACK I think there is, but to me a gateway has LAN protocols on both sides. Ah. To me, a "gateway" can be network layer, application layer, or do other things. I'll give you that a "gateway", as in a network layer gateway or router, does have network protocols that it routes / bridges between. (They may be on a single interface, a la one-armed-router.) The 3174 NEVER accepts any sort of incoming connections. Just physical terminals. Um … what do you consider the connections from remote 3174s (physically / logically) connecting to a local 3174 via Token Ring / Ethernet / SDLC to be if not connections to the local 3174? I'm using IBM's definition for "local" and "remote" in this context. I can see some wiggle room for the connections from the remote 3174 being to the mainframe via the local 3174 and not actually to the local 3174. That being said I still think that the 3270 connection from the RS/6000 are addressed /to/ the local 3174's Token Ring (MAC) address. Or is this the above wiggle room too? When used to connect network traffic to a mainframe the 3174 does not terminate the TCPIP connection., it passes the frames across to the channel. I may be wrong its been a long time since I did this and I don't want to go delving into the VTAM documentation. The reading that I've done since the start of this thread makes me think that the connections from the RS/6000 would be SNA over Token Ring. As I understand it, this means that they are 802.2 LLC SNAP frames carrying something other than TCP/IP. Perhaps the 3174 is receiving those frames and passing them on to the mainframe via some form of routing or bridging. Or perhaps the 3174 is extracting the SNA data off of the Token Ring frames and passing just the SNA application layer data to the mainframe. I suspect that VTAM documentation is in my future if I truly want to understand this. Or maybe I'll get lucky and someone can answer my pointed questions. Its kind of odd. RS232 (so X.25/SDLC/HDLC/Bi-Sync) connections can only be used to connect to a Mainframe, not another 3174. That's contrary to what I have been reading this week. Based on the reading that I've done (I can dig for sources if you want me to), a remote 3174 can connect to a local 3174 via Token Ring / Ethernet / SDLC. This implies that the remote 3174 is connecting to another 3174. (See additional comments below.) The Token Ring or Ethernet interface can be used to connect traffic to the mainframe But from what I remember the 3174 isn't too involved at this level it is acting as a network router/bridge. "too involved" is critical. Just to confuse things this is an IBM manual where IBM does use it as a "gateway"... ~chuckle~ Very little about IBM is simple. http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/lan/GG24-3366-0_3174_Remote_Token-Ring_Gateway_Feb89.pdf I have seen virtually identical diagrams to the one on page 15 where the NCP was a local 3174 instead of the 3720 / 3725 / 3745. Notice how the listed 3174 sub models are all the remote variety. Take a look at page 54 of the following pdf. http://www.bitsavers.org/pdf/ibm/3174/GG24-4172-0_Using_3174_in_TCP_IP_Networks_Jun94.pdf The downstream 3174-13R can talk to either the upstream 3174-11L or the 3172. Figure 244 on page 259 shows the same. so using the Token Ring interface on a remote 3174 to connect SNA traffic to the host via SDLC ... again no TCPIP, working at the frame level, and the host end cannot be a 3174... Figure 244 on page 259 tends to refute that. This document seems to be from 94 verses the document you linked to seeming to be from 89. Maybe things changed in the intervening years. That really muddies the waters because it uses the term "3270" connection in two senses. It uses it to refer to the co-ax type connection from a work station (CUT or DFT) with with 3270 over Channel/SNA as defined in the 3270 data streams manual and these really are different protocols. I agree to your prior comment that this traffic between the terminals and the 3174 terminal controller is not 3270. That’s where you are going wr
Re: IBM 3174 C 6.4 Microcode Disks?
It was thus said that the Great Kevin Monceaux via cctalk once stated: > Grant, > > On Sat, Feb 16, 2019 at 07:36:11PM -0700, Grant Taylor via cctalk wrote: > > > If the 2513 you have is the one that was used for this, I'd love to see > > the config, if it's still on there. That would very likely settle > > things for my curiosity. > > I have the 2513 now. I'm new to Cisco router commands and configuration. > If you could give me a crash course on the commands that would display the > parts of the configuration that would settle things for your curiosity, I'll > see what it has. The Cisco "command line" is quite nice and will always show you what it's expecting next when you press '?' at any point. If I recall correctly, "show config" will show the current saved configuration to the screen, and "show running-config" will show the currently running configuration (it will be different if you've made changes without saving them). You don't even need to type out the whole thing---just enough to disambiguate the command (I think 'sh conf" is enough, maybe even "sh c"). -spc
Re: IBM 3174 C 6.4 Microcode Disks?
Grant, On Sat, Feb 16, 2019 at 07:36:11PM -0700, Grant Taylor via cctalk wrote: > If the 2513 you have is the one that was used for this, I'd love to see > the config, if it's still on there. That would very likely settle > things for my curiosity. I have the 2513 now. I'm new to Cisco router commands and configuration. If you could give me a crash course on the commands that would display the parts of the configuration that would settle things for your curiosity, I'll see what it has. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
Re: IBM 3174 C 6.4 Microcode Disks?
> FDDI didn't live all that long because 100 Mb Ethernet replaced it, but while > it was out there it made a fine backbone for Ethernet-based LANs. And a good sized chunk of the Internet ran over it for a good long while. Also pretty bullet proof. -- Will
Re: IBM 3174 C 6.4 Microcode Disks?
On Wed, Feb 20, 2019 at 2:23 PM Paul Koning wrote: > > > > > On Feb 20, 2019, at 2:13 PM, Ken Seefried via cctalk > > wrote: > > > > ... > > You can bridge between TR (and FDDI) and ethernet on a Cisco, > > generally for non-routable protocols (e.g. NetBIOS); see: > > 'translational bridging'. If you're trying to get these protocols > > across an intermediary 'alien' network (like the corp FDDI backbone, > > or the Internet), there are things like DLSw. > > Please note that among LANs, there is Token Ring (802.5) and there is > everything else. FDDI is like Ethernet and like 802.4. Token Ring is the > oddball because (a) it doesn't have proper multicast addresses, and (b) for > some reason IBM invented source-routed bridging and tied that to Token Ring. > > FDDI is in no way at all like Token Ring. The only thing the two have in > common is "token" and "ring". The MAC protocol is utterly different; the > closest relative is 802.4 Token Bus. And as far as addressing is concerned, > FDDI is like 802.4 and Ethernet, with real multicast and general use of > normal transparent bridges. > I didn't say TR was like FDDI. I said you could bridge FDDI to Ethernet using translation bridging.
Re: IBM 3174 C 6.4 Microcode Disks?
> On Feb 20, 2019, at 2:13 PM, Ken Seefried via cctalk > wrote: > > ... > You can bridge between TR (and FDDI) and ethernet on a Cisco, > generally for non-routable protocols (e.g. NetBIOS); see: > 'translational bridging'. If you're trying to get these protocols > across an intermediary 'alien' network (like the corp FDDI backbone, > or the Internet), there are things like DLSw. Please note that among LANs, there is Token Ring (802.5) and there is everything else. FDDI is like Ethernet and like 802.4. Token Ring is the oddball because (a) it doesn't have proper multicast addresses, and (b) for some reason IBM invented source-routed bridging and tied that to Token Ring. FDDI is in no way at all like Token Ring. The only thing the two have in common is "token" and "ring". The MAC protocol is utterly different; the closest relative is 802.4 Token Bus. And as far as addressing is concerned, FDDI is like 802.4 and Ethernet, with real multicast and general use of normal transparent bridges. The only complication with FDDI (and 802.4, if you could find it) is that it only has 802.2 frames, not classic-Ethernet (with 16 bit protocol types). So an FDDI to Ethernet bridge has to translate Ethernet frames to an 802.2 based encapsulation. That is done by converting them to SNAP frames, as described in RFC 1042. Bridges like the DECbridge 500 and DECbridge 900 will do that; I assume Cisco does likewise. FDDI didn't live all that long because 100 Mb Ethernet replaced it, but while it was out there it made a fine backbone for Ethernet-based LANs. paul
RE: IBM 3174 C 6.4 Microcode Disks?
re: Cisco and IBM protocols If you're really interested, all of this is exhaustively documented under the umbrella of Cisco's "IBM Feature Set". There's a *lot* here under the hood, but the last time I looked (admittedly, a while) a number of folks had web sites that documented the correct incantations for Hercules and common hardware. You can bridge between TR (and FDDI) and ethernet on a Cisco, generally for non-routable protocols (e.g. NetBIOS); see: 'translational bridging'. If you're trying to get these protocols across an intermediary 'alien' network (like the corp FDDI backbone, or the Internet), there are things like DLSw. If you're trying to get TCP/IP from TR to ethernet and vice versa, routing generally works better/is simpler (IME), but Cisco has all sorts of bizarre encapsulation/translation features for different use cases should you need them. You can also make the router look like an SNA concentrator (PU?). KJ
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/19/19 7:39 PM, Jim Stefanik via cctalk wrote: > Well, it turns out my floppies are for *3274* rather than 3174. But, > that said, if anyone needs any of them, let me know: just shipping cost. I can use them. I ended up with one w/o media
Re: IBM 3174 C 6.4 Microcode Disks?
OK, so this thread pushed my to pursue playing with DT/6000. If anyone has documentation on how exactly everything fits together, please let me know...if someone miraculously has a copy of DT/6000 in their archive, I could use a copy. Feel free to ping me off list to keep the noise here down. --- Jim Stefanik Dallas Vintage Computing Center From: Jay Jaeger via cctech Sent: Monday, 18 February 2019 15:48 To: cct...@classiccmp.org Subject: Re: IBM 3174 C 6.4 Microcode Disks? On 2/15/2019 10:22 AM, Jay Jaeger via cctech wrote: > On 2/14/2019 9:28 PM, Kevin Monceaux via cctalk wrote: >> Classic Computer Fans, >> >> I posted this to the IBM-Legacy-Hercules mailing list. I just realized it >> probably wouldn't hurt to post it here too. >> >> I'm finally in possession of a box that hopefully is capable or can be made >> capable of connecting a real terminal to Hercules. It's a 3174 11L. It was >> retired last year where I work. I finally got the okay to save it from >> being sent to a scrapper. I love the build quality of older IBM gear, >> except when I'm trying to move such gear. Between the 3174 and a 9406-520 I >> also acquired, I pulled or strained something in my left arm moving them >> into place. >> >> It's currently wired to run on 220v. I think I've seen mentioned somewhere >> that it can be changed to run on 110v. If that's the case, does anyone have >> a pointer to documentation on what's involved? >> >> It has dual floppy drives. At least one drive is a 2.4MB drive. But, all >> the microcode disks I have are at level B 4.6. Does anyone know where I can >> get a set of C 6.4 control and control extension disks. From what I've >> heard those are what's needed to enable an attached terminal to connect to >> other systems via telnet. >> >> It has a token ring card. I will probably be able to get the MAU it was >> connected to, and possibly the router that acted as a token ring to Ethernet >> bridge. >> >> I'm not sure how much memory it has. Does anyone have any tips on >> determining the amount of memory it has, and/or identifying its boards? >> These are the numbers on its boards: >> >> 9210 >> 9351 >> 9052 z2 >> 9053 >> 9501 >> >> Plus the boards for coax connections. >> >> >> > > I have some 3174 floppy disks, but I don't know what - they are not in > my inventory. I will put it on my queue to look at them - but it may be > a couple of weeks. I don't hold out much hope, but I will look. > Well, it turns out my floppies are for *3274* rather than 3174. But, that said, if anyone needs any of them, let me know: just shipping cost. Here is a sample: 3274 Disks IBM Diskette 2 256 Bytes/Sector Date Name 8/09/83 A13 FEAT DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 [Customized] 8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 [Customized] 6/18/84 A22 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A12 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/01/84 A22 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 7/01/84 A12 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 7/12/84 A23 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/12/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/18/84 A23 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 6/11/85 B22 18.33 LANGUAGE DISKETTE FOR CONFIG D AT REL 64.0 OR HIGHER 6/11/85 A12 21.30 SYSTEM - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR HIGHER 6/18/85 A12 19.40 FEATURE - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR HIGHER 6/24/86 B23 17.17 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER 6/24/86 B12 17.08 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER 6/24/86 B12 17.05 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER --- KYB DEF UTILILTY REL G FOR LOAD 3290 D41.00, 3179-G D25.00 OR HIGHER (And about 150 more, in a similar date range)
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/15/2019 10:22 AM, Jay Jaeger via cctech wrote: > On 2/14/2019 9:28 PM, Kevin Monceaux via cctalk wrote: >> Classic Computer Fans, >> >> I posted this to the IBM-Legacy-Hercules mailing list. I just realized it >> probably wouldn't hurt to post it here too. >> >> I'm finally in possession of a box that hopefully is capable or can be made >> capable of connecting a real terminal to Hercules. It's a 3174 11L. It was >> retired last year where I work. I finally got the okay to save it from >> being sent to a scrapper. I love the build quality of older IBM gear, >> except when I'm trying to move such gear. Between the 3174 and a 9406-520 I >> also acquired, I pulled or strained something in my left arm moving them >> into place. >> >> It's currently wired to run on 220v. I think I've seen mentioned somewhere >> that it can be changed to run on 110v. If that's the case, does anyone have >> a pointer to documentation on what's involved? >> >> It has dual floppy drives. At least one drive is a 2.4MB drive. But, all >> the microcode disks I have are at level B 4.6. Does anyone know where I can >> get a set of C 6.4 control and control extension disks. From what I've >> heard those are what's needed to enable an attached terminal to connect to >> other systems via telnet. >> >> It has a token ring card. I will probably be able to get the MAU it was >> connected to, and possibly the router that acted as a token ring to Ethernet >> bridge. >> >> I'm not sure how much memory it has. Does anyone have any tips on >> determining the amount of memory it has, and/or identifying its boards? >> These are the numbers on its boards: >> >> 9210 >> 9351 >> 9052 z2 >> 9053 >> 9501 >> >> Plus the boards for coax connections. >> >> >> > > I have some 3174 floppy disks, but I don't know what - they are not in > my inventory. I will put it on my queue to look at them - but it may be > a couple of weeks. I don't hold out much hope, but I will look. > Well, it turns out my floppies are for *3274* rather than 3174. But, that said, if anyone needs any of them, let me know: just shipping cost. Here is a sample: 3274 Disks IBM Diskette 2 256 Bytes/Sector DateName 8/09/83 A13 FEAT DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 [Customized] 8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30 [Customized] 6/18/84 A22 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A12 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/01/84 A22 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 7/01/84 A12 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 7/12/84 A23 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/12/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33 7/18/84 A23 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR HIGHER 6/11/85 B22 18.33 LANGUAGE DISKETTE FOR CONFIG D AT REL 64.0 OR HIGHER 6/11/85 A12 21.30 SYSTEM - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR HIGHER 6/18/85 A12 19.40 FEATURE - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR HIGHER 6/24/86 B23 17.17 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER 6/24/86 B12 17.08 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER 6/24/86 B12 17.05 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER --- KYB DEF UTILILTY REL G FOR LOAD 3290 D41.00, 3179-G D25.00 OR HIGHER (And about 150 more, in a similar date range)
Re: IBM 3174 C 6.4 Microcode Disks?
Grant, On Sat, Feb 16, 2019 at 11:05:23PM -0700, Grant Taylor via cctalk wrote: > Is that by chance a 9291? Looks like a white / bage box with a grey > strip on the front with lights or buttons and a serial port and ""phone > (PSTN) network jack on the back? Checking our hardware list it looks like I made a typo. It is a 9291. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
RE: IBM 3174 C 6.4 Microcode Disks?
I will apologise at the top as this is slightly rambling... > -Original Message- > From: cctalk On Behalf Of Grant Taylor via > cctalk > Sent: 18 February 2019 03:46 > To: cctalk@classiccmp.org > Subject: Re: IBM 3174 C 6.4 Microcode Disks? > > On 2/17/19 2:23 AM, Dave Wade wrote: > > I would say the 3174 is acting more as a Terminal Server rather than a > > gateway. So 3270 CO-AX terminals which are directly attached to the > > 3174 can connect via TN3270 to another host. Often this is Hercules > > where Hercules provides a a TN3270 server which is presented to the > > host as a channel attached 3174... > > I think we should clarify what "Terminal Server" and "Gateway" mean in this > context. > > I was using "Gateway" to mean going between two different types of > networks, SNA / 3270 on one side and TCP/IP / Telnet on the other side. > So the 3174 does not do this. 3270 terminals don't talk SNA/3270 to the 3174 as defined in the IBM 3270 data streams. They are usually pretty dumb and from what I can gather all keystrokes go to the 3174 just as for an ASCII terminal. It only becomes a 3270 protocol when it exits the 3174. You get dumb terminals, either ASCII or 3270 Screens in, and at the other side you connect 3270 over SNA/SDLC, SNA/Token Ring, BiSync, X.25 or whatever. > I'm not sure how to define "terminal server". I would think that a terminal > server does what is needed to connect a terminal and drive a terminal. > That’s exactly what a 3174 does. IBM calls it a Terminal Controller. > I think there's a significant overlap in those two terms and their associated > definitions. > > Please correct me as you see fit. I think there is, but to me a gateway has LAN protocols on both sides. > > > A 3174 can have either a Token Ring or Ethernet interface but not both. > > (it can also have hdlc/sdlc/bi-sync and bus+tag) > > The reading that I did last night agrees with that. But I don't see how > that's > germane to this discussion. > > > The 3174 never acts as a telnet server but. > > > > A channel attached 3174 can be used to pass TCPIP into the mainframe > > and there are products that run on the mainframe that act as > > Telnet/TN3270 servers. So in effect it acts as a channel attached > > network interface for the mainframe. > > Okay. > > Maybe I'm supplementing a poor understanding of what a 3174 is with what I > /think/ a Cisco router with a Channel Interface Processor is. Namely that the > Cisco terminates the TCP/IP connection and generates a new 3270 based > terminal connection into the mainframe. Note how there is no TCP/IP > passing through the Cisco + CIP into the mainframe. > The 3174 NEVER accepts any sort of incoming connections. Just physical terminals. When used to connect network traffic to a mainframe the 3174 does not terminate the TCPIP connection., it passes the frames across to the channel. I may be wrong its been a long time since I did this and I don't want to go delving into the VTAM documentation. > > Some 3174s have RS232 ports, so locally attached serial terminals can > > connect to the mainframe. This can be via Channels or via remote > > network connectivity, SNA token ring, X.25, SNA over Ethernet. > > ACK > > It's my understanding that 3174s that connect to channels / ESCON / FICON > (via adaptation) are "Local" 3174s. They can have network (Token-Ring / > Ethernet / RS-232 / other) interfaces that are used to talk to other "Remote" > 3174s. The "Remote" 3174s then connect and drive local 3270 terminals > which communicate across the network. > Its kind of odd. RS232 (so X.25/SDLC/HDLC/Bi-Sync) connections can only be used to connect to a Mainframe, not another 3174. The Token Ring or Ethernet interface can be used to connect traffic to the mainframe But from what I remember the 3174 isn't too involved at this level it is acting as a network router/bridge. Just to confuse things this is an IBM manual where IBM does use it as a "gateway"... http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/lan/GG24-3366-0_3174_Remote_Token-Ring_Gateway_Feb89.pdf so using the Token Ring interface on a remote 3174 to connect SNA traffic to the host via SDLC ... again no TCPIP, working at the frame level, and the host end cannot be a 3174... > > It depends on what is at the other end. If you are going TCPIP/TN3270 > > then normally you use a router. However if you are going SNA over LAN > > into the mainframe, from what I remember SNA LAN protocols are > > non-soutable so you need a bridge/gateway. > > I think we just fell of
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/17/19 2:23 AM, Dave Wade wrote: I would say the 3174 is acting more as a Terminal Server rather than a gateway. So 3270 CO-AX terminals which are directly attached to the 3174 can connect via TN3270 to another host. Often this is Hercules where Hercules provides a a TN3270 server which is presented to the host as a channel attached 3174... I think we should clarify what "Terminal Server" and "Gateway" mean in this context. I was using "Gateway" to mean going between two different types of networks, SNA / 3270 on one side and TCP/IP / Telnet on the other side. I'm not sure how to define "terminal server". I would think that a terminal server does what is needed to connect a terminal and drive a terminal. I think there's a significant overlap in those two terms and their associated definitions. Please correct me as you see fit. A 3174 can have either a Token Ring or Ethernet interface but not both. (it can also have hdlc/sdlc/bi-sync and bus+tag) The reading that I did last night agrees with that. But I don't see how that's germane to this discussion. The 3174 never acts as a telnet server but. A channel attached 3174 can be used to pass TCPIP into the mainframe and there are products that run on the mainframe that act as Telnet/TN3270 servers. So in effect it acts as a channel attached network interface for the mainframe. Okay. Maybe I'm supplementing a poor understanding of what a 3174 is with what I /think/ a Cisco router with a Channel Interface Processor is. Namely that the Cisco terminates the TCP/IP connection and generates a new 3270 based terminal connection into the mainframe. Note how there is no TCP/IP passing through the Cisco + CIP into the mainframe. Some 3174s have RS232 ports, so locally attached serial terminals can connect to the mainframe. This can be via Channels or via remote network connectivity, SNA token ring, X.25, SNA over Ethernet. ACK It's my understanding that 3174s that connect to channels / ESCON / FICON (via adaptation) are "Local" 3174s. They can have network (Token-Ring / Ethernet / RS-232 / other) interfaces that are used to talk to other "Remote" 3174s. The "Remote" 3174s then connect and drive local 3270 terminals which communicate across the network. It depends on what is at the other end. If you are going TCPIP/TN3270 then normally you use a router. However if you are going SNA over LAN into the mainframe, from what I remember SNA LAN protocols are non-soutable so you need a bridge/gateway. I think we just fell off the end of the continental shelf into the ocean. - But IMHO this is fun. This is how we (I) learn new things. :-D After having skimmed the PDF that Kevin linked to, I've mostly settled on the following: The 3174s speak TCP/IP on the downstream (grey) (Token Ring / Ethernet) LAN / side. (I'm ignoring the protocols across the other circuits that the 3174 supports between 3174s.) There are two frame types that are supported on Token Ring, 802.2 Logical Link Control and 802.2 LLC with SubNetwork Access Protocol. TCP/IP on Token Ring traditionally uses SNAP. Conversely, there are four frame types that are supported on Ethernet; LLC, SNAP, Ethernet v2, and 802.3 "Raw". TCP/IP on Ethernet traditionally used Ethernet v2. So, we have a discrepancy between the frame types that traditionally carry TCP/IP on Token Ring and Ethernet. The easiest way to deal with this is to use a router that uses the proper frame type for the underlying network. But that's /routing/, and not bridging. Hence why my qualm / uncertanty was "routing" vs "bridging". I think it may be possible to have a piece of software / hardware actually /bridge/ the IP packet or TCP datagram between SNAP and Ethernet v2 (and vice versa). But I've /rarely/ heard of that being done. Especially when you have MTU differences between Token Ring and Ethernet that are difficult to deal with transparently. I concede that data is being connected between the two networks much like a bridge allows cars to connect between islands. So, back to your statement. "TCPIP/TN3270 then normally you use a router." Where does the TCP/IP connection that is the TN3270 traffic terminate? Is it on the router? Or is it on the mainframe? Please elaborate on what you mean by "SNA over LAN". What protocols would that be seen as on the LAN client? NetBIOS? Something other than TN3270 over TCP/IP? Are you referring to DLC? It's my understanding that DLC is a point-to-point protocol and not usable on a LAN. I ask because I did not see any reference to anything other than TCP/IP in conjunction with the 3174 LAN interface. I agree that NetBIOS is not routable. If you run Hercules on a PC with a Token Ring card then you don't need anything. How is the 3174 going to connect a 3270 terminal to Hercules running on a PC via Token Ring if not TN3270? Or is that the difference in terms that I was comm
RE: IBM 3174 C 6.4 Microcode Disks?
> -Original Message- > From: cctalk On Behalf Of Al Kossow via > cctalk > Sent: 17 February 2019 16:29 > To: cctalk@classiccmp.org > Subject: Re: IBM 3174 C 6.4 Microcode Disks? > > > > On 2/16/19 6:36 PM, Grant Taylor via cctalk wrote: > > >> As for using telnet on the 3174, I'm going by what I've seen posted > >> on Hercules mailing lists about how others have connected real > >> terminals to the Hercules mainframe emulator. A few pictures of such > terminals connected to Hercules can be found at: > >> > >> http://CoreStore.org/emuterm.htm > > > > I should look for more details. It sounds like some 3174's, with > > proper firmware, can actually function in both directions. > > > > Coax connected 3270 terminals using the 3174 as a gateway to connect > > to something across the network (Token Ring or maybe Ethernet) via > telnet. I suspect this is what a number of Hercules systems are doing. > > > > Guy has this running with a 3174 and ethernet interface. > Jay has it working with token ring. > > I have all the parts to put this together, just no time to work on it right > now. > Mine isn't up at the moment, but I have had it running via Token Ring Dave
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/16/19 6:36 PM, Grant Taylor via cctalk wrote: >> As for using telnet on the 3174, I'm going by what I've seen posted on >> Hercules mailing lists about how others have >> connected real terminals to the Hercules mainframe emulator. A few pictures >> of such terminals connected to Hercules >> can be found at: >> >> http://CoreStore.org/emuterm.htm > > I should look for more details. It sounds like some 3174's, with proper > firmware, can actually function in both > directions. > > Coax connected 3270 terminals using the 3174 as a gateway to connect to > something across the network (Token Ring or > maybe Ethernet) via telnet. I suspect this is what a number of Hercules > systems are doing. > Guy has this running with a 3174 and ethernet interface. Jay has it working with token ring. I have all the parts to put this together, just no time to work on it right now.
RE: IBM 3174 C 6.4 Microcode Disks?
> > I should look for more details. It sounds like some 3174's, with proper > firmware, can actually function in both directions. > > Coax connected 3270 terminals using the 3174 as a gateway to connect to > something across the network (Token Ring or maybe Ethernet) via telnet. > I suspect this is what a number of Hercules systems are doing. > I would say the 3174 is acting more as a Terminal Server rather than a gateway. So 3270 CO-AX terminals which are directly attached to the 3174 can connect via TN3270 to another host. Often this is Hercules where Hercules provides a a TN3270 server which is presented to the host as a channel attached 3174... A 3174 can have either a Token Ring or Ethernet interface but not both. (it can also have hdlc/sdlc/bi-sync and bus+tag) > I think it's also possible to have (Token Ring or Ethernet) network connected > clients telnet to and use the 3174 as a gateway to connect to ESCON / Bus > and Tag machines. > The 3174 never acts as a telnet server but. A channel attached 3174 can be used to pass TCPIP into the mainframe and there are products that run on the mainframe that act as Telnet/TN3270 servers. So in effect it acts as a channel attached network interface for the mainframe. Some 3174s have RS232 ports, so locally attached serial terminals can connect to the mainframe. This can be via Channels or via remote network connectivity, SNA token ring, X.25, SNA over Ethernet. > > The posts I've seen say one either needs a router to act as a token > > ring to Ethernet bridge, or a PC with both token ring and Ethernet > > cards in it to act as a bridge. > > I tend to agree. My only qualm / uncertanty is "bridge" vs "route". > It depends on what is at the other end. If you are going TCPIP/TN3270 then normally you use a router. However if you are going SNA over LAN into the mainframe, from what I remember SNA LAN protocols are non-soutable so you need a bridge/gateway. If you run Hercules on a PC with a Token Ring card then you don't need anything. > But this is likely the pedantic part of me that knows enough details to think > "Wait, tab A doesn't directly fit in slot B, what gives?" in this situation. > > If the 2513 you have is the one that was used for this, I'd love to see the > config, if it's still on there. That would very likely settle things for my > curiosity. But that's likely not going to happen. 1) The config should have > been wiped before leaving a business, and 2) you shouldn't show it to a > stranger even if #1 didn't happen. > Do a search on "CISCO SNA Token Ring Bridging". Lots of papers on there. Last time I fired this lot up I used the CISCO as an IP router and then used NAT In the CISCO hide the token ring from main network. Now I have a 3174 with An Ethernet card and a P390 with a bigger selction of Oss I have lots of options... ... but I am currently distracted by a pile of VAXen > > > -- > Grant. . . . > unix || die Dave
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/16/19 9:49 PM, Kevin Monceaux via cctalk wrote: The 9121 voice server connected a T1 line to the RS/6000 for use by DT/6000. DT/6000 was used to create interactive phone menu systems. Is that by chance a 9291? Looks like a white / bage box with a grey strip on the front with lights or buttons and a serial port and ""phone (PSTN) network jack on the back? I suspect wherever I saw the term "bridge" used, it was used in the sense of providing IP connectivity from token ring to Ethernet, in the same sense that a physical bridge provides connectivity between two banks of a river. ACK Yes, that's what our RS/6000 was doing. It connected via token ring to the 3174 and screen scraped 3270 sessions to move data between its phone menu system and our mainframe. You might find this interesting: http://www.bitsavers.org/pdf/ibm/lan/ZZ78-0355-0_IBM_Token-Ring_Gateways_and_Bridges_Comparisons_and_Recommendations_Nov89.pdf Probably more show than is health in this day and age. I counter you with this: https://www.argecy.com/3174 I don't have it yet. If I'm able to get it with its config intact, I'll share what I can, minus any company specific details. Cool! Based on the Argecy link above, I'm guessing that it's likely routed TCP/IP. That would be the simplest option. -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
Grant, On Sat, Feb 16, 2019 at 07:36:11PM -0700, Grant Taylor via cctalk wrote: > I'm running into collisions with IBM 9121 and mainframe components. > Even that is vague. I'm not having nearly the luck I usually do looking > up IBM four digit model numbers. The 9121 voice server connected a T1 line to the RS/6000 for use by DT/6000. DT/6000 was used to create interactive phone menu systems. > So you had IP connectivity from Ethernet to Token Ring. That's trivial > to do. The Cisco 2513 would be a very good candidate router to do that. I suspect wherever I saw the term "bridge" used, it was used in the sense of providing IP connectivity from token ring to Ethernet, in the same sense that a physical bridge provides connectivity between two banks of a river. > I think it's also possible to have (Token Ring or Ethernet) network > connected clients telnet to and use the 3174 as a gateway to connect to > ESCON / Bus and Tag machines. Yes, that's what our RS/6000 was doing. It connected via token ring to the 3174 and screen scraped 3270 sessions to move data between its phone menu system and our mainframe. You might find this interesting: http://www.bitsavers.org/pdf/ibm/lan/ZZ78-0355-0_IBM_Token-Ring_Gateways_and_Bridges_Comparisons_and_Recommendations_Nov89.pdf > If the 2513 you have is the one that was used for this, I'd love to see > the config, if it's still on there. I don't have it yet. If I'm able to get it with its config intact, I'll share what I can, minus any company specific details. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/14/19 10:03 PM, Kevin Monceaux via cctalk wrote: I also acquired an RS/6000 7012-340, its 7208 8mm tape drive, and a couple of 9121 voice servers. It used to run DirectTalk/6000. I'm running into collisions with IBM 9121 and mainframe components. Even that is vague. I'm not having nearly the luck I usually do looking up IBM four digit model numbers. I might have the terminology wrong. I not very familiar with the token ring side of things. By the time I got into mainframe operations about twenty years ago we only had a few token ring devices left. The RS/6000 mentioned above was only connected to the token ring side of our network. It connected to the 3174 via token ring to screen scrape emulated 3270 sessions. Before the RS/6000 was shut down, I was able to telnet to it from my PC, which was on the Ethernet side of the network. So you had IP connectivity from Ethernet to Token Ring. That's trivial to do. The Cisco 2513 would be a very good candidate router to do that. Many things can /route/ between Ethernet and Token Ring. There are only a few things (that I'm aware of) that can /bridge/ between Ethernet and Token Ring. Even then, the union of the type of traffic that works on both Ethernet and Token Ring is considerably smaller than either side. TCP/IP inside of 802.2 SNAP frames will work. But exceptionally little on the Ethernet side can, much less does, uses that for TCP/IP. It's possible, but not likely. I think it's far more likely that the 2513 was routing. It may have also been doing some sort of NAT / port forwarding (which is largely modifying the packet before it's routed). The router in is the Cisco 2500 series, perhaps a 2513. I found this photo on the net, which looks like the router in question, if I remember correctly: https://kyozoufs.blob.core.windows.net/filestoragetcdb/Pictures/_30/29886/29885389.jpg Yep. That's a quintessential Ethernet & Token Ring router. As for using telnet on the 3174, I'm going by what I've seen posted on Hercules mailing lists about how others have connected real terminals to the Hercules mainframe emulator. A few pictures of such terminals connected to Hercules can be found at: http://CoreStore.org/emuterm.htm I should look for more details. It sounds like some 3174's, with proper firmware, can actually function in both directions. Coax connected 3270 terminals using the 3174 as a gateway to connect to something across the network (Token Ring or maybe Ethernet) via telnet. I suspect this is what a number of Hercules systems are doing. I think it's also possible to have (Token Ring or Ethernet) network connected clients telnet to and use the 3174 as a gateway to connect to ESCON / Bus and Tag machines. The posts I've seen say one either needs a router to act as a token ring to Ethernet bridge, or a PC with both token ring and Ethernet cards in it to act as a bridge. I tend to agree. My only qualm / uncertanty is "bridge" vs "route". But this is likely the pedantic part of me that knows enough details to think "Wait, tab A doesn't directly fit in slot B, what gives?" in this situation. If the 2513 you have is the one that was used for this, I'd love to see the config, if it's still on there. That would very likely settle things for my curiosity. But that's likely not going to happen. 1) The config should have been wiped before leaving a business, and 2) you shouldn't show it to a stranger even if #1 didn't happen. -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
There was quite a bit of difference up until POWER6 although each generation came closer and closer together. It wasn’t just the IOPs, the systems had different management controllers, cases, expansion enclosures, etc as late as POWER5 and only ran AIX in LPARs or PASE. The early PowerPC 400s were PowerPC-AS chips designed in Rochester, MN whereas most other POWER and PowerPC work was an Austin, TX creation. Rochester did the RS64 family of processors which were very nice low power chips that also introduced “hyperthreading” and other advanced technologies but these were offered in RS/6000s as well for commercial workloads (DB, web services). https://en.wikipedia.org/wiki/IBM_RS64 On Fri, Feb 15, 2019 at 7:02 PM Paul Berger via cctalk < cctalk@classiccmp.org> wrote: > > On 2019-02-15 4:04 p.m., Liam Proven via cctalk wrote: > > On Fri, 15 Feb 2019 at 19:27, Paul Berger via cctalk > > wrote: > > > >> Knowledge Center refers to it as IBM i, but it is not the name of a > >> system it is just the name of another OS that runs on IBM Power systems > >> and can even be vitalized on a system with other OSes. > > IBM moved the AS/400 onto POWER processors. The TIMI (sp?) firmware > > made this doable and binaries were portable from the old hardware. The > > OS was renamed i5/OS. > > > > Later they replaced the proprietary POWER hardware with generic POWER > > servers, and they renamed the OS to IBM i. > > > > IBM supports 3 OSes on POWER servers now: AIX, Linux and IBM i. > > > > Silly name, though. > > Only the very first RISC based AS/400s where really different hardware, > by the turn of the century when the second generation of RS64 / Power3 > systems where coming along there was already a lot of common hardware > between AS/400or iSeries and RS/6000 or pSeries only by Power5 time the > hardware was all the same except iSeries was still clinging to the IOP > but even that went away with Power 6 and even the support for Twinax WSC > is gone now since the last ones where PCI. > > Paul. > > >
Re: IBM 3174 C 6.4 Microcode Disks?
On 2019-02-15 4:04 p.m., Liam Proven via cctalk wrote: On Fri, 15 Feb 2019 at 19:27, Paul Berger via cctalk wrote: Knowledge Center refers to it as IBM i, but it is not the name of a system it is just the name of another OS that runs on IBM Power systems and can even be vitalized on a system with other OSes. IBM moved the AS/400 onto POWER processors. The TIMI (sp?) firmware made this doable and binaries were portable from the old hardware. The OS was renamed i5/OS. Later they replaced the proprietary POWER hardware with generic POWER servers, and they renamed the OS to IBM i. IBM supports 3 OSes on POWER servers now: AIX, Linux and IBM i. Silly name, though. Only the very first RISC based AS/400s where really different hardware, by the turn of the century when the second generation of RS64 / Power3 systems where coming along there was already a lot of common hardware between AS/400or iSeries and RS/6000 or pSeries only by Power5 time the hardware was all the same except iSeries was still clinging to the IOP but even that went away with Power 6 and even the support for Twinax WSC is gone now since the last ones where PCI. Paul.
Re: IBM 3174 C 6.4 Microcode Disks?
On 02/15/2019 02:43 PM, Cameron Kaiser via cctalk wrote: On *some* Power Systems machines. IBM really hates it if you try running it on Power hardware it's not licensed for, even if you can get it working (ditto for AIX). I think Linux will run on any contemporary IBM POWER system. You need entitlement codes to enable AIX and / or IBM i. It's possible to run all three on one box. -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/15/19 3:04 AM, Dave Wade via cctalk wrote: > 2) https://www.argecy.com/2389 have microcode. Al says he got some from them > recently. I can copy the latest version but I am short of 2.4MB disks > (and in th uk) They have many revs of the firmware. I bought two, the last for the hard-disk supported 3174, and a set for an early 81R 2.4mb floppy media is unobtainium. I did ask if they had any. I bought a 91R to experiment with figuring out more about running the drives in ED mode, but have been busy with dealing with media recovery.
Re: IBM 3174 C 6.4 Microcode Disks?
> Knowledge Center refers to it as IBM i, but it is not the name of a > system it is just the name of another OS that runs on IBM Power systems > and can even be vitalized on a system with other OSes. On *some* Power Systems machines. IBM really hates it if you try running it on Power hardware it's not licensed for, even if you can get it working (ditto for AIX). -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- TRUE HEADLINE: Morning-After Pill Decision Delayed -
Re: IBM 3174 C 6.4 Microcode Disks?
On Fri, 15 Feb 2019 at 19:27, Paul Berger via cctalk wrote: > Knowledge Center refers to it as IBM i, but it is not the name of a > system it is just the name of another OS that runs on IBM Power systems > and can even be vitalized on a system with other OSes. IBM moved the AS/400 onto POWER processors. The TIMI (sp?) firmware made this doable and binaries were portable from the old hardware. The OS was renamed i5/OS. Later they replaced the proprietary POWER hardware with generic POWER servers, and they renamed the OS to IBM i. IBM supports 3 OSes on POWER servers now: AIX, Linux and IBM i. Silly name, though. -- Liam Proven - Profile: https://about.me/liamproven Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: IBM 3174 C 6.4 Microcode Disks?
On 2019-02-15 12:45 p.m., Grant Taylor via cctalk wrote: On 02/15/2019 08:03 AM, Kevin Monceaux via cctalk wrote: I know, they're not called AS/400s any more. We're on a POWER 8 box, an 8286-41A. But until IBM comes up with a new name that's an improvement over AS/400, we're sticking with that name. Apple was already using the letter i, and giving the platform a single letter name makes searching for online information about the platform a challenge. I think the ""proper (yes, with (air)quotes) name is "IBM i". So it's not a single letter. But it is a collision ala "A. Pope" from National Treasure. (Yes, that scene blew my mind. Hence it's the canonical example that I use.) Knowledge Center refers to it as IBM i, but it is not the name of a system it is just the name of another OS that runs on IBM Power systems and can even be vitalized on a system with other OSes. Paul.
Re: IBM 3174 C 6.4 Microcode Disks?
> I know, they're not called AS/400s any more. We're on a POWER 8 box, > an 8286-41A. But until IBM comes up with a new name that's an improvement > over AS/400, we're sticking with that name. Just like approximately everyone else. I have even heard IBMers involved with the machines stick to AS/400, although I am sure there have been reams of internal memos printed that command them otherwise. The change to z stuck, but the change to i was a bit of a disaster. -- Will, with 3272
Re: IBM 3174 C 6.4 Microcode Disks?
On 02/15/2019 08:03 AM, Kevin Monceaux via cctalk wrote: I know, they're not called AS/400s any more. We're on a POWER 8 box, an 8286-41A. But until IBM comes up with a new name that's an improvement over AS/400, we're sticking with that name. Apple was already using the letter i, and giving the platform a single letter name makes searching for online information about the platform a challenge. I think the ""proper (yes, with (air)quotes) name is "IBM i". So it's not a single letter. But it is a collision ala "A. Pope" from National Treasure. (Yes, that scene blew my mind. Hence it's the canonical example that I use.) -- Grant. . . . unix || die
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/14/2019 9:28 PM, Kevin Monceaux via cctalk wrote: > Classic Computer Fans, > > I posted this to the IBM-Legacy-Hercules mailing list. I just realized it > probably wouldn't hurt to post it here too. > > I'm finally in possession of a box that hopefully is capable or can be made > capable of connecting a real terminal to Hercules. It's a 3174 11L. It was > retired last year where I work. I finally got the okay to save it from > being sent to a scrapper. I love the build quality of older IBM gear, > except when I'm trying to move such gear. Between the 3174 and a 9406-520 I > also acquired, I pulled or strained something in my left arm moving them > into place. > > It's currently wired to run on 220v. I think I've seen mentioned somewhere > that it can be changed to run on 110v. If that's the case, does anyone have > a pointer to documentation on what's involved? > > It has dual floppy drives. At least one drive is a 2.4MB drive. But, all > the microcode disks I have are at level B 4.6. Does anyone know where I can > get a set of C 6.4 control and control extension disks. From what I've > heard those are what's needed to enable an attached terminal to connect to > other systems via telnet. > > It has a token ring card. I will probably be able to get the MAU it was > connected to, and possibly the router that acted as a token ring to Ethernet > bridge. > > I'm not sure how much memory it has. Does anyone have any tips on > determining the amount of memory it has, and/or identifying its boards? > These are the numbers on its boards: > > 9210 > 9351 > 9052 z2 > 9053 > 9501 > > Plus the boards for coax connections. > > > I have some 3174 floppy disks, but I don't know what - they are not in my inventory. I will put it on my queue to look at them - but it may be a couple of weeks. I don't hold out much hope, but I will look.
Re: IBM 3174 C 6.4 Microcode Disks?
Jim, On Thu, Feb 14, 2019 at 11:37:34PM -0600, Jim Stefanik via cctalk wrote: > As for my system, I've got a z800 (a 2066-0A1 to be exact). Nice!! > It's got ESCON, so I've got an Optica converter box of which the model > number escapes me; but it's the replacement/alternative to the IBM Pacer > boxes. That allows bus and tag gear to connect up to ESCON channels. My 3174 was last attached to a z890, 2086-A04, via a similar ESCON converter box. Actually, they might be the same. The name Optica sounds familiar. We have five or six of them under the floor. I haven't pulled them yet, but they're on my list. Since we've downgraded to an AS/400 based platform, the powers that be want "all that old mainframe stuff" out of our computer room. Fortunately I managed to get permission to haul off as much as I can myself before they get recyclers involved. Now if I could only fit a z890 in my minivan. :-) I know, they're not called AS/400s any more. We're on a POWER 8 box, an 8286-41A. But until IBM comes up with a new name that's an improvement over AS/400, we're sticking with that name. Apple was already using the letter i, and giving the platform a single letter name makes searching for online information about the platform a challenge. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
RE: IBM 3174 C 6.4 Microcode Disks?
1) If it has a token ring card then it does not matter that it also has Bus+Tag channel card. It will still talk TCP/IP and other machines. 2) https://www.argecy.com/2389 have microcode. Al says he got some from them recently. I can copy the latest version but I am short of 2.4MB disks (and in th uk) 3) Boot up the diagnostics and utility disk. It will show the memory. There is a list of card numbers in the Maintenance Manual http://bitsavers.org/pdf/ibm/3174/SY27-2572-4_3174_1L_1R_2R_3R_11L_11R_12R_1 3R_Maintenance_May89.pdf 4) You need 2 x 2.4 or 1 x 2.4 and a hard disk for config C6. The smaller 3174's have a movable link for the PSU. No idea about the model 11 Dave (also some info on old Lordsnet site via archive.org http://web.archive.org/web/20080820002806/http://www.lordsnet.com/UsedIBM317 4Summ.htm Dave > -Original Message- > From: cctalk On Behalf Of Kevin Monceaux > via cctalk > Sent: 15 February 2019 03:29 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: IBM 3174 C 6.4 Microcode Disks? > > Classic Computer Fans, > > I posted this to the IBM-Legacy-Hercules mailing list. I just realized it > probably wouldn't hurt to post it here too. > > I'm finally in possession of a box that hopefully is capable or can be made > capable of connecting a real terminal to Hercules. It's a 3174 11L. It was > retired last year where I work. I finally got the okay to save it from being sent > to a scrapper. I love the build quality of older IBM gear, except when I'm > trying to move such gear. Between the 3174 and a 9406-520 I also acquired, I > pulled or strained something in my left arm moving them into place. > > It's currently wired to run on 220v. I think I've seen mentioned somewhere > that it can be changed to run on 110v. If that's the case, does anyone have a > pointer to documentation on what's involved? > > It has dual floppy drives. At least one drive is a 2.4MB drive. But, all the > microcode disks I have are at level B 4.6. Does anyone know where I can get > a set of C 6.4 control and control extension disks. From what I've heard those > are what's needed to enable an attached terminal to connect to other > systems via telnet. > > It has a token ring card. I will probably be able to get the MAU it was > connected to, and possibly the router that acted as a token ring to Ethernet > bridge. > > I'm not sure how much memory it has. Does anyone have any tips on > determining the amount of memory it has, and/or identifying its boards? > These are the numbers on its boards: > > 9210 > 9351 > 9052 z2 > 9053 > 9501 > > Plus the boards for coax connections. > > > > -- > > Kevin > http://www.RawFedDogs.net > http://www.Lassie.xyz > http://www.WacoAgilityGroup.org > Bruceville, TX > > What's the definition of a legacy system? One that works! > Errare humanum est, ignoscere caninum. > > > > Posted by: Kevin Monceaux > > > > > > Yahoo Groups Links > > <*> To visit your group on the web, go to: > http://groups.yahoo.com/group/ibm-legacy-hercules/ > > <*> Your email settings: > Individual Email | Traditional > > <*> To change settings online go to: > http://groups.yahoo.com/group/ibm-legacy-hercules/join > (Yahoo! ID required) > > <*> To change settings via email: > ibm-legacy-hercules-dig...@yahoogroups.com > ibm-legacy-hercules-fullfeatu...@yahoogroups.com > > <*> To unsubscribe from this group, send an email to: > ibm-legacy-hercules-unsubscr...@yahoogroups.com > > <*> Your use of Yahoo Groups is subject to: > https://info.yahoo.com/legal/us/yahoo/utos/terms/ > > > > -- > > Kevin > http://www.RawFedDogs.net > http://www.Lassie.xyz > http://www.WacoAgilityGroup.org > Bruceville, TX > > What's the definition of a legacy system? One that works! > Errare humanum est, ignoscere caninum.
Re: IBM 3174 C 6.4 Microcode Disks?
Kevin, No problem in the link. As for my system, I've got a z800 (a 2066-0A1 to be exact). It's got ESCON, so I've got an Optica converter box of which the model number escapes me; but it's the replacement/alternative to the IBM Pacer boxes. That allows bus and tag gear to connect up to ESCON channels. As for converting R to L, I'll play around with stuff. Worst case, I'll just buy an 11L and use the 11R for spares or for messing around. --- Jim Stefanik Dallas Vintage Computing Center From: Kevin Monceaux via cctalk Sent: Thursday, 14 February 2019 23:07 To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: IBM 3174 C 6.4 Microcode Disks? Jim, On Thu, Feb 14, 2019 at 10:23:30PM -0600, Jim Stefanik via cctalk wrote: > Simon Systems should be able to get you the microcode diskettes. I think > they charged me around $35 USD when I bought in Nov. 2017. Send them an > email and let them know what you need. Thanks!! I'll check with them. > On a side note, I may need to ping you off list...I've got an 11R and I'm > curious if it can be converted to an 11L, since I'd prefer to channel > attach it to my machine instead of use ethernet. Now I'm curious, as others on the list might also be. What machine do you have with bus and tag channels to connect an 11L to? Unfortunately I know nothing about converting an 11R to an 11L, or if it's even possible. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
Re: IBM 3174 C 6.4 Microcode Disks?
Jim, On Thu, Feb 14, 2019 at 10:23:30PM -0600, Jim Stefanik via cctalk wrote: > Simon Systems should be able to get you the microcode diskettes. I think > they charged me around $35 USD when I bought in Nov. 2017. Send them an > email and let them know what you need. Thanks!! I'll check with them. > On a side note, I may need to ping you off list...I've got an 11R and I'm > curious if it can be converted to an 11L, since I'd prefer to channel > attach it to my machine instead of use ethernet. Now I'm curious, as others on the list might also be. What machine do you have with bus and tag channels to connect an 11L to? Unfortunately I know nothing about converting an 11R to an 11L, or if it's even possible. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
Re: IBM 3174 C 6.4 Microcode Disks?
Grant, On Thu, Feb 14, 2019 at 08:52:25PM -0700, Grant Taylor via cctalk wrote: > Nice haul. I also acquired an RS/6000 7012-340, its 7208 8mm tape drive, and a couple of 9121 voice servers. It used to run DirectTalk/6000. > You mentioned telnet, which largely implies TCP/IP, which in combination > with Token Ring means specific things. Things which I question about > how much of a "bridge" the device was as much as a gateway. I might have the terminology wrong. I not very familiar with the token ring side of things. By the time I got into mainframe operations about twenty years ago we only had a few token ring devices left. The RS/6000 mentioned above was only connected to the token ring side of our network. It connected to the 3174 via token ring to screen scrape emulated 3270 sessions. Before the RS/6000 was shut down, I was able to telnet to it from my PC, which was on the Ethernet side of the network. The router in is the Cisco 2500 series, perhaps a 2513. I found this photo on the net, which looks like the router in question, if I remember correctly: https://kyozoufs.blob.core.windows.net/filestoragetcdb/Pictures/_30/29886/29885389.jpg As for using telnet on the 3174, I'm going by what I've seen posted on Hercules mailing lists about how others have connected real terminals to the Hercules mainframe emulator. A few pictures of such terminals connected to Hercules can be found at: http://CoreStore.org/emuterm.htm The posts I've seen say one either needs a router to act as a token ring to Ethernet bridge, or a PC with both token ring and Ethernet cards in it to act as a bridge. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
Re: IBM 3174 C 6.4 Microcode Disks?
Simon Systems should be able to get you the microcode diskettes. I think they charged me around $35 USD when I bought in Nov. 2017. Send them an email and let them know what you need. https://simonsys.com/ On a side note, I may need to ping you off list...I've got an 11R and I'm curious if it can be converted to an 11L, since I'd prefer to channel attach it to my machine instead of use ethernet. -Jim From: Kevin Monceaux via cctalk Sent: Thursday, 14 February 2019 21:28 To: General Discussion: On-Topic and Off-Topic Posts Subject: IBM 3174 C 6.4 Microcode Disks? Classic Computer Fans, I posted this to the IBM-Legacy-Hercules mailing list. I just realized it probably wouldn't hurt to post it here too. I'm finally in possession of a box that hopefully is capable or can be made capable of connecting a real terminal to Hercules. It's a 3174 11L. It was retired last year where I work. I finally got the okay to save it from being sent to a scrapper. I love the build quality of older IBM gear, except when I'm trying to move such gear. Between the 3174 and a 9406-520 I also acquired, I pulled or strained something in my left arm moving them into place. It's currently wired to run on 220v. I think I've seen mentioned somewhere that it can be changed to run on 110v. If that's the case, does anyone have a pointer to documentation on what's involved? It has dual floppy drives. At least one drive is a 2.4MB drive. But, all the microcode disks I have are at level B 4.6. Does anyone know where I can get a set of C 6.4 control and control extension disks. From what I've heard those are what's needed to enable an attached terminal to connect to other systems via telnet. It has a token ring card. I will probably be able to get the MAU it was connected to, and possibly the router that acted as a token ring to Ethernet bridge. I'm not sure how much memory it has. Does anyone have any tips on determining the amount of memory it has, and/or identifying its boards? These are the numbers on its boards: 9210 9351 9052 z2 9053 9501 Plus the boards for coax connections. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. Posted by: Kevin Monceaux Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/ibm-legacy-hercules/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/ibm-legacy-hercules/join (Yahoo! ID required) <*> To change settings via email: ibm-legacy-hercules-dig...@yahoogroups.com ibm-legacy-hercules-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: ibm-legacy-hercules-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/ -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
Re: IBM 3174 C 6.4 Microcode Disks?
On 2/14/19 8:28 PM, Kevin Monceaux via cctalk wrote: I'm finally in possession of a box that hopefully is capable or can be made capable of connecting a real terminal to Hercules. It's a 3174 11L. It was retired last year where I work. I finally got the okay to save it from being sent to a scrapper. I love the build quality of older IBM gear, except when I'm trying to move such gear. Between the 3174 and a 9406-520 I also acquired, I pulled or strained something in my left arm moving them into place. Nice haul. It has a token ring card. I will probably be able to get the MAU it was connected to, and possibly the router that acted as a token ring to Ethernet bridge. I'm quite interested in the network configuration. You mentioned telnet, which largely implies TCP/IP, which in combination with Token Ring means specific things. Things which I question about how much of a "bridge" the device was as much as a gateway. Or, if it's telnet like, but not actually telnet ~> TCP/IP, then it could be other things, but I think they are more problematic to "bridge" to Ethernet. -- Grant. . . . unix || die