RE: Burning V5R3 CD image files (was i5 backup options without tape)

midrange-l-request@xxxxxxxxxxxx wrote:

>   3. RE: Burning V5R3 CD image files (was i5 backup options
>      without tape) (Wilt, Charles)
>
>You sure about that?
>
>I've never had a CD that couldn't be read by all the interfaces if it could be 
>read by one.
>
>In addition, my gut reaction is that your statement is incorrect, but I don't 
>have anything to back it up.  Do you have anything to prove it true?

Charles:

I'm trying to recall the last time I was "sure" about _any_ element of 
programming... Oh, yeah... A few minutes ago, I was "sure" I'd specified a 
pre-run command correctly on a TurnOver form promotion. But the blasted compile 
kept failing. Finally noticed that I was adding a library to the current 
library list rather than the "application" library list. (Might not make sense 
if you don't use TurnOver, but I'm _sure_ you know what I mean.)

Anyway, I recall noting differences in areas such as DSPOPT DATA(*VOLATR) and 
DSPOPT(*FILEATR). It had to do with incorrect settings when burning the CD, but 
I don't have details in mind. Maybe it had to do with QDSETMAP, maybe it was an 
upper-/lower-case name, maybe something completely different. In any case, once 
all the details of creation and burning were all specified correctly, it all 
fell into place.

Perhaps you've never seen a CD fail in some interfaces because you've never had 
one that was... ummm... created incorrectly in the right way?

If the CD in question works well in some interfaces but not others, that will 
be a significant clue where to look.

Tom Liotta