Review Status Files
Throughout the update scripts, several status files are produced. The status files are intended to maintain the updated status of a particular job. As a job is launched, if the status file does not exist, one is created. If one already exists, the script will read the status file and use the information within that particular job.
Status files created by the update.ifas script:
- status.<database name>.dbjob – This file contains information about the "Convert Database" option. The purpose of this file is to provide the update scripts information about where the update process is for a certain subsystem, and then provide that same information for the person running the update. The status file is simply a collection of flags for all the subsystems, and each flag represents a part of the update and is based on the job.initstat file.
- status.<database name>.adminjob – This file contains information about the "Load Global Settings" option.
job.initstat
When the initial update scripts are loaded, there is a file called "job.initstat" that contains information regarding all BusinessPlus schema updates for a release. An example of the "job.initstat" file is shown below.
#!/bin/ksh
#======================================================================
#3/11/2008 7:07:25 AM Last Generation Date
#======================================================================
SDB_SCHEME=0
SDB_SUBSYS=1
SDB_SSDB=2
SDB_DWDB=3
SDB_7IABLE=4
SDB_NEWTBL=5
SDB_ACTIVE=6
SDB_DBNAME=7
SDB_DBSPACE=8
SDB_UKEY=9
SDB_AMASTER=10
SDB_PID=11
SDB_STATUS=12
SDB_SKIPCHK=13
SDB_XSCHEMAOPT=14
SDB_TRIAD=15
set -A gSDBVals
set -A SDB_LIST \
"ardb:AR:N:N:Y:N:na:na:na:na:na:na:na:Y:-qa -nl -b:N" \
"fadb:FA:N:N:Y:N:na:na:na:na:na:na:na:Y:-qa -nl -b -nf:Y" \
"gldb:GL:N:N:Y:N:na:na:na:na:na:na:na:Y:-nl -b:N" \
"hrdb:HR:N:N:Y:N:na:na:na:na:na:na:na:Y:-qa -nl -b -nf:Y" \
"pedb:PE:N:N:Y:N:na:na:na:na:na:na:na:Y:-qa -nl -b:N" \
"pgdb:PG:N:N:Y:Y:na:na:na:na:na:na:na:Y:-qa -nl -b -nf:N" \
"podb:PO:N:N:Y:N:na:na:na:na:na:na:na:Y:-qa -nl -b:N" \
"prdb:PR:N:N:Y:Y:na:na:na:na:na:na:na:Y:-qa -nl -b -nf:N" \
"pydb:PY:N:N:Y:N:na:na:na:na:na:na:na:Y:-qa -nl -b:N" \
"rootdb:NU:N:N:Y:N:na:na:na:na:na:na:na:Y:-qa -nl -b:N" \
"sydb:SY:N:N:Y:Y:na:na:na:na:na:na:na:Y:-qa -nl -b:N" \
"wfdb:WF:N:N:Y:N:na:na:na:na:na:na:na:Y:-qa -nl -b:N" \
"wodb:WO:N:N:Y:N:na:na:na:na:na:na:na:Y:-qa -nl -b -nf:Y" \
"yedb:YE:N:N:Y:Y:na:na:na:na:na:na:na:Y:-qa -nl -b -nf:N" \
SDB_MAX=14
SAD_DBNAME=0
SAD_DBSPACE=1
SAD_PID=2
SAD_STATUS=3
set -A gSADVals
set -A SAD_LIST \
"na na na na" \
SAD_MAX=1
The job.initstat file contains variables that are used throughout the update.ifas scripts. SDB_LIST defines BusinessPlus schema subsystems being updated.
Output
As the update scripts are run, the job.initstat variables are read, and create and write to the "status" files. The "status" file that is produced by our example (SDB_LIST) is called "status.<database name>.dbjob" and looks similar to this:
ardb:N:N:Y:N:Y:modtst13:datadbs:N:N:3746:Done:Y:-qa -nl -b
fadb:N:N:Y:N:Y:modtst13:datadbs:N:N:3746:Done:Y:-qa -nl –b -nf
gldb:N:N:Y:N:Y:modtst13:datadbs:N:N:3746:Error:Y:-nl -b
hrdb:N:N:Y:N:Y:modtst13:datadbs:N:N:3746:Error:Y:-qa -nl -b -nf
pedb:N:N:Y:N:Y:modtst13:datadbs:N:N:3746:Error:Y:-qa -nl -b
The output looks similar to the job.initstat file, except the flags are filled in. Because the flags are not defined in the status file, it is necessary to reference the "job.initstat" file for this information. Each flag represents a portion of the string.
SDB_SCHEME=0 | Represents the schema that is being loaded. |
SDB_SUBSYS=1 | The two-character letters that represent each subsystem. |
SDB_SSDB=2 | Is this schema a student subsystem? |
SDB_DWDB=3 | Is this schema a DegreeWorks subsystem? |
SDB_7IABLE=4 | Is this schema 7i enabled? |
SDB_NEWTBL=5 | Is this a new schema to this release? |
SDB_ACTIVE=6 | Is this schema active on this account? |
SDB_DBNAME=7 | What is the database name of the account? |
SDB_DBSPACE=8 | What is the database space for the account? |
SDB_UKEY=9 | If a new schema file, build unique_keys? |
SDB_AMASTER=10 | If a new schema files, use automatic masters? |
SDB_PID=11 | What was the PID that ran this process? |
SDB_STATUS=12 | Did the update abort, fail, or complete? |
SDB_SKIPCHK=13 | Is the Check portion being skipped? |
SDB_XSCHEMAOPT=14 | What are the xschema options for this subsystem? |
SDB_TRIAD=15 | Is this schema file a TRIAD schema file? |
The first line in our example shows that the update scripts ran against an account that has the AR subsystem.
ardb:N:N:Y:N:Y:modtst13:datadbs:N:N:3746:Done:Y:-qa -nl -b
The flags represent the following:
ardb | Subsystem that is being updated. |
:AR | Two-character code for Accounts Receivable. |
:N | This is not a student subsystem. |
:N | This is not a DegreeWorks subsystem. |
:Y | This subsystem is 7i enabled. |
:N | This is not a new schema to the software. |
:Y | The subsystem exist in the account. |
:modtst13 | The database name of the account. |
:datadbs | The database space of the account. |
:N | Not a new schema file, ignore. |
:N | Not a new schema file, ignore. |
:3746 | PID that ran the update. |
:Done | Status of the subsystem. |
:Y | Skip the Check step of the update. |
:-qa –nl -b | Options used for xschema for AR subsystem. |
:N | Not a TRIAD schema file. |
Each subsystem in the status file will have these flags updated whether the subsystem is active on the account or not. The update scripts are written to reference the status file (on subsequent runs) and determine if the subsystem is active or not, based on what the update scripts find, and to skip the update on that subsystem if it has already been run or the subsystem is inactive. Though only the AR subsystem was used to explain what the status file represents, the same concept is used for all subsystems in that file.
The result is not something that is typically looked at when running the update. The contents of this file are created during the "CDB – Convert Database" step when it is run for the first time. If after running the "CDB - Convert Database" option, that option is selected again, the status file that exists on the system will be displayed. The output, through the scripts, will look similar to this:
**** Results for Convert Database ****
Job Summary for 7100
Working with Database: modtst13
Database Space: datadbs
Schema:ardb Status:Done
Schema:fadb Status:Error
Schema:gldb Status:Done
If there are errors in subsystems, the "Status:" will show "Error" and the errors will be displayed following the summary of updated subsystems.