Linked by snydeq on Fri 12th Aug 2011 03:55 UTC
OSNews, Generic OSes InfoWorld's Galen Gruman highlights 18 technologies that remain core to the computing experience for IT, engineers, and developers 25 to 50 years since their inception. From Cobol, to the IBM mainframe, to C, to x86, these high-tech senior citizens not only keep kicking but provide the foundations for many vital systems that keep IT humming.
Thread beginning with comment 485184
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Infoworld
by rcsteiner on Mon 15th Aug 2011 21:21 UTC in reply to "RE[2]: Infoworld"
rcsteiner
Member since:
2005-07-12

An OLTP subsystem is a specific environment within a mainframe that is different from the more traditional interactive and batch environments a mainframe also has (and which are conceptually similar to a UNIX shell and shell scripts).

It represents a very specific way of designing, writing, and executing software. Very controlled.

My coding experience is limited to the Sperry and Burroughs flavors of OLTP, not IBM's, but I suspect they are all similar in some elements of their basic

OLTP is an event-driven subsystem running in addition to the base OS which is dedicated to the very fast loading, execution, and termination of small single-purpose programs under the control of a central scheduling service.

This scheduling service is the only thing which really stays resident as such ... it generally parses the first few bytes of each incoming message (often known as a "transaction ID" or "search ID") and uses that information to reference a table which determines which OLTP program should be started to address the issue, often by program number.

One simple transaction program build a screen on the screen when called, then exit ... maybe the current weather, or a flight status display, or just a fill-in mask (form) prompting the user for more information.

Another transaction program might parse a screen that has been resubmitted with bits of data added, and then generate some form of positive or negative response before terminating.

A third might receive a message from another system (no user interface at all), store it in a defined manner, and exit. Or massage it and pass it along to a third system.

A fourth might start when a timer triggers, perform some tasks, and then exit. A lot of housekeeping runs are controlled in that way. Similar to, but predating things like crontab.

Programs don't hang around. Usually. They might be configured to remain resident in memory for speed of access, and multiple copies might be kept in that state to speed things along, but control is never passed to them until the scheduler says so. It's purely a push technology.

Similar subsystems probably exist in UNIX environments somewhere, but I've not seen them. Tuxedo can be a little similar in some respects, since a Tux server tends to push messages to resident Tux services, but that sort of message passing is the only bit that's the same. Tux programs are still run from a standard shell, request memory from the OS, etc., while OLTP programs don't really work that way.

Hard to explain in a short note. Just like it's hard to explain the concept of "freespace files" to someone who only does relational databases. If you only knew how slllooowwww an RDMS is compared to other established systems...

Interestingly, the IBM OLTP environment was developed for American Airlines, while the UNIVAC/Sperry solution was developed for United Airlines and Air Canada. Not sure where MCP transactions started, but I suspect either an airline or a bank.

Edited 2011-08-15 21:27 UTC

Reply Parent Score: 2