Jeff writes:
< snip >
> Looks better, but it still fails:
> (MANAGER.SYS)# listf @.backup2,3
> ********************
> FILE: STORE.BACKUP2.SYS
>
> FILE CODE : 2501 FOPTIONS: BINARY,FIXED,NOCCTL,STD
> BLK FACTOR: 1 CREATOR : **
> REC SIZE: 256(BYTES) LOCKWORD: **
> BLK SIZE: 256(BYTES) SECURITY--READ : ANY
> EXT SIZE: 65535(SECT) WRITE : ANY
> NUM REC: 14691733 APPEND : ANY
> NUM SEC: 14691744 LOCK : ANY
> NUM EXT: 7177 EXECUTE : ANY
> MAX REC: 16777000 **SECURITY IS ON
> MAX EXT: 32 FLAGS : NO ACCESSORS
> NUM LABELS: 0 CREATED : SUN, SEP 12, 2004, 1:10 PM
> MAX LABELS: 0 MODIFIED: SUN, SEP 12, 2004, 2:06 PM
> DISC DEV #: 43 ACCESSED: SUN, SEP 12, 2004, 2:06 PM
> SEC OFFSET: 0 LABEL ADDR: **
> VOLCLASS : DEVELOPMENT:DISC
>
> (MANAGER.SYS)# listeq
>
> FILE EQUATIONS
>
> FILE T;DEV=TAPE
> FILE P;DEV=LP
> FILE STORE=STORE.BACKUP2;DEV=DISC
>
> (MANAGER.SYS)# restore *store;;listdir
> >> TURBO-STORE/RESTORE VERSION C.75.08 B5152AA <<
> (C) 1986 HEWLETT-PACKARD CO.
>
> RESTORE *store;;LISTDIR
>
> SUN, SEP 12, 2004, 3:27 PM
>
> WARNING: YOUR DEFAULT FILESET BECOMES [log in to unmask]@.@' SINCE YOU HAVE OP
> OR SM CAPABILITY (S/R 1911)
> This message is reserved.
> STORE/RESTORE WAS UNABLE TO OPEN PERMANENT DISC FILE
> "/SYS/BACKUP2/STORE" OR "/SYS/BACKUP2/STORE" (S/R 2300)
>
> RESTORE aborted because of error. (CIERR 1091)
If the STORE file was corrupt you would get an error from store saying
FILE [whatever] DOES NOT APPEAR TO BE A STORE BACKUP (S/R 1306)
and so on...
The message you are getting says it cannot find the STORE file. The key to knowing why it thinks
it cannot probably lies in the message "This message is reserved.". There are 10 instances of that
in SYSCAT, all are File System. Of the 10 errors 6 are place holders and probably never issued
(didn't check them all), the other 4 errors might occur in rare circumstances. These errors are
237 - HOP_BAD_PREFETCH_OPTION
239 - HOP_CANT_SPECIFY_PARSE_STRING
341 - HOP_BAD_OVERRIDE_PROT[ection]_OPTION
353 - HOP_LARGE_MAPPED_REQUIRED
The first (237) and last (353) seem as if they might be possible in the case where a file is mis-
representing itself to the file system but that's just a swag on my part.
Here's an idea, take the original store-to-disk file and use FCOPY/COMPARE against the file
retrieved from the remote system and see what results. If there are no compare errors then maybe
this is a case of there being something slightly wrong with the construction of the new file. That might
be solved/proven by building a new copy with the exact dimensions needed to hold the data and
copying the FTP'd contents into it.
hth,
Bill
hp/vCSY
===========================================
Reply to: bill . vcsy -at- comcast . net
===========================================
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
