1 / 40

COMMITMENT CONTROL IN ADVANTAGE PLEX for DB2/400

EDGE EMEA Conference - 2002. COMMITMENT CONTROL IN ADVANTAGE PLEX for DB2/400. Yolanda Scholtz 18 November 2002 Session - 4E 15:15 - 16:00. Agenda. Overview Setting Up Commitment Control for DB2/400 Across Advantage Plex and Advantage 2E Switching Commitment Control On or Off

camilla-doyle
Download Presentation

COMMITMENT CONTROL IN ADVANTAGE PLEX for DB2/400

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. EDGE EMEA Conference - 2002 COMMITMENT CONTROL IN ADVANTAGE PLEX for DB2/400 Yolanda Scholtz 18 November 2002 Session - 4E 15:15 - 16:00

  2. Agenda • Overview • Setting Up Commitment Control for DB2/400 • Across Advantage Plex and Advantage 2E • Switching Commitment Control On or Off • Considerations • Commitment Control Errors • Additional Notes • Questions

  3. Need & Benefits • Operations to run optimally • Reliable data within Information Systems • Improving / ensuring data integrity • Reduce time spent on correcting data

  4. Definition • Commitment Control is a database facility that enables a group of database changes to be treated as a single transaction, regardless of the files being changed. Thus you can ensure that either ALL or NONE of the changes are performed.

  5. Illustration Parent Updates Calls Child 2 Child 1 Commit Changes Updates Updates ERROR

  6. Illustration Parent Updates Calls Child 2 Child 1 Rollback Occurred Updates Updates

  7. Setting up Commitment Control Commitment Control Parent Commit / Rollback Child 1 Child 2 Child 3

  8. Setting up Commitment Control • Setting Up Commitment Control for DB2/400 • Framework • Implementation • Logic in the Patterns • Commitment Control Functions • Inheritance • Development Standards • Business Functions

  9. Framework • Commit Group • Parent • Child • None • Commit / Rollback • Journal OS/400 Physical Files

  10. Commit Group • A Commit Group is a group of one or more data access functions within which all database changes are treated as a single transaction. • Define a commit group using the triple FNC Commit SYS verb None Parent Child

  11. None FNC Commit SYS None None is the default value if no commit property is specified. It means that the function will not be part of a commit group. Commit groups should be specified only where they are necessary, otherwise they serve only to decrease the performance of the function.

  12. Parent FNC Commit SYS Parent This server function belongs to a commit group and will be generated with the code that starts commitment control (unless another parent in the commit group has already started it). A Commit group must have at lease one parent.

  13. Child FNC Commit SYS Child This server function belongs to a commit group. A commit group can have one, many, or no child functions.

  14. Commit / Rollback • Commit and Rollback statements in action diagram • If not, the results will be unpredictable - any database changes will remain uncommitted until another program executes a commit or rollback operation.

  15. Journal Physical Files • Ensure that the OS/400 physical files being updated are being journalled. • For information on journal management, refer to the AS/400 Advanced Backup and Recovery Guide.

  16. Implementation • Pattern • Function Shell • Functions • Commit Start • Commit End • Inheritance • Business functions

  17. Pattern • Function Shell changes : • Local Variable and fields • Commitment • Control Status • Control On • Meta coding to interrogate triples of functions to determine if Commitment Control is required • Initialise • Terminate • Go SubCommit • Additional Subroutine(Commit) • Rollback message

  18. FunctionShell Model Editor

  19. FunctionShell Action Diagram - Initialise

  20. FunctionShell Action Diagram - Subroutine Commit

  21. Commit Start Purpose: To ensure that STRCMTCTL command is executed (this is done automatically due to triple commit SYS parent) Coding: None

  22. Commit Start Model Editor

  23. Commit End • Purpose: • To ensure that ENDCMTCTL command is executed (this is done automatically due to triple commit SYS parent) • To execute COMIT / ROLLBACK statement. (This is done exclusively in program)

  24. Commit End Model Editor Action Diagram

  25. Inheritance • The FunctionShell is inherited by ALL functions • Commit function inherits from main function • Data Access function Commit - • auto created in model through inheritance • scoped to data access function

  26. Development Standards • Naming Convention • MyEntity.MyFunction Commit • Syntax • Model Editor • Action Diagram

  27. Model Editor MyFunction comprises MyFunction Commit MyFunction Commit is a MyFunction MyFunction Commit Commit Sys Child

  28. Action Diagram Condition calls to functions Coding may be copied to the desired place in the action diagram where a function call is done.

  29. Development Standards • BENEFITS of Common Sequence • Remove monotony of coding the conditional call construct • Eliminate errors in coding the conditional call construct • To ensure standardization

  30. Action Diagram Additional Notes • Process Group • Set returning status (as it is always normal) • Control Commit / Rollback • via Commit Subroutine • Commit Subroutine always in Terminate

  31. Across Advantage Plex and 2E • Either function (Plex or 2E) may contain the main commit point • Both Plex and 2E functions may be specified as Child/Slave within the same Commit Group • Only one Parent/Master may be defined

  32. Across Advantage Plex and 2E

  33. On / Off Switch As easy as 1... Set Triple COMMIT SYS (parent / none) 2... Gen & Build this main function 3... Start / End Journalling on affected OS/400 files

  34. Considerations • Performance • Replace default data access functions • In EDITDETAIL, EDITDIALOG, ect. • Make function a Parent or Child • Undefine the deleterow • Replace with conditional coding Reason: the default deleterow is automatically called in these functions (inheritance).

  35. Considerations • If Client is parent • set Panel Properties<Window Type>=dialog • to prevent another MDI child being executed simultaneously • test returned status and set returning status • To ensure that rollback occurs if data access fails • Call Commit Start in initialization section • STRCMTCTL auto executed if server parent • Call Commit End for Commit / Rollback • auto executed if server parent

  36. Considerations • Implementation timing • During vs After Development • Identification of Business Functions • Journal OS/400 Physical Files • Development effort • Test entire system • Room for Error • Impact on system maintenance and support • Model Administration • Integration impact

  37. Commitment Control Errors • unexpected Return Code = 01217. • Member EntityPF not journaled to journal *N • Function check. CPF8351 unmonitored by FTN0001S at statement 845, instruction X'0179’. • Commitment control already active.

  38. Additional Notes • Can retrieve data from file during process • Can update same record twice • Cannot make changes to record externally • Terminate only executed on close • Commit desired business function, row or grid • Files may be journalled and updated by functions NOT under commitment control • If the function is under commitment control the files being referenced for update MUST be journalled

  39. Questions

  40. Questions

More Related