TAPEMAP Bug

[halfmeg]

In addition to TAPEMAP producing different results for AWS vs HET images, it reports bad info when an AWS image is chunked to a specific size.

tapemap shar75.awsimage
Hercules tape map program Version 3.06
(c)Copyright 1999-2007 by Roger Bowler, Jan Jaeger, and others
File 1: Blocks=4550, block size min=2640, max=8000
File 2: Blocks=0, block size min=0, max=0
File 3: Blocks=0, block size min=0, max=0
File 4: Blocks=0, block size min=0, max=0
End of tape.

tapemap shar75.aws
Hercules tape map program Version 3.06
(c)Copyright 1999-2007 by Roger Bowler, Jan Jaeger, and others
File 1: Blocks=9099, block size min=2640, max=4096
File 2: Blocks=0, block size min=0, max=0
File 3: Blocks=0, block size min=0, max=0
File 4: Blocks=0, block size min=0, max=0
End of tape.

Unchunking this 2nd tape, chunck size 4096, produces the the original tape with the true block size of 8000.

---------------------------------------------------------------------

Additional reference for other problem with TAPEMAP:

Hercules User Reference Manual, page 356-358, shows different results on the same tape, T38321A, when it is AWS vs HET images.

The above tape as HET image processed by TAPEMAP provides:

tapemap shar75.het
Hercules tape map program Version 3.06
(c)Copyright 1999-2007 by Roger Bowler, Jan Jaeger, and others
File 1: Blocks=4550, block size min=458, max=5382
File 2: Blocks=0, block size min=0, max=0
File 3: Blocks=0, block size min=0, max=0
File 4: Blocks=0, block size min=0, max=0
End of tape.

The utility shouldn't report 3 different things for a single tape based upon how the image is stored.

Phil

[fish-8]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

halfmeg wrote:

> In addition to TAPEMAP producing different results for AWS
> vs HET images, it reports bad info when an AWS image is chunked
> to a specific size.

Oh?

> tapemap shar75.awsimage
> Hercules tape map program Version 3.06
> (c)Copyright 1999-2007 by Roger Bowler, Jan Jaeger, and others
> File 1: Blocks=4550, block size min=2640, max=8000
> File 2: Blocks=0, block size min=0, max=0
> File 3: Blocks=0, block size min=0, max=0
> File 4: Blocks=0, block size min=0, max=0
> End of tape.
>
> tapemap shar75.aws
> Hercules tape map program Version 3.06
> (c)Copyright 1999-2007 by Roger Bowler, Jan Jaeger, and others
> File 1: Blocks=9099, block size min=2640, max=4096
> File 2: Blocks=0, block size min=0, max=0
> File 3: Blocks=0, block size min=0, max=0
> File 4: Blocks=0, block size min=0, max=0
> End of tape.
>
> Unchunking this 2nd tape, chunck size 4096, produces the the original tape
> with the true block size of 8000.

Hmmm. I guess we should perhaps be using different terminology. The values
reported are probably correct. It's probably the use of the terms "Blocks"
and "block size" that are misleading you. The "Blocks" values is actually
the number of CHUNKS the program read, and the "block size" values it
reports are actually CHUNK size values.

You DO understand the difference, right?


> ---------------------------------------------------------------------
>
> Additional reference for other problem with TAPEMAP:
>
> Hercules User Reference Manual, page 356-358, shows different results on
the

> same tape, T38321A, when it is AWS vs HET images.
>
> The above tape as HET image processed by TAPEMAP provides:
>
> tapemap shar75.het
> Hercules tape map program Version 3.06
> (c)Copyright 1999-2007 by Roger Bowler, Jan Jaeger, and others
> File 1: Blocks=4550, block size min=458, max=5382
> File 2: Blocks=0, block size min=0, max=0
> File 3: Blocks=0, block size min=0, max=0
> File 4: Blocks=0, block size min=0, max=0
> End of tape.
>
> The utility shouldn't report 3 different things for a single tape based

upon
> how the image is stored.
>
> Phil

Actually what it should probably be doing (but then maybe this would be even
MORE misleading??) is internally invoking HETMAP for HET tapes since it's
technically a file format tapemap wasn't meant to handle.

Tapemap is supposed to be for aws format only. HETMAP can handle either as I
recall, but tapemap doesn't understand HET format.

To tapemap a HET file is just an AWS file. It doesn't know about (doesn't
care about) the fact that the chunks are compressed (and thus the ACTUAL
chunk size is much larger than the actual *physical* chunk size). From ITS
point of view the size of the chunk/block is THE size of the chunk/block.

But I can see that we should probably at the very least be using the terms
"Chunks" and "chunk size" rather than the currently misleading "Blocks" and
"block size" terminology. Would making that change make you happy?

What about my idea about it internally invoking HETMAP for het tapes? (since
HET =/= AWS) How does that sit with you?

For that matter how do others feel about these issues/ideas?

- --
"Fish" (David B. Trout) - fish@...
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52




-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.8.0 (Build 2158)
Charset: us-ascii

wj8DBQFKxw+GSPXX9MTuPioRAnK4AKDEurHwhwHvGN+EcQCjz/+8l+8htQCg5jJY
x/1c0Ju3zLH+L6m44E7NtSA=
=J0JN
-----END PGP SIGNATURE-----

[halfmeg]

> Fish wrote:

> > halfmeg wrote:

> > In addition to TAPEMAP producing different results for AWS
> > vs HET images, it reports bad info when an AWS image is chunked
> > to a specific size.

> Oh?

><snip>

> Hmmm. I guess we should perhaps be using different terminology. The
> values reported are probably correct. It's probably the use of the
> terms "Blocks" and "block size" that are misleading you.
> The "Blocks" values is actually the number of CHUNKS the program
> read, and the "block size" values it reports are actually CHUNK
> size values.

> You DO understand the difference, right?
 
><snip>

Yes, I understand perfectly.  TAPEMAP was probably written before HET was ever around and not updated to accomidate HET tapes.  It does seem to report values for the virtual tape's physical block size for the virtual container instead of the physical tape's block size which is stored in the virtual container whether AWS or HET.

The virtual container's block size is immaterial to MVS or VM and provides no help at all in construction JCL or whatever VM may use to read the tape's true original blocksize.

In addition, Hercules has added the ability to utilize FLEX-ES Fake-Tape format.  Don't believe TAPEMAP has been updated to handle that either.  Not sure if HETMAP uses the same underlying code as Hercules of if the utilities are seperate and static.  If static, then HETMAP may not handle Fake-Tape format either.

So do we trust what the Hercule's User Reference states on page 356:

"The Hercules tape map program shows the content of an AWS or HET tape. It displays all header data contained on the tape. Please note that the utility does not display the actual contents of the files. Although the TAPEMAP utility does display the same data as the HETMAP utility, the output is formatted in a totally different way."

If so, then the below examples where TAPEMAP blocksizes differ from HETMAP are incorrect.  Example 1 is only one where TAPEMAP and HETMAP are the same.  Example #2 is strict AWS standard which TAPEMAP should report correctly but doesn't.  Example #3 is HET tape which TAPEMAP never claimed to process correctly but shows TAPMAP doesn't reject it and reports values different from HETMAP.

Downloaded CBT072 ( tape072.zip ) from CBT Tape site ( small tape < 2M ).  http://www.cbttape.org/c249down.htm

Unzipped it, ran "tapesplt cbt072.aws test.aws 6" to get a subset.

Ran "hetupd -s test.aws test-4096.aws" which according to HETUPD creates a "strict AWSTAPE specification (chunksize=4096,no compression)", so still a AWS image processable by TAPEMAP.

Ran "hetupd test.aws test.het" to get the HET image.

Example #1 - plain AWS image - TAPEMAP & HETMAP report same blocks and blocksizes.

File 1: Blocks=10, block size min=30560, max=32000
File 2: Blocks=2, block size min=2960, max=32000
File 3: Blocks=1, block size min=19520, max=19520
File 4: Blocks=1, block size min=80, max=80
File 5: Blocks=1, block size min=80, max=80
File 6: Blocks=1, block size min=11280, max=11280
End of tape.

---------------------
Filename            : test.aws
---------------------
File #              : 1
Blocks              : 10
Min Blocksize       : 30560
Max Blocksize       : 32000
Uncompressed bytes  : 318560
Min Blocksize-Comp  : 30560
Max Blocksize-Comp  : 32000
Compressed bytes    : 318560
---------------------
File #              : 2
Blocks              : 2
Min Blocksize       : 2960
Max Blocksize       : 32000
Uncompressed bytes  : 34960
Min Blocksize-Comp  : 2960
Max Blocksize-Comp  : 32000
Compressed bytes    : 34960
---------------------
File #              : 3
Blocks              : 1
Min Blocksize       : 19520
Max Blocksize       : 19520
Uncompressed bytes  : 19520
Min Blocksize-Comp  : 19520
Max Blocksize-Comp  : 19520
Compressed bytes    : 19520
---------------------
File #              : 4
Blocks              : 1
Min Blocksize       : 80
Max Blocksize       : 80
Uncompressed bytes  : 80
Min Blocksize-Comp  : 80
Max Blocksize-Comp  : 80
Compressed bytes    : 80
---------------------
File #              : 5
Blocks              : 1
Min Blocksize       : 80
Max Blocksize       : 80
Uncompressed bytes  : 80
Min Blocksize-Comp  : 80
Max Blocksize-Comp  : 80
Compressed bytes    : 80
---------------------
File #              : 6
Blocks              : 1
Min Blocksize       : 11280
Max Blocksize       : 11280
Uncompressed bytes  : 11280
Min Blocksize-Comp  : 11280
Max Blocksize-Comp  : 11280
Compressed bytes    : 11280
---------------------
Summary             :
Files               : 6
Blocks              : 16
Uncompressed bytes  : 384480
Compressed bytes    : 384480
Reduction           : 0

Example #2 - Strict AWS Image ( 4096 Chunk size ) - nothing matches, # of blocks, min or max blocksizes.

File 1: Blocks=80, block size min=1888, max=4096
File 2: Blocks=9, block size min=2960, max=4096
File 3: Blocks=5, block size min=3136, max=4096
File 4: Blocks=1, block size min=80, max=80
File 5: Blocks=1, block size min=80, max=80
File 6: Blocks=3, block size min=3088, max=4096
End of tape.

---------------------
Filename            : test-4096.aws
---------------------
File #              : 1
Blocks              : 10
Min Blocksize       : 30560
Max Blocksize       : 32000
Uncompressed bytes  : 318560
Min Blocksize-Comp  : 30560
Max Blocksize-Comp  : 32000
Compressed bytes    : 318560
---------------------
File #              : 2
Blocks              : 2
Min Blocksize       : 2960
Max Blocksize       : 32000
Uncompressed bytes  : 34960
Min Blocksize-Comp  : 2960
Max Blocksize-Comp  : 32000
Compressed bytes    : 34960
---------------------
File #              : 3
Blocks              : 1
Min Blocksize       : 19520
Max Blocksize       : 19520
Uncompressed bytes  : 19520
Min Blocksize-Comp  : 19520
Max Blocksize-Comp  : 19520
Compressed bytes    : 19520
---------------------
File #              : 4
Blocks              : 1
Min Blocksize       : 80
Max Blocksize       : 80
Uncompressed bytes  : 80
Min Blocksize-Comp  : 80
Max Blocksize-Comp  : 80
Compressed bytes    : 80
---------------------
File #              : 5
Blocks              : 1
Min Blocksize       : 80
Max Blocksize       : 80
Uncompressed bytes  : 80
Min Blocksize-Comp  : 80
Max Blocksize-Comp  : 80
Compressed bytes    : 80
---------------------
File #              : 6
Blocks              : 1
Min Blocksize       : 11280
Max Blocksize       : 11280
Uncompressed bytes  : 11280
Min Blocksize-Comp  : 11280
Max Blocksize-Comp  : 11280
Compressed bytes    : 11280
---------------------
Summary             :
Files               : 6
Blocks              : 16
Uncompressed bytes  : 384480
Compressed bytes    : 384480
Reduction           : 0

Example #3 - HET image - # of blocks matches, but TAPEMAP report compressed block sizes, not correct block sizes.

File 1: Blocks=10, block size min=3338, max=7134
File 2: Blocks=2, block size min=525, max=6169
File 3: Blocks=1, block size min=3783, max=3783
File 4: Blocks=1, block size min=44, max=44
File 5: Blocks=1, block size min=44, max=44
File 6: Blocks=1, block size min=2205, max=2205
End of tape.
---------------------
Filename            : test.het
---------------------
File #              : 1
Blocks              : 10
Min Blocksize       : 30560
Max Blocksize       : 32000
Uncompressed bytes  : 318560
Min Blocksize-Comp  : 3338
Max Blocksize-Comp  : 7134
Compressed bytes    : 56316
---------------------
File #              : 2
Blocks              : 2
Min Blocksize       : 2960
Max Blocksize       : 32000
Uncompressed bytes  : 34960
Min Blocksize-Comp  : 525
Max Blocksize-Comp  : 6169
Compressed bytes    : 6694
---------------------
File #              : 3
Blocks              : 1
Min Blocksize       : 19520
Max Blocksize       : 19520
Uncompressed bytes  : 19520
Min Blocksize-Comp  : 3783
Max Blocksize-Comp  : 3783
Compressed bytes    : 3783
---------------------
File #              : 4
Blocks              : 1
Min Blocksize       : 80
Max Blocksize       : 80
Uncompressed bytes  : 80
Min Blocksize-Comp  : 44
Max Blocksize-Comp  : 44
Compressed bytes    : 44
---------------------
File #              : 5
Blocks              : 1
Min Blocksize       : 80
Max Blocksize       : 80
Uncompressed bytes  : 80
Min Blocksize-Comp  : 44
Max Blocksize-Comp  : 44
Compressed bytes    : 44
---------------------
File #              : 6
Blocks              : 1
Min Blocksize       : 11280
Max Blocksize       : 11280
Uncompressed bytes  : 11280
Min Blocksize-Comp  : 2205
Max Blocksize-Comp  : 2205
Compressed bytes    : 2205
---------------------
Summary             :
Files               : 6
Blocks              : 16
Uncompressed bytes  : 384480
Compressed bytes    : 69086
Reduction           : 315394

> > The utility shouldn't report 3 different things for a single tape
> > based upon how the image is stored.

> > Phil
 
> Actually what it should probably be doing (but then maybe this
> would be even MORE misleading??) is internally invoking HETMAP for
> HET tapes since it's technically a file format tapemap wasn't meant
> to handle.

As I mentioned in the 1st post, perhaps another argument for HETMAP to report a 1 line output as TAPEMAP does now but with correct values output.
 
> Tapemap is supposed to be for aws format only. HETMAP can handle
> either as I recall, but tapemap doesn't understand HET format.

Does HETMAP also handle Fake-Tape ?  Or does HETMAP use whatever code in current in Hercules tape handling so that 'new' tape formats are processed correctly ?
 
> To tapemap a HET file is just an AWS file. It doesn't know about
> (doesn't care about) the fact that the chunks are compressed (and
> thus the ACTUAL chunk size is much larger than the actual
> *physical* chunk size). From ITS point of view the size of the
> chunk/block is THE size of the chunk/block.

Yes, but neither I or the OS for which I have to prepare JCL or other things to read the tape properly care how many bytes are compressed or what size a compress block is.  We only care about the original blocksize.

> But I can see that we should probably at the very least be using
> the terms "Chunks" and "chunk size" rather than the currently
> misleading "Blocks" and "block size" terminology. Would making that
> change make you happy?

It's not about making me or anyone else happy.  The results are wrong.  Providing information that is not used anywhere doesn't make much sense to me and MVS would just abend on the read of a block if the JCL utilized the reported values of compressed blocksize.

> What about my idea about it internally invoking HETMAP for het
> tapes? (since> HET =/= AWS) How does that sit with you?

If it gets rid of the maintenance burden of TAPEMAP then yea, yahoo !

If it reports incorrect blocksizes, then phooey.

> For that matter how do others feel about these issues/ideas?

Looks like it's just us so far.

Phil

[Harold Grovesteen-2]

halfmeg wrote:

>>Fish wrote:
>>    
>>
>
>  
>
>>>halfmeg wrote:
>>>      
>>>
>
>  
>
>>>In addition to TAPEMAP producing different results for AWS
>>>vs HET images, it reports bad info when an AWS image is chunked
>>>to a specific size.
>>>      
>>>
>
>  
>
>>Oh?
>>    
>>
>
>  
>
>><snip>
>>    
>>
>
>  
>
>>Hmmm. I guess we should perhaps be using different terminology. The
>>values reported are probably correct. It's probably the use of the
>>terms "Blocks" and "block size" that are misleading you.
>>The "Blocks" values is actually the number of CHUNKS the program
>>read, and the "block size" values it reports are actually CHUNK
>>size values.
>>    
>>
>
>  
>
>>You DO understand the difference, right?
>>    
>>
>
>  
>
>><snip>
>>    
>>
>
>Yes, I understand perfectly.  TAPEMAP was probably written before HET was ever around and not updated to accomidate HET tapes.  It does seem to report values for the virtual tape's physical block size for the virtual container instead of the physical tape's block size which is stored in the virtual container whether AWS or HET.
>
>The virtual container's block size is immaterial to MVS or VM and provides no help at all in construction JCL or whatever VM may use to read the tape's true original blocksize.
>
>In addition, Hercules has added the ability to utilize FLEX-ES Fake-Tape format.  Don't believe TAPEMAP has been updated to handle that either.  Not sure if HETMAP uses the same underlying code as Hercules of if the utilities are seperate and static.  If static, then HETMAP may not handle Fake-Tape format either.
>
>So do we trust what the Hercule's User Reference states on page 356:
>
>"The Hercules tape map program shows the content of an AWS or HET tape. It displays all header data contained on the tape. Please note that the utility does not display the actual contents of the files. Although the TAPEMAP utility does display the same data as the HETMAP utility, the output is formatted in a totally different way."
>
>If so, then the below examples where TAPEMAP blocksizes differ from HETMAP are incorrect.  Example 1 is only one where TAPEMAP and HETMAP are the same.  Example #2 is strict AWS standard which TAPEMAP should report correctly but doesn't.  Example #3 is HET tape which TAPEMAP never claimed to process correctly but shows TAPMAP doesn't reject it and reports values different from HETMAP.
>
>Downloaded CBT072 ( tape072.zip ) from CBT Tape site ( small tape < 2M ).  http://www.cbttape.org/c249down.htm
>
>Unzipped it, ran "tapesplt cbt072.aws test.aws 6" to get a subset.
>
>Ran "hetupd -s test.aws test-4096.aws" which according to HETUPD creates a "strict AWSTAPE specification (chunksize=4096,no compression)", so still a AWS image processable by TAPEMAP.
>
>Ran "hetupd test.aws test.het" to get the HET image.
>
>Example #1 - plain AWS image - TAPEMAP & HETMAP report same blocks and blocksizes.
>
>File 1: Blocks=10, block size min=30560, max=32000
>File 2: Blocks=2, block size min=2960, max=32000
>File 3: Blocks=1, block size min=19520, max=19520
>File 4: Blocks=1, block size min=80, max=80
>File 5: Blocks=1, block size min=80, max=80
>File 6: Blocks=1, block size min=11280, max=11280
>End of tape.
>
>---------------------
>Filename            : test.aws
>---------------------
>File #              : 1
>Blocks              : 10
>Min Blocksize       : 30560
>Max Blocksize       : 32000
>Uncompressed bytes  : 318560
>Min Blocksize-Comp  : 30560
>Max Blocksize-Comp  : 32000
>Compressed bytes    : 318560
>---------------------
>File #              : 2
>Blocks              : 2
>Min Blocksize       : 2960
>Max Blocksize       : 32000
>Uncompressed bytes  : 34960
>Min Blocksize-Comp  : 2960
>Max Blocksize-Comp  : 32000
>Compressed bytes    : 34960
>---------------------
>File #              : 3
>Blocks              : 1
>Min Blocksize       : 19520
>Max Blocksize       : 19520
>Uncompressed bytes  : 19520
>Min Blocksize-Comp  : 19520
>Max Blocksize-Comp  : 19520
>Compressed bytes    : 19520
>---------------------
>File #              : 4
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 80
>Max Blocksize-Comp  : 80
>Compressed bytes    : 80
>---------------------
>File #              : 5
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 80
>Max Blocksize-Comp  : 80
>Compressed bytes    : 80
>---------------------
>File #              : 6
>Blocks              : 1
>Min Blocksize       : 11280
>Max Blocksize       : 11280
>Uncompressed bytes  : 11280
>Min Blocksize-Comp  : 11280
>Max Blocksize-Comp  : 11280
>Compressed bytes    : 11280
>---------------------
>Summary             :
>Files               : 6
>Blocks              : 16
>Uncompressed bytes  : 384480
>Compressed bytes    : 384480
>Reduction           : 0
>
>Example #2 - Strict AWS Image ( 4096 Chunk size ) - nothing matches, # of blocks, min or max blocksizes.
>
>File 1: Blocks=80, block size min=1888, max=4096
>File 2: Blocks=9, block size min=2960, max=4096
>File 3: Blocks=5, block size min=3136, max=4096
>File 4: Blocks=1, block size min=80, max=80
>File 5: Blocks=1, block size min=80, max=80
>File 6: Blocks=3, block size min=3088, max=4096
>End of tape.
>
>---------------------
>Filename            : test-4096.aws
>---------------------
>File #              : 1
>Blocks              : 10
>Min Blocksize       : 30560
>Max Blocksize       : 32000
>Uncompressed bytes  : 318560
>Min Blocksize-Comp  : 30560
>Max Blocksize-Comp  : 32000
>Compressed bytes    : 318560
>---------------------
>File #              : 2
>Blocks              : 2
>Min Blocksize       : 2960
>Max Blocksize       : 32000
>Uncompressed bytes  : 34960
>Min Blocksize-Comp  : 2960
>Max Blocksize-Comp  : 32000
>Compressed bytes    : 34960
>---------------------
>File #              : 3
>Blocks              : 1
>Min Blocksize       : 19520
>Max Blocksize       : 19520
>Uncompressed bytes  : 19520
>Min Blocksize-Comp  : 19520
>Max Blocksize-Comp  : 19520
>Compressed bytes    : 19520
>---------------------
>File #              : 4
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 80
>Max Blocksize-Comp  : 80
>Compressed bytes    : 80
>---------------------
>File #              : 5
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 80
>Max Blocksize-Comp  : 80
>Compressed bytes    : 80
>---------------------
>File #              : 6
>Blocks              : 1
>Min Blocksize       : 11280
>Max Blocksize       : 11280
>Uncompressed bytes  : 11280
>Min Blocksize-Comp  : 11280
>Max Blocksize-Comp  : 11280
>Compressed bytes    : 11280
>---------------------
>Summary             :
>Files               : 6
>Blocks              : 16
>Uncompressed bytes  : 384480
>Compressed bytes    : 384480
>Reduction           : 0
>
>Example #3 - HET image - # of blocks matches, but TAPEMAP report compressed block sizes, not correct block sizes.
>
>File 1: Blocks=10, block size min=3338, max=7134
>File 2: Blocks=2, block size min=525, max=6169
>File 3: Blocks=1, block size min=3783, max=3783
>File 4: Blocks=1, block size min=44, max=44
>File 5: Blocks=1, block size min=44, max=44
>File 6: Blocks=1, block size min=2205, max=2205
>End of tape.
>---------------------
>Filename            : test.het
>---------------------
>File #              : 1
>Blocks              : 10
>Min Blocksize       : 30560
>Max Blocksize       : 32000
>Uncompressed bytes  : 318560
>Min Blocksize-Comp  : 3338
>Max Blocksize-Comp  : 7134
>Compressed bytes    : 56316
>---------------------
>File #              : 2
>Blocks              : 2
>Min Blocksize       : 2960
>Max Blocksize       : 32000
>Uncompressed bytes  : 34960
>Min Blocksize-Comp  : 525
>Max Blocksize-Comp  : 6169
>Compressed bytes    : 6694
>---------------------
>File #              : 3
>Blocks              : 1
>Min Blocksize       : 19520
>Max Blocksize       : 19520
>Uncompressed bytes  : 19520
>Min Blocksize-Comp  : 3783
>Max Blocksize-Comp  : 3783
>Compressed bytes    : 3783
>---------------------
>File #              : 4
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 44
>Max Blocksize-Comp  : 44
>Compressed bytes    : 44
>---------------------
>File #              : 5
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 44
>Max Blocksize-Comp  : 44
>Compressed bytes    : 44
>---------------------
>File #              : 6
>Blocks              : 1
>Min Blocksize       : 11280
>Max Blocksize       : 11280
>Uncompressed bytes  : 11280
>Min Blocksize-Comp  : 2205
>Max Blocksize-Comp  : 2205
>Compressed bytes    : 2205
>---------------------
>Summary             :
>Files               : 6
>Blocks              : 16
>Uncompressed bytes  : 384480
>Compressed bytes    : 69086
>Reduction           : 315394
>
>  
>
>>>The utility shouldn't report 3 different things for a single tape
>>>based upon how the image is stored.
>>>      
>>>
>
>  
>
>>>Phil
>>>      
>>>
>
>  
>
>>Actually what it should probably be doing (but then maybe this
>>would be even MORE misleading??) is internally invoking HETMAP for
>>HET tapes since it's technically a file format tapemap wasn't meant
>>to handle.
>>    
>>
>
>As I mentioned in the 1st post, perhaps another argument for HETMAP to report a 1 line output as TAPEMAP does now but with correct values output.
>
>  
>
>>Tapemap is supposed to be for aws format only. HETMAP can handle
>>either as I recall, but tapemap doesn't understand HET format.
>>    
>>
>
>Does HETMAP also handle Fake-Tape ?  Or does HETMAP use whatever code in current in Hercules tape handling so that 'new' tape formats are processed correctly ?
>
>  
>
>>To tapemap a HET file is just an AWS file. It doesn't know about
>>(doesn't care about) the fact that the chunks are compressed (and
>>thus the ACTUAL chunk size is much larger than the actual
>>*physical* chunk size). From ITS point of view the size of the
>>chunk/block is THE size of the chunk/block.
>>    
>>
>
>Yes, but neither I or the OS for which I have to prepare JCL or other things to read the tape properly care how many bytes are compressed or what size a compress block is.  We only care about the original blocksize.
>
>  
>
>>But I can see that we should probably at the very least be using
>>the terms "Chunks" and "chunk size" rather than the currently
>>misleading "Blocks" and "block size" terminology. Would making that
>>change make you happy?
>>    
>>
>
>It's not about making me or anyone else happy.  The results are wrong.  Providing information that is not used anywhere doesn't make much sense to me and MVS would just abend on the read of a block if the JCL utilized the reported values of compressed blocksize.
>
>  
>
>>What about my idea about it internally invoking HETMAP for het
>>tapes? (since> HET =/= AWS) How does that sit with you?
>>    
>>
>
>If it gets rid of the maintenance burden of TAPEMAP then yea, yahoo !
>

It looks to me like TAPEMAP should be deprecated and replaced by
HETMAP.  Or TAPEMAP and HETMAP invoke the same executable.  If we keep
TAPEMAP, then we should document it supports only plain AWS tapes.  
Tweaking the HETMAP verbiage for clarity is a separate consideration.  
My vote is dump TAPEMAP.  It now provides no real value, other than some
might like the output format better.  That too could likely be made a
part of the HETMAP output by adding a -verbose option for everything and
the one-line/file without it.

>
>If it reports incorrect blocksizes, then phooey.
>
>  
>
>>For that matter how do others feel about these issues/ideas?
>>    
>>
>
>Looks like it's just us so far.
>

Not really, but I don't have the time to address it and probably nobody
else has either.  I think some documentation updates are needed regardless.

>
>Phil
>
>
>
>------------------------------------
>
>Community email addresses:
>  Post message: hercules-390@...
>  Subscribe:    hercules-390-subscribe@...
>  Unsubscribe:  hercules-390-unsubscribe@...
>  List owner:   hercules-390-owner@...
>
>Files and archives at:
>  http://groups.yahoo.com/group/hercules-390
>
>Get the latest version of Hercules from:
>  http://www.hercules-390.org
>
>Yahoo! Groups Links
>
>
>
>
>  
>

[au1john]

Harold,
It took me an age to find your points in this. How easily can you see your
stuff below?
I think some trimming is needed when you reply.



-----Original Message-----
From: hercules-390@... [mailto:hercules-390@...] On
Behalf Of Harold Grovesteen
Sent: Wednesday, 7 October 2009 20:46
To: hercules-390@...
Subject: Re: [hercules-390] Re: TAPEMAP Bug



halfmeg wrote:

>>Fish wrote:
>>    
>>
>
>  
>
>>>halfmeg wrote:
>>>      
>>>
>
>  
>
>>>In addition to TAPEMAP producing different results for AWS
>>>vs HET images, it reports bad info when an AWS image is chunked
>>>to a specific size.
>>>      
>>>
>
>  
>
>>Oh?
>>    
>>
>
>  
>
>><snip>
>>    
>>
>
>  
>
>>Hmmm. I guess we should perhaps be using different terminology. The
>>values reported are probably correct. It's probably the use of the
>>terms "Blocks" and "block size" that are misleading you.
>>The "Blocks" values is actually the number of CHUNKS the program
>>read, and the "block size" values it reports are actually CHUNK
>>size values.
>>    
>>
>
>  
>
>>You DO understand the difference, right?
>>    
>>
>
>  
>
>><snip>
>>    
>>
>
>Yes, I understand perfectly.  TAPEMAP was probably written before HET was

ever around and not updated to accomidate HET tapes.  It does seem to report
values for the virtual tape's physical block size for the virtual container
instead of the physical tape's block size which is stored in the virtual
container whether AWS or HET.
>
>The virtual container's block size is immaterial to MVS or VM and provides
no help at all in construction JCL or whatever VM may use to read the tape's
true original blocksize.
>
>In addition, Hercules has added the ability to utilize FLEX-ES Fake-Tape
format.  Don't believe TAPEMAP has been updated to handle that either.  Not
sure if HETMAP uses the same underlying code as Hercules of if the utilities
are seperate and static.  If static, then HETMAP may not handle Fake-Tape
format either.
>
>So do we trust what the Hercule's User Reference states on page 356:
>
>"The Hercules tape map program shows the content of an AWS or HET tape. It
displays all header data contained on the tape. Please note that the utility
does not display the actual contents of the files. Although the TAPEMAP
utility does display the same data as the HETMAP utility, the output is
formatted in a totally different way."
>
>If so, then the below examples where TAPEMAP blocksizes differ from HETMAP
are incorrect.  Example 1 is only one where TAPEMAP and HETMAP are the same.
Example #2 is strict AWS standard which TAPEMAP should report correctly but
doesn't.  Example #3 is HET tape which TAPEMAP never claimed to process
correctly but shows TAPMAP doesn't reject it and reports values different
from HETMAP.
>
>Downloaded CBT072 ( tape072.zip ) from CBT Tape site ( small tape < 2M ).
http://www.cbttape.org/c249down.htm
>
>Unzipped it, ran "tapesplt cbt072.aws test.aws 6" to get a subset.
>
>Ran "hetupd -s test.aws test-4096.aws" which according to HETUPD creates a
"strict AWSTAPE specification (chunksize=4096,no compression)", so still a
AWS image processable by TAPEMAP.
>
>Ran "hetupd test.aws test.het" to get the HET image.
>
>Example #1 - plain AWS image - TAPEMAP & HETMAP report same blocks and
blocksizes.

>
>File 1: Blocks=10, block size min=30560, max=32000
>File 2: Blocks=2, block size min=2960, max=32000
>File 3: Blocks=1, block size min=19520, max=19520
>File 4: Blocks=1, block size min=80, max=80
>File 5: Blocks=1, block size min=80, max=80
>File 6: Blocks=1, block size min=11280, max=11280
>End of tape.
>
>---------------------
>Filename            : test.aws
>---------------------
>File #              : 1
>Blocks              : 10
>Min Blocksize       : 30560
>Max Blocksize       : 32000
>Uncompressed bytes  : 318560
>Min Blocksize-Comp  : 30560
>Max Blocksize-Comp  : 32000
>Compressed bytes    : 318560
>---------------------
>File #              : 2
>Blocks              : 2
>Min Blocksize       : 2960
>Max Blocksize       : 32000
>Uncompressed bytes  : 34960
>Min Blocksize-Comp  : 2960
>Max Blocksize-Comp  : 32000
>Compressed bytes    : 34960
>---------------------
>File #              : 3
>Blocks              : 1
>Min Blocksize       : 19520
>Max Blocksize       : 19520
>Uncompressed bytes  : 19520
>Min Blocksize-Comp  : 19520
>Max Blocksize-Comp  : 19520
>Compressed bytes    : 19520
>---------------------
>File #              : 4
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 80
>Max Blocksize-Comp  : 80
>Compressed bytes    : 80
>---------------------
>File #              : 5
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 80
>Max Blocksize-Comp  : 80
>Compressed bytes    : 80
>---------------------
>File #              : 6
>Blocks              : 1
>Min Blocksize       : 11280
>Max Blocksize       : 11280
>Uncompressed bytes  : 11280
>Min Blocksize-Comp  : 11280
>Max Blocksize-Comp  : 11280
>Compressed bytes    : 11280
>---------------------
>Summary             :
>Files               : 6
>Blocks              : 16
>Uncompressed bytes  : 384480
>Compressed bytes    : 384480
>Reduction           : 0
>
>Example #2 - Strict AWS Image ( 4096 Chunk size ) - nothing matches, # of

blocks, min or max blocksizes.

>
>File 1: Blocks=80, block size min=1888, max=4096
>File 2: Blocks=9, block size min=2960, max=4096
>File 3: Blocks=5, block size min=3136, max=4096
>File 4: Blocks=1, block size min=80, max=80
>File 5: Blocks=1, block size min=80, max=80
>File 6: Blocks=3, block size min=3088, max=4096
>End of tape.
>
>---------------------
>Filename            : test-4096.aws
>---------------------
>File #              : 1
>Blocks              : 10
>Min Blocksize       : 30560
>Max Blocksize       : 32000
>Uncompressed bytes  : 318560
>Min Blocksize-Comp  : 30560
>Max Blocksize-Comp  : 32000
>Compressed bytes    : 318560
>---------------------
>File #              : 2
>Blocks              : 2
>Min Blocksize       : 2960
>Max Blocksize       : 32000
>Uncompressed bytes  : 34960
>Min Blocksize-Comp  : 2960
>Max Blocksize-Comp  : 32000
>Compressed bytes    : 34960
>---------------------
>File #              : 3
>Blocks              : 1
>Min Blocksize       : 19520
>Max Blocksize       : 19520
>Uncompressed bytes  : 19520
>Min Blocksize-Comp  : 19520
>Max Blocksize-Comp  : 19520
>Compressed bytes    : 19520
>---------------------
>File #              : 4
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 80
>Max Blocksize-Comp  : 80
>Compressed bytes    : 80
>---------------------
>File #              : 5
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 80
>Max Blocksize-Comp  : 80
>Compressed bytes    : 80
>---------------------
>File #              : 6
>Blocks              : 1
>Min Blocksize       : 11280
>Max Blocksize       : 11280
>Uncompressed bytes  : 11280
>Min Blocksize-Comp  : 11280
>Max Blocksize-Comp  : 11280
>Compressed bytes    : 11280
>---------------------
>Summary             :
>Files               : 6
>Blocks              : 16
>Uncompressed bytes  : 384480
>Compressed bytes    : 384480
>Reduction           : 0
>
>Example #3 - HET image - # of blocks matches, but TAPEMAP report compressed

block sizes, not correct block sizes.

>
>File 1: Blocks=10, block size min=3338, max=7134
>File 2: Blocks=2, block size min=525, max=6169
>File 3: Blocks=1, block size min=3783, max=3783
>File 4: Blocks=1, block size min=44, max=44
>File 5: Blocks=1, block size min=44, max=44
>File 6: Blocks=1, block size min=2205, max=2205
>End of tape.
>---------------------
>Filename            : test.het
>---------------------
>File #              : 1
>Blocks              : 10
>Min Blocksize       : 30560
>Max Blocksize       : 32000
>Uncompressed bytes  : 318560
>Min Blocksize-Comp  : 3338
>Max Blocksize-Comp  : 7134
>Compressed bytes    : 56316
>---------------------
>File #              : 2
>Blocks              : 2
>Min Blocksize       : 2960
>Max Blocksize       : 32000
>Uncompressed bytes  : 34960
>Min Blocksize-Comp  : 525
>Max Blocksize-Comp  : 6169
>Compressed bytes    : 6694
>---------------------
>File #              : 3
>Blocks              : 1
>Min Blocksize       : 19520
>Max Blocksize       : 19520
>Uncompressed bytes  : 19520
>Min Blocksize-Comp  : 3783
>Max Blocksize-Comp  : 3783
>Compressed bytes    : 3783
>---------------------
>File #              : 4
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 44
>Max Blocksize-Comp  : 44
>Compressed bytes    : 44
>---------------------
>File #              : 5
>Blocks              : 1
>Min Blocksize       : 80
>Max Blocksize       : 80
>Uncompressed bytes  : 80
>Min Blocksize-Comp  : 44
>Max Blocksize-Comp  : 44
>Compressed bytes    : 44
>---------------------
>File #              : 6
>Blocks              : 1
>Min Blocksize       : 11280
>Max Blocksize       : 11280
>Uncompressed bytes  : 11280
>Min Blocksize-Comp  : 2205
>Max Blocksize-Comp  : 2205
>Compressed bytes    : 2205
>---------------------
>Summary             :
>Files               : 6
>Blocks              : 16
>Uncompressed bytes  : 384480
>Compressed bytes    : 69086
>Reduction           : 315394
>
>  
>
>>>The utility shouldn't report 3 different things for a single tape
>>>based upon how the image is stored.
>>>      
>>>
>
>  
>
>>>Phil
>>>      
>>>
>
>  
>
>>Actually what it should probably be doing (but then maybe this
>>would be even MORE misleading??) is internally invoking HETMAP for
>>HET tapes since it's technically a file format tapemap wasn't meant
>>to handle.
>>    
>>
>
>As I mentioned in the 1st post, perhaps another argument for HETMAP to

report a 1 line output as TAPEMAP does now but with correct values output.
>
>  
>
>>Tapemap is supposed to be for aws format only. HETMAP can handle
>>either as I recall, but tapemap doesn't understand HET format.
>>    
>>
>
>Does HETMAP also handle Fake-Tape ?  Or does HETMAP use whatever code in
current in Hercules tape handling so that 'new' tape formats are processed
correctly ?

>
>  
>
>>To tapemap a HET file is just an AWS file. It doesn't know about
>>(doesn't care about) the fact that the chunks are compressed (and
>>thus the ACTUAL chunk size is much larger than the actual
>>*physical* chunk size). From ITS point of view the size of the
>>chunk/block is THE size of the chunk/block.
>>    
>>
>
>Yes, but neither I or the OS for which I have to prepare JCL or other

things to read the tape properly care how many bytes are compressed or what
size a compress block is.  We only care about the original blocksize.

>
>  
>
>>But I can see that we should probably at the very least be using
>>the terms "Chunks" and "chunk size" rather than the currently
>>misleading "Blocks" and "block size" terminology. Would making that
>>change make you happy?
>>    
>>
>
>It's not about making me or anyone else happy.  The results are wrong.

Providing information that is not used anywhere doesn't make much sense to
me and MVS would just abend on the read of a block if the JCL utilized the
reported values of compressed blocksize.

>
>  
>
>>What about my idea about it internally invoking HETMAP for het
>>tapes? (since> HET =/= AWS) How does that sit with you?
>>    
>>
>
>If it gets rid of the maintenance burden of TAPEMAP then yea, yahoo !
>

It looks to me like TAPEMAP should be deprecated and replaced by
HETMAP.  Or TAPEMAP and HETMAP invoke the same executable.  If we keep
TAPEMAP, then we should document it supports only plain AWS tapes.  
Tweaking the HETMAP verbiage for clarity is a separate consideration.  
My vote is dump TAPEMAP.  It now provides no real value, other than some
might like the output format better.  That too could likely be made a
part of the HETMAP output by adding a -verbose option for everything and
the one-line/file without it.

>
>If it reports incorrect blocksizes, then phooey.
>
>  
>
>>For that matter how do others feel about these issues/ideas?
>>    
>>
>
>Looks like it's just us so far.
>

Not really, but I don't have the time to address it and probably nobody
else has either.  I think some documentation updates are needed regardless.

>
>Phil
>
>
>

[Harold Grovesteen-2]

To the list member who was annoyed by my lack of trimming, please accept
my apologies.  When I tried to trim it to repond, Netscape decided to
eat the list email and it disappeared into the ether.  Again, sorry.

Harold

[fish-8]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

au1john wrote:

> Harold,
> It took me an age to find your points in this.
> How easily can you see your stuff below? I think
> some trimming is needed when you reply.

<CHOMP!>

People in glass houses...  :)

- --
"Fish" (David B. Trout) - fish@...
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52





-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.8.0 (Build 2158)
Charset: us-ascii

wj8DBQFKzoruSPXX9MTuPioRAvLfAJ9P7o5ANyYUBjAEayiesO4a+kpwHwCePHIl
hUBFQH1kZhvUZBnEBIeSpEw=
=cJcM
-----END PGP SIGNATURE-----

[fish-8]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harold Grovesteen wrote:

<CHOMP!>

Trimming posts is good, m'kay?

> It looks to me like TAPEMAP should be deprecated and
> replaced by HETMAP.

Good idea. I'm for it. Others?


> Or TAPEMAP and HETMAP invoke the same executable.

That's sort of what I was originally thinking: tossing out the code for
tapemap altogether and simply adding a new build option for hetmap (e.g.
"OPTION_TAPEMAP"?) that when set would cause the existing hetmap code to
simply issue a deprecation warning at startup before falling into existing
hetmap code.

The new "OPTION_TAPEMAP" build option could also be used to cause hetmap to
output the information in the same compact one line format currently used by
tapemap that Phil and I presume others like so much.

How does that sound Phil?


> If we keep TAPEMAP, then we should document it supports
> only plain AWS tapes. Tweaking the HETMAP verbiage for
> clarity is a separate consideration.

Our documentation definitely needs updating.


> My vote is dump TAPEMAP.  It now provides no real value,
> other than some might like the output format better.
> That too could likely be made a part of the HETMAP output
> by adding a -verbose option for everything and the
> one-line/file without it.

An excellent idea IMO!

Unless there are no objections I'll add that to my TODO list.

I just really need to concentrate on finishing HercGUI et al. It's been over
TWO YEARS since I've released an update to it and I'm very close to having
it done.


- --
"Fish" (David B. Trout) - fish@...
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52





-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.8.0 (Build 2158)
Charset: us-ascii

wj8DBQFKzo/SSPXX9MTuPioRAs/sAJ90DYfG6AGuSwDpd2G3mEZ7m4UdUwCfRwtU
OjgnoN/E/0nlM5hia2+vlOo=
=AR7s
-----END PGP SIGNATURE-----

[fish-8]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

halfmeg wrote:

[...]
> As I mentioned in the 1st post, perhaps another argument for HETMAP
> to report a 1 line output as TAPEMAP does now but with correct values
> output.

I think we all agree that sounds like a good idea.


> > Tapemap is supposed to be for aws format only. HETMAP can handle
> > either as I recall, but tapemap doesn't understand HET format.
>
> Does HETMAP also handle Fake-Tape?

Not as far as I know, no.


> Or does HETMAP use whatever code in current in Hercules tape
> handling so that 'new' tape formats are processed correctly ?

No. It presumes the specified file is a HET file.


[...]
> [...] We only care about the original blocksize.

I understand that.


> > But I can see that we should probably at the very least be using
> > the terms "Chunks" and "chunk size" rather than the currently
> > misleading "Blocks" and "block size" terminology. Would making that
> > change make you happy?
>
> It's not about making me or anyone else happy.  The results are wrong.

But only because its terminology is wrong, thus causing the user to
misinterpret its report.


> Providing information that is not used anywhere doesn't make much
> sense to me

Oh, but it *IS* used!

Just not by the average user, that's all.  :)


> and MVS would just abend on the read of a block if the JCL utilized
> the reported values of compressed blocksize.

Understood.


> > What about my idea about it internally invoking HETMAP for het
> > tapes? (since> HET =/= AWS) How does that sit with you?
>
> If it gets rid of the maintenance burden of TAPEMAP then yea, yahoo !
>
> If it reports incorrect blocksizes, then phooey.

I've added this change to my TODO list.

           ** NOTE! **    (to other developers..)

Just because I say I've added it to "my" TODO list does NOT of course mean
that I'm somehow ultimately responsible for seeing that it gets done! The
responsibility to see that it gets done is *ALL* of ours! (meaning of course
that if any of you have the time to make this change then PLEASE, by all
means, do so! Please DON'T wait for me to do it!)

- --
"Fish" (David B. Trout) - fish@...
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52





-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.8.0 (Build 2158)
Charset: us-ascii

wj8DBQFKzwtCSPXX9MTuPioRAt5nAKCVkqtGEPN9Vn8JcmitPqJbcQXeHQCfajvY
rAHeKkOIACopRUMlQXxfEk0=
=owWH
-----END PGP SIGNATURE-----

[fish-8]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

THANK YOU Kevin!

- --
"Fish" (David B. Trout) - fish@...
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52



-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.8.0 (Build 2158)
Charset: us-ascii

wj8DBQFK1Fh0SPXX9MTuPioRAt2vAJ91UdHaTpkOuPApQLS/ikZHSIX1gACgiNRo
qEkEZdHy6fsawJoRDofJ+T0=
=T8s1
-----END PGP SIGNATURE-----