User Manual Version 6.08f 7/1996 *********************************************************** * Notices * *********************************************************** **************************************************** Copyright: --------- This program remains the copyright of the author, Peter J. Vincent. All Rights Reserved 1996 Program Distribution: -------------------- As of 10/1995, this program is being released as FREEWARE. The distribution disk can be freely passed around. 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 asked to contact the author. PATCH files: ----------- The main DOS program file 'reg5.exe' is always being modified; either to remove bugs or add new functions. To upgrade from an old version can be done several ways. The easiest way is to watch for a new version release and download the entire release. The only files that need to be unpacked are the 'reg5.exe' file and the 'regman.new' manual file. Unpacking the entire lot in the same directory may accidentally overwrite files already in use. Data WARNING: ------------ The program has been found to be prone to power supply problems. It seems to relate to power fluctuations that may eventually cause the computer to power down or reboot. The use of a backup strategy and the 'LOG' file that is generated will allow for a speedy recovery. See BACKUP =*=*=*= Page 2 =*=*=*= *********************************************************** * User Registration * *********************************************************** **************************************************** As of 10/1995 the program is available as FREEWARE. This allows for the free distribution and use of the program. The program no longer contains any feature that cripples. Whilst the program is FREEWARE, the author would like users to establish contact. This is to get some feedback about use and spread of the program. The author can be contacted by email at 5 Flintoff Court Mill Park, Vic, 3182 AUSTRALIA Email : hobby@pjv101.net WebPage: pjv101.net =*=*=*= Page 3 =*=*=*= *********************************************************** * Modifications and Bug Fixes * *********************************************************** **************************************************** From Version 6.07a ( 9/1995 ) bug fixes and modifications are being listed will be listed: 6.08f: 7/7/1996 .. Program will create a NEW field called WEBPAGE in the file 'REGVER.dbf'. This is the start of the modififications required to output data in HTML format for use in a webpage link structure. .. Can set up without modifying 'autoexec.bat' file .. On vehicle outputs using CODE/NUMBER/F3 all references in the notes are cross referenced against the F10Notes/References text. Default delimiters for this are "[]". .. Car Names array problem fixed. 6.08e: 20/4/1996 .. Program now linked with 'Blinker 4' .. Compressed 'exe' file that releases more main memory Drawback to this is the program and some routines take longer to start up and shut down. .. When shelling to DOS, the program is released from memory, allowing other major DOS application to be run if required. This change has seen the usual 130Kb of memory in the DOS shell jump to 540Kb. .. Fix 'aCodes' bug in 'Find/By List' 6.08d: 11/4/1996 .. Removal of 'most common used item' from SUBJECT REFERENCE picklist. Picklist is now displayed on pure alphabetical sequence. .. Manual update .. Internal rationalisation 6.08c: 4/4/1996 .. Subject Reference add option (F7) now allows user to insert last word in text or "_". .. Time taken for some routines is now logged and shown at the end of the report. .. USER ID is now configurable from 'Utlilities/Modify Setup' .. Removal of all cripple features. .. Internal rationalisation of some functions 6.08b: 20/3/1996 .. Notes from F9/Codes would crash if user ESC'd from note number entry. Fixed. .. Generat Notes output had incorrect header. Fixed 6.08a: 11/3/1996 .. Lower case Locations and Subject References possible. .. Complete revamp and regrouping of menu choices similar to "Windows" style except for quitting. .. Joining all data searches into one main search area. =*=*=*= Page 4 =*=*=*= *********************************************************** * Modifications and Bug Fixes * *********************************************************** **************************************************** .. Implementing a Subject/Reference system which can allow users to cross reference ANYTHING within the NOTES section. Potential for 1,000,000 References. .. NOTES are now available from the 'Code' field of "ADD - DATA. This allows for simple cross referencing of photographs without the use of another program for items such as trains, signals, buildings etc. When user exit and returns, the same note is ready for more data entry .. Internals modified to cut 35K from .EXE file .. Long routines now show progress by percentage .. The two direct access add methods for new systems and new vehicle types were rewritten as standard data entry fields. The program defaults some info. The user will have to edit this if required. The info is support material only. .. All Direct access edits were rewritten for some user control. .. Problem with PACK routine not covered by 'add-on' vendor. PACK can now finish task but some records MAY be deleted automatically ( the data was unreadable anyway). Run 'Integrity' to find wagons. .. Unknown vehicle data now included in Summary Table and Code/Activity for 1 year. Due to change of strategy with data. .. Ability to handle 36 vehicle identities, up from 9. Will describe to the '9th' identity, then show '#10', '#11' etc up to '#36'. 6.07e: 24/12/1995: ----------------- .. BUG FIX. When 'Pack REFERENCE' was run it was overwriting wagon data. Now fixed. .. When SPREAD DATE is edited, the routine did not format correctly. The field is now formatted with a blank entry. .. Register check for Code will now hold the date. Previously it was clearing the date all the time. 6.07d: 3/12/1995: ----------------- .. Vehicle Tally for a single code was upgrading the next code in the list. Now fixed. .. When selecting a single CAR NAME from a list to view a history, the program would then list out the remaining cars as well until the last car. This is now fixed to only list the car requested. .. Searching for vehicle with a CAR NAME would give a heading with the car 'storage' number. This has now been corrected to show the car name. .. The LogFile for a class that included CAR NAMES did not show what the CAR NAMES were. This has been partly corrected for the cars of the class, but NOT the conversions (Conversions are found in the EXPANDED listing). .. Inclusion of Integrity check into LogFile. 6.07c: 11/11/1995: ----------------- .. With CLEAN disabled there was no way to check ALL data to check for corruptions. A routine called INTEGRITY is now provided in the 'Utilities' menu. This checks all data and writes to a file all rolling stock with suspicious data entries. .. With STEP HISTORY 'OFF', pages were not being set up. .. Car Names on LOCAL search are now formatted properly 6.07b: 31/10/1995: ----------------- =*=*=*= Page 5 =*=*=*= *********************************************************** * Modifications and Bug Fixes * *********************************************************** **************************************************** .. In data edit, the last LOCATION is 'remembered' during a session. This location is only used when the existing location is '- ', ie NO LOCATION RECORDED. This allows users to edit with minimum key strokes. .. In Search/Find, the debug info for a wagon has been removed. =*=*=*= Page 6 =*=*=*= *********************************************************** * Installation * *********************************************************** **************************************************** The following files are distributed in the file REGNNNNC.zip where NNNN is the Version Number and C is the Version Modification letter 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. These numbers then tell you that Version 6.07b of REG5.exe is distributed in REG607b.zip. Information files ----------------- README .bat: Run this first. REGMAN .new: The user manual FILE_ID .DIZ: Program description for distribution Program file ------------- REG5 .exe: The program Data Files ---------- 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 REGPREF .dbf: Subject reference file REGTYPE .dbf: Vehicle Type reference file REGVER .dbf: CODE VERSION reference file REGWGN .dbf: Vehicle identity file 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 ) Installing the program ---------------------- The program should be sitting in a directory with all the files unzipped. The program must be run from the directory that all the files are in. For the program to run the CONFIG.sys file may have to be modified. As the program uses about 45 file 'handles' the reference to =*=*=*= Page 7 =*=*=*= *********************************************************** * Installation * *********************************************************** **************************************************** 'FILES=' must be raised to allow for normal operation of the computer plus the added load from the program. Trial and error will find the best value to use. If in doubt set the number high as in FILES=80 and take it from there. More file handles may be used by the program as dynamic overlaying is involved which allows larger EXE files than normal to run in limited memory space. These changes may be made by any text editor. To enable the program to run with minimum of external programs it is possible to use the program to make these changes. Type the command 'REG5 setup' where 'setup' is a parameter that starts the program in no frills edit mode. The program opens up the file 'CONFIG.sys' ( which MUST be sitting in the hard disk root directory "C:\". If the computer is booted from another drive designation or floppy, it is best to edit the file with another program ) to allow editing. Instructions are also included inside the editor screens. When the editing has finished the program will quit. The user must REBOOT the computer for the changes to take effect. If the program detects that there is insufficient file handles from either of the above settings, the program will advise that 'setup' mode is required and quit. File changes: ------------ When the program is run in 'setup' mode the original files "CONFIG.SYS" is copied to file "CONFIG.REG". So this file will not be overwritten if 'reg5 setup' is run again, the program looks for the '.REG' file and if it exists, will copy the file with a DOS extension of '.2ND'. This allows the original files to be preserved. =*=*=*= Page 8 =*=*=*= *********************************************************** * Running in DOS * *********************************************************** **************************************************** At the DOS prompt the program can be started with the command REG5. When the program starts it checks that all indexes are present, the LOG subdirectory is present and that the database files have the correct fields. Any changes will be made automatically. This allows for modifications without the need to modify each database manually. The program detects whether a colour video card is installed. In some cases there may be a colour card but a mono monitor. This causes the screens to be hard to see. To force the program to run in MONO or improve readability on LCD screens start the program with 'REG5 m' or 'REG5 M'. Disk space required: ------------------- The disk space required depends upon: ...Text files uploaded to NOTES ...Data entry for individual vehicle histories Limited use would see 2 - 5Mb disk space Moderate use 5 -20Mb " " Reference use 20 -50Mb " " The size of arrays, text searches and basic manipulations is determined by the amount of base 640K memory the program is running with. If EMS memory is available the some of that can be used to. =*=*=*= Page 9 =*=*=*= *********************************************************** * Running in WINDOWS * *********************************************************** **************************************************** The program can by run under Windows using a DOS box. For multi-tasking, use a 'PIF' file. Sample GRP/PIF and ICO file is provided. As these files are samples, the parameters will have to be altered to reflect the users drive and directory. Running the program in Windows will slow it down by about 10 - 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. Multiple copies of the program cannot be run under Windows. If the user wishes to run two programs simultaneously in seperate directories, then each of the programs must have a unique '.exe' filename. For example rename one of the 'REG5.exe' to 'REGISTER.exe'. Ensure that enough file handles have been allocated in the CONFIG.sys file (FILE=nn). Start one of the programs as 'REG5.exe' and the other as 'REGISTER.exe' and there should not be any problem. -----------------: WARNING :-------------------- Any functions in the Utilities menu should NOT be conducted as background tasks. There is the probability of the Windows environment becoming unstable and a General Protection Fault may be issued. To avoid data corruption, only perform Utilities operations as a FOREGROUND or DOS only operation. These operations have been performed by myself as background tasks. Early in the development when this was done, data was corrupted. I am reluctant to advise that this can not be done safely. =*=*=*= Page 10 =*=*=*= *********************************************************** * Program Development * *********************************************************** **************************************************** The program has been under continuous development since 1988 and has been driven by the data entry and users with requests for the program to perform tasks not originally envisaged. As well the programming experience gained has been channelled back into the program to make operations run better and faster. The entire program has been rewrittin several times. The development has revolved around making it work. The basic design strategy has not altered. The next big step is to transfer the program to a Windows environment. This change is for compatability rather than performance. A Windows based program will not have the speed the DOS version does. The program is mainly text entry and whilst mouse control would be nice it has always been felt that mouse control/text entry would slow down a user. With Windows, several unique features of the program may disappear. Gradually most of the little hiccups ( bugs ) have been removed. But sometimes problems do occur. If they happen try to duplicate them and get a screen print or good description of the problem. =*=*=*= Page 11 =*=*=*= *********************************************************** * Known Inconsistencies * *********************************************************** **************************************************** 1.. '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. It will work normally and select the correct identity for a given year. However it will only count overlapped ID's as 1, not as 2. 2.. 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. 3.. The NOTES date is not quite developed. 4.. 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. 5.. In the DATA_LOG.SAV file 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. 6.. 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. 7.. If a textfile is uploaded into the NOTES section, the 'end-of-file' marker is sometimes carried up as well. The can cause some problems with trying to edit a LOG file or maybe a NOTE file as the LOG file for example may be large but the editor does NOT pick up the complete file. (Originally fixed 3/95 resurfaced 11/95) 8.. If Code Data is downloaded in 'Utilities/List/Code RawData' ( or similar ) an edit screen is provided to VIEW the data. When the user exits from this screen there are several options available. As of 3/96 none of the options except QUIT/ESC have been tested. The 'Rename' option will cause the program to fail. The others might too!. =*=*=*= Page 12 =*=*=*= *********************************************************** * Program Design * *********************************************************** **************************************************** The program was developed to store information about wagons, carriages and locomotives. There are many problems associated with this type of storage, least of which is the data entry. Many people have tried storing the thousands of pieces of data collected by using journals and book type methods. Others have set up simple database or text entry systems which allow for 'unlimited' entry and relative ease of use compared to books. However these methods fail in establishing a rapid data entry combined with data cross-reference. Main design revolved around the following issues: ...Ability to retrieve data long after the information is forgotten and without having to remember or record file names of data or notes ...Rapid data entry ...Ability to add data without any references to other material ...Ability to add data once and let computer assemble the info without the need to maintain seperate data lists ...Ability to cross link rolling stock history on data entry for automatic linking on output ...Ability to create reference material on-the-fly as required avoiding the need to 'preplan' data entry ...Ability to add sightings, notes or whatever as free form text and have this data cross referenced ...Minimum disk space ...Minimum number of files to service the data ...User needs a minimum of understanding to run the program The task has been broken into two groups: GENERAL and ITEM data. The GENERAL information is stuff like sightings, quotes from books, tabulated data from timetables. The ITEM data on the other hand is specific information about a specific vehicle; such as a vehicle photograph, the date of construction or scrapping or the date and location of a particular modification. Included in this is the conversion information when a vehicle ( carriage, wagon or locomotive ) is renumbered or changes class or owner. =*=*=*= Page 13 =*=*=*= *********************************************************** * Definitions * *********************************************************** **************************************************** In order that the information can be found and used without too much trouble or ambiguity, data entry is rigidly formatted. This section covers the definitions I have used in setting the program up. The user will then be able to understand the terms and the formatting involved. The program has been designed around the conditions found for the identification of rolling stock in Australia. For general interest this program is now available through the Internet. As such the program may not be adaptable to some systems. =*=*=*= Page 14 =*=*=*= *********************************************************** * Definitions - Vehicle Identity * *********************************************************** **************************************************** Railway rolling stock can be identified in a unique way and this is used for the operation of the program. The complete vehicle description is required and this description used to set up reference files. The description allows the program to logically group data for summaries, etc. A vehicle is described by: Code + Number + System + Version See VERSION =*=*=*= Page 15 =*=*=*= *********************************************************** * Definitions - Code * *********************************************************** **************************************************** This is the group of letters used by some rail systems to identify a specific group of vehicles. Such a group may be coal hoppers, cattle vans, 1800hp locomotives, etc. For the Victorian Railways, Australia some groups are: Code Description -------------------- 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 CODE letters can be from 1 to 6 letters and/or numbers. Unfortunately not all vehicles are identified by specific letters. Some carriages are known by NAME and vehicles may belong to a group that does not have Code letters but are numbered nonetheless. For these vehicles the program will accept a '-' ( dash ). The dash signifies the vehicle group being recorded are known by a description, not a series of letters. 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. Some Victorian Railways examples are: .. Joint Stock Sleeping Cars .. VR Sleeping Cars .. Scrap underframe .. Unknown vehicle International: ------------- North America: CODE = REPORTING MARK. Elsewhere: Not enough information to comment. =*=*=*= Page 16 =*=*=*= *********************************************************** * Definitions - Version * *********************************************************** **************************************************** From 1859 the Victorian Railways established an alphabetical Code system possibly copied from European practice at the time. I say this with some confidence as observation of European vehicle code practice in 1979 showed remarkable coincidence in patterns and vehicle types. One of the problems associated with Code systems is the limited number of Code possibilities, as there are only 26 letters available for main groups. As rolling stock is distinctive and the usual book methods ensure segregation of data, similar coding letters are applied to locomotives, passenger vehicles and freight stock. One example to give is the Victorian Railways Code 'M' where the following example shows different rolling stock types: Code Version ---- ----------------------------------------------- M Electric Suburban - Swing Door - Sliding door - Martin & King / Harris Trains - Martin & King / Hitachi Trains - Comeng ( For this example I am ignoring the fact that all code 'M' ) ( electric stock was segregated into distinct number groups ) M Cattle wagons M Shunting locomotives For a computer program this presents a problem. When writing up books, the Versions or different classes that have the same code letters are separated by different ledger books; ie 'Passenger' books, 'Engine' books, Freight' books, etc. There is no such distinction for a database apart from using different files for each Code. The aim was to cross reference data automatically using one main file only. What was established to provide a unique database identity was a tag applied to each vehicle. This 'tag' is called the Version and consists of two characters. The first character represents the Owning system and the second character represents a computer generated letter within the Owning System. The Owning System is used to describe a group of Codes with some common heritage. For example all Victorian Railways rolling stock has been given the letter 'V' in my program. See 'Definition - Owning System'. Taking a Swing Door Electric Suburban Motor Car Code 'M' and Number 27 the program stores this as: M 27.VA where M = Class M 27 = Number 27 . = Tag Seperator V = Owning System 'Victorian Railways' A = Version 'A' of the 'M' letter group, for Owning system V where =*=*=*= Page 17 =*=*=*= *********************************************************** * Definitions - Version * *********************************************************** **************************************************** A=Swing Door Electric Suburban Motor Car The object of the Version System is to provide a compact method of storing unique vehicle information giving the program the potential to cross reference with the minimum amount of information. The requirements for the Version description are: 1..Code identifiers. These can be alphanumeric with some other symbols as well. Main other identifier is '-'. Other symbols not tested. 2..Description of the Code group Very simple description to describe a specific code group 3..Date This is the 'year of first use' for the items 1 and 2 above. 4..Vehicle group Type The main traffic category; eg Passenger car, Locomotive, etc. The principle concept of the program is the maintenance of 'loose' descriptions for each Code. This method enables the user to link vehicle histories together after years of data entry whereby the original Code Description can still apply. It is possible to very tightly define a Code by Builder description or body type. However problems result when one Vehicle may have several identities each of different body types or Builders. The scope is the ability to track histories and enable data entry without reference. The collating of body types and other unique features is a seperate issue and better placed in General Notes in tabulated form. =*=*=*= Page 18 =*=*=*= *********************************************************** * Definitions - 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 and isolate sytems for summary lists. The Owning System can be set up for a specific railway or can be used to group a number of common rail systems together. The Code is then used to describe each rail system. Using 'V' for Victoria the codes represent each vehicle group. If for example 'I' is used to group the 'Iron & Steel' railways of Australia, the Codes BHP, IAS, HI, MTN would represent each of the railways. Most of the rolling stock for these systems are numbered only. Only the user can decide how to juggle the Code and Owner System for best use. Irrespective of method used, the cross referencing ability is not jeopardised. The 'Owning System' need not be a system in the true sense. To monitor rail vehicles operated by preservation groups, 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 vehicles in traffic that are not 'on the books' of the state systems. One interesting historical point that is occurring is the preservation groups that recode vehicles. This recoding is not always in line with State systems. This change can be recorded without altering the summaries or System 'On Register' figures. For example, the VR had a QB code which was became a Code VWAA. A vehicle was sold to a private group and it was recoded back to a QB. For the program to track this, a new QB code is described with a 'Private System' reference. =*=*=*= Page 19 =*=*=*= *********************************************************** * Definitions - Number * *********************************************************** **************************************************** The number is used to identify a vehicle, usually as part of a group of wagons. The 'number group' for a vehicles is generally a continuous run of numbers from lowest to highest. Most numbers in Australia rarely are longer than 5 digits. However to cope with the unexpected I have left the number field as 6 digits. This also allows for North American number series which do run this long. =*=*=*= Page 20 =*=*=*= *********************************************************** * Definitions - Name * *********************************************************** **************************************************** Some carriages or items of rolling stock are known by a Name. As a Name of 10 - 15 characters does not fit into a 6 character space, a special rule is applied to enable the program to store the Name and to reduce the confusion of one vehicle having a multiple identity such as a Name AND an Number. To enable the program to function with vehicle Names, a rule was formed that reduced the problem. The rule put simply says that for a vehicle to have a Name it MUST NOT be referenced by any other identifier such as a Number. If the vehicle has a Number then the Name is not an identifier in the true sense; the car is numbered but is painted and known as 'such and such' name. It is left to users to decide whether the vehicle is to be referenced by Name or Number in such cases where common knowledge may differ. The program can function but it will reduce conflict if a vehicle can be set up with one identifier. To reduce the problem of multiple identities a further rule was imposed. The condition imposed was that a vehicle with a Name MUST have a Code that included DASH ( '-' ). The dash evolved because all the Victorian Railways carriages that were known by Name belonged carriage groups that did not have Codes; they were known by description only. By example, 'Sleeping Cars'. Hence the dash condition. =*=*=*= Page 21 =*=*=*= *********************************************************** * Definitions - Date * *********************************************************** **************************************************** The Date is time of an event in the lifespan of a vehicle identity. Every event has a date. Finding the date is a different story. The program wa designed to handle unknown (circa) dates, DD/MM/YYYY, MM/YYYY and YYYY dates. =*=*=*= Page 22 =*=*=*= *********************************************************** * Definitions - Notes * *********************************************************** **************************************************** The Notes attached to each data record are for adding references and other useful information. They are meant to be brief, up to 8 lines of text. More wordy notes are better suited to the 'General Note' storage where notes can be referenced and are tagged with a number. =*=*=*= Page 23 =*=*=*= *********************************************************** * Definitions - History * *********************************************************** **************************************************** The History ( Activity ) is a designated event in the life of a vehicle. The program was designed with a limited number of available Histories to choose from. In fact there is a maximum of 52 available for use. The number of choices is purposely limited to aviod fragmentation of similar histories by different phrases. 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 is History tracking, phrase uniqueness is dropped to provide easier reference and a simpler output. The user can revert to other phrases if required. However instead of zeroing in on ONE event for a a summary, more than one phrase must be searched for what is essentially the same thing. Histories provided with the program are: History Definition ------- ---------- Body Reference of a vehicle body at a specified location and noted at a specified date. Built new Built and placed into service at a specified location and date. 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. Ex Recoded or renumbered from another identity. May or may not involve rebuilding. Rebuilding and modifications ( if any ) in the recoding are generally implied. Ex.. 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. =*=*=*= Page 24 =*=*=*= *********************************************************** * Definitions - History * *********************************************************** **************************************************** May be represented in the database as 'Ex/P'. Use whatever suitable as long as ONLY four characters are used. History not known Enables user to comment on a vehicle identity. The program produces the message "Unknown History" when data cannot be found in reference files In Service The vehicle is already built and may or not be on the Register. This History places 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. 'Modified' indicates any change to the vehicle that is NOT made for the purpose of TRAFFIC requirements. This relates to brakes, bogies, wheels, rebuilt bodies, handbrakes etc. See 'Traffic' history. 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 railway 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. 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. =*=*=*= Page 25 =*=*=*= *********************************************************** * Definitions - History * *********************************************************** **************************************************** 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' must be taken 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 NOTE: 'Sold for scrap' is more appropriately placed under 'Scrapped' 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 be removed. Sold (to) Vehicle has been removed from service and sold from the rail property. Generally, sold implies the sale of the vehicle without wheels. NOTE: 'Sold' implies the vehicle is sold for usee elsewhere either body or underframe to another railway or for use as a dwelling or shed, etc. 'Sold for scrap' is more appropriately placed under 'Scrapped'. 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 at a workshops or siding. This is generally when there is a downturn in traffic To Vehicle is renumbered or recoded to another identity To.. The opposite of 'Ex..'. Used to show where

arts of a vehicle have gone. This history is used to prevent a full cross reference during a search. May be represented as 'To/P' in the database. Use whatever is suitable so long as only four characters are used. 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. Traced at Stocktake Found or traced after a systemwide stocktake event and subsequently restored to the Register. Traffic A vehicle is used or stencilled for a specific type =*=*=*= Page 26 =*=*=*= *********************************************************** * Definitions - History * *********************************************************** **************************************************** 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 undercarriage of the vehicle Withdrawn Removed from service as in 'Withdrawn from traffic' These are the terms and definitions I have used. Any user of the program can create and define their own terminology. For those Histories above that are inappropriate can be rephrased or changed. The only restrictions are that the Histories 'Ex', 'Ex/P', 'To', 'To/P' should NOT be altered. They have special rules attached that allow the program to function as a cross referencing tool. These four histories are restricted to 4 characters. In the original program there were no pull down lists to choose from, it was all manually entered. Hence the limit of 52 choices is A - Z and a - z. As there is no longer any manual entry and the history is only known by the phrase not by the character, it is possible to use any ASCII value from 32 to 255. This gives in excess of 200 histories to play with. ASCII values not on the keyboard can be typed in by holding down the 'ALT' key while typing any number between 0 and 255. Numbers between 0 and 31 inclusive should be AVOIDED as they may be interpreted incorrectly by the program. Special Note for 'Ex..', 'To..': ------------------------------- As the information provided for this history is generally one- sided: ie, one vehicle provides the data. To maintain this information reference in the program, the data is marked by special text 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 provided the information. The special text is: [org] : Data originated from this vehicle [rec] : Data was received from the other vehicle. These histories are limited to four characters. Initial description was 'Ex/P' and 'To/P'. This description may be in the distributed database. =*=*=*= Page 27 =*=*=*= *********************************************************** * Definitions - History Groups * *********************************************************** **************************************************** 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 shown below: Group Program Code Representation ---- -------------- O On Register ( On the 'books' ) S Off Register ( Off the 'books' ) I Vehicle Information P Private source data The groups give the program ability to filter out data and 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 examples are: HISTORY GROUP ------- ----- Body P Built New O Modified I Note I Ex O Off Register S Photograph P Scrapped S Sighting P To S Traffic I =*=*=*= Page 28 =*=*=*= *********************************************************** * Definitions - Location * *********************************************************** **************************************************** The location is where the 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. =*=*=*= Page 29 =*=*=*= *********************************************************** * Definitions - Local History * *********************************************************** **************************************************** This is the type of history as written up in a journal. The history presented is usually of one vehicle identity. The history presented is local; of value to the immediate vehicle without providing cross referenced data. =*=*=*= Page 30 =*=*=*= *********************************************************** * Definitions - Step History * *********************************************************** **************************************************** This history was so named because of the ability to 'step' across the code changes of vehicles and track the history from start to finish. 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 * --- =*=*=*= Page 31 =*=*=*= *********************************************************** * Definitions - 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 'paragraph mark'. 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 ... When data entry is first started the default ID is ' ' (space). The program accepts this as ONE vehicle. Only when necessary, and when more data shows multiple ID's exist do the previous data entries require editing. Each record must then be marked as 1,2,3, etc., in the edit box. In fact it is possible to add a single data entry and then edit to show it as the 5th ID. The program will still function. However it is accepted by the program that the tally for the number of vehicles with that ID is 5. To assist with American loco renumberings, I have modified the number of ID's available from 9 to 36. This is achieved by the ID numbers from 1 - 9, and the alphabet list A = 10, B = 11, C = 12, ..., Z = 36. Output for the ID's is described by 1st, 2nd, 3rd up to 9th, then it is simply #10, #11, #12 etc. =*=*=*= Page 32 =*=*=*= *********************************************************** * Definitions - Subject / Reference * *********************************************************** **************************************************** The Subject or 'Reference' is only applicable from the 'General Notes' section. This category allows the user to insert into a Note any reference from a table. This allows the user to cross reference photographs by subject or whatever information is required. This is very similar to the 'Location' input where new locations are added as required. There are two exceptions: 1/..The computer generated reference is not displayed as this is not required in general use. The code characters generated are created from the length of the database and the next code after the highest one in use. The code is generated with ASCII values; 2/.. When input into the text, the reference is not inserted as the free format wording to be used may be slightly different. The symbol "_" is used to show the user the reference has been added. The field is 30 characters long for reference input which is long enough for most subjects. To enable easy retrieval of the data it is suggested that some grouping take place. Instead of a 'ragged' list such as: Tait Train Silver Train Home Signal Fred Bloggs A simple grouping method would keep all similar references together. Such as: Contact - Fred Bloggs Signal - Home Train - Tait Train - Silver The references can also be used to tie together different notes by topic. This allows a similar theme or 'thread' to tie together notes that have the same link. This allows the user to quickly add a note and provide a thread without the knowledge of where the other notes. This method also saves the user from trying to tie all relevant information into one note as a specific topic. For example a refernce could be: 'Topic - Narrow Guage Recoding 1902' =*=*=*= Page 33 =*=*=*= *********************************************************** * Program Operation * *********************************************************** **************************************************** The program has been designed around keyboard use. There are no mouse controls (Shock, horror!). As the majority of program use is DATA ENTRY, ie text input, the use of a mouse would only complicate matters. I have decided to wait and implement mouse control with the Windows version. 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 a program request: 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 "." This allows a less intrusive method that highlighted video. 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. =*=*=*= Page 34 =*=*=*= *********************************************************** * Program Operation * *********************************************************** **************************************************** 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. The keys are F8 and F10. =*=*=*= Page 35 =*=*=*= *********************************************************** * Program Operation - Output file access * *********************************************************** **************************************************** 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. Print: The selected file is sent to the printer. 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. =*=*=*= Page 36 =*=*=*= *********************************************************** * Program Operation - 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: Pressing this key saves all the edit changes for the BLOCK of text. If the user does not want the text, re-edit. 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 ). This is limited by the available main memory when the program runs. Less main memory restricts the amount of text data the program can manipulate. 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. Pressing ESC will leave a BLOCK and 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. =*=*=*= Page 37 =*=*=*= *********************************************************** * Program Operation - Text Editor * *********************************************************** **************************************************** 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. =*=*=*= Page 38 =*=*=*= *********************************************************** * Program Operation - 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, pressing the F10 function key will display the JOTNOTES on the screen. The 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 main steps of Note taking are: 1.. Select the heading required by arrow keys and press 3.. Type in Notes required 4.. Save the note by pressing the ESC key. 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. 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. References: To facilitate easy cross reference with the Vehicle Notes cross reference matching "markers" are used. The example shows how. In the vehicle data notes add a note like "[JM]: says 10/5" This is shorthand for person JM indicating a different date. In the F10 Jotnotes/Reference section add JM as a reference thus: [JM] : John Middleton Then when the vehicle data is output, the "[JM]" in the notes will be matched to the "JM" in the Reference list and shown. It does not matter how the list is organised, the reference will be matched. If a reference is found in the notes and cannot be matched, it will NOT be included in the output. =*=*=*= Page 39 =*=*=*= *********************************************************** * Program Operation - Pop up Notes * *********************************************************** **************************************************** =*=*=*= Page 40 =*=*=*= *********************************************************** * Main Menu * *********************************************************** **************************************************** The main menu has the following selections Add - Main data entry for vehicles and Notes Find - Search for specific Vehicle or Note information Summaries - Tables, Summaries or Reports from data Edit - Modify database tables Utilities - Program stats and housekeeping Quit - Close files and exit the program =*=*=*= Page 41 =*=*=*= *********************************************************** * Main Menu - Add * *********************************************************** **************************************************** Data: ---- This is the section where data is added for a specific identity. Information required for adding vehicle data is: CODE NUMBER HISTORY LOCATION DATE NOTES Notes: ----- This is the section where general information such as sightings, daily notes or other information is placed. Information required for Notes are: REFERENCE NUMBER DATE HEADER Within the notes, free form text is added. The following cross-reference data may be added: CODE, LOCATION, REFERENCE ( SUBJECT ). The cross references are inserted into the text at the cursor. If the text is not required it may be deleted or altered to suit the note. LOAD a File: ----------- The program transfers a file from disk and loads it up into Notes. Once loaded, the text can be cross referenced or modified. The user is prompted with a Reference Number for the Note. The user can provide some other reference if required. When the textfile is stored the program will indicate on the screen the Reference Number the Note was stored with in case the supplied reference cannot be used. To indicate a file loaded by this method the note heading includes the letters "[TF]" which the textfile origin. The Header can be edited if these letters are not required. Maximum file size for an upload is 3Mb. The only files acceptable for loading are standard text ASCII files, generally those with a DOS extension of "TXT". Files created with Word Processor type programs are not suitable unless they are saved from the Word Processor program as ASCII files. ---------------** Please Note **----------------- The file transfer into Notes is for ASCII text ONLY. Any other file type loaded will cause the program to fail. ---------------** Please Note **----------------- =*=*=*= Page 42 =*=*=*= *********************************************************** * Main Menu - Find * *********************************************************** **************************************************** Vehicle: ------- This is where vehicle histories are output. The default for this screen is a single vehicle. The history presented will depend upon whether the STEP history is ON or OFF. Data: ---- In this section a search of individual vehicle data is possible. There are several criteria options. If no criteria is specified for an option, the default is for ALL. The criteria are: SYSTEM - Specify a certain rail system / code grouping TYPE - Specify a certain rolling stock type CODE - Search a specific vehicle code DATE - Select a date range for the search LOCATION - Specify a location to search for ACTIVITY - Select one or more activities TEXT - Type in text for the vehcle data text search These criteria may be searched for singly or in multiple. For example, the user may wish to search a single rail system, freight stock only, at a specific location for the text 'burnt'. On output, the file indicates what was searched for. Text search: To assist with text search the user can specify spaces before and/or after the word to be searched for. All that is required is to place underscores where required to retain the space marker. For example, typing in " pipe " only will allow the program to trim all the trailing and leading spaces to "pipe". To force the spaces type "__pipe__". The underscores will be altered to spaces as in " pipe ". This is handy for some text but beware; this type of search will only pick up words in the of phrases, not beginning or end words. 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 =*=*=*= Page 43 =*=*=*= *********************************************************** * Main Menu - Find * *********************************************************** **************************************************** finish numbers required. 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. This function is very useful for listing all the unknown numbers in use. on the CODE input. Type '#.....' as the low number and '#99999' as the high number. All the unknown numbers will be listed. 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 ..........[WAG_LIST] 2... Use an existing list generated from a report......[REG_LIST] Method <1> is used for most ad-hoc reports. Method <2> is used when the program has generated a list of vehicles from another summary. The only lists created at the moment are from the 'On Register' summary. 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. If a new list is required press on this name and start adding wagons. When the user apes from the list, the program 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 program will immediately begin searching for vehicle histories. 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. 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: =*=*=*= Page 44 =*=*=*= *********************************************************** * Main Menu - Find * *********************************************************** **************************************************** 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..Subject If this option is NOT selected, all NOTES will be checked. Only a single SUBJECT can be searched for. 5..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. 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. 6..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. =*=*=*= Page 45 =*=*=*= *********************************************************** * Main Menu - Find * *********************************************************** **************************************************** 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 ================= If no criteria is provided for 'A' or 'B', the search 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' =*=*=*= Page 46 =*=*=*= *********************************************************** * Main Menu - Find * *********************************************************** **************************************************** criteria. The CANCEL option allows the user to reset the search criteria to zero before a search, in case of mistakes. =*=*=*= Page 47 =*=*=*= *********************************************************** * Main Menu - Summaries * *********************************************************** **************************************************** With the amount of data entry possible there is the potential to use the information storedand the potential 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 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. Menu choices are grouped into similar reports. An elipse ( ... ) shows that more options are available at the choice selected. Activity ... : ------------- 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. Code and 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. 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 =*=*=*= Page 48 =*=*=*= *********************************************************** * Main Menu - Summaries * *********************************************************** **************************************************** given but may not be shown if no activities were recorded for it. For Code, 1 year - ------------------ From the Tally Table option, a list of activities is tallied and recorded against the years. To find the vehicle numbers that created the tallies, specify a year and a code to search. The output will be ordered with activity groups and each group will have a list of vehicle numbers. Tally Table: ------------ 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. Register Check ... : -------------------- Code - ------ 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. 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. =*=*=*= Page 49 =*=*=*= *********************************************************** * Main Menu - Summaries * *********************************************************** **************************************************** 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. 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. 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. List - ------ 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. 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. Location Resume: --------------- 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 =*=*=*= Page 50 =*=*=*= *********************************************************** * Main Menu - Summaries * *********************************************************** **************************************************** Code Data Audit: --------------- 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 it does present a small problem. 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. Well it is available by browsing the data but that can get laborious. 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 quantify. The table below shows how the Audit output is arrived at: ----------------------------------------------------- Line No. 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 =*=*=*= Page 51 =*=*=*= *********************************************************** * Main Menu - Summaries * *********************************************************** **************************************************** 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. Logic notes: ----------- 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 =*=*=*= Page 52 =*=*=*= *********************************************************** * Main Menu - Summaries * *********************************************************** **************************************************** vehicle portion is most significant for history tracking. Timeline: -------- 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. Class Numbers ... : ------------------ Code tallies - -------------- 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 =*=*=*= Page 53 =*=*=*= *********************************************************** * Main Menu - Summaries * *********************************************************** **************************************************** the same time, the data is output to file for viewing. 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. 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. This will result in a 'short count' if a SYSTEM TALLY is run. SystemWide - ------------ 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. 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. =*=*=*= Page 54 =*=*=*= *********************************************************** * Main Menu - Edit * *********************************************************** **************************************************** --------------------------- WARNING --------------------------- Some FIELDS are headed with a 'ptr' or 'pointer' wording. These fields are used to store a special number that points to data in another file. The program generates these characters and they cannot be duplicated by key strokes. They are 4 byte LONG INT values. To allow for unforeseen problems the program cannot fix I have allowed edit access to the pointer fields. If there are persistant data problems that the user has isolated to the data location, then BLANK OUT the pointer field with spaces. This will effictively cut the reference to the data and allow the program to generate a new location and pointer reference. ---------------------------------------------------------------- The edit tables all have a similar format. Main feature is the control over data entry. 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 Left Arrow: Pan across the database fields to the left. Right Arrow: Pan across the database fields to the right. : Allows data entry on field. Then is pressed a small box is opened to allow for data entry. The user can go back with changes by pressing the ESC key. ESC: Exit from current operation and go back. F2: Conduct a search on the current FIELD or column. The search is only relevant for some indexed fields and description fields. If the F2 key does not work then the search routine has been determined as not appropriate. Use other methods. To alter the index state, press on the blank search input field. This will set the index to the field if applicable. Description field searches will search sequentially on text within the field. F3: Toggles the record between and . is unmarked; the standard record status. Entries marked as will be physically removed from the database when the "PACK References" choice is initiated from the "Utilities" menu. F4: Will append a blank record to the file. Because the record is blank, it will automatically be indexed to the top. Codes: ----- There are three screens required to handle the number of fields. The screens are itemised as "Code1", "Code2" and "Code3" on the first column. The first columns are locked and the other screens show the data. This EDIT table is valuable for adding information such as: =*=*=*= Page 55 =*=*=*= *********************************************************** * Main Menu - Edit * *********************************************************** **************************************************** ... 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. System Names: ------------ 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 avoid 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. 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 Reference database table only is altered, not the links in the main datafile. Locations: --------- The edit allows the user to correct minor spelling or alter a location reference that may cause reference errors. Subject Refs: ( Subject References ) ------------ This edit allows for corrections in spelling or editing data that may cause problems. The three character reference system uses all ASCII characters and so will display funny characters. If these characters are altered, the references in the notes will be lost. Car Names: --------- Car Names have two parts: a Reference Number and the Car name "word" which can be up to 20 characters long. The Reference Number must be unique in the range ' 1' to '999' and right justified. When the program generates the number it uses the first unused number. If required, the user can generate The Reference Number for the Car Name need not be a number in the strictest sense. It could be alphabetically unique. The user can experiment with this one. Vehicles: -------- Access to this database is mainly to fix problems that may occur. Within =*=*=*= Page 56 =*=*=*= *********************************************************** * Main Menu - Edit * *********************************************************** **************************************************** 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. Note References: --------------- 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. The table is shown in NOTE NUMBER order. The order is altered by the use of the F2 key in a search. Search on DATE sets the order to DATE and search on NOTE_REF sets the order to NUMBER. 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. 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. =*=*=*= Page 57 =*=*=*= *********************************************************** * Main Menu - Edit * *********************************************************** **************************************************** 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 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. 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. "Ex", "To", "Ex.." and "To.." 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. 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, for example, 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. The user can be the judge on how to do it. =*=*=*= Page 58 =*=*=*= *********************************************************** * Main Menu - Edit * *********************************************************** **************************************************** =*=*=*= Page 59 =*=*=*= *********************************************************** * Main Menu - Utilities * *********************************************************** **************************************************** 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 'PACK' the files. 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. Generate List ... : ------------------ Jot Notes ... ------------- Each Jot Note section is itemised for output. The sections are: Notes, References, Contacts, Enquiries, Definitions 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. Perhaps a better method may be only list all UNREFERENCED vehicles. This is a future modification. There are three options: 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. =*=*=*= Page 60 =*=*=*= *********************************************************** * Main Menu - Utilities * *********************************************************** **************************************************** 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. Reference Files --------------- Audit/Log --------- 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 for 'CODES'. 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 =*=*=*= Page 61 =*=*=*= *********************************************************** * Main Menu - Utilities * *********************************************************** **************************************************** 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. Raw Code Data ------------- 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. 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. Unfinished Data --------------- 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. 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. =*=*=*= Page 62 =*=*=*= *********************************************************** * Main Menu - Utilities * *********************************************************** **************************************************** BLOCK 1: Standard screen colors BLOCK 2: Menu colors BLOCK 3: Text display colors BLOCK 4: General program information BLOCK 5: Text editor data BLOCK 6: Printer setup codes Other BLOCKS may be added in future versions of the program. Integrity: --------- This routine was developed to check each vehicle history for problems. The routine does two things: 1.. Checks data validity 2.. Counts the number of lines of data. Invalid data is logged in the output. All the lines are tallied to show the number of lines being referenced. This is guide to the amount of data stored as the system is independant of a 'datafile record' count. 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. Pack ... : --------- Notes ----- 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. =*=*=*= Page 63 =*=*=*= *********************************************************** * Main Menu - Utilities * *********************************************************** **************************************************** 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. Data ---- 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. 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. PLEASE NOTE: ------------ If either of the 'Pack' routines fails the program, the most likely cause would be insufficient memory. To overcome this problem I have included a seperate program with the file regNNNc.zip. The file is called 'regpack.exe'. It can only be run from DOS. The program accepts two filenames: the file to pack and the file the packed data is going to. Format of the parameters is: REGPACK REGISTER.pjv REGISTER.new REGDATA.pjv REGDATA.new When each file is packed successfully, rename the files with an extention of "old", then rename the files to filenames. References ---------- This option packs the reference 'dbf' files that store locations, histories, vehicle codes and notes. At the same time, the file is reindexed and the menu counter is reset. =*=*=*= Page 64 =*=*=*= *********************************************************** * Main Menu - Utilities * *********************************************************** **************************************************** 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. Clear dates ... : ---------------- Audit ----- 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. DataLog ------- As 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. 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. DOS shell: --------- This option allows the user to access the DOS prompt without quitting the program. The DOS SHELL will be allocated as much conventional memory as possible. Memory will generally be about 25K less than prior to starting the program. More than enough to run other programs if required To exit from the DOS session, type 'EXIT' and press the key. The 'Shell' feature is to enable DOS users to view and copy files on the computer without the need to quit the peogram. Options: ------- There are several program functions which can be configured by the user. The options are: 1..Form Feed Allow the user to immediately FORMFEED or EJECT the paper in the printer. =*=*=*= Page 65 =*=*=*= *********************************************************** * Main Menu - Utilities * *********************************************************** **************************************************** 2..Set Top of Form This resets the printer and initialises it to standard settings. 3..Data Reference delimiters. The delimiters are to be unique start/end characters, not to be confused with anything else. Suggested delimiters are '[]'. Optional delimiters could be '<>', '::', '{}'. The delimiters are matched against the references recorded in the JotNotes/References text, and must be exact. 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 Sometimes the program may fail due to lack of memory when editing or when searching for data. Reducing this number can get the program back running. The number arrived at by experimentation would be the optimum for the user setup. For example 40000 ( bytes ) may be too large a buffer and the program fails. But be reducing the buffer size to say 16000 ( bytes ) may restore program operation. 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 ( for alphabetical character ) This option tells the program whether to prompt if an alpha character is in the number. 'No' indicates NO checking. 9..Step History There are two history output options: LOCAL (Step OFF) and STEP (Step ON) STEP 'ON' output is the most informative. 10..Repeat Data For STEP history output each line is described by the vehicle =*=*=*= Page 66 =*=*=*= *********************************************************** * Main Menu - Utilities * *********************************************************** **************************************************** 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 has the start of each line blanked out. 11..Show Version This option allows the user to show output in book entry style. When 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'. The 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. 12..Paragraph separator: There is a 10 character 'space' for users to define a separator. This is used to separate multiple vehicle ID's from the same request. 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. =*=*=*= Page 67 =*=*=*= *********************************************************** * Getting Started * *********************************************************** **************************************************** =*=*=*= Page 68 =*=*=*= *********************************************************** * Getting Started - 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. 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. =*=*=*= Page 69 =*=*=*= *********************************************************** * Getting Started - Code * *********************************************************** **************************************************** 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 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 Focus. The program records the date each time a HISTORY is used. If a HISTORY has not been used for 30 days the recorded data for the routine will be dropped when the 'Pack REFERENCES' utility is used. This prevents excess data being stored when not required. 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. FOCUS: For LOCAL history, the program saves the data by CODE, HISTORY, =*=*=*= Page 70 =*=*=*= *********************************************************** * Getting Started - Code * *********************************************************** **************************************************** DATE, LOCATION and NOTE. In this way data entry for a specific CODE can be resumed quickly. =*=*=*= Page 71 =*=*=*= *********************************************************** * Getting Started - 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 =*=*=*= Page 72 =*=*=*= *********************************************************** * Getting Started - Number * *********************************************************** **************************************************** 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. When the program detects the vehicle has multiple identities, as in 1st, 2nd, 3rd; each 'vehicle identity history' is separated by a 'paragraph mark'. The user can specify their own paragraph mark in the menu Find/Options/Para Mark. 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. 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. The check letter program is for Australian Systems. If users require a special check program, contact me with the way it is generated. 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'. 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 =*=*=*= Page 73 =*=*=*= *********************************************************** * Getting Started - Number * *********************************************************** **************************************************** returns to the NUMBER field. UNKNOWN NUMBER: If the user cannot identify a vehicle, the program can generate a unique number. 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. 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. =*=*=*= Page 74 =*=*=*= *********************************************************** * Getting Started - 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. The box will be redrawn when the user presses the key. 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. This choice is an option and is not rquired to be done. 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. =*=*=*= Page 75 =*=*=*= *********************************************************** * Getting Started - History * *********************************************************** **************************************************** 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. The history is saved when the FOCUS is set to ON. 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..", "To" or "To.." 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. =*=*=*= Page 76 =*=*=*= *********************************************************** * Getting Started - 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. 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 + 'AZ' 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 FOCUSL 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 =*=*=*= Page 77 =*=*=*= *********************************************************** * Getting Started - Location * *********************************************************** **************************************************** 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. To restore the data again, ESC from the field and re-enter the data entry again. 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. =*=*=*= Page 78 =*=*=*= *********************************************************** * Getting Started - Subject / Reference * *********************************************************** **************************************************** The Subject is some item of information or object that is required to be cross referenced for future searches. As spelling and phrases are not exactly duplicated over the years of free format text entry, a 'text search' as such has the potential of missing important data. This method was adopted as a quick clean way of cross referencing EXACTLY without the need to create specific data fields and more reference tables. It also allows one Note to have multiple references thereby allowing the user to add data ONCE without the concern of seperating the data into two or three categories and the seperate filing involved therein. This was adopted to replace the addition of a seperate database for photographs and the information contained within the photos. With careful cross referencing details photographs of any wagons could be found by the keys: < VEHICLE CODE > + < PHOTO - DETAILS > This reduces the need for specifying EXACT detail photos which would appear in the output. The concept was simplicity and speed of data entry with a search eliminating 99% of the hard work. So rather than getting EXACTLY one line of text which describes the photo only, a Note is found which may be 20 - 30 lines long. Out of this data, the photo required is found. It is possible for the user to explicity describe each photo and give more than one cross reference. The program will handle it. There is potential for 5000 cross-reference items PER NOTE. =*=*=*= Page 79 =*=*=*= *********************************************************** * Getting Started - 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 DATE based. All data storage is organised by DATE. Hence the use of unknown days, months and years to enable the information to be presented in the correct order. 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 DATE ) years. Valid is year2 must be higher than year1. For VR this only applies for some dates between 1871 and 1874. 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. =*=*=*= Page 80 =*=*=*= *********************************************************** * Getting Started - Date * *********************************************************** **************************************************** 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. Ad-hoc: The routine is not strict about characters that are input, nor does it check to see if the month or day are correct. The following is possible as a more accurate work around of general dates: c/10/1900 Approximately Oct 1900 / c/1900 Approximately 1900 Care should be taken when adding alphabetical letters into the DATE field. Only the dates above have been tested. For example if the user types all lower case characters into the DATE field for General Notes, then the NOTES will be missed during a search. =*=*=*= Page 81 =*=*=*= *********************************************************** * Getting started - Vehicle 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 longer than the page is wide, then the NOTES are truncated and printed after all the data. As each NOTE is extracted it is given a number and the reference is placed on the line. 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 note is identified by number and printed in full. =*=*=*= Page 82 =*=*=*= *********************************************************** * Getting started - General Information Notes * *********************************************************** **************************************************** There are two methods of starting 'General Information Notes'. One is via the 'Add/Notes'. The other is via the function key F9 from the CODE field at the 'Add/Data' option. When data is added from the 'Add/Notes' option, the user is prompted for a new note number at each turn. The user can then choose to accept the number offered or type in a specific note reference ( alpha-numeric characters ). When the F9 key is pressed from CODE ( from the 'Add / Data' option only ) a 'window like' interface is provided. This allows the user to toggle between specific vehicle data input and the current NOTE selected. This is the type of data entry associated with scanning strips or multiple lots of photographs and toggling between specific data on vehicles and more general photo data that may be signals, trains, trackwork, etc. The object was to avoid running a seperate program. The operation is as follows: 1 .. From within CODE, press the F9 key 2 .. A default note number is provided 3 .. Users accepts Note Number or supplies own. If user supplied Note does not exist a new Note is started. 4 .. If a New Note is started the user is prompted for Date and Heading 5 .. Partial text entry and cross referencing is carried out. 6 .. When the user requires to add specific data, the ESC key is pressed. 7 .. The Note is saved, the Note Number is recorded and the CODE field returns. 8 .. Further operation of the F9 key re-installs the currently used Note to the screen for further text and cross reference entry. 9 .. When the user exits from the CODE field to return to the Main menu, the Note Number is cleared. 10 .. Re-entry to the Notes via the F9 procedure starts the operation at No.2 again. The main components 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. REF NO.: ------- Each note is assigned a number. This number is used to quickly access the note for editing or output. The main program generated reference number can be reset from the 'Modify Setup' Menu option. On data entry, the program will prompt for a Reference Number. There are several choices available when adding a new NOTE =*=*=*= Page 83 =*=*=*= *********************************************************** * Getting started - General Information Notes * *********************************************************** **************************************************** 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. 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, LOCATION and SUBJECT references can be added to the text 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 the =*=*=*= Page 84 =*=*=*= *********************************************************** * Getting started - General Information Notes * *********************************************************** **************************************************** notes and when a reference to a CODE, LOCATION or SUBJECT is given, then add the reference to the note using the data the program has access to. The cross reference method allows the text to be printed out or sent to file without worrying about special formatting data imbedded into the text. From the text the user can press the F5 key for CODES or F6 for LOCATIONS or F7 for SUBJECT. 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. 3... The user picks the reference from the list presented. 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. SUBJECT: The SUBJECT 'phrase' is placed into the text. There are some special points with this method worth more attention: ... Any text added from these routines can be deleted or changed if required. The change or deletion WILL NOT affect the cross reference capability. ... Whilst text search can also find the data, it can also find notes where the letters were found but the subject was wrong. ... With the time of data entry spanning many years there is no guarantee that the same phrase is typed in the same way. ... The method 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. ... Search times will depend upon the speed of the computer and the number of notes. All notes are searched in SEQUENTIAL order which in time may take a few minutes. =*=*=*= Page 85 =*=*=*= *********************************************************** * Getting started - General Information Notes * *********************************************************** **************************************************** ... A 3Mb text/note limit depends upon base memory. This limit may vary up or down depending upon the program environment. In real terms NOTES are generally only 1 - 200K in size. ... There is potential for 64Kbytes of cross referenced material per NOTE. This equates to 5000 cross referenced items PER NOTE. In reality, the cross reference data depends upon the EDITOR size. NOTES are broken down into BLOCKS. The BLOCK size can vary upon memory. Because NOTES are generally small, a new NOTE is allocated to ONE BLOCK. The BLOCK size can be altered by changing the EDITOR size from 'Utilities/Options'. To allow the NOTE to expand 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 20K ( about 20,000 ) 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. Please note that the text is not automatically adjusted between BLOCKS. All that is done is to place a NEW BLOCK at the end of text; this adds another 20k of text capability. 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. The cross referencing system is not affected by any change to the NOTES size or by the number of BLOCKS. =*=*=*= Page 86 =*=*=*= *********************************************************** * Getting started - Data References * *********************************************************** **************************************************** From inside the JotNotes ( F10 ) there is a section for References. This is where major references are abbreviated and described for use. Any use within the program can then be by the code. For example a reference to a specific book could be '[Book1]'. The JotNotes/References would show: [Book1] : 1973 Book No.1 handwritten workshops records 1960-1973 Any reference to this 'book' would be by the code '[Book1]'. To allow for this description to be included in data output, the special letter code with delimiters must be used. A data reference could be: [Book1]: shows converted 1/1961 and painted silver. On output the reference '[Book1]' is matched with the JotNotes/Reference. References must match exactly for the listing to work. =*=*=*= Page 87 =*=*=*= *********************************************************** * Tutorial * *********************************************************** **************************************************** 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. 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 =*=*=*= Page 88 =*=*=*= *********************************************************** * Tutorial - Australia * *********************************************************** **************************************************** This will involve a simple non existant vehicle. The program will establish certain codes and versions which can be deleted if required later. In most cases the user is urged to establish a code called 'TEST' or even better a SYSTEM called 'TEST' which would isolate experimental work from the real 'gutsy' stuff. The following histories are going to be typed in. In most case information is not presented in such a concise way. It is gathered and collected across 10 - 20 years, if not more. To represent this the data is presented in ad-hoc fashion Use these code descriptions. In the SV column the S indicates system and the V is the version letter. The user has control of the System letter. The program generates the V/Version letter. Code SV Date Sys Description Type A VA 1900 - VR F/Whl Boxvan Freight B VB 1915 - VR F/Whl Boxvan Freight C VA 1925 - VR F/Whl Boxvan Freight One vehicle with three identities with the data collected in sequence as follows: C 500 Scrapped 1945 A 100 Built New at Newport Workshops, 10/10/1900 C 500 photographed 21/1/1938, photo #1200.46 B 27 rebuilt to C 500, 1931 A 100 stored at Newport Workshops 1921 to 1926 A 100 rebuilt with new side doors about 1917 C 500 sighted in sleeper traffic 1937 A 100 referenced in book "Along the Line" p28, 1916 A 100 converted to B 27 Oct 1927 A 100 modified with new type handbrake 1912 B 27 modified with new type brake, 1929 F3/STEP history output would appear from the program as: Vehicle............ # Date...... Loc History........... Notes *A 100 - 10/10/1900 NWS Built new - / /1912 - Modified new type handbrake / /1916 - Reference p28, Along the Line circa 1917 - Modified New side doors / /1921 NWS Stored ... til 1926 / /1927 - To B 27 - B 27 - / /1929 - Modified New type handbrake / /1931 - To C 500 - C 500 - / /1937 - Traffic in sleeper/tie 21/ 1/1938 - Photograph #1200.46 / /1945 - Scrapped - =*=*=*= Page 89 =*=*=*= *********************************************************** * Tutorial - Australia * *********************************************************** **************************************************** Later the railways built a replacement vehicle B 27 which performs the same job as the original. As it performs the same job, it slots into the same 'version'. So the new data would be B 27 Built new 1935 B 27 Scrapped 1956 B 27 referenced in plan B - 17, dated 1948. B 27 Pole traffic 1949 - 1955 Notice that when adding this data the history fits in quite well. Now for the editing. Edit each line for the B 27 history. Put a number '1' in the Vehicle field in the edit window for each of the data items that belong to the FIRST vehicle. Do likewise for the SECOND vehicle but instead of '1', use '2'. This is the output from an F3/STEP history request for B 27: Vehicle............ # Date...... Loc History........... Notes A 100 - 10/10/1900 NWS Built new - / /1912 - Modified new type handbrake / /1916 - Reference p28, Along the Line circa 1917 - Modified New side doors / /1921 NWS Stored ... til 1926 / /1927 - To B 27 - *B 27 1st / /1929 - Modified New type handbrake / /1931 - To C 500 - C 500 - / /1937 - Traffic in sleeper/tie 21/ 1/1938 - Photograph #1200.46 / /1945 - Scrapped - {--------} *B 27 2nd / /1935 - Built new - / /1948 - Reference Plan B-17, dated 1948 / /1949 - Traffic Pole traffic til 1955 / /1956 - Scrapped - Note: The '{-------}' is the paragraph ID marker which denotes data joined because there is information from multiple vehicle ID. The '*' represents the vehicle that 'intitiated' the search. Lets back up a bit. Just suppose that the first B 27 was not converted until 1936 because the railways kept it in the Workshops 'off the books' from 1931 until 1936 when it was converted. Change the conversion date from 1931 to 1936 and add an 'Off Register' history of 1931. Notice that the histories still hold together. =*=*=*= Page 90 =*=*=*= *********************************************************** * Tutorial - North America * *********************************************************** **************************************************** I am including some info here as one method for storing data on North American activities. There are many ways to accomplish the same task from the this program. Only the user can decide by feeling comfortable about a certain methodology. To maintain rapid data entry with minimum information I have broken down the North American rail rolling stock into four basic categories: Steam, Diesel, Freight Cars, Passenger Cars. Miscellaneous stock such as MofW and vans fit into freight cars. The categories are basic, the intent is not specific groups. I'll use Santa Fe as an example. I would create four Santa Fe 'codes' of 'ATSF'. The code can be the Reporting Mark, AAR alpha-numeric code or a code selected by the user. Now whatever the method selected there are two points to remember: (1) the same data can be found no matter what the description and (2) because the user typed in the data, the memory of the method remains. The descriptions are defined below. I've created three for the example. It's up to the user to decide whether to split Loco Fleet into steam and diesel. Code.. Date...... Sys V Type..... Description................... ATSF ---- N/A A Frgt Freight Cars ATSF ---- N/A B Loco Loco Fleet ATSF ---- N/A C Pass Passenger Fleet From most references the user can now decide whether the Santa Fe data is about Loco's, freight cars or passenger cars. The specific description of the item is included in the notes. This allows the user to add data and follow up later. The main problem of specific identification of an object is the lengthy search required to find more data. The program was designed to avoid this, hence the general nature of data entry. So to include a photo of ATSF 123456 freight car, loco 8234 or pass car 20007, the user can see there are only three choices to select from. It is quite possible to set an 'ATSF' loco description specifically for SD40's for example. It would be easy to find all the SD40 fleet but can cause problems with data entry. Specific definitions can also use up most of the 84 limit allocation of code descriptions per letter group. A list of the above photographs would show: ------ ATSF ---- - N/A Freight Cars Freight Number # Date Loc Activity Notes 123456 - / /1986 - Photograph Slide 123/456 Hopper ------ ATSF ---- - N/A Loco Fleet Engine Number # Date Loc Activity Notes =*=*=*= Page 91 =*=*=*= *********************************************************** * Tutorial - North America * *********************************************************** **************************************************** 8234 - / /1986 - Photograph #34: SD40 ------ ATSF ---- - N/A Passenger Fleet Passenger Number # Date Loc Activity Notes 20007 - / /1986 - Photograph #1200 To add to the example, I present a fictitous scenario that loco 8234 gets renumbered to 8000 and another loco is built that is 8234. The program shows: Vehicle............ # Date...... Loc History........... Notes *ATSF 8234 1st / /1986 - Photograph #34: SD40 circa 1987 - To ATSF 8000 - {--------} *ATSF 8234 2nd / /1988 GE Built new C36-7 / /1990 - Photograph #500, slide Code SV Date Sys Description Type ATSF UB ---- - N/A Loco Fleet Engine Code Location / Builder - - GE GENERAL ELECTRIC CO An interesting point to remember when adding histories to multiple ID's: in most cases there is no need to be aware of the multiple ID's until the point of data entry. Then a decision can be made about which ID 'belongs' to the history. Even if a mistake is made, the data is still there. A modification of the program has now allowed multiple ID's up to a maximum of 36. This allows plenty of scope for the mass of renumberings on North American systems. =*=*=*= Page 92 =*=*=*= *********************************************************** * Tutorial - Europe * *********************************************************** **************************************************** This is the area where I think the program doesn't work so well. As Europe has many rail systems and most of the systems employ codes and numbers, there is some difficulty in anticipating what users want. The program can cope well with a single system easily enough. The problem I see is general interest such as photography across all the systems. One approach that could be used is the 'General Notes'. The reference system allows over 1,000,000 references. The user can type any 30 character Name/number/description and include the data in thee Notes. Probably not elegant but at least it works. =*=*=*= Page 93 =*=*=*= *********************************************************** * Tutorial - General Information Notes * *********************************************************** **************************************************** The following paragraph of fictitious data will be used for an example of data entry and search: 'Sighted today at Wallan was a freight train loaded with pipes. This is the start of pipe traffic Albury to Melbourne for the new gasline' The date of the sighting is April 1967. The data entry: .. Call up the Notes ( Add/Notes ) .. The program will give a default note number to use. Press to use this number. Otherwise add an appropriate identifier/number. .. Add the date .. Add a descriptive heading. For non specific sighting, this can simply be 'Daily Notes'. .. Data entry can now proceed. Type in the paragraph as shown. .. There are three key locations: Wallan, Albury and Melbourne. At the bottom of the text press the F6 key for locations and add the three towns. The towns and codes are added into the text. .. Delete the town text added by the program as this is not required now. .. Save the note ( F2 or ESC ). .. Repeat the above in a new note BUT when each town is mentioned, press the F6 key and add the location from the table. .. Save the note as before. Searching: To find from the notes, all notes that mention Wallan the procedure is simple. .. Goto to Find/Notes and select 'Location'. Select Wallan from the table. .. Move the menu bar down to the 'List Text' search and press . .. The program will search every note reference looking for 'Wallan'. This is NOT a text search. The above example applies equally well for CODES and SUBJECT/REFERENCES. The search becomes more powerful when the search criteria are combined. =*=*=*= Page 94 =*=*=*= *********************************************************** * Technical * *********************************************************** **************************************************** =*=*=*= Page 95 =*=*=*= *********************************************************** * Technical - Files * *********************************************************** **************************************************** This is the list of file structure and what the program uses the fields for. Temporary files that are uses and deleted are not included. Location File ------------- Structure for database: REGLCTN.DBF Field Field Name Type Width Dec Program Use 1 LOCATION Character 30 0 Location description 2 VELAS Character 3 0 Location 3 letter code 3 USE_TALLY Numeric 2 0 Tally of menu use **Total** 36 Subject Reference File ------------- Structure for database: REGPREF.DBF Field Field Name Type Width Dec Program Use 1 REFERENCE Character 30 0 Reference description 2 VELAS Character 3 0 Reference 3 letter code 3 USE_TALLY Numeric 2 0 Not used (will be removed) **Total** 36 Version File ------------ Structure for database: REGVER.DBF Field Field Name Type Width Dec Program Use 1 TYPE Character 1 0 Type code 2 CODE Character 6 0 Alphanumeric vehicle 'ID' 3 VERSION Character 1 0 Program generated version letter 4 DATE Character 4 0 Year of first use 5 LAST_ON Character 4 0 Year of last use 6 MEMO Character 30 0 Vehicle class description 7 STATE Character 1 0 System ID letter 8 USE_TALLY Numeric 2 0 Tally of menu use 9 AUDIT Date 8 0 Last date of data check for Vehicle ID 10 DL_DATE Date 8 0 Last date of a 'Data Log' download 11 COMPLETE Date 8 0 Date user determintes as 'all info recorded' 12 WAG_COUNT Numeric 5 0 Program count for number of ID's found 13 UK_COUNT Numeric 3 0 Unknown vehicle count 14 NAMES Character 4 0 Car name storage here. Only used by '-' Codes. **Total** 86 History File ------------ Structure for database: REG_HIST.DBF Field Field Name Type Width Dec Program Use 1 USE_TALLY Numeric 2 0 Menu tally of use 2 CODE Character 1 0 Single letter code for history 3 FULL_DESC Character 21 0 History description 4 T_DESC Character 3 0 Tally Table header letters 5 T_ORD Character 2 0 Tally Table ordinal list 6 GROUP Character 1 0 Rule code: O, S, I or P =*=*=*= Page 96 =*=*=*= *********************************************************** * Technical - Files * *********************************************************** **************************************************** 7 LAST_USE Character 4 0 Recorded data from vehicles using this history 8 USE_DATE Date 8 0 Date last used in Add menu **Total** 43 Notes File ---------- Structure for database: REG_REF.DBF Field Field Name Type Width Dec Program Use 1 DATE Character 8 0 Note date 2 REF_NO Character 6 0 Note Number 3 HEADER Character 30 0 Note description 4 REFERENCE Character 4 0 Note reference list 5 TEXT Character 4 0 The notes **Total** 53 System File ----------- Structure for database: REG_STAT.DBF Field Field Name Type Width Dec Program Use 1 STATE Character 1 0 System code letter 2 STATE_REF Character 35 0 System Description 3 STATE_CODE Character 4 0 1-4 character alpha-code for System **Total** 41 Vehicle Type File ----------------- Structure for database: REGTYPE.DBF Field Field Name Type Width Dec Program Use 1 CODE Character 1 0 Type code letter 2 F_DESC Character 20 0 Lengthy Type description 3 S_DESC Character 4 0 Short Type description 4 USE_ORDER Numeric 2 0 Tally for menu use **Total** 28 Vehicle DataFile ---------------- Structure for database: REGWGN.DBF Field Field Name Type Width Dec Program Use 1 CODE Character 6 0 Vehicle Code 2 NUMBER Character 6 0 Vehicle Number 3 VERSION Character 2 0 Vehicle Version letters (System + Version) 4 DATA Character 4 0 Pointer to Data **Total** 19 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. The original program stored data in a database that referenced itself. The system at the time whilst fast ( faster than this system ) relied on pointers which required a lot of space and manipulation. The current storage method is a table called an array. The array can =*=*=*= Page 97 =*=*=*= *********************************************************** * Technical - Files * *********************************************************** **************************************************** 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, data loss has been minimal. This means that out of 82,000 vehicles listed that account for 220,000 pieces of information I have only lost about 20 vehicle histories. These were recovered from the 'DataLog' files. Knowing which records are damaged is the key, this is why the routine 'Integrity' was established. If these problems continue all I can do is to completey re-structure the program data back to dbf files. This would increase the size of the program by about 20%. =*=*=*= Page 98 =*=*=*= *********************************************************** * Technical - Miscellaneous * *********************************************************** **************************************************** 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. =*=*=*= Page 99 =*=*=*= *********************************************************** * Technical - Problems * *********************************************************** **************************************************** The program has been prototyped to this stage. 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 five 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 *.cdx' 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). =*=*=*= Page 100 =*=*=*= *********************************************************** * Technical - Problems * *********************************************************** **************************************************** ------------------- 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. =*=*=*= Page 101 =*=*=*= *********************************************************** * Technical - Problems * *********************************************************** **************************************************** ...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. 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. Therefore 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. 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' Log Files: =*=*=*= Page 102 =*=*=*= *********************************************************** * Technical - Problems * *********************************************************** **************************************************** --------- 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. =*=*=*= Page 103 =*=*=*= *********************************************************** * Technical - Problems * *********************************************************** **************************************************** 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. =*=*=*= Page 104 =*=*=*= *********************************************************** * Technical - Archive / Backup: * *********************************************************** **************************************************** As the program is now being distributed on the 'Internet', I am assuming the user has backup knowledge and experience on the basis of computer access to get the file. The files to be backed up are: *.dbf, *.exe, .\log\*.sav, *.pjv, *.bat If in doubt backup the entire directory and go from there. Best strategy is backup as frequently as data entry is done; regular backups with alot of data entry, no backup with no data entry. 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. 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. 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. WARNING: Any restore of the program MUST restore all files, not just some of them. =*=*=*= Page 105 =*=*=*= *********************************************************** * Table of Contents * *********************************************************** **************************************************** Notices.............................................page 3 User Registration...................................page 3 Modifications and Bug Fixes.........................page 4 Installation........................................page 7 Running in DOS......................................page 9 Running in WINDOWS..................................page 10 Program Development.................................page 11 Known Inconsistencies...............................page 12 Program Design......................................page 13 Definitions.........................................page 14 Definitions - Vehicle Identity......................page 15 Definitions - Code..................................page 16 Definitions - Version...............................page 17 Definitions - Owning System.........................page 19 Definitions - Number................................page 20 Definitions - Name..................................page 21 Definitions - Date..................................page 22 Definitions - Notes.................................page 23 Definitions - History...............................page 24 Definitions - History Groups........................page 28 Definitions - Location..............................page 29 Definitions - Local History.........................page 30 Definitions - Step History..........................page 31 Definitions - Vehicle ID............................page 32 Definitions - Subject / Reference...................page 33 Program Operation...................................page 34 Program Operation - Output file access..............page 36 Program Operation - Text Editor.....................page 37 Program Operation - Pop up Notes....................page 39 Main Menu...........................................page 41 Main Menu - Add.....................................page 42 Main Menu - Find....................................page 43 Main Menu - Summaries...............................page 48 Main Menu - Edit....................................page 55 Main Menu - Utilities...............................page 60 Getting Started.....................................page 68 Getting Started - Code..............................page 69 Getting Started - Number............................page 72 Getting Started - History...........................page 75 Getting Started - Location..........................page 77 Getting Started - Subject / Reference...............page 79 Getting Started - Date..............................page 80 Getting started - Vehicle Notes.....................page 82 Getting started - General Information Notes.........page 83 Getting started - Data References...................page 87 Tutorial............................................page 88 Tutorial - Australia................................page 89 Tutorial - North America............................page 91 Tutorial - Europe...................................page 93 Tutorial - General Information Notes................page 94 Technical...........................................page 95 Technical - Files...................................page 96 Technical - Miscellaneous...........................page 99 Technical - Problems................................page 100 Technical - Archive / Backup:.......................page 105 =*=*=*= Page 1 =*=*=*= *********************************************************** * Technical - Archive / Backup: * *********************************************************** **************************************************** INDEX...............................................page 107 =*=*=*= Page 2 =*=*=*= *********************************************************** * Index * *********************************************************** **************************************************** ACTIVITY................5,24,39,43,48,49,52,61,67,91,92,105 AUTOEXEC..................................................4 BACKGROUND............................................10,34 BACKUP.........................................2,60,102,105 BUILDER......................................18,29,50,77,92 CAR NAME....................................4,5,12,56,72,96 CLIPPER..................................................37 CODE.................4,5,7,12,15,16,17,18,19,21,24,26,28,29 31,32,33,36,37,42,43,44,45,48,49,50,51 52,53,54,55,56,57,58,60,61,62,63,64,65 67,69,70,71,72,73,74,76,77,79,82,83,84 85,87,88,89,91,92,93,94,96,97,101,102 103,104 CONFIG..........................................4,7,8,10,65 DATALOG...............................................65,98 DATA_LOG.SAV......................................12,60,103 DATE................4,5,12,13,18,22,24,25,28,36,39,42,43,45 46,48,49,50,52,53,56,57,58,61,62,65,66 69,70,71,73,76,80,81,83,84,88,89,90,91 92,94,96,97,103 DOS...................2,4,8,9,10,11,36,42,64,65,100,101,102 FAILURE...................................52,74,100,101,102 FILES.................2,7,8,9,10,13,15,17,25,36,41,42,60,61 62,64,65,67,96,97,98,100,101,102,103 104,105 FOREGROUND...............................................10 F2..................................52,55,57,69,72,73,88,94 F3...................................4,37,55,62,73,80,89,90 F4..............................................37,55,70,81 F5...........................................37,70,73,81,85 F6..............................................38,73,85,94 F7.....................................................4,85 F8.................................................35,36,60 F9.....................................................4,83 F10..............................................4,35,39,87 GENERAL PROTECTION FAULT.................................10 HISTORY.............5,7,13,24,25,26,27,28,29,30,31,32,42,43 44,50,52,53,58,63,66,67,70,73,75,76,77 80,88,89,90,92,96,97 IDENTITY............5,7,12,17,21,22,24,25,26,30,42,51,54,73 76 JOTNOTES........................................39,63,66,87 LOCATION.............4,6,7,12,13,24,29,33,39,42,43,45,50,55 56,57,58,60,64,70,71,76,77,78,82,84,85 91,92,94,96 MENU................4,5,10,12,34,36,41,44,46,48,53,55,56,60 61,62,63,64,67,70,73,75,83,88,94,96,97 100,101,102 MONO......................................................9 NAME................4,5,10,12,13,16,21,29,31,36,37,39,44,56 60,62,63,64,69,70,72,73,93,96,97,100 102,103,105 NOTES.................4,5,7,9,12,13,18,23,27,32,33,39,41,42 44,45,46,52,56,58,60,62,63,64,66,76,81 82,83,84,85,86,87,89,90,91,92,93,94,97 98,99,100,103,104 =*=*=*= Page 106 =*=*=*= *********************************************************** * NOTES * *********************************************************** **************************************************** NUMBER................4,5,7,8,12,13,15,16,17,19,20,21,23,24 26,27,28,32,37,38,39,42,43,44,45,46,48 49,50,52,53,54,55,56,57,58,60,62,63,65 66,67,69,70,72,73,74,75,76,82,83,84,85 86,88,90,91,92,93,94,96,97,100,101,103 PIF....................................................7,10 QUIT..................4,8,10,12,41,51,65,67,76,77,90,91,100 REFERENCE.............4,5,7,9,13,15,17,18,19,21,23,24,25,26 27,29,30,31,33,39,42,45,46,50,51,53,54 55,56,57,58,60,61,62,63,64,66,69,70,72 73,74,79,82,83,84,85,86,87,89,90,91,93 94,96,97,98,99,101,103 REINDEX...........................................64,65,102 SETUP....................................4,8,62,63,65,66,83 SHELL..................................................4,65 SPEED..................................2,10,11,64,79,85,103 SUBJECT....................4,5,7,33,42,45,56,79,84,85,94,96 SYSTEM..............5,7,13,14,15,16,17,18,19,26,43,49,50,53 54,56,58,60,61,62,63,69,70,73,86,89,92 93,96,97,98 TALLY.....................2,5,32,48,49,50,53,54,58,61,96,97 TIMELINE.................................................53 UNDERFRAMES........................................16,50,73 UNKNOWN...............5,12,16,22,25,44,48,53,66,72,73,74,78 80,81,96 USER ID...................................................4 UTILITIES...........5,10,12,36,39,41,49,53,55,65,86,100,102 VELAS.................................................77,96 VERSION...............2,4,5,7,11,13,15,17,18,31,32,34,37,44 48,49,50,53,54,56,58,61,63,67,69,70,76 88,89,90,96,97,101 WARNING.........................................2,10,55,105 WINDOWS........................................4,7,10,11,34 =*=*=*= Page 108 =*=*=*=