Yep. Digital Research had a contract with all their prior customers. If they cut the price for a new customer, they change the price and REFUND the difference on all previous sales.
On Thu, May 20, 2021 at 11:47 AM Seymour J Metz <sme...@gmu.edu> wrote: > > Admittedly DR-C was a sin for which there is no forgiveness, but my > understanding is that the IBM-DR negotiations foundered on the issue of > contract terms, and IBM gave away the farm with m$. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Charles Mills <charl...@mcn.org> > Sent: Thursday, May 20, 2021 11:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re: JCL COND vs IF/THEN - Best catch up resources for > MVS / ZOS Technologies > > Digital Research was certainly an accomplice in its own strangulation. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: Thursday, May 20, 2021 8:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re: JCL COND vs IF/THEN - Best catch up resources > for MVS / ZOS Technologies > > Stuck to DR-DOS? We would have all been better off had m$ not taken over the > PC OS market and used the monopoly to strangle its competitors. > > SMB? Doesn't NFS play better with the *ix world? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Pommier, Rex <rpomm...@sfgmembers.com> > Sent: Thursday, May 20, 2021 10:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re: JCL COND vs IF/THEN - Best catch up resources > for MVS / ZOS Technologies > > Sorry Chris, > > But I would venture a guess that you're pretty much standing alone here. > The "if it ain't broke don't fix it" otherwise known as "if it's good enough > for me it should be good enough for everybody else" attitude is what has us > on a slowly dying platform. So what if IF/THEN doesn't handle all the > arcane COND= Boolean logic? Sysprogs aren't the only people using JCL. If > I can easily train an application developer or an implementation analyst on > the use of IF/THEN once and have them go away and build their own JCL > without needing my continual assistance to help them understand COND= logic, > it is a win-win situation. I would bet every sysprogs on this list has > horror stories of having to fix somebody's COND= screw-up. > > It's actually quite enjoyable having a developer come to me puzzled about > COND=something and be able to say "Here, use this IF/THEN JCL logic > instead", and see the light come on in their eyes. > > But then, if PCs would have stuck with DR-DOS the mainframe would still be a > more major player in the SMB business arena. > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > CM Poncelet > Sent: Wednesday, May 19, 2021 8:50 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [External] Re: JCL COND vs IF/THEN - Best catch up resources for > MVS / ZOS Technologies > > Again and with all due respect, progress is made not by blunting the tool > but by sharpening the user. > > "IF/THEN" does not handle all boolean AND/OR/NAND/XOR and steps-not-executed > conditions. > > Let not those who cannot master playing the violin demand that the violin be > made more easy, but let them try playing the banjo instead. > > And SMP/E? In the 1980's it was 'recommended' to use its dialogs. In the > late 90's, its Custom-Pak etc. became 'de rigueur' and 'de facto'. And yet I > continued to use only native SMP/E - and did so daily to track down and fix > PTFEs etc. etc. > > Who gains from this progressive and continual stultification of mainframe > systems programming? Is it not Windows for mainframes? > > As they say, "Use it or lose it." > > Cheers, Chris Poncelet (r) > > > > On 19/05/2021 01:55, Nash, Jonathan S. wrote: > > Once I learned of the IF/THEN statements for JCL I never used COND= > > again. IF/THEN is much easier to use and to explain to new people. > > I have seen many people code COND statements incorrectly because they > > did not acually understand how they worked. > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > > Behalf Of CM Poncelet > > Sent: Tuesday, May 18, 2021 8:19 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [EXTERNAL] Re: Best catch up resources for MVS / ZOS > > Technologies > > > > With all due respect, anyone who has difficulty coding JCL COND= > > statements should consider *not* working with IBM mainframe systems. > > > > All boolean conditional execution steps can be handled using only > > COND= statements. I submitted a paper on this & it was published in > > "Computing" in 1989. I would but cannot attach it, as uploading PDF > > files to this discussion list is not permitted. > > > > No sysprog worth his salt has ever had a problem with coding JCL COND= > > statements. > > > > Likewise IF/THEN statements belong in "JCL for dummies" - as do > > symbols in JCL and SYSIN. Ditto IF/THEN <etc.> in assembler. > > > > Chris Poncelet (r) > > > > > > . > > On 18/05/2021 14:02, Charles Mills wrote: > >> Yeah, and IF/THEN is slightly better than COND= > >> > >> Also symbols in SYSIN data. > >> > >> Charles > >> > >> > >> -----Original Message----- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >> On Behalf Of Steve Horein > >> Sent: Tuesday, May 18, 2021 5:35 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Best catch up resources for MVS / ZOS Technologies > >> > >> I would argue JCL got better when symbols were allowed! :-) > >> https://www.ibm.com/docs/en/zos/2.4.0?topic=es-symlist-parameter > >> > >> On Mon, May 17, 2021 at 10:46 PM Charles Mills <charl...@mcn.org> wrote: > >> > >>> Steve, let me wade in here and suggest some big picture. I think > >>> SHARE and such is great for the details. > >>> > >>> What has changed since 2001? An idiosyncratic, IMHO list: > >>> > >>> - In 2001 SNA was yielding to TCP/IP. That transition has continued. > >>> An awful lot of mainframe connectivity is now TCP/IP. Lots and lots > >>> of Internet connectivity to the mainframe. > >>> - Security is huge. Encryption is hot. Zero Trust is the buzzword of > >>> the month. > >>> - Everything is of course bigger. Z hardware goes up to what? 4TB real? > >>> Someone will correct me if that is wrong. > >>> - Tape drives have pretty much gone away. They live on as virtual, > >>> emulated-on-DASD tape drives. > >>> - The Cloud. Read any airline magazine for the latest. > >>> - Remember VM? It was pretty moribund in 2001. It has found new life > >>> hosting thousands of Linux instances. Yes, Linux running like a > >>> champ on Z hardware. Mainframe Linux is huge. You can run Linux in a > >>> region of MVS in a "container." > >>> - Speaking of which, there is a Z box that will not IPL z/OS! It is > >>> called Linux One. It's a mainframe with a bit hobbled somewhere such > >>> that mainframe operating systems will not IPL, only Linux. > >>> - Lots of new features in core MVS but you would fully recognize the > >>> environment. If you sit down at a TSO/ISPF session it will seem like > >>> nothing has changed. JCL has not gotten any better (or any worse, > >>> thankfully). > >>> - Remember the issue of "above the (24-bit) line"? It is still > >>> there, but pretty much in the background. The new thing is data and > >>> execution "above the (2GB/31-bit) bar." Lots of software products > >>> are exploiting data above 2GB, and code can even run there, with lots of > limitations. AMODE/RMODE 64. > >>> - IBM JES3 is dead. Long live Phoenix JES3 plus. IBM ditched JES3, > >>> and Phoenix picked it up. > >>> - More emphasis on high level languages. Hardware design is being > >>> driven by the Java folks and the compiler folks. Lots of new > >>> hardware instructions. Hardware cycle times are not getting any > >>> faster, but instructions do more per cycle. Caching getting more > >>> sophisticated and more critical. The concept of "how long does an LR > >>> take" has totally disappeared. It is a question with no answer other > than "it depends." > >>> > >>> Anyone else want to weigh in? > >>> > >>> Charles > >>> > >>> > >>> -----Original Message----- > >>> From: IBM Mainframe Discussion List > >>> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave > >>> Sent: Monday, May 17, 2021 6:58 PM > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Best catch up resources for MVS / ZOS Technologies > >>> > >>> I would suggest SHARE presentations and perhaps Marna Walle's > >>> migration guides > >>> > >>>> -----Original Message----- > >>>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > >>>> Behalf Of Steve Estle > >>>> Sent: Monday, May 17, 2021 6:42 PM > >>>> To: IBM-MAIN@LISTSERV.UA.EDU > >>>> Subject: Best catch up resources for MVS / ZOS Technologies > >>>> > >>>> Hello Everyone in Mainframe Land, > >>>> > >>>> I've been out of the mainframe world since about 2001, but spent > >>>> the > >>> prior > >>>> 20 years immersed in that world working with everything from > >>>> MVS/370 to MVS/ESA and VM, performance and capacity planning > >>>> disciplines across a variety of situations in the IT Services and > >>>> consulting spaces. I, am, > >>> now as a > >>>> "IT Infrastructure Engineer- IBM z/OS Mainframe Engineer" after > >>>> nearly 20 years of other activities (Project Mgmt, entrepreneur, > >>>> etc) am about to potentially come back into a new mainframe role > >>>> and I need to catch up as quickly as possible. Any suggestions on > >>>> ways to fill in the gaps for > >>> ZOS, ZVM, > >>>> hardware, performance, etc? Bottom line I'm looking for that gap > >>> education > >>>> to as quickly as possible get up to speed with changes in platforms > >>> since 2001. > >>>> If prefer to call - all my info is below. > >>>> > >>>> Thanks, > >>>> Steve Estle > >>>> 303-604-0925 > >>>> sest...@gmail.com > >>>> > >>>> ------------------------------------------------------------------- > >>>> --- 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 . > >> > > ---------------------------------------------------------------------- > > 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 > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > ---------------------------------------------------------------------- > 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 -- 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
