Project name: Planetary Data System
(PDS)
Program set name:
PDS Label Verifier
Abbreviation: lvtool
Version number: 2.19
Platforms
supported: Windows, Unix,
Linux
This document provides information on the
use of the PDS Label Verifier software set. This software checks PDS labels for
compliance with the labeling standards established by the PDS for data product
labels. These standards are documented in (1) The Planetary Science Data Dictionary
(PSDD), which contains definitions of the standard data element names and
objects that are used in labels, and in (2) The Planetary Data System Standards Reference, which defines all PDS standards for data
preparation (see Section 1.6).
This document
provides:
- A description of the components of the
PDS Label Verifier software set
- Information on how to install and run
the software
- A description of the command line
parameters
- A description of the messages that that
result from the validation process.
This
document is intended for those who are responsible for ensuring that labels
submitted to the PDS conform to PDS standards. This document assumes
familiarity with the PDS data preparation process and label design
requirements. The data preparation process is described in the PDS Data Preparation Workbook (JPL Document
D-7669, Part 1); label file requirements are described in full in
Chapter 5 of the PDS Standards Reference (http://pds.nasa.gov/documents/sr/Chapter05.pdf).
See Section 1.6.
PDS labels are written in the Object Description Language
(ODL). ODL consists of a series of lines of the form "keyword = value",
with certain keywords (for example, OBJECT) being used to delimit named
groups of keywords within the label. For
a description of the PDS implementation of ODL, see Chapter 12 of the PDS
Standards Reference. (http://pds.nasa.gov/documents/sr/Chapter12.pdf).
The keywords and objects are themselves defined in the Planetary Science Data Dictionary (PSDD).
The Dictionary exists as a Word file for human readers, as a text file for use by
the software, and is available via an online look up tool at (http://pds/tools/data_dictionary_lookup.cfm).
The PDS Label
Verifier reads PDS labels and performs the following types of error checking:
·
ODL
Language Checking
ODL Language checking detects errors in the usage of ODL, such as
missing quote marks, invalid characters in names, etc.
·
Data
Dictionary Checking
Data Dictionary checking detects errors in the use of keywords and
objects, such as misspelled or unknown keywords, objects that do not have all
required keywords, etc.
·
SFDU
Checking
The PDS does not require Standard Formatted
Data Unit (SFDU) labels on individual products, but they may be desired for
conformance with specific project or other agency requirements. When present, SFDU Checking performs
validation in accordance with Chapter 16 of the PDS Standards Reference, SFDU
Usage. (http://pds.nasa.gov/documents/sr/Chapter16.pdf).
·
Planetary Science Data Dictionary Document, August 28, 2002, Planetary Data
System, JPL D-7116, Rev. E.
·
Planetary Data System Data Preparation
Workbook, JPL D-7669, Part 1. (http://pds.jpl.nasa.gov/dpw/dpw.pdf)
The PDS Label Verifier software set consists of the
following files:
Windows
Lvtool.exe - executable
pdsdd.full or pdsdd.idx - Data Dictionary full or index
file, respectively
make_index.exe –
utility that creates the pdsdd.idx
Unix or Linux
lvtool – executable
pdsdd.full or pdsdd.idx - Data Dictionary full or index
file, respectively
make_index - –
utility that creates the pdsdd.idx
These files are
available via a platform-specific installer package and may be downloaded from
the following url: http://pds/tools/software_download.cfm.
At the url, scroll down the window until LVTOOL is displayed, click on the
appropriate platform once, fill in the requested information and hit the
“download now” button. When the new
information is displayed, click on the download hyperlink to obtain the
installer package.
PDSDD.FULL is
bundled together with the LVTOOL installation. It can also be obtained by scrolling through the download page to “PDS
Toolbox Data Dictionary and index Version *****”(the version number will be
changed from time to time and is not shown here). Select MULTIPLE from the download list.
MAKE_INDEX (Version
1.7 or higher) is also a program that is bundled together with the LVTOOL
installation. This tool allows you to create the Data Dictionary index file
needed for semantic validation of a label or series of labels.
Download the platform-specific
installer package file to the hard drive.
Run the file (via
command-line or by double-clicking the file with your mouse) and follow the
installation instructions on the screen. When you get to the “Package Component
Selection” screen, choose “Selected Applications” under the “Binaries” section
and if desired, check the Source Code and the Documentation to retrieve the
LVTOOL source and user guide, respectively. The next screen will take you to
the list of PDS tools that are available for installation. Look for LVTOOL,
check the appropriate box, and hit “install”. The user will then be prompted to
choose their desired installation folder before the actual LVTOOL installation
is complete.
Once the
installation is complete, go to that directory and run make_index to create the
Data Dictionary index file.
You can do this by
typing at the prompt:
%> make_index
pdsdd.full
Or if you desire,
you can let the Verifier create the index file for you during program execution
via the –df flag (see section 4.0 for detailed usage).
Since the Verifier
makes a system call to make_index to do this, make sure that make_index is
lying in the same directory as LVTOOL or your PATH variable contains a location
to make_index. Also, only make_index version 1.7 or higher can be used for this
feature.
The PDS Label Verifier is a command line tool and will need
to be run from a command prompt.
To start the Label
Verifier from the same directory in which the Verifier and default Data
Dictionary files are located, enter the command:
lvtool -f <input-file> -r
<output-file>
where
<input-file> is the name of the label file to verify, and
<output-file> is the name of the file of the verification report. If the Verifier cannot locate the Data
Dictionary files it needs, it will generate a message.
The Verifier may
also be started from a different directory that the one in which the Verifier
and Data Dictionary files are located.
For example, on a Unix system, if the Verifier and dictionary files are
located in directory /usr/local/pds, enter the command:
/usr/local/pds/lvtool -f <input-file> -r <report-file> -d
/usr/local/pds/pdsdd.idx
The -d option tells
the Verifier the path name of the PDS Data Dictionary index file.
If using the data
dictionary full file, then use the –df option instead of –d:
/usr/local/pds/lvtool -f <input-file> -r <report-file> -df
/usr/local/pds/pdsdd.full
The –df option
tells the Verifier the path name of the PDS Data Dictionary full file. You will
need to also make sure the the make_index program is located in the same path
as lvtool since it uses that to create the index file internally when giving
the full file as an input.
NOTE: If using the Verifier to check
catalog template files, see the -a option.
(See the “Command Reference” chapter.)
To get a brief
description of the command line parameters, at the command prompt type:
lvtool
The parameters are
also explained in detail in the COMMAND REFERENCE section of this document.
For further help or
information, contact the PDS Operator at pds_operator@jpl.nasa.gov
The following
examples will help in using the Verifier immediately. The chapter, “What the
Verifier Does,” explains verification in more detail.
While reviewing the
following examples, refer to the “Command Reference” chapter, which explains
the command line options available for the Verifier, and the “Verifier
Messages” chapter, which explains the error and warning messages generated by
the Label Verifier.
The following
examples assume that both the Verifier and the Data Dictionary reside in the
current directory.
Assume there is a
label file called “example1.lbl” as shown below:
_____________________________________________________________
CCSD3ZF0000100000001NJPL3IF0PDS20000001
RECORD_BYTES =
284
RECORD_TYPE =
FIXED LENTGTH
FILE_RECORDS =
529
TARGET_NAME =
VENUS
MISSION_NAME =
MAGELLAN
^TABLE =
“GEO.TAB”
OBJECT =
FEATURE_TABLE
INTERCHANGE_FORMAT = ASCII
ROWS = 529
COLUMNS = 8
OBJECT = COLUMN
NAME =
MINIMUM_LATITUDE
DATA_TYPE =
REAL
UNIT =
DEGREE
START_BYTE = 1
BYTES = 8
DESCRIPTION = “The minimum_latitude element
specifies
the
southernmost latitude of the feature.”
END_OBJECT = COLUMN
/* Etc
... */
END_OBJECT =
FEATURE_TABLE
END
Label File “example1.lbl”
_____________________________________________________________
Entering the
command:
lvtool -f example1.lbl -r myreport.rpt
tells the Verifier:
“Validate file ‘example1.lbl’ and write the report to file
‘myreport.rpt’.” After this command
completes, the “myreport.rpt” file will look as follows:
_____________________________________________________________
************************************************************************
* *
* Planetary
Data System Validation Report *
* Label Verifier Version 1.5 *
* *
* Thu Sep 24 08:58:33 1998 *
* *
* Toolbox
Data Dictionary name: pdsdd.idx *
* *
* Data Dictionary Validation is ON *
* Verbose Error Reporting is OFF *
* Screen Display is OFF *
* Name Aliasing is OFF *
* Itemized Error Reporting is ON *
* Expand Structure Pointers is OFF *
* DOS Recursive Directory Search is
OFF *
* Label Validation and Pointer File
Verification *
* *
************************************************************************
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> example1.lbl >
> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * * * The
hierarchy of objects in this label is: * * * * *
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FEATURE_TABLE
(line 8)
COLUMN - MINIMUM_LATITUDE (line 12)
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * * * The
ODL syntax errors in this file are: * * * * *
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ERROR: Line
3 - - syntax error
ERROR: Line
3 - - Expected ‘=’ after name
WARNING: Line
24 - - Label reading complete with 2
errors, 0 warnings.
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * * * The
semantic errors in this file are: * * * * *
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Keywords of ROOT (line 0):
WARNING: Line 3
- - RECORD_TYPE: Value is not a standard value
Sub-objects of TABLE (line 8):
WARNING:
Line 8 - - FEATURE_TABLE: Using PDS
GENERIC object definition.
Keywords of TABLE (line 8):
ERROR: Line 8 - - FEATURE_TABLE: The following required keywords are
missing:
ROW_BYTES
Sub-objects of COLUMN (line 12):
WARNING:
Line 12 - - COLUMN:
Using PDS GENERIC object definition.
Semantic validation completed with 4 errors of
warnings.
************************************************************************
* *
* This is
the end of
the Validation Report *
* *
* Thu Sep 24 08:58:33 1998 *
* *
************************************************************************
Report File
“myreport.rpt “
_____________________________________________________________
The report file is
divided into 4 sections:
·
A file
header, which indicates which label was verified.
·
An
object hierarchy, which indicates the nesting of ODL objects within the
label. This is useful for detecting
problems with object nesting.
·
A
syntax message section, with SFDU Label and ODL language errors and warnings
listed by line number.
·
A
semantic error message section, with Data Dictionary errors and warnings listed
both by line number and by the object in which they occur.
The first error in
the syntax message section is listed below:
ERROR: Line 3 - - Expected ‘=’ after name
Line 3 of the example
labe file “example1.lbl” is:
RECORD_TYPE = FIXED LENGTH
The correct line
should have an underscore in the value:
RECORD_TYPE = FIXED_LENGTH
The additional
error message:
WARNING: Line 3 - -
RECORD_TYPE: Value is not a
standard value
is also a result of
this typographical error.
If there are
several label files in the directory, (e.g. “example1.lbl”, “example2.lbl”, and
“example3.lbl”), enter the command:
lvtool -f *.lbl -r myreport.rpt
This tells the
Verifier: “Validate all the files in the directory that have extension ‘.lbl’
and write all the results to file ‘myreport.rpt’”. The report file will look the same as it did
in the first example, except that the four report sections will be repeated for
every file in in the directory that has extension “.lbl”.
Assume that the
existing Data Dictionary contains too general a set of rules for the object
class TABLE. The generic, PDS-supplied
TABLE object class includes an optional keyword, DESCRIPTION, that should be
required in all of the labels. The Data
Dictionary may be modified according to the instructions in the “Toolbox Data
Dictionary” chapter of the PDS Toolbox Overview and define a new object class,
called FEATURE_TABLE, which requires the presence of the keyword DESCRIPTION in
every FEATURE_TABLE object. Enter the
command:
lvtool -f example1.lbl -r newreport.rpt -d mydd.idx
to tell the
Verifier: “Validate file ‘example1.lbl’ again and write the results to file
‘newreport.rpt’, only this time use the Data Dictionary index file
‘mydd.idx’”. (The file “mydd.idx” must
be a Data Dictionary index file generated by the make_index program.) The following example shows what the report
file “newreport.rpt” will look like:
_____________________________________________________________
******************************************************************************
* *
* Planetary
Data System Validation Report *
* Label Verifier Version 1.5 *
* *
* Thu Sep 24 08:58:33 1998 *
* *
* Toolbox
Data Dictionary name: mydd.idx *
* *
* Data Dictionary Validation is ON *
* Verbose Error Reporting is OFF *
* Screen Display is OFF *
* Name Aliasing is OFF *
* Itemized Error Reporting is ON *
* Expand Structure Pointers is OFF *
* DOS Recursive Directory Search is
OFF *
* Label Validation and Pointer File
Verification *
* *
******************************************************************************
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> example1.lbl >
> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * * * The
hierarchy of objects in this label is: * * * * *
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FEATURE_TABLE
(line 8)
COLUMN - MINIMUM_LATITUDE (line 12)
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * * * The
ODL syntax errors in this file are: * * * * *
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ERROR: Line 3 - - syntax error
ERROR: Line
3 - - Expected ‘=’ after name
WARNING: Line
24 - - Label reading complete with 2
errors, 0 warnings.
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * * * The
semantic errors in this file are: * * * * *
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Keywords of ROOT (line 0):
WARNING: Line 3
- - RECORD_TYPE: Value is not a standard value
Sub-objects of TABLE (line 8):
WARNING:
Line 8 - - FEATURE_TABLE: Using PDS
GENERIC object definition.
Keywords of TABLE
(line 8):
ERROR: Line 8 - - FEATURE_TABLE: The following required keywords are
missing:
ROW_BYTES, DESCRIPTION
Sub-objects of COLUMN (line 12):
WARNING:
Line 12 - - COLUMN:
Using PDS GENERIC object definition.
Semantic validation completed with 4 errors of
warnings.
******************************************************************************
* *
* This is
the end of
the Validation Report *
* *
* Thu Sep 24 08:58:33 1998 *
* *
******************************************************************************
Report File
“myreport.rpt “
_____________________________________________________________
Note that this time
the message:
ERROR: Line 8 - - FEATURE_TABLE:
The following required keywords are
missing: ROW_BYTES, DESCRIPTION
is included in the
semantic message section of the report file.
The ODL language
checking function detects errors in the syntax of the “KEYWORD = VALUE”
statements in the label. The language
checking procedure does not have knowledge of the Data Dictionary. Therefore, it does not know what a value
should be, only how it should look. This
phase of verification cannot be turned off, since Data Dictionary errors are
sometimes a result of earlier language errors which have confused the
Verifier’s ability to correctly interpret the label. The information resulting from ODL language
checking will be written to two sections of the report. The first is labeled:
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * * * The
hierarchy of objects in this label is: * * * * *
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This section
contains an indented list showing all the objects found in the label, their
nesting level, and the line numbers associated with them. Examine the hierarchy closely, since many
errors encountered later may stem from the improper nesting of objects. If the -a (Enable Aliasing) option is used,
then the names of the objects displayed here will reflect any changes made by
the aliasing procedure. Immediately
following the tree will also be a series of messages stating which keywords, if
any, where changed by the aliasing procedure.
The next section of
the report file, labeled:
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * * * The
ODL syntax errors in this file are: * * * * *
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
will contain all
additional warnings, errors, and informational messages resulting from ODL checking. This will include syntax errors, warnings
about missing END_OBJECTs, duplicate keywords, etc. The list of messages resulting from the ODL
checking phase of verification may be found in the “Verifier Messages” chapter.
SFDU labels are not
required. The Verifier will check the
SFDU label if it is present but will not issue any message if this label is
missing. The SFDU checking phase occurs
automatically during the ODL Language Checking phase. The Verifier will perform basic checks on the
Standard Formatted Data Unit Labels it encounters in the PDS label, as long as
any such labels are located on the top line of the label file or on the line
immediately following the ODL END statement.
Messages resulting from SFDU checking will be written to the syntax
messages section of the report.
SFDU verification
is not foolproof at this time, so it is wise to check the SFDU labels by other
means. The process has been tailored to
look for the SFDU Labels expected in PDS data products, and so it will not
recognize all SFDU constructs. The
checking is designed to catch errors such as:
·
SFDU
structures not valid in the PDS context.
·
Missing
end markers.
·
Invalid
SFDU classes, versions, and delimitation types.
·
SFDU
labels out of date in the PDS context.
The list of
messages resulting from the SFDU Label checking phase of verification may be
found in the “Verifier Messages” chapter.
The Data Dictionary
(sometimes called semantic) phase of
verification detects errors in the values of keywords and the usage of objects
in the label. Unlike the ODL checking
procedure, the Data Dictionary checking procedure knows what values should look
like and how objects should be used.
This phase of verification can be turned off (see “-nd” in the “Command
Reference” chapter) when a Data Dictionary is not present, or when only ODL
messages are desired until the label is formatted correctly. The information resulting from Data
Dictionary checking will be written to the section of the report that is
labeled as follows:
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* * * * * The
semantic errors in this file are is: * * * * *
- - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The Data Dictionary
checking procedure will do the following:
·
Object
Checking
For each object in the label, the Data Dictionary will be searched for
the definition of the object’s class. If
no definition is found, then no further object checking will be performed. If a definition is found, then the Verifier
will check that all the object’s required keywords and sub-objects are present
in the label, and that all remaining keywords and sub-objects are present in
the label, and that all remaining keywords and sub-objects are at least listed
in the Data Dictionary as optional members of the object being verified.
·
Keyword
Checking
For each keyword in the label, the Verifier will search the Data
Dictionary for the definition of the keyword.
If no definition is found, the Verifier will proceed to class word
checking. If a definition is found, then
the Verifier will check the data type of the keyword’s value; the range of the
value, if it is numeric; the length of the value, if it is a character string;
the validity of the units expression associated with the value, if any; the
format of dates and time.
If applicable, the value itself will be compared to a list. The PDS Data Dictionary contains lists of
available, or “standard” values, for some keywords. The Verifier will compare the value of the
keyword against this list. Note that some
lists of standard values only contain “suggested” terms, and that standard
value lists are always expanding.
Therefore, the message “Value not a standard value” does not necessarily
signify serious errors, only that a new standard value may need to be added to
the Data Dictionary, if deemed appropriate.
The list of
messages resulting from the Data Dictionary checking phase of verification may
be found in the “Verifier Messages” chapter.
This type of
checking is only performed as a last resort when a keyword’s definition cannot
be found in the Data Dictionary. The
Verifier will determine the class (last) word of the keyword and then,
according to PDS rules for keyword nomenclature, check to see that the data
type of the value matches the data type indicated by the class word. For example, the keyword PRIMARY_BODY_NAME
has class word NAME. According to PDS
rules for data nomenclature, items with class word NAME should have data
type CHARACTER. The Verifier will therefore check to see that
the value of the keyword is of type CHARACTER.
Available class
words are listed in the Planetary Science
Data Dictionary. If a keyword does
not have one of these class words as its last component, the class word is
assumed to be VALUE, which implies a numeric data type.
The Label Verifier
does not do any of the following:
·
Correlate
the label and data files.
The Label Verifier does not read the data file associated with the
label.
·
Check
keyword values “in context.”
Although the Data Dictionary can be customized for the mission or data
set to a certain extent, the Verifier cannot automatically tell that the
MAGELLAN spacecraft, for instance, did not contain an instrument called “CAMERA
A.”
Also be aware of
the following:
·
If
verbose error reporting has been disabled, then not all messages resulting from
the Data Dictionary checks listed above will be reported.
·
The
Verifier will only check unit names and abbreviations to see if they are
recognized in order to prevent misspellings.
It does not yet have the ability to determine if the whole expression
makes sense.
·
The
line number displayed next to each syntax error message is usually only an
approximation. If the problem does not seem to be at that exact line number,
try looking back a few lines.
·
When
objects are not nested properly, many errors often result. Check the object hierarchy not other source
for an error can be found.
·
If the
label needed to be aliased and was not, this may generate errors regarding
missing or invalid sub-objects and keywords.
(see "-a Enable Aliasing” in the “Command Reference” chapter.)
·
When an
extraordinary number of syntax messages result from verification, especially if
the same message occurs over and over, check for a missing quotation mark.
·
If a
keyword has more than one value because it is a set or sequence, the values are
referenced by position in error messages:
·
ERROR:
Line X - - TARGET_NAME, Value 2. Not a
standard value.
·
The
Verifier is designed to handle labels which combine both the object name and
the class name on the same line. For
instance, if the label contains
OBJECT = ENGINEERING_TABLE
then the Verifier will search the Data Dictionary
for an object definition with class ENGINEERING_TABLE. If it does not find such a definition, it
will assume that ENGINEERING was really part of the object name, and will then
search for a definition with class TABLE.
Default: -na (no
aliasing)
The -a command line
option enables the aliasing feature of the Verifier. This option is useful when processing a label
which was developed according to another Data Dictionary, or to identify
out-of-date keywords and objects in the label.
When this option is
turned on, the Label Verifier will compare the object classes in the label with
the list of object class aliases in the Data Dictionary, and replace them with
their official names. Object classes
that were changed may be identified by examining the label hierarchy in the
report file. For example:
OBJECT = TABLE_STRUCTURE
will be replaced by
OBJECT = TABLE
if TABLE_STRUCTURE
is defined to be an alias for object class TABLE in the Data Dictionary.
The Verifier will
then compare the keywords in the label with the list of keyword aliases in the
Data Dictionary and replace them with their official names. For every name replace, a message will be
displayed in the Verifier report file.
For example:
MEDIUM = TAPE
will be replaced by
MEDIUM_TYPE = TAPE
if MEDIUM is
defined to be an alias for MEDIUM_TYPE in the Data Dictionary, and a message
warning of the replacement will appear in the report file.
After aliasing is
finished, the Verifier will continue validating the label, using the official
names instead of the aliases when it searches the Data Dictionary.
Note that only full
class names will be replaced. For
example, EDR_TABLE_STRUCTURE will not become EDR_TABLE just because
TABLE_STRUCTURE is defined as an alias for TABLE. The same is true for the keyword
replacement. Remember that the Verifier
does not change the actual label file at all.
The changes to the label remain in effect only for the duration of the
Verifier’s run.
NOTE: PDS Catalog template files, which cast PDS
Catalog information into ODL form for ingestion into the PDS Catalog, must
always be verified using the -a option.
This does not imply that the names in the actual file should be changed.
Enabling the
aliasing option significantly slows the verification process, and so the
default is -na.
Default: Validation yes and file pointer verification yes
The –b1 option disables the File Pointer Verification feature. File Pointer Verification is the feature that checks for the existence
of all pointer files. It will check
starting in the current working directory and work down the directory tree. If
–b3 is specified then the check will start in the directory specified in –b3
and work down the directory tree.
Default: Validation yes and file pointer verification yes
The –b2 option disables the Label Validation feature.
Default is the current working directory.
The path specified in this parameter will be the starting point of a
search for pointer files if either –b2 is specified or neither –b1 nor –b2 are
specified.
Default: -d
pdsdd.idx
Off switch: -nd
The -d command line
option enables Data Dictionary verification of labels and provides the name of
a Data Dictionary name to the Verifier.
If Data Dictionary verification is not enabled (i.e., -nd is speicified
on the command line), then only ODL language verification will be performed.
The default is -d
pdsdd.idx. Do not specify the -d command line options unless also providing the name of the Data
Dictionary index file to use. For
example:
lvtool -d mydd.idx -r
instructs the
Verifier to use file “mydd.idx” as the Data Dictionary index file for
verification. If the Verifier cannot
find the Data Dictionary index file, it will display a warning and try to
continue verification without it:
WARNING: Verification will proceed without a data dictionary.
If this happens,
consider aborting the verification, as the Verifier will not be able to detect
any Data Dictionary errors in the labels.
The –df command line option enables the user to give the
Data Dictionary full file instead of the index file as an input. When this is
given, the Verifier will make the index file internally by making a system call
to the make_index program. It will then use this internally created index file
to continue verifying the labels. For this reason, the make_index program
(version 1.7 or higher) must be located in the same directory as the Verifier
or the path to the program must be set in the PATH variable of the user system.
If there was an error in creating the Data Dictionary index
file, then it will display something like the following:
**************Creating
Data Dictionary index file**************
PDS Make Dictionary
Index - Version 1.7
The data dictionary
file you specified does not exist or cannot be read.
The data dictionary
file you specified does not contain any object or element de
finitions.
Data Dictionary index
file could not be created, Verification will cease
Check that the Data
Dictionary full file exists in the directory path you have specified
If this happens, make sure that the correct path to the Data
Dictionary Full file is specified and make sure that the make_index.
The default is for
the Verifier to search all subdirectories for labels to Validate. This option
will prevent the Verifier from searching all subdirectories for labels to be
validated. The search will begin in the directory specified with the
file name(s) in the -f option. The -di option only works for DOS at this time.
This option used to
be a separate program named EXPAND. Only
structure pointers will be expanded The pointer files
must be located in the same directory as the label or in a LABEL directory
somewhere on the same drive that contains the label file. This option does NOT use the path in –b3 to
look for pointer files. An expanded file will be written in the
directory the program is executed from.
The new file will have the same name as the original label file with a
new extension. The program will try to
create a file with an extension of “Xnn” where nn is a two digit number. If all of these names are in use an error
message will be issued and the file will be validated without being expanded. All files created in this manner will be
deleted if the program ends normally.
Default: None.
Off Switch: None.
Specify a label file for verification.
The -f command line
option specifies one or more files are to be verified. The Verifier will search
all subdirectories of the pathname of the file specified in this option. To disable this searching feature (in DOS),
use the -di option. (There is no -n option).
Specify just one
filename:
lvtool -f mylabel.lbl . . .
Or a wildcard
pattern:
lvtool -f /home/joeuser/*.lbl . . .
(in unix -f /home/joeuser/”*.lbl”)
Or a series of
filenames and / or wildcard patterns:
lvtool -f /hme/joeuser/*.lbl *.fmt catalog.lbl
In the last case,
all files with extension “.lbl” in the directory /home/joeuser, all files in
the current directory with the extension “.fmt”, and the file “catalog.lbl” in
the current directory will be processed by the Verifier. The directory specifications and wildcards
should be those expected by the particular operating system.
Default: No
validation list file to check.
This option allows
the user to specify a file containing a list of files to be validated. The format of the file is one file name per
line, path is assumed to be included if the file to be validated is not in the
current working directory.
Default: no file.
The file contains a
list of directories the user does not want to be checked for files to
validate. Each directory is on a
separate line, names are case sensitive.
There be up to 30 entries. Each
directory file specification be less than 100 characters in length\n");
-ivf <file
name>
Any file with an
extension in this list will not be validated.
Some types of file extensions that might be included in this list are:
c, h, txt, img. The list is a string of
file extensions that are comma separated. The program is case
sensitive. The list may not contain
blanks and can only be 200 characters in
length. Lower case characters can be
included in the string. A sample string
is:
C,H,TXT,IMG,c,h
This string of
characters tells LVTOOL not to validate any file having an extension of C (or
c), H (or h), TXT, or IMG. The string is
saved in an ASCII file with a name of the choice.
4.14
–lef <file name> Create a Log File of
all Skipped Files
Default: Do not create a log file.
Directs LVTOOL to keep a log file of all files that are skipped because
of the –ivf , -ivd, or –l3d options and specifies a file name for the log.
The default is to make sure that the file being validated is
in fact a label. Specifying this option will make the Verifier not check what
file is being validated.
Default: 300 errors
This option allows the user to specify the maximum number of errors that
LVTOOL will print to the output file. <val> is an integer value that the
user must specify if this flag is used.
Default: -na
This option disables alias substitution.
To turn on alias substitution use the –a option.
Default: Output information messages
Lvtool outputs informational messages, warning messages, and error
messages. This option turns off the
informational messages.
Default: This is the default
This option only affects the program when the –s option is used. It prevents the program from telling the user
when 20*x files have been processed, where x is a positive integer.
Example:
With the –p flag set, the user will be notified as follows:
---> 20 files complete
---> 40 files complete
…
---> All files complete
Of course, if less than 20 files are being validated, this notification
will not be seen at all.
Default: This is the default
Terminal output may be invoked with the –t option.
Default: This is the default
Verbose output may be invoked with the –v option.
Default: Display Warning Messages
Lvtool outputs informational messages, warning messages, and error
messages. This option turns off the
warning messages.
Default: Wrap the messages
Normally messages will wrap to the next line of output if the line is longer than the output device
allows. If the option is specified then
the messages will be broken into smaller pieces and each portion will be
preceded by a line number. The numbers
will start over for each message. The
numbers normally are not larger than 3.
Default: Do not show progress
This option is only affected with the –s option. Please see the –np
description for details.
Default: no report
file
The -r command line
specifies the name of the report file to which the Label Verifier writes error
messages. Either specify a report file
name using -r, or use the -t command line option to display messages to the terminal. If neither option is used, the Verifier will
display an error message and verification will stop. The file specification used should be –t or a
–r followed by a partial or full path name.
lvtool -r
/home/joeuser/label.rpt ...
or
lvtool –r
c:\pds\testarea\label.rpt…
This function was
originally a separate program named SLVTOOL.
It is now a part of LVTOOL. Selecting this option will disable the
itemized reporting that LVTOOL normally performs.
When –e is specified, it will create a temporary file (i.e.
explabel.x00) if a label to be verified needs to be expanded. The report file
makes reference to this expanded file when it prints out any errors or warnings
that are found. By default, the Verifier deletes these temporary files at the
end of verification. The –se option keeps these files in the users hard drive.
Default: -nt (no
terminal display)
The -t command line
option enables interactive display of error messages. This option is useful for observing the
progress of the Verifier, or for performing verification of only one label and
viewing the messages resulting from verification without having to examine the
report file.
When the -t option
is used, most of the messages generated by the Verifier will be printed to the
screen at the same time they are written to the report file. “Progress reports”
will be shown such as:
Now validating the keywords of object CATALOG
The format of the
messages which come to the screen is not exactly the same as their final format
in the report file. The number and type
of messages received on the screen will be determined by the value of the -v
(Enable Verbose Errors) command line option.
Not that enabling
terminal display increases the time required to validate each label and may be
inconvenient if trying to use the Verifier in background mode. For this reason the default is -nt.
Default: -v
Off switch: -nv
The -v command line
option controls the number of error messages generated by the Verifier. Error reporting in verbose mode uses all the
error messages listed in the Verifier Messages chapter of the user’s
guide. However, many of these messages
are warnings. To suppress warnings, specify -nv on the Verifier command line;
this will suppress any of the errors or warnings which have a “[V]” printed
next to them in the “Verifier Messages” chapter.
Since -nv may
suppress important error messages, the default is -v
Note that this
command line option does not affect the display of ODL Language errors found in
the label. Only Data Dictionary messages
are affected.
This chapter lists
the most common Verifier messages. For
messages not on this list, contact the PDS. (See “Getting Help” in the “Getting
Started” chapter.)
The following is a list of messages that may be generated during the
SFDU Label checking phase of Verification.
These messages will appear in the same section as the ODL syntax
messages, grouped at the top. The messages are alphabetized by the first
significant word. To locate the error message in the list, discard any WARNING,
INFO, or ERROR tag from the front of the error message before searching the
alphabetized list. Error messages which will only appear when the -v (Enable
Verbose Errors) command line option is used are marked by [V] to the left of the message.
It is impossible to explain the entire SFDU concept here. The following
messages attempt to provide an “SFDU-like” explanation for the error, followed
by a simple message stating what byte was missing or incorrect in the file to
cause the error.
In all of the following messages, the “Z wrapper” is assumed to be the first SFDU label in the file,
occupying the first 20 bytes. The “catalog SFDU” is identified by the next 20
bytes, and then encompasses all of the PDS Label up to the ODL “END” statement.
The “end marker” is assumed to be a 20
byte SFDU label following the ODL “end” statement, if any. The “data SFDU” is identified by the 20 bytes immediately
following the end marker, and it is assumed to encompass everything from there
to the end of the file.
Catalog SFDU has unknown delimitation type.
An ‘F’, ‘A’, or ‘S’ was expected in file
position X.
Only the end-of-file (F), byte count (A) and marker (S) SFDU delimitation
types are expected for the catalog class SFDU in PDS products. One of these
characters was expected in the catalog SFDU label at the top of the file.
Data SFDU has unknown delimitation type.
An ‘A’ or ‘F’ was expected X bytes after the
catalog end marker.
Only the end-of-file (F) or byte count delimitation types are expected
for the data class SFDU in PDS products.
One of these characters was expected
in the data SFDU label following the ODL “END” statement.
Data SFDU is not version 3.
A ‘3’ was expected X bytes after the catalog end marker.
Only version 3 SFDUs support marker
delimiting. Therefore, the data SFDU following the ODL “END” statement must
have a version 3 label.
First SFDU in file does not have class Z.
A
‘Z’ was expected in file position X.
Every file which contains SFDU labels must
start with a Z class SFDU.
[v] No SFDU labels were found in this file.
There apparently were no SFDU labels in the
label file. Contact the PDS if there is a question about the need for an SFDU
label in the product labels. Sometimes, this error message occurs because there
is a blank line or other character at the beginning of the file. In order for
the first SFDU label to be valid, the file must begin with the characters
“CCSD”.
Note that, if the file really did contain
SFDU labels, this problem may be the cause of other errors the Verifier reports
later on, since it can only ignore SFDU labels during the remainder of its
validation if it recognized them during SFDU label checking.
Second SFDU has unrecognized class. A
catalog SFDU was expected.
A ‘K’ or ‘I’ was expected in file position X.
In PDS products, the second 20 byte SFDU
label at the top of the file is expected to be of class catalog (K) or data
(I).
SFDU following end marker is not data class.
An ‘I’ was expected X bytes after the catalog end marker.
In PDS products, any SFDU label following
the catalog end marker (which in turn follows the ODL “END” statement) is
expected to be of class data (I).
SFDU label for catalog data does not have 0
as spare byte 1.
A ‘0’ was expected in file position X.
Apparently, version 1 SFDU labels are being used. Version 1 SFDU labels
require zeros in their 7th position. The
catalog SFDU label (the second 20 bytes at the top of the file) apparently does
not have this.
SFDU label for catalog data does not have 0 as spare byte 2.
A
'0' was expected in file position X.
Both version 1 and version 3 SFDU labels
require a zero in their 8th position. The catalog SFDU label apparently does
not have this.
SFDU label for catalog data has unrecognized version.
A ‘1’ or ‘3’ was expected in file position X.
The PDS expects only version 1 or version 3
SFDU labels.
SFDU
label for data does not have 0 as spare byte 2.
A ‘0’ was expected X bytes after the catalog end marker.
Both version 1 and version 3 SFDU labels
require a zero in their 8th position. The catalog SFDU label apparently does
not have this.
[V] SFDU label is out of date.
PDS version 1 labels used a simpler SFDU
structure. Essentially, this consisted of a single 20 byte label at the top of
the file: NJPL1IOOPDS100000001. This structure is no longer used.
SFDU label for Z wrapper does not have 0 as spare byte 1.
A
‘0’ was expected in file position X.
Apparently, version 1 SFDU labels are being used. Version 1 SFDU labels
require zeros in their 7th position. The first SFDU label (the first 20 bytes
at the top of the file) apparently does not have this.
SFDU label for Z wrapper does not have 0 as spare byte 2.
A
‘0’ was expected in file position X.
Both version 1 and version 3 SFDU labels
require a zero in their 8th position. The catalog SFDU label apparently does
not have this.
SFDU label for Z wrapper has unrecognized version.
A
‘1’ or ‘3’ was expected in file position X.
The PDS expects only version 1 or version 3
SFDU labels. The first SFDU label apparently does not indicate either of these
versions.
SFDU Z wrapper does not have a DDID of 0001.
‘0001’ was expected beginning in file position X.
The first SFDU in the file must have the
characters “0001” in bytes 9 through 12.
SFDU Z wrapper has unrecognized delimitation type.
An
‘A’ or ‘F’ was expected in file position X.
The PDS expects only the end-of-file (F) and
byte count (A) delimitation types for the first SFDU label in the file.
The SFDU structure of this file is not recognized.
The PDS expects only those SFDU constructs
detailed in the PDS Data Preparation
Workbook. The Verifier has not been able to identify the construct used.
Note that this may be a major cause of other errors the Verifier reports later
on, since it can only ignore SFDU labels during the remainder of its validation
if it recognized them during SFDU label checking.
Unable
to locate catalog end marker in file.
CCSD3REOOOOOXXXXXXXX or CCSD$$MARKERXXXXXXXX was expected
after the PDS Label.
The
catalog SFDU label at the top of the file (the second 20 byte value) indicated
that the catalog information would be delimited by marker (delimitation type
S). This implies that an end marker SFDU label should be found following the
ODL “END” statement. The Verifier has searched a large part of the file for it,
and has not found it.
The following is a list
of the messages that may be generated from the ODL language checking phase of
label verification. The messages are alphabetized by the first significant
word. To locate the error message in the list, discard the WARNING, ERROR, or
INFO tag and the “Line N” indicator from the front of the message before searching
the alphabetized list.
A parameter named KEYWORD already exists for GROUP <group1>
The
label contains a group called <group1> which contains more than one
instance of the given KEYWORD. The Verifier is reporting this, since some
software may ignore multiple definitions of keywords in PDS Labels.
NOTE: The PDS does not
recommend the use of GROUP.
A parameter named KEYWORD already exists for OBJECT <object1>
The label contains an object with class
<object1> which contains more than one instance of the given KEYWORD. The
Verifier is reporting this, since some software may ignore multiple definitions
of keywords in PDS Labels.
Bad value in assignment statement.
The Verifier encountered a “KEYWORD = <something>” but it has no idea what
<something> is. Check to make sure that <something> is a legal
value in the ODL language, i.e., an integer, real number, date, time, quoted
string, set, sequence, or unquoted string (which may contain letters, numbers,
and underscores only, and must begin with a letter).
Based integer contains illegal digits.
The label contains a non-decimal number of
the form B#NNNNNNN#, where B is the base of the number and “NNNNNNNN”
represents the digits in the given base. One of the digits is not appropriate
for the given base, e.g., in the value 2#10010031#, the digit 3 is not a legal
digit in the given base, which is 2.
BEGIN-GROUP statement found. Will be converted to GROUP.
The label contains a “BEGIN-GROUP =”
statement. This statement is part of the CCSDS Parameter Value Language (PVL),
which is a superset of ODL. The Verifier is reporting something which is not
technically an ODL statement, and that it is assuming that this is the same as
a “GROUP =‘I statement.
NOTE:
The PDS does not recommend
the use of GROUP.
BEGIN-OBJECT statement found. Will be converted to OBJECT.
The label contains a “BEGIN-OBJECT =” statement. This statement is part of the CCSDS
Parameter Value Language (PVL), which is a superset of ODL. The Verifier is
warning that it has found something which is not technically an ODL statement,
and that it is assuming that this is the same as an “OBJECT =” statement.
Characters found on line after comment ignored
The Verifier encountered a comment in the label. Comments begin with
“/‘+” and end with “*/“. The Verifier is warning that it found non-blank
characters on the line following the end of the comment (i.e., between the “*/”
and the line feed character). All such characters will be ignored. If they are
an important part of the label, they should be moved to the line following the
comment.
Day-of-year must be in range 1..365 (or 366 in a leap year).
The
Verifier has found a value it has interpreted as a date in the form YYYY-DOY,
but the value of the day-of-year (DOY) field is not between 1 and 365 (or 366
for leap years).
Day number should be in range l..<max>
The Verifier has found a value it has
interpreted as a date of the form YYYY-MM-DD, but the value of the day field is
too large for the given month.
Encountered an extra END-GROUP - Ignored.
The label contains an “END-GROUP” statement
which does not match up with a “GROUP =”
statement. There may be too many “END-GROUP” statements, or some other error
may have caused the Verifier to miss the beginning of the group in question.
NOTE: The PDS does not recommend the use of GROUP.
Encountered an extra END-OBJECT - Ignored.
The
label contains an “END-OBJECT” statement which does not match up with an
“OBJECT =” statement. There may be too many “END-OBJECT” statements, or some
other error may have caused the Verifier to miss the beginning of the object in
question.
END statement is missing.
PDS Labels require an “END” statement as the
last statement in the file.
END-GROUP = qroup2> does not match GROUP
= <group1>
The nesting of groups in the label appears
to be incorrect, because the Verifier has encountered an “END-GROUP” statement
whose name, <group2>, does not match the name of the corresponding “GROUP
=” statement, which was called <group1 >.
NOTE:
The PDS does not recommend
the use of GROUP.
END-OBJECT = <object2> does not match
OBJECT = <object1>
The nesting of objects in the label appears
to be incorrect, because the Verifier has encountered an “END-OBJECT” statement
whose name, <object2>, does not match the name of the corresponding “OBJECT
=” statement, which was called <object1>.
NOTE:
In older PDS Catalog
template files, “OBJECT-NAME =” was used rather than “OBJECT =” OBJECT-NAME” is
now considered incorrect, and will often result in errors like the one above.
Error in value list.
The label contains a set or sequence value
(lists of values enclosed by parentheses or curly braces). However, the
Verifier has found something in the list that it did not expect. Check to make
sure that the items inside the set or sequence are all legal values, and that
the set or sequence is closed properly.
Expected ‘=’ after name.
This error may be caused by many things. The Verifier encountered
something it thought was a keyword, so it wanted to see an “=” next, but it
didn’t find it. While this may be caused by an omitted “=“, this is not usually
the case. Usually, this error occurs because the Verifier got confused earlier
and should not have decided it was looking at a keyword in the first place.
This confusion is often caused by one of the following errors, which may have
occurred several lines before the line indicated in this error message:
·
A missing single or double quote mark at
the end of a string.
·
An
invalid quote mark inside a quoted string. Use the opposite type of quote marks
(single versus double) to include a quoted string within a quoted string.
·
An
unquoted value with a space or other illegal characters in it. Values that have
spaces in them must be quoted.
·
Illegal
characters in a keyword. (Only letters, numbers, and underscores are allowed).
·
A
singly quoted value that crossed a line boundary.
·
A
missing “END” statement in the label, which will cause the Verifier to read on
into any attached data.
Expected a ‘*‘, ‘/‘ or ‘**’ operator.
The label contains a unitized value, i.e.,
“KEYWORD = VALUE <units>“. The only operators allowed as part of
<units> are ‘/’ (for division), ‘*’ (for multiplication) and
‘**’ (for exponentiation).
Exponent in units expression must be
integer.
The label contains a unitized value, i.e.,
“KEYWORD = VALUE <units>“. When the exponentiation operator is used in
<units>, e.g., METERS**2, the exponent itself must be an integer.
METERS**SECONDS, for example, is illegal.
Found END-OBJECT when expecting END-GROUP.
The Verifier encountered an “END-OBJECT”
statement, but it was expecting “END-GROUP”, because the current aggregation
was begun with a “GROUP =” statement. This sometimes indicates improper nesting
in the label.
NOTE:
The PDS does not recommend
the use of GROUP.
Found END-GROUP when expecting END-OBJECT.
The Verifier encountered an “END-GROUP”
statement, but it was expecting “END-OBJECT”, because the current aggregation
was begun with a “OBJECT =‘I
statement. This sometimes indicates improper
nesting in the label.
NOTE:
The PDS does not recommend
the use of GROUP.
Hours must be in range 0..59.
The Verifier has found a value it has
interpreted to be a time in the format HH:MM:SS.SSS, but the value of the hours
field is not between 0 and 59.
Label file was found only after name was
converted to lower case.
The label file specified was found, but only
after the file name was converted to all lower case.
Label reading complete with X errors, Y
warnings.
The Verifier has completed ODL language
checking, and is reporting how many errors and warnings were found in the
label.
Low value of range is greater than high value.
The Verifier has encountered a range value
of the form X..Y, where X and Y are numbers. It is reporting that the value of
Y, which is supposed to be greater than or equal to the value of X, is too
small.
NOTE:
Range values were included
in earlier versions of the ODL language, but are no longer officially part of
the language. Ranges should now be specified as sequences with two values: (X,
Y).
Magnitude of integer number is too large.
The number has been set to the maximum
negative/positive value.
The Verifier has encountered an integer
value that is too large to be represented on the particular computer being
used.
Magnitude of real number is too large. The number has been set to the maximum
negative/positive value.
The Verifier has encountered a real value that is too large to be
represented on the particular computer being used.
Minutes must be in range 0..59.
The Verifier has found a value it has
interpreted to be a time in the format HH:MM:SS.SSS, but the value of the
minutes field is not between 0 and 59.
Missing ‘=’ operator
after GROUP.
The Verifier has encountered the word
“GROUP” but found no “=” after it. The word “GROUP” is reserved for forming
aggregations, and can not be used by itself in other contexts unless it is
quoted.
NOTE:
The PDS does not recommend
the use of GROUP.
Missing ‘=’ operator
after OBJECT.
The Verifier has encountered the word
“OBJECT” but found no “=” after it. The word “OBJECT” is reserved for forming
aggregations, and can not be used by itself in other contexts unless it is
quoted.
Month number must be in range L.12.
The Verifier has found a value it has
interpreted as a date of the form YYYY-MM-DD, but the value of the month field
is not between 1 and 12.
Row X of sequence has different number of
columns than first row.
The Verifier has encountered a nested sequence, such as “((1,2), (3,4),
(5,6))“. In this case, all the inner sequences must have the same number of
values in them. Viewing the nested sequence as an array, this means that every
row must have the same number of columns. For instance, “((1, 2), (3, 4, 5))” is illegal, because the second inside
sequence has three values, while the first only had two.
Seconds must be less than 60.
The Verifier has found a value it has
interpreted to be a time in the format HH:MM:SS.SSS, but the value of the
seconds field is not less than 60.
Sequences with
no values not allowed.
The Verifier has found an empty sequence, represented by “0”. This is
not allowed in ODL. In some rare cases, a value may have been placed in the
sequence, but the Verifier found something wrong with the value and had to skip
it, so it now thinks it saw an empty sequence. Examine any earlier errors that
occurred on or near this line.
Syntax error.
The Verifier has encountered an error it
does not understand at all, but it can recover and will continue.
Syntax error - cannot backup.
The Verifier has encountered an error it
does not understand at all, and it is unable to recover.
The number base must be in range 2..16.
The label contains a non-decimal number of
the form B#NNNNNNN#, where B is the base of the number and “NNNNNNNN”
represents the digits in the given base.
However, the base, B, must be between 2 and 16.
Time zone minutes value must be in range
0..59.
The label contains a value that has been
interpreted to be a zoned time in the format HH:MM:SS.SSS+hh:mm, but the value
of the time zone minutes (time zone minutes) field is not between 0 and 59.
Time zone hours value must be in range
-12..+12.
The label contains a value that has been
interpreted to be a zoned time in the format HH:MM:SS.SSS+hh:mm, but the value
of the time zone hours (time zone hours) field is not between -12 and 12.
Units designator must be a name.
The label contains a unitized value, i.e.,
“KEYWORD = VALUE <units>“. The units names used in <units> can only
contain letters, numbers, and underscores, and must begin with a letter. Thus,
“<METERS/SECOND>” is legal, but
“<METERS!/SECOND>” is not.
Value is assumed to be a file name -
converted to a string.
The label contains an unquoted value with a
dot, or period, in it. The period is not a legal character in an unquoted
string, unless it is a real number. However, it is a common mistake for users
to forget the quotes around values that represent file names, which often
contain the period character, so the Verifier is assuming that the value is a
file name and will pretend the value was enclosed in double quotes.
Thus, the statement
DATA-FILE-NAME = IMAGE.DAT
will be converted to
DATA-FILE-NAME = “IMAGE.DAT”
Value N/A is not a name - will appear within
single quotes.
The label contains the value “N/A” without
any quote marks surrounding it. The slash is not a legal character in. an
unquoted string. However, it is a common mistake for users to forget the quotes
around the value “N/A”, which represents “not applicable.” The Verifier is recognizing this fact and
will pretend the value was enclosed in single quotes. Thus, the statement
INSTRUMENT-MODE-ID = N/A
will be converted to
INSTRUMENT-MODE-ID
= ‘N/A’
Year is outside expected range - please
check.
The label contains a value that has been
interpreted as a date of the form YYYY-MM-DD or YYYY-DOY, but the value of the
year field looks suspicious.
‘)’ at end of sequence is missing.
The label contains a sequence value like
“(1,2,3)” but the final ‘1’ is either missing or was skipped because the
Verifier got confused after a previous error.
‘}’ is missing at end of set.
The
label contains a set value like “{1,2,3)” but the final ‘1’ is either missing
or was skipped because the Verifier got confused after a previous error.
The following is a list of Data
Dictionary. The messages are
alphabetized by the first significant word. To locate the error message in the
list, discard any WARNING, INFO, or ERROR tag from the front of the error
message, the “Line N” indicator, and any KEY-WORD or OBJECT name included at
the beginning of the message before searching the alphabetized list. Error messages which will only appear when
the -v (Enable Verbose Errors) command line option is used are marked by [VI to
the left of the message.
KEYWORD:
Character value too short. (Must be between <min> and <max>
characters in length)
According to the Data Dictionary, the value
of KEYWORD should be at least <min> characters long.
KEYWORD: Character value too long. (Must be between <min> and
<max> characters in length)
According to the Data Dictionary, the value
of KEYWORD should be at most <max> characters in length. The value may be
truncated by some PDS specific software if left as is.
KEYWORD: Inconsistent data type. (Value should be of type <data
type>)
The data type of the value of KEYWORD does
not match the data type given for KEYWORD in the Data Dictionary. For example,
there may be quotes around a numeric or date value. Sometimes this error also
occurs when KEYWORD is not in the Data Dictionary. In this case, the Verifier
determines what type the value of the keyword should be by examining its class
word and using the rules for PDS keyword nomenclature. If this type does not
match the data type of the value in the label, the error above will result. For
more information on class word validation, see “What the Verifier Does”.
INTEGER value too small. (Must be in range <min> to <max>)
According to the Data Dictionary, KEYWORD
should have an integer value greater than or equal to <min>.
KEYWORD: INTEGER value too large. (Must be in range <min> to
<max>l
According to the Data Dictionary, KEYWORD
should have an integer value less than or equal to <max>.
KEYWORD: Invalid date string
The data type of the value of KEYWORD is
supposed to be DATE (as determined from the Data Dictionary or the keyword’s
class word) but the Verifier is confused by whatever it has found. Remember
that PDS date format is YYYY-MM-DD.
KEYWORD: Invalid value for day field
The value of KEYWORD has been interpreted as
a date of the form YYYY-MM-DD, but the value of the day field is incorrect for
the given month.
KEYWORD: Invalid value for day-of-year field
The value of KEYWORD has been interpreted as
a date in the form YYYY-DOY, but the value of the day-of-year field is not
between 1 and365 (or 366 for leap years).
KEYWORD: Invalid value for
hours field
The value of KEYWORD has been interpreted to
be a time that is in the format HH:MM:SS.SSS, but the value of the hours field
is not between 0 and 59.
KEYWORD: Invalid value for time zone hours field
The value of KEYWORD has been interpreted to
be a zoned time in the format HH:MM:SS.SSS+hh:mm, but the value of the hours
(hh) field is not between -12 and 12.
KEYWORD: Invalid value for time zone minutes field
The value of KEYWORD has been interpreted to
be a zoned time in the format HH:MM:SS.SSS+hh:mm, but the value of the minutes
(mm) field is not between 0 and 59.
KEYWORD: Invalid value for minutes field
The value of KEYWORD has been interpreted to
be a time that is in the format HH:MM:SS.SSS, but the value of the minutes
field is not between 0 and 59.
KEYWORD: Invalid value for month field
The value of KEYWORD has been interpreted as
a date of the form YYYY-MM-DD, but the value of the month field is not between
1 and 12.
KEYWORD: Invalid value for seconds fraction
The
value of KEYWORD has been interpreted to be a time that is in the format
HH:MM:SS.SSS, but the value of the fractional part of the seconds field (the
portion of seconds after the decimal point) is not between 0 and 999999.
KEYWORD: Invalid value for seconds field
The value of KEYWORD has been interpreted to
be a time that is in the format HH:MM:SS.SSS, but the value of the seconds
field is not between 0 and 59.
KEYWORD: Invalid value. (Contains syntax errors)
An ODL syntax error occurred while the
Verifier was trying to read this line. Therefore, Data Dictionary checking will
not take place. Refer to the section of the report that contains ODL messages
to find out what was wrong with this line.
KEYWORD:
Matched a standard value only after blanks, underscores, and quotes were removed,
and it was converted to upper case
The value of KEYWORD matched a value on the
list of standard values for the keyword in the copy of the Data Dictionary, but
only after the Verifier removed underscores, removed extra blanks, and
converted the value to upper case.
KEYWORD:
Not an allowed keyword. (It was not found on the optional or required keywords
list)
In the Data Dictionary, KEYWORD was not
found on either the optional or required keyword list of its parent object.
OBJECT:
Not an allowed sub-object, (It was not found on the optional or required
sub-objects list)
In the Data Dictionary, OBJECT was not found on either the optional or
required sub-objects list of its parent object. Note that this error is often
caused by improper nesting of objects. Check that the section of the report
that lists ODL language messages for “END-OBJECT = <object2> does not
match OBJECT = <object1>” errors
[V] KEYWORD: Not in data dictionary
A definition for KEYWORD was not found in
the version of the PDS data dictionary. This may mean a misspelled keyword, or
that it is a new keyword. The Verifier will perform limited validation of the
keywords value based on its class word. (See “Data Dictionary Checking” for
more information on class word validation.) It is often necessary for users to
create labels that contain keywords that are not in the PDS Data Dictionary, so
this is not necessarily a serious error.
[V]
OBJECT: Not in the data dictionary. (Sub-objects and keywords will not
be validated against required and
optional lists)
No definition of OBJECT could be found in
the Data Dictionary. The Verifier will not be able to determine if all the
OBJECT’s required sub-objects and keywords are present. However, it will
attempt to validate each individual keyword inside the object.
KEYWORD: REAL value too small. (Must be in
range <min> to <max>)
According to the Data Dictionary, KEYWORD
should have a real value greater than or equal to <mm>.
KEYWORD: REAL value too large. (Must be in
range <min> to <max>)
According
to the Data Dictionary, KEYWORD should have a real value less than or equal to
<max>.
KEYWORD: Sequence or set matched a standard value only after blanks,
underscores, and quotes were removed, and it was converted to upper case
According to the Data Dictionary, the value of keyword should be a
sequence in the form “(X,Y,Z)“, or a set in the form “{X,Y,Z}“. The value given
for KEYWORD matched a value on the list of available sets or
sequences in the copy of the Data Dictionary, but only after the Verifier
removed underscores, removed extra blanks, and converted the value to upper
case.
[v] KEYWORD: Sequence or set value is not a standard value
According to the Data Dictionary, the value
of keyword should be a sequence in the form “(X,Y,Z)“, or a set in the form
“{X,Y,Z}“. The value of KEYWORD in the label is not on the list of available
sets or sequences in the copy of the Data Dictionary. While one should check
the hard copy Data Dictionary to see if there is an accepted value for the
keyword which will suit the purposes, quite often there is none. It is not
unusual for users to create labels with many new values in them.
OBJECT: The following required keywords are
missing: <keyword1>
The Data
Dictionary definition of OBJECT states that it has a required keyword called
<keyword1> but the label did not include this keyword. Note that this is
sometimes caused by object nesting problems or by misspelled keywords. Check
the section of the report that lists ODL language messages for “END-OBJECT =
<object2> does not match OBJECT = <object1>” errors.
Caveats:
·
Some
PDS labels contain a “*STRUCTURE” keyword, whose value points to another file
which contains required keywords. The Label Verifier does not currently have
the ability to search this additional file for required keywords. For
information on how to get around this, see the “Version 1.2 Release Notes”
section of this document.
·
Some
PDS objects have “conditional” keywords, i.e., keywords which are included
based on the type of data being described. The Label Verifier does not
understand these types of conditions, and so it will often report an error.
OBJECT: The following required sub-objects
are missing: <object1>
The Data Dictionary definition of OBJECT
states that it has a required sub-object called <object1> but the label
did not include this sub-object. Note that this is sometimes caused by object
nesting problems. Check the section of the report that lists ODL language
messages for “END-OBJECT = <object2> does not match OBJECT = <object1>”
errors.
Caveats:
·
Some
PDS labels contain a “^STRUCTURE” keyword, whose value points to another file
which contains required sub-object definitions. The Label Verifier does not
currently have the ability to search this additional file for required
sub-objects.
·
Some
PDS objects have “conditional” sub-objects, i.e., sub-objects which are
included based on the type of data being described. The Label Verifier does not
understand these types of conditions, and so it will often report an error.
KEYWORD: Unit <unit-name> is not
recognized.
The expression <unit-name> contains a
unit name which is not on the list of known unit names. Check to make sure the
unit name is not misspelled. However, it is sometimes necessary for label
developers to use unit names not included in the PDS Data Dictionary.
[v] OBJECT: Using PDS GENERIC object
definition
The Data Dictionary
received with the Verifier may contain some generic PDS definitions of commonly
used objects, such as IMAGE, TABLE, COLUMN, etc. The Verifier is reporting that
it has been forced to use one of these definitions, because no specific
definition has been defined. (See “Toolbox Data Dictionary” in the PDS Toolbox
Overview.)
[v] KEYWORD: Value is not a standard value
The value of KEYWORD is not on the list of
standard values for the keyword in the copy of the Data Dictionary. While one should check the hard copy Data
Dictionary to see if there is an accepted value for the keyword which is
acceptable, quite often there is none. It is not unusual for users to create
labels with many new values in them.
Added the capability to search for pointers to files for
these additional
objects: HEADER, QUBE, IMAGE, SPREADSHEET, SERIES, SPECTRUM,
and PALETTE.
Made a fix to correctly print the validation results to the
user screen when
the -t flag is used. LVTOOL was originally crashing during
label validation
with the -t flag set.
Made a bug fix to correctly handle local data dictionary
keywords of 61
characters long (30 for the namespace ID, 30 for the element
name, and 1 for
the colon that separates the two). Previous version assumed
a 60 character max
length for local keywords.
Because of changes made to the ODLC library, if during
validation, an overflow
occurs while obtaining a keyword integer value, LVTOOL will
tell the user what
value it will be set to. Before it just said, "will set
to the maximum postive
value" without telling the user what that max value
was.
Made a fix to always print out to the report, the hierarchy
of objects in a
label, regardless of whether or not the -a flag was set.
Previous versions
only printed out the hierarchy when the -a flag was set.
Made a change to the LVTOOL reporting system to only mention
in the report
that we are expanding STRUCTURE pointer files IF there was a
STRUCTURE pointer
file found in the first place.
Example:
Before we would have,
------------------------------------------------------------------------
Expanding ^STRUCTURE pointers in c:\TEST_PRODUCTS\TABLES\3277281A.LBL
STUCTURE keyword not found, label was not
expanded
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
<
#
c:\TEST_PRODUCTS\TABLES\3277281A.LBL
<
>
<
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Now it would simply say,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> <
#
c:\TEST_PRODUCTS\TABLES\3277281a.lbl <
> <
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
with no mention of attempting to expand the label file. This
avoids confusion
of thinking that something was wrong with the label.
KNOWN ISSUES
- The
aliasing feature may produce "funny" results. This has been most
recently reported when a label contains the
keyword AXIS_NAME.
- There
is a known anomaly regarding LVTOOL's ability to handle sequences. When a
label contains a sequence of standard keyword values, LVTOOL will complain
about those values not being part of the standard value set when they
really are.
Example:
If you have in a
label,
SUFFIX_NAME = ("EMISSION ANGLE",
"INCIDENCE ANGLE")
LVTOOL will print
out a message like so,
1 WARNING: Line 73 -- SUFFIX_NAME: Sequence or set value is not a
2 standard value:
EMISSION ANGLE INCIDENCE ANGLE
when those values
are part of the standard value set in the data dictionary.
Please ignore this
message for the time being until a proper solution can be
worked out.
- For
Solaris and Linux systems, LVTOOL does not know how to interpret
relative path names correctly and will
not be able to properly search for
STRUCTURE pointer files.
i.e. If LVTOOL is
executed down a directory tree like so,
[/home/dschultz/pds_toolbox/bin/]> ./lvtool -f label.lbl -e -r
report.txt
and if label.lbl contains
a STRUCTURE pointer to a .fmt file and this .fmt
file is located in
the LABEL directory located at a higher level, then LVTOOL
will not go up the
tree and find the pointer file. This will get fixed for
the next version.
The workaround is to specify the full path to the label
file.
PORTABILITY ISSUES
When an integer is either too large or too small to handle,
LVTOOL will not
always give this warning message out to the report depending
on what platform
LVTOOL is being executed on.
i.e. WARNING: Line 25 -- Magnitude of integer number is too
large. The number
has been set to the maximum positive value of
2147483647.
During regression testing, this message would be seen on a
report in linux and
not on a report in solaris or windows when LVTOOL was run
with the same label
on all 3 platforms.
LVTOOL now gives the user the option to input either the
pdsdd.idx file or the pdsdd.full file. If the full file is desired, you will
need to use the -df option instead of the -d option like so,
lvtool -df
c:\data\pdsdd.full…
LVTOOL uses the MAKE INDEX program (version 1.7 or higher)
to create the data dictionary index file in this case. Because of this
dependency, you must make sure that the MAKE INDEX program is in the same
directory as the LVTOOL program or that the PATH environment is set properly to
where the MAKE INDEX program can be located.
Other changes include:
- Added
a new option, -se, that will save the temporary files that lvtool creates
onto hard drive when it needs to
expand a label with STRUCTURE pointers
- lvtool
now checks, by default, if a file is a label or not. Users can turn this
feature off by specifying "-nol3d" on the command-line.
Historically, users had to turn this feature ON with the "-l3d"
option.
- Fixed
a memory leak that occurs when label files are expanded and a temporary
file is created
- Fixed
a bug to prevent program crash when a keyword value is longer than 250
characters
- Made
a bug fix to correctly exclude a file from being validated if it is in one
of the user-specified directories to be excluded from processing.
- Made
change to not check for an END statement at the end of a format file. END
statements are not required in format files.
- Fixed
a bug in the code where lvtool couldn't find pointers to files for labels
validated from a CD were expanded.
- lvtool
will now properly look for pointer files in a PDS volume if a pointer is
encountered in a file. It will recursively search up a directory tree and
find the appropriate direcotries. The PDS standards state which
directories these pointers to files should be located in a PDS volume. For
example, DESCRIPTION pointer keywords would be found in the DOCUMENTS
directory.
Fixed a small bug where in Solaris and Linux, when a file is
inputted as "../file_name.lbl" and the user wants to expand the file
with the "-e" option, lvtool would create a temp file called
".x00" instead of "<file_name>.x00".
The functionality
of the Label Verifier has changed in the following ways since the previous
release (1.2):
·
A
summary report may be generated instead of a detailed report (previously
SLVTOOL).
·
^STRUCTURE
pointers can be expanded if desired (previously EXPAND).
·
Files
of a specified extension can be passed over.
·
DOS can
now search directory trees.
·
DOS can
start directory tree searches at a specified directory
Pointers can be
validated. The files they point to will
be searched for on. If they are not
found an error message is generated. An
itemized list is generated for all occurrences of these files.
The Label Verifier
has the following known bugs:
·
A
keyword longer than 35 characters will cause the program to terminate in DOS.
·
Specifying
-v when specifying -nd, or if the data dictionary is not found will cause the
program to terminate.
TBD
TBD
