On Wed, 27 May 2020 20:15:43 -0700, Sri h Kolusu wrote: > >Thanks for sharing the REXX execs. couple of observations. > >1 The PDSTOSEQ fails processing members having aliases. (LISTDS does give >you the ALIAS information too) For example I tried with z/OS V2R4 >SYS1.MACLIB > > %PDSTOSEQ SYS1.MACLIB OFF > >The result is REPRO fails when it encounters > >NAME=ERBPICT ALIAS(PICTURE) > Wouldn't a smarter PARSE alleviate this, but at the expense of making aliases separate members or ignoring them?
>2. with PDSTOSAM, you need to have REGION=0M. Without it you would get > >IRX0005I Error running PDSTOSAM, line 69: Machine storage exhausted > For any REGION on almost any system, it's possible to have a data set that causes IRX0005I. (Well, i suppose you can have more virtual storage than the largest single-volume PDSE.) But writing one member at a time probably alleviates the problem. And writing one record at a time almost surely eliminates it. Accumulating everything in one gigantic stem may be a bad habit: in many cases it merely trades paging overhead for EXECIO call overhead. DFSORT developers are aware of such tradeoffs. On Thu, 28 May 2020 08:25:18 -0700, Sri h Kolusu wrote: > >IMHO writing a 100+ REXX exec is not an ideal solution. It takes an >elaborate set up to run it in batch(compile or set up ISPF to run in >batch). > Supporting 100+ Rexx execs is hardly more burdensome than supporting a library of 100+ DFSORT control files. It depends on the programmer's comfort zone. And rote learning makes running ISPF in batch (or from OMVS) easy the second and subsequent times. Copy, paste, and edit. Thanks, gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
