Kirk - just allocating the dataset prior to the cp was faster - and that was
without passing the //DD.
Alloc f(dd) shr reuse ds('my.pds')
Bpxwunix - cp -v -S a=.txt "//'my.pds'" .
Free f(dd)
Appreciate your suggestion
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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Kirk Wolf
Sent: Wednesday, June 17, 2020 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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 <lbd...@gmail.com> 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 <IBM-MAIN@LISTSERV.UA.EDU> On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, June 16, 2020 9:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 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
