Stephen Morgan's FoxPro Projects - Details

Introduction

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 contiually 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 conditons, 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 sychronized 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 mininum, 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 psuedo 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 everthing 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.

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

Document Completion Notification program.

ICN

Installation Completion Notification program.

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

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

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 editng 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 possesion 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 governmant 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 evntually 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

Range Manager-Equipment Status

Smoky Sams Usage

QA PDR Forms

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.

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

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. (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 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' the 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 likelyhood 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 PRs and POs, 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, venders, 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 requistion 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 substantionally 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.