Re: Consolidate Consoles
I realize this is a bit 'out there' but CA's Solve: Operations has something called OCS. – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: 28 November 2017 10:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Consolidate Consoles That is a thought. Tony Thigpen Tom Brennan wrote on 11/27/2017 11:58 PM: > A bit far-fetched, but: > > Create a HLLAPI application that reads a number of minimized ICC > terminal emulators and piles all the console messages into a single > display. Use a different text color for each - just like sysplexed > consoles do. > > For command input, have the operator open that particular emulator > window. That way you avoid HLLAPI code for command input and routing, > and (more importantly) you force the user to focus their attention on > one system. Once the command is entered, minimize the emulator window > and the big HLLAPI application with all the messages shows again. > > Tony Thigpen wrote: >> That is what I initially suggested. Then they said "but can we do it >> with one session window open?" Thus my question. >> >> Tony Thigpen >> >> Porowski, Kenneth wrote on 11/27/2017 04:20 PM: >> >>> A single PC with multiple 3270 sessions to an ICC would work, just >>> get a monitor(s) big enough to see/read all the sessions at the same >>> time. >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List >>> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen >>> Sent: Monday, November 27, 2017 2:58 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: [IBM-MAIN] Consolidate Consoles >>> >>> I have been asked about "Console Consolidation" for our multiple zOS >>> LPARs. Management wants to know what is available that will let us >>> have one display with all the console traffic from 5 LPARs. They are >>> envisioning a PC based solution, but we have the ability to run >>> something on zVM. (These z/OS LPARs are not under z/VM, but we have >>> z/VM on another CPU with NJE interconnection.) >>> >>> Thoughts? >>> -- >>> Tony Thigpen >>> >>> >>> -- 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 MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2 & CICS Training
AFAIK Circle ceased trading and providing training courses in the UK about 10 years ago. But if their CICS/DB2 training courses are still available elsewhere, go for it. BTW I kept in touch with Circle's DB2 lecturer for several years - until he told me that Circle had closed down and that he was now working as an independent consultant. Cheers, Chris Poncelet (retired sysprog consultant) On 27/11/2017 18:10, william janulin wrote: > THEMIS is also a good choice. > > > On Monday, November 27, 2017, 11:25:28 AM EST, Gene Hudders > <00883908b3b7-dmarc-requ...@listserv.ua.edu> wrote: > > Hi: > > You can also get excellent CICS/DB2 trainning at Circle. > > Regards, > Gene > > In a message dated 11/26/2017 1:35:30 PM SA Western Standard Time, > surecha...@gmail.com writes: > > > Dear Venkat > > You can find CICS and Db2 courses at Marist IDCP, Poughkeepsie, NY, U.S. > You may contact Mr. Angelo Corridori in angelo.corrid...@marist.edu. > > Best regards > Suresh Chacko > > Sent from my iPhone > >> On Nov 26, 2017, at 17:58, David Staudacher wrote: >> >> Venkat: Besides the IBM courses Timothy mentioned, there are also several >> good providers listed here: >> http://linkd.in/2arLJqM - Mainframe Education >> ... Circle, Themis and Interskill are all very good. >> >> >> -- >> 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: OS/390 2.5
z13 has 31 bit mode. z14 IPLs in 64 bit mode and cannot run 31 bit Operating systems, z/OS 2.2 SA-ICKDSF, etc. Requires z/OS 2.3 SA-ICKDSF. On Sun, Nov 26, 2017 at 6:51 AM, Mark Wilson wrote: > Hi Folks, > > I have a client who is running OS/390 2.5 and they cannot upgrade their OS > for many reasons, let’s just not go there! > > They have asked what is the latest z Hardware they can use whilst running > OS/390 2.5, but I am struggling to find any info out there at the moment. > > I know its old, unsupported, but we are where we are…. > > So, does anyone know? z9, z10, etc…. > > Mark > > -- > 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
Re: OS/390 2.5
This all comes down to what the site is willing to do for their long term viability. If they are happy with the current release and hardware, and are willing to live with the fact that at some point in time they just won't be able to fix the hardware, then they obviously are welcome to pay IBM for the old software to do that. At some point it will occur to them that they can't function in that environment. They have probably already put off doing "things" that they would like to do (software wise), because the hardware won't support the extra load, or the software can't handle the specific required by the code they want to write. I have learned that you can't force a company who is in the "head in the sand" mode to pull their head out until they are good and ready to do so. Typically all it really takes is pointing out that they can actually save a good chunk of money by doing so, but sometimes even that is not enough. In the end, you can't force them to do anything they don't want to do. I guess it's like having someone who has a substance abuse problem, "you" can't want them out of their condition, they have to want out for themselves. Brian Westerman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Consolidate Consoles
That is a thought. Tony Thigpen Tom Brennan wrote on 11/27/2017 11:58 PM: A bit far-fetched, but: Create a HLLAPI application that reads a number of minimized ICC terminal emulators and piles all the console messages into a single display. Use a different text color for each - just like sysplexed consoles do. For command input, have the operator open that particular emulator window. That way you avoid HLLAPI code for command input and routing, and (more importantly) you force the user to focus their attention on one system. Once the command is entered, minimize the emulator window and the big HLLAPI application with all the messages shows again. Tony Thigpen wrote: That is what I initially suggested. Then they said "but can we do it with one session window open?" Thus my question. Tony Thigpen Porowski, Kenneth wrote on 11/27/2017 04:20 PM: A single PC with multiple 3270 sessions to an ICC would work, just get a monitor(s) big enough to see/read all the sessions at the same time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Consolidate Consoles I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- 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: Consolidate Consoles
A bit far-fetched, but: Create a HLLAPI application that reads a number of minimized ICC terminal emulators and piles all the console messages into a single display. Use a different text color for each - just like sysplexed consoles do. For command input, have the operator open that particular emulator window. That way you avoid HLLAPI code for command input and routing, and (more importantly) you force the user to focus their attention on one system. Once the command is entered, minimize the emulator window and the big HLLAPI application with all the messages shows again. Tony Thigpen wrote: That is what I initially suggested. Then they said "but can we do it with one session window open?" Thus my question. Tony Thigpen Porowski, Kenneth wrote on 11/27/2017 04:20 PM: A single PC with multiple 3270 sessions to an ICC would work, just get a monitor(s) big enough to see/read all the sessions at the same time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Consolidate Consoles I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- 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: Consolidate Consoles
That is what I initially suggested. Then they said "but can we do it with one session window open?" Thus my question. Tony Thigpen Porowski, Kenneth wrote on 11/27/2017 04:20 PM: A single PC with multiple 3270 sessions to an ICC would work, just get a monitor(s) big enough to see/read all the sessions at the same time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Consolidate Consoles I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- 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: My attglobal.net email was moved to att.net
On Mon, 27 Nov 2017 15:51:22 -0500, Sam Golob wrote: > > So both the sbgolob.cbttape.org and sbgolob.att.net addresses are >now valid. > > I'm trying to make it easier to reach out for CBT Tape information, >and to contact me. Thanks for bearing with me. Dealing with this was a >pain in the neck.l. > In the interim, does it help to use an IMAP client supporting Smart Mailboxes such as Thunderbird or Mac Mail.app? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OS/390 2.5
Brian Westerman wrote: >Any way, your client can run OS/390 2.5 on a z800 (not >an 890) which supports OS/390 through z/OS 1.13. The IBM z800 (and z900 for that matter) never officially supported OS/390 2.5. Do you have any anecdotal reports of that particular combination running (and any known caveats)? I can't say I've ever run into that combination. >or get a used z114 instead of the z13s z/OS 2.3, released in September, 2017, requires a zBC12/zEC12 or higher model. z/OS 2.2 is the last release that's compatible with the z114. There's no End of Service date announced yet for z/OS 2.2, but September 30, 2020, would be consistent with prior release lifecycles. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CF REPORT
z/OS is only using about half the subchannels that you defined (to mitigate path busy conditions). I don't think you have a subchannel issue. Your sync times are very nice. Your async times are horrific. That is most likely the problem. Async completion time is influenced by such things as distance to the CF, processing time in the CF, and the time it takes z/OS to become aware of and process the request completion. The good sync times push me towards thinking that the issue is with back end completion on the z/OS host side. I'd look at things that would influence the ability of the z/OS host to process work. Shared CPs? Appropriate LPAR weights? that sort of thing. If running on zBC12/zEC12 or later hardware, I'd make sure that the XCF functions switch for COUPLINGTHININT is ENABLED. Mark A Brooks z/OS Sysplex Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Consolidate Consoles
A single PC with multiple 3270 sessions to an ICC would work, just get a monitor(s) big enough to see/read all the sessions at the same time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Consolidate Consoles I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- 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: Consolidate Consoles
Correction: OSA/ICC will not do (what my understanding of what the OP posted) wants. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Monday, November 27, 2017 2:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Consolidate Consoles How do you *know* what the OP wants? All he said was " Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs." That could mean almost anything including 5 PCOM emulator windows on the same PC. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Monday, November 27, 2017 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Consolidate Consoles **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** OSA/ICC will not do what the OP wants. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Monday, November 27, 2017 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Consolidate Consoles OSAICC? https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.ioaq100%2Fioaq10012.htm&data=02%7C01%7Callan.staller%40HCL.COM%7C6606c0cdbd534756449e08d535d279d5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636474100485648328&sdata=NmNftHuI3a2w%2BsaVRVjDrGHEhhpA4V35u%2F7QCWADf64%3D&reserved=0 You don’t mention what your configuration is.You also don’t say if you want 5 different consoles running on the same PC? Or output from 5 systems combined into one? 5 systems in the same sysplex? _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Consolidate Consoles **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying,
My attglobal.net email was moved to att.net
Hi Folks, To write to me about CBT Tape information, the proper email address is: sbgo...@cbttape.org. My attglobal.net email went away, and all emails sent there, are now lost. But I was able to replace it with: sbgo...@att.net. So both the sbgolob.cbttape.org and sbgolob.att.net addresses are now valid. I'm trying to make it easier to reach out for CBT Tape information, and to contact me. Thanks for bearing with me. Dealing with this was a pain in the neck. I think that AT&T is trying to get rid of the attglobal.net domain altogether. Now I have to try and change all the references in the CBT Tape documentation (yecch). So at least this message gives you a heads-up. My cbttape.org email address is pointed to, on the home page of www.cbttape.org, as is Sam Knutson's email. All the best of everything to all of you. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Consolidate Consoles
Then I would assume BMC's MainView CM solution - or the SuperVision solution could help http://www.secureagent.com/SV-index.htm Carmen - Original Message - From: "Tony Thigpen" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, November 27, 2017 2:08:07 PM Subject: Re: Consolidate Consoles We are currently not set up as a sysplex. And, don't really want to. Tony Thigpen John McKown wrote on 11/27/2017 03:03 PM: > On Mon, Nov 27, 2017 at 1:58 PM, Tony Thigpen wrote: > >> I have been asked about "Console Consolidation" for our multiple zOS >> LPARs. Management wants to know what is available that will let us have one >> display with all the console traffic from 5 LPARs. They are envisioning a >> PC based solution, but we have the ability to run something on zVM. (These >> z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE >> interconnection.) >> >> Thoughts? > > > The simplest way is to have all your LPARs in a single sysplex. That > automatically makes messages from every LPAR available to every other > LPAR. If you run a parallel sysplex, then, as Allan said, use OPERLOG > instead of SYSLOG for recording. > > >> -- >> Tony Thigpen >> >> > -- 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: Consolidate Consoles
How do you *know* what the OP wants? All he said was " Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs." That could mean almost anything including 5 PCOM emulator windows on the same PC. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Monday, November 27, 2017 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Consolidate Consoles **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** OSA/ICC will not do what the OP wants. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Monday, November 27, 2017 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Consolidate Consoles OSAICC? https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.ioaq100%2Fioaq10012.htm&data=02%7C01%7Callan.staller%40HCL.COM%7C6606c0cdbd534756449e08d535d279d5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636474100485648328&sdata=NmNftHuI3a2w%2BsaVRVjDrGHEhhpA4V35u%2F7QCWADf64%3D&reserved=0 You don’t mention what your configuration is.You also don’t say if you want 5 different consoles running on the same PC? Or output from 5 systems combined into one? 5 systems in the same sysplex? _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Consolidate Consoles **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, pleas
Re: Consolidate Consoles
OSA/ICC will not do what the OP wants. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Monday, November 27, 2017 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Consolidate Consoles OSAICC? https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.ioaq100%2Fioaq10012.htm&data=02%7C01%7Callan.staller%40HCL.COM%7C6606c0cdbd534756449e08d535d279d5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636474100485648328&sdata=NmNftHuI3a2w%2BsaVRVjDrGHEhhpA4V35u%2F7QCWADf64%3D&reserved=0 You don’t mention what your configuration is.You also don’t say if you want 5 different consoles running on the same PC? Or output from 5 systems combined into one? 5 systems in the same sysplex? _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Consolidate Consoles **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Consolidate Consoles
along those same lines we use SuperVision consoles, ICC interface to the server, and client connections to the consoles, I've consolidated the consoles down to one NIP (master by name only) for each system and one alternate. you can use one of their console controllers and your own emulator if you like , you don't have to use the server/client setup, but it's more secure, LDAP mananged http://www.secureagent.com/supervision-a.htm Carmen - Original Message - From: "Rob Jackson" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, November 27, 2017 2:10:26 PM Subject: Re: Consolidate Consoles We have BMC's MainView CM, a very nice product that provides console consolidation, LDAP-controlled operator logons, command auditing, and automation (it interfaces with the HMC, as well). We run it on RHEL on x86, though I believe you could run it on any Linux. First Tennessee Bank Mainframe Technical Support 1638 Robert C Jackson Dr Maryville, TN 37801 O: 865-977-5343 C: 334-201-8516 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Consolidate Consoles [External Email] I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- 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: Consolidate Consoles
We have BMC's MainView CM, a very nice product that provides console consolidation, LDAP-controlled operator logons, command auditing, and automation (it interfaces with the HMC, as well). We run it on RHEL on x86, though I believe you could run it on any Linux. First Tennessee Bank Mainframe Technical Support 1638 Robert C Jackson Dr Maryville, TN 37801 O: 865-977-5343 C: 334-201-8516 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Consolidate Consoles [External Email] I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Consolidate Consoles
We are currently not set up as a sysplex. And, don't really want to. Tony Thigpen John McKown wrote on 11/27/2017 03:03 PM: On Mon, Nov 27, 2017 at 1:58 PM, Tony Thigpen wrote: I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? The simplest way is to have all your LPARs in a single sysplex. That automatically makes messages from every LPAR available to every other LPAR. If you run a parallel sysplex, then, as Allan said, use OPERLOG instead of SYSLOG for recording. -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Consolidate Consoles
OSAICC? https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ioaq100/ioaq10012.htm You don’t mention what your configuration is.You also don’t say if you want 5 different consoles running on the same PC? Or output from 5 systems combined into one? 5 systems in the same sysplex? _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Consolidate Consoles **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Consolidate Consoles
On Mon, Nov 27, 2017 at 1:58 PM, Tony Thigpen wrote: > I have been asked about "Console Consolidation" for our multiple zOS > LPARs. Management wants to know what is available that will let us have one > display with all the console traffic from 5 LPARs. They are envisioning a > PC based solution, but we have the ability to run something on zVM. (These > z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE > interconnection.) > > Thoughts? The simplest way is to have all your LPARs in a single sysplex. That automatically makes messages from every LPAR available to every other LPAR. If you run a parallel sysplex, then, as Allan said, use OPERLOG instead of SYSLOG for recording. > -- > Tony Thigpen > > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Consolidate Consoles
SYSTEM LOGGER (operlog) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 27, 2017 1:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Consolidate Consoles I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Consolidate Consoles
I have been asked about "Console Consolidation" for our multiple zOS LPARs. Management wants to know what is available that will let us have one display with all the console traffic from 5 LPARs. They are envisioning a PC based solution, but we have the ability to run something on zVM. (These z/OS LPARs are not under z/VM, but we have z/VM on another CPU with NJE interconnection.) Thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEFACTRT and flowerbox with excp consolidation
Does anyone have an IEFACTRT exit, that produces a flower box AND processes all the smf30 extension records for when DDCONS is set to NO, so we just get one total for all the EXCP's done to each DDNAME? I've tried the ones on the CBT tape, and none of them seem to do that. Thank, Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shocking Bug in Latest PCOMM Release
On 11/27/2017 6:00 AM, Greg Price wrote: On 2017-11-27 7:00 AM, Seymour J Metz wrote: What is "GDDM graphics", APA or PSS? "All Points Addressable" and "Programmable Symbol Sets" are what I take these acronyms (initializations?) to mean. PCOMM refers to these as: 1. "Vector Graphics" where you specify either "native" or "advanced" and ... 2. "Programmed Symbols" where you provide a cell type of "automatic" or "fixed" (with a cell size such as 9x16). I have used vector graphics quite a bit in RMF output and have had customers show me how they do as well. Our products leverage graphics escape characters, but not PS or vector graphics. We might, if they were more readily available. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OS/390 2.5
On 11/27/2017 5:57 AM, Peter Relson wrote: I don't know the official answer, but a way to guesstimate a quasi-sane answer: Pick whatever machine was made available 3 years after OS/390 2.5 became available. Any machine available after that would most likely not have had any exploitation support provided as far back as a release 3 years old, but might have had toleration support. Add another 3 years and come up with that machine and you'll likely not have had toleration support either as far back as OS/390 2.5. My recollection is that the two-tier TLB was the major change that broke stuff. Back in the day, z/VM used to do a good job hiding that difference (and perhaps others) from the older operating systems that couldn't cope... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OS/390 2.5
On 11/26/2017 9:59 PM, Timothy Sipples wrote: Unofficially, there was a report back in 2009 in this forum that OS/390 2.4 IPL'ed under z/VM 5.3 on an IBM z990 machine. There were some restrictions (512MB memory or less, 1 CP only, and a special z/VM setting). That might have been from me. We ran, and continue to run, old operating systems using z/VM as a bridge to our newer hardware (at the moment z13s). Our policy is to go back only ten years, so OS/390 2.5 fell off our RADAR long ago... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shocking Bug in Latest PCOMM Release
Have to many users that are dieing on V12.0.2 They still have not added the update to Fix Central. :( On Wed, Nov 22, 2017 at 10:27 AM, Ed Jaffe wrote: > On 11/21/2017 7:36 PM, Ed Jaffe wrote: > >> This problem is not caused by a messed up keyboard map. Incredibly, the >> DEL key simply does not work any more! >> > > I opened a PMR and IBM was able to identify and fix the problem overnight. > I installed an updated pcskbd.dll this morning and all is well. > > Still shocked that I was the first to discover something so incredibly > fundamental! It proves to me beyond a shadow of a doubt that not a single > mainframe programmer actually *used* this product before it shipped... > > I'll let you know when I get a real APAR number (or whatever passes for an > APAR in this "loosy goosey" off-platform DevOps programming world...) > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2 & CICS Training
THEMIS is also a good choice. On Monday, November 27, 2017, 11:25:28 AM EST, Gene Hudders <00883908b3b7-dmarc-requ...@listserv.ua.edu> wrote: Hi: You can also get excellent CICS/DB2 trainning at Circle. Regards, Gene In a message dated 11/26/2017 1:35:30 PM SA Western Standard Time, surecha...@gmail.com writes: Dear Venkat You can find CICS and Db2 courses at Marist IDCP, Poughkeepsie, NY, U.S. You may contact Mr. Angelo Corridori in angelo.corrid...@marist.edu. Best regards Suresh Chacko Sent from my iPhone > On Nov 26, 2017, at 17:58, David Staudacher wrote: > > Venkat: Besides the IBM courses Timothy mentioned, there are also several > good providers listed here: > http://linkd.in/2arLJqM - Mainframe Education > ... Circle, Themis and Interskill are all very good. > > > -- > 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: Shocking Bug in Latest PCOMM Release
Silly me; I thought that IND$FILE had been replaced by WSA, or some combination of FTP, SFTP and WSA. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Elardus Engelbrecht Sent: Monday, November 27, 2017 3:26 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Shocking Bug in Latest PCOMM Release Tom Brennan wrote: >Well, I said the same thing about IND$FILE back in 1998, thinking it would be >totally replaced by FTP. I was certainly wrong about that! Today I think >people use IND$FILE more than ever for smaller file transfers. ... and FTP is supposed to be replaced by SFTP or FTPS ... but I could be wrong! ;-) >And there are folks like you without FTP available - I know how that is, >logging on to a customer's mainframe and needing to upload something like >SHOWMVS. It is indeed a PITA, especially if that customer's firewall and network settings block you to enter the mainframe. Groete / Greetings Elardus Engelbrecht -- 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: OS/390 2.5
On Mon, Nov 27, 2017 at 11:49 AM, retired mainframer < retired-mainfra...@q.com> wrote: > It must be nice to be able to tell a customer you don't need their > business. > > ROI - It depends on how much the customer is willing to pay you to keep from paying IBM for the upgrade. If they have a system which "just works" for them, and they have no strategic direction for the "mainframe", then perhaps paying to maintain the old software is worth it to them. However, I am confused as to why they would want to invest in a new machine but not invest in new OS software, but Mark said "just don't go there"; so I won't. Perhaps, as I recall from many years ago about a DOS shop (sysprog basically rewrote 80% of it), they have so modified OS/390 2.6 that it is no longer recognizable as OS/390. -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OS/390 2.5
It must be nice to be able to tell a customer you don't need their business. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Beverly Caldwell > Sent: Monday, November 27, 2017 8:28 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: OS/390 2.5 > > Why would you even waste your time with these idiots, Mark ? They have > screwed themselves into the ground. > > You can bet your boots the same team of management clowns who brought this > situation about are still in control. So I would pitch them a complete > upgrade to the latest software and hardware, cost it all out and tell them > this is what you will have to pay to get yourselves out of this hole. > > Any technical fix is only going to be temporary and will only prolong the > situation, doing nothing to solve the basic problem. > > You could maybe find a more polite way of putting it. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Graphic output on the mainframe
Or was that the 3179G? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Monday, November 27, 2017 12:24 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Graphic output on the mainframe I believe that the 3279G used APA rather than PSS; GDDM supports both. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 LinkedIn as sme...@gmu.edu From: IBM Mainframe Discussion List on behalf of Bernd Oppolzer Sent: Monday, November 27, 2017 9:51 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Graphic output on the mainframe Maybe dump question: would a manual describing all the GDDM calls (from Fortran, for example), be sufficient? Or is a lower level of definition needed? Is GDDM the only way to access the graphic functions of the 3279 G graphic displays? I recall that I had some problems in the 1980s, because GDDM expected for all function calls that the leftmost bit be set on the last parameter address, which Pascal didn't; so I had to build ASSEMBLER glue functions for every GDDM function which inserted the missing leftmost bit at the position of the last parameter address. This was expected by GDDM, although the number of parameters was fixed. I had a GDDM manual at that time which contained descriptions for all GDDM functions; IIRC independent of the calling language (the "normal" calling languages were Fortran and ASSEMBLER, obviously ... both using call by reference; because Pascal supports call by value, too, setting the high order bit in the parameter list is normally not a good idea). But this GDDM manual is long gone ... sadly. Kind regards Bernd Am 27.11.2017 um 15:17 schrieb Greg Price: > On 2017-11-27 7:22 PM, Bernd Oppolzer wrote: >> run on my 3279 G display > > And this time I'll get straight to the point. > > I would pay money for a 3179-G manual. > > Why? > > Because while using programmed symbols is documented in a current > manual, using 3270 vector graphics is not. > > It used to be documented in the relevant hardware component manuals, > but since those pieces of hardware are no longer marketed, the manuals > have disappeared. > > So how would TN3270 client writers figure out how to support vector > graphics? Probably with a lot of VTAM traces of GDDM applications' > TPUT traffic. > > Anyway, just sayin'. > > BTW, did I mention that after 10 years, I'm out of IBM since the end > of last August? I wonder if they didn't think I was trendy or "with > it" enough. With my interest in bleeding edge technologies like 3270 > graphics, that can't be right. Never mind blockchain - I say let's > think block-mode terminals! > > :/ > > Cheers, > Greg -- 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: OS/390 2.5
You can't IPL any 24-bit operating system on a machine that doesn't support S/370 mode; it's not just the addressing, but also the I/O. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of PINION, RICHARD W. Sent: Monday, November 27, 2017 9:05 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: OS/390 2.5 So you are saying I can't IPL OS/360 on our z13 :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Monday, November 27, 2017 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 2.5 [External Email] I don't know the official answer, but a way to guesstimate a quasi-sane answer: Pick whatever machine was made available 3 years after OS/390 2.5 became available. Any machine available after that would most likely not have had any exploitation support provided as far back as a release 3 years old, but might have had toleration support. Add another 3 years and come up with that machine and you'll likely not have had toleration support either as far back as OS/390 2.5. That would then be the machine that you should not be at all surprised if OS/390 2.5 did not run on. Although I suppose it is possible (I do not recall) that back then we provided support "further back" when a new machine came along. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- 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: Mainframe Branding Insanity
Mark: You may be right, but I had also complained that the special characters even in the manual names were a real nuisance. Do a download, open it, try to cut and paste the title and you had to remove all the special characters. Maybe they ran into this elsewhere and finally said, lets get the special characters out of it. Bill From: IBM Mainframe Discussion List on behalf of Mark Regan Sent: Monday, November 27, 2017 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fwd: Mainframe Branding Insanity https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fenterprisesystemsmedia.com%2Farticle%2Fbranding-insanity%23When%3A14%3A05%3A00Z&data=02%7C01%7CHarry_Wahl%40HOTMAIL.COM%7Cd3207115a11b42893ef808d535a5a49a%7C84df9e7fe9f640afb435%7C1%7C0%7C636473907909329881&sdata=9I1SB4%2BWtwX3bANhkoM4QmpgRqUD4N5oVc1ZRz%2B8puI%3D&reserved=0 -- Regards, Mark T. Regan -- 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: Graphic output on the mainframe (was: Shocking Bug in Latest PCOMM Release)
On 11/27/2017 10:18 AM, Dave Jones wrote: I would like to see x3270 support GDDM graphics. Did you ever write to Paul about that? -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Graphic output on the mainframe
I believe that the 3279G used APA rather than PSS; GDDM supports both. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Bernd Oppolzer Sent: Monday, November 27, 2017 9:51 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Graphic output on the mainframe Maybe dump question: would a manual describing all the GDDM calls (from Fortran, for example), be sufficient? Or is a lower level of definition needed? Is GDDM the only way to access the graphic functions of the 3279 G graphic displays? I recall that I had some problems in the 1980s, because GDDM expected for all function calls that the leftmost bit be set on the last parameter address, which Pascal didn't; so I had to build ASSEMBLER glue functions for every GDDM function which inserted the missing leftmost bit at the position of the last parameter address. This was expected by GDDM, although the number of parameters was fixed. I had a GDDM manual at that time which contained descriptions for all GDDM functions; IIRC independent of the calling language (the "normal" calling languages were Fortran and ASSEMBLER, obviously ... both using call by reference; because Pascal supports call by value, too, setting the high order bit in the parameter list is normally not a good idea). But this GDDM manual is long gone ... sadly. Kind regards Bernd Am 27.11.2017 um 15:17 schrieb Greg Price: > On 2017-11-27 7:22 PM, Bernd Oppolzer wrote: >> run on my 3279 G display > > And this time I'll get straight to the point. > > I would pay money for a 3179-G manual. > > Why? > > Because while using programmed symbols is documented in a current > manual, using 3270 vector graphics is not. > > It used to be documented in the relevant hardware component manuals, > but since those pieces of hardware are no longer marketed, the manuals > have disappeared. > > So how would TN3270 client writers figure out how to support vector > graphics? Probably with a lot of VTAM traces of GDDM applications' > TPUT traffic. > > Anyway, just sayin'. > > BTW, did I mention that after 10 years, I'm out of IBM since the end > of last August? I wonder if they didn't think I was trendy or "with > it" enough. With my interest in bleeding edge technologies like 3270 > graphics, that can't be right. Never mind blockchain - I say let's > think block-mode terminals! > > :/ > > Cheers, > Greg -- 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: Graphic output on the mainframe (was: Shocking Bug in Latest PCOMM Release)
I would like to see x3270 support GDDM graphics. It would come in handy viewing the GDDM graphics displays the IBM Performance Toolkit for z/VM produces now without having the extra hassle of making a csv file, downloading it to Excel and making a graph there. DJ David Jones | Managing Director for zSystems Services | z/VM, Linux, and Cloud 703.237.7370 (Office) | 281.578.7544 (Cell) Information Technology Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Mainframe Branding Insanity
On Mon, Nov 27, 2017 at 10:31 AM, Doug Fuerst wrote: > Welcome to the new Ginny Rometty IBM. She should have been canned years > ago. Perhaps caned as well. > > > Doug Fuerst > 718.921.2620 (O) > 917.572.7364 (C) > d...@bkassociates.net > > > > > -- Original Message -- > From: "Mark Regan" > To: IBM-MAIN@listserv.ua.edu > Sent: 27-Nov-17 9:45:31 AM > Subject: Fwd: Mainframe Branding Insanity > > http://enterprisesystemsmedia.com/article/branding-insanity#When:14:05:00Z >> >> -- >> >> Regards, >> >> Mark T. Regan >> >> -- >> 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 > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Mainframe Branding Insanity
Welcome to the new Ginny Rometty IBM. She should have been canned years ago. Doug Fuerst 718.921.2620 (O) 917.572.7364 (C) d...@bkassociates.net -- Original Message -- From: "Mark Regan" To: IBM-MAIN@listserv.ua.edu Sent: 27-Nov-17 9:45:31 AM Subject: Fwd: Mainframe Branding Insanity http://enterprisesystemsmedia.com/article/branding-insanity#When:14:05:00Z -- Regards, Mark T. Regan -- 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: OS/390 2.5
Why would you even waste your time with these idiots, Mark ? They have screwed themselves into the ground. You can bet your boots the same team of management clowns who brought this situation about are still in control. So I would pitch them a complete upgrade to the latest software and hardware, cost it all out and tell them this is what you will have to pay to get yourselves out of this hole. Any technical fix is only going to be temporary and will only prolong the situation, doing nothing to solve the basic problem. You could maybe find a more polite way of putting it. On Mon, Nov 27, 2017 at 8:44 AM, John McKown wrote: > On Mon, Nov 27, 2017 at 8:05 AM, PINION, RICHARD W. < > rpin...@firsttennessee.com> wrote: > > > So you are saying I can't IPL OS/360 on our z13 :) > > > > Not without an "RPQ". I remember back in the 1980s when Braniff Airways > (now defunct) was running OS/MVT on a 3033. It only ran because IBM wrote > special patches to allow it. These patches were only available via an "RPQ" > (Request for Price Quotation?). > > Given that all the current IBMZ machines are basically "millicoded", I can > imagine that it is _theoretically_ possible to have an a number of MCL > variants which could implement almost any level of architecture. Of course, > if marketing tried this, I would guess that they would be subject to a > "dark ops" strike from the hardware engineers. > > > -- > I have a theory that it's impossible to prove anything, but I can't prove > it. > > Maranatha! <>< > John McKown > > -- > 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: DB2 & CICS Training
Hi: You can also get excellent CICS/DB2 trainning at Circle. Regards, Gene In a message dated 11/26/2017 1:35:30 PM SA Western Standard Time, surecha...@gmail.com writes: Dear Venkat You can find CICS and Db2 courses at Marist IDCP, Poughkeepsie, NY, U.S. You may contact Mr. Angelo Corridori in angelo.corrid...@marist.edu. Best regards Suresh Chacko Sent from my iPhone > On Nov 26, 2017, at 17:58, David Staudacher wrote: > > Venkat: Besides the IBM courses Timothy mentioned, there are also several > good providers listed here: > http://linkd.in/2arLJqM - Mainframe Education > ... Circle, Themis and Interskill are all very good. > > > -- > 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
My attglobal.net email address has disappeared
Hi Folks, When writing to me (Sam Golob), please do not use my attglobal.net email address. It has disappeared, and it isn't coming back. Instead, please use sbgo...@cbttape.org to write to me. I now have the large job of removing this address from the entire CBT Tape. I'll let you know if I get another address instead of this one, but the sbgo...@cbttape.org address is the one to use. Please update your own information and your own records about writing to me. Thanks much. All the best of everything to all of you. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fwd: Mainframe Branding Insanity
>Obviously some PHB (Dilbert) managers think they justify their existence by change -- any change. Now, if you compare IBM managers to PHB, this makes PHB look like a brilliant manager. I remember a cartoon from quite some time a go. PHB said to Dilbert: "I think we need a new database". Uh, oh, thought Dilbert and ask the PHB what color it should be? PHB answered that "Mauve seems to be just about right". -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Mainframe Branding Insanity
On 11/27/2017 08:45 AM, Mark Regan wrote: > http://enterprisesystemsmedia.com/article/branding-insanity#When:14:05:00Z > Obviously some PHB (Dilbert) managers think they justify their existence by change -- any change. The world would be a better place with people in corporate management positions that care and know more about the product they make and their customer base and less about generalized marketing and management strategies. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Graphic output on the mainframe
Am 27.11.2017 um 15:54 schrieb David Crayford: On 27/11/2017 10:51 PM, Bernd Oppolzer wrote: Maybe dump question: That's a very mainframe Freudian slip ;) Indeed, I had a good laugh myself, when your answer came in ... it was not only a typo on my side. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Graphic output on the mainframe
On 27/11/2017 10:51 PM, Bernd Oppolzer wrote: Maybe dump question: That's a very mainframe Freudian slip ;) would a manual describing all the GDDM calls (from Fortran, for example), be sufficient? Or is a lower level of definition needed? Is GDDM the only way to access the graphic functions of the 3279 G graphic displays? I recall that I had some problems in the 1980s, because GDDM expected for all function calls that the leftmost bit be set on the last parameter address, which Pascal didn't; so I had to build ASSEMBLER glue functions for every GDDM function which inserted the missing leftmost bit at the position of the last parameter address. This was expected by GDDM, although the number of parameters was fixed. I had a GDDM manual at that time which contained descriptions for all GDDM functions; IIRC independent of the calling language (the "normal" calling languages were Fortran and ASSEMBLER, obviously ... both using call by reference; because Pascal supports call by value, too, setting the high order bit in the parameter list is normally not a good idea). But this GDDM manual is long gone ... sadly. Kind regards Bernd Am 27.11.2017 um 15:17 schrieb Greg Price: On 2017-11-27 7:22 PM, Bernd Oppolzer wrote: run on my 3279 G display And this time I'll get straight to the point. I would pay money for a 3179-G manual. Why? Because while using programmed symbols is documented in a current manual, using 3270 vector graphics is not. It used to be documented in the relevant hardware component manuals, but since those pieces of hardware are no longer marketed, the manuals have disappeared. So how would TN3270 client writers figure out how to support vector graphics? Probably with a lot of VTAM traces of GDDM applications' TPUT traffic. Anyway, just sayin'. BTW, did I mention that after 10 years, I'm out of IBM since the end of last August? I wonder if they didn't think I was trendy or "with it" enough. With my interest in bleeding edge technologies like 3270 graphics, that can't be right. Never mind blockchain - I say let's think block-mode terminals! :/ Cheers, Greg -- 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: Graphic output on the mainframe
Maybe dump question: would a manual describing all the GDDM calls (from Fortran, for example), be sufficient? Or is a lower level of definition needed? Is GDDM the only way to access the graphic functions of the 3279 G graphic displays? I recall that I had some problems in the 1980s, because GDDM expected for all function calls that the leftmost bit be set on the last parameter address, which Pascal didn't; so I had to build ASSEMBLER glue functions for every GDDM function which inserted the missing leftmost bit at the position of the last parameter address. This was expected by GDDM, although the number of parameters was fixed. I had a GDDM manual at that time which contained descriptions for all GDDM functions; IIRC independent of the calling language (the "normal" calling languages were Fortran and ASSEMBLER, obviously ... both using call by reference; because Pascal supports call by value, too, setting the high order bit in the parameter list is normally not a good idea). But this GDDM manual is long gone ... sadly. Kind regards Bernd Am 27.11.2017 um 15:17 schrieb Greg Price: On 2017-11-27 7:22 PM, Bernd Oppolzer wrote: run on my 3279 G display And this time I'll get straight to the point. I would pay money for a 3179-G manual. Why? Because while using programmed symbols is documented in a current manual, using 3270 vector graphics is not. It used to be documented in the relevant hardware component manuals, but since those pieces of hardware are no longer marketed, the manuals have disappeared. So how would TN3270 client writers figure out how to support vector graphics? Probably with a lot of VTAM traces of GDDM applications' TPUT traffic. Anyway, just sayin'. BTW, did I mention that after 10 years, I'm out of IBM since the end of last August? I wonder if they didn't think I was trendy or "with it" enough. With my interest in bleeding edge technologies like 3270 graphics, that can't be right. Never mind blockchain - I say let's think block-mode terminals! :/ Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fwd: Mainframe Branding Insanity
http://enterprisesystemsmedia.com/article/branding-insanity#When:14:05:00Z -- Regards, Mark T. Regan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OS/390 2.5
On Mon, Nov 27, 2017 at 8:05 AM, PINION, RICHARD W. < rpin...@firsttennessee.com> wrote: > So you are saying I can't IPL OS/360 on our z13 :) > Not without an "RPQ". I remember back in the 1980s when Braniff Airways (now defunct) was running OS/MVT on a 3033. It only ran because IBM wrote special patches to allow it. These patches were only available via an "RPQ" (Request for Price Quotation?). Given that all the current IBMZ machines are basically "millicoded", I can imagine that it is _theoretically_ possible to have an a number of MCL variants which could implement almost any level of architecture. Of course, if marketing tried this, I would guess that they would be subject to a "dark ops" strike from the hardware engineers. -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shocking Bug in Latest PCOMM Release
Hi Greg! Yes, with your help I did get the LPS functions going years ago in what I called V1.25. It seemed fine until some people I worked with started using it for SAS graphs and found errors. I spent a lot of time trying to figure out what I was doing wrong, and then (sorry) kind of decided there just wasn't enough call for it. And I you're right around Win 7 time. With early Vista TN3270 I wanted to go against the grain (and even MS standards) and pile everything in one directory. That included exe, dll, support, and even parameter files which were regularly updated by the user. The objective was to be able to copy/backup one directory and have everything. Win 7 spoiled that by enforcing the MS standards. Regards, Tom Greg Price wrote: But Tom has serious paying customers who don't really care for what I may or may not want in a TN3270 client and so I gather that these code changes were more of a prototype quality rather than production quality code and so were not copied into the product's code base used going forward. (Tom can correct me here if I have any of this wrong, of course.) I think it was Win7 that introduced the Program Data directory, yes? Anyway, Tom had to make a change to Vista so it was a happy Win7 citizen (IIRC). The net result of the new directory paradigm was that it was a pain to use the 1.25 version under Win7 and later so I gave it away in the end. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Graphic output on the mainframe
On 2017-11-27 7:22 PM, Bernd Oppolzer wrote: run on my 3279 G display And this time I'll get straight to the point. I would pay money for a 3179-G manual. Why? Because while using programmed symbols is documented in a current manual, using 3270 vector graphics is not. It used to be documented in the relevant hardware component manuals, but since those pieces of hardware are no longer marketed, the manuals have disappeared. So how would TN3270 client writers figure out how to support vector graphics? Probably with a lot of VTAM traces of GDDM applications' TPUT traffic. Anyway, just sayin'. BTW, did I mention that after 10 years, I'm out of IBM since the end of last August? I wonder if they didn't think I was trendy or "with it" enough. With my interest in bleeding edge technologies like 3270 graphics, that can't be right. Never mind blockchain - I say let's think block-mode terminals! :/ Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shocking Bug in Latest PCOMM Release
LOL - at 06:15 with everyone else still sleeping. Elardus Engelbrecht wrote: ... and FTP is supposed to be replaced by SFTP or FTPS ... but I could be wrong! ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OS/390 2.5
So you are saying I can't IPL OS/360 on our z13 :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Monday, November 27, 2017 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 2.5 [External Email] I don't know the official answer, but a way to guesstimate a quasi-sane answer: Pick whatever machine was made available 3 years after OS/390 2.5 became available. Any machine available after that would most likely not have had any exploitation support provided as far back as a release 3 years old, but might have had toleration support. Add another 3 years and come up with that machine and you'll likely not have had toleration support either as far back as OS/390 2.5. That would then be the machine that you should not be at all surprised if OS/390 2.5 did not run on. Although I suppose it is possible (I do not recall) that back then we provided support "further back" when a new machine came along. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shocking Bug in Latest PCOMM Release
On 2017-11-27 7:00 AM, Seymour J Metz wrote: What is "GDDM graphics", APA or PSS? "All Points Addressable" and "Programmable Symbol Sets" are what I take these acronyms (initializations?) to mean. You could say that "GDDM graphics" is graphics performed by employing calls to GDDM. If displaying the graphics on a TSO 3270 terminal, then GDDM will employ one of PSS (really raster graphics - the original 3270 graphics) or what I call "native 3270 vector graphics" (no programmed symbols here - first supported by the 3179G I believe) or the even newer "enhanced PC handshaking vector graphics" implemented in the data stream after PCs pretending to be 3270 terminals became widespread. (The "PC handshaking" as I call it, was known as DOSLINK, then later on as OS2LINK, then as PCLK, and was not used with any real 3270 hardware, AFAIK.) Typically, the TSO terminal will only fully support one of these. The support for these can be determined by an application from the response to a Read Partition (Query). PCOMM3270 allows you to enable any one or none of these 3 3270 graphics options. In a sense, PSS does provide APA, it could be argued. Once you have the ability to specify the illumination of each pixel in any of the supported colors (ok, I want to say colours) independently from the illumination of any other pixel, you effectively have APA. (The 3179G which supported vector graphics did also support single-plane programmed symbols - meaning monochrome - whereas only triple-plane programmed symbols can provide multiple colours in a single character.) But really, with each symbol, you are specifying how a character display location is used whenever that symbol is displayed. This is very efficient (I think) if you have symbols that you are going to reuse because you can specify (load) them once and then reuse them many times with relatively small overhead. In practice, what were they used for? Diagrams? Text with custom symbols? I think mainly for graphs and charts - probably mainly from MVS performance data. There may well have been many other uses by applications, but I think it was MVS performance folks who were the majority of users. So how do you make a graph or chart? Well, I would make a big rectangle of pixels into which I would project the chart, and then I would map each 9x16 (or 8x10 or 10x8 or whatever the terminal - screen or printer - used) cell and load each symbol into consecutive codes points and then after the symbols were loaded then I would switch to that character set and display those points: x'4142434445446...FCFDFEFF' and then switch to the next character set and display those and so on until the whole chart was on display. Or for vector graphics, you could effectively display a bitmap by sending rows of pixels - again the single plane (monochrome - meaning you choose the 1 3270 colour to use) or triple-plane (RGB - really GRB for 3270) concepts apply. Anyway, enough of my waffle. Most of what I know about 3270 graphics is described here: http://www.prycroft6.com.au/misc/3270grfx.html I am hardly a world authority on the topic, so if you spot anything which needs to be corrected then please let me know - preferably with the correction to be made. :) Recently I optimized the REVIEW display of pictures using programmed symbols where LPS recycle did not occur, and so I may have broken the display where LPS recycle did occur (ie. larger pictures) so if there is a bug in that which you would like fixed, give the relevant test conditions and I'll try to have a look at it. REVIEW employs 3270 graphics to - display PCX files - display BMP files - display GIF files - don't do JPEGs because I don't understand how to decode them - assembler code donations welcome. Programmed symbol and native vector graphics terminals are supported by assembler invocations of TPUT. "PC handshaking" graphics is supported by calling GDDM. In RFE (REVIEW Front End - poor man's PDF for use when ISPF is broken or not present) when a specific volume is selected in option 3.4 at the bottom of the data set list when geometry suits and programmed symbols are supported, a row of graphics is displayed depicting the space usage of the volume, where each vertical slice of pixels represents 1 cylinder. That is, the scale is 1 pixel per track. Tracks addressed by the same head are in the same horizontal line of pixels. Colour code indicates use. (eg. white=VTOC, green=DSCB1/DSCB8 descriptors, yellow=DSCB3 descriptors, red=tracks in more than 1 extent (error) etc.) For completeness I'll mention that the RFE main menu uses programmed symbols under MVS/370 to display: - virtual storage page assignment - UIC frame population bar graph - real storage frame assignment. The colour codes are documented in the TSO HELP member for the RFE command. If you want to look at REVIEW, go ahead, but do not install releases 47.5 to 47.7 into produc
Re: OS/390 2.5
I don't know the official answer, but a way to guesstimate a quasi-sane answer: Pick whatever machine was made available 3 years after OS/390 2.5 became available. Any machine available after that would most likely not have had any exploitation support provided as far back as a release 3 years old, but might have had toleration support. Add another 3 years and come up with that machine and you'll likely not have had toleration support either as far back as OS/390 2.5. That would then be the machine that you should not be at all surprised if OS/390 2.5 did not run on. Although I suppose it is possible (I do not recall) that back then we provided support "further back" when a new machine came along. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: jes2 HASP003 RC = (84)
Q1) - See answer for Q3 Q2) - Not necessary Q3) - Check the JES parameter PCEDEF and increase the number of processors. ISTR it requires a minimum of a JES HOT START. Check the fine manuals. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ibmm...@foxmail.com Sent: Thursday, November 23, 2017 5:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: jes2 HASP003 RC = (84) Hi all There are 12 members in the sysplex(NP1A-NP1M) At 15:41:46 this afternoon,SA issue " $ CO JQ, ALL, H> 6" command triggered by HASP050 JNUM and JQES > 80% message on NP1F. At about 15: 43: 52.58, SA issue " $ CO JQ, ALL, H> 6" command triggered by HASP050 JNUM and JQES > 80% message on all other members(except NP1F) On all other members (except NP1F),HASP263 WAITING FOR ACCESS TO JES2 CHECKPOINT VOLUME NP1SL1 message is shown every 12 seconds after 15:41:46. From 15: 44: 10.03 to 15: 44: 47.38 , HASP003 RC = (84), CO JQ - JOB IS BUSY, TRY LATER is shown on all members. However, JNUM and JQES remained at more than 70% until 16:00 Befer 16:00,the output of JES2 is purged very very slowly .After 16:00 ,the output of JES2 is purged very very quickly. The questions: Q1. From 15:41:46 -16:00:00 ,it is about 18 minuts. During this 18 minutes, why the output is purged very very slowly? Q2 Do we need to issue " $ CO JQ, ALL, H> 6" command on all members? Q3. How to speed up to purge the output? Below is the definition MASDEF SHARED=CHECK, DORMANCY=(20,500), HOLD=10, RESTART=YES, AUTOEMEM=ON, LOCKOUT=1200 Thanks a lot! Jason Cai -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shocking Bug in Latest PCOMM Release
On 2017-11-27 7:42 AM, Tom Brennan wrote: Years ago I was getting help from Greg Price Probably circa turn of the century (before Vista was also a release of Windows) I thought it might be nice if one the the not-prohibitively-expensive TN3270 clients supported a form of 3270 graphics, and so I sent an email or two to Tom with a view to convincing him that (a) programmed symbol graphics is fully documented in the 3270 Data Stream Programmer's Guide and (b) it is a "simple matter of programming" to implement it. Looking after a few data structure arrays must be bread-and-butter to anyone who can code up a reliable and function-rich TN3270 client, was my considered opinion, not that I really know about such things, of course. Basically, the TN3270 client has to - flag in the response to a Read Partition (Query) that it supports such functionality - understand and digest the LPS (Load Programmed Symbols) data stream - render loaded symbols into the screen buffer when SA or SFE orders request a switch to that character set. A point to remember is that the TN3270 client cannot simply have a storage array for each RWS (read/write storage) being emulated. An IBM 3279G will show the "green lightning" while an LPS data stream is being processed, but all of the RWSes added up cannot supply enough characters to paint an entire 32x80 screen. So at least some of them are used more than once, in the usual case, before input-inhibit is reset (or the keyboard is unlocked, if you prefer) to allow a user response. BUT - the symbols rendered when the "first lot" of symbols were in the RWSes must still be rendered that way, even though the relevant RWSes have been overlaid with a new set of symbol data, which is quite often used to render the bit-less-than-second-half of the screen. So, symbol data must be remembered by the TN3270 client until BOTH of - the symbols are no longer in any current RWS - the symbols are no longer displayed on the screen are true. At the time, Vista 1.24 was the current release. Once Tom took up the challenge, in fairly short order (no comment from me on how much work it did or did not take to do it) there was a quite impressive (to me) Vista 1.25 which did a very good job of displaying the graphics that I could produce. But Tom has serious paying customers who don't really care for what I may or may not want in a TN3270 client and so I gather that these code changes were more of a prototype quality rather than production quality code and so were not copied into the product's code base used going forward. (Tom can correct me here if I have any of this wrong, of course.) I think it was Win7 that introduced the Program Data directory, yes? Anyway, Tom had to make a change to Vista so it was a happy Win7 citizen (IIRC). The net result of the new directory paradigm was that it was a pain to use the 1.25 version under Win7 and later so I gave it away in the end. Hmmm, probably time to cast the net more widely... I still refer anyone who asks me about Vista 1.25 to Tom. I asked Paul Mattes about x3270 graphics support, and he said that it was a to-be-done thing and had been for years. I gave him a TSO graphics program in my brief dialogue with him, and he said that he now had his sample application, the lack of which had been one of the stumbling blocks up till that time. He seemed confident that rendering symbols constructed at run-time would not be a problem. I can't see that much has been done in this area in the years since, though. Still, he does work on it without pay (I believe) so that's understandable. It's probably better to keep it running satisfactorily for the existing customer base that to appease a former MVS sysprog. My next port-of-call was Hans Erik at Nexus Terminal. I went through my shtick and he also took up the challenge. Further, it is now part of the base product, and therefore officially supported, I believe. So, for regular 3270 work, I have the choice of two great TN3270 clients, both with expert support, and for my graphics work, there's Nexus Terminal. (Bonus points for spotting that the map on the http://www.nexit.com/ web page is from one of my sample pictures available from the REVIEW (TSO command) home page and from CBT file 134.) Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shocking Bug in Latest PCOMM Release
I forget, but the only big plotter was an EIA attached to a PDP-8 over in the Chemistry building. So I'd have to run the simulations on the mainframe and write the output to DTR and carry them over to the Chem lab. They didn't like me 'cause they couldn't play 'Duck Hunter' while the plotter was running. In a message dated 11/27/2017 12:56:49 AM Central Standard Time, martin_pac...@uk.ibm.com writes: At UCL in the early 1980’s we had Tektronix graphics terminals that were exactly as you said. Exotic and scarce devices, fun to watch :-) , compared to the character-based terminals we all had access to. (This on GEC 4000 series mainframes.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Graphic output on the mainframe (was: Shocking Bug in Latest PCOMM Release)
On 2017-11-27 8:06 PM, Bernd Oppolzer wrote: I guess, the original 3279 G displays had small (HP?) plotters attached to them, so that the content of the display could simply be hardcopied by pressing a certain key (or controlled by the application, maybe). Our SAS/MXG performance guy back in the day had a Memorex 3279G look-alike with its own printer that printed the screen image when the hardcopy print key on the terminal's keyboard was pressed. IBM may have had similar hardware, but OEM stuff was cheaper. We did have a real 3279G which exhibited the "green lightning" while the LPS (load programmed symbols) data stream was being processed. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Graphic output on the mainframe (was: Shocking Bug in Latest PCOMM Release)
Am 27.11.2017 um 09:47 schrieb Elardus Engelbrecht: Bernd Oppolzer wrote: We used GDDM and 3279 G (IIRC) displays to do preview of our plotter outputs . ... This was in the 1985 to 1995 time frame. After that, the applications moved off the mainframe, to Unix workstations. Around 1990 - 2000, I and some of my colleagues used GDDM to display on a 3270 screen (PCOMM IIRC) the SAS graphs produced from SMF data. If the pic is looking great, neat and accurate, then we plot that on a desktop plotter. Now, today I am wondering how the graphs were transferred. I simply can't remember how these plotters are connected to the PCs and how the emulator screen is transferred to a plotter. Granted, those plotters were setup before I worked with them. I guess, the original 3279 G displays had small (HP?) plotters attached to them, so that the content of the display could simply be hardcopied by pressing a certain key (or controlled by the application, maybe). I recall that another public transport company in Bochum, Germany, had an APL application to interactively build timetables, and this application used APL and GDDM and the 3279 G display stations (and the attached hardcopy printer). Kind regards Bernd It was great 'fun' if someone who used the plotter, forgot to replace the pen caps back after usage... ;-) ... You then sit with dry pens and no available wet pens while managements wants the pics NOW!!! These days, we don't use any plotters at all. We are still have these ADM... DD statements in our TSO procs in case someone wants to use them. Groete / Greetings Elardus Engelbrecht -- 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: Source of SYSLOAVG value in RMF3
Thanks Roger. I did actually stumble across this after some more googling on 'WEB queue', and have had a play with it, but think it is more aligned with dump analysis, than info on a running system. Whilst it does work on a running system, it is very slow, and very cpu intensive. My main aim at least initially, is to get a view of the WEB queue totals at least once a second, so this doesnt really seem to fit the bill. On 27 November 2017 at 00:06, Roger Lowe wrote: > On Sun, 26 Nov 2017 01:33:40 +, Graham Harris > wrote: > > >Would anyone happen to know where the "SYSLOAVG" (stands for 'system load > >average') value in RMF3 comes from? > >I think it is also known as the WEB queue. > > > >I have ploughed through the data areas manuals, and cant see any obvious > >candidate control block at an LPAR level, but i may not be searching for > >the right thing, and it may not actually be a control block in its own > >right anyway. > > > >From what i have seen in the data areas, I have a nasty suspicion is that > >each address space may have its own WEB queue, and RMF may perhaps be > >amalgamating them to give a system-wide view (which is what I am > >specifically interested in, but want it at a much finer granularity than > >RMF3 can give). > > > >Any info gratefully received. > > > In IPCS, try issuing IPCS IEAVWEBI and see if that gives you the info that > you might be after > > Hope that helps. > > Roger > > -- > 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: Graphic output on the mainframe (was: Shocking Bug in Latest PCOMM Release)
Bernd Oppolzer wrote: >We used GDDM and 3279 G (IIRC) displays to do preview of our plotter outputs >. ... This was in the 1985 to 1995 time frame. After that, the applications moved off the mainframe, to Unix workstations. Around 1990 - 2000, I and some of my colleagues used GDDM to display on a 3270 screen (PCOMM IIRC) the SAS graphs produced from SMF data. If the pic is looking great, neat and accurate, then we plot that on a desktop plotter. Now, today I am wondering how the graphs were transferred. I simply can't remember how these plotters are connected to the PCs and how the emulator screen is transferred to a plotter. Granted, those plotters were setup before I worked with them. It was great 'fun' if someone who used the plotter, forgot to replace the pen caps back after usage... ;-) ... You then sit with dry pens and no available wet pens while managements wants the pics NOW!!! These days, we don't use any plotters at all. We are still have these ADM... DD statements in our TSO procs in case someone wants to use them. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shocking Bug in Latest PCOMM Release
Tom Brennan wrote: >Well, I said the same thing about IND$FILE back in 1998, thinking it would be >totally replaced by FTP. I was certainly wrong about that! Today I think >people use IND$FILE more than ever for smaller file transfers. ... and FTP is supposed to be replaced by SFTP or FTPS ... but I could be wrong! ;-) >And there are folks like you without FTP available - I know how that is, >logging on to a customer's mainframe and needing to upload something like >SHOWMVS. It is indeed a PITA, especially if that customer's firewall and network settings block you to enter the mainframe. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Graphic output on the mainframe
BTW, this was very helpful for me, being the lead developer (first: the only) of those technical applications. Before GKS, I had to wait a long time before the plotter was ready and I wasted much time and many sheets of paper during testing. With GKS, I could look at the results immediately after the test run on my 3279 G display. It was possible to zoom in and inspect the details (if the graphic elements are in the right place etc.). I did speed computations for the public transport system (subway trains); the output (driving diagrams, speed and time related to location) was shown graphically. And graphic timetables (showing all traffic of one subway line on one large sheet of paper). Both applications were heavily used by the different planning departments. Kind regards Bernd Am 27.11.2017 um 09:03 schrieb Bernd Oppolzer: We used GDDM and 3279 G (IIRC) displays to do preview of our plotter outputs (which were to pe printed on big electrostatic Calcomp plotters in the end). The (most technical) software was written in Pascal and Fortran and built the output using a graphic software which was called GKS (graphic kernel system). GKS had two adapters, one for the Calcomp plotter and one for GDDM, so the output (GKS metafile) could be plotted and shown at the display station at the same time. Later we added an adapter to HPGL (HP graphics language) and bought some HP plotters. This was in the 1985 to 1995 time frame. After that, the applications moved off the mainframe, to Unix workstations. IIRC, some other companies here in Germany (car manufacturers) did similar things, in the same time frame. There were even some CAD like systems running on the mainframe. Kind regards Bernd Am 26.11.2017 um 21:01 schrieb Seymour J Metz: What is "GDDM graphics", APA or PSS? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- 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
Graphic output on the mainframe (was: Shocking Bug in Latest PCOMM Release)
We used GDDM and 3279 G (IIRC) displays to do preview of our plotter outputs (which were to pe printed on big electrostatic Calcomp plotters in the end). The (most technical) software was written in Pascal and Fortran and built the output using a graphic software which was called GKS (graphic kernel system). GKS had two adapters, one for the Calcomp plotter and one for GDDM, so the output (GKS metafile) could be plotted and shown at the display station at the same time. Later we added an adapter to HPGL (HP graphics language) and bought some HP plotters. This was in the 1985 to 1995 time frame. After that, the applications moved off the mainframe, to Unix workstations. IIRC, some other companies here in Germany (car manufacturers) did similar things, in the same time frame. There were even some CAD like systems running on the mainframe. Kind regards Bernd Am 26.11.2017 um 21:01 schrieb Seymour J Metz: What is "GDDM graphics", APA or PSS? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
