your other member are readable.
there are various ways to solve the problem to acces members that had been created with a larger
blocksize.
- you can easily, i.e. using rather standard "tricks" to convince any utility
to use the intended size
alloc da(bad.stuff) fi(xxx) blksize(6160) shr
xmit nnn.user da(bad.stuff) outdat(transfer)
receive indat(transfer)
on a level below you add a blksize to an iebcopy dataset.
...
- you may want to just change whatever attribute on an existing datatet
allocate it to a file with disp mod,
open/close
-- and forget the details and ruin your dataset, or
CLOPS on file 1003 cbttape. "alloc fi(clops) da(xxxx) blksize(whather)' call
...(clops)
on file 1003 on cbttape;
/ps
btw:
when you create the "member encapsulated pds, a load module or else", you may use the the msg
parameter for xmit:
when you receive it, you can get during receive all kind of instructions, reminders, warnings during
receive.
On 18/12/2025 18:52, Charles Mills wrote:
There was some discussion here last week or so about the hard-coded
BLKSIZE=3120 in TSO TRANSMIT. Someone IIRC expressed the hope that at least it
respected existing data set BLKSIZEs.
It does not! I just got bit!
If you have a PDS with BLKSIZE > 3120 with existing members, and you use that
data set and a member name for TSO TRANSMIT output, TRANSMIT clobbers the BLKSIZE
to 3120 and your existing members become unreadable.
Grrr!
Thank you for your sympathy.
Charles
----------------------------------------------------------------------
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
