LAMPS SOFTWARE ENVIRONMENT GUIDE
Laser-Scan Ltd.
Laser-Scan Automated Map Production System
LAMPS Software Environment Guide
Issue 2.4 - 31-Mar-1992
Copyright (C) $$year Laser-Scan Ltd
Science Park, Milton Road, Cambridge, England CB4 4FY tel: (0223) 420414
Document "LAMPS Software Environment Guide"
Document Issue 0.1 Paul Hardy 16-May-1986
Document Issue 1.0 Paul Hardy 22-Jul-1986
Document Issue 1.2 Paul Hardy 19-Dec-1986
Document Issue 2.0 Paul Hardy 27-Jul-1987
Document Issue 2.1 Paul Hardy 14-Jan-1988
Document Issue 2.2 Paul Hardy 05-Aug-1988
Document Issue 2.3 Paul Hardy 03-Aug-1990
Document Issue 2.4 Paul Hardy 31-Mar-1992
--------------------------------------------------------------------------------
PREFACE
--------------------------------------------------------------------------------
Intended audience
This manual is intended for any user of the *Laser-Scan *Automated *Map
*Production *System (LAMPS), and Laser-Scan *Geographic *Information *System
(GIS) software who requires an overview of the system, and an
understanding of the software environment.
In particular it is for the system manager who is responsible for software
updates and the continued smooth running of the system. The guide will describe
the components of the system, their usual locations in the filing system, and
the environment necessary to run the programs.
It is assumed that the user is already familiar with general use of a
DEC VAX series computer and of the VMS operating system.
More details on VMS are available in the DEC VAX/VMS reference manuals.
Readers are also referred to associated Laser-Scan references. See
below for a list of associated manuals.
--------------------------------------------------------------------------------
Structure of this document
This document is composed of 4 major sections.
-
Firstly an overview of hardware and software components
-
Secondly a description of the general software environment
-
Thirdly a section on LAMPS system management.
-
Fourthly a description of required environment by package.
--------------------------------------------------------------------------------
Associated documents
Documentation for Laser-Scan LAMPS software is distributed in with each
software package. The following documentation indicate manuals which may be
particularly relevant to maintenance of
the software environment for LAMPS. Latest versions of these documents are
obtainable from Laser-Scan.
Package MAPPING
LSL LAMPS Software Installation Guide
IFF User Guide
IFFLIB Reference manual
FRT User Guide
FRTLIB Programmer Reference Manual
SRINORM User Guide
MAPPING Software Product Specification
Package IMP
IMP User Guide
IMP Reference Manual
IMP Software Product Specification
Package LITES2
LITES2 Reference Manual
LITES2 User's Guide
LITES2 Software Product Specification
LITES2 Workstation Guides for particular displays
Package PLOTTING
FPP Fast Plotting Program Reference Manual
FPP Software Product Specification
FPP User Guides for particular plotters
Optional Packages
See package documentation
Device Support Packages
The Laser-Scan HRD-1/Lasertrak Reference Manual
VAX LDLIB and HR Driver Technical Documentation and System Manager's Guide
--------------------------------------------------------------------------------
Conventions used in this document
--------------------------------------------------------------------------------
Convention Meaning
--------------------------------------------------------------------------------
<CR> The user should press the carriage return key on the
terminal.
--------------------------------------------------------------------------------
'colour' Single quotes imply that the quoted object is to be
substituted by a particular occurrence of the object,
eg BLUE or RED for 'colour'.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
INTRODUCTION
Laser-Scan LAMPS is a combination of hardware and software components which
together allow use of modern high performance DEC VAX minicomputers and
worksystems for digital cartography and automated map production.
Laser-Scan GIS software (HORIZON for Environmental systems and METROPOLIS
for land information), uses the same LAMPS components with some extra software
(XGIS) to provide facilities for geographic query and update. In the
discussion which follows, both map production and GIS systems will often be
referred to collectively as "LAMPS".
LAMPS and GIS systems may vary in size considerably. At the bottom end, there
may be just a single editing workstation, running the "Basic LAMPS" software
packages. At the top end it may be a a large system using multiple networked or
clustered computers running many automated data capture, manual data capture,
editing, processing, check plotting, conversion, update, final plotting, and
query tasks on a variety of workstations and terminals.
Laser-Scan may provide a complete hardware/software turnkey system, together
with continuing full system support, including VMS support. Alternatively, in
some cases Laser-Scan provide just software to complement existing customer
hardware.
In either case there will usually be someone on-site with responsibility
for the smooth running of the LAMPS system, and the information in the rest
of this document should help him or her achieve an overview of the system.
--------------------------------------------------------------------------------
HARDWARE COMPONENTS
The central hardware component of a LAMPS system will be one or more
DEC VAX or MicroVAX series computers, with associated disk, magtape,
communications and terminal peripherals.
The other hardware components of the system will depend on the software options
selected, but may include one or more of the following.
-
A Lasertrak is a vector scanning digitiser which can also be used
as a large screen display and 105mm diazo microfilm plotter. A Lasertrak is
connected
to the host computer via the UNIBUS, which is a fast parallel interface.
There is an LSL-supplied device driver (HRDRIVER) for this device.
In the case of a MicroVAX, a QBUS to UNIBUS converter is required.
The Lasertrak console includes a colour graphics display (normally a Tektronix
4105) for use
as both a VMS terminal, and closeup graphics display screen. This terminal is
connected via a serial line to the host computer.
-
A FASTRAK is an earlier version of the Lasertrak, having a different console
incorporating a monochrome graphics storage tube display (Tektronix 4010)
in place of the 4105.
-
An HRD-1 is a simplified FASTRAK or Lasertrak without the scanning
capabilities.
-
A Laserplot is a microprocessor-controlled laser plotter designed for
cartographic quality vector output on approximately A3 size film.
It is connected to the host computer via a serial line.
-
A Laser-Scan Digitising Table is a manual digitising table with a 16 button
cursor and serial line controller. Currently this is likely to be an Altek
table with either an AC90 or AC40 controller. It is connected to the host
computer or workstation controller via a serial line. Other manufacturer's
tables may be acceptable, possibly with reduced functionality.
-
A Laser-Scan Vector Graphics display can be one of the following types:
-
A Laser-Scan GKS Segment Storage Display is a high resolution
device capable of storage and display of vector (lines and symbols), text, and
fill area data.
A typical example would be a
Sigmex 6164 which is a 1000 line colour display, and a member of the Sigmex
6000 series of GKS compatible graphics devices.
It has a large internal segment store and can hence do local zoom and pan.
It is connected to the host computer via a serial line.
-
A Laser-Scan Basic Vector Display is a medium to high resolution
device capable of display of vector (lines, symbols and text) data, and having a
limited refresh capability.
A typical example would be a
Tektronix 4014 DVST.
It is connected to the host computer via a serial line.
-
A Laser-Scan Raster Graphics Display is a high resolution (1000+ line)
device capable of display of both vector (line) and raster (pixel) data.
A typical example would be a Sigmex ARGS 7000 graphics system,
which is connected to the host computer via a DR11-like 16bit parallel interface
on the UNIBUS, and requires an LSL-supplied device driver (IDDRIVER).
-
A Laser-Scan MUART or WOSP workstation is a general
purpose graphical editing station
consisting of a Laser-Scan Vector Graphics display, possibly a small menu
tablet, an Altek digitising table, and possibly a
DEC alphanumeric VDU terminal.
These devices are connected to a Laser-Scan MUART (TMU)
intelligent graphics controller/multiplexer, which communicates with the
host computer via a single serial line.
-
A Laser-Scan Windowing Graphics Workstation is a high resolution (1000 line)
device capable of display of both vector (line) and raster (pixel) data in
multiple windows on a closely coupled bitmapped screen. The workstation has
integral VAX processor, memory, disk, magtape, mouse etc.
A typical example would be a DEC VAXstation 4000.
It provides the functionality of the Laser-Scan Vector Graphics display,
and some of the functionality of a Laser-Scan Raster Graphics display, together
with a responsive interaction environment.
--------------------------------------------------------------------------------
SOFTWARE COMPONENTS
A LAMPS system consists of both hardware and software components. Software
components are grouped by function into packages, which may be either
single programs or collections of individual utilities. For a description
of the contents of each package, and its hardware and software requirements,
please refer to its Software Product Specification (SPS), available separately
from Laser-Scan.
The following is a list of major software components with their major hardware
dependencies.
--------------------------------------------------------------------------------
LAMPS KERNEL PACKAGES
-
The Laser-Scan system software support package (LSLSYSTEM) is required by
all LSL software components. It includes environment setup command files,
supplementary system utilities, and utility programs needed by more than
one package.
-
The Laser-Scan Mapping Kernel Software package (MAPPING) is required by all
other LAMPS software components. It includes the IFF file interface library
(IFFLIB), the Feature Representation library (FRTLIB), as well as
various central LAMPS initialisation and control procedures.
-
The IFF file format is central to all LAMPS components. All LAMPS
software reads and writes digital cartographic information as IFF files.
The IFFLIB library is supplied to allow user-written programs to
access IFF files.
-
The FRT (Feature Representation Table) lookup system is used by several
LAMPS components. Any LAMPS program requiring to know the graphic representation
of an IFF feature will use FRTLIB to access information about feature type,
colour, shape, size, etc.
The FRTLIB library is supplied to allow user-written programs to
access FRT files.
-
Laser-Scan maintenance utilities package (LSLMAINT) includes various
utilities and libraries needed by LSL for maintenance and development of
software on-site. This package is not present in most turnkey LAMPS systems,
and will not normally be used by customers.
--------------------------------------------------------------------------------
LAMPS BASIC PACKAGES
-
The IFF Map Processing package (IMP) is a central component, and allows
creation, sorting, clipping, transformation, selection, combination, listing,
etc of IFF files.
-
The cartographic editor and display package (LITES2) will usually be part of
any system. This allows map display, manual interactive digitising, correction
of operator errors following automated or blind digitising, and map update.
LITES2 is available to run on a variety of graphics hardware, using various
interaction peripherals. See the LITES2 Software Product Specification for
details of suported hardware configurations.
-
The fast plotter program FPP package (PLOTTING) will usually be part of a
LAMPS system to allow plotting of IFF data to cartographic quality. FPP is
available to run on a variety of graphics hardware. See the Software Product
Specification for details of suported hardware configurations.
--------------------------------------------------------------------------------
LAMPS OPTIONAL PACKAGES
-
The vector scanning and line following digitiser package (VTRAK) is an
optional component giving the capability of semi-automated capture of
cartographic data from raster-scanned documents at speed.
It requires a Windowing Graphics Workstation, and
an LSL-approved raster scanner, or offline source of raster
scanned data.
-
The vector scanning and line following digitiser package (LASERAID) is an
optional component
giving the capability of semi-automated capture of cartographic data at speed.
It requires a Laser-Scan Lasertrak or FASTRAK digitiser, and has been largely
superceded by the VTRAK package above.
This package now includes the structured data (link-node) digitising
capabilities which were formerly a separate package (JUNCTIONS). See also
the STRUCTURE package below.
-
The blind table digitising system package (DIGSYS) is an optional component
for bulk entry of manually digitised geographic data. It requires use of
Laser-Scan manual digitising tables with VDU screens, and a single dedicated
hardcopy control terminal.
-
The IFF data conversion package (CONVERT) is an optional component which
allows conversion of IFF data to and from a variety of standard external
formats. Note that this package is divided into modules for different
formats, and only relevant modules need be supplied.
-
The Flowline Control package (FLOWLINE) is an optional component which
allows control of the tasks and data involved in managing a production flowline.
It uses the DEC Rdb relational database to store flowline and status
information.
-
LSL-supplied customer-specific software (CUSTOMER) is often supplied as an
integral part of a LAMPS system, eg to allow transfer of map data to a private
external databank.
-
The Structured IFF data package (STRUCTURE) is an optional component which
allows the creation and manipulation of link-node structured (junction) IFF
data files. The ILINK program which is a major element of this package
will do extensive geometric "tidies" on vector data, eg extension, truncation,
common alignment, etc.
-
The Polygon IFF data package (POLYGONS) is an optional component which
allows the creation and manipulation of Polygon IFF files. The STRUCTURE
package is needed as a prerequisite.
--------------------------------------------------------------------------------
LAMPS MATRIX PROCESSING PACKAGES
-
The matrix data kernel package (MATRIX) is required by all
LAMPS matrix data handling software components below.
It includes the DTI file interface library, and basic matrix viewing and
manipulation utilities.
-
The terrain model creation package (DTMCREATE) is an optional component
which allows generation of Digital Terrain Model matrices (DTMs) from vector
topographic data (eg contours and spot heights). It includes the Panacea
surface modeller.
-
The DTM preparation package (DTMPREPARE) is an optional extension to package
DTMCREATE which allows checking and analysis of vector data to be used as input
to terrain model generation. An example is the automated calculation of heights
of river networks by intersection of rivers with contours.
-
The DTM conversion package (DTMCONVERT) is an optional component which
allows conversion of DTI matrix data to and from a variety of standard external
formats. Note that this package is divided into modules for different
formats, and only relevant modules need be supplied.
-
The terrain validation and exploitation package (TVES) is an optional
component which allows display, analysis, and exploitation
of DTM matrix data.
It requires use of a Laser-Scan Raster Graphics display eg Sigmex ARGS 7000.
-
The Image processing package (IMAGEPROCESS) is an optional component which
provides conversion to DTI file of remotely sensed (eg satellite imagery)
data from external formats
--------------------------------------------------------------------------------
LAMPS GIS PACKAGES
-
The X-windows GIS package (XGIS) is needed as the basis of the GIS application
packages METROPOLIS (for land information) and HORIZON (for environmental
information).
It requires a Laser-Scan Windowing Graphics workstation with DECwindows
and OSF/MOTIF.
-
The land information GIS (METROPOLIS) is a Geographic Information System
aimed at the storage, retrieval, and analysis of information on human land
usage. It is particularly relevent to local authorities, utilities, etc.
It requires the XGIS support package.
-
The Environmental GIS (HORIZON) is a Geographic Information System aimed at
the storage, retrieval, and analysis of information on the environment. It has
particular strengths in handling terrain and polygon information. It requires
the XGIS support package.
--------------------------------------------------------------------------------
LAMPS DEVICE SUPPORT PACKAGES
-
The raster scanner data conversion package (SCANCONVERT) is needed if the
VTRAK vectorisation package is in use, or if the Raster Backdrop option
is purchased for the LITES2 package.
-
The HRD device support package (HRD) is needed
if the configuration includes a Laser-Scan HRD-1 display or a
Lasertrak/FASTRAK digitiser.
These devices can be used by the LASERAID and LITES2 packages.
If the HRD option for high quality diazo film output is required, the HIACC
package is needed to supply calibration utilities.
-
The Laserplot device support package (LASERPLOT) is needed
if the configuration includes a Laser-Scan Laserplot plotter.
This device can be used for FPP plotting.
-
The High Accuracy calibration support package (HIACC) is used when
either a Lasertrak or Laserplot is used for cartographic quality plotting.
-
The ARGS device support package (ARGS) is needed
if the configuration includes a Sigmex ARGS 7000 series graphics display.
This device can be used by LITES2, DTMCREATE, TVES.
-
The Sigmex 6000 device support package (SIGMA) is needed
if the configuration includes a Sigmex 6000 series graphics display.
This device can be used by LITES2, DTMCREATE, and TVES
-
The multi-UART workstation device support package (MUART) is needed
if the configuration includes a Laser-Scan multi-UART workstation.
This device can be used by LITES2, DTMCREATE, and TVES
-
The digitising table device support package (TABLE) is needed
if the configuration includes a manual digitising table. This will currently
normally be an Altek table.
Other manufacturer's tables may be acceptable to some programs, possibly with
reduced functionality. Contact Laser-Scan for further information.
This device can be used by LITES2, DIGSYS, TVES, DTMCREATE.
--------------------------------------------------------------------------------
LAMPS SUPERCEDED PACKAGES
-
The IFF data manipulation package (DAMP) is a predecessor to IMP, and is now
obsolescent as all its major functionality is replaced by IMP. It allows
limited sorting, clipping, transformation, selection, combination, listing, etc
of IFF files. In general its required environment may be assumed to be
the same as that for package IMP.
-
The LITES1 editor package (LITES) is a predecessor to LITES2, with reduced
functionality and restricted graphics device support.
Variants of this program were known as SOLADI, SOLMPS, SOLOS, IGES, IGEMPS
and IGEOS. It is not described further in this document.
Please refer to the LITES SPS, User Guide and Reference Manual for further
details.
-
The matrix data processing package (DTMPROCESS) was an optional component
which allowed manipulation and processing of Digital Terrain Model matrices
(DTMs) as produced by package DTMCREATE. It is now obsolete, and its
functionality is now provided by elements of the other matrix packages,
particularly MATRIX and TVES.
--------------------------------------------------------------------------------
SYSTEM ENVIRONMENT
--------------------------------------------------------------------------------
LOGICAL NAMES
Most programs read and/or write disk data files and terminals during their
operation.
For reasons of simplicity, flexibility, and economy, all Laser-Scan
programs carry out these accesses via "logical names" rather than via
embedded device names, or
default or fixed directories. This means that the user need
not be concerned with current default directory etc, and there is no
need to copy or duplicate files. These logical names usually have the
form LSL$name or LSL_name to avoid conflict with DEC or other manufacturer's
products.
--------------------------------------------------------------------------------
FILES AND DIRECTORIES
The files involved in the LAMPS system can be divided firstly into
program files and data files.
Program files are supplied by Laser-Scan, while most data files are transient.
A series of logical names is provided by Laser-Scan to allow easy access to
LAMPS files and directories. These are described below.
There have been a variety of directory layouts on Laser-Scan systems in the
past, but all future LAMPS systems should use the following conventions. All
Laser-Scan files should now be contained on five (occasionally six) directory
trees, as follows:
-
LSL$PUBLIC_ROOT contains all LSL-distributed software.
This tree is usually [LSLPUBLIC...], and contains the definitive
versions of LSL-issued software. It may be write-protected on site,
and need only be written to to install new releases of software.
Example directories on it might include:
LSL$PUBLIC_ROOT:[LITES2.EXE] executable images for LITES2
LSL$PUBLIC_ROOT:[LITES2.HELP] help files for LITES2
LSL$PUBLIC_ROOT:[LITES2.COM] command files for LITES2
LSL$PUBLIC_ROOT:[IMP.EXE] executable images for IMP
-
LSL$SITE_ROOT contains all site-dependent files.
This tree is usually [LSLSITE...], and contains copies of standard
files which need to change from site to site. This includes static data files,
lookup files, and possible tailored copies of command procedures from the
public tree. Example directories on it might include:
LSL$SITE_ROOT:[LSL.COM] tailored command procedures
LSL$SITE_ROOT:[LITES2.CMD] .LCM command files for LITES2
LSL$SITE_ROOT:[HRD.LOOKUP] HRD system constants (LDSY21) files
-
LSL$DATA_ROOT contains user data files.
This tree is usually [LSLDATA...], and contains user data files such as
IFF files and DTI files.
Example directories on it might include:
LSL$DATA_ROOT:[LSL.IFF] IFF map data files
LSL$DATA_ROOT:[LSL.DTI] DTI matrix data files
-
LSL$USER_ROOT contains all user home directories .
This tree is usually [LSLUSER...], and contains home directories and
personal files for LAMPS users.
Example directories on it might include:
LSL$USER_ROOT:[LSLUSER] home directory for template LAMPS user
On sites which have pre-existing conventions
for user home directories, this tree may be empty.
-
LSL$LOCAL_ROOT contains all node-specific files.
This tree is usually [LSLLOCAL...], and contains workspace files which should
be local to a particular node of a VAXcluster. This includes LITES2 workspace
and journal files.
Example directories on it might include:
LSL$LOCAL_ROOT:[LITES2.JNL] journal files for LITES2
LSL$DATA_ROOT:[LITES2.WORK] workspace files for LITES2
-
LSL$SOURCE_ROOT contains any Laser-Scan program sources
This tree is not usually present on site, but if it exists, it is usually
[LSLSOURCE...], and contains any Laser-Scan program sources. These are often
only present for customer-specific programs.
The files can be further categorised as follows.
-
Program executable image files. These are the definitive copies of the
programs making up the LAMPS suite. All the Laser-Scan user programs
are contained in a directory tree pointed at by LSL$PUBLIC_ROOT.
The exact location of the program on the tree need not
be known, as a logical name LSL$EXE is provided as a search list
running through all the relevant branches of this "public tree".
-
Command procedure files. These are DCL procedures for carrying out
housekeeping functions, and running certain LAMPS programs.
Like the image files, these are kept on the "public tree".
The exact location of the command file on the tree need not
be known as a logical name LSL$COM is provided as a search list
running through all the relevant tree branches.
-
Help files. These are files containing on-line help information
for certain LAMPS programs.
Like the image files, these are kept on the "public tree".
The exact location of the help file on the tree need not
be known as a logical name LSL$HELP is provided as a search list
running through all the relevant tree branches.
-
Program source files. These are the component parts of those programs
which can be recompiled on site (if any), including standard libraries.
These files are resident in a directory tree pointed at by LSL$SOURCE_ROOT.
-
IFF map data files. These are the maps in digital form, created by
digitising or input (eg from magnetic tape for editing).
Depending on the application,
they may be kept, or output from the system to a databank.
These are usually resident on the
LSL$DATA_ROOT directory tree and are pointed at by the logical name
LSL$IF.
-
DTI raster data files. These are eg terrain models in digital form, created
by DTM modelling, or input eg from magtape for display and manipulation.
Depending on the application, they may be kept, or output from the system to a
databank. These are usually resident on the LSL$DATA_ROOT directory tree.
-
Static data files. These are files containing subsidiary information
necessary for the running of certain programs. An example would be the
FRT files which determine the graphical representation of features
according to their feature codes.
These are usually resident on the
LSL$SITE_ROOT directory tree, and are pointed at by logical names, eg
LSL$FRT.
-
Workspace files. These are files containing temporary copies of data
while programs are running. They reside temporarily
on the LSL$LOCAL_ROOT directory tree.
--------------------------------------------------------------------------------
SEARCH LISTS
As described above, logical name search lists are provided to obviate the need
for ordinary users to know the precise location on the public tree of program
images, help files, command procedures etc.
The main ones of these are LSL$EXE, LSL$COM, LSL$HELP, and LSL$LOOKUP.
Taking LSL$EXE as an example, on a minimal LAMPS system with packages
LSLSYSTEM, MAPPING, IMP, LITES2, PLOTTING, SIGMA and TABLE,
the logical name LSL$EXE must
translate to include the following directories
LSL$PUBLIC_ROOT:[LSLSYSTEM.EXE],
LSL$PUBLIC_ROOT:[MAPPING.EXE],
LSL$PUBLIC_ROOT:[IMP.EXE],
LSL$PUBLIC_ROOT:[LITES2.EXE],
LSL$PUBLIC_ROOT:[PLOTTING.EXE],
LSL$PUBLIC_ROOT:[SIGMA.EXE],
LSL$PUBLIC_ROOT:[TABLE.EXE]
It is recommended that it also include as the first translation the directory:
LSL$SITE_ROOT:[LSL.EXE]
in which testing or modified releases of software can be placed so that
they get taken in preference to the public tree "standard" version.
Similarly LSL$COM, LSL$HELP, and LSL$LOOKUP should pass first through
directories [LSL.COM], [LSL.HELP] and [LSL.LOOKUP] on LSL$SITE_ROOT.
These can then be used for modified command procedures, help files and lookup
files to avoid changing the standard versions on the public tree.
At sites which have been installed using the LSLINSTALL automated installation
procedure (see below), a file containing the definitions for these search lists
will automatically have been generated using a procedure called
LSLSEARCHLISTS_GENERATE.COM which is supplied as part of the LSLSYSTEM
package. This procedure can be re-run while logged on as user SYSTEM to
regenerate the file which will be called LSDEFNS_SEARCHLISTS.COM and live in
the SYS$MANAGER: directory.
--------------------------------------------------------------------------------
USERS, PROCESSES, AND UICS
Conventionally, each user of the system has their own username and
password, so that a record is kept in the accounting system of resources
used. All Laser-Scan programs may be run by any authorised user of the
system, and do not require the use of any particular username.
It is however conventional to have a captive user CONTROL to run the DCL
procedure which administrates the DIGSYS control process, and a user VTRAK
to run the VTRAK vector digitising package.
All users of the LAMPS system must be allocated User Identifier Codes (UICs) in
the same group (usually 100) so that they have group privileges with respect
to one another. This allows files created by one user to be edited by another,
and allows inter-process synchronisation for eg DIGSYS via group-wide common
event flags.
Note that in the production flowline situation, many users are involved in
progressing a map through the various stages of digitising, editing,
processing, plotting, validating etc. Hence it is particularly important that
file protections do not interfere with this sharing of data.
It is normal to reserve UICs [100,1] to [100,10] inclusive for Laser-Scan use,
particularly for hardware and software maintenance, and if so then the
following usernames are also reserved.
-
The LSLSOFT user is required to be the owner of all LAMPS programs, and
will have been created using AUTHORIZE as follows:
UIC=[100,2], username=LSLSOFT, owner="LSL Software",
account=LSL, directory=[LSLSOFT], device=LSL$SITE_ROOT:,
privileges=(GROUP,TMPMBX,NETMBX)
-
If there is LSL-maintained hardware installed as part of the system it
is conventional to have an LSL engineer's account as follows:
UIC=[100,3], username=LSLENG, owner="LSL Service",
account=LSL, directory=[LSLENG], device=LSL$SITE_ROOT:
privileges=(GROUP,TMPMBX,NETMBX)
-
Where there will be continued LSL consultancy support it
is conventional to have an LSL liaison officer's account as follows:
UIC=[100,4], username=LSLLIAISON, owner="LSL Consultancy",
account=LSL, directory=[LSLLIAISON], device=LSL$SITE_ROOT:
privileges=(GROUP,TMPMBX,NETMBX)
-
A typical template LSL user account should also have been created as follows:
UIC=[100,100], username=LSLUSER, owner="LSL LAMPS user",
account=LSL, directory=[LSLUSER], device=LSL$USER_ROOT:
privileges=(GROUP,TMPMBX,NETMBX)
-
If any of the LAMPS Matrix packages (eg DTMCREATE), or the STRUCTURE or
POLYGONS packages are to be used, then a user is needed with enhanced
quotas to allow use of these programs.
A template "big" user account should then be created as follows:
UIC=[100,101], username=LSLBIG, owner="LSL LAMPS big user",
account=LSL, directory=[LSLUSER], device=LSL$USER_ROOT:,
privileges=(GROUP,TMPMBX,NETMBX),
WSQUOTA=2048, WSEXTENT=8192, PGFLQUOTA=30000
--------------------------------------------------------------------------------
SYSTEM MANAGEMENT
--------------------------------------------------------------------------------
PACKAGE INITIALISATION
All the symbols and logical names required to run LAMPS programs can be set
up by a series of command procedures available on LSL$COM - a general
Laser-Scan one, and one for each package.
The default action of each package initialisation procedure is to set up
all symbols, and all logical names in the process logical name table.
Some packages support definition of their logical names at VMS system
startup (bootstrap) time.
If an optional argument SYSTEM or GROUP is given to such a procedure, then
it will only define the logical names, and will do it in the given logical
name table (system or group).
Note that while duplicated effort can be avoided by defining logical names
system-wide at system startup time, symbols can only be defined on
a per-process basis.
Generally, if logical names are already set up when a package initialisation
procedure is invoked, they will not be overwritten.
The package initialisation procedure must be executed before running any of the
programs of that package, and this is normally done in one of the following
ways.
-
Explicit invocation of each package initialisation procedure as and when needed
before use of the package. This method is rare, and only relevant when users
only occasionally require LAMPS software.
-
Automatic invocation of relevant package initialisation procedures at
login time by means of commands in each user's private LOGIN.COM file.
-
Automatic invocation of all package initialisation procedures at
login time by means of commands in a central login command file using
the DEC SYS$SYLOGIN mechanisms. This is the most usual approach.
-
Automatic invocation of all package initialisation procedures in SYSTEM mode
at system startup time by means of commands in the Laser-Scan startup files
which are called from the DEC system startup
command file SYS$MANAGER:SYSTARTUP.COM. This can only set up logical names,
not symbols, so is usually combined with (3) or (2) above.
--------------------------------------------------------------------------------
SOFTWARE INSTALLATION PROCEDURES
LAMPS software is normally issued as DEC BACKUP savesets on either 1/2 inch
1600bpi industry standard magtape, or on DEC TK50 cartridge tape. Each package
is a normally a single saveset with the saveset name the same as the package
name. In some cases, there will be a second saveset for a package, with a name
having "_2" appended to the package name, eg LITES2_2.
A command procedure LSLINSTALL.COM is provided as part of the basic
LSL system support package LSLSYSTEM to carry out the main steps in LAMPS
software installation. The procedure has built in help. However, as it is
part of the software it is intended to install, some degree of manual
bootstrapping is of course required.
There is a separate document, the "LSL LAMPS Software Installation Guide" which
explains the installation procedure in some detail, and the reader is referred
to this document for further information.
--------------------------------------------------------------------------------
SOFTWARE UPDATES PROCEDURES
All DEC standard software including VMS should be kept up to date with new
releases as issued by DEC, using the DEC-supplied procedures. See the
"VMS Software Installation Guide" for details.
Laser-Scan will issue periodic new releases of software components to
customers with software maintenance contracts.
New releases of software may take the form of complete packages in the
same form as for an initial installation (see above), or of particular package
components. In either case, the usual distribution medium is BACKUP savesets
on 1600bpi 1/2 inch magtape or on TK50 cartridge.
These new releases should
be placed on the appropriate directories on the LSL$PUBLIC_ROOT
public directory tree. There is a procedure LSLUPDATE.COM available
on the LSL$COM search list which automates the steps in reading an update
tape onto a temporary directory tree, reporting its contents, checking for
conflicts, merging
the temporary tree with the public tree, and clearing up afterwards.
The LSLUPDATE procedure has an inbuilt help facility, and the steps involved are
-
PREPARE -
Prepare the update directory tree and set up the rooted logical name
and empty directory tree used to hold the updating files prior to the merge
stage.
This command must be given before LOAD, MERGE, or TIDY.
It will delete any existing files from a previous failed update.
-
LOAD -
Load the BACKUP savesets containing the software updates onto
the temporary tree.
-
DIRECTORY -
Give a directory listing of the update files now on the temporary
tree.
-
CHECK-
Check the update files now on the temporary tree to see if site-specific
versions exist on LSL$SITE_ROOT. If so, give warning messages and advice
about resolving any possible conflicts.
-
MERGE -
Merge the update files onto the main public tree. Before doing the merge,
the procedure checks for any package-specific update procedures supplied as
part of this release, and if any are found then it invokes them. It then
creates any directories needed on LSL$PUBLIC_ROOT, and renames the files
from the temporary tree into their permanent homes.
-
TIDY -
Tidy up after update, eg by purging the public tree.
Note that if any LSL images are installed, INSTALL/REPLACE
should be used or the system must be rebooted before the tidy phase.
If you have an update to install, and (for some strange reason) have not yet
got the LSLUPDATE procedure currently on your public tree, then you can
bootstrap it from the release tape as follows:
Logon as LSLSOFT, and mount the distribution tape (assumed below to
be a TK50 cartridge MUA0:) as /FOREIGN. Then use BACKUP to read the LSLUPDATE
file from the tape using lines such as:
$ MOUNT MUA0:/FOREIGN
$ BACKUP MUA0:/REWIND/SELECT=LSLUPDATE.COM LSL$PUBLIC_ROOT:[*...]/LOG
$ DISMOUNT MUA0:/NOUNLOAD
NOTES
-
If LSLUPDATE is used to install a Laser-Scan software package which is not
currently installed on this computer, then it will be necessary to edit the
system startup file which sets up the logical name definitions to include the
newly created package directories. These definitions may be in files
LSDEFNS.COM or
LSDEFNS_SEARCHLISTS.COM in the SYS$MANAGER directory. If the existing
definitions are in LSDEFNS_SEARCHLISTS.COM, then see the section above on
"Search Lists" for how to automatically regenerate this file.
-
If a new package is being installed, it will also be
necessary to edit the Laser-Scan login definitions file (LSLOGIN.COM) to invoke
the appropriate package initialisation file eg LSL$COM:STRUCTUREINI.COM.
-
If LSLUPDATE is used to install changed or new programs which require
environment additions such as new logical names,
then it will again be necessary to edit the system startup files.
-
These changes are not necessary in the normal case where LSLUPDATE is being
used to install minor updates to an existing package.
--------------------------------------------------------------------------------
ENVIRONMENT FOR LAMPS KERNEL PACKAGES
The following sections detail the required LAMPS software environment by
package. It should be noted that package LSLSYSTEM and package MAPPING
are prerequisites for all other LAMPS packages, and therefore, their
environments are assumed to be present and are not fully described again for
each subsequent package.
--------------------------------------------------------------------------------
LSLSYSTEM - LASER-SCAN SYSTEM SUPPORT SOFTWARE
The Laser-Scan system software support package (LSLSYSTEM) is required by
all LSL software components. It includes environment setup command files,
supplementary system utilities, and utility programs needed by more than
one package.
Its environment requirements are also needed for all LAMPS packages, and are
described below.
-
SYS$OUTPUT points to the terminal to be used for message output.
-
SYS$INPUT points to the terminal to be used for command input.
-
LSL$PUBLIC_ROOT points to the disk and directory which is the root for
the public tree of Laser-Scan standard software.
This will usually be 'lsldisk':[LSLPUBLIC.],
where 'lsldisk' is the device
containing the Laser-Scan public and site directory trees, eg DUA0:.
-
LSL$SITE_ROOT points to the disk and directory which is the root for
the tree of all site-dependent files.
This will usually be 'lsldisk':[LSLSITE.]
-
LSL$DATA_ROOT points to the disk and directory which is the root for
the tree of user data files.
This will usually be 'lsldatadisk':[LSLDATA.]
where 'lsldatadisk' is the device
containing the Laser-Scan data directory trees eg DUA1:.
-
LSL$EXE is a search list running through LSL$SITE_ROOT:[LSL.EXE], then
through all public tree .EXE directories.
-
LSL$COM is a search list running through LSL$SITE_ROOT:[LSL.COM], then
through all public tree .COM directories.
-
LSL$HELP is a search list running through LSL$SITE_ROOT:[LSL.HELP], then
through all public tree .HELP directories.
-
LSL$LIBRARY is a search list running through LSL$SITE_ROOT:[LSL.LIB], then
through all public tree .LIB directories.
-
LSL$LOOKUP is a search list running through LSL$SITE_ROOT:[LSL.LOOKUP], then
through all public tree .LOOKUP directories.
-
LSL$LSLSHR points to the file containing a shared image of LSLLIB routines
used by most LAMPS programs. This will usually be LSL$LIBRARY:LSLSHR.EXE.
--------------------------------------------------------------------------------
MAPPING - LASER-SCAN MAPPING KERNEL SOFTWARE
The Laser-Scan Mapping Kernel Software package (MAPPING) is required by all
other LAMPS software components. It includes the IFF file interface library
(IFFLIB), the Feature Representation library (FRTLIB), as well as
various central LAMPS initialisation and control procedures.
Its environment requirements are also needed for all LAMPS packages, and are
described below.
-
LSL$IF points to the disk and directory to contain the IFF map
data files to be processed. This may for example be LSL$DATA_ROOT:[LSL.IFF].
Note that a utility SI is provided to allow easy reassignment of the LSL$IF:
logical name. SI will also upkeep a second logical name IF which is
supplied for compatibility with earlier PDP11/RSX systems.
-
LSL$FRT points to a directory in which FRTLIB expects to
find FRT, SRI, and TRI files (feature representation files).
This will usually be LSL$SITE_ROOT:[LSL.FRT]
-
LSL$IFFSHR points to the file containing a shared image of IFFLIB routines
used by most LAMPS programs. This will usually be LSL$LIBRARY:IFFSHR.EXE.
--------------------------------------------------------------------------------
ENVIRONMENT FOR LAMPS BASIC PACKAGES
--------------------------------------------------------------------------------
IMP - IFF MAP PROCESSING
These are programs which create, modify or examine IFF map data
files in various ways. This package is an enhanced replacement for package
DAMP. Examples of IMP programs are -
IMERGE - Merge IFF. Used to combine IFF files or extract features by layer.
ISORT - Sort IFF. Used to restore features into FSN order.
ITOTEXT - IFF convertor to printable (ASCII) text format.
Their required environment is usually little more than that for the kernel
packages (LSLSYSTEM and MAPPING), but note the following:
-
LSL$IF, LSL$FRT, LSL$EXE, LSL$COM etc are obviously required.
-
LSL$LOOKUP search list must include the disk and directory containing a
valid AC skeleton definitions file if utility ISELAC is to be used.
-
LSL$HELP points to a directory in which IMP expects to find its online help
file (IMP.HLB). This will normally be a search list passing through
LSL$PUBLIC_ROOT:[IMP.HELP]. The same help file may also be set up as a
supplementary DCL help file using the VMS HLP$LIBRARY_'n' mechanisms.
This allows access to IMP help information from the DCL level.
See the VMS documentation for details of help libraries.
-
LSL$LITES2CMD points to the disk and directory that will receive the LITES2
guidance command file produced by some IMP programs.
--------------------------------------------------------------------------------
LITES2 - CARTOGRAPHIC EDITING
LITES2 is the current version of the Laser-Scan Cartographic Editing System. It
has a moderately complex environment, described below, and users are referred
to the "LITES2 Reference Manual", and the appropriate "LITES2 Workstation
Guide" for more information.
-
The environment of the kernel packages LSLSYSTEM and MAPPING is assumed
to be present, including LSL$IF, LSL$FRT, LSL$HELP.
-
If the optional facilities of LITES2 to display raster background data are to
be used, then the environment of the kernel package MATRIX is assumed to be
present, including LSL$DTI.
-
LSL$LITES2LOCK points to the full file specification
of a file containing a valid LSL-supplied LITES2 site licence, eg
LSL$PUBLIC_ROOT:[LITES2.EXE]LSLBUREAU.LIC.
If this file is not present, then LITES2 will not run at all.
-
LSL$LITES2ROUTINES points to the full file specification of a
shareable image containing the LITES2 user routines.
This will usually be LSL$PUBLIC_ROOT:[LITES2.EXE]LITES2ROUTINES.EXE.
See the LITES2 Reference Manual for details of user routines
-
LSL$LITES2WORK points to a directory in which LITES2
is to put IFF workspace and dump files, usually LSL$LOCAL_ROOT:[LITES2.WORK].
-
LSL$LITES2CMD points to a directory in which LITES2
expects to find command files (default extension .LCM).
This will usually be LSL$SITE_ROOT:[LITES2.CMD].
In particular this directory will normally contain the system-wide and
terminal dependent LITES2 initialisation files.
On later systems, LSL$LITES2CMD is a search list, running through
LSL$SITE_ROOT:[LITES2.CMD], then through all [.CMD] directories on the public
tree.
-
LSL$LITES2JNL points to a directory into which LITES2
writes a journal file of commands given during a session (extension .LJN).
This will usually be LSL$LOCAL_ROOT:[LITES2.JNL].
It is advisable either to regularly purge this directory, or to set a version
limit on it (using the DCL command SET DIRECTORY/VERSION_LIMIT='number'), so
that journal files do not build up without limit.
-
LSL$LITES2SETUP points to a directory in which LITES2 preserves table setup
parameters for use in future sessions (file extension .SET). It is often
convenient to use the same directory as LSL$LITES2JNL for this.
-
LSL$LITES2TERMINAL if set to a string, means that this string
is used as the terminal name when naming device dependent files. If
LSL$LITES2TERMINAL is not assigned then the logical translation of
SYS$COMMAND is used as the terminal name.
-
LSL$LITES2INI may be set to point to a file of LITES2 commands
which will be obeyed automatically every time LITES2 is started up.
-
If a serial interface Laser-Scan Vector Graphics Display is to be used for
graphics output, eg a Sigmex 6164, then LSL$TK points to the serial line to be
used for communication with it eg TXB6:.
-
If a parallel interface Laser-Scan Raster Graphics Display is to be used for
graphics output, eg Sigmex ARGS 7000, then LSL$VS points to the parallel
interface port to be used for communication with it eg IDA0:.
-
LSL$SIGMA_COLOUR, LSL$TEK_COLOUR, LSL$VAX_COLOUR LSL$DECW_COLOUR point
to the colour table
definition file for the appropriate display type (Sigmex 6000, Tek 4100, or
VWS VAXstation, or DECwindows VAXstation).
--------------------------------------------------------------------------------
PLOTTING - CARTOGRAPHIC PLOTTING (FPP)
The core of package PLOTTING is FPP which is the Laser-Scan Fast Plotter
program. Variants of FPP are available for a variety of plotting devices.
FPP takes features from nominated IFF files and displays them according
to feature representations extracted from a set of FRT, SRI, and TRI files.
Its required environment is described below.
-
The environment of the kernel packages LSLSYSTEM and MAPPING is assumed
to be present, including LSL$IF, LSL$FRT, LSL$HELP.
-
LSL$FPPINI is optional, and may point to a file containing FPP
initialisation commands.
This may be for example LSL$SITE_ROOT:[PLOTTING.CMD]CAL1044INI.FPP
-
LSL$CALCOMP points to the Calcomp plotter to be used for graphics output
(if present) eg TXB6:. For other program versions there may be other logical
names pointing to the required graphics device, eg LSL$BENSON, LSL$FERRANTI.
--------------------------------------------------------------------------------
ENVIRONMENT FOR LAMPS OPTIONAL PACKAGES
--------------------------------------------------------------------------------
VTRAK - VECTOR DIGITISING
The vector scanning and line following digitiser package (VTRAK) has a very
complex and largely self-contained environment, which is described in the
package documentation for the VTRAK package. It requires a the SCANCONVERT
package and a source of raster scanned map data.
--------------------------------------------------------------------------------
LASERAID - AUTOMATIC DIGITISING
Laseraid is the Laser-Scan vector scanning and line-following automatic
digitiser program.
It uses a FASTRAK or Lasertrak digitiser.
See also packages HRD and HIACC for details of the device support required.
Its required environment is described below.
-
The environment of the kernel packages LSLSYSTEM and MAPPING is assumed
to be present, particularly LSL$IF.
-
TT points to the terminal for interactive input and output. Note that
this is used rather than SYS$INPUT and SYS$OUTPUT.
-
LSL$LK points to the disk and directory containing the patch file
(Laseraid parameter file) to
be used to initialise the parameter values which control the line following
and other digitising algorithms.
This will normally be LSL$SITE_ROOT:[LASERAID.PATCH].
-
As package LASERAID requires a Lasertrak (or FASTRAK) digitiser, the
environment of the HRD package is therefore required. Note particularly
that SYS$HRD points to the Lasertrak, and SYS$LDSY21 points to the
system constants file for digitising, usually LDSY21.R'nn' ,
where 'nn' is the Lasertrak number.
-
LSL$GU points to the disk and directory containing the guidance IFF file
that will be used to guide the digitising operation. This file is only
used if the guidance mode of operation is selected.
It will usually be the same place as LSL$IF.
-
LSL$FLFHLP points to the help file containing the explanatory texts
available online. This will normally be LSL$HELP:LASERAID.HLB
--------------------------------------------------------------------------------
DIGSYS - MANUAL DIGITISING
The DIGSYS on-line digitising system has a complex environment which is
documented more fully in the "DIGSYS Reference Manual". Note that DIGSYS is
usually invoked via a captive CONTROL user.
A summary of the required environment is given below.
-
LSL$DIG'n' where n=1,2,..., should point to the device names
of the terminal ports to which the digitising tables are attached.
Note that earlier versions of DIGSYS used the logical names SYS$DIG'n' instead.
-
MCE$MODE should translate, system-wide, to the security status of the
computer system - either OPEN or SECURE.
-
MCE$SECTERM should point to a secure
(/HARDCOPY) terminal for
use by the CONTROL process during SECURE operation. It may be omitted if
SECURE operation is never required.
-
LSL$EXE search list should point through the disk and directory where the
digitising system's CONTROL and TABLE executable images used by the system are
held. This is usually LSL$PUBLIC_ROOT:[DIGSYS.EXE].
-
LSL$MGMT should point to the disk and directory where the
digitising management files are held. This will usually be
LSL$SITE_ROOT:[LSL.MGMT]
-
LSL$CPF should point to the disk and directory where the
control point files are held. It may be omitted if the control point file
facility is not used.
It is usual for this directory to be the same as LSL$MGMT.
-
LSL$MENU should point to the disk and directory where the
menu and puck definition files are held.
It is usual for this directory to be the same as LSL$MGMT.
-
LSL$'task name' is the general form of a series of logical names that are set
up at group level in the CONTROL user's login file, and which define default
disk and directory names for the IFF files relating to particular tasks.
-
LSL$DIGMBTERM is a logical name created by the digitising system itself
and translating, group-wide, to the mailbox used by the CONTROL process for
receiving notification of the termination of digitising TABLE processes.
Note that earlier versions of DIGSYS used the logical names DIGMBTERM instead.
-
LSL$DIG_OPTIONS should point to the options file which defines how the
DIGSYS system will behave.
-
LSL_DIGCEFC'table' are the names of the common event flag clusters created
by DIGSYS, where 'table'
identifies the TABLE process which will use the cluster to communicate with the
CONTROL process.
-
LSL_CONGBLSEC is the name of the control global section created by DIGSYS.
-
LSL_MENGBL'table' are the names of the multiple menu global sections
created by DIGSYS, where 'table' identifies
the TABLE process whose puck and menu definitions are contained within the
section.
--------------------------------------------------------------------------------
CONVERT - IFF DATA CONVERSION
The IFF data conversion package (CONVERT) is an optional component which
allows conversion of IFF data to and from a variety of standard external
formats. The package is divided into modules, and each customer will normally
receive only those modules which are relevant.
The required environment may vary between options, but is basically
the same as for the IMP package.
--------------------------------------------------------------------------------
FLOWLINE - FLOWLINE CONTROL
The Flowline Control package (FLOWLINE) is an optional component which
allows control of the tasks and data involved in managing a production flowline.
It uses the DEC Rdb relational database to store flowline and status
information. The main program involved is called LAMPSCONTROL.
The required environment is quite complex and is described fully in the
Reference Manual of the FLOWLINE package.
--------------------------------------------------------------------------------
CUSTOMER - CUSTOMER-SPECIFIC SOFTWARE
Many LAMPS customers have a need for customer-specific software to tailor
the LAMPS system for their precise application, eg to transfer map data
to an external databank in a particular format. Such utilities usually require
a limited environment similar to that of IMP (qv). Any customer-specific
Laser-Scan logical names should take the form LSL$'customer'_'purpose'. eg
LSL$OS_CODES for customer OS (Ordnance Survey), code lookup file.
--------------------------------------------------------------------------------
STRUCTURE - STRUCTURED IFF PROCESSING
The Structured IFF data package (STRUCTURE) is an optional component which
allows the creation and manipulation of link-node structured (junction) IFF
data files. The ILINK program which is a major element of this package
will do extensive geometric "tidies" on vector data, eg extension, truncation,
common alignment, etc.
The required environment is described below.
-
The environment of the kernel packages LSLSYSTEM and MAPPING is assumed
to be present, including LSL$IF, LSL$FRT, LSL$HELP.
-
LSL$IF points to the disk and directory to contain the IFF map
data file(s) to be processed. This may for example be LSL$DATA_ROOT:[LSL.IFF].
The same directory will receive the output structured IFF data file (IFJ file).
-
LSL$LITES2CMD points to the disk and directory that will receive the LITES2
guidance command file produced by program RELHT in case of coding ambiguity.
-
The current default directory of SYS$DISK:[] is used for reading an optional
file containing feature code pairs (FCP file). The same directory is used to
create a saved statistics file (ILINKSTAT.DAT).
file
--------------------------------------------------------------------------------
POLYGONS - POLYGON IFF PROCESSING
The Polygon IFF data package (POLYGONS) is an optional component which
allows the creation and manipulation of Polygon IFF files. The STRUCTURE
package is needed as a prerequisite.
The required environment is described below.
-
The environment of the kernel packages LSLSYSTEM and MAPPING is assumed
to be present, including LSL$IF, LSL$FRT, LSL$HELP.
-
LSL$IF points to the disk and directory containing the IFF and IFJ map
data file(s) to be processed. This may for example be LSL$DATA_ROOT:[LSL.IFF].
The same directory will receive the output polygon IFF data file.
-
LSL$LITES2CMD points to the disk and directory that will receive the LITES2
guidance command file produced by program IPOLYGON in case of problems.
-
LSL$LOOKUP points to a disk and directory containing an optional selections
definitions file.
--------------------------------------------------------------------------------
ENVIRONMENT FOR MATRIX PROCESSING PACKAGES
--------------------------------------------------------------------------------
MATRIX - MATRIX DATA HANDLING
The MATRIX package allows basic viewing and manipulation of matrix data.
It is a prerequisite for packages DTMCREATE, DTMCONVERT, TVES and IMAGEPROCESS.
Its environment is assumed to be available for those packages, and is described
below.
-
The environment of the kernel packages LSLSYSTEM and MAPPING is assumed
to be present, including LSL$IF, LSL$FRT, LSL$HELP, LSL$LOOKUP.
-
LSL$DTI points to the disk and directory to contain the DTI
matrix data file to be read and/or modified.
This may for example be LSL$DATA_ROOT:[LSL.DTI].
-
If a serial interface Laser-Scan Vector Graphics Display is to be used for
graphics output, eg a Sigmex 6164, then LSL$TK points to the serial line to
be used for communication with it eg TXB6:.
-
If a parallel interface Laser-Scan Raster Graphics Display is to be used for
graphics output, eg Sigmex ARGS 7000, then LSL$VS points to the parallel
interface port to be used for communication with it eg IDA0:.
-
If a Sigmex ARGS 7000 is to be used, then LSL$LOOKUP and LSL$IDSYDIR both
point to the disk and directory containing Sigmex ARGS 7000 colour lookup tables
(LUTs).
-
LSL$SIGMA_COLOUR, LSL$TEK_COLOUR, LSL$VAX_COLOUR point to the colour table
definition file for the appropriate display type (Sigmex 6000, Tek 4100, or
VAXstation).
--------------------------------------------------------------------------------
DTMCREATE - TERRAIN MODEL CREATION
The DTMCREATE package allows generation of terrain models from IFF map data.
Its required environment is described below.
-
The environment of the kernel packages LSLSYSTEM, MAPPING, MATRIX is assumed
to be present, including LSL$IF, LSL$DTI, LSL$HELP, LSL$FRT.
-
The environment of the requisite device support package (ARGS, SIGMA etc)
is assumed to be present if graphics output is required. This includes
LSL$VS, LSL$TK, LSL$LOOKUP.
-
LSL$LOOKUP search list must also include a disk and directory containing
the Panacea lookup files used to determine default hardware characteristics.
This will usually be LSL$SITE_ROOT:[LSL.LOOKUP]
-
LSL$PANLOOKUP points to the same place as LSL$LOOKUP.
--------------------------------------------------------------------------------
DTMPREPARE - PREPARATION FOR TERRAIN MODELLING
The DTMPREPARE package is an optional extension to package
DTMCREATE which allows checking and analysis of vector data to be used as input
to terrain model generation. An example is the automated heighting
of river networks by intersection with contours.
Its required environment is described below.
-
The environment of the kernel packages LSLSYSTEM, MAPPING, MATRIX is assumed
to be present, including LSL$IF, LSL$DTI, LSL$HELP, LSL$FRT.
--------------------------------------------------------------------------------
DTMCONVERT - DTI MATRIX DATA CONVERSION
The DTM conversion package (DTMCONVERT) is an optional component which
allows conversion of DTI matrix data to and from a variety of standard external
formats. Note that this package is divided into modules for different
formats, and only relevant modules need be supplied.
Its required environment may vary according to module, but
is likely to be as described below.
-
The environment of the kernel packages LSLSYSTEM, MAPPING, MATRIX is assumed
to be present, including LSL$DTI, LSL$HELP, LSL$IF.
--------------------------------------------------------------------------------
TVES - TERRAIN VALIDATION AND EXPLOITATION
The TVES package allows display and analysis of terrain model data.
Its required environment is described below.
-
The environment of the kernel packages LSLSYSTEM, MAPPING, MATRIX is assumed
to be present, including LSL$IF, LSL$DTI, LSL$HELP, LSL$FRT.
-
The environment of the requisite device support package (ARGS, SIGMA etc)
is assumed to be present if graphics output is required. This includes
LSL$VS, LSL$TK, LSL$LOOKUP.
--------------------------------------------------------------------------------
IMAGEPROCESS - REMOTE SENSED IMAGE PROCESSING
The Image processing package (IMAGEPROCESS) is an optional component which
provides conversion to DTI file of remotely sensed (eg satellite imagery)
data from external formats
Its required environment is described below.
-
The environment of the kernel packages LSLSYSTEM, MATRIX is assumed
to be present, including LSL$DTI, LSL$HELP.
--------------------------------------------------------------------------------
ENVIRONMENT FOR LAMPS GIS PACKAGES
--------------------------------------------------------------------------------
LAMPS GIS PACKAGES
-
The X-windows GIS package (XGIS) is needed as the basis of the GIS
application packages METROPOLIS (for land information) and HORIZON (for
environmental information). It requires DECwindows and OSF/MOTIF.
It provides a user-friendly menu interaction environment, using the UILMENUS
facilities of the LITES2 package.
It has a complex environment, described in the documentation for the XGIS
package. It is structured into 3 layers of software: XGIS core, product (eg
HORIZON), and customer-specific.
-
The land information GIS (METROPOLIS) is a Geographic Information System
aimed at the storage, retrieval, and analysis of information on human land
usage.
Its environment is determined by the XGIS support package.
-
The Environmental GIS (HORIZON) is a Geographic Information System aimed at
the storage, retrieval, and analysis of information on the environment.
Its environment is determined by the XGIS support package.
--------------------------------------------------------------------------------
ENVIRONMENT FOR LAMPS DEVICE SUPPORT PACKAGES
--------------------------------------------------------------------------------
HRD - HRD-1 DEVICE SUPPORT
This package includes device driver and interface library for the HRD-1
high resolution display/plotter, and also for the Lasertrak and FASTRAK
digitisers.
Note that this package is also used outside the LAMPS environment to
support use of HRD-1 displays for other applications, and that it may need
the HIACC package if high accuracy plotting is to be achieved.
Its required environment is described below.
See the "VAX LDLIB and HR: Driver Technical Documentation and System
Manager's Guide" for a more detailed description.
-
SYS$HRD points to the HRD/Lasertrak/FASTRAK to be used, eg HRA0:.
-
SYS$LDSY21 points to the system constants file containing the
machine-specific calibrations to be used. An example would be
LSL$LDSYDIR:LDSY21.B22 for blue refresh on machine 122.
-
LSL$LDSYDIR points to the disk and directory containing all system
constants files. This is usually LSL$SITE_ROOT:[HRD.LOOKUP].
-
HRD$EXE points to the disk and directory containing the engineer's
diagnostics, exerciser, and calibration utilities.
This is usually LSL$PUBLIC_ROOT:[HRD.LIB].
-
LSL$HRDSYSDRV points to the disk and directory containing the device driver.
Provided that LSL$PUBLIC_ROOT is resident on the system disk (SYS$SYSDEVICE:),
then this can be LSL$PUBLIC_ROOT:[HRD.DRIVER]. If the public tree is on some
other disk, then a copy of the driver (HRDRIVER.EXE, or HRQDRIVER.EXE)
must be placed on the system disk in a directory pointed at by LSL$HRDSYSDRV.
This is because it is referenced at bootstrap (system startup) time from
SYCONFIG.COM before the other disks have been mounted in SYSTARTUP.COM.
-
LSL$LIBRARY is usually a search list pointing through the disk and
directory containing the LDLIB interface library. This is usually
LSL$PUBLIC_ROOT:[HRD.LIB]
-
LSL$CMNLDL points to the disk and directory containing FORTRAN common
block declarations for interfacing to LDLIB.
This will normally be LSL$PUBLIC_ROOT:[HRD.COMMON.LDLIB].
-
LSL$COM is usually a search list pointing through the disk and
directory containing calibration command procedures. This is usually
LSL$PUBLIC_ROOT:[HRD.COM]
--------------------------------------------------------------------------------
LASERPLOT - LASERPLOT/MLP1 DEVICE SUPPORT
This package includes utilities and interface library for the Laserplot
and MLP-1 microprocessor controlled laser plotters.
Its required environment is described below.
-
LSL$LASERPLOT should be a search list pointing through the public
tree directories containing relevant command files and executable images.
This will normally be LSL$PUBLIC_ROOT:[LASERPLOT.EXE], and
LSL$PUBLIC_ROOT:[LASERPLOT.COM].
-
LD0 points to the serial line to the plotter to be used.
-
LSL$LIBRARY is usually a search list pointing through the directory
containing LPLIB.OLB, the interface library.
This will normally be LSL$PUBLIC_ROOT:[LASERPLOT.LIB]
-
LSL$CMNLPL points to the disk and directory containing FORTRAN common
block declarations for interfacing to LPLIB.
This will normally be LSL$PUBLIC_ROOT:[LASERPLOT.COMMON.LPLIB].
--------------------------------------------------------------------------------
HIACC - LASERPLOT/HRD HIGH ACCURACY SUPPORT
This package is needed when either a Lasertrak or Laserplot is used for
cartographic quality plotting.
It includes utilities and command procedures for carrying out calibrations.
Its required environment is described below.
-
LSL$TK points to the serial line for the workstation to be used for
digitising the grid, if a MUART workstation is used.
-
GRIDIN points to the serial line to the digitising table to be used
for digitising the grid, if a MUART workstation is not used.
-
LSL$IF points to the disk and directory to contain the IFF residuals
data file to be created. This may for example be LSL$DATA_ROOT:[LSL.IFF].
--------------------------------------------------------------------------------
ARGS - SIGMEX ARGS 7000 DEVICE SUPPORT
This package includes utilities and interface library for
the Sigmex ARGS 7000 colour raster display.
Its required environment is described below.
-
LSL$VS points to the Sigmex ARGS 7000 to be used for
graphics output eg IDA0:.
-
LSL$LIBRARY is usually a search list pointing through the directory
containing VSLIB.OLB, the interface library. This will normally be
LSL$PUBLIC_ROOT:[ARGS.LIB]
-
LSL$IDSYDIR points to the disk and directory containing the
Sigmex ARGS7000 system constants files (colour lookup files).
Eg LSL$SITE_ROOT:[LSL.LOOKUP]
-
LSL$LOOKUP search list includes the same directory as LSL$IDSYDIR.
-
LSL$IDSY02 points to the disk, directory and file containing the
default Sigmex ARGS7000 system constants file (colour lookup file).
Eg LSL$IDSYDIR:COLOUR8.DAT
--------------------------------------------------------------------------------
SIGMA - SIGMEX 6000 DEVICE SUPPORT
This package includes command procedures and unsupported interface library for
the Sigmex 6000 series colour raster displays.
Its required environment is described below.
-
LSL$TK points to the serial line for the Sigmex 6000 series display to be used
for graphics output eg TXA3:.
-
LSL$SIGMA_COLOUR points to the disk, directory, and file containing
the colour definition table for the display,
eg LSL$SITE_ROOT:[LSL.LOOKUP]SIGMA.COL.
--------------------------------------------------------------------------------
MUART - MULTI UART WORKSTATION DEVICE SUPPORT
This package includes utilities and command procedures for
a Laser-Scan MUART multiplexing workstation.
Its required environment is described below.
-
LSL$TK points to the serial line for the workstation to be used for
graphics output eg TXA3:.
-
LSL$WOSP points to the directory
containing MUART microprocessor load command files and utilities.
This will normally be
LSL$PUBLIC_ROOT:[MUART.EXE]
--------------------------------------------------------------------------------
SCANCONVERT - RASTER SCANNER INPUT SUPPORT
The raster scanner data conversion package (SCANCONVERT)
includes support utilities for use of a raster scanner or offline
magtape input of raster scanned map data. It is needed if the
VTRAK vectorisation package is in use, or if the Raster Backdrop option
is purchased for the LITES2 package.
Its environment is dependent on whether its output is destined for LITES2
or VTRAK, and is covered by the description of those packages.
--------------------------------------------------------------------------------
TABLE - ALTEK DIGITISING TABLE DEVICE SUPPORT
This package includes device support utilities for use of an Altek digitising
table, and an interface library for
use of a manual digitising table via the Laser-Scan Table Monitor. The Table
Monitor is a detached process which runs at elevated priority and receives
digitising events from the table. It then communicates these events to an
applications process (such as LITES2 or TVES), using common event flags (CEFs)
and a shared global section. See the "Table Monitor Reference Manual" for
details.
Tables supplied by Laser-Scan are currently likely to be Altek tables with
AC40 controllers.
Other manufacturer's tables may be acceptable to some programs, possibly with
reduced functionality. Contact Laser-Scan for further information.
The TABLE package required environment is described below.
-
LSL$MONITOR_TABLE points to the serial line for the table to be used for
digitising if there is more than one table on the system, or if a named Table
Monitor process is to be used.
-
LSL$EXE points through the directory containing the Table Monitor
image (TABMON) to allow the detached process starter image (STARTMON)
to be used. STARTMON must either be installed with ALTPRI privilege,
or be invoked by a privileged process (eg system startup).
-
LSL$LIBRARY is usually a search list pointing through the directory
containing TABLIB.OLB, the interface library.
This will normally be LSL$PUBLIC_ROOT:[TABLE.LIB]
-
LSL$CMNTAB points to the disk and directory containing FORTRAN common
block declarations for interfacing to TABLIB.
This will normally be LSL$PUBLIC_ROOT:[TABLE.COMMON.TABLIB].
-
LSL$MGMT points to the disk and directory to contain the shared global
section files, and the error files, used to communicate between the Table
Monitor and the applications program (eg LITES2).
-
LSL$TABMON_ROUTINE_'ddcu' if defined, points to a shared image containing a
decode routine to handle the format of a table event for a non-standard
table which is on serial port 'ddcu':, eg TXA6:.