! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ! SDDL Name: zspss_user_types.sddl ! ! Purpose: This file consists of the standard spss object types. ! ! Modification History: ! ! Date OPR Who Reason ! -------- ------- --- ------------------------------------------------- ! 11/94 27329 Team Updates for relation conversion project. ! 12/94 27329 Team More updates for relation conversion project. ! 01/95 27329 Team More updates for relation conversion project. ! 11/95 30445 NLC Duplicate type SI_STATE_TYPE; rename to ! SI_CONFIG_STATE_TYPE ! 1/96 30681 EGB Add LRP_NAME_TYPE ! 03/13/96 31033 MRB Add PASS_SMS_ID_TYPE ! 04/02/96 29724 NLC Add LOCK_FIELD_TYPE ! 03/13/96 30954 MRB Add OPUS_ASSOCIATION_ID_TYPE,OPUS_PRODUCT__ID_TYPE ! 06/24/96 31689 SFS Modify definition of OPUS_ASSOCIATION_ID_TYPE ! 10/30/96 32496 SFS Resolved CMS variant for this file ! 12/6/97 32404 EGB Clarify cclist version. ! 11/03/98 37306 bao Delete remnants of GSSS interface from SPSS ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ! Langauge Specifications LANGUAGE FORTRAN, C !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ! PMDB Proposal Hierarchy Types ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! USER_TYPE PROPOSAL_ID_TYPE DESCRIPTION "A proposal consists of many individual observations submitted as a package by a proposer. When a proposal is processed by the proposal entry system (PEPSI, RPS2), it is assigned a proposal identifier. That identifier is an integer that is converted into a 5 character base 36 string. This field, typically called 'proposal_id', will often contribute to the index on a relation. In the PMDB a proposal will minimally consist of proposal-specific data plus observation set, alignment, exposure, and target data, as defined below." TYPE C5 UNITS "BASE_36" END_USER_TYPE USER_TYPE INT_PROPOSAL_ID_TYPE DESCRIPTION "This is the PEPSI/RPS2 proposal identifier field. It is simlar to the PMDB proposal_id field except that it is an integer instead of a base-36 string. PEPSI only assigns base-10 proposal ids to the propsals so that this field will be identical (except for the leading 0)." TYPE I*2 END_USER_TYPE USER_TYPE PROGRAM_ID_TYPE DESCRIPTION "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 PODPS software. It is also used in the PODPS and DADS rootname for all archived science data files. Because of flight design software, program_id must be three characters." TYPE C3 UNITS "BASE_36" END_USER_TYPE USER_TYPE OBSET_ID_TYPE DESCRIPTION "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. In the PMDB an observation set will minimally consist of observation set-specific data plus alignment, exposure, and target data. OBSET is an acronym for observation set." TYPE C2 UNITS "BASE_36" END_USER_TYPE USER_TYPE OBSET_SPEC_TYPE DESCRIPTION "This is the full specification of an observation set (See OBSET_ID_TYPE). The specification is: ppppp:oo:vv where ppppp = proposal id oo = obset id vv = version num" TYPE C11 END_USER_TYPE USER_TYPE ALIGN_ID_TYPE DESCRIPTION "An alignment is a collection of exposures that are grouped together based upon changes in the target/aperture combinations and the length of a visibility period. That is, a separate alignment is generated if the target or aperture changes between eposures or the sum of the exposure times is greater than a visibility period. An alignment is identified by a 2 character base 36 string. This field, typically called 'alignment_id', will often contribute to the index on a relation together with a proposal_id, obset_id, version_num and possibly other fields. In the PMDB an alignment will minimally consist of alignment-specific data plus exposure, and target data, detailed below." TYPE C2 UNITS "BASE_36" END_USER_TYPE USER_TYPE ALIGN_SPEC_TYPE DESCRIPTION "This is the full specification of an alignment (See ALIGN_ID_TYPE). The specification is: ppppp:oo:aa:vv where ppppp = proposal id oo = obset id aa = alignment id vv = version num" TYPE C14 END_USER_TYPE USER_TYPE EXPOSURE_ID_TYPE DESCRIPTION "An exposure is a separate instrument operation using a instrument/target combination. Together with target data, this is the smallest entity in the PMDB to comprise a proposal. An exposure is identified by a 2 character base 36 string. This field, typically called 'exposure_id', will often contribute to the index on a relation together with a proposal_id, obset_id, alignment_id, version_num and possibly other fields." TYPE C2 UNITS "BASE_36" RANGE "00..ZZ" END_USER_TYPE USER_TYPE EXPOSURE_SPEC_TYPE DESCRIPTION "This is the full specification of a scheduling unit (See EXPOSURE_ID_TYPE). The specification is: ppppp:oo:aa:ee:vv where ppppp = proposal id oo = obset id aa = alignment id ee = exposure id vv = version num" TYPE C17 END_USER_TYPE USER_TYPE VERSION_NUM_TYPE DESCRIPTION "All observation sets, and their associated alignments and exposures have a version number. The scheduling unit containing an observation set inherits the version number of the observation set. When the scheduling unit contains more than one observation set the version numbers must all be the same. A version number is identified by a 2 character base 36 string. This field, typically called 'version_num', will often contribute to the index on relation together with a proposal_id, obset_id, and possibly alignment_id, exposure_id, and other fields. Version numbers are always set to '01' operationally. They currently are only utilized in testing." TYPE C2 UNITS "BASE_36" RANGE "00..ZZ" END_USER_TYPE USER_TYPE VISIT_ID_TYPE DESCRIPTION "A visit is a synonym for a scheduling unit, and is more of a front-end system/proposal instruction term. The visit identifier is a 2 character string, while the scheduling unit identifier which is a 7 character string. The visit idenitifier will always be the last two characters of the SU identifier. Following is the definition of visit in the Proposal Instructions. A visit is an exposure or a series of consecutive exposures, with overheads, on a given target, and may consist of the following parts: 1. guide-star acquisition (to point HST at the target) 2. target acquisition (to place the target in an instrument aperture) 3. science exposure(s) (to obtain the data) 4. instrument overheads (to set up the instrument and read out the data) 5. instrument calibrations/overheads (if more than standard calibration is required) If the visit lasts more than one orbit, it will continue with the following for each subsequent orbit: 6. guide-star re-acquisition (to keep HST pointed and locked after earth occultation) 7. science exposure(s) 8. instrument overheads 9. instrument calibrations/overheads A new visit is required whenever a new set of guide stars must be acquired." TYPE C2 END_USER_TYPE USER_TYPE SUNIT_ID_TYPE DESCRIPTION "A scheduling unit consists of one or more observation sets and is the fundemental object which is placed on SPSS calendars. A synonym for a scheduling unit in SPSS is a 'candidate.' A scheduling unit is identified by a seven character base 36 string. For operational proposals the first five characters are the proposal id (with a leading zero). This field, typically called 'sunit_id', will often contribute to the index on relation together with a proposal_id, obset_id, version_num, and possibly other fields. In the PMDB a scheduling unit will minimally consist of scheduling unit-specific data plus observation set, alignment, exposure, and target data. SU is a common acronym for a scheduling unit." TYPE C7 END_USER_TYPE USER_TYPE SUNIT_SPEC_TYPE DESCRIPTION "This is the full specification of a scheduling unit (See SUNIT_ID_TYPE). The specification is: sssssss:vv where sssssss = sunit id vv = version num" TYPE C10 END_USER_TYPE USER_TYPE TARGET_ID_TYPE DESCRIPTION "The target identifier defines the astronomical object to be observed. The target name can be up to 15 characters and is derived from the proposal id with a unique number for the object within the proposal, i.e. for proposal 04931 the 5th target would be 4931_5. Within the database relations, the target field is typically called 'target_id'. It will often contribute to the index on relation together with a proposal_id, and possibly other fields." TYPE C15 END_USER_TYPE USER_TYPE LINK_SET_ID_TYPE DESCRIPTION "A linked set is a collection of two or more scheduling units with a defined timing relationship between the scheduling units. A link set is named, and can be up to 16 characters. Within the database relations that store link set information, the field is typically called 'link_set_id', and it will often contribute to the index on relation." TYPE C16 END_USER_TYPE USER_TYPE AF_REVISION_NUMBER_TYPE DESCRIPTION "A number incremented each time the assignment file (AF) is regenerated. It is used to keep track which version was last generated." TYPE I2 END_USER_TYPE !!!!!!!!!!!!!! ! ! Guide Star Types ! !!!!!!!!!!!!!! USER_TYPE GS_ID_TYPE DESCRIPTION "The first five characters of the guide star id represent a region id, and the second five, an id of a star within that region. The sky was divided into approximately 9500 regions for the creation of the guide star catalog; it is these region numbers that are used for the region id." TYPE C10 END_USER_TYPE USER_TYPE GS_PAIR_ID_TYPE DESCRIPTION "The guide star pair id consists of the guide star ids of the dominant and subdominant stars, and the FGS numbers. The dominant star is listed first, and is the star that controls the pointing of the telescope. The subdominant star controls the roll. The field is formatted as follows: characters ---------- 1-10 : the guide star id of the dominant star (GS_ID_TYPE) 11 : 'F', which stands for FGS 12 : the integer identifier of the FGS (1, 2, or 3) 13-22 : the guide star id of the subdominant star (GS_ID_TYPE); or a string of '0's for a 'pair' with only one star, resulting from a single FGS guide star request 23 : 'F', which stands for FGS 24 : the integer identifier of the FGS (1, 2, or 3); or 0, resulting from a single FGS guide star request" TYPE C24 END_USER_TYPE !!!!!!!!!!!!!!!!!!!! ! ! C&C List/SMS Types ! !!!!!!!!!!!!!!!!!!!! USER_TYPE CCLIST_ID_TYPE DESCRIPTION "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. Example activities include slews, PCS aquisitions, small angle maneuvers, science, TDRS contacts, tape recordings, science instrument reconfigurations, and others. When a C&C List is saved in SPSS (via the CCLIST/SAVE comand) it receives an identifier. The identifier can be up to 9 characters long. Within operations, the C&C list naming convention is: yydddnxx where yy = last two digits of the year ddd = day of year of start of calendar n = length of calendar in days (usually 7) xx = unique identifier within above info. Within the database relations, this field is typically called 'cclist_id', and will often contribute to the index on the relation together other fields." TYPE C9 END_USER_TYPE USER_TYPE CCLIST_VERSION_NUM_TYPE DESCRIPTION "C&C list files have a version number associated with them. The version number is incremented by one as each version of a C&C List is saved (via CCLIST/SAVE). Operationally, version numbers for C&C Lists are not used, meaning they never in practice create C&C Lists with a version number higher than one." TYPE I2 END_USER_TYPE USER_TYPE ORBIT_FILE_ID_TYPE DESCRIPTION "The orbit file is a major data structure within SPSS that contains ephemeris information for the HST and two Tracking and Data Relay Spacecraft (designated as TDRS East and West) for a specific time period. It also contains ascending node crossing times, Earth shadow crossing times, and multiple SAA contour crossing times. Raw ephemeris data files are provided by PASS for the HST and TDRS spacecraft. The WEREADX program catalogs and converts the data to a format used by the PEFFIT program. PEFFIT generates a set of Least Squares Fit coefficients from this data and stores them in the PMDB. The ORBFILE/CREATE program generates an Orbit File from these coefficients. The Orbit File is used by many SPSS programs for scheduling related calculations involving the positions of HST and the TDRS spacecraft" TYPE C9 END_USER_TYPE USER_TYPE ORBIT_FILE_VERSION_NUM_TYPE DESCRIPTION "Orbit Files have a version number associated with them. The version number is incremented by one as each version of an orbit file is created (via ORBFILE/CREATE). Operationally, version numbers for orbit files are always 01." TYPE I2 END_USER_TYPE USER_TYPE EPHEMERIS_FILE_TYPE DESCRIPTION "Filename of ephemeris file produced by the WEREADX program. The filename can take one of the following forms: File Type Filename ------------------------------------------ ST7WP SPSSPEF:ST7WP_YYDDD.DAT ST9MP SPSSPEF:ST9MP_YYDDD.DAT STDEF SPSSPEF:STDEF_YYDDD.DAT TDRSaaa SPSSPEF:TDRSaaa_YYDDD.DAT Where YY = Start of file Year DDD = Start of file Day number aaa = West Longitude of TDRS (degrees) SPSSPEF is a VMS logical." TYPE C*128 END_USER_TYPE USER_TYPE EPHEMERIS_FILE_VER_TYPE DESCRIPTION "This is the version number of the ephemeris file. Generally, this will be '1'." TYPE I*2 END_USER_TYPE !!!!!!!!!!!!!!!!! ! ! SI Types ! !!!!!!!!!!!!!!!!! USER_TYPE SI_ID_TYPE DESCRIPTION "This is the identifier type for a Science Instrument (SI). The current 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" TYPE C4 DISCRETE "FOC", "HRS", "WFII", "FGS", "NIC", "STIS", "CSTR" END_USER_TYPE USER_TYPE SI_DETECTOR_TYPE DESCRIPTION "Each science instrument may have its own unique set of detectors. A detector is ." TYPE C4 END_USER_TYPE USER_TYPE SI_CONFIG_STATE_TYPE DESCRIPTION "The state of an SI denotes what configuration a particular science instrument is in blah blah blah ..." TYPE C8 END_USER_TYPE !!!!!!!!!!!!!!!!! ! ! Time Types ! !!!!!!!!!!!!!!!!! USER_TYPE FULL_SOGS_CHAR_TIME_TYPE DESCRIPTION "This is the standard SOGS output time in full precision in the following format - yyyy.ddd:hh:mm:ss.sss where yyyy = year ddd = day of year hh = hours mm = minutes ss.sss = seconds" TYPE C21 UNITS "UTC" RANGE "1980.001:00:00:00.000..2015.001:00:00:00.000" END_USER_TYPE USER_TYPE SOGS_CHAR_TIME_TYPE DESCRIPTION "This is the standard SOGS output time in the following format - yyyy.ddd:hh:mm:ss where yyyy = year ddd = day of year hh = hours mm = minutes ss = seconds" TYPE C17 UNITS "UTC" RANGE "1980.001:00:00:00..2015.001:00:00:00" END_USER_TYPE USER_TYPE SOGS_INT_TIME_TYPE DESCRIPTION "This is the compact representation of the SOGS character time. It is the integer number of seconds past January 1, 1980. There are software mechanisms and SYBASE formatting mechanisms for performing the conversion from integer to the more readable, friendly string representation (yyyy.ddd:hh:mm:ss or yyyy.ddd:hh:mm:ss.mmm)." TYPE I4 UNITS "UTC" END_USER_TYPE USER_TYPE FULL_TIME_STAMP_TYPE DESCRIPTION "This is the standard SOGS output time field that is used to 'time stamp' a record. Time stamping a record means putting in the current system time into the field and that will designate the last time the record or some process was updated or run. See description for the FULL_SOGS_CHAR_TIME_TYPE for format details. The data type of this field will be changed in the future to a SYBASE date time datatype." TYPE C21 UNITS "UTC" END_USER_TYPE USER_TYPE TIME_STAMP_TYPE DESCRIPTION "This is the standard SOGS output time field that is used to 'time stamp' a record. Time stamping a record means putting in the current system time into the field and that will designate the last time the record or some process was updated or run. See description for the SOGS_CHAR_TIME_TYPE for format details. The data type of this field will be changed in the future to a SYBASE date time datatype." TYPE C17 UNITS "UTC" END_USER_TYPE USER_TYPE BRIEF_TIME_STAMP_TYPE DESCRIPTION "This is the shortened standard SOGS output time field that is used to 'time stamp' a record. Time stamping a record means putting in the current system time into the field and that will designate the last time the record or some process was updated or run. The format of the field is yyyy.ddd where yyyy = year ddd = day of year" TYPE C8 UNITS "UTC" RANGE "1980.001..2015.001" END_USER_TYPE USER_TYPE INT_TIME_STAMP_TYPE DESCRIPTION "This is an integer representation of a standard SOGS time field that is used to 'time stamp' a record. Time stamping a record means putting in the current system time into the field and that will designate the last time the record or some process was updated or run. See description for the SOGS_INT_TIME_TYPE for format details. The data type of this field will be changed in the future to a SYBASE date time datatype." TYPE I4 UNITS "UTC" END_USER_TYPE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ! SMS Generation/Instruction Expansion Types ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! USER_TYPE TABLE_NAME_TYPE DESCRIPTION "This field holds the name of a table, and is seen in many of the qg* relations. A table is one of the instruction types ('TBL'). A table statement provides a convenient mechanism for loading table data into the memory of the NSSC-1, DF-224, Co-Processor, and/or SI microcomputers through the SMS. The table format, and optionally, a set of pre-defined parameter values are defined by PDB (and the data gets generated by IMTOOL). The table name is the name of this PDB table." TYPE C8 END_USER_TYPE USER_TYPE INSTRUCTION_NAME_TYPE DESCRIPTION "This is the instruction name or mnemonic. Instruction names are user determined (IM) or pre-defined from the ST PDB tape. Often they are named according to functionality. An instruction name must be unique within the relation." TYPE C12 END_USER_TYPE USER_TYPE PREC_CHECK_VALID_TYPE DESCRIPTION "This flag indicates the validity of a precedence checker table's records where: V : all records in this relation are valid; I : some records in this relation are invalid." TYPE C1 DISCRETE "I", "V" END_USER_TYPE USER_TYPE SMS_ID_TYPE DESCRIPTION "This is the filename of the Science Mission Specification (SMS) file. The name and version create a unique key for referring to an SMS. Other SMS related files with the same SMS_ID and version are identified by filetype. This id is the same as the CCLIST_ID." TYPE C9 END_USER_TYPE USER_TYPE SMS_VERSION_NUM_TYPE DESCRIPTION "SMS files have a version number associated with them. The version number is incremented by one as each version of an SMS is generated (via SMSG/Generate). Operationally, version numbers for SMSes are not used." TYPE I2 END_USER_TYPE USER_TYPE PASS_SMS_ID_TYPE DESCRIPTION "This is the name of the PASS SMS as generated by SMSG/Send. The naming convention is: Sadddnpr where: S = source (S for SSC/STSCI) a = alternate code (A-Z), default = 'A' ddd = day-of-year of SMS start time (from START parameter) n = year sent (base 36: 0-9,A-Z), modulus 1980 p = patch number (base 36), default = 0, for a given alternate code, day-of-year, and same day code, incremented for each patch of an SMS r = revision number (base 36), default = 0, for a given alternate code, day-of-year, and same day code, incremented for each revision of an initial or alternate SMS." TYPE C8 END_USER_TYPE !!!!!!!!!!!!!! ! ! Other Types ! !!!!!!!!!!!!!! USER_TYPE YES_NO_FLAG_TYPE DESCRIPTION "This field is a Yes/No flag database field. Read the field description to determine what 'Y' (or 'y') means, 'N' (or 'n') means, and what a blank field maps to if anything." TYPE C1 DISCRETE "Y", "y", "N", "n" END_USER_TYPE USER_TYPE PAR_ALLOWED_TYPE DESCRIPTION "At the scheduling unit, observation set, and alignment levels are flags of this type that control how a primary SU, OBSET, or alignment can handle a parallel SU's activites. This is a 4-way flag. 'Y' means parallel SUs can be scheduled on top of the SU, OBSET, or alignment. 'A' means only attached, targeted parallel SUs can be scheduled on top of the SU, OBSET, or alignment. 'I' means only non-targeted SUs can be scheduled on top of the SU, OBSET, or alignment. 'N' means no parallel SUs can be scheduled on top of the SU, OBSET, or alignment. " TYPE C1 DISCRETE "Y", "A", "I", "N" END_USER_TYPE USER_TYPE PDB_ID_TYPE DESCRIPTION "This field contains the name of a Project Database (PDB). The PDB name is controlled by SCIOPSDB. It gets changed with each new installation of the PDB. Many tables contain this identifier and could support multiple datasets that are indexed by this PDB identifier." TYPE C8 END_USER_TYPE USER_TYPE COMMENT_PAGE_TYPE DESCRIPTION "This field is a page number for a PMDB comments relation and enables multiple pages of comment text to be entered." TYPE C2 RANGE "01..03" END_USER_TYPE USER_TYPE COMMENT_LINE_TYPE DESCRIPTION "This is a line of text that can be found in one of the PMDB comment relations. There are no rules on the format of the text within the string, and it may be blank. A comment relation will normally have 24 fields of this type that enable a record to hold a fair amount of information (on whatever the subject is)." TYPE C80 END_USER_TYPE USER_TYPE SAA_MODEL_TYPE DESCRIPTION "This field contains the SAA model id as it applies to a particular relation. The SAA, or South Atlantic Anomaly, is a region of the earth over which there is a magnetic disturbance that affects some of the instruments onboard the HST. Because of this there are certain events that have to avoid occurring during an SAA passage. Note that the different instruments can use different SAA models (therefore will have different SAA Model IDs). SAA ID '00' is the TDRS Multiple Access Return (MAF) Radio Frequency Interference (RFI) model. SAA ID '01' is the TDRS S-Band Single Access Return (SSAR) RFI model. SAA ID's '02' through '99' are SAA contour models for HST and other spacecraft. Relation 'wvvert_type' describes each SAA contour." TYPE C2 RANGE " ", "00..99" END_USER_TYPE USER_TYPE PCS_MODE_TYPE DESCRIPTION "This field indicates the PCS mode for the observation set. GYRO = neither fgs nor FHST is used, FGS = FGS(s) only are used, FHST = FHST(s) only are used, BOTH = both FGS and FHST may be selected by the acquisition scenario." TYPE C4 DISCRETE "GYRO", "FGS", "FHST", "BOTH" END_USER_TYPE USER_TYPE GSACQ_SCENARIO_NAME_TYPE DESCRIPTION "This field is the scenario name associated with an obset's guide star acquisition or re-acquisition. The scenario will have a set of characteristics associated with it that will impose limitations on the GS and GS pair selection process that will eventually be used in the generation of acquisition data sets stored in the relation WGACQUIS. Acquisition data sets control the timing of acquisition and reacquisition activities and also specify observation set level roll constraints. This field establishes the link between the relations QBS_OBSET, QBACQS, QBACQD_DEF" TYPE C8 END_USER_TYPE USER_TYPE LRP_NAME_TYPE DESCRIPTION "This field contains the Long Range Plan (LRP) name created by SPIKE that associates a group of plan windows for an SU or group of SUs. The scheduling unit is intended to schedule some time within the LRP timeframe." TYPE C15 END_USER_TYPE USER_TYPE LOCK_FIELD_TYPE DESCRIPTION "This field is a filler field used for updating the locking tables." TYPE C3 END_USER_TYPE USER_TYPE OPUS_ASSOCIATION_ID_TYPE DESCRIPTION "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. 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 dataset counter (a) that is always 0 (for the first product_id of the association which is always 0). For example, the first NICMOS association for program ABC and obset 01 would be NABC01010." TYPE C9 END_USER_TYPE USER_TYPE OPUS_PRODUCT_ID_TYPE DESCRIPTION "This field identifies an OPUS product. An association product is a dataset, distinct from any exposure dataset, that is generated by pipeline calibration during concurrent processing of multiple exposures. Exposures are associated in order to generate products. This field is a single digit base 36 number: 0, 1, ..., Z, and is set by OPUS. Note STIS can only have one product per association while NICMOS can have as many as nine products." TYPE C1 END_USER_TYPE