Agentless Backup is Not a Myth
Something borrowed, something new
Bachman describes IDS as "an assemblage of a number of different ideas". Some of these ideas came from abstract concepts such as data hierarchies, data descriptions and randomised addressing. Other ideas grew from earlier attempts to analyse data such as the 702 Report Generator developed for the IBM 702 and 9PAC that was built for the 702's successor, the IBM 709. Bachman became involved with work to develop the 9PAC reporting system through the IBM SHARE user group while still at Dow.
He recalls the way that SHARE worked then was comparable in some ways to today's open source development. Participants gave their time and ideas voluntarily and swapped code – as long as you had several million dollars to buy the machine to run it on.
"DBMS is a leap back to a 100-year-old technology – it tracks back to what we used to do with punched cards" – Charlie Bachman
But it was not only novel software ideas that made IDS possible. Developments in storage technology also played their part and the big enabler was the emergence of "affordable" and reliable disk storage devices. Disk stores had been around since the mid-1950s, but it was not until the early 1960s that it became practical to use them in commercial applications.
Building the programs needed to operate IDS turned out to be a real challenge for Bachman. He had only written a single program previously.
"When I came to develop IDS, I had only one program behind me. We started out using a language called GECOM, which was GE's version of what later became Cobol. For two years we were dealing with GECOM although there was a feature that allowed you to enter the assembly language: GEPLAN."
Even before the MIACS project was completed, Bachman realised that IDS would be important: "MIACS did not go into production until 1965 – but we already had two IDS sites running in 1964 and saw we could put it into production."
Database software derived from IDS's network model continued to grow until the 1980s, when the faster hardware enabled the relational model developed by IBM's Ted Codd to take the lead.
Bachman, though, remains skeptical about the use of relational database in large-scale transaction processing systems: "There is still a large discussion here in my mind. Ideas have a great deal of momentum. Big systems are very difficult to replace with 'new' systems. Otherwise why do a thousand IDMS (IDS) systems still run some very large IBM mainframes around the world?"
It's a hot topic. Others, particularly supporters of NoSQL, would argue RDMS is not suited to large systems. Today those large systems are not mainframes, they are data centers running companies' clouds. When it comes to so-called very-large databases today, Bachman is fairly dismissive and brief. "Oh that was all happening in the 1970s," he tells us.
Passion in the blood
Bachman's later work has taken him into open systems and computer-aided software engineering (CASE) tools, but his passion for database systems has continued. Most recently he has worked with the Cord Blood Registry (CBR) in California to develop special database software for stem cell research.
Bachman's papers and correspondence are archived at the Charles Babbage Institute.
And with his birthday fast approaching next month, Bachman is still thinking outside the box, coming up with fresh insights on databases.
"While working on my data-modelling book I had an insight into what relational DBMS is really all about. Thinking back to the old card-based 702 report writer it was all about flattened files - where all codes are in every record. If you do a relational JOIN you do just that - you flatten the file.
"So," he concludes, "it struck me that relational DBMS is a leap back to a 100-year-old technology – it tracks back to what we used to do with punched cards – aside from SQL as a language to control what is going on." ®
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
Size doesn't matter
"Others, particularly supporters of NoSQL, would argue RDMS is not suited to large systems."
The size of the system isn't the point. The nature of the data is. RDMS works well with structured data which can be at least somewhat normalized and which is queried primarily on the structured bits. RDMS does not work so well with non-structured data. NoSQL technologies, on the other hand, work better with non-structured data, but aren't as efficient as an RDMS can be with structured data.
A Moment of Zen
IDMS structure diagrams used to be referred to as "Bachman Diagrams". Problem was, Charlie didn't create the gory details of the structure diagram... each Record box on the diagram was subdivided into about a number of sub-boxes (Record name, location mode, Area name, etc). These were extensions to the classic E-R diagram; CulCorp even used to give away rubber stamps with the Record block so people could draw their diagrams (I still have mine).
On tech conference Charlie was invited as a guest, and my region had created t-shirts that featured a portion of a database diagram on the front.
Your zen moment: watching the head of West Coast Field Education explain to Charlie Bachman the "Bachman Diagram" on his tshirt.
Relative fun value
Agreed. A good academic in a decent position (this unfortunately excludes many good academics stuck in fixed-term teaching-mill jobs) doesn't teach the same thing every year. Even if they teach under the same course numbers and titles, they change the syllabus and classroom practices. And in non-recitation classes, where the class size is small enough that there can be real interaction between instructor and students, that "new batch of students" means it won't be the same class as last year's anyway.
No doubt some engineers have more fun than some academics. And no doubt the reverse is true as well.
And, of course, there are those who wear both hats. (Generally not at the same time, but you *can* perch a mortarboard on top of an engineer's cap if you're careful.)

IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring