Last update May 2010, minor adjustments
September 3,
2002 (just adjusting links)
This
page is under construction and far from complete! This is
an outline that I will fill out when I have time.
Note: a lot of this was written about last century so much of the more recent work is missing.
This is a more detailed history of the kinds of programming tasks I have worked on than the moderate list of what I did in the Space Program at "http://www.alprosser19.com/alworks.html" or more recently at EDS "http://www.alprosser19.com/alwork.html".
There are several ways to organize this information, so I will try to cross reference some of the paths and may change the order some time in the future. I may also split off some parts to separate files.
While in University is in a separate file.
I graduated from University of Houston in December, 1985. I was working at IBM Federal Systems Division for a few weeks, and just got my NASA badge when the famous Challenger explosion occured. I still remember where I was and all that. I'll write about it sometime. From then until October 1997, I worked in the same organization, all but the first six months in the same department. The name of the organization, division, and company changed several times. To be expanded
To be expanded. For now, see the list of languages.
I have used so many Operating Systems, and survived so many upgrades, that learning a new one is like learning to drive a different brand of Automobile. They all have to do the same functions, it is only a matter of finding the controls.
While still in school, I used Digital VAX machines. UNIX was just coming out, and my Operating Systems class project was to simulate the UNIX file system with protection.
I used DOS 1.0 - 2.x at my Coop Job and at home. I later used as far as DOS 3.2 before changing to OS/2 1.3, 2.0, 2.1, 3.0 Warp at work. I used many Windows 3.x application from OS/2, and still use OS/2 4.0 at home on one computer and Windows 95 on the other (until 1998).
I began using VM and MVS early in my IBM career (1982-3). In later years, I was on teams to help coordinate application tool changes to be compatible with systems upgrades.
I have used Windows on workstations from 3.0 to 3.1 to 95 to 98SE to XP. I did Java Programming on Win XP to be ported to Solaris. I used Solaris for 4 years.
To be expanded
I have seen quite a number of programming methodologies over the years. The names and terms change more often than the underlying concepts. Even in the mid 1980s while we were doing structured, procedural programming with concepts that would later be called Object Oriented, Frameworks, reusable components, patterns, or whatever. I have worked in all phases of the system life cycle, and used waterfall and spiral models to show parts of the cycle and studied other models.
To be expanded
To be expanded. For now, see the list of recent duties.
To be expanded. For now, see the list of recent duties.
My Compiler Design professor counted documentation as half our programming grade, IF our projects worked. Since then, I have considered proper documentation vital to any programming project. Frequently, I have seen documenting programs as a prerequisite for moving on to new opportunities. I ususally start writing a program by writing an outline of the design in comments, then filling in the code.
Some of my early work was writing user interface and help panels for ISPF interactive applications. I was also on teams to create standards and procedures for documentation as well as code. I worked on documents for several types of users, each requiring a different level of detail.
Small applications or tools to be used by experienced programmers would only require a small amount of detail, perhaps just a high level help panel. We created a standard that when someone was using an ISPF application and pressed the Help key, they should see something related to the application that they were using.
Requirements for critical tools and higher had to be at a detailed enough letter that a fairly technical non-programmer could determine through testing that the code met the requirements. All the developers reviewed any requirements before they went to the customer and user community for approval. I made updates to requirements for the AP101 Linkage Editor in my later years.
User documentation had to be at a level sufficient for the intended audience. We had applications for managers that needed to be fairly detailed, and some for non-programmer contractors that needed to be almost step by step foolproof. User's Guides often had figures and screen shots for interactive applicatiosn or JCL samples for background programs. They could be 20 or 30 pages for some of the medium applications, or several hundred pages for the mission simulator or configuration management system. I create User's Guides for several medium to large applications that I wrote.
When errors were found in programs, we had to write up an analysis of the problem and solution that a moderately technical person (a representative to a review board) could explain and answer questions to people possibly unfamiliar with the application (NASA or contractors overseeing our work).
We often had to write up an analysis or even design for proposed changes such that another programmer could pick them up months later and do the program change. That programmer could very well the same person.
When ISO 9001 kinds of quality stuff came along, procedures had to be written so that someone unfamiliar with them could do an audit that they were being followed. After the Challenger, in the preparation for Reflight, we went through all of our procedures and standards to see that they were reasonable. I went through an update of the Flight Software Application Tools procedures and added language specific standards and guidelines for PL/I and ISPF applications.
In later years, we started creating Functional Design Documents for major new applications before any code was written. They could be 10-60 pages long, and I wrote a couple of them. When we started using Object Modeling Technique for C++ application, we would include the kinds of diagrams for OMT, especially Object Diagrams, but also sometimes Data Flow Diagrams or State Diagrams. I worked on Object Diagrams for a couple applications in the early design stages, but changed roles to verifier or domain expert by the time they were implemented.
In early 1987, I got tired of waiting for an available documentation specialist and took a course in Script/GML. While most of the other programmers and analysts would hand write their documentation updates, I would just write in SGML (or later, Bookmaster) and turn in the file. Almost all of my home page is written in raw HTML in a plain editor, since HTML is just a Generalized Markup Language dialect anyway.
I have written a lot of documentation in Ami-Pro, since it was the standard desktop word processor for a few years, and used Microsoft Word for several years, but really prefer to write in a operating system and tool independent manner, so lean a bit to HTML as a preference. I find it bothersome when a word processor formats text how IT wants, instead of how I want. At least many of them will now read and save in HTML, so I can have the best of both.
To be expanded.
This is not a complete list, just a sample.
One day in the mid-1980s, a lead technical programmer and I went to the NASA contract monitor and brought up the subject of the little tools that programmers write to help do their job, that do not particularly meet some customer request, but will save time for programmers. It would happen from time to time that more than one person would develop something similar to a tool already written. We proposed the idea that we provide some means for communicating about these tools to others and when appropriate, finding a way to share them. I helped work on tools to help, and was a representative to the periodic meetings where these things were discussed.
There was a time in the late 1980s (1987?) when we needed to know which system products were used by which tools, so that we would know who to contact when a new compiler was developed, or a new version of ISPF needed to be tested. There was some plans to buy a new database system to replace the IMS that we were using for our Configuration Management Database, but a decision had not been made by NASA to use DB2 or Oracle. It turned out to be several years before the real Oracle based application was written
We wanted to collect the data, so one of the staff people wrote up a list of the information to collect and I was asked to create an interactive tool that would be easy to use to collect the data. We created paper forms that responsible developers or analysts could fill out, and I created an ISPF application to allow data entry, either by developers or non-technical subcontractors from the paper copies. Every component (program, clist, panel, JCL Skeleton) was assigned to a "tool" and every tool had a responsible person and manager for approving updates.
Everything was stored in ISPF tables from a PL/I program. I found that ISPF only allows 255 names in a name list, so had to do some fancy tricks to get the dependency table included. It was possible to get reports listing all information about a tool, or a matrix of all tools against system products, or just a list of system products that we had dependencies for.
I wrote the application in a few weeks and we were able to collect the information so that when we made our next major annual release, were were able to tell the customer what levels of operating system components needed to be when they stepped up to the new version.
From the beginning through the early 1990s, Flight Software and Tool builds involved a loosely controlled set of JCL that needed error prone manual edits at several points in the process. A set of JCL ISPF skeletons and clists evolved that were controlled at the lower level Backroom tool process. Since ones and zeros that would fly on the Shuttle were affected by this process, it was designated a critical tool, and decided to write an application that would rigorously control the builds to make sure everything that needed to be done was done correctly and in the correct order. Since I had experience with similar applications for lower level tools and Flight Software Reconfiguration, I was to be the lead programmer.
The three programmers that were to help me became unavailable, and I ended up writing most of it myself. It is known as the Build Dialog. It has over 10,000 lines of code, about a dozen PL/I modules, dozens of JCL skeletons, many ISPF panels and some clists. It was really quite a challenge. The procedures we were using (requirements, approval, design, code, test, build, verification) were optimal for small to medium maintenance to existing applications, and a large application really needs an iterative process. It took a little while to figure out how to do it right, even if the requirements still needed work. Still, we got it out, and last I checked, there were about a dozen errors in the original implementation, mostly from miscommunication of requirements and most found before production.
I developed a few PL/I tricks while working on this to increase productivity, reuse, and to make long term maintenance easier. I'll include them in a list of PL/I hints, someday
Reengineering projects will be added later.
To be expanded.
To be expanded. For now, see the list of recent duties.
Over the years, I frequently worked on teams to coordinate upgrades in operating systems or compilers.
For a while, I was the tools area representative or backup to the group with NASA to discuss operating system upgrades and issues. This was to keep our developers informed of changes that could impact our programs, and to make sure changes that were made by the systems folks were coordinated with our developers.
A lot of subprograms in the Shuttle Simulator and post processing systems were originally written for the IBM FORTRAN H extended compiler, essentially FORTRAN IV. A few years after IBM stopped supporting FORTRAN H, I was the lead to coordinate the conversion to VS FORTRAN, essentially FORTRAN 77.
When we converted from PL/I version 1.5.1 to version 2.3, I did research across the IBM internal network, communicating with programmers from other sites to find out what challenges had been faced and how to avoid the pitfalls. I combined information from reports from Austria(?) and somewhere else to a list of program characteristics to search for that was distributed to developers responsible for PL/I programs. I also did searches to identify which programs were at risk.
I would frequently do searches and audits over the years because of my familiarity with the languages we used and the location of the files. One of the last was to do some checks for YR2000 compliance. We were to get a PTF (bug fix) applied so that the PL/I date function will work, and I audited the executables to be sure which ones would need to be relinked if they were not already being updated. I also checked a few applications that were using dates in various ways.
Part of becoming a mature software organization (as defined by the Software Engineering Institute), is coordinating between groups. There are many of these groups in OBS, and I served as a representative to several of them. Some were long term, like
Panels Working Group (PWG).
Backroom Tools Control Board (BTCB).
Support Software Application Tool Discrepancy Report Control Board (SSDRB).
Support Software Change Report Control Board (SSCRB).
There were some short term coordination groups as well.
The team to coordinate a major operating system upgrade (from MVS ESA to the version just before OS390). We were also going from ISPF 3.5 to 4.2, so it was a major interface upgrade as well.
The YR2000 team.
We had various groups for each major (approximately annual) release. Recently I would work with other verifiers to help put test cases in the data to test new releases.
To be expanded.
To be expanded. For now, see the list of languages.
Most of the applications I worked on had to have some security considerations. Each application needed to be evaluated to determine what level of security was needed, and how to provide it. There were many combinations of hard coded userids, ISPF table lookups, RACF protection of input, output, or control datasets.
In the early 1990s, I became a RACF group administrator for our second level organization, as a side task to my normal duties. Although I had already written applications that did most of the commands required, I took the certification course required by NASA of anyone with GROUP SPECIAL access.
I audited the security, set up userids, and reset passwords for several departments, including a duplicate system set up for Government SECRET operations.
To be expanded.
Al's Home Page is at http://www.alprosser19.com/
Comments to alprosser19@yahoo.com