Database Guide

A description of the components of a Sablime database

Introduction

This document is intended for use by Sablime Administrators or other users curious about the design and layout of the Sablime database. Knowing this information can help users understand how Sablime commands interact with the database.

Basic Layout

Each Sablime instance has one global database. This contains the user information; information about the products being stored in this instance of Sablime; and information about other Sablime systems that may be exchanging information with this one. For each product stored in this Sablime, there is an active, inactive, and source database.

The active database contains information about the product’s generics, MRs, and files. Some of this information is moved to the inactive database when the items are closed. The source database contains the actual content of the files being controlled by this instance of Sablime.

Follow the links below to jump to detailed information about the four Sablime databases.

Whenever you set up to use console Sablime (using . set_sablime), the variable $sabGDB will be set in your shell environment. Display its value in order to discover where the GDB is located on your machine:

$echo $sabGDB
/home/sablime/databases/gdb

The active, inactive, and source databases are usually located in the same parent directory as the GDB, in a sub-directory named for their product. For example, if the instance above had a product named “mypr”, the Active Database would probably be at /home/sablime/databases/adb/mypr.

Note that /home/sablime/databases/gdb is an example; and although the default Sablime setup puts the other databases in the same parent directory as the GDB, your instance may be configured otherwise. The actual location for each of these can be discovered by using ssql to query the global database:

$ssql adbdir idbdir sdbdir from PR where pr.eq.mypr
/home/sablime/databases/adb/mypr
/home/sablime/databases/idb/mypr
/home/sablime/databases/sdb/mypr

The global, active, and inactive databases contain sub-directories for the Sablime relations. Relations that store generic-specific information have, within them, subdirectories named for each generic.

If you look in the relation directories or generic-specific subdirectories, you would see files with two-character file names. These are called tuple files. Each line of a tuple file is a database record containing information about an individual item. Some relations — like the PR relation — contain only a few files, and each of them contains only a few records. That’s because there aren’t usually many products in a Sablime instance.

Some relations may contain hundreds of these files, and each may have hundreds of lines (records). The MD relation in the active database is one of these that tends to have a large number of tuple files and records. Sablime stores the records in these many files so that it doesn’t need to open one huge file to find the specific record it is looking for.

The name of the tuple file that stores a particular record is determined by the record’s first field: its hash key. The dbhash command can be used to discover the file name. For example, the records in the MD relation associated with an MR named “mypr090076” would be stored in the tuple file “dd”:

$dbhash mypr090076
dd <-- mypr090076

In addition to the relation sub-directories with the tuple files, there are some other sub-directories where text files — such as an MR’s description — are stored.

The source database is structured differently. It is composed of an instance of the product's directory structure (combining all generics). The individual directories contain the files used by the Version Control Tools to store the actual contents of the files you’ve stored into Sablime. See Source Database for more details.

The following table shows where the relations and other significant database entities can be found:

Database Relations Other
Global BK ES PR PTS TR DBLOCK rd rq sd sq tmp
Active ADM BH BLD CAS COM CP CRIT DEP DG EMG EMR FTD FZ G GRP GRPM GS GT MC MD MG MR MRH MRS MRX MS ND NH NX ORG PDEP PGR SC SD SNAP UMS ATTACHMENTS DBLOCK FILES GROUPS recover tmp
Inactive BH BLD COM CP CRIT DEP DG EMG EMR G GS GT MD MG MR MRH MRS MRX MS ND NH NX ORG PDEP SD SNAP ATTACHMENTS DBLOCK FILES tmp

Return to: Top of Page

The Sablime Databases

Global Database (GDB)

Each Sablime instance has one global database. This contains the user information; information about the products being stored in this instance of Sablime; and information about other systems that may be exchanging information with this one. Whenever you set up to use console Sablime, $sabGDB will be set to the location of your GDB:

$cd $sabGDB
$ls
BK      DIR     PR      TR      rq      sq    
DBLOCK  ES      PTS     rd      sd      tmp
$

The GDB contains the following relations: Click on the relation name to jump to detailed information about that relation

Relation Name Description
BK Build Keys The unique keys associated with the builds in the products associated with this GDB.
ES External Source Other (i.e. External) projects that exchange data with this Sablime.
PR Product General information about the products associated with this GDB.
PTS Personnel Tracking Details about the individual Sablime users of this system.
TR Translation The names of the generics associated with the products associated with this GDB; whether or not they are to be visible on the web interface; and whether or not they are active (i.e. not closed).

In addition to the relations, you will see some other items in the global database:

Item Description
DBLOCK Contains directories matching the relations of the global database. Sablime puts a tuple file in one of these when it is busy updating the corresponding file in the GDB. This tells other Sablime processes to wait a second or two before trying to do their own updates to that file.
rd / sd Text files being sent to or received from external systems.
rq / sq Contains messages being sent to or received from external systems.
tmp Used by Sablime as temporary workspace when updating database files. Also contains the dbawarn files: there is one of these for each product in the instance, and they store the Sablime system warning (and error) messages. There is also an ftdlog file for each product, recording the updates to the FTD relation.
The ftdlog and dbawarn files grow over time, and you can feel free to remove or truncate them to save disk space as desired.

The following sections describe in detail each of the global database’s relations.

Return to: Top of PageGlobal DB

BK Relation — Build Keys

$ssql -help from BK
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   key       Key                      3   g         Generic                 
   2   prod      Product                  4   bld       Build

The above output from ssql -help shows the field names (keywords) and the description of the fields of the BK relation. An actual record in the BK relation might look like this:

$tail -1 $sabGDB/BL/fl
ab;sab;v7.0;ilinux

The BK Relation has the unique 2-character build key for each configured build of the products and generics associated with this global database. This allows Sablime to quickly associate a build artifact with the appropriate configured build. There is one record for each key, which in turn associates with a unique Product + Generic + Build combination.

BK records get created by build_create, and deleted by build_delete.

Field Description
Key The unique, two character, key for this Product + Generic + Build combination.
Product The product, generic, and build to which this record applies.
Generic
Build

Return to: Top of PageGlobal DBBK Relation

ES Relation — External Source

$ssql -help from ES
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   proj      External Project         6   parm      Parameters
   2   prod      External Product         7   sflag     Status Flag
   3   host      Remote Machine           8   stats     Status
   4   net       Network Type             9   stsend    Send MR state
   5   prog      Remote Program          10   stmrnote  Send mrnote Desc

The above output from ssql -help shows the field names (keywords) and the description of the fields of the ES relation. An actual record in the ES relation might look like this:

$tail -1 $sabGDB/ES/nn
sablime;expr;europa;6;rcv_msgs;;y;y,y,y,y,y,y,y,y,y,y,y,y,y,y,n;n;n

The ES Relation holds the configuration data for the External Communications feature. This feature allows Sablime instances to communicate MR data to other Sablime (and even non-Sablime) systems. There is one record for each External Project + External Product combination.

Sablime’s setrel command is used to create and change External Communications configurations.

Field Description
External Project Values as set by setrel.
External Product
Remote Machine
Network Type
Remote Program
Parameters
Status Flag The “y” or “n” answer to “Do you want to communicate MR status changes ?” from setrel.
Status The set of “y” or “n” values corresponding to the 15 Status Change fields in the setrel command (assuming “y” for “Status Flag”).
Send MR state The “y” or “n” answer to “Do you want to communicate MR state at link time ?”
Send mrnote Desc The “y” or “n” answer to “Do you want two-way mrnote communication ?”

Refer to the setrel documentation for more details.

Return to: Top of PageGlobal DBES Relation

PR Relation — Product

$ssql -help from PR
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   pr        Product                  7   idbdir    Inactive Database
   2   prtype    Type                     8   sdbdir    Source Database
   3   mm        Multi-Machine Type       9   dbver     Database Version
   4   host      Host                    10   sys       For Future Use
   5   mcbdir    Master Bin              11   rel       For Future Use
   6   adbdir    Active Database         12   loc       For Future Use

The PR Relation holds information about each of the products managed by this Sablime instance. There is one PR record for each Product in a Sablime instance. An actual record in the PR relation might look like this:

$tail -1 $sabGDB/PR/mh
mypr;internal;1;devhost;/home/sablime/bin;/home/sablime/databases/adb/mypr;
/home/sablime/databases/idb /mypr;/home/sablime/databases/sdb/mypr;v7.0;;;

The information in the PR relation is placed there by initsab when the product is created. The values can be updated by using setrel (PR relation), except in the case of the Database Version, which is updated by dbconvert when the database is upgraded:

Field Description
Product The product name.
Type This is always “internal”
Multi-Machine Type 1 if this product is part of a host+satellite Sablime setup. 0 otherwise.
Host The host machine name.
Master Bin The absolute path to the Sablime bin on the host machine.
Active Database The absolute path to the Active Database.
Inactive Database The absolute path to the Inactive Database.
Source Database The absolute path to the Source Database.
Database Version The most recent database upgrade applied to this database. Not necesssarily the same as the Sablime version, as there are some Sablime updates that don’t include database upgrades.

Return to: Top of PageGlobal DBPR Relation

PTS Relation — Personnel Tracking System

$ssql -help from PTS
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   ptsid     User Name               11   mflag     Receive Mail  
   2   name      Full Name               12   auth      Auth Products   
   3   dept      Department              13   lu        Last Usage     
   4   loc       Location                14   aom       Auto Orig Mail 
   5   room      Room                    15   aam       Auto Asgn Mail
   6   phone     Phone                   16   mwd       Verbose Email 
   7   vflags    Verbose Flags           17   mlic      Obsolete      
   8   ed        Preferred Editor        18   lmu       Obsolete      
   9   email     Email Address           19   mgr       Manager       
  10   lic       Licensed                20   srcacc    Source Access 

The PTS Relation holds information about each of your authorized users. There is one PTS record for each user. An actual PTS record might look like this:

$tail -1 $sabGDB/PTS/li
joedev;Joe Developer;10009910;CB;1b370;614 555-4836;fs,n,n,y,5;vi;
joedev@mycompany.com;y;y;All_Products;03/02/09;n;n;y;;;;;y

Some users will have been automatically added during the initial setup of Sablime by initsab. For most users, though, the information in the PTS relation is entered by a Sablime administrator — using pts — when the individual is given access to Sablime.
Most fields can be updated by the user; some only by the Database Administrator; and a few are updated by the system.

For most fields, the “Description” in the above ssql output is the same as the field name in the pts command where the data was collected. The one exception is field 7 (Verbose Flags) where these 5 pts values are stored as one comma-separated field: Command Mode, Verbose Prompts, Verbose Info, Verbose Help, Popup Delay.
Refer to the pts documentation for details about what values might be present, and what they mean.

Return to: Top of PageGlobal DBPTS Relation

TR Relation — Translation

$ssql -help from TR
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   g         Generic                  3   web       Visible on Web
   2   pr        Product                  4   active    Active  

The TR Relation stores the names of the generics associated with the products in this GDB; whether a particular product/generic combination is to be made visible on Web Sablime; and whether the generic is active (i.e. not closed). There is one TR record for each Generic + Product combination. An actual TR record might look like this:

$tail -1 $sabGDB/TR/nk
g13.2;mypr;y;y

A record in the TR relation is automatically created by initsab when a new product is created, and by newgen when a generic is added. Fields 3 (web) and 4 (active) are initially populated with a “y”. The web value indicates whether this particular product/generic combination should be included on the selection menus for Web Sablime users. Active indicates whether the generic is in use. The set_sablime initialization script will ignore generics that have active set to “n”. The dbedit command can be used to change the values (either “y” or “n”). Each is set to “n” when closegen is used to close the generic.

Return to: Top of PageGlobal DBTR Relation

Active Database

The active database contains information about a product’s active assets: its builds, generics, MRs, nodes, and files. The Active Database relations detail such things as which files are in which generics; which MRs have changed which files; which files are currently being edited (and by whom); etc.

Although the definitive location of the active database is stored in the PR relation (ssql adbdir from PR where pr.eq.$sabPROD), it is usually safe to find the Active Database based on the $sabGDB and $sabPROD environment variables that were established when you ran . set_sablime:

$cd $sabGDB/../adb/$sabPROD
$ls
ADM          CRIT         FTD           GT          MRX          PGR     
ATTACHMENTS  DBLOCK       FZ            MC          MS           SC
BH           DEP          G             MD          ND           SD
BLD          DG           GROUPS        MG          NH           SNAP
CAS          EMG          GRP           MR          NX           UMS      
COM          EMR          GRPM          MRH         ORG          recover
CP           FILES        GS            MRS         PDEP         tmp

The Active Database contains the following relations: Click on the relation name to jump to detailed information about that relation

Relation Name Description
ADM Administration Product-level settings and configuration choices.
BH Build History Information about significant events related to each Build.
BLD Build Information about the configured Builds.
CAS Cascade Settings for command fields that cascade: the contents on one menu is determined by the selection in another.
COM Commit Information about MRs where a committment date has been set.
CP Command Permissions Information about commands where special permissions and/or email recipient settings have been established.
CRIT Criteria Criteria settings for automatic assignment and/or email routing.
DEP Dependency Information about MRs that are dependent on other MRs.
DG Directory/Generic Records the latest change in the directory within the generic.
EMG External MR/G Information about External MRs within their Generic.
EMR External MR Information about MRs being shared with an External project.
FTD Field Tracking Data Configuration data about the individual fields of the Sablime commands.
FZ File Snapshot Information about which files are used in snapshots.
G Generic Configuration data and about each generic.
GRP Group Information about the Sablime groups.
GRPM Group Members The contents defined for the Sablime groups.
GS Generic/Source Information about which files have been added to which generics.
GT Generic/Test Information about the test teams (groups) used in each generic.
MC MR/Checkouts Information about MRs currently holding checkouts.
MD MR/Delta Information about MRs that have applied changes (deltas) to files.
MG MR/Generic Information about the MRs that have are accepted (or beyond) in the generic(s).
MR MR Information about the active MRs that exist in this product.
MRH MR History Information about the significant events related to each MR.
MRS MR/Spawn Information about the MRs that have had spawns created from them.
MRX MR/Extra Information about MRs that have been put under study, or have been deferred (before being accepted).
MS MR/Source Information about which MRs have touched which files.
ND Nodes Information about the configured nodes.
NH Node History Information about significant events related to each Node.
NX Node Syncs Information about completed node_sync operations.
ORG Originator Further information about each of the product’s MRs (in particular, the Originator).
PDEP Physical Dependencies Information about MRs that are dependent on other MRs due to having changed the same file(s).
PGR PTS/Group Information about which PTS groups each individual PTS ID belongs to.
SC Source/Checkouts Information about the files that are currently checked out.
SD Source/Delta Information about source files that have had changes (deltas) applied.
SNAP Snap Information about the contents and creation parameters of each snapshot.
UMS Unapproved MRs Information about which files have been touched by unapproved MRs.

In addition to the relations, you can see some other items in the Active database:

Item Description
ATTACHMENTS Contains directories for storing attachments to the standard text files. For generic-specific items (resolutions, for example), that directory contains a subdirectory for each generic where attachments exist. The attachment files themselves are stored in subdirectories named for the MR to which they are attached.
The first level subdirectories that may be present are:
  • description
  • resolution
  • testnotes
  • glob_solution
  • solution
  • rejection
  • spawnnotes
Attachments get moved to the Inactive Database when the associated MR is closed or killed.
DBLOCK Contains directories matching the relations of the active database. Sablime puts a tuple file in one of these when it is busy updating the corresponding file in the Active Database. This tells other Sablime processes to wait a second or two before trying to do their own updates to that file.
FILES/sab.stopfile Usually, this is a zero-length file. When it has contents, access to this product’s database is denied. This file is given contents by the dbstop command, and emptied by dbstart.
FILES/builds A directory containing a sub-directory for each generic. These contain a further subdirectory for each build configured for that generic. The build-named directory contains the text files associated with the last 7 fields of the BLD relation.
FILES/description A directory containing the description file for each active MR.
FILES/glob_solution A directory containing the proposal text for each MR that was put under study before being accepted into a generic.
FILES/mrcommit A directory containing a sub-directory for each generic. These contain a file for each committment ID, listing the MRs committed by that ID.
FILES/node_files A directory containing a sub-directory for each generic. These contain a further subdirectory for each managed node for which a node_update has been run. The node-named directory contains the text files associated with the last 6 fields of the ND relation.
FILES/rejection A directory containing a sub-directory for each generic. These contain the rejection text for each active MR that has been rejected in that generic.
FILES/resolution A directory containing a sub-directory for each generic. These contain the resolution text for each active MR that has been submitted in that generic.
FILES/snap_cmds A directory containing a sub-directory for each generic. These contain a file for each snapshot. These files contain the version control commands needed to extract the particular version of each file used by that snapshot.
FILES/snap_gout A directory containing a sub-directory for each generic. These contain the output from the getversion that created the snapshot.
FILES/solution A directory containing a sub-directory for each generic. These contain the solution text for each active MR that has been under study in that generic.
FILES/spawnotes A directory containing a sub-directory for each generic. These contain the spawn notes text for each active MR that has been spawned in that generic.
FILES/structure Contains a directory structure file for each generic listing the relative path of each directory.
FILES/templates A directory containing templates for various text files (e.g. description file, resolution file, etc.).
FILES/testnotes A directory containing a sub-directory for each generic. These contain the test notes text for each active MR that has been testpassed in that generic.
FILES/trace A directory containing a file for each PTS ID — showing their command usage and results. These can be very helpful in investigating reported system problems.
GROUPS Contains subdirectories for the three types of groups: “mr”, “ptsid”, and “other”. Within these are the files containing the members of each such group.
recover Contains the file and relation data necessary to restore files that have been deleted (in case the deletion was a mistake). See the Usage Guide for more details on restoring deleted files.
tmp Used by Sablime as temporary workspace when updating database files.

Return to: Top of PageActive DB

ADM Relation — Product Administration

$ssql -help from ADM
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   dbgroup   Database Admin          12   autoassgn Auto Assign
   2   mrgroup   MR Admin                13   reassgn   Reassignment
   3   suffix    MR Suffix               14   autodep   Auto Dependency     
   4   prefix    MR Prefix               15   depoverr  Dependency Override
   5   trace     Trace File              16   srcgrp    Source Admin      
   6   dummy1                            17   mailint   Mail Dispatch Interv
   7   mail      Mail                    18   hwgrp     Hardware Admin      
   8   fldsep    Field Separator         19   vctool    Version Ctrl Tool     
   9   unused                            20   dummy3   
  10   dummy2                            21   brflags   Branch Flags
  11   routing   Auto Route  

The ADM Relation holds configuration information about the product. There is only one ADM record per product. An actual ADM record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/ADM/ck
dba_mypr;mra_mypr;090019;mypr;y;;y;,;y;y;n;n;all;line-level;y;sa_mypr;5
;ha_mypr;Either;;y

Most of the information in the ADM relation is collected by initsab when the product is created. Refer to the initsab documentation for details on the fields and their values. The values in the ADM relation can be changed by the Database Administrator using the setrel command.

The following table describes those fields that are not included in the initsab documentation (and a couple where the Field Description from above could use some elaboration):

Field Description
MR Suffix The portion of the MR name appended to the MR prefix to create new MR names. This must be an numeric value, 1 to 6 digits (leading zeros are OK). The value gets incremented by one each time a new MR is created. By default initsab sets this to “000000”.
MR Prefix The portion of the MR name prepended to the MR suffix to create new MR names. This is set by initsab to the same as the product name, but that is not a requirement.
Field Seperator This is set to “,”(comma) and should not be changed.
Mail Dispatch Interval This should not be changed.
Auto Dependency This is the type of automatic dependency selected if the admin replied “y” to “Do you want Automatic Dependency?” in initsab. Otherwise, this is “none”.
Branch Flags This is the answer to the “Do you want Temporary Branching enabled?” question from initsab.

Because ADM relation records are neither MR nor generic-specific, there is no ADM relation in the Inactive Database.

Return to: Top of PageActive DatabaseADM Relation

BH Relation — Build History

$ssql -help from BH
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   bld       Build                    6 host        Command Host            
   2   when      Time Stamp               7 txt1        Field/Status            
   3   g         Generic                  8 txt2        Newval/pmrs             
   4   cmd       Command Used             9 txt3        Oldval/promoted/ofiles  
   5   user      Command User            10 txt4        Reason/xfiles

The BH Releation holds information about the status and configuration events associated with builds. It does not track the build executions themselves: those are recorded by builder. There is one BH record for each Build + Time Stamp + Generic combination. An actual BH record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/BH/__v7.0/fi
ilinux;1291317908.277317;v7.0;build_status;devsab;yams;status;busy;built;

BH records get created by build_create, build_config, and build_delete, and by builder when it sets the build status.

Some commands may generate multiple history event records. For example, a build_config operation changing more than one value will generate an event record for each change.

Field Description
Build Designates the event to which this record applies.
Time Stamp
Generic
Command Used The command that triggerred the event.
Command User The user (PTS ID) that executed the command.
Command Host The host (machine name) where the command was executed.
Field/Status These fields store the major parameters associated with the operation being recorded. For the build_config operation, for example, they store the field being changed, the old value, and the new value. Different operations store different values. A complete guide to the contents of these fields will be released at a later date.
Newval/pmrs
Oldval/promoted/ofiles
Reason/xfiles

BH records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseBH Relation

BLD Relation — Builds

$ssql -help from BLD
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   bld       Build                    9   rundir    Run Directory           
   2   g         Generic                 10   bparams   Build Parameters        
   3   key       Key                     11   etmpl     Email Template          
   4   desc      Description             12   hooks     Hooks                   
   5   status    Status                  13   nparams   Node Parameters         
   6   owner     Owner                   14   errlist   Error List              
   7   chgdt     Latest Change           15   warnlist  Warning List            
   8   rundt     Run Date                16   lkd_nodes Locked Nodes

The BLD Releation holds information about the builds that have been configured for the product. There is one BLD record for each Build + Generic combination. An actual BLD record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/BLD/__v7.0/fi
ilinux;v7.0;ab;v7.0u3 nightly build;nobuild;devsab;;12/02/10 04:14:05;
/home/devsab/builder_rundata/sab/v7.0/ilinux/D201012020414n

BLD records get created by build_create, and may get updated by build_config or builder. BLD records may get removed by build_delete.

Field Description
Build Designates the build to which this record applies.
Generic
Key A two-character build key unique across the products in this global database. This key is also stored in the GDB BK Relation.
Description Value set by build_create or build_config.
Status
Status Meaning
built The most recent builder execution successfully completed a build.
busy Builder is currently running builds or unlocking build nodes.
configured The build has been created or its configuration has been changed. It has not been run since.
errors The most recent builder build finished, but had more than the number of build errors allowed for a “successful” build.
failure The most recent builder execution ended because of a system or program issue (not a build error).
nobuild The most recent builder execution found no source files changed and was not instructed to continue unconditionally. It did not launch an actual build.
unlocked Builder was launched with -U, which unlocks its nodes and sets this status unconditionally.
Owner Value set by build_create or build_config.
Latest Change Set by the most recent build_create or build_config.
Run Date The launch time of the most recent builder execution of this build.
Run Directory The directory containing the runtime output and status files for the most recent execution of the build by builder.

The next 7 items are not actual fields in the BLD relation record. They can be queried by ssql by field name or field number, but the command actually retrieves the data from the associated text file stored under $sabGDB/../adb/$sabPROD/FILES/builds/generic/build.

Build Parameters The file contents as specified when the build was created or configured.
Email Template
Hooks
Node Parameters
Error List
Warning List
Locked Nodes A list of nodes - specified by full path name - currently locked by builder.

BLD records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseBLD Relation

CAS Relation — Cascading Fields

$ssql -help from CAS
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   type      Cascade Type             3   group     Lower Level Group
   2   key       Upper Level Key

The CAS Relation holds the configuration of command fields that cascade. These are fields where the menu items presented in one field vary based on the selection in another. For example, the choices in the Subsystem menu of create depend on the selection in the System menu. There is one record per Cascade Type. An actual CAS record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/CAS/eb
sysCASsub;Admin;_AdmSubs

The initsab command puts default values into the CAS relation when the product is created. You can use the setrel command to customize these values for your local needs.

Field Description
Cascade Type This is the particular cascading relationship being defined. The system-to-subsystem cascade, for example, is named “sysCASsub”.
Upper Level Key The selection in the upper level menu.
Lower Level Group The group name whose contents are used for the lower level menu when this Upper Level Key is selected.

Because CAS relation records are neither MR nor generic-specific, there is no CAS relation in the Inactive Database.

Return to: Top of PageActive DatabaseCAS Relation

COM Relation — Committed MRs

$ssql -help from COM
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   comid     Commitment ID            4   nusers    Number of Users Affe
   2   g         Generic                  5   tstamp    Date and Time
   3   comdate   Commitment Date

The COM Relation information contains information about committed MRs. There is one COM record for each Commitment ID + Generic where that ID is defined. An actual COM record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/COM/nk
fall09;g13.2;08/31/09;25;02/28/09 14:44:09

The commit command is used to create and update values stored in the COM relation. See the commit documentation for details.

COM Relation records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseCOM Relation

CP Relation — Command Permissions

$ssql -help from CP
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   cmd       Command                  4   exec      Executors
   2   g         Generic                  5   email     Email Recipients
   3   fcntype   Function

The CP Relation holds information about customized command execution and email recipient settings. There is (at most) one CP record for each Command + Generic + Function combination. Commands that aren’t generic-specific will not have a Generic value. Many records will not have a Function value either. An actual CP record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/CP/mn
review;;;__DEFAULT,annadm;__DEFAULT

Use the setrel command to create or update records in the CP relation. See the setrel documentation for details. Note that the Function (fcntype) in a CP record refers to a specific capability (such as “add” or “delete”) of the command being customized. It does not refer to the Function field of the setrel command itself.
When Sablime is first installed, the execution and email settings use their default values and there are no records in CP.

Generic-specific CP records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseCP Relation

CRIT Relation — Criteria

$ssql -help from CRIT
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   crtype    Criteria Type            7   subtype   Subtype
   2   crowner   Criteria Owner           8   sys       System
   3   g         Generic                  9   subsys    Subsystem
   4   class     Class                   10   mod       Module
   5   subclass  Subclass                11   site      Site
   6   type      Type                    12   rel       Rlse Detected

The CRIT Relation holds automatic assignment and automatic email routing criteria, enabling individuals to be notified when certain MRs get created and/or enabling certain MRs to be automatically assigned. There is (at most) one CRIT record for each Criteria Type + Owner combination. An actual CRIT record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/CRIT/ob
assign;guiteam;g13.2;software;;;;gui;;;;;

Use the setrel command to create or update records in the CRIT relation. See the setrel documentation for details. When Sablime is first installed, there are no CRIT records.

CRIT Relation records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseCRIT Relation

DEP Relation — Dependencies

$ssql -help from DEP
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   mr        Dependent MR             4   logical   Logical
   2   g         Generic                  5   physical  Physical
   3   dep       Depended-Upon MR         6   reason    Reason

The DEP Relation contains information about the MRs that have been made dependent on other MRs within a generic. Dependencies are used to ensure that changes that require other changes are kept together. There is one DEP record for each Dependent MR + Generic + Depended-Upon MR combination. An actual DEP record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/DEP/__g13.2/dd
mypr090076;g13.2;mypr090043;n;y;auto:line-level

DEP records may get created automatically by edput if your project is using automatic file-level or line-level dependencies. The initsab command establishes whether your project uses automatic dependencies, and if so, what type. This setting can be changed by using setrel.

DEP records may also get created manually using depend. See the depend documentation for details about why you might want to create a dependency manually.

The unedput command can cause DEP records to be removed, as can the source command (when a file that was involved in a dependency gets removed). Dependencies can also be removed manually using depend.

Field Description
Dependent MR Sget, getversion, or approve of this MR requires inclusion of the changes from the Depended-Upon MR.
Generic The generic in which the dependency applies.
Depended-Upon MR Sget, getversion, or approve of the Dependent MR requires inclusion of the changes from this MR.
Logical Logical dependencies are those created by using depend. This field will contain either “y” or “n”.
Physical Physical dependencies are the automatic dependencies created by edput. This field will contain either “y” or “n”. Note that a depencency might be both Logical and Physical. Physical dependencies will also have one or more records in the PDEP Relation.
Reason One or more of the following (comma separated):
Value Description
auto:INITfile-level Physical dependency: triggered by the edput of a file changed by both the Dependent and Depended-Upon MR. These will also have one or more entries in the PDEP Relation.
auto:file-level
auto:line-level
auto:SBCSfile-level
auto:SVCSfile-level
User-supplied text Logical dependency: Value from the Reason field of depend.

DEP Relation records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseDEP Relation

DG Relation — Directory/Generic

$ssql -help from DG
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   dir       Directory                3   chgdt     Latest Change           
   2   g         Generic

The DG Relation tracks the latest change made to any file in a directory within the generic. There is one DG record for each Directory + Generic combination where files exist. An actual DG record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/DG/__g13.2/hh
src/lib/widgets;g13.2;11/18/09 12:22:48

DG records get created automatically when the first file is added to a directory within a generic. The Latest Change date is set when a file is moved into or out of the directory (by source), and whenever the GS Latest Change field is set for some file in the directory and generic. If — after a file move or delete — no files remain in the directory for a generic, the DG record is removed.

Field Description
Directory The Directory and Generic to which this record applies.
Generic
Latest Change The date of the most recent change to any file in this Directory/Generic.

DG Relation records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseDG Relation

EMG Relation — External MR/Generic

$ssql -help from EMG
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   emgid     External ID              6   emgrdate  Commitment Date
   2   esg       Ext Generic              7   mtype     Message Type
   3   esprod    External Product         8   reason    Reason
   4   emgstat   External Status          9   tstamp    Time Stamp
   5   emgcomid  Commitment ID

The EMG Relation contains information about MRs of external products with which this Sablime instance is communicating. There is one EMG record for each External ID + Ext Generic + External Product combination. An actual EMG record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/EMS/cd
ext090023;ext2.3;ext;submitted;;;3;;11/17/09 15:02:23

EMG records are created and updated by the review command. See the External MR Documentation for more details.

Field Description
External ID The name of this MR within its External Product.
Ext Generic The generic in the Exteral Product that contains this Exernal ID.
External Status The status of this External ID within its Ext Generic.
Commitment Id The commitment ID (if any) established for this External ID within its Ext Generic.
Commitment Date The commitment date of the Commitment ID (if any) of this External ID within its Ext Generic.
Message Type The message type of the most recent message that updated this record.
Reason The review command will insert the user-supplied value of its Reason field.

EMG records get moved to the Inactive Database when the associated MR is closed or killed using closemr or killmr.

Return to: Top of PageActive DatabaseEMG Relation

EMR Relation — External MR

$ssql -help from EMR
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   mr        MR                      14   extsys    Ext System
   2   eproj     Ext Project             15   extsub    Ext Subsystem
   3   esprod    Ext Product             16   extrel    Ext Release
   4   esid      Ext ID                  17   extsite   Ext Site
   5   rte       Route                   18   extcat    Ext Category
   6   esnorg    Dialog Originator       19   extmod    Ext Module
   7   estat     Ext Status              20   extpd     Ext Phase Det
   8   reason    Reason                  21   emrudf1   EMR UDF1
   9   tstamp    Time Stamp              22   emrudf2   EMR UDF2
  10   extorg    Ext MR Org              23   emrudf3   EMR UDF3
  11   extodate  Ext Org Date            24   emrudf4   EMR UDF4
  12   extrdate  Ext Reqd Date           25   emrudf5   EMR UDF5
  13   extsev    Ext MR Severity         26   dummy     Dummy

The EMR Relation contains information about MRs that are shared with external products, including much of the MR Relation data from the external project. There is one EMR record for each MR + External Project + External Product combination for MRs being shared. An actual EMR record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/EMR/ma
mypr090101;sablime;ext;ext090023;out;joedev;open;;11/17/09 14:47:03;
ahndev;11/17/09;;3;data_coll;ui_scr;2.2;Cols;bug;;unit_test;;;;;;

EMR records get created by the qmr command when sending an MR to an external system, or by the review command when receiving an MR from an external system. See the External MR Documentation for more details.

Field Description
MR The name of the MR on this system.
Ext Project The external project type. Usually “sablime”.
Ext Product The name of the product the MR is being coordinated with.
Ext ID The name of the corresponding MR in the Ext Product.
Route Either “out” or “in” depending on whether this system or the Ext Product originated the MR.
Dialog Originator The user on this system who initiated the association between these MRs.
Ext Status The MR status of the Ext ID on the External Product.
Time Stamp The date and time of the most recent update to this record.
Reason The review command will insert the user-supplied value of its Reason field.

The remaining fields are the values from the corresponding fields of the MR Relation where the MR was created.

EMR records get moved to the Inactive Database when the associated MR is closed or killed using closemr or killmr.

Return to: Top of PageActive DatabaseEMR Relation

FTD Relation — Field Tracking Data

$ssql -help from FTD
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   prog      Command                  5   value     Values
   2   intkey    Internal Key             6   fvalue    Group/File
   3   flag      Flags                    7   hmi       HMI Attributes
   4   text      Text Fields              8   extkey    External Key

The FTD Relation contains information about the Sablime command fields and their presentation. It exists to allow customization of such things as the field labels, and whether or not a field value is mandatory. There is one record for each Sablime Program + Internal Key combination. An actual FTD record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/FTD/oa
create;sub;y,n,y;Product Subsystem:,,,2107;3,24,;;
11,17,_,0,left,Subsystem:,0,1;sub

FTD records get created by initsab when the product gets created, and can be customized using ftd. See the ftd documentation for details.

Field Description
Command The Command field from ftd.
Internal Key The Internal Key field from ftd.
Flags Three comma-separated “y” or “n” values, from the Display, Mandatory, and Hideable fields, respectively, of ftd.
Text Fields Four comma-separated values. The first is from the Command Line Help field of ftd. The fourth value is from the Verbose Help Key field. The second and third values are unused
Values Three comma-separated values from the Field Type, Length, and Default Value fields, respectively, of ftd.
Group/File The Group/File field from ftd.
HMI Attributes Eight comma-separated values from the following fields of ftd.
  1. Row Number
  2. Col Number
  3. Fill Character
  4. L/R Scroll Size
  5. Prompt Position
  6. Screen Label
  7. Attribute
  8. Popup Selections
External Key The External Key field from ftd.

Because FTD relation records are neither MR nor generic-specific, there is no FTD relation in the Inactive Database.

Return to: Top of PageActive DatabaseFTD Relation

FZ Relation — Files / Snapshot

$ssql -help from FZ
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   sfile     File                     4   snapid    Snapshot   
   2   dir       Directory                5   SID       Delta ID
   3   g         Generic

The FZ Relation holds information about the files that are used in snapshots. This information is used to maintain the integrity of the snapshots, by preventing files from being removed or changes being undone if they are part of an established snapshot. There is (at most) one FZ record for each File + Directory + Generic + Snapshot combination. An actual FZ record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/FZ/__g13.2/bh
config.c;src/lib/widgets;g13.2;load17;22.1.2.9

FZ records get created by getversion when a snapshot ID is specified for creation. Snapshots (and thus FZ records) can be removed using the snapedit command.

Field Description
File The name of a file included in the snapshot.
Directory The location of that file in the generic’s directory structure.
Generic The generic to which the snapshot applies (that is, the generic where the getversion operation that created the snapshot was performed).
Snapshot The name given to the snapshot by the user during execution of getversion.
Delta ID The SCCS delta ID of the latest MR-branch delta used in the snapshot. This could be empty if no MR-branch deltas are used.

FZ Relation records get removed when the associated generic is closed using closegen. There is no FZ relation in the Inactive DB.

Return to: Top of PageActive DatabaseFZ Relation

G Relation — Generics

$ssql -help from G
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   g         Generic                  9   gcrdate   Creation Date
   2   gstat     Status                  10   gcrid     Creator
   3   gsid      Generic SID             11   gcldate   Closemr Date
   4   ga        Generic Admin           12   gclid     Closer
   5   gdoc      Obsolete                13   rflag     Released Flag
   6   gfirm     Obsolete                14   srccnt    For Future Use
   7   ghard     Obsolete                15   relgen    For Future Use
   8   gsoft     Obsolete                16   nodes     Auto-Update Nodes

The G Relation holds information about the generics within the current product. There is one G record for each Generic. An actual G record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/G/nk
g13.2;active;22.1;ga_g13;;;;;11/28/08 15:35:19;annadm;;;n;;;

G records get created by initsab or newgen when the generic is created. G records get modified by mvgen or modgen.

Field Description
Generic The name of the generic.
Status “active” for any non-closed generic. If the generic were closed, it would be in the Inactive Database.
Generic SID The Generic’s SCCS Identifier. This will be “n.1” where “n” is a sequential numbering of the generics in this product. The Generic SID serves as the first two components of the SCCS Delta ID of all file changes in this generic.
Generic Admin The group containing the names of the users permitted to do generic administration (e.g., to assign, or testassign MRs).

Fields 9 through 12 specify when and by whom the generic was created or closed. If the generic were closed, this record would be in the Inactive Database. Fields 5 through 8, and 13 through 15 are unused.

Auto-Update Nodes If there are automatically-updated nodes configured for this generic, they will be listed in this field.

G Relation records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseG Relation

GRP Relation — Groups

$ssql -help from GRP
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   grpname   Group                    4   crdate    Creation Date
   2   owner     Owner                    5   chgdt     Latest Change             
   3   grptype   Type

The GRP Relation holds basic information about the Sablime groups defined in this product. There is one GRP record for each group. The contents of a group are retrieved from the GRPM Relation. An actual GRP record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/GRP/hh
ga_g13;;ptsid;06/24/10 20:00:09;01/19/11 14:31:01

GRP records get created, modified, or removed by setgroup. The fields of a GRP record are populated from the corresponding fields of setgroup. Refer to the setgroup documentation for details.

Field Description
Group The name of the group.
Owner The user declared to be the owner of the group. Often empty.
Type Either “mr” for groups of MR names; “ptsid” for groups of Users; or “other” for everything else.
Creation Date The date and time at which the group was first created.
Latest Change The data and time at which the contents or any of the above attributes were most recently changed.

Because GRP relation records are neither MR nor generic-specific, there is no GRP relation in the Inactive Database.

Return to: Top of PageActive DatabaseGRP Relation

GRPM Relation — Group Members

$ssql -help from GRPM
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   grpname   Group                    2   item      Member

The GRPM Relation can be queried to return the members of a group. There is one GRPM record for each member of each group. Contrary to what you might expect, the GRPM data is not stored in $sabGDB/../adb/$sabPROD/GRPM. The Group Members are actually stored in a separate file for each group:

$cat $sabGDB/../adb/$sabPROD/GROUPS/ptsid/ga_g13
annadm
joedev

GRPM data gets created, modified, or removed by setgroup. Each Member is one item (i.e. one line) from the group’s contents. Refer to the setgroup documentation for details.

Because GRPM relation records are neither MR nor generic-specific, there is no GRPM relation in the Inactive Database.

Return to: Top of PageActive DatabaseGRPM Relation

GS Relation — Generics / Source

$ssql -help from GS
  (%)  Keyword   Description             (%)  Keyword    Description
  ---  -------   --------------------    ---  -------    --------------------
   1   sfile     File                    10   kx         Expand Keywords
   2   dir       Directory               11   owner      Owner
   3   g         Generic                 12   verctl     Version Ctrl Tool
   4   sdir      SDB Directory           13   lastofcsid Last Official SID
   5   gschg     Latest Change           14   dsn        Delta Serial Number
   6   gsstat    GS Status               15   rmr        Reserved MR
   7   common    Common Generic          16   cocnt      Checkout Count
   8   bfile     Binary File             17   lsid       Last SID
   9   fltype    File Type               18   lmr        Last MR

The GS Relation holds information about the files that have been added to a generic. There is one GS record for each File + Directory + Generic combination. An actual GS record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/GS/__g13.2/bh
config.c;src/lib/widgets;g13.2;src/lib/widgets;11/18/09 12:22:48;
free;;n;c;y;;SCCS;0;37;;0;4;mypr090076

GS records get created by addsrc or batch_addsrc when a file is added to a generic. GS records can get changed by edget, unedget, edput, unedput, common, uncommon, reserve, unreserve, approve, and source, and may get removed by the source.

Field Description
File The dir/file and generic to which this record applies.
Directory
Generic
SDB Directory Usually this is the same as the Directory field. However, if the file has been moved to a different location in this generic (but not in all generics where the file exists), the SDB Directory field will point to the location where the file was originally located, which will also be the location of the file’s archive in the Source Database.
Latest Change Date and time that the source file was last changed in this generic. Adding the file to the generic, or successfully running edput or unedput will cause this to be updated.
GS Status Usually “busy” or “free”, indicating whether or not there are existing check-outs of the file. Gets set to “locked-busy” or “locked-free” temporarilly if source is being used to update the file record.
Common Generic Generics (space separated) where the file is common. When used, it includes the current generic.
Sometimes, it includes only the current generic, indicating that the file was once common with other generics, but uncommon was used to remove the others. Having only the current generic is the same as having none at all.
Binary File “y” or “n”. A binary file will be stored using SBCS (see the Version Control Tool field). A non-binary may be stored in either SCCS or SBCS.
File Type As set by addsrc or batch_addsrc when the file was added; or as later changed by source.
Expand Keywords
Owner
Version Ctrl Tool “SCCS”, “SBCS”, or “SVCS” as established by addsrc or batch_addsrc when the file was added.
Last Official SID The highest numbered delta on the “mr” branch (of this file in this generic) where the associated MR is now approved.
Delta Serial Number In an SCCS or SBCS maintained file, every delta has a sequence number indicating its overall sequential position, regardless of branch or generic. This field holds the sequence number of the latest change to this file in this generic.
For an SVCS maintained file, this field holds the hash key - an unique idenitifier of the latest version of the file in this generic.
Reserved MR If the file is currently checked out in reserved mode, the MR that holds the checkout.
Checkout Count The number of currently open check-outs of this file. “0” if GS Status is “free”.
Last SID The highest numbered delta on the “mr” branch for this file in this generic (i.e. the most recent change).
Last MR The MR responsible for the most recent change to this file in this generic.

GS records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseGS Relation

GT Relation — Generics / Test

$ssql -help from GT
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   g         Generic                  7   tt5       Test Team 5
   2   class     Class                    8   at        Approval Team
   3   tt1       Test Team 1              9   mt        Manufacturing Team
   4   tt2       Test Team 2             10   qat       QA Team
   5   tt3       Test Team 3             11   status    Status
   6   tt4       Test Team 4             

The GT Relation holds information about the Sablime groups that store the names of users permitted to advance MRs into (or reject MRs out of) the associated test state. It also records whether or not the particular MR class is enabled. There is (at most) one GT record for each Generic + Class combination. An actual GT record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/GT/nk
g13.2;software;spit_g13;;spst_g13;sst_g13;spat_g13;sat;;;enabled

GT records get created by initsab or newgen when the generic is created. GT records get modified by mvgen or modgen.

Field Description
Generic The generic and MR class to which this record applies.
Class
Test Team 1 The test team names (PTS ID group names) for the five optional test states, and for the approved state for this Generic + Class. If an optional test state does not have a test team, then that state is not used in that generic. The approval team is mandatory.
Test Team 2
Test Team 3
Test Team 4
Test Team 5
Approval Team
Manufacturing Team The Manufacturing Team and the QA Team field values are no longer used.
QA Team
Status “enabled” or “disabled”. At least one Class must be enabled in each generic.

GT records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseGT Relation

MC Relation — MR / Checkouts

$ssql -help from MC
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   mr        MR                       5   dev       Developer
   2   g         Generic                  6   sid       Checked-out Delta ID
   3   sfile     File                     7   mcstat    Status
   4   dir       Directory                8   mcchg     Latest Change

The MC Relation holds information about files that are currently checked-out. There is one MC record for each MR + Generic + File + Directory + Developer combination of an existing checkout. An actual MC record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/MC/__g13.2/dd
mypr090076;g13.2;config.c;src/lib/widgets;joedev;10;11/18/09 13:01:05

MC records get created by edget when the file gets checked out. MC records get removed when the checkout is edput or unedget.

Field Description
MR Designates the checkout to which this record applies.
Generic
File
Directory
Developer
Checked-Out Delta ID The Delta ID of the version that was checked-out. This is the fourth component of the full SCCS ID (SID). The MD relation uses the full SID.
MC Status Either “reserved” or “unreserved”
Latest Change The date and time of the checkout. Is also updated by edput when it sets up a merge of unreserved checkouts of this file.

Because MC relation records are associated only with non-closed MRs, there is no MC relation in the Inactive Database.

Return to: Top of PageActive DatabaseMC Relation

MD Relation — MR / Delta

$ssql -help from MD
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   mr        MR                       6   dev       Developer
   2   g         Generic                  7   mdflags   Flags
   3   sfile     File                     8   mdchg     Latest Change
   4   dir       Directory                9   psid      Parent Delta ID
   5   sid       Delta ID

The MD Relation holds information about the changes that have been applied to files. There is one MD record for each MR + Generic + File + Directory + Delta ID combination where a change was applied. An actual MD record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/MD/__g13.2/dd
mypr090076;g13.2;widget.c;src/lib/widgets;22.1.2.9;joedev;;12/28/08 14:57:01;

MD records get created by addsrc, edput, or approve. MD records get removed by unedput or source as they remove specific deltas or files.

Field Description
MR Designates the delta to which this record applies.
Note that the Delta ID in the MD relation is the full, four-component SCCS ID.
Generic
File
Directory
Delta ID
Developer The user who applied the change.
Flags A value of “n” indicates that the checked-in version of this file does not end in a newline.
Latest Change The date and time of the delta.
Parent Delta ID The short Delta ID (fourth component of the SCCS ID) of the delta that was checked out for this change. This is left empty if the checked-out delta was the immediate predecessor of the checked-in delta. A non-empty value indicates that a merge operation was necessary to produce this record’s delta.

MD records get moved to the Inactive Database when the associated MR is closed using closemr.

Return to: Top of PageActive DatabaseMD Relation

MG Relation — MR / Generic

$ssql -help from MG
  (%) Keyword    Description             (%)  Keyword   Description
  --- -------    --------------------    ---  -------   --------------------
  1   mr         MR                      39   ancdt     Activate Date (Nocha  
  2   g          Generic                 40   defdt     Defer Date
  3   mrgstat    Gen State               41   adefdt    Activate Date (Defer)  
  4   chgdate    Latest Change           42   stdydt    Gen Study Date      
  5   dev        Developer               43   propdt    Gen Propose Date  
  6   sev        Gen Severity            44   accptdt   Accept Date
  7   due        Due Date                45   assgndt   Assign Date
  8   rcode      Gen Reason Code         46   submtdt   Submit Date
  9   reason     Defer/Nochange Reason   47   tstdt1    Testpass 1 Date
 10   mgstcd     State Code              48   tstdt2    Testpass 2 Date
 11   class      Class                   49   tstdt3    Testpass 3 Date
 12   type       Type                    50   tstdt4    Testpass 4 Date
 13   spawns     Gen Spawns              51   tstdt5    Testpass 5 Date
 14   mgcomid    Commitment ID           52   apprdt    Approve Date
 15   mrgeflag   External MR Flag        53   flttype   Fault Type
 16   activity   Gen Activity            54   ndc       Non-Det Cause   
 17   pdi        PDI Number              55   ndcs      Non-Det Cause Subcat 
 18   subclass   Subclass                56   cost      Cost of Problem
 19   subtype    Subtype                 57   dupmr     Duplicate Nochanged   
 20   rel        Rlse Introduced         58   dummy1    For Future Use
 21   pi         Phase Introduced        59   dummy2    For Future Use
 22   odp        Optimal Det Phase       60   dummy3    For Future Use
 23   rootc      Root Cause              61   tester1   Level 1 Tester
 24   rootsubc   Root Cause Subcat       62   tester2   Level 2 Tester  
 25   acteff     Gen Effort              63   tester3   Level 3 Tester  
 26   esteff     Est Gen Effort          64   tester4   Level 4 Tester  
 27   tte1       Team 1 Effort           65   tester5   Level 5 Tester  
 28   tte2       Team 2 Effort           66   tasdt1    Testassign 1 Date  
 29   tte3       Team 3 Effort           67   tasdt2    Testassign 2 Date  
 30   tte4       Team 4 Effort           68   tasdt3    Testassign 3 Date  
 31   tte5       Team 5 Effort           69   tasdt4    Testassign 4 Date  
 32   mrgudf1    Gen UDF1                70   tasdt5    Testassign 5 Date  
 33   mrgudf2    Gen UDF2                71   reso      Resolution
 34   mrgudf3    Gen UDF3                72   hist      History
 35   mrgudf4    Gen UDF4                73   reject    Reject Notes
 36   mrgudf5    Gen UDF5                74   solu      Gen Proposal
 37   studyeff   Gen Study Effort        75   spawnotes Spawn Notes
 38   ncdt       Nochange Date           76   testnotes Test Notes

The MG is easily the largest Sablime relation, and holds information about MRs within the generics. There is one MG record for each MR + Generic combination where an MR has been accepted. An actual MG record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/MG/__g13.2/fj
mypr090076;g13.2;assigned;11/23/09 15:05:01;joedev;3;;;;20;software;
modification;0;;;;;customer facing;usability;;;;;;;2.5;;;;;;;;;;;;;;;;;;
11/17/09 15:45:10;11/17/09 15:45:20;;;;;;;;;;;;;;;;suetst;;;;;
11/19/09 09:00:00;;;;;

MG records get created when the MR is accepted or fcreated into a generic. MG records get removed by unaccept, and get modified by many other commands as the MR is applied within the generic.

Notes on the tableThe table indicates which commands typically update MG relation fields. Many of the values can also be updated using the mrgedit command, and most by dbedit.

Date field values are retained even if the MR moves on to other states. The presence of a date in Nochange Date, for example, does not necessarilly indicate that the MR is currently “nochanged”.

The table assumes “software” Class, with as-delivered state names for the five optional test state names. The actual names are configurable and vary from Class to Class.

Field Description
MR Designates the MR and generic to which this record applies.
Generic
Gen State One of the following:
  • nochange
  • deferred
  • understudy
  • accepted
  • spawned
  • assigned
  • submitted
  • preitpassed
  • itpassed
  • prestpassed
  • stpassed
  • preapproved
  • approved
Latest Change Date and time of most recent Gen State change, or other record-changing event, such as one which changes the number of Spawns (field 13), or that sets or unsets the Gen Activity (field 16).
Developer The current assignee (User or User group) of the MR. This value is retained even as the MR moves beyond the “assigned” state.
Gen Severity Values as set by assign or fcreate. The accept or spawnmr commands may also set these if their Auto Assign capability is used.
Due Date may also be set by study, and is also used by defer to store the Activation Date.
Due Date
Gen Reason Code From the most recent execution of defer, submit, reject, or nochange, the Resolution Code (submit), Reject Code (reject), Defer Code (defer), or Nochange Code (nochange).
Defer/Nochange Reason The Reason from the most recent execution of defer or nochange.
State Code Internal Code for the Gen States:
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
Class Values as set by accept or fcreate.
Type
Gen Spawns The number of spawns of this MR in this generic (see spawnmr).
Commitment ID Value, if any, as established by the commit command.
External MR Flag “y” or “n”, indicating whether or not this MR is coordinated with an external MR. See the External MR Documentation for more details.
Gen Activity “y” or empty, with “y” indicating that this MR (in this generic) has existing checkouts, or checked-in changes.
Hardware PDI Number No longer used by the software.
Subclass Values as set by accept or fcreate.
SubType
Rlse Introduced Values as set by submit.
Phase Introduced
Optimal Det Phase
Root Cause
Root Cause Subcat
Gen Effort Value as set by submit or nochange. Note that submit increments the existing value, whereas nochange sets it without regard to any existing value.
Est Gen Effort Value as set by mrg_propose or assign.
Team 1 Effort Values as set by testpass.
Team 2 Effort
Team 3 Effort
Team 4 Effort
Team 5 Effort
Gen UDF1 Values as set by accept, assign, fcreate, submit, reject, or testpass.
Note that these are the User Defined Fields for within this Generic. There is a separate set of 5 User Defined Fields associated with the overall MR, independent of generic. Those values are stored in the MR Relation.
Gen UDF2
Gen UDF3
Gen UDF4
Gen UDF5
Gen Study Effort Value as set by mrg_propose.
Nochange Date The date and time the MR was most recently nochanged in this generic.
Activate Date (Nochange) The date and time the MR was most recently activated from the “nochanged” state (in this generic).
Defer Date The date and time the MR was most recently deferred in this generic.
Activate Date (Defer) The date and time the MR was most recently activated from the “deferred” state (in this generic).
Gen Study Date The date and time the MR was most recently assigned for study in this generic.
Gen Propose Date The date and time the MR was most recently proposed from the “understudy” state (in this generic).
Accept Date The date and time the MR was most recently accepted into this generic.
Assign Date The date and time the MR was most recently assigned, or when it was most recently rejected to the “assigned” state (in this generic).
Submit Date The date and time the MR was most recently submitted, or when it was most recently rejected to the “submitted” state (in this generic).
Testpass 1 Date The date and time the MR was most recently testpassed or rejected to the associated test state (in this generic).
Note that when testpass is used to promote an MR beyond the next configured state, the dates of the intervening configured states are also updated. The same is not true for reject, where only the target state date is updated.
Testpass 2 Date
Testpass 3 Date
Testpass 4 Date
Testpass 5 Date
Approve Date The date and time the MR was approved in this generic.
Fault Type Values as set by submit.
Non-Det Cause
Non-Det Cause Subcat
Cost Don’t know where this is supposed to come from.
Duplicate Nochanged The Duplicate MR field value as set by nochange.
Level 1 Tester Values as set by testassign.
Level 2 Tester
Level 3 Tester
Level 4 Tester
Level 5 Tester
Testassign 1 Date Date and time the MR was most recently testassigned for the associated state (in this generic).
Testassign 2 Date
Testassign 3 Date
Testassign 4 Date
Testassign 5 Date
Resolution

These last six items (fields 71 through 76) are not actual fields in the MG relation record. They can be queried by ssql by field name or field number, but the command actually retrieves the data from the associated text files stored under $sabGDB/../adb/$sabPROD/FILES or, in the case of History, by retrieving and reformatting data from the MRH Relation

History
Reject Notes
Gen Proposal
Spawn Notes
Test Notes

MG records get moved to the Inactive Database when the associated MR is closed using closemr.

Return to: Top of PageActive DatabaseMG Relation

MR Relation — MRs

$ssql -help from MR
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
  1   mr         MR                      12   cldate    Completion Date  
  2   cid        Creator                 13   clid      Closer
  3   stat       MR State                14   dummy       
  4   cat        Category                15   pd        Phase Detected      
  5   abst       Abstract                16   mrudf1    MR UDF1  
  6   rdate      Required Date           17   mrudf2    MR UDF2
  7   sev        MR Severity             18   mrudf3    MR UDF3
  8   spawns     Total Spawns            19   mrudf4    MR UDF4
  9   reason     Killmr Reason           20   mrudf5    MR UDF5
 10   rcode      Killmr Code             21   dupmr     Duplicate Killed MR
 11   crdate     Create Date             22   desc      Description

The MR Relation holds information about MRs, independent of their acceptance into generics. There is one MR record for each MR. An actual MR record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/MR/dd
mypr090076;joedev;active;internal_mod;Fix flaw in widget presentation;
;3;0;;;12/25/08 12:33:06;;;;unit_test;;;;;;;

MR records get created by create and fcreate. MR records may get updated by study, mra_propose, defer, activate, or spawnmr.

Field Description
MR The MR to which this record applies.
Creator The User who created or fcreated the MR.
MR State One of “created”, “active”, “mra_deferred”, or “mra_study”. “Active” indicates that the MR has been accepted into at least one generic.
Category Values as set by create or fcreate, or as modified by mredit.
Abstract
Required Date
MR Severity
Total Spawns Total number of spawns for this MR in all generics.
Killmr Reason Values as set by killmr. Should be empty in the Active Database.
Killmr Code
Create Date The date and time when the MR was created or fcreated.
Completion Date These are populated when the MR is closed or killed. These are empty in the Active database.
Closer
Phase Detected Values as set by create or fcreate, or as modified by mredit.
Note that these “UDF” fields are the User Defined Fields of MR independent of any generic. There is a separate set of 5 User Defined Fields associated with the MR within each generic where it may be accepted. Those values are stored in the MG Relation.
MR UDF1
MR UDF2
MR UDF3
MR UDF4
MR UDF5
Duplicate Killed MR Value (if any) as set by killmr. Should be empty in the Active Database.
Description This item is not an actual field in the MR relation record. It can be queried by ssql by field name or field number, but the command actually retrieves the data from the associated text file stored under $sabGDB/../adb/$sabPROD/FILES/description.

MR records get moved to the Inactive Database when the associated MR is closed or killed using closemr or killmr.

Return to: Top of PageActive DatabaseMR Relation

MRH Relation — MR History

$ssql -help from MRH
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
  1   mr         MR                       7   host      Command Host  
  2   when       Time Stamp               8   txt1      File/Assignee/Code
  3   g          Generic                  9   txt2      Dir/Severity/Level
  4   state      MR State/Dependency     10   txt3      Sid/Due/Mode      
  5   cmd        Command Used            11   txt4      Reason/Abstract
  6   user       Command User

The MRH Relation holds the history of MRs from creation through use within generics and any subsequent closure. There is one MRH record for each recorded event. An actual MRH record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/MRH/fj
mypr090076;1241613917.401258;g13.2;assigned;assign;devhost;annadm;joeuser;3;;

MRH records get created upon successful execution of most Sablime commands. Some commands will generate multiple history event records. For example, a depend operation setting an MR as dependent on two other MRs will generate an event record for each depended-upon MR. An fcreate operation will generate one event for the creation of the MR, and a separate event for assigning it to the user within a generic.

Field Description
MR The MR to which this record applies.
Time Stamp When the event happened. The value is the number of seconds since the “Unix epoch” (Jan 1, 1970), with fractional part in microseconds.
Generic If applicable, the generic in which the event occurred.
MR State/Dependency For most operations, this will be the resultant MR Status (see MR Relation) or MRG State (see MG Relation). For the depend operation, this will have either “depend” or “rmdepend” and the name of the depended-upon MR.
Command Used The command that triggerred the event.
Command User The user (PTS ID) that executed the command.
Command Host The host (machine name) where the command was executed.
File/Assignee/Code These fields store the major parameters associated with the operation being recorded. For the assign operation, for example, they store the assignee’s name, the assignment severity, and the due date. Different commands store different values. A complete guide to the contents of these fields will be released at a later date.
Dir/Severity/Level
Sid/Due/Mode
Reason/Abstract

MRH records get moved to the Inactive Database when the associated MR is closed or killed using closemr or killmr.

Return to: Top of PageActive DatabaseMRH Relation

MRS Relation — MR / Spawns

$ssql -help from MRS
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
  1   mr         MR                       3   mrs       Spawned MR  
  2   g          Generic    

The MRS Relation holds the names of spawned MRs. There is one MRS record for each MR + Generic + Spawned MR combination. An actual MRS record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/MRS/__g13.2/kb
mypr090071;g13.2;mypr090071.01

MRS records get created by spawnmr. Besides dbedit, commands do not update MRS records.

MRS records get moved to the Inactive Database when the associated MR is closed using closemr.

Return to: Top of PageActive DatabaseMRS Relation

MRX Relation — MR / Extra

$ssql -help from MRX
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   mr        MR                       6   mrxsev    MR Severity
   2   adate     Activate Date            7   mrxdue    Due Date
   3   rcode     Defer Code               8   mrxast    Study Time
   4   reason    Defer Reason             9   mrxee     MR Est Effort
   5   mrxdev    Study Dev               10   globsolu  MR Proposal

The MRX Relation holds information about MRs that were deferred and/or put under study prior to being accepted into a generic. There is one MRX record for each such MR. An actual MRX record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/MRX/ig
mypr090044;12/31/09;other;next release;joedev;3;;3.00;7

MRX records get created by defer or study, and get updated by the mra_propose.

Field Description
MR The MR to which this record applies.
Activate Date Values as set by defer. Note that Activate Date is a value entered when running defer. It is not the date when activate was executed.
Defer Reason
Defer Code
Study Dev Values as set by study.
MR Severity
Due Date
Study Time Values as set by mra_propose.
MR Est Effort
MR Proposal

The Proposal from mra_propose. This item is not an actual field in the MRX relation record. It can be queried by ssql by field name or field number, but the command actually retrieves the data from the associated text file stored under $sabGDB/../adb/$sabPROD/FILES/glob_solution.

MRX records get moved to the Inactive Database when the associated MR is closed or killed using closemr or killmr.

Return to: Top of PageActive DatabaseMRX Relation

MS Relation — MR / Source

$ssql -help from MS
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   mr        MR                       4   dir       Directory
   2   g         Generic                  5   msstat    Status
   3   sfile     File       

The MS Relation holds information about MRs that have touched files in a generic. There is one MS record for each such MR + Generic + File + Directory combination. An actual MS record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/MS/__g13.2/dd
mypr090076;g13.2;config.c;src/lib/widgets;unapproved

MS records get created by edput or addsrc, and may get updated by approve. There will only be one MS record even though the MR may make multiple changes. MS records may get removed by unedput if it undoes the only remaining change made to that file by that MR, or by source if it removes the file altogether.

Field Description
MR Designates the file change to which this record applies.
Generic
File
Directory
Status Either “unapproved” or “approved”, indicating the condition of the MR in this generic.

MS records get moved to the Inactive Database when the associated MR is closed using closemr.

Return to: Top of PageActive DatabaseMS Relation

ND Relation — Nodes

$ssql -help from ND
  (%)  Keyword    Description            (%)  Keyword     Description
  ---  -------    -------------------    ---  -------     --------------------
   1   node       Node                   17   umrs        Delta MRs
   2   g          Generic                18   incldep     Add Missing MRs
   3   status     Status                 19   purge       Purge MRs
   4   chgdt      Latest Change          20   dir         Directory             
   5   desc       Description            21   brdt        Cutoff Date           
   6   loc        Location               22   kx          Expand Keywords    
   7   owner      Owner                  23   ignore_exp  Ignore Diffs Matching
   8   updatemode Update Mode            24   rm          Overwrite        
   9   sync       Allow Sync             25   rm_extras   Remove Extras     
  10   overlay    Allow Overlay          26   mrs_used    Selection MRs Used  
  11   pstate     Promote To             27   umrs_used   Delta MRs Used  
  12   rtflds     Runtime Fields         28   upd_output  Update Output         
  13   snapid     Snapshot               29   ndfiles     Node Files            
  14   br         Branch                 30   kfiles      Files Not Updated     
  15   amrs       Allowed MRs            31   xfiles      Extra Files           
  16   mrs        Selection MRs

The ND Releation holds information about the managed nodes that have been configured for the product. There is one ND record for each Node + Generic combination. An actual ND record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/ND/__g1/bi
mynode;g1;configured;11/05/09 12:30:34;Submitted MR source;
/home/devsab/source/g1;;manual;y;n;preitpassed;purge,snapid;
;ofc;submitted+;submitted;;inumrs;y;;;y;;y;y

ND records get created by node_create, and may get updated by node_config, node_update, or testpass. ND records may get removed by node_delete.

Field Description
Node Designates the node to which this record applies.
Generic
Status One of “configured”, “updated”, or “promoted” depending on which of node_create/config, node_update, or testpass was last run against the node.
Latest Change Set by the most recent node_create/config, node_update, or testpass.
Description Values as set by node_create or node_config.
Location
Owner
Update Mode
Allow Sync
Allow Overlay
Promote To
Runtime Fields
Snapshot
Branch
Allowed MRs
Selection MRs
Delta MRs
Add Missing MRs
Purge MRs
Directory
Cutoff Date
Expand Keywords
Ignore Diffs Matching
Overwrite
Remove Extras

The next 6 items are not actual fields in the ND relation record. They can be queried by ssql by field name or field number, but the command actually retrieves the data from the associated text file stored under $sabGDB/../adb/$sabPROD/FILES/node_files/Generic/Node.

Selection MRs Used The MR sets used in the most recent update. May be more or fewer MRs than were specified, since MRs may have been included or purged based on dependencies. MRs will be marked “specified” or “added” depending on whether they were part of the specified set or were added to satisfy a dependency.
Delta MRs Used
Update Output The command output generated by the most recent node_update.
Node Files Lists the files updated (or found to be not in need of update) during the most recent node_update.
Files Not Updated Lists the files that would have been updated during the most recent node_update but were not: either because they were writable, or because Overwrite was set at “n”.
Extra Files Lists the files that were detected on the node, but were not associated with the most recent node_update.

ND records get moved to the Inactive Database when the associated generic is closed using closegen, except that the final 6 fields (which are really files associated with the most recent node_update) are not copied to the inactive database. They are removed.

Return to: Top of PageActive DatabaseND Relation

NH Relation — Node History

$ssql -help from NH
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   node      Node                     6   host      Command Host            
   2   when      Time Stamp               7   txt1      Field/Status            
   3   g         Generic                  8   txt2      Newval/pmrs             
   4   cmd       Command Used             9   txt3      Oldval/promoted/ofiles  
   5   user      Command User            10   txt4      Reason/xfiles

The NH Releation holds information about the events associated with managed nodes. There is one NH record for each Node + Time Stamp + Generic combination. An actual NH record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/NH/__g1/bi
mynode;1257464194.497265;g1;node_config;devsab;europa;rm_extras;y;n;

NH records get created by node_create, node_config, testpass, and node_delete.

Some commands may generate multiple history event records. For example, a node_config operation changing more than one value will generate an event record for each change.

Field Description
Node Designates the event to which this record applies.
Time Stamp
Generic
Command Used The command that triggerred the event.
Command User The user (PTS ID) that executed the command.
Command Host The host (machine name) where the command was executed.
Field/Status These fields store the major parameters associated with the operation being recorded. For the node_config operation, for example, they store the field being changed, the old value, and the new value. Different operations store different values. A complete guide to the contents of these fields will be released at a later date.
Newval/pmrs
Oldval/promoted/ofiles
Reason/xfiles

NH records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseNH Relation

NX Relation — Node Syncs

$ssql -help from NX
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   node      Node                     6   rmtdir    Remote Directory        
   2   g         Generic                  7   rmttool   Remote Tool             
   3   rmthost   Remote Host              8   toolarg1  Tool Arg 1              
   4   rmtlogin  Remote Logi              9   toolarg2  Tool Arg 2              
   5   date      Date

The NX Releation holds information about managed nodes that have been synchronized to a remote host. There is one NX record for each Node + Generic + Remote Host + Remote Login combination. An actual NX record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/NX/__g1/bi
mynode;g1;hawk.stc.lucent.com;devsab;11/05/09 16:14:46;
/home/devsab/syncg1;/tools/bin/rsync;rsh;

NX records get created or updated by node_sync.

Field Description
Node Designates the synchronization to which this record applies.
Generic
Remote Host
Remote Login
Date The date of the most recent execution of this sync.
Remote Directory Values as set by node_sync. (Tool Arg 1 is “Transport”).
Remote Tool
Tool Arg 1
Tool Arg 2 Unused

NX records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseNX Relation

ORG Relation — Originator

$ssql -help from ORG
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   mr        MR                       6   sub       Subsystem
   2   org       Originator               7   rel       Rlse Detected
   3   odate     Origination Date         8   site      Site
   4   prod      Product                  9   mod       Module
   5   sys       System

The ORG Relation holds additional information about each MR, intended to help pinpoint the issue. There is one ORG record for each MR. An actual ORG record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/ORG/dd
mypr090076;CalCustomer;11/17/09 15:45:01;mypr;client;ui;g13.1;OH;widgets

ORG records get created by create and fcreate. ORG records get moved to the Inactive DB when the associated MR is closed or killed using closemr or killmr.

All the field values in the ORG relation are as specified by the create or fcreate that created the record, or as modified by mredit or dbedit.

Return to: Top of PageActive DatabaseORG Relation

PDEP Relation — Physical Dependencies

$ssql -help from PDEP
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   mr        Dependent MR             5   dir       Directory
   2   g         Generic                  6   sid       Version Control ID
   3   dep       Depended-Upon MR         7   reason    Reason
   4   sfile     File

The PDEP Relation holds information about automatically created dependencies and the file changes that triggered them. There is one PDEP record for each such Dependent MR + Generic + Depended-Upon MR + File + Directory + Version Control ID combination. If a particular MR changes the same file more than once, it may result in multiple PDEP records (differing only in the Version Control ID field). An actual PDEP record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/PDEP/__g13.2/fj
mypr090076;g13.2;mypr090043;config.c;src/lib/widgets;22.1.2.9;auto:line-level

PDEP records get created by edput. PDEP records may get removed by unedput if it undoes the dependent change, by depend when instructed to remove the dependency, or by source if it removes the file altogether.

Any Dependent MR + Depended-Upon MR pair with one or more PDEP records will also have a record in the DEP Relation.

Field Description
Dependent MR Specifies the dependency and the file change that triggered it.
Note that the Version Control ID is the SCCS or SBCS ID of the change made by the Dependent MR.
Generic
Depended-Upon MR
File
Directory
Version Control ID
Reason One or more of the following (comma separated):
Value Description
auto:INITfile-level The Depended-Upon MR added the file to this generic.
auto:file-level The Depended-Upon MR changed the same file, and file-level dependency is in effect.
auto:line-level The Depended-Upon MR changed the same line(s) of the file, and line-level dependency is in effect.
auto:SBCSfile-level or auto:SVCSfile-level The Depended-Upon MR changed the same SBCS or SVCS file (SBCS and SVCS require file-level dependency).

PDEP records get moved to the Inactive Database when the associated MR is closed using closemr.

Return to: Top of PageActive DatabasePDEP Relation

PGR Relation — PTS Groups

$ssql -help from PGR
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   ptsid     User Name                2   grpname   Group 

The PGR Relation tracks individual User membership in groups. There is one PGR record for each User Name + Group combination. An actual PGR record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/PGR/fj
joeuser;mra_g3

PGR records get created, modified, or deleted by setgroup as it manipulates the groups themselves.

Because PGR relation records are neither MR nor generic-specific, there is no PGR relation in the Inactive Database.

Return to: Top of PageActive DatabasePGR Relation

SC Relation — Source / Checkouts

$ssql -help from SC
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   sfile     File                     4   mr        MR
   2   dir       Directory                5   dev       Developer
   3   g         Generic          

The SC Relation holds information about files that are currently checked-out. There is one SC record for each File + Directory + Generic + MR + Developer combination of an existing check-out. An actual SC record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/SC/__g13.2/bh
config.c;src/lib/widgets;g13.2;mypr090076;joedev

SC records get created by edget when the file gets checked out. SC records get removed when the checkout is edput or unedget.

Field Description
File Designates the checkout to which this record applies.
Directory
Generic
MR
Developer

Because SC relation records are associated only with non-closed MRs, there is no SC relation in the Inactive Database.

Return to: Top of PageActive DatabaseSC Relation

SD Relation — Source / Deltas

$ssql -help from SD
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   sfile     File                     4   sid       Delta ID
   2   dir       Directory                5   mr        MR
   3   g         Generic                  6   digest    Digest

The SD Relation holds information about files that have had changes (deltas) applied. There is one SD record for each File + Directory + Generic + Delta ID combination of a checked-in change. An actual SD record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/SD/__g13.2/bh
fconfig.c;src/lib/widgets;g13.2;46;mypr090076;2jmj7l5rSw0yVb/vlWAYkK/YBwk

SD records get created by edput or addsrc. SD records get removed if the change is unedput or by source if the file is removed altogether.

Field Description
File Designates the delta to which this record applies.
In the SD Relation, Delta ID is the fourth component of the SCCS ID (SID). The MD relation uses the full SID.
Directory
Generic
Delta ID
MR The MR holding the checkout.
Digest A hash value produced from the version of the file checked-in by this change. Sablime may use this to determine if an extracted version is correct and whether it has changed since this checkin.

SD records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseSD Relation

SNAP Relation — Snapshots

$ssql -help from SNAP
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   snapid    Snapshot                10   incldep   Add Missing MRs
   2   g         Generic                 11   purge     Purge MRs
   3   cid       Creator                 12   dir       Directory
   4   crdate    Creation Date           13   brdt      Cutoff Date
   5   comments  Comments                14   kx        Expand Keywords
   6   br        Branch                  15   files     List of Files
   7   amrs      Allowed MRs             16   gout      Getversion Output
   8   mrs       Selection MRs           17   vcmds     Command Script
   9   umrs      Delta MRs

The SNAP Relation holds information about Snapshots and the parameters used in their creation. There is one SNAP record for each Snapshot ID + Generic combination of a created shapshot. An actual SNAP record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/SNAP/__g13.2/fj
load17;g13.2;joedev;11/20/09 14:23:23;;;ofc;no;submitted+;;;;y

SNAP records get created by getversion when a New Snapshot ID is specified. The snapedit command can be used to change the Comments field, or to remove the snapshot altogether.

Field Description
Snapshot Designates the snapshot to which this record applies.
Generic
Creator The user (PTS ID) who executed getversion to create this snapshot.
Creation Date The date and time that the getversion was executed to create this snapshot.
Comments Values from getversion. Among these, only the Comments field is editable by the snapedit command.
Branch
Allowed MRs
Selection MRs
Delta MRs
Add Missing MRs
Purge MRs
Directory
Cutoff Date
Expand Keywords

These last three items (fields 15 through 17) are not actual fields in the SNAP relation record. They can be queried by ssql by field name or field number, but the command actually retrieves the data from the associated text files stored under $sabGDB/../adb/$sabPROD/FILES/snap_files, ../snap_gout, and ../snap_cmds.

List of Files A list of the directory/files belonging to the snapshot.
Getversion Output The output from the getversion that created the snapshot.
Command Script The series of commands needed to extract these specific versions of these files from SCCS and/or SBCS.

SNAP records get moved to the Inactive Database when the associated generic is closed using closegen.

Return to: Top of PageActive DatabaseSNAP Relation

UMS Relation — Unapproved MR Source

$ssql -help from UMS
  (%)  Keyword   Description             (%)  Keyword   Description
  ---  -------   --------------------    ---  -------   --------------------
   1   sfile     File                     3   g         Generic
   2   dir       Directory                4   mr        MR

The UMS Relation holds information about the files that have been changed by not-yet-approved MRs. There is one UMS record for each such Source File + Directory + Generic + MR Number combination. An actual UMS record might look like this:

$tail -1 $sabGDB/../adb/$sabPROD/UMS/__g13.2/bh
config.c;src/lib/widgets;g13.2;mypr090076

UMS records get created by edput or addsrc when they change a file in a generic. UMS records get removed by unedput if it removes the only remaining change by that MR to that file, or by source if it removes the file altogether. UMS records will also get removed when the MR is approved.

Because UMS relation records are associated only with non-closed MRs, there is no UMS relation in the Inactive Database.

Return to: Top of PageActive DatabaseUMS Relation

Inactive Database

The inactive database contains information about those product assets associated with killed or closed MRs and closed generics. The Inactive Database relation set is a sub-set of those from the Active Database because some Active Database relations are — by nature — associated only with open MRs (SC, for example, which tracks current check-outs), and other relations are not generic or MR specific (e.g. ADM).

Although the definitive location of the inactive database is stored in the PR relation (ssql idbdir from PR where pr.eq.$sabPROD), it is usually safe to find the Inactive Database based on the $sabGDB and $sabPROD environment variables that were established when you ran set_sablime:

$cd $sabGDB/../idb/$sabPROD
$ls
BH DBLOCK FILES GT MRH ND PDEP BLD DEP G MD MRS NH SD COM EMG GROUPS
MG MRX NX SNAP CP EMR GS MR MS ORG tmp CRIT

The Inactive Database contains the following relations. Click on the relation name to jump to details about the differences (if any) between this relation in the active and the inactive database.

Relation Name Description
BH Build History Information about events associated with builds from a closed generic.
BLD Build Information about the builds that were defined in a closed generics.
COM Commit Information about closed MRs where a committment date had been set.
CP Command Permissions Information about generic-specific special permissions and/or email recipient settings from closed generics.
CRIT Criteria Criteria settings for automatic assignment and/or email routing in closed generics.
DEP Dependency Information about closed MRs that were dependent on other MRs.
EMG External MR/G Information about closed or killed External MRs within their Generic.
EMR External MR Information about closed or killed MRs that were shared with an External project.
G Generic Configuration data and about each closed generic.
GS Generic/Source Information about which files had been added to the closed generics.
GT Generic/Test Information about the test teams (groups) used in each closed generic.
MD MR/Delta Information about closed MRs that had applied changes (deltas) to files.
MG MR/Generic Information about closed MRs that were accepted (or beyond) into generic(s).
MR MR Information about the closed or killed MRs in this product.
MRH MR History Information about the significant events related to each closed or killed MR.
MRS MR/Spawn Information about the closed MRs that had spawns created from them.
MRX MR/Extra Information about closed or killed MRs that had been put under study, or have been deferred (before being accepted).
MS MR/Source Information about which closed MRs have touched which files.
ND Nodes Information about the managed nodes that were defined in the closed generics.
NH Node History Information about significant events associated with managed nodes from the closed generic.
NX Node Syncs Information about node syncs of managed nodes that were defined in the closed generics.
ORG Originator Further information about each of the product’s closed or killed MRs (in particular, the Originator).
PDEP Physical Dependencies Information about MRs in closed generics that were dependent on other MRs due to having changed the same file(s).
SD Source/Delta Information about source files in closed generics that have had changes (deltas) applied.
SNAP Snap Information about the contents and creation parameters of each snapshot in the closed generics.

In addition to the relations, you can see some other items in the Inactive database:

Item Description
ATTACHMENTS Contains directories for storing attachments to the standard text files associated with closed or killed MRs. For generic-specific items (resolutions, for example), that directory contains a subdirectory for each generic where attachments exist. The attachment files themselves are stored in subdirectories named for the MR to which they are attached.
The first level subdirectories that may be present are:
  • description
  • resolution
  • testnotes
  • glob_solution
  • solution
  • rejection
  • spawnnotes
DBLOCK Contains directories matching the relations of the inactive database. Sablime puts a tuple file in one of these when it is busy updating the corresponding file in the Inactive Database. This tells other Sablime processes to wait a second or two before trying to do their own updates to that file.
FILES/builds A directory containing a sub-directory for each closed generic. These contain a further subdirectory for each build configured in that generic. The build-named directory contains the text files associated with the last 7 fields of the BLD relation.
FILES/description A directory containing the description file for each closed or killed MR.
FILES/glob_solution A directory containing the proposal text for each closed or killed MR that had been under study before being accepted into a generic.
FILES/mrcommit A directory containing a sub-directory for each generic. These contain a file for each committment ID, listing the closed MRs committed by that ID.
FILES/rejection A directory containing a sub-directory for each generic. These contain the rejection text for each closed MR that had been rejected in that generic.
FILES/resolution A directory containing a sub-directory for each generic. These contain the resolution text for each closed MR that had been submitted in that generic.
FILES/snap_cmds A directory containing a sub-directory for each generic. These contain a file for any “snapshot” that had been defined for closed generics. These files contain the version control commands needed to extract the particular version of each file used by that snapshot.
FILES/snap_gout A directory containing a sub-directory for each generic. These contain the output from any getversion that had created snapshots there.
FILES/solution A directory containing a sub-directory for each generic. These contain the solution text for each closed MR that had been under study in that generic.
FILES/spawnotes A directory containing a sub-directory for each generic. These contain the spawn notes text for each closed MR that had been spawned in that generic.
FILES/structure Contains a directory structure file for each generic listing the relative path of each directory.
FILES/testnotes A directory containing a sub-directory for each generic. These contain the test notes text for each closed MR that had been testpassed in that generic.
tmp Used by Sablime as temporary workspace when updating database files.

Return to: Top of PageActive DB

Inactive BH Relation — Build History

The Inactive BH Relation holds information events associated with the builds from a subsequently closed generic.

BH Relation records get moved from the Active Database when the associated generic is closed using closegen. The records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive BLD Relation — Builds

The Inactive BLD Relation holds information about builds configured in the subsequently closed generic.

BLD Relation records get moved from the Active Database when the associated generic is closed using closegen. The records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive COM Relation — Committed MRs

The Inactive COM Relation holds information about closed MRs where a committment date had been set.

COM Relation records get moved from the Active Database when the associated generic is closed using closegen. The record is not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive CP Relation — Command Permissions

The Inactive CP Relation holds information about generic-specific special permissions and/or email recipient settings from closed generics.

CP Relation records get moved from the Active Database when the associated generic is closed using closegen. The records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive CRIT Relation — Criteria

The Inactive CRIT Relation holds criteria settings for automatic assignment and/or email routing from closed generics.

CRIT Relation records get moved from the Active Database when the associated generic is closed using closegen. The record is not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive DEP Relation — Dependencies

The Inactive DEP Relation holds information about closed MRs that were dependent on other MRs.

DEP Relation records get moved from the Active Database when the associated generic is closed using closegen. The DEP records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive DG Relation — Directory/Generic

The Inactive DG Relation holds information about the latest change to any file in the directory of this closed generic.

DG Relation records get moved from the Active Database when the associated generic is closed using closegen. The DG records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive EMG Relation — External MR/Generic

The Inactive EMG Relation holds information about External MRs associated with killed or closed local MRs.

EMG records get moved from the Active Database when the associated local MR is closed or killed using closemr or killmr. The EMG records are not otherwise modified.

Return to: Top of PageInactive DB

Inactive EMR Relation — External MR

The Inactive EMR Relation holds information about closed or killed MRs that were shared with an External project.

EMR records get moved from the Active Database when the associated MR is closed or killed using closemr or killmr. The EMR records are not otherwise modified.

Return to: Top of PageInactive DB

Inactive G Relation — Generics

The Inactive G Relation holds configuration data and about each closed generic.

G records get moved from the Active Database when the associated generic is closed using closegen.

Closegen changes Status (field 2) of G records to “closed”, and populates the Close Date (field 11) and Closer (field 12) when moving G records to the Inactive Database.

Return to: Top of PageInactive DB

Inactive GS Relation — Generics / Source

The Inactive GS Relation holds information about which files had been added to the closed generics.

GS records get moved from the Active Database when the associated generic is closed using closegen.

The closegen command removes the generic being closed from Common (field 7) of all GS records before moving GS records to the Inactive Database.

Return to: Top of PageInactive DB

Inactive GT Relation — Generics / Test

The Inactive GT Relation holds information about the test teams (groups) used in each closed generic.

GT records get moved from the Active Database when the associated generic is closed using closegen. The records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive MD Relation — MR / Delta

The Inactive MD Relation holds information about closed MRs that had applied changes (deltas) to files.

MD records get moved from the Active Database when the associated MR is closed using closemr. The MD records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive MG Relation — MR / Generic

The Inactive MG Relation holds information about closed MRs that had been accepted into generic(s).

MG records get moved from the Active Database when the associated MR is closed using closemr.

Closemr command changes Gen State (field 3) to “closed” and updates Latest Change (field 4). It also changes State Code (field 10) to either “89” if the MR’s previous Gen State was “nochange”, or to “99” if the state was “approved”.

Return to: Top of PageInactive DB

Inactive MR Relation — MRs

The Inactive MR Relation holds information about the closed or killed MRs in this product.

MR records get moved from the Active Database when the associated MR is closed or killed using closemr or killmr.

Closemr changes MR State (field 3) of the MR record to “completed”, and populates Completion Date (field 12) and Closer (field 13) when moving MR records to the Inactive Database.

Killmr changes MR State to “killed”, populates Killmr Reason and Killmr Code (fields 9 and 10), and populates the Completion Date (field 12) and Closer (field 13) when moving MR records to the Inactive Database.

Return to: Top of PageInactive DB

Inactive MRH Relation — MR History

The Inactive MRH Relation holds information about the significant events related to each closed or killed MR.

MRH records get moved from the Active Database when the associated MR is closed or killed using closemr or killmr.

Closemr or killmr adds an appropriate History record for the closemr or killmr event. The MRH records are not otherwise modified.

Return to: Top of PageInactive DB

Inactive MRS Relation — MR / Spawns

The Inactive MRS Relation holds information about the closed MRs that had spawns created from them.

MRS records get moved from the Active Database when the associated MR is closed using closemr. The MRS records are not otherwise modified.

Return to: Top of PageInactive DB

Inactive MRX Relation — MR / Extra

The Inactive MRX Relation holds information about closed or killed MRs that had been put under study, or had been deferred (before being accepted).

MRX records get moved from the Active Database when the associated MR is closed or killed using closemr or killmr.The MRX records are not otherwise modified.

Return to: Top of PageInactive DB

Inactive MS Relation — MR / Source

The Inactive MS Relation holds information about which closed MRs have touched which files.

MS records get moved from the Active Database when the associated MR is closed using closemr. The MS records are not otherwise modified.

Return to: Top of PageInactive DB

Inactive ND Relation — Nodes

The Inactive ND Relation holds information about the nodes that were configured in closed generics.

ND records get moved from the Active Database when the associated generic is closed using closegen. The ND records are not otherwise modified except that the last 6 fields (which are really files associated with the most recent node_update) are not copied to the inactive database.

Return to: Top of PageInactive DB

Inactive NH Relation — Node History

The Inactive NH Relation holds information about significant events associated with managed nodes from the closed generics.

NH records get moved from the Active Database when the associated generic is closed using closegen. The NH records are not otherwise modified.

Return to: Top of PageInactive DB

Inactive NX Relation — Node Syncs

The Inactive NX Relation holds information about node syncs of the nodes that were configured in closed generics.

NX records get moved from the Active Database when the associated generic is closed using closegen. The NX records are not otherwise modified.

Return to: Top of PageInactive DB

Inactive ORG Relation — Originator

The Inactive ORG Relation further information about each of the product’s closed or killed MRs (in particular, the Originator).

ORG records get moved from the Active Database when the associated MR is closed or killed using closemr or killmr. The records are not otherwise modified.

Return to: Top of PageInactive DB

Inactive PDEP Relation — Physical Dependencies

The Inactive PDEP Relation holds information about MRs in closed generics that were dependent on other MRs due to having changed the same file(s).

PDEP Relation records get moved from the Active Database when the associated generic is closed using closegen. The PDEP records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive SD Relation — Source / Deltas

The Inactive SD Relation holds information about source files in closed generics that have had changes (deltas) applied.

SD records get moved from the Active Database when the associated generic is closed using closegen. The records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Inactive SNAP Relation — Snapshots

The Inactive SNAP Relation holds information about the contents and creation parameters of each snapshot in the closed generics.

SNAP records get moved from the Active Database when the associated generic is closed using closegen. The records are not otherwise modified by the closing.

Return to: Top of PageInactive DB

Source Database

The source database contains the Version Control Tool storage for each file that has been added to Sablime. These are specially structured files and/or subdirectories that contain the file’s actual contents, and knowledge of every change that’s been made to it since it was first added.

Although the definitive location of the source database is stored in the PR relation (ssql sdbdir from PR where pr.eq.$sabPROD), it is usually safe to find the Source Database based on the $sabGDB and $sabPROD environment variables that were established when you ran set_sablime:

$cd $sabGDB/../sdb/$sabPROD

Within the source database is the directory structure that your project has defined for its generics. This includes all generics, so even if you’ve removed a directory from a generic, the directory will still be present in the Source Database as long as it is still used in any other generic.

Sablime uses one of three Version Control Tools, depending on the characteristics of the file and on project and user preferences:

SCCS
Souce Code Control System — The default tool for non-binary files. Can not store binary files.
SBCS
Source and Binary Control System — The default tool for binary files. Can also be used for non-binary files.
SVCS
Separate Versions Control System — The default tool for binary files larger than 1.5 GigaBytes. Can also be used for other binary or non-binary files.

See the Usage Guide for more information on the usage of Version Control Tools.

For SCCS, the contents and change history of each file is stored in a file named “s.FILENAME”, where FILENAME is the name you defined for the file. This file will be in the directory defined for the file. For example, the contents and change history of the file src/lib/widgets/config.c would be found at src/lib/widgets/s.config.c under the root of the source database.

For SBCS, the contents and change history of each file is stored in a file named “s.FILENAME”, where FILENAME is the name you defined for the file. This file will be in the “,SBCS” subdirectory of the directory defined for the file. For example, the contents and change history of the file src/lib/widgets/config.c would be found at src/lib/widgets/,SBCS/s.config.c under the root of the source database.

SVCS, as its name implies, stores the separate versions into separate files. Each directory containing SVCS-stored files will have a “,SVCS” subdirectory which in turn will have both an “index” and a “versions” subdirectory. The index subdirectory contains “s.FILENAME” files having some meta-data about each version of the file. The versions subdirectory has a further subdirectory for each file, containing the actual versions referenced in the index/s.FILENAME file. Some of the files might actually be links (for the cases where the file didn't actually change between versions). This has no practical effect, other than saving disk space.

An SVCS “index” file contains version records of 6 fields each, like in this example:

$tail -1 $sabGDB/../sdb/$sabPROD/src/lib/widgets/,SVCS/index/s.config.c
1.1.2.1;01/03/13 09:53:50;devsab;p3n130000;25;EZop63YUkQ5bpsiL8NOMqTesG7Y
Field Description
Delta ID A four component ID formatted the same as the SCCS and SBCS delta IDs: the first two components are the generic ID, the third is the branch (1 for “ofc”, 2 for “mr”), and lastly the sequence number of this delta on that branch. Same as the Delta ID in the MD Relation record for this change.
Change Date The date and time of the change that created this version. Same as the Change Date in the MD Relation record for this change.
Developer The user (PTS ID) who applied the change that created this version.
Generic The generic in which the change was applied.
File Size The size of this version of the file, in bytes.
Hash Key A unique value for this version of the file, used to quickly determine whether the file has changed from version to version. The Delta Sequence Number field of the GS Relation contains the Hash Key of the most recent version of the file in this generic.

See the SCCS and SBCS documentation for details of their “s.” file format, and for information on the commands you can use to view or edit SCCS and SBCS files. (Note that the linked-to “SCCS” documentation is really “CSSC” documentation. CSSC is a clone of SCCS).

In addition to the “s.” file, there may also be a “p.” file in the Source Database directory for the file. The “p.” file is a lock file indicating that the corresponding file is currently checked out in “reserved” mode, and thus cannot be checked out reserved (or checked-in at all) by anyone else in the same generic.

Return to: Top of PageSource DB