Thank you for putting words in my mouth. However, I'd rather speak for myself. Alternative facts?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Friday, May 21, 2021 10:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies A well-known Bank I was working at, as a systems programming consultant (in '99,) asked me to install custompac. So I did that and checked it out. It was so full of errors, including that the user enter the MCAT password and the hlq of PARMLIB (and of whatever else,) for it to function, never mind its then allocating dozens of CYLs and (if memory serves) 100's of directory blocks to SAMPLIB which, after the install, contained no more than a dozen or so of members - and then underestimated the DASD space and directory blocks required for SMPPTFIN and whatever the DLIB/TLIB loadlibs were, causing S*37 abends when it was executed. I pointed this out to the Bank and suggested that I write my own version of it. They gave me the go-ahead. My version then did everything custompac was supposed to do, including updating all its "logs" and datasets etc. and being 100% compatible with custompac - but requiring only two inputs from the user, with no MCAT password or PARMLIB etc. hlqs needed - and it genned all the correct SMP/E JCL to install/update the Bank's products. Later on, IBM kept on asking me to explain to them - and for weeks - how I had 'fixed' their custompac, so they could tell their developers in Canada what to do. Yes, and COND is easy to understand; it's also unnatural in that it requires using the brain as well as the fingers. OK, got it. Thanks for explaining. Cheers, Chris Poncelet (r) On 22/05/2021 01:23, Seymour J Metz wrote: > When did custompack stop having SMP steps? > > Yes, COND is easy to understand; it's also unnatural. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > CM Poncelet <ponce...@bcs.org.uk> > Sent: Friday, May 21, 2021 7:01 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS > Technologies > > "I don't like it when IBM takes away tools" - and IBM stopped publishing > system control block DSECTs with ESA, thereby preventing sysprogs from > modifying its OSes (or so it thought.) > > Next step (perhaps in 10+ years' time) will be to withdraw support of > native SMP/E (and thus of CBPDO/CBIPO installs) and enforce using > custompac (or custompak, whatever it is now called) instead. That would > be a "progressive and continual stultification ofmainframe systems > programming" and of IBM's progressively taking over full control of how > customers' systems are installed, managed and maintained - as is already > done by Micro$oft. > > How "COND=" works is trivial and needs no 'help' from "IF/THEN" > statements. "COND=" just means "execute the step *unless* any of the > COND= parms is true." Anyone who has difficulty understanding even > *that* should not be working with mainframes. > > Chris Poncelet (r) > > > > On 21/05/2021 23:02, Seymour J Metz wrote: >>> ESA's OCO? >> What's that in reference to? >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> ________________________________________ >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of >> CM Poncelet <ponce...@bcs.org.uk> >> Sent: Friday, May 21, 2021 4:22 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS >> Technologies >> >> ESA's OCO? >> >> On 20/05/2021 08:43, Seymour J Metz wrote: >>> Progress is also not made by pretending that a blunt tool is sharp just >>> because you're used to it. COND= is a blunt tool, and IF/THEN puts a >>> bandage over some, but not all, of its ugliness. >>> >>> What's wrong with taking advantage of skeletons and such? Yes, I have been >>> known to hand craft an SMP/E job when the templates didn't suit my needs, >>> but what's wrong with taking advantage of them when it saves me time? >>> >>> I don't like it when IBM takes away tools, but that's not the same as >>> providing new tools that I can ignore when they don't suit the task at hand. >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> >>> ________________________________________ >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >>> CM Poncelet [ponce...@bcs.org.uk] >>> Sent: Wednesday, May 19, 2021 9:50 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: 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 >>> >>> ---------------------------------------------------------------------- >>> 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
