|
Thanks for providing the full diagnostic block!
There haven't been any changes to the catalog search algorithms
for V2.1.
If the customer moved his catalogs to a different disk/directory,
then the abs_catalog and abs$catalog logicals were modified in
abs$startup to be a search list (See section 13.3.2 in the
ABS Guide to Operations). This is something that the customer
would have to modify.
$ SysDefine ABS_CATALOG ABS$ROOT:[CATALOG], disk$abs_catalog
$ SysDefine ABS$CATALOG ABS$ROOT:[CATALOG], disk$abs_catalog
When the V2.1 installation was done, a new abs$startup was probably
placed in sys$startup. This would replace the catalog logical definitions
with the default values.
$ SysDefine ABS_CATALOG ABS$ROOT:[CATALOG]
$ SysDefine ABS$CATALOG ABS$ROOT:[CATALOG]
There are a couple possible scenarios:
1) The database of catalogs is stored in ABS_CATALOG:ABS_CATALOG_OBJECTS.DAT.
If the catalog logicals were reset during the installation and the
customer moved this file to disk$abs_catalog directory, ABS would not
know where to find the catalog database. In this scenario you would
most likely get a file not found error in the diagnostic block.
2) If the catalog logicals were reset during the installation, ABS would
no longer know about the disk$abs_catalog directory. The coordinator
would look for the catalog via the ABS_CATALOG logical and wouldn't be
able to find it because it is in the disk$abs_catalog directory.
3) If you look at the directory listing provided by the customer,
there are a couple versions of abs_catalog_objects.dat. ABS will
not create new versions of this data file. ABS will open the file,
modify records in the file, but not create new versions. Since there
are new versions, someone has been editing this file. You might
want to ask the customer if they have been modifying this file.
This seems like the most likely case...
>Following show the log file entry:
>
>Directory APG4$DISK:[CATALOG]
>ABS_CATALOG_BAOE.DAT;3 ABS_CATALOG_BAOE.DAT;2
>ABS_CATALOG_BAOE_INSNC.DAT;3 ABS_CATALOG_BAOE_INSNC.DAT;2
>ABS_CATALOG_BTLE.DAT;3 ABS_CATALOG_BTLE.DAT;2
>BS_CATALOG_OBJECTS.DAT;3 ABS_CATALOG_OBJECTS.DAT;2
>CODE_CATALOG_BAOE.DAT;3 CODE_CATALOG_BAOE_INSNC.DAT;3
>CODE_CATALOG_BTLE.DAT;3 DISASTER_;1
>MISC_CATALOG_BAOE.DAT;3 MISC_CATALOG_BAOE_INSNC.DAT;3
>MISC_CATALOG_BTLE.DAT;3 SUPP_CATALOG_BAOE.DAT;3
>SUPP_CATALOG_BAOE_INSNC.DAT;3 SUPP_CATALOG_BTLE.DAT;3
>SYST_CATALOG_BAOE.DAT;3 SYST_CATALOG_BAOE_INSNC.DAT;3
>SYST_CATALOG_BTLE.DAT;3 USER_CATALOG_BAOE.DAT;3
>USER_CATALOG_BAOE_INSNC.DAT;1 USER_CATALOG_BTLE.DAT;1
>
>Total of 26 files.
Kim
|
| Hi Victoria,
Moving the catalogs is the problem. I'll find the specifics and post them here.
We keep a "list" of all of the catalogs that we know about. If you add a
new catalog, you must add it to the list, or we don't know about it. In note
147, the "new feature" was the addition of this list of catalogs. From that
point on, you need to add the names of any "new" catalogs. The file in which
we keep the list probably got moved, and so we could not find the file in
which the list was kept. I'll get more specifics and add them in another
reply.
Jim
|
| OOOOPPPssss, notes collision on .1 and .2.
Here's some more specifics.
Here's how the "catalog name database" works.
This "database" is a file that contains the names of the catalog files we
recognize. A "catalog" itself is composed of 3 files. When the user creates
a new catalog, they first must add the catalog name to the catalog name
database. They do this with the CATLG_OBJECT. To create a new catalog,
the user runs Catlg_object and specifies the catalog name. We then take
the catalog name, and create the 3 files that are part of a catalog.
catalog_name_btle.dat
catalog_name_baoe.dat
catalog_name_baoe_insc.dat
Once we have created these files, we open the catalog list file,
ABS_CATALOG:ABS_CATALOG_OBJECTS.DAT
and add a record for the catalog. From then on, when the catalog_name
is specified, we look in ABS_CATALOG:ABS_CATALOG_OBJECTS.DAT, find the catalog,
and then we know where to look for the actual catalog files. If the user
changes the location of ABS_CATALOG, then we don't know where to look for
the files. If the customer moved the files, and didn't change the logical
definition for abs_catalog, then we could not find the files, because we
will always look in abs_catalog. Even if they change the abs_catalog
logical, depending on when they change the logical, and when they copy the
files, we may be confused.
As Kim said, if they moved the entire directory, and changed the logical
name, we should be ok. The catalog files are still ok, we just can't find
them. If the customer deletes or changes the
ABS_CATALOG:ABS_CATALOG_OBJECTS.DAT, then we may not, (probably won't), be
able to find the catalogs. The catalogs themselves are still ok, unless they
have been deleted. We do an rms "sys$open" on the name
ABS_CATALOG:ABS_CATALOG_OBJECTS.DAT and rms translates the logical name
abs_catalog. If we can't find the file, we return an error
AIM0>abs lookup $1$dua605: /obj=vms_files
Unable to open catalog ABS_CATALOG for the following reason
The catalog does not exist
(I just renamed the ABS_CATALOG_OBJECTS.DAT file and tried a lookup and got
the above error).
I then tried renaming the ABS_CATALOG_BTLE.DAT file and I got the following
AIM0>abs lookup $1$dua605: /obj=vms_files
Unable to open catalog ABS_CATALOG for the following reason
Error opening catalog
The errors are slightly different. The coordinator logs slightly different
errors. The point where the error you received, ABS_CATLG_DB_NOT_FOUND,
is returned, indicates the ABS_CATALOG_OBJECTS.DAT file was successfully
opened, but specific catalog name could not be found. This leads me to believe
the user still had the ABS_CATALOG_OBJECTS.DAT file in Abs_catalog, but had
already moved the other catalog files (the btle, baoe and baoe_insc) to
another directory.
Hope this helps.
Jim
|