1 / 45

Advantage ™ CA-ADS ® for CA-IDMS ® Application Performance

Advantage ™ CA-ADS ® for CA-IDMS ® Application Performance. UKIUA September 22, 2004. Session Abstract.

yosefu
Download Presentation

Advantage ™ CA-ADS ® for CA-IDMS ® Application Performance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Advantage™ CA-ADS®for CA-IDMS®Application Performance UKIUA September 22, 2004

  2. Session Abstract • The Advantage™ CA-ADS® for CA-IDMS® family of tools is a powerful and fast way to create runtime applications. Efficiency and performance are important considerations. This class will discuss factors that affect runtime performance.

  3. Agenda • Advantage CA-ADS Family of Tools • Structure and Performance: The Connection • Dialog Coding Strategies • Application Levels and Extended Run-Units • Locking • System Considerations

  4. Family of Advantage CA-ADS Tools

  5. Structure and Performance • Load module size is important • Applications (see attachment) • Dialogs ( see attachment) • Maps • Limit scope of work • Reduce redundancy • Eliminate unnecessary pieces • Global records with unneeded elements • Global subschemas • Overlarge components • Dialog code that can be handled automatically (more later)

  6. Application-level Flow of Control • Application-defined functions drive control • Control via function keys or ‘Execute Next Function’ • May eliminate redundant code • Easier maintenance • Can provide dynamically-built menus • Prototyping tool • Can minimize link levels • Optional apar 86 (GS39792) for security check when using EXECUTE NEXT FUNCTION

  7. Determining the Response

  8. ‘Switching’ Application • Split very large applications into manageable pieces • Build new ‘subset’ applications • Use functional divisions • Build a new ‘Switching’ control application • Run from primary dictionary or CDMSLIB • GET SCRATCH for next task code, or use global rec • SET new dictname • LEAVE ADS NEXT TASK

  9. Map Design • Site or application standards control size: header & message formats, control key definitions, responses • Number of fields per map lead to trade-offs: data stream length, interrupts, ease of comprehension • Use Automatic Editing (whenever possible) • Use Pageable Maps (when appropriate) • Retrieval only • Manage page builds in response- reduce scratch usage

  10. SCRATCH Records • For temporary storage • Used to transfer data not in global records • Trades nucleus calls (I/O) for storage pool use • Can be put into XA storage • If amount varies greatly, can save lots of storage • Requires coding effort • Great for variable numbers of records even if accessed randomly

  11. Subschema Size • Subschema size effects storage for: • IB50, VB50 (Fixed / variable subschema block) • $*$CURCY (Currency block) • FDB (SSAN Table) • RAT (Ready Area table) • Application-specific subschemas are best

  12. Ready Area Table (RAT) • One for each dialog process application thread • Less storage impact for tailored subschemas • Area name (each area in subschema) • ‘Ready All’ flag: Ready All, Noready • Mode: Explicit, subs default, shared retrieval default • Flag shows ready mode (last command for area)

  13. Agenda • Advantage CA-ADS Family of Tools • Structure and Performance: The Connection • Dialog Coding Strategies • Application Levels and Extended Run-Units • Locking • System Considerations

  14. Dialog Standards • Use symbol table during testing, not in production • Use diagnostic tables always unless very stable • Limit dialog size to 50k whenever possible • Limit dialogs to one function (edit, calculation, update) • Minimize work record storage • Perform efficient editing • Reduce error handling code • Eliminate redundant code with common routines • Built-in functions, subroutines, Mapless dialogs • ADSA response control: Default, AGR-AID-BYTE • Efficient database access

  15. WORK Records • Tailored for each dialog • Avoids wasted buffer space • Allows for easy dialog modification • Filler should be used only if the dialog is dynamic • New dialogs should have one work record • Some work records may be shared • Global records require Filler (waste) • Hopefully very little Filler in database records

  16. Efficient Editing • Editing of operator input averages 1/3 of processing • Map edits eliminate much of this dialog edit code • Edit tables validate input • Code tables translate values • Edit modules format input/output data • Automatic editing sets error flags, attributes, messages • Dialog code: relational edits (map / dialog fields) • Execute On Edit Error • Allows edit of multiple fields • Easy for user, code must check IN ERROR • Dialog editing is more flexible, more expensive

  17. Checking ERROR-STATUS • Use AUTOSTATUS to limit error statuses returned • Use ALLOWING for specific error statuses • Modify the status definition record to group statuses as needed. (level-88 for range of values) • AUTOSTATUS=NO means that dialog code must check for all statuses that a particular process command can return

  18. AUTOSTATUS Example

  19. Eliminate Redundant Code • Subroutines • If code is used more than 2 - 3 times in process • Names limited to eight characters, start with 2-digit ascending number for easier maintenance. • Include Modules • Write standard routines included in multiple dialogs • CA-supplied or user-written BIFs • Eliminate and centralize redundant or complex code. • Dates (Today, tomorrow, CGDATE, etc.) • Arithmetic (Abs value, invert sign, trig, etc.) • String (Concat, Substr, Replace, etc.) • User-written

  20. Database Access • Largest impact on response time • Test navigation: Advantage™ CA-OLQ® Online Query for CA-IDMS®, Advantage™ CA-IDMS® Database DML Online Option, OCF • Avoid area sweeps, totaling, walking long sets • Use batch jobs for long or inefficient access • Physical database tuning important • Maintain indexes: orphans, sizing • Monitor statistics: reduce calc/via overflows, buffers • Avoid OOAK records that own high activity sets

  21. Agenda • Advantage CA-ADS Family of Tools • Structure and Performance: The Connection • Dialog Coding Strategies • Application Levels and Extended Run-Units • Locking • System Considerations

  22. Application Thread • List of operative dialogs at a given moment during execution • A dialog becomes operative when it receives processing control • A function or dialog becomes non-operative when it passes control to a higher level-function or dialog (including a copy of itself) • All functions and dialogs become non-operative when control passes out of the application

  23. Application Levels • Top level established by first function or dialog • Some commands establish lower levels • Invoke • Link • SYSGEN default is ten level maximum • Attempt to exceed maximum causes abend • Link levels take up additional concurrent storage • Multiple link levels can be very difficult to debug • Multiple levels can cause waits and deadlocks

  24. TRANSFER Command

  25. Invoke/Return Command

  26. Link/Return Command LINK

  27. Extended Run-Units • Link to dialog (premap) with no subschema • Link to dialog (premap) with identical schema & subschema • Link to user program • If RATs show equal or less restrictive usage (for each area), then extend • Potential for waits / deadlocks • May reduce storage, no subschema duplication

  28. Extended Run-Unit Implications • Currencies passed to lower level dialog, restored on return • Currencies possibly passed to user programs • Record locks in upper-level dialog not released • If lower-level program opens transaction, deadlock possible. Avoid deadlock by • Issue Commit prior to Link (can’t rollback) • Pass Subschema-ctrl to user program, issue no Bind or Finish in user program

  29. LINK NOSAVE • NOSAVE is faster than save/restore • Can be used in a Retrieval Nolock dialog to LINK to an update dialog • Currencies from before the link are not saved • Currencies on return from Link Nosave • If run-unit is extended, currencies are ‘passed upward’ • Else, currencies are initialized

  30. Agenda • Advantage CA-ADS Family of Tools • Structure and Performance: The Connection • Dialog Coding Strategies • Application Levels and Extended Run-Units • Locking • System Considerations

  31. Usage Mode Restrictions

  32. RETRIEVAL NOLOCK Option • Allowed by parameter on the SYSTEM statement • Effective for dialogs with no database update • All subs areas readied for retrieval, in all processes • Implemented by dialog • Dialog Options screen in ADSC • Specify RETRIEVAL LOCK: NO • Saves storage for locking control • Improves performance • May result in ‘dirty reads’

  33. Locking Within the Run-Unit • Set locks explicitly for the duration of R-U • KEEP command or keyword (shared lock) • KEEP EXCLUSIVE (exclusive lock) • Locks set implicitly by ready mode & DML • Subschema default for area • Default: shared retrieval • Area locks (NL, IS, IX, S, U, UIX, X, XR) • Row locks • Shared (upon read) enable retrieval, not update • EXclusive (upon update) prevents other access • Area S (protected retrieval) = S lock on every record • Area X (exclusive) = X lock on every row

  34. Locking Across Run-Units • Keep Longterm (Notify) Lock-options • Can be used for single-threading • Two common uses during a pseudo-converse • Gain exclusive control of a frequently updated record • Monitor updates to sometimes-updated records • Keep Longterm <longterm-id> RELEASE • If lock already released, error status 1521 is returned • Releases all long-term locks attached to lterm • Does not return a non-zero error status if no locks held • Consider using Notify • Create a work field to hold the notification • Test against the notification field • Code example in attachment

  35. Premap Process: KEEP LONGTERM LOCK-ID EXCLUSIVE CUSTOMER. DISPLAY. Response Process: MODIFY CUSTOMER. KEEP LONGTERM LOCK-ID RELEASE. DISPLAY MSG TEXT ‘Customer Modified’. Prevent Access From Other Terminals

  36. KEEP LONGTERM Considerations • Lock is attached to the logical terminal (LTERM) • NOT released by COMMIT • Release often forgotten • when the user signs off • via DCMT V LTERM <ltermid> RESOURCE DELETE. • Managed by lock ID • A 1-16-character constant in single quotation marks • A 1-16 byte variable field containing the lock ID • Must be unique for the record type

  37. Handling Deadlocks • Avoid by single threading • OBTAIN KEEP • LINK TO PROGRAM ‘ENQUEUE’ • Control record update dialog • Copy to Queue • Avoid by using Notify Locks • Recover from them with automatic recovery • ALLOWING (‘0329’) • FIND CURRENT ALLOWING (‘0329’) on control commands • Notify Operator and/or DBA

  38. Minimize Locking Problems • Database tuning (page size, area size, indexes) • Use least exclusive usage mode necessary • Small transactions (recovery unit of work) • Efficient dialogs (testing) • No conversational programming • No locks held across pseudo-converse

  39. Agenda • Advantage CA-ADS Family of Tools • Structure and Performance: The Connection • Dialog Coding Strategies • Application Levels and Extended Run-Units • Locking • System Considerations

  40. Sysgen Recommendations (GI76847) • ADSO statement parms • Activity Log is NO • Dialog Statistics OFF • Fast Mode Threshold is OFF • Record Compression is OFF • Resources are Fixed • Storage Mode is Calculated • Maximum Links (10) • Newpage Mapout No (no literals) • System statement parms • Retrieval Nolock • Scratch in XA is YES • Reentrant pool sizes

  41. Reentrant Program Pools • Many uses with Advantage CA-ADS: • ADSOMAIN (built-in functions) • TAT (Task ApplicationTable) • Application Load Module • Dialog Load Module • Map (Tables, Edit Modules) • Subschema, Access Module • XA Reentrant pool between 6000K and 12000K

  42. Release 15.0 and Late Compilers • ADSOBCOM will not compile a Checked out dialog • QO33088 disables this (with OPT000235) • RHDCMAP1 will not change a Checked out map • QO35104 disables this (with OPT000235) • Optionally, the online compilers will not release an entity that has been changed but not compiled • ADSA, ADSC, and MAPC • OPT000212

  43. Agenda • Advantage CA-ADS Family of Tools • Structure and Performance: The Connection • Dialog Coding Strategies • Application Levels and Extended Run-Units • Locking • System Considerations

  44. Session Summary • Smaller is faster: map, subschema, dialog, application • Tailor when possible: subschema, work records • Share when possible: reduce redundancies • Automate as a rule: map edits, autostatus, application-level function control • Database tuning imperative • Consider locking during design and testing • No strict coding rules, maximize trade-offs • Consider efficiency during design and coding • The Advantage™ CA-IDMS®/DC Transaction Server Option environment • The business in which an application runs

  45. Questions & Answers

More Related