Batch vs Interactive

Solid state memories start showing up from chip manufacturers in the very late 1960's. Initially, the larger of these were ‘recirculating’, taking as many as 512 clock cycles for the data at a particular address to be readable after it had been written. Among the first products that use these are CRT terminals - the DEC VT05, IBM 3270, Datapoint 3300, and so forth. While the initial terminals were built up from discrete semiconductors, it didn’t take long for single-chip CPUs to replace large collections of simpler components. These terminals, when connected to mainframes and minicomputers built from solid state memory and magnetic disk drives, presented business users with ‘interactive’ systems. The break from ‘batch’ to ‘interactive’ was stark and sudden, occurring pretty much from 1970 to 1975.

Almost no applications written in the 1960's are still in use (for an exception, research the ‘Taxpayer Master File’). A lot of applications written in the 1970's still plod on, either as CICS COBOL, RPG IV, ‘Business Basic’, C, C++, Pascal/Delphi, and so forth. In current design environments, character oriented fixed screen size applications are called ‘Console Apps’, and developers code new ones all the time, often in languages such as Java and C# that didn’t come into existence until the late 1990's.

IBM applications written around ‘block transmissions’ transmit a screen to a terminal, the user navigates through defined fields using cursor keys, and then ‘submits’ the edited screen using Enter or a function key. ‘Minicomputer’ applications operate on character streams, with a single character entered and then (usually) ‘echoed’ to the display, allowing processing on a character by character basis. GUI applications, such as the Mac, Windows, and smart phones, tend to have a more complex processing hierarchy that combines these characteristics.

An interesting ‘halfway’ exception is APL, which was an ‘interactive’ system that was implemented on mainframes using printer terminals. This exploited the ability of a printer to ‘overprint’ multiple characters to form more complex symbols. APL was a popular product within IBM in the 1960's and has survived to this day, but the ‘overprinting’ nature of the programming instructions hasn’t caught on much in video displays.

Legacy Code

Programs written for CRTs in the 1970's are still usable, at least in the literal sense that computers now still have keyboards and screens. Trying to find a 1960's era card reader, card punch, 9-track tape drive, or impact printer would be difficult but not impossible. Batch style jobs would tend to read and write files saved on disk or in flash memory, either of which is, at heart, random access.

Dozens of custom written applications, such as payrolls, accounts receivable, accounts payable, general ledger/financial reporting, order entry/inventory/sales analysis, and similar systems could, in theory, still operate on brand new desktops and laptops. To the extent such code is obsolete, it is obsolete due to the business models being replaced - local distribution companies, for example, have consolidated to regional or national warehouses; and have shifted to ‘just in time’ delivery schedules.

While the earlier systems used flat files, the emergence of relational databases has unified these into more complex ‘models’. Some ‘databases’ that emerged in the 1980's, such as dBase, had ‘columns’ and ‘tables’, even though these ‘tables’ were each a distinct file. As databases shifted from desktop machines to servers, more and more layers of administration and management were needed, and it made more sense to integrate all of the tables into a single database file.

Programmers often discover that their manager is expecting them to maintain or migrate a ‘legacy’ application that is ‘ancient’. Thus one finds open source versions of COBOL, Fortran, Basic, dBase, and various one-time proprietary languages. The industries most notorious for this are Finance, Health Care, and Government. A programmer might have learned Java and Python five years ago, and now has a ‘decent amount of experience’, only to find out that the jobs employers are desperate for are in MUMPS, C, or CICS COBOL. In many cases the current versions of these languages use reasonably modern coding conventions.

If one runs the clock in reverse, one discovers a smart-phone app written in JavaScript or one of its flavors accesses an API written in ‘classic ASP’. This API in turn queries data out of an IMS hierarchical database designed in the 1970's. Multiple generations of technology are strung together end-to-end. Some of these validate or update multiple data sources, so the IMS database is one of several, others being Oracle or Sql Server. The versions of these in production may still date from the late 1990's or early 2000's.

The constraints on migration come from multiple sources. One of them is an attitude of ‘if it ain’t broke don’t fix it’. Another is the sheer scale of the application makes it impossible to move all of it - it is still cheaper to use an updated mainframe than it is to recode 1 million lines. If the space probe is at the edge of the solar system the computer architecture is pretty much cast in concrete - there’s no way to go out and update the CPU. Most of the time the issue is budgets - Congress and state legislatures don’t have any confidence that agencies can properly migrate their systems, and some of this lack of confidence is justified.

Job Search Strategies

If someone in a software engineering role is ‘let go’, one approach is to get tanked up on AI and learn to train AI models. Another is to ‘archeological’, to dredge up some ancient language and write a few demos in it. A typical ‘mainframe’ of the 1960's didn’t operate at even 1 million operations per second (MIPS) - their speed was often 100K operations per second. It is possible to install an IBM mainframe emulator (Hercules Project) and recreate legacy mainframe environments. This is also true for PDP/11s and similar minicomputers. Many of these emulators run on Raspberry Pi’s.

Some embedded chips include FPGAs (Field Programmable Gate Arrays). These can be used to create what is effectively a ‘native machine’ via device programming. Some of this IP is free and some costs money, but it is an approach one can use to create a literal ‘legacy’ architecture computer with no emulation. Often this approach is used in product development when newer custom chips aren’t available yet - the FPGAs are used to identify any problems that might arise with the architecture before the design is taped out.

If 1K DRAM chips show up in 1971 (Wikipedia), then applications written on solid state memory computers could be as old as 52 years. If industry expansion is roughly linear, than three quarters of all applications in use today are probably less than 26 years old. This would suggest that the ‘average’ age of an application in use today is 13 years, or centered around 2010. This is about 3 years after the first smart phones went on sale in 2007.

Companies are often unwilling to admit they are running 40 year old code. In such circumstances ads become somewhat cryptic - the database is ‘Oracle’ but no mention of ‘which’ Oracle, the web scripting is ASP or PHP, and the embedded control assembler is ‘Z80'. There is no telling whether this is Oracle 11 or Oracle 19c, whether the PHP is 2.x or 3.x, or the Z80 is a 40 year old board or a 5 year old board. Even more cryptic is demand for experience with Manufacturing Resource Planning (MRP), Oil and Gas Joint Interest Billing and Revenue Distribution, or (name of state) Unemployment Compensation.

Skill in legacy system can be a key differentiator in a job search. Finding work in one of these systems requires an active presence in various discussion groups, publication of working programs, and personal acquaintance with others that work in the same platform/language. Showing a screen shot of an APL program running on your PC is useless - the people that do this stuff know who uses it and why. If you aren’t in communication with those people, you are a ‘babe in the woods’. These kinds of jobs are filled by word of mouth, and those mouths belong to people you know.