On Mon, 11 Oct 2021 14:51:23 -0400, David Spiegel wrote: > >"... "An error occurred" is woefully inadequate. Were other errors >logged? ..." No > No comment on my ENQ hypothesis? Thinking further, BPXBATCH probably forks (see BPXBATSL), then shell exec pax forks to a third ASID while the TRS step is holding ENQ SHR on the data set. pax (probably via C/C++ RTL) attempts a contending ENQ EXC on OPEN WRITE.
Dear IBM, Please copy allocation messages to stderr when an error occurs. OK? >"... Why bother with TRS? Doesn't your "pax -z" achieve comparable >compression? >(Often a second compression expands the file. Or, pax without the -z, >then TRS.) ..."I want a robust backup Dataset which can survive >downloads/uploads to non-z/OS platforms. > If the "pax -z" output file is pre-allocated RECFM=FB, it should be comparably robust. And those non-z/OS platforms are unlikely to be savvy to TRS. (But are they just waystations? I've found Linux pax unable to deal with z/OS "pax -z" unless I pipe it through gunzip.) >The Dataset and File Names have been masked; /src/ is not MOUNTd at Root > >Regards, >David > >On 2021-10-11 14:40, Paul Gilmartin wrote: >> On Mon, 11 Oct 2021 14:03:11 -0400, David Spiegel wrote: >>> I am trying to PAX and TRS a zFS. >>> >>> When I run a Step to PAX followed by a Step to TRS, I get: >>> pax: //'MY.PAX': EDC5061I An error occurred when attempting to define a >>> file to the system. >>> >> "An error occurred" is woefully inadequate. Were other errors logged? >> >> Why bother with TRS? Doesn't your "pax -z" achieve comparable compression? >> (Often a second compression expands the file. Or, pax without the -z, then >> TRS.) >> >> Time warp? A subsequent TRS step causes the earlier pax step to fail!? >> >> Does the initiator issue an ENQ because of TRS that somehow causes pax >> to fail? (Remember pax probably forks to a separate ASID.) >> >> (Is /src/ really mounted on root?) >> >> (It's regrettable that pax doesn't support a temp DSN.) >> >>> (I tried TAR and got the same result.) >>> When I run the PAX in one job and the TRS in another job, it works. >>> Has anyone seen this behaviour? (I'm on z/OS V2.4) >>> >>> Here is the JCL: >>> //STEP001 EXEC PGM=BPXBATCH >>> //STDOUT DD SYSOUT=* >>> //STDERR DD SYSOUT=* >>> //STDPARM DD * >>> SH pax -wzvf "//'MY.PAX'" /src/ >>> //STEP002 EXEC PGM=AMATERSE,PARM=SPACK >>> //SYSPRINT DD SYSOUT=* >>> //SYSUT1 DD DISP=SHR,DSN=MY.PAX >>> //SYSUT2 DD DISP=(,CATLG), >>> // UNIT=SYSALLDA, >>> // DATACLAS=DCZFSEXT, >>> // STORCLAS=SCZFSEXT, >>> // SPACE=(CYL,(1000,500),RLSE), >>> // RECFM=FB,LRECL=1024,BLKSIZE=27648, >>> // DSN=MY.PAX.TRS >>> -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
