CD mastering via tape using compression

["Peter Dow" <maillist@xxxxxxxxxxxxxxx>]

I've written a little command and program based on IBM's example at

http://www-1.ibm.com/servers/eserver/iseries/optical/cdrom/restore.htm

which is basically:

    -use API QlpHandleCdState to turn on the CD mastering mode
    -SAVLIB with DTACPR(*YES)
    -use API QlpHandleCdState to turn off the CD mastering mode
    -CRTPF tempfile with record length 28672
    -CPYFRMTAP to tempfile with blocklength and recordlength 28672
    -FTP tempfile to a PC

At this point, using Nero software, I burned tempfile onto a CD, stuck it in
the AS400 CD drive, and tried to do a RSTLIB.  After listing each object in
the saved library and stating that it couldn't restore it, it gives message

Message . . . . :   Error decompressing file /tempfile.

Cause . . . . . :   An error occurred while trying to decompress data read
  from a tape, diskette, or optical volume.  The data should have been
  compressed when it was written to the file.  The error occurred while
  processing file *N in library *N on device OPT02.
Recovery  . . . :   If the data writing operation did not complete normally,
  create the input file again. Verify that the correct set of volumes is
  available.  Try the request again. If the problem continues, report the
  problem (ANZPRB command).
Technical description . . . . . . . . :   Conditions that can cause this
error
  include: 1. Mounting an incorrect continuation volume for a multi-volume
  file. 2. Using a volume which did not compress properly because the output
  operation did not complete normally.

Now, this same process, with DTACPR(*NO) on the SAVLIB command, works just
fine.  More interesting stuff -- a DSPTAP DEV(TAP01) DATA(*LABELS)
OUTPUT(*PRINT) of the tape file for both the compressed and non-compressed
versions shows a record length of zero, and a block length of 32760.  This
is odd, because the documentation at the URL noted above says use 28672.

So I tried 32760 instead, and the RSTLIB got an MCH0601 error, clearly not
the solution to my problem.  IBM's documentation has a rather large
paragraph talking about using CPROBJ instead of DTACPR(*YES), but ends up
saying use one or the other, but not both.  Since CPROBJ does not work on
data files, I would like to be able to use DTACPR(*YES), but it clearly
doesn't work, in spite of the documentation implying otherwise (although
their example has DTACPR(*NO)). Am I stuck using 3-4 times the number of
CD's I would need if DTACPR(*YES) worked?  Or does anyone know what the
problem is?  An associate of mine suggests that it's something wrong when
writing to the CD.

tia,
Peter Dow
Dow Software Services, Inc.
909 793-9050 voice
909 522-3214 cellular
909 793-4480 fax