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

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 key. 2/... Select a highlighted line from a menu box ( PICKLIST ) and press the 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 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 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 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 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 '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 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 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 3.. Type in Notes required 4.. Stop recording/editing Notes by Saving the note (F2 key or Ctrl-W) or 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 on the choice. If no specific System is required then press the key. All System matches will be presented. 2.. Vehicle Type: Select the Type from the list. Press on the choice. If no specific Type is required then press . 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 . 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 key on the selected item 2.. Press the 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 '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: + 'AA' + 'AB' + 'AC' " " to + '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 . To BLANK out the location to represent an unknown or NIL location, press the [SPACEBAR] then . 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 . 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 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 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 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 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.. irect ccess 2.. 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. : On a field allows user to add data. ESC: Exit from the table and return to the menu. DEL: Marks the record as . The DEL key toggles this function. If DEL is pressed on a entry the mark will be removed. Entries marked as 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 '' 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 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 on the QUIT option of the main menu. 2.. Type the letter 'Q' on the top line menu. 3.. Type the key combination '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 ======================================== 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 , ================================ 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 drive. REGA.BAT: As for REG.bat REGB.BAT: As for REG.bat but 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 . 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