So, a couple of years into being a Programmer-Analyst... it's still the early 80's, back when jobs had numbers after them, so you would start as a PA 1, progress to PA 2, and so on. Progression also meant raises along with annual increases. I would say this was the period of my career, unique to the time, where my salary grew the fastest. No one had invented bonuses based on company success, you made what you made without concern for company profits, while realizing that low or no profit was not good for job security.
So, a couple of years in, the Corporate Systems department gets a new development project! This is full in-house development, PL/1, IMS DB/DC. The company had been using a system similar to the mortgage system I have described, but for securities: stocks, bonds, money markets, etc. I was not in on the process that led to the decision, still being a junior programmer busy on current projects, but looking back now it must have been a reaction to the realization that every-other-night batch processing was not going to be good enough for stocks and bonds trading. So, this was going to be an online system, where the trades on the markets would be captured right after they occurred. It was not a trading system itself, nor was it connected to one, so the traders were going to record what they did in this new securities administration and control system (more on how that worked out, later).
As I mentioned earlier, the core Individual Insurance Systems were already online using this technology, but it would be the first such system in a Corporate area. Our senior programmer/designer/architect took on the challenge of building a trial online system first, to show it could be done in Corporate Systems, It was an easy-to-develop structure he came up with.
Most online systems have one program for each screen used in the system that handles both out put to the screen, and receiving input from the user. I saw this structure as awkward, as it could be tough to discern which part of a program was being used at any one time. Our architect devised a master control program that would, for example, discern what screen had been just used by the user and pass its input to a program built to process input from that screen. It would do all the editing and, if there were input errors, it would pass that information to a program built to send data and messages to that screen, which would do just that. The user has the response and does what they need to do, hit enter and the whole process starts again. Once the input program is OK with the data its has received, it will then do one of many possible things defined for it; for example, the user may have indicated they want to navigate to another screen, so the input program would pass control (and any needed data) to the output program for that other screen, it does what it does and sends data out to the user, etc. etc.
Just want to remind the reader that this is still a mainframe, green screen system, so next time I will recall how we actually built it, and the good and bad things that happened.
No comments:
Post a Comment