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

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