T.R | Title | User | Personal Name | Date | Lines |
---|
363.1 | see note 361 | UTRTSC::KNOL | isn't every bug a bit wrong | Fri Jan 17 1997 01:28 | 5 |
363.2 | Investigating | COOKIE::MHUA | | Tue Jan 21 1997 13:41 | 8 |
363.3 | Successful result from testing here | COOKIE::MHUA | | Tue Jan 21 1997 14:46 | 11 |
363.4 | Catalog update problem? | SUOBOS::RUCKH | | Wed Jan 22 1997 00:29 | 85 |
363.5 | Execute the *.com files | COOKIE::HEISLER | Chris Heisler, ABS Engineering | Wed Jan 22 1997 08:14 | 5 |
363.6 | Staging catalog update log file | COOKIE::MHUA | | Wed Jan 22 1997 10:59 | 12 |
363.7 | no error | SUOBOS::RUCKH | | Thu Jan 23 1997 00:18 | 34 |
363.8 | no update | SUOBOS::RUCKH | | Thu Jan 23 1997 07:31 | 27 |
363.9 | Statistics not collected | COOKIE::MHUA | | Thu Jan 23 1997 09:01 | 8 |
363.10 | Catalog entries still missing? | COOKIE::MHUA | | Thu Jan 23 1997 12:44 | 9 |
363.11 | still missing! | SUOBOS::RUCKH | | Fri Jan 24 1997 03:03 | 8 |
| Masami,
the entries are still missing after running the update.
On my other client nodes there are also all entries for the second
thread missing. On this nodes there are NO *.com files left, only the
*.stg files. The update is running but no update occurs.
Thomas
|
363.12 | try creating a catalog that is NOT a staged catalog | COOKIE::LEWIS | | Fri Jan 24 1997 09:11 | 20 |
| Try creating a catalog that does not use staging, then modify the save
request to use the newly created NON staged catalog. Hopefully this will
give us some errors when the catalog update attempts to take place.
Do small saves if possible so we don't need to write a lot to the catalog,
and we should have smaller log files then also.
I'll be trying some things here to see if I can create or reproduce the
situation.
Do you see any errors in the save log file, (even any warnings or informational
errors? can you post one of the log files from the save request?) In note
361.0 there is an error about the agent info being altered.
This may just be because the unix save template had to be modified, but check
and see. In some testing here last week with RDB saves, we found that the
template file was the problem.
(see chapt 13 for creating new catalogs)
Thanks,
Jim Lewis, ABS engineering
|
363.13 | VMS-systems | SUOBOS::RUCKH | | Mon Jan 27 1997 00:36 | 7 |
| Jim,
I can't log in today to the customer system. Please show 336.11 or
360.3 for the log. BTW, my systems are all VMS-systems with no template
modified.
Thomas
|
363.14 | a couple of more questions | COOKIE::LEWIS | | Mon Jan 27 1997 16:36 | 29 |
| Hi Thomas,
I tried some saves here and everything saves and restores ok.
I created a save request and saved a file and a directory. I then restored
the file and a different file from the directory I had saved. It all worked
fine.
I tried an
abs lookup "filename" and that worked also. (Note, I did have
the quotes ^ ^ because I was specifying a unix file. It did find
both files in the catalog.
HOWEVER, If I did an
abs report save_log/full
The number of files it said it saved was incorrect. One of the save requests
showed no files saved (Number of archived objects: 0), but I COULD successfully
restore those files.
Have you tried an ABS LOOKUP to see if it can find the files you saved? Or,
just try and restore one of the files.
For now, we know we have a problem with the abs report save_log command not
showing correct numbers for number of archived objects when archiving multiple
objects in a single save request.
What versions of ABS and VMS are you running?
I'll keep trying to reproduce the problem here.
Thanks!
Jim
|
363.15 | That's it | SUOBOS::RUCKH | | Tue Jan 28 1997 08:10 | 19 |
| Hi,
since manualy started one catalog-update there are no new *.stg and
*.com files left. Great, it seems to work!
The day after doing the manual update thread #1 does a incremental
level 2 operation and thread #2 does a full backup. One more day after
both treads doing an inc. level 3 operation ...
Also the lookup for thread #2 finds entries in the catalog.
The REP SAVE/FULL shows 0 objects archived for thread #2.
Now there is only one node left where the lookup doesn't functions
proper. The lookup only fails for thread #2 and only for files which
are saved with a full operation.
I'm waiting two days for the next full operation and then do another
test.
Thank you
Thomas
|
363.16 | Why staging update quits??? | COOKIE::MHUA | | Wed Jan 29 1997 10:52 | 19 |
|
Thomas,
We have locally reproduced your problem by stop/id= on staging catalog
update process. The catalog entries cannot be found, and the next
round of backup does the FULL cycle if the staging catalog update did
not complete prior to the cycle starts.
The question now is why do you have so many uncompleted staging catalog
update processes???? Did you have system failure or crash of some sort
in the past?? If everything is operating normal and the staging
catalog update still does not finish, that's a problem.
We did fix some problem (memory leak fix) in ABS V2.1 for staging
catalog update. If it keeps happening, we may want to consider getting
V2.1 ABS installed.
Masami
|
363.17 | resource problems? | SUOBOS::RUCKH | | Fri Jan 31 1997 05:31 | 87 |
| Masami,
now the full backups are succesfully completed, but there are still
problems with the catalogs.
Node WAK006:
The last days all seems ok with the catalogs. Now after the full save a
*.stg and *.com file is left.
WAK006>abs look/obj=vms_files/stor=client_sc WAK006$DKA200:[000000]/dat=today
Object of type VMS_FILES found
_WAK006::WAK006$DKA200:[000000]000000.DIR;1 31-JAN-1997 04:26:50.57
_WAK006::WAK006$DKA200:[000000]100.DIR;1 31-JAN-1997 04:26:50.64
_WAK006::WAK006$DKA200:[000000]A1MGR.DIR;1 31-JAN-1997 04:26:52.89
_WAK006::WAK006$DKA200:[000000]ALLIN1.DIR;1 31-JAN-1997 04:27:05.12
_WAK006::WAK006$DKA200:[000000]AW.DIR;1 31-JAN-1997 04:31:40.58
_WAK006::WAK006$DKA200:[000000]BACKUP.SYS;1 31-JAN-1997 04:31:52.77
_WAK006::WAK006$DKA200:[000000]BADBLK.SYS;1 31-JAN-1997 04:31:52.78
_WAK006::WAK006$DKA200:[000000]BADLOG.SYS;1 31-JAN-1997 04:31:52.79
_WAK006::WAK006$DKA200:[000000]BD.DIR;1 31-JAN-1997 04:31:52.80
9 objects(s) found in 1 catalog(s).
$dir wak006$dka200:[000000]
DirectoryWAK006$DKA200:[000000]
000000.DIR;1 100.DIR;1 A1MGR.DIR;1 ALLIN1.DIR;1
AW.DIR;1 BACKUP.SYS;1 BADBLK.SYS;1 BADLOG.SYS;1
BD.DIR;1 BFUE.DIR;1 BHOE.DIR;1 BITMAP.SYS;1
BJN.DIR;1 BWB_MBR.DIR;1 CHB.DIR;1 CL.DIR;1
CONTIN.SYS;1 CORIMG.SYS;1 DKL.DIR;1 FBE.DIR;1
FM.DIR;1 GD.DIR;1 GEM_ABLAGEN.DIR;1 HG.DIR;1
INDEXF.SYS;1 JM.DIR;1 KITS.DIR;1 KPF.DIR;1
LCI.DIR;1 LP1.DIR;1 MZ.DIR;1 NOTES$LIBRARY.DIR;1
OA$SHARE.DIR;1 PES_PESTAK.DIR;1 PFR.DIR;1 PKNA.DIR;1
PUBLIC.DIR;1 SECURITY.SYS;1 SP.DIR;1 STK.DIR;1
SYSEXE.DIR;1 TEF.DIR;1 UGR.DIR;1 UHD_WEITKAMP.DIR;1
UMA.DIR;1 VOLSET.SYS;1 WTI_3.DIR;1 WTI_4.DIR;1
WTI_5.DIR;1 WTI_KRAFF.DIR;1 WTI_UK.DIR;1 ZKR.DIR;1
Total of 52 files.
After manuel starting the update the result is the same. On days with
incremental saves everything seems ok, but on days with many objects it
seems that there is done some update but not all. The update seems to
be quitting anywhere without any message.
This is an ALL-IN-1 disk with many files.
$abs look/obj=vms_files/stor=client_sc WAK006$DKA200:[*...]/dat=today
shows
6932 objects(s) found in 1 catalog(s).
$dir WAK006$DKA200:<*...>/gran/tot
shows
Grand total of 421 directories, 23909 files.
In the listing file the last saved file is shown as:
...
(VMS_FILES) [ZKR.A1]ZWNMEVUIS.WPL
Node WAK005:
On this node the catalog seems to be corrupted or something:
abs look/obj=vms_files/stor=client_sc WAK005$DKA100:[kits]/dat=today
Unable to show object WAK005$DKA100:[KITS]*.*;* for the following reason
An Object entry was not found in the catalog
abs look/obj=vms_files/stor=client_sc WAK005$DKA100:[kits]*.txt/dat=tod
Object of type VMS_FILES found
_WAK005::WAK005$DKA100:[KITS]LIESMICH.TXT;1 31-JAN-1997 01:09:49.36
1 objects(s) found in 1 catalog(s).
abs look/obj=vms_files/stor=client_sc WAK005$DKA100:[000000]
Unable to show object WAK005$DKA100:[000000]*.*;* for the following reason
An Object entry was not found in the catalog
Should I create a new catalog? On this node there are no *.stg and
*.com files left.
Thomas
|
363.18 | Status | COOKIE::MHUA | | Mon Feb 03 1997 15:09 | 20 |
|
I sent a private correspondence to Thomas and recommended to
upgrade to V2.1 SSB version. We have fixed the problem in staging
catalog update (memory leak) and it quits after memory runs out.
The staging updates should finish after upgrading to V2.1 (unless
there are more problems...)
About the catalog lookup problem, on WAK005, I think there are some
syntax problem with ABS lookup. Lookup is not working as flexible as
we'd like it to be. I have not tried all cases reported. I'll let you
know the results.
BTW, if anyone sees undesirable behavior from catalog lookup
(syntax or behavior), please report to ABS engineering. We'd like
to enhance (at least I am personally lobbying) the lookup for the
next version of the product and your input is important to us.
Thanks,
Masami
|
363.19 | yeah | SUOBOS::RUCKH | | Tue Feb 04 1997 01:53 | 6 |
| Masami,
I have upgraded to V2.1 and converted the catalogs.
*** It Works !!!
Thomas
|