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
