Frequently Asked Questions

OPUS Observation Manager

OPUS Observation Manager (OMG)

What are observations?
This is a term we use for the datasets which are processed by the pipeline. They may, indeed, not be observations or exposures. They may be GIF files (as in the case of the sample pipeline). Or they may be archive requests or some other entity in the form of a dataset. The term "observation" is a heritage of the Hubble Space Telescope project.


What is the OMG?

The OMG is an Observation ManaGer, a Graphical User Interface (GUI) that allows the user to control the datasets being processed by a pipeline. The OMG controls and monitors what is happening in the pipeline through Observation Status Files (OSF). An example of an OMG display on a real pipeline looks like this:

Initial OMG Window

Do I need any software not provided on the OPUS CD to run the OMG?
The OMG is written as a Java application and consequently requires that Java 1.3 or 1.4 is installed on your system. Java is, of course, available without cost from Sun Microsystems, Inc.


How do I start the Observation Manager?
The installation package for the OPUS managers will allow you to install the Managers on Windows NT platforms, Linux and many Unix platforms.  For the Windows NT users, after installation you should see the OpusManagers on your Start/Programs menu:

OpusManagers on Start Menu

You can drag those icons to your Desktop (with the right mouse button) to put Shortcuts there:

OPUS Manager shortcuts

Double-click or select OMG from the OpusManagers Start Menu and first thing you should see is the OPUS splash screen, and then an OPUS Server login dialog:

Image of Server Dialog

The OPUS Managers are able to work over the network only if they have a valid connection with the OPUS CORBA server. That server needs to have been installed, and needs to be running for the OPUS Managers to have something to talk to.

You need to enter the proper node name where the server is running for the OPUS Managers to find that server.

If the servers are not running, a dialog will popup after you attempt to login telling you the manager could not find the servers:

Image of No Server Dialog

Click OK, start the servers, and start the Manager again.

Once you have entered the full node name of the server, you now are required to enter your name and password on that server so the OPUS Managers can log into that account and establish a connection.

Image of Password Dialog

Note: if you are using Unix, you can start up the OPUS Process Manager by entering:

  % ~/OMG
This is a link to the installed task which executes the Java OMG.


What's the password dialog for?
The OPUS Managers are able to work over the network only if they have a valid connection with the OPUS CORBA server.   That server needs to have been installed, and needs to be running for the OPUS Managers to have something to talk to. 

The name and password being requested may be different from your user name.  If you have multiple accounts, use the one which you want to have ownership of your pipelines.  Every different account logged into the OPUS Server will have its own independent services so there will be no conflicts.

At the bottom of the password dialog there is an option to "Enable SFTP for file transfer". By default, the OPUS Managers use FTP to initialize the connection with the CORBA server and verify the user. FTP is also used for remote file access while viewing items in the Managers such as log files and resource files. Because there exists a potential security risk with the use of traditional unencrypted FTP (eventhough the password is hidden from the display, and not logged in the log file), OPUS now supports the use of SFTP. Select this check-box to enable SFTP instead of FTP.


What happens after I am properly authorized?
If you are just starting out, and have not saved your environment from a previous session, you will see a blank OMG:

Note that nothing is displayed.  This is because no path has yet been selected.  Notice the message at the bottom of the screen.


How do I select a path?
As instructed, go to the File Menu and select the "Open Path" option:

Selecting a path

Move the cursor over the "Open Path" option and you will see the list of paths which are available to you.

Note that if the Managers do not find any path files in your OPUS_DEFINITIONS_DIR, you will be unable to do any processing.

Selecting a path

Select one (say bab5 in this case), and the Observation Status Files on that blackboard will be displayed.

  bab5 path selected

Ugly! How can I get rid of the dots?
If the width of a column is too small, then the values in that column cannot be displayed properly.  Java ends each field of text with an ellipsis (...) in that case.  To make the width of the column larger, position the cursor on the column divider, and drag that divider to enlarge the column; that gets rid of the ellipses.

  Column dividers
Note that you can also change the order of the columns in the display.  Just drag the column to a new position.  Even more!  You can completely remove an entire column from the display.  Right-click on the column to bring up the short column menu, and select "Hide".

hiding column

In this example the "dcf_num" column is removed.

  column hidden
...and yes, you can get the column back.  Just right-click on any column to get the column menu, and select "UnHide Last". Hidden columns are saved in a traditional stack, so you can unhide columns in exactly the reverse order that you hid them.

column returned

How can I subdivide a display field?
This is one of the useful features of the Java OPUS Managers: any field such as "dataset" can be broken into subfields for display purposes.  Assume for example the size of the dataset field as specified in the opus.env file is 24 characters where the first ten indicate the name of the dataset, and the last 14 indicate the beginning time. To break the dataset field into two others you need to put the following definition in your initialization file:
The timestamp field is a special case. It is automatically converted by both managers into a string of the form yyyy MM/dd HH:mm:ss with 19 characters. To subdivide that field you need to partition the 19 characters. We did this for the PMG, and subdivided the start_time field into its components: year, day, time.  The initialization file for the PMG contains the following line:
The line in the initialization file says to divide the 19 characters as 4 characters of "year", 6 characters of "day", and 9 characters of "time".  The names of the subfields are arbitrary, the only requirement is that the number of characters is exactly the size of the original field.  The sizes of each field are specified in the opus.env file.

Each user can have different definitions of the subfields.  When you select the SAVE option on the FILE menu, the preferences file is saved for each unique user in their preferences directory.


How do I save my preferences?
Each OPUS Manager has a File/Save option which will record your current settings: which path you selected, which columns you have hidden, which tabs you have defined.  The next time you start the Manager, this information will be read to configure your display.  This information is saved in your own initialization file with the name:
That file is saved in your user.home directory  known to the Java Virtual Machine, and depends on which platform you are running the Managers on.

Platform user.home
Windows 2000 C:\Documents and Settings\<username>\OPUSDATA
Windows NT C:\Winnt\Profiles\<username>\OPUSDATA
Windows 98 C:\Windows\OPUSDATA


Does the OMG support the OAPI?
Yes. The Java versions of the managers are designed to work with the new CORBA blackboards made possible by the OAPI for the current release.  The original observation status file structure is still the basis even for the Java OMG although, as you will see, you can modify the display of that structure.


What is an Observation Status File (OSF)?
An OSF is an Observation Status File, a file that is zero length (contains no data) in which all necessary control information about an observation is contained within the filename itself. Traditionally, OPUS has used these files to record state data for a pipeline. However, with the introduction of the OPUS Servers, these files only are a persistent copy of the state information stored in physical memory by the servers. Consequently, it is no longer possible (or safe) to directly manipate these files through the file system.

The OMG is sent data by the servers of the same type as are present in OSFs for each "observation" in the pipeline. These data are used to control and manipulate observations which are being processed by the OPUS pipeline, and to some extent can be modified by the user through the OMG.

The following information is contained in an OSF (the sizes of certain fields may be different in your pipelines):

|-- 1 -| |--------- 2 ----------| |---------------------------------- 3 -------------------------| |4| |5| | 6|

  1. TIME STAMP: The first component of the OSF is a time stamp expressed as a hexadecimal number (34070859). This is the time at which the observation first started in the pipeline. It is translated into a user-friendly ASCII time and displayed in the "time_stamp" field of the OMG display. You can use the time_stamp utility to make the same translation.

  3. STATUS: These letters indicate the status of the observation (cccccc, i.e., the first six steps in the pipeline are "complete"). Typically, one column is used for one process in the pipeline, although multiple processes can share a column. The order of the columns is defined in the pipeline.stage file, which also controls the two character mnemonics (OSF stage) used in the OMG title bar and the meanings associated with each status. Each process will set status fields for the observation based on whether the processing was successful or not. The standard is:
    "w": waiting for the process,
    "p": processing data,
    "c": successful completion,
    "e": unsuccessful completion,
    "n": not applicable,
    "x": process died.
    While these are the standard letters, any alphanumeric character permissible in a file name can be used in these fields. The actual characters used are specified in process resource files and their meanings are defined in the pipeline.stage file. The default size of this field is 24 characters, so this is the default maximum number of stages in a pipeline.

  5. DATASET: This field contains the name of the observation or dataset (gif9703). The OMG displays this in the "OBS" column. The default size of this field is 64 characters (changed from 23 in release 2.2), so this is the default maximum size of a dataset name.

  7. DATA ID: This field is called the datatype of the observation or dataset (GIF in this example). It is often used by processes to determine what kind of observation is coming down the pipeline, and whether that kind of observation is to be processed. The OMG displays this field in the "data_id" (class) column. The default size of this field is 3 characters.

  9. DCF NUMBER: This field contains an optional identifier of the observation (000). Called the Data Classification Field (DCF). The OMG allows the user to sort the display using this field. Consequently if there are meaningful attributes which can be used to classify the datasets, they can be set in this field. For example, one might use this field to specify the source of the dataset. The default size of this field is 3 characters. It is displayed in the "dcf_num" column of the OMG.

  11. COMMAND: This portion of the OSF is the command area (all underscores, or blank, in this example). This field provides the capability to SUSPend an observation. As an example, if it is known that a particular reference file is required by a calibration step for this one observation, this observation can be SUSPended in the pipeline before reaching calibration without affecting the processing of other observations. The OMG provides the capability both to SUSPend an observation and to RESUme it. The command is displayed in the "obs_cmd" column of the OMG.


Can I modify how an Observation Status File is structured?

You can configure the sizes, locations, and formatting of the fields in an OSF for your pipelines by changing the default parameters in the file opus.env located in OPUS_OBSERVATIONS_DIR. The portion of this file related to OSF's looks like:

! OSF definitions
! The size of each OSF field must be specified here as must a template for
! composing a string representation of the OSF out of each field. The OSF
! fields that distinguish one OSF from another also must be specified.
! The formatting and keyword names are self-explanatory although it should
! be noted that each field must appear in the template once and only once,
! there must be at least one field labeled as "UNIQUE", and the template
! format and field sizes should be consistent with the blackboard
! implementation to be utilized (ie., appropriate for file names if BB_TYPE =
! FILE).
OBS_STAT.SIZE       = 24
!DATASET.SIZE        = 23       VMS only
DATASET.SIZE        = 64
DATA_ID.SIZE        = 3
DCF_NUM.SIZE        = 3
OBS_CMD.SIZE        = 4
The comments above include the instructions for changing these parameters. The fields marked as "UNIQUE" are those used by the OPUS system to distinguish one OSF from another. This is important because duplicate OSF's are not allowed on the blackboard. It is not recommended that you change the unique fields although you are free to do so.

Before changing any of these parameters for a pipeline, be sure that there are no OSF's in your  paths, otherwise they will not be recognized as OSF's after you make the changes. In addition you should make sure that the OPUS CORBA servers are not running.

How do I create an OSF?
There is a utility included with the OPUS system called osf_create. This is used in the sample pipeline to start the processing, and can be used interactively or in any application. Typing the command with no arguments gives usage information:
% osf_create
   A path file must be specified (-p)
            osf_create -p pathfilename -f filename -t type 
                    -n number -c column -s status
            osf_create -p blue.path -f n32s1496 
                    -t nic -n 123 -c DP -s p 
   note: the path file must be in OPUS_DEFINITIONS_DIR
Note that the -c flag will default to the first column and multiple statuses can be specified:
          osf_create -p blue.path -f n32s1496
                   -t nic -n 123 -s ccw
This results in the creation of an Observation Status File on the OSF blackboard described in the OPUS_OBSERVATIONS_DIR entry of OPUS_DEFINITIONS_DIR:blue.path. The OSF is assigned specific DATASET (n32s1496), DATATYPE (nic), and DCF (123) fields.  The STATUS field of the OSF has the first column set to 'c', the second column set to 'c', the third column set to 'w', and all remaining columns set to '_'.


How do I update an OSF?
If you only want to change one of the STATUS columns, the easiest way is to use the interactive facilities of the OMG (Observation Manager), in particular the Modify menu selection items.

If you need to modify the STATUS field from a program or script, or if you want to modify the DCFNUM field, there is a utility included with the OPUS system called osf_update. It can be used interactively or in any application. Typing the command with no arguments gives usage information:

> osf_update

      A path file must be specified (-p)

         osf_update -p pathfilename -f filename [-t type]
                 [-n number] [-m new_dcf] [-x timestamp] [-c column] -s status

         osf_update -p blue.path -f n32s1496
                 -t nic -n 123 -c DP -s p

      note: the path file must be in OPUS_DEFINITIONS_DIR

Note that the -c flag will default to the first column in your PATH_pipeline.stage file, and multiple status values can be specified:

          osf_update -p blue.path -f n32s1496
                   -t nic -n 123 -s ccw
This results in an update to an existing OSF on the OSF blackboard described in the OPUS_OBSERVATIONS_DIR entry of OPUS_DEFINITIONS_DIR:blue.path. The OSF blackboard is searched for an OSF matching the DATASET (n32s1496), DATATYPE (nic), and DCF (123) values.  If found, the STATUS field of the OSF is modified such that the first column is set to 'c', the second column to 'c' and the third column to 'w'.  All other OSF status columns are unaffected.

How do I test for an Observation Status File?
There is a utility included with the OPUS system called osf_test. This can be used interactively or in any application. Typing the command with no arguments gives usage information:
   % osf_test

            osf_test -p pathfilename [-f filename] [-t type] [-x timestamp]
                    [-n number] [-c column] [-s status] [-m command]
                   [-pr time status dataset dataid dcfnum command COLUMN]
            osf_test -p blue.path -f n32s1496 -pr GC
    note: the path file must be in OPUS_DEFINITIONS_DIR
The utility provides a means of querying an OSF blackboard and printing information for selected OSFs.  The entire OSF can be printed or only certain OSF fields can be printed, using the pr option and a fixed set of OSF keywords.
For example, to query the KW column of a particular dataset running in the sample pipeline, use
   % osf_test -p g2f.path -f gif9506 -pr KW

To find the DATASET names for all OSFs that are in an error state in the KW stage, use
   % osf_test -p g2f.path -c KW -s e -pr dataset
This tool is useful in scripts when actions to be performed depend on the state of processing.

Can I display auxiliary files related to an OSF?

Yes. If your pipeline is designed such that there are dataset-specific text files generated, they may be viewed in the OMG via the "Dataset Log" option under the "View" menu, or by double-clicking the appropriate OSF listing in the OMG table.

In a simple pipeline design (such as the Sample Pipeline), there is likely to be a one-to-one correspondence between datasets and OSFs. Therefore, it is intuitive to try to obtain information on the status of a single dataset by double-clicking its OSF in the OMG. A common example would be if each pipeline process were to write output to a "dataset log" file for each dataset that it manipulates (in addition to whatever is written to the process log file). This is exactly how this is used in the Sample Pipeline.

Such a dataset log file would contain a view of the history of a single dataset. This is orthogonal to the way each process log (double-click a process in the PMG) contains a view of the history of a single process.

This feature can be used for any dataset-specific text file, it does not have to be a history log. It may be, in your pipeline design, that the resulting product from all processing on a dataset is such a text file !

The text files displayed are found via the rules for file-searches listed inside the OPUS_DEFINITIONS_DIR:dataset_views.dat file, which contains documentation describing its syntax.

How do I read the time stamp on an Observation Status File?
The value is a hexadecimal time stamp that is translated by the OMG into the format:
and displayed in the "Start Time" column of the display. Outside of the OMG, you can use the utility time_stamp to interpret these numbers. For example:
   %time_stamp 33DC9DC8
produces the response:
   date: 28-Jul-97 13:25:28


Can I monitor more than one pipeline or path at a time?

This is because the set of processing stages defined in the pipeline.stage files (usually) varies from path to path. However, you can monitor both pipelines simultaneously by running two copies of the OMG.


Can I stop a specific observation from processing further?

To do this, select the observation(s) with your mouse (this will highlight the selected line(s)) and then click on the "Suspend..." option under the "Manage" pull down menu.

OMG Manage Menu:  Suspend

Selecting the "Suspend..." will bring up a confirmation dialog:

Choosing "OK"  will update the corresponding OSFs with the string "halt" in the command section of the OSF.

The "halt" command will alert the processes polling for observations to skip the selected observation. The observation(s) can then be resumed by highlighting the pertinent observations in the OMG display, selecting "Resume..." from the "Manage" menu, and choosing "OK" in the confirmation dialog.

OMG Manage Menu:  Resume

Note that the Java managers do not actually  modify the Observation Status Files directly.  Instead a request is made of the CORBA server to do so.

While the Observation Status Files should accurately reflect the status of the blackboard, it should be remembered that the actual files constitute a backing store for the blackboard maintained by the server.

How do I tell if an observation has encountered a processing problem?
The OMG display will make this obvious. One or more characters in the status field for the problem observation will be highlighted in red and will either be an "e" indicating that there was a problem, or an "x" indicating that the problem was so severe that the process aborted. The actual status characters associated with processing problems are defined in the pipeline.stage file.


OMG Data Processing Error

Additionally, there is a count of the observations in each stage at the bottom of the OSF window.

If you see columns containing "e" or "x", but the counters don't seem to be registering them, there might be a missing status value in the default list.  That list is in the original OMG.ini which is in the .jar file, and has been preset to:


You might want to add status values to this list. To alter this list of values you need to save a similar line in your personal <username>OMG.ini file found in your preferences directory.  Anything you have in your personal <username>OMG.ini file will override the original defaults. OMG.ini is similar to the PMG.ini, and contains some defaults for configuring the OPUS managers.

Additionally, you might get information about what caused the problem by examining the process log file for the stage that failed.

Is there a way to determine the meaning of a status of an observation?
A short description of each status value for each stage is part of the definition of the pipeline.stage file. These descriptions are accessible in the OMG by clicking the header of the status column with the third mouse button; doing so brings up a menu which has a "Values" entry.  Sliding your mouse down to that entry displays the full interpretation of each status value for that particular column.

OMG Status value help screen

When you "hover" over a particular status column header, the cryptic two letter mnemonic for that stage will be interpreted in a standard Java tooltip.

OMG Status value help screen


How do I change the status of one or more observations?
There are two methods available for changing the status of observations. A quick way is just to click on a particular status cell for an observation.  This will first highlight (select) that observation, and second show a dropdown menu of the choices you have.

Modify a status value

By selecting any of the choices you will first be asked if the action is OK before the server is notified of the requested change. An alternate way is to first select the observation(s) with your mouse (your selected observations will now be highlighted in the OMG). Next, select the "Modify" option from the "Manage" pull down menu of the OMG.



This results in a single window displaying the current status values of the first OSF selected.  Any status modifications requested by using the dialog will be applied to all selected OSFs that have the same current status values as the first OSF selected.

This is considered safe because if you happen to pick up a few OSFs with your mouse selection that you did not intend to modify, they most likely will have different status entries than the first OSF selected and they will not be modified. A message will appear in the OMG log window indicating that the OSF was skipped if this happens.

Click on the button next to the column heading that you wish to change. A list of available column values will be displayed-- simply click on the desired value. Follow this procedure to modify as many columns as desired. Once you are finished, click on the "OK" button located at the bottom of the modify window. This will send a request to the server to make the desired changes to the OSF(s) and then the window will disappear.

The list of available column values for each pipeline stage is determined by entries in the pipeline.stage file.  If you want to modify a certain OSF column to a value that does not appear in the menu of possible selections, then the pipeline.stage file needs to be updated with this new value.

Can I change the frequency at which the display is updated?
No.  The old Motif managers operated in a "pull" mode and had to reread the entire directory of OSFs to have an accurate display of the state of things.  This was proven to be inefficient and was a major motivation for the "push" technology implemented with the current Java managers and the CORBA caching blackboard.  All modifications to the blackboard are automatically sent to the managers when they happen when operating in CORBA mode.  Since only changes are broadcast, network traffic is not significantly affected, and the updates are immediate.  However you can force an update by selecting the "Reload" option in the "View" menu of the OMG.

The default FILE mode still polls the entire blackboard at regular intervals, but the server does the polling instead of each manager.

OMG Reload

Can I filter the types of Observation Status Files that are displayed?
Yes, this capability is quite useful.  When the OMG is first displayed, you automatically are given a view of all OSFs on the selected blackboard.  However that is only one view of the blackboard, you can create your own views. Select the "New Tab..."  option from the "View" menu on the OMG.

New Tab

This brings up a dialog where you can select a "Panel name" (an arbitrary title of your choosing), a "Filter Column" (any one of the columns of the OSF), and the letter or beginning string which OSFs should "...start with".  For example you might want to have a view of the "stis" observations.  At STScI, these are observations for which the "dataset" starts with the letter "o".

New Tab Dialog

When you click on "OK", a new tab is created which contains only the selected observations.


Can I copy part of the OSF listing to the system clipboard?
Yes.  Use the Edit.Copy Selected pulldown menu option after selecting the OSFs you want to copy.  This menu option will place the selected OSF data on the system clipboard from which you can paste them into other clipboard-enabled applications.

Note that when you select a single OSF on the display, the name of the dataset is automatically copied to the system clipboard. This makes it easy to search for that dataset name in the process log file. Just 'paste' the name in the search dialog using the Ctrl-V accelerator key.

How do I change the colors used on the display?
You can't yet. Currently the Java managers use the default colors, and the "Metal" look and feel.


What controls the order of the observations in the OMG?
You control the order of observations in the OMG. When you "right click" on a column title, a short menu is displayed.  One of the selections on that menu is "Sort", and it will do just that.  If you want the sort to be descending rather than ascending (or vice-versa), just select "Sort" again: it is a toggle and will reverse its meaning each time it is selected.

The same behavior, but without the menu, can be obtained with a "left click" on the column title.


Is there any limit on the length of an observation "name"?
Yes. When the software is shipped, "Observations" in the OMG display are limited to a maximum of 64 characters. For example, the sample pipeline gets its observation names from the names of the files in the .../gif directory on the CD-ROM. Those files have names like:
The length of the filename root ranges between 7 and 9 characters. That's well below the 64-character maximum, so these conform to the OMG requirements for displaying observation names.  You can, however, change that maximum to conform with you own system requirements.
The size of the "dataset" column in the OMG is initially determined from the first observation to be displayed.  If other names are longer they will appear to be truncated, ending in an ellipsis (...).  Just resize the column to see the entire name.


What is the pipeline stage file?
The pipeline stage file determines the order in which the different stages of the pipeline are displayed in the OPUS Observation Manager (OMG) as well as the possible status values for each stage. It does NOT control the order of processing, however. The order of processing is controlled by the triggers in the individual process resource files.

Note that each path is associated with the pipeline stage file defined by its STAGE_FILE keyword or the default naming convention [path]_pipeline.stage (use of the latter requires that the file be located in OPUS_DEFINITIONS_DIR).
This is an example of the g2f_pipeline.stage file distributed with the sample pipeline:
! g2f_pipeline.stage
! Pipeline stage files define the title, description, and status values
! for each stage of a data processing pipeline. The number of stages is
! defined by the required key NSTAGE.
! Each stage entry begins with the class STAGEnn where nn is a number between
! 01 and 99 (the number must be formatted as two digits) that indicates where
! a stage falls in the processing order (the first stage is 01, the second 02,
! and so on). Valid subclasses include:
! .TITLE        (required) a two character title for the stage
! .DESCRIPTION  (required) a short description for the stage
! .PROCESSnn    (optional; nn : 01 to 99) a process name for that stage
! (NOTE: all values containing spaces must be enclosed in single quotes)
! In addition, the characters that indicate the status of a dataset with
! respect to each stage are defined in this file. There are four subclasses
! to which a status character can be assigned to:
! .CSTATUS.c    status indicates "complete" in this stage
! .TSTATUS.c    status indicates "trouble" in this stage
! .PSTATUS.c    status indicates "pending" in this stage
! .NSTATUS.c    status does not fall into any category
! where c is the status character. The value for each of these entries
! should be a short description of its meaning. For example,
! STAGE01.CSTATUS.P = 'Processing dataset'
! STAGE01.TSTATUS.E = 'Fatal error while processing dataset'
! STAGE01.NSTATUS.W = 'Waiting for processing'
! Status characters must be categorized consistently across all stages; if
! a character is assigned as a CSTATUS for one stage, that same character
! cannot be assigned to TSTATUS, PSTATUS, or NSTATUS in another stage.
 STAGE01.CSTATUS.C = 'GIF file recognition complete'
 STAGE01.TSTATUS.X = 'External process controller error'
 STAGE02.DESCRIPTION = 'Database select'
 STAGE02.NSTATUS.W = 'Waiting for keyword lookup'
 STAGE02.PSTATUS.P = 'Keyword lookup in progress'
 STAGE02.CSTATUS.C = 'Keyword lookup complete'
 STAGE02.TSTATUS.E = 'Error during keyword lookup'
 STAGE03.NSTATUS.W = 'Waiting for hold up'
 STAGE03.PSTATUS.P = 'Delaying processing for a while'
 STAGE03.CSTATUS.C = 'Hold up complete'
 STAGE03.TSTATUS.E = 'Error occurred during hold up'
 STAGE03.TSTATUS.X = 'External process controller error'
 STAGE04.NSTATUS.W = 'Waiting for conversion to FITS'
 STAGE04.PSTATUS.P = 'Conversion of GIF to FITS in progress'
 STAGE04.CSTATUS.C = 'Conversion to FITS file complete'
 STAGE04.TSTATUS.E = 'Error occurred during conversion'
 STAGE05.NSTATUS.W = 'Waiting for FITS header listing'
 STAGE05.PSTATUS.P = 'Generating FITS header listing'
 STAGE05.CSTATUS.C = 'FITS header listing complete'
 STAGE05.TSTATUS.E = 'Error occurred during FITS header listing'
 STAGE05.TSTATUS.X = 'External process controller error'
 STAGE06.DESCRIPTION = 'File Compression'
 STAGE06.NSTATUS.W = 'Waiting for file compression'
 STAGE06.PSTATUS.P = 'Compressing FITS file'
 STAGE06.CSTATUS.C = 'FITS file successfully compressed'
 STAGE06.TSTATUS.E = 'Error occurred during file compression'
 STAGE06.TSTATUS.X = 'External process controller error'

Top of OMG FAQ