Looking forward to CA IDMS 18.5’s SQL Web Connect feature

Next year, we will be performing an upgrade to CA IDMS release 18.5 for Vivium, the insurance company I work for.  THE thing I’m looking forward to is to finally have JDBC capabilities available for our IDMS environment – we never had a license for the SQL Option and IDMS Server…  It is a bit late maybe, especially since alternatives for the relational model are emerging in the form of NoSQL databases, but nevertheless I intend to make use of this feature to offer an alternative to importing and updating schemas from their syntax

Adding new import/update capabilities to the Eclipse CA IDMS™/DB Schema Diagram Editor is fairly straightforward :  its main plug-in (‘org.lh.dmlj.schema.editor’) defines an extension point called ‘import’ for this purpose.  When you write an Eclipse plug-in, you usually extend Eclipse by defining 1 or more extensions; defining an extension point in your plug-in allows others to extend your plug-in (by defining extensions for that extension point).  The ‘import’ extension point allows you to define 1 or more import tools – import tools provide the diagram editor with the data it needs to create (or update) a schema diagram.

When you install the diagram editor, you have 1 import tool available out of the box :  ‘org.lh.dmlj.schema.editor.importTool1’ (‘Import or update a CA IDMS/DB schema from a file that contains CA IDMS/DB schema syntax.’).  When you launch the CA IDMS/DB Schema Import Wizard, you don’t need to select an import tool (in fact you can’t), since there is only one available.  When additional import tools are defined, you will have to select one though :

Import Tool Selection

After selecting an import tool, pressing the Select button will lock it; this is necessary because each import tool defines its own set of wizard pages and it’s easier to implement a wizard if you don’t need to remove and add pages (the wizard page flow can become complicated); you can always cancel and restart the wizard if you want to use a different import tool.

Besides the standard import tool, the above example lists an import tool I wrote about 2 years ago and that allows me to import or update a CA IDMS/DB schema directly from a DDLDML area whose (single) file is available on the file system; this import tool is built on my own navigational API library for Java and in which IDMS is not involved (you could say that I built a small part of the IDMS DBMS in Java).

The illustration below gives an impression of the extension point definitions for both import tools (the standard import tool is on the left) :


I will not be going into too much details here but the things to note are :

  • Each import tool has to provide a Java class that implements the ISchemaImportTool interface; it is this class that will supply all data regarding the schema.
  • There is 1 options page, which is preceded by at least 1 data entry page and followed by zero or more data entry pages.
  • You’ll need at least 1 data entry page to allow the user to select the schema to be imported or updated (hence the ‘at least 1 data entry page’ to preceed the options page)
  • The options page allows you to fine-tune the import/update operation (e.g. for IDMSNTWK)
  • Besides defining import tools, you can define your own layout managers; layout mangers determine the initial placement of records in the diagram (not applicable for update operations).

Now, back to the SQL Web Connect feature…

The idea is to define a new import tool, provide it with at least 1 data entry page that allow(s) you to select an IDMS environment, dictionary and schema, and have the associated class access the dictionary via JDBC calls.  I will most probably add a preference page as well, which will allow you to define IDMS environments and dictionaries.

The good news is that it will make the diagram editor interact directly with IDMS for the first time; the bad news is that you’ll have to wait until next year (and of course you should have either the CA IDMS SQL Option and CA IDMS Server or the SQL Web Connect feature available), but now that you have a little background on defining import tools, you can always write this (or any other) import tool yourself 🙂

To be continued…

Creating and deleting indexes

The next version of the diagram editor will allow you to create indexes and remove existing ones.  This is the first step towards making it possible to build IDMS diagrams from scratch. Of course you will want to create records and sets as well, but creating an index is relatively simple, so that’s why I’m beginning with that one 😉

The diagram editor’s palette will feature an ‘Index tool’, that, when selected (1), allows you to ‘drop’ a new index on a record, just by clicking inside a record (2).  This is illustrated with the following screenshot :


The new index will appear in the diagram after the operation is complete…

diagram2The index will have a generated name (‘NEW-INDEX-1’ in the example above), and it will be put in a separate (new) area, whose name is directly related to the name of the index. Moreover, the index will have the following initial characteristics :

  • The set membership option is set to MANDATORY AUTOMATIC.
  • The set order is LAST.

It’s easy to add the index pointer, change the membership option (you’ll need to add the index pointer first), move the index to another area or change the name of the generated area, all using the Properties view.

Work has to be done to the diagram editor for what changing the set order is concerned, so at the time of writing this article, that is NOT yet possible; the ‘Order’ property is currently read-only :


Implementing the ‘Index tool’ revealed a weak spot in the diagram editor for what reacting to ‘model changes‘ is concerned (the model is the object graph behind a diagram). Especially the recently added Outline view expects the model to be in a consistent state when adding or removing a diagram item.  As a consequence, I’m redesigning the way the diagram editor deals with model changes :  in stead of reacting to (listening for) individual property change events, model changes are bundled (compare this to a unit of work) and the diagram editor’s components (the diagram itself, the Properties view and the Outline view) will be notified of these model changes in a more controlled way (i.e. the model will always be consistent when a component receives a notification).  More on this in a later post…

That takes a lot of work, especially since I’m also adding unit tests for all the commands that carry out the model changes (those unit tests should have been there in the first place, I know).

by Luc Hermans