Re: Re: VMFPLC2 DUMP malfunction in sixpack 1.2 environment

Ivan Warren wrote:
> 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).
> 

Looking at the VM/R6 service tape it appears to be (I haven't had time 
to do a byte compare, but its the right size) the same module that's on 
that tape. I assume that the VMMFPLC2 on the base software was updated 
at some point because IBM was using a system with SEPP or BSEPP to 
produce the service tapes?


> 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.
> 

I think it ignores it because that's what the parameter block (FST) at 
the front tells it to do. It has how many items there are on the tape. 
VMFPLC2 is easy to read because you know how big the file is, because 
the parameter block (FST) is on the front of the tape. TAPE DUMP files 
are a pain to read because the parameter block (FST) is on the end.

Of course the converse is true which is why my VMFPLC2 for DOS/UNIX only 
reads tapes....

> Finally, at X'EB58' (56237+4005+6 we find 2 TMs..
> 
> So apparently, the idea is to skip spurious PLCDs when reading VMFPLC2 
> files..
> 

No, only read what the FST tells you to read...

> --Ivan
>