IDMS

 View Only
  • 1.  ADSA vs. Dialog controled navigation

    Posted Dec 12, 2013 05:09 PM

    A group of us have developed a series of new dialogs with one overriding ADSA module.  Our DBA has expressed concern that some of the dialogs are transferring to other dialogs by using explicit transfer commands (i.e. TRANSFER 'other dialog') and some are using ADSA (MOVE 'blahblah' to AGR-CURRENT-RESPONSE.  EXEC NEXT FUNCTION).  I would prefer that we use ADSA in order to not 'lose ourselves' in some of these transfers. We also have situations where dialog-A will LINK NOSAVE to dialog-B where both dialog-A and dialog-B have 'hot keys' to TRANSFER to Dialog-C (which can potentially TRANSFER back to dialog-A but not dialog-B).

    Should we concern ourselves with this mix of TRANSFER 'protocols'?  Are there excessive system overhead issues with one type over the other?



  • 2.  RE: ADSA vs. Dialog controled navigation

    Posted Dec 12, 2013 05:11 PM

    Sorry, that should have been 'He would prefer, not 'I would prefer'



  • 3.  RE: ADSA vs. Dialog controled navigation
    Best Answer

    Posted Dec 12, 2013 05:35 PM

    Strictly my opinion - but I would vote for do it one way or the other - but do not use "mixed mode" (so to speak) of ADSA responses in one place and hard coded transfers elsewhere.

    The point is that if in all cases you use ADSA responses to define which function:dialog you end up at - then everybody knows for an absolute fact that changing ADSA will change the result! And you can make all navigation changes at the ADSA level without changing dialog code!

    If some dialogs use ADSA for navigation and other have hard coded "transfer to dialog name" - then you don't know what the result of an ADSA change will be. While you may expect that navigation will have changed - if there is even one hard coded transfer to dialog statement - then all bets are off.

    What I would be most concerned about is that you guarantee that there is a RETURN after the LINK. If there is no RETURN executed (either hard coded or through ADSA structure) then you will have moved the entire "transfer structure" down one run-time level - which has (CPU) performance implications in terms of implicit database currency save/restore which is performed by ADS run-time system.

    I have seen cases where "max application levels exceeded" eventually happening after "one LINK too many" - and there being a devil of a time to work out the problem. Meanwhile huge amounts of CPU were being consumed for the implicit overheads of running  a "flat" application structure several levels deeper than anticipated. When the RETURN was put in place lots of things worked better!

    HTH - cheers - GaryC



  • 4.  RE: ADSA vs. Dialog controled navigation

    Posted Dec 12, 2013 05:57 PM

    Gary's right, (more than just his opinion) don't play around mixing modes (unless you're really an ADS expert and you can guarentee that where you go, you'll come back to before ADSA takes back over and you can guarentee anyone in the future will be as careful)

    I've also seen the application level problem when people mix ADSA with explicit dialog transfers and links.  I've also seen applications shoot off into a totally unexpected place because of mixing ADSA with dialog controls and somewhere a dialog issues an EXECUTE NEXT FUNCTION.

    Play it safe, use ADSA



  • 5.  RE: [Application Developer Issues] RE: ADSA vs. Dialog controlled navigatio

    Posted Dec 12, 2013 07:39 PM
    Even if YOU are an ADS expert, the next poor soul to work on this application may not be – I say go one way or another I’m gonna code ya I’m gonna code ya code ya code ya code ya one way or an … oops sorry – was having a Blondie moment ……

    Chris hoelscher
    Technology Architect | Database Infrastructure Services
    Technology Solution Services
    [Description: Description: cid:image001.png@01CD13D7.1A57CAF0]
    123 East Main Street |Louisville, KY 40202
    choelscher@humana.com
    Humana.com
    (502) 476-2538 – office
    (502) 714-8615 - blackberry
    Keeping CAS and Metavance safe for all HUMANAty

    From: CA IDMS IUA EIUA Global User CommunityMessage Boards [mailto:CommunityAdmin@communities-mail.ca.com]
    Sent: Thursday, December 12, 2013 5:57 PM
    To: mb_message.15281477.106200526@myca-email.ca.com
    Subject: [Application Developer Issues] RE: ADSA vs. Dialog controled navigation


    Gary's right, (more than just his opinion) don't play around mixing modes (unless you're really an ADS expert and you can guarentee that where you go, you'll come back to before ADSA takes back over and you can guarentee anyone in the future will be as careful)

    I've also seen the application level problem when people mix ADSA with explicit dialog transfers and links. I've also seen applications shoot off into a totally unexpected place because of mixing ADSA with dialog controls and somewhere a dialog issues an EXECUTE NEXT FUNCTION.

    Play it safe, use ADSA
    Posted by:lindajcasey
    --
    CA Communities Message Boards
    106203066
    mb_message.15281477.106200526@myca-email.ca.com<mailto:mb_message.15281477.106200526@myca-email.ca.com>
    https://communities.ca.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.


  • 6.  RE: [Application Developer Issues] RE: ADSA vs. Dialog controlled navigatio

    Posted Dec 13, 2013 09:12 AM

    Thank you all for your insights (and the song).  Excellent catch Gary with our (now obvious) design flaw (transfer from a linked-to dialog and back to the linked-from dialog) which would not only incur excessive resource usage but eventually bust through the max link level limit.  Will review code to use ADSA for all navigation.