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
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
posted by Stephen at 11/01/2009 01:01:00 AM
0 Comments:
Post a Comment
<< Home