Re: Re: VMFPLC2 DUMP malfunction in sixpack 1.2 environment

On 8/25/2010 1:35 AM, Dave Wade wrote:
> I think you need to fix you oorexx code. If you look in the original file
>

Yes and no.. The interpretation of the VMFPLC2 tape is a bit off it 
seems.. But.. The VMFPLC2 DUMP is weird nonetheless !

'Had to write myself a quick hex dump + EBCDIC interpretation for this - 
this was actually long overdue !)

The AWS file is still good :

000000 : 4D000000 A00002D7 D3C3C8C4 D4D2C7D9 C64040E4 D7C4D3D6 C7404008 
24193302 >>(......PLCHDMKGRF  UPDLOG  .....<<
000020 : 410001C1 F1024005 32C60000 00006100 46F1F000 00000500 00000D00 
00000000 >>...A1. ..F..../..10.............<<

Little endian 004D : Block length : 77 (That's where I come to the 
conclusion it's not an original VMFPLC2... Original VMFPLC2 PLCH record 
would have been FST+8 bytes long (5+48).. not FST+8+EDF bytes long 
(5+72) - That's a SEPP/BSEPP+ VMFPLC2 output).

PLCH header followed by the FST :

'DMKGRF UPDLOG A1', RECFM F, Dated August 24th Year 10 7:33 PM, 
X'0241'/576 records, LRECL X'61'/97. VMFPLC2 Specifics : 5 800 byte 
blocks in last block, 13 complete 4000 byte blocks. That's a bit odd 
because I usually expect 0/14 and not 5/13 here.. but anyways..

So now : 576*97 is 55872. Leftover of 128. The last tape block should 
end at (77+6)+((4005+6)*14) : +X'DBAD'/+56237 in the file and should be 
followed by 2 TMs..

Instead we find...

Another PLCD record on a 4005 block. I guess VMFPLC2 ignores it because 
it's expecting a PLCH there.

Finally, at X'EB58' (56237+4005+6 we find 2 TMs..

So apparently, the idea is to skip spurious PLCDs when reading VMFPLC2 
files..

--Ivan