Grant, On Thu, Feb 14, 2019 at 08:52:25PM -0700, Grant Taylor 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 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/2… 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.

Grant, On Sat, Feb 16, 2019 at 07:36:11PM -0700, Grant Taylor 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. 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. 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_an… 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.

Grant, On Sat, Feb 16, 2019 at 11:05:23PM -0700, Grant Taylor via cctalk wrote: 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.

On 2/17/19 2:23 AM, Dave Wade wrote: 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. The reading that I did last night agrees with that. But I don't see how that's germane to this discussion. 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. 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. 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. 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 commenting about above. Also, I would expect a 3174 with Ethernet to similarly be able to connect a 3270 terminal to Hercules running on a PC via Ethernet. Yep. As with all things mainframe related, it's complex and there are a lot of options. The trick is finding the options that will work in the various constraints. NAT on the 2500 series Cisco is decidedly routing and not bridging. :-) ~chuckle~ -- Grant. . . . unix || die

On 2/18/19 1:20 AM, Dave Wade via cctalk wrote: Okay. So I misunderstood ~> misspoke about the protocol on the coax side of the 3174. 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. ACK 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.) 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? 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. 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.) "too involved" is critical. ~chuckle~ Very little about IBM is simple. 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_Netw… The downstream 3174-13R can talk to either the upstream 3174-11L or the 3172. Figure 244 on page 259 shows the same. 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. I agree to your prior comment that this traffic between the terminals and the 3174 terminal controller is not 3270. Some of the documents that I've looked at this week have explicitly shown a routed TCP/IP network between the upstream / host 3174 and the downstream 3174. I've lost track of what document you're referencing. I don't see anything like the following on (file) page 39 and page (number) 39 is a source code listing. I'll agree that the RS/6000 may be using SNA on 802.2 LLC SNAP frames directly and not using TCP/IP. Hum.... Normal telnet traffic most certainly does terminate on the 3174 when it's being used as a gateway for 3270 / CUT terminals to Telnet sessions on other systems, like the RS/6000. But that's not what we've been discussing. LU6.2 doesn't translate to what a network sniffer would show things as, which is what I'm trying to determine. I've gathered that it's 802.2 LLC SNAP frames. Which work perfectly fine on both Ethernet and Token Ring. As such, they can also be bridged between the two. I get the impression that "normal" is highly subjective. Especially with later firmware on 3174s. ACK Agreed. I think I'm talking about things on the odder end of the spectrum. -- Grant. . . . unix || die

On 02/21/2019 04:02 AM, Dave Wade wrote: Okay. I'll have to ponder this. Okay. I'm starting to see a pattern as I re-read your email, pontificate, and reply. 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. ~chuckle~ ;-) I'm starting to get the impression that the tables are even larger than I might have originally suspected. 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? 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? 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. 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 know of LU type 6.2, but not much else about them. 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 think we're having semantical differences. The 3174 is one of the endpoints of the established TCP connection. Bidirectional traffic for an established TN3270 session going from the 3174 terminates on the RS/6000 and traffic going from the RS/6000 terminates on the 3174. ACK IMHO "cheap" and "IBM" don't belong in the same phrase. Thank you for your input Dave. -- Grant. . . . unix || die

On 03/05/2019 02:18 PM, Kevin Monceaux via cctalk wrote: 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

Mine isn't up at the moment, but I have had it running via Token Ring.... Dave

It was thus said that the Great Kevin Monceaux via cctalk once stated: 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

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 <cctalk at classiccmp.org> 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: Thanks!!? I'll check with them. 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.

On 02/15/2019 08:03 AM, Kevin Monceaux via cctalk wrote: 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

On Fri, 15 Feb 2019 at 19:27, Paul Berger via cctalk <cctalk at classiccmp.org> wrote: 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: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053

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 at classiccmp.org> wrote:

On 02/15/2019 02:43 PM, Cameron Kaiser via cctalk wrote: 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

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 <cctech at classiccmp.org> Sent: Monday, 18 February 2019 15:48 To: cctech at classiccmp.org Subject: Re: IBM 3174 C 6.4 Microcode Disks? On 2/15/2019 10:22 AM, Jay Jaeger via cctech 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. 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)

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: