And don't forget "Muggeridge's Law" :-) On Wed, Jun 17, 2020 at 12:32 PM Jesse 1 Robinson <[email protected]> wrote:
> Malcom Muggeridge was famous for characterizing UK and US as being > *separated* by a common language. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > [email protected] > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Lionel B Dyck > Sent: Wednesday, June 17, 2020 10:23 AM > To: [email protected] > Subject: (External):Re: Improve OMVS cp performance? > > CAUTION EXTERNAL EMAIL > > Frank - true it is all z/OS but that is like saying it's all Europe - in > this case z/OS speaks one language and OMVS another - they just share the > continent and unlike England and the US they don't share a common language > 😊 > > > Lionel B. Dyck <sdg>< > Website: https://www.lbdsoftware.com > > "Worry more about your character than your reputation. Character is what > you are, reputation merely what others think you are." - John Wooden > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Frank Swarbrick > Sent: Wednesday, June 17, 2020 12:12 PM > To: [email protected] > Subject: Re: Improve OMVS cp performance? > > I wonder what kind of effort it might be for z/OS to support Unix path > names as aliases/links to MVS legacy data sets. Probably a lot of work, > but it seems like it would be quite useful for situations such as this > where the Unix application only supports Unix paths. > > Just a wild thought. Not opening an RFE for it or anything, unless > someone can say it sounds at all reasonable. > > By the way, z/OS Unix is z/OS, as some like to say. I prefer to use the > terms "legacy data sets" or "MVS data sets" saying "the z/OS side". It's > all z/OS! 🙂 > > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf > of Lionel B Dyck <[email protected]> > Sent: Wednesday, June 17, 2020 6:14 AM > To: [email protected] <[email protected]> > Subject: Re: Improve OMVS cp performance? > > Kirk - thank you for the ideas. > > What I'm doing is in the ZIGI (see https://zigi.rocks) where I need to > copy PDS members to/from USS so that Git can manage them. With small > projects this isn't an issue but with larger projects it could take enough > time for you to go to lunch ☹ > > Btw. I voted your RFE. > > > Lionel B. Dyck <sdg>< > Website: https://www.lbdsoftware.com > > "Worry more about your character than your reputation. Character is what > you are, reputation merely what others think you are." - John Wooden > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Kirk Wolf > Sent: Wednesday, June 17, 2020 7:03 AM > To: [email protected] > Subject: Re: Improve OMVS cp performance? > > Hi Lionel, > > Can you provide any more detail on how you are invoking "cp" ? > > - With cp, there won't be any way to avoid opening the PDSE for each > member, but you might get some improvement by allocating a DD to the PDSE > and then passing //DD(member) to cp, so as to avoid allocation each time. > If you do this, then you will also know for sure if you are using local > spawn (_BPX_SHAREAS=YES), since otherwise the DD won't be visible if a new > AS was forked. > > - The other issue would be the cost of spawning a Unix process for each > member, even if local spawned. I haven't tested this, but you might write > a shell script that is passed the DD as arg and member names as lines to > stdin. Then the script could do the cp for each member. The hope is > that since cp is also a shell "built-in" you might avoid spawning > processes for each one. > > - the "best" performance possible would be writing your own BPAM code that > also does the Unix fileio. Assembler is fine, but I would use C/++ for > everything except the low level BPAM I/O routines, since I would probably > use buffered filestreams for the Unix files. > > FWIW: It's a pity that the IBM C library doesn't have any support for > BLDL/NOTE/POINT processing of PDS/Es -- see my old RFE and vote if you > agree: > https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=80811 > > > > On Wed, Jun 17, 2020 at 5:30 AM Lionel B Dyck <[email protected]> wrote: > > > " What's on the non-OMVS side? a PDS(E)? Multiple PS data sets?" > > > > On the z/OS side is a PDS(E). > > > > Thanks > > > > > > Lionel B. Dyck <sdg>< > > Website: https://www.lbdsoftware.com > > > > "Worry more about your character than your reputation. Character is > > what you are, reputation merely what others think you are." - John > > Wooden > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On > > Behalf Of Paul Gilmartin > > Sent: Tuesday, June 16, 2020 9:23 PM > > To: [email protected] > > Subject: Re: Improve OMVS cp performance? > > > > On Tue, 16 Jun 2020 20:34:59 -0500, Lionel B Dyck wrote: > > > > >Any suggestions on how to speed up cp copying multiple file to and > > >from > > z/OS? > > > > > >I gave SHAREAS=YES. Anything else? Can I control buffers or ? > > > > > What's on the non-OMVS side? a PDS(E)? Multiple PS data sets? > > > > I might suggest as an extreme measure Rexx under ISPF using ADDRESS > > SYSCALL I/O for OMVS and LM services for Classic. > > SYSCALL READFILE/WRITEFILE are available for text files only. > > > > -- gil > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
