
--------------------------------------------------------------------------

                        R E G I S T E R

                          User Manual

                         Version 6.07am

                             10/1995

                Internet e-mail:  pjv@mpx.com.au         
--------------------------------------------------------------------------

      SECTION           Contents  

      1.00              Operation 
      2.00              Program Error
      3.00              Introduction
      4.00              Definitions
      5.00              The Program
      6.00              Tutorial        <----- jump in
      7.00              Examples    
      8.00              Log Files
      9.00              Archive/Backup
     10.00              Technical Reference
     90.00              Registration - Register Your Copy Now!  



                    COPYRIGHT


   This program remains the copyright of the author, Peter J. Vincent.
   If you can re-engineer it: good luck!! If you would like to see 
   modifications to this program please email. If you've written a better one, 
   please tell me about that too!
 
                    DISTRIBUTION

   As of 10/1995, this program is being released as FREEWARE. The existing
   restrictions that cripple the program will remain in force. See text 
   later on. To provide for a unique USER ID, please register the program
   via email <pjv@mpx.com.au>. Each user is allowed to run and copy the 
   program for others. However, only copy the original files in entirety
   as once the program runs, the program cannot be copied to another
   machine.

   The distribution and use of the program is for the benefit of amateur
   railfans. Those institutions and commercial concerns that may wish to
   use the program are advised to negitiate with the author.

 
 
-------------------------------------------------------------------------
SECTION  1.00	       OPERATION
-------------------------------------------------------------------------


FILES:   To run the program the following files must be present:

         NAME           STORAGE USE
         -------------  ----------------------------------------------- 

         README   .bat: Run this first, I dare you!

         REG      .id : User ID File
         REG5     .exe: The program
         REG_HIST .dbf: History reference file 
         REG_REF  .dbf: NOTES reference file
         REG_STAT .dbf: Owner System reference file 
         REGDATA  .pjv: Vehicle information file
         REGISTER .pjv: Notes and general information file
         REGLCTN  .dbf: Location reference file
         REGTYPE  .dbf: Vehicle Type reference file
         REGVER   .dbf: CODE VERSION reference file
         REGWGN   .dbf: Vehicle identity file
         MANUAL   .txt: The user manual
         R5       .bat: Starts the program until the user
                        can modify the 'Autoexec.bat' and 'Config.sys'
                        files. If the program does not run then the 
                        'CONFIG.sys' file must be modified. 

         Windows files:

         REGISTER .GRP: Windows group file for REGISTER operations
         REGISTER .PIF: Item file to run REG5.exe
         REG3     .ICO: Program Icon ( Open/shut Register books ) 


===========================================================================
WARNING  WARNING  WARNING  WARNING  WARNING  WARNING  WARNING  WARNING !!!
===========================================================================

The program has been found to be VERY prone to power supply problems. 
The problem seems to relate to power fluctuations that may eventually 
cause the computer to power down or reboot.

It is the WISE user who decides to implement a backup strategy immediately
the program is running. With regular data saving and with the 'LOG' file
that is generated, recovery from disaster would be very quick. 

The other option, 'DO NOTHING' also means I'll 'DO NOTHING' to help. If the 
user has not done any regular backups try not to call late at night.

See Section 9 for more information

===========================================================================
WARNING  WARNING  WARNING  WARNING  WARNING  WARNING  WARNING  WARNING !!!
===========================================================================


1.05     DOS COMMAND LINE
-------------------------

         There are three ways of starting the program. Each way has 
         an optional parameter after the program name.

         The program must be run from the directory that all the files 
         are in.


         1..The program can be started for normal use by typing

                                REG5

            at the DOS PROMPT. The program will start and function 
            normally provided the computer environment has been set up.

            To assist with easy startup, the program creates a subdirectory
            'LOG' in the directory it is in. This subdirectory is where
            the logfile ( DATA_LOG.SAV ) is created and where all the 
            raw data LOG files go to.

         2..The program can be started for setup use by typing

                                REG5 setup

            at the DOS PROMPT. The program will start in mono colors
            and will run to allow the editing of two files:

                            CONFIG.sys    and
                            AUTOEXEC.bat 
         
            When the editing has finished the program will quit. The user 
            must restart the computer for the changes to take effect. 

            When the program is run in 'setup' mode the original files
            CONFIG.SYS and AUTOEXEC.BAT are copied to files

                     CONFIG.REG and AUTOEXEC.REG.  

            So these files will not be overwritten if 'reg5 setup' is
            run again, the program looks for the '.REG' files. If they 
            exist, the program will copy the '.SYS' and '.BAT' files
            with a DOS extension of '.2ND'. This allows the original 
            copies to be preserved. 

         3..For MONO screens and LCD screens, the program may not detect
            monochrome operation. This is because the program is checking
            the videocard capability, not the monitor. To ensure operation 
            on a MONO screen the program can be forced to run mono by 
            starting as 

                           REG5 M  or 
                           REG5 m

1.08     Windows Environment
----------------------------

         The program can by run under Windows by running the program
         in a DOS box. To run the program in a multi-tasking enviromnent
         the program needs to be controlled by a 'PIF' file.

         The 'Chain of command' is as follows:

         1.. Windows Icon selects 'pif' file
         2.. PIF file sets environment and runs REGISTER program

         To assist users three sample files are provided:

         ... A Program group file ( REGISTER.GRP ). This file 
             allocates a group for the program. The user could add
             other program icons relevant to REGISTER operation
             to this group.

         ... A Program PIF file ( REGISTER.PIF ). 

         ... An icon ( REG3.ICO ) to use within the group file.

         The user must edit and alter the parameters for the 
         PIF and GRP files to reflect the drive and directory
         that the program is running in. The user will also have to
         move the files to the Windows directory.


NOTES:   Running the program in Windows will slow it down by about
         20% minimum. To achieve maximum speed, quit Windows and run it
         from straight DOS. The speed effect is not really critical 
         until some operations take over one hour.

         The advantage of Windows is that the user can set a lengthy
         search routine then swap to another task and proceed with
         other work.


WARNING: Any functions in the Utilities menu should NOT be conducted as 
-------- as background tasks. There is the probability of the Windows 
         environment becoming unstable and a General Protection Fault
         being issued. To avoid data corruption, only perform 
         Utilities operations as a FOREGROUND or DOS only operation.
     
1.10     Computer Environment
-----------------------------

         The program can be run by typing REG5 from the directory 
         the program files are residing.

         All the files to run the program sit at one location.

         The program can run in DOS or in a DOS box within WINDOWS.

         The program requires DOS 3.3 or higher and requires 640K of
         memory. It can run with less. If the program cannot start
         then there is probably not enough memory. 

1.15     To run the program the files 'AUTOEXEC.bat' and 'CONFIG.sys'
         must be altered. See 1.05 for new setup method

         The 'AUTOEXEC.bat' must have the following line included 

         SET CLIPPER=//F:40

         This line is used by the program.

         The CONFIG.sys file must have the line 'FILES=xx' altered. The 
         program uses about 25 file handles. Therefore to run this program
         the MINIMUM noumber of file handles must be 5 + 30 = 35. The 5 are
         used by DOS itself in running the computer. If the computer is
         running Windows or other multi tasking feature the number of 
         file handles must reflect the increased use of files.

         If your computer is already using a large number of file 
         handles, increase the FILES= by 25.

         DON'T FORGET TO REBOOT AFTER MAKING THESE CHANGES!!!!!

         NOTE: The file handle is what the computer uses to reference an
               open file. The file handle is attached to the filename in 
               use and is subsequently referenced by the file handle number.

         If the number is too low, the program will not start.

         To assist with an easy start, the batch file 'R5.bat' has been
         included. This has the line 'SET CLIPPER=//F:40' included
         to set up for the program. It this does not make the program
         work, the file 'CONFIG.sys' must be modified to show an extra
         'FILES=' value.

 
1.30     HARD DISK capacity
---------------------------

         The original design concept was for the program to grow to a 
         maximum of 15Mb. This covered all Victorian rolling stock data.

         With the expansion of the concept and the introduction of textfiles
         being loaded up into the storage system, the space required 
         is now limited by what the user intends to do.

         Moderate to low use of the program would require 5 - 10Mb.
         Good use would take 10 - 20Mb. High capacity users can 
         anticipate up to 50Mb of space used.

         To allow the program to grow the following is advised:

         Minimum requirements:  20Mb free
         Maximum requirements: 100Mb free

         Obviously the new program would only consume 2 - 5Mb with growth 
         to 20Mb taking two years. 


1.80     Registration file
--------------------------

         The program uses the file 'Reg.id' to obtain certain information.
         This file contains the USER ID number and the access level the 
         program has.

         There are three access levels:

         LEVEL 0: Program is VIEW only. No data entry, no editing, 
                  no utilities access.

         LEVEL 1: Demonstration access. Full access except data entry which
                  is limited to 20 CODE VERSIONS and 2000 VEHICLE
                  IDENTITIES

         LEVEL 2: Full access, no limits.


         As well, each program must have an 'ID' file with a User Number
         or USER ID. The USER ID is checked each time the program is 
         run. Each 'REG.id' file is tied to the machine that it runs on
         and is 'installed' the first time the program runs. Therefore 
         keep the original 'reg.id' file in a safe place.

         If the program detects that it is running on another machine
         it will automatically change to LEVEL 0 access.

         If the program finds that the 'Reg.id' file is missing, a new 
         file is created with LEVEL 0 access.

NOTE:    Whilst 'pirating' in a private environment is rare, I have 
         endeavoured to reduce such action. The action of 'pirating' 
         can be detected two ways:

         1... Outputs always contain the USER ID number. If seperate 
              programs produce output with the same USER ID then copying
              has been done.

         2... If assistance is required, the USER ID must be quoted.
              If I am not satisfied as to the owner of the program 
              then both the 'copier' and the registered user will
              be disadvantaged by lack of information for problems.


         A more drastic action could be inability of the program to 
         function. At least this way, there is still some access in case
         of a genuine problem.


1.82     USER ID
----------------

         The USER ID is an eight character registration description.
         It is used to assist with the program ID and to track outputs.

         With a lot of people using the program and with similar type
         outputs being handed around, the user id number can identify the 
         source of each output. 

         When running the program, the USER ID is placed in the header
         to show the program owner. This is useful when running multiple
         copies of the REGISTER program on the same machine, each copy 
         from a different user.

         There are three main types of USER ID:

         1... An ID that shows a sequence of numbers or letters;

                   eg 'VIC 001 ', 'NSW 002 ', etc.

         2... The ID used with the demonstration program:

                   eg 'DemoProg'

         3... An ID that the program generates when the 'REG.id' file
              is missing and a new one is created:

                   eg 'DEFAULT '  


-------------------------------------------------------------------------
SECTION  2.00          PROGRAM ERROR
------------------------------------------------------------------------- 

2.01  General
-------------

The program is under continuous development. Things that worked last week
may not work this week. Gradually as the development has eased more time 
has been spent testing and improving sloppy programming.

Since 1988 the program has progressed through:

   Version 1   - dBaseIII+
   Version 2   - Clipper Summer '86
   Version 3   - Clipper Summer '87
   Version 4   - Clipper Summer '87/Blinker/Funcky
   Version 5   - Clipper 5.02 / Clipper Tools
   Version 6   - Clipper 5.02 / Clipper Tools / dbxStore 

(  Version 7   - Clipper 5.02 / Clipper Tools / dbxStore / FiveWin )
(                Windows version to be written 1996+               )

If problems occur, try to duplicate them and get a screen print of the 
error messages. Maybe by the time you tell me they'll be fixed already.

The version number has several parts: eg 'Version 6.02a'

          Main Number: Current storage practice
       Decimal Number: Small changes within storage practice
      Alpha character: The 'bug' fix letter for programs issued.

      ie a Version 6.02c has 'bugs' fixed that 602a had.
           Version 6.08a supersedes any version lower, as an improved 
           program

2.90   KNOWN inconsistencies
----------------------------

1.. The PACK routine is quite safe. However, there appears to be problems
    with the CLEAN routine. Avoid this routine until advised or given 
    a new program version. ( 'CLEAN' now DISABLED til further notice 9/95 )

2.. 'On Register' check from the SUMMARY menu: With the adoption of
     1st/2nd/3rd for vehicle identities, the 'On Register' checking
     routine has not been modified to check all identities.

3.. If a 'spread date' is modified in the EDIT routine for data,
    the program configures it to a standard date, which looks jumbled.

4.. If during an unknown date entry the year is left blank, the 
    program returns to the initial date entry BUT with a '06' sitting
    in the month column.

5.. The NOTES date is not quite developed. 

6.. In the SEARCH for GENERAL NOTES there is a DATE option which allows the 
    user to localise a date search. If searching by years put search 
    from January or one year to December of the next: numbers should be 
    zero filled ( January as 01 ). If the month field is left BLANK 
    not all notes will be picked up.

7.. In the DATA_LOG.SAV file and other LOG files the CAR NAME is not 
    expanded out. The user will see a NUMBER formatted like 
    "@VI 12" which is the storage method for a car name.

8.. On LOCAL output the CAR NAME line on the left of the page
    is not formatting properly.

9.. With the LOCATION RESUME menu choice the first line will be longer by
    one vehicle. This line is greater than the formatted output should be.

-------------------------------------------------------------------------
SECTION  3.00          INTRODUCTION
-------------------------------------------------------------------------


-----
3.01:  Design and development
-----

The program was originally developed to be a storage method for 
Victorian Rolling Stock.

Rob O'Regan has expanded the effort to include Australian rolling stock.
Due to his encouragement, the program has been greatly expanded and modified
to cope with additional historical problems.

To achieve maximum speed with minimum disk space an important design 
criteria has been adopted which is radically different from most programs.
The entire program speed is focussed on data entry. 

To find all other data, ie Locations, text entry; the entire database
must be searched. Consideration was given to the importance of requests and 
the amount of 'crunching' required to perform these tasks.   

Given that requests seem to have the importance of 'immediate' and the 
information is required NOW, the sad truth seems to be the data is generally
not used for weeks.  

----
3.02:
----

This program has evolved from a book entry system of storing vehicle 
histories. The problems with book entry ( ledger ) type storage are many.

Some of the problems if not already known cover:

... Adding out of order data 
... Allocation of page space
... 'Preformatting' books to accept any data found
... Reluctance to tackle any data entry due to problems of changing data
    after initial entry
... Rewriting books to reflect new data entries and worn out pages due to
    use.
... Logistics of juggling vehicle groups
... Hazards of cross referencing by data twice for conversions.
... Difficulty in assembling data
... 'Static' data: Can't do summaries or searches easily.

Perhaps the most important concept of the design criteria was very simple
data entry. By simple I mean the very MINIMUM of data required to identify
a vehicle to attach a history to it. The ability to enter data for a vehicle 
without regard to builder or body style was a must!. I wanted data entry
to be performed without using books or references for idendifying use.

Within the framework of the program information is split into two main 
areas. One area deals with specific info like scrappings, construction, etc
whilst the other is general data such as sightings, notes, etc. 


The two main data types are:

    GROUP INFORMATION: This is data that may not be specific to any ONE 
                       vehicle.

                       Examples would be:
                       
                       - Plans and diagram information
                       - Sightings at locations covering many wagons
                       - Vehicle class data like dimension tables etc.
                       - Data collected from libraries etc
                       - References to data collected that resides in
                         personal files                       
                         
     ITEM INFORMATION: This is the data collected about a SPECIFIC vehicle.
                       
                       - Histories such as Built, Scrapped, Converted
                       - Personal photos
                       - Photos in books
                       - Interesting sightings

3.05   Data Distribution
------------------------

One side effect of the program is the immediate access to information
transfer. With the ability of the program to group the information 
required, or for the user to create data by editing information found, the 
transfer of data is extremely easy. 

Without the laborious work required to find the information, present
the information and then copy it, the program enables the user to 
transfer years of collected data on one or two floppy disks. 


3.09   Starting The New Program:
--------------------------------

The use of this program for data entry is extremely simple. It is suggested
that the new user spend several weeks experimenting first. There are several
reasons for this.

First will be the knowledge that the initial data input will only be for 
testing the use of the program. Keep the test data seperate from the 
long term accurate information. If data testing is not done, then possibly
a mountain load of data may have to be edited and re-typed.

Second will be the importance of SLOWING down. In the initial rush to use 
the program there will be mistakes made. If the mistakes are made during the 
learning curve and data entry is rapid, a lot of undoing will have to be 
made. Some processes of data input can only be redone manually.
Therefore to correct data entry mistakes across many wagons is time 
consuming. By design, some of these processes have been kept MANUAL. 
This is to prevent the user from changing their mind at will. This is a
program to replace the bookwork of data storage. The fact that it is 
computer data entry should not change the regimen of careful data storage.

Thirdly is the overall process of looking after the program
and its environment. Care of the program covers the following:

   ... Defragmenting the disk drive the program is on
   ... Backing up all the files that the program uses
   ... Keeping spare copies of the backups away from the computer location
   ... Regularly creating LOG files with the process of auditing the data

These steps do not have to be done daily or weekly. The main point is that
they are done regularly. As the data in the program grows, the cycle of 
events will become longer and longer. Even if one cycle takes two years
the key is DOING.  
                  

3.10   A Register User Group
----------------------------

With people now using the program across a wider geographical base
than friends, the thought of a User Group has some merit.

I see a User Group that has two loose objectives

1... Establishes a group of users who would learn how to get more 
     out of the program by contact with others. This is the PROGRAM 
     link. 

     There is potential here to develop the program further and discuss
     problems.

2... Establishes contact amongst users that have similar goals. This 
     is the INFORMATION link, where users can share research material.           


-------------------------------------------------------------------------
SECTION  4.00          DEFINITIONS
-------------------------------------------------------------------------

               Please read or glance at this section!

               These are the definitions that the program uses in 
               deciding certain actions. How they are applied is a 
               seperate issue and is covered in the operation
               instructions.

               In the text, the word VEHICLE is taken to mean a Rolling
               Stock identity, whether passenger car, guards van,
               freight vehicle or locomotive or other type of identity.

4.02     CODE: This is the group of letters used by the rail systems
               to identify a specific class of vehicle. The vehicle class
               is a group of wagons, carriages or engines that form a
               unique group. They are unique by construction and/or 
               traffic use. Some examples are:
               
               O    : Fixed wheel Open Hopper
               IT   : Fixed wheel open wagon modified for Timber traffic
               FQX  : Bogie Exchange Flat Wagon for Container Transport
               VOCX : Bogie Exchange Open Wagon with Tarpaulin supports
               
               Generally class or code letters are 1 to 4 characters long.
               Some manage to be up to 5 or 6 or longer.
               
               Some types of rolling stock groups have not been defined 
               by letters. They are referred to by a general description.
               An example could be 'VR Sleeping Cars'. 
               
               Some vehicles are not classified by the rail system
               but are required to be classified for the purposes of
               running the program. These are 'scrap underframes' and
               'unknown' vehicles.  
               
               For both the example types above, the CODE can be 
               defined as '-' ( DASH ). The CODE description is then
               used as a definition for the vehicle group. 
               For example

               -      Joint Stock Sleeping Cars
               -      VR Sleeping Cars
               -      McKeen Car
               -      Scrap underframe
               -      Unknown vehicle

               For all codes, the computer generates a VERSION letter
               with each CODE description. This allows the program to
               figure out multiple codes with the same code letters.
               See 4.06 for more information
                                               
4.04   NUMBER: For the majority of rolling stock, the NUMBER is self
               explanatory. The vehicle number is the unique identifier
               within a class of vehicles. Some vehicles classes ran to
               over 15,000 numbers.
               
               Two problems with the NUMBER became apparent when 
               developing the program:
               
               1.. Vehicles identified by NAME, the name being in
                   excess of 6 characters.

                   To easily remember and locate a car name the 
                   following observations were used to construct
                   rules:
                   
                   (i) If the vehicle is only known by a name, then the 
                       CODE of the vehicle MUST be a '-' ( DASH ), or
                       have a DASH within the code letters.

                       The program will only access a car name if the 
                       CODE has a '-' ( DASH ) in it.
                       
                       This is to prevent a vehicle having two references,
                       one by NAME and another by NUMBER: the program
                       will not connect the two vehicles as being the 
                       same. 

                   (ii) If the vehicle has a NUMBER but the NAME
                       is still used for reference, the vehicle is
                       known by the NUMBER and the NAME is just
                       a reference.                   
                       
              EXAMPLE:   The VR had an observation car called 'NORMAN' 
                         which originated from old Spirit of Progress stock. 
                         The car was identified by the name. In about 1985, 
                         the car was given a CODE and NUMBER of OS 237 with 
                         the NAME 'NORMAN' still applied to the exterior.
							   
                         For program purposes the vehicle is identified as 
                         NORMAM until the new CODE of OS. It is then 
                         identified by the new CODE and NUMBER with a 
                         note indicating the NAME still used as reference.

                   
               2.. Placing an identity on an unknown vehicle. 

                   To further identify unknown veicles and underframes
                   a '-' is used as the NUMBER. To avoid cross reference
                   problems, the program assigns a unique number every
                   time the '-' is used. The user has the option of
                   displaying the '-' or the actual number used.
                   
                   The unique number can be referenced through the 
                   program to add or edit existing data.

                   There is even the potential to link up known vehicles to
                   an unknown vehicle to maintain history continuity.              

4.05     NAME:  See NUMBER

4.06  VERSION:  The version is the method used of describing a class.
                For example there were several types of CODE letter 'M':
                
                Code  Version
                ----  -----------------------------------------------
                M     Electric Suburban - Swing Door
                                        - Sliding door
                                        - Martin & King / Harris Trains
                                        - Martin & King / Hitachi Trains
                                        - Comeng
                                    
                M     Cattle wagons
                M     Shunting locomotives   


                When writing up books, the VERSIONS or different classes
                that have the same code letters are seperated by the 
                groupings within the pages of the books; ie 'Passenger'
                books, 'Engine' books, 'Freight' books, etc.
                
                There is no such distinction for the program, so 
                characters are 'tagged' to the identity of the vehicle.
                This 'tag' is called the VERSION.
                
                The VERSION consists of two characters.  The first
                character represents the owning system. The second
                character represents a UNIQUE letter for the CODE, 
                within the owning system. 
                
                The normal display method is:
                                
                CODE + NUMBER + SEPERATOR + VERSION.
                
                Example:  M   27.VA
                
                          M   Class M
                         27   Number 27
                          .   SEPERATOR
                          V   Owning system V
                          A   Version 'A' of the 'M' letter group, for 
                              Owning system V.
                           

                VERSION DESCRIPTION:
                -------------------
                
                The version description is the key to the vehicle identity.
                The program was designed to add vehicle data without 
                prior knowledge of the vehicles existence. That is, the
                computer would maintain a reference of all vehicle
                identities that had been keyed in. When a new code
                was found, the computer would prompt the user for 
                enough information to establish a new VERSION for
                the CODE being typed in.


                The goal was to provide a platform of vehicle identities
                that could be cross referenced with the minimum amount
                of information. ie, the user did not have to know
                any of the vehicle characteristics, number groups, 
                construction type, scrapping dates, anything.
                
                The requirements for the description were:
                
                CODE LETTERS: The unique combination of characters
                              that the class was known by.
                              
                 DESCRIPTION: A simple description of the vehicle group.

                        DATE: The CODE DATE is defined as the year of 
                              first use of code letters with the given
                              description. So 'I' wagons built in 1929
                              are still described as: 
                              'I 1859 F/Whl Open Wagons'

                        TYPE: The TYPE is simply the main traffic use, 
                              eg Passenger, Freight, Van etc.
                              
                              Combination vehicles are left to the
                              user to make rules for. As a rule, the
                              the largest portion gets the TYPE group.

   				   -------
                   CAUTION:
                   -------
                
                   It is possible to define the CODE groupings into 
                   design types or builders. This will fragment
                   some class number groups when conducting overall
                   searches. Also, reference material will be needed to 
                   fit the identity into the correct group. At different
                   times, the same vehicle number can have multiple
                   identities; each identity may NOT be of similar
                   design or builder. eg 'I 6' wooden wagon 8 tons
                   and 'I 6' steel 16 ton wagon.

                   The concept was to add data without reference
                   to any material, except the users awareness or 
                   knowledge of rolling stock; ie the program is
                   HISTORY based.



4.07 OWNING SYSTEM:  The owning system is used to describe a group of
                     CODES with some common heritage. Only the
                     user of the program has the knowledge to know how 
                     best to use this description. The user will know the 
                     scope of the data, and will be able to group all 
                     wagon data within the 'SYSTEM' limit of 84.
                     
                     This 'Owning System' concept enables the program to 
                     accurately monitor 'REGISTER' figures.
                     
                     Three scenarios are presented to show the  
                     use of the OWNING SYSTEM reference.
                     
                     Scenario 1:  Mainly VR and V/line data;
                                  some interstate conversions;
                                  European rolling stock photos;
                                  North American freight cars;
                                  
                                  OWNING SYSTEM setup:
                                  
                                  A: ANR references
                                  E: European references.
                                  N: NSW references
                                  n: NSW Private
                                  R: NRC references
                                  S: SA  Rail references
                                  s: SA  Private references
                                  U: North American references
                                  V: Victorian Govt Stock
                                  v: Victorian Private

                      Private is a reference to 'non-State' Rail Systems.                     
                                  
                      Scenerio 2  Histories Australia wide
                      
                                  A: ANR
                                  B: Suger cane tramways                     
                                  I: 'Iron and steel' rail systems
                                  N: New South Wales
                                  Q: Queensland
                                  S: Sth Australia
                                  V: Victoria
                                  W: West Australia
                     

                      Scenario 3  ONLY Victorian history with 
                                  Interstate conversions: 


                                  V: Victorian
                                  H: Hobsons Bay
                                  D: Deniliquin & Moama
                                  K: Kerang & Koondrook
                                  Y: Yarrawonga
                                  W: Shire of Horsham
                                  G: Melb & Geelong Rly Co.
                                  N: NSW
                                  S: SAR
                                  A: ANR/AN
                                  
                                  Basically, one letter for each rail
                                  company. 

                The scope of activity will decide whether to allocate
                a letter for EACH rail company OR to group common 
                companies together under ONE letter and describe the 
                rail company in the CODE version description.  

                NOTE: The 'Owning System' need not be a system in the 
                true sense. To monitor rail vehicles that are running
                and preserved, the idea of a 'Private System' or 
                historical group for each state is presented. This allows the
                program to accurately reflect the State systems rolling
                stock and still track preserved vehicles in traffic 
                that are not 'on the books' of the state systems.

                One problem that has occurred is private rail group's 
                recoding of vehicles. This recoding is not in line with 
                State systems, but the change has occurred and can tracked 
                without changing the State systems Register figures.

                eg: VR had a QB code which was became VWAA. A vehicle placed
                    'Off Register' and sold to a private group who recoded
                    vehicle back to QB. For the program to track this, a new
                    QB code is described with a 'Private' reference.    
 
4.08     DATE:  The date is the date of event occurrence. That is,
                the Built New, scrapping or whatever date. 

                Due to the nature of recording, a valid DATE must
                be between 1850 and the current calender day.
                

4.10    NOTES:   The notes are written comments attached to each
                 activity or history. They are designed to simulate the 
                 additional notes or remarks added to Register entries.
                 
                 The notes are only meant to be a reference to the 
                 specific data item being entered. If the notes to be
                 entered are expansive, they are better off being 
                 entered in the 'INFORMATION' section. 
                 
                 The current program limitation on Register note
                 length is 512 characters or about 8 lines of text.

                 NOTE: For the data entry in NOTES only a 40 character
                       area is visible. This is to prevent verbose
                       writing for every entry. 

                       With a full window of 8 lines at 80 characters across
                       for data entry, it would be very tempting to 
                       'fill the void'. 

4.12  HISTORY:	 The HISTORY or ACTIVITY is a designated event that
                 occurs on a certain date at a certain location to a specific
                 vehicle; ie Built new, Scrapped, Converted, etc.
                 
                 The date and location may or may not be known.
                 
                 Notes may be added as required to provide more
                 information.
                 
                 The program has a limited number of HISTORIES with
                 the user being able to add some more as required.

                 The number of choices available is limited by intent.
                 To avoid fragmentation of categories and history types,
                 similar types of HISTORY are grouped to ONE HISTORY, 
                 meaning the same thing. 
                 
                 For example: the HISTORY 'SCRAPPED' is used to 
                 denote three events:  DISMANTLED
                                       BROKEN UP
                                       SCRAPPED.
                                       
                 Each of the phrases mean the same thing but were applied
                 in different eras. As the program intent was HISTORY
                 tracking, the phrase uniqueness was dropped to provide
                 easier reference and simpler summary output.
                 
                 The user can revert to other phrases if required.
                 However instead of zeroing in on ONE event, the 
                 user must be aware that a search for more than 
                 one event is required.
                      


                 Histories provided with the program are:
                 

              History              Definition
              -------              ---------- 

              Body                 Reference of vehicle body at a location

              Built new            Built and placed into service

              Condemned            No longer fit for service

              Damaged              a/c Collision or derailment where
                                   vehicle was not destroyed

              Delivered            Handed over from Contractor but prior
                                   to entry to service

              Destroyed            Wrecked on site and no longer fit for
                                   traffic. May or may not be scrapped
                                   on site

              Equipment            A note that a vehicle is fitted with
                                   specific fittings. Previously used when
                                   the NOTES section was only 28 chars
                                   long

              Ex                   Recoded or renumbered from another 
                                   identity. May or may not
                                   involve rebuilding. Rebuilding and 
                                   modifications in the recoding are 
                                   implied from the conversion
 
              Ex/P                 Ex (parts): Reference to least 
                                   significant parts of vehicles being
                                   used on other rolling stock. This 
                                   HISTORY enables the program to add
                                   cross referenced data but does not 
                                   cross link when searching.

              History not known    Enables user to comment on a vehicle
                                   identity. 

                                   The program produces the message
                                   "Unknown History" data cannot
                                   be found in reference files

              In Service           The vehicle is already built and may 
                                   or not be on the Register. This 
                                   history is to place the vehicle 
                                   'On Register' when other histories
                                   may be inappropriate  

              Into Workshops       Records vehicle going to Workshops
 
              Modified             Vehicle has been altered in some way.
                                   To enable the user to find data fairly
                                   easily and a text search may not 
                                   retrieve all the data a basic rule has
                                   been made. 'Modified' indicates any 
                                   change to the vehicle that is NOT made
                                   for the purpose of TRAFFIC requirements.
                                   Simply put, 'Modified' relates to 
                                   brakes, bogies, wheels, rebuilt bodies,
                                   handbrakes etc 

                                   See TRAFFIC.

              Not Traced Stocktake The vehicle was not found at a 
                                   Stocktake and placed 'off Register'
                                    
              Note                 A reference to be written for a vehicle
                                   that does not fit any useful HISTORY

              Off Register         Vehicle crossed off the Register. The
                                   vehicle may or may not exist at that 
                                   time

              On Register          Sometimes vehicles are marked 'off
                                   Register' and later restored to 
                                   traffic due to shortages
 
              Out of Workshops     Date vehicle left the workshops. Mainly
                                   data from departmental records  

              Photo Details        Reference to detail photos as distinct 
                                   from general photos

              Photograph           Reference to any photograph of a vehicle.
                                   Could be from user photos, publications
                                   or magazines

              Preserved            Attempt to track vehicles still on 
                                   wheels that are no longer in service. 
                                   
                                   (This history is now redundant for the 
                                   program as other methods can be used)
 
              Purchased            This is used for rolling stock that have
                                   been disposed of and due to some reason
                                   have been repurchased. New rolling stock
                                   purchased by contract is implied in the
                                   'Built New' HISTORY
 
              Rec Scrap            Internal reference to correspondence
                                   indicating vehicle 'Recommended for
                                   scrapping'. This may or may not be
                                   followed up. Vehicle generally 'off
                                   Register' by this stage

              Reference            To indicate a vehicle has a 
                                   'Reference' in a plan, diagram or 
                                   some publication
 
              Scrapped             Vehicle has been cut up and no longer 
                                   exists. The term 'scrapped' is to
                                   be taken on face value. In 'rail' 
                                   terminology it is taken to meant the 
                                   the vehicles is off the books and has
                                   been broken up or destroyed. Obviously
                                   if more data shows the vehicle still 
                                   exists, the wording 'scrapped' needs to 
                                   be interpreted with the information

              Sighting             Used to record the 'hard' evidence of
                                   a vehicle existence or modification 
                                   in the absence of more data. With more
                                   data available, the sighting record 
                                   may or may not be removed from the 
                                   items recorded

              Sold (to)            Vehicle has been removed from the 
                                   Register and sold from the rail 
                                   property. Generally, sold implies
                                   the sale of the vehicle without wheels

              Stencilled           Indication that the vehicle is stencilled
                                   with some interesting workings. Usually
                                   the stencil is loosely indicated under
                                   the TRAFFIC history

              Stored               Vehicle has been placed out of traffic use
                                   and is stored. This is generally when 
                                   there is a downturn in traffic

              To                   Vehicle is renumbered or recoded/
                                   renumbered to another identity

              To/P                 The opposite of 'Ex/P'. Used to show 
                                   where <P>arts of a vehicle have gone.
                                   This history is used to prevent a full
                                   cross reference during a search

              To Historical Reg.   A History used to track the vehicles
                                   that were placed 'off Register' and 
                                   removed from general traffic but were
                                   retained for historical use. To the 
                                   program this event signifies 'off 
                                   Register'.

                                   This history is now redundant for the
                                   program as other methods are now in use
 
              Traced at Stocktake  Found or traced after a systemwide
                                   stocktake event

              Traffic              A vehicle is used or stencilled for a 
                                   specific type of TRAFFIC. Implied 
                                   with the traffic 'condition' is the
                                   vehicle may have been 'modified' for
                                   the traffic use. To assist in 
                                   seperating out modified for traffic
                                   and modified for improvement, the 
                                   term TRAFFIC covers any modification
                                   involved in the traffic use  

              Underframe           Similar to BODY, except the under-
                                   carriage of the vehicle
 
              Withdrawn            Removed from service as in
                                   'Withdrawn from traffic'
                                      
              Note: The history is a method of 'tagging' a vehicle with
                    an event. These are the terms and definitions I have 
                    used. Any user can create and define their own 
                    terminology. The main key is the ease of use for the 
                    user. 


              Warning!:    The program has the flexibility to allow the
                           user to add or delete ANY of the histories 
                           given above. The only restrictions are
                           that the HISTORIES 'Ex', 'Ex/P', 'To', 'To/P'
                           have special rules attached to them and should
                           NOT be altered. The user can, but the user
                           beware!
                               

              SPECIAL NOTE: ( Ex/P, To/P ) 

              As the information provided for this history is generally one-
              sided; one vehicle provides the data, the program marks this
              by special text placed in the notes. The vehicle used to 
              CREATE the history (ie the vehicle at the top of the screen )
              is taken as the vehicle which has the information.

              The special text is:

              [org] : Data originated from this vehicle

              [rec] : Data was received from the other vehicle.


              HISTORY GROUPINGS:  For the program to function with 
                                  certain routines and to provide user
                                  flexibility, a HISTORY must be placed
                                  into a certain group. 
                                     
              Currently there are four groups. Within the scope of program 
              development there may be recognition of more.         

              The four groups are:

              Code        Representation
              ----	  --------------
               O          On Register
               S          Off Register                               
               I          Vehicle Information
               P          Private source data  


             The groups give the program ability to filter out data. 
             More importantly they enable the program to recognise 
             vehicle status in regard to 'On' or 'Off' the Register.
             In this way the program can generate a list of vehicle numbers
             in service for a given date


             Some example are:

             HISTORY            GROUP                             
             -------            -----
							 
             Body                 P
             Built New            O                               
             Modified             I
             Note                 I                              
             Ex                   O
             On Register          O
             In Service           O
             Off Register         S 
             Photograph           P
             Scrapped             S
             Sighting             P
             To                   S
             Traffic              I

4.14 ACTIVITY:   See HISTORY

4.18 LOCATION:   The location is where the ACTIVITY or HISTORY occurred.
                 Locations are usually Workshops or in the the case of
                 derailments and accidents the station or location of
                 incident.
                 
                 For vehicles "Built New", the location represents the name
                 of the builder, whether Workshops or contractor.
                 
                 Any description is sufficient to describe a location or
                 builder. The reference could be a Km/milepost or 
                 even a section of track between two stations,
                 such as "Longwarry - Drouin".  
                 
                 A three letter locaion code is used to identify each
                 location or builder reference.


-----------------------------------------------------------------------
SECTION  5.00          THE PROGRAM
-------------------------------------------------------------------------


5.01

Menu choices are the means of accessing all the things the program does.
Within each menu choice, the options will be given and a simple explanation
of the function.

Method of operation:

There are two basic methods used to add data to the program:

1/... Type letters into an allotted space ( called a FIELD ) and 
      press the <ENTER> key. 

2/... Select a highlighted line from a menu box ( PICKLIST ) and
      press the <ENTER> key. 

As the data must be rigidly formatted, the picklist ensures the user
adds data in a consistent manner.

The FIELD to add data is usually delimited by a "." 

Menus have two colors to aid the user. A highlighted choice with
white background and blue letters tells the user that SELECTION only is
possible. When the line is RED with white lettering, the user is alerted
to the potential EDIT or CHANGE of that line. 

For VERTICAL menu tables or 'picklists' the UP/DOWN arrows are used to
move to the appropriate line.

PgUp /PgDn can be used to goto to the Top or Bottom of the table.

For HORIZONTAL menus the LEFT/RIGHT arrows are used to move to the 
appropriate line.

For most menu/picklist selections pressing the letter of the menu choice
will move the highlight bar to the word starting with the letter. 

Generally for menus the pressing the letter will move the bar to the
first word in the menu AND commence operation of THAT choice.

Generally with picklist tables, pressing the first letter of the 
choice will MOVE the highlight bar only. The user must press <ENTER>
to then make the selection. Pressing the first letter choice multiple
times will make the highlight bar move in turn to all the sentences 
starting with the letter.   

In most cases, the ESC key will step the user backwards to the last
item/menu selected. This allows 'backing out' of most menus back 
to the main menu. 


For the rest of this guide if the user is asked to type in characters for a 
field the actual process is:

        Type in characters and then press the <ENTER> key. 


There are two main function keys which can be used practically
anywhere within the screens at nearly anytime. The keys are
F8 and F10.

F8: The F8 key choice allows the user to view files that have been generated
    by the program. By default these are DOS extension ".TXT" files.

    A list of files is presented in a VERTICAL table with Filename, 
    Filesize and Filedate shown.

    When the file is selected by the highlight bar and the <ENTER> key
    pressed the following options are available:

      View: Allows the user to view and/or edit the file. SEE 5.08

     Print: The selected file is sent to the printer.     SEE 5.09

      Copy: The file is copied to another name. The user must
            enter the new name in the FIELD provided.

    Append: Allows the user to join several files into one file.
            A table of files is presented. The file selected is the 
            MASTER file with the original file selected APPENDed to the
            bottom of the second file.

    Delete: Deletes the file from disk.


    -----------------------------------------------------------------
    The last choice has ONE of two options. When called by the F8 key
    the menu displays the "Create" choice. When displayed from the 
    Utilities menu "View Log Files" the choice is "Expand"
    -----------------------------------------------------------------

    Create: Allows the user to create a new file for the purposes of
            writing text as required. The new file with have the words
            'New file' as the first line. These words 'prime' the function
            to start it.  

    Expand: When this choice is pressed on a Log File the program 
            will <expand> out all the coded data to standard text
            format. The file will be placed in the standard program
            directory with the same filename but with a 'TXT' file 
            extension.  
    
5.08: Text Editor
      -----------

To enable the program to function as a standalone product a text editor 
had to be written. All program output is directed to file first. From the
file the data can be viewed, printed or saved with another name. The default
filename for all output is "OUT_PUT.txt". 

The editor controls/keys are:

INS: Pressing the '<INS>ert key toggles text entry between insert text 
     between characters and write-over mode.

DEL: The user can delete a character at a time.

ESC: The user can <ESC>ape from the BLOCK without changes being saved.

 F2: Pressing this key saves all the edit changes for the BLOCK of text. 

 F3: To enable the user to insert a formfeed in the text, the F3 key is
     pressed. Direct input of the ASCII code [chr(12)] is not possible.
     The text "[EOP]" is added to the line when the F3 key is pressed.
     When the text is saved, this 'token' is converted to the formfeed
     character for printer use.  

 F4: Enables the user to delete a line at a time

 F5: The text editor is written using CLIPPER functions. To allow the 
     editor to work on any large textfile the following method was adopted:

     1.. Chop textfile into BLOCKS of 40k chunks of text.
     2.. Edit each BLOCK in sequential order from start to finish.
     3.. Number each BLOCK to allow user to skip around and select
         a BLOCK as required.
     4.. When finished, save all the BLOCKS in sequential order and write
         them to a temporary textfile.

     5.. When the temporary file is confirmed to exist, delete the old 
         file and rename the temporary file with the old name.
 
     With the current version, the largest file that can be edited is
     3Mb ( 3,000,000 characters ). 

     To show the user how many BLOCKS there are are, there is a display
     on the upper screen. The left number shows current BLOCK and the 
     number on the right show total number of BLOCKS.

     The editor progresses sequentially through the BLOCKS. Either by
     ESCaping or F2 (Save) to leave a BLOCK will automatically skip to the
     next BLOCK. If leaving the LAST BLOCK the BLOCKS will be saved to 
     file. 
         
     By pressing the F5 key, the user can enter a BLOCK number. The program
     will go to that BLOCK. If the number entered is less than 0, the number 
     will be set to 1. If the number is greater than the highest BLOCK 
     number, the EDIT will terminate and save the file. 
     
     Setting the BLOCK number allows the user to go to the start or end of 
     the textfile or to 'skip back' one or two blocks while editing.

F6:  To help find key words in text, a 'Mark' facility has been added.
     Press the F6 key to open a 15 character field beneath the 
     top line at 'F6: Mark'. When the text is entered, the field will
     diappear. Any text on the screen that matches the text typed in
     will be highlighted. This included lines 1,2 and 24 on the screen!.

     The highlighted text can be cancelled moving the text out of the 
     screen frame and returning it; ie PgUp/PgDn.

     To cancel further marking, press the F6 key. Press <ENTER> on the 
     blank field. 


5.09: Pop up Notes
      ------------

     To allow the user to take quick notes without jotting notes on pieces 
     of paper the 'JOTNOTES' function has been written into the program.

     From nearly anywhere in the program, the key press of F10 function 
     key will display the JOTNOTES on the screen. JOTNOTES has been split 
     into several categories:

           Notes: Adhoc notes for quick reference and followup.
      References: Allows the user to note abbreviations and refer
                  to them quickly. 
        Contacts: Very simple Name/Address/Phone list for people 
                  associated with program data. 
     Definitions: Other abbreviations used that apply to modifications
                  or equipment.

The popup Notes can be accessed from most areas of the program. Press the 
F10 key for access. The main steps of Note taking are:

1.. Press F10 to call up JotNotes
2.. Select the heading required by arrow keys and press <ENTER>
3.. Type in Notes required
4.. Stop recording/editing Notes by Saving the note (F2 key or Ctrl-W)
    or <ESC>aping from the note by pressing the ESC key.
5.. Select another heading or press the ESC key to clear the screen of
    notes and resume normal program activity.

NOTE: The JotNotes are only accessible when there is no disk activity.
      ie the notes are not available during long search routines or
      utilities that require disk use.     

New!: JotNotes can be now be accessed from the General Notes section.
      The Note Number is "S2". The first four characters are 
      entered as 'ALT + 254': hold down the 'Alt' key while typing in 
      the numbers '254'. Repeat three more times.  

      Each BLOCK of the five BLOCKS represents the location of the 
      of data for the headings used; ie BLOCK 1 = Notes, BLOCK 2 = References,
      etc.
  
-----------
Add - Data: 
-----------


This is the section where data is added for a specific identity.
Data entry order is as follows:

               CODE: See 5.10
             NUMBER: See 5.11
            HISTORY: See 5.12
           LOCATION: See 5.13
               DATE: See 5.14		
              NOTES: See 5.15

----------
5.10 CODE:
----------

The program can accept up to 6 letters, numbers and most characters to 
form a letter group that represents a CODE or class description.

If the vehicle group is represented by a 'description' rather than a 
specific code letter group then a '-' ( DASH ) can be used. (SEE 4.02)

When the code letters are typed in the program searches the CODE 
reference file for the matching letter group. All matching letter
groups are displayed in a small table with descriptions with each code.

The user can then select the appropriate line for the CODE required
at input time. 

When the VERSION has been selected from the table, the description
of the code is displayed above the CODE and NUMBER input for input reference.

There are several function keys that can be used within CODE. However all
are not valid for every CODE input.

F2: This key allows the user to list all the VERSIONS that match the 
    letters displayed in the CODE field. 

    If the CODE field is BLANK every CODE VERSION is listed out. 

    For example if the letters 'ABC' are in the CODE field, the output
    will be formatted thus:
   
    Code.. Date...... Sys  V Type..... Description...................
 
    ABC    1910 -1975 VR   A Pass      Bogie First/Second/Van        
    ABC    1899 -1915 VR   B Pass      Bogie 1st/2nd Corridor Compt. 
    ABCL   1919 -1927 VR   A Pass      Bogie 1st/2nd ex McKeen Car   
    ABCM   1917 -1922 VR   A EMU       Swing Door First/Second/Van   

    All CODES that begin with the letters typed in are presented. 

    This list is generated to a disk file which can be edited, printed
    or renamed.

    To assist with a CODE (list) search two main choices are available:

    1.. System List: 

        Select the specific System to focus on. 

        Press <ENTER> on the choice. 

        If no specific System is required then press the <ESC> key.

        All System matches will be presented.  

    2.. Vehicle Type: 

        Select the Type from the list. 

        Press <ENTER> on the choice.

        If no specific Type is required then press <ESC>. 

        All Types will be presented.


F4: The F4 key is pressed in the CODE field when the user does not know
    the CODE and wishes to find a vehicle by the NUMBER or NAME.

    The F4 key bypasses the CODE input and the user is requested for a
    NUMBER. When the NUMBER is input, a table of CODES and VERSIONS is
    shown on screen for all CODES found with the NUMBER entered. Select the
    line for the CODE of interest and press <ENTER>.  

    To reduce the searchlist, the program will ask for the RAIL SYSTEM
    and then for the VEHICLE TYPE. For each table there are only two choices:
    
    1.. Select an item from the list no narrow the search criteria. Press
        the <ENTER> key on the selected item

    2.. Press the <ESC> key. This will indicate that all items in the table
        will be selected

    After the CODE has been selected from the table, the action will
    depend upon the initial menu choice:

    If the start menu was ADD, the vehicle history will be presented,
    ready to add more data. 

    If the start menu was FIND, the vehicle history will be output.
    
    See NUMBER, 5.11

    New!: To assist with F4/NUMBER entry, the last number input 
    will remain displayed. If the F6/INC(rement) is set 'ON' the 
    last number displayed will be incremented. 

F5: To ease the 'pain' of repititious data entry, the program tracks 
    the last data used and re-uses the data for the next vehicle. This 
    reduces data entry to a few key strokes for common events. 

    This function key is called 'FOCUS' and toggles between General (Gen'l) 
    and Local.

    The states are described as:

    GENERAL: The program stores the last data used irrespective
             of CODE and NUMBER. This is useful where the data remains the 
             same whilst there is a variety of vehicles to add data for.

             eg: Photographs or sightings at a single location of many
                 types of rolling stock.

      LOCAL: For LOCAL history, the program saves the data by CODE, HISTORY,
             DATE, LOCATION and NOTE.

             In this way data entry for a specific CODE can be 
             resumed quickly. 



NOTE: The program records the date each time a HISTORY is used. If a HISTORY 
      has not been used for about eight weeks all data will saved for the 
      'FOCUS' will be lost.  
    

-----------
5.11 NUMBER
-----------

From within a group of vehicles or CODE, each one is identified by aNUMBER
or NAME.

The program can accept up to 6 characters or numbers for a NUMBER. 

When the NUMBER is <ENTER>'d the program searches for an EXACT match.

A small table is presented at the bottom of the screen showing all the 
data found for the vehicle. The data is in chronological order 
WITHIN the vehicle ID number( 1st, 2nd, 3rd, etc ) order.

The last line of the table is the default line at all times. This line 
allows the user to add more data to the vehicle.

When data is present within the table the user can choose a line to EDIT
if more data has been found.

The maximum number of histories for a single vehicle is 4000. When the 
table is presented, only the LAST 17 histories are shown. Scroll up to
see if more histores seem to be missing.

If no data is found for the vehicle, then the table is presented one line;
the line to ADD data.

The following function keys can be used:

F2: The F2 key will provide the user with a list of NUMBERS that
    the program has DATA for, ie currently referenced in the database.
    To assist in a clear output the function returns a list showing 
    consecutive and non consecutive NUMBERS formatted by line.

    To avoid actually showing each number, the program determines a
    'run' of numbers and gaps in number groups.

    A number 'run' has a '-' (DASH) seperating the first and last of the
    number run. Non consective numbers end with a ',' (COMMA).

    ie the numbers  1 2 3 4 5 8 11 12 14 17 18 19 20 are formatted as:


    1 - 5, 8, 11, 12, 14, 17 - 20. This allows long runs of numbers to
    be presented on a few lines. 


    Any non-numeric NUMBER causes the program to accept each following
    number as non-consectutive. Car NAMES are simply listed along a line.

    The usual input is to enter a number range, From and To. This 
    allows the user to be selective, particularly for large number groups.

    If the 'From' NUMBER is BLANK the routine assumes ALL numbers 
    required. If the 'To' NUMBER is BLANK, the routine assumes 
    'til end of number group'.

    Unknown numbers ( the '-' DASH computer generated numbers ) will
    be tallied only and be presented as ' xx unknown underframes '.  

F3: The F3 key allows the user to output complete histories of each vehicle.
    A 'From' and 'To' NUMBER must be entered. 

    If the STEP history is set to LOCAL, only the immediate vehicle data
    is found. If set to STEP, the program does a complete cross reference
    on the vehicle.

       Note: When the program detects the vehicle has multiple identities,
             as in 1st, 2nd, 3rd each 'vehicle identity history' is 
             separated by a '[+' on the left side.

    Similar to the F2 key above, if the 'To' number is blank, the vehicles
    to the end of the code group are searched. If the 'From' number is 
    left blank then the code group is searched from the start.

    Unknown numbers ( the '-' DASH computer generated numbers ) will
    always be after the last visible alphanumeric NUMBER in a class. 
    ie  1, 2, 100, #..100, #..250, etc.   

    NOTE: When 'called' from the 'Add-Data' menu, the 'To' number
          is copied from the 'From' input. This allows the user to
          to do a STEP history of a single vehicle quickly without
          jumping to the search menu.


F5: The program does NOT store 'check letters'. To allow the user a facility
    to validate check letters, the F5 key can be pressed in the NUMBER
    field. The check letter is computed from the CODE + NUMBER.

    To allow the user to validate some codes, a 'phantom' CODE may 
    have to be included in the CODE references. 

    For example: AN locomotive check letters are generated by the inclusion
    of the word 'LOCO' in front of the loco number. Hence loco 842 
    check letter is generated from 'LOCO842'.

    NOTE: At present the check letter routine will not work for AN
          Passenger stock.  


F6: The F6 key allows the user to set INCREMENT 'ON' or 'OFF'. This is
    useful if the data entry is a consecutive number group. The 
    F6 toggles between 'ON' and 'OFF'. 

    INCREMENT 'ON' advances the number when the user leaves the data
    entry screen. If the vehicle is an unknown identity or has
    some alphabetical character or is a NAME reference, then the 
    "number" is not incremented.

    INCREMENT 'OFF' means the number is not incremented when the user
    returns to the NUMBER field.
    
    
UNKNOWN NUMBER: If the user cannot identify a vehicle, the user can let the 
                program generate one. The number is created when the user 
                types a DASH ('-') into the NUMBER field.

                The unique unknown number is required by the program to 
                establish an independent reference. The Number is
                identified by a '#' (HASH) on the left side followed by
                dots and a number; eg '#..123'. 

                If the user specifically wishes to use a certain unknown
                number, say 15000, then the NUMBER can be entered as 
                '#15000'. 

                The program maintains a record of the highest unknown
                number used and increments it on next use. If other numbers
                are used out of order to this sequence then the user may 
                find certain numbers may be duplicated. This is not a 
                problem when the same number is used across different codes.
                But when the same number is used for the same code, then
                disimilar data will be added to the same unknown vehicle.

DEFAULT VALUE:  The value for the start of a new program should be 1 (one).
                This number will obviously increment whilst being used.

                In case of failure and the program must start or establish
                default values, the new start number will be 99000. This 
                number should alert the user to modify the number to the 
                a higher number than one the program has referenced.

                When the program arrives at number 99995, the number will 
                be reset to 1 again. In reality this is not expected to 
                happen.

-------------
5.12: HISTORY
-------------

The HISTORY is selected from a 'droplist'. 

To move the highlight bar press the Up or Dn arrow keys to move up or down 
one item at a time. Use PgUp/PgDn to jump to Top or Bottom of the table. 
To enable easier selection press the first letter of the phrase or word. 
This moves the highlight bar to the next occurrence of the letter.

If there are no selections visible that begin with the letter, the bar 
does not move.  

Successive pressing of the same letter cycles through all the visible 
lines that start with the letter.

The program has been designed to minimise keystrokes and simplify 
data entry. When HISTORY is selected there are number of events that
happen during data entry:

1.. A list of commonly used histories are presented in a box. The 
    minimum that will appear is 5. 

2.. The program records the use of each HISTORY. As some histories are used 
    more than others, they will move to the top of the list. The most common
    history will be at the TOP of the list. This reduces similar data entry 
    to ONE keystroke for this event as the highlight bar will be at the top 
    of the box. 
 
3.. To select a known history which is NOT displayed in the box, the user 
    must drop to the bottom item of the list in the box. This item 
    redraws the box to show ALL the histories available. The user can then 
    pick the required history. To quickly arrive at the BOTTOM of the 
    list, press the DOT or FULLSTOP key '.'. This will move the highlight
    bar to the bottom item.

4.. With the full box drawn, the BOTTOM line changes from "REDRAW box"
    to "RESET" box. This function recomputes the position for every 
    HISTORY. On the next display of the box, only the top five 
    HISTORIES will be presented. To allow a LEAST used history to 
    'bubble' to the top quickly, use the 'RESET' feature first, then
    use the history required.    

5.. The user is unable to ADD new histories in this box. This is to 
    prevent new histories being generated without thought.

    To add a new HISTORY or alter the wording of one that exists,
    use the EDIT menu.

6.. The number of turns taken to move a history in the list depends
    upon the count number used. The default number is 20. The minimum 
    number is 7 and the maximum number is 99.

    Frequent use of a history will cause that history to 'bubble' to the 
    top of the displayed list.

7.. Data is saved for each history used. The data is

                CODE + LOCATION + DATE + NOTES

    In this way, the last history of a CODE can be restored when 
    retyped at a later date.

    To reclaim space, the last date of the HISTORY is recorded. If not
    used after a while, the data for ALL the history will be deleted.

8.. When the HISTORY is "Ex", "Ex/P", "To" or "To/P" the program
    will prompt for the CODE and NUMBER of the other vehicle identity.

    The vehicle initially typed in can be referred to as the 
    'Primary' vehicle. The vehicle called up after the HISTORY
    selection is called the 'Secondary' vehicle.

    To ensure that conversions involve the correct data, after all
    the data for the 'Primary' vehicle is entered, a window at the 
    bottom of the screen displays all the data for the 'Secondary'
    vehicle. This allows the user to check data without quitting 
    the existing ADD screen.
 
    There is the opportunity to add a new CODE and VERSION if the 
    conversion involves a new CODE.

9.. When the program detects more than one ID for vehicle, the user is 
    requested to supply the correct vehicle ID for the history in 
    question. This was outlined in 'Add - Data'. 

    The vehicle ID is also requested for the secondary conversion if 
    the program detects multiple ID's when displaying data.

           
--------------
5.13: LOCATION
--------------

The LOCATION is the geographical location of an event. Generally a
HISTORY occurred at a LOCATION. If the HISTORY is BUILT NEW, then the 
location is more correctly a Builder or Contactor. The Builder could be
a Workshops.

To avoid problems of remembering the EXACT spelling of the LOCATION
phrase only the first few letters need to be typed. If more letters
are used then the search list is reduced. Generally, the three first letters
of a location is enough to provide a moderate list of matches.

NOTE: It is not possible to key the VELAS or three letter code to 
      have the program return the corresponding location.

If the required LOCATION does NOT appear within the selections presented
then a NEW LOCATION will have to be added. The last line of the selection
list must be selected for an addition.

When the 'ADD New Location' is selected the letters typed in are 
redisplayed to allow the user to finish typing in the required locale 
or builder.

The following points are worth noting:

1.. The LOCATION entry may be in UPPER or LOWER case. Howver, the 
    search is difficult if the EXACT use cannot be remembered. Use 
    UPPER case to be consistent.

2.. From the LOCATION typed in, the program generates a 3 letter 
    location code ( called VELAS, after a VicRail Wagon Tracking Program ).
    The 'VELAS' code is generated from the first word by taking the 
    first TWO letters and the LAST letter of the word. The program
    then checks to see if that specific code is in use. If it is the 
    the program tries to create another code.

    The code is generated from taking the first letter of the location
    and trying the combinations:

       <first letter> + 'AA'
       <first letter> + 'AB'
       <first letter> + 'AC'
          "     "            to
       <first letter> + 'zz'

    This would generate some 2,700 location codes. The first unused
    code is presented to the user for input as the LOCATION 3-letter
    code. If the user wishes to try another code, the program will
    search to see if it is used. If not in use it will be accepted
    as the location 'VELAS' code. If in use, the previously generated
    code will be re-presented. This will continue until the a code is
    found that has not been used or the user presses ESC to quit.

3.. Depending upon the status of the LOCAL function, locations used will be 
    presented for data entry. To accept the existing location presented 
    for use, press <ENTER>. To BLANK out the location to represent an 
    unknown or NIL location, press the [SPACEBAR] then <ENTER>. This will 
    cancel the location displayed.

    Typing data into the location FIELD will immediately delete the 
    data present. 

4.. To assist in quick retrieval of locations from the listbox, the use 
    of each location is recorded. The frequently used locations will
    'bubble' to the top. 

    This interesting feature works with whatever locations are chosen and 
    with any given letter group asked for.

----------
5.14: DATE
----------

For each HISTORY, the program stores a date. A Blank date is not allowed.

The nature of historical dates spans 'wild guess' to 'accurate'. The program 
has allowed DATE storage to be the best one for the time of data entry.

An important point here is that the program is designed as DATE based. All
data storage is organised by DATE. To achieve this, the DATE field
had to organise the data. Hence the use of unknown days, months and years to 
enable the information to be presented in the correct order. 

NOTE: To assist data entry from the right hand keypad, any unknown 
      day, month year can be entered using the '0' key. The DATE field
      will automatically skip the slash mark to allow an 8 keystroke
      entry:

      The leading zero's will be converted to blanks.  

The type of DATE input possible is:

   Day/Month/Year:  eg 12/12/1994. 
                
       Month/Year:  eg   /12/1994. Can enter as '00/12/1994'. Program will
                                   request approximate day, default '20th'.
                                   Valid entries are 0,1,2,3 which represent
                                   the 00th, 10th, 20th, 30th days. 

                                   'Fiddling' the day can be useful when
                                   a partly known date 'MUST' be organised
                                   to appear after another date, when the 
                                   events being recorded are known to have
                                   occurred in a certain sequence.         
                                    
             Year:  eg   /  /1994. Program requests approximate Month. 
                                   Default is '6th' month. Valid entries
                                   are all alphanumeric. '0' to '12' would
                                   be the normal range.
 
                                   This allows DATES with year only to be
                                   organised in a certain order. On 
                                   output, the 'date fiddles' are not shown.   
                
       Year1/Year2:  eg 1873/1874. Register entry has ( Spread )  years. 
                                   Valid is year2 must be higher than year1. 
                               
                                   For VR this only applies for some dates
                                   between 1871 and 1974. The correct
                                   DATE in the Register reads
                                   '1872 or 1873' for a date published
                                   '1872/1873'.

                                   NOTE: For the purposes of DATE 
                                   organisation for some summaries and 
                                   outputs the FIRST year typed in is 
                                   SIGNIFICANT.

                                   Press the F3 key to see the date field
                                   change from "  /  /   " to "    //    ".
                                   Type in the two dates involved.
                                   
     dd/mm/yy (W/E): Some dates are given as Week Ending only. This means 
                     the event occurred sometime in the past week but the 
                     only date being recorded is the 'End of week' date.
                     The date is typed in normally and the F4 key pressed.
                     This informs the program to place a "(W/E)" as the 
                     first entry in the data notes.

                     The week ending will only apply to the data at the 
                     time. For the next entry, normal date will apply.

    Best Guess date: The computer can accept a 'best guess' date in the 
                     absence of accurate information. This formalises the 
                     often unwritten but passed on dates of prior events. 
                     The best guess date is given as Month/Year.

                     The  'best guess' can be displayed accurately as 
                     '  /  /    ' which satifies the 'Unknown date' OR can 
                     be displayed as 'circa YYYY' which assists data entry
                     and provides a guide to the era of the unknown date. 

                     There are two ways to set up for an unknown date:

                     1.. Type zero's or blanks in the entire field and 
                         press <ENTER>. 

                     2.. Press the F5 key.

                     The unknown date has two parts: Year and Month:

                     The YEAR is required as the 'best guess' DATE.

                     The MONTH is a default of '6' which can be 
                     altered from '1' to '12'. 

                     This way the unknown date can be modified to 
                     suit data organisation.
                     
                                               			
-----------
5.15: NOTES
-----------

The Register notes are used to add more general information to the data	
being added. 

There is the ability to add up to 512 characters to the note field. This 
works out at about seven lines of text.

There are several ways in which the NOTES are displayed and can be accessed.

The display method depends upon the access method. below is a table 
showing the access method and what is displayed:

Access           Notes Display
----------------------------------------------------------
ADD DATA - New   A FIELD across the screen allows the user to enter data.
                 The FIELD is about 40 characters wide. As the user types 
                 in information, the text will scroll from right to left
                 until the end of the FIELD is reached. The cursor keys can 
                 be used to go back to the start if required. To go to 
                 the end of the text press the 'END' key. To go to the
                 start of the text, press the 'HOME' key.


         - Edit  As above except the text is displayed along a line of
                 about 30 characters.


         - Info  When the vehicle data is shown in a data table only the 
                 leftmost characters of the text are shown. This is about
                 30 characters. There should be enough text displayed to
                 satisfy curiosity. To see the full text, edit the 
                 data and use the EDIT window to select the NOTES line.


Outputs          The display on output will depend upon the number of 
                 columns the output has been formatted to. When printing
                 out the program detects how long the notes are. If the 
                 NOTES are short then they are printed along the line with
                 the data. If the NOTES are lengthy, ie longer than the 
                 page is wide, then the NOTES are truncated and printed
                 after all the data has been printed. 

                 As each NOTE is extracted it is given a number. A reference
                 on the line is given. The reference is 'See Note xxx' where
                 'xxx' is a number given. The number is generated at report
                 time and will always start at one (1).

                 The NOTES extracted are printed at the very end of the 
                 information and before the CODE and LOCATION references.
                 Each notes is identified by number and printed in full.


-----------------
5.20 ADD - Notes:
-----------------

It is this section where the general information such as sightings, daily
notes or other information is placed. 


The main components of the Notes are:

       REF NO: The Number used to EDIT or directly access the Note.
         DATE: The date of the actual occurence, rather than the date the 
               notes were typed in.
       HEADER: The title of the notes. 
        NOTES: The text stored about particular events. 
   REFERENCES: The cross reference data stored along with the 
               notes in 'free text' format.  

Ref No.: Each note is assigned a number. This number is used to 
         quickly access the note for editing or output. 

         The reference number can be reset from the 'Utilities' Menu.

         On data entry, the program will prompt for a Reference Number.
         There are several choices available when adding a new NOTE
         REFERENCE number: 

         1.. The computer will allocate a Reference Number to a new note.

         2.. The user can type in a specific number. There are two actions
             from this

             .. If the NOTE reference exists, the program will allow the 
                user to EDIT the existing NOTE.

             .. If the NOTE reference does NOT exist, a NOTE will be 
                created with the NOTE REFERENCE number.

         3.. To assist with reference material management, the NOTE
             REFERENCE can accept alphabetical characters. Hence a
             note to reference all 'Newsrail' magazines could be 
             called "NR". Any reference to "NR" as a note would 
             recall this data.


             TIP: In some ways this can help with train photos such as
                  'TAIT', 'M&K', 'X35' etc. The restriction is 6 characters
                  and there is no reference to CODE VERSIONS. However, it
                  does simplify data storage of a more general kind which
                  could clog up the data side of the program.

                  Clogging could occur when there are only two pieces of
                  Register type information and 50-100 items which are
                  photographic in nature.

DATE: This date should be as close to the actual event as possible.
      If more data is added to a note, then the date would indicate the 
      start of the notes.

      The Notes search routine can use the dates to narrow down a search.
      If the actual date of occurrence is not used, a specific time frame
      search may miss important data.

HEADER: The header is used to describe the note. In anticipation of 
        many notes, one search method will only produce a list of
        headings instead of the full text. The description in the 
        header allows the user to be more selective with picking out
        data to view.

        If the HEADER is left blank, the program will ask if the NOTE
        is to be deleted. If the answer is "Y"(es) the entire NOTE will
        be deleted.

        This allows the user to delete a note without removing all the text
        first.

NOTES: The notes can be typed in as required. There is no formatting
       involved. Current limitation is 64K per BLOCK. 


REFERENCES:  For the program to provide cross-reference potential, CODE
             and LOCATION references can be added to the NOTE typed in.

             The idea is provide as close as possible a method of typing 
             notes with minimum effort to cross reference.

             All the user is required to do is type up notes and when a 
             reference to a CODE or LOCATION is given, then add the 
             reference to the note using the data the program has access to.
             
             As the program already has on hand a CODE reference file
             under the guise of 'VERSIONS' and a LOCATION reference file
             the cross referencing is very easy.

             This also allows the text to be printed out or sent to file
             without worying about special characters imbedded into the 
             text for cross referencing purposes. Another independant
             reference system is used.

             From the text the user can press the F5 key for CODES or
             F6 for LOCATIONS. Whichever key is pressed the following
             action occurs:

             1... A 'window' is opened up over the top of the existing 
                  screen. 

             2... The user is prompted to select the required reference,
                  either a CODE or LOCATION, depending upon the F5/F6
                  selection.

             3... The user picks the reference from the list presented
                  ( as for data entry )

             4... The 'window' is closed and the the reference is placed
                  into the notes as follows:

                  CODE: The CODE letters are placed with a space after the 
                        last letter. If the CODE is a '-' (DASH), then 
                        the CODE DESCRIPTION is added to the text.

                  LOCATION: The LOCATION with the LOCATION CODE is added
                            to the text.

             NOTE: Any text added from these routines can be deleted or 
                   changed if required. The change or deletion WILL NOT
                   affect the cross reference capability.


In General: Whilst the capability of text search ( looking for certain
            characters in the text ) is powerful there is a basic flaw. 
            To find text by this method without dragging in wrong text 
            involves formatting the text entry to some extent.

            The method I have used ensures that free format text entry
            is not compromised and that no knowledge of how the data was 
            added previously is required.

            Within the search section of the NOTES, there is still the 
            ability to text search for non CODE/LOCATION references. 
            In fact including text search with CODE or LOCATION references
            makes the search ability even more powerful.


Large Notes: 3Mb is the current limit of the note size. This is a computer
             memory restriction. Theoretical limit is 1.5Gigabytes. In 
             real terms, memory runs out at about the 3Mb limit. This limit
             may vary up or down depending upon the program environment.

             Reality has NOTES at about 20 - 100K.

             NOTES are broken down into BLOCKS as described in section 5.08
             under the 'F5' heading. With NOTES, the BLOCK size can be 
             greater than 40K. Because NOTES are generally small, a new 
             NOTE is allocated to ONE BLOCK.

             To allow the NOTE to expand to the potential of a 3Mb size
             ( which could be up to 100 BLOCKS ) the following procedure
             has been adopted:

                   When a NOTE that is NEW or EDITED is being saved to 
                   memory, the LAST BLOCK of the NOTE is checked for size.
                   If this BLOCK exceeds 20000 characters the user will
                   be prompted to ADD a new BLOCK to the end of the file.
           
                   This new BLOCK allows the NOTE to grow and gives some 
                   flexibility in text entry.

                   The user has the option of typing "Y" or "y" for YES.

                   The default is "N" for NO. Nothing happens with this
                   option.

                   If the user types in "Y" or "y" and presses the ENTER
                   key, a NEW BLOCK is added to the end of the NOTE.

                   To provide some reference to the event, the new BLOCK
                   has the text "New Block" inserted.

                   If the new BLOCK is not required it can be deleted.
                   See section 5.08.

                   The cross referencing system is not affected by any
                   change to the NOTES size or by the number of BLOCKS. 

---------------
5.25 LOAD File:
---------------

This text transfer ability has been added to ease the burden of text
entry. The program transfers a file from disk to the program storage 
system. Once in the storage system, the NOTES loaded up are accessible
for further data entry and cross referencing.

To provide the cross referencing capability, the user must EDIT the 
NOTES loaded up and scan through the text looking for text to reference.
At each reference point the user can simply use the F5 or F6 keys to
pop up the windows as for data entry ( SEE 5.20 ). 

As the REFERENCE system adds text to the NOTE, the user will be required
to delete the extra text by using the backspace key.

To indicate a file that has been loaded by this method the note heading
has a "[TF]" attached. The letters indicate 'Text File'. 

The entire file will occupy ONE note heading, irrespective of file size.
Maximum file size for an upload is 3Mb.  Usual size would be about 250Kb.

NOTE: At present the only files that are acceptable for loading are 
      standard text ASCII files; generally those with a DOS extension
      of "TXT"

      As a general guide if the file can be printed without the program
      that it was typed in then it will be OK.

      ANY file can be loaded up into the text notes. However any file that
      is not TEXT would only produce garbage output or no output at all.

      Files created with Word Processor type programs would be unsuitable
      unless they are saved from the Word Processor program as 
      straight text or ASCII files. 


-----------------------------------------------------------------------
5.30  Find
-----------------------------------------------------------------------

This is the menu section where specific data is found. That is the 
user wishes to find information from a known starting point.

The following search or find titles are:

             Vehicle History      5.31
             Vehicle Group        5.32
             Vehicles from List   5.33
             Activity             5.34
             Register Notes       5.35
             General Notes        5.36
             List Jot Notes       5.37
             List ALL Vehicles    5.38
             List Reference files 5.39

             Options              5.399

--------------------
5.31 Vehicle History
--------------------

This is the section where vehicle histories are output. The original concept
had two sections: ADDing and VIEWing. The program code has been now modified 
to obtain this output from the ADD menu to allow faster data return.

The default for this screen is a single vehicle. This data is output to a 
file. The sequence for output is 

      CODE
      NUMBER

The following keys can be used in code:

         F2
         F4

         See CODE 5.10 for details

The following keys are available in the NUMBER field

         F2
         F3
         F4

         See NUMBER 5.11 for details

The main difference between the ADD menu and this section is the 
operation on a single vehicle. Within ADD, the single vehicle entry
initiates data entry, whilst in this section a vehicle history is
presented.

The history presented will depend upon whether the STEP history is 
ON or OFF. 

------------------- 
5.32  Vehicle Group
-------------------

This output is loosely defined. It is an attempt to provide a continuous
number group across various codes. For example the 'N' cars have a 
continuous number group of 1 - 53, with different codes for these
numbers. By informing the program of the codes required and the number
range, the program will put the output in NUMBER order with the CODE 
attached to the NUMBER.

The method is to ADD codes when prompted. When the code selections are 
done, ESC from the CODE field.

The program will prompt for a low and high number range, being start to 
finish numbers required. 

When the NUMBERs are entered, the program will find the data and present 
the list. The list will be in numeric sequence.

If specific CODES are NOT required, then the user can ESC from the CODE 
input immediately. When the number range is entered, the program will 
list EVERY code applicable to ANY number within the range.

ie: Number range 1 - 10 would give a list of ALL the CODES for Number 1;
all the codes for Number 2, etc., etc.

NOTE: Most useful function of this routine to date is the listing of
      unknown numbers in use by the program.

      ESC on the CODE input. Type '#.....' as the low number and 
      '#99999' as the high number. The program will then list out all
      numbers that start with '#' ( the unknown computer generated number ).
     
------------------------
5.33  Vehicles from List
------------------------

This selection allows the user to build a list of vehicles.

There are two methods of building a list:

   1... Start from scratch, add vehicles ad-hoc
   2... Use an existing list generated from a report

Method <1> is used for most ad-hoc reports.

Method <2> is used when the program has generated a list of vehicles
to a certain criteria. The only lists created at the moment are from the
'On Register' options in the 'Summaries' menu.

The screen for the 'Vehicles from List' contains an input field.
The input field has a default name 'WAG_LIST'. This is the database
name CREATED when this particular menu is run. It overwrites any
file called 'WAG_LIST.dbf' that is residing in the directory the program
is running from.

By <ESC>aping from the list, the program stops adding wagons to the file
and begins the history search. The Vehicle data is output in alphabetical
order, not in the order the vehicles were typed in.

To use the database list generated from another source, the user must
alter the name in the field to 'REG_LIST'. This will tell the program
to open the file mentioned. 
 
The history output will depend upon whether the STEP history option is ON
or OFF.

After all the data has been presented, the program will list out the 
wagons or vehicles it did not find. This may allow the user to redo part 
of the list, perhaps if the wrong code version has been given.

 

--------------
5.34  Activity
--------------

This is the section where a HISTORY or ACTIVITY can be 'pulled' out.
The user has the option of narrowing the search to 

      CODE: Specific Code
     GROUP: Vehicle Group ( Passenger, Van, Freight, etc ) 
    SYSTEM: Specific rail system
       ALL: All vehicles on file    

The output to file consists of the data entry found with the vehicle number.
A tally is provided at the end of the file.

This routine allows the user to specify a search for 'Body' or whatever
required. The search criteria can be joined to cover a list of ACTIVITIES.
In this way a search could be done for:

   'Off Register'
   'Scrapped'
   'Withdrawn'
   'Destroyed'

at one time.

  
---------------------
5.35   Register Notes
---------------------

The user can specify a 'Text search' of the NOTES attached to the data
entry of all the vehicles on file. The search is case insensitive, ie 
it searches text and ignores upper and lower case. It will pick up text
within a word however. 

At the end of the search, the output can be edited to remove all data the 
user did not want. This is a small price for searches covering thousands 
of records within several minutes; when the search using nornal book entry
would be impossible.

A text search example could be a list of vehicles that have the word
'Water' written in the notes; a reference to vehicles used in 
'Water Traffic' where the traffic may not be specifically given.

At present there are no parameters; ALL the notes must be searched. This was 
in line with the thinking of searching across all boundaries of code and 
number.

However a future development will be the ability to specify a code
or system etc.

The search produces the note in the same format as ACTIVITY search:

       Vehicle + data + Note

NOTE: At present the NOTE will be on the SAME line as the DATA irrespective
      of the line length. With a line length of 512 characters output 
      would need to be edited prior to printing.
    

---------------------
5.36    General Notes
---------------------

This menu choice is used to search and printout the notes generated 
by ADD NOTEs and LOAD file.

To search the notes there are several choices. These are available from a 
menu. The menu has two parts. The top portion consists of search criteria
choices. The bottom portion consists of producing a search and various
NOTES operations. The menu is described below: 
 

       CRITERIA OPTIONS
       ================

    1..Date        

       If this option is NOT selected, then the entire NOTES are checked.

       If selected then the user must enter a start date and an end date.
       The date is MM/YYYY only. To assist with a single date, the TO date
       is copied from the START date.
  

    2..Code

       If this option is NOT selected, all NOTES will be checked. 

       Only a single CODE can be searched for. To search for a specific
       vehicle the best way is by CODE criteria PLUS a text search for the 
       NUMBER. The results may have to be edited to remove data that was
       found but not required.

    3..Location

       If this option is NOT selected, all NOTES will be checked.

       Only a single LOCATION can be searched for. 
 
    4..Text

       If this option is NOT selected, the search will be based on other
       criteria.

       The text search is a quick character search method which ignores
       case, ie case insensitive. Short text may be found with other
       letters inside a word. For example it is possible to search for CODE
       letters by using just the text search. However, searching for 'I' 
       will find all words with 'I' in them, resulting in nearly all the 
       notes being displayed.
 
    5..Reference No.

       This choice allows the user to specify NOTES to output to a file.
       The user must type in a NOTE reference. The reference typed in will
       appear under the field to show the last number entered. This way
       multiple numbers can be entered. To end the typing press <ENTER> 
       on the blank field. The list is sorted by NUMBER.

       The program will process the list one by one and output the 
       NOTES to a single file.
 
       This option has been provided when the user may have found several
       NOTE headings from a search and wishes to view the respective NOTES. 


       SEARCHING OPTIONS
       ================= 

       Note: If no criteria is provided, the searching will not start.

    A..Show TEXT

       When the search is ready to begin press <ENTER> on this option.
       The TEXT of every note that the search found will be output to a 
       file.

       To the right of the menu choice, a running display of the current
       note date is provided. This allows the user to see the approximate
       rate of searching and the progress made.

    B..Show HEADINGS

       When the search is ready to begin press <ENTER> on this option.
       The HEADINGS of every note that the search found will be displayed
       only.

       In anticipation of large searches and too much text to view, the 
       headings option has been provided. The search would then become 
       a two step process:

       1.. Conduct search based on search criteria. Search to produce
           a list of NOTE headings.
       2.. From the headings list select the NOTES that apply.
           From the REFERENCE No. menu choice, type in the list of
           NOTE numbers and obtain the text.

    C..LIST notes

       Select this option to view all the note headings. The notes 
       are indexed by date, so all notes will appear in date order. 
       The NOTE REFERENCE (Number) if not significant, so will not be in 
       order.

       NOTES that have reference numbers but are NOT being used are shown
       as 'Note not in use'. This shows the user the NOTES available for 
       re-use. These notes are re-used by specifically using the NOTE
       REFERENCE to add data or by accepting the default computer 
       reference when adding a new note. 

    D..EDIT note

       The user can specify a NOTE REFERENCE to add data to or EDIT.
       The EDIT facility has been provided with this menu to avoid 
       returning to the main menu to select ADD NOTES.

    E..C A N C E L

       After every search the criteria are reset to zero. If the search 
       has not been conducted the user is unable to reselect a 'used'
       criteria. The CANCEL option allows the user to reset the search
       criteria to zero before a search, in case of mistakes.

----------------------
5.37    List Jot Notes
----------------------

With the option of the F10 JotNotes, there must be a facility to view 
and output the notes to file. With this option the user can 
specify the jotnote to list. The note goes to file.

TIP: The file created can be loaded up into a note for temporary storage.

-------------------------
5.38    List ALL Vehicles
-------------------------

This was a facility originally provided to obtain a list of all vehicles 
in the program. The program begins at the top of the file and checks each 
vehicle and number. By this method, unreferenced vehicles can be traced
or deleted. 

To facilitate speedy output there are now 3 option available. There 
is the choice of specifying a code. If ESC is pressed to indicate 
that a code is not required a system list will be shown. 

The choices are:

1.. Press ESC on CODE input and ESC on System table. This will 
    inform the program that the user wants to see ALL vehicles,
    starting from the top of the list. The program will then proceed
    alphabetically through the list until the end of file. At any time
    the ESC key can be pressed to halt the operation. 

2.. Select a specific CODE. The program will find the CODE in the 
    database. It will proceed toward the end of the database as per
    Item 1. This allows the user to split a lengthy operation over several 
    smaller bursts.

3.. Press ESC on the CODE and the select a System from the table.
    The program will only list all the vehicles for the requested
    system. The only option here is a complete list in one hit. It cannot
    be restarted once the ESC key has aborted the operation.


There is future potential for this routine to only show unreferenced
vehicles. This sort of information sits in the database after the user
has experimented with data entry or changed the CODE VERSION reference 
file without changing the corresponding data. Neither action is 
catastophic. It simply means there is space being taken up in the 
database system that is not being used.

This sort of unreferenced data can cause statistical errors when 
producing tally summaries for example. The 'vehicles' are not visible
during normal program activity but the data is used when producing 
certain summary outputs.
 
----------------------------
5.39    List Reference files
----------------------------

In one 'hit' the user can view all the reference files in use.

The reference files shown are:

   Histories
   Locations
   Systems
   Vehicle Types

The CODE references are covered by the F2 key when selecting CODES.

The CAR NAMES are covered by the F4 key option in NUMBER.


---------------
5.399   Options
---------------

There are several program functions which can be configurable by the user.
As they are rarely used, they have been placed within this 'list' at the 
bottom of this menu.

The options are:

  1..Form Feed

     Allow the user to immediately FORMFEED or EJECT the paper in the 
     printer.

  2..Set Top of Form

     This resets the printer and initialises it to standard settings.

  3..Set MOUSE [ ON | OFF ]

     This option is UNAVAILABLE. 

     There was some interest in running the program with a mouse but the 
     work has not been done yet. The program is mainly text entry anyway.

     The option in the table will change but the function does not work.

  4..Unknown date:[ "circa YYYY" | "  /  /    " ]

     The choice will toggle between two options. One option has the 
     unknown date displayed as 'circa YYYY' whilst the other more correctly
     shows no date at all as in '  /  /    '. 

     The unknown date is representative of data that has no specific date
     attached. Whilst not displaying the date is correct, the advantage of 
     the 'circa' date is that it assists data entry and aids the 
     deciphering of output.

  5..Editor size

     This feature is no longer in use, though the change is possible.
     It has been left in for future problems that could occur.

  6..Debug

     This is to assist the programmer in checking what the program is 
     doing. For normal use it is 'OFF'.

     If the user turns it 'ON' then strange occurrences will happen.
     Undocumented and unseen program halts could occur.

     NOTE: If the program has to set up default values because it is
           unable to find screen color instructions and other numeric 
           data, it will create a new default set of values. 

           To indicate that this event has occurred, DEBUG is automatically
           set ON.   

  7..Unknown Wagon

     The unknown wagon display is toggled between
     '#..123' and '     -'. The '-' (dash) is more correct but to assist
     vehicle tracking the actual computer reference works better.

  8..Check Number

     This option tells the program whether to prompt if an alpha character
     is in the number. 

     'No' indicates NO checking.  'Yes' says check.

  9..Step History

     There are two history output options

     LOCAL (Step OFF) and STEP (Step ON)

     Except for some circumstances, the STEP 'ON' output is the most 
     informative.

 10..Repeat Data

     For STEP history output each line is described by the vehicle
     at the first part of the line. 

     With 'Repeat Data' set to ON ( the default condition ), each line 
     is described.

     With 'Repeat Data' set to OFF, the first line only of each vehicle
     is described. Any remaining history for the same vehicle does not 
     show the vehicle.

     This option is provided for user preference.

 11..Show Version

     This option allows the user to show output in book entry style.
     
     The 'Show Version' option set to 'Yes', each vehicle has the 
     version with the code and number, as in 'M   27.VA'

     With the option set to 'No' only the code and number are displayed;
     ie 'M    27'. 

     This Code description list after the output remains unchanged.
 
     The ADD Info and Edit box remains unchanged.

     It is up to the user to decide whether this option has value, as 
     there may be difficulty at times matching codes to the description
     list.


-------------------------------------------------------------------------
5.40    Summaries
-------------------------------------------------------------------------

With the amount of data entry involved there is now the potential to 
use the information stored. As the data is tightly formatted the scope 
what can be done is probably unrealised. 

However, within this menu there are several basic summaries which
I consider to be of value. The program does not have the flexibility 
of adhoc searching and use such as from a database program. What I have 
organised is a group of basic search/summary options which can provide
some information. 

As it is impossible to provide one option that will provide all answers, I
`have set up a set of standard summaries. A complex task summary or
search can be done by breaking down the request into several components.
Each component will provide part of the answer.

By normal methods, the requests provided here would be impossible or 
may take months of work. By the methods I have used, the time taken to 
arrive at an answer is negligible.

-------------------------
5.4.1    Activity by Date
-------------------------

This option tallies up all the items of data for each vehicle in the 
database. A table is produced listing a tally of activities by year for
every year. 

There is no option to request a specific year. As the program must search
the entire database anyway it is easier to do the whole lot. If the 
user requires a specific year or year block, then edit out the unknown
years from the output that has been assembled. The time taken to 
produce the table plus the time taken to edit out the data not required 
is still much less than the time taken to create the figures manually.


--------------------------------
5.4.2    Activity by Code & Time
--------------------------------

This option looks at the amount of data ( ACTIVITIES ) that are recorded
for a specific time frame.

The user nominates a start and end year. The program then finds all
activities that occurred within the given times.

The output is ordered by

         DATE
         ACTIVITY
         VEHICLE


The main use of this routine was to see how busy certain years were in
regard to conversions, scrappings, etc and obtain vehicle numbers from the
list.

NOTE: The list will only show vehicles if an event occurred for that vehicle in the
      time frame. The vehicle may still be running in the years given but 
      may not be shown if no activities were recorded for it.

----------------------------------
5.4.3    Activity for Code, 1 year
----------------------------------

From the Tally Table option 5.4.4 a list of activities is tallied and
recorded against the years. To find the vehicle numbers that created the 
tallies use this option.

Specify a year to search and the code to search. The output will be ordered
with activity groups and each group will have a list of vehicle numbers.

------------------------------------
5.4.4    Tally Table for single Code
------------------------------------

The 'Tally Table' is a quick method of creating a table that groups all 
the known data about a class or code. The data is assembled across the 
page with activities and down the page for YEAR dates. Only the years where
events occurred are shown.

From the table, the user can see the basic trends of construction, 
scrapping or modifications applicable to the vehicle group.
  
--------------------------
5.4.5    Register for Date
--------------------------

This would perhaps be the most important summary. The program has the 
ability to 'look' at the data and determine whether the vehicle is 
'On' or 'Off' Register. The program cannot determine if the vehicle 
is in actual traffic; it may have been in storage for years. However
within a small timeframe ( say 60 minutes for 77,000 vehicles running
a 486 ) it is possible to return a list of vehicles that were 'On Register'
for a given Year. It is possible to to look at MM/YYYY or DD/MM/YYYY but a 
lot of the information is Year only or 'Best Guess' which tends to put a 
'drift' into the numbers.

NOTE: This summary is only valid if ALL the data for ALL the vehicles has 
      been typed in. If less than the full data is available, then the 
      program inaccuracy must be recognised. The list thus created must be
      edited to remove spurious data.

To assist the program the CODE VERSION list is used as an aid. Before
starting to look at each code the program inspects the CODE DATE and the 
CODE LAST_ON date. If the year to be searched is outside of these dates
then the code and entire number group is skipped.

In some ways this allows the user to 'Finish' a code before all the data
has been keyed in. If the LAST_ON entry is anything other than a valid year
then that CODE and number group are searched. If the CODE date is not a
valid year, the CODE and number group are checked.

The two parameters required for the routine to work are

    1.. Date to check
    2.. System to check. The default system is the system entered in the 
        UTILITIES 'Set up' option.   

The output is by CODE and VERSION description. Underneath, the description
will be displayed the numbers found that were 'On Register'. At the bottom
of the list will be a grand tally of Codes, Vehicles and Underframes found.

NOTE: As yet the program does not show the vehicle ID against a number 
      found. ie if the 2nd 'I 6' is found the list will only show
      '6' NOT '6(2nd)'. This may be a future development. 

CAUTION: As yet the program has not been modified to check Vehicle ID's.
         Instead the program checks the TOTAL number of histories 
         presented. This may reduce the accuracy. Some testing would be
         advisable. Correct checking will be a future development.        

----------------------------------
5.4.6    Register for Date (Codes)
----------------------------------

For users who are interested in a CODE list only without spending time
checking ALL the data, this option has been provided. This option also
has value for those who have correct CODE data but specific vehicle data
is missing.

The program checks the CODE VERSION list ONLY. It uses the DATE and 
LAST_ON year references. The user inputs the year and the program
generates a list of codes running AT or DURING the year. If either
field has characters that do not represent a year, the CODE is 
automatically included.

The user should check and edit the list for accuracy. As the data is 
provided reasonably quickly some minutes spent editing is far shorter 
than current methods of generating these type of lists. 

----------------------------------
5.4.7    Register for CODE by DATE
----------------------------------

This option allows the user to select a specific CODE and produce a 
register check for a given date. The option saves the user from 
producing a list of ALL the vehicles in a system.

------------------------
5.4.8    Location Resume
------------------------

See example 7.06

This routine was created to derive information about a specific LOCATION.
By LOCATION, this is taken to mean 'Builder' or 'Workshops' as well.

As LOCATION like most of the other 'fields' cannot be indexed, the entire 
data must be inspected. As the entire data must be traversed, ALL applicable
information for the LOCATION is presented. To narrow the 'search', the 
user can simply edit the data ( ie delete what is not required ) to suit.

The information is provided in the following order:

            DATE
            HISTORY
            CODE
            NUMBERS

------------------------------
5.4.9    Audit for single code
------------------------------

See example 7.07

The beauty of the program and this sort of data entry is the ease of use
and the adhoc storage access. The 'black box' does not change shape or grow
bigger. However there is one key issue worth describing. This is the 
'auditing' of the data to hand.

With book work, the user will always be referencing and browsing the data.
In this way there is an intrinsic knowledge of what information is still 
required to be collected. With the computer this option is not available.

There is a way it can be done from the program but this involves printing
out all the data for a CODE and visually checking the information. 
This could be very tedious. 

What this option does is look at the data for each vehicle. What can be 
checked from the information provided is quite simple and of much value.
The program uses the following information to make an assessment:

   ... Where the vehicle came from ( Built New, Converted from, etc )

   ... Where the vehicle went to ( Scrapped, Converted to , etc )

Other information cannot be determined with accuracy and so is ignored. 
This is information such as references, photographs, traffic, modification,
etc. The data is too varied to accurately quantify.

The table below shows how the Audit output is arrived at:

         ----------------------------------------------
         #  FROM          TO            Output Response 
         ----------------------------------------------

         1..YES           YES           OK
         2..YES           NO            To?
         3..NO            YES           From?
         4..NO            NO            Misc
         5..No Vehicle                  No output             

Line 1: The program has detected where the vehicle came from and where 
        the vehicle went to. This condition is enough to assess that the 
        SCOPE of the vehicle identity use is known and therefore complete.
        The audit response is 'OK'. Obviously all the known data for the 
        vehicle may never be collected. However the basic lifespan data of
        the vehicle is known. If this lifespan data is known for the 
        entire CODE or class, then searching for specific From/To data
        can cease. Data searching and addition for this CODE would then be 
        relegated to second place.

        In addition to the 'OK' a single right arrow ( '>' ) is used to mark 
        the response graphically. 

Line 2: The program has detected that it knows where the vehicle came from
        but has no information about where the vehicle went to. The 
        output response is "To?". This is a way of saying that this 
        information still needs to be collected.

        The graphical response with the text is two right arrows ( '>>' ).

Line 3: The program has data that shows where the vehicle went to but has 
        no information about where the vehicle came from. 

        The response is 'From?'.

        The graphical response is three right arrows ( '>>>' ).     
         
Line 4: If the data for the vehicle does NOT contain either "ON REG" or
        "OFF REG" information the response is "Misc" for miscellaneous
        data.

        The graphical response is ">>>>Misc"

Line 5: The only way to assess whether a vehicle is missing from the list
        of vehicles to check is to know the number group of the CODE group
        or class in question. To know the number group requires information
        which may or may not be available to the user. In some cases the only 
        way to gain the information is if the data in the program itself.

        This capability of number group checking was tried but removed. Apart
        from simple single run number groups, there was no advantage to be 
        had from the programming effort.

        To detect missing vehicles from a class or CODE, then the F2 option 
        from the NUMBER input is the best method.

NOTE:   1.. At present the routine does not look at the Vehicle ID to 
            determine the To/From/OK output. Therefore until this development
            there may be some 'drift' in the intelligence of the routine.

        2.. The assessment is made from the Activity. However the routine 
            FAILS when a history is added that has TWO vehicles going to 
            make ONE vehicle. The routine may also FAIL when the vehicle 
            is removed from service with similar histories but different 
            dates OR when the data is non consecutive. 

            The FAILure is only in the assessment, not in a program 'CRASH'.
  
            The use of 'Ex/P' and 'To/P' will eliminate the problem.
            However the user will have to make an assessment as to which
            vehicle portion is most significant for history tracking.
  
----------------------------------
5.4.10    Timeline for single code
----------------------------------

See example 7.08

The TimeLine routine has been provided as a historical tool. This option
takes a number group and places the 'On Register' year graphically along
a line. Each year represents a position along the line.

The start year on the line is determined from the CODE DATE year in the 
VERSION file.

If all the data for the class construction is available, then the entry 
dates will form a 'graph' pattern. However if data is missing because of
transcriptions from older books or other data anomolies, then this can be 
graphically seen as inconsistent data along the lines. 

Specifically the routine was designed to show the date to service for 
I wagons of the Victorian Railways. The TimeLine clearly shows the 'missing'
vehicles which were built but without any Register data available. 

A side effect of this particular search idea has been the graphical display
of poorly built vehicles in the 1870's. Until this display, this information
was only alluded to. The data clearly shows groups of vehicles being 
replaced within 15-20 years when the average age of vehicles for the time is 
20 - 50 years.   

-------------------------------------
5.4.11    Class Nos. - Accurate tally
-------------------------------------

The total number of vehicles on record is an interesting question for 
those involved in data entry. Whilst the total allows the user to play a 
'number game', it only represents the references not the quality or 
quantity of data attached to each vehicle. The quick summary provided from 
the 'Utilities' menu only looks at the size of the database which holds 
all the vehicle references.

As many vehicles have one, two or three identities for a vehicle the tally 
presented is not accurate. As well, there is no breakdown of the figures
for passenger cars, vans, vehicles or locomotives. Even then, there is 
no breakdown by system.

This option allows the user to select a specific code to count or 
starts the program to check ALL the vehicles on file. At present there is
no method of halting or restarting part way through a count session.

In either case, the program looks at each vehicle and counts up the 
number of identities found. The default value for any vehicle found  is 
obviously one. The minimum count done is for a class or CODE. The counting
done for the CODE is:

         ... Number of identities found
         ... Number of unknown vehicles

The totals are placed into the CODE VERSION reference file for storage. At 
the same time, the data is output to file for viewing. 

NOTE: There are times during data entry when vehicles did not exist and 
      require some explanation. Two examples are:

      1... The NUMBER is blank in the Register because there was no vehicle
           at the time. data entry for this vehicle is simply

           XYZ 123  ... NO DATA in Register      

           This quickly gives the viewer a reason for no vehicle.

      2... A vehicle that is mislettered can be referenced by the actual
           identity AND by the 'real' vehicle with a note of explanation.
 
           ie a VBBX was lettered VBAX by mistake. The photograph of the 
           'VBBX' can be noted as 'Lettered as VBAX'. In the VBAX group
           the incorrect vehicle can have a note attached as 
           ' "VBBX" lettered by mistake '.

      To override the counting process a special character must be 
      added to the ID field. The character is a '-' ( DASH ). However
      when the '-' is displayed it is the same as the 'blank' display.
      This is to maintain the data accuracy on output. 


NOTE: At the end of each CODE, the tally of vehicles is placed into the 
      CODE VERSION file. If the user presses the ESC key to abort the 
      routine, the tally up this time is placed into the VERSION file.
      As this may be a short count, the tally presented will not be accurate
      nor will the summary as in 5.4.12.
 
----------------------------------
5.4.12    Class Nos. - System wide
----------------------------------

This output provides a list of vehicle totals for each system.
Within each system total is a break down by all the types in use.
There is a sub total for each system. At the end of the report there 
is a GRAND TOTAL by type which is then totalled.

PLEASE NOTE: This summary is produced from the VERSION reference file.
             The figures are totalled from all the previous 'Class tallies'
             done, whether by CODE or across the database. The routine 
             simply tallies all these figures and presents a table.

             Therefore the most accurate GRAND TOTAL possible will be 
             immediately after the most recent System wide tally as 
             described in 5.4.11

---------------------------------------------------------------------------
5.50      Edit
---------------------------------------------------------------------------
                        =======
                        WARNING
                        =======

The direct editing of the databases must be done with care. The 
responsibility of inadvertant data loss is with the user.

Character based fields in most cases can be reconstructed. However
the fields that are FOUR (4) characters wide and have funny graphic 
symbols MUST NOT be altered. The data in these fields is created by the 
program and cannot be entered manually. 

The only changes to these fields required in editing are to place 
BLANKS into the field, thereby cutting the 'pointer' reference between
the subject and the data. Subject being vehicle or note. 

   =====================================================

To facilitate program release it was decided to adopt a quick fix for 
direct database manipulation. Each routine that provides direct access
has been marked 'DA' in the menu. The 'DA' has TWO MEANINGS:

   1.. <D>irect <A>ccess

   2.. <DA>NGER!!!!!!!!!

       The DANGER reference is because the data can be altered WITHOUT
       validation. ie, the program will NOT cross check to see if the data
       altered is valid for the field. The Upside is that if the user 
       is aware of the problem, it is a simple matter to change it.


The edit procedures within each table are essentially the same. They are
dBase like in action. Below is a description of the key strokes that can be 
used within the tables:

              PgDn: Go down one page
              PgUp: Move up one page
          Dn Arrow: Move down one record
          Up Arrow: Move up one record
Ctrl -  Left Arrow: Pan across the database fields to the left.
Ctrl - Right Arrow: Pan across the database fields to the right.
           <ENTER>: On a field allows user to add data.  
               ESC: Exit from the table and return to the menu.
               DEL: Marks the record as <Deleted>. The DEL key toggles 
                    this function. If DEL is pressed on a <Deleted> entry
                    the mark will be removed. Entries marked as <Deleted>
                    will only be physically removed from the database 
                    when the "PACK References" is initiated from the 
                    "Utilities" menu.

     NOTE: All the data will be saved even though the ESC key has been used.
           To ensure the data has been saved, move away from the field 
           just altered to go to another record. This step will ensure 
           the data is added.
 
---------------
5.5.1  DA-Codes
---------------

This option allows the user access to the CODE VERSION list. On entry to the
screen the user is requested a CODE. This CODE request is for DELETION
purposes. If a a DELETION is NOT required, ESC from the field.

If a CODE is selected, the program will request confirmation of the 
DELETION. The default is 'N' ( No ). If the request is 'Y'es the CODE 
will be marked as DELETED in the database. No physical deletion will 
take place UNTIL the 'Pack REFERENCES' option is selected from the 
'Utilities' menu.

As many codes as required may be selected for DELETION. Such may be the 
case in setting up TEST codes to try out the data without distorting 
valid historical information.

When the user presses the ESC key on CODE, the 'Delete' list is exited
and the VERSION table is displayed.
 
In the VERSION table, a CODE may be UNDELETED by pressing the DEL key on 
the item marked as '<deleted>' at the top of the table.

This EDIT table is valuable for adding information such as:

... Altering spelling or phrase of CODE description
... Adding the ERA date
... Adding a COMPLETE'd date
... Adding an AUDIT'ed date
... Resetting a field which is incorrect.

Pressing ESC in the table will return the user to the EDIT menu.

-----------------------
5.5.2  DA-Owner Systems
-----------------------

The database for the owner systems has been pre-filled with basic 
information. This was the quickest way to allocate all the allowable 
symbols used to represent each system. 

Whilst the potential with a one character field is 255 characters, care
must be taken to aviod graphics characters and control sequence characters.
The choice was restricted to keyboard charcaters that could print on any
printer and not provide a visual clash with the surrounding data. As such
the allowable number is 84, the same group of characters used by the 
VERSION describers.
 
The edit table allows the user to alter spelling or phrases.

NOTE: An attempt to change the meaning of a reference in this file will
      cause the database to fail to describe the correct system. This is 
      a REFERENCE file which the data looks at.

      The database table only is altered, not the refernces to them in the
      main datafile.  
  
---------------------
5.5.3  Location names
---------------------

This edit choice allows the user to edit in a controlled environment. The
routine will check what the user has done and decide whether the operation 
is valid. This may be DELETE a location or change the spelling, for example.

-------------------
5.5.4  DA-Locations
-------------------

The DA-Locations was provided as an escape hatch. In some cases the option 
above will not function properly on incorrect data. If the data is known 
to be incorrect, the edit/browse table in this option will allow the 
user to change the REFERENCE file.

From the table select the item to DELETE and press the DEL key. This will mark 
the record for deletion the next time the 'Pack REFERENCES' is used. 

---------------
5.5.5  DA-Names
---------------

At present this is the only way to edit Car Names.

Car Names are stored as a sentence or string of characters. As there is 
not enough room in the NUMBER field, the 'number' stored for the car 
is composed of three parts:

      Character   1: "@" sign. Informs program that the NUMBER is actually
                     a car name
 
      Character 2-3: The first two letters of the Car name. This is used 
                     to index the car name alphabetically. 

      Character 4-6: A three character number which the program uses to 
                     find the Car Name.

When the DA-Names option is pressed, the user is asked for a CODE. The 
CODE request is for the group the car is located in. When a code is 
selected a small table is presented which shows all the car names that are
allocated to the CODE. 

Each line is one sentence. The first three characters are the number used
to find the Car Name and the remaining characters ( 4-20 ) are actual car
name description used. Along the top of the box the character locations are
indicated. 

The 'NNN' is a reference to the reference number. This number must be 
right justified with the three character group.

           ie  '2' is actually typed in as '  2'.  

The 'ccccccccccc' reference is an indication of where the Car name is 
placed along the line.

The user can select the bottom line to ADD a new car name. If the user 
selects a line other than the last line, this sets the program up to
EDIT the existing line. The number or the text may be changed to suit
requirements. However in output of data, the car name may not be found.

If the line selected is changed to all BLANKS, the Car name reference will
be deleted.


If a Car Name is not found during data output, the message

                'CCNNN>NONE' will be displayed, 
                where CC is the first two characters and
                NNN is the number reference not found.

Use this data to 'reconstruct' a Car name if the list has been destroyed. 

----------------
5.5.6  DA-Wagons
----------------

To enter the database the user must start with a CODE. This allows the user 
to start midway or close to the end of the database.

To start near the top of the database select a CODE near the 'A' or '-' 
group. Use the PgDn/PgUp keys to rapidly move to a specific CODE.

Access to this database is mainly to fix problems that may occur. Within 
normal program control the problem may no be solved due to program access.
To assist in overcoming the problems, the data can be directly accessed and 
modified. 

There are two main deletions which may be required to overcome the 
problem.

   1.. Delete the DATA: Blank out the data in the field DATA. The field holds
       4 blank spaces. 'Resetting' this field to 4 spaces will cut the 
       connection to the historical data for that item. 
       
       This deletion may be required if the program can access the vehicle 
       but is failing to pick up the data.

   2.. Delete the vehicle: This requires blanking out all the fields.
       In the CODE field six (6) special characters will be required
       to be added. Each of the six characters can be added by pressing down
       the 'Alt' key and typing '254'. This is the same as the ASCII 
       character 'chr( 254 )'. Fill the CODE field with this character.
       The program uses this information to re-use the location in the 
       database.


--------------------
5.5.7  DA-Note Ref's
--------------------

There may be occassion to manually edit the NOTE REFERENCE file. This could
be to blank out the REFERENCE or TEXT fields to cut the connection to the 
data or to manually "DELETE" a NOTE no longer in use.

The program recognises the following note as a disused note:

    1.. The REF_NO is set to "000000" (Database view)
    2.. The heading has "DELETED" as the left most text


The REF_NO (Reference Number or NOTE NUMBER) serves the purpose of
providing a unique ID to each note. There is no cross referencing used 
for the note numbers. Therefore the REF_NO number/characters can be altered
at will. The only caution would be to watch for duplicate use of the 
same character/numbers.  


TIP: There are two ways to view the NOTE REFERENCE file. The ways are 
     by DATE or by NOTE NUMBER.

     Notes from a search or LIST are output in DATE order. Therefore to 
     edit the database in DATA order, conduct a small search first.

     The Notes are found by NOTE NUMBER order. To edit the database in
     NUMBER order, request a specific NOTE NUMBER to ADD or EDIT.
     ESC from the routine if the Note was found or not. Go to the 
     EDIT menu and the database order will be by NUMBER.


NEW!: Certain types of programming information are now being accessed and 
      stored from this database. To indicate to the user and the program 
      that this is special data, the Reference Number will start with
      "" ( in ASCII - chr( 254 ). This will indicate to the program NOT to 
      display this 'note' on any list or use this 'note' during any search.

-------------------
5.5.8  DA-Histories
-------------------

In this option the user can add or change the Histories that have been set
up. This allows some freedom in customising the information base to suit 
the material being added.

New histories are only allowed to be added here. This was designed to 
prevent the user from hastily adding histories and quickly filling up 
the code list. The concept of the program is to group all 'like' histories
together so they are represented by ONE standard reference. Remember, this
program is storing the data for ease of access. 

The following fields are used to provide the program with information:

            CODE: Single letter code stored with the data

                  WARNING: Do not change the codes "X", "T", "x" or "t".
                           They have special meaning for the program.

                  The CODE choices are from the list A-Z, a-z. Maybe
                  other keyboard characters would work if more histories
                  are required.

                  CAUTION: Select an UNUSED CODE when adding a new History.

                   

       USE_TALLY: Used to count the number of times the routine is used.
     DESCRIPTION: This is the 22 character text placed into the outputs
                  to replace the single character code.
  
                  WARNING: "Ex", "To", "Ex/P" and "To/P" are only allowed
                           4 characters as the rest of the line after this 
                           is overwritten by conversion data during output.            

           GROUP: The program uses this data to seperate the data into 
                  groups. At present the two codes that are used in this 
                  field are "O" and "S" to represent "ON" and "OFF" 
                  Register entries. Whilst other groups are designated
                  they are not currently in use.

        LAST_USE: This is where the program stores the information for 
                  ALL the vehicles which have used this history. This allows
                  the program to 'remember' the dates, locations and notes 
                  of last use.

            DATE: Date of last use. This has been included to allow the 
                  program to 'clean out' data if it has not been used for 
                  a long time.  

                 
-----------------------
5.5.9  DA-Vehicle types
-----------------------

This allows the user to edit the Vehicle Type database. The user can add a
new type if required. 

The TYPE is a loose definition of vehicle characteristic. Again, the user
can define types if required.

Some types in use are BUS, RAILCAR, FREIGHT.

To record containers, a TYPE called CONTAINER has been set up. The 
vehicle is a 'Container' type complete with CODE and NUMBER. To complete
the segregation from rail 'vehicles' a system called 'Containers' 
can be set up. Again, the user can be the judge on how to do it. 
  

----------------------------------------------------------------------------
5.60    Utilities
----------------------------------------------------------------------------


5.6.1   Statistics
------------------

On this option a window will pop up on the screen. Several figures are 
available to show the user basic details. The table is also to show the 
user how the database is growing. The size or change in size can indicate 
to the user when it is time to 'CLEAN' and 'PACK'.

5.6.2   View Log Files
----------------------

Similar to the 'F8' key, this table shows all LOG type files only.
( ie any *.s* file ). From this menu the user can view any log file or 
rename it. Two important functions this menu has are:

1.. Rename the DATA_LOG.sav file for permanent storage. When the file 
    is renamed, a NEW 'DATA_LOG.sav' file will be created.
    The renamed old file can be stored elsewhere as an information backup. 

2.. As the LOG files are composed of raw unformatted data, they are hard to 
    read. To allow the transfer of information using the LOG files, an 
    'Expand' facility has been provided. The Expand option formats
    each line of the logfile and provides a reference list of CODES and 
    LOCATIONS at the bottom of the output.

    To preserve integrity of data, any notes in the 'DATA_LOG.sav' file 
    or equivalent will NOT be transferred. This is to ensure that 
    NOTES information is sent to others using the standard notes output
    options.
 

5.6.3   Audit/Log list
----------------------

This option creates a list of all the CODES. Shown in the list
are the AUDIT, COMPLETE and LOGFILE dates. To allow the user some method
of checking data these dates are provided. The dates can be changed in the 
EDIT menu choice for 'DA-CODES'.

NOTE: The logfile date is AUTOMATICALLY recorded, other dates are manually
      altered as required. 

The use of the dates is loosely defined below:

     AUDIT: The user has CHECKED all the data for the CODE. 
            Any discrepancies have been fixed or all problems noted for 
            future action. The date is an indication that all the data was
            found to be OK on the date shown.

            Therefore if a problem with data exists, the cause of the problem
            can be isolated to between the AUDIT date and the date of the 
            problem.


  COMPLETE: The user has checked all the data and has determined that all
            the "From" and "To" data is complete. Basically the CODE no 
            longer exists and the user has all the details about where they
            came from and where they went to. Other information can always
            be gleaned and updated.

            This is to inform the user the CODE data search is finished.

   LOGFILE: It is possible to download all the CODE data to a LOG file. This
            may be for a data transfer or to provide data security by having
            all data off-site in storage. It also allows the user access to
            all the information with a standard text editor, without use of
            the program.

            Every time a LOG file is created for a CODE, the date is recorded
            automatically. This is to assist the user in housekeeping. It 
            can also prompt the user to knowledge of the last logfile.
 


5.6.4   Code data to file
-------------------------

This menu option was created to download the data for one CODE to file.
The file describes the download and CODE description but does not 
generate a reference file. Each line of data is prefaced with an 'L:'.

This indicates the source of the data, ie LOG download.

The idea was to generate all the data and download it to textfile. This 
would preserve the data and get the data offsite.

TIP: Use this method of download to test the data to ensure Vehicle and 
     Data integrity. If there are problems with data entry use this routine.
     

     When sending information to someone always expand out a CODE LogFile.
     This creates the smallest possible file that shows all data and 
     references, without the verbose outputs from an F3 search.

5.6.5   Code Completion list
----------------------------

This option generates a list of all codes that do NOT have a COMPLETE'd
date. This list allows the user to see which codes have not had data 
completed yet. The user will be aware of the codes of vehicles that
will still be running in service and ignore them. 

 
5.6.6   Modify setup
--------------------

This choice allows the user change some basic parameters of the program.
Some of the parameters are:

... Alter the column width of the output
... Set the printer to standard text or compressed text output
... Provide the program with a default Owner System.
... Set the page length for output
... Set the line spacing on the page
... Set the default filename extension for the textfiles generated 


To access this data in raw format and view or change other data, the 
information can be accessed by going to 'Add-Notes'. The Note 
Reference Number is 'S1'. Where the first four characters are
ASCII chr( 254 ).

There are currently 6 lines of information, each one a BLOCK.

BLOCK 1: Standard screen colors
BLOCK 2: Menu colors
BLOCK 3: Text display colors
BLOCK 4: General program information
BLOCK 5: Text editor data ( not currently in use, reserved )
BLOCK 6: Printer setup codes

Other BLOCKS may be added in future versions of the program.


5.6.7   Vehicle re-order
------------------------

In a database environment, new records are added to the bottom of the file.
With an index in place, records that appear next to each other may in fact
be thousands of record apart. To reset the database so the records will be 
together, the indexed file is transferred to a new file and renamed. The 
new file is thus ordered correctly. This file is indexed and the process 
will repeat itself as new records are added. 

The main benefit of this transfer is a reduction in time during searches
and disk use is minimised.

The 'Statistics' option shows the percentage growth of the wagon file. 
This a a guide to show the user that only increases greater than 5 - 10%
or greater are worth re-ordering. With smaller increases there are 
minimal gains for the disk use required to perform the transfer.

When the transfer is completed the program stores the new file 
size. This number is used to show the growth of the file as new records
are added.

5.6.8   Pack DATA-Reg
---------------------

This routine packs the waste space out of the REGISTER.pjv file. This 
file contains data for the program, Jotnotes and all the notes with 
references.

This has been made a seperate operation from the wagon data to split the 
function. Depending upon user operation, one file may consistently 
get more use than the other. This way the seperate files get 'PACK'ed
when required. 

As the basics are the same see 5.6.9 for operation

See 5.6.9 for CAUTION note.


5.6.9   Pack DATA-Wgn
---------------------

As data is added and edited the main wagon information file (REGDATA.pjv)
will grow in size. As the file grows, there is often waste space in the 
file. This is caused by the program storing the data at another location,
leaving the old location unused.

To 'empty' out all the waste space this PACK routine has been included.

This routine will take a long time, depending upon the size of the 
file and the speed of the machine running the program. For example
a 77,000 location file will take more than 14 hours on an XT. Yet with
a 486DX33 this time will be reduced to about 1 hour. 

If the power fails or the program crashes, the data will not be lost.
The routine 'Packs' the data to a temporary file. If the packing is
completed and everything is OK, the old file is renamed with '.OLD' 
extension. The temporary file is then renamed to become the program file.
    
CAUTION: Once the program has finished, do not rename the 'OLD' file 
         back. This will cause the location references in the program 
         to 'double up' and cross linked records will result.


5.6.10  Pack REFERENCES
-----------------------

This option packs the main reference 'dbf' files. At the same time, the 
file is reindexed and the menu 'bubble' counter is reset to the program
default number. 

The user may wish to change the default value to either a higher or lower
number. This is done from the "Utilities"/"Modify Setup" options.

In either case, this option allows the value to be reset.
 

5.6.11  Clean DATA-Reg
----------------------


WARNING: Power supply problems are known to affect the peformance
         of the data storage system. If any 'Clean' routine is used
         there are chances most of the data will be wiped.
         
         Only use the clean routine when there are no known 
         problems and AFTER a backup has been done.  


This option interrogates the file and checks to make sure every item of 
information can be traced back to the program database files. In the 
event the information CANNOT be traced the routine will do the 
following:

      ... Display the location number of the data.
      ... Display the type of data found at the location.
      ... Print to file the information found.    
      ... The location will be NUL'ed.

The clean routine also checks for duplicate use (ie two sources 
incorrectly pointing to the same information) and that the data is 
of a valid type.

At present there are only two datatypes stored. Data checking is 
provided to filter out 'trashed' data other than that being used.

For best results this task is best done before 'PACK'ing the file.


5.6.12  Clean DATA-Wgn
----------------------

See WARNING in 5.6.11

This option perform the same task as 5.6.11 except the wagon information
file is checked.

For best results this task is best done before 'PACK'ing the DATA file.


5.6.13  Clear Audit dates
-------------------------

On the presumption that good housekeeping is practised, the AUDIT date 
will be used for all the CODES on file. To allow the user an easy way to 
start again ( ie cycle through the AUDIT process ) this option allows the 
AUDIT dates for the entire file to be reset. 

All the date will be reset to BLANK. This is the most effective date to
show codes that have NOT been audited.


5.6.14  Clear DataLog dates
---------------------------

In the same fashion as 5.6.11 above, the LOG files will be downloaded in a
cyclic routine. Once a cycle has finished and the next cyle is due to begin, 
the DATALOG dates can be BLANK'd out and reset. 

This clearly shows the user which codes have not yet been downloaded.

 
5.6.15  Reindex database
------------------------

Just in case some problems occur, this option allows the user to 
re-index all database files. The routine recreates the index file in the
process. 

If this action fails and the problem persists, the next step
is to delete all '.NTX' files. This can only be done by quitting the 
program, deleting the index files and starting the program again.

 
5.6.16  Shell to DOS
--------------------

This option allows the user to access the DOS prompt without quitting the 
program. As there is not much memory left it may not be possible to 
run any programs. However the option will allow the user direct access 
to DOS to browse or copy and delete files.

To exit from the DOS session, type 'EXIT' and press the <ENTER> key.

WARNING:  To avoid problems after exiting from the DOS window,  
=======   do not delete any files in the program directory, and 
          make sure the directory is the one the program is running from.
          If the user changes directory, the EXIT will NOT restore
          the old directory.


-------------------------------------------------------------------------
5.99      QUIT
-------------------------------------------------------------------------

The user can quit the program four ways:

   1.. Press <ENTER> on the QUIT option of the main menu.

   2.. Type the letter 'Q' on the top line menu. 

   3.. Type the key combination

        <ALT> 'C' ( Hold 'ALT' key then type 'C' key )

       This is an escape hatch to quit from the program. All processing
       will stop and all files will be closed off. Data in memory which
       has not been saved to disk will NOT be saved.

   4.. Turn off the computer OR 'CTRL-ALT-DEL'

       This action would be the most drastic. If at all possible, check 
       the disk light for activity and wait for the activity to cease.
       
       Under normal circumstances the only data that should be lost is 
       data in memory not yet saved. This has been tested and no data
       loss ( except new data ) has resulted.
 

			   
-------------------------------------------------------------------------
SECTION  6.00          Tutorial
-------------------------------------------------------------------------

This section still under construction.

If you wish to jump into the program select Add/Data from the menus.

You will be presented with an input field called CODE. Press 'F2' 
key to see a list of CODES already in the data.  Add one of these
in the input field and select the version from the list. Next box
is input field for NUMBER. Press 'F2' key again for a list of NUMBERs
that there is data for. At the NUMBER input field enter a number shown
and the HISTORY or DATA recorded for the vehicle will be shown.

NOW: Read the manual or experiment.




------------------------------------------------------------------------
SECTION  7.00          EXAMPLES
-------------------------------------------------------------------------

This section was mainly included to provide some data examples for the 
user to learn some of the data entry procedures.

With the demonstration program the following CODE VERSIONS are given:


Code.. Date...... Sys  V Type..... Description...................

A      ----       PVIC A Pass      F/Whl 1st Class car           
A      1859       VR   A Pass      F/Whl 1st Class Car           
AB     1859       VR   A Pass      F/Whl 1st/2nd car             
AWS    1902       VR   A Sdry      F/whl Workman Sleeper         
B      ----       PVIC A Pass      F/Whl 2nd Class, D&MR Co      
B      1859       VR   A Pass      F/Whl 2nd Class car           
BH     1895       VR   A Pass      F/Whl 2nd 'Holiday' car       
E      1925       VR   A Frgt      Bogie Flat wagon              
HR     1953       VR   A Sdry      Rolling Stock Branch Use      
S      1925       VR   A Frgt      Bogie Flat Wagon - 40t        
VZDA   1990       VR   A Sdry      Workshops Use                 
VZMA   1985       VR   A Sdry      Workshops Use                 
W      1910       VR   A Sdry      F/Whl Workman's Sleeper       
WS     1880       VR   A Sdry      F/Whl Workmen's Sleeper       
YH     1910       VR   A Pass      F/Whl 2nd Cl. 'Holiday' car   



=================
7.01 STEP HISTORY
=================

As STEP history can involve several identities, it is possible
to 'lose' the vehicle asked for in the search. To assist
output clarity and avoid verbose messages the vehicle 
first asked for ( either by user or program ) will be 
emphasised by an asterisk (*) next to it.

eg   Request for IT 

 I  ..... To IA
 IA ..... To IT
*IT ..... To XX       
 XX .....

If the vehicle does not appear on the left side, it will
indicate that the vehicle is referenced inside the text.
This is because the vehicle is at the end of the linking
chain and there is no data EXCEPT the conversion info.
To identify this vehicle in the list an asterisk is 
presented UNDER the text with an underline ( -------- )
beneath the vehicle within the text.

eg  Request for IT

 I   ..... To IA
 IA  ..... To IT
*             --- 

These examples are kept simple to aid explanation. 

================
7.02  VEHICLE ID
================

Some vehicles have had several identities attached.
Each vehicle history is presented as a paragraph of
data. For vehicles with multiple identities ( 1st, 2nd, 3rd,
etc ) each paragraph will be joined by a '[+' sign.
This clearly denotes histories joined by association
of similar CODE+NUMBER with the same description.

If histories are entered as different VERSIONS then 
1st, 2nd, 3rd, etc, will not be valid.
		
eg  Search for HR 24

 I    -  ... IA
 IA   -  ... HR
*HR  1st ...
[+                <--- 'joined by association'
 U    -  ... KAB 
 KAB  -  ... HR 
*HR  2nd ...



=================
7.03  Tally Table
================= 

           E    T    T    M    W    S    P    B
           X    O    R    O    K    C    H    L
                     F    D    I    R    O    T
       

1963       5    -    -    -    -    -    -   15
1964      33    -    -    -    -    -    -   14
1965      42    1    -    3    -    -    -    -
1966       -    8    -    -    -    -    -    -
1967x     10    1   10    -    -    -    -    -
1968       -    -    -    -    1    -    -   88
1969       -    -    -    6    -    1    -   83
1970       -    -    -    6    -    -    -   50
1971       -    -    -    -    -    -    -   54
1973       -    -    -    -    -    -    -   26
1974       -    -    -    -    -    -    8   64
1975       -    -    -    -    -    1    -   30
1976       -    -    -    -    -    -    -    9
1977       -    -   15    1    -    -    -   41
1978       -   20    -    2    -    -    -    4
1979x      -  348    -    4    -    -    -    -
1980       -  143    -    -    -    -    -    -
1981       -   35    -    -    -    -    -    -
1982       -    8    -    -    -    -    -    -
1983       -    1    -    -    -    -    -    -


========================================
7.04  Code Activity for <Year1 to Year2>
========================================

Example here 1900 to 1905:


1900  Built new             [AA    ] 1880 - VR   Steam Engine              
          532

1900  Ex                    [-     ] 1886 - VR   V & SA Joint Stock Cars   
           31     32     33     34     35     36

1900  Scrapped              [AB    ] 1857 - VR   F/Whl 1st & 2nd Class Car 
           46     52     54

1901  Built new             [-     ] ---- - VR   Special Stock             
      
        State Car 2
        State Car 3

1902  Built new             [AA    ] 1880 - VR   Sw/Door Bogie 1st Class   
            1      2      3      4      5      6

1902  Ex                    [-     ] 1902 - VR   Casualty Van              
            1      2      3      4      5

1902  Ex                    [AA    ] 1880 - VR   Sw/Door Bogie 1st Class   
          129

1903  Scrapped              [-     ] 1902 - VR   Casualty Van              
            2      5

1904  Ex                    [A     ] 1858 - VR   F/Whl 1st Class Carriage  
           24

1904  Sold (to)             [-     ] 1892 - VR   Rowan Steam Car           
            1      2

1904  To                    [-     ] 1886 - VR   V & SA Joint Stock Cars   
          020    021    022


================================
7.05  Summary for <Year>, <Code>
================================

Example for 1967, ELX wagons:


History: Ex                   

       
            2      3      9     14     31     40     43     44     45 
           46 


History: To                   

       
            2 


History: Traffic              

       
            3      7     15     24     44     51     63     69     71 
           72 


=====================
7.06  Location Resume
=====================

Example: NEWPORT WORKSHOPS

Note: Example truncated. Ellipsis (...) represent more data
      Dots between years represent data edited out of the example. 

1912  Built new            : ABW         8.VA ABW        10.VA ...
                             ABW        14.VA ABW        15.VA ...  
                             ABW        20.VA ABW        21.VA ... 
                             ACP        24.VA ACP        25.VA ... 
.
.
.
1920  To                   : AC        138.VA 

1927  Photograph           : -           3.Vo 

1929  Ex                   : ABM       164.VA 

1930  Into Workshops       : ABW        60.VA 

1930  Out of Workshops     : ABW        60.VA 
.
.
.
1959  Scrapped             : ABC         1.VA 

1960  Scrapped             : ABC         4.VA ABC        12.VA ... 
.
.
.
1967  Stored               : ABL        24.VA ABL        26.VA ... 
                             ABL        45.VA ABL        50.VA ... 


===========
7.07  Audit
===========

Example: History Audit for W, example truncated

>     OK:      1      2      3      4      5      6
>>    To?      7      8      9
>     OK:     10     11     12     13     14     15     16     17 ...  
.
.
.
>>    To?    465    466    467    468
>>> From?    479    484


==============
7.08  TimeLine 
==============

Example: I wagons

   100      >                     1875            1891
   101      >                           1881
   102      >        1862                               1897
   103      >        1862                         1891
   104      >        1862                               1897
   105      >        1862
   106      >                            1882      1892
   107      >                         1879        1891
   108      >                        1878          1892
   109      >                      1876            1892
   110      >                      1876           1891
   111      >                      1876            1892
   112      >                     1875            1891
   113      >        1862                          1892
   114      >                     1875            1891
   115      >        1862                          1892
   116      >      1860
   117      >      1860
   118      >      1860
   119      >      1860
   120      >      1860

-------------------------------------------------------------------------
SECTION  8.00          LOG FILES
-------------------------------------------------------------------------

The data stored by the program has a unique format that cannot be accessed
by database programs. To ensure data integrity, particularly when the
information may not be seen for years, several steps have been taken to
allow the user some comfort with data integrity.

Step 1: All data entry ( except JOT notes ) is recorded on a continuous 
        logfile. The logfile records start and end date/time for all
        sessions. Operation is transparent in that data entry speed is not
        reduced and normal search operations can still be done.

        All data in the logfile is considered RAW in that it requires 
        reference files to 'decode' the information. 

        To assist with integrity, all data that is edited is first
        saved to log file BEFORE the edit and again AFTER the edit.  


Step 2: The program can create a logfile of each class. This logfile can
        then be stored offsite or in a compressed file. The data stored
        is in RAW format. 

As can be visualised, with all codes on log file and the data entry log
running, no information is lost. The user can also accurately send out
all data entry for a given period, making data exchange much simpler.

Also any machine problems due to lost data not saved to disk can be quickly
extracted and redone.

The program creates the default logfile if one does not exist. If the
file exists already, new data is appended to the bottom. The file
is called "DATA_LOG.SAV" and is placed in a special sub-directory of the 
program direct

To use the logfiles, a special function has been developed called 
'EXPAND' which takes the RAW logfile and processes the entries into a
readable and useable form.

One plan is as follows:

 1.. Create a logfile for EACH code in use

 2.. When the DATA_LOG.sav file is about 500,000 characters long,
     rename it at the end of the month. Suggested file name is:

     DLYYMMnn.SAV where

     DL: Data Log file
     YY: Year of use
     MM: Month of use, zero filled ( 1 = 01 )
     nn: The number of months the file was active.

     eg  file DL941003: Created Oct 1994. The file is a log of the 
         last three months.
     
         In this way several logs per year are saved and stored. 
         Importantly, the logfiles are only saved as required.

 3.. At a point where all the codes have had a log file created, the process
     repeats. In this way all the data is at least saved/checked on a 
     1-5 year cycle depending upon the amount of data.

NOTE: 1.. At the top of each 'EXPAND'ed file there is a description list
          of the code letters used to start each line. 

      2.. When the 'DATA_LOG' file ( or derivative ) is expanded out
          the NOTES will not be included. It is felt that
          any NOTES that are written are better being distributed as a
          seperate project, rather than 'blanket' coverage.
 
-------------------------------------------------------------------------
SECTION  9.00          Archive / Backup 
-------------------------------------------------------------------------

On the distribution disk is a file called PKZ204G.EXE. This is a shareware 
program and must be registered. The file is self extracting and contains the 
PKZIP programs and manuals plus registration documents. 

To assit with a backup routine there are several files included which make
data saving very easy. All that is required is a routine and some 'floppies'. 

The routine will depend upon the amount of data entry. For a limited data
entry scenerio backups would only need to be done every 2-3 weeks. For 
intensive data entry, at least 1-2 times a week is advised.

The user must balance the time lost doing the backups with the time lost
re-typing in the data to get the program data back to normal. 

In any of the cases, the best method is FULL backup all the time. A typical
example would be to have several sets of floppies. Each floppy set
holds one backup and each backup is rotated through the sets. This ensures
that there is more than one set of backups and that each floopy is 
evenly used. At a set time each year ( or maybe twice per year ) one set 
is removed from the rotating set and placed in long term storage.

For a six floppy set the routine would contain the following:

     Set 1: Backup today
     Set 2: Backup last week
     Set 3: Backup last fortnight
     Set 4: Backup three weeks ago
     Set 5: Backup at  6 months ago 
     Set 6: Backup at 12 months ago 

Sets 1 - 4 would run a weekly sequence of 1-2-3-4-1-2-3-4-etc through each
year. As each floppy failed in use, then it would be replaced.

At nominated dates through the year, say end of financial year and 
new year, a set would be saved for each date.

Note: The backup timing will depend upon the amount of data entry. Perhaps
      a time guide could be backup after 2 hours of data entry. 

By the restoration of a Set to disk and the re-typing of the data log files
into the restored program, the 'new' program can be returned to 'pre-problem'
condition.   
   
Obviously the choice of routine is with the user. The decision must be 
made on the frequency of backups and the oldest data that needs to be 
retained.

NOTE: Before restoring data back to the disk, please ensure that the log 
      files are copied to floppy or another directory or are renamed.
      
      The process of restoring data will overwrite the existing files
      with the backup files. This will destroy the data that will be 
      used to reconstruct the database. 

The batch files to run the backup are:

REG .BAT: Invokes PKZIP to compress files to multiple floppies in <a:> drive.
REGA.BAT: As for REG.bat
REGB.BAT: As for REG.bat but <b:> drive is used.

These files are provided to assist the user. Other backup configurations 
can be attempted with more computer use.

The file 'RTF.LST' is the file list used by PKZIP when compressing. Other
files may be added to the list as required.


For those that are less regimented or the data entry is not regular enough
to involve constant backups there is an easier method. Still use the
same sets of floppies, BUT only perform a backup when there is a need to
do it. 

If there is continuous data entry, the perform a backup, say every 3 
days. If there is no work on the program for several weeks, do nothing.
ie only perform backups after program activity. For each backup, get the 
next set to use, to maintain the set cycle.   

Please Note: The PKZIP/PKUNZIP files are shareware and are distributed as 
             such. It is up to each user to REGISTER the copy provided.          


To restore the backup files from any floppy set the command:

           pkunzip a:reg     

can be used. The restore will place the files in the CURRENT directory
the user is in. If the user in the operating directory, take care 
not to overwrite files.

WARNING: Any restore of the program MUST restore all files, not just 
         some of them. 
             
-------------------------------------------------------------------------
SECTION  10.00          Technical Reference 
-------------------------------------------------------------------------
------------
10.1  NOTES:
------------

The program detects an unused note by the following method:

The NOTE field has "000000" in it and the HEADER has the words
"DELETED" at the left most position. 

If the user deletes a note and the reference does not say "Not used" or 
similar, then check the entry manually using DA Note-Ref's. 


----------------------
10.50  Problem Solving
----------------------

The program has been prototyped to this development. This means that the 
program has been written, run and crashed until it worked. As the development
has spanned many modifications and revisions the strategy of error correction 
has been neglected in favour of 'getting the damn thing working'. Thus any 
problem that has not been anticipated within the data environment has not 
been planned for. The program will 'crash'. 

These are the severe 'bugs'.  Minor 'bugs' ( Beetles? ) are where the 
screen does not clear or lines on output are too long for the 
page etc, etc, etc.

This section will explain the way the program works and if it crashes or 
fails the basic strategy to adopt.

There are four key areas where the program can fail:

   1... Indexes        ( a filename that ends with 'ntx' )
   2... Database files ( a filename that ends with 'dbf' )
   3... Datafiles      ( a filename that ends with 'pjv' ) 
   4... Crossed data   ( Notes info in DBF file and vice versa )

------------------
FAILURE 1: Indexes
------------------

If an index file is missing, the program will create it whenever the program 
restarts.

An Index problem can be caused by the program halting ( power down, etc )
midway through the creation of an index or a re-indexing process. The 
problem can be detected by the program not finding vehicles or vehicles 
that may be out of order. 

An index is a special file that has a list of items in special order with 
record numbers attached. When an item is found in the list, the record 
number is used as a pointer to the database file.

To create a new index file there are two methods:

   1.. Re-index: Use the 'Utilities' menu to re-index all files.

   2.. Delete all index files in the directory the program is in. This 
       is NOT POSSIBLE from within the program as all the files are 'Open'
       to the program. The user must quit the program and go to the DOS
       prompt. If a File Manager ( PCTools, Xtree, etc ) is available, use
       that.

       Delete all the files by typing 'DEL *.ntx' and <ENTER>.  

       Restart the program. The program will detect each index file that
       is missing and create a new one. This ensures there will be no data
       corruption inside the file.


If (1) does not help then try (2).

-------------------
FAILURE 2: Database
-------------------

Perhaps the greatest fear is that of trashing or corrupting the database
files. The file might by 4,000,000 characters long but it only takes 
one to be wrong to create problems.

The problem is to determine WHERE the data has caused a problem.

The best way to check if the DATABASE is integral is select a routine 
that will pass from the top to the bottom of the file. As most routines
use the DATA for the wagon, the routine has to pass through the database 
WITHOUT looking at the data. 

A routine that does this is the 'List ALL Vehicles' from the 'Find' menu.
This option produces a list of wagons and a list of numbers. The versions
are given. However, none of the data is touched, which helps to isolate the 
problem.

If the routine is successful then the problem may be isolated and found in 
the next section.

If the routine fails at some point then two events may occur:

   ... The program will CRASH
   ... The routine will have invalid data in the output.


To home in on where the problem is look at the vehicles that were output
prior to the crash/invalid data. The data can be looked at from the 
'DA-Wagons' option of the 'Edit' menu. 

From the table progressively scroll down the data to look at the data.
To get close to the problem, select a code BEFORE the problem and scroll
down towards the problem. Carefully note the RECORD NUMBER ( Recno() ) as
the inspection progresses. 

A corrupted database may have some of the following characteristics:

...Data in the fields will start to drift out of the columns into other 
   fields. ie The code may slowly drift into the number field

           Recno()  CODE.. NUMBER
            10000   IT        252      
            10001    IT        25 3
            10002     IT        2 53  etc

...Data in the fields corresponds to data that SHOULD be in another file;
   ie this is cross linked, a DOS reference problem. 

...The window will 'lock up'. Restart the program and repeat the process
   until the recno() of the problem is reasonably known.

...The window view of the database will suddenly jump to the end of the file,
   missing hundreds or thousands of records.

The action to take will depend upon the severity of the case. If the 
file is corrupted near the end of the file, the best method is to copy the
database to a new file transferring only nominated records. ie 
file is corrupted at record 12000. Copy records up to 11990 to another 
file. Basically start again with the new file. Rename the new file to the 
same name as the old one. Reindex and retry. Obviously there is going to 
be some retyping of data. Use the 'DATA_LOG' files. 

NEW!: To avoid the problems of determining the exact damage and the worry
      of correct data the best option is to cut the losses and restore 
      the entire data from backup. This ensures data integrity.


-------------------
FAILURE 3: Datafile
-------------------

The information contained in these files is a special format. Therfore it 
is impossible from this program to DIRECTLY access the data for manipulation.
Unlike DBF files it is not possible to go to a FIELD and correct the data.

As checking all the records would be a long task a simpler more methodical 
way can be tried.

Select the 'Code to File' option from the 'Utilities' menu. This option
downloads all the raw data to a file for safekeeping. Produce a code list
to check off during the operation. Progress down through the each code
and check the data being output.

The output will show invalid data or the program will fail. From the 
list, the user will be able to zero in on the vehicle or the data and 
delete them. Delete the data first and retry the vehicle. If there is 
still failure, delete the vehicle too.

The data can be deleted by using the 'DA-Wagon' option and replacing the 
DATA field with spaces. This severes the link between vehicle and data.


NEW!: As discussed, the best method of data recovery is to restore an older
      backup.

-----------------------
FAILURE 4: Crossed Data  
-----------------------

This problem relates to DOS and concerns the file structure mechanism. In
simple terms, information in each files is pointing to information in 
another file. The term is 'cross-linked'.

It is possible to reconstruct the files. However the time taken and the 
uncertainty of full data integrity shows the preferred course of action 
to be 'Restore From Latest Backup'

 
-------------------
10.8   DATA STORAGE
-------------------

For storage and simplicity the program uses '.DBF' files which are 
indexed. The database files allow the user to use a third party database 
viewer/editor in case of problems.

In recent times a move away from database files was required for the 
DATA attached to each vehicle. The system at the time whilst fast ( faster
than this system ) relied on pointer references which required a lot of 
space.

The current storage method is a table called an array. The array can 
grow and shrink as required. Not only can there be up to 4000 items 
in EACH array, but each item in the array can be up to 64K ( 64,0000 )
characters in length. 

The beauty of this system is the vehicle only has to point to ONE reference
to recover all the data. As well there is no wasted space, despite various
length notes or data.   

As recently found, this data storage method seems to be susceptible to power
surges. Whilst this does not seem to make the data storage as robust as I
would like, it should be recognised that that no data loss has been suffered
by me across 12 months of data entry.  


=============================================================================
SECTION 90.00        REGISTRATION
=============================================================================

As of 10/1995 the program is available as FREEWARE. This allows for the 
free distribution and use of the program. The existing 'cripple' routines
still exist which will limit the program if a registered user has copies
made without knowlwdge.

To provide a unique ID for every user, please email me at

      pjv@mpx.com.au

to register your copy. No dollars required.

For commercial interests, registration will be by negitiation.


       Peter J. Vincent
       5 Flintoff Court
       Mill Park, Vic, 3182

