Audit and Troubleshooting Guide

Sablime® v7.0

Overview

Sablime includes several utilities to assist in maintaining the system and troubleshooting issues.

The audits are designed to be run on a regular basis (usually daily), to detect corruption and inconsistencies in the databases. Database corruption can occur as a result of a system failure, disk or temporary space issues, or for a variety of other reasons.

The troubleshooting utilities are intended to be run when a user or administrator suspects a problem with the system, and wants to evaluate the current setup.

Audits

The audit programs dbcross and dbdelta check for corruption of individual database records, and compare data in one place with corresponding data elsewhere. Dbcross concentrates on verifying the consistency of the Sablime relational data, while dbdelta looks for consistency between the Version Control files and the Sablime database records.

A third audit program — dbxcross — is for verifying the relations associated with the External Communications Feature, and is described in that documentation.

The audit programs can be run from the console interface by typing the program name. Use <audit> ‑help to see the possible option settings.

It is recommended that you run the audits daily, using the system's automated scheduler. Sablime supplies a script named run_audits (in your command bin directory on the Sablime host). The script is designed to run the audits, keeping a week's worth of output files for each product.

Sablime also supplies a cron (the system's scheduler) entry to run the script on a regular basis. Modify the file (named audit_crontable) to have the correct path-to-Sablime, and then use the system's crontab command to install it:

crontab < audit_crontable

The audit output will be stored into $HOME/audits/<product>. Someone should review the audit output on a regular basis: the system does not attempt to do analysis of the results. See the Audit Message section for a description of the output messages that might be emitted by the audits, and the recommended response to these.

Troubleshooting

If you suspect there's a problem with Sablime, there are some utilities you can run to check for and/or fix non-database problems. The first, hotline.ck, runs from the console interface. Just type in hotline.ck after initializing Sablime; its output should be self-explanatory.

You can also run setperm from the console interface. It will review and update the permissions of Sablime database and executable files.

(The image shows the expanded Tools menu from the Sablime toolbar).

From the Web interface, you can run several utilities from the Tools->Debug menu:

Show environment — This displays the runtime environment settings for the commands that execute on the Sablime host.

Site information — This displays much technical information about the Web Sablime client and host setup.

Run site diagnostics — This evaluates the contents and permissions of Web Sablime associated files, and reports any issues to the screen.

Clear Sablime cache — For enhanced performance, Sablime saves certain evaluated and discovered settings from session to session (so that it doesn't need to re-figure them). On rare occasions, this data can become out-of-sync with the actual environment and create issues. You can run Clear Sablime cache to cause Sablime to discard these saved settings.

Audit Messages

The following tables lists messages that might be reported in the audit output, and suggests the action you should take to address the problem.

Follow these links to skip directly to a specific table:

Note: Unless the distinction is specifically important, most of these message listings and responses do not distinguish between the active and inactive databases. Your actual message may refer, for example, to inactive MG instead of just MG. Adjust the response actions as appropriate.

Dbcross Index

RELATION vs RELATION

For most RELATION vs. ITSELF (e.g. ND vs ND) messages, check the above link first. These messages usually indicate one of a small handful of problems that could apply to any relation. Rather then repeating these 60 times, they are grouped under RELATION vs RELATION.

Messages from dbcross
Audit Message Response
ADM vs GRPReturn to: Top of PageDbcross index
The ADM relation does not contain exactly 1 record. The ADM relation should have exactly one record (and thus one tuple file), whose key is the database administrator group name for this product. If there is more than one, determine which is the correct record and remove the others.
If there is no ADM record, then restore the missing file from a backup if possible, or create one from scratch (use the Database Guide for guidance).
The ADM relation shows Temporary Branching as disabled, but the following GENERIC SOURCEFILE DIRECTORY combinations show multiple checkouts in COCNT Normally, turning off temporary branching (using setrel) is not permitted while any files are checked out more than once. This condition suggests that the Temporary Branching flag in the ADM relation was changed manually to n. Either use setrel command to set the flag back to y, or use edput or unedget to eliminate the extra checkouts of the indicated file(s).
The following database administrator from ADM is not a valid PTS group Use setgroup to add the missing group.
The following MR administrator from ADM is not a valid PTS group Use setgroup to add the missing group, or use setrel/ADM to change the MR Administrator group to one that exists.
CAS vs GRPReturn to: Top of PageDbcross index
The following GROUPNAMEs from CAS do not exist in GRP Use setgroup to create the missing group, or use setrel/CAS to modify the cascade record to point to an existing group.
CP vs CPReturn to: Top of PageDbcross index
The following CMD GENERIC FUNCTYPE combinations from CP are duplicated Use dbedit (CP relation, Key for Edit is <CMD>) to remove the duplicated records.
The following CMD GENERIC FUNCTYPE combinations from CP contain empty fields while CMD indicates that this is incorrect Use setrel/CP to correct or delete this record. Use dbedit (CP relation, Key for Edit is <CMD>) to delete the record if setrel/CP cannot.
The following CMD GENERIC combinations from CP have an invalid GENERIC Use dbedit (CP relation, Key for Edit is <CMD>) to correct the generic name in field 2, or to delete the record.
The following CMD GENERIC combinations from CP are incorrect. GENERIC should be blank for that CMD Use dbedit (CP relation, Key for Edit is <CMD>) to remove the generic name from field 2, or to delete the record altogether.
The following CMD FUNCTYPE combinations from CP are incorrect. FUNCTYPE should be blank for that CMD Use dbedit (CP relation, Key for Edit is <CMD>) to remove the function from field 3, or to delete the record altogether.
The following EXECUTOR(s) from CP are invalid Use ssql to find the record with the bad executor (ssql all from CP where exec.lk.<bad_value>). Use setrel/CP to modify or remove the record(s).
The following CMDs from CP have __ALL or _NONE mixed with other values in field 4 or 5 Use setrel/CP to modify or delete the faulty records.
__NONE is not allowed as an EMAIL RECIPIENT for the following CP CMDs
The following EMAIL RECIPIENT(s) from CP are invalid
The following CP CMDs have __AD in fields 4 or 5, but are not allowed to
The following field from CP should NOT be comma-separated Use dbedit (CP relation, Key for Edit is <CMD>) to modify the record so it has only one item in the indicated field, or to delete the record altogether.
The following CMD GENERIC FUNCTYPE combinations from CP should NOT be empty in the fourth field Use setrel/CP to modify the record so it lists executor(s), or to delete the record altogether.
The following CMD GENERIC FUNCTYPE combinations from CP should NOT be empty in the fifth field Use setrel/CP to modify the record so it lists email recipient(s), or to delete the record altogether.
The following CMD FUNCTYPE combination is invalid for CP Use dbedit (CP relation, Key for Edit is <CMD>) to change the record so that the function type is valid, or to delete the faulty record altogether.
The following CMD is invalid for CP Use dbedit (CP relation, Key for Edit is <CMD>) to correct the command name, or to delete the faulty record altogether. Since the command name is the key for this relation, it's likely that a corrupted command name would cause the record to be in an unexpected tuple file. If dbedit can not retrieve the record based on the indicated command name, use grep (cd $sabLCB/../adb/$sabPROD/CP;grep "^<bad_command_name>;" ??) to find the bad record. Use a text editor to remove the record from the tuple file.
CRIT vs PTS/GRPReturn to: Top of PageDbcross index
The following CRITERIA OWNERS from CRIT are not valid PTS IDs/groups First, find the specific criteria that have each owner: ssql crtype crowner from CRIT where crowner.eq.<CRITERIA OWNER>. Then use the setrel/CRIT command to change the criteria's owner to a valid PTS ID or PTS ID group, or to delete it.
DB Relation File NamesReturn to: Top of PageDbcross index
The following relation directories are missing At minimum, use mkdir to re-create the missing directories. Try to recover the directories' contents from a backup if possible. Unless these were empty relations, there will be other audit failures due to the missing data. This error causes immediate failure, though, so you will not see other issues until the directories are restored.
The following file names are invalid within the relations (RELATION/file)
of the ADB [or IDB]
Delete the indicated files, or move them out of the database directory.
The following are not regular files in the relations (RELATION/file)
of the ADB [or IDB]
Delete the indicated items (probably directories), or move them out of the database directory.
The following lock files should be removed from DBLOCK (RELATION/file)
in the ADB [or IDB] [<path to database>]
The database is currently stopped (see dbstop), and thus cannot be in the midst of an update. Remove the lock file from <path to database>/DBLOCK/<RELATION>
The following lock files were found in DBLOCK (RELATION/file) in the ADB [or IDB] [<path to database>] The presence of lock files indicates that a database changing command was running during the audit. Consider whether any discovered issues may be a result of this pending update, and whether to re-run the audits.
On the other hand, if the lock file is more than a few minutes old (ls -l <path to database>/DBLOCK/<RELATION>/<file>, then you can safely delete it, since it is probably the result of a crashed command execution.
DEP vs DEPReturn to: Top of PageDbcross index
The following MR GENERIC DEPMR combinations from DEP have Logical and Physical dependency flags set to 'n' If this DEP record refers to an existing physical dependency (ssql mr from PDEP where mr.eq.<MR> and g.eq.<GENERIC> and dep.eq.<DEPMR>), then use dbedit (DEP relation, Key for Edit is <MR>) to change the Physical dependency flag (field 5) to y. Otherwise, change the Logical flag (field 4), or delete the record altogether.
DEP vs MGReturn to: Top of PageDbcross index
The following DEPMR GENERIC combinations from DEP are not in MG or inactive MG Either there's a missing or corrupted MG record (check other audit output), or you should use dbedit (DEP relation, Key for Edit is <MR>, where <MR> is the MR associated with the Depended-upon MR(s) in the audit message: ssql mr from DEP where dep.eq.<DEPMR> and g.eq.<GENERIC>) to remove this faulty DEP record.
If a missing MG record is indicated (e.g. there are MD records for this MR in this generic), then you may have to re-create the record. Consider correcting other audit issues first, since database corruptions often generate multiple audit errors and one of the other (easier) corrections might also eliminate this problem.
The following MR GENERIC combinations from DEP are not in MG
The following MR GENERIC DEPMR combinations from DEP were found in PDEP but Physical dependency flag was not set to 'y' Use dbedit (PDEP relation, Key for Edit is <MR>) to change the Physical dependency flag (field 5) of the DEP record to y.
DEP vs PDEPReturn to: Top of PageDbcross index
The following MR GENERIC DEPMR combinations from DEP were not found in PDEP but Physical dependency flag was not set to 'n' Use dbedit (PDEP relation, Key for Edit is <MR>) to change the Physical dependency flag (field 5) to n, unless other information (i.e. MD records) suggests that the Physical dependency should exist. In that case, you may have to re-create the missing PDEP record. Consider correcting other audit issues first, since database corruptions often generate multiple audit errors and one of the other (easier) corrections might also eliminate this problem.
FILES vs MGReturn to: Top of PageDbcross index
The following MR GENERIC combinations from (inactive)FILES/resolution (or rejection or solution) are not in (inactive) MG Either there's a missing or corrupted MG record (check other audit output), or you should remove this file.
If a missing MG record is indicated (e.g. there are MD records for this MR in this generic), then you may have to re-create the record. Consider correcting other audit issues first, since database corruptions often generate multiple audit errors and one of the other (easier) corrections might also eliminate this problem.
FILES vs MRReturn to: Top of PageDbcross index
The following MR MRSTATUS combinations from MR have invalid MR STATUS In the active database, the MR status should be one of active, created, mra_study, or mra_deferred. In the inactive database, the status should be completed or killed. Use dbedit (MR relation, Key for Edit is <MR>) to change the status (field 3) to a valid status.
The following MR's for which spawned MR's exist are missing in MR If other audit messages don't point you to where a damaged version of the parent MR's missing MR record has ended-up, you'll need to recover it from a backup if possible (the record should be in the file $sabGDB/../adb/$sabPROD/MR/<tuple> where <tuple> is the return from dbhash <MR>), or if you must rebuild the record, copy a similar one and step through the fields to adjust the values as necessary. Set field 8 of the Parent MR record to the number of spawns (ssql mr from MR where mr.lk.<MR>. [note the trailing dot]). The MR record for one of the child MRs is a good candidate for the copy (ssql all from MR where mr.eq.<Spawned MR>), since spawns generally keep the same values for MR record fields.
The following MR names from FILES/description are not in MR If this indicates a missing MR record, refer to the other related audit messages for the proper response. Otherwise, remove the indicated file from $sabGDB/../adb/$sabPROD/FILES/description.
The following MR names from MR are not in FILES/description Assuming this is a legitimate MR name (if not, there will be other audit messages to deal with the bad MR record), try to retrieve the file from a backup (the file should be at $sabGDB/../adb/$sabPROD/FILES/description/<MR>) or use a text editor to create the missing file.
The following MR names from FILES/glob_solution are not in MR If this indicates a missing MR record, refer to the other related audit messages for the proper response. Otherwise, remove the indicated file from $sabGDB/../adb/$sabPROD/FILES/glob_solution.
FILES vs MRS, MRS vs FILESReturn to: Top of PageDbcross index
The following MR GENERIC combinations from FILES/spawnotes are not in MRS Check the MG relation to verify that this is a legitimate spawn (ssql mr from MG where g.eq.<GENERIC> and mr.lk.<MR>. [note the trailing dot]), and if so, use dbedit (MRS relation, Key for Edit is <MR>) to create the missing MRS record(s): <MR>;<GENERIC>;<SPAWN>, where <SPAWN> is each value returned from the first query. If the appropriate tuple file for this new record doesn't already exist, dbedit may fail, and you'll need to create the file first: touch $sabGDB/../adb/$sabPROD/MRS/<TUPLE>, where <TUPLE> is the return from dbhash <MR>
If this is not a legitimate spawn, check the spawnnotes file itself (head $sabGDB/../adb/$sabPROD/FILES/<GENERIC>/<MR>) to see which MR the spawnotes file is supposed to be associated with. Rename the file if appropriate, or delete it if it is not needed.
The following MR GENERIC combinations from MRS are not in FILES/spawnotes Assuming that other audit messages don't suggest that the MRS records are corrupted, check the spawnotes directory to see if the file intended for this MR has somehow been renamed (grep '[<MR>.' $sabGDB/../adb/$sabPROD/FILES/spawnotes/<GENERIC>/*). If not, you can attempt to recover the missing record from a backup, or use a text editor to create the file. You may not be able to re-create its contents, but simply creating the file will at least suppress the audit error message.
No $adb/FILES/spawnotes directory .. Could not run tests! Create the missing directory: mkdir $sabGDB/../adb/$sabPROD/FILES/spawnotes
FTD RelationReturn to: Top of PageDbcross index
WARNING: The following Command/Field Screen Labels (right column) do not match the <other_command> command Screen Label (left column). Format Below: (CMD INT-KEY LABEL | CMD INT-KEY LABEL): You can use the ftd command to make the Labels consistent, if desired. There is no requirement that the commands use the same labels.
Note that the warning is using the internal key to identify the field. Your external key may have been customized.
WARNING: The following Command/Field External Keys (right column) do not match the <other_command> command External Key (left column). Format Below: (CMD INT-KEY EXT-KEY | CMD INT-KEY EXT-KEY) You can use the ftd command to make the External Keys consistent, if desired. There is no requirement that the commands use the same external keys.
Note that the warning is using the internal key to identify the field.
The following COMMAND INT-KEY names have their Display Flag turned on, but the <other_command> command Display Flag is turned off One command displays the field, while the other does not. You can use the ftd command to make the displays consistent, if desired. There is no requirement that the commands both display the same fields.
Note that the warning is using the internal key to identify the field. Your external key may have been customized.
The following COMMAND EXT-KEY combinations in FTD are duplicated Use dbedit (FTD relation, Key for Edit is <COMMMAND>) to remove one of the duplicate records.
FZ vs SDReturn to: Top of PageDbcross index
The following FILE DIR GENERIC SID combinations from FZ are not in SD Either the snapshot record is corrupted, or there's a missing SD record. You can check for the missing SD record by comparing the records for this file (in this generic) in SD vs the records in MD. There should be one SD record for each MD record where the mr branch was changed:
ssql all from MD where sfile.eq.<FILE> and g.eq.<GENERIC> and dir.eq.<DIR> and sid.lk..1.2. vs ssql all from SD where sfile.eq.<FILE> and g.eq.<GENERIC> and dir.eq.<DIR>
If SD looks OK, then you can either use dbedit (FZ relation, Key for Edit is <FILE>) to remove the faulty FZ record, or since it's likely that the snapshot is corrupted, you may want to use snapedit to delete the snapshot.
If the SD record is indeed missing, you can used dbedit (SD relation, Key for Edit is <FILE>) to add the missing record:<FILE>;<DIR>;<GENERIC>;<SID>;<MR> where <SID> is the last part of the four-part delta ID seen in the MD record, and MR is the MR that created that MD record. If the appropriate tuple file for this record doesn't already exist, dbedit may fail, and you'll need to create the file first: touch $sabGDB/../adb/$sabPROD/SD/<TUPLE>, where <TUPLE> is the return from dbhash <FILE>
FZ vs SNAPReturn to: Top of PageDbcross index
The following GENERIC SNAPID combinations from FZ are not in SNAP You can either use dbedit to remove the FZ records, or try to re-create the missing SNAP record. SNAP records have 14 fields, so creating one from scratch is difficult unless there's another, very similar one, to copy. Use dbhash <SNAPID> to determine the proper tuple file name, and then use a text editor to add the snapshot record into $sabGDB/../adb/$sabPROD/SNAP.
G RelationReturn to: Top of PageDbcross index
The following GENERIC GID combinations from G have invalid GID GIDs should always end in .1. Use dbedit (G relation, Key for Edit is <GENERIC>) to correct this record.
GRP vs MRReturn to: Top of PageDbcross index
The following MR names from MR and GROUPNAMEs from GRP are the same. MR and group names must be mutually exclusive Use setgroup to remove the contents of the group so that Sablime deletes it.
GRPM vs GRP, GRP vs GRPMReturn to: Top of PageDbcross index
WARNING: The following groups are empty Normally, Sablime removes groups when they become empty. Thus, an empty group is considered a problem. Use setgroup to add contents to the group or to make it empty. If you make it empty, Sablime will delete the GRP record.
The following GROUPNAMEs from GRPM do not exist in GRP Use dbhash <GROUPNAME> to determine the proper tuple file name, and then use a text editor to add a Group record (<GROUPNAME>;<OWNER>;<TYPE>) for this item into $sabGDB/../adb/$sabPROD/GRP. The proper TYPE will be evident by which directory under $sabGDB/../adb/$sabPROD/GROUPS the group contents were stored into.
Alternatively, if the problem group does not need to be saved, you can simply delete the storage file instead of creating the missing GRP record.
GS vs PTS/GRPReturn to: Top of PageDbcross index
The following FILE OWNERS from GS are not valid PTS IDs/groups First, find the specific files(s) that have each owner: ssql sfile dir g from GS where owner.eq.<FILE OWNER>. Use the source command to change the file's ownership to a valid PTS ID or PTS ID group, or to make the file unowned.
GS vs GSReturn to: Top of PageDbcross index
The following SOURCEFILE DIRECTORY GENERIC GSSTATUS combinations from inactive GS show a GS status of other than free. All files from in [closed] generics should be status free. Use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to change the gsstat (field 6) of this record to free.
The following GENERIC SOURCEFILE DIRECTORY RMR combinations from GS indicate a reserved checkout, but zero total checkouts. Check in the MC relation to see if indeed the indicated MR has a reserved checkout for this file in this generic (ssql all from MC where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY> and mcstat.eq.reserved). If yes, use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to change the check-out count of the GS record (field 16) to 1; if not, use dbedit to remove the MR from field 15.
The following GENERIC SOURCEFILE DIRECTORY combinations from inactive GS show reserved MR checkout, but zero total checkouts. Use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to remove the MR from field 15 of the GS record in the inactive database.
The following SOURCEFILE DIRECTORY GENERIC GSSTATUS combinations from GS indicate that the source command was renaming, moving, or deleting the file during the audits. This could cause unpredictable audit results. Field 6 of the GS record was set to locked-free or locked-busy, meaning that the source command was being run against this file. This is not necessarilly a problem, and any audit issues associated with this file might be transient, since a database update may have been in progress when the audit was run.
The following SOURCEFILE DIRECTORY GENERIC GSSTATUS combinations from inactive GS indicate that the source command was renaming, moving, or deleting the file during the audits. This could cause unpredictable audit results. Use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to set the GSSTATUS (field 6) of this inactive GS database record to free.
The following GENERIC SOURCEFILE SCCSDIR combinations are duplicated in [inactive] GS Use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to remove one of the duplicated records.
The following GENERIC SOURCEFILE SCCSDIR combinations are duplicated between GS and inactive GS} If the generic is closed, then use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to remove the GS record from the active database. If not closed, then remove the GS record from the inactive database.
The following GENERIC SOURCEFILE DIRECTORY COMMON combinations from GS contain inconsistent common field declarations The displayed records show disagreements between 2 or more generics. Determine which is correct and use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to add or remove generic entries to the common field (field 7) of the others.
GS vs MC, MC vs GSReturn to: Top of PageDbcross index
The following GENERIC SOURCEFILE DIRECTORY combinations from MC have no corresponding busy record in GS If the file is really checked-out (ssql all from SC where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY>), then use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to change the gsstat (field 6) to busy. If not, find which MR(s) in the MC relation refer to this file (ssql mr from MC where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY>) and use dbedit (MC relation, Key for Edit is <MR>) to remove the faulty MC record(s).
The following GENERIC SOURCEFILE DIRECTORY combinations from GS have GSSTATUS of "busy", but there is no corresponding record in MC If the file is really checked-out (ssql mr from SC where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY>), then use dbedit (MC relation, Key for Edit is <MR>, where <MR> is the MR returned from the SC query) to add the missing MC record (<MR from SC>;<GENERIC>;<SOURCEFILE>;<DIRECTORY>;<DEV from SC>;<SID>;<reserved, if GS field 15 is populated, unreserved otherwise>;<DATE> where SID is field 17 of GS plus 1, and DATE is a reasonable guess at the date when the edget occurred (mm/dd/yy hh:mm:ss). If the appropriate tuple file for this record doesn't already exist, dbedit may fail, and you'll need to create the file first: touch $sabGDB/../adb/$sabPROD/MC/<TUPLE>, where <TUPLE> is the return from dbhash <MR from SC>.
If the file isn't really checked out, use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to change the gsstat (field 6) to free.
The following MR GENERIC SOURCEFILE DIRECTORY combinations from MC are listed as reserved checkouts but are not present as the "reserved MR" (rmr) for any GS record If the file is really checked out reserved, there will be a p.<SOURCEFILE> at $sabGDB/../sdb/$sabPROD/<DIRECTORY> with this GENERICS's gsid in it (ssql gsid from G where g.eq.<GENERIC>). If so, use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to add the MR to field 15 of this file's GS record. If not, use dbedit (MC relation, Key for Edit is <MR>) to change the MC record from reserved to unreserved.
The following GENERIC SOURCEFILE DIRECTORY RMR combinations from GS show the MR as a reserved checkout, with no corresponding MC reserved checkout record If the file is really checked out reserved, there will be a p.<SOURCEFILE> at $sabGDB/../sdb/$sabPROD/<DIRECTORY> with this GENERICS's gsid in it (ssql gsid from G where g.eq.<GENERIC>). If so, use dbedit (MC relation, Key for Edit is <RMR>) to change the MC record from unreserved to reserved. If not, use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to remove the MR from field 15 of this file's GS record.
GS vs SDReturn to: Top of PageDbcross index
The following SFILE DIR G LSID combinations from GS are not in SD If there is no MD record corresponding to the missing SD record (ssql all from MD where g.eq.<G> and sfile.eq.<SFILE> and dir.eq.<DIR> and sid.lk..1.2.<LSID>), then use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to set fields 17 and 18 of the GS record to the highest numbered delta that does exist in MD (ssql all from MD where g.eq.<G> and sfile.eq.<SFILE> and dir.eq.<DIR> and sid.lk..1.2.). If the MD record does exist, use dbedit (SD relation, Key for Edit is <SOURCEFILE>) to create an SD record for it (<SFILE>;<DIR>;<G>;<LSID>;<MR>, where the first four fields are from the audit message and the MR is from the found MD record. If the appropriate tuple file for this new record doesn't already exist, dbedit may fail, and you'll need to create the file first: touch $sabGDB/../adb/$sabPROD/SD/<TUPLE>, where <TUPLE> is the return from dbhash <SOURCEFILE>
The following SFILE DIR G LSID combinations from GS do not match the sid of the highest delta in SD Use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to set fields 17 and 18 of the GS record to the highest numbered delta that does exist in SD (ssql sid MR from SD where g.eq.<G> and sfile.eq.<SFILE> and dir.eq.<DIR>).
The following SFILE DIR G LSID LMR combinations from GS do not match the MR in the highest delta in SD
GT vs G, G vs GTReturn to: Top of PageDbcross index
The following GENERIC names from G are not in GT If GENERIC is a legitimate name that should exist, then check elsewhere in the audits to see if the missing GT records are maybe in the other database (i.e. in the active DB when they should be in the inactive, or the opposite). Use dbedit (G relation, Key for Edit is <GENERIC>) to delete them from the one and create them in the other. If the GT records are simply missing from the active database, you'll need to use modgen to create new test team records for GENERIC. If they are missing from the inactive database, you'll need to use dbedit (GT relation, Key for Edit is <GENERIC>) to create them (use another, existing, generic's records as a model. Since it's a closed generic, the accuracy of the GT records is of little consequence). If the appropriate tuple file for this new record doesn't already exist, dbedit may fail, and you'll need to create the file first: touch $sabGDB/../adb/$sabPROD/GT/<TUPLE>, where <TUPLE> is the return from dbhash <GENERIC>
If GENERIC is not a legitimate generic name, then use dbedit (G relation, Key for Edit is <GENERIC>) to delete the record.
The following GENERIC names from GT are not in G If GENERIC is a legitimate name that should exist, then check to see if the G record is maybe in the other database (i.e. in the active DB when the GT records are be in the inactive, or the opposite). Use dbedit (GT relation, Key for Edit is <GENERIC>) to delete the GT records from the one and create them in the other. If the G record is simply missing from the active database, and other audit messages don't point you to where a damaged version of the record has ended-up, you'll need to use dbedit (G relation, Key for Edit is <GENERIC>) to create the G record. This is an unlikely situation, but if it does arise, use caution to create the record correctly. In particular, make sure the gsid, field 3, is correct. You can discover the correct value from the GENERIC's records in the MD relation: ssql sid from MD where g.eq.<GENERIC>; the first two components of these are the gsid for use in the G record (i.e. <integer>.1).
If GENERIC is not a legitimate generic name, then use dbedit to delete the bad GT records.
MC vs MCReturn to: Top of PageDbcross index
The following MR GENERIC SOURCEFILE DIRECTORY SID MDSTATUS combinations from MC have invalid MCSTATUS If the file is checked out reserved, there will be a p.<SOURCEFILE> at $sabGDB/../sdb/$sabPROD/<DIRECTORY> with this GENERICS's gsid in it (ssql gsid from G where g.eq.<GENERIC>). Use dbedit (MC relation, Key for Edit is <MR>) to set the MCSTATUS to either reserved or unreserved.
MC vs SCReturn to: Top of PageDbcross index
The following SOURCEFILE DIRECTORY GENERIC MR DEV combinations from SC have no matching record in MC If the file is not checked out in reserved mode by this MR, (i.e. if ssql gsstat from GS where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY> and rmr.eq.<MR> doesn't return busy), then use dbedit (SC relation, Key for Edit is <SOURCEFILE>) to remove the SC record. If it is also not checked out by any other MR in this generic (ssql all from MC where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY>), then use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to change the gsstat (field 6) to free.
Warn the developer DEV they may need to edget the file again: if they've already made changes to their edgotten copy, they should save that copy to another name before doing the new edget.
If the file is checked out in reserved mode by this MR (the initial ssql above returned busy, then you'll need to use dbedit to recreate the missing MC record: <MR>;<GENERIC>;<SOURCEFILE>;<DIRECTORY>;<DEV>;<SID>;reserved;<DATE> where the first 5 values come from the audit message; SID is from the GS record (ssql lsid from GS where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY>), and DATE is a reasonable guess at the date when the edget occurred (mm/dd/yy hh:mm:ss).
The following MR GENERIC SOURCEFILE DIRECTORY DEV combinations from MC have no matching record in SC If the file is not checked out in reserved mode by this MR, (i.e. if ssql gsstat from GS where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY> and rmr.eq.<MR> doesn't return busy), then use dbedit to remove the MC record. If it is also not checked out by any other MR in this generic (ssql all from MC where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY>), then use dbedit (GS relation, Key for Edit is <SOURCEFILE>) to change the gsstat (field 6) to free.
Warn the developer DEV they may need to edget the file again: if they've already made changes to their edgotten copy, they should save that copy to another name before doing the new edget.
If the file is checked out in reserved mode by this MR (the initial ssql above returned busy, then you'll need to use dbedit to recreate the missing SC record: <SOURCEFILE>;<DIRECTORY>;<GENERIC>;<MR>;<DEV>.
MD vs SDReturn to: Top of PageDbcross index
The following SOURCEFILE DIRECTORY GENERIC SID MR combinations from MD are not in SD Unless other audit messages suggest that the corresponding MD record is itself corrupted, use dbedit to create the missing SD record: <SOURCEFILE>;<DIRECTORY>;<GENERIC>;<SID>;<MR>, where all five fields are as indicated in the audit message.
MC vs GS (Checkout Count)Return to: Top of PageDbcross index
The following GENERIC SOURCEFILE DIRECTORY COCNT#_of_MD have COCNT (check-out count) showing a different number of checkouts in GS than there are reserved or unreserved MC records Unless you have reason to believe that the MC records are corrupted, use dbedit to change the cocnt (field 16) of the GS record to the COCNT#_of_MD value from the audit message.
The following GENERIC SOURCEFILE DIRECTORY combinations have more than one "reserved" checkout MC records Check the GS relation to see which MR holds the reserved checkout: ssql rmr from GS where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY>. Use dbedit (MC relation, Key for Edit is <MR>) to change mcstat (field 7) of the MC records (ssql all from MC where g.eq.<GENERIC> and sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY> and mcstat.eq.reserved) to unreserved for the MRs other than the one found in the first query.
MC vs MGReturn to: Top of PageDbcross index
The following MR GENERIC combinations from MC are not in MG Check other audit messages, and unless it is apparent that the MG relation is damaged, use dbedit (MC relation, Key for Edit is <MR>) to remove this faulty record.
If the MG relation is the problem, these are difficult to rebuild. If you can, retrieve a version from a backup (the record should be in the file named $sabGDB/../adb/$sabPROD/MG/<tuple> where <tuple> is the return from dbhash <MR>). If you must rebuild the record, copy a similar one and step through the fields to adjust the values according to other database information about this MR.
MD vs MGReturn to: Top of PageDbcross index
The following MR GENERIC combinations from MD are not in MG Corrupted records generally trigger multiple audit messages. Evaluate other audit messages and consider making other, simpler fixes first. Fixing either the MD or the MG records can be difficult, and it's possible that other fixes will eliminate this problem.
If it turns out that the MG record is missing, try to retrieve a version from a backup (the record should be in the file named $sabGDB/../adb/$sabPROD/MG/<tuple> where <tuple> is the return from dbhash <MR>). If you must rebuild the record, copy a similar one and step through the fields to adjust the values according to other database information about this MR.
MG vs GReturn to: Top of PageDbcross index
The following GENERIC names from MG are not in G If GENERIC is a legitimate name that should exist, then check to see if the G record is maybe in the other database (i.e. in the active DB when the MG records are be in the inactive, or the opposite). Use dbedit (MG relation, Key for Edit is <MR>) to delete the records from the one and create them in the other (for closed MRs, mrgstat [field 3] should be changed to closed and mgstcd [field 10] should be either 89 if the MR's active-DB status was nochange, or 99 if the status was approved. If the G record is simply missing from the database, and other audit messages don't point you to where a damaged version of the record has ended-up, you'll need to use dbedit (G relation, Key for Edit is <GENERIC>) to create the record. This is an unlikely situation, but if it does arise, use caution to create the record correctly. In particular, make sure the gsid, field 3, is correct. You can discover the correct value from the GENERIC's records in the MD relation: ssql sid from MD where g.eq.<GENERIC>; the first two components of these are the gsid for use in the G record (i.e. <integer>.1).
If GENERIC is not a legitimate generic name, then use dbedit (MG relation, Key for Edit is <MR>) to delete the bad records, or to change their generic to a legitimate one.
The following GENERIC names from inactive MG are not in G or inactive G See immediately above for info on recreating the G record if the listed GENERIC is a legitimate name that should exist. Otherwise, use dbedit (MG relation, Key for Edit is <MR>) to correct the faulty generic names in the MG records (ssql mr g from MG where g.eq.<GENERIC>), or to remove the records altogether.
MG vs MGReturn to: Top of PageDbcross index
The following MR GENERIC combinations in MG have no assigned developer If the MR is shown as assigned (ssql mrgstat from MG where g.eq.<GENERIC> and mr.eq.<MR>), then use the assign command to add an assignee, or to unassign the MR (if it hasn't changed files). If the MR is shown as being understudy, then use the study command to add a study developer.
The following MR GENERIC STATE SYSCODE combinations from MG contain inconsistent STATUS and SYSCODE
nochange 1 preitpassed 45
deferred 6 itpassed 50
understudy 8 prestpassed 55
accepted 10 stpassed 60
spawned 15 preapproved 70
assigned 20 approved 80
submitted 30
Each MR state has an associated code. Review other available information (this MR's history, for example: ssql all from MRH where mr.eq.<MR> and g.eq.<GENERIC>) to determine what the correct state should be, and then use dbedit (MG relation, Key for Edit is <MR>) to either correct the state name or the system code according to the table at right. Note that the table uses the as-shipped, software-class, state names for the 5 optional test states. The codes are the same for the equivalent states in the other classes.
MG vs MRReturn to: Top of PageDbcross index
The following MR names from MG are not in MR If this and other audit messages suggest that the problem is a missing MR record, and other audit messages don't point you to where a damaged version of the record has ended-up, you'll need to recover the missing record from a backup if possible (the record should be in the file named $sabGDB/../adb/$sabPROD/MR/<tuple> where <tuple> is the return from dbhash <MR>), or if you must rebuild the record, copy a similar one and step through the fields to adjust the values according to other database information about this MR.
The following MR names from MG should not be in MG, because the MRSTATUS from MR is created, mra_deferred or mra_study Use other available information to determine if this MR is actually in use within any generics (e.g. Are there checkouts: ssql MR from MC where mr.eq.<MR>; or are there deltas: ssql sid from MD where mr.eq.<MR>). If not, use dbedit (MG relation, Key for Edit is <MR>) to remove the faulty MG records (ssql mr from MG where mr.eq.<MR>). If the MR is in use in generic(s), use dbedit to change the MR status (field 3) to active instead of the value listed in the audit message.
The following MR names from MR should be in MG, because the MRSTATUS from MR is active Use other available information to determine if this MR is actually in use within any generics (e.g. Are there checkouts: ssql mr from MC where mr.eq.<MR>; or are there deltas: ssql sid from MD where mr.eq.<MR>). If not, used dbedit (MR relation, Key for Edit is <MR>)to change the MR status (field 3) to created. If the MR is in use in generic(s), and other audit messages don't point you to where a damaged version of the missing MG record has ended-up, you'll need to recover it from a backup if possible (the record should be in the file $sabGDB/../adb/$sabPROD/MG/<tuple> where <tuple> is the return from dbhash <MR>), or if you must rebuild the record, copy a similar one and step through the fields to adjust the values according to other database information about this MR.
The following MR GENERIC MGSTATUS combinations from inactive MG have invalid MGSTATUS. It should be closed because the MRSTATUS from inactive MR is completed. Use dbedit (MG relation, Key for Edit is <MR>) to change the MG status (field 10) of the MG record to closed.
MG vs PTS/GRPReturn to: Top of PageDbcross index
The following ASSIGNEE's from MG are not valid PTS IDs/groups First, find the specific MR(s) that have this assignee: ssql mr g from MG where dev.eq.<ASSIGNEE>. Then use the assign command to set the assignee to a valid PTS ID or PTS ID group, or to unassign the MR.
The following TESTERs from MG are not valid PTS IDs/groups First, find the specific MR(s) and test levels that have each assignee: ssql mr g tester1 tester2 tester3 tester4 tester5 from MG where tester1.eq.<TESTER> or tester2.eq.<TESTER> or tester3.eq.<TESTER> or tester4.eq.<TESTER> or tester5.eq.<TESTER>. Then use the testassign command to set the tester to a valid PTS ID or PTS ID group, or to undo the testassignment.
MR Initialization CheckReturn to: Top of PageDbcross index
The following MR GENERIC MGSTATUS TYPE combinations from MG are [initialization] type MRs, but have not yet been approved. This could result in zero length files being retrieved when br=ofc in getversion or sget. This is not necessarily a problem, as long as your process either avoids br=ofc extractions or doesn't mind zero-length files.
MRS vs MG, MG vs MRSReturn to: Top of PageDbcross index
The following MR GENERIC combinations from MRS are not in MG with a STATUS of spawned If this is indeed the parent of one or more spawned MRs (ssql mr from MG where g.eq.<GENERIC> and mr.lk.<MR>. [note the trailing dot]), then use dbedit (MG relation, Key for Edit is <MR>) to change the mrgstat (field 3) to spawned. If it is not the parent of one or more spawns, then use dbedit (MRS relation, Key for Edit is <MR>) to remove the MRS record.
The following MR GENERIC combinations from MRS are not in MG If this MR is indeed the parent of one or more spawned MRs (ssql mr from MG where g.eq.<GENERIC> and mr.lk.<MR>. [note the trailing dot]), then the parent's MG record is damaged or missing. If other audit messages don't point you to where a damaged version of the missing MG record has ended-up, you'll need to recover it from a backup if possible (the record should be in the file $sabGDB/../adb/$sabPROD/MG/<tuple> where <tuple> is the return from dbhash <MR>), or if you must rebuild the record, copy a similar one and step through the fields to adjust the values according to other database information about this MR.
On the other hand, if this is not the parent of one or more spawns, then use dbedit (MRS relation, Key for Edit is <MR>) to remove the record.
The following Spawned MR GENERIC combinations from MRS are not in MG If the Spawned MR is a legitimate spawn (ssql mr cmd from MRH where g.eq.<GENERIC> and mr.eq.<Spawned MR>), and other audit messages don't point you to where a damaged version of the missing MG record has ended-up, you'll need to recover it from a backup if possible (the record should be in the file $sabGDB/../adb/$sabPROD/MG/<tuple> where <tuple> is the return from dbhash <Spawned MR>), or if you must rebuild the record, copy a similar one and step through the fields to adjust the values according to other database information about this MR.
On the other hand, if this is not a legitimate Spawned MR, then use dbedit (MRS relation, Key for Edit is <MR>) to remove the record.
The following MR GENERIC combinations from MG are in the spawned state but are not in MRS If this MR does indeed have spawns (ssql mr from MG where g.eq.<GENERIC> and mr.lk.<MR>. [note the trailing dot]), use dbedit (MRS relation, Key for Edit is <MR>) to create the missing record(s): <MR>;<GENERIC>;<SPAWN>, where <SPAWN> is each value returned from the first query.
If this is not an spawn parent, check the MR history for this MR in this generic (ssql mr cmd from MRH where g.eq.<GENERIC> and mr.eq.<MR>) to try and discover what the MR status should be, and use dbedit (MG relation, Key for Edit is <MR>) to change the mrgstat (field 3 in the MG relation).
The following Spawned MR GENERIC combinations from MG are not in MRS Assuming this is a legitimate Spawned MR (ssql mr cmd from MRH where g.eq.<GENERIC> and mr.eq.<Spawned MR>), then use dbedit (MRS relation, Key for Edit is <MR>) to create the missing MRS record: <PARENT>;<GENERIC>;<Spawned MR> where <PARENT> is the Spawned MR name without the suffix.
MRS vs MRReturn to: Top of PageDbcross index
The following Spawned MR names from MRS are not in MR Each spawned MR has its own MR record, separate from the parent MR's MR record. If the Spawned MR is a legitimate spawn (ssql mr cmd from MRH where mr.eq.<Spawned MR>), and other audit messages don't point you to where a damaged version of the missing MR record has ended-up, you'll need to recover it from a backup if possible (the record should be in the file $sabGDB/../adb/$sabPROD/MR/<tuple> where <tuple> is the return from dbhash <Spawned MR>), or if you must rebuild the record, copy a similar one and step through the fields to adjust the values as necessary. The MR record for the parent MR is a good candidate for the copy, since spawns generally keep the same values for MR record fields. Set field 8 of the Spawned MR record to zero 0.
On the other hand, if this is not a legitimate Spawned MR, then use dbedit (MRS relation, Key for Edit is <MR>) to remove the MRS record.
MRS vs MRSReturn to: Top of PageDbcross index
The following MR GENERIC Spawned MR combinations from MRS do not belong together Either the MR name or the Spawned MR name is corrupted (the spawned MR must have the same core name as the MR). Use other database information to determine which is correct, and use dbedit (MRS relation, Key for Edit is <MR>) to change the other one. If the MR was incorrect, verify that the corrected record is in the correct tuple file ($sabGDB/../adb/$sabPROD/MRS/<tuple> where <tuple> is the return from dbhash <MR>). If it is not, use a text editor to remove it from the incorrect file and add it to the correct one.
MRX vs MRReturn to: Top of PageDbcross index
The following MR names from MRX are not in MR Corrupted records generally trigger multiple audit messages, so if this is a legitimate MR name, evaluate other audit messages and consider making other, simpler fixes first. Creating a missing MR record from scratch can be difficult, and it's possible that other fixes will eliminate this problem.
If it turns out that the MR record is simply missing, try to retrieve a version from a backup (the record should be in the file named $sabGDB/../adb/$sabPROD/MR/<tuple> where <tuple> is the return from dbhash <MR>).
If you must rebuild the record, copy a similar one and step through the fields to adjust the values according to other available information about this MR.
If this is not a legitimate MR name, and other audit messages don't indicate what the MR name should be, then use dbedit (MRX relation, Key for Edit is <MR>) to remove the record. If the MR name has been corrupted, then it might not be in the proper hash file (and thus dbedit won't find it). If so, go to the MRX relation directory at $sabGDB/../adb/$sabPROD/MRX and use grep to find the faulty record: grep ^<MR>; ??. Use a text editor to remove the record from the file.
MRX vs ORGReturn to: Top of PageDbcross index
The following MR names from MRX are not in ORG If this is a legitimate MR name, and other audit messages don't point you to where a damaged version of the missing ORG record has ended-up, you can attempt to recover the missing record from a backup (the record should be in the file named $sabGDB/../adb/$sabPROD/ORG/<tuple> where <tuple> is the return from dbhash <MR>), or use dbedit (ORG relation, Key for Edit is <MR>) to create the ORG record: <MR>;<ORG>;<ODATE>;<PROD>;<SYS>;<SUB>;<REL>;<SITE>;<MOD>. The values can be found by finding the Sablime trace record for when the MR was created: (grep '<ABST>' $sabGDB/../adb/$sabPROD/FILES/trace/*, where <ABST> is the MR abstract: ssql abst from MR where mr.eq.<MR>).
If this is not a legitimate MR name, and other audit messages don't indicate what the MR name should be, then use dbedit (MRX relation, Key for Edit is <MR>) to remove the record. If the MR name has been corrupted, then it might not be in the proper hash file (and thus dbedit won't find it). If so, go to the MRX relation directory at $sabGDB/../adb/$sabPROD/MRX and use grep to find the faulty record: grep ^<MR>; ??. Use a text editor to remove the record from the file.
MRX vs PTS/GRPReturn to: Top of PageDbcross index
The following ASSIGNEE's from MRX are not valid PTS IDs/groups First, find the specific MRs that have each assignee: ssql mr mrxdev from MRX where mrxdev.eq.<ASSIGNEE>. Use the study command to change the MR's assignee to a valid PTS ID or PTS ID group, or use the propose command to move the MR out of the mra_study state.
MS vs MD, MD vs MSReturn to: Top of PageDbcross index
The following MR GENERIC SOURCEFILE DIRECTORY combinations from MD are not in MS If this is a legitimate MD record, there will be corresponding records in SD: ssql mr from SD where sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY> and g.eq.<GENERIC> and mr.eq.<MR>. If so, use dbedit (MS relation, Key for Edit is <MR>) to create the missing record: <MR>;<GENERIC>;<SOURCEFILE>;<DIRECTORY>;<MSSTAT>, where <MSSTAT> is approved if the MR's status within that generic is either approved or closed (ssql mrgstat from MG where g.eq.<GENERIC> and mr.eq.<MR>), or is unapproved otherwise.
If this is not a legitimate MD record, use other audit-reported issues to address the repair or removal of the damaged MD record.
The following MR GENERIC SOURCEFILE DIRECTORY combinations from MS are not in MD If the corresponding record(s) aren't in SD either (ssql mr sid from SD where sfile.eq.<SOURCEFILE> and dir.eq.<DIRECTORY> and g.eq.<GENERIC> and mr.eq.<MR>), then use dbedit (MS relation, Key for Edit is <MR>) to remove the record. If the MR name has been corrupted, then it might not be in the proper hash file (and thus dbedit won't find it). If so, go to the MS relation directory at $sabGDB/../adb/$sabPROD/MS and use grep to find the faulty record: grep ^<MR>; ??. Use a text editor to remove the record from the file where it appears.
If there are SD records corresponding to the MS record, and other audit messages don't point you to where a damaged version of the missing MD record(s) ended-up, you can attempt to recover the missing record(s) from a backup (they should be in the file named $sabGDB/../adb/$sabPROD/MD/<tuple> where <tuple> is the return from dbhash <MR>), or use dbedit (MD relation, Key for Edit is <MR>) to create an MD record for each SD record: <MR>;<GENERIC>;<SOURCEFILE>;<DIRECTORY>;<MDSID>;<DEV>;;<MDCHG>;. Each <MDSID> is <GID>.2.<SDSID>, where <GID> is the return from ssql gsid from G where g.eq.<GENERIC> and <SDSID> is the sid value returned by the first SD query above.
The values for <DEV> and <MDCHG> can be found in the source history file by using that same (four part) <MDSID> value: grep '<MDSID>' $sabGDB/../sdb/$sabPROD/<DIRECTORY>/s.<SOURCEFILE>
MS vs MG, MG vs MSReturn to: Top of PageDbcross index
The following MR GENERIC combinations from MS are not in MG If this is a legitimate MS record, there will be one or more corresponding MD records: ssql mr from MD where g.eq.<GENERIC> and mr.eq.<MR>. If so, and other audit messages don't point you to where a damaged version of the missing MG record has ended-up, you'll need to recover it from a backup if possible (the record should be in the file $sabGDB/../adb/$sabPROD/MG/<tuple> where <tuple> is the return from dbhash <MR>), or if you must rebuild the record, copy a similar one and step through the fields to adjust the values according to other database information about this MR.
On the other hand, if this is not a legitimate MS record, then use dbedit (MS relation, Key for Edit is <MR>) to remove it.
The following MR GENERIC MGSTATUS MSSTATUS combinations from MG and MS have incompatible statuses The MG relation is, generally, the definitive indicator of an MR's status within a generic. Unless other audit data suggests that the MG record is damaged, use dbedit (MS relation, Key for Edit is <MR>) to change the msstat (field 5) to approved if the MGSTATUS is approved or closed, or to unapproved otherwise.
ORG vs MR, MR vs ORGReturn to: Top of PageDbcross index
The following MR names from MR are not in ORG If this is a legitimate MR name, and other audit messages don't point you to where a damaged version of the missing ORG record has ended-up, you can attempt to recover the missing record from a backup (the record should be in the file named $sabGDB/../adb/$sabPROD/ORG/<tuple> where <tuple> is the return from dbhash <MR>), or use dbedit (ORG relation, Key for Edit is <MR>) to create the ORG record: <MR>;<ORG>;<ODATE>;<PROD>;<SYS>;<SUB>;<REL>;<SITE>;<MOD>. The values can be found by finding the Sablime trace record for when the MR was created: (grep '<ABST>' $sabGDB/../adb/$sabPROD/FILES/trace/*, where <ABST> is the MR abstract: ssql abst from MR where mr.eq.<MR>).
If this is not a legitimate MR name, and other audit messages don't indicate what the MR name should be, then use dbedit (MR relation, Key for Edit is <MR>) to remove the record. If the MR name has been corrupted, then it might not be in the proper hash file (and thus dbedit won't find it). If so, go to the MR relation directory at $sabGDB/../adb/$sabPROD/MR and use grep to find the faulty record: grep ^<MR>; ??. Use a text editor to remove the record from the file.
The following MR names from ORG are not in MR Corrupted records generally trigger multiple audit messages, so if this is a legitimate MR name, evaluate other audit messages and consider making other, simpler fixes first. Creating the missing MR record from scratch can be difficult, and it's possible that other fixes will eliminate this problem.
If it turns out that the MR record is simply missing, try to retrieve a version from a backup (the record should be in the file named $sabGDB/../adb/$sabPROD/MR/<tuple> where <tuple> is the return from dbhash <MR>).
If you must rebuild the record, copy a similar one and step through the fields to adjust the values according to other available information about this MR.
If this is not a legitimate MR name, and other audit messages don't indicate what the MR name should be, then use dbedit (ORG relation, Key for Edit is <MR>) to remove the record. If the MR name has been corrupted, then it might not be in the proper hash file (and thus dbedit won't find it). If so, go to the ORG relation directory at $sabGDB/../adb/$sabPROD/ORG and use grep to find the faulty record: grep ^<MR>; ??. Use a text editor to remove the record from the file.
PDEP vs MDReturn to: Top of PageDbcross index
The following MR GENERIC FILENAME DIR SID combinations from PDEP are not in MD If the corresponding record(s) aren't in SD either (ssql mr sid from SD where sfile.eq.<FILENAME> and dir.eq.<DIR> and g.eq.<GENERIC> and mr.eq.<MR>), then use dbedit (PDEP relation, Key for Edit is <MR>) to remove the PDEP record. If the MR name has been corrupted, then it might not be in the proper hash file (and thus dbedit won't find it). If so, go to the PDEP relation directory at $sabGDB/../adb/$sabPROD/PDEP and use grep to find the faulty record: grep ^<MR>; ??. Use a text editor to remove the record from the file where it appears.
If there are SD records corresponding to the PDEP record, and other audit messages don't point you to where a damaged version of the missing MD record(s) ended-up, you can attempt to recover the missing record(s) from a backup (they should be in the file named $sabGDB/../adb/$sabPROD/MD/<tuple> where <tuple> is the return from dbhash <MR>), or use dbedit (MD relation, Key for Edit is <MR>) to create an MD record for each PDEP record: <MR>;<GENERIC>;<FILENAME>;<DIR>;<MDSID>;<DEV>;;<MDCHG>;. Each <MDSID> is <GID>.2.<SDSID>, where <GID> is the return from ssql gsid from G where g.eq.<GENERIC> and <SDSID> is the sid value returned by the first SD query above.
The values for <DEV> and <MDCHG> can be found in the source history file by using that same (four part) <MDSID> value: grep '<MDSID>' $sabGDB/../sdb/$sabPROD/<DIR>/s.<FILENAME>
PGR vs GRPMReturn to: Top of PageDbcross index
The following ptsid MEMBER GROUP combinations from GRPM are not in PGR Each ptsid group membership should be reflected in a PGR record. Remove the ptsid group if it's not needed. If it is needed, save its contents to a external file, then use setgroup to empty the group and quit setgroup. Launch setgroup again and put the contents back into the file; setgroup will re-create the group and all the PGR records.
The following GROUP MEMBER combinations from PGR are not in GRPM If the PTS IDs from PGR are supposed to be in the indicated groups, use setgroup to add them. Otherwise, use dbedit (PGR relation, Key for Edit is <PTS ID>) to remove the records from PGR.
PTS vs GRPReturn to: Top of PageDbcross index
The following GROUP OWNERS from GRP are not valid PTS IDs First, find the specific group(s) that have each OWNER: ssql grpname from GRP where owner.eq.<GROUP OWNER>. Then use setgroup to change the group owner(s) to legitimate PTS IDs or PTS group names.
PTS vs GRPMReturn to: Top of PageDbcross index
The following GROUP MEMBERS from GRPM are not valid PTS IDs First, find the specific group(s) that have each GROUP MEMBER: ssql grpname from GRPM where item.eq.<GROUP MEMBER>. Then use setgroup to change the group members to legitimate PTS IDs or PTS group names, or to delete the group, or to make it a non-PTS type group.
PTS vs SNAPReturn to: Top of PageDbcross index
The following CREATOR from SNAP is invalid First, find the specific snapshots(s) that have the CREATOR: ssql snapid from SNAP where cid.eq.<CREATOR>. Then use dbedit (SNAP relation, Key for Edit is <SNAPID>) to change the cid (field 3) to a legitimate PTS ID. Or use snapedit to delete the snapshot.
RELATION vs RELATIONReturn to: Top of PageDbcross index
Relation <REL> expected <number> fields but got <number> Dbcross found records with an incorrect number of fields. Compare with known good records, or with the Database Guide or with the output of ssql -help from <REL>, and use dbedit (<REL> relation, Key for Edit is <first field value>) to correct the record.
Warning: <REL> record in wrong tuple file [<tuple file>]: field [<key value>] Use other database information to determine if the key value (field 1) of the record is legitimate. If so, use dbhash <key value> to discover which tuple file the record should be in. Use a text editor to remove the record from the incorrect tuple file (the one mentioned in the audit message) and add it to the correct one.
If the key value is not legitimate, use a text editor to either correct it or to delete the record (in the directory $sabGDB/../adb/$sabPROD/<REL>).
The following keys have empty fields in <REL> Each relation has a specific number of key fields: fields that make the record unique, and cannot be empty. The G relation, for example, has 1: generic. The GS relation, on the other hand, has 3: file_name;directory;generic.
Dbcross is reporting that the indicated record has an empty key field. If other database information or audit messages suggest the correct value for the empty field, use dbedit (<REL> relation, Key for Edit is <first field value>) to correct the record, or to delete the record otherwise.
The following keys are duplicated in <REL> Each relation has a specific number of key fields: fields that must be unique. The G relation, for example, has 1: generic. The GS relation, on the other hand, has 3: file_name;directory;generic.
Use dbedit (<REL> relation, Key for Edit is <first field value>) to view the tuple file and find and remove the records with the duplicated key fields.
The following keys are duplicated between <REL> and inactive <REL> Each relation has a specific number of key fields: fields that must be unique across both the active and inactive databases. The G relation, for example, has 1: generic. The GS relation, on the other hand, has 3: file_name;directory;generic.
Use other database information or audit messages to determine whether the indicated record should be in the inactive database (closed generics and killed and closed MRs) or the active database, and then use dbedit (<REL> relation, Key for Edit is <first field value>) to find and remove the records with the duplicated key fields.
SNAP vs SNAPReturn to: Top of PageDbcross index
The following SNAPID GENERIC combinations from SNAP have invalid GENERIC Check the FZ relation for this snapshot for the correct generic name: ssql g from FZ where snapid.eq.<SNAPID>. Use dbedit (SNAP relation, Key for Edit is <SNAPID>) to correct the generic value (field 2). If FZ and SNAP agree on the generic, then you may have a corrupted or missing G relation. There will be other audit messages to suggest how to handle the G relation issue.
The following SNAPID GENERIC combinations from SNAP have empty CREATOR You may discover who created this particular snapshot by looking for the trace record from its creation: grep newsnapid=<SNAPID> $sabGDB/../adb/$sabPROD/FILES/trace/*. Use dbedit (SNAP relation, Key for Edit is <SNAPID>) to insert the creator into field 3.
TR vs PRReturn to: Top of PageDbcross index
The following GENERIC PRODUCT combinations from TR do not have 'y' or 'n' in the third field Use TR relation, Key for Edit is <GENERIC>) to set the Web visibilty to y or n.
The following GENERIC PRODUCT combinations have no corresponding TR record Use dbhash <GENERIC> to determine the proper tuple file name, and then use a text editor to add a Web visibility record (<GENERIC>;<PRODUCT>;<y or n>) for this item into $sabGDB/TR.
The following GENERIC PRODUCT combinations from TR do not correspond to a generic in the given product Use dbedit (TR relation, Key for Edit is <GENERIC>) to remove the unnecessary TR record.
UMS vs GSReturn to: Top of PageDbcross index
The following GENERIC SOURCEFILE DIRECTORY combinations from UMS are not in GS Unless other audit messages indicate that there is a missing GS record for this file, use dbedit (UMS relation, Key for Edit is <SOURCEFILE>) to remove this faulty UMS record.
UMS vs MGReturn to: Top of PageDbcross index
The following MR GENERIC combinations from UMS are not in MG Unless other audit messages indicate that there is a missing MG record for this MR, find the specific files(s) that have this <MR> and <GENERIC>: ssql sfile dir from UMS where mr.eq.<MR> and g.eq.<GENERIC>, and use dbedit (UMS relation, Key for Edit is <SOURCEFILE>) to remove the faulty UMS record(s).
UMS vs SDReturn to: Top of PageDbcross index
The following SOURCEFILE DIRECTORY GENERIC MR combinations from UMS are not in SD Unless other audit messages indicate that there is a missing SD record for this file, use dbedit (UMS relation, Key for Edit is <SOURCEFILE>) to remove this faulty UMS record.
The following SOURCEFILE DIRECTORY GENERIC MR combinations from SD are for unapproved MRs, but do not exist in UMS Unless other audit messages indicate that the SD record is incorrect, use dbedit (with SOURCEFILE as the Key for Edit) to create a corresponding UMS record: <SOURCEFILE>;<DIRECTORY>;<GENERIC>;<MR>. If the appropriate tuple file for this record doesn't already exist, dbedit may fail, and you'll need to create the file first: touch $sabGDB/../adb/$sabPROD/UMS/<TUPLE>, where <TUPLE> is the return from dbhash <SOURCEFILE>

 

Messages from dbdelta

Most dbdelta messages are of this form:

<REL> <keys>: <fieldname> [<value>] should be [<newvalue>]

For example:

GS myfile;src/dir;g1: srcid [2] should be [3]

These are generated when the source history file (the s. file in the Source Database) has information that conflicts with information in one of the Sablime database relations (the <REL>).

See the Database Guide or the output of ssql -help from <REL> for field names of the indicated relation. Review other audit messages and database information to confirm the reasonableness of the suggested change, and then use dbedit (<REL> relation, Key for Edit is <first key field>) to correct the record in <REL>.

Audit Message Response
<path to s. file>: no deltas found The indicated file has no deltas, and thus cannot represent a legitimate file managed by Sablime. Review other audit and database information to determine if this is a damaged file that should be recovered from a backup, or if it should simply be removed.
SD <SFILE>;<DIR>;<GEN>;<SID>: no corresponding delta in SDB The SD relation has a record for which there is no delta in an s. file. Since it is usually impractical to edit a missing delta into an s. file, use dbedit (SD relation, Key for Edit is <SFILE>) to remove the unmatched SD record.
Refer to other database and audit output and consider notifying the individual whose failed change has been eliminated.
SD <SFILE>;<DIR>;<GEN>: discrepancy versus SDB The message will accompany other, more explicit, messages. Refer to those other messages for suggested responses.
Return to: Top of PageDbdelta messages
MD <MR>;<GEN>;<SFILE>;<DIR>;<FULLSID>: sid [<FULLSID>] does not match gsid [<GSID>] for generic [<GEN>] The first two components of a four-component SCCS-ID are the Generic ID. This message indicates that the <FULLSID> in this MD record doesn't agree with the Generic ID of the record's <GEN> (ssql gsid from G where g.eq.<GEN>). Use other database information and audit messages to determine whether the <GEN> or the <FULLSID> of this record is incorrect, and use dbedit (MD relation, Key for Edit is <MR>) to correct the record.
MD <MR>;<GEN>;<SFILE>;<DIR>;<FULLSID>: no corresponding delta in SDB The MD relation has a record for which there is no delta in an s. file. Since it is usually impractical to edit a missing delta into an s. file, use dbedit (MD relation, Key for Edit is <MR>) to remove the unmatched MD record.
Refer to other database and audit output and consider notifying the individual whose failed change has been eliminated.
unexpected sid [<FULLSID>] in MD rec [<MR>;<GEN>;<SFILE>;<DIR>;<FULLSID>] This indicates a invalid <FULLSID> (where the third component, for example, isn't either 1 (ofc branch) or 2 (mr branch). Use dbedit (MD relation, Key for Edit is <MR>) to repair this record (if other database and audit information suggest the correction) or to remove the record.
Return to: Top of PageDbdelta messages
MD missing record: <MR>;<GEN>;<SFILE>;<DIR>;<FULLSID>;<DEV>;;<DATE>; The MD relation is missing a record for a delta that is recorded in the s. file of the Source database. Unless you have reason to believe that the s. file is corrupted, use dbedit (MD relation, Key for Edit is <MR>) to create the missing MD record (as defined in the message). If the appropriate tuple file for this new record doesn't already exist, dbedit may fail, and you'll need to create the file first: touch $sabGDB/../adb/$sabPROD/MD/<TUPLE>, where <TUPLE> is the return from dbhash <MR>
missing sdb file <DIR>;<s.SFILE> The GS (Generic/Source) relation suggests that there should be an s. file by this name in <DIR> of the Source Database. If other database and audit information suggest that the GS record is incorrect, use dbedit (GS relation, Key for Edit is <SFILE>) to remove it. Otherwise, attempt to recover the missing s. file from a backup. In the unlikely circumstance that the s. file is totally lost and unrecoverable, you may need to use dbedit to remove the GS and other database records for the file, and then to use addsrc to re-add it.
extra sdb file <DIR>;<s.SFILE> The Source Database has an s. file by this name in <DIR>, but there are no GS (Generic/Source) relation records for the file. If this is, in fact, a Sablime-managed file, there will be other audit messages (use dbcross) to suggest how to replace the missing GS record. Otherwise, remove the s. file from $sabGDB/../sdb/$sabPROD/<DIR>.
Return to: Top of PageDbdelta messages

 




Sablime is a registered trademark of Alcatel-Lucent Inc.
Contents copyright © 2009 Alcatel-Lucent. Permission to photocopy in support of a licensed installation of Sablime is hereby granted.