Wednesday, November 01, 2006

IDMS: a cautionary tale about the Central Version

I have gotten a call of two from recruiters about some old mainframe experience that I had with IDMS. This was a network database model with Schemas, and had at one time belonged to Cullinane Corporation. It should not be confused with IBM's IMS, which is a hierarchal database model.

In fact, in the 1970s Sperry Univac had owned a similar product, DMS-1100, which had the same kind of structure, and which was intended for its 1100 series computers (1108, 1110), running under Exec8, which was a command-like JCL somewhat like Linux today (simpler than IBM mainframe with its verbosity). In fact, Exec8 offered an automated JCL generator called SSG in the 1970s, which was more flexible than IBM's concept of Procs. While working for Univac, I did a training exercise putting my classical record library on DMS-1100, something easily done today with products like MySQL. In the 1970s, NBC (National Broadcasting Company) was a Univac shop (relatively rare in New York City then) and used DMS-1100 and SSG heavily, as well as "Ascii COBOL".

IDMS could work with either its own format, or with its VSAM transparency, where the data was actually on VSAM files that could be manipulated with standard IBM utilities (IDCAMS). On the salary deduction billing and collection system in the early 1990s, I worked with the VSAM transparency.

Database access could be controlled with either the Central Version (the "CV"), with the inclusion of one specific CV dataset and a specific DD name in a specific STEP in the JCL, or in local mode, in which the actual datasets (in our case, VSAM files) had to be named in the specific STEP (or for the whole job.

When running in local mode, normal security worked. A programmer could not update the production database without specific access. But in the Central Version there was a loophole, because in the 90s at least, Top Secret could see past the CV control dataset to protect update access with the specific VSAM files. There was a risk that with a wrong CV dataset (pointing to the production files) anyone could update billing or collection data with an ordinary submitted batch job, and that the update would not even be noticed for a long time, making recovery very difficult. I don't know if IDMS eventually fixed this.

No comments: