Re: SMPE UPGRADE Command
>If you plan to continue to use SMP/E 36.105 or higher when processing >the subject target and dlib zone, then it is perfectly safe to use the >UPGRADE command. Thanks Kurt, for confirming that it should not be a problem. In the meantime I found out that IBM had ordered V24 for us *without* asking for our z/OS level, which is 2.3, all on the strength of us having bought V2. This might explain the discrepancy with the SMPE level. I am now waiting for the software version that fits our z/OS version and see what happens with the apply. The biggest problem is that there is no good documentation coming with the CBPDO. I seem to remember that the program directory contained the software prerequisites, i.e. the z/OS level fitting the product. Was unable to find that, though. >Chuck Norris never uses CHECK when he applies PTFs. Is he a z/OS champion?!? :-) Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
I didn't think of TN3270 as an intermediate step so far. I cannot really assess how much value that brings for the end goal, though it might be at least fun and educational. Thanks for the insights, especially 3270.pdf seems very interesting. On Tue, Jan 14, 2020 at 07:23:55AM -0800, Charles Mills wrote: > Would talking the TN3270 protocol to a 3270 emulator do the job for you? > That solves all of the hardware issues: it is simply TCP out of your > implementation and into the emulator. > > You could then if you wished "graduate" to a real 3270 terminal. If I were > doing it I would go SNA but that is because once upon a time I knew SNA at > the bit level, but little about how bus & tag worked at that level. > > I can't speak much to physical connection or the layer immediately above > that but this book http://ruelgnoj.co.uk/3270/3270.pdf is the bible of the > byte stream going to the device. > > There is no real reason you could not drive one from Linux or Windows. A > Raspberry Pi with a 3270 attached would be an amusing idea. > > BTW, RS232 is a specification for the plug between a device and a modem. It > is at a lower level in the stack than most of the other things you mention. > Yes, it would be relevant to a dial-up SNA implementation. The "bits going > over the modem" layer of SNA is called SDLC > (https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control). > > Good luck! Sounds like fun. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Alexander Huemer > Sent: Tuesday, January 14, 2020 1:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Talking to 3270 terminals? > > Hi > > I am new to this list and would like to discuss an idea and ask several > questions. > > * Did anybody ever attempt to 'talk' to 3270 terminals with something > different than an IBM mainframe? > > This might sound like a strange idea, though I find it intriguing to be > able to display content on such a terminal and be able to receive > keyboard input from it. > > I guess the most straight-forward way to attempt something like that is > to use a 3270 terminal attached to a 3174 or similar and try to talk to > that instead of the terminal itself. I wouldn't know how to interface > with the terminal directly over the coax. > > * What's the best available documentation regarding 3174 models and > their features? > > I poked around on ibm.com and google but wasn't able to find much. It > seems like there were several different physical-layer north-bound > interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not > mistaken, for dial-up connections), maybe others? > > Bus&Tag doesn't seem to be a good candidate, it's difficult to interface > with as far as I understand. > Ethernet is way more common these days than Token Ring, though TR NICs > are easy to procure second hand and protocol support under Linux (the OS > I am most savvy with) is in place. > RS232 is easy to interface with also, though then again, I am not sure > if that interface really exists. > > * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3 or > was there by any chance something going on with TCP/IP? I doubt it > though. > > Talking SNA with custom software doesn't seem to be a low-hanging fruit. > From where I stand right now I cannot say how straight-forward the > network traffic between the mainframe and a 3174 is, how difficult it > would be to emulate that protocol with custom software over several > layers. > > * Is anybody on the list here able to provide protocol traces from the > link between mainframe and 3174 over any interface? pcap format is > preferred, though anything would be valuable. > > I would appreciate any thoughts regarding this topic, especially to the > questions marked with asterisks. > Also, if anything is known regarding a similar thing with 5250 instead > of 3170 terminals, that would be interesting as well. > > -Alex > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
I read through the thread. Not sure I fully understand what is happening over there. Will read again. On Tue, Jan 14, 2020 at 11:44:46AM -0600, Mike Schwab wrote: > https://turnkey-mvs.yahoogroups.narkive.com/YoMvjj8Q/turnkey-mvs-under-vm-and-3270-w-3174 > 3174 with ethernet and token ring. Hercules on PC connected to > ethernet. Apple II with token ring as console. > > On Tue, Jan 14, 2020 at 9:24 AM Charles Mills wrote: > > > > Would talking the TN3270 protocol to a 3270 emulator do the job for you? > > That solves all of the hardware issues: it is simply TCP out of your > > implementation and into the emulator. > > > > You could then if you wished "graduate" to a real 3270 terminal. If I were > > doing it I would go SNA but that is because once upon a time I knew SNA at > > the bit level, but little about how bus & tag worked at that level. > > > > I can't speak much to physical connection or the layer immediately above > > that but this book http://ruelgnoj.co.uk/3270/3270.pdf is the bible of the > > byte stream going to the device. > > > > There is no real reason you could not drive one from Linux or Windows. A > > Raspberry Pi with a 3270 attached would be an amusing idea. > > > > BTW, RS232 is a specification for the plug between a device and a modem. It > > is at a lower level in the stack than most of the other things you mention. > > Yes, it would be relevant to a dial-up SNA implementation. The "bits going > > over the modem" layer of SNA is called SDLC > > (https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control). > > > > Good luck! Sounds like fun. > > > > Charles > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Alexander Huemer > > Sent: Tuesday, January 14, 2020 1:52 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Talking to 3270 terminals? > > > > Hi > > > > I am new to this list and would like to discuss an idea and ask several > > questions. > > > > * Did anybody ever attempt to 'talk' to 3270 terminals with something > > different than an IBM mainframe? > > > > This might sound like a strange idea, though I find it intriguing to be > > able to display content on such a terminal and be able to receive > > keyboard input from it. > > > > I guess the most straight-forward way to attempt something like that is > > to use a 3270 terminal attached to a 3174 or similar and try to talk to > > that instead of the terminal itself. I wouldn't know how to interface > > with the terminal directly over the coax. > > > > * What's the best available documentation regarding 3174 models and > > their features? > > > > I poked around on ibm.com and google but wasn't able to find much. It > > seems like there were several different physical-layer north-bound > > interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not > > mistaken, for dial-up connections), maybe others? > > > > Bus&Tag doesn't seem to be a good candidate, it's difficult to interface > > with as far as I understand. > > Ethernet is way more common these days than Token Ring, though TR NICs > > are easy to procure second hand and protocol support under Linux (the OS > > I am most savvy with) is in place. > > RS232 is easy to interface with also, though then again, I am not sure > > if that interface really exists. > > > > * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3 or > > was there by any chance something going on with TCP/IP? I doubt it > > though. > > > > Talking SNA with custom software doesn't seem to be a low-hanging fruit. > > From where I stand right now I cannot say how straight-forward the > > network traffic between the mainframe and a 3174 is, how difficult it > > would be to emulate that protocol with custom software over several > > layers. > > > > * Is anybody on the list here able to provide protocol traces from the > > link between mainframe and 3174 over any interface? pcap format is > > preferred, though anything would be valuable. > > > > I would appreciate any thoughts regarding this topic, especially to the > > questions marked with asterisks. > > Also, if anything is known regarding a similar thing with 5250 instead > > of 3170 terminals, that would be interesting as well. > > > > -Alex > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua
Re: Talking to 3270 terminals?
Well, I guess the proposal was to write a piece of software that a TN3270 client connects to and is able to exchange data with it. I think that's a neat idea, especially as that removes the dependency on ancient hardware that I don't currently have. You say TN3270 merely encapsulates 3270, which makes this a good idea AFAICS. On Tue, Jan 14, 2020 at 07:46:44PM +, Seymour J Metz wrote: > You don't talk TN3270 to an emulator; all of the 3270 simulation is in the > TN3270 client. Tn3270 just encapsulates 3270 data streams and associated > housekeeping. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of > Charles Mills > Sent: Tuesday, January 14, 2020 10:23 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Talking to 3270 terminals? > > Would talking the TN3270 protocol to a 3270 emulator do the job for you? > That solves all of the hardware issues: it is simply TCP out of your > implementation and into the emulator. > > You could then if you wished "graduate" to a real 3270 terminal. If I were > doing it I would go SNA but that is because once upon a time I knew SNA at > the bit level, but little about how bus & tag worked at that level. > > I can't speak much to physical connection or the layer immediately above > that but this book > http://secure-web.cisco.com/1NJfAPk9CmbKpO7wNkHn9B6nE4DIuDh8VjmoRD6W14LTnkYRS8mUF9pSaMLpoFNQw1X7bKTufSQxpDFbxWiK_GJYC4fCTMeYoNXrWdY006d3QvNX5gwLKr_Tddhqv6hARKpUa2Ww_M-j3EtEtqgNXVwwhqxhBwkNHfbHZNfctAXcxWr7RaxxyYllBigY0HWHt1hks74ObW0Emd3pHjWjCQHpzxYI6aytGZbSKExfPlNvoHUHfwOnPOHU_wmz_J3R0OqSaVHen3cuw0dZztcIwamLWVnT8OOQTiI77EDcb1tWEj5cBj7OzyBwA6w6iZON7Ri3ukxOmPLHqij2zcSk4cUnQ_K-sX-tj8NSLSBvFxasoFny16vytF4hNgcCM-jBg6miye3bvKK4X5b8TCMWs7yI2ByD6-70MEZGk2McpqNsWtMdhCMLw_4RLIurdIAR8/http%3A%2F%2Fruelgnoj.co.uk%2F3270%2F3270.pdf > is the bible of the > byte stream going to the device. > > There is no real reason you could not drive one from Linux or Windows. A > Raspberry Pi with a 3270 attached would be an amusing idea. > > BTW, RS232 is a specification for the plug between a device and a modem. It > is at a lower level in the stack than most of the other things you mention. > Yes, it would be relevant to a dial-up SNA implementation. The "bits going > over the modem" layer of SNA is called SDLC > (https://secure-web.cisco.com/18c0BA4dtXGJ3jrmHxOb0fQfMOn7KsS3MCPwA3S8XLeEpnbvImAU6lrPFliVgZUwfdITCv2vD8QAyQIst3e9t4oQBI5fw6kn3Z5zvTgtodVYMWXfgRrZ_rDOHCTuoC9voavt2oVRuk2rXTFzrTcGuqP2njC-JbLJOzNAFUOz_790kOT5eusVJPhfplzNyOqiC-BBSmblQkv6CG1UkI3YxnfLa6Bh_I3qU4A1_sCKjFd31oN7FM6cohvAz-j8TsK3jjrajkQ4gi3GT8bcI4tjYJ4-8v0X7FsTJ9-lesmTEaWHX0JEhBPROGC5-Psii1-zu50IIMKHtMOJ68yp_bmrKiDcLeI-jUnK_rg6t38XQ7mp3DWnrpndTasniJpzPJ4yk1XewnqlxgXQ_oMJ423_1em3a2ThaJg9sIN_pZIMYnHPGn7lUOGfPv6DNpk7G8fpp/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSynchronous_Data_Link_Control%29. > > Good luck! Sounds like fun. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Alexander Huemer > Sent: Tuesday, January 14, 2020 1:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Talking to 3270 terminals? > > Hi > > I am new to this list and would like to discuss an idea and ask several > questions. > > * Did anybody ever attempt to 'talk' to 3270 terminals with something > different than an IBM mainframe? > > This might sound like a strange idea, though I find it intriguing to be > able to display content on such a terminal and be able to receive > keyboard input from it. > > I guess the most straight-forward way to attempt something like that is > to use a 3270 terminal attached to a 3174 or similar and try to talk to > that instead of the terminal itself. I wouldn't know how to interface > with the terminal directly over the coax. > > * What's the best available documentation regarding 3174 models and > their features? > > I poked around on ibm.com and google but wasn't able to find much. It > seems like there were several different physical-layer north-bound > interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not > mistaken, for dial-up connections), maybe others? > > Bus&Tag doesn't seem to be a good candidate, it's difficult to interface > with as far as I understand. > Ethernet is way more common these days than Token Ring, though TR NICs > are easy to procure second hand and protocol support under Linux (the OS > I am most savvy with) is in place. > RS232 is easy to interface with also, though then again, I am not sure > if that interface really exists. > > * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3 or > was there by any chance something going on with TCP/IP? I doubt it > though. > > Talking SNA with custom software doesn't seem to be a low-hanging fruit. > From where I stand right now I cannot say how straight-forward the > network traffic between the mainframe a
Re: Talking to 3270 terminals?
I am aware RS232 is just a low-level protocol, though, if I decide to really spend time on this, I have to interface with a 3174 somehow, low-level. And I wonder which options I have for that, regardless of the higher protocol layer. I am not questioning that they have to be figured out. What is bitsavers? On Tue, Jan 14, 2020 at 07:59:49PM +, Seymour J Metz wrote: > An interface to 3270 displays would be useful only if you had software that > supported 3270 on your platform. Further, is there a real 3270 that is less > expensive than running, e.g., TN3270, on a desktop? > > RS-232-C is just a protocol between a serial adapter and a modem; it doesn't > specify, e.g., control characters, packets, going between the modems. B&T, > Ethernet and TR all specify controls at a higher level. > > Your best resource for 3270 information is probably bitsavers. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of > Alexander Huemer > Sent: Tuesday, January 14, 2020 4:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Talking to 3270 terminals? > > Hi > > I am new to this list and would like to discuss an idea and ask several > questions. > > * Did anybody ever attempt to 'talk' to 3270 terminals with something > different than an IBM mainframe? > > This might sound like a strange idea, though I find it intriguing to be > able to display content on such a terminal and be able to receive > keyboard input from it. > > I guess the most straight-forward way to attempt something like that is > to use a 3270 terminal attached to a 3174 or similar and try to talk to > that instead of the terminal itself. I wouldn't know how to interface > with the terminal directly over the coax. > > * What's the best available documentation regarding 3174 models and > their features? > > I poked around on ibm.com and google but wasn't able to find much. It > seems like there were several different physical-layer north-bound > interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not > mistaken, for dial-up connections), maybe others? > > Bus&Tag doesn't seem to be a good candidate, it's difficult to interface > with as far as I understand. > Ethernet is way more common these days than Token Ring, though TR NICs > are easy to procure second hand and protocol support under Linux (the OS > I am most savvy with) is in place. > RS232 is easy to interface with also, though then again, I am not sure > if that interface really exists. > > * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3 or > was there by any chance something going on with TCP/IP? I doubt it > though. > > Talking SNA with custom software doesn't seem to be a low-hanging fruit. > From where I stand right now I cannot say how straight-forward the > network traffic between the mainframe and a 3174 is, how difficult it > would be to emulate that protocol with custom software over several > layers. > > * Is anybody on the list here able to provide protocol traces from the > link between mainframe and 3174 over any interface? pcap format is > preferred, though anything would be valuable. > > I would appreciate any thoughts regarding this topic, especially to the > questions marked with asterisks. > Also, if anything is known regarding a similar thing with 5250 instead > of 3170 terminals, that would be interesting as well. > > -Alex > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
I am aware of hercules, an amazing piece of software. Though I am more looking for a dedicated piece of software just to talk to terminals, not as part of a S3*0 OS. > I think I've recently read some articles where someone is trying to > use a 3270 as a terminal for a Unix (Linux?) workstation. If you could provide a pointer to that, that would be much appreciated! > I think I've recently read some articles where someone is trying to > use a 3270 as a terminal for a Unix (Linux?) workstation. Even more stunning. I am eager to read more. > I think I've recently read some articles where someone is trying to > use a 3270 as a terminal for a Unix (Linux?) workstation. Possible, I didn't check. Though running Linux kernels from the 3.x era isn't what I would consider painful. > SNA is decidedly NOT TCP/IP. That's well understood. I just wondered whether they might have been a communication scheme between an 3174 and a mainframe over Ethernet or Token Ring that used TCP/IP instead of SNA. But again, I doubt it. Thanks for your thoughts. I will consider spamming the hercules mailinglist also. On Tue, Jan 14, 2020 at 06:07:19PM -0700, Grant Taylor wrote: > On 1/14/20 2:52 AM, Alexander Huemer wrote: > > Hi > > Hi, > > > I am new to this list and would like to discuss an idea and ask several > > questions. > > Welcome. > > > * Did anybody ever attempt to 'talk' to 3270 terminals with something > > different than an IBM mainframe? > > Yes* > > * because it's highly dependent on what you mean by "IBM mainframe". More > specifically if you mean the hardware and / or the software. > > I know that there are people actively working in the Hercules community to > drive (talk to) 3270 terminals. > > I think I've recently read some articles where someone is trying to use a > 3270 as a terminal for a Unix (Linux?) workstation. > > So, "It depends" > > > This might sound like a strange idea, though I find it intriguing to be > > able to display content on such a terminal and be able to receive > > keyboard input from it. > > It doesn't sound completely crazy to me. It does some completely atypical. > But atypical can be entertaining and / or educational. > > > I guess the most straight-forward way to attempt something like that is > > to use a 3270 terminal attached to a 3174 or similar and try to talk to > > that instead of the terminal itself. I wouldn't know how to interface > > with the terminal directly over the coax. > > I believe the article I recently read was talking about driving the signal > on the coax. > > I typically see some variation of the following discussed: > > 1) 3270 terminal talks to the (remote) 3174 Control Unit (?). > 2) The remote 3174 CU talks across Ethernet or Token Ring or RS-232 > something else acting like a local 3174 CU. > 3) This thing acting like a local 3174 usually talks TN3270 to a mainframe > OS, be it running on a physical mainframe or emulated. > > I believe that some later / feature rich 3174s have the ability to act like > primitive telnet clients. Thus you could use the 3270 to talk to a Unix > box. > > > * What's the best available documentation regarding 3174 models and > > their features? > > I don't know. > > I've seen quite informative discussions about this type of thing on the > hercules-390 and cctalk mailing lists, plus a few newsgroups. > > > I poked around on ibm.com and google but wasn't able to find much. It > > seems like there were several different physical-layer north-bound > > interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not > > mistaken, for dial-up connections), maybe others? > > I think it's highly dependent on if it's the "local" or "remote" 3174. > > I think that the "local" 3174 was exclusively Bus & Tag for northbound. — > I've not heard of any ESCON interfaces for 3174. — The Token Ring / > Ethernet / SDLC / RS-232 was southbound to talk to "remote" 3174s. > > Similarly, the "remote" 3174 was Token Ring / Ethernet / SDLC / RS-232 for > northbound and coax for southbound. > > The Token Ring / Ethernet / SDLC / RS-232 was used to connect "local" and > "remote" 3174s. > > > Bus&Tag doesn't seem to be a good candidate, it's difficult to interface > > with as far as I understand. > > Two things come to mind to interface with B&T. The B&T cards that exist for > PCs running things like the PC/370 / P/390(-E) or something like a big iron > Cisco router with a Channel Interface Processor card. But I think even the > CIP is a "grey" downstream device and can't pretend to be a "black" host > (mainframe) device. > > > Ethernet is way more common these days than Token Ring, though TR NICs > > are easy to procure second hand > > Agreed. > > > protocol support under Linux (the OS I am most savvy with) is in place. > > Be careful there. Contemporary Linux (4.x) no longer includes Token Ring > support. I believe it was removed from 3.5. > > Even then, there are other protocols that I've
Re: Talking to 3270 terminals?
But a couple of minutes earlier you said: > Well, I guess the proposal was to write a piece of software that a > TN3270 client connects to and is able to exchange data with it. Do you really have a 3174? Do you have a real IBM terminal? Or another way to ask: If you created such a program, what would you be typing on when you work with the program? I think Shmuel is talking about https://archive.org/details/bitsavers And I just noticed my old web bookmark to the 3270 Programmer's Reference is now gone! I guess I need to keep my 1990 printed manual which covered in notes and marks and sticky notes :) On 1/15/2020 8:01 AM, Alexander Huemer wrote: I am aware RS232 is just a low-level protocol, though, if I decide to really spend time on this, I have to interface with a 3174 somehow, low-level. And I wonder which options I have for that, regardless of the higher protocol layer. I am not questioning that they have to be figured out. What is bitsavers? On Tue, Jan 14, 2020 at 07:59:49PM +, Seymour J Metz wrote: An interface to 3270 displays would be useful only if you had software that supported 3270 on your platform. Further, is there a real 3270 that is less expensive than running, e.g., TN3270, on a desktop? RS-232-C is just a protocol between a serial adapter and a modem; it doesn't specify, e.g., control characters, packets, going between the modems. B&T, Ethernet and TR all specify controls at a higher level. Your best resource for 3270 information is probably bitsavers. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Alexander Huemer Sent: Tuesday, January 14, 2020 4:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Talking to 3270 terminals? Hi I am new to this list and would like to discuss an idea and ask several questions. * Did anybody ever attempt to 'talk' to 3270 terminals with something different than an IBM mainframe? This might sound like a strange idea, though I find it intriguing to be able to display content on such a terminal and be able to receive keyboard input from it. I guess the most straight-forward way to attempt something like that is to use a 3270 terminal attached to a 3174 or similar and try to talk to that instead of the terminal itself. I wouldn't know how to interface with the terminal directly over the coax. * What's the best available documentation regarding 3174 models and their features? I poked around on ibm.com and google but wasn't able to find much. It seems like there were several different physical-layer north-bound interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not mistaken, for dial-up connections), maybe others? Bus&Tag doesn't seem to be a good candidate, it's difficult to interface with as far as I understand. Ethernet is way more common these days than Token Ring, though TR NICs are easy to procure second hand and protocol support under Linux (the OS I am most savvy with) is in place. RS232 is easy to interface with also, though then again, I am not sure if that interface really exists. * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3 or was there by any chance something going on with TCP/IP? I doubt it though. Talking SNA with custom software doesn't seem to be a low-hanging fruit. From where I stand right now I cannot say how straight-forward the network traffic between the mainframe and a 3174 is, how difficult it would be to emulate that protocol with custom software over several layers. * Is anybody on the list here able to provide protocol traces from the link between mainframe and 3174 over any interface? pcap format is preferred, though anything would be valuable. I would appreciate any thoughts regarding this topic, especially to the questions marked with asterisks. Also, if anything is known regarding a similar thing with 5250 instead of 3170 terminals, that would be interesting as well. -Alex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
On Wed, 15 Jan 2020 08:29:38 -0800, Tom Brennan wrote: >I think Shmuel is talking about https://archive.org/details/bitsavers I think he meant http://bitsavers.trailing-edge.com/ or http://bitsavers.trailing-edge.com/pdf/ibm/ or http://bitsavers.trailing-edge.com/pdf/ibm/360/ or http://bitsavers.trailing-edge.com/pdf/ibm/370/ or, perhaps more specific to the OP's question, http://bitsavers.trailing-edge.com/pdf/ibm/360/ -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
On Wed, 15 Jan 2020 10:48:26 -0600, Tom Marchant wrote: >or, perhaps more specific to the OP's question, >http://bitsavers.trailing-edge.com/pdf/ibm/360/ Oops. I meant http://bitsavers.trailing-edge.com/pdf/ibm/3270/ -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
You are misunderstanding. My concern, and I admit its a small one, is about those programs that were tested prior to the version upgrade but implemented after the version upgrade. Meaning they were tested having been compiled with V6.2, but compiled for implementation using V6.3. It's a short window where that would happen, so probably not worth fretting about. From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, January 14, 2020 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release I think we are getting into "how many compiler developers can dance on the head of a pin?" territory here. I stand by my original answer: - Yes, be prudent. There are old sysprogs and there are bold sysprogs but there are no old, bold sysprogs. - I would be surprised if there were any reasons why having 6.3 installed would affect how 6.2-compiled programs would run. I would be really surprised if such reasons existed and they could not be quickly fixed by APAR and PTF. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, January 14, 2020 1:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release I disagree with that. A new version may simply be new features, none affecting any features the old version supported. From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, January 14, 2020 2:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release > My question has to do with the (probably slight) possibility that the code generated by one compiler would be different, for the same statement, for another. It certainly would. If the code generated for every statement was the same for both compilers, then there would be no difference between the two. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, January 14, 2020 11:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release I understand that the runtime is part of LE, and is generally shared between versions (at least V5 and V6 seem to share the same runtime for many/most functions). Conceivably it's still possible that the code generated by a certain version of a compiler may have defects. Probably less likely if the code is in a pre-existing feature. My question has to do with the (probably slight) possibility that the code generated by one compiler would be different, for the same statement, for another. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
I was just stating what a theoretical new version of a theoretical compiler might provide. In the specific case of E.C. 6.3 you are certainly correct. Of course there is no requirement to change ARCH level upon implementation of a new version, even if you're at that necessary hardware level. From: IBM Mainframe Discussion List on behalf of Clark Morris Sent: Tuesday, January 14, 2020 4:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release [Default] On 14 Jan 2020 13:58:34 -0800, in bit.listserv.ibm-main frank.swarbr...@outlook.com (Frank Swarbrick) wrote: >I disagree with that. A new version may simply be new features, none >affecting any features the old version supported. The 6.3 compiler supports a new ARCH level for the z15 and uses SIMD instructions rather that the selected conversion to floating point decimal for some calculations. Both code sequences are an enhancement over using standard packed decimal instructions. Clark Morris > > >From: IBM Mainframe Discussion List on behalf of >Charles Mills >Sent: Tuesday, January 14, 2020 2:09 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Migrating to new compiler release > >> My question has to do with the (probably slight) possibility that the code >generated by one compiler would be different, for the same statement, for >another. > >It certainly would. If the code generated for every statement was the same >for both compilers, then there would be no difference between the two. > >Charles > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Frank Swarbrick >Sent: Tuesday, January 14, 2020 11:37 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Migrating to new compiler release > >I understand that the runtime is part of LE, and is generally shared between >versions (at least V5 and V6 seem to share the same runtime for many/most >functions). Conceivably it's still possible that the code generated by a >certain version of a compiler may have defects. Probably less likely if the >code is in a pre-existing feature. > >My question has to do with the (probably slight) possibility that the code >generated by one compiler would be different, for the same statement, for >another. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
Bitsavers.org is a "wiki" site with scans of out-of-print tech manuals. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Alexander Huemer Sent: Wednesday, January 15, 2020 8:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? I am aware RS232 is just a low-level protocol, though, if I decide to really spend time on this, I have to interface with a 3174 somehow, low-level. And I wonder which options I have for that, regardless of the higher protocol layer. I am not questioning that they have to be figured out. What is bitsavers? On Tue, Jan 14, 2020 at 07:59:49PM +, Seymour J Metz wrote: > An interface to 3270 displays would be useful only if you had software that supported 3270 on your platform. Further, is there a real 3270 that is less expensive than running, e.g., TN3270, on a desktop? > > RS-232-C is just a protocol between a serial adapter and a modem; it doesn't specify, e.g., control characters, packets, going between the modems. B&T, Ethernet and TR all specify controls at a higher level. > > Your best resource for 3270 information is probably bitsavers. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of Alexander Huemer > Sent: Tuesday, January 14, 2020 4:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Talking to 3270 terminals? > > Hi > > I am new to this list and would like to discuss an idea and ask several > questions. > > * Did anybody ever attempt to 'talk' to 3270 terminals with something > different than an IBM mainframe? > > This might sound like a strange idea, though I find it intriguing to be > able to display content on such a terminal and be able to receive > keyboard input from it. > > I guess the most straight-forward way to attempt something like that is > to use a 3270 terminal attached to a 3174 or similar and try to talk to > that instead of the terminal itself. I wouldn't know how to interface > with the terminal directly over the coax. > > * What's the best available documentation regarding 3174 models and > their features? > > I poked around on ibm.com and google but wasn't able to find much. It > seems like there were several different physical-layer north-bound > interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not > mistaken, for dial-up connections), maybe others? > > Bus&Tag doesn't seem to be a good candidate, it's difficult to interface > with as far as I understand. > Ethernet is way more common these days than Token Ring, though TR NICs > are easy to procure second hand and protocol support under Linux (the OS > I am most savvy with) is in place. > RS232 is easy to interface with also, though then again, I am not sure > if that interface really exists. > > * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3 or > was there by any chance something going on with TCP/IP? I doubt it > though. > > Talking SNA with custom software doesn't seem to be a low-hanging fruit. > From where I stand right now I cannot say how straight-forward the > network traffic between the mainframe and a 3174 is, how difficult it > would be to emulate that protocol with custom software over several > layers. > > * Is anybody on the list here able to provide protocol traces from the > link between mainframe and 3174 over any interface? pcap format is > preferred, though anything would be valuable. > > I would appreciate any thoughts regarding this topic, especially to the > questions marked with asterisks. > Also, if anything is known regarding a similar thing with 5250 instead > of 3170 terminals, that would be interesting as well. > > -Alex > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Tape problem
Anyone ever run into a problem where the CA-1 catalog and the volcat seem to be out of sync? We keep getting the below messages and aren’t able to eject tapes. Thought it was 3494 hardware related by IBM doesn’t thing so. Any suggestions? CBR3770I Volume T00xxx misplaced in library TAPELIB1 CBR3769I Misplaced volume T00xxx found in library TAPELIB1 Dean Nai > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
Seems to me your problem is recompiling after testing. If you want to avoid problems that re-compiling could introduce, then don't. sas On Wed, Jan 15, 2020 at 11:59 AM Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > I was just stating what a theoretical new version of a theoretical > compiler might provide. In the specific case of E.C. 6.3 you are certainly > correct. Of course there is no requirement to change ARCH level upon > implementation of a new version, even if you're at that necessary hardware > level. > > > From: IBM Mainframe Discussion List on behalf > of Clark Morris > Sent: Tuesday, January 14, 2020 4:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > [Default] On 14 Jan 2020 13:58:34 -0800, in bit.listserv.ibm-main > frank.swarbr...@outlook.com (Frank Swarbrick) wrote: > > >I disagree with that. A new version may simply be new features, none > affecting any features the old version supported. > > The 6.3 compiler supports a new ARCH level for the z15 and uses SIMD > instructions rather that the selected conversion to floating point > decimal for some calculations. Both code sequences are an enhancement > over using standard packed decimal instructions. > > Clark Morris > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tape problem
Are you using IBM VTS, emc vts, other tape appliance I have found the CA 1 Support team to be very helpful. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nai, Dean Sent: Wednesday, January 15, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Tape problem Anyone ever run into a problem where the CA-1 catalog and the volcat seem to be out of sync? We keep getting the below messages and aren’t able to eject tapes. Thought it was 3494 hardware related by IBM doesn’t thing so. Any suggestions? CBR3770I Volume T00xxx misplaced in library TAPELIB1 CBR3769I Misplaced volume T00xxx found in library TAPELIB1 Dean Nai > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
That doesn't fit in to our current processes. We migrate source code, not executables. I guess we could consider changing that, but this is small enough an issue. From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Wednesday, January 15, 2020 10:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release Seems to me your problem is recompiling after testing. If you want to avoid problems that re-compiling could introduce, then don't. sas On Wed, Jan 15, 2020 at 11:59 AM Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > I was just stating what a theoretical new version of a theoretical > compiler might provide. In the specific case of E.C. 6.3 you are certainly > correct. Of course there is no requirement to change ARCH level upon > implementation of a new version, even if you're at that necessary hardware > level. > > > From: IBM Mainframe Discussion List on behalf > of Clark Morris > Sent: Tuesday, January 14, 2020 4:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > [Default] On 14 Jan 2020 13:58:34 -0800, in bit.listserv.ibm-main > frank.swarbr...@outlook.com (Frank Swarbrick) wrote: > > >I disagree with that. A new version may simply be new features, none > affecting any features the old version supported. > > The 6.3 compiler supports a new ARCH level for the z15 and uses SIMD > instructions rather that the selected conversion to floating point > decimal for some calculations. Both code sequences are an enhancement > over using standard packed decimal instructions. > > Clark Morris > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
Any difference should be documented in the migration guides I would think. On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick wrote: > I understand that the runtime is part of LE, and is generally shared > between versions (at least V5 and V6 seem to share the same runtime for > many/most functions). Conceivably it's still possible that the code > generated by a certain version of a compiler may have defects. Probably > less likely if the code is in a pre-existing feature. > > My question has to do with the (probably slight) possibility that the code > generated by one compiler would be different, for the same statement, for > another. > > > From: IBM Mainframe Discussion List on behalf > of Charles Mills > Sent: Monday, January 13, 2020 4:54 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > Caution and backups and fallback strategies are always good, but I don't > think there is much relationship between *running* a COBOL version X > program > and having the *compiler* version Y installed. I believe all of the runtime > is part of LE, not the compiler, and compatibility from VS COBOL II (if I > recall correctly) to current C++, PL/I and COBOL is what LE does for a > living. Not always perfectly, but that is what APARs and PTFs are for. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank Swarbrick > Sent: Monday, January 13, 2020 3:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Migrating to new compiler release > > I was wondering what "methodologies" shops have for migrating to a new > "release" within the same "version" of a compiler. Specifically, we > currently have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now available. Our > systems group asked if we just wanted to "replace" 6.2 with 6.3. I'm a bit > wary especially of a program having been compiled with V6.2 but then > implemented with V6.3. Am I over thinking this, perhaps because of the > large difference in the compiler from V4 to V5? What is the likelihood of > a > compiler bug being introduced in V6.3 for code that worked in V6.2? > Perhaps > very, very little. But I'd still like to hear thoughts and opinions. > > For what its worth, along with 6.2 we still have 4.2 and 5.2 installed. > But > we really should only be using 6.2 at this point any time a program is > recompiled. Anyway, up to this point we've always made sure that the > production compile is done with the same version/release as all of the > testing. > > Thanks, > Frank > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
Intentional differences, yes. Bug; probably not! 🙂 From: IBM Mainframe Discussion List on behalf of Michael Babcock Sent: Wednesday, January 15, 2020 11:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release Any difference should be documented in the migration guides I would think. On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick wrote: > I understand that the runtime is part of LE, and is generally shared > between versions (at least V5 and V6 seem to share the same runtime for > many/most functions). Conceivably it's still possible that the code > generated by a certain version of a compiler may have defects. Probably > less likely if the code is in a pre-existing feature. > > My question has to do with the (probably slight) possibility that the code > generated by one compiler would be different, for the same statement, for > another. > > > From: IBM Mainframe Discussion List on behalf > of Charles Mills > Sent: Monday, January 13, 2020 4:54 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > Caution and backups and fallback strategies are always good, but I don't > think there is much relationship between *running* a COBOL version X > program > and having the *compiler* version Y installed. I believe all of the runtime > is part of LE, not the compiler, and compatibility from VS COBOL II (if I > recall correctly) to current C++, PL/I and COBOL is what LE does for a > living. Not always perfectly, but that is what APARs and PTFs are for. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank Swarbrick > Sent: Monday, January 13, 2020 3:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Migrating to new compiler release > > I was wondering what "methodologies" shops have for migrating to a new > "release" within the same "version" of a compiler. Specifically, we > currently have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now available. Our > systems group asked if we just wanted to "replace" 6.2 with 6.3. I'm a bit > wary especially of a program having been compiled with V6.2 but then > implemented with V6.3. Am I over thinking this, perhaps because of the > large difference in the compiler from V4 to V5? What is the likelihood of > a > compiler bug being introduced in V6.3 for code that worked in V6.2? > Perhaps > very, very little. But I'd still like to hear thoughts and opinions. > > For what its worth, along with 6.2 we still have 4.2 and 5.2 installed. > But > we really should only be using 6.2 at this point any time a program is > recompiled. Anyway, up to this point we've always made sure that the > production compile is done with the same version/release as all of the > testing. > > Thanks, > Frank > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
You’ve got me there! I would think that chance is relatively small and wouldn’t worry about it. On Wed, Jan 15, 2020 at 12:08 PM Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > Intentional differences, yes. Bug; probably not! 🙂 > > > From: IBM Mainframe Discussion List on behalf > of Michael Babcock > Sent: Wednesday, January 15, 2020 11:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > Any difference should be documented in the migration guides I would think. > > On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > I understand that the runtime is part of LE, and is generally shared > > between versions (at least V5 and V6 seem to share the same runtime for > > many/most functions). Conceivably it's still possible that the code > > generated by a certain version of a compiler may have defects. Probably > > less likely if the code is in a pre-existing feature. > > > > My question has to do with the (probably slight) possibility that the > code > > generated by one compiler would be different, for the same statement, for > > another. > > > > > > From: IBM Mainframe Discussion List on behalf > > of Charles Mills > > Sent: Monday, January 13, 2020 4:54 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Migrating to new compiler release > > > > Caution and backups and fallback strategies are always good, but I don't > > think there is much relationship between *running* a COBOL version X > > program > > and having the *compiler* version Y installed. I believe all of the > runtime > > is part of LE, not the compiler, and compatibility from VS COBOL II (if I > > recall correctly) to current C++, PL/I and COBOL is what LE does for a > > living. Not always perfectly, but that is what APARs and PTFs are for. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Frank Swarbrick > > Sent: Monday, January 13, 2020 3:33 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Migrating to new compiler release > > > > I was wondering what "methodologies" shops have for migrating to a new > > "release" within the same "version" of a compiler. Specifically, we > > currently have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now available. > Our > > systems group asked if we just wanted to "replace" 6.2 with 6.3. I'm a > bit > > wary especially of a program having been compiled with V6.2 but then > > implemented with V6.3. Am I over thinking this, perhaps because of the > > large difference in the compiler from V4 to V5? What is the likelihood > of > > a > > compiler bug being introduced in V6.3 for code that worked in V6.2? > > Perhaps > > very, very little. But I'd still like to hear thoughts and opinions. > > > > For what its worth, along with 6.2 we still have 4.2 and 5.2 installed. > > But > > we really should only be using 6.2 at this point any time a program is > > recompiled. Anyway, up to this point we've always made sure that the > > production compile is done with the same version/release as all of the > > testing. > > > > Thanks, > > Frank > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > Michael Babcock > OneMain Financial > z/OS Systems Programmer, Lead > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
We migrate source *and* executable into a controlled stage environment where the app folks are supposed to do one last round of tests. From there, its straight copy to all PROD locations. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Babcock Sent: Wednesday, January 15, 2020 1:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** You’ve got me there! I would think that chance is relatively small and wouldn’t worry about it. On Wed, Jan 15, 2020 at 12:08 PM Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > Intentional differences, yes. Bug; probably not! 🙂 > > > From: IBM Mainframe Discussion List on > behalf of Michael Babcock > Sent: Wednesday, January 15, 2020 11:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > Any difference should be documented in the migration guides I would think. > > On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > I understand that the runtime is part of LE, and is generally shared > > between versions (at least V5 and V6 seem to share the same runtime > > for many/most functions). Conceivably it's still possible that the > > code generated by a certain version of a compiler may have defects. > > Probably less likely if the code is in a pre-existing feature. > > > > My question has to do with the (probably slight) possibility that > > the > code > > generated by one compiler would be different, for the same > > statement, for another. > > > > > > From: IBM Mainframe Discussion List on > > behalf of Charles Mills > > Sent: Monday, January 13, 2020 4:54 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Migrating to new compiler release > > > > Caution and backups and fallback strategies are always good, but I > > don't think there is much relationship between *running* a COBOL > > version X program and having the *compiler* version Y installed. I > > believe all of the > runtime > > is part of LE, not the compiler, and compatibility from VS COBOL II > > (if I recall correctly) to current C++, PL/I and COBOL is what LE > > does for a living. Not always perfectly, but that is what APARs and PTFs > > are for. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick > > Sent: Monday, January 13, 2020 3:33 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Migrating to new compiler release > > > > I was wondering what "methodologies" shops have for migrating to a > > new "release" within the same "version" of a compiler. > > Specifically, we currently have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now > > available. > Our > > systems group asked if we just wanted to "replace" 6.2 with 6.3. > > I'm a > bit > > wary especially of a program having been compiled with V6.2 but then > > implemented with V6.3. Am I over thinking this, perhaps because of > > the large difference in the compiler from V4 to V5? What is the > > likelihood > of > > a > > compiler bug being introduced in V6.3 for code that worked in V6.2? > > Perhaps > > very, very little. But I'd still like to hear thoughts and opinions. > > > > For what its worth, along with 6.2 we still have 4.2 and 5.2 installed. > > But > > we really should only be using 6.2 at this point any time a program > > is recompiled. Anyway, up to this point we've always made sure that > > the production compile is done with the same version/release as all > > of the testing. > > > > Thanks, > > Frank > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > -- > Michael Babcock > OneMain Financial > z/OS Systems Programmer, Lead > > -- > For IBM-MAIN subscribe / signoff / archive access instructions,
Re: Migrating to new compiler release
Yeah. We do have regressions tests, but it's not built in to change control itself. Perhaps something we should look in to enhancing. Thanks. From: IBM Mainframe Discussion List on behalf of Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, January 15, 2020 11:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release We migrate source *and* executable into a controlled stage environment where the app folks are supposed to do one last round of tests. From there, its straight copy to all PROD locations. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Babcock Sent: Wednesday, January 15, 2020 1:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** You’ve got me there! I would think that chance is relatively small and wouldn’t worry about it. On Wed, Jan 15, 2020 at 12:08 PM Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > Intentional differences, yes. Bug; probably not! 🙂 > > > From: IBM Mainframe Discussion List on > behalf of Michael Babcock > Sent: Wednesday, January 15, 2020 11:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > Any difference should be documented in the migration guides I would think. > > On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > I understand that the runtime is part of LE, and is generally shared > > between versions (at least V5 and V6 seem to share the same runtime > > for many/most functions). Conceivably it's still possible that the > > code generated by a certain version of a compiler may have defects. > > Probably less likely if the code is in a pre-existing feature. > > > > My question has to do with the (probably slight) possibility that > > the > code > > generated by one compiler would be different, for the same > > statement, for another. > > > > > > From: IBM Mainframe Discussion List on > > behalf of Charles Mills > > Sent: Monday, January 13, 2020 4:54 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Migrating to new compiler release > > > > Caution and backups and fallback strategies are always good, but I > > don't think there is much relationship between *running* a COBOL > > version X program and having the *compiler* version Y installed. I > > believe all of the > runtime > > is part of LE, not the compiler, and compatibility from VS COBOL II > > (if I recall correctly) to current C++, PL/I and COBOL is what LE > > does for a living. Not always perfectly, but that is what APARs and PTFs > > are for. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick > > Sent: Monday, January 13, 2020 3:33 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Migrating to new compiler release > > > > I was wondering what "methodologies" shops have for migrating to a > > new "release" within the same "version" of a compiler. > > Specifically, we currently have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now > > available. > Our > > systems group asked if we just wanted to "replace" 6.2 with 6.3. > > I'm a > bit > > wary especially of a program having been compiled with V6.2 but then > > implemented with V6.3. Am I over thinking this, perhaps because of > > the large difference in the compiler from V4 to V5? What is the > > likelihood > of > > a > > compiler bug being introduced in V6.3 for code that worked in V6.2? > > Perhaps > > very, very little. But I'd still like to hear thoughts and opinions. > > > > For what its worth, along with 6.2 we still have 4.2 and 5.2 installed. > > But > > we really should only be using 6.2 at this point any time a program > > is recompiled. Anyway, up to this point we've always made sure that > > the production compile is done with the same version/release as all > > of the testing. > > > > Thanks, > > Frank > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > --
Re: Tape problem
IBM 3494. I’ll open a ticket with CA….thanks Dean Nai Senior z/OS Systems Programmer Technical Services Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 work: 603-271-1529 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. On 1/15/20, 12:56 PM, "IBM Mainframe Discussion List on behalf of Lizette Koehler" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Are you using IBM VTS, emc vts, other tape appliance > >I have found the CA 1 Support team to be very helpful. > >Lizette > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Nai, Dean >Sent: Wednesday, January 15, 2020 10:31 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Tape problem > >Anyone ever run into a problem where the CA-1 catalog and the volcat seem to >be out of sync? We keep getting the below messages and aren’t able to eject >tapes. Thought it was 3494 hardware related by IBM doesn’t thing so. Any >suggestions? > >CBR3770I Volume T00xxx misplaced in library TAPELIB1 CBR3769I Misplaced volume >T00xxx found in library TAPELIB1 > > >Dean Nai > > > > >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
Here's another gotcha to worry about regardless of compiler version. It was a real problem, not hypothetical. We installed a new z/OS Server Pac that happened to include a new COBOL release: 4.2 to replace 4.1. As others have mentioned, the ancient practice here is to do *all* compiles on the development system, then migrate only load modules throughout the enterprise. We did some testing with 4.2 compiles on the production system ahead of time and found a bug in LE. The problem was not 4.2 per se but simply that prod was down level in maintenance. There was an LE PTF available, but it would have required a production IPL to implement. We could not just drop the new z/OS onto development until we had a chance to IPL production to install the LE fix beforehand, none of which was part of the rollout plan. The woeful tale goes on and on, but the experience is burned into bio-memory. Be cautious. Be very very cautious. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Wednesday, January 15, 2020 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Migrating to new compiler release Yeah. We do have regressions tests, but it's not built in to change control itself. Perhaps something we should look in to enhancing. Thanks. From: IBM Mainframe Discussion List on behalf of Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, January 15, 2020 11:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release We migrate source *and* executable into a controlled stage environment where the app folks are supposed to do one last round of tests. From there, its straight copy to all PROD locations. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Babcock Sent: Wednesday, January 15, 2020 1:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** You’ve got me there! I would think that chance is relatively small and wouldn’t worry about it. On Wed, Jan 15, 2020 at 12:08 PM Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > Intentional differences, yes. Bug; probably not! 🙂 > > > From: IBM Mainframe Discussion List on > behalf of Michael Babcock > Sent: Wednesday, January 15, 2020 11:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > Any difference should be documented in the migration guides I would think. > > On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > I understand that the runtime is part of LE, and is generally shared > > between versions (at least V5 and V6 seem to share the same runtime > > for many/most functions). Conceivably it's still possible that the > > code generated by a certain version of a compiler may have defects. > > Probably less likely if the code is in a pre-existing feature. > > > > My question has to do with the (probably slight) possibility that > > the > code > > generated by one compiler would be different, for the same > > statement, for another. > > > > > > From: IBM Mainframe Discussion List on > > behalf of Charles Mills > > Sent: Monday, January 13, 2020 4:54 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Migrating to new compiler release > > > > Caution and backups and fallback strategies are always good, but I > > don't think there is much relationship between *running* a COBOL > > version X program and having the *compiler* version Y installed. I > > believe all of the > runtime > > is part of LE, not the compiler, and compatibility from VS COBOL II > > (if I recall correctly) to current C++, PL/I and COBOL is what LE > > does for a living. Not always perfectly, but that is what APARs and PTFs > > are for. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick > > Sent: Monday, January 13, 2020 3:33 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Migrating to new compiler release > > > > I was wondering what "methodologies" shops have for migrating to a > > new "release" within the same "version" of a compiler. > > Specifically, we currently have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now > > avai
Re: Migrating to new compiler release
We got bit by that years ago too. IBM seems to be pretty good now with hold actions on COBOL PTF that requires a specific LE PTF to be available everywhere prior to the introduction of the Cobol PTF. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Wednesday, January 15, 2020 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Here's another gotcha to worry about regardless of compiler version. It was a real problem, not hypothetical. We installed a new z/OS Server Pac that happened to include a new COBOL release: 4.2 to replace 4.1. As others have mentioned, the ancient practice here is to do *all* compiles on the development system, then migrate only load modules throughout the enterprise. We did some testing with 4.2 compiles on the production system ahead of time and found a bug in LE. The problem was not 4.2 per se but simply that prod was down level in maintenance. There was an LE PTF available, but it would have required a production IPL to implement. We could not just drop the new z/OS onto development until we had a chance to IPL production to install the LE fix beforehand, none of which was part of the rollout plan. The woeful tale goes on and on, but the experience is burned into bio-memory. Be cautious. Be very very cautious. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Wednesday, January 15, 2020 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Migrating to new compiler release Yeah. We do have regressions tests, but it's not built in to change control itself. Perhaps something we should look in to enhancing. Thanks. From: IBM Mainframe Discussion List on behalf of Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, January 15, 2020 11:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release We migrate source *and* executable into a controlled stage environment where the app folks are supposed to do one last round of tests. From there, its straight copy to all PROD locations. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Babcock Sent: Wednesday, January 15, 2020 1:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** You’ve got me there! I would think that chance is relatively small and wouldn’t worry about it. On Wed, Jan 15, 2020 at 12:08 PM Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > Intentional differences, yes. Bug; probably not! 🙂 > > > From: IBM Mainframe Discussion List on > behalf of Michael Babcock > Sent: Wednesday, January 15, 2020 11:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > Any difference should be documented in the migration guides I would think. > > On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > I understand that the runtime is part of LE, and is generally shared > > between versions (at least V5 and V6 seem to share the same runtime > > for many/most functions). Conceivably it's still possible that the > > code generated by a certain version of a compiler may have defects. > > Probably less likely if the code is in a pre-existing feature. > > > > My question has to do with the (probably slight) possibility that > > the > code > > generated by one compiler would be different, for the same > > statement, for another. > > > > > > From: IBM Mainframe Discussion List on > > behalf of Charles Mills > > Sent: Monday, January 13, 2020 4:54 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Migrating to new compiler release > > > > Caution and backups and fallback strategies are always good, but I > > don't think there is much relationship between *running* a COBOL > > version X program and having the
Re: Migrating to new compiler release
The early you catch compatibility issues the better. IMHO, rolling out source and recompiling is much safer. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Wednesday, January 15, 2020 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release Seems to me your problem is recompiling after testing. If you want to avoid problems that re-compiling could introduce, then don't. sas On Wed, Jan 15, 2020 at 11:59 AM Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > I was just stating what a theoretical new version of a theoretical > compiler might provide. In the specific case of E.C. 6.3 you are certainly > correct. Of course there is no requirement to change ARCH level upon > implementation of a new version, even if you're at that necessary hardware > level. > > > From: IBM Mainframe Discussion List on behalf > of Clark Morris > Sent: Tuesday, January 14, 2020 4:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > [Default] On 14 Jan 2020 13:58:34 -0800, in bit.listserv.ibm-main > frank.swarbr...@outlook.com (Frank Swarbrick) wrote: > > >I disagree with that. A new version may simply be new features, none > affecting any features the old version supported. > > The 6.3 compiler supports a new ARCH level for the z15 and uses SIMD > instructions rather that the selected conversion to floating point > decimal for some calculations. Both code sequences are an enhancement > over using standard packed decimal instructions. > > Clark Morris > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
Wiki? NFW. Bitsavers is an archive. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Wednesday, January 15, 2020 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? Bitsavers.org is a "wiki" site with scans of out-of-print tech manuals. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Alexander Huemer Sent: Wednesday, January 15, 2020 8:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? I am aware RS232 is just a low-level protocol, though, if I decide to really spend time on this, I have to interface with a 3174 somehow, low-level. And I wonder which options I have for that, regardless of the higher protocol layer. I am not questioning that they have to be figured out. What is bitsavers? On Tue, Jan 14, 2020 at 07:59:49PM +, Seymour J Metz wrote: > An interface to 3270 displays would be useful only if you had software that supported 3270 on your platform. Further, is there a real 3270 that is less expensive than running, e.g., TN3270, on a desktop? > > RS-232-C is just a protocol between a serial adapter and a modem; it doesn't specify, e.g., control characters, packets, going between the modems. B&T, Ethernet and TR all specify controls at a higher level. > > Your best resource for 3270 information is probably bitsavers. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of Alexander Huemer > Sent: Tuesday, January 14, 2020 4:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Talking to 3270 terminals? > > Hi > > I am new to this list and would like to discuss an idea and ask several > questions. > > * Did anybody ever attempt to 'talk' to 3270 terminals with something > different than an IBM mainframe? > > This might sound like a strange idea, though I find it intriguing to be > able to display content on such a terminal and be able to receive > keyboard input from it. > > I guess the most straight-forward way to attempt something like that is > to use a 3270 terminal attached to a 3174 or similar and try to talk to > that instead of the terminal itself. I wouldn't know how to interface > with the terminal directly over the coax. > > * What's the best available documentation regarding 3174 models and > their features? > > I poked around on ibm.com and google but wasn't able to find much. It > seems like there were several different physical-layer north-bound > interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not > mistaken, for dial-up connections), maybe others? > > Bus&Tag doesn't seem to be a good candidate, it's difficult to interface > with as far as I understand. > Ethernet is way more common these days than Token Ring, though TR NICs > are easy to procure second hand and protocol support under Linux (the OS > I am most savvy with) is in place. > RS232 is easy to interface with also, though then again, I am not sure > if that interface really exists. > > * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3 or > was there by any chance something going on with TCP/IP? I doubt it > though. > > Talking SNA with custom software doesn't seem to be a low-hanging fruit. > From where I stand right now I cannot say how straight-forward the > network traffic between the mainframe and a 3174 is, how difficult it > would be to emulate that protocol with custom software over several > layers. > > * Is anybody on the list here able to provide protocol traces from the > link between mainframe and 3174 over any interface? pcap format is > preferred, though anything would be valuable. > > I would appreciate any thoughts regarding this topic, especially to the > questions marked with asterisks. > Also, if anything is known regarding a similar thing with 5250 instead > of 3170 terminals, that would be interesting as well. > > -Alex > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --
Re: Talking to 3270 terminals?
Why trailing-edge rather than the bitsavers.org site? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, January 15, 2020 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? On Wed, 15 Jan 2020 10:48:26 -0600, Tom Marchant wrote: >or, perhaps more specific to the OP's question, >http://secure-web.cisco.com/1v-KC3csCPpvQ7mc1lxvt-nxyWsy9CexRkdVnT18F0rz9WGb81U6ntRlr93sPQCBPT2SjmHeF_vau0u9KaskWYmOnA-3o0mN_s3IDAXzsQdPewjo2RP4ZJ1FoPFV8m67peZ5ep1mkUI7AHLzXyf4WtzXpHqU4V2bHqI_FSc2F9bC0-FUP1WVN_TxZJGsOnzRtA-T0jPpQCxtWKkT2zN-5lSfrQ9UUrOQa32KCTscKHdIzjE93-C0HoFb2_J4OV5ChIbEP0Q-bCzb4fIujXX9GgFMR-JzNDv2nAmA-tx0MnTNvYhEKd7nd_78YQz_I0TrC5PRanZXigUqWt-WoB3zU70pLDsJN9pOW0gd2pe2d7oLfrWpZlECDKeIQNYH9jJmShyqBdj-YKG8OoWxHv1EEYBdUFTO9ZnXLIKTC5Vs7ZU6twvIbz5N6v_vd9wgB84MQ/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fibm%2F360%2F Oops. I meant http://secure-web.cisco.com/1t9F8VODz0qVbtwctMS0C9UvyErIv44Scw41poTzCMchagOZ_ADQYz3Aapu4YQxblZuxTdU54IkGnbhWlsURXTaObAl0vNE46irt-wVpppYUNFpW-_SlSDZLH8bOYNgDg5AEpt5HDaEmsI_RKX9lF3tabjewl_els0XSUUH9ezhXER8Hy9OEfnx66b9Btys56tDJs00yvjv37238v52t09v-NqZjdYXPDkVP17NQLuqD1FzVtOvpmLfg6M_S6pIgifD6mtjdNbKY2az9jrvsukSm3oOt2hK-jE8mXPyoJyY7NOFSqls8Mg_RCqnv9IFpwQwKouqbqEGN3_s1YVR8rFqnzT8BLBtwBCc1s69cslyWakm2WT-UxZwD776lKsgBolGN_xLZjjsU10MCLZfPa-BX1aU-GecF8Ug3805qM7i4phENZdMUamtdy1EjbCPTv/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fibm%2F3270%2F -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
No, I meant bitsavers, not archive or trailing edge. HTTP colon //bitsavers.org/pdf/ibm/3270 is probably of most interest, but pdf/ibm/370 might have something of interest. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, January 15, 2020 11:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? On Wed, 15 Jan 2020 08:29:38 -0800, Tom Brennan wrote: >I think Shmuel is talking about >https://secure-web.cisco.com/1tgQ7bW1CAdvm6qk8rStLJK_LHyVdTwMP-gt-hIXOajFVCF2zEUx6Vg0-SvF2bSu0m-P1yfbBhjDPnMEwRhl10ZUYYS4oZv9SaBo9565zDxhsL6pVrHZSuSPTtN86IH394yNKcJz_HIcuYwQA1Osf22ba9qb8LKSOmpC3cqvs7UFouHssO0Ieo0syn6naqPf1f1nGQjZT5B4jPZ-2hMeniV2VrAzfvH1FQBzPD3j2FQ0HCrwR0qFly2xbFRFprHAu3USowjT6IFndTpFuerOYf2B2UQmKH8p_o9MZFw6dy623XDkILvCJY340k6VYCEYtPoPMbhIYKYdjAQIbdBLdgFfYstWuQPjRHy8BXConBcpHylPSL0w675Bx_rDfY72vYEaEtvXxUBTbnfLT99KwIUcTCkBcDIoOe_Nb1Ji05QzmQwKYvyJHTKfrHwM-xhdc/https%3A%2F%2Farchive.org%2Fdetails%2Fbitsavers I think he meant http://secure-web.cisco.com/1nbdHE1UN3wIsLP5z-PdJCFJfwesiO_f28vhsEJkfkhu5OSC77S4cCdsLWlBK1xqNkl2IvbSx3WpKALgQ8ymsEF-tSAgJSUYJjN9qlsyJMPgljS4Z5XtOQRiHILY9q2GZW-FvpFtHS68t66uwNYHo3E7VvaBCer5M6mMmVX-aXHuMmoWnjkykBrE_VHVGW3j6OkUkp69-T5S2BEVAxs-UppOYNL5y2odXcapYC6sliGqsPCfZPzEevk4AYz3KuZidqOh8bk-eIEdRJ7uj8JlCC8CY2Rcl2ZgHsYDBgPi6JvB0Fra0y1HkSg7ad8a-QE5nAULzOdYt-80mtiAxmjPrJOe9oFWy8EEenb_thCD4Mg69g9_SI9OT7hl4vFTZLndmTPc8PiYWIeez3lb6DVX7qAhym39GIPdni9FGV8wyUhHLtxZoZtNOWz2FxZnvT-vR/http%3A%2F%2Fbitsavers.trailing-edge.com%2F or http://secure-web.cisco.com/17Fe-BBlvJJDWIXKw0_33nLZxQgSIoGKOt0Bpxt5xZvQUPApB6JfaSqTQ5ly4S9Y9zg7TIw3hKIJ8EgcQnPkHicU4CQfoEOrc6nN0ITp2Hdo5HsqJ0v1ZW8yUHUaOr1UNGXienmIWaebYt48YMtDQ0mDra-8uu8vaKgBD7ny3lVZBGL2vDOY3hTaX0x2SZbs0DsUKozMJmeJsIUG6spU5pLrNdKHQ0fAgI-4Zy2Y7rp3wyJpiVjkh4Lw9QZKPwxZsnuTDI3jjdPqCWMiDvDPf8qQjZFSHxjqiZQVCbxEcnd-O1H1TECxRJdtUYCKbdo5IYS_HjlGTyBKmz-DwzDbRGP11Q6mFwWMTMInB0ePGzY96PbCsVsDSTn5Ghtv__IAMQtOU6Sx_qaBEmxiyWlVDK9ZxflOxzrLZg3aFQ2nxD5ltwehep4q-KvKCgvsuYc-v/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fibm%2F or http://secure-web.cisco.com/19pCJPtZQGWiCn1Egsr11hkk2mrQ36KZyKAhKCBSAwBEIr9VLED7ijbRiWnAVbU0m2EQ2U1f5a2arYA2MZsf6x_DdHbk87BNLYCH-6lDH71fRf1fixNu_ucrjy-NIovCDslcCm9oY7kHmht8azkKC-g5b-ksg7KwE12DPnBh3Eh0aMeUrD5_G72FOnLD2EVPk0JemrfajTvAgegUOppqzbeIVcOw5tVHYtkPG1stbx0S5k688TbakjMgg7ntzMwo205qDR_6_3YKTWP5XnxoMwT0kUorpsAo84XEcRemTI50W5KCHzpVe804FiaOqPGvmzff73ISsXUVWWW9bszZyvx_G7H1hue3Mo8AqRWGP5r_BDFIz3g9O8GzIXxxCtadXXUlSvfSEhEyyvV8j0G5sBogyZKrbYj7pzCjjN4h4ycTJAp0ifuY-4PQFovyIlZ2c/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fibm%2F360%2F or http://secure-web.cisco.com/1jMo-6w6Th58MCd19E4gXrwgNUpDxyclK_F9LLN1MTvEbEO6l27hZhsFR-IxLX2W4pVx2w-9Q6ACxdz-QwzDgTXJ_sQ5upocokFnbxAiyiCWJ8vzi6HmLLKGpWQO6B3xnsuAyYlu12DDfGYu4dtHLyG1kCberFeQ2ThcxDSpHfQdv4OSJrqOmV4cQOOc8HBHptxIrF9Gl2vXqHP0VsS8hUjhtE6RExLDz_z2aus8Vt-vgh0RosUo2PRjRzHv1m6qLXpHIlWJDc86yJacVZ7ZQIIU3_ugSpiLKhFh4bBxqDrVKHa8hPDNXKWHEIV6_EK9gbCwOKcA3SzJqb4VXfwSuwSyeqyjAUVyz8i4rDbbKDb2jV9B3eMHKgfe0PvjNBu8HZTLb3jJfhVk7wqYm1lCR4m7GyRVVdfOCy_0x3qQmnDpA7Z8vK1XOysSkxzN1F7d8/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fibm%2F370%2F or, perhaps more specific to the OP's question, http://secure-web.cisco.com/19pCJPtZQGWiCn1Egsr11hkk2mrQ36KZyKAhKCBSAwBEIr9VLED7ijbRiWnAVbU0m2EQ2U1f5a2arYA2MZsf6x_DdHbk87BNLYCH-6lDH71fRf1fixNu_ucrjy-NIovCDslcCm9oY7kHmht8azkKC-g5b-ksg7KwE12DPnBh3Eh0aMeUrD5_G72FOnLD2EVPk0JemrfajTvAgegUOppqzbeIVcOw5tVHYtkPG1stbx0S5k688TbakjMgg7ntzMwo205qDR_6_3YKTWP5XnxoMwT0kUorpsAo84XEcRemTI50W5KCHzpVe804FiaOqPGvmzff73ISsXUVWWW9bszZyvx_G7H1hue3Mo8AqRWGP5r_BDFIz3g9O8GzIXxxCtadXXUlSvfSEhEyyvV8j0G5sBogyZKrbYj7pzCjjN4h4ycTJAp0ifuY-4PQFovyIlZ2c/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fibm%2F360%2F -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
> Why trailing-edge rather than the bitsavers.org site? Things may have changed over the years, but Al and Tim decided to mainly point people towards Tim's servers, to keep Al's bandwidth down. -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
No, bitsavers. Do you mean http colon //bitsavers.org/pdf/ibm/3270/GA23-0059-4_3270_Data_Stream_Programmers_Reference_Dec88.pdf? /pdf/ibm/3274/GA23-0061-2_3274_Control_Unit_Description_and_Programmers_Guide_Mar85.pdf? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: Wednesday, January 15, 2020 11:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? But a couple of minutes earlier you said: > Well, I guess the proposal was to write a piece of software that a > TN3270 client connects to and is able to exchange data with it. Do you really have a 3174? Do you have a real IBM terminal? Or another way to ask: If you created such a program, what would you be typing on when you work with the program? I think Shmuel is talking about https://secure-web.cisco.com/1hl-1uC8pqGwZWJD8gYPs-NCek47f5-NxLk2cA6HhvoJ9jiGxv8Rj4mgwlwDIJ8DwXCugcYs1lpZpkfl4Wag4m4pUQN5r0xgcesYgtJzW0RNJvui18gLxAFZ7DMq-gmqF-mm5IQr3M6vsKICPIJOLt4msO99MOeBwxyC88taYRkY9jcgSY_Xe6RWkd4KdmVhqxIgs7RG8wgu_I-YKZpOZLrFozXnXonCviXXJgm79PUwxrDikBZL9c6Fc-om9otTsjmwl58-Gb0BXNY9XOP5Ehjy-BRg3VepffkzIbW8F79aiYOlvjMoZKPFbycgNo3XYm1kwn_P3UFJLv2YmncchPx9UFTnKB1DTbQVgCv87EZ30HDuxuzqgbnkGNjBkeyFKwBycaVQ3fJGQtwaNAH4zjVKYSC9NMxiyA9lRW5SHpQJ2M8oIiBncBqOwG2TtERHL/https%3A%2F%2Farchive.org%2Fdetails%2Fbitsavers And I just noticed my old web bookmark to the 3270 Programmer's Reference is now gone! I guess I need to keep my 1990 printed manual which covered in notes and marks and sticky notes :) On 1/15/2020 8:01 AM, Alexander Huemer wrote: > I am aware RS232 is just a low-level protocol, though, if I decide to > really spend time on this, I have to interface with a 3174 somehow, > low-level. And I wonder which options I have for that, regardless of the > higher protocol layer. I am not questioning that they have to be figured > out. > > What is bitsavers? > > On Tue, Jan 14, 2020 at 07:59:49PM +, Seymour J Metz wrote: >> An interface to 3270 displays would be useful only if you had software that >> supported 3270 on your platform. Further, is there a real 3270 that is less >> expensive than running, e.g., TN3270, on a desktop? >> >> RS-232-C is just a protocol between a serial adapter and a modem; it doesn't >> specify, e.g., control characters, packets, going between the modems. B&T, >> Ethernet and TR all specify controls at a higher level. >> >> Your best resource for 3270 information is probably bitsavers. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> >> From: IBM Mainframe Discussion List on behalf of >> Alexander Huemer >> Sent: Tuesday, January 14, 2020 4:52 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Talking to 3270 terminals? >> >> Hi >> >> I am new to this list and would like to discuss an idea and ask several >> questions. >> >> * Did anybody ever attempt to 'talk' to 3270 terminals with something >>different than an IBM mainframe? >> >> This might sound like a strange idea, though I find it intriguing to be >> able to display content on such a terminal and be able to receive >> keyboard input from it. >> >> I guess the most straight-forward way to attempt something like that is >> to use a 3270 terminal attached to a 3174 or similar and try to talk to >> that instead of the terminal itself. I wouldn't know how to interface >> with the terminal directly over the coax. >> >> * What's the best available documentation regarding 3174 models and >>their features? >> >> I poked around on ibm.com and google but wasn't able to find much. It >> seems like there were several different physical-layer north-bound >> interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not >> mistaken, for dial-up connections), maybe others? >> >> Bus&Tag doesn't seem to be a good candidate, it's difficult to interface >> with as far as I understand. >> Ethernet is way more common these days than Token Ring, though TR NICs >> are easy to procure second hand and protocol support under Linux (the OS >> I am most savvy with) is in place. >> RS232 is easy to interface with also, though then again, I am not sure >> if that interface really exists. >> >> * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3 or >>was there by any chance something going on with TCP/IP? I doubt it >>though. >> >> Talking SNA with custom software doesn't seem to be a low-hanging fruit. >> From where I stand right now I cannot say how straight-forward the >> network traffic between the mainframe and a 3174 is, how difficult it >> would be to emulate that protocol with custom software over several >> layers. >> >> * Is anybody on the list here able to provide protocol traces from the >>link between mainframe and 3174 over any interface? pcap format is >>preferred, though anything would be valuable. >> >> I would appreciate any
Re: Talking to 3270 terminals?
Does that mean that citations in wiki should use trailing-edge? If so, does wiki know? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of William Donzelli Sent: Wednesday, January 15, 2020 3:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? > Why trailing-edge rather than the bitsavers.org site? Things may have changed over the years, but Al and Tim decided to mainly point people towards Tim's servers, to keep Al's bandwidth down. -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
> Does that mean that citations in wiki should use trailing-edge? If so, does > wiki know? Most bitsavers mirrors tend to be well synced, so it probably does not really matter. -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
If you want to look like the host side then your options are B&T, BSC, Ethernet, SDLC and TR, depending on the controller model and configuration. For BSC and SDLC you would need a synchronous serial adapter, not the asynchronous adapter that some PCs come with. If you have a B&T adapter and software to drive it, and your controller is configured for local non-SNA then that might be the simplest option. SDLC and local would require that you write an SSCP, which is probably more work than you want to consider. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Alexander Huemer Sent: Wednesday, January 15, 2020 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? I am aware RS232 is just a low-level protocol, though, if I decide to really spend time on this, I have to interface with a 3174 somehow, low-level. And I wonder which options I have for that, regardless of the higher protocol layer. I am not questioning that they have to be figured out. What is bitsavers? On Tue, Jan 14, 2020 at 07:59:49PM +, Seymour J Metz wrote: > An interface to 3270 displays would be useful only if you had software that > supported 3270 on your platform. Further, is there a real 3270 that is less > expensive than running, e.g., TN3270, on a desktop? > > RS-232-C is just a protocol between a serial adapter and a modem; it doesn't > specify, e.g., control characters, packets, going between the modems. B&T, > Ethernet and TR all specify controls at a higher level. > > Your best resource for 3270 information is probably bitsavers. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of > Alexander Huemer > Sent: Tuesday, January 14, 2020 4:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Talking to 3270 terminals? > > Hi > > I am new to this list and would like to discuss an idea and ask several > questions. > > * Did anybody ever attempt to 'talk' to 3270 terminals with something > different than an IBM mainframe? > > This might sound like a strange idea, though I find it intriguing to be > able to display content on such a terminal and be able to receive > keyboard input from it. > > I guess the most straight-forward way to attempt something like that is > to use a 3270 terminal attached to a 3174 or similar and try to talk to > that instead of the terminal itself. I wouldn't know how to interface > with the terminal directly over the coax. > > * What's the best available documentation regarding 3174 models and > their features? > > I poked around on ibm.com and google but wasn't able to find much. It > seems like there were several different physical-layer north-bound > interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not > mistaken, for dial-up connections), maybe others? > > Bus&Tag doesn't seem to be a good candidate, it's difficult to interface > with as far as I understand. > Ethernet is way more common these days than Token Ring, though TR NICs > are easy to procure second hand and protocol support under Linux (the OS > I am most savvy with) is in place. > RS232 is easy to interface with also, though then again, I am not sure > if that interface really exists. > > * Did the LAN interfaces (Ethernet, TR) talk SNA on layers 2 and 3 or > was there by any chance something going on with TCP/IP? I doubt it > though. > > Talking SNA with custom software doesn't seem to be a low-hanging fruit. > From where I stand right now I cannot say how straight-forward the > network traffic between the mainframe and a 3174 is, how difficult it > would be to emulate that protocol with custom software over several > layers. > > * Is anybody on the list here able to provide protocol traces from the > link between mainframe and 3174 over any interface? pcap format is > preferred, though anything would be valuable. > > I would appreciate any thoughts regarding this topic, especially to the > questions marked with asterisks. > Also, if anything is known regarding a similar thing with 5250 instead > of 3170 terminals, that would be interesting as well. > > -Alex > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN
Re: HSFLOG and HSFTRACE
Allocate them yourself. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Gadi Ben-Avi Sent: Wednesday, January 15, 2020 1:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HSFLOG and HSFTRACE Hi, SDSF allocates two SYSOUT files named HSFLOG and HSFTRACE. How do I change the SYSOUT Class these files use? I am running z/OS v2.3 Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
1. If you're trying to look like a 3270 on a 3174 and you need to be usable as a console before VTAM is up then you need to connect over B&T, ESCON or FICON. A TN3270 session with an OSA-ICC will do the trick. 2. The 3174 had both synchronous and asynchronous RS-232-C adapters. a. A 3174 used as a protocol converter had asynchronous adapters. b. A remote (BSC or SDLC) model had a synchronous adapter. Depending on the configuation, it might be dial, leased analog or digital. 3. TN3270 does not carry SNA packets, although tere are some housekeeping data that may be transmitted. 4. Only an SNA 3174 looks like a tree of devices. 5. MSNF already allowed SNA traffic between hosts; what APPN did was to allow semi-autonomous nodes with less complexity. 6. It's easy to capture the traffic between a local 3174 and the host. For local non-SNA it's also easy to read the traces. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, January 14, 2020 8:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? On 1/14/20 2:52 AM, Alexander Huemer wrote: > Hi Hi, > I am new to this list and would like to discuss an idea and ask several > questions. Welcome. > * Did anybody ever attempt to 'talk' to 3270 terminals with something > different than an IBM mainframe? Yes* * because it's highly dependent on what you mean by "IBM mainframe". More specifically if you mean the hardware and / or the software. I know that there are people actively working in the Hercules community to drive (talk to) 3270 terminals. I think I've recently read some articles where someone is trying to use a 3270 as a terminal for a Unix (Linux?) workstation. So, "It depends" > This might sound like a strange idea, though I find it intriguing to > be able to display content on such a terminal and be able to receive > keyboard input from it. It doesn't sound completely crazy to me. It does some completely atypical. But atypical can be entertaining and / or educational. > I guess the most straight-forward way to attempt something like that is > to use a 3270 terminal attached to a 3174 or similar and try to talk to > that instead of the terminal itself. I wouldn't know how to interface > with the terminal directly over the coax. I believe the article I recently read was talking about driving the signal on the coax. I typically see some variation of the following discussed: 1) 3270 terminal talks to the (remote) 3174 Control Unit (?). 2) The remote 3174 CU talks across Ethernet or Token Ring or RS-232 something else acting like a local 3174 CU. 3) This thing acting like a local 3174 usually talks TN3270 to a mainframe OS, be it running on a physical mainframe or emulated. I believe that some later / feature rich 3174s have the ability to act like primitive telnet clients. Thus you could use the 3270 to talk to a Unix box. > * What's the best available documentation regarding 3174 models and > their features? I don't know. I've seen quite informative discussions about this type of thing on the hercules-390 and cctalk mailing lists, plus a few newsgroups. > I poked around on ibm.com and google but wasn't able to find much. It > seems like there were several different physical-layer north-bound > interfaces for 3174. Bus&Tag, Token Ring, Ethernet, RS232 (if I am not > mistaken, for dial-up connections), maybe others? I think it's highly dependent on if it's the "local" or "remote" 3174. I think that the "local" 3174 was exclusively Bus & Tag for northbound. — I've not heard of any ESCON interfaces for 3174. — The Token Ring / Ethernet / SDLC / RS-232 was southbound to talk to "remote" 3174s. Similarly, the "remote" 3174 was Token Ring / Ethernet / SDLC / RS-232 for northbound and coax for southbound. The Token Ring / Ethernet / SDLC / RS-232 was used to connect "local" and "remote" 3174s. > Bus&Tag doesn't seem to be a good candidate, it's difficult to interface > with as far as I understand. Two things come to mind to interface with B&T. The B&T cards that exist for PCs running things like the PC/370 / P/390(-E) or something like a big iron Cisco router with a Channel Interface Processor card. But I think even the CIP is a "grey" downstream device and can't pretend to be a "black" host (mainframe) device. > Ethernet is way more common these days than Token Ring, though TR NICs > are easy to procure second hand Agreed. > protocol support under Linux (the OS I am most savvy with) is in place. Be careful there. Contemporary Linux (4.x) no longer includes Token Ring support. I believe it was removed from 3.5. Even then, there are other protocols that I've not been able to find support for in Linux. SNA being the biggest contender. There are pieces that I think could be
Re: Migrating to new compiler release
A new version that doesn't affect the generated code may have an IFREQ that affects the run-time environment. But it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Frank Swarbrick Sent: Tuesday, January 14, 2020 4:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release I disagree with that. A new version may simply be new features, none affecting any features the old version supported. From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, January 14, 2020 2:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release > My question has to do with the (probably slight) possibility that the code generated by one compiler would be different, for the same statement, for another. It certainly would. If the code generated for every statement was the same for both compilers, then there would be no difference between the two. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, January 14, 2020 11:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release I understand that the runtime is part of LE, and is generally shared between versions (at least V5 and V6 seem to share the same runtime for many/most functions). Conceivably it's still possible that the code generated by a certain version of a compiler may have defects. Probably less likely if the code is in a pre-existing feature. My question has to do with the (probably slight) possibility that the code generated by one compiler would be different, for the same statement, for another. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Talking to 3270 terminals?
You might say it, but the IETF did not. In particular, RFC 1576 does not, but refers to the client as an emulator. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, January 14, 2020 4:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? I would say you do talk TN3270 to the emulator: https://secure-web.cisco.com/1XYv2BUXDGPDPIvuqb0NOWGfNixk3FRjPRKGpZQRkX47YFzdi7ZJWW72c35u4e9_PMLOZ-jxs5gjltuZyBkFNHzuwy1f_PK1CcEGpggHhLmuGBeoXtUsmHjm2TF4A7ALjxwmpwwZdMMJ2qUmGmXZcVS7LovR3tCgtFEwBvJjqKAFea6YqNo9EY4BOFoEUu1Wnn_kSPX6p55NtwYiwlYyLmNvXPeuAzfZs6CxnuHUG4jWCPnpG0q0sOz_P-uv4COgjX1IRPzc3cnr9gX0oeD5pVqjan0ChRdCWZg6xYk8taMogx5rNtTIGsPMjTj9geNvwrjXsmPlgsDJkPwPRdqEmDJKAH5JlQHQOQ8LUeZ2MQkNTDclBacNosje_-PSYJK1mVF_1ajTio5-l5DOpWK4V1v3HS0VvKg7DjgHYxhQuikHX-P8MAWm7ua4c-vqFQYspTg3ZEnYCgsRFhDXUCQTZkQ/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc1576 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, January 14, 2020 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Talking to 3270 terminals? You don't talk TN3270 to an emulator; all of the 3270 simulation is in the TN3270 client. Tn3270 just encapsulates 3270 data streams and associated housekeeping. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
I did indeed misunderstand what you meant by "implemented." I interpreted that as meaning "rolled out into production" but you meant "recompiled." Absolutely I would NOT test under 6.2 and then release compile under 6.3. Yeah, it should work, but I would not do it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Wednesday, January 15, 2020 8:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release You are misunderstanding. My concern, and I admit its a small one, is about those programs that were tested prior to the version upgrade but implemented after the version upgrade. Meaning they were tested having been compiled with V6.2, but compiled for implementation using V6.3. It's a short window where that would happen, so probably not worth fretting about. From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, January 14, 2020 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release I think we are getting into "how many compiler developers can dance on the head of a pin?" territory here. I stand by my original answer: - Yes, be prudent. There are old sysprogs and there are bold sysprogs but there are no old, bold sysprogs. - I would be surprised if there were any reasons why having 6.3 installed would affect how 6.2-compiled programs would run. I would be really surprised if such reasons existed and they could not be quickly fixed by APAR and PTF. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, January 14, 2020 1:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release I disagree with that. A new version may simply be new features, none affecting any features the old version supported. From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, January 14, 2020 2:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release > My question has to do with the (probably slight) possibility that the code generated by one compiler would be different, for the same statement, for another. It certainly would. If the code generated for every statement was the same for both compilers, then there would be no difference between the two. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, January 14, 2020 11:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release I understand that the runtime is part of LE, and is generally shared between versions (at least V5 and V6 seem to share the same runtime for many/most functions). Conceivably it's still possible that the code generated by a certain version of a compiler may have defects. Probably less likely if the code is in a pre-existing feature. My question has to do with the (probably slight) possibility that the code generated by one compiler would be different, for the same statement, for another. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSFLOG and HSFTRACE
> I believe it's SDSFAUX that allocates these files... > Dan Used to be SDSFAUX. With z/OS 2.3, the SDSF address space took over this function. Ant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
I was under the impression that newer releases of a compiler might smarten up inefficient code, such as moving assignments that are unchanging out of loops, or opening out loops, for example. None of this should affect a program flow detrimentally or produce a bug. We're currently moving from COBOL 4.2 to version 6 (.1). Along the way I'm discovering lots of undesirable things that were done years ago when Endevor was installed and the internal staff took no interest in the process. Today I found hard coded references to COBOL versions, CICS SDFHLOAD, MAC etc. I assured the support guy that if the current load modules are working, it's nothing to worry about. However, it would be wise to recompile with all the pieces as current as possible, such as DB2 precompile components, CICS and COBOL etc. Of course, lots of testing will be needed after this recompile. On Thu, Jan 16, 2020 at 8:57 AM Charles Mills wrote: > I did indeed misunderstand what you meant by "implemented." I interpreted > that as meaning "rolled out into production" but you meant "recompiled." > > Absolutely I would NOT test under 6.2 and then release compile under 6.3. > Yeah, it should work, but I would not do it. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank Swarbrick > Sent: Wednesday, January 15, 2020 8:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > You are misunderstanding. My concern, and I admit its a small one, is > about > those programs that were tested prior to the version upgrade but > implemented > after the version upgrade. Meaning they were tested having been compiled > with V6.2, but compiled for implementation using V6.3. It's a short window > where that would happen, so probably not worth fretting about. > > > From: IBM Mainframe Discussion List on behalf > of > Charles Mills > Sent: Tuesday, January 14, 2020 3:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > I think we are getting into "how many compiler developers can dance on the > head of a pin?" territory here. I stand by my original answer: > > - Yes, be prudent. There are old sysprogs and there are bold sysprogs but > there are no old, bold sysprogs. > - I would be surprised if there were any reasons why having 6.3 installed > would affect how 6.2-compiled programs would run. I would be really > surprised if such reasons existed and they could not be quickly fixed by > APAR and PTF. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank Swarbrick > Sent: Tuesday, January 14, 2020 1:58 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > I disagree with that. A new version may simply be new features, none > affecting any features the old version supported. > > > From: IBM Mainframe Discussion List on behalf > of > Charles Mills > Sent: Tuesday, January 14, 2020 2:09 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > > My question has to do with the (probably slight) possibility that the > code > generated by one compiler would be different, for the same statement, for > another. > > It certainly would. If the code generated for every statement was the same > for both compilers, then there would be no difference between the two. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank Swarbrick > Sent: Tuesday, January 14, 2020 11:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Migrating to new compiler release > > I understand that the runtime is part of LE, and is generally shared > between > versions (at least V5 and V6 seem to share the same runtime for many/most > functions). Conceivably it's still possible that the code generated by a > certain version of a compiler may have defects. Probably less likely if > the > code is in a pre-existing feature. > > My question has to do with the (probably slight) possibility that the code > generated by one compiler would be different, for the same statement, for > another. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > --
Re: Talking to 3270 terminals?
Don't forget Nixdorf, although the machine I worked with was built by
Hitachi in Israel. It had a 3274 emulator that worked on a early LAN type
architecture, not quite the same and it also had a comms controller that
behaved like a 3174.
On Wed, Jan 15, 2020 at 6:40 PM Timothy Sipples wrote:
> Alexander Huemer wrote:
> >I am new to this list and would like to discuss an idea and ask several
> >questions.
> >* Did anybody ever attempt to 'talk' to 3270 terminals with something
> > different than an IBM mainframe?
>
> Yes, here are some examples of entities that did exactly that:
>
> Amdahl
> Fujitsu
> Hitachi
>
> The so-called "plug compatible" mainframe vendors, in other words.
>
> IBM itself offered a couple choices that (in my view anyway) are fairly
> described as "non-mainframes." The IBM 3790 was one such example, a
> "distributed computer" announced in 1975. Many 3790s were connected to
> mainframes (IBM and non-IBM), and you needed a mainframe to create programs
> for it, but it could (and often did) operate independently.
>
> I found an article written by John J. Hunter and published in the October
> 6, 1986, edition of "Network World" that describes some other products,
> including IBM's own 3174 Subsystem Control Unit that had some interesting
> capabilities. Let's start with the IBM 3174, which was available with "an
> optional protocol converter adapter that allows IBM terminals to emulate
> Digital Equipment Corp. VT 100 and IBM 3101 terminals. It will also enable
> the terminals to communicate with Ascii host applications and public data
> networks." In other words, you could use an IBM 3174 with this optional
> adapter to enable your physical IBM 3270 series (e.g. IBM 3179 Model 1)
> terminals to communicate with DEC VAX, PDP, IBM Series/1, and various other
> systems that supported at least one of those two ASCII terminal protocols
> -- and there were gobs of them in the 1980s. The article alludes to
> attaching an IBM 3174 (with IBM 3270 series terminals) to a suitably
> equipped IBM PC/AT or IBM RT PC ("local applications-processing facilities
> [.] [u]nless personal computers are used")
>
> The article also describes the directly competing products at that time:
> "the ITT Courier 9000 Series, the Lee Data 300/400 product line, and the
> Telex 270." The products also effectively turned physical IBM 3270 series
> terminals into ASCII terminals. ITT and Lee Data also offered local
> processors running the Xenix operating system.
>
> IBM also had something called the "IBM 5209 Link Protocol Converter" which
> allowed 3270 series devices to be attached to older and contemporary
> System/36, System/38, and AS/400 machines.
>
> >I guess the most straight-forward way to attempt something like that is
> >to use a 3270 terminal attached to a 3174 or similar and try to talk to
> >that instead of the terminal itself. I wouldn't know how to interface
> >with the terminal directly over the coax.
>
> If you can find an IBM 3174 equipped with the optional protocol converter
> adapter and the RS-232-C port for a host connection, you should be able to
> connect genuine IBM 3270 series terminals to, for example, a PC running
> Linux that has a serial port, or at least a USB port since you should be
> able to find a USB to RS-232-C "dongle" cable. The ITT, Lee Data, or Telex
> equipment described in "Network World" should also work if you can find it,
> although I have to believe the IBM 3174 equipment is easier to find.
>
> Bitsavers.org has a copy of IBM Publication GA27-3850 ("IBM 3174
> Establishment Controller Introduction") that describes the Asynchronous
> Emulation Adapter ("AEA") starting on page 2-2:
>
>
> http://www.bitsavers.org/pdf/ibm/3174/GA27-3850-0_3174_Establishment_Controller_Introduction_Apr89.pdf
>
> According to that publication the AEA Feature was available for all the
> "large" and "medium" 3174 models, but not the "small" 8xx and 9xx models.
>
> For what it's worth, the November 23, 1987, edition of "Network World"
> describes another IBM 3174 competitor: the Harris H174-32L Local Control
> Unit, part of their "Challenger" line. It too included a protocol converter
> to allow IBM 3270 series terminals to "appear" as VT 100 compatible ASCII
> terminals to hosts, and it had RS-232 and RS-422 interfaces (plus some
> other choices) for host attachment, according to the article.
>
> An Ethernet connection might be trickier to get working than the RS-232-C
> interface, although if you can find a single IBM 3174 with both, that'd be
> nice. Token-Ring is another possibility, probably also with some protocol
> difficulty. It's rather easy to find used PCI Token-Ring adapters and IBM
> 8226 MAUs. (The IBM 8228 works too, but the unit and associated cabling are
> much bulkier.)
>
> As another completely different approach to getting genuine, physical IBM
> 3270 series terminals working with command line/VT-100-style Linux (as a
> notable example), hypothetically you could have one or
Re: HSFLOG and HSFTRACE
On our z/OS 2.4 system there's still a SDSFAUX address space. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSFLOG and HSFTRACE
> On our z/OS 2.4 system there's still a SDSFAUX address space. Yes, SDSFAUX remains to execute various data gatherers, XCF communications and so on, but the allocation of HSFLOG and HSFTRACE was moved to the SDSF address space with z/OS 2.3. Ant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tape problem
You can run the CA-1 CTSSYNC utility, to synchronize the TCDB from the TMC. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nai, Dean Sent: 15 January 2020 18:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Tape problem Anyone ever run into a problem where the CA-1 catalog and the volcat seem to be out of sync? We keep getting the below messages and aren’t able to eject tapes. Thought it was 3494 hardware related by IBM doesn’t thing so. Any suggestions? CBR3770I Volume T00xxx misplaced in library TAPELIB1 CBR3769I Misplaced volume T00xxx found in library TAPELIB1 Dean Nai > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tape problem
It's not normally a CA-1 caused problem. This is "normally" caused when tapes are added to the VTS and you forget to update the ROBTY and VENDOR fields so tht when a tape is used (and scratched) that CA-1 can tell the VTS and OAM that it's again available. Someone always forgets to do this at most sites when they add tapes, and it isn't a problem right away because it takes a while for the tapes to come up and be reused. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
