Hi Gil,
Every time I've used Windows as a "waystation", I've never had a problem
with TRS Files.
Regards,
David
On 2021-10-11 15:10, Paul Gilmartin wrote:
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 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
