Sunday, November 01, 2009

My time at GeoCities

Yahoo GeoCities closed sometime Monday, October 26, 2009, perhaps at the end of the day, as it was still available earlier in the day. I had been on it for a long time. I got a surprising amount of traffic for a while, though I got little or no traffic in the later years.

Before I joined GeoCities, I had been looking for a place where I could have my own web page. I chose GeoCities because it had just been acquired by Yahoo, and I already had a Yahoo email account.

The earliest file creation date I have on my C: drive for copies of my GeoCities files is for an old version of Index.html, the starting page for my site. The date for the file is Tuesday, July 4, 2000, 7:15:00 AM, meaning I probably joined GeoCities around that time.

I used one of their templates to create it, a pale green one. It had a place for a picture at the top left, with the part below that occupied by a short set of default links (to Yahoo locations), my name and email address, a smiley face that indicated whether I was online or not, and two links to the guestbook, to leave a message or to view the messages. I later replaced the Yahoo default links with ones of my own, and though the list remained short, it got long enough to affect the display and I had to adjust the code several times, to both place the links closer together and lengthening the lines that were used to frame the page.

On the right side of the page, room was given to write something. I devoted it initially to talking about what was on the other pages, with links to them, and also about being mentioned by a famous FoxPro book writer and programmer, in response to something I asked her about, and with links to that. I later also mentioned this blog. Originally the text the template used in this area was very small, but I eventually adjusted to display slightly larger.

The lines that framed the page were actually pictures and not connected to each other, with small square blocks at the corners that were in two sizes. The blocks weren't connected to the lines. If the page was stretched due to adding too many links or because of adding too much to the text, the vertical lines and the small blocks at the bottom corners grew too far apart.

I had been intending to redo the Index page and make the two sides two cells in a table, and get rid of the bordering picture lines and the associated code. This would make the page a lot easier to update. However, when I discovered that GeoCities was going to be discontinued, I dropped the plans. I had not actually written anything anyway, so it wasn't a big deal in that regard. I kind of wish I had done it earlier, though, and got it up, so it would be there for a while and I would have the satisfaction of having done it.

Two of the pages on my site were colored. The Index page, as mentioned already, was a light green. The color code for it was "#CCCC99". My Resume page was a kind of yellow-cream, with a code of "#FFF8CB". I found the color by looking for a web site that had a color close to what I wanted somewhere on it, then checking the source code for that page and finding the background color code for what I saw. I then did a little bit of experimentation with it on one of my web pages, perhaps the Resume page itself, to see if I could make the color a little closer to what I wanted. The rest of the pages were white.

I put site counters on all the pages, except those concerned with the guestbook. At one time the Index page counter showed over 800 visitors, but it got reset at some point, perhaps because of excessive time between visits. Some of the other pages also had high counts. All had shown very low counts for years, though, and the style of the display had changed on its own to show tall, thin, narrow letters. In researching and viewing things near the end, I noticed that it said that the settings would be dropped if there was no activity on that page for 90 days. That would explain some of it, though I'm not sure why the main page would reset. I tried to visit it more often than that, though I guess it's possible I could have been away longer than I thought a time or two. The pages had not only lost their counts, they lost the type of number display I had chosen, changing to the tall, narrow, hard to read numbers, which was frustrating. In going through it again near the end, I saw that the thin, narrow number style was the default one, so that it explains it. I changed it back for the Index page to normal looking, easy to read numbers, though it probably just had hours left to go at that point.

Besides the Index page, I had a resume and a long list of programs I had worked on, with links to descriptions of the programs. The program descriptions were in two files, one for utility programs and one for the others. I put code in to take the viewer to the specific program that was chosen. Because of the length of the two pages, I have divided them further here. The utility programs occupy two posts and the other programs occupy four posts.

There was a problem with the guestbook files, that occurred sometime along the way. While I could view the messages left (there was only one, plus a test message from me), I found near the end when I wanted to see what the display looked like for the one where a viewer enters a message, I got an error for the file not being found. The link pointed to a GeoCities file, that presumably would have pointed back to the file at my site containing the entry form. The entry form file (addbook.html) was still there that the file linked to should be looking for, and after opening it up to look at the code, I found that it seemed to reference the same address that the link had (going back and checking I found it was shown in a FORM clause). I doubt that it ever looked for addbook.html once the error started happening, though. It would have failed at the address linked to on the Index page. After a while I seemed to remember seeing this error years ago, and attributed it to a Yahoo-Geocities problem of some kind, since there wasn't any other reason for it not working. I had made no changes in it for a long time, and even then just to the text displayed with it, not to anything important.

Thinking now that they had changed in some way how guestbooks were handled, I went and set up another guestbook. I discovered that after it was done, I was just given code for the links to add a message or to view existing messages. They didn't have guestbook files on my actual site anymore (though what I had before wasn't bothered, of course; they didn't care about what was there). I tested it out and found that it now worked, but I didn't bother putting the links for the new guestbook on my Index page, as only hours were left and it was seldom visited by anyone now.

The files here have undergone some changes in appearance. Besides that already mentioned, in some cases the fonts may not aways be the same or the same size as they were. Some minor corrections have also been made, and where, in a few instances, the program descriptions were not filled in, they have now been done. Due to so many years passing, they may not be quite as detailed or certain as they might have been, but they should be sufficient. The links now also point to this blog and posts on it, of course.



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 GeoCities File Manager

Create & Update > File Manager

geocities.yahoo.com/stephen_m99: GeoCities Free View My Site

GeoCities Control Panel
Home Create & Update Manage Promote Help Index

Create & Update > File Manager


Your site: http://www.geocities.com/stephen_m99 Edit using: HTML Editor Basic HTML Editor

New Edit Copy Rename Delete checked files
Name Last Modified (GMT) Size (KB)
[] / addbook.html View August 02, 2000 Stats 2
[] / dtlpg1.html View August 03, 2000 Stats 47
[] / dtlpga.html View August 02, 2000 Stats 16
[] / geobook.html View November 11, 2000 Stats 2
[] / index.html View March 20, 2009 Stats 17
[] / projpg1.html View August 03, 2000 Stats 6
[] / resume.html View October 30, 2001 Stats 6
Check All - Clear All = Subdirectory = PageBuilder = PageWizard
New Edit Copy Rename Delete checked files

Subdirectories
New (Create Subdirectories to organize your files)

Disk Space Usage
Used:
0.1 MB
Available:
14.9 MB
Total Allocated:
15.0 MB

.


Notes from the final two days

[ Written initially around 3:26 AM, 10/26/2009, with later additions ]

I updated the counter style for the index page and it did update and did increment (going from 00029 to 00030 after the initial viewing and one or two subsequent ones). The new one is an easy to read square style instead of a thin narrow style (which was the default). (At one time the counter was over 800, but the counter used back then stopped working and I had to replace it, years ago.)

I also added a counter to geobook.html (the old View Guestbook file), and it gave me the code to add to the file. However, GeoCities no longer uses that setup, keeping the guestbook files in a central location. When I had earlier attempted to view the Sign guestbook page, it gave me an error for the page not being found. The link pointed to a Geocities location that would have presumably pointed back toward my file, but that Geocities page evidently no longer exists, having been replaced with the new system. I did not try to actually add the code to geobook.html.

The Control panel page seems to have largely stopped updating statistics a few hours ago. It did finally show 10/26 on the graph, but it came up as zero even though I had just visited it, and I noticed earlier that it had stopped updating 10/25.

Goecities closes today, Monday, October 26, 2009.

Checking it again late afternoon October 26, 2009 (writing this 6:12 PM 10/26/2009), I saw that 10/26 did update to five I think, then to 11 after a lot of viewing, making it the most activity for a day this month.

The counter for the Index page (the starting page for my site) got updated to 33, I think, the other counters don't seem to work, and at least a couple of them seemed stuck at zero. Even the counter for the Index page seemed to work erratically, which is normal.

The final statistics, from the GeoCities Control Panel:


Site Status
Data Transfer Usage
0% 100%
Hourly limit: 4.2MB
Used: 10%
Times exceeded today: 0
Times exceeded this month: 0

Disk Space Usage (MB)
0% 100%
Total: 15.0
Used: 0.1
Extra: 0.0
Available: 14.9

Tired of hourly limits? Need more room? Upgrade your plan.



Site Activity
Page View Summary
Total page views in last 7 days: 23
Total page views in last 30 days: 23
Most page views in last 30 days: 11 (Mon 10/26)


Daily Page Views
50
25
0
0 0 0 0 3 9 11

10/20 10/21 10/22 10/23 10/24 10/25 10/26

Site Statistics
Review all available reports on your site traffic and
performance.

Labels: , , ,

My GeoCities Homepage

This originally had a green background when it was at Yahoo GeoCities, with the text in a column at the right and everything else in a column at the left, which also had a dafault picture place marker image. The links to other pages on my Geocities site have been changed to link to posts on this blog.



Title: Welcome to Stephen Morgan's home page


This site features a description of my programming abilities and includes examples of my work. The programs, for the most part, are written in FoxPro. A list of past projects will also be presented.

My resume may be viewed by clicking here.

A partial list of past projects may be viewed by clicking here.

In early 1998 I emailed a question to Lisa Slater Nicholls, who is a major figure in Foxpro circles. She very graciously answered me, and later that year published the question on her web site, as well as a more detailed answer. See the heading Menuing and keyboard interactions on the page Lisa Slater Nicholls Fox Volume 4 on her site.

In the original email, I also responded to a question she had posed on the site, as to whether anyone would be interested in hearing how to accomplish individually coloring bars in a list. I mentioned that I would be interested, and in a later page she responded, again mentioning me. See the heading Coloring separate items within listboxes and comboboxes on the page Lisa Slater Nicholls Fox stuff on her site.

I am also writing a blog now, Stephen's Thoughts. It is on a variety of topics, with many details of my personal life.

The number of posts on my blog has now exceeded 100. The oldest posts are falling off the bottom, and the archive list only shows the month and year, not the posts' titles, so I have created a separate blog to act as a table of contents. The second blog is called, appropriately enough, Table of Contents for Stephen's Thoughts, and is accessed through links on the main blog.


My Favorite Links:

Lisa Slater Nicholls Fox stuff

FoxPro Advisor Magazine

FoxTalk Newsletter Online

Pinter Consulting

Word Imperfect

Never-Ending Story

My Info:

Name:
Stephen E. Morgan

Email:
stephen_m99@yahoo.com

[ Yahoo! Presence indicator. This is a picture of a smiley, awake if the user in question is connected to the internet and asleep otherwise, but it's always asleep if Yahoo Messenger is uninstalled. ]

Sign Guestbook

View Guestbook

[ Number of visitors Counter. At one time it had over 800, but got reset for some reason, perhaps lack of visits over a long enough time. ]



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

Labels: , , ,

My GeoCities Guestbook

The original guestbook leave-a-comment page

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

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


Title: ADD Entry to Stephen Morgan's Guestbook


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

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

Nickname:

URL:http://

Email:

City and State:

Your Comments:




The original guestbook

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


Title: Past Visitors to Stephen Morgan's Guestbook


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

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

thnaks
[thin blue line]

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


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




Testing the original guestbook

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


Title: Past Visitors to Stephen Morgan's Guestbook


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

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

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

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


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




The new guestbook

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


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

[narrow double red line]


Return to Web Site Sign Guestbook




The comment in full

The following is my comment as it was actually written:

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





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

Labels: , ,

Resume

Home

Stephen Morgan's Resume



Email: stephen_m99@yahoo.com

Objective


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

Summary of Qualifications


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


Professional Experience


Using Visual FoxPro:


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


Using FoxPro, FoxBase and dBASE III:


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


Using Turbo C:


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


Networks:


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


Education


2000
Landmark Forum
Landmark Education Corporation, Phoenix, Arizona

1997
MP2 5.0 Enterprise Training
Datastream Systems Incorporated, Irvine, California

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




Work History


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

1990-1998
Software Engineer/R&D Engineer
1988-1990
Associate Software Engineer


Volunteer Experience


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


Home

Labels: , , ,

Program List

Stephen Morgan's Projects


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


Printer Menu - Details

Error Handler - Details

Startup Error Handler - Details

Error Handler for Visual FoxPro - Details

Status Monitor - Details

ECP Summary - Details

ECP Pages - Details

Config. Status Acct. Rpt. - Details

DCN - Details

ICN - Details

TEC - Details

Engineering Drawings - Details

Engineering Taskings - Details

Engineering Release Record Forms - Details

Technical Library - Details

Barcode Trakker-Inventory - Details

Barcode Trakker-Technical Library - Details

Training Program - Details

Shipping Documents - Details

GFE Inventory - Details

Test Equipment - Details

Key Control - Details

Job Control-Equipment Status - Details

Range Manager-Equipment Status - Details

Smoky Sams Usage - Details

QA PDR Forms - Details

UPS Alerts - Details

MANDATE - Details

Supply - Details

Supply-Purchasing Interface - Details

Supply-Servmart Interface - Details


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

Labels: , ,

Utility Programs, Part I - Printers

Stephen Morgan's FoxPro Projects - Utility Program Details

Introduction

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


Printer Menu

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

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

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

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

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

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

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

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

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


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

Labels: , ,

Utility Programs, Part II - Error handlers

Error Handler

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

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

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

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

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

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

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

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

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


Startup Error Handler

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

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


Error Handler for Visual FoxPro

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

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


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

Labels: , ,

Programs, Part I

Stephen Morgan's FoxPro Projects - Details

Introduction

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


Status Monitor

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

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

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

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

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

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


ECP Summary

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

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

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

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


ECP Pages

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

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

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

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

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

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

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

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


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

Labels: , ,

Programs, Part II

Configuration Status Accounting Report

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

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


DCN

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

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


ICN

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

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


TEC

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

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

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

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


Engineering Taskings

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

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

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


Engineering Drawings

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


Engineering Release Record Program

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


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

Labels: , ,

Programs, Part III

Technical Library

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

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

tablename INDEX index1, index2, index3

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

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

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

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


Barcode Trakker-Inventory

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

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

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

This was the program I was originally hired to write.


Barcode Trakker-Technical Library

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

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


Training Program

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

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

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

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

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

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


Shipping Documents

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

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

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


GFE Inventory

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

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

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

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

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

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


Test Equipment

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


Key Control

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


Job Control-Equipment Status

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

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

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


Range Manager-Equipment Status

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

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

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


Smoky Sams Usage

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

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

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


QA PDR Forms

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

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

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

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


UPS Alerts

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

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

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

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

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

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


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

Labels: , ,

. . Older Posts