[Previous Page ] [Main Documentation Page ] [Next Page]

As you no doubt will see, this table is not complete. The best way to get me to complete the information is to nag me with e-mails!  However, I see that this page is getting a lot of hits, and the understanding of the tables is vital to operating MidWatch as the UI is so weak, you will often have to edit data in these tables by hand.

Tables and Data Files

    1. The Scheduled Events Table

      • 3.1.1 ID
        AutoNumber: A unique primary key, used to separate event records.
      • 3.1.2 TimeOf
        Date/Time: The Date and Time the event is due to fire. The Scheduler will fire an event who’s TimeOf is less then or equal to now().
      • 3.1.3 Event
        Text: This denotes the type of event, valid values are "TIP" and "TLB". The Tip build will use the config spec in the PDR without (much) modification. The TLB or Target Label Build will
      • 3.1.4 Label
        Text: This is the name of the event as it appears on the right pane of the scheduler. It has no real effect on the build. This field will likely be removed during a code cleanup.
      • 3.1.5 ReOccurs
        Yes/No: Indicates that this event should be scheduled to re-occur after the event has been completed.
      • 3.1.6 Priority
        Number: Not used.
      • 3.1.7. ProductName
        Text: This is the product name that is being produced. This value must match the ProductName value of the Product Launch Record.
      • 3.1.8. ProductID
        Number: This matches the ProductID in the Product Launch Record
      • 3.1.9. Status
        Text: The status of the event, valid values are:
        P - Pending
        A - Active
        C - Closed
      • 3.1.10. StartedTime
        Date/Time: The date and time that the event last started. Currently this value is not read by anything. It is set by Engine
      • 3.1.11. EndedTime
        Date/Time: The date and time that the event last ended. Currently this value is not read by anything. It is set by Engine
      • 3.1.12. DelayUntil
        Date/Time: Not used.
      • 3.1.13. Sun,Mon,Tue,Wed,Thu,Fri,Sat
        Yes/No: Stores the days that the build should re-occur on
      • 3.1.14. IncrementBuild
      • Yes/No: If yes, causes the tbl_ProductLaunchRecords.LabelCounter to increment each build.
      • 3.1.15. DropLabel
        Yes/No: If yes, causes MidWatch to create a new label that is equal to tbl_ProductLaunchRecords.MajorLabel & tbl_ProductLaunchRecords.LabelCounter

    2. The Product Launch Records


      These fields are best edited using the dialog box described in 2.3.
      Now that we have open sourced MidWatch, and even for BMC Software's needs, an important modification will be for MidWatch to handle other SCMs besides ClearCase. The beginning of the Product Description is here in this table. No doubt a field will be added here that descibes which SCM the product uses. In fact I believe this would allow for a single instance of MidWatch to communitcate with several SCMs if your company is organized well enough to use multiple SCMs :)

      • 3.2.1. Product ID
        AutoNumber: Primary key of the table
      • 3.2.2. ProductName
        Text: This is the "name of the product" it is loaded into the scheduler product combo box. (2.2.5)
      • 3.2.3. PDRSCCPath
        Text: This defines the path of the .apd file. An example value would be \best1\build\AengelB\NTC.apd
      • 3.2.4. CZPath
        Text: This is the "mapped drive" that points to the CZ View. Actually, you must use the MS DOS subst command to get the drive to "map" to the view’s subdirectory. If this is now done prior to MidWatch’s build, then the build will not start, MidWatch will test for this path to be a Clearcase view, and will quit if the test fails. Note: that the subst command must be performed after each reboot.
      • 3.2.5. ConfigSpec
        Memo: This describes the config spec to be used for the build. It is best edited using the dialog box.
        A config spec is a ClearCase implementation detail, which describes the branch the product source is on. Since this is a memo field, it should be able to be re-used by other SCMs to describe branch information.
      • 3.2.6. DistDirectory
        Text: This is actually a sub directory under the DistributionRoot value described in the ini_table 3.7.4. The entire distribution path is made of concatenating the following values:
        • DistributionRoot (3.7.4)
        • DistDirectory (this value)
        • MSIDistribution= (3.3.15)
        • Build Number

      • 3.2.7. MajorLabel
        Text: This field and the addition of the Label Counter comprises the build label. For Example in the 6.3.00.0360 build, this value was "6.3.00"
      • 3.2.8. LabelCounter
        Text: This is the minor number of the build. Note that this number is incremented at build start. For the 6.3.00.0360, this field had the value of "359" prior to the build start.
      • 3.2.9. PlayThrough
        Yes/No: If set causes the build to ignore error and continue building. This is useful after a major merge of the product and many things are expected to break. Allows the Build Meister to detect all build errors so that correction efforts can be made in parallel.
      • 3.2.10. SignalBridge
        Text: Path to where the realtime HTML report should be written.
      • 3.2.11. SCM proposed
        This is not yet implemented, but will likely be added, example values will be "ClearCase", "CVS", "SourceSafe" etc.
        other fields may be needed for other SCMs.
      • 3.2.12. CZFullPath
        Added for version 0.1.42, this will describe the full physical path to the Construction Zone so that MidWatch may automatically test the state of the DOS subst command and run the subst command if needed. Sample value would be:
        "D:/Viewstore/midwatch_snap_view" . Note this dose not obsolete 3.2.4

    3. The .apd File

      (formerly known as the Aengel Product Definition file)
      My good friend and install expert, Dmitry Berkolayko pointed out that the whole .apd file is silly. I go throught all this stupid parsing of a quasi .ini file thing, when I already have the ablity to reduce Access tables to ASCII. Why not store the information in a table instead? DUH! Now that's the kind of benefit I expect from open source!
      Well, Dmitry is right. the .apd should be replaced, but right now it exists.

      • 3.3.1. MajorVer=, MinorVer=, RevVer=
        These fields define what the minimum version of MidWatch is to be used with this .apd file. From time to time new features are generated that require data to be stored in the .apd file. When new keys are added, these version numbers are upgraded to serve as a warning to older MidWatches that there are keys in this .adp file which they cannot read. It simply ensures that MidWatches are upgraded.
      • 3.3.2. ProjectListSCC=
        This is a semi-full path to the project list table in ASCII format. I call it semi-full as it does not contain a drive letter, but it is relative to the root of the ClearCase view. An Example value is \best1\build\AengelB\tbl_ProjectList.txt
      • 3.3.3. ProjectDepends=
        Same as ProjectListSCC= except that it refers to the dependancy table.
      • 3.3.4. SnapShot=
        I believe that this key is obsolete.
      • 3.3.5. ExtraVobs=
        Comma separated. This is perhaps the only string that is still currently separated by commas, and I will clean this up and standardize in the future.
      • 3.3.6. CleanVobs=
        Separation ???. This is a list of vobs in the view that MidWatch will remove all view private files from. It may even work for subdirectories, but this has not been tested. Aengel will perform this removal if the Clean Build button is set. Othwerwise it will not clean the vob.
      • 3.3.7. LibDir=
        This is the root directory that .lib files will be copied to by MidWatch.
      • 3.3.8. InstallType=
        This is for backwards compatiblity. The orignal install method used a combination of RPM and InstallShield 5.1 (This would be install type =0) The new MidWatches will still support this type of install. (Provided RPM and Install Shield asre loaded on the build machine.) If this key is absent, type 0 is assumed.
        Type 1 is for MSI generation.
      • 3.3.9. MSIRoot=
        The semi-full path to the root of the MSI package. This is a semi-colon seperated list. If there are several paths here, there will be several kits generated depending on the values of MSIDistribution (See below)
      • 3.3.10. MSIDB=
      • 3.3.11. MSITablesDir=
      • 3.3.12. MSIPreModifyTables=
      • 3.3.13. MSISubstStr=
      • 3.3.14. MSICopyTree=
      • 3.3.15. MSIDistribution=
      • 3.3.16. PostInstallCmd=
      • 3.3.17. Obsolete Keys
        • 3.3.17.1. RPMProductSpec=
        • 3.3.17.2. RPMScriptDir=
        • 3.3.17.3. ISScriptDir=

    4. The Project List Table

      • 3.4.1. ID
        AutoNumber: Primary key of the table
      • 3.4.2. ProjectName
        Text: Familiar name of the project, normally the same as the .dsp file name without the .dsp
      • 3.4.3. ProjectGroup
        Text: Not currently used, intended to group projects into components such as all GUI projects, All MiddleWare etc.
      • 3.4.4. BuildOrder
        Number: The order in which the projects will be built.
      • 3.4.5. Cmd
        Text: Tells MidWatch what to do with each record. Valid values are:
        • SOE : Stop on Error, compiles project as C++ and stops the build if the project returns errors greater than the ErrorLimit (3.4.11), unless PlayThrough (3.2.9) is set yes.
        • DBL : Double Build, used sometimes when you are building a large project that blows the heap. The first pass is a full re-buildall followed by a second pass of build what hasn't got built.
        • DOS : DOS Command, will run CmdLine (3.4.7) in DspPath (3.4.6)
        • IAE : Ignore All Errors, build C++ but don't stop for any errors. Depreciated after release 0.1.25.
      • 3.4.6. DspPath
        Text: semi-full path to .dsp file, that is the path from the root of the view. Such as
        \vobname\project\subproject\subproject.dsp
        The root of the view will be prepended by MidWatch.
      • 3.4.7. CmdLine
        Text: used when Cmd is equal to "DOS".
      • 3.4.8. InstallPath
        Text: Not used
      • 3.4.9. ReBaseAddress
        Not used in this MidWatch. It was used in the ASA MidWatch, could be, should be used here.
        Defines the address to rebase the project.
      • 3.4.10. ResponsibleEngineer
        Not Used
      • 3.4.11. ErrorLimit
        Number: The number of errors acceptable from this project (almost always should be set to 0)
      • 3.4.12. Config
        Text: A semicolon seperated list of the configurations to build for this project such as:
        Win32 Release Static;Win32 Unicode Release;Win32 Release

    5. Dependency Table

      • 3.5.1. ChildProject
        3.5.2. ParentProject

      • The Restart Table

      • 3.6.1. Event
        3.6.2. StopInstruction

    6. Ini_table


      Meaning of the Keys
      This table is basically a Key Value pair lookup for the program. Rather than describing the fields which should be easy to figure out, I will describe the important keys to this table and the effect they have on MidWatch. 

      • 3.7.1. InstallShieldRoot
      • 3.7.2. MSIDBPath
      • 3.7.3. WFWIPath
      • 3.7.4. DistributionRoot
      • 3.7.5. InspectionViewPath
      • 3.7.6. ProduceInstall
      • 3.7.7. WebRoot

    7. Changes since 0.1.41

      From time to time, changes will be required to the data base. This section will be a quick reference for changes you may have to make to keep your db current.

[Previous Page ] [Main Documentation Page ] [Next Page]