EDPS PASS Products Data Receipt (PDR) Pipeline Reference Manual

Contents

PDR Pipeline Overview

The need for an PDR Pipeline

The PDR Pipeline is the Pipeline within the EDPS that is responsible for receiving and processing products from the HST Planning and Scheduling System (PASS). The products received include Mission Schedule files, Mission Timeline Report files, Science Mission Schedule files, Orbital Ephemeris files, and various PASS Auxiliary Data files. The type of processing performed on each product received is as follows: 
	Mission Schedule files - parsed to extract various obset and observation related information which is
	                         inserted into database relations that are used to determine and control
				 the specific processing that is performed by the EDPS FOF, FGS, and Astrometry
				 pipelines; renamed and submitted for archiving to the HST archive system; and moved to a holding
				 directory (PDR_HLD_DIR) to be held there until deemed 
				 to be no longer needed by operations personnel    

        Mission Timeline Report files - renamed and submitted for archiving to the HST archive system
	
	Science Mission Schedule files - renamed and submitted for archiving to the HST archive system
	
	Orbital Ephemeris files - used as input to produce FITS and ASCII files containing the ephemeris data
	                          and also renamed and submitted for archiving to the HST archive system

        PASS Auxiliary Data Files - copied to a holding directory (PDR_HLD_DIR) for use by operations personnel

Intended Audience and Scope

This Reference Manual is intended primarily to give OPUS Operations Personnel information needed to understand the operation of the EDPS PDR Pipeline. This includes information on the PDR Pipeline Input and Output products, the directories and files used, and the processes involved. Hopefully, as envisioned, this manual will be a dynamic document that is updated when PDR Pipeline changes are made.

PDR Pipeline Dependencies

The PDR pipeline is one of two EDPS pipelines that is not dependent upon other EDPS pipelines to function correctly; the EDPS Engineering Data Receipt (EDR) Pipeline being the other one. The PDR and EDR pipelines however are dependent upon systems outside of the EDPS. The PDR pipeline is dependent upon the HST Plannng and Scheduling System (PASS) to to provide notification that PASS products are available for processing and to provide the products themselves. Also, the PDR Pipeline and the OPUS EDPS in general for that matter are highly dependent upon database interaction; see PDR Pipeline Database Usage. In order for the PDR pipeline database interaction to occur correctly, the processes in the pipeline should be executed in a pipeline mode as opposed to an interactive mode. Typically, as specified by the OK_TO_UPDATE_DATABASE mnemonic in process resource files, processes that run in interactive mode are prohibited from performing database updates. Therefore, to ensure correct operation of the pipeline, !!! ALL PDR PIPELINE PROCESSES SHOULD BE RUN ONLY IN THE PIPELINE MODE !!!.

PDR Pipeline Nominal Operational Description

The PDR pipeline remains idle until it receives Transfer Notification files from the PASS System. These files indicate to the PDR pipeline which PASS products are available for transfer and processing. Once a transfer notification file is received, processes in the PDR pipeline will verify that all of the products listed in the notification file are present on disk; if any are missing, the notification file will be renamed to indicate an error. If all specified products are present, the PDR pipeline will determine if any OSF already exists for any of the specified products. If OSFs already exists, the OSFs will be marked as duplicate and the offending transfer notification file wil be renamed as a duplicate. If OSFs don't already exist for the products, they will be created for each product to trigger subsequent processing for the product and a record will be inserted into the database file_times relation to keep a historical record of the products received. All of the various products received from PASS are initially received by the PDR pipeline in a transfer directory, i.e., the PDR_PASS_DIR directory. Prior to processing the products, the products are copied to individual directories specific to each product type. During the copies, the products are renamed to make them recognizeable to downstream processes. The product specific directories used and the type of processing performed (as specified in the Overview section) on each product type is as follows: 
     PDR_MSC_DIR directory
	Mission Schedule files - parsed to extract various obset and observation related information which is
	                         inserted into database relations that are used to determine and control
				 the specific processing that is performed by the EDPS FOF, FGS, and Astrometry
				 pipelines; submitted for archiving to the HST archive system; and moved to a 
				 holding directory (PDR_HLD_DIR) to be held there until deemed 
				 to be no longer needed by operations personnel         
     
     PDR_MTL_DIR directory
        Mission Timeline Report files - submitted for archiving to the HST archive system

     PDR_SMS_DIR directory
        Science Mission Schedule files - submitted for archiving to the HST archive system

     PDR_ORB_DIR directory
        Orbital Ephemeris files - used as input to produce FITS and ASCII files containing the ephemeris data
	                          and then submitted along with the FITS and ASCII files for archiving to the HST
				  archive system

     PDR_HLD_DIR directory
        PASS Auxiliary Data Files - held in this holding directory for use by operations personnel
After the PASS products have been processed, the PDR pipeline starts is clean-up phase where it deletes no longer needed files and OSFs. The deletion of files is automatic however the deletion of OSFs requires manual intervention. The PDR pipeline process that deletes OSFs, i.e., the PDRDEL process residing in the (DL) stage of the pipeline is triggerred by the manual insertion of a 'd' in the (DL) stage of the pipeline for each class of OSF that is to be deleted.

PDR Pipeline Directories and Files

PDR Pipeline Processes

PDR Pipeline Processes Overview

The PDR Pipeline is composed of the following 16 processes:

  1. MSCCPY - polls the PDR_PASS_DIR directory for PASS Mission Schedule Product Transfer Notification Message files from the PASS system; creates 'msc' class OSFs for each file listed in the notification message files; and moves the files listed in the notification message files to the PDR_MSC_DIR directory. When the files are moved they are renamed.
  2. MTLCPY - polls the PDR_PASS_DIR directory for PASS Mission Timeline Report Transfer Notification Message files from the PASS system; creates 'mtl' class OSFs for each file listed in the notification message files; and moves the files listed in the notification message files to the PDR_MTL_DIR directory. When the files are moved they are renamed.
  3. SMSCPY - polls the PDR_PASS_DIR directory for PASS Science Mission Schedule Product Transfer Notification Message files from the PASS system; creates 'sms' class OSFs for each file listed in the notification message files; and moves the files listed in the notification message files to the PDR_SMS_DIR directory. When the files are moved they are renamed.
  4. ORBCPY - polls the PDR_PASS_DIR directory for PASS Orbital Ephemeris Product Transfer Notification Message files from the PASS system; creates 'orb' class OSFs for each file listed in the notification message files; and moves the files listed in the notification message files to the PDR_ORB_DIR directory. When the files are moved they are renamed.
  5. PASCPY - polls the PDR_PASS_DIR directory for PASS Auxiliary Data Transfer Notification Message files from the PASS system; creates 'pas' class OSFs for each file listed in the notification message files; and moves the files listed in the notification message files to the PDR_HLD_DIR directory.
  6. PDRORB - creates FITS and ASCII format Definitive Ephemeris Files using the data provided in the Orbital Ephemeris file received from the PASS system in the PDR_PASS_DIR directory.
  7. REPLAN - examines Mission Schedule pod files in the PDR_MSC_DIR directory to determine when Mission Schedule Re-plans occur and removes the information in the database that is being superceeded by the Re-plan.
  8. UPDATR - uses information provided in Mission Schedule pod files in the PDR_MSC_DIR directory to update Support Schedule information in various database relations
  9. MSCXTR - parses Mission Schedule pod files in the PDR_MSC_DIR directory to extract desired observation related information and populates various database tables with the information. The information is used by other EDPS pipelines; i.e., the FOF, FGS, and AST pipelines in the generation of their respective output products.
  10. CONTRL - uses Mission Schedule information contained in previuosly populated database relations to populate other relations that are used to dictate/control the specific processing performed by the EDPS FOF, FGS, and AST pipelines.
  11. NICSAA - uses Mission Schedule information contained in previuosly populated database relations to populate other relations containing information about NICMOS exposures and SAA dark associations, and NICMOS associations and SAA dark exposures.
  12. PDRREQ - generates request to archive various products received from the PASS System and the products produced by the PDR pipeline itself.
  13. PDRRSP - processes responses to archive requests.
  14. MSCMOV - moves Mission Schedule pod files from the PDR_MSC_DIR directory to the PDR_HLD_DIR directory to keep them around until operations personnel deems them no longer needed.
  15. PDRCLN - deletes mtl and sms class pod files from the PDR_MTL_DIR and PDR_SMS_DIR directories repsectively, and deletes orb pod files and orb FITS and ASCII products from the PDR_ORB_DIR directory.
  16. PDRDEL - deletes 'msc', 'mtl', 'sms', 'orb', and 'pas' class OSFs from the pipeline after their associated processing has completed.

PDR Pipeline Processes Details

MSCCPY Process details

MTLCPY Process details

SMSCPY Process details

ORBCPY Process details

PASCPY Process details

PDRORB Process details

REPLAN Process details

UPDATR Process details

MSCXTR Process details

CONTRL Process details

NICSAA Process details

PDRREQ Process details

PDRRSP Process details

MSCMOV Process details

PDRCLN Process details

PDRDEL Process details

PDR Pipeline Database usage

Database Relations Accessed

Database Querries Performed

Database Relations accessed

file_times Relation

     This relation is used to track the receival and processing of the various product files received from
     the PASS system.  The PDR Pipeline MSCCPY,  MTLCPY,
     SMSCPY, ORBCPY, PDRORB,
     REPLAN, UPDATR, MSCXTR,
     CONTRL, and NICSAA processes use this relation. 

       	Field name               type/size    description  
        ----------               ---------    -----------
	dataset_name             C23          file name of product file        

        archclass                C3           classification used to archive the data
	
        archdate                 C20          latest file date associated with the dataset          

        window_start             C13          Corrected spacecraft time for first minor frame in the file.
	                                      (UTC rounded to the nearest second, in the format YYYYDDDHHMMSS)         

        window_stop              C13          Corrected spacecraft time for first minor frame in the file.
	                                      (UTC rounded to the nearest second, in the format YYYYDDDHHMMSS) 
        tm_generated             C13          time file was generated at PASS

        pdb_version              C8           PDB tape ID number

        environment              C8           AEDP environment tape name

        replan_time              C13          Replan start time (UTC rounded to the nearest second, in the 
	                                      format YYYYDDDHHMMSS)

keyword_source Relation

 
     This relation specifies the source of keywords to be written to the FITS file produced by the 
     PDRORB process.  The source may be specified in three ways, from the PDB
     (Project Database), from the PMDB (Proposal management Database), or as a difference calculation.

     In the first case (PDB) the source of the keyword will be the name of a mnemonic as specified in the 
     EUDL.DAT file of the PDB.  The OPUS software will look up the location of that mnemonic in the yurintab 
     relation.  If it is desired to convert the value of the mnemonic to a string (discrete conversion) or to 
     engineering units (linear or polynomial conversion), then the second field (subsource) specifies the 8 
     character mnemonic of a conversion.  See the description of conv_discrete, conv_linear, and conv_polynomial.

     In the second case (PMDB) the source field is the name of a database relation in the PMDB.  The subsource 
     specifies the name of the field in that relation.  Only relations which can be joined with the relation 
     qolink on the basis of program_id, obset_id and ob_number can be used.  There is a special case of deep 
     relations like qesiparm.  In this case there is only a field for si_par_name and si_par_value,
     both of which are string fields.  To obtain a value from such a deep relation, specify the name of the 
     parameter in a form (usually uppercase) that will match the value in the database.

     Finally, for keywords which are simply differences between two already dredged keywords, only the names of 
     the subtrahend and minuend mnemonics are required for the source and subsource fields.

       	Field name           type/size	 description  
        ----------           ---------   -----------
        instrument           C3          instrument to which the keyword is associated:
                                         hsp, wfc, foc, fos, hrs, wfII, fgs, acs, nic, sti
        keyword              C8          name of keyword
        sourcetype           C8          which kind of source applies (PDB, PMDB, DELTA)          
        source               C30         source name: mnemonic, relation, subtrahend
        subsource            C30         specify: conversion mnemonic, fieldname or parameter name,
				         minuend mnemonic

cgg1_keyword Relation

 
     This relation provides keywords to be written to the FITS file produced by the PDRORB
     process.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        instrument           C3          instrument to which the keyword is associated:
                                         hsp, wfc, foc, fos, hrs, wfII, fgs, acs, nic, sti

        file_type            C3          generic file type.  values are:
                                           shp (standard header packet),
                                           udl (unique data log);
                                           dsk (digital sky), dst (digital star),
                                           ask (analog sky),  ast (analog star),
                                           asd (area scan/digital), asa (area scan/analog);
                                           ext (extracted data), sci (science data);
                                           shl (science header line), stl (science trailer line);
                                           img (image)

        order_index          I4          an index defining the keyword order in the relation;
                                         it is used to order the appearance of keywords in the header
					 file to which it will be written 

        fixed_index          I4          this item should be thought of as a map of a fixed index
                                         for a keyword into a value in the sequence 1,2,...,n.  the
                                         fixed index is used to indicate a particular keyword

        keyword_str          C8          keyword character string

        keyword_typ          C3          data type of the keyword value

        keyword_val          C20         keyword value

        comment_str          C72         comment character string

        cnv_flag             C1          flag stating whether to automatically convert keyword

        optional             C1          indicates whether this keyword is an optional one. If an 
	                                 optional keyword has a blank value (restricted to strings), 
					 then that keyword will be omitted from the header

cgg4_order Relation

 
     This relation provides information on the groupings and ordering of keywords to be written to the FITS file
     produced by the PDRORB process.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        instrument           C3          instrument to which the keyword is associated:
                                         hsp, wfc, foc, fos, hrs, wfII, fgs, acs, nic, sti
        header_type          C36         The name of the FITS header. eg: NIC_SPT_PRIMARY
        ftype_order          I2          The order in which to put the following section
        cgg1_instr           C3          The cgg1_keyword relation instrument name.  This
			                 can be the same as 'instrument' above, or another
			                 name such as SSY or GEN."
        cgg1_ftype           C3          The cgg1_keyword relation 'file_type' specification
			                 for this section of keywords

sms_catalog Relation

 
     This relation, used by the REPLAN process, provides information about the 
     generation of the Science Mission Schedule (SMS).  It includes information on first generating a 
     logical SMS (LSMS), precedence checking the LSMS, formatting the LSMS into an SMS, transferring 
     the SMS to the PASS System, and sending the PASS products to the OPUS EDPS System. 
     Descriptions of each field in the sms_catalog relation are available to provide detailed information.

qolink Relation

 
     This relation, used by the REPLAN, UPDATR, 
     CONTRL, and NICSAA processes provides information about the linking of exposures to observations.  
     Descriptions of each field in the qolink relation are available to provide detailed information.

qolink_sms Relation

     This relation is used to provide DADS and OPUS with the SMS_ID for any observation in 
     the Mission Schedule. It can be used to list all observations and association
     products for a particular SMS_ID. It contains a status field to identify observation 
     or product archive success or unavailability.

     The REPLAN, UPDATR, CONTRL, and 
     PDRRSP processes use this relation.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        program_id           C3          When a proposal is accepted into the PMDB by SPSS it must
		                         be assigned a unique 3 character base 36 program identifier.
		                         Is is used for identification of proposals by spacecraft 
                                         and OPUS software. It is also used in the OPUS and DADS 
                                         rootname for all archived science data files.
					 
        obset_id             C2          An observation set is a collection of one or more alignments
	                                 that are grouped together based on FGS pointing requirements.  
					 That is, if multiple alignments can all be executed using the 
					 same guide star pair, they are grouped into the same observation set.

        ob_number            C3          Observations are numbered sequentially throughout an observation set. 
	                                 An ob_number is _NOT_ the same as an obset_ID. The third character is
					 only used for association products
 
        sms_id               C9          The C&C list is a major data structure within SPSS that 
		                         contains information on 'candidates' and the 'calendar'.
					 The candidate data, often referred to as the candidate pool, are 
					 scheduling units and their associated  observation set, alignment, and
					 target data.  The calendar is a timeline of activities that are laid 
		                         down by the SPSS scheduling utilities.  When a C&C List is saved in 
    					 SPSS it receives an identifier (sms_id)

	status               C1          The condition or availability for archiving is indicated
                                         by a status code with the following definition:
		
                                           U - Unexecuted - the initial condition for exposures or
                                               products that will be archived independently of
                                               associations
 
                                           M - Member - the initial condition for exposures that
                                               are only archived within an association product

                                           N - Not available - set by operations to indicate 
                                               exposures or products that cannot be generated

                                           E - Executed and archived successfully				 

        inst                 C1          One character identifier for the instrument used for the science 
	                                 observation. The relation between this value and the names in 
					 qobservation.si_id are: 

                                           1 = 1     2 = 2     3 = 3     J = ACS     N = NIC     O = STIS
                                           U = WFII  V = HSP   W = WFPC  X = FOC     Y = FOS     Z = HRS

        tag                  C1          Flags observation as a target acquisition.
                                           Y - The qobservation.target_acqmode field is 01 or 02.
                                               This observation is a target acquisition


        ocx_expected         C1          Flags this observation as real time (mode 1) target acq.
                                           Y - The qobservation.target_acqmode field is 01.
                                               This observation is a mode 1 (real time) target acquisition 
					       image

        pdq_created          C1          indicates if the OPUS pipeline has created a PDQ file for this 
	                                 observation.  The value of this column is an alphanumeric code that
                                         indicates the status, real or inferred, of the PDQ file for the 
					 observation

        oms_archived         C1          indicates if the OMS pipeline has successfully achived an 
	                                 observation log for this observation. 
                                           X - The data assessment software has validated existence of the
					   OMS observation log for this observation in DADS

        rti_checked          C1          indicates if OPUS staff has checked for existence of real time
                                         information for this observation.
                                           X - OPUS staff has run RTI_CHECK software for this observation

        ocx_appended         C1          indicates if an OCX file has been appended to the PDQ file.
                                         The value of this field is an alphanumeric code that indicates 
					 that the data assessment software has located an OCX file (and 
					 the type of file) for this observation and has appended it to 
					 the PDQ file

        assessed             C1          indictaes if this observation has been assessed for procedural 
	                                 quality. The value of this column is an alphanumeric code that
                                         summarizes the essentials of the assessment process."

        dq_archived          C1          indicates the archive status of the procedural data quality 
	                                 file(s).  The value of this column is an alphanumeric code that
                                         indicates the archive status of the PDQ (and optionally
                                         the OCX) file of this observation

        start_time           C17         This field (format: yyyy.ddd:hh:mm:ss) contains either the 
	                                 planned or actual start time of the observation. The time_type 
					 field indicates the source of the time.

        end_time             C17         This field (format: yyyy.ddd:hh:mm:ss) contains either the 
	                                 planned or actual end time of the observation. The time_type 
					 field indicates the source of the time.

        time_type            C1          (P/A) When this field is P for planned, start_time and end_time 
	                                 are generated from SPSS planning data and the accuracy is 
					 questionable. When this field is A for actual, start_time and 
					 end_time have been updated by the OPUS pipeline using science 
					 data.

executed Relation

    This relation is used to replace the executed_flg in the qobservation relation as qobservation
    is replicated from SPSS and cannot be updated by the EDPS.  Some additional data is also supplied
    but only the executed_flg is updated by EDPS software.  The additional fields can be used to 
    distinguish dumps from science observations.

     The REPLAN and UPDATR processes use this relation.     


       	Field name           type/size	 description  
        ----------           ---------   -----------
        program_id           C3          When a proposal is accepted into the PMDB by SPSS it must
		                         be assigned a unique 3 character base 36 program identifier.
		                         Is is used for identification of proposals by spacecraft 
                                         and OPUS software. It is also used in the OPUS and DADS 
                                         rootname for all archived science data files.
					 
        obset_id             C2          An observation set is a collection of one or more alignments
	                                 that are grouped together based on FGS pointing requirements.  
					 That is, if multiple alignments can all be executed using the 
					 same guide star pair, they are grouped into the same observation set.

        ob_number            C3          Observations are numbered sequentially throughout an observation set. 
	                                 An ob_number is _NOT_ the same as an obset_ID. The third character is
					 only used for association products

        proposal_id          C5          A proposal consists of many individual observations 
		                         submitted as a package by a proposer.  When a proposal is 
		                         processed by the proposal entry system (RPS2), 
		                         it is assigned a proposal identifier.  That identifier is 
		                         an integer that is converted into a 5 character base 36
		                         string   

        si_id                C4          This is the identifier type for a Science Instrument (SI).
		                         The SI list includes the following:
			                    FOC  - Faint Object Camera
			                    FOS  - Faint Object Spectrograph
			                    WFPC - Wide Field Planetary Camera 1
			                    WFII - Wide Field Planetary Camera 2
			                    WF3  - Wide Field Camera 3
			                    HRS  - High Resloution Spectrograph
			                    CSTR - COSTAR
			                    1    - Fine Guidance Sensor 1
			                    2    - Fine Guidance Sensor 2
			                    3    - Fine Guidance Sensor 3
			                    NIC  - NICMOS
			                    STIS - Space Telescope Infrared Spectrograph
                                            ACS  - Advanced Camera for Surveys
                                            COS  - Cosmic Origins Spectrometer

        control_id           C5          This is information on how OPUS is supposed to
                                         process the data. The data is stored in five bytes:

                                            H/Y/N  : Calibration data flag
                                            F/P    : Output product type  (film/plot) - unused
                                            2 bytes: Output format spec               - unused
                                            Y/N    : Output product holding tank flag

        coord_id             C10         This is the SI aperture and coordinate system
                                         identifier; it specifies the aperture and
                                         coordinate system of the instrument to be
                                         used for the observation of the target.
                                         It is the aperture identifier concatenated with
                                         the aperture coordinate system identifier.
                                         They specify the default location of the target within 
                                         the aperture

        executed_flg         C1          When the record is created this value is blank. When
                                         the observation has been executed on board HST, OPUS
                                         receives a science POD file or EDPS generates an 
                                         astrometry file from engineering data, and this field is
                                         updated to the Type (ninth) character of the dataset
                                         rootname

qobservation Relation

 
     This relation, used by the REPLAN, UPDATR, and NICSAA processes,
     provides information about the observations contained in Science Mission Schedules.  
     Descriptions of each field in the qobservation relation are available to provide detailed information.

dataset_link Relation

     This relation is used to link dataset rootnames to programmatic ids with keys to facilitate 
     joins to other relations.
		   
     The REPLAN and CONTRL processes use this relation.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        dataset_rootname     C9          IPPPSSOOT for jitter or astrometry datasets

        dataset_type         C3          Either FGS or AST, for FGS obslogs or astrometry,
                                         respectively
        program_id           C3          When a proposal is accepted into the PMDB by SPSS it must
		                         be assigned a unique 3 character base 36 program identifier.
		                         Is is used for identification of proposals by spacecraft 
                                         and OPUS software. It is also used in the OPUS and DADS 
                                         rootname for all archived science data files.
					 
        obset_id             C2          An observation set is a collection of one or more alignments
	                                 that are grouped together based on FGS pointing requirements.  
					 That is, if multiple alignments can all be executed using the 
					 same guide star pair, they are grouped into the same observation set.

        ob_number            C3          Observations are numbered sequentially throughout an observation set. 
	                                 An ob_number is _NOT_ the same as an obset_ID. The third character is
					 only used for association products

product_eng_map Relation

     This relation is used to identify the FOF engineering telemetry files that need to be converted to provide
     intermediary telemetry files containing telemetry parameters needed for FGS, GSA or AST product generation.
     It is used to simplify creation and collection of telemetry for processing.  When a product has no 
     eng_ready = N flags, then the OSF for the product can be created using the product rootname.
     
     The REPLAN and CONTRL processes use this relation.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        product_rootname     C14         IPPPSSOOT for jitter or astrometry products;
                                         GYYYYDDDHHMMSS for GS acquisition data
 
        product_type         C3          FGS for jitter, AST for astrometry, or GSA for GS 
                                         acqusition data
 
        eng_rootname         C12         TYYYYDDDHHMM, rootname of the ENG telemetry file

 
        eng_ready            C1          (Y/N), 'N' indicates the telemetry file eng_rootname is not
                                         yet recognized as ready for this product_type. 'Y' indicates
                                         that the processing for this product type has recognized
                                         the presence of eng_rootname. Having separate control for
                                         each product type simplifies initiation of processing. "

asn_association Relation

     This relation is used to provide attributes that apply to entire associations.  An association is
     a set of exposures that will be merged into products by OPUS pipeline. The full association 
     consists of a list of exposures and products.  This is one of the relations used to define 
     associations for OPUS. The asn_members and 
     asn_product_link are the others.
     
     The REPLAN and UPDATR processes use this relation.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        association_id       C9          This field identifies an OPUS association.   An
                                         association is a set of exposures that will be
                                         merged into products by OPUS pipeline calibration
                                         processing. The full association consists of a
                                         list of exposures and products.  

                                         This field completely identifies an association. This is 
                                         the OPUS value used for the keyword ASN_ID.  It has the
                                         following format:

                                            IPPPSSAAa

                                            where:
                                               I = instrument code (e.g., N for NICMOS, O for STIS),
                                             PPP = program_id
                                              SS = obset_id of the first associated exposure,
                                             AAa = the two-character sequence (AA = 01,02,...)
                                                   is unique within the obset SS; plus the product id
						   (a) that is always 0 for associations and primary 
						   products.

        si_name              C4          This is the identifier type for a Science Instrument (SI).
                                         The SI list includes the:
                                             FOC  - Faint Object Camera
                                             FOS  - Faint Object Spectrograph
                                             WFII - Wide Field Planetary Camera 2
                                             HRS  - High Resloution Spectrograph
                                             CSTR - COSTAR
                                             FGS  - Fine Guidance Sensor
                                             NIC  - NICMOS
                                             STIS - Space Telescope Infrared Spectrograph
                                             ACS  - Advanced Camera for Surveys
                                             COS  - Cosmic Origins Spectrometer
                                             WF3  - Wide Field Planetary Camera 3       


        last_exp_date        C17         This field contains the latest predicted time of the
                                         exposure members of an association. It uses the standard
                                         SOGS time format - yyyy.ddd:hh:mm:ss
                                         where:
					        yyyy = year
                                                ddd = day of year
                                                hh = hours
                                                mm = minutes
                                                ss = seconds
        collect_date         C17         This field contains the date of the association file 
	                                 created by OPUS. It uses the standard SOGS time
                                         format - yyyy.ddd:hh:mm:ss
                                         where:
					        yyyy = year
                                                ddd = day of year
                                                hh = hours
                                                mm = minutes
                                                ss = seconds

asn_members Relation

     This relation is used for all members (exposure and product) that form an OPUS association. This
     is one of the relations used to describe OPUS associciations.  The 
     asn_association and 
     asn_product_link are the others.
                 
     An association is a set of exposures that will be merged into products by OPUS pipeline. The full
     association consists of a list of exposures and products.

     An association product is a dataset, distinct from any exposure dataset, that is generated by the
     pipeline.  Exposures are associated in order to generate products.  For an exposure, the 
     mem_number is two characters and is the same as ob_number.  For a product, the mem_number is the
     combination of the association number within the obset and the product_id.

     Prior to the collection the member_status for exposures is 'U'. Afterwards, it is either 'C' or 
     'O'. The value for products is always 'P'.                    

     Prior to the collection the product_status for products is 'U'. Afterwards, it is either 'C' or 
     'M'. The value for exposures is always 'E'.

     The REPLAN and UPDATR processes use this relation.     


       	Field name           type/size	 description  
        ----------           ---------   -----------                   
        association_id       C9          This field identifies an OPUS association.   An association 
	                                 is a set of exposures that will be merged into products by 
					 OPUS pipeline calibration processing. The full association 
					 consists of a list of exposures and products.  STIS can only
					 have one product per association.  NICMOS can have as few as
					 one and as many as nine products. ACS can have 
                                         a single product having a product_id of either '0'
                                         (for a dither product) or '1' for a cr-split or repeat-obs 
					 product at a single pointing. If there are more than one 
					 product the there is always a dither product having the 
					 product_id '0' and the other products use product ids that 
					 range from '1' to 'I'. 

                                         This field completely identifies an association.  It
                                         is set by TRANS.  It is used by DADS as the dataset
                                         name to archive the association file.  This is the
                                         OPUS value used for the keyword ASN_ID.  It has the
                                         following format:


                                            IPPPSSAAa

                                            where:
                                               I = instrument code (e.g., N for NICMOS, O for STIS),
                                             PPP = program_id
                                              SS = obset_id of the first associated exposure,
                                             AAa = the two-character sequence (AA = 01,02,...)
                                                   is unique within the obset SS; plus the product id
						   (a) that is always 0 for associations and primary 
						   products
						                    

        program_id           C3          When a proposal is accepted into the PMDB by SPSS it must
                                         be assigned a unique 3 character base 36 program identifier.
                                         This is done by the PMDB/ACCEPT_PROP command.  This program
                                         identifier is tagged as 'program_id' in most PMDB relations.
                                         Is is used for identification of proposals by spacecraft
                                         and OPUS software. It is also used in the OPUS and DADS
                                         rootname for all archived science data files.
                                         Because of flight design software, program_id must be
                                         three characters             
        obset_id             C2          An observation set is a collection of one or more
                                         alignments that are grouped together based on FGS pointing
                                         requirements.  That is, if multiple alignments can all be
                                         executed using the same guide star pair, they are grouped
                                         into the same observation set.

                                         An observation set is identified by a 2 character base 36
                                         string.  This field,  typically called 'obset_id', will
                                         often contribute to the index on relation together with a
                                         proposal_id, version_num, and possibly other fields.

                                         OBSET is an abbreviation for observation set
        member_num           C3          For exposures, observations are numbered sequentially
                                         throughout an observation set and are assigned by SMS/Gen.
                                         For exposures the name is two characters and it is the
                                         same as the observation ob_number. For products it is the
                                         association number (two characters) plus the product_id


        member_type          C12         This field describes the role of the member in the
                                         association. If there are multiple products, then the
                                         format of the exposure names correlate to the 
                                         product names by rules that depend on the SI.

                                         For exposures this name must be the same as exp_type
                                         in qeassociation   
        member_status        C1          This field describes the status of a member of the
                                         association. Valid values are:

                                            U -- uncollected exposure
                                            C -- collected exposure
                                            O -- orphan exposure (not collected)
                                            P -- product dataset   
        product_status       C1          This field describes the status of a product of the
                                         association. Valid values are:

                                            U -- uncollected product
                                            C -- collected product
                                            N -- not collected - missing product after collection
                                            E -- exposure (not a product)
                                            X -- unknown (only valid for old records)

asn_product_link Relation

     This relation is used for all products for an OPUS association. It identifies the exposures 
     contained in each product. It can also be accessed to find the products associated with any 
     exposure. The other relations used to describe OPUS associations are
     asn_association and asn_members.
     
     The REPLAN, UPDATR, and NICSAA processes
     use this relation.     


       	Field name           type/size	 description  
        ----------           ---------   -----------
        program_id           C3          When a proposal is accepted into the PMDB by SPSS it must
                                         be assigned a unique 3 character base 36 program identifier.
                                         This is done by the PMDB/ACCEPT_PROP command.  This program
                                         identifier is tagged as 'program_id' in most PMDB relations.
                                         Is is used for identification of proposals by spacecraft
                                         and OPUS software. It is also used in the OPUS and DADS
                                         rootname for all archived science data files.
                                         Because of flight design software, program_id must be
                                         three characters
        asn_obset_id         C2          Association observation set identifier.  An observation set 
	                                 is identified by a 2 character base 36 string.  This field,
					 typically called 'obset_id', will often contribute to the 
					 index on relation together with a proposal_id, version_num, 
					 and possibly other fields.
        member_num           C3          Member number (in asn_members) of the product: it is the
                                         association number (two characters) plus the product_id
        obset_id             C2          Exposure observation set identifier.  An observation set is 
	                                 identified by a 2 character base 36 string.  This field,  
					 typically called 'obset_id', will often contribute to the 
					 index on relation together with a proposal_id, version_num, 
					 and possibly other fields. OBSET is an abbreviation for 
					 observation set
       ob_number             C2          Observations are numbered sequentially throughout
                                         an observation set and are assigned by SMS/Gen.
                                         An ob_number is _NOT_ the same as an obset_ID.
                                         This field can be joined to member_num for exposure records 
					 in asn_members

jitter_evt_map Relation

     This relation is used to identify the all the jitter datasets that follow either the SMS start 
     event or the GS acquisition event, identified by event time. The event_type specifies whether 
     the event_start_time is for an SMS or a GS acquisition. If the event is an acquisition, then the
     evt_start_time will exactly match the acq_start_time in the gsa_data table. This table is also 
     used to identify internal exposures that do not need engineering telemetry for its defaulted 
     jitter files. The table was designed to be easily joined to qolink_sms to get exposure status so
     that jitter files are not generated for exposures have a status of N.
		   
     The REPLAN and CONTRL processes use this relation.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        event_start_time     C17         YYYY.DDD:HH:MM:SS, Start time of event. If event_type is
                                         G for GSACQ then this time must match the acq_start_time
                                         in the gsa_data table and it can be used to join to that
                                         table
        event_type           C3          (SMS or GSA)  SMS start or GS acquisition start
	
        program_id           C3          When a proposal is accepted into the PMDB by SPSS it must
		                         be assigned a unique 3 character base 36 program identifier.
		                         This is done by the PMDB/ACCEPT_PROP command.
                                         It is used for identification of proposals by spacecraft 
                                         and OPUS software. It is also used in the OPUS and DADS 
                                         rootname for all archived science data files. 
                                         Because of flight design software, program_id must be
                                         three characters
        obset_id             C2          An observation set is a collection of one or more 
		                         alignments that are grouped together based on FGS pointing 
		                         requirements.  That is, if multiple alignments can all be 
		                         executed using the same guide star pair, they are grouped
		                         into the same observation set
        ob_number            C2          Observations are numbered sequentially throughout
                                         an observation set and are assigned by SMS/Gen.
                                         An ob_number is _NOT_ the same as an obset_ID
        internal_flag        C1          (Y or N) Y indicates if this is a internal observation

product_status Relation

     This relation is used to identify the completion status of all FGS, AST, and GSA products in order to 
     control telemetry file cleanup.  The records are created with N for complete_flag. This relation is 
     designed to be joined to product_eng_map to determined when all the products, identified in 
     product_eng_map by product_type and product_rootname, have been marked completed.  

     For reprocessing, all the products to be reprocessed should have the complete_flag interactively reset 
     to N. For replans, any records for dataset no longer present in qolink. must be deleted. Only one record 
     for each product and type is allowed. "

     The REPLAN and CONTRL processes use this relation.
     
     
       	Field name           type/size	 description  
        ----------           ---------   -----------
	product_rootname     C14         IPPPSSOOT for jitter or astrometry products;
                                         GYYYYDDDHHMMSS for GS acquisition data

        product_type         C3          FGS for jitter, AST for astrometry, or GSA for GS 
                                         acqusition data

        complete_flag        C1          (Y/N) set to Y by cleanup software indicating this dataset has been 
	                                 processed and no longer prevents cleanup of telemetry files

qelogsheet Relation

     This relation, used by the UPDATR and NICSAA processes is closely related to the fields
     (columns) on the proposal Exposure Logsheet.  The Logsheet is used to define the proposed
     exposures for the HST Scientific instruments.  
     Descriptions of each field in the qelogsheet relation are available to provide detailed information.

qeassociation Relation

     This relation, used by the UPDATR process is used to define the set of
     exposures that form an OPUS association.  
     Descriptions of each field in the qeassociation relation are available to provide detailed information.

product_code Relation

    This relation is used to provide the tool, UPDATE_QODATA, with a mechanism to assign a product_id
    and member_name (of a product) for NICMOS or any that has multiple products. The product_id is 
    correlated with the unique value of EXP_TYPE in qeassociation table. This is a one
    character product_id that supercedes the last character of the association_id to form the 
    member-name of a product. 

     The UPDATR process uses this relation.
     
     
       	Field name           type/size	   description  
        ----------           ---------     -----------
        si_name              C4            This is the identifier type for a Science Instrument (SI).
		                           The current SI list for qeassociation candidates are:

			                       NIC  - NICMOS - Near IR Camera - Multi-Object Spectr.
			                       STIS - Space Telescope Infrared Spectrograph

                                               STIS only has one product_id but many exp_type values and
                                               will not appear in this table
	exp_type             C12           This field describes the role of the exposure in the
                                           association.  Valid values for NICMOS exposures are
                                           (EXP-TARG, EXP-BCK1, EXP-BCK2, ..., EXP-BCK8)   
        product_id           C1            This is the last character of an member_id of a product. The
	                                   first eight characters of the id are the same as the association_id.
					   The first product_id is 0 which forms a member_name that is the 
					   same as the association_id       
        product_code         PRODCODE_TYPE Assign product_id by exp_type

msc_events Relation

     This relation is used to hold events extracted from Mission Schedule files that are of interest
     to the EDPS FGS pipeline. 

     The MSCXTR processes populates this relation and the relation is used by
     the CONTRL process.
     
     
       	Field name           type/size	   description  
        ----------           ---------     -----------
        event_time           C20           YYYY.DDD.HH.MM.SS.CC the time within a hundreth of
                                           a second for each event
        event_type
                             C3            OPS for operational info; FGS for jitter; RTI for PCS 
                                           events; RTO for offset slot data; TDR for TDRSS COMCON events
        event_class          C5
                                           for OPR type classes
                                           --------------------

                                           BOM   begin mission schedule
                                           EOM   end mission schedule

                                           for FGS type classes
                                           --------------------
                         
                                           BOSn  begin slew of type n (n=1 to 4)
                                           PCP   Pointing Control Processor
                                           ORBIT related to HST orbit
                                           BOA   begin GS acquisition or reacquisition
                                           EOA   end GS acquisition or reacquisition

                                           for RTI type classes
                                           --------------------

                                           EOS2  end slew of type 2
                                           FHST3 fhst - start of 3-axis update
                         
                                           for RTO type classes
                                           --------------------
 
                                           GEN   generate offset slot
                                           REUSE reuse offset slot
                                           SET   set offset slot
                                           CLEAR clear offset slot

                                           for TDR type classes
                                           --------------------

                                           BOC   begin COMCON
                                           EOC   end COMCON
                                           BRC   begin rejected COMCON
                                           ERC   end rejected COMCON
                                           BTC   begin trimmed COMCON
                                           ETC   end trimmed COMCON "
        event_name           C10           Format     Description
                                           ---------- --------------------------------------
                                           mmmmmmmmm  9-char MSC rootname for BOM and EOM
                                           aaaaaaaaaa 10-char aperture name for BOSn,or EOS2
                                           TERMINATE  PCP state
                                           GYRO       PCP state
                                           FGS_OCCULT PCP state
                                           SAA        PCP state
                                           ENTR_DAY   entering ORBIT day 
                                           ENTR_NIGHT entering ORBIT night
                                           GSACQ1     first acquisition for BOA and EOA
                                           GSACQ2     second acquisition for BOA and EOA
                                           REACQ      reacquisition for BOA and EOA
                                           S_ss_pppoo RTO: ss is slot num, pppoo is obset
                                           pppoo_ssss TDR: pppoo is obset, ssss is service

msc_gs_acq Relation

    This relation is used to hold the events extracted from Mission Schedule files that entail detailed 
    parameters of Guide Star (GS) Acquisitions and Re-acquistions.  This information is of interest to 
    the EDPS FGS pipeline.

     The MSCXTR process populates this relation.
     
     
       	Field name           type/size	   description  
        ----------           ---------     -----------
        event_time           C20           YYYY.DDD.HH.MM.SS.CC the time within a hundreth of
                                           a second for each event
        event_name           C10           Format     Description
                                           ---------- --------------------------------------
                                           GSACQ1     first acquisition for BOA and EOA
                                           GSACQ2     second acquisition for BOA and EOA
                                           REACQ      reacquisition for BOA and EOA
        dom_fgs              C1            FGS number for  dominant GS

        prim_fgs             C1            FGS number for primary GS, that is acquired first

        rol_fgs              C1            FGS number for  roll GS

        dom_gs_ra            R8            Right ascension (degrees) for dominant GS

        dom_gs_dec           R8            Declination (degrees) for  dominant GS

	rol_gs_ra            R8            Right ascension (degrees) for roll GS or zero

        rol_gs_dec           R8            Declination (degrees) for  roll GS or zero

        dom_gs_mag           R4            (Vmag) brightness of dominant GS

        rol_gs_mag           R4            (Vmag) brightness of roll GS or zero

        dom_gs_id            C10           GSC ID of dominant GS

        rol_gs_id            C10           GSC ID of roll GS or blank if no GS

        tracking             C2            FL for finelock, CT for coarse track, FG for
                                           finelock/gyro, and CG for coarse track/gyro.
                                           CT and CG tracking modes are no longer used.

msc_ast_obset Relation

    This relation is used to hold the events extracted from Mission Schedule files that entail obset 
    level data for astrometry.  The event time is taken from the time found in the MSC file but there 
    is no msc_events record for this data.  This information is of interest to the EDPS AST pipeline; 
    i.e., the fields are used to set astrometry keywords in astrometry output products.

     The MSCXTR process populates this relation.
     
     
       	Field name           type/size	   description  
        ----------           ---------     -----------
        event_time           C20           YYYY.DDD.HH.MM.SS.CC the time within a hundreth of
                                           a second for each event
        program_id           C3            When a proposal is accepted into the PMDB by SPSS it must
		                           be assigned a unique 3 character base 36 program identifier.
		                           This is done by the PMDB/ACCEPT_PROP command.
                                           It is used for identification of proposals by spacecraft 
                                           and OPUS software. It is also used in the OPUS and DADS 
                                           rootname for all archived science data files. 
                                           Because of flight design software, program_id must be
                                           three characters.
        obset_id             C2            An observation set is a collection of one or more 
		                           alignments that are grouped together based on FGS pointing 
		                           requirements.  That is, if multiple alignments can all be 
		                           executed using the same guide star pair, they are grouped
		                           into the same observation set.
        fgs                  C1            FGS number, 1 2 or 3, or 0 for all

        param_name           C8            Keyword name or keyword related parameter name

        param_value          C20           Formatted value of parameter

msc_ast_observe Relation

     This relation is used to hold the events extracted from Mission Schedule files that entail
     observation level data for astrometry.  The event time is taken from the time found in the MSC file 
     but there is no msc_events record for this data.  This information is of interest to the EDPS AST 
     pipeline; i.e., the fields are used to set astrometry keywords in astrometry output products.

     The MSCXTR process populates this relation.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        event_time           C20         YYYY.DDD.HH.MM.SS.CC the time within a hundreth of a second 
	                                 for each obset

        program_id           C3          When a proposal is accepted into the PMDB by SPSS it must
		                         be assigned a unique 3 character base 36 program identifier.
		                         Is is used for identification of proposals by spacecraft 
                                         and OPUS software. It is also used in the OPUS and DADS 
                                         rootname for all archived science data files.
					 
        obset_id             C2          An observation set is a collection of one or more alignments
	                                 that are grouped together based on FGS pointing requirements.  
					 That is, if multiple alignments can all be executed using the 
					 same guide star pair, they are grouped into the same observation set.

        ob_number            C3          Observations are numbered sequentially throughout an observation set. 
	                                 An ob_number is _NOT_ the same as an obset_ID. The third character is
					 only used for association products

        fgs                  C1          FGS number, 1 2 or 3, or 0 for all

        param_name           C8          Keyword name or keyword related parameter name

        param_value          C20         Formatted value of parameter

msc_slew_slot Relation

    This relation is used to hold the events extracted from Mission Schedule files that entail the details
    of msc_events of type RTO and class GEN taken from the Mission Schedule file GEN-SLEW block.  This 
    information is of interest to the EDPS FGS pipeline.

     The MSCXTR process populates this relation.
     
     
       	Field name           type/size	   description  
        ----------           ---------     -----------
        event_time           C20         YYYY.DDD.HH.MM.SS.CC the time within a hundreth of a second 
	                                 for each obset
					 
       program_id            C3          When a proposal is accepted into the PMDB by SPSS it must
		                         be assigned a unique 3 character base 36 program identifier.
		                         This is done by the PMDB/ACCEPT_PROP command.
                                         It is used for identification of proposals by spacecraft 
                                         and OPUS software. It is also used in the OPUS and DADS 
                                         rootname for all archived science data files. 
                                         Because of flight design software, program_id must be
                                         three characters.
        obset_id             C2          An observation set is a collection of one or more 
		                         alignments that are grouped together based on FGS pointing 
		                         requirements.  That is, if multiple alignments can all be 
		                         executed using the same guide star pair, they are grouped
		                         into the same observation set.
        slot                 C3          Slot number
    
        load_by              C17         YYYY.DDD:HH;MM:SS - load by date

        max_slew             C3          formatted as integer arcsec - maximum slew angle

        offset_id            C13         An identified used in the SPSS database

qexposure Relation

 
     This relation, used by the CONTRL process is used to define exposures.  It
     provides information on how to control the Science Instruments for the exposures defined in its
     records.  
     Descriptions of each field in 
     the qexposure relation are available to provide detailed information.

gsa_data Relation

     This relation is used to identify the full time range of planned Guide Star acquisitions, and 
     to report results of the actual acquisition. The first three fields are populated when the 
     record is inserted into the table and the remaining fields are updated after gs acqisition 
     processing. 

     The CONTRL process updates this relation.
     
     
       	Field name           type/size	   description  
        ----------           ---------     -----------
        gsa_rootname         C14           GYYYYDDDHHMMSS where the time values match the gsa_start_time

        gsa_start_time       C17           YYYY.DDD:HH:MM:SS, Commanded start of the GSACQ1 or
                                           REACQ event
        gsa_end_time         C17           YYYY.DDD:HH:MM:SS, Allocated end of the REACQ event, or 
	                                   the end of the GSACQ1 event if num_pair is 1, or end of 
					   the GSACQ2 event if num_pair is 2.
        acq_success_time     C17           YYYY.DDD:HH:MM:SS, time of the start of FGS guiding
                                           when takedata flag is first raised during the 
                                           acquistion or blank if no telemetry or acq failure
        guiding_mode         C2            Guiding mode at end of acquisition. 
	                                     GY - gyro, 
                                             FL - fine lock on both stars, FG - fine lock/gyro,
                                             CT - coarse track on both stars, CG - coarse track/
                                                  gyro. CT and CG are no longer allowed but old
                                                  schedules allowed these modes
        acq_status           C12           GSFAIL keyword value or blank. The non-blank values
                                           are: 
					     TLMGAP - unknown due to missing telemetry
                                             VEHSAFE - not attempted due to safing 
					     SSLEXP - scan step limit exceeded on primary GS 
					     SSLEXS - scan step limit exceeded on secondary GS 
					     SREXCPn - search radius exceeded on primary GS of pair n
                                             SREXCSn - search radius exceeded on secondary GS of pair n
					     NOLOCK - failed to obtain finelock on either GS
        acq_tlm_gap          R4            (Seconds) time of telemetry gap that overlaps 
                                           the acquisition window between gsa_start_time and 
                                           gsa_end_time
        actual_pair_num      I4            -1 = undetermined, 0 - failure, 1 - first pair is
                                            acquired, or 2 - second pair is acquired. 
					  
        acq_dom_fgs          I4            Dominant FGS number or 0, after acquisition. A zero
                                           value indicates a total failure
        acq_rol_fgs          I4            Roll FGS number or 0, after acquisition. A zero 
                                           value is either a planned FGS/GYRO mode or a
                                           failure to acquire both GSs

nic_saa_exit Relation

 
     This relation, used by the NICSAA process contains data needed to support the
     NICMOS post-SAA (South Atlantic Anomaly) dark exposures. SAA exit times are significant to the NIC
     because beginning in cycle 10, NICMOS will execute a series of dark calibration observations immediately
     after each SAA passage in order to eliminate persistence due to cosmic rays. 
     Descriptions of each field in 
     the nic_saa_exit relation are available to provide detailed information.

nic_saa_dark Relation

     This relation is used to identify NICMOS associations containing Post-SAA dark exposures. The records 
     are created for all such associations whether or not there are any exposures that use it. There is a 
     separate record for each NICMOS configuration and saa_exit time. The relation
     is used to allow the linkage of NICMOS exposures to SAA darks that may occur in a previous (replan) SMS.
     Records having saa_exit_hour values that are a few weeks old have no operational value and may be deleted
     at any time. There is no reason to archive any of these records.

     The NICSAA process populates this relation.
     
     
       	Field name           type/size	   description  
        ----------           ---------     -----------
       saa_exit_hour         C11           YYYY.DDD:HH -- This is the hour at which the saa
                                           exit occurs. If the exit time is near an hour 
                                           boundary, a second record with the adjacent hour
                                           is also present. This field is used to match with
                                           the first 11 characters of SPSS nic_saa_exit.saa_exit
                                           relation to create the nic_saa_link records.
       config                C15           This is the value from qelogsheet.config that must be
                                           the same for both exposures of the association. The same
                                           value must match any qelogsheet.config for linked 
                                           exposures in nic_saa_link. There should be three records
                                           with different config values for each value of saa_exit_hour
       program_id            C3            The program_id of the dark association. See asn_product_link.program_id 
       
       obset_id              C2            Association observation set identifier of the dark association. See
                                           asn_product_link.asn_obset_id 
       member_num            C3            Member number of the dark association primary product. 
                                           See asn_product_link.member_num. "

nic_saa_link Relation

     This relation is used to link NICMOS exposures to the SAA dark association that is relevant to the 
     exposure. If no record exists, then either the exposure is an SAA dark or the exposure occurs too long 
     after the SAA exit time.  The individual exposures of the associations can be accessed through the 
     asn_product_link table. All the timing info for both the exposures and the darks are found in the 
     nic_saa_exit table. 

     For records in this table, the dark association must have nearly the same saa_exit time (from NIC_SAA_EXIT table)
     as the exposure. That is, the most recent SAA exit for both the darks and the exposures must be in the 
     same orbit.  The exposure from the dark association must have the same  qelogsheet.config value.  The 
     qelogsheet.targname value for the dark exposures will be POST-SAA-DARK. 

     The records in this table are inserted during the processing of the mission schedule, after updating the
     the asn tables.  

     The NICSAA process populates this relation.
     
     
       	Field name           type/size	   description  
        ----------           ---------     -----------
        program_id           C3            When a proposal is accepted into the PMDB by SPSS it must
                                           be assigned a unique 3 character base 36 program identifier.
                                           This is done by the PMDB/ACCEPT_PROP command.  This program
                                           identifier is tagged as 'program_id' in most PMDB relations.
                                           Is is used for identification of proposals by spacecraft
                                           and OPUS software. It is also used in the OPUS and DADS
                                           rootname for all archived science data files.
                                           Because of flight design software, program_id must be
                                           three characters.
        obset_id             C2            An observation set is a collection of one or more
                                           alignments that are grouped together based on FGS pointing
                                           requirements.  That is, if multiple alignments can all be
                                           executed using the same guide star pair, they are grouped
                                           into the same observation set.

                                           An observation set is identified by a 2 character base 36
                                           string.  This field,  typically called 'obset_id', will
                                           often contribute to the index on relation together with a
                                           proposal_id, version_num, and possibly other fields.
                                           OBSET is an abbreviation for observation set.
        ob_number            C2            Observations are numbered sequentially throughout
                                           an observation set and are assigned by SMS/Gen.
                                           An ob_number is _NOT_ the same as an obset_ID.
                                           This field can be joined to member_num for 
                                           exposure records in asn_members.
        dark_program_id      C3            The program_id of the dark association. See asn_product_link.program_id. "

        dark_obset_id        C2            Association observation set identifier of the dark association. 
	                                   See asn_product_link.asn_obset_id. " 

        dark_member_num      C3            Member number of the dark association primary product.
                                           See asn_product_link.member_num. "
        dark_association     C9            This is a convenience field. It can be reconstructed
                                           from the letter N, the dark_program_id, the dark_obset_id, and the
					   dark_member_num. See asn_members for complete definition of 
					   association_id. "

dads_archive Relation

     This relation tracks requests made by applications to archive files and responses made by the on-line
     dads archive system.  Entries are retained in this table after processing is completed for historical
     purposes.

     The PDR Pipeline PDRREQ and PDRRSP processes use 
     this relation.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        dataset_name         C23         The name given to describe a group of files         

        archclass            C3          The classification used to archive the data 
 
        archdate             C20         The latest file date associated with the dataset    

        reqdate              C23         The date when the archive insertion request was generated    

        reqtype              C4          either a TAPE or DISK archive insertion requests   

        response             C10         Response status returned by DADS            

        disk_date            C23         The optical disk date assigned by DADS  

        file_cnt             I2          The file count as determined by DADS

        path                 C10         The path from which the request is made                    

        tape_date            C20         The date when a tape is made         

        saveset              C17         The saveset name

        archv_tape           C6          Tape label

qoarchives Relation

     This relation holds records that have been inserted when the OPUS data partitioning processes 
     determine the name of the ipppssoots from the science POD files.  Any pipeline process that
     subsequently has trouble processing science data will update the trouble_flag and trbl_process
     fields.  In addition, OPUS/EDPS archive processes update a number of fields in this relation.

     The PDR Pipeline PDRREQ process uses this relation.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        program_id           C3          Unique 3 character base 36 program identifier for the proposal for
	                                 which this observation is a part.  Used with the obset_id, 
					 ob_number, and data_class fields to form the observation rootname,
					 which uniquely identifies an observation

       obset_id              C2          A collection of one or more alignments that are grouped together
                                         based on FGS pointing requirements.  That is, if multiple alignments
					 can all be executed using the same guide star pair, they are grouped
					 into the same observation set.  Part of the OPUS rootname.

       ob_number             C2          Observations are numbered sequentially throughout an observation set 
                                         and are assigned by sms (base 36 number max. 1295 observations per
					 obset).  Part of the OPUS rootname.

       data_class            C1          Type of data (R real-time, T tape-recorded, etc

       obs_root              C9          The ipppssoot, where
                        
                                              i = instrument code (N - NICMOS, O - STIS, U - WFPC2
                                                  V - HSP, W - WFPC1, X - FOC, Y - FOS, Z - HRS)
                                            ppp = program_id
                                            ss  = obset_id
                                            oo  = ob_number
                                            t   = data_clas

       proc_strt_tm          C16         Time pipeline processing for this dataset.  Format is 
                                         yyyydddHHMMSSsss

       proc_stop_tm          C16         Time pipeline processing completed for this dataset. Format is 
                                         yyyydddHHMMSSsss   

       data_eval             I4          obsolete field??

       flg_mismatch          C1          archive flag for file count mismatches

       geis_only             C1          obsolete field??

       calib_indic           I2          obsolete field??

       trouble_flag          C1          Set to 'T' if observation sent to 'trouble'

       trbl_process          C6          Name of process that sent observation to 'trouble'   

       edsci_file            C9          obsolete field??

       edt_archdate          C20         DADS ARCHDATE for EDT archive class.  Format is yyyydddHHMMSSss

       edt_fcnt              I2          File count for EDT archive class

       calib_file            C9          obsolete field??

       cal_archdate          C20         DADS ARCHDATE for CAL archive class.  Format is yyyydddHHMMSSsss         

       cal_fcnt              I2          File count for CAL archive class

       cdbs_data             C15         obsolete field??
           
       repro_flg             C10         obselete field??

archive_files Relation

     This relation is used to track a dataset's file extensions. The file extension are written to 
     this relation when the ARCHIVE_CLASS.TRACK_EXT is set to "Y" in a processes resource file.

     The PDR Pipeline PDRREQ process uses this relation.


       	Field name           type/size	 description  
        ----------           ---------   -----------
        dataset_name         C23         The name given to describe a group of files

        archclass            C3          The classification used to archive the data          

        archdate             C20         The latest file date associated with a dataset           

        file_ext             C3          The files' extension

Database Querries Performed

MSCCPY Process Querries

MTLCPY Process Querries

SMSCPY Process Querries

ORBCPY Process Querries

PDRORB Process Querries

REPLAN Process Querries

UPDATR Process Querries

MSCXTR Process Querries

CONTRL Process Querries

NICSAA Process Querries

PDRREQ Process Querries

PDRRSP Process Querries