Audit and Troubleshooting Guide

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 database relational data, while dbdelta looks for consistency between the Version Control files and the Sablime database.

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_name -help to see the possible option settings.

Note:If you run the audits when the database is not stopped, there is always the possibility that the audits will report a database problem when, in fact, an update was only partially completed at the instant the audits were checking there. Always verify that the indicated problem really exists before taking corrective actions.

It is recommended that you run the audits daily, using the system’s automated scheduler. Sablime supplies a script named run_audits (under your command bin directory at $sabLCB/admin 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 at $sabLCB/ref_files) 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 $sabGDB/audits/product_name. 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
Displays the runtime environment settings for the commands that exectute on the Sablime host.
Site information
Displays technical information about the Web Sablime client and host setup.
Run site diagnostics
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 does not need to re-figure them). On rare occasions, this data can become out-of-sync with the actual environment and thus create issues. You can run Tools > Debug > Clear Sablime cache to cause Sablime to discard these saved settings.

Audit Messages

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

Follow these links to skip directly to a specific table:

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.”

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.

Messages from dbcross
Audit Message Response
Green Checkmark Symbol Messages marked with the green checkmark indicate those that the audit program will automatically fix if you supply the --fixme or --fixudf argument on the audit command line. --fixudf applies only to the FTD inconsistency messages.
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 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 create the missing group and/or to make it a PTS ID group.
The following MR administrator from ADM is not a valid PTS group Use setgroup to create the missing group and/or to make it a PTS ID group, or use setrel/ADM to change the MR Administrator group to one that exists.
The following Source administrator from ADM is not a valid PTS group Use setgroup to create the missing group and/or to make it a PTS ID group, or use setrel/ADM to change the Source 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 records(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 "^CMD;" ??) 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 setrel/CRIT 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 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 (stat, 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 records(s): MR ; GENERIC ; SPAWN, where SPAWN is each value returned from the first query.
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
Green Checkmark Symbol 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 ftd 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.
Green Checkmark Symbol 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 ftd 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.
Green Checkmark Symbol 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 ftd 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 COMMAND) 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. compared with 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.
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 vs GReturn 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.
The following generic administrators from G are not valid PTS groups Use setgroup to create the missing group and/or to make it a PTS ID group, or use Manage Generics to change the Generic Administrator group name to one that exists.
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 source 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 (cocnt, field 16) to 1; if not, use dbedit to remove the MR from rmr, 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 (rmr) 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 (gsstat) 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 gsstat (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 of common (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 records(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/unreserved ; DATE) where SID is field 17 (lsid) of GS plus 1, “reserved/unreserved” is “reserved” if GS field 15 (rmr) is populated, and DATE is a reasonable guess at the date when the edget occurred (mm/dd/yy hh:mm:ss). 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 file at $sabGDB/../sdb/$sabPROD/DIRECTORY with this GENERIC’s ID 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 (rmr) 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 file at $sabGDB/../sdb/$sabPROD/DIRECTORY with this GENERIC’s ID 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 (rmr) 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 (lsid and lmr) of the GS record to the highest numbered delta (and its MR) 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.
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 (lsid and lmr) of the GS record to the highest numbered delta (and its MR) 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 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.
GT vs GRPReturn to: Top of PageDbcross index
The following team names from GT are not valid PTS groups The indicated group names are present in the GT relation as Test Teams for one of the five optional test states or as the Approval Team for this generic. Use setgroup to create the missing group and/or to make it a PTS ID group, or use Manage Generics to change the Team group name to one that exists.
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 file at $sabGDB/../sdb/$sabPROD/DIRECTORY with this GENERIC’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 that they may need to edget the file again: if they’ve already made changes to their checked out 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 checked-out 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).
MC vs GS (Checkout Count)Return to: Top of PageDbcross index
The following GENERIC SOURCEFILE DIRECTORY COCNT#_of_MC have COCNT (checkout 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_MC” value from the audit message.
The following GENERIC SOURCEFILE DIRECTORY combinations have more than one "reserved" checkout MC record 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 that 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 assign 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 study to add a study developer.
The following MR GENERIC STATE SYSCODE combinations from MG contain inconsistent STATUS and SYSCODE
State Code State Code
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 (mgstcd) according to the table. 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: 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 (stat, 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: 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 (MR relation, Key for Edit is MR) to change the MR status (stat, 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 code (mgstcd, 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 assign 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 testassign 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 branch is “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 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 records(s) (MR ; GENERIC ; SPAWN), where SPAWN is each value returned from the first query. If this is not a 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 (spawns) 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 “tuple” 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 “tuple” 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 study to change the MR’s assignee to a valid PTS ID or PTS ID group, or use propose to move the MR out of the “mra_study” state.
MS vs MD, MD vs MSReturn to: Top of PageDbcross index
Green Checkmark Symbol 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 records(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 “tuple” 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 records(s) ended-up, you can attempt to recover the missing records(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 “tuple” 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 “tuple” 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 records(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 “tuple” 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 records(s) ended-up, you can attempt to recover the missing records(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 GROUP 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 that CREATOR (ssql snapid from SNAP where cid.eq.CREATOR). Then use dbedit (SNAP relation, Key for Edit is SNAPI) 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 which cannot be empty. The “G” relation, for example, has one: g (generic). The “GS” relation, on the other hand, has three: sfile (source file name), dir (directory), and g (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 one: g (generic). The “GS” relation, on the other hand, has three: sfile (source file name), dir (directory), and g (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 make the record unique across both the active and intactive databases. The “G” relation, for example, has one: g (generic). The “GS” relation, on the other hand, has three: sfile (source file name), dir (directory), and g (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 g (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 (cid).
TR vs PRReturn to: Top of PageDbcross index
Green Checkmark Symbol The following GENERIC PRODUCT combinations from TR do not have 'y' in the fourth field This generic is not closed, but the “Active” flag is either missing or set to “n”. Use dbedit (TR relation, Key for Edit is GENERIC) to set active (field 4) to “y”.
Green Checkmark Symbol The following GENERIC PRODUCT combinations from TR do not have 'n' in the fourth field This generic is closed, but the “Active” flag is either missing or set to “y”. Use dbedit (TR relation, Key for Edit is GENERIC) to set active (field 4) to “n”.
Green Checkmark Symbol The following GENERIC PRODUCT combinations from TR do not have 'y' or 'n' in the fourth field This message comes along with one of the above. Use dbedit (TR relation, Key for Edit is GENERIC) to set active (field 4) to “y” or “n” depending on whether the generic is open or closed.
Green Checkmark Symbol The following GENERIC PRODUCT combinations from TR do not have 'y' or 'n' in the third field Use dbedit (TR relation, Key for Edit is GENERIC) to set the Web visibilty (web, field 3) to “y” or “n”. (Note: the --fixme option will set this to “n”.)
Green Checkmark Symbol The following GENERIC PRODUCT combinations do not have a corresponding TR record Use dbhash GENERIC to determine the proper tuple file name, and then use a text editor to add a TR record (GENERIC ; PRODUCT ; y or n ; y or n) for this item into $sabGDB/TR. (Note: the --fixme option will set field 3 (web) to “n”, and will set field 4 (active) to “y” for open generics or “n” for closed generics.)
Green Checkmark Symbol 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 records(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.
Green Checkmark Symbol 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).
Messages from dbdelta

Green Checkmark Symbol 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
# no GS records for the following FILE GENERIC sabSDB combinations:
SFILE GEN DIR
# NOTE: some checks were skipped because of the missing GS records
# Run dbdelta again after fixing these
The Source Database has this “s.” file that has deltas for the indicated Generic, but there is no GS (Generic/Source) record. If the missing record isn’t available in a backup copy (the record should be in the file $sabGDB/../adb/$sabPROD/GS/tuple where tuple is the return from dbhash SFILE, or if you must rebuild the record, duplicate the GS record from this SFILE and a different GEN; and step through the fields to adjust the values as necessary. Use dbedit (GS relation, Key for Edit is SFILE) to open the file that should contain the records for this SFILE.
As the “NOTE” says, certain other dbdelta checks are skipped when a missing GS record is detected. This is because the validity of some SD and MD records can not be determined without a GS record. Once the GS record is recovered or recreated, dbdelta should be executed again.
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.
Green Checkmark Symbol 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.
Green Checkmark Symbol SD missing record: SFILE ; DIR ; GEN ; SID ; MR The SD 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 (SD relation, Key for Edit is SFILE) to create the missing SD record (as defined in the message).
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 (FULLSID) are the GSID (Generic ID). This message indicates that the FULLSID in this MD record doesn’t agree with the GSID 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.
Green Checkmark Symbol 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
Green Checkmark Symbol 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).
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-2015 Alcatel-Lucent. Permission to photocopy in support of a licensed installation of Sablime is hereby granted.