My GeoCities Guestbook

The original guestbook leave-a-comment page

The following is approximately how the original guestbook leave-a-comment page would have looked, but it was evidently unavailable for much of the time I was there, because it was replaced by another guestbook system. I didn't realize this until near the end, because I seldom tried to access that page. I have this information about the page only because I had the code for the page, and indeed the page itself, though when I tried to go to it through the link I got an error, because it tried to access other things that were no longer used by Yahoo. I do think I remember trying to access it a few times several years ago and got an error then, too, but attributed it to a problem on Yahoo's part. I don't remember if I ever noticed anything about the guestbook system being changed.

Active links have been changed from the originals to point to addresses on this blog. Any links that are part of the comments and appear in plain text form are just dummy test data and are not valid links, or at least were not intended to be.


Title: ADD Entry to Stephen Morgan's Guestbook


Welcome to my Guestbook! Please sign in and leave a message. The fields are optional. Fill in as many as you feel comfortable doing, but please leave some means of identifying you as a unique visitor, such as a nickname, even if the nickname is chosen solely for this site.

I read all messages. If you would like me to respond to a message, please leave your email address. Note that email addresses will be visible to other visitors. If you would rather not have other visitors view your email address, leave your greeting or message here and send me an email with your address in the body. An email may be sent to me through the link on my home page.

Nickname:

URL:http://

Email:

City and State:

Your Comments:

---

The original guestbook

The following is the guestbook as it appeared for almost all the time it was there. The first comment is a test comment by me, but the second one was real. I have blocked part of the email name, but it was complete originally.


Title: Past Visitors to Stephen Morgan's Guestbook


Welcome to my Guestbook! Entries of past visitors may be viewed here.

Sahid sumitro - 11/11/00 23:05:56
[thin blue line]
[thin blue line]
My Email:--------@yahoo.com
City and State: indonesia
Comments:
I want to look for guide book of visual foxpro,
If you don't mind, help me please... and send me a book.

thnaks
[thin blue line]

S. Morgan - 08/02/00 06:25:46
My URL:http://whereeveriam.com
My Email:www@http.com
City and State: Whereiam, US
Comments:
This IS a test.
[thin blue line]


My Home Page
Explore Yahoo! GeoCities
Get your own free homepage

---

Testing the original guestbook

The following three test entries were deleted and replaced by one with more obscure info, as shown above. The ones below appeared for only a short time.


Title: Past Visitors to Stephen Morgan's Guestbook


Welcome to my Guestbook! Entries of past visitors may be viewed here.

S. Morgan - 08/01/00 14:10:20
City and state: field 4
Comments:
Test 3.

S. Morgan - 08/01/00 14:08:34
My URL:http://anywhere.com
My Email:field 3
City and state: field 4
Comments:
Test 2.

S. Morgan - 08/01/00 14:02:01
My Email:Scottsdale, AZ
Comments:
This is my message to myself. This IS a test.


My Home Page
Explore Yahoo! GeoCities
Get your own free homepage

---

The new guestbook

The following is the new guestbook with my comment as it appeared, with the end cut off. Unlike the prior guestbook, the new one used a common storage area at Yahoo for the guestbook leave-a-comment and view-comments pages and for the data, so nothing for it appeared at my site. The only access was through links, which i didn't install on my web page, as there were only hours left before GeoCities shut down. I accessed the guestbook myself by pasting the links directly into the browser address bar.


First Name : Stephen
URL : http://stephen-has-spoken.blogspot.com/
Comment : This is the first and likely only comment, as the GeoCities site is closing down today (its 2:03 AM Monday, October 26, 2009 now), and I am not likely to add the Guestbook links to my home page. It already has such links, but the Sign option no longer wor

[narrow double red line]


Return to Web Site Sign Guestbook

---

The comment in full

The following is my comment as it was actually written:

This is the first and likely only comment, as the GeoCities site is closing down today (it's 2:03 AM Monday, October 26, 2009 now), and I am not likely to add the Guestbook links to my home page. It already has such links, but the Sign option no longer works, evidently because of a change in how it's done.

---

My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
Program List
Utility Programs, Part I - Printers
Utility Programs, Part II - Error handlers
Programs, Part I
Programs, Part II
Programs, Part III
Programs, Part IV

Resume

Home

Stephen Morgan's Resume

Email: stephen_m99@yahoo.com

Objective

A position in computer programming using Visual FoxPro to create and maintain programs and databases.

Summary of Qualifications

• Experience with Visual FoxPro
  
• Experience with Datastream MP2 5.0 Enterprise for MS NT SQL Server, including writing Visual FoxPro programs to import records.
  
• 10 years of experience with FoxPro, FoxBase and dBASE III. This includes creating and upgrading a wide variety of programs of all sizes and complexities.
  
• Experience with multi-user programming, including site level and user level security.
  
• Experience with software documentation, including writing and editing user manuals and detailed descriptions of program operations.
  
• Experience with Novell NetWare and Microsoft Windows NT SQL Server.
  
• Experience with the programming languages of Assembly, BASIC, Pascal, and C.
  
• Can work alone or as part of a team. Though most work was performed alone, some activities were coordinated with another programmer who worked on a related program, with the programs released as a team effort.
  

Professional Experience

Using Visual FoxPro:

• Created programs to import records from DOS FoxPro tables to Datastream MP2 5.0 Enterprise for MS SQL Server 6.5 after reworking tables and data to match MP2 requirements.
  
• Created a program to reopen (unclose) MP2 work orders.
  
• Created custom MP2 reports.
  
• Corrected various MP2 data problems through direct commands to SQL Server from Visual FoxPro and through specially created programs for that purpose.
  
• Created a form for searches.
  

Using FoxPro, FoxBase and dBASE III:

• Created programs for inventory control, data entry, and equipment status tracking, as well as modifying and rewriting existing programs. Program features included complex screen displays, extensive file manipulation, data validation and error checking, mathematical computations, and a variety of menu driven options and editing features.
  
• Screen displays included screen and window scrolling, left-right scrolling, displays of help instructions, switching and returning from record lists to specific records, and multiple window displays.
  
• Database manipulation/management included creation of temporary work files, verifying and/or copying specific information across files, use of multiple tables, complex indexing/sorting, movement of table information across networks, simultaneous access of tables by multiple users, automatic notification of data updates, and automatic updating of data displays.
  
• Data validation included checking of values and formats, and duplicate entry prevention.
  
• Some programs were written with spreadsheet-like screens that computed totals and subtotals, including both horizontal and vertical calculations.
  
• Programs were written to automatically generate monthly/quarterly inventory summary records.
  
• A complex error and exception handler was created. Error data was logged to a table.
  
• A complex program was created to allow the entry of printer codes, printer location (LAN or local) and printer menu choices. The average user simply had to choose the appropriate printer from the menu, and the program saved the choice.
  
• Programs were created which printed highly detailed forms when an HP LaserJet printer was chosen. The form was hand-coded and the graphics and text micro-positioned.
  

Using Turbo C:

• Created a program for polling machinery operation status through a modem by utilizing PC interrupts, for the purpose of querying a large UPS for status and other data. Also created an associated FoxPro program. The C program wrote text files containing the UPS data, which were then read by the FoxPro program. If the power to the UPS went down, the FoxPro program notified users over the network by use of the Novell SEND command.
  
• Created a program for printing the company logo (Ford Aerospace) on dBASE III/FoxBase reports.
  

Networks:

• Assisted in troubleshooting Windows NT Server.
  
• Assisted in troubleshooting, installation and maintenance of NetWare 3.x and 2.x servers.
  
• Installed NetWare 2.15C and set up server and workstations to communicate through modems.
  

Education

2000

Landmark Forum
Landmark Education Corporation, Phoenix, Arizona

1997

MP2 5.0 Enterprise Training
Datastream Systems Incorporated, Irvine, California

1988

Bachelor of Science in Electronics Engineering Technology
Presidential Honor Society
Upsilon Delta Chapter of Tau Alpha Pi
DeVry Institute of Technology, Phoenix, Arizona

Work History

Lockheed Martin/Loral/Ford Aerospace (they merged), Fallon, NV

1990-1998

Software Engineer/R&D Engineer

1988-1990

Associate Software Engineer

Volunteer Experience

Expert in multiple categories on askme.com (as stephen2345)


Home

Program List

Stephen Morgan's Projects


This is a partial list of my past projects. Almost all are in FoxPro for DOS 2.0, though some are in Visual FoxPro 5.


Printer Menu - Details

Error Handler - Details

Startup Error Handler - Details

Error Handler for Visual FoxPro - Details

Status Monitor - Details

ECP Summary - Details

ECP Pages - Details

Config. Status Acct. Rpt. - Details

DCN - Details

ICN - Details

TEC - Details

Engineering Drawings - Details

Engineering Taskings - Details

Engineering Release Record Forms - Details

Technical Library - Details

Barcode Trakker-Inventory - Details

Barcode Trakker-Technical Library - Details

Training Program - Details

Shipping Documents - Details

GFE Inventory - Details

Test Equipment - Details

Key Control - Details

Job Control-Equipment Status - Details

Range Manager-Equipment Status - Details

Smoky Sams Usage - Details

QA PDR Forms - Details

UPS Alerts - Details

MANDATE - Details

Supply - Details

Supply-Purchasing Interface - Details

Supply-Servmart Interface - Details


My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
Program List
Utility Programs, Part I - Printers
Utility Programs, Part II - Error handlers
Programs, Part I
Programs, Part II
Programs, Part III
Programs, Part IV

Utility Programs, Part I - Printers

Stephen Morgan's FoxPro Projects - Utility Program Details

Introduction

This area offers details of some major general-purpose programs used in some form by almost all the full application programs I wrote. Unless noted, all these programs were written in FoxPro 2.0, for DOS. Some early programs started out in dBASE III PLUS or FoxBase, but all were converted to FoxPro at some point.


Printer Menu

One of the first versions of the printer menu program was as a short list of available printers for the Technical Library program. The list included a high speed LAN printer. At that time, the Novell CAPTURE command was used to access the printer, but this caused memory problems if the command was used more than once or twice in a program session. Eventually, FoxPro added a command to access printers on a Novell network, and that command was substituted.

The printer menu eventually had four or more options, with the LAN printer being one of them. The printer codes were usually placed just before the report began and just after it ended, though some hand-coded reports had internally placed codes because of such things as expanded-print bold titles and different character spacing at different points in the reports. The printer codes were soon placed in variables instead of being stated directly, though extra steps were necessary in processing the LAN printer because of the requirement of connecting and disconnecting. Not all programs were given a printer menu, though the Engineering programs usually were. It became a problem to keep updating the code for all the programs, so I eventually wrote a separate program.

In the separate printer program, the printer names and printer codes were kept in tables instead of being hard coded. Three tables existed: one with the users' names and printer choices; and with the printer names and codes; and one with the actual menu options. The one with the menu options also tracked whether the printer was LAN or Local, and the server name was also recorded. Key numbers existed for the menu options and for the printer definitions.

Though the program worked well, it had a major deficiency in that it did not have the ability to edit anything. All editing had to be done directly from FoxPro. I had not wanted to get too deeply into writing a printer program because I was expecting FoxPro to offer a printer selection utility. However, the utility FoxPro offered was extremely slow in operation and required setting up predefined report definitions. This meant that I had to either set up a report definition for all necessary printers and continue offering the user my own menu, or rely on the user to set up the definitions (and to know what the definitions should be). For example, a user would have to know that a report required 17 characters per inch. Also, although a table of printers and codes was provided, altering anything required recompiling the utility. The utility could also be used only with FoxPro report forms, and not with hand-coded reports, which were sometimes absolutely required for Engineering printouts.

It became evident that FoxPro would not provide what I was looking for. Also, some programs on which I wished to implement the printer menu were going to be released to other locations, and it would not be right (or workable) to require the users at the other locations to set up the printer records directly from FoxPro. I then created the second major version of the separate printer menu program.

In the new version of the program, the menu options and printer definitions were set within the program. The users were not manually set within the program, as the program automatically detected new users and added user records as necessary. User names were placed in a variable in the DOS environment at the time of network login, and most of the programs accessed that variable for a user name, though Status Monitor had a partially separate system. All that was needed was a common variable name that the printer program could access, or at least a known range of possibilities. The programs did not in fact all have the same user variable name, so the printer program checked for all reasonable variations on the variable name before looking for a name in the DOS environment. (Some initial user variable name possibilities were User, MUser, UserName, and MUserName. This list was later expanded after variable type and scope prefixes were added, producing variations such as cUserName and gcUserName. Although I did not personally implement scope prefixes, I thought it best to check for them in order to handle possible future situations.)

What the printer program did was set public variables with the users' printer choice, and save key numbers recording the users' choice in a record. Normally, the printer program did not save a LAN printer choice, but could be configured to allow this.

When a report was to be printed, modules within the application program, not the printer program, accessed the variables, connected to the named file server if the choice was a LAN printer (or connected to the default server if a server was not explicitly named), and sent the appropriate printer codes (held in code variables such as cCPI10, cCPI17, cLPI6, and cLPI8) for that report. After printing, the printer codes to restore the normal printer state were sent, and if the printer was a LAN printer, a disconnect was sent by setting the printer to local.

This allowed both report forms and hand-coded reports with internal printer codes to be used.


My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
Program List
Utility Programs, Part I - Printers
Utility Programs, Part II - Error handlers
Programs, Part I
Programs, Part II
Programs, Part III
Programs, Part IV

Utility Programs, Part II - Error handlers

Error Handler

Originally, none of the programs had an error handler. I had never used an error handler, and none of the preexisting programs had one. I tried to write the programs to eliminate as many errors as I could. This was not enough to totally prevent errors, and so I eventually began to explore setting up an error handling system.

The error handler was originally centered on handling file-does-not-exist problems (if the requested file is on an unavailable file server, this can easily cause the error) and file-is-in-use-by-another errors, and had minimal processing for other errors. Except for printer-not-ready errors, most errors resulted in shutting down the program, since the consequences of allowing the program to continue with an unresolved error is great. Exceptions were allowed if the section of the program from whence the error originated indicated that it would be able to handle the problem.

For instance, if a table was unavailable and the user did not want to retry, and the section of the program where the error occurred had previously set variables indicating that the command was being checked, the error handler would return control to that portion of the program after setting a variable to an error value and the program would see that an error had occurred and cancel the operation.

What would happen if the program had simply continued, thinking the table had been opened? The user would eventually be presented with some other error. Perhaps a field would be referenced and a variable-not-found error would occur, or a string of such errors if the error handler kept returning control to the program. Eventually, a command would probably be encountered which would cause FoxPro to believe that a table should be open. At that point, FoxPro would present the user with a list of available tables to open. Even if the user knew which table to select, any associated indexes would not be opened and so the indexes would be corrupted if the table was updated. No guarantee exists that the table would be positioned on the correct record or that the correct table would be chosen. If the wrong table was chosen, the program might proceed without further activating the error handler, as some commands are sufficiently general as to work with any table, but the wrong table would be used. What if the command was to update a record, delete a record, or to delete ALL records?

Even a variable-not-found error can be dangerous. If the variable not found was being used to initialize another variable, then the variable is not initialized and may itself not be found when the variable is later referenced. {If the variable has been declared in some fashion, the variable will exist, but may be of the wrong data type.) If either variable is used in another command, then that command will fail, whatever that command may be. For an extreme example, what if table work area numbers are kept in variables, and the program intends to switch work areas, delete all the records in a temporary table, and then return to the original work area, which holds a permanent table with 30,000 records? If the work area variable does not exist, an error will occur and the work area selected will remain that holding the permanent table. If the program is allowed to continue, and the next command is to delete all records, the 30,000 records in the permanent table will be deleted instead of the records in the temporary table.

It would be best if some means were provided to allow the user to safely continue. Eventually, I devised a system where variables held the name of the module to return to when an error occurred. If the error was a printer error, a special variable was referenced which was set to the name of the report menu module. If a table was being opened and if the operation was being checked, the error handler returned control to the program at the point where the error occurred. Otherwise, and for almost all other errors, the error handler attempted a return to the designated main module. If a special variable was set with the name of the main module, the program tree was checked to see if the name was present. If the name was not found, an alternate possible name, such as MainMenu was checked. If nothing was found, a RETURN TO MASTER command was given. Note that such a command will result in leaving the current program if the program was called from another program. In some cases, and for some errors, the situation was deemed sufficiently serious to directly quit FoxPro. Tables were always closed in situations where control was not returned to the area of the program where the error occurred. If the error occurred while the user was in the designated top module, the user might be returned to the place of the error. If the error occurred during initialization of the program, further errors might occur even (or maybe especially) if the user is returned directly to the top module. Though such situations are rare, I had the error handler place a counter in a public variable the error handler itself created, and if multiple errors of the same general type were occurring too close together, the error handler would decide that the situation couldn't be saved and simply quit FoxPro.

Almost all errors resulted in the user being given notification. Sometimes the error handler message was suppressed to allow the module where the error occurred to give a message, and sometimes custom messages where passed to the error handler. More often, in cases where a FoxPro type error occurred, the error handler presented the FoxPro error message and number.

Non-FoxPro errors and events could also occur, as the error handling portion could be bypassed and a call made directly to a section of the error handler that saved the errors. Sometimes, specific areas of programs were set to log unusual or disturbing events or activities, in which case the error would be saved as a custom error message and number (usually, but not always, zero), along with the user name, the name of the module (or a special name), and the date. These records would go into the same table as the FoxPro error records. Additionally, the error handler recorded the frequency of the error by looking backward through the file for other errors with the same message, number, user name, module name, and date, and then incrementing the error count and saving the result.

In the end, I did not record large numbers of errors, except in unusual situations.


Startup Error Handler

One type of error that disturbed me was an error that seemed unreachable. Some users loaded FoxPro from their file server and then received a file-does-not-exist error when FoxPro attempted to load the application, because the application was on a server to which they had failed to attach. This happened relatively frequently, as some users failed to provide the proper password when the attempt to attach was made. In some cases the subsequent attempt to map a drive also failed. In some cases, the user did not know the right password, because the user had changed the password on the default server and not on the other servers. This was all occurring in DOS, sometimes even on Windows computers running DOS windows (the programs were in DOS). When such an error occurred, the error handler was not activated because the application could not even be found. FoxPro presented its own error message through its native error handler. After acknowledging the message, the user was left in the command window. The user was frequently trapped in FoxPro, not knowing how to exit.

Eventually, I decided to do something about it. FoxPro had a startup program that installed the Run menu. I didn't use the Run menu. I substituted my own program for the startup menu. The new program ran a version of my error handler in a subdirectory I created off the FoxPro directory, and specified a table in that subdirectory when errors were logged. I gave users Novell write rights to that directory, to allow them to write to the table. The new system worked very well, enabling me to identify users with password problems and inform the LAN Administrator, frequently before the users themselves did (when the users did complain, they frequently blamed the program or some unknown problem, rather than the password).


Error Handler for Visual FoxPro

In converting the error handler to Visual FoxPro, I made two versions: one as a program and one as a class. Although a class was needed to fully handle errors occurring in forms and classes, a separate error handler was also needed for those cases where the class error handler was not available. The updates from the earlier error handler involved mainly adding error checks for new error types, saving class information in the tree of procedure names leading to the module in which the error occurred, modifying the file structure of the error log table, and using the Windows msgbox instead of coding message windows.

Note that error handling within classes is more complicated than simply installing a global error handler, as ideally the class should have some native error/exception handling mechanisms built-in, with the error passed to the global error handler only if it falls outside of what the class can handle. Since I wanted errors recorded, I made the error log portion available separately from the error handler, so the class error handler could log the errors without calling the global error handler.


My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
Program List
Utility Programs, Part I - Printers
Utility Programs, Part II - Error handlers
Programs, Part I
Programs, Part II
Programs, Part III
Programs, Part IV

Programs, Part I

Stephen Morgan's FoxPro Projects - Details

Introduction

This provides a brief description of some of my past FoxPro projects, with extra information given when unusual or special features are present. Unless noted, all these programs were written in FoxPro 2.0, for DOS. Some early programs started out in dBASE III PLUS or FoxBase, but all were converted to FoxPro at some point.


Status Monitor

This project was a very large one, and was also one of the early ones. Initial programming was in dBASE III, but was soon moved to FoxBase. Movement to FoxPro (v1) took place either before initial use of the program or soon after. An oddity which required some reprogramming was that FoxPro did not normally have a space before and after the popup menu options, while FoxBase did. Since the program displays were written to incorporate the extra spaces, the code had to be modified.

Although this was a small thing, it was disturbing to see incompatibilities displayed so quickly, and it made me wonder about what else was ahead, and whether future versions might have more of this. Also, although FoxPro had added new popup and the menu commands, I decided to stay with FoxBase versions for now, as I did not see a great need for the new ones. The action of the new menu bar seemed counterintuitive, because users were used to seeing menus constantly displayed, instead of the menu disappearing into the menu bar. (I had trouble with users who did not understand menu bars, even when the popups were always displayed. They did not understand how to use the arrow keys to get from one popup to another.)

Other than this, there turned out not to be much trouble in the language changeover. I eventually found a FoxPro bug in the array-based popups I was using, where the chosen bar decreased by one each time the user selected an option. That is, the highlighted bar when the menu was reactivated was the bar above the previous selection, as long as a previous selection was available. I felt this was confusing, so I wrote code to correct it. I also later found that some keys acted differently. For instance, the End key moved the selection to the last bar for DEFINE POPUP structures, but (I believe) closed the menu and activated the current selection for array-based popups. These were good reasons to change over to the new POPUP command. I was concerned about memory usage, as the new commands created structures that remained in memory unless specifically removed, and lack of memory was a problem with some computers. I did eventually change most programs to the new commands, taking care to remove menus from memory when no longer needed, but some array-based menus remained in places.

The Status Monitor program showed Equipment status in hierarchical color-coded lists which could be set to continually scroll or manually paged up and down. The equipment lists had two major divisions based on both location and official equipment groupings. Separate or combined viewing of lists of equipment from these two main locations was possible.

Two different passwords existed, one for users who might have to acknowledge viewing the status changes or who might edit the status (acknowledgements and all edits were recorded) and one for users who might edit the equipment itself and other users. Users were not required to know a password, but such users were limited to viewing or printing. Additionally, all users were entered in a table, along with their rights. The rights usually limited them to viewing, but some users had lists of equipment for status editing, and other users had broader equipment status groups for status editing.

Since the LAN link between the two main locations was subject to frequent outages at the time the program was conceived, the program was written so that copies of the data were kept at both locations. Under normal conditions, both locations were updated with each edit, but if a server was unavailable, the programs could run independently and update only the data at the programs' physical location. The data was synchronized after the link was up by either reediting the record in question or by choosing a menu option to copy one file over another.


ECP Summary

ECP's are Engineering Change Proposals. This program tracked ECP Summaries, and was one the extremely early programs. A separate 'ECP History' list was also kept by this program. The History was a brief collection of information from the summary, and included a shortened title, to allow easier printing and displaying.

Within the program, the ECP to be edited could be chosen by either entering the number directly or by viewing the History list and then entering the number.

Normally, an ECP Summary was just printed once, so the program tracked that, but still left an override available so that the Summary could be reprinted if necessary.

This, and almost all the Engineering programs, had a rights system that allowed, as a minimum, the ability to set a user to either have editing rights or display-only rights. Initially, this was accomplished by maintaining a separate display-only program, with users separated by Novell menus taking them to their respective programs, but I later combined the versions and used a simple user rights setup within the programs themselves.


ECP Pages

The ECP Pages program was a long time getting finished, because of the extreme complexity involved and because the government kept updating the pages. The initial plans for the program were extremely difficult to accomplish in dBASE III, and contained such things as help for each field. The help would be displayed if the user wanted help when editing that field.

This is relatively easy in FoxPro, but could only be accomplished in dBASE III if each field had its own READ command. In order to present a normal display, the screen had to first be painted, including all the GETs. As the user traveled through the GETs, each one was READ and then the method of exit was checked to see what the user wanted. If the user wanted help, the help was displayed and the user was then returned to the screen. (Remember, no separate windows were available, so the screen had to be repainted each time.) If the user did not want help, and if the user was not trying to exit the screen, the direction of exit from the field was checked, to determine what field the user should be placed on next.

In practice, in order to keep the code to a manageable size, this resulted in assigning the fields to pseudo array variables (dBASE did not have arrays), with names such as varname11, varname12, etc., and lots of macro expansion. Before the program was completed, though, we moved to FoxBase and then FoxPro. This made programming a lot easier, but it required that everything be rewritten. By that time, the code was so dense that I had to proceed carefully, as it was no longer clear in many cases exactly what the code was doing, even though I had written it and knew the general outline of what was happening. In the end, though, I fully converted it all.

The ECP pages were numbers 1 through 6, SCN's, MCN's (actually modified SCN's, and thus not really a separate page, but they were used as such), and attachments. In practice, word processor documents and CAD drawings and such were usually used instead of the program attachment section, but it was included for completeness.

The pages were based on pre-existing government forms. For example, page 1 was DD Form 1692 and page 2 was DD Form 1692-1.

Some of the pages were extremely lengthy, sometimes over 100 fields, and sometimes required special handling, such as spreadsheet-style calculations and editing on one page causing updates of other pages.

A page 7 was later added by the government. Page 7 was similar to page 6, and both required landscape print settings.

The ECP Pages program was the first of the programs to offer the choice of printing high quality forms if an HP LaserJet printer was chosen from the Printer menu. The forms were hand-coded and the graphics and test were micro-positioned. A great deal of trial and error was involved, but the process became faster as time went on.


My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
Program List
Utility Programs, Part I - Printers
Utility Programs, Part II - Error handlers
Programs, Part I
Programs, Part II
Programs, Part III
Programs, Part IV

Programs, Part II

Configuration Status Accounting Report

The Configuration Status Accounting Report program, another early program, was based on a report that had been generated in a word processor. The report actually consisted of two reports, one following directly after the other. That is, the second one began on the same page where the first one ended. The length of the reports varied, depending on the number of items in the reports, so the second report did not start on a fixed position, but needed enough room on the page for at least the header and a reasonable amount of data. The report was in a table format and every item, including the titles and each individual field, was enclosed by lines, forming a grid. The report was hand-coded.

The only printer code related oddity was the expansion of the title into double-wide, bold, separated letters, to match the word processor report. While it was possible to send the printer such codes, and I did set the report up to do it, it was difficult to make such a thing truly portable without being able to test the action of other printers. I did later put in a variation for HP LaserJets, though.


DCN

The Document Completion Notification program was an Engineering program, similar to some of the others, but using its own form. It was one of the later ones, and I think also set up to print high quality HP LaserJet reports, something that required a lot of testing, since I had to hand code all of it. And, like the other programs, it could also use a dot matrix printer.

This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.


ICN

The Installation Completion Notification program was an Engineering program, similar to the Document Completion Notification program if I remember correctly, but using its own form. It was one of the later ones, and I think also set up to print high quality HP LaserJet reports, something that required a lot of testing, since I had to hand code all of it. And, like the other programs, it could also use a dot matrix printer.

This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.


TEC

The Temporary Equipment Change program was based on a pre-existing paper form. The form was simple enough that a separate HP LaserJet version was not needed, but the hand-coded report still contained some specific areas where the printout was altered if an HP LaserJet was used.

Early versions of the program printed a Ford logo on the report, as I worked for Ford Aerospace at the time. I wrote the logo in Turbo C, because dBASE III, used at the time, did not permit direct input of the necessary printer codes. The codes were for a dot-matrix printer that the Engineering department used back then.

The form featured a large central area, where the temporary equipment changes were listed and described. In order to allow easy entry on the screen, with a format approaching that of the printed form, the area was divided into four parts: upper left, upper right, lower left, and lower right. The fields were laid out in a table format, and validation clauses determined the next field to access, based on the keys that were used to exit the current field. If the edge of the display was reached, the screen automatically changed to display the particular section that the user was heading for, with some overlap of the displayed data, so that the user could see a fragment of the other screen for reference.

A complication of the display was that some fields were split. In such cases, an area of the field from the next or previous screen was displayed, but was not available for data entry on the current screen, because the user needed to see part of what was in the section of the field on the other screen, and because if the area was currently available for editing the cursor would be placed on it and not where the user had been typing. Choosing a specific field to be activated when the READ began was not enough, because the field was only partially shown, even with the read-only part included. If the user had the entire displayed area for editing, the hidden part on the other screen would not be part of the edit and the user might overlook it or not realize that some other data existed there, particularly if the hidden section was on the right. The field was split only at the display, where it was divided into separate variables, and not in the actual field in the DBF table.


Engineering Taskings

The Engineering Taskings program began as a way to organize Taskings written in FormTool. The FormTool Taskings were based on a pre-existing paper form. The Taskings program imported the ASCII file portion of the FormTool record, which FormTool saved as an individual file (the other portion, saved separately by FormTool in a file with data from other forms, consisted of such things as underlining and other formatting). The file was placed in a long DBF field in a series of records. Each record had another field recording the Tasking number, which was extracted from the file name. The list of Taskings could now be easily displayed, and the tasking itself could also be viewed and printed from within the program. because of the large size of the form, the viewing was divided into several different screens, which could be reached with the arrow keys.

A different program was written by someone else, where the Tasking could be created and edited within the program. Unlike the previous program, where the report was hand-coded, the form was printed from a FoxPro report form. Since FormTool was no longer used to make the report, this meant that the large underlined section at the bottom, for hand-written notes, became instead a large blank area, but the Engineering department accepted this. The Engineering department had various complaints about the new program, and although I intermediated with the programmer, he was unwilling to make any more changes. The program was eventually given to me, and I rewrote it. (Still no underlines in the printouts, though. If they accepted the printouts without the underlines, why bother implementing them now.)

The old Taskings-converted-from-FormTool program remained in use, because it held the older Taskings that had not yet been entered into the new Taskings program.


Engineering Drawings

The Engineering Drawings program was a very early program, initially written in dBASE III, and later rewritten for FoxPro. It recorded Engineering department drawings. It basically recorded the drawing number and title, and various other useful related data.


Engineering Release Record Program

The Engineering Release Record (ERR) program was a relatively late edition to the Engineering programs. It featured highly detailed printouts for HP LaserJet printers, and less detailed printouts for other printers. The ERR form was not nearly as complex as the ECP forms, but a continuation form had to be written also, with the program set to automatically print the continuation form when the number of line items becomes too great for the main form. The page count also had to be tracked, as in 'Page (Number) of (PageCount).' Like all such Engineering forms, the printouts were hand-coded.


My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
Program List
Utility Programs, Part I - Printers
Utility Programs, Part II - Error handlers
Programs, Part I
Programs, Part II
Programs, Part III
Programs, Part IV

Programs, Part III

Technical Library

The purpose of the Technical Library program was to track the items in the library, including the items at the sites, and to print periodic reports.

Parts of the Technical Library program were originally written by several different people. After I was given the program, I quickly rewrote it. The original code usually lacked proper structure. Also, an enormous problem existed with indexes not being properly updated, to the point where options to reindex were present on report menus, and some report menus automatically reindexed before printing a report. At that time, reindexing could take up to fifteen minutes. I solved the problem by making sure that all the indexes were always open whenever the tables were open. I placed the table and index names in public variables in the form

tablename INDEX index1, index2, index3

which the program referenced whenever the tables were opened (except when the indexes were recreated). Thus, changes to indexes were easily carried throughout the program.

Another problem was the radical differences in field names and field purposes in different tables used by the program. This was to the point that fields with similar names had totally different purposes and fields with the same purposes had totally different names. This caused some difficulty in maintaining the program, since I had to refer to a translation list I created in order to understand what I was seeing. I eventually renamed the fields to commonly held and more understandable names.

An oddity of this program was the use of colored menu 'bars' in the initial menus. Some 'bars' were even blinking. This was in dBASE III PLUS, so the colors were simply painted on the screen. The screen background was usually black, but the menu options could have any color. Deeper menus were usually simply green on black, because that was the color setting at the time of the user selection of the previous menu option, and the setting was not overridden by the new menu. Part of what I did was to explicitly code all this, so that the menus were not accidentally green on black, but purposely so. This menu system was carried through to FoxPro, because I did not want to remove the special menu displays. Eventually, FoxPro added the ability to create separately colored menu bars, and I converted the menus to popups with colored bars (even blinking bars), and also retained the green on black colors of the deeper menus.

One of the first versions of the printer menu program was as a short list of available printers for this program. The list included a high speed LAN printer. At that time, the Novell CAPTURE command was used to access the printer, but this caused memory problems if the command was used more than once or twice in a program session. Eventually, FoxPro added a command to access printers on a Novell network, and that command was substituted.


Barcode Trakker-Inventory

This was in two parts, a program in the 9440 Barcode Trakker written in Intermec and a program in dBASE III PLUS to receive and process the data. This was actually part of the Supply program, used by the Supply warehouse.

I did not write the Trakker program, although I helped the programmer out from time to time.

The dBASE III PLUS program I wrote from scratch, in 1988. The program was later written in FoxBase and then FoxPro. Much of the later editing was done by another programmer, although I was given it back years later when the Supply program was made my responsibility.

This was the program I was originally hired to write.


Barcode Trakker-Technical Library

This was in two parts, a program in the 9440 Barcode Trakker written in Intermec and a program in dBASE III PLUS to receive and process the data. This was actually part of the Technical Library program, used by the Librarian to track inventory.

I did not originally write either program, but I was given both programs within a year or two, and quickly upgraded both by a substantial amount.


Training Program

The Training Program was originally an extremely simple one, just two or three pages of code, written by one or more people at another location, who evidently weren't really programmers. I used it as a guide to what was wanted, or at least what I had to include in it. I also discussed it with the training person at the location where I was, to find out what I needed to put in it and what he would like it to look like.

The result was an enormously complex program. It used various validation checks in a series of fields set up on the screen in a table, or grid, format, so that updating a date in one would cause another field to be updated with another date, probably with the next due date, if the training was periodical, and also allow the user to move through the fields with the cursor keys in any direction, even though they were actually all GET's and would normally be traversed only in the order that they were written. It had two sets of these artificial grids, a broad one in the middle and a tall narrow one to the right.

The tall narrow one showed two columns of recurring training types, plus probably just one date for each one, making a total of four columns. The names for the training here were just simple identifier code names, probably usually in the area of four to six characters long, if I remember correctly. The length of the narrow grid varied, though, depending on how many recurring training items that location had, up to what the screen would allow within the display. The area available for it didn't go all the way to the top or bottom, though, and the maximum number that could be displayed was probably in the 12 to 14 area.

The broad one in the middle had a lot more complexity, at least in terms of data validation, though it was fixed in the amount it could hold and was always the same size. It was filled in as necessary for the employee that the data was for, and allowed all sorts of things to be entered, including classes taken somewhere. The fields included one for the name of the training, plus I think two dates for it, maybe three (possibly the due date, the date completed, and the next due date, but I'm not sure now) and the program would automatically move the cursor to the next needed field when updates were made, and give error messages when data was not entered properly. Although the amount of space allocated to this kind of training didn't allow a large number of them to be entered (perhaps six or eight), it was not thought to be a problem at the time as the older training was thought to be less important and a lot of the training listed there was apparently thought to be less critical, as it also included or could include a lot of training that wasn't necessarily job related, or related in a minor way, and the older training could be overwritten if more space was needed. However, it did become a problem eventually, and the training people were wishing that they could enter more. It was never updated to do so, though. Space on the screen was limited, as there were fields above it to record other data about the employee, and two long fields for comments under it.

The program also allowed different different types of training and identifiers and the length between trainings to be placed in a DBF table (manually, outside the program), with a field also recording which of the trainings were used by that location. The program would automatically pick it all up then and display the proper ones on the screen and in reports, allowing editing for those people with editing rights and just a display and printing for others. The program was able to allow varying numbers and types of recurring training by gathering what had been placed into an array of the proper length, and then displaying the short title identifiers and the dates in the artificial grid, with the dates being in the form of GET's. For the reports, a function gathered the information into an array and then into a long variable that displayed in a series of short columns due to automatic word wrap in the report form.

This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.


Shipping Documents

The Shipping Document program printed shipping documents based on a pre-existing paper shipping form, DD Form 1149. The documents were printed in landscape mode on HP LaserJet printers. The printed form was hand-coded, and looked similar to the original. Two versions of the form were available in the program, because the originally requested version of the form for the program was in fact outdated, so a printout of the new version of the form was written.

The program allowed the saving of addresses for selection within the program, and also allowed information from a previous form to be copied to a new one. In addition, a floating section in the form printout allowed the filling-in of receive information, such as parcel acceptance data. The program also automatically added the line items. A security system was also used, to prevent a user from changing the data in another users form, unless the form was assigned to a common department or unless the user had supervisor rights. All entered data and shipping forms could be viewed, however, by anyone accessing the program.

Some government personnel liked the program so much that they installed it in their own area.


GFE Inventory

The GFE Inventory program tracked items such as desks, chairs, tables, computers, printers, vehicles, and other non-consumable items. Each item was given a number, and sites or departments were periodically required check their assigned items against a list.

The sites were given read-only access to the program, with certain personnel within the Supply department given editing rights. When I received the program, the user names were hard-coded, but I rewrote it to use a generalized security system with user names and rights stored in a table. Eventually, a much more elaborate system of rights was developed, allowing the sites to transfer items in their possession within newly and strictly defined location trees. Some users were given multiple sites, sometimes with different rights from site-to site. Several fields were added to aid in tracking items, and reports were greatly expanded.

A complication in this program, and thus in the reports, was the different categories the items could fall into. An item could be owned by the government or by the corporation working as a government contractor, and the item could be added or deleted, and could be a test equipment item or not. Depending on the report, different types of items and groupings were needed.

In order to keep track of where items were going, and to keep the books straight, movement between the major categories resulted in transaction records with a deletion in the old category and an addition in the new one. Location changes and price changes had their own transaction records.

A problem existed in that quarterly reports were required, and in order to make accurate reports the reports had to be generated immediately after the new quarter began, before any transactions occurred. Frequently, transactions did occur first, and sometimes the report generation was forgotten for days or even weeks, resulting in considerable time spent in manually going through the reports and trying to figure out what belonged and what didn't, and eventually arriving at true figures for the quarter. I added a feature to the program that automatically generated a summary for all the various categories, which was then saved to a table. The first user with major editing rights that opened the program after the new quarter began generated the summary. The related Test Equipment program could also generate the summary if a user with major editing rights opened that program first.

The summary was a great aid in determining what the true figures for the quarter should be, although the major report was still required and the differences had to still be tracked down and explained. This was made more difficult on occasion because the person printing the report sometimes did not get the correct categories selected, and people did not initially realize the error and spent a long time wondering why they could not get the figures to match, and I was still frequently called in to help.


Test Equipment

Test Equipment was a subset of the GFE inventory, and thus this program was related to the GFE program. However, because of the separate needs of the Test Equipment department, the Test Equipment program had its own data entry screens and reports, as well as separate user security. Both programs shared the same directory and the same main tables, and in both programs the major users could activate the automatic quarterly summary generation, depending on who opened their program first after the new quarter began. See the GFE Inventory program, above for more information.


Key Control

The Key Control program tracked the keys that were available and that were checked out by employees. I did not create the program, but at some point it was given to me. I rewrote the program to improve the structure and action, as I did with the other programs, and as with the other programs, I tried to retain the general look and feel of the program.


Job Control-Equipment Status

The Job Control-Equipment Status program was similar to some parts of MANDATE, and I think that part of the MANDATE code was originally derived from this or the similar Range Manager-Equipment Status program. Both programs were, I believe, originally written by a different person than the person who handled MANDATE before I took it over. MANDATE apparently started out as a collection of various range programs, which were substantially upgraded and given additional features by the person who originally handled MANDATE, who also had a hand in writing some of the collected programs.

When I was given the task of upgrading the Job Control-Equipment Status program, it was a relatively simple program, which, if I recall correctly, required changes to the code each time any of the equipment was changed, and I placed the equipment names in a table, so that changes could be made a lot easier. I also did a general major upgrade of everything, while trying to retain a lot of the previous feel of it, with the interface changes that were sharply different being similar to things on other programs that I wrote.

This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.


Range Manager-Equipment Status

The Range Manager-Equipment Status program was similar to some parts of MANDATE, and I think that part of the MANDATE code was originally derived from this or the similar Job Control-Equipment Status program. Both programs were, I believe, originally written by a different person than the person who handled MANDATE before I took it over. MANDATE apparently started out as a collection of various range programs, which were substantially upgraded and given additional features by the person who originally handled MANDATE, who also had a hand in writing some of the collected programs.

When I was given the task of upgrading the Range Manager-Equipment Status program, it was a relatively simple program, which, if I recall correctly, required changes to the code each time any of the equipment was changed, and I placed the equipment names in a table, so that changes could be made a lot easier. I also did a general major upgrade of everything, while trying to retain a lot of the previous feel of it, with the interface changes that were sharply different being similar to things on other programs that I wrote.

This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.


Smoky Sams Usage

The Smoky Sams Usage program tracked usage of the Smoky Sams, as the program name suggests. It was one of the fairly early programs I wrote, but after it was written it was unused for years, apparently forgotten by the people it was written for, though I think personnel changes probably had a lot to do with it. Eventually, after bringing up the subject a few times over the years, it started being used and then I substantially upgraded it, going from probably dBASE III to FoxPro. It was one of the programs where the printed report required that the table be shown with cross hatched lines, so it took a lot of fiddling to get it all worked out for the dot matrix printers, and I think I also did a version of the form for HP LaserJets.

After being used for a while, it again fell into a long period of disuse, again apparently because of personnel changes. After mentioning its existence to a QA person, it was investigated and then written procedures were drawn up for it by them.

This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.


QA PDR Forms

The QA PDR Forms was used by Quality Assurance to keep track of the various sites' needs and requirements in that area, though I don't remember now what that was. It may have even been a list of faults found, if any, that they had to fix, that were discovered as part of the equipment/site checks, and it may also have been used to keep track that such checks were made. I'm not sure now.

Originally, it was a very simple FoxPro program that was written by the person that did many of the minor Supply-related programs, such as the GFE Inventory program. I upgraded it enormously, while retaining much of its general look. Part of the upgrade was putting in detailed user security checks, doing such things as restricting most users to only modifying limited fields relating to their site or equipment, probably just enough to allow them to update it showing what they had done to comply with the requirements, and maybe to print out their own site's or equipment's forms.

It was one of the programs I had to set up to use HP LaserJet printers, as well as regular ones. As with the others, the LaserJet forms portion would have been hand-written by me, and would have involved a lot of testing. Regular table-format reports probably used a FoxPro report form. Also, as with the other programs that used the LaserJets, I had to eventually put timers in the reports, even embedding them in the report forms (as functions that called the PDR program) that printed nothing but just waited a small amount of time. This was necessary because some reports were lengthy, and the printer would just ask for it happily and then abruptly stop asking while it printed what it had, taking so long that a time out error was generated. The slowing down prevented the error in all but the lengthiest of reports. (Some reports were enormously long, and it was better anyway to send those to the LAN printer, which had no problem with them, since the reports just became files waiting to be printed. However, the pauses were still in them while the program was generating them, so the program took a long time to get them out, and I had to make changes so that it recognized when a LAN printer was used (by a field in my printer program) and not provide the pauses.)

This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.


UPS Alerts

The UPS Monitor program was for monitoring the status of a UPS on a mountain. If a power failure occurred, the program was to transmit the status to people not on the mountain, in the hope that the power could be restored before the UPS batteries failed. The batteries could maintain power for approximatedly four hours. The program took a few minutes to complete the check, and then waited for user input for a few minutes nfore beginning the check again (the wait was later shortened to increase the polling speed). The program was placed on a dedicated computer, and ran continuously.

Using Turbo C, I created a program for polling the UPS through a modem by utilizing PC interrupts, for the purpose of obtaining, one by one, status, three input voltage screens, three output voltage screens, and other data. The screens were up to four lines long. The C program wrote text files containing the UPS data, which were then read by the FoxPro program. The status was determined by checking for the existence (or non-existence) of key words in certain locations. If the power to the UPS went down, the FoxPro program notified users over the network by use of the Novell SEND command.

The program was also available to certain users over the LAN. The users did not run the section of the program that polled the UPS, but instead viewed the results of the checks, which could also be printed out. The last several hours of checks were saved (more in later editions), and all power failure data was saved permanently. The version of the program actually polling the UPS could also be accessed remotely by an extremely limited number of users.

The program sent messages to members of specific Novell groups. Some people received notification of all status errors and some people were notified only if the power failed. The program periodically resent the message during the time the status remained abnormal. Power failure error notifications were sent every five to ten minutes, while other error notifications were resent every hour. An additional notification was sent upon return to normal status. Because of high winds, momentary power failures and glitches frequently occurred (wires slapped), and the program had to filter this out by waiting to see if the error was still present in the next poll.

When a power failure occurred, the program also displayed a clock counting down from four hours to zero, so people could instantly see how much time was left.

The UPS Monitor program was originally only for the UPS on the mountain, but was later expanded to include the servers in the LAN room. At first, the original program was simply copied to another directory and renamed, with the code also changed as necessary to reflect the changed UPS. Later, the programs were combined and run from the same computer, alternating checks of the UPS's through the two serial ports.


My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
Program List
Utility Programs, Part I - Printers
Utility Programs, Part II - Error handlers
Programs, Part I
Programs, Part II
Programs, Part III
Programs, Part IV

Programs, Part IV

MANDATE

MANDATE, usually written as Mandate, stood for Maintenance Data System. A separate version was used in a different state and called MANDATES (note the ending S), but I did not maintain it, or even have much interaction with the programmer who did.

Mandate consisted mostly of sections for viewing color-coded range and equipment status, for opening jobs on the equipment and ordering parts, for automatically updating the equipment status by the status of the jobs open on the equipment or on components of the equipment, a special section for TACTS equipment jobs, and sections for non-jobs parts ordering, for scheduling preventive maintenance, and for various related and non-related reports.

The version of Mandate I worked on started out in a branch of the company in Florida, as series of programs written by various users at that location. These programs came to be gathered under the control of one the programmers there. This programmer came out to Nevada, where I was located, and worked with the programmer of the Supply program, both in upgrading (actually creating) Mandate and in integrating Mandate and Supply. The integration, for the most part, consisted of creating a requisition form, based in part on an existing paper requisition, which would be used by both programs. A user could order parts in Mandate, either for a Job (generally an equipment repair of some type), or as office or other supplies. After approval by a supervisor, the requisition was then available to the Supply program for action. Within the Supply program, Supply personnel could then research the order and assign PR and PO numbers. When the part was received, non-job requisitions were deleted, but job ones were retained. When the job was archived, a slightly abbreviated version of the requisition followed it.

The Mandate programmer moved to Nevada and worked for the company there. He made various improvements and added many features. Due to the speed at which this was occurring, many errors and anomalies crept into the code, and not all implementations of features were done in the manner the users would have wished. Near the end of his time there, I was given the task of researching his code and documenting what the code was doing. Day after day I kept bringing lists of things I found wrong or that were odd in some way, and he finally told me that unless it was something major, to just fix it and not bother him with it.

One time, he was trying to correct a problem with a user's computer locking up when a job with a large number of requisitions was being archived. If the user reset the computer, sometimes more than once, and restarted the archive process, the job archive would eventually be completed. The programmer could not find the problem, and finally had me look at it. After carefully examining the code, I finally determined that the problem was occurring because the records were blanked as they were being archived, and the controlling index was moving the record to the top of the file. Since the file was being sequentially scanned (it was a FOR scan of the file, instead of using WHILE), the scan was starting over with each archived requisition. This took a long time if over a thousand requisitions were involved, especially on computers in use at the time. The computer had only seemed to lock up because the long time involved (over an hour), and the lack of feedback during the process. After being told what was wrong, the programmer corrected the problem and also added a count of requisitions being archived, to let the user know that something was happening.

The Mandate programmer moved to California in the summer of 1991, and I was given the program to work on. After I made some improvements, the Supply programmer and I went to Florida to install the new versions there. The printer selection in the Mandate program was done in an odd manner, with a printer-1 and printer-2 setup. One printer was assumed to be the major LAN printer and be capable of using wide paper. The major LAN printer was not sent any printer codes. The other printer was assumed to be more under the users' control, and was sometimes sent codes. The codes were initially for an HP LaserJet, but each user had the capability of substituting the codes of another printer as part of the user's personal setup. Oddly, this feature was almost completely hidden within the program, and users generally had to be individually told about it.

I discovered the reasons for the printer-1, printer-2 setup in Florida. It seems that the original setup was at that location, and the programmer had made an effort to generalize it after he moved to Nevada. I got some complaints about the printers no longer automatically selecting themselves and printing at the same time when a certain report was chosen, but of course activity that location specific was changed before I was given the program. The bigger problem, by far, was getting the printing section to work right at all. Neither the Supply programmer nor I could figure out what was wrong. It seems that the LAN-Local printer section did not want to work at all, and only the local printer was available. (At the time of writing this (2000), almost nine years have passed since then and some details are hazy. The LAN printer may have been the one available, but the local one seems more logical, especially considering the trouble in getting reports to print.) Since most computers did not have a local printer, this severely restricted the ability to print reports. We finally discovered that the secret was commands placed in the Novell menu option for the program. The commands assigned printers to LPT1 and LPT2, and the program switched between the printers by switching between LPT1 and LPT2. Evidently, that particular system was devised in Nevada, and some other method had been used in Florida. I do not have program code recording what it was, though I do have some isolated 'range programs' that the programmer left from those days. I eventually got rid of that printer system and substituted my own, but that was years later.

Mandate grew over the years as I added features and documentation. Eventually, the code grew to more than four megabytes. Normally, new versions were initially used in Nevada at the location where I worked, and then released to other locations nationally, even locations no longer run by the company, since the program was for the government. At the time of the final version, I also had the Supply program, as well as nearly all other database-style programs worked on or used by the company at that location.

The final version appeared only in Nevada, and occurred less than a year before Mandate and Supply began to be phased out in favor of the Datastream MP2 application, a decision made by the Navy. Years before, a team of Navy people had been assembled, including one or more people from my location, to study what the next version of Mandate-Supply should be. In the meantime, development work and new versions continued coming. In early 1997, the Navy made its decision. The decision, though, was not how the Mandate-Supply system should be upgraded, but simply for two finalists for its replacement. After some discussion, including viewing of both contenders by a large group of people, including people from various Mandate locations, and including me, the Navy decided on MP2.

I attended the MP2 training and asked more questions than anyone, sometimes stumping the teacher. MP2 evidently has a fine reputation, but it seemed to me that it was not quite suited for what we were doing. At the vary least, a major change in operations and expectations was required, and the program itself required a lot of fiddling to fit what we were doing. The fiddling included a lot of retitling of fields, a process written into the program, but we used it to such an extent that whole sections changed purpose. Additionally, the different locations in the different states were having trouble agreeing on a common standard, and each was, at least initially, using some of the fields for different purposes. This had to be worked out eventually, as the government wanted a common standard. This was still ongoing, a year later, when I left the company.

I had been wanting to leave for a long time. Although I enjoyed programming, and I still had things to do if I remained, the frequent travel, by car, between Arizona and Nevada was extremely tiring, and had grown old long ago. This was in fact a period a relative stability in the programs, though some were still updated from time to time, (sometimes every few weeks). The two really large programs that had been undergoing large, frequent updates, Mandate and Supply, were now passing (slowly) into history. Though I had been doing some work in Visual FoxPro, I could see that the time involved to convert the remaining programs, and possibly have to go to a large number of users' computers and fiddle with the installation personally as well, was going to take too long, even if it could all be done by one person. I could also see that if I completed the work, even for one program, the result would be incomprehensible to the people I left behind. Because of the level at which I programmed, they had great difficulty in understanding the programs in FoxPro 2.0, for DOS, even though I wrote a lot of notes and explanations in the programs and sometimes explained things personally. Better to leave in this period of relative stability, and while they still had a chance of doing maintenance themselves. I feel the likelihood of such maintenance is limited, and many or most of the programs will end up being replaced with something else entirely, or simply discarded. Such is the case with programs, though, as they are replaced by evolution, revolution, or simply fade away.


Supply

The Supply program was used by the Supply department to order items, to assign PR's and PO's, to research vendors, to manage inventory, to print various reports, and all such related activities. The Supply program grew out of an early set of programs for that purpose. The system of programs was reworked and rewritten by a highly skilled field engineer, who then became the Supply programmer. Initially, the program was in dBASE, but was moved to FoxBase and then FoxPro. At that time, the interaction with Mandate was established, including the electronic requisition developed by the Mandate programmer. The requisition was called the electronic 1250, after the name of the paper form the electronic version was loosely based on.

After the linking of Mandate and Supply, relatively few changes occurred within the Supply program. The program code remained mostly at the FoxBase level. Some FoxPro features, such as windows, were implemented, as well as changes necessary for compatibility with Mandate. The Supply programmer had increasing demands on his time, as he was also the CIS Manager now, even though he apparently remained classified as a field engineer. He was responsible for maintaining and upgrading the LAN, and for maintaining and upgrading the users' computers. The number of users with computers had risen drastically.

Eventually, another programmer was brought in. This new programmer was hired from a different location, and did not have FoxPro experience, and evidently none in any related language either, but was well thought of in the language he normally used. It took a while to gain experience, of course, and I helped him out from time to time. I think he may have been hampered by the fact that the Supply program was mostly FoxBase level code, and by his apparent reliance on using the FoxPro menu system in his work and thus not studying the commands deeply enough.

Still, he seemed to be working out. He wrote the Supply-Purchasing Interface. The Purchasing program was a separate corporate program meant to replace the purchasing section of the Supply program, as well as any such purchasing programs or other ways of handling purchasing activities by other corporate locations. He also wrote the Supply-Servmart interface and an initial version of the Security Log program. However, the government at his new location (at the Supply program) decided that they needed him as a programmer of his previous language, and so they hired him away.

I was then given the Supply program. I had already been given the Mandate program years before. I spent a lot of time upgrading and improving the Supply program, but this version was fated to be the last, and unlike the previous versions, was released only at the company location where I worked.


Supply-Purchasing Interface

The Supply-Purchasing Interface program was initially written by another person, to interface the traditional Supply program with the new corporate Purchasing program. The Purchasing program was written in FoxPro 2.5 for DOS by a different programmer hired on the east side of the country by the corporation, and the program was supplied to the various corporate locations as an EXE file.

Initially, of course, many awkward areas existed in the program, though efforts were made to reduce these as time went by. Since the Supply program was still used, with its own and incompatible PR and PO system, in order to prevent the constant double entry of items in both programs an interface between them was developed. The Purchasing program was not itself aware of the Interface, though the programmer made available some fields in the program for use in the Interface.

The Interface had to send the Supply program requisition records to the Purchasing program, and then monitor the Purchasing program for updates, such as assigning PR and PO numbers, vendors, and prices, and checking for receives and partial receives. The checks and updates occurred when the Supply program was opened, and at such times as the user chose to execute a menu option for that purpose. The Purchasing program was itself updated from files downloaded from a central corporate location, and it similarly updated the corporate location with a file transfer of its own. It was all quite complicated, particularly since the files returned from the central location frequently had multiple copies of the same requisition record, in different stages of update. This meant that the Interface to the Supply program not only had to check for updates, but to repeatedly check the same requisition for updates in a particular order, in order that the transaction records be generated in the proper sequence. Even more complicating the action was that the actual Supply requisition record was really in a MANDATE table, but the PO, PR, and transaction records were in Supply tables.

When I was given the Interface program to work on, I quickly substantially speeded it up and then spent a lot of time tracking down the various anomalies and improving the interface. I also added many features to allow the Supply department to better manually track and update items within the Interface. Eventually, the company was acquired by another one, and the new company had its own purchasing system, which was on a distantly located mainframe, and so the Interface could no longer be used. Thus, the Supply department was forced, after all, to use double entry with the Supply program and its later replacement, the Datastream MP2 application.


Supply-Servmart Interface

Servmart was a Navy store, and an Interface was developed by another programmer to allow direct selection from the Servmart tables to the MANDATE requisition table, with a corresponding update of a Supply PR table. Initially, this was solely done by the Supply department, but was later expanded to include the normal range of sites and departments used by MANDATE.

At some point I was given the program. I had earlier given the programmer various help and hints. The four column site menu was even based on the two column MANDATE main menu, which I designed, and the printer program used was the one I had written. I quickly cleaned up various anomalies in the Interface program and improved the code. Eventually, the Navy stopped using Servmart, and so the Interface program was discontinued.


My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
Program List
Utility Programs, Part I - Printers
Utility Programs, Part II - Error handlers
Programs, Part I
Programs, Part II
Programs, Part III
Programs, Part IV