CA IDMS IUA EIUA

Re:Re: IDMS Data Replication Via TCP/IP

  • 1.  Re:Re: IDMS Data Replication Via TCP/IP

    Posted 11-09-2008 09:06 AM
    This probably doesn't help your situation any, but I can tell you what
    we did.

    We are trying to get off the mainframe (and IDMS).
    We have a need to keep many databases synchronized real-time throughout
    the day while development continues to retire IDMS applications and
    replace with brand new non-IDMS systems.

    We wrote our own message exchange system.
    It handles both PUBLISH and SUBSCRIBE messages.
    IDMS can be updated from an update that originates on another database
    and another database can be updated when an update originates in IDMS.

    On the PUBLISH end:
    1. An update occurs in IDMS.
    2. A database procedure gets called for the record and writes a queue
    record to any one of over a hundred queues.
    3. A DC-COBOL program fires up as a result of queue trigger of 1.
    4. DC-COBOL program re-obtains the record or (in case of an ERASE,
    captures the key from the queue record) and writes appropriate fields
    for the record to message exchange database on IDMS.
    5. TCP/IP Socket program idles looking for PUBLISH records to send to
    server.
    6. Server routes message to appropriate system and processes update
    database.

    On the SUBSCRIBE end:
    1. TCP/IP Socket program sends message to message exchange database on
    IDMS from open-systems side.
    2. Another non-socket idler program looks for SUBSCRIBE messages to
    process.
    3. Idler program reads the tag to figure out what message it is.
    4. Idler attaches the appropriate task to process the message and
    update IDMS.

    The above is a simplification of what happens.
    There are called programs for handling writing and reading messages and
    a lot of tables are involved so we don't have to recompile / reassemble
    every time there is a change or a new message.

    It took a while to develop ( 1 year +) and it was a lot of fine-tuning
    effort along the way for the first couple of years.
    Also, it is possible to end up with ""Dead Messages"" for any of a number
    of reasons.
    We have a process in place to handle those so we don't lose updates and
    get databases out-of-sync.

    Thanks.
    Jon Gocher