No, SR 4701-321604 doesn't say it was fixed in 5.5 it was reported
against an early 5.5 release. The SR only offers the workaround of trying
not to store > 32K files.
However, I could not reproduce that on 6.5, I used SYSGEN/STORE
to store 42K files, they were empty files but that shouldn't matter. Worked
fine, no errors sysgen/store exited normally.
I did find out (never having used store from sysgen before) that if you
ABORT a sysgen/store you will get the error:
SENDMAIL TO SYSGEN FROM STORE FAILED. (S/R 1741)
The reason you see this is because STORE is designed to gracefully handle
termination so it can clean things up. If you abort the SYSGEN/STORE
process SYGEN goes into a termination as any other process would while
STORE tries to clean up. Part of the clean up is to try to send status to sysgen
via the SENDMAIL intrinsic. This fails with CCG and 3 is returned in the
"mailstatus" variable meaning the pin was illegal. It is illegal because it has
begun termination and is blocked waiting for its child processes, namely
STORE, to exit.
I tried to simulate I/O errors by doing an ABORTIO to the tape while a
sysgen/store was running and it terminated normally. This isn't a very realistic
test but since the tape drive is about 400 miles away I couldn't do what I
usually do which is reach around back of the device and jiggle the SCSI
cable ("professional driver on a closed course " - don't try this at home :-).
So I cannot prove that the I/O error scenario explains what Campbell saw but
that'd be my suspicion.
In looking more closely at what Donna saw, I'm not sure what might have
triggered that. If it wasn't aborted it is possible that some sort of trap occured
when SENDMAIL was called, it's coded to treat a trap the same as bad CCODE
and issue the same error. I have no idea what might have triggered such a trap.
One last thing I noted about sysgen/store is that if it requests a reel switch and you
abort it with that request pending that IS NOT cleaned up as it would be for a
plain old store. So aborting sysgen/store hangs but there is a request for new media
on the console. Since I'm 400 miles away from the tape drive my attempt to
programmatically put the same tape on line failed with filesystem errors - don't know
why, likely the program was the cause. Several abortio's on the tape drive cleared
it and the process ended.
So, bottom line: I couldn't reproduce the error storing > 32K files as that SR said so
either that problem IS fixed and just not documented or maybe it was misdiagnosed.
HTH,
Bill
HP/CSY
> Art Bahrs wrote:
>
> > Hmm... Ok... I am once again (still? Hehe) confused... I thot it
> > sounded like Bill was saying that the SysGen Tape process was designed
> > and built to have a 32k file limit (number of files put on tape) ... and
> > thot of that magic 32767? number from the old days...
>
> ...and i thot(? :-) that bill said it was fixed in 5.5. it could be an old
> code line got introduced into 6.5. - d
>
> --
> Donna Garverick Sr. System Programmer
> 925-210-6631 [log in to unmask]
>
> Come, my friends, 'Tis not too late to seek a newer world.
> Tho' much is taken, much abides; and tho'
> We are not now that strength which in old days
> Moved earth and heaven, that which we are, we are.
> "Ulysses", A. Tennyson
>
> >>>MY opinions, not Longs Drug Stores'<<<
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
