CA IDMS IUA EIUA

Expand all | Collapse all

cics to idms lu62 connectivity failure on CICS startup

  • 1.  cics to idms lu62 connectivity failure on CICS startup

    Posted 11-11-2008 10:46 AM
    apparently for the last hundred ? years, when CICS bounces (with IDMS
    up)
    - the Lu6.2 connections do not automatically sync up - they cannot force
    them from the CICS side, and the only way they have been able to resolve
    this is to issue DCMT V LINE *** OFL / ONL (in any event I am going to
    suggest connect)

    but is there a IDMS or CICS parameter that should make this happen
    automatically when CICS shuts down and starts while IDMS remains
    active??

    (we are idms 15.0 SP5 and CICS TS 3.1 and 3.2)


    thanks,

    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator Humana Inc
    502-476-2538
    choelscher@humana.com




    The information transmitted is intended only for the person or entity to
    which it is addressed and may contain CONFIDENTIAL material. If you
    receive this material/information in error, please contact the sender
    and delete or destroy the material/information.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: cics to idms lu62 connectivity failure on CICS startup
    "Chris,

    There is new CA-IDMS modules for the CICS to IDMS interfaces
    resynchronization program that need customized and linked. There are new
    parms for the CA-IDMS/CICS option module resyn program and task. Did you
    set that up?

    Steve Harmeson


  • 2.  Re:cics to idms lu62 connectivity failure on CICS startup

    Posted 11-11-2008 10:46 AM
    apparently for the last hundred ? years, when CICS bounces (with IDMS
    up)
    - the Lu6.2 connections do not automatically sync up - they cannot force
    them from the CICS side, and the only way they have been able to resolve
    this is to issue DCMT V LINE *** OFL / ONL (in any event I am going to
    suggest connect)

    but is there a IDMS or CICS parameter that should make this happen
    automatically when CICS shuts down and starts while IDMS remains
    active??

    (we are idms 15.0 SP5 and CICS TS 3.1 and 3.2)


    thanks,

    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator Humana Inc
    502-476-2538
    choelscher@humana.com




    The information transmitted is intended only for the person or entity to
    which it is addressed and may contain CONFIDENTIAL material. If you
    receive this material/information in error, please contact the sender
    and delete or destroy the material/information.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: cics to idms lu62 connectivity failure on CICS startup
    "well, since i am not familiar with what you are talking about, I will gess
    the asnwer is ... NO
    can you point me (in doc) to what you are referencing?

    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com




    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: [IDMSVENDOR-L] cics to idms lu62 connectivity failure on CICS startup
    "well, since i am not familiar with what you are talking about, I will gess
    the asnwer is ... NO
    can you point me (in doc) to what you are referencing?

    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com




    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDMS Data Replication Via TCP/IP
    "Now that the traffic on this topic has died down, and many folk are packing
    for Vegas...

    A few unsolicited thoughts on the matter of home-baked vs. store-bought
    replication mechanisms.

    First the disclaimer: Run Right, LLC is a consulting firm, and while we
    don't sell software, we (from time to time) DO provide services to firms
    that do. Be aware that we are not unbiased, and take what follows for what
    it's worth. Also note that we highly value the technical qualities of the
    IDMS product line, and believe that businesses have a huge investment of
    great value in the business logic embedded in their legacy IDMS
    applications.

    That said, there are situations why replication (and even migration) makes
    sense. What follows is a generic discussion, applicable to many products
    available commercially. This is not a commercial for a specific product or
    products (not going to discuss any), more of a Public Service Announcement,
    intended to point out things you should consider in approaching any
    replication project.

    Jon and his team are to be congratulated for crafting a solution that works
    for his shop. Another shop where I have toiled for many years (henceforth
    referred to as ""Company 'A'"") did something similar, but used embedded logic
    in applications and storing information in a databases rather than using DB
    Procedures and Queues. At Company A there are hundreds of thousands of IDMS
    record images sent down the pipe to Oracle-land daily (maybe millions).
    This solution has been in place for at least 10 years; the plumbing has
    changed slightly over time, but the basic architecture remains. Key to all
    this discussion is ""works for his (or your) shop"". What are you trying to
    do? I want to focus this discussion on: ""Offloading Reporting"".

    There are many objectives a company may have in seeking a replication
    strategy; offloading reporting to a cheaper platform than the mainframe
    being a common one. I personally think you're going to have problems
    arguing AGAINST the economics of offloading reporting cycles from the
    mainframe, but that's not where THIS PARTICULAR discussion is going.

    Once management has made this decision, the question becomes what is the
    most effective means of replicating to a distributed platform; and aside
    from functionality, performance and supportability, the issues of
    time-to-implement and net CPU savings need to be part of the evaluation.
    There are two major advantages commercial replication mechanisms will tend
    to have over home-grown: you can put it in quicker (thus starting to save
    cycles earlier), and you can save MORE cycles.

    Why is this?

    Most commercial solutions tend to be driven by JRNL data; home grown tend to
    be constructed using triggers and re-extracting from the original database
    (as in Jon's and Company A's solutions).

    So what?

    Well, using Jon's solution as an example (and Company A is the same), each
    time an update happens that needs to be replicated, TWO MORE IDMS UPDATES
    must happen to effect this change... a trigger (QUEUE record or other) is
    STORED, then eventually must be OBTAINED and ERASED. This is additional
    locking, updating, journaling... something that a solution based on JRNL
    extracts (either thru realtime exits or JRNL post-process) doesn't have to
    incur. You also won't have to concern yourself with lock contention if
    you're in a high volume situation. My guess is the locking issue posed Jon
    and team some serious implementation/design issues; I know it did at Company
    A.

    On top of the tripling of the update overhead (the original update plus two
    for the triggering), you have to OBTAIN the trigger/QUEUE record and
    re-OBTAINING the record(s) in question. That's two updates and two
    retrievals added for every change you're trying to replicate. This added
    overhead is a cost that a JRNL-based approach avoids.

    The downside of trying to construct a JRNL-based homegrown solution is that
    decoding JRNL data is hideously messy, and you have some real challenges
    pasting things together in a meaningful manner. It will require an advanced
    skill set to construct and maintain, and while you may have such expertise
    available, is this how you want them spending their time?

    So... the message here is IF your objective is workload offloading, esp in a
    high-volume environment, there are definite advantages to commercial
    solutions. You want to make sure you understand your shop's specific
    objectives, so you can map them in a prioritized fashion against the various
    commercial offerings vs. a DIY approach. And don't forget to factor in the
    time-to-implement dimension (rolling your own, as Jon notes below, can take
    some time).

    End of PSA.

    Don Casey
    Run Right, LLC

    P.S. Hi Jon! Linda says ""Hi"" too.