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