El lun, 19 abr 2021 a las 7:40, Hilario Garcia (<[email protected]>)
escribi=C3=B3:
> I have done multiple tests with different utilities (XMIT, FTP, IND $
> FILE, AMATERSE) and I have not been able to download them in a valid
> format.
Not surprising as it's been mangled -- the begining is chopped off plus
possibly other damage.
> Attached I send in hexadecimal format the beginning of one of the PDS
> (loaded as FB, lrecl 80) and it seems that at the beginning of the
> file is the directory of a PDS partitioned file. If the file is loaded
> as FB and 80 bytes long, you can see the code in EBCDIC format. The
> original file is in format binary and I have loaded it in binary.
Yes, it appears to be (mostly) an iebcopy unload of a pds:
IEBCOPY unload record 1: xid found at 1 (1)
dsorg 0200
blksize 18b0
lrecl 0050
recfm 90
devtyp 3030200f
refd 6b00de
end of iebcopy record 1 36 (input offset 2d)
extent 0 at 3d
The way iebcopy unload outputs a PDS is by dumping:
- the device type
- DEB information including the disk addresess for each extent
- the raw DASD directory blocks
- the raw DASD blocks for each member pointed to by each directory entry
Each block dumped by iebcopy will be proceeded by the count field from
that block. These 8 bytes contain CCHHRKDD:
CC - disk cylinder address
HH - disk head address
R - record number on track
K - key length (0 if no key)
DD - data length
These are all combined into the iebcopy VBS output file.
Since this PDS was RECFM F and text all the printable characters are
probably there ... somewhere. Which belong to which member is not as
easy to figure out.
Possibly it might take matching the CCHHR from the dumped data blocks to
the TTR in the directory entry. There might be something to the order
(member name order? TTR order?).
There is/was documentation on the iebcopy unload format in some
IBM manual. Possibly utilities or utilites logic?
PS: Until you posted some of the hex data there was not much anyone
could do to help you.
> ._....¢.&°..Ø"8......"8....Vs...ê.....,.ú...Ø......#...........±.Ø..»ØHì4à....®
> 0C60001B0590087F3320007F2200EA00250000060D000800000063000000F0008080088C5F40000A
> 0ADF2080000000F8000F00F8710F52002200020B0E00000010B790001000F000F0004B088440001F
>
> ------------------------------------------------------------------------------
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
