growfs error

[David B. Neal]

I'm creating a bootable dvd (hpux 11.23) from a script called from a job control application and occassionally get error 144 from this command.

/usr/local/bin/growisofs -Z \
/dev/rdsk/c0t0d0=/hpux/image/B.11.23.iso

I run it from the command line and it always works, and works for the calling program about 3 out of 4 times.

Has anyone seen this error and know a solution?
Could it have anything to do with not having a defined tty device in it's calling scipt, but does from the command line?
Thanks for any help.

[Peter Godron]

David,
are you getting error code 144 or return code 144 ?
Return code 144 could be caused by condition 16 (Device busy). Just a theory.

[David B. Neal]

Yes, it is a return code.
If the device is busy, would you have any idea of what would cause that, or maybe a delay for a few seconds may help.
Thanks...

[Peter Godron]

David,
I would certainly try the process with a delay, unless somebody else on the forum has a more detailed understanding of the workings of gowisofs with DVDs. The problem couls also be speed of transfer between background process and DVD writer. It would explain why it works in the forground/command line.

Please also read:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33 on how to reward any useful answers given to your questions.

[Ralph Grothe]

Before producing too many wasted flying saucers I would try running in dummy mode until 4 out of 4 times your job isn't aborted prematurely.
Try if this option prevents the laser from being activated:

-use-the-force-luke=dummy

I can remember, before DVD drives became affordable, that most CD writers had occasional problems with buffer underruns until they came up with so called "burnfree" capable drives.
With old-fashioned cdrecord you would adapt its fifo by specifying a big enough fifo size by the option e.g. fs=4m
This was especially crucial if you piped the output from mkisofs directly into cdrecord, not to mention over a network connection (this was fine with Linux to have a piped backup in Unix style over an rsh or ssh connection when all Windows plagued CD masterers were afraid not to even starta single other application while there was a burning session pending even on the same box ;-)
But most likely buffer underruns aren't an issue anymore with contemporary drives these days?
But maybe it couldn't hurt to have your job run during off-peak hours anyway?
Maybe also reducing the burning speed by e.g. -speed=4 or even less would help?
If you are keen on finding out what your return code signals you could get the sources of mkisofs (the underlying program of growisofs), as well as growisofs and other utilities from the dvd+rw tools and search there (the comments are also quite helpful)
I think (hope) HP haven't pathced them too much.

[David B. Neal]

I suspect a bad tape drive, will replace.