Basics of IDMS - great for reviewing for interviews: 

IDMS is a network (CODASYL) database sold by Computer Associates (originally marketed by Cullinane/Cullinet, the first software company to make it on the New York Stock Exchange). 

IBM's IMS is a hierarchical database.  DB2, Oracle, Microsoft/SQL, Informix, etc... are relational databases.   IDMS does have some relational capabilities, but based on what I have seen, only a small percentage of sites have taken advantage of this option (primarily because it is an extra-cost option from CA). 

DBA = Database Administrator  - Some sites separate the duties of the DBA and the System Programmer.  At other sites, the DBA provides both functions.  A system programmer is more likely to do installs and work with exits, where as the DBA is more likely to deal with logical and physical database design, schemas, DMCL, etc...

Click here to see Bachman (schema) diagram

CA = Computer Associates - the company that bought IDMS from Cullinet in approx 1989.

Three types of record storage modes: 

   1) CALC - random/hash algorithm used to assign a DBKEY target page to a logical key.

   2) VIA - physically clustered near other records (usually CALC records) in order to save I/O by reading multiple records on a single IDMS page in a single I/O.

   3) DIRECT - records stored on a suggested target page (based on DBKEY).  Not used near as often as the first two.

Other terms and quick review items for programmers:

   1) DBKEY - a 4 byte key, usually 3-byte page number and 1-byte  line index that uniquely identifies each physically stored IDMS record.  May also be called a "pointer" or "dbkey pointer".

   2) AREA - a range of IDMS pages used to stored IDMS data: Three critical factors, starting-page, number of pages (or ending page), and page-size.

   3) FILE - an IBM data set.  Areas can be mapped to files on a one-to-one, one-to-many, or many-to-one basis.

   4) DMCL - ties together journals, buffers, and files for an IDMS system.  There is always one global DMCL for a CV, but batch local jobs could have custom tailored or "local" DMCLs for performance.  The DMCLs are usually maintained by the DBA. 

   5) CV vs Local - all batch jobs run either under CV (Central Version) or in Local mode.  CV provides lock protection, journaling, etc... You should backup before running a local-update job.  Report jobs are often run in local mode (no backup needed).  Local is more efficient because it doesn't have the overhead of the CV.  See #29 and #30 below.

   6) TP-monitor - IDMS online programs can use any of the three methods to communicate with a terminal.  You should ask your prospective employer which kind of "shop" they are.

        (1) DC - IDMS has its only TP-monitor called DC

        (2) CICS - IDMS works with IBM's CICS.  Either you can write CICS programs which access IDMS database and use CICS maps to display and get the data, OR you can run IDMS under CICS/UCF (Universal Communication Facility), and programmers and user don't need to know they are really running under CICS.  Programs use IDMS maps, which gets translated into the appropriate language for CICS and terminals to understand. 

    Also ask if the company uses ADS or ADSO (some people leave the "O" off the end, both are commonly used).  ADS can run under DC or CICS, but some shops might use CICS for their TP-Monitor, but then use ADS for their programming interface.

    ADS stands for Application Development System, and is a separate language within IDMS.  You build IDMS Maps using the MAPC compiler (and online task), then connect the maps, work-records, code and subschemas into Dialogs.  Code is written in IDD modules, also called Response Processes.

   7) CAS - Cullinet Application System? - a manufacturing, accounting, payroll, inventory, PO, AR/AP system sold by CA that runs entirely under IDMS.

   8) Schema/subschema - a schema contains the logical database definintion.  A subschema is a subset of a schema.  Each batch program must refer to one (and only one) subschema/schema combination.  These are usually created and maintained by the DBA.

   9) DML = Database Manipulation Language, special IDMS verbs, such as OBTAIN, MODIFY, STORE, ERASE, COMMIT, READY, FINISH, ROLLBACK...  Programmers write DML code in their COBOL programs, which are run through the DMLC preprocessor to turn the special IDMS verbs into standard COBOL calls (to the IDMS subroutine). 

  10) A many-to-many relationship - is accomplished by a JUNCTION record (which is a member of two one-to-many relationships).  In the Bachman Diagram, EMPOSITION is a junction between JOB and EMPLOYEE.  

  11) Bill-of-Materials - is a special relationship, where a record has a "junction" record with two sets to it.  One set indicates a parent option, the other set indicates a member option.  This allows program to "explode or implode" the set relationship.  Two examples: PARTS in a manufacturing company.  An airplane wing is a part, but it consists of other parts, which in turn consist of other parts, etc...  The second example is an org-chart, where Vice-President has 5 manager reporting to him, but he reports to the President.  Each manager reports to a VP, but also has supervisor reporting to him, etc...

   12) Languages: Probably 90% of IDMS sites are COBOL, but IDMS also supports PL1, Fortran, and Assembler, but not C.  See reference above about IDMS's own language called ADS.  IDMS also has a batch report-writer called CULPRIT (which looks a little bit like RPG).

   13) OLQ = Online Query (which can actually also run in batch).  You can use online menu-mode to make reports, save reports, or generate a QFILE which is the code to reproduce the report.

   14) DMLO/DBOL - DMLO is CA's took DBOL is a competitor tool from Allen Systems Group. These allow online DML, retrieval or update.

   15) IDD - Integrated Data Dictionary - runs online or batch.  Has its own language DDL (Data Definition Language) sometimes called Double-"D" L (as compared to DDDL or Triple-"D" L used for schemas).  The IDD itself is an IDMS database, sometimes called a repository or metadata on other database systems.  Using DDL, IDD allows you to store and/or view elements, records, users and limited access to maps/programs.  Maps are usually stored using the MAPC compiler (online or batch).  Some sites allow programmers to update the IDD, others sites do not. 

    16) Program Error Codes - You can download my FREE IDMS error code book.  (click here) IDMS Error Status codes are 4 characters, consisting of a two byte major code and a two byte minor code.  The major code identifies the verb type (Store, Obtain, etc...) and the minor code the error type.  The most common errors are probably 0307 (end-of-set) and 0326 (record not found).  You should test for these type of errors, and each program usually has a catch-all routine for unexpected errors.  Programs can be written using AUTOSTATUS or non-AUTOSTATUS.  AUTOSTATUS calls the error-checking routine after each IDMS statement, so you must code the "ALLOWING" phrase for any expected error messages.

   27) Database Navigation - using DML to navigate through a database.  An Area Sweep ("Table space scan" for DB2 programmers) is where you read the entire IDMS Database Area looking for occurences of particular record types.  CALC-to-CALC sorted sets have a reputation of being inefficient, since each member is on a different page, there a lot of I/Os.  CALC-to-VIA is usually very efficient, usually only 1 or 2 I/Os, because the data is clustered together. 

   28) Locking - is too detailed of a topic to go into here.  Be aware that programs can lock each other out, slowing them down, or causing deadlocks (error=0329).  There are shared (inquiry) locks and exclusive (update) locks.

   29) What happens if you don't COMMIT every few records in a batch update program that updates hundreds of thousands of record?  Either the lock tables will fill up (IDMS locks every record updated until that record is committed) or the IDMS Journal will fill up.  See #30 below for more info. 

   30) IDMS usually has 3 or 4 disk journal files.  These record all the before/after images of all your updates.  Usually, IDMS cycles through these files.  When one journal file fills up, an auto-submitted job (via the WTO Write-To-Operator Exit) to offload the journal to tape, and to condense the disk journal.  The utility can only condense (remove) records that have been committed (see #29 above).    The DBA can use the RollForward or RollBack Utility with the tape journal to restore IDMS data.

   31) The IDMS log contains program dumps and statistical information.  Remember that it is the JOURNAL, not the log, that contains the before and after images used for recovery (see #30 above).  DB2 and MS/SQL Server write before and after images to a file they call the LOG, but IDMS calls the same type of file "The Journal", not the LOG.  Use a utility called IDMSPLOG (IDMS Print Log) to print dumps or time ranges from the log file). 

Hope this helps.  If you think of anything obvious that I have forgotten, please email: nwalters@sprynet.com