DB2 - L

 View Only
Expand all | Collapse all

CICS / DB2 transactions Docs

  • 1.  CICS / DB2 transactions Docs

    Posted Nov 11, 2021 11:37 AM
    Any recommended DOCS on CICS / DB2 transactions setup and processing?
    I have a lot of legacy transactions and "CICS / DB2" processes that we needed to weed thru and understand.........
    thanks
    Bill

    ------------------------------
    williamgiannelliMe
    ------------------------------


  • 2.  RE: CICS / DB2 transactions Docs

    Posted Nov 11, 2021 01:34 PM
    Hi
    what do you mean with setup and processing?
    How the connection between CICS and DB2 works? Commits and Rollbacks?
    Can you tel us a litle bit more?

    António Barata
     
    Phone: 00351 937402410





  • 3.  RE: CICS / DB2 transactions Docs

    Posted Nov 11, 2021 01:37 PM
    I am looking for an understanding of the "flow" of processing from CICS to DB2 and back. We are trying to understand and correlate waits times in cics and db2.
    Bill

    ------------------------------
    williamgiannelliMe
    ------------------------------



  • 4.  RE: CICS / DB2 transactions Docs

    Posted Nov 11, 2021 02:09 PM
    other side to this is to also understand if and how a transaction might "branch" out to other programs or call other transactions.
    Bill

    ------------------------------
    williamgiannelliMe
    ------------------------------



  • 5.  RE: CICS / DB2 transactions Docs

    Posted Nov 11, 2021 02:24 PM
    About your last question, a transaction has always an associated program, that gets executed whenever the transactions is entrered.
    A paogram can "brunch" to others, in one of two ways:
        LINK - It works as a normal CALL, you transfer control to the other program, and when it finishes it returns to the following instruction
        XCTL - You transfer control to the other program and the processing continues from there on that program, not returning

    Normally you can call a transaction with a START command, with parameters

    I suggest you get a look at the CICS Application Programming Guide, and the CICS Application Programming Reference

    António Barata
     
    Phone: 00351 937402410





  • 6.  RE: CICS / DB2 transactions Docs

    Posted Nov 11, 2021 07:42 PM
    One thing being left out of this tread is CICS TCBs. Not that I really understand them.
    Corrections welcome

    When the program for a CICS transaction starts executing, it executes under the control of
    the CICS address space main TCB. While is does CICS'y things (EXEC CICS ...) it stays
    under the control of that TCB. Since there is only one main TCB, it follows that there can be
    only one program executing in this state in a CICS address space.

    When the program wants to do a DB2'y thing (EXEC SQL ...), the program is transferred to a
    Db2 TCB in the CICS address space. The number of these and which transactions they are
    used for is controlled by the CICS DB2ENTRY etc definitions. While the program is under
    the control of a Db2 TCB the main TCB can be executing another program.

    After the DB2 thing has finished one of two things will happen:
    - control returns to the main TCB. If the main TCB is executing another program, our's will
    be put into a queue waiting for its turn at the main TCB
    - if the program has been declared "threadsafe" (that is it won't do nasty things to the CICS
    environment), it can continue executing under the control of the Db2 TCB. And will continue
    to do so until it does a CICS'y thing - when it will be returned to the main TCB.

    As I understand things, managing the number of DB2ENTRYs and their associated
    parameters is part of tuning CICS. Too few and transactions (programs) will queue waiting
    for a TCB under which they can execute.

    General recommendation is that threadsafe is good, since is allows maultiple programs to be
    executing in a single address space.

    https://www.ibm.com/docs/en/cics-ts/5.5?topic=fundamentals-threadsafe-learning-path

    There are also file related TCBs.

    James Campbell


    On 11 Nov 2021 at 19:24, Barata via International DB2 wrote:

    > About your last question, a transaction has always an associated program, that gets executed whenever the transactions is entrered.A paogram can "brunch" to others, in one of two ways: LINK - It works as a normal CALL, you transfer control to the other program, and when it finishes it returns to the following instruction XCTL - You transfer control to the other program and the processing continues from there on that program, not returning
    > Normally you can call a transaction with a START command, with parameters
    > I suggest you get a look at the CICS Application Programming Guide, and the CICS Application Programming Reference
    >
    > António Barata Phone: 00351 937402410e-mail: antonio.barata@yahoo.co.uk


  • 7.  RE: CICS / DB2 transactions Docs

    Posted Nov 11, 2021 10:53 PM
    Excellent explanation James! Very interesting also for me as a Db2 for LUW guy with a slight hang to communication with the host side.

    What I remember from a customer project: For CICS it is plain simple to have two apps working hand in hand, exchanging data via a table within the same transaction boundaries. One program is updating a row, but not yet commiting. The other program is feeding in some additional information in the same row (without getting locked out) and handing back the context.

    If people tend to migrate this to e.g. Microfocus Enterprise Server to run on Distributed, these communications can get nasty. There was a requirement to use just JDBC Type 2 drivers or similar close client connections, as only these allow the hand over of the transaction context.

    i can express this in CICS'y words, but I just understood this is a limitation of the driver and a Type 4 driver is too far out in a different context to join the game.

    just my €0.01

    ------------------------------
    Roland Schock
    ARS Computer und Consulting GmbH
    ------------------------------



  • 8.  RE: CICS / DB2 transactions Docs

    Posted Nov 12, 2021 04:15 AM

    Not to digress, but possibly doing so anyway, that's an interesting comment, Roland.  Twice now, for two different projects, I've seen eejit developers write two CICS/Db2 programs; one to insert a row into a table as a kind of 'store 'n' forward' repository (Db2 trying to put MQ out of business, basically) and firing another program to process the row and, ultimately, delete it.  Or update it.  Or wot eva.  And in both cases, occasionally this 2nd program fails to find the row to process.  Basically because the 2nd program is being passed details on the row's key via some CICS storage mechanism and looking up/processing the row that way, rather than looking in the table.  I'm sure you can guess where this is going, as occasionally the 1st program hasn't committed the row before the fired 2nd program goes looking for it to update/delete – and of course can't find it.

     

    All that I understand.  But the bit I don't, and it was mentioned in passing by a CICS Sprog here which I haven't had time to follow up, is that if the two programs were in the same CICS region... it would work!  Might that be related to what Mr. Campbell (that's James, not the 'other' Mr. Campbell) said, about all CICS trans in the same region sharing/running from the same TCB?  In my case the two programs were in different CICS regions.  In my colleague's case they were also different, but his CICS Sprog said if they were in the same region it would have worked.  That can only be true if they're in the same UOW.

     

    Just trying to get my head around how one program can, in some cases, modify the uncommitted Db2 changes made by another.  And I can only see that happening if they're in the same UOW, which sharing a TCB might effectively mean.

     

    Cheers,

     

     

    Raymond

     

     






  • 9.  RE: CICS / DB2 transactions Docs

    Posted Nov 12, 2021 05:58 AM
    You do know it’s a Friday right? Are you *trying* to give me a headache???

    Roy Boxwell

    SOFTWARE ENGINEERING GmbH and SEGUS Inc.
    -Product Development-

    Vagedesstrasse 19
    40479 Dusseldorf/Germany
    Tel. +49 (0)211 96149-675
    Fax +49 (0)211 96149-32
    Email: R.Boxwell@seg.de
    Web http://www.seg.de
    Link zur Datenschutzerklärung

    Software Engineering GmbH
    Amtsgericht Düsseldorf, HRB 37894
    Geschäftsführung: Gerhard Schubert, Ulf Heinrich




  • 10.  RE: CICS / DB2 transactions Docs

    Posted Nov 12, 2021 06:09 AM

    I'll leave that to the Warsteiner, you lager lout.

     

    Think I have a Franziskaner waiting for me later...

     






  • 11.  RE: CICS / DB2 transactions Docs

    Posted Nov 12, 2021 06:35 AM
    Raymond,

    Something sounds "off" about that description from the CICS Sysprog.

    It sounds like whether or not the 2nd transaction could read uncommitted data from the 1st would depend on a lot of things...what lock ISO is set to (2nd transaction may be ISO UR, allowing it to read, or a more restrictive ISO, causing it to lock-wait until 1st commits), what the EVALUNC ZPARM is set to, whether the regions are connected to the same subsystem or different ones (local memory would contain the uncommitted changes, but a remote member may not refresh/XI until COMMIT), etc, etc...

    This could all be solved by trans 1 issuing a COMMIT before asynchronously kicking off trans 2. We can pontificate whether bad design will work...or we can design it right in the first place. :)

    I personally hate using Db2 as a messaging service. Driving all of that overhead through the RDS just to allow two processes to communicate is a waste of resources. If you're in the same region, handing the data off in a TS queue makes more sense. If not...that's what WMQ (a message handler subsystem based on a stripped-down version of the Db2 code) would be more efficient.

    We've had cases where "Trans 2" is slow to execute or stalled for some reason, and "messaging tables" that only had one or two rows suddenly accumulate tens of thousands, and the previously-determined TS scan access path suddenly becomes problematic. (the VOLATILE spec helps in these cases) You get developers, though, who know SQL/Db2, and so they use the tools they have.

    But we digress...

    For the OP, look at the DB2CONN, DB2TRAN, and DB2ENTRY settings in the CICS region to determine how the transactions are configured.

    https://www.ibm.com/docs/en/cics-ts/5.4?topic=commands-inquire-db2conn
    https://www.ibm.com/docs/en/cics-ts/5.4?topic=commands-inquire-db2entry
    https://www.ibm.com/docs/en/cics-ts/5.4?topic=commands-inquire-db2tran

    As far as "flow"...that won't be easy. You could try to understand it from the Db2 end. CICS transactions typically use a CORRID where the first 4 characters are ENTR for entry threads and POOL for pool threads...the next 4 characters are typically the Transaction ID, and the rest are a unique serial identifier...not sure if that's customizable, I thought it was a CICS standard.

    You can also look at PLANNAMEs and PACKAGEs...PLANs are associated to a transaction in CICS, whereas PACKAGEs are associated with a given module. That could at least tell you which modules are invoked in a given transaction...the flow from one to the other is more of a programmatic issue. It'd help to have access to the source, or to the people who wrote the code...but from your line of questioning I'm guessing you have neither?






    ------------------------------
    MarkWieczorkowski...
    ------------------------------