Planetary Data System

Label Verifier (LVTOOL) User’s Guide (UG)

 

 

 

 

 

 

Draft Release Version 1

February 22, 2006

 

 

 

Prepared by:  Michael Cayanan/Dale Schultz

 

Document Custodian:  Valerie Henderson                                          

 

 

 

 

 

Approved by:

 

 

________________________________________________

Dan Crichton

PDS Project Manager

 

 

 

 

 

 

 

 

 

 

 

 

 


Jet Propulsion Laboratory

Pasadena, California

 

 

 

 


CHANGE LOG

                       

 

 

Revision

Date

Description

Author

Start Draft

April, 2003

Initial draft

D. Schultz

Release 1

June 30, 2003

Draft Release 1 – Edited all

V. Henderson

 

Sept 10, 2004

Updated document

Michael Cayanan

 

August 2005

Update document

Michael Cayanan

 

February 2006

Update hyperlinks and flag descriptions and installation instructions. Omitted text description that we do not check for pointers to files.

Michael Cayanan

 

 

 

 

 

 

 

 

 

 


Table of Contents

1.0       Introduction.. 1

1.1       Software Identification.. 1

1.2       Purpose.. 1

1.3       Document Scope.. 1

1.4       Audience.. 1

1.5       Overview... 2

1.6       Applicable Documents.. 2

2.0       Getting Started.. 4

2.1       PDS Label Verifier Setup Process.. 4

2.2       Installing the Verifier.. 4

2.3       Starting the Verifier.. 5

2.4       Getting Help.. 6

2.5       Using the Verifier – Examples.. 6

2.5.1                 Verifying One File. 6

2.5.2                 Verifying a Group of Files. 10

2.5.3                 Using a New Data Dictionary. 10

3.0       What the verifier does.. 13

3.1       ODL Language Checking.. 13

3.2       SFDU Checking.. 13

3.3       Data Dictionary Checking.. 14

3.4       Class Word Checking.. 15

3.5       Caveats and Limitations.. 15

4.0       Command Reference.. 18

4.1       -a  Enable Aliasing.. 18

4.2       –b1  Validation YES, File Pointer Verification No.. 19

4.3       –b2 Validation No, File Pointer Verification Yes.. 19

4.4       –b3 <path>  Start Search Path For File Pointer Verification   19

4.5       –d   Enable Data Dictionary Index File.. 19

4.6       –df Enable Data Dictionary Full File.. 20

4.7       –di Do not search subdirectories for label files to be validated. 20

4.8       –e Expand ^STRUCTURE files.. 21

4.9       –f Specify Label Files(s) 21

4.10    –fin <file name> Specifies name of file containing list of file names to validate.. 22

4.11    –ivd <file name> Specifies a file containing directories to skip   22

4.12    –ivf <file name> Specifies name of file containing a list of file extensions to skip   22

4.13    –I Specifies itemized error reports, this is the default. 22

4.14    –lef   <file name> Create a Log File of all Skipped Files.. 22

4.15    –nol3d Validate only files that contain a level 3 label. 22

4.16    –max <value>  The Maximum Number of Errors to List. 23

4.17    –na Disable Aliasing.. 23

4.18    –ninfo Disable Output of Information Messages.. 23

4.19    –np Disable Progress Reporting.. 23

4.20    –nt Disable Terminal Output. 23

4.21    –nv Disable Verbose Output. 24

4.22    –nwarn Disable Warning Messages.. 24

4.23    –nw Do Not Wrap Informational, Warning, or Error Messages   24

4.24    –p Show Progress Messages.. 24

4.25    –r Specify Report File Name.. 24

4.26    –s Specifies summary error reports.. 25

4.27    –se Save Files That Were Expanded.. 25

4.28    –t Enable Terminal Display. 25

4.29    –v Enable Verbose Errors.. 25

5.0       verifier Messages.. 27

5.1       SFDU Error Messages.. 27

5.2       ODL Language Messages.. 30

5.3       Data Dictionary Messages.. 38

Appendices.. 44

Appendix A - Release Notes.. 44

Version 2.19 Release Notes.. 44

Version 2.18 Release notes.. 46

Version 2.15 Release notes.. 47

Version 2.12 Release notes.. 47

Version 2.12 Known Bugs.. 48

Appendix B - Acronyms.. 48

Appendix C- Glossary.. 48

 

 

 

 

 

 


1.0           Introduction

 

1.1             Software Identification

 

Project name:                        Planetary Data System (PDS)

Program set name:              PDS Label Verifier

Abbreviation:                         lvtool

Version number:                    2.19

Platforms supported:            Windows, Unix, Linux

 

 

1.2             Purpose

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).

 

 

1.3             Document Scope  

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.

 

1.4             Audience

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.

 

 

1.5             Overview

 

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).

 

 

1.6             Applicable Documents

 

 

·        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)


 

2.0           Getting Started

2.1             PDS Label Verifier Setup Process

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.

 

2.2             Installing the Verifier

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.

 

2.3             Starting the Verifier

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.)

 

 

2.4             Getting Help

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

 

 

2.5             Using the Verifier – Examples

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.

 

2.5.1       Verifying One File

 

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.

 

 

2.5.2       Verifying a Group of Files

 

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”.

 

 

2.5.3       Using a New Data Dictionary

 

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.

 


 

3.0           What the verifier does

 

3.1             ODL Language Checking

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.

 

3.2             SFDU Checking

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.

 

3.3             Data Dictionary Checking

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.

 

3.4             Class Word Checking

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.

 

3.5             Caveats and Limitations

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.

 

 


 

4.0           Command Reference

4.1             -a  Enable Aliasing

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.

 

4.2             –b1  Validation YES, File Pointer Verification No

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.

 

4.3             –b2 Validation No, File Pointer Verification Yes

 

Default: Validation yes and file pointer verification yes

 

The –b2 option disables the Label Validation feature.

 

 

4.4             –b3 <path>   Start Search Path For File Pointer Verification

 

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.

 

4.5             –d   Enable Data Dictionary Index File

 

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.

 

4.6             –df Enable Data Dictionary Full File

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.

 

4.7             –di Do not search subdirectories for label files to be validated.

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.

 

4.8             –e Expand ^STRUCTURE files

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.

 

4.9             –f Specify Label Files(s)

 

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.

 

4.10         –fin <file name> Specifies name of file containing list of file names to validate

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.

 

4.11         –ivd <file name> Specifies a file containing directories to skip

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");

 

4.12         –ivf <file name> Specifies name of file containing a list of file extensions to skip

-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.13         –I Specifies itemized error reports, this is the default

 

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.

 

4.15         –nol3d Validate only files that contain a level 3 label

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.

 

4.16         –max <value>  The Maximum Number of Errors to List

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.

 

4.17         –na Disable Aliasing

Default: -na

 

This option disables alias substitution.  To turn on alias substitution use the –a option.

 

4.18         –ninfo Disable Output of Information Messages

Default: Output information messages

 

Lvtool outputs informational messages, warning messages, and error messages.  This option turns off the informational messages.

 

4.19         –np Disable Progress Reporting

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.

 

4.20         –nt Disable Terminal Output

Default: This is the default

 

Terminal output may be invoked with the –t option.

 

4.21         –nv Disable Verbose Output

Default: This is the default

 

Verbose output may be invoked with the –v option.

 

4.22         –nwarn Disable Warning Messages

Default: Display  Warning Messages

 

Lvtool outputs informational messages, warning messages, and error messages.  This option turns off the warning messages.

 

4.23         –nw Do Not Wrap Informational, Warning, or Error 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.    

 

4.24         –p Show Progress Messages

Default: Do not show progress

 

This option is only affected with the –s option. Please see the –np description for details.

 

4.25         –r Specify Report File Name

 

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…

 

4.26         –s Specifies summary error reports

 

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.

 

4.27         –se Save Files That Were Expanded

 

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.

 

4.28         –t Enable Terminal Display

 

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.

 

4.29         –v Enable Verbose Errors

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.

 

 

 


 

5.0           verifier Messages

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.)

 

5.1             SFDU Error Messages

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.

 

 

5.2             ODL Language Messages

 

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.

 

5.3             Data Dictionary Messages

 

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.

 

 


 

Appendices

Appendix A - Release Notes

Version 2.19 Release Notes

 

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.

 

Version 2.18 Release notes

 

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.

 

Version 2.15 Release notes

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".

 

Version 2.12 Release notes

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.

 

Version 2.12 Known Bugs

 

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.

 

Appendix B - Acronyms

TBD

 

Appendix C- Glossary

TBD