User_guide User Guide
User Manual: user_guide user guide pdf - FTP File Search (7/20)
Open the PDF directly: View PDF 
.
Page Count: 154 [warning: Documents this large are best viewed by clicking the View PDF Link!]
CSC/SD-92/6076R6.4
International Solar-Terrestrial
Physics (ISTP) Program Central Data
Handling Facility (CDHF) Users Guide
Release 6.4
Prepared for
National Aeronautics and Space Administration
Goddard Space Flight Center
Greenbelt, Maryland
Under
Contract NAS5-31000
Subcontract HQ-001057
Task Assignment 16 426
August 1997
CSC/SD-92/6076R6.3
International Solar-Terrestrial Physics (ISTP)
Program Central Data Handling Facility (CDHF)
Users Guide
Release 6.3
Prepared for
GODDARD SPACE FLIGHT CENTER
By
COMPUTER SCIENCES CORPORATION
Under
Contract NAS5-31000
Subcontract HQ-001057
Task Assignment 16 426
August 1997
Prepared by:
William R. Whitman Date
for CSC ISTP CDHF Software Team
Reviewed by:
S. Sekira (Code 514.1) Date
ISTP CDHF Project Manager
J. Garrahan (CSC) Date
Software Engineering Manager
Concurrence by:
R. Schneider (Code 407.0) Date
ISTP CDHF System Manager
Approved by:
P. Kay (CSC) Date
Senior Project Manager
E. Beard (Code 514) Date
Branch Head
iii
ABSTRACT
This document provides documentation for the International Solar Terrestrial Physics (ISTP)
Program Central Data Handling Facility (CDHF) User Interface (UI). This guide provides an
overview of the functions of the ISTP CDHF and is a user reference manual describing the
services available to the general CDHF science user community.
The ISTP Project homepage (http://www-istp.gsfc.nasa.gov) contains links to online versions of
ISTP documentation (including this document) as well as other information useful to ISTP
investigators.
iv
v
CONTENTS
QUICK TOUR OF THE CDHF USER INTERFACE
SECTION 1—INTRODUCTION
1.1 Purpose ........................................................................................................................1
1.2 Scope.............................................................................................................................1
1.3 ISTP Program Overview...............................................................................................1
1.4 Applicable Documents..................................................................................................3
1.5 Document Organization................................................................................................3
SECTION 2—CDHF SYSTEM OVERVIEW
2.1 Description of CDHF....................................................................................................5
2.2 System Software Configuration....................................................................................5
2.3 External Interfaces........................................................................................................6
SECTION 3—CDHF SUPPORT OF ISTP USERS
3.1 Obtaining an Account on the CDHF ............................................................................9
3.2 Obtaining Help..............................................................................................................9
3.3 Data Products................................................................................................................10
3.3.1 Science Data Files............................................................................................10
3.3.2 Report Files......................................................................................................20
3.3.3 Online Documentation.....................................................................................20
3.3.4 Data Rights and Computer Security.................................................................21
3.4 User Interface Overview...............................................................................................21
3.4.1 Invoking the User Interface..............................................................................21
3.5 How To Use SQL*Forms.............................................................................................22
3.5.1 Setup Requirements .........................................................................................22
3.5.2 How To Use a Menu........................................................................................24
3.5.3 Form Objects....................................................................................................24
3.5.4 Function Keys..................................................................................................27
3.5.5 Online Help......................................................................................................31
3.5.6 Form Modes.....................................................................................................33
3.5.7 Form Navigation..............................................................................................33
3.5.8 How To Perform a Query.................................................................................35
3.5.9 How To Modify the Database..........................................................................38
3.5.10 Editing Capabilities..........................................................................................40
3.5.11 Screen Prints ....................................................................................................40
3.5.12 Screen Redisplay..............................................................................................40
vi
3.5.13 Common Errors................................................................................................40
3.6 How To Use ORACLE Reports ...................................................................................43
3.6.1 Defining the Report Output Directory.............................................................43
3.6.2 Selecting the Report Mode...............................................................................43
3.6.3 Selecting the System Printer............................................................................43
3.6.4 Activating a Report..........................................................................................44
3.6.5 Displaying a Report on the Screen...................................................................44
3.6.6 Printing a Report..............................................................................................44
3.6.7 Transferring a Report.......................................................................................44
SECTION 4—USER INTERFACE SYSTEM
4.1 CDHF Queries and Reports..........................................................................................48
4.1.1 Introduction......................................................................................................48
4.1.2 Database Interface System Forms (Including KPGS Certification) ................48
4.1.3 Database Interface System Reports..................................................................65
4.2 User Data Transfer Services.........................................................................................71
4.2.1 Data Transfer Request Types...........................................................................71
4.2.2 Data Transfer Process Overview......................................................................71
4.2.3 Science Data Files Access Privileges...............................................................72
4.2.4 Mail Addresses.................................................................................................72
4.2.5 Destination Addresses......................................................................................73
4.2.6 Data Transfer Services User Interface.............................................................75
4.2.7 Data Transfer Services Error Handling and Recovery.....................................92
4.3 Update Key Parameter Quality Information.................................................................95
4.3.1 Key Parameter Quality Update Form...............................................................95
4.3.2 Process Key Parameter Update File.................................................................99
4.4 Create Decommutation Specifications Form................................................................100
4.5 Invoke Theory Programs ..............................................................................................104
4.6 Extract NRT LZ Data ...................................................................................................104
4.6.1 Query LZ Form................................................................................................104
4.6.2 EXTRACT_NRT_LZ Command.....................................................................106
4.7 Plot Orbit Data..............................................................................................................107
4.7.1 Orbit Plot Form................................................................................................108
4.8 Access the NEWS Bulletin Board................................................................................110
APPENDIX A—KEYBOARD MAPPINGS
APPENDIX B—NEAR-REAL-TIME DATA ACCESS
vii
APPENDIX C—CDHF PUBLIC SOFTWARE DIRECTORY
INDEX
ACRONYMS
LIST OF FIGURES
1–1 ISTP Mission Orbit Configuration........................................................................................... 2
1–2 Documentation Tree for the ISTP CDHF ................................................................................ 3
2–1 ISTP CDHF Context Diagram................................................................................................. 7
3–1 CDHF User Interface Main Menu............................................................................................ 22
3–2 SQL*Forms Objects................................................................................................................. 25
4–1 CDHF User Interface Main Menu............................................................................................ 47
4–2 Queries and Reports Menu Tree .............................................................................................. 49
4–3 User Data Transfer Services Menu .......................................................................................... 75
4–4 Update Key Parameter Quality Menu...................................................................................... 95
4–5 KP Quality Update File Format ............................................................................................... 100
4–6 ISTP Theory Programs Menu .................................................................................................. 104
LIST OF TABLES
4–1 Valid Byte Ranges.................................................................................................................... 102
4–2 Supported Graphics Devices.................................................................................................... 109
QT–1
QUICK TOUR OF THE CDHF USER INTERFACE
This quick-tour segment can help you quickly and easily learn to use the basic functions of the
CDHF User Interface. If you are already familiar with the interface, then you might want to jump
to the section titled "Getting Things Done." However, the section titled "Keys to Success" may
provide some helpful hints even to experienced users. Those users unfamiliar with the User
Interface or having trouble setting up their terminal to be compatible with the interface should
follow the advice of the doormouse in Alice in Wonderland and "start at the beginning and go on
until the end."
Getting Started
To use the CDHF User Interface, you first need an account on the computer system. If you do
not have one, you can obtain one by completing an online application. Either use Telnet to
istp1.gsfc.nasa.gov (128.183.92.58) or SET HOST ISTP1 (15461) and log in with the username
APPLY. You will be prompted through a set of questions and your application submitted for
approval. Once your account has been approved and established, you will be notified of your
username and initial password. Now that you have an account on the computer system, you can
start to use the User Interface.
Setting Up Your Terminal
You will communicate with the CDHF User Interface using the keyboard of your display device.
Keyboards come in many shapes, sizes, and layouts; and display devices can emulate a number
of standard terminal types. The CDHF User Interface provides support for three different classes
of terminals: (1) VT100 or VT100 emulators; (2) VT200, VT300, and their emulators; and (3) all
others.
If you have a Sun Workstation but do not have a VT100, VT200, or VT300 emulator, you might
want to obtain a copy of a terminal emulation package called VTTOOL. You can find a
compressed UNIX tape archive (tar) file containing this package on the CDHF in
SYS$PUBLIC:[VTTOOL], along with a README file with instructions for installing the
emulator on your Sun Workstation.
If you do not know which type of terminal your display device emulates, then proceed to the next
section, “Starting the interface.” The procedure that starts the User Interface attempts to
determine and set the appropriate terminal class for your display device.
If you have established the terminal class to which your display device belongs, place the
following command in your LOGIN.COM file:
DBI_TERM_TYPE:== "term_class"
where term_class is one of cdhf100 (for VT100 terminals and most VT100 emulators), cdhf220
(for VT200 terminals, VT300 terminals, and their emulators), or cdhf100e (for all other types of
terminals and VT100 emulators that do not work properly with cdhf100 classes).
For example:
DBI_TERM_TYPE:== "cdhf220"
QT–2
Because keyboards and terminal emulators can vary widely in the key mappings they use for the
keypad and the function keys, do not be discouraged if you initially have difficulty locating the
correct keys for your display device. If the cdhf100 or cdhf220 class does not work, use the
cdhf100e class. If possible, try a different terminal emulator package. IBM PCs and PC clones
have the widest range of available keyboards and have been the most difficult display devices for
which to provide keyboard mappings. Check the documentation for your terminal emulator
package to see if it provides a mapping from your keyboard to a DEC VT100 or VT200-style
keyboard. If you still have problems, contact the CDHF staff with the following information: the
display device and the emulator (if any) you are using and your method of accessing the CDHF
(dial-up or network). See “Whom Do You Call” for a list of people to call for help.
Starting the User Interface
The CDHF User Interface supports a NOVICE/EXPERT mode. By default, users are in
NOVICE mode. NOVICE mode prompts a user through the steps required to properly set up and
configure a session for the interface. If you have already defined your terminal class (described
in the previous section), execute the following command and place it in your LOGIN.COM file:
$ DEFINE CDHF_USER_LEVEL "EXPERT"
This action causes the startup procedure to skip the interactive steps that describe how to set up
your terminal.
Once you have determined the display-device class, turn to the appendixes and make a copy of
the keyboard mapping diagram that corresponds to the display device you are using. Place the
diagram near your terminal so you can refer to it until you have learned some of the basic key
mappings.
To actually start the User Interface, type the following command:
CDHF_UI
This action initiates the procedure that invokes the User Interface and opens the User Interface
main menu. However, if you are in NOVICE mode, you will see the terminal setup dialog.
The following table lists the available main menu items with a brief description of their
functions:
Menu Item Description
CDHF Queries and Reports Query the CDHF catalog for information and/or generate reports.
Data Transfer Services Request data files for transfer.
Update Key Parameter Quality
Information Update key parameter quality flag in the CDHF catalog.
Certify Key Parameter Generation
Software Set a flag indicating Key Parameters generated by the specified
program are suitable for distribution
Decommutation Specifications Create, modify, or delete decommutation specifications.
QT–3
Invoke Theory Programs Display menu of available theory investigation programs.
QT–4
Menu Item Description
Extract NRT Level-zero Data Extract data from WIND or POLAR near-real-time telemetry files.
Plot Orbit Data Generate plots of orbit data.
Access the NEWS Bulletin Board Run the NEWS bulletin board.
Keys to Success
You will navigate through two types of screens in the User Interface. The first is a simple menu
of items. In the menus, use the cursor keys to select the desired item. Invoke the item by using
the [RETURN] key. The second type of screen is a form that contains fields for querying and
displaying information. (Keyboard mappings are important to forms). The table below lists the
core set of functions and their descriptions. These functions, along with the special function
keys, are used 90 percent of the time. Functions not listed here but mentioned elsewhere in this
guide are described as needed. Altogether, 50 keys control the forms with some keys being more
important than others. A full list of keys and functions appears in the ISTP CDHF User’s Guide.
Function Description
Exit/Cancel Exits the current menu, form, or pop-up window. Cancels the current function.
Abort [CONTROL] Y usually gets you completely out of the User Interface but should not
be used unless you are hopelessly lost.
Refresh Redraws the current screen.
Show Keys Provides key mappings table (the keystroke for this is always [CONTROL] K). Note
that the table presented shows the key mappings for the defined terminal class. If
cdhf100 has been defined, then the mappings displayed are for a DEC VT100
keyboard. If you are using an emulator with a non-VT100-like keyboard, then your
key mappings may be different than shown.
Next Field Moves the cursor to next enterable field on the form.
Previous Field Moves the cursor to the previous enterable field on the form.
Up Moves the cursor to the next record.
Down Moves the cursor to the previous record.
List Displays a list of valid values for the current field (if available).
Next Block Moves cursor to the first enterable field in the next block of the form. Also used to
execute a query for criteria entered in the current block and display results in the next
block (see sample queries under “Getting Things Done”).
QT–5
Function Description
Previous Block Moves the cursor to the first enterable field in the previous block.
Insert/Replace Toggles between INSERT and REPLACEMENT character modes. In general,
REPLACEMENT should be used.
Menu Activates the pull-down menu items, allowing an alternative method to invoke the
form's functions.
Commit/Accept Used to commit changes, enter new information in the database, select from a list of
values, and to activate reports.
Special Function
Keys Four special function keys which are defined as needed, provide special functions on
forms. When needed, the keys and functions are described on the form.
A word about insert vs. replacement mode:
INSERT mode allows you to insert text at any point in a string. REPLACEMENT (or overstrike)
mode types over the existing text in a field. A common problem in using the User Interface is
trying to insert text into a field that is full. If you are in INSERT mode and try to type in a field
that is full, nothing happens. The mode you are in is indicated at the bottom right corner of each
form (<Insert> or <Replace>). To avoid confusion, stay in REPLACEMENT mode. Switch to
INSERT mode only when you need to, and then switch back to REPLACEMENT mode. Use the
INSERT/REPLACE key to toggle between INSERT and REPLACEMENT modes.
Getting From Here to There
Currently, to navigate through the User Interface you must go up and down the menus to reach
the desired form. A future release of the User Interface will let you jump directly to a form
without having to step through the menus.
Getting Things Done
This section contains step-by-step examples that should help you perform queries, generate
reports, request data files for transfer, and perform other functions available through the User
Interface. Before reading these examples, put a copy of the appropriate key mappings diagram
from Appendix A in front of you so you can refer to it.
Setting Defaults
One of the first things you will want to do is verify your default information. Default information
set up for your account is used to pre-fill certain fields on the User Interface forms.
QT–6
1. Select the "CDHF Queries and Reports" option from the main menu.
2. Select the "ISTP Users and Privileges Form" option.
3. Press [TAB] once to place you in the "Query All Versions" field. If this field is set to
Y, you see all versions of data files when you perform a query. If it is set to N, you
only see the most recent version of a data file. In general, you will want to look at
only the most recent version of a file. Viewing all versions of a file is useful when
you are interested in the reprocessing history of a data file.
4. Press [TAB] again to move to the "Default Mission Name" field. Press the List key
to obtain a list of missions from which you can choose. Highlight the mission name
you wish to have set as your default, and press [RETURN] to fill in the field.
5. Press [TAB] again to advance the cursor to the “Data Type” field. Press the List key
to obtain a list of data types from which you can select, highlight the desired data
type, and press [RETURN] to fill in the field.
6. Press [TAB] again to advance to the "Default Descriptor" field. Press the List key to
obtain a list of descriptors from which you can select, highlight the desired
descriptor, and press [RETURN] to fill in the field.
7. Press the Commit/Accept key to commit the changes to the database.
8. Press the Exit/Cancel key to exit.
Making Queries and Generating Reports
Numerous queries and reports can be generated through the User Interface. This section contains
examples of some of the more widely used queries and reports. One of the characters often used
in the examples is the % character. It is a wildcard character and, if allowed in the field, causes
all values to be matched for that field. Note that the wildcard character, if used, must appear as
the first character in the field.
To obtain a list of all key parameter files for all missions during the time period
01-JUN-1993 through 01-JUL-1993, perform the following:
1. Select the "CDHF Queries and Reports" option from the main menu.
2. Select the "Data File Information Menu" option.
3. Select the "Science Data File Information Form" option.
4. Type % under Mission Name (if necessary, use the space bar to erase any
remaining text in the field).
5. Press [TAB] to advance to the next field.
6. Type K% under Data Type.
7. Press [TAB] to advance to the next field.
8. Type % under Descriptor (if necessary, use the space bar to erase any remaining
text in the field).
9. Press [TAB] to advance to the next field.
10. Type 01-JUN-1993 into the starting date field.
11. Press [Tab] to advance to the next field.
12. Type 01-JUL-1993 into the ending date field.
To check your default information and change the default data type, do the following:
QT–7
13. Press the Next Block key to move to the next block and perform the query. If
records are found in the database, they appear in the second block on the screen.
14. Press the Up and Down arrow keys to scroll through the records retrieved.
15. Press the Exit/Cancel key to exit.
The preceding query can also be performed for a specific instrument or mission or for a different
time range. Simply type the desired mission or instrument name into the appropriate field instead
of the wildcard character % (or use the list of values to choose from), or specify the desired time
range.
To generate a report identical to the preceding query, perform the following:
1. Select the "CDHF Queries and Reports" option from the main menu.
2. Select the "Data File Information Menu" option.
3. Select the "Data Files Stored Online Report" option.
4. Type % under Mission Name (if necessary, use the space bar to erase any
remaining text in the field).
5. Press [Tab] to advance to the next field.
6. Type K% under Date Type.
7. Press [Tab] to advance to the next field.
8. Type % under Descriptor (if necessary, use the space bar to erase any
remaining text in the field).
9. Press [Tab] to advance to the next field.
10. Type 01-JUN-1993 into the starting date field.
11. Press [TAB] to advance to the next field.
12. Type 01-JUL-1993 into the ending date field.
13. Press SF1 if you want the report generated in BATCH mode instead of the
default INTERACTIVE mode.
14. Press the Commit/Accept key to execute the query. The report will be written
to your home directory unless DBI_RPT_DIR is defined in your LOGIN.COM.
(Refer to Section 4.1.1.2, “Customizations,” of the ISTP CDHF User's Guide.)
15. In INTERACTIVE mode, you are prompted to display the report to the screen.
Answering Y causes the report to be displayed to your screen.
While viewing the report, press [CONTROL] Z to abort the displayed report, if desired.
Afterward you are prompted to print the report. Answering Y to this prompt causes the report to
be printed on a printer at the CDHF. For remote users, this is not desired so, in general, answer
N. The report file remains in the designated report directory (DBI_RPT_DIR or your home
directory by default).
Viewing processing information
The CDHF catalog contains information on the processing history of ISTP data products.
Information on the input files used to generate specific key parameter files and version
information on key parameter generation software is available. Following are a sample query and
a sample report for retrieving historical information about data files and programs.
QT–8
To list KPGS program history information for IMP-8 MAG, perform the following:
1. Select the "CDHF Queries and Reports" option from the main menu.
2. Select the "File Processing Information Menu" option.
3. Select the "Process Program Information Form" option.
4. Enter the program name IMP8_MAG_KP or press the List key to obtain a list
of programs from which you can select, highlight IMP8_MAG_KP, and press
[RETURN] to fill in the field.
5. Press the Execute Query key to execute the query.
6. Use the arrow keys to scroll through multiple entries, if they exist.
7. Press Exit/Cancel to exit or press Enter Query to enter a new query.
To generate a report on key parameter certification information for IMP-8 MAG,
perform the following:
1. Select the "CDHF Queries and Reports" option from the main menu.
2. Select the "Data File Information Menu" option.
3. Select the "Data File Certification Status Report" option.
4. Enter the mission name I8 or press the List key to obtain a list of the programs
from which you can select, highlight I8, and press [RETURN] to fill in the
field.
5. Press [TAB] to move to the next field.
6. Type MAG in the descriptor field.
7. Press [TAB] to advance to the next field.
8. Type 01-JUN-1993 into the starting date field.
9. Press [TAB] to advance to the next field.
10. Type 01-OCT-1993 into the ending date field.
11. Press the Commit/Accept key to execute the query. The report will be written
to your home directory unless DBI_RPT_DIR is defined in your LOGIN.COM.
(Refer to Section 4.1.1.2, “Customizations,” of the ISTP CDHF User's Guide.)
12. In INTERACTIVE mode, you are prompted to display the report to the screen.
Answering Y causes the report to be displayed to your screen.
Transferring Data Files
The ISTP CDHF provides for two types of file transfers: scheduled and standing. A scheduled
request is a one-time request for specific data files that is executed at a scheduled time. A
standing transfer is a general request for data files that is executed periodically on a schedule
defined by the user. The files to be transferred in a standing request are determined at the time
the request executes.
Data files can be transferred to the user’s directory on the CDHF (staged transfer) or directly to
the user’s remote computer system (direct transfer). The following examples use the staged
method of transfer. For information on setting up your computer system to accept direct
transfers, refer to Section 4.2.5 of the CDHF User’s Guide.
QT–9
Before trying to execute the following examples, obtain the name of your home directory on the
CDHF by typing SHOW LOGICAL SYS$LOGIN at the VMS system prompt. The destination
address you will use in the examples looks like the following address:
ISTP::disk:[dir]
where disk:[dir] is the disk and directory name of your home directory.
The following is an example of a scheduled request to transfer GEOTAIL orbit data
for 01-JUN-1993:
1. Select the "User Data Transfer Services" option from the main menu.
2. Select the "Create Transfer Request for Cataloged Science Files" option.
3. Type the execution date (the default is an immediate transfer).
4. Press [TAB] to advance to the next field.
5. A default Mail Address appears; modify it if desired.
6. Press [TAB] to advance to the next field.
7. A default Transfer Destination appears; set this to be your home directory as
described above.
8. Press the Next Block key to advance to the next block.
9. Type the mission identifier GE or press the List key to obtain a list of mission
names from which you can select, highlight GE, and press [RETURN] to fill
in the field.
10. Press [TAB] to advance to the next field.
11. Type the datatype OR or press the List key to obtain a list of data types from
which you can select, highlight OR, and press [RETURN] to fill in the field.
12. Press [TAB] to advance to the next field.
13. Type the descriptor DEF or press the List key to obtain a list of descriptors
from which you can select, highlight DEF, and press [RETURN] to fill in the
field.
14. Press [TAB] to advance to the next field.
15. Type 01-JUN-1993 into the Start Date field.
16. Press [TAB] to advance to the next field.
17. Type 01-JUN-1993 into the End Date field.
18. Press the Next Block key to move to the next block and perform the query. If
records are found in the database, they appear in the second block on the
screen.
19. Use the arrow keys to move to the file to be selected for transfer, and press SF1
to select individual files. Use SF2 to select all files in the list.
20. Press the Commit/Accept key to commit the request.
21. Press [RETURN] to acknowledge the request.
22. Press the Exit/Cancel key to exit.
QT–10
The transfer request is queued and executed at the specified time. After the request is executed,
an E-mail message providing the status of the transfer is sent to the address entered in step 5
above.
QT–11
To set up a staged standing transfer for GEOTAIL definitive orbit data, perform the
following:
1. Select the "User Data Transfer Services" option from the main menu.
2. Select the "Create Standing Request for New Science files" option.
3. Type the date and time of execution of the first execution of the standing
request.
4. Press [TAB] to advance to the next field.
5. A default Mail Address appears; modify it if desired.
6. Press [TAB] to advance to the next field.
7. A default Destination Address appears; set this to be your home directory as
described in the previous example.
8. Press the Next Block key to advance to the next block.
9. Type the mission identifier GE or press the List key to obtain a list of mission
names from which you can select, highlight GE, and press [RETURN] to fill
in the field.
10. Press [TAB] to advance to the next field.
11. Type the datatype OR or press the List key to obtain a list of data types from
which you can select, highlight OR, and press [RETURN] to fill in the field.
12. Press [TAB] to advance to the next field.
13. Type the descriptor DEF or press the List key to obtain a list of descriptors
from which you can select, highlight DEF, and press [RETURN] to fill in the
field.
14. Press [TAB] to advance to the next field.
15. Type the effective catalog start date for request (must be no earlier than the
current date/time). The request looks for files cataloged after this date.
16. Press [TAB] to advance to the next field.
17. Type the time interval for the execution of the request. The value can be from
1 hour to 7 days and is entered as days or fractions of days.
18. Press the Commit/Accept key to commit the request.
19. Press [RETURN] to acknowledge the request.
20. Press the Exit/Cancel key to exit.
To remove a standing request from the request queue:
1. Select the "User Data Transfer Services" option from the main menu.
2. Select the "Query/Modify Standing Requests for New Science Files" option.
3. The standing transfer requests you have entered are displayed. Use the arrow
keys to view each request.
4. When you have the request displayed that you want to delete, press the Delete
Record key. You are asked if you really want to delete the record. Answer Y or
N and press [RETURN].
5. Press the Exit/Cancel key to exit.
QT–12
Extracting WIND Near-Real-Time Data
To extract near-real-time (NRT) data from an active message for WIND 3DP,
perform the following:
1. Select the "Extract NRT Level Zero Data" option from the main menu.
2. Type the mission identifier WI or press the List key to obtain a list of mission
names from which you can select, highlight WI, and press [RETURN] to fill
in the field.
3. Press [TAB] or [RETURN] to advance to the next field when the List key is
not used.
4. Type the descriptor or press the List key to obtain a list of descriptor names
from which you can select, highlight 3DP, and press [RETURN] to fill in the
field.
5. Press [TAB] or [RETURN] to advance to the next field when the List key is
not used.
6. Allow ACTIVE to remain as the File Type.
7. Press the Next Block key to query the database for the NRT LZ files.
(Note: The file WI_LZ_3DP.NRT will contain the data from the currently
active pass; however, if there is no active pass, this file will be empty.)
8. Press the SF1 key to select the WI_LZ_3DP.NRT active NRT file.
(Note: An “S” will appear in the Selected column, and times will appear in the
Start Date and End Date columns.)
9. To change the requested time range, press [TAB] to advance to the Start Date
field. Enter the start date and time for data to be extracted.
(Note: If a time is selected prior to the actual start of the message, the extracted
data will begin at the actual start time.)
10. Press [TAB] to advance to the End Date field. Enter the stop date and time for
the data to be extracted.
[Note: Only data that has been received can be extracted. For example, if a
real-time pass is scheduled to be captured from 2100 hours to 2300 hours, and
at 2200 hours a user performs an NRT extraction with a start time of 21:00:00
and an end time of 23:00:00, only 1 hour of data (21:00:00 to 22:00:00) will be
extracted.]
11. Press the Accept key to extract the NRT data and write it to your SYS$LOGIN
directory.
QT–13
Updating Key Parameter Quality Information
Authorized users are allowed to enter quality information on key parameter files into the CDHF
catalog. The examples below illustrate two mechanisms for performing these updates.
To update the key parameter quality information interactively, perform the
following:
1. Select the "Update Key Parameter Quality" option from the main menu.
2. Select the "Key Parameter Update Form" option.
3. Press the List key to obtain a list of mission names from which you can select,
highlight your selection, and press [RETURN] to fill in the field.
4. Press the List key to obtain a list of data types from which you can select,
highlight your selection, and press [RETURN] to fill in the field.
5. Press the List key to obtain a list of descriptors from which you can select,
highlight your selection, and press [RETURN] to fill in the field.
6. Enter the starting date for the query (or use the default).
7. Press [TAB] to advance to the next field.
8. Enter the ending date for the query (or use the default).
9. Press the Next Block key to execute the query. The results are displayed in the
second block of the form.
10. Use the SF1 key and the Up and Down keys to select the key parameter files
for which quality information and comments are to be entered.
11. Once the files have been selected, verify that the cursor is on one of the
selected files and press the SF4 key to display a form where quality and
comments may be entered. If the entry on which the cursor was positioned on
the previous form had quality and comment information already entered, this
information appears as defaults on this form.
12. To update the KP Quality Indicator, type Y.
13. Press [TAB] to advance to the next field.
14. Enter the quality information (GREEN, YELLOW, RED) or use the default.
15. Press [TAB] to advance to the next field. The Certify Date and User ID fields
are automatically filled in.
16. To update or enter the KP Comment, type Y.
17. Press [TAB] to advance to the next field.
18. Type in a one-line comment or press the Edit key to bring up a pop-up window
providing additional lines for comments.
19. Press the Accept key to commit the changes.
The second method of updating key parameter quality information is to supply the quality
information in a file, which is then processed to update the database. The following example
shows a method of creating a file with the appropriate information and then instructing the User
Interface to use that file to update the database.
QT–14
Updating key parameter quality information using a text input file
You can update key parameter quality information simultaneously for numerous files by using
information supplied in a text file. The format of the file is shown as follows (either upper or
lowercase may be used):
KEY PARAMETER QUALITY UPDATE FILE FOR USER [your username]
[logical filename]
[key parameter quality, RED, YELLOW, GREEN, or null string]
[comment]
[logical filename]
[key parameter quality, RED, YELLOW, GREEN, or null string]
[comment]
.
.
.
For example, the following file contains information to update three key parameter files. User
SMITH must have key parameter quality update privileges for GEOTAIL PWI key parameter
data. The first file is marked as PASS and has no comment in the command field. The second
and third files have comments in the comment field and are marked as FAIL and PASS,
respectively.
KEY PARAMETER QUALITY UPDATE FILE FOR USER SMITH
GE_K0_PWI_19930525_V01
GREEN
GE_K0_PWI_19930526_V01
RED
Excessive noise
GE_K0_PWI_19930527_V01
YELLOW
Only data after 0200GMT should be used
After creating the file with the update information, perform the following:
1. Select the "Update Key Parameter Quality" option from the main menu.
2. Select the "Process Key Parameter Update File" option.
3. Enter the name of the input file containing the key parameter quality update
information. If the file is in your default directory, you can simply enter the
filename; otherwise, you must enter the complete file specification.
4. Press the Accept/Commit key to start the update. You will receive status
information on the progress of the update.
5. When the update is complete, you are prompted to press [RETURN] to return
to the form.
Certifying Key Parameter Generation Software
Users with the privilege to update quality information for the key parameter files generated by a
KPGS program also have certification privilege for the program itself. A program that is certified
QT–15
indicates the program is believed to be generating key parameters suitable for distribution. An
uncertified program will generate key parameter files that will be cataloged in the system but
will not be sent to the DDF for distribution on CD-ROM. Once a KPGS program is certified, the
latest versions of all files generated by that program are sent to the DDF for distribution.
The example below illustrates the procedure for certifying a KPGS program that is in production
use.
To certify a KPGS program interactively, perform the following steps:
1. Log into a principal investigator (PI) account that has been authorized access to
the user data services (UDS) or a DBA account.
2. At the user prompt, enter "CDHF_UI" to start up the user interface to the UDS.
3. On the main menu of the user interface, select the "CDHF Queries and
Reports" option and press [RETURN].
4. Select the "File Processing Information Menu" option and press [RETURN].
5. Select the "Process Program Information Form" option and press [RETURN].
6. Press PF4 to cancel the query mode.
7. Press the SF1 key (View All Process Program) to display a list of the
production KPGS programs.
8. Select the KPGS program to be certified and press the Accept key to commit
the selection.
9. Press [TAB] to advance to the "Certify Status" field.
10. Enter Y in the Certify Status field.
11. Optionally press the Next Block key to display the "PI Comment" field and
enter a comment of up to 255 characters; else, skip to step 13.
12. Press the Accept key to terminate the PI Comment field.
13. Press the Accept key to commit the certification.
14. Press [RETURN] to acknowledge the informational message at the bottom of
the screen.
15. Press the Exit/Cancel key to exit the Process Program Information Form and
the user interface.
What Else Can I Do?
This Quick Tour of the CDHF User Interface has been provided to help you obtain information
and data products from the CDHF without having to wade through pages of documentation. The
examples are designed to get you started as quickly as possible in using the CDHF User
Interface. But many other functions and features are in the User Interface. The intrepid are
invited to explore further by perusing the user’s guide, which contains detailed information on all
functions and options of the User Interface.
Where To Go From Here
The ISTP CDHF Users Guide contains detailed information on all available options and
functions in the User Interface.
QT–16
THE SYS$PUBLIC:[DOCS] directory on the ISTP CDHF contains electronic versions of some
documents. See the README file for a list of what is available.
If you have a World Wide Web (WWW) client such as Mosaic, you may want to link to the ISTP
Project Home Page (http//buster.gsfc.nasa.gov/). This WWW server provides information on the
ISTP project, missions and investigations, and CDHF.
Whom Do You Call?
If you can log into the CDHF system, type HELP @SITE PERSONNEL to obtain a list of
people to contact for various problems. Below is a list of contacts for system or data access
questions:
Problem E-mail Telephone
Problems with the User Interface ISTP::PAC
PAC @ istp1.gsfc.nasa.gov (301) 286-3228
Login problem, forgotten password,
and other access problems ISTP::SYSTEM
system@istp1.gsfc.nasa.gov (301) 286-9561
Data access privilege changes ISTP::SCHNEIDER
schneider@istp1.gsfc.nasa.gov (301) 286-5543
Other ISTP data questions ISTP::WMISH
wmish@istp1.gsfc.nasa.gov (301) 286-5444
1
SECTION 1—INTRODUCTION
1.1 Purpose
This users guide serves as an introduction to the functions of the International Solar-Terrestrial
Physics (ISTP) Program Central Data Handling Facility (CDHF) and as a guide and reference for
the User Interface (UI) to the CDHF.
1.2 Scope
This document covers all activities and functions related to the CDHF support of the ISTP
science community. This version of the users guide is for Release 6.3 of the ISTP CDHF
Software System (ICSS).
It is assumed that the reader has some familiarity with the Virtual Address Extension
(VAX)/Virtual Memory System (VMS) Operating System and the Digital Command Language
(DCL) commands.
1.3 ISTP Program Overview
The ISTP is a cooperative scientific effort between the National Aeronautics and Space
Administration (NASA), the European Space Agency (ESA), and the Institute of Space and
Astronautical Science (ISAS). The ISTP program is a major new space science initiative to study
the energetics of the near-Earth space environment (or geospace), using instruments on a set of
integrated and coordinated spacecraft flight missions. The main program consists of ground-
based investigators (GBIs), theory investigators (TIs), and at least five spacecraft missions:
Geomagnetic Tail (GEOTAIL), Interplanetary Physics Laboratory Mission (WIND), Polar
Plasma Laboratory Mission (POLAR), Solar and Heliospheric Observatory (SOHO), and the
four Plasma Turbulence Laboratory (CLUSTER) satellites. Five other missions will contribute
data to ISTP. These are Interplanetary Monitoring Platform (IMP-8), the National Oceanic and
Atmospheric Administration (NOAA) Geostationary Operational Environmental Satellite
(GOES) spacecraft, the Los Alamos National Laboratory (LANL) spacecraft, Interball-Tail, and
the Solar Anomalous and Magnetospheric Particle Explorer (SAMPEX). Figure 1–1 illustrates
the ISTP mission orbit configuration.
The ISTP program includes two NASA spacecraft programs, the Collaborative Solar-Terrestrial
Research (COSTR) initiative and the Global Geospace Science (GGS) project, plus GBIs and
TIs.
The COSTR initiative provides for the development and operation of United States instruments
on ISAS and ESA spacecraft. The COSTR spacecraft developed by ISAS is the GEOTAIL
Laboratory; the spacecraft developed by ESA are the SOHO and CLUSTER. The major
objective of the COSTR initiative is to provide an overall assessment of energy flow throughout
geospace through parallel studies of closely related and time-dependent plasma physics
processes.
The GGS project provides for the development and operation of two spacecraft laboratories: the
Interplanetary Physics Laboratory (IPL) on WIND and the Polar Plasma Laboratory (PPL) on
POLAR. The project also manages the contributions of the IMP-8, GOES, and LANL to ISTP.
2
The mission objectives of the GGS project are to advance the scientific study of the source and
three-dimensional features of solar wind, solar wind-magnetosphere interaction, global plasma
storage flow and transformation, deposition of energy into the Earth’s atmosphere, and basic
plasma states and characteristics.
3
Figure 1–1. ISTP Mission Orbit Configuration
SOHO
CLUSTER
GEOTAIL
POLAR
WIND
SOLAR WIND
MAGNETOSPHERE
MAGNETOPAUSE
GEOMAGNETIC TAIL
EARTH
CUSP
SUN
4
The ISTP ground-based observing programs provide ground-based radar observations
coordinated with the spacecraft missions. The ground-based program provides the ISTP project
with observational data unobtainable from the ISTP spacecraft missions. The ISTP TIs provide
for the development and refinement of theoretical models for geospace and physical processes
and for the comparison of theory with observational data.
1.4 Applicable Documents
This document is based on the results of prior analysis and design work completed for the ICSS.
Figure 1–2 presents the documentation tree for the ISTP CDHF.
1.5 Document Organization
This document contains five sections. Section 1 presents the purpose and scope of the document
and an overview of the ISTP Program. Section 2 provides an overview of the ISTP CDHF.
Section 3 describes the UI to the ISTP CDHF and provides an overview of its use. Section 4
provides a detailed description of the use of each of the functions of the UI. Section 5 provides
additional information on CDHF operations relevant to the science users of the CDHF.
+When you see the symbol to the left of this line in the document, it indicates an important
note. It is used to draw attention to special procedures, warnings, caveats, and other items
of interest.
I
STP DPS
System
Requirements
Specification
ISTP CDHF
Operations
Concept
ISTP CDHF
System
Requirements
Specification
ISTP CDHF
Software
Requirements
Specification
ISTP CDHF
Hardware
Requirements
Specification
ICDs
ISTP CDHF
ADPE
Acquisition
Plan
ISTP CDHF
Preliminary
Design
Specification
ISTP CDHF
RFP
Package
ISTPS CDHF
Site Plan
ISTP CDHF
Hardware
Acceptance
Test Report
ISTP CDHF
Programmer's
Guide
ISTP CDHF
User's Guide
ISTP CDHF
Detailed
Design
Specification
ISTP CDHF
Operator's
Guide
ISTP CDHF
Training Plan
KPGS
Integration
Test Plan
ISTP CDHF
Hardware
Acceptance
Test Report
ISTP CDHF
System
Test Plan
ISTP CDHF
System Test
Procedures
ISTP CDHF
System
Test Report
Figure 1–2. Documentation Tree for the ISTP CDHF
5
SECTION 2—CDHF SYSTEM OVERVIEW
2.1 Description of CDHF
The CDHF is an ISTP project-unique, multimission facility dedicated to processing scientific
data. It provides for the centralized handling of instrument and related science data for the
scientific community. The CDHF receives science telemetry and supporting data. These data are
used to produce key parameters using principal investigator (PI)-supplied key parameter
generation software (KPGS) and calibration data. These data are maintained online and are made
available to users, on request, via electronic transfer.
To support the ISTP scientific community, the CDHF provides the following services and
functions:
• Receive telemetry, orbit, and attitude data
• Receive and store supplementary data, such as command history data and calibration data
•Receive and store key parameters from GBIs, LANL, GOES, CLUSTER, Interball-Tail,
SAMPEX, and IMP-8
• Generate key parameters
•Generate spin-phase data (GEOTAIL, WIND, POLAR) and despun platform attitude
(POLAR)
• Store and manage science data for online retrieval
• Transfer science data to other facilities
• Perform data management and accounting
• Control and monitor system operations
• Provide interactive user services
• Provide interactive access to the CDHF catalog
• Provide electronic transfer of online data to ISTP investigators
•Receive, edit, decommutate, and distribute WIND and POLAR telemetry data in near-
real time
• Generate key parameters in near-real time for specified instruments on WIND
The CDHF interacts closely with the Science Planning and Operations Facility (SPOF). The
SPOF is physically located in Goddard Space Flight Center (GSFC) Building 2, but it shares
some of the CDHF hardware resources via the network.
2.2 System Software Configuration
The operating system for the CDHF is the current version of VAX/VMS. The intent is that the
system be upgraded as needed to be maintained at the current release of the VMS operating
system over the life of ISTP mission support. Likewise, all other software products will be
maintained at the most current release unless operational considerations dictate otherwise. Not
all products are licensed for use on all CDHF computer systems. For a list of all software
products, the current versions, and the systems they are licensed on, contact the Computer
System Manager.
6
Communications software on the CDHF supporting access via NASA Science Internet (NSI)
consists of Digital Equipment Corporation network (DECnet) software for communicating with
NSI-DECnet nodes and Multinet Transmission Control Protocol/Internet Protocol (TCP/IP) for
communicating with NSI-TCP/IP nodes.
The following products are available to support development activities:
• VAX FORTRAN compiler
• VAX C compiler
• VAX Language-Sensitive Editor
• VAX Source Code Analyzer
• VAX Performance and Coverage Analyzer
• VAX DEC Code Management System
• VAX DEC Module Management System
• VAX DEC Test Manager
• Common Data Format (CDF)
• International Mathematics and Statistics Library (IMSL)
• Numerical Algorithms (NAG) Libraries
• ORACLE database management system (DBMS) and ORACLE SQL*Forms
2.3 External Interfaces
The CDHF communicates with GSFC Code 510 facilities over the InfoLAN. The CDHF
communicates with GSFC Code 550 facilities over the Mission Operations and Data Systems
Directorate (MO&DSD) Operational Development Network (MODNET).
The ISTP CDHF communicates with facilities other than Codes 550 and 510 over the NSI or the
GSFC Center Network Environment (CNE).
The CDHF provides dial-in access to support users without access to the NSI and to provide a
backup in the event that network access to the CDHF is unavailable. Magnetic tape is used as a
backup for all electronic interfaces with institutional facilities [i.e., Generic Data Capture Facility
(GDCF), Data Distribution Facility (DDF), and Flight Dynamics Facility (FDF)].
Figure 2–1 provides a context diagram that identifies all external data sources and sinks
interfacing with the ICSS and identifies the major data flows. The CDHF interfaces with the
following external systems:
• GDCF
• Unisys
• DDF
• ISAS
• FDF
• Remote Data Analysis Facilities (RDAFs)
• National Space Science Data Center (NSSDC)
• Command Management System (CMS)
• SPOF
• Rutherford-Appleton Laboratory (RAL)
• NOAA
7
• SOHO Experimenters’ Operations Facility (EOF)
8
Figure 2-1. ISTP CDHF Context Diagram
Interactive Request
Level-Zero
SIRIUS
Key Parameters
Def & Pred Orbit
Def & Pred Attitude
Command History
Near-Real Time
Online Data
Interactive Response
Level-Zero
SIRIUS
Data Quality Info
Quicklook
Near-Real Time
GDCF
Orbit
Attitude
FDF
Orbit
Attitude
Command History
ISAS
Externally Generated KP
KPGS
KP Calibration Data
RDAF
Command History
Reports and Schedules
CMS
Level-Zero
SIRIUS
Orbit Attitude
Data Distribution Status
DDF
User
Operator
DDF
SWIM
Investigators
RDAF
NSSDC
SPOF
User
Operator
ISTP
CDHF
30001134M-010
Solar Indices
NOAA
EOF
SOHO Summary
and Ancillary Data
Cluster Prime and
Summary Parameters
RAL
9
SECTION 3—CDHF SUPPORT OF ISTP USERS
The ISTP CDHF is the central repository for ISTP data products and information about these
data products. The CDHF provides online storage of instrument telemetry, spacecraft orbit and
attitude, key parameter, command history, and other ISTP-related data. Authorized users of the
CDHF may request transfer of ISTP data and query the CDHF database for information on the
data products. This section provides an overview of the support services provided to the ISTP
community by the CDHF.
3.1 Obtaining an Account on the CDHF
To obtain an account on the CDHF, connect to the ISTP CDHF system and then type APPLY at
the username prompt. A request for an account will be generated and submitted to the Project for
approval. Authorization may also be obtained by submitting a request form to the Project. Once
the account has been approved, the CDHF/RDAF Coordinator will set up the account with the
resident system manager for the ISTP CDHF. Approved users are assigned an account, a
password, and a set of privileges and resource quotas.
To access the CDHF, log onto the local RDAF computer and then enter one of the following
commands, depending on which network is used:
• DECnet over NSI
SET HOST ISTP ! Provided that ISTP is defined on your system
or
SET HOST 15461! If ISTP is not defined on your system
• TCP/IP Access over NSI
telnet istp1.gsfc.nasa.gov ! 128.183.92.58
In response to the prompts, enter your username and account password.
+When logging into the system for the first time, you will be prompted to change your
password. Passwords on the CDHF are a minimum of eight characters long. The user
account will have been set up with a standard LOGIN.COM file. This command file is
executed every time you log into the account. You should edit and customize this file
with your preferences.
3.2 Obtaining Help
The CDHF has an extensive online help facility. Information on operating system features and
commands can be obtained by using the HELP utility. To enter the HELP utility, type the HELP
command at the DCL prompt. In addition, you may obtain site-specific information from the
HELP utility by typing HELP @SITE.
For problems with user accounts (e.g., forgotten password), contact the CDHF System Manager.
See HELP @SITE PERSONNEL for details.
For problems related to the User Interface, send mail to the PAC account on the CDHF.
10
3.3 Data Products
The ISTP CDHF both receives and generates data products for use by investigators. All science
files are cataloged on the system with entries in the database. These files may be obtained by
using the appropriate function from the UI. In addition to the science files, various report files
and temporary files are directly available from specified directories. This section describes the
data products available and the methods used to obtain them.
3.3.1 Science Data Files
Information about ISTP science files is stored in the CDHF catalog. By using the UI, you can
request files for transfer, query information about the files, or generate a report containing
information from the catalog. Science data files are identified by logical file identifiers. Logical
file identifiers are a concatenation of five fields that identify the mission, data type, data
descriptor, date, and version of the data file or file group. Each of these fields is separated by an
underscore character. Blank characters are not allowed in the file identifier. These fields make up
the unique key that identifies the file in the CDHF catalog. The logical file identifier is
constructed as shown below:
mission_data type_descriptor_date_version
The fields are defined as follows:
• mission—Identifies the mission or investigation.
• data type—Identifies the type of data.
• descriptor—Describes or further qualifies the source of the data.
•date—Identifies the starting date of the data in the file group given in the form
YYYYMMDD. In multiple groups, this is the date of the start of the first file of the
group.
• version—Identifies the version of the data (01–99).
In addition to the logical file identifier, each data file has a file extension associated with it that
identifies the individual components of a multifile group.
A few specific examples follow:
GE_LZ_QAF_19920912_V01.SFDU
GE = GEOTAIL mission
LZ = Level-zero data type
QAF = Quality file
19920912 = Data starting on September 12, 1992
V01 = Version 1 of this file
SFDU = Indicates standard formatted data unit (SFDU) file
11
WI_CH_NUL_19930115_V01.DAT
WI = WIND mission
CH = Command history data
NUL = Field not applicable
19930115 = Data starting on January 15, 1993
V01 = Version 1 of this file
DAT = Indicates generic data type file
GE_SD_NUL_19920912_V01.S01
GE = GEOTAIL mission
SD = Scientific Information Retrieval Integrated Utilization System
(SIRIUS) data type
NUL = Descriptor for SIRIUS data is not applicable
19920912 = Data starting on September 12, 1992
V01 = Version 1 of this file
S01 = Indicates segment 1 of the SIRIUS data file group
GE_SD_NUL_19920912_V01.SFDU
GE_SD_NUL_19920912_V01.S01
GE_SD_NUL_19920912_V01.S02
GE_SD_NUL_19920912_V01.S03
GE_SD_NUL_19920912_V01.S04
The above group of files constitutes a multifile group of SIRIUS data files. Note that the logical
file identifier is the same for each file in the group. The group consists of a single SFDU file and
four data files.
The valid values for each of the fields of the logical file identifier are described in the following
list:
Mission:
C1 = CLUSTER spacecraft #1
C2 = CLUSTER spacecraft #2
C3 = CLUSTER spacecraft #3
C4 = CLUSTER spacecraft #4
CL = CLUSTER mission
12
CN = CANOPUS
DN = DARN
G6 = GOES_6
G7 = GOES _7
G8 = GOES_8
G9 = GOES_9
GE = GEOTAIL
I8 = IMP-8
IG = Interball-Ground
IT = Interball-Tail
L0 = LANL 1990_095
L1 = LANL 1991_080
L9 = LANL 1989_046
PO = POLAR
SO = SOHO
SE = SESAME
SL = Solar-Terrestrial Environment Laboratory, Nagoya
University
SN = Sondrestromfjord
SX = Solar Anomalous and Magnetospheric Particle Explorer
(SAMPEX)
XX = All missions
WI = WIND
Data Type:
AN = Ancillary data
AR = As-Run Plan
AT = Attitude
13
CD = Calibration data
CH = Command history
H0-H9 = High resolution parameters
K0-K9 = Key parameters (maximum of 10 files per instrument)
LZ = Level-zero
OR = Orbit
PA = Platform attitude
QL = Quick look
SD = SIRIUS data
SU = Summary data
WA = Working attitude
WO = Working orbit
Descriptor:
DEF = Definitive data
LNG = Long-term predicted
NUL = Indicates this field does not apply
PRE = Predicted data
CANOPUS
ASI = All Sky Imager
BARS = Bistatic Auroral Radar System
MARI = Magnetometer and Riometer Array (MARIA)
MPA = Meridian Photometer Array
CLUSTER
ASP = Active Spacecraft Potential Control (ASPOC)
AUX = Auxillary
CIS = Cluster Ion Spectrometry Experiment
14
DWP = Digital Wave Processing Experiment
EDI = Electron Drift Instrument
EFW = Electric Field and Wave Experiment
FGM = Magnetic Field Investigation
PEA = Plasma Electron and Current Experiment (PEACE)
RAP = Imaging Energetic Particle Spectrometer (RAPID)
STA = Spatio-Temporal Analysis of Field Fluctuations (STAFF)
WHI = Sounder and High-Frequency Wave Analyzer Experiment
(WHISPER)
DARN
AARC = Halley/Syowa/Sanae
ALPA = Alaska/Prince Albert
BARS = BARS VHF Radar
CTLS = Iceland/Finland (Cutlass)
GBAY = Goose Bay HF Radar
GBST = Goose Bay/Stokkseyri
HANK = Hankasalmi (Cutlass/Finland) Radar
ICEW = Iceland West Radar
KAPU = Kapuskasing
PYKK = Pykkvybaer (Cutlass/Iceland) Radar
SABR = SABRE VHF Radar
SAKA = Saskatoon/Kapuskasing
SASK = Saskatoon
SHAR = SHARE (Sanae Station) Radar
SYOW = Syowa Stations Radar
15
GEOTAIL
CPI = Comprehensive Plasma Composition
EFD = Electric Field
EPI = Energetic Particles and Ion Composition
HEP = High-Energy Particles
LEP = Low-Energy Particles
MGF = Magnetic Field
PWI = Plasma Wave Instrument
QAF = Quality File
SCR = Spacecraft Housekeeping
SPHA = Spin Phase
GOES
EP8 = Low Energy Particle and Electrons (different energies
from EPS)
EPS = Low Energy Particle and Electrons
MAG = Magnetometer
IMP-8
MAG = Magnetic Field Investigation
MCE = Multi-Coordinate Ephemeris
PLA = Plasma Investigation
Interball-Ground
PCI = PC Geomagnetic Index
Interball-Tail
AKR = High Frequency Raido Emission Flux
DEF = Definitive Data
ELE = Thermal Electron Experiment
16
EPI = Energetic Particle Experiment
ICD = Ion Composition
MFI = Magnetic Fields Instrument
LANL
MPA = Magnetospheric Plasma Analyzer
SPA = Synchronous Orbit Particle Analyzer
POLAR
CAM = Charge and Mass Magnetospheric Ion Composition
Experiment
CEP = Comprehensive Energetic Particle Pitch Angle
Distribution
EFI = Electric Fields Investigation
HYD = Fast Plasma Analyzer
MFE = Magnetic Fields Experiment
PDC = VIS Pixel Distortion Correction File
PIX = Polar Ionospheric X-ray Imaging Experiment
PWI = Plasma Wave Instrument
QAF = Quality File
SCR = Spacecraft Housekeeping
SEPS = Source/Loss-Cone Energetic Particle Spectrometer
SPHA = Spin Phase
TID = Thermal Ion Dynamics Experiment
TIM = Toroidal Imaging Mass-Angle Spectrograph
UVI = Ultraviolet Imager
VIS = Visible Imaging System
VLT = VIS Lookup Table
17
SAMPEX
30F = 30-Second Fluxes
POF = Polar Cap Fluxes
SESAME
AIS = Advanced Ionospheric Sounder
FPI = Fabry-Perot Interferometer
MAG = Fluxgate Magnetometer
RIO = Riometer
VLF = VLF/ELF Logger Experiment (VELOX)
SL
210 = 210 Magnetic Network
SOHO
FTR = Full-time resolution attitude data
G001 = SVM HK1 packets
G002 = SVM HK2 packets
G003 = SVM HK3 packets
G004 = SVM HK4 packets
G005 = AOCS HK1 packets
G006 = AOCS HK2 packets
G007 = ATTITUDE 1 packets
G008 = ATTITUDE 2 packets
G009 = S/W packets
G010 = OBT packets
G011 = Experiment HK packets
G012 = CDS HK packets
18
G013 = CELIAS HK packets
G014 = CEPAC HK packets
G015 = EIT/LASCO HK1 packets
G016 = EIT/LASCO HK2 packets
G017 = EIT/LASCO HK3 packets
G018 = GOLF HK packets
G020 = Reserved EGSE packets
G022 = SUMER HK packets
G023 = SWAN HK packets
G024 = UVCS HK packets
G025 = VIRGO HK packets
G026 = CDS SCIENCE LR packets
G027 = CDS SCIENCE MR packets
G028 = CDS SCIENCE HR packets
G029 = CELIAS SCIENCE packets
G030 = CEPAC SCIENCE packets
G031 = EIT/LASCO SCIENCE LR packets
G032 = EIT/LASCO SCIENCE HR packets
G033 = GOLF SCIENCE packets
G034 = MDI SCIENCE packets
G035 = SUMER SCIENCE LR packets
G036 = SUMER SCIENCE HR packets
G037 = SWAN SCIENCE packets
G038 = UVCS SCIENCE packets
G039 = VIRGO SCIENCE packets
19
G041 = MDI HK packets
CDS = Coronal Diagnostic Spectrometer
CEP = COSTEP-ERNE Particle Analysis Collaboration (CEPAC)
CEL = Charge, Element, and Isotope Analysis System
CST = Comprehensive Suprathermal and Energetic Particle
analyzer
EIT = Extreme-Ultraviolet Imaging Telescope
ERN = Energetic and Relativistic Nuclei and Electron experiment
GOL = Global Oscillations at Low Frequencies
LAS = Large-Angle Spectrometric Coronograph (LASCO)
MDI = Michelson Doppler Imager
SDR = SOHO Daily Report
SUM = Solar Ultraviolet Measurements of Emitted Radiation
(SUMER)
SWA = Solar Wind Anisotropies
TCF = Time Correlation File
UVC = Ultraviolet Coronal Spectrometer
VIR = Variability of Solar Irradiance Gravity Oscillations
(VIRGO)
Sondrestromfjord
GISR = Greenland Incoherent Scatter Radar
WIND
3DP = 3-D Plasma Analyzer
EPA = Energetic Particle Acceleration Composition Transport
KON = Konus
MFI = Magnetic Fields Investigation
QAF = Quality File
20
SCR = Spacecraft Housekeeping
SMS = Solar/Wind Suprathermal Ion Composition Studies
SPHA = Spin Phase
SWE = Solar Wind Experiment
TGR = Transient Gamma-Ray Spectrometer
WAV = Radio/Plasma Wave
WIFP = WIND Fields and Particle Parameters
Date:
YYYYMMDD
YYYY = 4-digit year
MM = month (01–12)
DD = day of month (01–31)
Version:
Vnn = version of file (01–99)
In general, a data file may have any extension. However, an SFDU file must always have the
SFDU extension. A CDF file should always have a CDF extension. SIRIUS data files and other
file groups consisting of multiple segments must use the Sxx extension. It is recommended that
in the absence of a meaningful extension for a data file that the extension DAT be used.
The values for the file extension field for data files that are cataloged are shown below:
SFDU = SFDU file
DAT = Generic data file
Sxx = Data file segment xx (01–99)
CDF = CDF file
3.3.2 Report Files
The CDHF receives and generates a number of report files that are temporarily stored on the
system for access by investigators. This section describes the reports files and their locations.
21
3.3.2.1 WIND and POLAR CMS Reports
The GGS CMS will place report files into directories on the CDHF for access by investigators.
These files will be placed into directories called CMS_WIND and CMS_POLAR. The files will
consist of the following:
Clock Delta Report Contains the measured differences between the
spacecraft clock's time and standard time. [produced
by the Payload Operations Control Center (POCC)]
Combined Request List Report Integrated list of spacecraft and instrument requests.
(produced by CMS)
Daily Operations Schedule Contains information such as confirmed station
contact intervals, stored commands to be executed
with the contact intervals, scheduled orbital
adjustment commands, and orbital events. Scheduled
loads and the corresponding uplink windows for each
load are summarized. (produced by CMS)
Integrated Print Time-ordered list of all stored commands that will be
executed during the operational day. Orbital events
and DSN contacts are included. (produced by CMS)
Old files will be deleted periodically from these directories.
3.3.2.2 SPOF Science Plans
The SPOF will place the long-term and biweekly science plans into directories on the CDHF for
access by investigators. These files will be located in subdirectories of a directory called
SPOF_DIR. Old files will be deleted periodically from these directories.
3.3.3 Online Documentation
Electronic versions of a number of documents are available through the ISTP World Wide Web
page located at http://www-istp.gsfc.nasa.gov/.
3.3.4 Data Rights and Computer Security
The CDHF has a responsibility to protect the data rights of the data files it manages. To this end,
certain restrictions are placed on the access to data files managed by the CDHF. The access
rights to data files for each CDHF user are defined in the interface control document (ICD)
governing the mission and instrument with which each user is associated. These access rights are
enforced through the UI. Access to any CDHF-managed data product is through the UI. Users
are not permitted direct access or network access to these data files. Users request data products
through the UI. These requests are validated and, if authorized, the requested data products are
transferred to the specified location. Once data files have been transferred to the user-specified
location, they are no longer under the control of the CDHF, and the CDHF will no longer be
capable of enforcing access restrictions on those files. You should be familiar with the file
protection mechanisms on the computer system to which the data products are transferred and
should set the file protections on the ISTP data files appropriately.
Your account on the CDHF is only as secure as the account password. Never give the password
out, write it down, or store it in a file on any computer system. Upon logging in, check for
22
messages indicating any failed logins to your account since the last time you logged in. If you
suspect that your account has been used by an unauthorized person, report this to the CDHF
system manager immediately.
3.4 User Interface Overview
The UI to the CDHF is implemented using ORACLE forms. This section provides an overview
of the interface and the methods of navigating through the menus and invoking interface
functions.
3.4.1 Invoking the User Interface
Invoke the UI by entering the CDHF_UI command from the system prompt, as follows:
$ CDHF_UI
The CDHF UI supports a novice/expert mode. By default, users are in novice mode. Novice
mode prompts you through the steps necessary to properly set up and configure a session for the
UI (see Section 3.5.1.1.) If you are familiar with the UI, place the following command in the
LOGIN.COM file:
$ DEFINE CDHF_USER_LEVEL “EXPERT”
With the CDHF user level set to expert, the CDHF UI main menu (Figure 3–1) is displayed. If
the user level has not been specified or has been set to novice, a procedure to assist in setting up
the terminal is invoked. Following this procedure, you will be asked whether you want to invoke
the UI now. If you answer YES, the system displays the CDHF UI main menu; otherwise, the
procedure exits to the system-command level.
+When using the KPGS development environment on the CDHF, exit that environment in
order to use the UI. The KPGS development environment establishes directory path links
that will interfere with the operation of the UI. In addition, you may have defined logical
names to support KPGS development that are incompatible with the UI. To ensure that
there are no conflicts, either log off the CDHF and then back in again or establish a
second connection to the CDHF specifically for the UI.
The UI main menu is a form that displays additional menu items for the UI function. You may
use the cursor keys to highlight the item and then press [RETURN] to select that item. These
menu items are discussed in detail in Section 4. Below is an overview of the use of ORACLE
forms.
3.5 How To Use SQL*Forms
The forms are a user representation of the CDHF database allowing users to enter, query, update,
and delete the information contained in it. Although there are some special behaviors in the
forms, as described in Section 4, all the forms operate in the same general manner. This section
describes the screen objects, functions, modes, and general operation that are common to all
forms.
In order to use SQL*Forms, you must verify that the requirements outlined in this section have
been fulfilled.
23
3.5.1 Setup Requirements
The setup requirements are as follows:
1. You must have a VAX account
and
a corresponding ORACLE account on the ISTP
VAXcluster. Contact the Data Processing Specialist (DPS) personnel if these accounts
have not been created for you. In general, there is no separate password for an ORACLE
account. An ORACLE account is directly related to a single VAX account.
Figure 3–1. CDHF User Interface Main Menu
2. You must log into the ISTP VAXcluster (ISTP1) to use the SQL*Forms.
3. You must be in the operational environment. The operational environment is the default
environment when you log into the ISTP VAXcluster, but commands in your personal
LOGIN.COM file can override the default. For example, if you are testing a program in
the key parameter test environment, you may need to log in again without the command
to point to the key parameter test environment. One way to verify your environment is to
enter the following command:
$ SHOW LOGICAL ORA_SID
If the value returned is “OP”, then you are pointing to the operational environment.
+Note: Unlike the KP environment, you do not need to execute a SET_DB… command
file in the operational environment.
3.5.1.1 Terminal Support
SQL*Forms will support any DEC terminal or DEC terminal emulator. The VT220 keypad for
the CDHF menus and forms will support any terminal or emulator with a designation of VT220
24
or higher, including VT240, VT320, VT1200, and DECTerm. The VT100 keypad will support
any VT100 terminal and most VT100 emulators for UNIX.
Some VT100 emulators, especially the ones for IBM personal computers (PCs), do not have full
VT100 functionality. These emulators can be identified by their lack of function key mappings
for the VT100 numeric keypad. The VT100 emulator keypad for the CDHF menus and forms
supports these partial emulators by using control keys and escape keys.
If you are using a Sun Workstation, you should obtain the VTTOOL terminal simulation
package. You can obtain it from the CDHF in directory SYS$PUBLIC:[VTTOOL].
The keypad maps for the VT220, VT100, and VT100 emulator are in Appendix A. For all three
keypad mappings, you can display the mappings for your particular type of terminal when you
are using SQL*Forms by pressing [CONTROL] and K simultaneously (press Down to view any
additional keys and press [RETURN] to return to your form).
If you are using a terminal or emulator with full VT220 or VT100 functionality, the correct
keypad will automatically be incorporated when you access the SQL*Forms.
+If you are using a VT100 emulator with partial functionality, you need to add the
following command to your LOGIN.COM before the DBI_MM command (see Section
4.1.1.2):
$ DBI_TERM_TYPE :== “CDHF100E”
Terminal Support Notes and Recommendations:
1. If you are using an IBM PC or PC clone and do not have a virtual terminal (VT)
emulator, a VT220 emulator is recommended. Cross Talk Communicator can be
purchased for less than $100 with a VT220 emulator.
2. Kermit is a public domain package with a VT100 emulator that works well with the
VT100 emulator keypad. VTTOOL is another public domain package for the UNIX
environment that works well with the regular VT100 keypad.
3. Procomm is not recommended for use with IBM PCs and PC clones because of the
known bugs in its DEC emulators. In particular, some versions do not echo the last
character in a field, but the character is actually there. If you have Procomm already, you
can use it as long as its limitations are accepted.
4. Some emulators allow the user to define icons for the function keys. This feature is
particularly useful if you have a mouse. The VTTOOL package and the emulator
included with Microsoft Windows 3.0 support mouse-driven keypad icons.
5. Some emulators do not respond to the DCL terminal width commands. Consequently,
when you execute a 132-column report interactively, the terminal width may remain
80 columns wide when you display the report to the screen. If your emulator has this
problem, the batch report mode is recommended.
6. For all keypad mappings, escape key sequences require the ESC key to be activated first
followed by the other key in the sequence. Likewise, gold key sequences require the PF1
key to be activated first followed by the other key in the sequence. For control key
sequences, however, both the control key and the other key in the sequence must be
activated at the same time.
25
7. If you do not have a VT emulator, you may be able to operate the forms using the VT100
emulator keypad (if the DBI_TERM_TYPE symbol is setup as described above), but the
degree of functional compatibility varies among terminal types. For example, XTERM
windows available on UNIX systems are fairly functional with the VT100 emulator
keypad.
8. Contact the database administrator (DBA) if you are unable to operate the forms with
your VT terminal or emulator. The DBA can also provide information on how to obtain
public domain emulators.
3.5.2 How To Use a Menu
There are four basic functions for working with menus. The Up and Down keys will move the
cursor among the menu items. The Return or Accept key will invoke the menu item on which the
cursor is positioned. The Exit key will cause the cursor to exit the current menu.
Within a menu, more menu items may be available than are displayed at one time. In such cases,
a message will appear upon entry into the menu. Use the Down key several times to access the
hidden menu items. When the Down key is used on the last menu item or the Up key is used on
the first menu item, the cursor will automatically cycle around to the first or last menu item,
respectively. Under the main menu, there are up to two levels of submenus. When exiting a
submenu, the previous (parent) menu is displayed.
3.5.3 Form Objects
To understand the purpose of the functions, it is necessary to understand the components of a
form. Figure 3–2 contains a graphical representation of these components.
3.5.3.1 Pages, Blocks, Records, and Fields
Each form must have at least one page, one block, one record, and one field. A page is one entire
screen of information, the most information that can be viewed at one time. Currently, all forms
have just one page except for the Science Data File Information Form and the Data Transfer
Services Forms. A block is a group of related data items (fields), often from one database table.
When a page is composed of multiple blocks, there is always a line separating them.
Typically, a page will contain multiple blocks either because a query criteria must be entered in
the upper block or because there are multiple entries in the lower block for each entry in the
upper block (known as parent-child or master-detail blocks). A record is one unique entry (row)
for the set of fields composing a block. Each distinct data item (column) in a block is a field.
In many blocks, only one record can be viewed at a time. Except for query criteria blocks, one-
record blocks have the same behavior as blocks with multiple records displayed at once because
they both can buffer the nondisplayed records until the user requires them. Query criteria blocks
contain a single record with a small set of fields that must be specified to retrieve records for a
lower block or a report.
26
Figure 3–2. SQL*Forms Objects
Page
Block #1
Block #2
Field
Record
Record
Message Line
Status Line
27
3.5.3.2 Pop-Up Windows
Several forms have special function keys that will invoke pop-up windows on top of the main
screen for a form. Like a page, a pop-up window can have blocks, records, and fields. Typically,
they only have one block. The information in a pop-up always relates to the information
currently displayed in the main screen. In some cases, information can be copied back to the
main screen from the pop-up window. In other cases, the pop-up is just a detail block that could
not fit on the main screen with the master block.
3.5.3.3 Message Line
The message line is the inverse-video line at the bottom of the page. It displays field-level help
messages, informational messages, warning messages, and error messages. Whenever the cursor
is moved to a new field, a field-level help message is automatically displayed for user assistance
(within the 80-character limit). The field-level help message may include the purpose, possible
values, format, and available functions for a field. Warning and error messages are accompanied
with a terminal bell. Error messages may be caused by user error or a data inconsistency.
Informational messages are usually non-field-level user assistance messages.
The message line “Transactions Complete -- {X} Records Posted and Committed” does not
always reflect the actual record count, but may indicate the number of fields updated or entered.
3.5.3.4 Status Line
The status line is immediately below the message line. It provides additional information about
the record count for a block, the form mode, the character mode, list of values, and the cursor
position relative to the records in the block and the characters in a field. The following symbols
may appear, from left to right, in the status line:
Count Indicates the number of records retrieved so far by a query. As the
cursor moves down through the records, the count will increment until
the last record is reached.
*Indicates that the record count for a query is final after all the records
have been retrieved.
<Indicates that the beginning of the current field is scrolled off the left
side of the screen. Occurs when a field’s actual length is larger than its
displayed length.
>Indicates that the end of the current field is scrolled off the right side of
the screen. Occurs when a field’s actual length is larger than its
displayed length. To display the entire field in a pop-up window, use the
Edit key.
Ÿ Indicates that there are records before the current record in the block.
⁄ Indicates that there are records after the current record in the block.
ENTER QUERY Indicates that the form is in enter query mode. Either enter a query
criteria, if any, and invoke Execute Query, or cancel the mode by
invoking Exit.
28
<List> Indicates that there is a list of values for the current field. (Note: For
logical identifiers, only the message line will indicate that a list of values
exists.)
<Insert> Indicates that new characters will be inserted between any pre-existing
characters. No characters are inserted if the field is full.
<Replace> Indicates that new characters will replace any pre-existing characters.
This default character mode should be used at all times unless characters
are being added between existing characters.
3.5.3.5 Alerts
SQL*Forms will automatically issue alerts if you have not committed database changes, or if
back-to-back messages or very important messages occur. The first type of alert is in the form of
a pop-up window that prompts you to respond Yes, No, or Cancel. Either position the cursor on
your response using the Left or Right functions and press [RETURN], or type a Y, N, or C to
respond accordingly. The other type of alert occurs when you must acknowledge a message.
+If you receive an OK prompt on the status line, press [RETURN] to continue after
acknowledging the message.
3.5.4 Function Keys
To operate SQL*Forms, various functions are predefined to move the cursor, execute queries,
modify data, and save changes. If you are a novice user, the number of functions available may
be overwhelming initially, but you only need to learn a fraction of these functions to use the
forms. To invoke the functions, either use the function keys as mapped to your terminal, or use
pull-down menus, which only require a couple of function keys.
Because SQL*Forms supports several terminal types, a function may be mapped differently for
each terminal. In addition, emulators tend to map the VT keys differently.
+Be sure to review the terminal support information in Section 3.5.1.1 before attempting to
use the forms. Throughout this users guide and the online help messages, the SQL*Forms
function names are referenced, not the keys to which the functions are mapped. Press
[CONTROL] and K to determine the associated VT keys for the SQL*Forms functions.
The function key mappings for the supported terminal types are also in Appendix A.
If you are using an emulator, you will also need to refer to the keypad mapping instructions for
the emulator. For example, the Accept function is mapped to the Do key (F16) for a VT220
terminal, but your VT220 emulator may map the Do key to Shift F6. Emulators usually support
escape and control keys exactly the same as a real VT terminal.
3.5.4.1 Function Keys Versus Pull-Down Menus
If you are a novice user, the pull-down menus are recommended for invoking SQL*Forms
functions. The functions are categorized, and you only need to memorize a couple of keys. When
you are comfortable with the functions, you may want to start using the function keys. If you are
an experienced user, the function keys tend to allow quicker operation of a form because fewer
key strokes are required. There are a few advanced SQL*Forms functions that are not available
as both pull-down menu items and function keys, but these functions are rarely used.
29
Because SQL*Forms is currently set up to support character-mode terminals, you cannot use
your mouse directly on the pull-down menus. Instead, you must invoke the Menu function,
which will place your cursor on the first pull-down menu item. If you press [RETURN], the
functions for the first pull-down menu item will be displayed. Using the Right function, you will
be able to view the functions for the other pull-down menu items. To invoke a function under the
current pull-down menu item, you can either type the capital letter that appears in the function
name, or you can use the Up and Down functions to position the cursor on the function and press
[RETURN] to invoke it. When you invoke a function, the pull-down menus will disappear and
the function will execute. To invoke another function, invoke the Menu function again. To exit
the pull-down menus without invoking a function, use the Exit/Cancel function. In summary, to
use the pull-down menus, you only need to learn the keys for six functions: Menu, Left, Right,
Up, Down, and Exit.
3.5.4.2 Special Function Keys
In many of the forms, there are up to four special function keys identified on the screen text as
SF1, SF2, SF3, and SF4. The purpose of these nonstandard SQL*Forms functions is different for
each form, as documented on the screen text and in Section 4. The most common purpose is to
display pop-up windows with information related to the main screen. The special function keys
cannot be invoked from the pull-down menus. In all three of the CDHF keypad mappings for
SQL*Forms, there are keypad mappings for SF1 through SF4. The online keypad help can be
used to display the mapping for your terminal/emulator type.
3.5.4.3 Disabled Keys
Depending on the form and your user privilege, several functions are often disabled at the field,
block, or form level. For example, if you do not have insert privilege in a form, functions such as
Commit, Insert Record, and Down after the last record may be disabled. In addition, some or all
fields in a form may not be updateable. The set of field values that distinguish a particular record
(primary key fields) is never updateable. In forms with restricted queries, the Enter Query and
Execute Query functions are usually disabled. If you find a disabled function that you believe
should not be disabled, contact the DBA for a resolution.
3.5.4.4 Function Key Definitions
The standard SQL*Forms functions are categorized and defined in this section. Unless noted
otherwise, all functions are included in the three keypad mappings available to SQL*Forms
users. Most functions are also available in the pull-down menus.
3.5.4.4.1 Navigation Functions
Exit/Cancel Used to exit the current menu, form, or pop-up window. In edit pop-up
windows, any edit changes are undone by the function. In pop-up
windows for selection purposes, such as list of values, the pop-up window
will disappear without returning a selection if Exit is invoked.
Left Moves the cursor one character to the left within a field.
Right Moves the cursor one character to the right within a field.
Next Field Moves the cursor to the next enterable field in the block. For most keypad
mappings, the Return key and Tab key can be used interchangeable for
this purpose. In special cases, such as list of values and print pop-up
30
windows, the tab key will move the cursor to a different field while the
Return key is used to accept an entry.
Previous Field Moves the cursor to the previous enterable field in the block.
Next Block Moves the cursor to the first enterable field in the next block. Used to
access a set of fields separated by a horizontal line.
Previous Block Moves the cursor to the first enterable field in the previous block.
Up Moves the cursor to the same field in the previous record within the
current block, if any.
Down Moves the cursor to the same field in the next record within the current
block, if any.
Scroll Up Displays the previous set of records for a block, if any. Recommended for
blocks with multiple records displayed simultaneously.
Scroll Down Displays the next set of records for a block, if any. Recommended for
blocks with multiple records displayed simultaneously.
Previous Record Virtually interchangeable with the Up function. This function is only
available in the pull-down menus.
Next Record Virtually interchangeable with the Down function. This function is only
available in the pull-down menus.
Next Set of Records Virtually interchangeable with the Scroll Down function. This function is
only available in the pull-down menus.
3.5.4.4.2 User Assistance Functions
Display Error Displays more detailed information, if any, for the last error that occurred.
It is primarily used to obtain more information about errors issued from
the ORACLE database management system as oppose to routine errors
issued by SQL*Forms.
Help Displays the brief field-level help message. If it is invoked twice,
advanced field help information is displayed. The brief field-level help
message is usually displayed automatically upon entry into a field.
List Activates a list of values pop-up window, if there is one available for the
current field. Use the Return key to accept the current value back into the
original field. Use the Exit function to return to the original field without a
value. Use the Next Field (Tab) function to enter a search criterion.
Menu Activates the pull-down menu items, allowing an alternative method to
invoke the SQL*Forms functions.
Print Writes the current screen contents or keypad mapping to a file. Options
are available to name the file, print the file, or to choose the keypad
mapping instead of the current screen. Use the Next Field (Tab) function
to specify the options.
31
Refresh Redraws the current screen. Can be used if broadcast messages or modem
characters disrupt the screen display.
Show Keys Displays the function key assignments for the CDHF keypad currently
activated. Use the Down function to review all of the assignments, and use
Return to exit the show keys window.
3.5.4.4.3 Query Processing Functions
Enter Query Clears the current block and activates the enter query mode to accept
query criteria. If invoked twice, the query criteria from the previous query
is displayed.
Execute Query Clears the current block and retrieves all the records that match the query
criteria, if any criteria was specified by invoking Enter Query. If the Enter
Query was used prior to Execute Query and no records were retrieved, the
form will remain in enter query mode. Otherwise, the form will return to
normal (update) mode.
Exit/Cancel Cancels enter query mode. Use if you do not want to specify any query
criteria.
Next Block Use to execute a query with the values entered in a query criteria block.
Query criteria blocks are only applicable for restricted queries.
Count Query Hits Clears the current block and displays the number of records that the query
would retrieve on the message line. This function is not recommended
because it has little practical use. The execution time is the same as it is
for Execute Query. This function is only available in the pull-down
menus.
3.5.4.4.4 Database Modification Functions
Accept/Commit Saves in the database all changes made since the last commit. Accept is
also used to activate selections such as menu items, reports, and list of
value entries.
Insert Record Inserts a new blank record below the current record to allow completion of
a new entry. A new entry is not permanent until it is committed to the
database.
Delete Record Deletes the current record if it has been previously saved in the database.
The deletion is not permanent until you commit your changes to the
database. Use the Clear Record function if the record has never been saved
in the database. Delete Record can be used to clear a blank record between
two nonblank records.
Clear Field Clears the value in the current field. Use to deassign (nullify) a value or to
correct a bad entry. If the applicable record has been previously saved in
the database, the change will not be permanent until it is committed. In an
edit pop-up window, the Clear Field function will clear the characters to
the left of the current cursor position.
32
Clear Record Clears the current record, reversing any uncommitted changes made to
that record. It does not affect the data saved in the database. Use Delete
Record to permanently remove a record from the database. Use clear
record to abort a new entry and to prevent the commit alert from being
activated. For example, if you start to enter a query criteria without being
in enter query mode or a query criteria block, the Clear Record function
will undo the changes so you can try again with Enter Query.
Clear Block Clears all records in the current block and leaves the block ready to accept
new records. It does not affect the data saved in the database. It only clears
the record buffer for the block. If you have not committed any changes, a
commit prompt alert will be issued before clearing the block. All changes
are rolled back if a commit is not selected when prompted.
Clear Form/Rollback Clears all blocks for the current form and returns the cursor to the first
field in the first block. It does not affect the data saved in the database. If
you have not committed any changes, a commit prompt alert will be
issued before clearing the form. All changes are rolled back if a commit is
not selected when prompted.
Duplicate Field When creating a new record, the Duplicate Field function can be used to
copy the value in the same field of the previous record into the new
record. This function is only available in the pull-down menus.
Duplicate Record When creating a new record, the Duplicate Record function can be used to
copy the values for the previous record into the new record. The values
copied can then be modified as required. This function is only available in
the pull-down menus.
3.5.4.4.5 Editing Functions
Delete Backward Deletes the character to the left of the current cursor position.
Insert/Replace Toggles the character mode between Insert and Replace.
Edit Displays a pop-up window in which the user can perform all editing
functions on the current field. The edit function is recommended to view
or modify long or truncated fields. Use the Accept or Edit function to exit
the pop-up window while maintaining the changes. Use the Exit function
to exit the pop-up window and to undo any changes made.
Beginning of Line Moves the cursor to first character in a field or edit line.
End of Line Moves the cursor to the last character in a field or edit line.
Search Displays a dialog box (special pop-up window) for entering a search
criteria string and optionally a replacement string. The function is only
available within an edit window.
Select For editing, the Selection function will underline all the characters to be
selected for cutting or copying. Select can also be used interchangeable
with Return to select a choice in a list or an alert dialog box.
Cut Used to remove the text selected and to save it in the Paste buffer.
33
Copy Used to copy the text selected into the Paste buffer. The text is then no
longer selected.
Paste Used to copy the current contents of the Paste buffer into the current field
to the right of the current cursor position.
3.5.5 Online Help
In SQL*Forms, there are several eatures that provide online help to users. This section describes
the purpose and usage of these features.
3.5.5.1 Keypad Map
From any terminal or emulator type, you can always view the key mapping for any function by
pressing [CONTROL] and K simultaneously. The first and third columns of the keypad help
contain the SQL*Forms functions. The second and fourth columns contain the corresponding
DEC keys for your terminal type. If you are using an emulator, you may need to map the DEC
keys to an actual key on your terminal, as specified by the documentation for your emulator. If
you cannot find a function in the keypad help, press the Down function to see any hidden
functions. If you still cannot find a function, it is disabled in the current block or form mode.
Press [RETURN] when you are done with keypad help.
3.5.5.2 Field-Level Help
In general, a field-level help message will automatically be displayed when the cursor first enters
a field. If the field-level help message is overwritten by another message, you can retrieve it
again by using the Help function. Within the 80-character limit, the message instructs the user on
the purpose, possible values, format, and other available functions for a field. Some messages
use the following codes to minimize the number of characters used:
• LOV—A list of values is available for the field by using the List function.
•EDT—The Edit function is recommended to view or modify the entire contents of the
field.
• MAN—A value is required to be entered into the field.
If you activate the Help function twice, an advanced field-level help screen will be displayed.
The advanced help information may include the data type, length, help message, format, and
default value for a the field. It may also include information on whether the field is updateable,
primary key, and mandatory. Press [RETURN] to exit the advanced field-level help screen.
3.5.5.3 List of Values
If the status or message line indicates that a list of values is available for a field, you may select a
value for the field by invoking the List function. When the pop-up window appears, the cursor
will be on the first value in the list. There may be more values in the list than visible at one time.
Use the Scroll Down function to view the next set of values in the list. To select a value back
into the original field, place the cursor on the value and press [RETURN]. If you would like to
exit the list of values window without selecting a value, invoke the Exit function. Unless the
form is in Enter Query mode, the cursor will automatically be forwarded to the next field when a
list of values window is terminated.
If the list of values is very long, you can use the find feature to reduce the number of values in
the list. To use this feature, invoke the Next Field (Tab) function, which will put the cursor in the
34
find field. Type in the find string pattern and press [RETURN]. A wild card will automatically
be appended to the end of your find string. Use an explicit wild card (%) if you would like wild
cards in the beginning or middle of your find string. A new list will be built based on the find
string.
Because the list of possible values for logical identifiers is extremely large, a nonstandard list of
values will appear that requires the selection of a mission name, data type, descriptor, and date
range before the logical identifier list will be generated. Once you select these values and invoke
the Next Block function, you can select a value from the list in the same manner as you would
with a regular list of values.
3.5.5.4 ORACLE Errors
If you receive an error message that an ORACLE error has occurred, use the Display Error
function to find the source of the error. The most common errors are “duplicate value in index”
(duplicate entry) and “insufficient privileges.” None of the records changed will be committed to
the database until the problem records are resolved. The cursor will usually reside on the
problem record when the error occurs. If the record is a duplicate entry, use the Clear Record
function to undo the change. If you believe that an insufficient privileges or duplicate entry error
should not have occurred, contact the DBA. Likewise, contact the DBA if any other ORACLE
errors occur.
3.5.6 Form Modes
When operating SQL*Forms, you should be aware of a few explicit and implicit form modes.
These modes determine the type of operations that are permitted in a given form state. Only the
Enter Query mode is explicitly indicated on the status line. This section describes how the form
modes can be recognized and what operations can be completed in them.
The form modes apply to all blocks except the query criteria blocks used to restrict queries.
Query criteria blocks are modeless. Therefore, you should simply provide the appropriate values
for query criteria blocks without worrying about the form mode.
3.5.6.1 Enter Query Mode
The Enter Query mode strictly allows a query criteria to be entered in the current block and the
query to be executed. Most functions are disabled in this mode, including special function keys
and the record/block-level navigation functions. With the exception of logical identifiers, the List
function is still available in Enter Query mode to select query criteria values. If you execute a
query while you are in Enter Query mode and no records are found, the form will remain in
Enter Query mode to allow you to respecify the criteria. If records are found when the query is
executed, the form is then in Update mode.
Upon entry into a form that allows unrestricted queries, the form will automatically be in Enter
Query mode if you do not have insert privilege for the form. The status line will indicate the
mode with the ENTER QUERY symbol. If you do not want to be in Enter Query mode, invoke
the Exit/Cancel function, which will return the form to Insert mode.
3.5.6.2 Insert Mode
A form is in Insert mode if the current block has no records in its buffers and the status line does
not indicate ENTER QUERY. Most functions are available in Insert mode before you start a
record entry. Therefore, special functions can be invoked, and the cursor can be moved to other
35
blocks. Likewise, a query can be executed. The only database modifications that can be
completed in Insert mode are the creation of new records. Once a new record entry is started, it
must either be completed or cleared to continue.
Upon entry into a form, the form will automatically be in Insert mode if you have insert privilege
for the form. Therefore, the form will be blank, and there will not be an ENTER QUERY symbol
on the status line. Use the Enter Query and Execute Query functions, respectively, to change the
form mode to Enter Query or Update mode.
3.5.6.3 Update Mode
A form is in Update mode if the current block has records in its buffers. The only way to put a
form in Update mode is to perform a query. Update mode allows records to be created, updated,
and deleted. All functions are available in Update mode as user privileges allow. A form is only
in Update mode upon entry into the form, if an automatic query is performed upon entry.
3.5.7 Form Navigation
To operate a form for query or database modification purposes, move the cursor to different parts
of the form. This section describes the various form navigation options. Section 3.5.3 explains
the various parts of a form.
3.5.7.1 Moving Block to Block
The Next Block and Previous Block functions allow block-to-block navigation. To move your
cursor to a field below when there is a horizontal line separating that field from the field in which
the cursor currently resides, the Next Block function is required. You cannot move the cursor to
another block if the form is in Enter Query mode. In most cases, you also cannot move the cursor
to a lower block if a record has not been created or queried in the current block.
3.5.7.2 Moving Record to Record
The Down, Up, Next Record, and Previous Record functions allow record-to-record navigation
within a block. If multiple records can be viewed at one time, the cursor will actually move to the
record. If only one record can be viewed at a time, the buffer entry for the record will be
displayed. The Scroll Down, Scroll Up, and Next Set of Records functions are also useful for
record-level navigation if multiple records can be viewed in a block at one time. If you enter an
invalid combination of field values, you will not be able to leave the record until the values are
corrected. The status line and the scroll bars in pop-up windows indicate the cursor’s relative
position from the first and last records.
3.5.7.3 Moving Field to Field
The Next Field and Previous Field functions allow field-to-field navigation within a block. If you
enter an invalid value in a field, you will not be able to leave the field until the value is corrected.
Fields are usually ordered left to right and top to bottom.
3.5.7.4 Moving Within a Field
The Right, Left, Beginning of Line, and End of Line functions allow navigation within a field. A
field may be larger than displayed. In such cases, the field will automatically scroll left and right
as the functions require. The Edit function is recommended for viewing and modifying truncated
fields.
36
3.5.7.5 Edit Window
Within a field edit pop-up window, the Down, Up, Left, Right, Beginning of Line, End of Line,
First Line, and Last Line functions all allow navigation within the window. Because word
wrapping is handled automatically, the Return function is not recommended. To exit an edit
window with any changes completed, use the Accept function. To exit an edit window with an
undo on any changes, use the Exit function.
3.5.7.6 Pop-Up Windows
Within a pop-up window, the block, record, and field-level navigation is the same as the main
screen for a form. To exit a pop-up window, use the Exit function. Some pop-up windows allow
a value to be selected. In such cases, the Accept function will select the current cursor value, exit
the pop-up window, and display the selected value in the main screen for the form.
3.5.7.7 Exiting a Form
The Exit function can be used to exit a form. Upon the exit, the cursor will return to the menu or
prompt that invoked the form. To exit all the menus, continue to use the Exit function until a
DCL prompt appears or the TAE menus reappear.
3.5.8 How To Perform a Query
This section explains how to perform queries using a form. The first step required is to determine
whether your particular form allows restricted or unrestricted queries. The usage restrictions for
each form in Section 4 indicate whether a form only allows restricted queries.
+If your form is in Enter Query mode upon entry into the form or if it allows you to
activate the Enter Query function, then your form allows unrestricted queries. If the first
block of your form contains a small set of fields and the Enter Query function is disabled,
then your form only allows restricted queries.
Detailed Query Information:
In general, forms that query large history tables and account information only allow restricted
queries. The queries on large history tables are restricted to prevent users from using excessive
computer resources by querying thousands of records at once. Some of the history tables will
eventually contain a few million records. You can view all of the information in a history table,
but you may have to perform a few different queries to view the information of interest to you.
Regular users can only view the information for their own accounts. The operations personnel
can view the information for all of the accounts.
Detail blocks and some specialized forms also enforce restricted queries. When a lower (detail)
block in a form or a pop-up window block is dependent on the current record displayed in the
upper (master) block, the queries in the detail block are restricted. In the ISTP Users and
Privileges Forms, for example, the access privileges and certify privileges displayed are always
for the user name currently displayed in the account information block above the privileges
information. An entire form is not considered to be restricted unless the master block only allows
restricted queries. In the User Interface and the Operator Interface, a few specialized forms, such
as the Scheduler File Selection Form, also restrict queries.
37
3.5.8.1 How To Perform Restricted Queries
In forms with restricted queries, the first block is a small query criteria block. The Enter Query
function is disabled for query criteria blocks. Some default values may appear in these blocks
based on defaults set up for your account and the current date. These defaults can be overwritten.
The List function may also be available for some of the fields. In a few of the forms, special
function keys will allow you to query using a couple of different query criteria blocks. The usage
of wild cards (%) in character fields for restricted queries is form dependent, but “K%” is usually
allowed to represent all KP data types. To perform a query, enter valid values (validation is
performed for restricted queries) for each field in the block and invoke the Next Block function.
A query will automatically be performed based on the values you specified. If no records match
your query criteria, the cursor will be returned to the query criteria block allowing the criteria to
be respecified. Otherwise, your cursor will reside on the first matching record.
3.5.8.2 How To Perform Unrestricted Queries
Many of the forms allow unrestricted queries, which are very flexible. You can retrieve all of the
records, or you can specify a simple or complex query criterion.
3.5.8.2.1 Retrieving All Records
To retrieve all records, simply invoke the Execute Query function without specifying a criterion.
It does not matter whether or not you are in Enter Query mode when you invoke Execute Query.
However, you should commit any database changes that you have performed before performing
the query.
3.5.8.2.2 Selective Queries
To retrieve records based on a certain criteria, you must be in Enter Query mode first. If your
status line does not indicate ENTER QUERY on it, invoke the Enter Query function after you
have committed any record changes that you have made. You can then proceed to specify your
query criteria using one or more of the fields in the block. The List function may be available for
some of the fields, but no field validation checks are performed on the values you enter. If you
enter invalid field values, the query will not return any matching records and the form will
remain in Enter Query mode.
For character fields, you have a choice of entering an exact value or a string pattern with wild
cards. The wild card for ORACLE is a percentage symbol (%) which represents any combination
of characters including no characters. The underscore symbol (_) is also available to represent a
single wild-card character. The following list contains examples of string patterns and matches:
Pattern Possible Matches
GE_LZ% GE_LZ_PWI_19920101_V01, GE-LZ-PWI
%KPGS% KPGS_IT, GE_PWI_KPGS_PROGRAM, CDHF_KPGS
S_AR_ SMART, SHARK
_IN%S BINS, WINNERS
38
KPGS KPGS
When you have completed your selection criteria for a query, invoke the Execute Query
function, which will return any matching records. SQL*Forms will display a “Working…”
message until the query is completed. If records are retrieved, use the Down and Up functions to
review them.
3.5.8.2.3 Advanced Query Techniques
Once you have mastered basic queries, a few advanced query features are available for
unrestricted queries while in Enter Query mode. These advanced features allow you to reexecute
the last query and to execute complex query criteria.
3.5.8.2.3.1 Retrieving the Last Query Criterion
To retrieve the query criterion you used for your previous query in a block, invoke Enter Query a
second time. The previous criterion will be displayed. You can change the criterion, as required,
and invoke Execute Query to retrieve the matching records.
3.5.8.2.3.2 Using Relational Operators
Within the field-length restrictions, you can specify query criteria values with relational
operators rather than specific values. For example, you can retrieve all KPGS programs with
more than one output file by simply specifying >1 in the field corresponding to the number of
39
output files. For character and date fields, you must include single quotes around your value. The
following list contains the relation operators available:
Operator Meaning Example
= Equal to = ‘DDF’
<> Not equal to <> ‘DDF’
> Greater than > 1
>= Greater than or equal to >= 2
< Less than < 3
<= Less than or equal to < = 2
BETWEEN Between two values (inclusive) BETWEEN 2 and 5
Unfortunately, this feature often cannot be used because a field length is too small. In such cases,
the SQL Where Clause feature can be used instead.
3.5.8.2.3.3 Creating a SQL Where Clause
If you are familiar with SQL, another feature is available that allows you to build a complex SQL
Where clause as your query criterion. This feature is useful for expressing compound conditions,
null value conditions, and relational conditions that cannot fit into a query field. Because the
feature uses a special pop-up window similar to an Edit window, a very large Where clause can
be specified, including nested Select statements.
To invoke the Query Where pop-up window after the form is in Enter Query mode, enter a colon
(:) immediately followed by an alphabetic variable name in one or more fields and invoke
Execute Query. Unless you are familiar with the table column names, you should put a colon and
variable name in each field you need to reference in the Where clause. When the Query Where
pop-up window appears, you can proceed to enter your SQL Where clause conditions, but you
do not need to type Where first. When you have completed the Where clause, invoke Accept to
retrieve the corresponding records. The following list contains example Where clauses for five
prespecified variables (:PROG, :VER, :IDATE, :DESC, and :FILE#):
Purpose Where Clause
Retrieve all programs with no
description or an installation
date greater than January 1,
1993.
:DESC IS NULL OR :IDATE > ‘01-JAN-93’
40
Retrieve all programs that have
more output files than skeleton
files.
:FILE# > (SELECT COUNT(*) FROM DATA_OUTPUT_RELATION
WHERE PROGRAM_NAME = PROCESS_PROGRAM.:PROG AND
PROGRAM_VERSION = PROCESS_PROGRAM.:VER)
3.5.9 How To Modify the Database
Unless you are a read privilege user, you will probably want to modify parts of the database
eventually. This section explains how to create, update, and delete a record, the three types of
database modifications available. To perform any type of modification, it is first necessary to
understand the concept of Commit and Rollback.
3.5.9.1 Commit and Rollback Overview
This section explains the commit and rollback concept and how it works.
3.5.9.1.1 What Is Commit and Rollback
When you modify records in a form, you are not directly modifying the database. Instead, you
are modifying your own private working buffer area based on the database. These changes can
only be viewed by you until they are saved to the database. SQL*Forms automatically manages
any conflicts between users by locking each record as it is changed. If you attempt to change a
record that another user has already changed in another buffer area, SQL*Forms will not let you
change the record until the other user saves his changes and you requery the record.
When you are satisfied with your changes, you can save them in the database by performing a
commit.
+A commit will process all record inserts, updates, and deletes completed in all blocks of
your form since your last commit. A commit is an all-or-nothing transaction. If there are
any errors, none of the changes will be saved in the database. Therefore, you must resolve
any errors so the other changes can be committed.
A rollback is an undo of any or all changes made in your buffer area. It can be accomplished by
clearing a record, block, or entire form. You cannot roll back a change once it is committed to
the database. When you accidentally commit an incorrect change, you can repair the database by
deleting an unnecessary record, updating a record to restore previous field values, or creating a
replacement record for a record accidentally deleted. You can also contact the DBA to see if a
restoration of certain data is possible.
3.5.9.1.2 How To Commit Database Modifications
Once you are ready to save your changes to the database, simply invoke the Commit function.
When a commit is processing, it may perform various validation checks and other SQL
statements. If an error is detected, a message and the associated record will be displayed for
correction. When the correction is completed, you must invoke Commit again.
Although SQL*Forms can buffer a few hundred record changes, you should commit frequently.
For example, you should commit after one large entry or a few small entries. If you do not
commit frequently, you risk losing a lot of work because of one error or an unexpected system
problem. In addition, you potentially prevent other users and processes from completing their
41
changes. Finally, you should commit any changes you want to save before invoking the
following functions:
• Enter Query
• Execute Query
• Exit/Cancel
• Clear Block
• Clear Form/Rollback
• Count Query Hits
If you have made changes that have not been committed or rolled back when you invoke these
functions, a commit alert pop-up window will appear. For example, if you accidentally enter a
query criteria while in Insert mode instead of Enter Query mode and then invoke Execute Query,
a commit alert will be displayed because SQL*Forms thinks you forgot to commit a new entry.
If you respond “Yes” to the commit alert, the changes will be committed, and the function will
proceed. If you respond “No,” the changes will be rolled back, and the function will proceed. If
you respond “Cancel,” the function that you just invoked before the commit alert will be aborted.
3.5.9.1.3 How To Roll Back Database Modifications
To undo all changes made in all blocks of a form, invoke the Clear Form function. To roll back
all changes within one block only, invoke the Clear Block function. To roll back a new or
updated entry, invoke the Clear Record function. The only way to roll back a record deletion
(after the Delete Record function but before Commit function) is to invoke Clear Form or Clear
Block in the applicable block. Answer “No” to the commit prompt displayed by the Clear Block
and Clear Form functions to complete the rollback.
3.5.9.2 How To Create New Records
To create a new record, complete the following steps:
1. If your cursor is not on a blank record, either invoke the Insert Record function or invoke
the Down function until your cursor is on the record after the last nonblank record. If you
cannot access a blank record with these functions, you do not have insert privilege for the
form.
2. Enter values into the fields for the record. Typically, the first few fields are mandatory
while the remaining fields may be optional. SQL*Forms will inform you if you did not
enter a value in a required field. It will also inform you if you have entered incorrect
values.
3. If there is a detail block or pop-up window in the form, you may need to create entries
that correspond with the entry you just made in the master block. It is optional to commit
the master block record first.
4. Commit your entries before proceeding to a new set of entries.
3.5.9.3 How To Update a Record
To update a record, complete the following steps:
1. The database record you want to update must be in your working buffer first. If it is not
in your buffer, you must perform a query to retrieve it.
42
2. Once your cursor is on the record you want to update, you can make the changes directly
on top of the previous values. The fields that uniquely identify a record cannot be
changed. They are always the first field(s) in the form. If you do not have update
privilege on a field, you also will be unable to change it. If you want to change a field so
it has no value, invoke the Clear Field function in that field. SQL*Forms will perform
field validations for updates as well as inserts.
3. When you have completed your update(s), commit your changes before completing other
changes or queries.
3.5.9.4 How To Delete a Record
To delete a record, complete the following steps:
1. The database record you want to delete must be in your working buffer first. If the record
is in your buffer already and it has never been committed, you only need to invoke the
Clear Record function to remove it from your buffer. If it is not in your buffer, you must
perform a query to retrieve it.
2. Once your cursor is on the record you want to delete, invoke the Delete Record function.
If the Delete Record function is disabled, you do not have delete privilege. If the record is
not in a pop-up window, you will be prompted to confirm the deletion. If you answer the
prompt with a “Y,” the record will disappear and be marked for deletion. If you answer
the prompt with an “N,” the record deletion is aborted. When you delete a record with
dependencies, the deletion may be prevented or the dependencies may also be deleted, as
documented for each form in Section 4.1.2.
3. To make the deletion permanent in the database, you must commit the deletion.
3.5.10 Editing Capabilities
3.5.10.1 Inserting, Replacing, and Deleting Characters
SQL*Forms has two modes for working with characters: Insert and Replace. The current mode is
always on the status line, and it can be toggled by invoking the Insert/Replace function. To
insert, replace, or delete characters, complete the following steps:
1. To insert characters between existing characters, change the character mode to Insert and
type the new characters. You should change the character mode back to Replace
immediately after inserting characters. No character will be inserted if the field is full.
2. To replace characters, change the character mode to Replace and type over the characters
to be replaced. Replace mode also works well when entering characters into blank fields.
3. To delete characters, put the cursor to the right of the characters to be deleted and invoke
the Delete Backward function.
3.5.10.2 Working With Large Text Fields (Edit Window)
When working with truncated fields or fields with more than 60 characters, invoke the Edit
function. It will redisplay the full field in a multiline pop-up window complete with automatic
wordwrapping. Additionally, several edit functions are available in an edit window such as
Search, Select, Cut, Copy, and Paste.
Sections 3.5.4.4.5 and 3.5.7.5 describe in detail the editing functions and navigation.
43
3.5.11 Screen Prints
To print the current screen display, invoke the Print function. A pop-up screen will be displayed
with three print options. The first item contains a default filename for the screen output. The
name can be changed. By invoking the Next Field function (Tab), access the other two options.
To print the file on the large printer in the CDHF computer room, invoke the Select function or
type X in the second option. To write the keypad map to the output file instead of the current
screen, invoke the Select function or type X in the third option. When all the options are correct,
invoke the Accept function or press [RETURN].
3.5.12 Screen Redisplay
If the screen display is overwritten by broadcast messages or bad communication signals, refresh
the screen by invoking the Refresh function.
3.5.13 Common Errors
This section describes the messages or symptoms for common SQL*Forms errors and the
corresponding reason and/or solution for each. If you encounter other errors that you cannot
resolve, contact the DBA for a resolution. Most errors appear directly on the message line only,
but more information can be obtained for some errors, especially ORACLE errors, by invoking
the Display Error function. The messages that only appear in the Display Error information are
identified accordingly.
Symptom/Message The commit prompt window appears when a query is attempted.
Explanation You may have forgotten to put the form into Enter Query mode before you
specified the query criteria. Consequently, SQL*Forms believes you
forgot to commit a new entry. Alternatively, you have changed data
without committing it.
User Action If you forgot to put the form into Enter Query mode, answer “No” to the
commit prompt, invoke the Enter Query function, re-enter your criteria,
and invoke the Execute Query function. If you did forget to commit data
modifications, answer “Yes” to the commit prompt.
Symptom/Message The commit prompt window appears when you have not made any
deliberate or accidental data modifications.
Explanation This behavior should not occur.
User Action Answer “No” to the commit prompt, and report the form name and the
function invoked to the DBA.
Symptom/Message Function key is disabled for this block.
Explanation In many of the form blocks, keys are disabled either because they are not
applicable to the block or because the current user’s privileges does not
allow the function. For example, Enter Query and Execute Query are
disabled for query criteria blocks because they are not applicable to
44
restricted queries. If you believe that you should have privilege for a
disabled function, contact the DBA for a resolution.
Symptom/Message Insufficient privileges to perform this database change operation. or ORA-
01031 insufficient privileges (Display Error)
Explanation Your user-privilege classification does not allow you to perform the type
of data modification attempted. If you believe that you need the privilege,
contact the DBA for a resolution.
Symptom/Message No user information exists for this account. Contact the DBA.
or
A fatal error occurred setting up form. Contact the DBA.
User Action Inform the DBA that your VAX account is not set up in the ISTP_USER
table. Alternatively, a database error occurred when the common globals
variables were initialized upon entry into the Database Interface System.
Symptom/Message Upon entry into the Database Interface System, a screen appears
prompting you for a user name as password.
User Action This symptom should not occur unless you have been issued a specific
user name and password for ORACLE usage. If you have multiple VAX
accounts, make sure you are using the one that was set up for ORACLE
usage. Otherwise, inform the DBA that an ORACLE account needs to be
created for your VAX account.
Symptom/Message The function key mappings displayed when you invoke Show Keys
([CONTROL], K) do not map to your terminal, or the functions do not
activate.
User Action Be sure to review the terminal support information in Section 3.5.3.1.2. If
you are using an emulator, you may need to review your emulator
documentation to determine how the emulator maps DEC terminal keys to
your terminal. You may need to set up the declaration for the VT100
emulator keypad mapping in your LOGIN.COM to avoid emulator keypad
mapping problems.
Symptom/Message You cannot move the cursor down until this record is entered or deleted.
Explanation SQL*Forms will not let you move down past the first blank record.
Symptom/Message Field cannot be updated - primary key or insufficient privileges.
User Action All fields that uniquely identify a record cannot be updated. You need to
delete the record and insert it again with the correct primary key values.
Alternatively, you tried to change a field for which you do not have update
privilege. Contact the DBA if you believe you should have update
privileges on the field.
45
Symptom/Message ORA-00001 duplicate key in index (Display Error)
User Action Another record with the same primary key or alternate key values has
already been created. Either adjust the primary key values accordingly or
invoke Clear Record to remove the record from your change buffer.
Invoke the Commit function again if other records were changed.
Symptom/Message Field is full. Cannot insert character. Check if in Insert character mode.
User Action The field only allows a fixed number of characters which you have
exceeded. If your character mode on the status line indicates Insert, you
may need to change it to Replace (Insert/Replace function) so you can
type over characters already entered.
Symptom/Message No records match the query criteria. Correct criteria or use Abort Query.
User Action There are no records in the database that match the query criteria you
specified. After you recheck and correct your query criteria, you can
invoke the Execute Query function again. If you do not want to query
again, invoke the Exit/Cancel function to terminate the Enter Query mode.
Symptom/Message Record changed by another user. Requery to see change.
User Action Since you performed your query, another user has updated at least one of
records you have queried (but not changed). Commit any changes you
have completed and reexecute your query to view the latest record values.
3.6 How To Use ORACLE Reports
ORACLE reports are an alternative, view-only representation of the CDHF database that allow
users to write data in a fixed format to an output file. The output file may be displayed to the
screen, printed on a system printer, or transferred to remote sites. Although many of the reports
allow you to specify various report query criteria parameters, all the reports operate in the same
general manner. This section describes how to generate a report, how the output files are named,
and how to view a report. Section 4.1.3 describes the purpose, contents, width, and user-
definable criteria for each report.
3.6.1 Defining the Report Output Directory
By default, the report output files will be generated in your home directory (SYS$LOGIN), the
directory you are in when you first log in to your VAX account. You can route the reports to a
different directory by defining the DBI_RPT_DIR logical in your LOGIN.COM.
The report output filenames generated cannot be customized. You can use the DCL RENAME
command to change a report name after it is generated. All report output filenames have the
following format:
DBI_xxxx.RPT
The xxxx represents the acronym associated with a particular report.
46
3.6.2 Selecting the Report Mode
Before you generate a report, you can choose between two report modes, interactive or batch.
The interactive mode generates the report while you wait, then prompts you to indicate whether
you want the output file displayed to your screen and whether you want it printed on your default
system printer. The batch mode submits a job to the batch queue and allows you to continue
other operations while it is executing. When the batch report is completed, you will be informed
by a broadcast message, but you must exit to the DCL prompt to view the contents of the output
file generated.
The current report mode is always displayed in the upper, left corner of the submenus. If a report
has an associated user-definable criteria form, the current report mode is also displayed in the
form. To change the report mode in a submenu, invoke the special function key SF1, which will
toggle the mode between interactive and batch. When the report mode is changed, the new mode
will be used for all reports generated until you change the mode again or exit the Database
Interface System.
3.6.3 Selecting the System Printer
By default, if you choose to print a report when prompted by the interactive report mode, it will
be printed on the large printer in the ISTP CDHF computer room. You can permanently route the
reports to a different printer by defining the DBI_PRINTER logical in your LOGIN.COM.
Section 4.1.1.2 contains the instructions for setting up this change. The printer selected, however,
must be a printer recognized by the VAXcluster. Alternatively, you can use the System Printer
Selection Form in the Database Interface System main menu to change your default printer
selection using the list of values feature to display all the system printers. The printer selection
will be active for all reports generated until you change it again or until the current login session
is terminated.
+Please note that the printing of reports on the CDHF computer systems will not be very
useful for remote users. Most users will want to create a report file and then transfer the
file to a local system.
3.6.4 Activating a Report
To activate a report, navigate through the menu tree until your cursor is on the menu item
associated with the report. The reports and the associated menu tree paths are listed in
Section 4.1.1. Once your cursor is on the correct report and the selected report mode is set,
invoke the Accept function or press [RETURN].
If your report does not allow any user-definable report criteria, it will execute immediately. If
your report does allow criteria to be specified, a query criteria form will be displayed. Query
criteria forms work in the same manner as query criteria blocks for restricted queries (no form
modes). Simply enter valid values for the fields displayed. Many fields have lists of values
available by invoking the List function. When you have finished entering the values, invoke the
Accept function, which will execute the report with the criteria. If you want to cancel the report
generation instead, invoke the Exit/Cancel function.
3.6.5 Displaying a Report on the Screen
If you generate the report using the interactive report mode, you can choose to display the report
on the screen when you are prompted. The screen width will automatically be adjusted to the
47
report width, and the report will be displayed one screen page at a time. You can press
[RETURN] to view the other screen pages until the end of the report, or press [CONTROL] and
Z to abort the display. If you generate the report using the batch report mode, you can only view
the report using an editor or the DCL TYPE command after you exit to the DCL prompt.
Notes:
1. When using an emulator, the screen width may not be adjusted properly to the report
width. Some emulators do not respond to the VT terminal width commands.
2. At the beginning of each page in a report output file, there is a form-feed control
character allowing reports to be printed properly. Because screen page sizes are smaller
than printed page sizes, the control characters are displayed rather than interpreted when
you display the report to your screen.
3. If your terminal supports window lengths greater than 24 lines (VT1200s and
VAXstations), the DCL SET TERM/PAGE=# command is recommended before
entering the User Interface so your reports are displayed correctly. Alternatively, the
customize window option can be used for VT1200s and VAXstations to set the page
length to 45 lines or greater. If the page length is not set to 45 lines or greater, the screen
may flash, and the last page of the report may not display.
3.6.6 Printing a Report
If you generate the report using the interactive report mode, you can choose to print the report
when you are prompted. If you generate the report using the batch report mode, you can only
print the report using the DCL PRINT command after you exit the User Interface. If your printer
is not recognized by the VAXcluster, such as remote site printers, you will need to transfer the
report and print it locally.
3.6.7 Transferring a Report
You can transfer a report using the Data Transfer Services (Create Transfer Request for User
Files option) in the User Interface. If your computer is not recognized by the network (as an
authorized RDAF), such as the case with some modem users, you can use a file transfer utility
such as Kermit. Most communication packages include a file transfer utility. A manual copy
command to the RDAF may be required if the RDAF does not support DECnet proxy accounts
or TCP/IP anonymous accounts.
4
7
SECTION 4—USER INTERFACE SYSTEM
This section provides a detailed description of the functions, services, and usage of the UI. There
is a subsection corresponding to each of the items of the main menu (Figure 4–1).
Figure 4–1. CDHF User Interface Main Menu
The following list summarizes the menu items and their functions.
•CDHF Queries and Reports—Provides a form-based interface to the CDHF database
used to query the database for information and to generate reports from the database.
•User Data Transfer Services—Provides the user with the capability to request the transfer
of ISTP data from the CDHF to a user-specified destination.
•Update Key Parameter Quality Information—Provides authorized users with the
capability to insert a quality flag into the CDHF database for key parameter files.
•Certify Key Parameter Generation Software —Provides authorized users with the
capability to insert a flag indicating that Key Parameter Generation Software is
generating key parameters suitable for distribution.
•Decommutation Specifications—Allows the user to specify minor frame and byte
extraction masks to be applied to level-zero files requested through the User Data
Transfer Services.
• Invoke Theory Programs—Allows the user to choose which theory program to run.
•Extract NRT Level Zero Data—Provides the user with the capability to extract near-real-
time (NRT) decommutated level-zero (LZ) data.
• Plot Orbit Data—Provides the user with the capability to plot orbit data.
48
• Access the NEWS Bulletin Board—Invokes the CDHF bulletin board.
4.1 CDHF Queries and Reports
4.1.1 Introduction
The CDHF database maintains information on the receipt and processing of science data; the
attribute information on science data; the DDF distribution history; and the user account and
privilege information. The CDHF Queries and Reports menu item allows users to view this
information and allows controlled updates of the data.
The Queries and Reports menu consists of integrated menus, forms, and reports. The menus
divide the database into the various functional areas and invoke the forms and reports within an
area. The forms and reports allow users to view the information of interest.
In most cases, users can view a certain piece of information by either invoking a form or a report.
Thus, each user has to make a choice whether to use a form or report to obtain this information.
Each method has different advantages.
A report strictly executes a standard query, and writes the information in a fixed format to an
output file. Many of the reports do allow the user to specify a range of values. For novice users,
reports are considerably easier to use than forms. Another advantage of reports is that the output
files can be transferred to remote sites for evaluation or printing.
A form usually allows ad hoc queries and controlled database modifications. A screen print can
be generated from a form, but only the information currently displayed is written to the output
file. The advantage of forms is that they allow a user to quickly retrieve, review, and modify
information in an ad hoc manner and without the generation of output files. However, a user
must become familiar with the basic SQL*Forms components and functions to use a form.
Under the main menu for Queries and Reports, seven submenus represent the functional areas
within the database:
1. The Data File Information menu contains forms and reports about the scientific data files
routinely cataloged on the CDHF.
2. The File Processing Information menu includes forms and reports for process queue
information, process history information, process program information, calibration data
file information, and parameter file information.
3. The ISTP Users and Privileges form allows users to set up default query criteria and to
view their access privileges.
4. The Data Quality Information menu contains forms and reports for the quality data
extracted from level-zero quality files.
5. The DDF Distribution Information menu contains forms and reports for the DDF
distribution status including user distribution list and file content for each data set.
6. The Static Mission Information menu contains forms and reports for miscellaneous data
such as the active missions and descriptors/instruments.
7. The System Printer Selection form allows local GSFC users to select a CDHF printer for
reports.
Figure 4–2 contains a graphical representation of the menu tree for the Queries and Reports
menu.
49
4.1.2 Database Interface System Forms (Including KPGS Certification)
This section contains an overview, a picture of the main screen, the usage restrictions, and the
detailed usage guidelines for each form in the Queries and Reports menu.
50
Data File
Information
Menu (SM1)
Science Data
File Information
Form (DFF)
Data Files
Stored
Online
Report
(DFSR)
Data Files
Received
Report
(DFRR)
Data File
Certification
Status
Report
(DFCR)
Data Files
Retransmitte
d Report
(DFXR)
Data File
Types and
Retentions
Form (DFTF)
Data File
Input/Output
Directory
Form
(DIODF)
Working
Data File
Report
(WFR)
Working
Data File
Form
(WFF)
Data
Files
RepCata
loged
ort
(DFR)
File
Processing
Information
Menu (SM2) File
Processing
Reports
Menu (SM21)
Data
Process
Queue Form
(DPQF)
Data
Process
History Form
(DPHF)
Process
Program
Information
Form (PPF)
Calibration
Data
Information
Form (CDF)
Parameter
File
Information
Form (PFF)
|
Data Process
Queue Report
(DPQR)
Key
Parameters
Reprocesse
d Report
(KPRR)
Process
History
Report - By
Input File
(IFPH)
Process
History
Report - By
Output File
(OFPH)
Process
History
Report - By
Program
Name
(KPFR)
Process
Program
Information
Report
(PPR)
Calibration
Data
Information
Report
(CDR)
Paramete
r File
Informatio
n Report
(PFR)
User Data
Services
Information
Menu (SM3) ISTP Users and
Privileges Form
(IUF)
ISTP Users
Report
(IUR)*
Data
Transfer
Services
Requests
Report
(UDSR)
Daily
Transfer
History Form
(DXHF)
Daily
Transfer
History
Report
(DXHR)
Data Quality
Information
Menu (SM4) Data Quality
Information Form
(DQF)
Data Quality
Information
Report
(DQFR
Facility File
Transfer
Information
Menu (SM6) Data Transfer
Queue Form
(DTQF)
Data
Transfer
Queue
Report
(DTQR)
Retransmit
Requests
Report
(RRR)
Data
Transfer
History Form
(DTHF)
Data
Transfer
History
Report - By
File Type
(DTHR)
Data
Transfer
History
Report - By
Facility
(DTHR2)*
Data
Transfer
Relation
Form
(DTRF)
Data
Transfer
Relation
Report
(DTRR)*
Static Mission
Information
Menu (SM7) ISTP Missions
Launched Form
(IMF)
ISTP
Missions
Launched
Report (IMR)
Mission
Descriptors/
Instruments
Form (MDF)
Mission
Descriptors/
Instruments
Report
(MDR)
Data
Directory
Information
Form
(DADF)
Data
Directory
Information
Report
(DADFR
Database
Interface
Menu Setup
Form
(MENU)**
System Printer
Selection
Form
(RPTFSP)
* Accessible by DPS/DBA only
** Accessible by DBA only
Figure 4-2. Queries and Reports Menu Tree
51
4.1.2.1 Science Data File Information Form (UI_DFF)
This form is used to display information about the science data files. The data file information
form is used for query only. However, any user with the appropriate certification privilege may
update key parameter information.
Format:
52
Usage Restrictions:
•Queries may only be performed from the first block. Enter query criteria and press Next
Block to view data file information. If the user has a default mission, data type, and
descriptor, it will be displayed as a default query criteria.
•Regular users may only view the information for science data files, unless they have
certification privilege for a mission instrument.
•Users with key parameter certification privilege are allowed to update key parameter
information.
Detailed Usage Guidelines:
•Wild cards (%) are allowed for the Mission Name, Data Type, and Descriptor in the
query criteria block. The only wildcard allowed for data type is K% (all KP files).
•For the query criteria block, the Mission Name, Data Type, Descriptor, Start Date, and
End Date must be specified. Date ranges should be limited to 90 days or less to avoid
excessive queries.
•For queries with multiple versions of a logical identifier, only the most recent version
will be displayed by default. To view all versions of a logical identifier, the user must
change the “Query All Versions” attribute in the ISTP User Information and Privileges
form to “Y”.
•Online determines the catalog status of the file. If online is set to “N”, the physical files
are not available on the CDHF, but they may be retransmitted from the DDF.
•Start Date and End Date contain the first and last dates and times associated with the
header file. They represent the telemetry span dates of all the reference files associated
with the header file.
•Catalog Date and Expire Date indicate the date and time the file is cataloged and the date
the file is to be taken offline, respectively.
•Group Size indicates the sum of the file sizes in bytes, associated with all the files in the
logical group.
•Proprietary Expire Date is the date the file is no longer proprietary. It usually applies to
level-zero files only. Explicit access privileges are required to transfer files that are still
proprietary.
•The special function key SF1 allows users to view a list of associated reference files.
Press SF1 to invoke the pop-up. Press Exit to return to the main screen. This pop-up is for
viewing reference files only.
•The special function key SF2 allows users to view the KP certification information. The
access is limited to K% data types only. Press SF2 to invoke this pop-up. Press Exit to
return to the main screen. Only users with certification privileges may update the quality
indicator (RED, YELLOW, GREEN) and the comment. Other users may only view
certification information, if any is available.
•The special function key SF3 allows users to view Flight Dynamics Facility (FDF)
despun platform attitude difference information. Press SF3 to invoke this pop-up. Press
Exit to return to the main screen. Access is limited to the PA data type only.
53
Format:
Format:
54
4.1.2.2 Working Data File Form (WFF)
This form is used to display information about the working orbit/attitude data files. The working
data file form is used for query only.
Format:
Usage Restrictions:
•Queries may only be performed from the first block. Enter query criteria and press Next
Block to view working data file information.
• User may only view the working data file entries.
• No inserts, updates, or deletes are allowed in the second block.
Detailed Usage Guidelines:
•For the query criteria block, the Mission Name, Datatype, Descriptor, Start Date, and End
Date must be specified. Date ranges should be limited to 90 days or less to avoid
excessive queries.
•For querires with multiple versions of logical identifiers or multiple entries, only the most
recent will be displayed by default. To view all versions of a logical identifier, the user
must use the Down key.
•Start Date and End Date contain the first and last dates and times associated with the
header file.
•Catalog Date and Expire Date indicate the date and time the file is cataloged and the date
the file is to be taken offline, respectively. File size indicates the size of the file in bytes.
55
4.1.2.3 Data Process History Form (DPHF)
This form displays the data process history. The data process history entries are created by an
ICSS routine upon successful completion of key parameter generation. A user can query the data
process history information by process program name, by an input file (primary or support file),
or by an output product file (key parameter file).
Format:
Usage Restrictions:
• Users may only view the data process history entries.
•Pop-up windows for special function keys SF1 and SF2 are view only. No inserts,
updates, or deletes are allowed in their second block.
Detailed Usage Guidelines:
•To query the process history information by a program name, enter the program name,
process completed start date, and process completed end date, the mandatory query
criteria. DBA and DPS users are allowed to enter wild card (%) for the program name.
•To query the process history information by an input file, use the special function SF1 to
bring up the pop-up window. Press the Next Block key after entering a specific input
filename. To view the detailed information for any entry in the pop-up window, place the
cursor on the entry and press the Accept key. The cursor will return to the main window
and the detailed information for the entry selected will be displayed. To exit the pop-up
window without selecting an entry, press the Exit key.
•To query process history information by an output product file, use the special function
SF2 to bring up the pop-up window. Press the Next Block key after entering a specific
output product filename. To view the detailed information for any entry in the pop-up
window, place the cursor on the entry and press the Accept key. The cursor will return to
the main window and the detailed information for the entry selected will be displayed. To
exit the pop-up window without selecting an entry, press the Exit/Cancel key.
56
•The special function key SF3 displays a pop-up window with the input support files used
by the process entry currently displayed in the main window. Press the Exit key to return
to the main screen.
•The special function key SF4 displays a pop-up window with the output product files
generated by the process entry currently displayed in the main window.
• The process summary field is not active now.
4.1.2.4 Process Program Information Form (PPF)
The form displays the information for each file processing program in the operational baseline.
Currently, all the file processing programs are used for key parameter generation. The Scheduler
will only complete processing if all the information is provided for a program. With the
exception of KPGS "Certify Status" and associated "Program PI Comment," which are the PI's
(or other authorized user's) responsibility, the DBA maintains the information in this form based
on information provided by the PIs and the Key Parameter Integration Test Team.
Format:
Usage Restrictions:
•A user with key parameter certification privilege may certify the KPGS program that
generates the key parameters.
•Regular users may only view the program information. The queries in this form are
unrestricted.
• A DBA user may create, update, or delete the program information.
• A DPS user may update the Process Queue Name field.
4.1.2.4.1 Detailed Query Usage Guidelines
•For non-DBA users, the form is in Enter Query mode upon entry. A query criteria, if any,
can be entered followed by the Execute Query key to view the program information. To
57
view all the programs and versions that match the query criteria, press the Down key until
the end of the list.
•For a brief view of several programs simultaneously, use the first special function key
(SF1). Warning: If you are in Enter Query mode, you must press Exit/Cancel first to
terminate the Enter Query mode. Use the Down or Scroll Down key to view the complete
list of programs. To view the detailed information for any entry in the pop-up window,
place the cursor on the entry and press the Accept key. The cursor will return to the main
window and the detailed information for the entry selected will be displayed. To exit the
pop-up window without selecting an entry, just use the Exit/Cancel key.
•The second special function key (SF2) displays a pop-up window with the data file types
for the primary input files used by the program version currently displayed in the main
window. Any type of input file such as level-zero and SIRIUS that requires regular
processing by a program must have this data file type information. The Cataloger will
automatically build entries in the Data Process Queue table/form based on these entries.
Press the Exit key to return to the main window.
•The third special function key (SF3) displays a pop-up window with the data file types
used as input support files during processing by the program version currently displayed
in the main window. For example, orbit, attitude, calibration, parameter, and level-zero
housekeeping data may be required to complete key parameter generation. The
information is used by the Scheduler and the ICSS routines to retrieve the applicable data
files with this information. Press the Exit key to return to the main window.
•The fourth special function key (SF4) displays a pop-up window containing the CDF
skeleton table (format) files required for each file generated by the program version
currently displayed in the main window. The number of entries must match the number
of output files generated starting with file number zero for the K0 output file. Press the
Exit key to return to the main window.
•When a new version of a program is approved for the operational baseline, a new set of
entries is required with the appropriate changes for the new version. Thus, the
requirements for a program can be changed with new releases of a program. The
Scheduler will use the highest version of a program that has an effective date range for
the primary input file. The effective dates must be carefully assigned to allow the newest
version to be used for new data files and to allow older versions to be used, as necessary,
for reprocessing older data files. The program version is composed of a “V” and up to a
four-digit real number, such as V1.0.
•The program location is the complete physical filename for the executable associated
with the logical program name. The program location name should be slightly different
for each new version of a program. The physical filenames specified for program location
and the CDF format files must be existing, online files.
•Currently, the output data types are always KP, representing the K0 through K9 data
types, and PA, representing platform attitude. The output descriptor is the instrument or
subcomponent that the generated files represent. The logical filename for the output files
is composed of the mission name of the primary input file, the output data type (i.e., “K”
and the output file number starting with K0), the output descriptor, the file date of the
primary input file, and a version (V01 if new, highest version plus one if reprocessed).
•The secondary required flag indicates that the input files for the previous day are also
required. Secondary files are not applicable for calibration and parameter data files.
58
•If the number of input calibration files is greater than zero, a single data file type
dependency must be declared in the input support data file types pop-up window with CD
as the data type.
•If orbit or attitude files are required as input support files, the descriptor should always be
specified as definitive (DEF). The Scheduler will automatically use the predictive version
of a file if the definitive file is not available.
•The skeleton table format files are used to generate the appropriate CDF format for the
generated key parameter output files. The physical filenames for skeleton table files
should include the disk/directory logical and the filename, but no file extension.
4.1.2.4.2 KPGS Certification Guidelines
•The Certify Status indicates whether the KPGS program has been certified (i.e., the
program is believed to be generating key parameters suitable for distribution).
•Users with certification privilege for the key parameters generated by a KPGS program
also have certification privilege for the program itself.
•An uncertified program will generate key parameter files that will be cataloged in the
system. However, files generated by uncertified programs will not be sent to the DDF for
distribution on CD-ROM (although they will be sent to NSSDC for archiving). Once a
KPGS program is certified, the latest versions of all files generated by that program are
sent to the DDF for distribution.
Exception: If a new version of a program is delivered, installed, and certified before the
previous version has been certified, then all files generated by the previous version will
be removed from the system and will not be sent to the DDF.
• Once a KPGS program has been certified, it may not be uncertified.
•The username (VAX user ID) of the person certifying the KPGS program and the date
certified are automatically entered when the program is certified. A comment field, with
room for several lines of text, is provided for entering comments about the program.
+Refer to page QT-11 in the "Quick Tour of the CDHF User Interface" for a step-by-step
example of how to certify a KPGS program.
Format:
59
4.1.2.5 Calibration Data Information Form (CDF)
This form displays calibration data file information for file processing. Because calibration files
are relatively static for a long period of time, they are manually cataloged by the DBA, separate
from the regular scientific files, after key parameter generation integration testing.
60
Format:
Usage Restrictions:
• Regular users may only view the calibration data entries.
• Only a DBA user may create, update, or delete the calibration data entries.
Detailed Usage Guidelines:
•For non-DBA users, the form is in Enter Query mode upon entry. A query criteria, if any,
can be entered followed by the Execute Query key to view the calibration data
information. To view all calibration information that matches the query criteria, press the
Down key until the end of the list.
•The data type attribute does not appear on the form because it is always CD, for
calibration data. Thus, CD should be used as the data type in the Logical Identifier and
the Physical Filename.
•The mission name and instrument name attributes should be the same for the Logical
Identifier and the Physical Filename.
•The Logical Identifier is composed of the mission name; data type, which is CD for
calibration data, instrument name; file date; and data file version.
•The Physical Filename is the complete physical filename for the calibration data file. It is
composed of the disk/directory logical, the logical identifier, and the file extension. The
instrument component is recommended as the file extension.
•For a given mission instrument, multiple calibration files can be used for key parameter
generation. Each file is distinguished by a different instrument component. Each file can
also have multiple versions to specify different effective date ranges.
•The calibration files for the mission instrument with the highest version for each
component having the effective dates in the range of the process file (e.g., level-zero file)
are selected for processing.
61
4.1.2.6 Parameter File Information Form (PFF)
This form displays the parameter file information for the file processing. Parameter files are a
type of input support file available for the key parameter file generation. The physical filename is
retrieved during the initialization of the key parameter file generation. Because parameter files are
relatively static for a long period of time, they are manually cataloged by the DBA, separate from
the regular scientific files, after key parameter integration testing.
Format:
Usage Restrictions:
• Regular users may only view the parameter file entries.
• DBA users may create, update, and delete parameter file entries.
Detailed Usage Guidelines:
• For creating a new parameter file entry, the physical file must exist on the disk.
•The logical filename must consist of the mission name, data type (PF), and instrument
name.
•Although there may be multiple versions of a parameter file, only one parameter file can
be used for a given mission instrument during key parameter generation. The highest
version of the parameter file having effective dates in the range of the primary process
file date is selected.
4.1.2.7 ISTP Users and Privileges Form (IUF)
This form displays the account information and access/certify privileges for each ISTP user.
Regular users will be able to view the information for their own account upon entry into the
form. Each user must have an account entry in this form for most CDHF applications to function.
A user must have access privilege for a file type to decommutate or transfer a file. A user must
have certification privilege for a file type to update the key parameter quality information.
62
Format:
Usage Restrictions:
•Regular users may only view the information for their own VAX account. The account
information is automatically displayed for regular users upon entry into the form.
•Regular users may update their Default Mission Name, Data Type, and Descriptor. They
may also set the Query All Versions flag, as needed.
•DPS may update the Daily Transfer Quota, Default Mail Address, Default Destination,
Query All Versions, Default Mission Name, Default Data Type, and Default Descriptor
for any account.
• Only a DBA user may create or delete the account information and privileges.
Detailed Usage Guidelines:
•You may have more access or certify privileges than displayed at once. Use the Next
Block and Down keys to view any additional privileges.
•Wild cards (%) are allowed for access privileges to reduce the number of file types that
need to be entered. Because level-zero files contain proprietary data, the only wild card
that should be used generally for data type is K% (all KP files). Wild cards may be
assigned by the DBA for mission name and descriptor, as appropriate.
•For certify privileges, specific mission and instrument combinations must be specified
(no wild cards). In general, only the users on the team for an instrument may have the
associated certification privilege.
•The Query All Versions item allows you to specify whether you want all versions of a
file (Y) or just the most recent version of a file (N) when a query is performed. Toggle
this value to suit your query requirements in the other forms.
•If a default mission, data type, and descriptor are selected, these values will automatically
be displayed in many of the other forms as default values to reduce data entry.
•The Default Mail Address and the Default Destination (network node identifier and/or
directory) are used for UDS transfer requests if specific values are not specified for a
63
request. Transfers to a user directory on the ISTP computers require a complete directory
path for the destination. For TCP/IP transfers, a node name recognized by the network
should be specified. For DECnet transfers, a node name and directory can be specified.
See Sections 4.2.4 and 4.2.5 for information on network address specifications.
•The Daily Transfer Quota is the maximum number of VMS blocks (512 bytes/block) that
a user may transfer in a 24-hour period. The Data Files Stored On-line Report has file
size information. The Daily Transfer History Form has information about transfer
requests completed in the last 24 hours.
•The Privilege Group determines the user’s database privileges. Regular PI users are
assigned the USER privilege. Users who may not perform any database modifications are
assigned the READ privilege. DPS or DBA privileges may be assigned to the CDHF
operational personnel.
•The First Name, Last Name, Title, and Experimenter ID are currently used only for the
DDF distribution information. The Experimenter ID is the unique user identifier used by
the DDF. It is composed of the users first-name initial, last-name initial, and a two-digit
number in case multiple users have the same initials. The assignment of experimenter IDs
must be coordinated with the DDF.
•The DB User ID is the ORACLE account corresponding to a user’s VAX user name. The
VAX user name is used in all the forms and reports to identify a user. A VAX account
must exist before the account information is created. Likewise, the ORACLE account
should be created first.
4.1.2.8 Data Quality Information Form (DQF)
This form displays the data quality information and corresponding data gaps. The data quality
gaps are the top 10 frame gaps per data quality file. The data quality information and
corresponding data gap entries are created from the data quality file by the EXTRACT_LZ_QA
task. The data quality file is typically generated once a day per mission, but it may be generated
more frequently by incrementing the version.
Format:
64
Usage Restrictions:
• Regular users may only view the data quality information and corresponding data gaps.
Detailed Usage Guidelines:
• Mission Name, File Start Date, and File End Date are mandatory query criteria.
•The special key SF1 displays a pop-up window with the data gaps corresponding to the
data quality entry currently displayed in the main window. The length (in seconds) of
each gap field in the pop-up window is calculated by the form.
4.1.2.9 ISTP Missions Launched Form (IMF)
This form displays the active missions and associated information. This information is used to
validate and generate SFDU headers and to provide list of values for mission names.
Format:
Usage Restrictions:
• Regular users may only view the active mission information.
Detailed Usage Guidelines:
• Mission Name is the two-character acronym for the satellite.
• Mission Long Name is the formal name of the satellite.
• Project is the abbreviated name of the project supporting the mission.
•Spacecraft ID is the unique spacecraft number identifier used by level-zero files
associated with the mission.
•Satellite Identification Code is the unique spacecraft identification code used by orbit and
attitude files associated with the mission.
65
4.1.2.10 Mission Descriptors/Instruments Form (MDF)
This form displays active mission descriptors/instruments and associated information. This
information is used primarily for lists of values, mail message distribution for key parameter
generation completed, SFDU header generation/validation, and database administration. The
information is relatively static. Users with certify privilege are allowed to update mail
information.
Format:
Usage Restrictions:
•Any user with certify privilege on a given mission instrument will be able to update the
mail and user message directory information.
•All other users may only view mission descriptors. If the user has a default mission and
descriptor, they will be displayed and the query will be automatically performed. If the
user does not have defaults, the form will be in enter query mode upon entry.
Detailed Usage Guidelines:
•The Mission Name and Descriptor fields are primarily used for validation. The
Descriptor is the encoded name for an instrument or a more detailed description of a data
type, such as PRE for predicted orbit and attitude data. The Descriptor Name is the entire
acronym for a descriptor. It is often the same as the descriptor. The Descriptor
Description is the full name or description for a descriptor.
•The Descriptor Type indicates if the descriptor is mission dependent (M) or instrument
dependent (I).
•Discipline and Sub-Discipline are primarily used in the generation and validation of
SFDU headers. Discipline identifies the field or type of physics associated with a
descriptor and Sub-Discipline identifies the science, studies, or observations associated
with a discipline. Although the discipline is mandatory, specification of a subdiscipline is
optional.
66
•Mail indicates whether a mail message is sent to the PIs associated with a mission
instrument when a related key parameter file is generated.
•User Message Directory is the directory that will receive the KPGS user message files
and that contains the distribution list file (must be named DISTRIB.DIS) of users to be
notified by E-mail if the mail flag is set. This location must be specified as a full disk and
directory path, as shown in the following example:
ISTP_USER:[WI_3DP.SAM.UMSG]
The user is responsible for the creation of this directory. In order for the system to create
the user message file in this directory, access rights must be granted to the ICSS. This is
done by issuing the SET_UMSG command.
If you need to decommutate the level-zero files for the mission instrument, the instrument
number, number of minor frames, and number of bytes (normal and maneuver) must have
values in them. The values for each mission instrument are specified in the
Data Format
Control Document Between the ISTP Program Information Processing Division Ground
Data Processing System and the ISTP Mission Investigators.
4.1.3 Database Interface System Reports
This section contains the purpose, usage restrictions, user-definable criteria, and column width
for each report in the Database Interface System.
Those reports generated with a start and end date will include this information on the report.
4.1.3.1 Data Files Stored On-Line Report (DFSR)
This report displays the information about data files that are online for a given mission, data type
descriptor, and data span time range. The information includes the mission name, descriptor,
logical filename, physical filename, the record size, and file size in VMS blocks. The report also
calculates the total number of VMS blocks used by the selected files.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Mission name (wild card allowed)
2. Data type (wild card allowed)
3. Descriptor (wild card allowed)
4. Span start date (no wild cards, format DD-MON-YYYY)
5. Span end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 132
4.1.3.2 Data Files Received Report (DFRR)
This report displays the information about data files received for a given mission name, data
type, descriptor and catalog date range. The information includes the data file logical filename,
physical filename, online flag, data span start date, data span end time, catalog date, expiration
date, reference file physical filenames, reference file data span start dates, and reference file data
span end dates.
Usage Restrictions: This report is available to all users.
67
User-Definable Report Criteria:
1. Mission name (wild card allowed)
2. Data type (wild card allowed)
3. Descriptor (wild card allowed)
4. Catalog start date (no wild cards, format DD-MON-YYYY)
5. Catalog end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 132
4.1.3.3 Data File Certification Status Report (DFCR)
This report displays the certification status information for selected KP data files as specified by
a file date range, mission, and instrument. The information includes the mission name,
descriptor, logical filename, file date, version, quality indicator, certification date, user ID of
person who certified, and KP comment.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Mission name (wild card allowed)
2. Data type (always K%)
3. Descriptor (wild card allowed)
4. Span start date (no wild cards, format DD-MON-YYYY)
5. Span end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 132
4.1.3.4 Data File Summary Report (DSUM)
This report displays a summary of the data files that are cataloged for a given mission, data type,
descriptor, and data span time range. The summary includes the mission name, data type,
descriptor, first and last dates for which there are data, and total number of days for which there
are data.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Mission name (wild card allowed by DPS and DBA users)
2. Data type (wild card allowed by DPS and DBA users)
3. Descriptor (wild card allowed by DPS and DBA users)
4. Span start date (no wild cards, format DD-MON-YYYY)
5. Span end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 80
4.1.3.5 Working Data File Report (WFR)
This report displays a summary of the working data files that are cataloged for a given mission,
data type, descriptor, and time range. The summary includes the mission name, data type,
descriptor, logical filename, span start date, span end date, catalog date, and expiration date.
68
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Mission name (wild card allowed)
2. Data type (always W%)
3. Descriptor (wild card allowed)
4. Span start date (no wild cards, format DD-MON-YYYY)
5. Span end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 132
4.1.3.6 Cataloged Data File Report (DFR)
This repor displays information about data files in the CDHF catalog for a given time range. The
information includes the mission name, descriptor, online flag, logical file name, span start time,
span stop time, record size, and data file size.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Mission name (wild card allowed)
2. Data type (wild card allowed
3. Descriptor (wild card allowed)
4. Span start date (no wild cards, format DD-MON-YYYY)
5. Span end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 132
4.1.3.7 Key Parameters Reprocessed Report (KPRR)
This report displays information about KP data files that have been reprocessed for a given date
range, mission, and descriptor. The information includes the mission name, descriptor, logical
identifier, file date, version, quality indicator, certification date, certifier, and the PI comment.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Mission name (wild card allowed)
2. Data type (always K%)
3. Descriptor (wild card allowed)
4. Span start date (no wild cards, format DD-MON-YYYY)
5. Span end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 132
4.1.3.8 Process History Report—By Input File (IFPH)
This report displays the process history information about the input data files and the
corresponding output product files for the date range, mission, data type, and descriptor specified
as the input data file criteria. The information includes the logical identifier of the input data file,
69
the program name and version that was used to process the input data file, the process
completion date, and the process summary.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Mission name (wild card allowed)
2. Data type (wild card allowed)
3. Descriptor (wild card allowed)
4. Span start date (no wild cards, format DD-MON-YYYY)
5. Span end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 132
4.1.3.9 Process History Report—By Output File (OFPH)
This report displays the process history information about the output product files and the
corresponding primary input data file for the date range, mission, and descriptor specified as the
KP data file criteria. The information includes the logical identifier of the output product file, the
program name and version that was used to generate the output product file, the process
completion date, and the process summary.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Mission name (wild card allowed)
2. Data type (always be K%)
3. Descriptor (wild card allowed)
4. Span start date (no wild cards, format DD-MON-YYYY)
5. Span end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 132
4.1.3.10 Process History Report—By Program (KPFR)
This report displays the process history information plus the corresponding input support files
and output product files for key parameter files generated in a given date range with a given
program name. The process information includes process program, version number of the
process program, primary input file, process requested date, process scheduled date, process
completed date, and schedule type. The key parameter files generated and the input support files
are also included for each process history entry.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Program name (wild card allowed by DBA or DPS users)
2. Process completed date range (DD-MON-YYYY)
Report Column Width: 132
70
4.1.3.11 Process Program Information Report (PPR)
This report displays all of the process program information including the primary input data file
types and the input support data file types associated with each program. The information for
each program also includes the program name, program version, program location, program
effective start date, program effective end date, output file type, number of output files, output
file descriptor, secondary input file required flag, number of input calibration files, program
installation date, and the CDF skeleton files associated with each output file.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria: None
Report Column Width: 132
4.1.3.12 Calibration Data Information Report (CDR)
This report displays all of the calibration data file information. The calibration data file
information includes mission name, instrument name, file version, instrument component, logical
filename, physical filename, catalog date, file effective start date, and file effective end date.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria: None
Report Column Width: 132
4.1.3.13 Parameter File Information Report (PFR)
This report displays all of the parameter file information. The parameter file information includes
mission name, instrument name, file version, logical filename, physical filename, catalog date,
file effective start date, and file effective end date.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria: None
Report Column Width: 132
4.1.3.14 Data Quality Information Report (DQR)
This report displays the information about the quality of level-zero data and the top 10 data gaps
on a given date range for a given mission name. The information includes mission name, version,
file date, logical filename of the data quality file, number of major frames, number of data gaps,
number of perfect frames, number of good frames, number of fill frames, and the frame start and
end date of the data gaps.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria:
1. Mission name (wild card allowed)
2. Data type (always ‘LZ’)
3. Descriptor (always ‘QAF’)
71
4. Span start date (no wild cards, format DD-MON-YYYY)
5. Span end date (no wild cards, format DD-MON-YYYY)
Report Column Width: 132
4.1.3.15 ISTP Missions Launched Report (IMR)
This report displays the ISTP active mission information. The ISTP mission information includes
mission name, mission long name, mission description, mission launch date, mission operation
date, project name, support identification code (SIC), and spacecraft identification number. This
information is used to validate and generate SFDU headers.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria: None
Report Column Width: 132
4.1.3.16 Mission Descriptors/Instruments Report (MDR)
This report displays all of the mission descriptor/instrument information. For each mission
descriptor, the report includes the mission name, descriptor, descriptor long name, descriptor
description, descriptor type, discipline, subdiscipline, key parameter generation mail flag, and
user message directory. This information is used to validate and generate SFDU headers and to
schedule key parameter generation jobs for a mission instrument.
Usage Restrictions: This report is available to all users.
User-Definable Report Criteria: None
Report Column Width: 132
4.2 User Data Transfer Services
The User Data Transfer Services allow the user to request the electronic transfer of files from the
CDHF to a specified network node. The CDHF supports both the DECnet and TCP/IP protocols
for the transfer of data files, and supports the staging of data files on the CDHF for remote access
from the RDAF.
4.2.1 Data Transfer Request Types
The Data Transfer Services supports the following three types of transfer requests:
•User File Requests—Allow users to transfer files for which they either own or have read
access privileges. For example, CDHF database reports or other files generated in the
user’s directory can be transferred using this option. Due to proprietary requirements,
cataloged science data files cannot be transferred with this option because they are not
directly accessible to the user community.
•Cataloged File Requests—Allow users to transfer science data files that are already
cataloged in the CDHF database. For each logical identifier selected, all the associated
physical filenames are transferred. If offline files are requested, a DDF retransmit request
is automatically created, which may require a day to process. When offline files are
selected, they will be verified that the data file requested was archived on the DDF
system. If a selected file was never sent to the DDF, that file will be unselected and no
72
request to retransmit will be made from the DDF. Once the offline files are retransmitted
for a request, the request will execute. If online files are requested, the request must either
be executed immediately or before any of the files selected expire. For any level-zero
files selected, a decommutation specification and/or an extraction time range can be
specified as an alternative to transferring an entire level-zero file.
•Standing Requests—Allow users to periodically transfer science data files that have been
newly cataloged since the last execution of a request. Each time a standing request
executes, it generates a new cataloged file request with a file list automatically generated
based on the files newly cataloged for the mission, data type, and descriptor associated
with the request. For example, a request can be created to automatically send newly
generated key parameter files for a mission instrument every 2 days. If the standing
request is for level-zero files, a decommutation specification and/or an extraction time
range can be specified as an alternative to transferring entire level-zero files.
+User file requests and cataloged file requests are automatically deleted either when all the
associated files are successfully transferred or when the maximum number of transfer
attempts is exceeded. Standing requests, however, are active until they are deleted by the
requester.
4.2.2 Data Transfer Process Overview
The processing of a transfer request involves a three-stage process to accept, schedule, and
process a transfer request. All three stages interface with the CDHF database.
4.2.2.1 Data Transfer Services User Interface
The user interface consists of forms and reports to allow users to create, query, and modify
requests. The forms provide database assistance in creating requests and ensure that all the
information is valid, including file access privileges, before the request is saved in the database.
Only remote mail and destination addresses are not validated until the transfer is actually
attempted. The Data Transfer Services user interface is the only means for accessing science data
files. The creation or modification of a transfer request automatically results in the invocation the
Transfer Handler.
4.2.2.2 Transfer Handler
The Transfer Handler is a resident task that creates and submits jobs in the system transfer queue
for all transfer requests based on the execution date/time requested. In addition to being invoked
by the user interface, the Transfer Handler automatically executes several times a day to submit
standing requests and requests that were created with deferred execution date/times. Every time
the Transfer Handler is invoked, it checks all the requests in the database that do not have job
IDs to determine the requests, if any, that are scheduled to be executed in the next few hours, as
defined by the UDS_TIME system parameter. The Transfer Handler then creates and submits
jobs for the requests determined. A job submitted for a request will not actually execute until the
execution time. Therefore, a job for a request may appear in the system queue anywhere from a
few hours before the execution time to a few seconds before it. Requests created with the current
time as the execution time are processed immediately. If the Transfer Handler is unavailable for
a time period, all requests requiring processing will be submitted to the system queue as soon as
the Transfer Handler is available again. If a cataloged file request has offline files associated
with it, the Transfer Handler will not submit a job for the request until all the offline files are
either retransmitted from the DDF or deleted from the request.
73
4.2.2.3 Transfer Files Task
The transfer files task, UXFER_FILES, is executed for a request when the submitted job
executes. It determines the files to be transferred and performs the transfer. For standing
requests, the task generates a cataloged file request after it determines the transfer file list based
on newly cataloged files. The new cataloged file request is then processed immediately, and the
dates for the standing request are updated to set up the next periodic execution. For the user file
and cataloged file requests, the task determines the transfer file list from the requester’s
selections in the database. This task also performs the decommutations and time extractions if
they are declared for any level-zero files associated with the request. After the transfers are
performed or attempted, the request is updated in the database, as appropriate, and a status
message is electronically mailed to the requester. Section 4.2.7.1 contains an explanation for all
the status messages. If a user file request or cataloged file request is successful, the request is
deleted. If the request is requeued because of a failure, the execution date is updated and the
Transfer Handler is invoked.
4.2.3 Science Data Files Access Privileges
The CDHF is required to restrict access to proprietary science data files. For cataloged file
requests, any file for which the proprietary date has not expired cannot be selected unless the
requester has explicit access privileges. Science data files that do not have a proprietary
expiration date do not require explicit access privileges. The proprietary expiration date for a file,
if any, can be viewed using the Data File Information Form. Access privileges are controlled by
the CDHF DBA. A user can view the access privileges for his/her account using the ISTP Users
and Privileges Form. For standing requests, explicit access privileges are required for all data file
types selected because the proprietary expiration date is not available for files that have not been
received yet by the CDHF.
4.2.4 Mail Addresses
The CDHF will electronically mail status files for file transfer requests to a mail destination or
distribution list. VAX mail over DECnet and Simple Mail Transfer Protocol (SMTP) mail over
TCP/IP are supported. Each user has a default E-mail address specified in the user’s profile
information in the database. This default address is specified by the user but set by the CDHF
operations personnel. Any change to the default mail address must be made via a request to the
operations personnel. The default address can be overridden by the user on a per-transfer-request
basis.
+The CDHF software will attempt to send mail to the specified mail address. If mail
cannot be sent to the specified address, the mail will be sent to the user’s local CDHF
mailbox. For this reason, do not forward mail from the CDHF by using the SET
FORWARD command of the VMS mail utility. If the primary E-mail address is
unreachable and mail is forwarded from the CDHF and the forwarded address is
unreachable, then no mail can be sent and you will not receive notification of the status of
the attempted transfer.
The format of the mail destination for VAX mail follows the standard VMS conventions (i.e.,
nodename::username). A single user can be specified or a list of users can be specified, as shown
in the following examples:
LEPVAX::SMITH (send mail to a single user)
74
LEPVAX::SMITH,NSSDCA::JONES (send mail to a list of users)
To send mail using SMTP over TCP/IP, the addresses must be included in a distribution list file.
The mail utility will not correctly process mail addresses using SMTP if they are entered directly
in the mail address field. The format of the address is SMTP%“user@hostname”. To specify that
mail should be sent to user Whitman at host groucho.gsfc.nasa.gov, the following address would
be entered into the distribution list file:
SMTP%“whitman@groucho.gsfc.nasa.gov”
The name of the distribution list file is then entered in the mail address field. If the distribution
list file is called MYLIST.DIS and is located on disk and directory
ISTP_USER:[DARN.BAKER], then the following is entered in the mail address field:
“@ISTP_USER:[DARN.BAKER]MYDIST.DIS”
Note that the full device and directory path must be specified for the distribution list file and that
the double quotes (“ ”) are part of the specification and must be included.
When using a distribution list file, both VAX mail addresses and SMTP addresses can be mixed.
The following example shows the contents of a distribution list file with mixed addresses:
LEPVAX::SMITH
NSSDCA::JONES
SMTP%“whitman@groucho.gsfc.nasa.gov”
4.2.5 Destination Addresses
The Data Transfer Services of the CDHF provide the user with the capability to request the
transfer of data files from the CDHF to a specified destination. The CDHF will transfer files to
an RDAF (or other remote computer system), or will stage the data files at the CDHF where the
user can then copy the files to the desired location. Transfers to remote systems are supported
using DECnet COPY and TCP/IP ftp. The protocol used in transferring the data files is
determined from the destination address format.
4.2.5.1 Staged Transfers
Staged transfers are file transfers to a user-controlled area on the CDHF. Staged transfers are
requested by specifying the destination of the transfer as ISTP::disk:[directory]. Users may
specify any directory for which they have write access to as the destination for staged files. Users
will be allocated a directory and disk space on a staging disk on request. This disk and directory
can then be used as the user’s staging area. Staged files will be owned by the user that made the
transfer request. The management of the user’s staging area is the responsibility of the user.
Users should delete files from the staging area once they have been transferred to their final
destination. Failure to delete files from the staging area could result in the user’s disk allocation
being exceeded during subsequent transfers.
The staging disk on the CDHF is called XSTAGE. A user that has been given a directory on the
staging disk called [GEOTAIL.PWI] would specify ISTP::XSTAGE:[GEOTAIL.PWI] as the
destination for a transfer request. When the request is processed, the requested data files are
moved to XSTAGE:[GEOTAIL.PWI] and the user is notified via E-mail in the usual manner.
The user may then copy the files remotely using DECnet COPY or ftp, or log into the CDHF and
access the files directly.
75
Files older than 3 days will be deleted from the staging disk.
4.2.5.2 RDAF Transfers
Transfers to RDAFs or other remote computer systems from the CDHF are accomplished by a
process that “pushes” the data files from the CDHF to the specified remote node and location.
The CDHF can “push” data to a remote system in the following three ways:
•A remote system supporting DECnet PROXY can set up a proxy account for the transfer
of data files. The account on the CDHF that handles the “pushing” of data files is called
DPS_OPBATCH. The establishment of a proxy for ISTP::DPS_OPBATCH will allow
the transfer of files from the CDHF to a specified account on the remote system. The
transferred files are owned by the proxy account. The user may specify the destination in
any of the following forms:
node:: Files are copied to the root directory of the proxy account.
node::disk:[directory] Files are copied to the specified disk and directory if the
proxy account has write access to disk:[directory].
•A remote system supporting DECnet can set up the default DECnet account to accept
incoming file copies. The user specifies the destination as follows:
node:: Files appear in the root directory of the default DECnet
account and are owned by the default DECnet account.
•A remote system can set up an anonymous ftp account with no password that allows
incoming file copies. The user specifies the destination as a valid TCP/IP node address,
as shown in the following example:
buster.gsfc.nasa.gov Files are copied to the root directory of the
anonymous account.
buster.gsfc.nasa.gov/incoming Files are copied to the specified directory relative
to the anonymous account. The destination directory
specification is separated from the node address by a
“/”. To test whether the destination has been correctly
specified, perform an ftp to the node, log in as
anonymous, and do a cd to each string separated by a /.
For example, to test whether buster.gsfc.nasa.gov/
incoming/istp is a correct specification
ftp buster.gsfc.nasa.gov
log in anonymous
cd incoming
cd istp
Users prevented from using any of these three options due to system management policies at
their sites should select staged transfers.
+Do not include your username and password in the destination string for DECnet
transfers. This information is stored in clear text form in the database. It will also appear
in the status message sent out when files are transferred. For security reasons, the
handling of remote systems’ usernames and passwords on the CDHF is not supported.
76
4.2.6 Data Transfer Services User Interface
The menu for the Data Transfer Services allows users to access various forms and reports to
create, modify, and query transfer requests. The menu can be accessed from the CDHF User
Interface Main Menu or by entering the Transportable Applications Environment (TAE)
command, FILEXFER. The individual forms cannot be directly accessed without accessing the
User Data Transfer Services Menu, which performs required initializations. Like the Database
Interface System (CDHF Queries and Reports), the Data Transfer Services menu, forms, and
reports were developed using the ORACLE SQL*Forms and report tools. Section 3 outlines the
terminal support requirements and the usage of the ORACLE tools. Under the User Data
Transfer Services Menu (Figure 4–3), there are eight menu items.
Figure 4–3. User Data Transfer Services Menu
•Create Transfer Request for User Files—Allows users to create new transfer requests for
files either owned by or accessible by the user.
•Create Transfer Request for User Files—Allows users to create new transfer requests for
files either owned by or accessible by the user.
•Create Transfer Request for Cataloged Science Files—Allows users to create new
transfer requests for files that are already cataloged in the CDHF database.
•Create Standing Request for New Science Files—Allows users to create standing transfer
requests for new science files as they are cataloged on the CDHF.
•Query/Modify Transfer Requests for User Files—Allows users to query and modify
existing transfer requests for files either owned by or accessible by the user.
• Query/Modify Transfer Requests for Cataloged Science Files—Allows users to query and
modify existing transfer requests for files that are already cataloged in the CDHF
database.
•Query/Modify Standing Requests for New Science Files—Allows users to query and
modify existing standing transfer requests.
77
•Data Transfer Requests Report—Displays all the current requests for a user including
user file requests, cataloged science file requests, and standing requests.
•Daily Transfer History Report—Displays a summary of all the requests successfully
completed for a user in the last 24 hours.
4.2.6.1 Create Transfer Request for User Files
This form allows users to create new transfer requests for files either owned by or accessible by
the user. For example, reports generated from the Database Interface System can be transferred
using this option. For each request, one or more physical filenames can be specified for transfer.
Cataloged science data files, however, cannot be transferred using this form because the files are
not directly accessible. This form allows users only to create new requests. No queries, updates,
or deletions are allowed.
Format:
78
Usage Restrictions:
• Read-only users may not access this form.
• Queries, updates, and deletions cannot be performed by any user.
•For any physical filename entered, the user must have read privilege for the file.
Cataloged science data files cannot be specified unless they have already been copied to a
staging area by another request. Use the Create Transfer Requests for Cataloged Science
Files Form for this purpose.
•The Commit function is not allowed in the first block. Users must first proceed to the
next block and complete the request by entering one or more physical file names.
•Each request must be saved using the Commit function before another request can be
created.
Detailed Usage Guidelines:
•The Request ID, Request By, and Request Date are automatically generated for new
requests. These fields cannot be accessed or updated. The Request ID is supplied by a
number generator shared by all users. Two requests created back to back may not have
sequential numbers, but the newer request will always have the higher number.
•Default values are provided for the Execution Date, Mail Address, and Transfer
Destination as you cursor to the respective fields. This information may be changed by
the user as required for each request. The default mail address and transfer destination for
your account may be changed by contacting the DPS.
•The Execution Date is the date and time the request should execute. It cannot be earlier
than the current date. Mail Address is the requester’s mail address for electronic transfer
status messages. Multiple addresses can be specified if they are separated by a comma.
Section 4.2.4 contains additional information on setting up mail addresses. Destination
Address is the destination node and/or directory for transferred files.
•For staged requests, you must enter into the Destination Address “ISTP::” followed by a
complete disk/directory path to which you have write access. To transfer a file to an
79
RDAF, you must, as a minimum, specify the DECnet or TCP/IP node ID for the RDAF.
Section 4.2.5 contains more information on file transfers to an RDAF.
•To enter the physical filenames associated with the request, invoke the Next Block
function. Your default home directory (as defined by the value of the SYS$LOGIN VMS
logical) is displayed upon entry into the field as the default disk/directory. You can easily
append the subdirectory and filename by invoking the End of Line function to move the
cursor to the end of the default directory. You can change the disk/directory specification
as necessary.
• The physical filenames must include the disk/directory, file name, and file extension.
• You must have read privilege on each file you have requested for transfer.
• The request will not be created if no physical filenames are entered by the user.
•Once all the information has been entered for a request, you can save it by invoking the
Commit function. The Transfer Handler will then be invoked to process the request
unless a message indicates that the request may be delayed due to the unavailability of
the Transfer Handler. Once the request is successfully saved, you can proceed to create
another request or to exit the form.
4.2.6.2 Create Transfer Request for Cataloged Files
This form allows users to create requests for file transfers. Only science data files that are
already cataloged in the CDHF database may be requested for transfer using this form. The user
may specify level-zero extraction timespans and/or level-zero decommutation specification
filenames when requesting level-zero files. This form is only used for creating requests; editing
and deleting are not permitted. To complete the file selection process, the user may query science
data files for which he or she may or may not have access privileges. However, the user may
only select files for which he/she has access privileges unless the proprietary date has expired or
the data file type is not proprietary.
Format:
80
Usage Restrictions:
• Users with read-only privilege may not access this form.
•Queries may only be performed from the second block to generate a list of available file
selections.
•Creating a single request from multiple queries is not allowed. The user may create one
request per query. Each request must be saved (Commit function) before another request
can be created.
•Inserts of files in addition to the ones queried are prohibited. The user may only select
files using special function keys SF1 and SF2 to create transfer requests.
81
•If the data file type queried is proprietary and the proprietary date has not expired for the
file, the user must have access privileges for the mission, data type, and descriptor
combination to select the file. Access privileges may be viewed using the ISTP Users and
Privileges Form.
•Users are not permitted to update or delete existing transfer requests using this form.
Modifications and deletions are done from the Modify Transfer Request for Cataloged
Files Form.
•The Commit function can only be invoked from the Select LZ Catalog Science Files and
Select Catalog Science Files screens if at least one file has been selected.
•Each request must be saved using the Commit function before another request can be
created.
Detailed Usage Guidelines:
•The Request ID, Request By, and Request Date are automatically generated for new
requests. These fields cannot be accessed or updated. The Request ID is supplied by a
number generator shared by all users. Two requests created back to back may not have
sequential numbers, but the newer request will always have the higher number.
•Default values are provided for the Execution Date, Mail Address, and Transfer
Destination as you cursor to the respective fields. This information may be changed by
the user as required for each request. The default Mail Address and Transfer Destination
for a user account may be changed by contacting the DPS.
•The Execution Date is the date and time the request should execute. It cannot be earlier
than the current date. Mail Address is the requester’s mail address for transfer status
messages. Multiple addresses can be specified if they are separated by a comma. Section
4.2.4 contains additional information on setting up mail addresses. Destination Address is
the destination node and/or directory for transferred files.
•For staged requests, you must enter into the Destination Address “ISTP::” followed by a
complete disk/directory path to which you have write access. To transfer a file to an
RDAF, you must, as a minimum, specify the DECnet or TCP/IP node ID for the RDAF.
Section 4.2.5 contains more information on file transfers to an RDAF.
•To proceed to the second page to enter the file selection list query criteria, invoke the
Next Block function.
•For the Query Cataloged Science Files screen (query criteria block), the Mission Name,
Data Type, Descriptor, Start Date, and End Date must be specified. If you have a default
mission, data type, and descriptor, it will automatically be displayed to reduce data entry.
The Query Start Date and End Date will be provided as defaults as well. Query Start Date
will be the current date less 30 days, and the Query End Date will be the current date. All
defaults provided may be changed to alter the query.
•Wild cards (%) are allowed for mission name, data type, and descriptor in the query
criteria block to reduce the number of requests that need to be created. The wild cards
allowed are “K%” (all KP files) for data type and “%” for mission name and descriptor
(all instruments/descriptors).
•The special function key SF3 allows users to add or edit level-zero extraction timespans.
Invoke SF3 to enter the pop-up. Invoke the Exit function to return to the previous screen.
This pop-up can only be invoked if the user is requesting level-zero (LZ) files. If LZ
extraction time is entered from the Query Cataloged Science Files screen, it is used as a
default for every LZ file returned by the query. LZ extraction timespans may be added or
updated for individual file selections from the Select LZ Cataloged Science Files screen.
82
If LZ timespans are specified, an asterisk appears under the LZ Extraction column for
each applicable file. The extraction times are relative to the file date of the LZ file being
processed.
•The special function key SF4 allows users to add or edit LZ decommutation specification
names. Invoke SF4 to enter the pop-up. Invoke the Exit function to return to the previous
screen. This pop-up can only be invoked if the user is requesting LZ files. If an LZ
decommutation specification name is entered from the Query Cataloged Science Files
screen, it is used as a default for every LZ file returned by the query. LZ decommutation
specification names may be added or updated for individual file selections from the
Select LZ Cataloged Science Files screen. If an LZ decommutation specification name is
specified, an asterisk appears under the LZ Decom column for each applicable file. The
List of Values function within the pop-up displays the decommutation specifications for
which the user has access privileges.
•After the query criteria are entered, you may view the qualifying data files available for
transfer by invoking the Next Block function.
•When a query is performed, your daily remaining transfer quota is displayed on the
Cataloged Science Files screen. The remaining quota informs the user of the amount of
available 24-hour transfer quota in VMS blocks. The daily transfer quota is informational
only. It does not prevent you from transferring files when the daily transfer quota is
exhausted.
•For queries with multiple versions of a logical identifier, only the most recent version
will be displayed by default. To view all versions of a logical identifier, change the Query
All Versions attribute in the ISTP User Information and Privileges form to “Y”.
•If an LZ data type is specified, the Select LZ Cataloged Science Files screen will appear
when the query is executed. If a non-LZ data type is specified, the Select Cataloged
Science Files screen will appear when the query is executed. However, if no files match
the query criteria, the cursor will remain in the query criteria block to allow modifications
to the criteria.
•A File Expired/Offline column exists on the Select LZ Catalog Science Files and Select
Catalog Science Files screens. An “O” indicates the file is offline and an “E” indicates
that the file is currently online, but it will expire before the request is executed. A file is
considered to be expired if it will expire within 6 hours of the execution date. A blank
indicates that the file is online and that it will not expire before the execution date.
•The special function key SF1 allows users to select or unselect the current file. Press SF1
to select or unselect the file. If the file is selected, an asterisk (*) appears under the File
Selected column and the file is selected for transfer. If the file is unselected, the asterisk
is removed and the current file is no longer selected for transfer.
•The special function key SF2 allows the user to select all files for transfer that were
returned by the query. Press SF2 to select all files. An asterisk will appear under the File
Selected column for all files returned by the query. Use the special function key SF1 to
unselect undesired files. If more files are returned by the query than can be displayed at
one time, invoke the Scroll Down function to view the other files.
•Once all the desired files have been selected, you can save the request by invoking the
Commit function. The Transfer Handler will then be invoked to process the request
unless a message indicates that the request may be delayed due to the unavailability of
the Transfer Handler.
•If an expired file is selected and the execution date has been changed from the default
value (current date/time), a small pop-up will appear, when the Commit function is
83
invoked, in the bottom right corner of the screen displaying the current date/time as the
revised execution date. You have the option to change the displayed execution date, if
desired. However, the form will not permit you to enter an execution date greater than 6
hours before the earliest expiration date for the selected file(s). In other words, to select
expired files, the request must be executed either immediately or before any of the files
selected expires (i.e., a file selected has already expired and subject to deletion, or the file
will expire before the request executes). You must invoke the EXIT function to exit from
the pop-up and continue the commit process.
•If you request an offline file, the form will verify whether the data file requested was
archived on the DDF system. Selected files that were never sent to the DDF will be
unselected, and a message will indictae that the file was never sent to the DDF. The
request form retransmit file list will be deleted.
If you request an offline file that is available from the DDF, the form will automatically
generate a DDF retransmit request and send a mail message to the DPS when the request
is committed. You will be warned that you have requested offline files. The request will
not execute until the file(s) are retransmitted from the DDF, even if some of the files
requested are already online. Retransmit requests for files that have been expired for less
than 30 days are automatically approved.
•After successfully creating a request, a message will appear informing you that the
request has been successfully created. In addition, this message displays the request ID
that was created and the approximate number of blocks that were requested for transfer.
The number of blocks requested is based on the file size of the files selected for transfer.
The number of blocks requested does not reflect LZ extractions and LZ decommutations.
You can then proceed to create another cataloged file request or can exit the form.
4.2.6.3 Create Standing Requests for New Science Files
This form allows users to create standing transfer requests. Standing requests provide users with
a method of receiving specific types of newly cataloged files on a routine basis. For example, a
user can request that key parameter files for a certain mission and instrument be transferred
every 2 days. Then, a cataloged file request will automatically be generated and executed every 2
days based on the key parameter files newly cataloged in that time period for the mission
instrument. This form is only for creating standing requests, not querying or modifying requests.
The user must have access privileges for the mission, data type, and descriptor combination
selected.
84
Format:
Usage Restrictions:
• Read-only users may not access this form.
•A user can only create a standing request for a mission, data type, descriptor combination
for which he/she has access privileges. Access privileges may be viewed using the ISTP
Users and Privileges Form.
• No queries, updates, or deletions are allowed in this form.
85
•A standing request cannot be created for files already cataloged. Use the Create Transfer
Requests for Cataloged Science Files Form for this purpose.
•Each request must be saved using the Commit function before another request can be
created.
•The Commit function cannot be invoked from the first block of the form. It must be
invoked from the second block after all the request information is entered.
Detailed Usage Guidelines:
•The Request ID, Request By, and Request Date are automatically generated for new
requests. These fields cannot be accessed or updated. The Request ID is supplied by a
number generator shared by all users. Two requests created back to back may not have
sequential numbers, but the newer request will always have the higher number.
•The default Execution Date displayed for new requests is 1 day greater than the current
system time. The default value may be changed, but it must be greater than the effective
catalog start date/time on the second page. The first execution of the standing request will
transfer all files for the data file type that are newly cataloged between these two dates.
Each time the transfer task processes the request, it updates the execution date based on
the time interval specified for the standing request.
•Upon entry into the Mail Address and Destination Address fields, the default values
assigned to the user account will be displayed. The values may be changed as required for
each request. The default values for your account may be changed by contacting the DPS.
The Mail Address determines where the transfer status message is electronically mailed
after the request is processed. Section 4.2.4 contains more information on setting up mail
addresses. The Destination Address determines where the files selected are transferred.
•For staged requests, you must enter into the Destination Address “ISTP::”, followed by a
complete disk/directory path to which you have write access. To transfer a file to an
RDAF, you must, as a minimum, specify the DECnet or TCP/IP node ID for the RDAF.
Section 4.2.5 contains more information on file transfers to an RDAF.
• To proceed to the second page to complete a request, invoke the Next Block function.
•To view the list of Mission Names, Data Types, and Descriptors for which you have
access privileges, invoke the List of Values function from the corresponding fields.
•If an instrument has multiple key parameter files, “K%” can be entered for the Data Type
to receive them all. Likewise, a “%” can be entered for the Descriptor to receive all of the
descriptors that apply to the mission and data type. No other wild cards are allowed.
•You cannot have two active standing transfer requests for the same mission, data type,
and descriptor combination. For example, you cannot enter one request with the data file
type, GE LZ %, and another request with the data file type, GE LZ EPI, because the
second data file type is redundant with the first data file type, which selects all
instruments.
•The Effective Catalog Start Date/Time entered for the request must be greater or equal to
the current date. It represents the earliest catalog date evaluated to determine which files
have been newly cataloged. Each time the transfer task processes the request, it updates
the Effective Catalog Start Date to be the system date/time just after the file list is
determined for the previous execution of the request. It tends to be slightly greater than
the Execution Date for the previous execution of the request.
•The time interval determines how often the standing request is executed after the initial
request execution. An interval between 0.04 and 7 days may be selected. If the
86
specification consists of 3 digits to the right of the decimal, it will be rounded to 2 digits
to the right of the decimal. The rounded number will not appear until the request is
viewed in the Query/Modify Standing Requests for New Science Files form.
•For LZ file requests, you may select a decommutation specification and/or an extraction
time range to be applied to all LZ files transferred by the standing request using the
special function keys SF1 and SF2, respectively. Use the List of Values function for the
Logical Decommutation Specification Name field to display the ones for which you have
access privileges. The extraction times are relative to the file date of the LZ file being
processed.
• Once all the information has been entered for a request, you can save it by invoking the
Commit function. The Transfer Handler will then be invoked to process the request
unless a message indicates that the request may be delayed due to the unavailability of
the Transfer Handler. Once the request is successfully saved, you can then proceed to
create another standing request or you can exit the form.
4.2.6.4 Query/Modify Transfer Requests for User Files
This form allows users to query and modify transfer requests for user files. This form can only be
used to modify existing requests. To create requests, the user must use the Create Transfer
Requests for User Files Form. Regular users may only view their own requests and make minor
updates to the requests such as changing the execution time or transfer destination for a request.
Alternatively, regular users may delete any of their own requests or a particular file for a request.
The DPS may view requests for all users, but can only delete jobs from the VMS system queue
as required for recovery purposes.
Format:
87
Usage Restrictions:
• Read-only users may not access this form.
•Inserts are prohibited in this form. Use the Create Transfer Requests for User Files to
request new files.
•A request cannot be updated or deleted if a job ID is assigned to the request. The job
must be deleted first using the special function key SF1. The job will not be deleted from
the VMS system queue if the request is already executing.
•A request must have at least one file associated with it. Therefore, the last and only file
associated with a request cannot be deleted unless the entire request is deleted.
•Regular users may only view and modify their own requests. The Execution Date, Mail
Address, and Destination Address are the only fields that may be updated. Regular users
may also delete any of their own requests or individual files associated with a request.
•In addition to viewing all requests, the DPS is only allowed to delete jobs associated with
requests from the VMS system queues.
•DBA users may view all requests, and they may update the Number of Transfer Attempts
in addition to the fields that are updateable by regular users. The DBA may also delete
requests as required.
Detailed Usage Guidelines:
•For DBA and DPS users, the form is in Enter Query mode upon entry. A query criteria, if
any, can be entered followed by the Execute Query function to view transfer requests.
•For regular users, a query is automatically performed upon entering the form. The query
will only return the users own requests. If no transfer requests exist, the user is informed
that he or she has no requests, and the form will exit.
•When a query is performed, the most recent request is displayed first. Use the Down
function to view any older requests.
•When the form is in Enter Query mode, fields such as Request ID, Transfer Job ID, and
Request By are enterable to allow queries for specific requests or users.
88
•If the request currently displayed has a job ID, the values in the enterable fields cannot be
changed. To modify the request before it executes, invoke the special function key SF1 to
delete the job. If the job is in a holding/pending state, the Job ID field will be cleared and
the job will be deleted from the system queue. If the job is not found in the system queue,
the Job ID field will be cleared. If the job is in an executing state, a message will be
displayed and the job will not be deleted from the system queue.
•You cannot invoke the special function key SF1 if there are any uncommitted changes.
You must either commit their changes or perform the query again to clear their changes
in order to attempt SF1 again.
•The Execution Date is the date and time the request should be executed. Mail Address is
the requester’s mail address for transfer status messages. Multiple addresses can be
specified if separated by a comma. Destination Address is the destination node and/or
directory for transferred files.
• The transfer execution date cannot be earlier than the current system date.
•For staged requests, enter into the Destination Address “ISTP::”, followed by a complete
disk/directory path to which you have write access. To transfer a file to an RDAF, as a
minimum, specify the DECnet or TCP/IP node ID for the RDAF. Section 4.2.5 contains
more information on file transfers to an RDAF.
•You may delete an entire request by invoking the Delete Record function from the first
screen of the form.
•To view all the user files associated with a request, invoke the Next Block function. You
can delete a file from a request by placing the cursor on it and invoking the Delete
Record function, but cannot add new files to a request.
• To save any updates or deletions made to a request, invoke the Commit function.
•If you modify any requests while you are in the form, the Transfer Handler will be
invoked when you exit the form to submit requests as necessary.
•If the transfer task processes your requests after you perform the query, you may be
warned, when attempting to modify the request, that another user has modified it. You
should commit any changes already completed and perform the query again to view the
current status for your request.
4.2.6.5 Query/Modify Transfer Requests for Cataloged Files
This form allows users to query and modify transfer requests for cataloged files. This form can
only be used to modify existing requests. To create requests, the user must use the Create
Transfer Requests for Cataloged Files Form. Regular users may only view their own requests
and make minor updates to the requests such as changing the execution time or transfer
destination for a request. Alternatively, regular users may delete any of their own requests or a
particular file for a request. The DPS may view requests for all users, but they can only delete
jobs from the VMS system queue as required for recovery purposes.
89
Format:
Usage Restrictions:
• Read-only users may not access this form.
•Inserts are prohibited in this form. Use the Create Transfer Requests for Cataloged Files
to request new files.
•A request cannot be updated or deleted if a job ID is assigned to the request. The job
must be deleted first using the special function key SF1. The job will not be deleted from
the VMS system queue if the request is already executing.
•A request must have at least one file associated with it. Therefore, the last and only file
associated with a request cannot be deleted unless the entire request is deleted.
90
•Regular users may only view and modify their own requests. The Execution Date, Mail
Address, Destination Address, Level Zero Decommutation Specification, and Level Zero
Extraction Start/Stop Times are the only fields that may be updated. Regular users may
also delete any of their own requests or individual files associated with a request.
•In addition to viewing all requests, the DPS is only allowed to delete jobs associated with
requests from the VMS system queues.
•DBA users may view all requests, and they may update the Online status and Number of
Transfer Attempts, in addition to the fields that are updateable by regular users. The DBA
may also delete requests as required.
Detailed Usage Guidelines:
•For DBA and DPS users, the form is in Enter Query mode upon entry. A query criteria, if
any, can be entered followed by the Execute Query function to view transfer requests.
•For regular users, a query is automatically performed upon entering the form. The query
will only return the user’s own requests. If no transfer requests exist, you are informed
that you have no requests, and the form will exit.
•When a query is performed, the most recent request is displayed first. To view any older
requests, use the Down function.
•When the form is in Enter Query mode, fields such as Request ID, Transfer Job ID, and
Request By are enterable to allow queries for specific requests or users.
•If the request currently displayed has a job ID, the values in the enterable fields cannot be
changed. To modify the request before it executes, invoke the special function SF1 to
delete the job. If the job is in a holding/pending state, the Job ID field will be cleared and
the job will be deleted from the system queue. If the job is not found in the system queue,
the Job ID field will be cleared. If the job is in an executing state, a message will be
displayed and the job will not be deleted from the system queue.
•Users cannot invoke the special function key SF1 if there are any uncommitted changes.
Users must either commit their changes or perform the query again to clear their changes
in order to attempt SF1 again.
•On the Modify Transfer Request for Cataloged Files screen, you may only update the
Execution Date, the Mail Address, and the Transfer Destination.
•The Execution Date is the date and time the request should be executed. Mail Address is
the requester’s mail address for transfer status messages. Multiple addresses can be
specified if separated by a comma. Destination Address is the destination node and/or
directory for transferred files.
• The transfer execution date cannot be earlier than the current system date.
•For staged requests, enter into the Destination Address “ISTP::”, followed by a complete
disk/directory path to which you have write access. To transfer a file to an RDAF, you
must, as a minimum, specify the DECnet or TCP/IP node ID for the RDAF. Section 4.2.5
contains more information on file transfers to an RDAF.
•An entire request may be deleted by invoking the Delete Record function from the
Modify Transfer Request for Catalog Files screen.
•To view all the files associated with a request, invoke the Next Block function. You can
delete a logical identifier from a request by placing the cursor on it and invoking the
Delete Record function, but you cannot add new files to a request.
•The special function key SF2 allows you to add or edit LZ decommutation specification
names for each logical identifier associated with the request. To display the pop-up,
91
invoke SF2. To return to the previous screen, invoke the Exit function. This pop-up can
only be invoked if you are modifying level-zero files. The List of Values function
displays the decommutation specifications for which you have access privileges.
•The special function key SF3 allows you to add or edit LZ extraction timespans for each
logical identifier associated with the request. To display the pop-up, invoke SF3. To
return to the previous screen, invoke the Exit function. This pop-up can only be invoked
if you are modifying level-zero files.
• To save any updates or deletions made to a request, invoke the Commit function.
•If you modify any requests while you are in the form, the Transfer Handler will be
invoked when you exit the form to submit requests as necessary.
•If the transfer task processes your request after you performs the query, you may be
warned, when attempting to modify the request, that another user has modified it. You
should commit any changes already completed and perform the query again to view the
current status for your request.
4.2.6.6 Query/Modify Standing Requests for New Science Files Overview
This form allows regular and operational users to query and modify existing standing transfer
requests. To create new requests, the Create Standing Requests for New Science Files Form must
be used. Regular users may view all of their own requests and make minor updates to the
requests, such as accelerating or deferring the execution of a request or changing the time
interval between request executions. Alternatively, regular users may use the form to delete any
of their own requests that are no longer required. DPS users may query all requests and delete
jobs associated with the requests as required for recovery purposes.
Format:
92
Usage Restrictions:
• Read-only users may not access this form.
• New requests cannot be created using this form.
•A request cannot be updated or deleted if a job ID is assigned to the request. The job
must be deleted first using the special function key SF1. The job will not be deleted from
the VMS system queue if the request is already executing.
•Regular users may only view and modify their own requests. The Execution Date, Mail
Address, Destination Address, Level Zero Decommutation Specification, Level Zero
Extraction Start/Stop Times, and Time Interval are the only fields that may be updated. A
new request must be created to receive a different type of data file. Regular users may
also delete any of their own requests that are no longer required.
•DPS users may view all requests, but they may only delete jobs associated with requests
from the VMS system queue.
•DBA users may view all requests, and they may update the Effective Catalog Date and
Number of Transfer Attempts in addition to the fields that are updateable by regular
users. The DBA may also delete requests as required.
Detailed Usage Guidelines:
•For DBA and DPS users, the form is in Enter Query mode upon entry. A query criteria, if
any, can be entered followed by the Execute Query function to view transfer requests.
•For regular users, a query is automatically performed upon entering the form. The query
will only return the user’s own requests. If no transfer requests exist, you are informed
that you have no requests, and the form will exit.
•When a query is performed, the most recent request is displayed first. To view any older
requests, use the Down function.
•When the form is in Enter Query mode, fields such as Request ID, Transfer Job ID, and
Request By are enterable to allow queries for specific requests or users.
•If the request currently displayed has a job ID, the values in the enterable fields cannot be
changed. To modify the request before it executes, invoke the special function SF1 to
93
delete the job. If the job is in a holding/pending state, the Job ID field will be cleared and
the job will be deleted from the system queue. If the job is not found in the system queue,
the Job ID field will be cleared. If the job is in an executing state, a message will be
displayed and the job will not be deleted from the system queue.
•You cannot invoke the special function key SF1 if there are any uncommitted changes.
You must either commit your changes or perform the query again to clear your changes
in order to attempt SF1 again.
•The Execution Date is the date and time the request should be executed. Mail Address is
the requesters mail address for transfer status messages. Multiple addresses can be
specified if separated by a comma. Destination Address is the destination node and/or
directory for transferred files.
• The Execution Date/Time must be greater than the Effective Catalog Start Date/Time on
the second page and greater than or equal to the current date. The next execution of the
standing request will transfer all files for the data file type that are newly cataloged
between these two dates. Each time the transfer task successfully processes the request, it
updates the execution date based on the time interval specified for the standing request.
•For staged requests, enter into the Destination Address “ISTP::”, followed by a complete
disk/directory path to which you have write access. To transfer a file to an RDAF, as a
minimum, specify the DECnet or TCP/IP node ID for the RDAF. Section 4.2.5 contains
more information on file transfers to an RDAF.
• An entire request may be deleted by invoking the Delete Record function.
•To proceed to the second page to view the rest of the request information, invoke the
Next Block function.
•The Time Interval determines how often the standing request is executed after the initial
request execution. You may select an interval between 1 and 7 days.
• For level-zero file requests, you may change or add a decommutation specification and/or
extraction time range to be applied to all level-zero files transferred by the standing
request using the special function keys SF2 and SF3, respectively. Use the List of Values
function for the logical decommutation specification name field to display the ones for
which you have access privileges. The extraction times are relative to the file date of the
level-zero file being processed.
• To save any updates or deletions made to a request, invoke the Commit function.
•If you modify any requests while in the form, the Transfer Handler will be invoked when
you exit the form to submit requests as necessary.
•If the transfer task processes your requests after you perform the query, you may be
warned, when attempting to modify the request, that another user has modified it. You
should commit any changes already completed and perform the query again to view the
current status for your request.
4.2.6.7 Data Transfer Requests Report
This report displays the UDS request information including user file requests, cataloged science
file requests, and standing requests for newly received science files. The information includes the
request ID, requester, mail and destination addresses, request type, requested date, execution
date, number of attempts, job ID, file list or type, extraction times, and associated
decommutation files. Regular users may only view their own requests, while operational users
may view all requests.
Usage Restrictions: This report is available to all users.
94
User-Definable Report Criteria: Requester VAX user ID (wild card allowed for DBA or DPS
users)
Report Column Width: 132
4.2.6.8 Daily Transfer History Report
This report displays a summary of the User Data Transfer Service requests successfully
completed for each user in the last 24 hours. The information is primarily used to enforce user
transfer quotas on a daily basis. The report includes the transfer requester, request ID, number of
VMS blocks transferred per request, request completion date/time, and sum of all VMS blocks
transferred per user.
Usage Restrictions: This report is available to all the users.
User-Definable Report Criteria: Requester VAX user ID (wild card allowed for DBA or DPS
users)
Report Column Width: 80
4.2.7 Data Transfer Services Error Handling and Recovery
The Data Transfer Services software will trap all errors associated with the processing of a
transfer request and the transfer of the data files. The user is provided with a status file that is
electronically mailed to the specified mail address at the completion of the transfer attempt.
Section 4.2.7.1 below lists all the messages along with an explanation.
Transfer attempts can be unsuccessful for several reasons. The most common problem is the
unavailability of the destination node, either due to network problems or to the remote node
being down. Another possibility is that the log-in information (proxy or anonymous ftp) is not
valid at the remote node or there is insufficient disk space at the remote node to receive the data
files. In any of these cases, the result is a failed transfer attempt. In these cases, the transfer
request is simply requeued to try again later. A single transfer request will be retried up to
MAX_XFER_TIMES. This system parameter can be tuned by the operations personnel. A
typical value is five attempts. The interval between retry attempts is controlled by the system
parameter DELTA_XFER_TIME minutes.
+If a transfer request is partially successful (i.e., some files transferred and some not), then
it is possible that an SFDU file will be successfully transferred and the associated data
file(s) not transferred. It may also result in a temporary condition where a partial file
group exists on the destination computer. In cases where a partial transfer of a file group
occurs, the entire file group is retried at a later time. On systems that support file
versions, multiple versions of individual files can result. A purge will eliminate this
duplication. On file systems that do not support multiple file versions, the earlier files are
overwritten. It is important to check the status file that is electronically mailed to the user
for any messages indicating that some files were not transferred.
Users are reminded that requests that include files that are currently not online in the CDHF will
not be processed until all files in the request have been retrieved and placed online. It can take 1
or 2 days to retrieve data files from the DDF.
Users of the staging are reminded to delete files from the staging directories after the files have
been transferred to their final destinations.
95
If you have a problem with a transfer or a question concerning the status of a transfer request, the
operations personnel can provide assistance. The request number for the transfer request in
question should accompany any queries about the request.
4.2.7.1 Status Messages in the Transfer Status
This section lists all of the status and error messages that can appear in the transfer status file that
is electronically mailed to the user at the completion of a transfer attempt. A short explanation is
provided for each message and the recommended user action, if any.
• [account] has exceeded transfer quota by [number] bytes
This message informs the user that the transfer quota was exceeded. The requested files
were transferred.
• [filename] not transferred, will be requeued
The specified file was not transferred due to an error. The request for this file will be
requeued.
• [filename] successfully transferred
The specified file was successfully transferred.
• [node address] is an unknown internet address
The specified node address is an unknown internet address. This message will occur if
the specified internet address is not known to the CDHF or if an incorrectly formatted
network address was entered. Because the CDHF will not be able to process the request,
it will be requeued for the next day. The user should log in and correct the destination
address using the appropriate query/modify form for the request.
• [num files] files transferred out of [tot files] files attempted
The transfer request was partially satisfied with [num files] out of [tot files] successfully
transferred. The files not transferred will be requeued unless the user exceeded the
maximum number of retries or exceeded the transfer quota.
•An error occurred processing this request. It will be requeued to execute again in
one day.
An error occurred in attempting to satisfy the transfer request. The request will be
requeued and will be attempted again in 24 hours.
• Data files will be transferred to: [node address]
This status message indicates the requested destination for the file transfer request.
• Logical file identifier [file id] is not online.
Files belonging to this logical file identifier will not be included in this request.
This message is associated with the processing of a standing request. The files associated
with the logical file identifier [file id] are not online in the CDHF, therefore they will not
96
be included in this transfer. A retransmission request will not be automatically generated
for this logical file ID. To request retransmission of this file, the user should use the
Create Transfer Request for Cataloged Files form to enter a new request.
• Maximum attempts to transfer this request exceeded. Request has been deleted.
The maximum number of retries to transfer the requested files has been exceeded and the
request has been deleted. This will occur if the network path to the specified destination
is not up or the destination node is not available for an extended period of time. Failed
transfer requests will be requeued MAX_XFER_TIMES (a system parameter). Each retry
will be separated by DELTA_XFER_TIME minutes (a system parameter).
•New transfer request number [request number] has been created from standing
transfer request number [request number]
This informational message indicates the request number of the new request that has
resulted from the processing of the specified standing transfer request. The request
numbers are primarily for tracking purposes in the database but are provided as status
information to the user because they can be useful in identifying specific requests when
multiple requests from the same user have been made.
•No online file found for standing transfer request number [request number] at
execution date [date:time]
This informational message indicates that the standing transfer with request number
[request number] was executed at [date:time] and the processing of the query resulted in
no matches for online files in the database, hence no files to transfer.
•Processing transfer request number [request number] for user [username] at
[date:time]
This informational message gives the request number, requesting username, and the date
and time that the request is being processed. This is the first message in the status file.
• Requested file [filename] not found
The request file was not found. If the file was a file in a user directory, it may have been
deleted before the request was processed. If the file was a cataloged file, then there was
an error on the CDHF. The operations personnel would have been notified by the
software, but it would not be inappropriate to forward the mail message to them.
• Request [request number] no files found for this request
This error message indicates that an inconsistency exists in the database. The operations
personnel would have been notified by the software, but it would not be inappropriate to
forward the mail message to them.
• Request completed successfully, [num files] files transferred
The request was successfully completed and a total of [num files] was transferred.
• The request has been requeued for [date:time]
97
If a request is not fully satisfied, it will be requeued. This status message indicates that
the specified request has been requeued and will be retried at the specified time.
For failed data transfer, the transfer status file, sent to the user, will include a log
detailing why the transfer failed.
4.3 Update Key Parameter Quality Information
The update key parameter service allows the user to update quality information for the specified
key parameter file within the CDHF catalog.
The user makes updates to key parameter file quality information within the CDHF catalog either
by using a form or by specifying all the changes in a file processed by the user interface. Figure
4–4 illustrates the Update Key Parameter Quality Information menu. Information to determine
the key parameter catalog entry to update, the updated comment, the updated quality flag, or the
file that contains this information is required.
For access through menus, choose the Update Key Parameter Quality Information option from
the CDHF User Interface main menu. From the next menu displayed, choose whether to perform
updates via a form or a file. You must have certification privilege for the mission instrument
associated with each key parameter file to be updated.
+A user with certification privilege for key parameters also has certification privilege for
the KPGS program that generated them. Refer to Section 4.1.2.4.2 for KPGS certification
guidelines.
Figure 4–4. Update Key Parameter Quality Menu
98
4.3.1 Key Parameter Quality Update Form
The Key Parameter Quality Update Form allows users with certification privilege for a mission
and instrument to update the Key Parameter (KP) Quality Indicator and KP PI Comments for any
corresponding KP files. This form is set up for USER privileged users.
Usage Restrictions:
•Read-only users cannot access this form because they do not perform key parameter
quality updates.
• Inserts and deletes are prohibited in this form.
• Queries are restricted. They must be performed using either of the query criteria blocks in
the top part of the form.
•The user must have certification privilege for the Mission Name and Descriptor
combination entered in the first block, or the Program Name and Program Version
entered in the second query criteria block must correspond to a Mission Name and
Descriptor for which the user has certification privileges.
Detailed Usage Guidelines:
•For the first query criteria block, the Mission Name, Data Type, Descriptor, Start Date,
and End Date must be specified. The default values displayed may be changed as
required. For the second query criteria block, the Program Name, Program Version, Start
Date, and End Date must be specified. The SF1 key toggles between the first and second
query criteria block. The performance of the second query criteria block may take
additional time due to the number of database tables used to perform the query.
•To view allowable field values, invoke the list of values function in the Mission Name,
Data Type, and Descriptor fields in the first query criteria block and in the Program
Name and Program Version fields in the second query block. After the information in the
query criteria block is entered, invoke the Next Block function to query the list of
corresponding key parameter file information.
•The wildcard, "K%" (all KP files), is allowed for Data Type in the first query criteria
block to reduce the number of KP data types that need to be entered. No other wildcards
are allowed.
•Information for several KP files may be returned by the query; invoke the down function
to view the information for the other files.
• The logical identifier identifies the key parameter file. This field cannot be updated.
•The KP Quality Indicator indicates whether the file is code RED, YELLOW, or GREEN.
To change the status, the file has to first be selected and the user must press the SF4 key.
•The Program Version field indicates the version of the program that generated the file.
This field cannot be updated.
•The Select Flag field indicates whether a file is selected for update or not. Blank indicates
that the file is not selected. By pressing the SF1 key, the file can be selected/deselected.
By pressing the SF2 key, all files are selected.
99
Format:
•To view or display KP details, press the SF3 key. When the SF3 key is pressed, a new
screen appears. This screen is for display only. No changes are allowed to this screen.
Press the EDIT key to view additional comments.
100
Format:
•Once the file(s) are selected, press the SF4 key to enter and/or update the KP Quality
Information and KP PI Comments. When the SF4 key is pressed, a new screen will
appear.
•To update the KP Quality Indicator, the Update KP Quality field must be set to "Y" for
YES. When Update KP Quality is set to "N," changes to the KP Quality Indicator are
disabled. If the KP Quality is updated, the KP Certify Date is set to the current date and
the KP VAX User ID is set to the current VAX user.
•To update the KP PI Comments, the Update KP PI Comments field must be set to "Y" for
YES. When Update KP PI Comments is set to "N," changes to the KP PI Comments are
disabled. Press the EDIT key to add additional comments.
101
Format:
4.3.2 Process Key Parameter Update File
The File Key Parameter Quality Updates form, illustrated below, can be invoked by selecting the
Process Key Parameter Update File option from the Update Key Parameter Quality Information
menu. This form allows users to update key parameters by processing an input file. The file must
reside on the CDHF, but it can be created at a remote facility (and transferred) or on the CDHF
using a VAX editor.
102
Format:
Usage Restrictions
• This is a data entry form only.
• Queries are not allowed.
Detailed Usage Guidelines:
•Enter the full physical filename of the file that contains the updates to the key parameter
quality information [i.e., ISTP_USER: (DOE.KP) KPUPDATE.DAT or, if the current
default directory contains the file, simply KPUPDATE.DAT].
•The input file must be set up to comply with the format illustrated in Figure 4–5. Failure
to comply will result in the file not being processed and errors being displayed on the
screen.
• Currently, only one 80-character comment may be entered using the input file.
An example of an input file is as follows:
KEY PARAMETER QUALITY UPDATE FILE FOR USER my_user_name
WI_KO_EPA_19930912_V02
GREEN
Maneuver at 1407
WI_KO_EPA_19930912_V01
RED
Excessive noise
WI_KO_EPA_19930911_V01
This file is not evaluated
103
Key Parameter Quality Update File for User [db_user_id]
logical_file_name (max 26 chars -- KP filename)
PI_comment (max 80 chars -- KP quality comment)
.
.
.
logical_file_name
KP_quality_update
PI_comment
Header Record
Entry # 1
Entry # n
80 column record
80 column record
80 column record
80 column record
KP_quality_update (max 6 chars -- RED, YELLOW, GREEN)
Figure 4–5. KP Quality Update File Format
4.4 Create Decommutation Specifications Form
This form allows users to create, modify, and delete decommutation specifications for level-zero
files. The decommutation specifications are used to specify a set of bytes to extract from a level-
zero file for transfer to the user. This will ensure that the quantity of level-zero data is kept to a
minimum. The decommutation specifications created can be referenced in the Create Transfer
Request for Cataloged Science Files and Create Standing Request for New Science Files forms.
The decommutation specification will consist of a list of minor frames and the bytes within those
minor frames from which data is to be extracted.
Several frames and bytes may be specified for extraction for a single decommutation
specification.
You may only create decommutation specifications for mission instruments for which you have
the appropriate access privilege as indicated in the ISTP Users and Privileges form. If you create
the decommutation specification, you may allow other users to reference your specification.
Only the creator and the DBA are allowed to delete decommutation specifications. Additionally,
the DBA may create decommutation specifications. The DPS may only view decommutation
specifications.
104
Format:
Usage Restrictions:
• Read-only users may not access this form.
• Only the owner is allowed to modify a decommutation specification.
•Users are only allowed to create decommutation specifications for mission instruments in
which they have access privilege.
•Decommutation specifications can only be created for the mission instruments listed in
Table 4–1.
Detailed Usage Guidelines:
•A query will automatically be performed upon entering the form. The query returns all
decommutation specifications that you created and the ones that you are allowed to
reference in transfer requests.
•When a query is performed, you may cursor to the desired decommutation specification
by using the Down key. Once you find the desired decommutation specification, you may
use the Next Block key to access the lower level blocks.
•If a deletion is made from the first block, the entire decommutation specification will be
deleted.
•The special function key SF1 allows the owner to add and delete authorized users to
access the decommutation specification. The authorized users have access to use the
decommutation specification when transferring level-zero files. The owner is
automatically given access privilege when a new decommutation specification is created.
•The Decommutation Specification Name identifies the unique name associated with the
decommutation specification. It is recommended that the mission and instrument be used
to construct the name.
•The Owner, Creation Date, and Last Update are automatically generated for new
decommutation specifications. You are not allowed to modify fields in the first block.
105
Additionally, the Last Update attribute is updated with the current date each time a
modification to the decommutation specification is made.
Table 4–1. Valid Byte Ranges
Instrument
Normal
Maneuver
GEOTAIL
CPI 0–35 0–35
EFD 0–7 0–7
EPIC 0–19 0–19
HEP 0–12 0–12
LEP 0–15 0–15
MGF 0–7 0–7
PWI 0–10 0–10
SCR 0–10 0–10
WIND
EPACT 0–23 0–22
KONUS 0–5 0–5
MFI 0–24 0–22
SMS 0–41 0–34
SWE 0–44 0–1
TGRS 0–20 0–20
WAVES 0–44 0–60
3DPLASMA 0–49 0–35
SCR 0–12 0–53
POLAR
CAMMICE 0–9 0–9
CEPPAD 0–17 0–17
EFI 0–12 0–12
HYDRA 0–23 0–1
MFE 0–5 0–5
PIXIE 0–23 0–10
PWI 0–20 0–20
SEPS 0–23 0–10
TIDE 0–20 0–20
106
TIMAS 0–20 0–20
UVI 0–57 0–48
VIS 0–50 0–54
SCR 0–6 0–49
•The Mission and Instrument identifies the mission and instrument associated with the
decommutation specification for level-zero extraction. You can only specify a
mission/instrument combination in which you have access privilege. No wild cards are
allowed.
•The Specification Numbers identify the number of minor frame specifications that exist.
As you cursor through a set of minor frame specifications, the specification numbers
indicate the specification number currently being viewed and the total number of
specifications that exist.
•The Starting Minor Frame Number specifies the first minor frame in which bytes are to
be extracted. The Ending Minor Frame Number specifies the last minor frame in which
bytes are to be extracted. The Increment Between Minor Frames attribute identifies the
increment between frames in the minor frame extraction. When you type in the starting
minor frame, a default value for the ending minor frame is automatically displayed to be
the same as the starting minor frame. A default value of 1 is automatically displayed for
Increment Between Minor Frames. You may overwrite both default values.
• The range of valid minor frame number is as follows:
GEOTAIL 0–511
WIND 0–249
POLAR 0–249
•The Byte Ranges To Extract attribute identifies a range of bytes to extract for each frame.
Single bytes or a range of bytes may be specified. The starting byte and the last byte are
to be specified. Once the starting byte has been entered, a default value that is the same as
the starting byte will be displayed for the ending byte. You may overwrite the default
ending byte. Table 4–1 lists the valid byte ranges for each instrument and mode.
•Frame and byte range specifications can be modified or deleted; however, each frame
specification number must have at least one byte range, each decommutation
specification number must have at least one byte range, and each decommutation
specification must have at least one frame specification number.
•If an incomplete decommutation specification is entered, the commit function will fail.
You must complete the specification indicated in the failure message. If the specification
causing the failure is not your own specification, contact the DPS personnel for a
resolution.
•After identifying a range of bytes to extract, a user may decide to change the
mission/instrument fields or the instrument field before committing the form. After
committing the form, if the ending minor frame or ending extract byte is invalid for the
newly changed mission/instrument fields or instrument field, a message indicating this
will appear. After acknowledging the message, the cursor will appear either in the
starting minor frame of the invalid record or the starting extract byte of the invalid record.
The user will make the change and commit the form. Refer to Table 4–1 for valid byte
ranges.
107
4.5 Invoke Theory Programs
When you select the Invoke Theory Programs item from the main menu of the User Interface,
the menu shown in Figure 4–6 is displayed. This menu lists the available theory programs. Use
the cursor keys to select the desired program and press [RETURN] to invoke the program. The
theory groups provide their own online help for these programs: the User Interface does to
provide this help.
4.6 Extract NRT LZ Data
The extract NRT LZ service provides the capability to extract NRT decommutated LZ data via
the User Interface form or the command line (if the NRT filename is known).
Figure 4–6. ISTP Theory Programs Menu
4.6.1 Query LZ Form
The query LZ form allows you to list NRT LZ files that are available for data extraction. The
filename indicates the instrument and date/time the pass was received in CDHF. Once you have
listed the files, the SF1 key can be used to select files for data extraction. You may press the
Accept key to extract data into output files for all selected files. This form does not allow
changes to the database.
108
Format:
Usage Restrictions:
• Inserts are prohibited in this form.
• Once files have been queried, they cannot be updated or deleted.
•Queries may only be performed from the first block. Enter the query criteria and press
Next Block to view NRT LZ files.
•If you have a default mission and descriptor, they will be automatically displayed as a
query criteria. The file type will be set to “ACTIVE” as a default. “ACTIVE” indicates
that the current file is opened by the NRT software during an NRT pass.
• You may select a maximum of 10 files at one time.
Detail Usage Guidelines:
+Refer to page QT-1 in the “Quick Tour of the CDHF User Interface” for terminal setup
information, including keyboard mapping. Use [CONTROL] K to show key definitions
from any SQL*Form. Refer to page QT-10 for a step-by-step example of how to extract
NRT data from an active file.
• Wild cards (%) are allowed for descriptor and file type in the query criteria block.
•File type may be specified as “ACTIVE” which will only query current files that are
opened during a pass or “%” for files that exist in the specified descriptor directory.
•You may query NRT LZ files for the specified query criteria by pressing the Next Block
key.
•Use special function key SF1 to select or unselect files for data extraction. When the files
are selected, an “S” appears under the selected column for that file. Unselect a selected
file by pressing the same key. Pressing SF1 for a selected file removes the “S” from the
“Selected” column. The cursor will automatically advance to the next row after a file has
been selected or unselected.
•When a file has been selected, the start and end dates are displayed. When a file is
unselected, the start and end dates are erased from the screen. The amount of data
109
extracted can be adjusted by changing the start and end times. The file must be selected
before the start and end dates can be modified. Press [TAB] to advance to the next field.
•Extracted data will be written to an output file in the SYS$LOGIN directory logical. The
name of the output file will be the same as the physical filename of the selected file with
an “X” appended to the end of the file (e.g., WI_LZ_3DP_19930707_V01.1212X).
+One second has been added to the end time extracted from the NRT LZ file to ensure that
all of the data are extracted for that file. When entering end time for an extracted file, add
1 second to the time. In both cases, the additional second is required to compensate for
the milliseconds that are truncated by the User Interface.
Level-Zero Data File Information:
+The level-zero data file that is opened by the NRT software during an active pass also is
available for data extraction. Note that the file label record (FLR) contains information
related to start of the pass until the pass is completed. At the end of a pass, the first 176
bytes (i.e., through the instrument filename field) are updated. (The remainder of the FLR
remains zero filled because it is not used for NRT files.) Then, the file is closed and the
file is renamed to include its date and time.
4.6.2 EXTRACT_NRT_LZ Command
NRT LZ extraction can also be performed from the command line without going through the UI.
The EXTRACT_NRT_LZ command is described in the following paragraphs.
FORMAT
$ EXTRACT_NRT_LZ/INPUT=inputFile/OUTPUT=outputFile -
/START=startTime/END=endTime
PARAMETERS
There are no parameters for EXTRACT_NRT_LZ
DESCRIPTION
EXTRACT_NRT_LZ extracts the data from the selected time period from the specified NRT LZ
input file and writes the data and an updated file label record to the output file.
Normally, a User Interface SQL*Form is used for selecting the input file and invoking this
command. The form aids in finding the active and nonactive LZ files and in finding the start and
stop times for the files for nonactive files (or the start time only for active files).
Messages regarding the extraction process are written to the standard output (normally the
screen).
QUALIFIERS
• /INPUT=inputFile
The inputFile is the full physical filename of the input NRT LZ file from which the data
are to be extracted. This qualifier and inputFile name are required. When using
EXTRACT_
NRT_LZ from the command line to extract level-zero data, the input filename should be
110
specified along with the logical name that points to the location of the level-zero data file
(e.g., NRT_WI_3DP).
• /OUTPUT=outputFile
The outputFile is the full physical filename of the output file to which the extracted data
are to be written. This qualifier and outputFile name are required.
• /START=startTime
The startTime is a date and time in VAX/VMS format (“dd-mmm-yyy hh:mm:ss”) for
the first major frame to be extracted. (The double quotes are needed, since the string
contains a blank.) If this qualifier and startTime are not supplied, the data will be
extracted starting at the start of the inputFile.
• /END=endTime
The endTime is a date and time in VAX/VMS format (“dd-mmm-yyy hh:mm:ss”) for the
last major frame to be extracted. (The double quotes are needed, since the string contains
a blank.) If this qualifier and endTime are not supplied, the data will be extracted ending
at the end of the inputFile.
EXAMPLES
• $EXTRACT_NRT_LZ/INPUT=NRT_WI_3DP:WI_LZ_3DP.NRT-
/OUTPUT=WI_LZ_3DP.NRT_A-
/START=“21-APR-1994 22:10:00”-
/END=“21-APR-1994 22:22:00”
In this example, a user invokes EXTRACT_NRT_LZ from the DCL command line to
extract data from an active NRT LZ file starting at 21-apr-1994 22:10:00 and ending at
21-apr-1994 22:22:00 and to place the output in the file WI_LZ_3DP.NRT_A. In order
for data to be extracted, the user must know that data are in the file for the requested
span.
If no /START or /END qualifiers are provided, then the entire file is copied.
• $ EXTRACT_NRT_LZ /INPUT=NRT_WI_3DP:WI_LZ_3DP_19940421_V01.2250 -
/OUTPUT=extracted_data.dat.
In this case, a user invokes EXTRACT_NRT_LZ from the DCL command line to extract
the entire file and place the output in the output file extracted_data.dat.
• $ EXTRACT_NRT_LZ /INPUT=NRT_WI_3DP:WI_LZ_3DP_19940421_V01.2250 -
/OUTPUT=extracted_data2.dat /START=“21-apr-1994 22:22:00”
In this case, a user invokes EXTRACT_NRT_LZ from the DCL command line to extract
the file starting at 21-apr-1994 22:22:00 and ending at the end of the file and to place the
output in the file extracted_data2.dat.
• $ EXTRACT_NRT_LZ /INPUT=NRT_WI_3DP:WI_LZ_3DP_19940421_V01.2250 -
/OUTPUT=extracted_data3.dat /END=“21-apr-1994 22:42:00”
In this case, a user invokes EXTRACT_NRT_LZ from the DCL command line to extract
the file starting at the start of the file and ending at 21-apr-1994 22:42:00 and to place the
output in the file extracted_data3.dat.
• $ EXTRACT_NRT_LZ /INPUT=NRT_WI_3DP:WI_LZ_3DP_19940421_V01.2250 -
/OUTPUT=extracted_data4.dat /START=“21-apr-1994 22:12:00” -
/END=“21-apr-1994 22:22:00”
In this case, a user invokes EXTRACT_NRT_LZ from the DCL command line to extract
the file starting at 21-apr-1994 22:12:00 and ending at 21-apr-1994 22:22:00 and to place
the output in the file extracted_data4.dat.
111
+When an NRT pass is completed (indicated by the file extension's change from “NRT” to
the hhmm format), a network copy can be used to transfer the entire file.
4.7 Plot Orbit Data
This orbit plot services provide the capability to plot orbit files.
4.7.1 Orbit Plot Form
The orbit plot form allows you to query daily and working orbit files for plotting. Once you have
queried the files, the SF1 key can be used to select files for data plotting. You may press the
Accept key to plot the selected files. This form does not allow changes to the database.
Format:
Usage Restrictions:
• Inserts are prohibited in this form.
• Once files have been queried, they cannot be updated or deleted.
•Queries may only be performed from the first block. To view orbit files, enter the query
criteria and press Next Block.
•If you have a default mission, data type, and descriptor, they will be automatically
displayed as query criteria to reduce data entry.
• You may select a maximum of 10 files at one time.
• Only CDF orbit files may be plotted.
• Online file status is not available for working orbit files.
Detail Usage Guidelines:
• Wild cards (%) are allowed for mission and descriptor in the query criteria block.
112
•Special function key SF1 can be used to select or unselect files for plotting. When the
files are selected, an “S” appears under the “Selected” column for that file. A selected file
can be unselected by pressing the same key. Pressing SF1 for a selected file removes the
“S” from the “Selected” column. The cursor will automatically advance to the next row
after a file has been selected or unselected.
Supported Devices:
The names of the device types can be abbreviated if the abbreviations are not ambiguous; in most
cases, the first two letters are sufficient. To display plots on your terminal, you must be using a
supported graphics device and enter the corresponding PGPLOT device type, as shown in
Table 4–2.
Example:
You will be prompted with a series of questions once the Accept key has been pressed to plot the
files. The following text in bold will appear on screen. The text not in bold shows possible user
responses.
Gathering data
Graphics device/type (? to see list): ?
PGPLOT v4.9D Copyright 1990 California Institute of Technology
Legal PGPLOT devices are:
/GF (Graph On) /HIDMP /FILE /NULL
/PK /PS /PRINTRONIX /PERITEK
/RETRO /TEK4010 /TFILE /TK4100
/VPS /VT125 /WSO /X11 (Landscape)
Graphics device/type (? to see list): /tek4010
Select coordinate system: GCI, GSE, GSM
Cntrl-Z to exit
GSM
Select plot axis: X-Y, X-Z
X-Z
Table 4–2. Supported Graphics Devices
Device Description PGPLOT Device Type
Metafile /FILE
GraphOn GO-230 terminal /GF
Houston Instruments HIDMP pen plotter /HIDMP
Null device (no graphical output) /NULL
Peritek Corp. VCH-Q frame-buffer video /PERITEK
Peritek Corp. VCK-Q frame-buffer video /PK
Printronix P300 pr P600 printer /PRINTRONIX
PostScript device (landscape mode) /PS
113
Retrographics modified VT100 terminal (VT640) /RETRO
Tektronix 4006/4010 storage-tube terminal /TEK4010
Tektronix 4014 (12-bit addressing) /TFILE
Tektronix 4100-series color terminal /TK4100
PostScript device (portrait mode) /VPS
DEC VT125, VT240, or VT340 terminal (REGIS) /VT125
VAX/VMS workstations /WS0
X-terms /X11
4.8 Access the NEWS Bulletin Board
The UI provides access to the ISTP Bulletin Board utility. This bulletin board is implemented
using the public domain ANU NEWS utility. It contains news groups of interest to the ISTP
community.
When you invoke the NEWS utility for the first time, it displays all of the news groups. The
groups named Control and Junk are used by the NEWS utility for its housekeeping, and you
should not be concerned with these two groups. When you move the cursor with the arrow keys
to any other new group and press [ENTER], a directory of all news items in that news group is
displayed. You can move the cursor to the news item and press [ENTER] to read that item. After
the complete news item is displayed, press [ENTER] again to return to the directory of the news
group. To read another item in this news group, repeat the process. If you are interested in this
news group, enter the command REGISTER to register to that news group. Now you can return
to the main directory by the DIR/NEWS command. By moving the cursor to any other news
group, you can repeat the above process. Upon completion, exit NEWS with the EXIT
command.
Additional commands may be used as follows:
•POST—Posts a news item. Users with write access to a particular news group can post
an item in that news group.
•EXTRACT—Copies the selected item to a file.
•PRINT—Prints a news item to a print queue.
•MAIL—Sends a news item to a given user.
•HELP—Provides more details on the above commands and other commands.
To request establishment of a new news group, send E-mail to ISTP::KNIGHT. Again, online
help is available from within the NEWS utility by entering the HELP command.
If the command $NEWS/SCAN is included in your LOGIN.COM, the NEWS utility will
automatically notify you when there is a new news item. If you want to start an interactive
session automatically when there are any unseen news items, use the $NEWS/UNSEEN2
command in your LOGIN.COM.
The NEWS utility creates a file named NEWSRC. in your login directory for housekeeping.
A–
1
APPENDIX A—KEYBOARD MAPPINGS
This appendix provides keyboard mappings for various terminals, keyboard types, and
emulators.
A–2
SQL*FORMS KEYPAD VT100
KEY:
Gold Stroke
Single Stroke (E) = Edit window only
Scroll Up
Up
Scroll Down
Down
Begin. of Line
Left Right
End of Line
Left Down Right
Up
PF1 PF2 PF3 PF4
12
0.
3
4 5 6
789-
Enter
,
Gold
Previous
Field
Display
Error Exit/
Cancel
Clear
Field Clear
Record
Clear
Block
Clear
Form
Copy
Execute
Query
Paste
Insert
Record
Cut
Delete
Record
Select
Enter Query
Previous
Block
Next Block
Help
Show Keys Commit/
Accept
SF1 SF2 SF3
SF4
Menu
Search (E)
InsertLine
(E)
Edit
List Insert/
Replace
Delete Backwards-BackspaceDelete
Line (E)-Gold BackspaceFirst Line (E)
-Gold, Gold, UpInsert/Replace-
CTRL-ALast Line (E)-Gold, Gold,
DownNext Field-ReturnNext Field/Exit
Edit-TabPrevious Field-Gold
ReturnPrint Screen-CTRL-PScroll
Left-Gold, Gold, LeftScroll Right-
Gold, Gold, RightShow Keys-CTRL-K
Refresh Screen-CTRL-R
A–3
Enter
SQL*FORMS KEYPAD VT220
PF1 PF2 PF3 PF4
1 2
0•
3
45 6
789-
,
Gold Previous
Field Display
Error
Exit/C
ancel
Nxt. Scrn.
F14
First Line (E)
Menu
LastLine (E) Search (E) InsertLine (E)
Edit List Insert/
Replace
HELP DO
Help
Show Keys
Commit/
Accept
F17 F18 F19 F20
SF1 SF2 SF3 SF4
F7 F8 F9
Clear
Field Clear
Record Clear
Block Clear
Form
KEY: Gold Stroke
Single Stroke (E) = Edit window only
Delete Backwards-Backspace
Delete Line (E)-Gold
BackspaceInsert/Replace-
CTRL-ANext Field-ReturnNext
Field/Exit Edit-TabPrevious Field-
Gold ReturnPrint Screen-
CTRL-PShow Keys-CTRL-K
Refresh Screen-CTRL-R
Copy
Execute
Query
Paste
Insert
Record
Cut
Delete
Record
Select
Enter Query
Scroll Left
Previous
Block
Scroll Right
Next Block
Scroll Up
Up
Scroll Down
Down
Begin. of Line
Left Right
End of Line
Left Down Right
Up
Select Prv. Scrn.
Find Ins. Here Remove
Nxt. Scrn.
F11 F12 F13 F14
F10
A–4
Enter
SQL*FORMS KEYPAD VT220 Emulation on Mac Extended Keyboard
clear = / *
1 2
0•
3
45 6
7 8 9 -
+
Gold Previous
Field Display
Error
Exit/
Cancel
Nxt. Scrn.
F14
First Line (E)
Menu
LastLine (E) Search (E) InsertLine (E)
Edit List Insert/
Replace
F10 F11
Help
Show Keys
Commit/
Accept
F12
SF1
F13 F14 F15
SF2 SF3 SF4
F2 F3 F4
Clear
Field Clear
Record
Clear
Block Clear
Form
KEY:
Gold Stroke
Single Stroke (E) = Edit window only
Delete Backwards-Backspace
Delete Line (E)-Gold
BackspaceInsert/Replace-
CTRL-ANext Field-ReturnNext
Field/Exit Edit-TabPrevious Field-
Gold ReturnPrint Screen-
CTRL-PShow Keys-CTRL-K
Refresh Screen-CTRL-R
Copy
Execute
Query
Paste
Insert
Record
Cut
Delete
Record
Select
Enter Query
Scroll Left
Previous
Block
Scroll Right
Next Block
Scroll Up
Up
Scroll Down
Down
Begin. of Line
Left Right
End of Line
Left Down Right
Up
del end.
help home page up
page down.
F6 F7 F8 F9F5
A–5
B–1
APPENDIX B—NEAR-REAL-TIME DATA ACCESS
The ISTP CDHF supports the receipt and processing of WIND and POLAR telemetry data in
near-real time. During each Deep Space Network (DSN) contact, telemetry data is forwarded to
the CDHF where the data is edited and decommutated into instrument major frames. The
decommutated data is written to online storage on the CDHF for access by authorized
investigators. In addition, WIND near-real-time data for the MFI, SWE, and 3DP instruments is
processed into key parameters in real time for the SWIM investigation. These NRT key
parameters are sent to specified remote sites in real time and are written to online storage in the
CDHF for access by authorized investigators.
B.1 WIND and POLAR NRT Telemetry
The WIND and POLAR decommutated near-real-time telemetry files are written to separate
directories by instrument. These files are created in the same format as the playback level-zero
data files. Authorized investigators are granted direct access to the appropriate NRT directory.
The locations of the files are listed below.
WIND NRT Telemetry POLAR NRT Telemetry
Instrument Location Instrument Location
3DP NRT_WI_3DP CAM NRT_PO_CAM
EPA NRT_WI_EPA CEP NRT_PO_CEP
KON NRT_WI_KON EFI NRT_PO_EFI
MFI NRT_WI_MFI HYD NRT_PO_HYD
SCR NRT_WI_SCR MFE NRT_PO_MFE
SMS NRT_WI_SMS PIX NRT_PO_PIX
SWE NRT_WI_SWE PWI NRT_PO_PWI
TGR NRT_WI_TGR SCR NRT_PO_SCR
WAV NRT_WI_WAV TID NRT_PO_TID
TIM NRT_PO_TIM
UVI NRT_PO_UVI
B–2
VIS NRT_PO_VIS
The NRT telemetry files are named in the same manner as the playback level-zero files, with the
exception that the file extension contains a time stamp. For example:
WI_LZ_MFI_19940419_V01.1420
This is a WIND MFI level-zero near-real-time file for the real-time contact at 1420 Greenwich
mean time (GMT) on April 19, 1994.
PO_LZ_HYD_19950503_V01.0445
PO_LZ_HYD_19950503_V01.1518
These are two POLAR HYD level-zero data files for real-time contacts at 0445 and 1518 GMT
on May 3, 1995.
B.1.1 Access to NRT Telemetry Data
The active WIND and POLAR near-real-time level-zero files can be accessed by investigators
during a real-time pass. The files can be accessed through the UI (see Section 4.6) or by user
software. When accessed from a user program the files must be opened with READONLY and
SHARED attributes. Figure B–1 shows a sample FORTRAN program for reading and extracting
major frames of data from active near-real-time files.
Files from completed real-time passes can be transferred at any time using the ftp or COPY
commands.
B.2 Near-Real-Time Key Parameters
Key parameters are generated in near-real time for the WIND 3DP, MFI, and SWE instruments
as part of the SWIM investigation. These data are transmitted electronically in near-real time to
specified SWIM sites. In addition, near-real-time key parameter files are created on the CDHF.
The data in these files is created in Institute of Electrical and Electronics Engineers (IEEE)
format. Access to the near-real-time key parameter files is provided to authorized investigators.
Access is by file transfer at the end of a pass, although, in principle, the same program shown in
Figure B–1 could be used to read the active near-real-time key parameter file.
The near-real-time key parameter files are found the directories listed below.
WIND NRT Key Parameters
Instrument
Location
3DP NRT_WI_3DP_KP
MFI NRT_WI_MFI_KP
SWE NRT_WI_SWE_KP
B–3
The NRT key parameter files are named in the same manner as the key parameter files generated
from playback data, with the exception that the file extension contains a time stamp and all files
are of type KP (multiple key parameter output files are not supported in the NRT subsystem).
For example:
WI_KP_MFI_19940419_V01.1420
This is a WIND MFI near-real-time key parameter file for the real-time contact at 1420 GMT on
April 19, 1994.
B–4
character*255 lz_file,out_file
character*25 prompt
integer*4 clen,rec_len,rec_size
byte lz_rec(20000)
prompt = 'Enter name of input file: '
status = lib$get_input(lz_file,prompt,clen)
open(file=lz_file(1:clen),unit=10,status='old',readonly,
1 shared,access='sequential',form='unformatted')
inquire(unit=10,recl=rec_len)
rec_size = rec_len*4 ! to get bytes
prompt = 'Enter output file name: '
status = lib$get_input(out_file,prompt,clen)
open(file=out_file(1:clen),status='new',unit=11,
1 access='sequential',form='unformatted',
2 recordtype='fixed',recl=rec_len)
call extract(lz_rec,rec_size)
close(unit=10)
close(unit=11)
stop
end
subroutine extract(lz_rec,rec_size)
integer rec_size
byte lz_rec(rec_size)
do while (.true.)
read(10,end=999) lz_rec
write(11) lz_rec
end do
999 continue
return
end
Figure B–1. Sample Extraction Program
C–1
APPENDIX C—CDHF PUBLIC SOFTWARE DIRECTORY
The CDHF has established a public software directory called SYS_FILES:[PUBLIC]. This
directory contains public files of general use to the ISTP CDHF user community. The
subdirectories under [PUBLIC] can be accessed directly by preceding the subdirectory name
with SYS$PUBLIC: (e.g., SYS$PUBLIC:[CDF] specifies the CDF subdirectory).
The PUBLIC area on ISTP can be accessed via anonymous ftp. Anonymous ftp users will be
placed directly in the PUBLIC area .
The files in this directory and their contents are as follows:
AAAREADME.TXT This file
CDF.DIR Contains CDF distribution currently used on CDHF
DOCS.DIR ASCII and postscript versions of CDHF documents
OA_ROUTINES.DIRSource code for orbit and attitude transformation routines
SFDU_TOOLS.DIR SFDU utility programs
SPOF.DIR SPOF related files
TOOLS.DIR Software tools for ISTP
VTTOOL.DIR VTTOOL, a VT200 terminal emulator for UNIX
IN–1
INDEX
account 9
data files
data file information form 48
data processing
data process history form 51
data quality
level zero 59
data rights
access to files 20
ISTP users and privileges form 57
proprietary files 70
DDF
distribution information 60
DDF distribution report 67
distribution
DDF distribution information form 60
electronic mail
addresses 70
errors
forms 40
transfer requests 90
help
system 9
user interface 31
key parameter generation
calibration data information form 55
calibration data information report 66
certification report 64
data process history form 51
key parameter quality updates 93
parameter file information form 57
parameter file information report 66
processing history report 65, 66
program information report 66
reprocessing report 65
key parameter generation software certification 53
logical file identifiers 10
mission information
instruments 62
ISTP missions launched form 61
ISTP missions launched report 68
mission descriptors/instruments report 68
IN–2
near real time
access to telemetry files
extract NRT data 102
printing
printer selection 43
screens 40
reports
calibration data information report 66
CMS 20
daily transfer history report 90
database 42
data file certification 64
data file summary 64
data files received 63
data files stored on-line 63
data quality information report 67
data transfer requests report 89
DDF distribution report 67
ISTP missions launched report 68
key parameters reprocessed 65
mission descriptors/instruments report 68
parameter file information report 66
process program information 66
processing history 65, 66
setting output directory 42
SPOF 20
science files 10
terminal support 22
transfer requests
cataloged files 75
destinations 71
level-zero data extraction 99
modification 82, 84, 87
standing requests 79
status message 91
types 68
user files 73
user interface
advanced features 36
form modes 32
form navigation 33
forms 24
function keys 28
main menu 45
menus 23
queries 34
starting 21
wildcards 35
IN–3
AC–1
ACRONYMS
BFX bulk file transfer
bpi bits per inch
cd change directory
CDF Common Data Format
CDHF Central Data Handling Facility
CLUSTER Plasma Turbulence Laboratory
CMS Command Management System
CNE Center Network Environment
COSTR Collaborative Solar-Terrestrial Research
CRT Cathode Ray Tube
DBA database administrator
DBMS Database Management System
DCL Digital Command Language
DDF Data Distribution Facility
DECnet Digital Equipment Corporation network
DPS data processing specialist
DSN Deep Space Network
DX digital exchange
EOF Experimenters’ Operations Facility
ESA European Space Agency
EST eastern standard time
FDF Flight Dynamics Facility
FLR file label record
ftp file transfer protocol
GB gigabyte
GBI ground-based investigator
GDCF Generic Data Capture Facility
GEOTAIL Geomagnetic Tail
AC–2
GGS Global Geospace Science
GMT Greenwich mean time
GOES Geostationary Operational Environmental Satellite
GSFC Goddard Space Flight Center
HSC Hierarchical Storage Controller
ICD interface control document
ICSS ISTP CDHF Software System
IEEE Institute of Electrical and Electronics Engineers
IMP-8 Interplanetary Monitoring Platform-8
IMSL International Mathematics and Statistics Library
InfoLAN IPD local area network
IPD Information Processing Division
IPL Interplanetary Physics Laboratory
ISAS Institute of Space and Astronautical Science
ISTP International Solar-Terrestrial Physics
KP key parameter
KPGS key parameter generation software
LACN local area computing network
LANL Los Alamos National Laboratory
LAT Local Area Transport
LZ level-zero
MB megabyte
mm millimeter
MODNET MO&DSD Operational Development Network
MO&DSD Mission Operations and Data Systems Directorate
NAG Numerical Algorithms
NASA National Aeronautics and Space Administration
NETEX Network Executive
NOAA National Oceanic and Atmospheric Administration
NRT near-real-time (subsystem)
NSC Network Systems Corporation
AC–3
NSI NASA Science Internet
NSSDC National Space Science Data Center
PC personal computer
PI principal investigator
POCC Payload Operation Control Center
POLAR Polar Plasma Laboratory Mission
PPL Polar Plasma Laboratory
RAL Rutherford-Appleton Laboratory
RDAF Remote Data Analysis Facility
SAMPEX Solar Anomalous and Magnetospheric Particle Explorer
SEAS Systems, Engineering, and Analysis Support
SFDU standard formatted data unit
SIC support identification code
SMTP Simple Mail Transfer Protocol
SOHO Solar Heliospheric Observatory
SPOF Science Planning and Operations Facility
SWIM Solar Wind Interplanetary Measurement
TAE Transportable Applications Environment
TCL TAE Command Language
TCP/IP Transmission Control Protocol/Internet Protocol
TI theory investigator
UI User Interface
UTC Universal Time Coordinated
VAX Virtual Address Extension
VMS Virtual Memory System
VT virtual terminal
WIND Interplanetary Physics Laboratory Mission
