MIMIX+Reference

Version 6.0 MIMIX ha1™ and MIMIX ha Lite™ for IBM® i MIMIX Reference Published: March 2009 level: 6.0.06.00 Copyrights, Trademarks, and Notices Product conventions.................................................................................................. 16 Menus and commands ........................................................................................ 16 Accessing online help.......................................................................................... 16 Publication conventions............................................................................................. 16 Formatting for displays and commands .............................................................. 17 Sources for additional information............................................................................. 18 How to contact us...................................................................................................... 19 Chapter 1 MIMIX overview 21 MIMIX concepts......................................................................................................... 23 System roles and relationships ........................................................................... 23 Data groups: the unit of replication...................................................................... 24 Changing directions: switchable data groups ...................................................... 24 Additional switching capability ....................................................................... 25 Journaling and object auditing introduction ......................................................... 25 Log spaces .......................................................................................................... 26 Multi-part naming convention .............................................................................. 27 The MIMIX environment ............................................................................................ 29 The product library .............................................................................................. 29 IFS directories ............................................................................................... 29 Job descriptions and job classes......................................................................... 30 User profiles .................................................................................................. 32 The system manager........................................................................................... 32 The journal manager ........................................................................................... 33 The MIMIXQGPL library ...................................................................................... 34 MIMIXSBS subsystem................................................................................... 34 Data libraries ....................................................................................................... 34 Named definitions................................................................................................ 35 Data group entries ............................................................................................... 35 Journal receiver management................................................................................... 37 Interaction with other products that manage receivers........................................ 38 Processing from an earlier journal receiver ......................................................... 38 Considerations when journaling on target ........................................................... 39 Operational overview................................................................................................. 40 Support for starting and ending replication.......................................................... 40 Support for checking installation status ............................................................... 41 Support for automatically detecting and resolving problems ............................... 41 Support for working with data groups .................................................................. 41 Support for resolving problems ........................................................................... 42 Support for switching a data group...................................................................... 44 Support for working with messages .................................................................... 45 Replication process overview 46 Replication job and supporting job names ................................................................ 47 Cooperative processing introduction ......................................................................... 49 MIMIX Dynamic Apply ......................................................................................... 49 Legacy cooperative processing ........................................................................... 50 Advanced journaling ............................................................................................ 50 System journal replication ......................................................................................... 51 Processing self-contained activity entries ........................................................... 52 Chapter 2 2 Processing data-retrieval activity entries ............................................................. 53 Processes with multiple jobs ............................................................................... 55 Tracking object replication................................................................................... 55 Managing object auditing .................................................................................... 55 User journal replication.............................................................................................. 58 What is remote journaling?.................................................................................. 58 Benefits of using remote journaling with MIMIX .................................................. 58 Restrictions of MIMIX Remote Journal support ................................................... 59 Overview of IBM processing of remote journals .................................................. 60 Synchronous delivery .................................................................................... 60 Asynchronous delivery .................................................................................. 62 User journal replication processes ...................................................................... 63 The RJ link .......................................................................................................... 63 Sharing RJ links among data groups............................................................. 63 RJ links within and independently of data groups ......................................... 64 Differences between ENDDG and ENDRJLNK commands .......................... 64 RJ link monitors ................................................................................................... 65 RJ link monitors - operation........................................................................... 65 RJ link monitors in complex configurations ................................................... 65 Support for unconfirmed entries during a switch ................................................. 67 RJ link considerations when switching ................................................................ 67 User journal replication of IFS objects, data areas, data queues.............................. 69 Benefits of advanced journaling .......................................................................... 69 Replication processes used by advanced journaling .......................................... 70 Tracking entries ................................................................................................... 71 IFS object file identifiers (FIDs) ........................................................................... 72 Lesser-used processes for user journal replication................................................... 73 User journal replication with source-send processing ......................................... 73 The data area polling process ............................................................................. 74 Chapter 3 Preparing for MIMIX 76 Checklist: pre-configuration....................................................................................... 77 Data that should not be replicated............................................................................. 78 Planning for journaled IFS objects, data areas, and data queues............................. 79 Is user journal replication appropriate for your environment? ............................. 79 Serialized transactions with database files.......................................................... 79 Converting existing data groups .......................................................................... 79 Conversion examples .................................................................................... 80 Database apply session balancing ...................................................................... 81 User exit program considerations........................................................................ 81 Starting the MIMIXSBS subsystem ........................................................................... 83 Accessing the MIMIX Main Menu.............................................................................. 84 Planning choices and details by object class 86 Replication choices by object type ............................................................................ 88 Configured object auditing value for data group entries............................................ 89 Identifying library-based objects for replication ......................................................... 91 How MIMIX uses object entries to evaluate journal entries for replication .......... 92 Identifying spooled files for replication ................................................................ 93 Additional choices for spooled file replication................................................ 94 Chapter 4 3 Replicating user profiles and associated message queues ................................ 95 Identifying logical and physical files for replication.................................................... 96 Considerations for LF and PF files ...................................................................... 96 Files with LOBs.............................................................................................. 98 Configuration requirements for LF and PF files................................................... 99 Requirements and limitations of MIMIX Dynamic Apply.................................... 101 Requirements and limitations of legacy cooperative processing....................... 102 Identifying data areas and data queues for replication............................................ 103 Configuration requirements - data areas and data queues ............................... 103 Restrictions - user journal replication of data areas and data queues .............. 104 Identifying IFS objects for replication ...................................................................... 106 Supported IFS file systems and object types .................................................... 106 Considerations when identifying IFS objects..................................................... 107 MIMIX processing order for data group IFS entries..................................... 107 Long IFS path names .................................................................................. 107 Upper and lower case IFS object names..................................................... 107 Configured object auditing value for IFS objects ......................................... 108 Configuration requirements - IFS objects .......................................................... 108 Restrictions - user journal replication of IFS objects ......................................... 109 Identifying DLOs for replication ............................................................................... 111 How MIMIX uses DLO entries to evaluate journal entries for replication .......... 111 Sequence and priority order for documents ................................................ 111 Sequence and priority order for folders ....................................................... 112 Processing of newly created files and objects......................................................... 114 Newly created files ............................................................................................ 114 New file processing - MIMIX Dynamic Apply............................................... 114 New file processing - legacy cooperative processing.................................. 115 Newly created IFS objects, data areas, and data queues ................................. 115 Determining how an activity entry for a create operation was replicated .... 116 Processing variations for common operations ........................................................ 117 Move/rename operations - system journal replication ....................................... 117 Move/rename operations - user journaled data areas, data queues, IFS objects ... 118 Delete operations - files configured for legacy cooperative processing ............ 121 Delete operations - user journaled data areas, data queues, IFS objects ........ 121 Restore operations - user journaled data areas, data queues, IFS objects ...... 121 Chapter 5 Configuration checklists 123 Checklist: New remote journal (preferred) configuration ......................................... 125 Checklist: New MIMIX source-send configuration................................................... 128 Checklist: Converting to remote journaling.............................................................. 131 Converting to MIMIX Dynamic Apply....................................................................... 133 Converting using the Convert Data Group command ....................................... 133 Checklist: manually converting to MIMIX Dynamic Apply.................................. 134 Checklist: Change *DTAARA, *DTAQ, IFS objects to user journaling .................... 136 Checklist: Converting to legacy cooperative processing ......................................... 138 System-level communications 140 Configuring for native TCP/IP.................................................................................. 140 Port aliases-simple example ............................................................................. 141 Chapter 6 4 Port aliases-complex example .......................................................................... 142 Creating port aliases ......................................................................................... 143 Configuring APPC/SNA........................................................................................... 144 Configuring OptiConnect ......................................................................................... 144 Chapter 7 Configuring system definitions 146 Tips for system definition parameters ..................................................................... 147 Creating system definitions ..................................................................................... 150 Changing a system definition .................................................................................. 151 Multiple network system considerations.................................................................. 152 Configuring transfer definitions 154 Tips for transfer definition parameters..................................................................... 156 Using contextual (*ANY) transfer definitions ........................................................... 160 Search and selection process ........................................................................... 160 Considerations for remote journaling ................................................................ 161 Considerations for MIMIX source-send configurations...................................... 161 Naming conventions for contextual transfer definitions ..................................... 162 Additional usage considerations for contextual transfer definitions................... 162 Creating a transfer definition ................................................................................... 163 Changing a transfer definition ................................................................................. 165 Changing a transfer definition to support remote journaling.............................. 165 Finding the system database name for RDB directory entries ................................ 167 Using IBM i commands to work with RDB directory entries .............................. 167 Starting the TCP/IP server ...................................................................................... 168 Using autostart job entries to start the TCP server ................................................. 169 Identifying the current autostart job entry information ....................................... 169 Changing an autostart job entry and its related job description ........................ 169 Using a different job description for an autostart job entry .......................... 170 Updating host information for a user-managed autostart job entry ............. 170 Updating port information for a user-managed autostart job entry .............. 171 Verifying a communications link for system definitions ........................................... 173 Verifying the communications link for a data group................................................. 174 Verifying all communications links..................................................................... 174 Configuring journal definitions 176 Journal definitions created by other processes ....................................................... 178 Tips for journal definition parameters ...................................................................... 179 Journal definition considerations ............................................................................. 184 Naming convention for remote journaling environments with 2 systems........... 185 Example journal definitions for a switchable data group ............................. 185 Naming convention for multimanagement environments .................................. 187 Example journal definitions for three management nodes .......................... 188 Journal receiver size for replicating large object data ............................................. 191 Verifying journal receiver size options .............................................................. 191 Changing journal receiver size options ............................................................. 191 Creating a journal definition..................................................................................... 192 Changing a journal definition................................................................................... 194 Building the journaling environment ........................................................................ 195 Changing the journaling environment to use *MAXOPT3 ....................................... 196 Changing the remote journal environment .............................................................. 200 Chapter 8 Chapter 9 5 Adding a remote journal link.................................................................................... 202 Changing a remote journal link................................................................................ 204 Temporarily changing from RJ to MIMIX processing .............................................. 205 Changing from remote journaling to MIMIX processing .......................................... 206 Removing a remote journaling environment............................................................ 207 Chapter 10 Configuring data group definitions 209 Tips for data group parameters ............................................................................... 210 Additional considerations for data groups ......................................................... 220 Creating a data group definition .............................................................................. 221 Changing a data group definition ............................................................................ 225 Fine-tuning backlog warning thresholds for a data group ....................................... 225 Additional options: working with definitions 229 Copying a definition................................................................................................. 229 Deleting a definition................................................................................................. 230 Displaying a definition ............................................................................................. 231 Printing a definition.................................................................................................. 232 Renaming definitions............................................................................................... 232 Renaming a system definition ........................................................................... 232 Renaming a transfer definition .......................................................................... 235 Renaming a journal definition with considerations for RJ link ........................... 236 Renaming a data group definition ..................................................................... 237 Swapping system definition names ......................................................................... 238 Configuring data group entries 241 Creating data group object entries .......................................................................... 242 Loading data group object entries ..................................................................... 242 Adding or changing a data group object entry................................................... 243 Creating data group file entries ............................................................................... 246 Loading file entries ............................................................................................ 246 Loading file entries from a data group’s object entries ................................ 247 Loading file entries from a library ................................................................ 249 Loading file entries from a journal definition ................................................ 250 Loading file entries from another data group’s file entries........................... 251 Adding a data group file entry ........................................................................... 252 Changing a data group file entry ....................................................................... 253 Creating data group IFS entries .............................................................................. 255 Adding or changing a data group IFS entry....................................................... 255 Loading tracking entries .......................................................................................... 257 Loading IFS tracking entries.............................................................................. 257 Loading object tracking entries.......................................................................... 258 Creating data group DLO entries ............................................................................ 259 Loading DLO entries from a folder .................................................................... 259 Adding or changing a data group DLO entry ..................................................... 260 Creating data group data area entries..................................................................... 261 Loading data area entries for a library............................................................... 261 Adding or changing a data group data area entry ............................................. 262 Additional options: working with DG entries ............................................................ 263 Copying a data group entry ............................................................................... 263 Removing a data group entry ............................................................................ 264 Chapter 11 Chapter 12 6 Displaying a data group entry............................................................................ 265 Printing a data group entry ................................................................................ 265 Chapter 13 Additional supporting tasks for configuration 266 Accessing the Configuration Menu.......................................................................... 268 Starting the system and journal managers.............................................................. 269 Setting data group auditing values manually........................................................... 270 Examples of changing of an IFS object’s auditing value ................................... 271 Checking file entry configuration manually.............................................................. 276 Changes to startup programs.................................................................................. 278 Starting the DDM TCP/IP server ............................................................................. 279 Verifying that the DDM TCP/IP server is running .............................................. 279 Checking DDM password validation level in use..................................................... 280 Option 1. Enable MIMIXOWN user profile for DDM environment...................... 280 Option 2. Allow user profiles without passwords ............................................... 281 Starting data groups for the first time ...................................................................... 282 Identifying data groups that use an RJ link ............................................................. 283 Using file identifiers (FIDs) for IFS objects .............................................................. 284 Configuring restart times for MIMIX jobs ................................................................. 285 Configurable job restart time operation ............................................................. 285 Considerations for using *NONE ................................................................. 287 Examples: job restart time ................................................................................. 287 Restart time examples: system definitions .................................................. 288 Restart time examples: system and data group definition combinations..... 288 Configuring the restart time in a system definition ............................................ 291 Configuring the restart time in a data group definition....................................... 291 Starting, ending, and verifying journaling 293 What objects need to be journaled.......................................................................... 294 Authority requirements for starting journaling.................................................... 295 MIMIX commands for starting journaling................................................................. 296 Journaling for physical files ..................................................................................... 297 Displaying journaling status for physical files .................................................... 297 Starting journaling for physical files ................................................................... 297 Ending journaling for physical files .................................................................... 298 Verifying journaling for physical files ................................................................. 299 Journaling for IFS objects........................................................................................ 300 Displaying journaling status for IFS objects ...................................................... 300 Starting journaling for IFS objects ..................................................................... 300 Ending journaling for IFS objects ...................................................................... 301 Verifying journaling for IFS objects.................................................................... 302 Journaling for data areas and data queues............................................................. 303 Displaying journaling status for data areas and data queues............................ 303 Starting journaling for data areas and data queues .......................................... 303 Ending journaling for data areas and data queues............................................ 304 Verifying journaling for data areas and data queues ......................................... 305 Configuring for improved performance 306 Minimized journal entry data ................................................................................... 307 Restrictions of minimized journal entry data...................................................... 307 Configuring for minimized journal entry data ..................................................... 308 Chapter 14 Chapter 15 7 Configuring for high availability journal performance enhancements...................... 309 Journal standby state ........................................................................................ 309 Minimizing potential performance impacts of standby state ........................ 310 Journal caching ................................................................................................. 310 MIMIX processing of high availability journal performance enhancements....... 310 Requirements of high availability journal performance enhancements ............. 311 Restrictions of high availability journal performance enhancements................. 311 Caching extended attributes of *FILE objects ......................................................... 313 Increasing data returned in journal entry blocks by delaying RCVJRNE calls ........ 314 Understanding the data area format.................................................................. 314 Determining if the data area should be changed............................................... 315 Configuring the RCVJRNE call delay and block values .................................... 315 Configuring high volume objects for better performance......................................... 317 Improving performance of the #MBRRCDCNT audit .............................................. 318 Chapter 16 Configuring advanced replication techniques 320 Keyed replication..................................................................................................... 322 Keyed vs positional replication .......................................................................... 322 Requirements for keyed replication ................................................................... 322 Restrictions of keyed replication........................................................................ 323 Implementing keyed replication ......................................................................... 323 Changing a data group configuration to use keyed replication.................... 323 Changing a data group file entry to use keyed replication........................... 324 Verifying key attributes ...................................................................................... 326 Data distribution and data management scenarios ................................................. 327 Configuring for bi-directional flow ...................................................................... 327 Bi-directional requirements: system journal replication ............................... 327 Bi-directional requirements: user journal replication.................................... 328 Configuring for file routing and file combining ................................................... 329 Configuring for cascading distributions ............................................................. 331 Trigger support ........................................................................................................ 334 How MIMIX handles triggers ............................................................................. 334 Considerations when using triggers .................................................................. 334 Enabling trigger support .................................................................................... 335 Synchronizing files with triggers ........................................................................ 335 Constraint support ................................................................................................... 336 Referential constraints with delete rules............................................................ 336 Replication of constraint-induced modifications .......................................... 337 Handling SQL identity columns ............................................................................... 338 The identity column problem explained ............................................................. 338 When the SETIDCOLA command is useful....................................................... 339 SETIDCOLA command limitations .................................................................... 339 Alternative solutions .......................................................................................... 340 SETIDCOLA command details .......................................................................... 341 Usage notes ................................................................................................ 342 Examples of choosing a value for INCREMENTS....................................... 342 Checking for replication of tables with identity columns .................................... 343 Setting the identity column attribute for replicated files ..................................... 343 Collision resolution .................................................................................................. 345 Additional methods available with CR classes .................................................. 345 8 Requirements for using collision resolution ....................................................... 346 Working with collision resolution classes .......................................................... 347 Creating a collision resolution class ............................................................ 347 Changing a collision resolution class........................................................... 348 Deleting a collision resolution class............................................................. 348 Displaying a collision resolution class ......................................................... 348 Printing a collision resolution class.............................................................. 349 Omitting T-ZC content from system journal replication ........................................... 350 Configuration requirements and considerations for omitting T-ZC content ....... 351 Omit content (OMTDTA) and cooperative processing................................. 352 Omit content (OMTDTA) and comparison commands ................................ 352 Selecting an object retrieval delay........................................................................... 354 Object retrieval delay considerations and examples ......................................... 354 Configuring to replicate SQL stored procedures and user-defined functions.......... 356 Requirements for replicating SQL stored procedure operations ....................... 356 To replicate SQL stored procedure operations ................................................. 357 Using Save-While-Active in MIMIX.......................................................................... 358 Considerations for save-while-active................................................................. 358 Types of save-while-active options ................................................................... 359 Example configurations ..................................................................................... 359 Chapter 17 Object selection for Compare and Synchronize commands 360 Object selection process ......................................................................................... 360 Order precedence ............................................................................................. 362 Parameters for specifying object selectors.............................................................. 363 Object selection examples ...................................................................................... 368 Processing example with a data group and an object selection parameter ...... 368 Example subtree ............................................................................................... 371 Example Name pattern...................................................................................... 375 Example subtree for IFS objects ....................................................................... 376 Report types and output formats ............................................................................. 378 Spooled files ...................................................................................................... 378 Outfiles .............................................................................................................. 379 Comparing attributes 380 About the Compare Attributes commands .............................................................. 380 Choices for selecting objects to compare.......................................................... 381 Unique parameters ...................................................................................... 381 Choices for selecting attributes to compare ...................................................... 382 CMPFILA supported object attributes for *FILE objects .............................. 383 CMPOBJA supported object attributes for *FILE objects ............................ 383 Comparing file and member attributes .................................................................... 384 Comparing object attributes .................................................................................... 387 Comparing IFS object attributes.............................................................................. 390 Comparing DLO attributes....................................................................................... 393 Comparing file record counts and file member data 396 Comparing file record counts .................................................................................. 396 To compare file record counts ........................................................................... 397 Significant features for comparing file member data ............................................... 399 Repairing data ................................................................................................... 399 Chapter 18 Chapter 19 9 Active and non-active processing...................................................................... 399 Processing members held due to error ............................................................. 399 Additional features............................................................................................. 400 Considerations for using the CMPFILDTA command ............................................. 400 Recommendations and restrictions ................................................................... 400 Using the CMPFILDTA command with firewalls................................................ 401 Security considerations ..................................................................................... 401 Comparing allocated records to records not yet allocated ................................ 401 Comparing files with unique keys, triggers, and constraints ............................. 402 Avoiding issues with triggers ....................................................................... 402 Referential integrity considerations ............................................................. 403 Job priority .................................................................................................... 403 CMPFILDTA and network inactivity................................................................... 404 Specifying CMPFILDTA parameter values.............................................................. 404 Specifying file members to compare ................................................................. 404 Tips for specifying values for unique parameters .............................................. 405 Specifying the report type, output, and type of processing ............................... 408 System to receive output ............................................................................. 408 Interactive and batch processing................................................................. 408 Using the additional parameters........................................................................ 408 Advanced subset options for CMPFILDTA.............................................................. 410 Ending CMPFILDTA requests ................................................................................. 414 Comparing file member data - basic procedure (non-active) .................................. 415 Comparing and repairing file member data - basic procedure ................................ 418 Comparing and repairing file member data - members on hold (*HLDERR) .......... 421 Comparing file member data using active processing technology .......................... 424 Comparing file member data using subsetting options ........................................... 427 Chapter 20 Synchronizing data between systems 431 Considerations for synchronizing using MIMIX commands..................................... 433 Limiting the maximum sending size .................................................................. 433 Synchronizing user profiles ............................................................................... 433 Synchronizing user profiles with SYNCnnn commands .............................. 434 Synchronizing user profiles with the SNDNETOBJ command ................... 434 Missing system distribution directory entries automatically added .............. 435 Synchronizing large files and objects ................................................................ 435 Status changes caused by synchronizing ......................................................... 435 Synchronizing objects in an independent ASP.................................................. 436 About MIMIX commands for synchronizing objects, IFS objects, and DLOs .......... 437 About synchronizing data group activity entries (SYNCDGACTE).......................... 438 About synchronizing file entries (SYNCDGFE command) ...................................... 439 About synchronizing tracking entries....................................................................... 441 Performing the initial synchronization...................................................................... 442 Establish a synchronization point ...................................................................... 442 Resources for synchronizing ............................................................................. 443 Using SYNCDG to perform the initial synchronization ............................................ 444 To perform the initial synchronization using the SYNCDG command defaults . 445 Verifying the initial synchronization ......................................................................... 447 Synchronizing database files................................................................................... 449 Synchronizing objects ............................................................................................. 451 10 To synchronize library-based objects associated with a data group ................. 451 To synchronize library-based objects without a data group .............................. 452 Synchronizing IFS objects....................................................................................... 455 To synchronize IFS objects associated with a data group ................................ 455 To synchronize IFS objects without a data group ............................................. 456 Synchronizing DLOs................................................................................................ 459 To synchronize DLOs associated with a data group ......................................... 459 To synchronize DLOs without a data group ...................................................... 460 Synchronizing data group activity entries................................................................ 462 Synchronizing tracking entries ................................................................................ 464 To synchronize an IFS tracking entry ................................................................ 464 To synchronize an object tracking entry ............................................................ 464 Sending library-based objects ................................................................................. 465 Sending IFS objects ................................................................................................ 467 Sending DLO objects .............................................................................................. 468 Chapter 21 Introduction to programming 469 Support for customizing........................................................................................... 470 User exit points.................................................................................................. 470 Collision resolution ............................................................................................ 470 Completion and escape messages for comparison commands ............................. 472 CMPFILA messages ......................................................................................... 472 CMPOBJA messages........................................................................................ 473 CMPIFSA messages ......................................................................................... 473 CMPDLOA messages ....................................................................................... 474 CMPRCDCNT messages .................................................................................. 474 CMPFILDTA messages..................................................................................... 475 Adding messages to the MIMIX message log ......................................................... 479 Output and batch guidelines.................................................................................... 480 General output considerations .......................................................................... 480 Output parameter ........................................................................................ 480 Display output.............................................................................................. 481 Print output .................................................................................................. 481 File output.................................................................................................... 483 General batch considerations............................................................................ 484 Batch (BATCH) parameter .......................................................................... 484 Job description (JOBD) parameter .............................................................. 484 Job name (JOB) parameter ......................................................................... 484 Displaying a list of commands in a library ............................................................... 485 Running commands on a remote system................................................................ 486 Benefits - RUNCMD and RUNCMDS commands ............................................. 486 Procedures for running commands RUNCMD, RUNCMDS.................................... 487 Running commands using a specific protocol ................................................... 487 Running commands using a MIMIX configuration element ............................... 489 Using lists of retrieve commands ............................................................................ 493 Changing command defaults................................................................................... 494 Customizing with exit point programs 495 Summary of exit points............................................................................................ 495 MIMIX user exit points ....................................................................................... 495 Chapter 22 11 MIMIX Monitor user exit points .......................................................................... 495 MIMIX Promoter user exit points ....................................................................... 496 Requesting customized user exit programs ...................................................... 497 Working with journal receiver management user exit points ................................... 498 Journal receiver management exit points.......................................................... 498 Change management exit points................................................................. 498 Delete management exit points ................................................................... 499 Requirements for journal receiver management exit programs................... 499 Journal receiver management exit program example ................................. 502 Appendix A Supported object types for system journal replication 505 Appendix B Copying configurations 508 Supported scenarios ............................................................................................... 508 Checklist: copy configuration................................................................................... 509 Copying configuration procedure ............................................................................ 513 Appendix C Configuring Intra communications 514 Manually configuring Intra using SNA ..................................................................... 515 Manually configuring Intra using TCP ..................................................................... 516 Appendix D MIMIX support for independent ASPs 518 Benefits of independent ASPs................................................................................. 519 Auxiliary storage pool concepts at a glance ............................................................ 519 Requirements for replicating from independent ASPs ............................................ 522 Limitations and restrictions for independent ASP support....................................... 522 Configuration planning tips for independent ASPs.................................................. 523 Journal and journal receiver considerations for independent ASPs .................. 524 Configuring IFS objects when using independent ASPs ................................... 524 Configuring library-based objects when using independent ASPs .................... 524 Avoiding unexpected changes to the library list ................................................ 525 Detecting independent ASP overflow conditions..................................................... 527 Appendix E Creating user-defined rules and notifications 528 What are rules and how they are used by auditing ................................................. 529 Requirements for using audits and rules................................................................. 530 Guidelines and recommendations for auditing ........................................................ 530 Considerations and recommendations for rules ................................................ 531 Replacement variables ................................................................................ 532 Rule-generated messages and notifications ............................................... 532 Creating user-defined rules ..................................................................................... 534 Example of a user-defined rule ......................................................................... 534 Creating user-generated notifications ..................................................................... 535 Example of a user-generated notification .......................................................... 536 Running user rules and rule groups programmatically............................................ 538 Example of creating a monitor to run a user rule .............................................. 538 MIMIX rule groups ................................................................................................... 539 Interpreting audit results 540 Resolving audit problems - MIMIX Availability Manager ......................................... 541 Resolving audit problems - 5250 emulator.............................................................. 543 Checking the job log of an audit .............................................................................. 545 Appendix F 12 Interpreting results for configuration data - #DGFE audit........................................ 546 Interpreting results of audits for record counts and file data ................................... 548 What differences were detected by #FILDTA.................................................... 548 What differences were detected by #MBRRCDCNT ......................................... 550 Interpreting results of audits that compare attributes .............................................. 551 What attribute differences were detected .......................................................... 552 Where was the difference detected................................................................... 554 What attributes were compared ........................................................................ 554 Attributes compared and expected results - #FILATR, #FILATRMBR audits.... 556 Attributes compared and expected results - #OBJATR audit ............................ 561 Attributes compared and expected results - #IFSATR audit ............................. 569 Attributes compared and expected results - #DLOATR audit ........................... 571 Comparison results for journal status and other journal attributes .................... 573 How configured journaling settings are determined .................................... 576 Comparison results for auxiliary storage pool ID (*ASP)................................... 577 Comparison results for user profile status (*USRPRFSTS) .............................. 580 How configured user profile status is determined........................................ 581 Comparison results for user profile password (*PRFPWDIND)......................... 583 Appendix G Journal Codes and Error Codes 585 Journal entry codes for user journal transactions.................................................... 585 Journal entry codes for files .............................................................................. 585 Error codes for files in error ............................................................................... 587 Journal codes and entry types for journaled IFS objects .................................. 590 Journal codes and entry types for journaled data areas and data queues........ 590 Journal entry codes for system journal transactions ............................................... 592 Appendix H Outfile formats 595 Outfile support in MIMIX Availability Manager......................................................... 595 Work panels with outfile support ............................................................................. 596 MCAG outfile (WRKAG command) ......................................................................... 597 MCDTACRGE outfile (WRKDTARGE command) ................................................... 600 MCNODE outfile (WRKNODE command)............................................................... 602 MXCDGFE outfile (CHKDGFE command) .............................................................. 604 MXCMPDLOA outfile (CMPDLOA command)......................................................... 606 MXCMPFILA outfile (CMPFILA command) ............................................................. 608 MXCMPFILD outfile (CMPFILDTA command) ........................................................ 610 MXCMPFILR outfile (CMPFILDTA command, RRN report).................................... 613 MXCMPRCDC outfile (CMPRCDCNT command)................................................... 614 MXCMPIFSA outfile (CMPIFSA command) ............................................................ 617 MXCMPOBJA outfile (CMPOBJA command) ......................................................... 619 MXDGACT outfile (WRKDGACT command)........................................................... 621 MXDGACTE outfile (WRKDGACTE command)...................................................... 623 MXDGDAE outfile (WRKDGDAE command) .......................................................... 631 MXDGDFN outfile (WRKDGDFN command) .......................................................... 632 MXDGDLOE outfile (WRKDGDLOE command) ..................................................... 640 MXDGFE outfile (WRKDGFE command)................................................................ 642 MXDGIFSE outfile (WRKDGIFSE command) ......................................................... 646 MXDGSTS outfile (WRKDG command) .................................................................. 648 WRKDG outfile SELECT statement examples .................................................. 670 13 WRKDG outfile example 1........................................................................... 670 WRKDG outfile example 2........................................................................... 670 WRKDG outfile example 3........................................................................... 671 WRKDG outfile example 4........................................................................... 671 MXDGOBJE outfile (WRKDGOBJE command) ...................................................... 674 MXDGTSP outfile (WRKDGTSP command) ........................................................... 677 MXJRNDFN outfile (WRKJRNDFN command) ....................................................... 680 MXRJLNK outfile (WRKRJLNK command) ............................................................. 684 MXSYSDFN outfile (WRKSYSDFN command)....................................................... 687 MXTFRDFN outfile (WRKTFRDFN command) ....................................................... 691 MZPRCDFN outfile (WRKPRCDFN command) ...................................................... 693 MZPRCE outfile (WRKPRCE command) ................................................................ 694 MXDGIFSTE outfile (WRKDGIFSTE command)..................................................... 697 MXDGOBJTE outfile (WRKDGOBJTE command).................................................. 699 Index 703 14 15 . you can add the product library name to your library list or you can qualify the command with the name of the product library. In text. The following topics illustrate formatting techniques that may be used in this book. 16 . the function is invoked immediately.Product conventions The conventions described here apply to all MIMIX products unless otherwise noted. To view help for a specific option. • • To view general help for a command. When there is a corresponding command for a menu option. Notes and Attentions are specialized formatting techniques that are used. Accessing online help MIMIX Availability Manager includes online help that is accessible from within the product. Some commands can be submitted in batch jobs. You can use either the menu option or the command to access the function. specialized styles and techniques distinguish information you see on a display from information you enter on a display or command line. or a menu. context sensitive online help is available for all MIMIX commands and displays. the system will prompt you for any required parameters. press F1 when the cursor is located in the area for which you want help. respectively. The position of your cursor determines what you will see. From a 5250 emulator. If you enter a command without parameters. a display. To issue a command from a command line outside of the menu interface. prompt. From any window within MIMIX Availability Manager. Publication conventions This book uses typography and specialized formatting to help you quickly identify the type of information you are reading. For example. press F1 when the cursor is at the top of the display. the command is shown at the far right of the display. If you enter the command with all of the required parameters. bold type identifies a new term whereas an underlined word highlights its importance. selecting the Help icon will open the help system and access help for the current window. Simply press F1 to view help. or column. to highlight a fact or to warn you of the potential for damage. Menus and commands Functionality for all MIMIX products is accessible from a common MIMIX Main Menu. The options you see on a given menu may vary according to which products are installed. DGDFN(name system1 system2) CHGVAR &RETURN &CONTINUE Convention Initial Capitalization Italic UPPERCASE System-defined mnemonic names for commands. Names of columns. (Column names are also shown in italic). commands. user-defined values Examples MIMIX Basic Main Menu Update Access Code command Page Up key The Status column The Start processes prompt The library-name value CHGUPSCFG command WARNMSG parameter The value *YES Type the command MIMIX and press Enter. and values. Examples showing programming code. keyboard keys.Publication conventions Formatting for displays and commands Table 1 shows the formatting used for the information you see on displays and command interfaces: Table 1. parameters. variables. the conventions of italic and UPPERCASE also apply. columns. Formatting examples for displays and commands Description Names of menus or displays. In instructions. monospace font Text that you enter into a 5250 emulator command line. prompts on displays. 17 . Sources for additional information This book refers to other published information. can be located in the IBM System i and i5/OS Information Center. SG24-5189 18 . and redbooks: • • • • • • • • • • Backup and Recovery Journal management DB2 Universal Database for IBM PowerTM Systems Database Programming Integrated File System Introduction Independent disk pools OptiConnect for OS/400 TCP/IP Setup IBM redbook Striving for Optimal Journal Performance on DB2 Universal Database for iSeries. SG24-5189 IBM redbook PowerTM Systems iASPs: A Guide to Moving Applications to Independent ASPs. The following information. books. SG24-6802 The following information may also be helpful if you use advanced journaling: • • • DB2 UDB for iSeries SQL Programming Concepts DB2 Universal Database for iSeries SQL Reference IBM redbook AS/400 Remote Journal Function for High Availability and Data Replication. plus additional technical information. From the Information center you can access these IBM PowerTM Systems topics. SG24-6286 IBM redbook AS/400 Remote Journal Function for High Availability and Data Replication. If you are current on maintenance. 19 .How to contact us How to contact us For contact information. It is important to include product and version information whenever you report problems. If you use MIMIX Availability Manager. visit our Contact CustomerCare web page. you should also include the version information provided at the bottom of each MIMIX Availability Manager window. support for MIMIX products is also available when you log in to Support Central. 20 . you can quickly switch users to the backup system where they can continue using their applications. data areas. When the original production system is brought back online. This allows you to generate reports. and reference information for MIMIX ha1 and MIMIX ha Lite. integrated file system (IFS) objects. replicated databases and objects can be used for distributed processing. In the event of an outage. • Configuration choices determine the degree of cooperative processing used between the system journal and user journal replication paths when replicating database files. In previous versions. One common use of MIMIX is to support a hot backup system to which operations can be switched in the event of a planned or unplanned outage. and document library object (DLOs) using the system journal. The system journal replication path handles replication of critical system objects (such as user profiles. MIMIX uses two replication paths to address different pieces of your replication needs. MIMIX continuously captures changes to critical database files and objects on a production system. When configuring this path. • The user journal replication path captures changes to critical files and objects configured for replication through a user journal. For simplicity.CHAPTER 1 MIMIX overview This book provides concepts. allowing you to off-load applications to a backup system. and applies the changes to the appropriate database file or object on the backup system. MIMIX captures changes on the backup system for later synchronization with the original production system. You can view the replicated data on the backup system at any time without affecting productivity. These paths operate with configurable levels of cooperation or can operate independently. More complex environments have 21 . or spooled files). this book uses the term MIMIX to refer to the functionality provided by either product unless a more specific name is necessary. In addition to real-time backup capability. its backup is already prepared for users. IFS objects. MIMIX version 6 provides high availability for your critical data in a production environment on IBM PowerTM Systems through real-time replication of changes. and data queues. MIMIX DB2 Replicator provided this function. Simple environments have one production system and one backup system. If a production system becomes unavailable. sends the changes to a backup system. submit (read-only) batch jobs. Typically MIMIX is used among systems in a network. configuration procedures. or perform backups to tape from the backup system. program objects. The backup system stores exact duplicates of the critical database files and objects from the production system. In previous versions MIMIX Object Replicator provided this function. shipped defaults use the remote journaling function of the operating system to simplify sending data to the remote system. MIMIX assists you with analysis and synchronization of the database files and other objects. MIMIX also provides a means of verifying that the files and objects being replicated are what is defined to your configuration. “Operational overview” on page 40 provides information about day to day MIMIX operations. 22 .MIMIX overview multiple production systems or backup systems. “Journal receiver management” on page 37 describes how MIMIX performs change management and delete management for replication processes. This can help ensure the integrity of your MIMIX configuration. The topics in this chapter include: • • • • “MIMIX concepts” on page 23 describes concepts and terminology that you need to know about MIMIX. MIMIX can also be used on a single system. “The MIMIX environment” on page 29 describes components of the MIMIX operating environment. MIMIX automatically monitors your replication environment to detect and correct potential problems that could be detrimental to maintaining high availability. 23 . A MIMIX installation is a network of systems that transfer data and objects among each other using functions of a common MIMIX product. In normal operations. it is important to correctly identify the instance to which you are referring. In normal operations.MIMIX concepts MIMIX concepts This topic identifies concepts and terminology that are fundamental to how MIMIX performs replication. for normal operations in basic two-system environment. You should be familiar with the relationships between systems. if you switch application processing to the backup system. replication occurs between two or more systems. In an availability management context. A MIMIX installation is defined by the way in which you configure the MIMIX product for each of the participating systems. A target system is the system on which MIMIX replication activity between two systems completes. the source system contains the journal entries used for replication. A system can participate in multiple independent MIMIX installations. A backup system is the system that is not currently running the production workload for the applications. the production system is the system on which the principal copy of the data and objects associated with the application exist. The terms production system and backup system are used to describe the role of a system relative to the way applications are used on that system. The most common scenario for replication is a two-system environment in which one system is used for production activities and the other system is used as a backup system. A source system is the system from which MIMIX replication activity between two systems originates. if a payroll application on system CHICAGO is backed up on system LONDON and another application on system LONDON is backed up to the CHICAGO system. In replication. the backup system is the system on which you maintain a copy of the data and objects associated with the application. It is helpful to consider each installation of MIMIX on a system as being part of a separate network that is referred to as a MIMIX installation. the terms production system and backup system may not be sufficient to clearly identify a specific system or its current role in the replication process. For example. a production system is the system currently running the production workload for the applications. the backup system temporarily becomes the production system. These roles are not always associated with a specific system. the concepts of data groups and switching. replicated data flows from the system running the production workload to the backup system. both systems are acting as production systems and as backup systems at the same time. Typically. For example. In a more complex environment. and role of the IBM i journaling function in replication. The terms source system and target system identify the direction in which an activity occurs between two participating systems. Because multiple instances of MIMIX can be installed on any system. Information from the journal entries is either replicated to the target system or used to identify objects to be replicated to the target system. System roles and relationships Usually. when a production system is removed from the network for planned downtime. you can limit a data group to replicate using only one replication path. A data group may represent an application. A network system is any system in a MIMIX installation that is not designated as the management system (control point) of that MIMIX installation. A management system is the system in a MIMIX installation that is designated as the control point for all installations of the product within the MIMIX installation. A data group entry identifies a source of information that can be replicated. These roles remain associated with the system within the MIMIX installation to which they are defined. you specify which of the two systems in the data group is the source for replicated data. Application environments may define a data group as a specific set of files and objects. Users can start and stop replication activity by data group. For example.The terms management system and network system define the role of a system relative to how the products interact within a MIMIX installation. If you are using both user journal and system journal replication. The parameters in the data group definition identify the direction in which data is allowed to flow between systems and whether to allow the flow to switch directions. data groups support replication from both the system journal and the user journal. and display replication status by data group. Once a data group definition is created. DLOs. library-based objects. In normal operation. Changing directions: switchable data groups When you configure a data group definition. Often the system defined as the management system also serves as the backup system during normal operations. a set of one or more libraries. 24 . for example. library-based objects. Typically one system in the MIMIX installation is designated as the management system and the remaining one or more systems are designated as network systems. or a combination thereof that defines a unit of work by which MIMIX replication activity is controlled. Work definitions are automatically distributed from the management system to a network system. By default. or all of the critical data on a given system. you can define data group entries. MIMIX uses the data group entries that you create during configuration to determine whether a journal entry should be replicated. The replication process is started and ended by operations on a data group. A data group is a logical grouping of database files. IFS objects. Data groups: the unit of replication The concept of a data group is used to control replication activities. You also define the data to be replicated and many other characteristics the replication process uses on the defined data. and DLOs. a data group can have any combination of entries for files. data flows between two systems in the direction defined within the data group. The management system is the location from which work to be performed by the product is defined and maintained. Often a system defined as a network system also serves as the production system during normal operations. switch the direction of replication for a data group. Optionally. default values in the data group definition allow the same data group to be used for replication from either direction. When you need to switch the direction of replication. the R/3 environment defines a data group as a set of SQL tables that all use the same journal and which are all replicated to the same system. IFS objects. Journaling must be active before MIMIX can perform replication. Additional switching capability Typically. For some configurations. a record in a journal receiver. MIMIX uses the recorded journal entries to replicate activity to a designated system. switching is performed by using the MIMIX Switch Assistant. including those made by a system or user function. logged events in a user journal can be on a remote system using remote journaling. MIMIX ha1 and MIMIX ha Lite include MIMIX Monitor. Object auditing is the process by which the system creates audit records for specified types of access to objects. MIMIX Switch Assistant calls your default MIMIX Model Switch Framework to control the switching process. or when a security-relevant event occurs. QAUDJRN). whereby the journal and journal receiver exist on a remote system or on a different logical partition.MIMIX concepts MIMIX provides support for switching due to planned and unplanned events. When you perform switching in this manner. Variations in the replication process are optimized according to characteristics of the information provided by each of these functions. Optionally. Data group entries and other data group configuration settings determine whether MIMIX replicates activity for objects and whether replication is performed based on entries logged to the system journal or to a user journal. Note: A switchable data group is different than bi-directional data flow. Your authorized MIMIX representative can assist you in implementing advanced switching scenarios. the system logs identifying information about the event as a journal entry. which provides support for the MIMIX Model Switch Framework. MIMIX Switch Assistant provides a user interface that prompts you through the switch process. Switching support in MIMIX Monitor includes logical and physical switching. the Switch Data Group (SWTDG) command will switch the direction in which replication occurs between systems. the exit programs called by your implementation of MIMIX Model Switch Framework must include the SWTDG command. 25 . Journaling is the process of recording information about changes to user-identified objects. Object auditing logs events in a specialized system journal (the security audit journal. Events are logged in a user journal. remote journaling. you can customize monitoring and switching programs. Journaling and object auditing introduction MIMIX relies on data recorded by the IBM i functions of journaling. Each of these functions record information in a journal. At the data group level. see the Using MIMIX Monitor book. For more information. When an event occurs to an object or database file for which journaling is enabled. Through this support. The journal receiver is associated with a journal and contains the log of all activity for objects defined to the journal or all objects for which an audit trail is kept. MIMIX uses entries from both journals. and object auditing. for a limited number of object types. Bi-directional data flow is a data sharing technique described in “Configuring advanced replication techniques” on page 320. Journal entries deposited into the system journal (on behalf of an audited object) contain only an indication of a change to an object. For additional information. The maximum includes: • • • Objects for which changes are currently being journaled Objects for which journaling was ended while the current receiver is attached Journal receivers that are. Journal entries deposited into a user journal (on behalf of a journaled file. 26 . data area. Some of these types of entries contain enough information needed by MIMIX to apply the change directly to the replicated object on the target system. Journals created by MIMIX have a maximum of 250. the journal receivers must reside in the same primary independent ASP or a secondary independent ASP within the same ASP group. This information is needed by MIMIX in order to apply the change directly to the replicated object on the target system. MIMIX can use existing journals with this value. IBM i requires that journaled objects reside in the same auxiliary storage pool (ASP) as the user journal. see “Journal receiver management” on page 37. The IBM i remote journal function controls where it starts sending entries from the source journal receiver to the remote journal receiver. or IFS object) contain images of the data which was changed. Remote journaling requires unique considerations for journaling and journal receiver management. All internal structures and objects that make up a log space are created and manipulated by MIMIX. a log space is a MIMIX object that provides an efficient storage and manipulation mechanism for replicated data that is temporarily stored on the target system during the receive and apply processes. IBM i (V5R4 and higher releases) allows journaling a maximum of 10. The journal receivers can be in a different ASP.000 objects. the specified sequence number and receiver name is the starting point for MIMIX processing from the remote journal. associated with the journal while the current journal receiver is attached. or were. the start request (STRDG command) identifies a sequence number within a journal receiver at which MIMIX processing begins.000. data queue. When replication is started. In data groups configured with remote journaling.000 objects to one user journal. If the journal is in a primary independent ASP. User journaling will not start if the number of objects associated with the journal exceeds the journal maximum. however many types of these entries require MIMIX to gather additional information about the object from the source system in order to apply the change directly to the replicated object on the target system. Log spaces Based on user space objects (*USRSPC). The first element. if the data group definition INVENTORY CHICAGO HONGKONG is the only data group with the name INVENTORY. Together the elements of the multi-part name define the entire environment for that definition. When using command interfaces which require a data group definition. which has unique requirements for naming data group definitions. the name INVENTORY by itself no longer describes a unique data group. specifying INVENTORY HONGKONG will generate a “not found” error because HONGKONG is not the first system in any of the data group definitions. The multi-part name consists of a name followed by one or two participating system names (actually. Newly created data groups use remote journaling as the default configuration. names of system definitions). a fully-qualified two-part or three-part name must be unique. if a second data group named INVENTORY NEWYORK LONDON is created. This applies to all external interfaces that reference multi-part definition names. MIMIX automatically creates a journal definition for the security audit journal when you create a system definition. If MIMIX cannot find the transfer 27 . For more information. MIMIX uses the context of the operation to determine the fully qualified name. MIMIX can derive the fully-qualified name of a data group definition if a partial name provided is sufficient to determine the unique name. the order of the system names is also important. This includes a two-part name for journal definitions and a threepart name for transfer definitions and data group definitions. If the first part of the name is unique. and the specified transfer definition name to derive the fully qualified transfer definition name. For example. so the name alone is not unique. For example. then specifying INVENTORY on any command requiring a data group name is sufficient. As a whole unit. However. when starting a data group. the name. A multi-part. such as QAUDJRN CHICAGO or QAUDJRN NEWYORK. The system HONGKONG appears in only one of the data groups definitions. When a subsequent operation requires the transfer definition. MIMIX uses information in the data group definition. it can be used by itself to designate the data group definition. since two valid definitions may share the same three elements but with the system names in different orders. then the fully qualified name would be required to uniquely identify the data group. does not need to be unique. Each of these journal definitions is named QAUDJRN. MIMIX can also derive a fully qualified name for a transfer definition.Multi-part naming convention MIMIX uses named definitions to identify related user-defined configuration information. INVENTORY CHICAGO would be the minimum parts of the name of the first data definition necessary to determine its uniqueness. In a three-part name. The name must be qualified with the name of the system to which the journal definition applies. Data group definitions and system definitions include parameters that identify associated transfer definitions. However. For example. The order in which the systems are identified is also important. the data group definitions INVENTORY CHICAGO HONGKONG and INVENTORY HONGKONG CHICAGO are unique because of the order of the system names. qualified naming convention uniquely describes certain types of definitions. If a third data group named INVENTORY CHICAGO LONDON was added. Similarly. see “Naming convention for remote journaling environments with 2 systems” on page 185. the systems specified in the data group name. You can also use contextual system support (*ANY) to configure transfer definitions. When you specify *ANY in a transfer definition. Unlike the conventional configuration case. 28 . a specific search order is used if MIMIX is still unable to find an appropriate transfer definition. it reverses the order of the system names and checks again. For more information. see “Using contextual (*ANY) transfer definitions” on page 160. MIMIX uses information from the context in which the transfer definition is called to resolve to the correct system.definition. avoiding the need for redundant transfer definitions. Several items are shipped as part of the product library. This topic describes each of the components of the MIMIX operating environment. see “Data that should not be replicated” on page 78. Each MIMIX installation also contains several default job descriptions and job classes within its library. The VvRrMm value is the same as the release of License Manager on the system.The MIMIX environment The MIMIX environment A variety of product-defined operating elements and user-defined configuration elements collectively form an operational environment on each system. For additional information. The IFS directory structure is associated with the product library for the MIMIX installation and is created during the installation process for License Manager and MIMIX. Two structures that you should be aware of are: /LakeviewTech/Service/MIMIX/VvRrMm/ is the recommended location for users to place fixes downloaded from the website. 29 . The directories created when License Manager is installed or upgraded follow these guidelines: /LakeviewTech This is the root directory for all IFS-based objects. The default name of the product installation library is MIMIX. /LakeviewTech/system-based-area This directory structure contains system-based objects that need to exist only once on a system. Over time. /LakeviewTech/Upgrades/ is where the MIMIX Installation Wizard places software packages that it uploads to the system. Also do not place user created objects in this library. The product library The name of the product library into which MIMIX is installed defines the connection among systems in the same MIMIX installation. A MIMIX environment can be comprised of one or more MIMIX installations. Each system that participates in the same MIMIX environment must have the same operational environment. Note: Do not replicate the library in which MIMIX is installed or any other libraries created by MIMIX. the installation processes for products and fixes will restore objects to the IFS directory structure as well as to the QSYS library. IFS directories A default IFS directory structure is used in conjunction with the library-based objects of the MIMIX family of products. The IFS directory structure is associated with the product library for the MIMIX installation and is created during the installation process for License Manager and MIMIX. /LakeviewTech/UserData/ is available to users to store product-related data. The systembased-area represents a unique directory for each set of objects. Multiple VvRrMm directories will exist as the release of License Manager changes. /LakeivewTech/ISC/ contains artifacts which enable the Vision Solutions plugin to appear in IBM Systems Director Navigator for IBM i5/OS under the category of i5/OS Management. Customized job descriptions optimize characteristics for a category of jobs. Job descriptions and job classes MIMIX uses a customized set of job descriptions and job classes. shows a combined list of MIMIX job descriptions. Name Job descriptions used by MIMIX Description Shipped in Installation Library X Shipped in MIMIXQGPL Library MXAUDIT MIMIX Auditing. MXDFT X 30 . these job descriptions are automatically restored in the product library. along with these job descriptions. Used for MIMIX load commands and by other commands that do not have a specific job description as the default value on the JOBD parameter. Used for MIMIX compare commands. is automatically restored on the system when a MIMIX product is installed. Compare File Data (CMPFILDTA). Jobs and related output are associated with the user profile submitting the request. Customized job classes optimize runtime characteristics such as the job priority and CPU time slice for a category of jobs. job queue. The structure is determined by the set of objects needed by an area of the product and the product installation library. /LakeviewTech/MIMIX/product-installation-library/productarea There is a unique directory structure for each installation of MIMIX. Commands such as Compare File Attributes (CMPFILA). Older commands that provide job description support for batch processing use different job descriptions that are located in the MIMIXQGPL library. MIMIX Default. All of the shipped job descriptions and job classes are configured with recommended default values. Table 2. as the default value on the Job description (JOBD) parameter. such as those called by MIMIX audits. and routing data for the job. MXSYNC. MXAUDIT. as well as numerous others support this standard. Synchronize Object (SYNCOBJ). Installing additional MIMIX installations on the same system does not create additional copies of these job descriptions. Table 2. message logging level. The directories created when MIMIX is installed or upgraded follow these guidelines. When MIMIX is installed. These job descriptions exist in the product library of each MIMIX installation. The MIMIXQGPL library. The requirements of your MIMIX environment determine the structure of these directories: /LakeviewTech/MIMIX/product-installation-library There is a unique directory structure for each installation of MIMIX. and MXDFT. including the user profile. Job descriptions control batch processing. MIMIX features use a set of default job descriptions. Characters nnnnn in the name identify the server port. container send. MIMIX UPS Monitor. object send. MIMIX TCP Server. Used for MIMIX synchronization commands. object retrieve. MIMIX Monitor. Used for MIMIX system manager and journal manager jobs. MIMIX Default. MIMIX Synchronization. Used for all MIMIX jobs that do not have a specific job description. MIMIXAPY MIMIXCMN MIMIXDFT MIMIXMGR MIMIXMON MIMIXPRM MIMIXRGZ MIMIXSND MIMIXSYNC X X X X X X X X X MIMIXUPS X MIMIXVFY X PORTnnnnn or alias name X1 1. Used for file reorganization jobs submitted by the database apply job. Used for database send. Used for MIMIX apply process jobs. MIMIX Apply. MIMIX Communications. and status send jobs in MIMIX. MIMIX Manager. A job description exists for each transfer definition which uses TCP protocol and enables MIMIX to create and manage autostart job entries. Used for MIMIX verify and compare command processes. The job descriptions are created in the installation library when transfer definitions which specify PROTOCOL(*TCP) and MNGAJE(*YES) are created or changed. such as those called by MIMIX audits. Used for the uninterruptible power source (UPS) monitor managed by the MIMIX Monitor product. The associated autostart job entries are added to the subsystem description for the MIMIXSBS subsystem in library MIMIXQGPL. where nnnnn identifies the server port number or alias. MIMIX Reorganize File. Used for MIMIX file synchronization. 31 . MIMIX Send. MIMIX Verify. Used for jobs submitted by the MIMIX Promoter product. Used for most jobs submitted by the MIMIX Monitor product. Name Job descriptions used by MIMIX Description Shipped in Installation Library X Shipped in MIMIXQGPL Library MXSYNC MIMIX Synchronization. as the default value on the JOBD parameter. MIMIX Promoter. This is valid for synchronize commands that do not have a JOBD parameter on the display. This is valid for verify and compare commands that do not have a JOBD parameter on the display. Used for all target communication jobs.The MIMIX environment Table 2. The profile is created with sufficient authority to run all MIMIX products and perform all the functions provided by the MIMIX products. including cleanup of the system and data group history files. Once started. The system manager also gathers messages and timestamp information from the network system and places them in a message log and timestamp file on the management system. Reducing the authority of the MIMIXOWN requires significant effort by the user to ensure that the products continue to function properly and to avoid adversely affecting the performance of MIMIX products. This profile owns all MIMIX objects.User profiles All of the MIMIX job descriptions are configured to run jobs using the MIMIXOWN user profile. Dynamic status changes are also collected and returned to the management system. there are four pairs of system manager jobs. Since each pair has a send side system manager job and a receiver side system manager job. These jobs must be active to enable replication. In addition. System manager jobs in a MIMIX installation with one management system and 32 . Note: Do not replicate the MIMIXOWN or LAKEVIEW user profiles. The authority of this user profile can be reduced. Each pair has a send side system manager job and a receiver side system manager job. there are eight total system manager jobs in this installation. the system manager monitors for configuration changes and automatically moves any configuration changes to the network system. the system manager performs periodic maintenance tasks. Each arrow represents a pair of system manager jobs. The system manager The system manager consists of a pair of system management communication jobs between a management system and a network system. if business practices require. In this installation. see “Data that should not be replicated” on page 78. but this is not recommended. Figure 1. two between the first network system and the management system and two between the second network system and the management system. including the objects in the MIMIX product libraries and in the MIMIXQGPL library. Figure 1 shows a MIMIX installation with a management system and two network systems. See the License and Availability Manager book for additional security information for the MIMIXOWN user profile. For additional information. A journal manager job runs on each system in a MIMIX installation.m. System manager jobs are included in a group of jobs that MIMIX automatically restarts daily to maintain the MIMIX environment.).The MIMIX environment two network systems. The default operation of MIMIX is to restart these MIMIX jobs at midnight (12:00 a. The journal manager The journal manager is the process by which MIMIX maintains journal receivers on a system. The System manager delay parameter in the system definition determines how frequently the system manager looks for work. For more information. Other parameters in the system definition control other aspects of system manager operation. If you have a MIMIX installation with a management system and two network systems. see the section “Configuring restart times for MIMIX jobs” on page 285. you 33 . MIMIX determines when to restart the system managers based on the value of the Job restart time parameter in the system definitions for the network and management systems. For more information. you may find additional objects in the MIMIXQGPL library. For more information. a library named MIMIXQGPL is restored on the system. they may be deleted during the next installation process. see “Journal receiver management” on page 37. Journal manager jobs are included in a group of jobs that MIMIX automatically restarts daily to maintain the MIMIX environment. see “Journal definition considerations” on page 184. The Journal manager delay parameter in the system definition determines how frequently the journal manager looks for work. The MIMIXQGPL library When a MIMIX product is installed. The default operation of MIMIX is to restart these MIMIX jobs at midnight (12:00 a. These objects include the MIMIXSBS subsystem and a variety of job descriptions and job classes.m. Parameters in a journal definition allow you to customize details of how the change and delete operations are performed. The MIMIXQGPL library includes work management objects used by all MIMIX products. MIMIX creates the first data library when needed and may create additional data libraries. Note: If you have previous releases of MIMIX products on a system. one on each system.have three journal manager jobs. see the section “Configuring restart times for MIMIX jobs” on page 285. MIMIX performs both change management and delete management for journal receivers used by the replication process. see “Data that should not be replicated” on page 78. If you place objects in these libraries. A for ASP 1. where x is derived from the ASP. This subsystem is shipped with the proper job queue entries and routing entries for correct operation of the MIMIX jobs. do not replicate the MIMIXQGPL library. Currently there are two series of data libraries: • MIMIX uses data libraries for storing the contents of the object cache. The Job restart time parameter in the system definition determines when the journal manager for that system restarts. Data libraries MIMIX uses the concept of data libraries. By default. MIMIXSBS subsystem The MIMIXSBS subsystem is the default subsystem used by nearly all MIMIX-related processing. B for ASP 2. Many of these objects are customized and shipped with default settings designed to streamline operations for the products which use them. These ASP-specific data libraries are created when needed and are not deleted until the product is uninstalled. Also. • 34 . The names of data libraries are of the form product-library_n (where n is a number starting at 1). however you should not place objects in this library. For example. For additional information. For system journal replication. MIMIX creates libraries named product-library_x. For more information.). The naming conventions used within definitions are described in “Multi-part naming convention” on page 27. One or more or each of the following definitions are required to perform replication: A system definition identifies to MIMIX the characteristics of a system that participates in a MIMIX installation. using the transfer definition defined in the data group. A data group definition determines the direction in which replication occurs between the systems. MIMIX uses the data group entries that you create during configuration to determine whether or not a journal entry should be replicated. Data group object entries This type of entry allows you to identify library-based objects for replication. user profiles. journal information. and whether the IBM i remote journal function sends journal entries asynchronously or synchronously. message queues. A transfer definition identifies to MIMIX the communications path and protocol to be used between two systems. When a data group is added. You can create named definitions for system information. and non-journaled database files. Within a file entry. you can override the default file entry options defined for the data group. A remote journal link (RJ link) is a MIMIX configuration element that identifies an IBM i remote journaling environment. A journal definition identifies to MIMIX a journal environment on a particular system. MIMIX supports Systems Network Architecture (SNA). and the default processing characteristics to use when processing the database and object information associated with the data group. To select these • 35 . Examples of library-based objects include programs. MIMIX supports both positional and keyed access paths for accessing records stored in a physical file. MIMIX only replicates transactions for physical files because a physical file contains the actual data stored in members. the ADDRJLNK command is run automatically.The MIMIX environment Named definitions MIMIX uses named definitions to identify related user-defined configuration information. primary and secondary transfer definitions for the communications path used by MIMIX. Data group entries Data group entries are part of the MIMIX environment that must exist on each system in a MIMIX installation. and replication (data group) information. An RJ link identifies journal definitions that define the source and target journals. communication (transfer) information. OptiConnect. A data group definition identifies to MIMIX the characteristics of how replication occurs between two systems. whether that direction can be switched. MIMIX uses the journal definition to manage the journal receiver environment used by the replication process. Newly created data groups use remote journaling as the default configuration. • Data group file entry This type of data group entry identifies the location of a database file to be replicated and what its name and location will be on the target system. and Transmission Control Protocol/Internet Protocol (TCP/IP) protocols. Any definitions you create can be used by both user journal and system journal replication processes. you can specify an extended object attribute such as PF-DTA or DSPF. • • A single data group can contain any combination of these types of data group entries. You can select IFS objects for replication by specific or generic path name. However. only the entries associated with the product to which you are licensed will be processed for replication. IFS objects include directories. Data group data area entries This type of entry allows you to define a data area for replication by the data area polling process. Data group DLO entries This type of entry allows you to identify document library objects (DLOs) for replication.. and symbolic links. and owner. • Data group IFS entries This type of entry allows you to identify integrated file system (IFS) objects for replication. and object type. Optionally. the preferred way to replicate data areas is to use advanced journaling. To select DLOs for replication you select individual DLOs by specific or generic folder and DLO name. you select individual objects or groups of objects by generic or specific object and library name. If your license is for only one of the MIMIX products rather than for MIMIX ha1 or MIMIX ha Lite.types of objects for replication. They are contained in folders (except for first-level folders). for files. DLOs are documents and folders. similar to DOS or UNIX files. 36 . stream files. They reside in directories. unless the receiver size option (RCVSIZOPT) is *MAXOPT3. • When you specify *NONE. MIMIX recognizes remote journals and ignores change management for the remote journals. The conditions specified in these parameters must be met before change management can occur. The shipped default value *TIMESIZE results in MIMIX changing the journal receiver by both threshold size and time of day.Journal receiver management Journal receiver management Parameters in journal definition commands determine how change management and delete management are performed on the journal receivers used by the replication process. MIMIX does not handle changing the journal receivers.The Receiver change management (CHGMGT) parameter controls how the journal receivers are changed. respectively. Note: The value *TIME can be specified with *SIZE or *SYSTEM to achieve the same results as *TIMESIZE or *TIMESYS. You must ensure that the system or another application performs change management to prevent the journal receivers from overflowing.The Receiver delete management (DLTMGT) parameter controls how the journal receivers used for replication are deleted. consider the following: • When you specify *TIMESYS. It is strongly 37 . the sequence number will not be reset and a new journal receiver will not be attached unless the sequence number exceeds the sequence number threshold. Change management . When you allow the system to perform change management (*SYSTEM) and the attached journal receiver reaches its threshold. the system manages the receiver by size and during IPLs and MIMIX manages changing the receiver at a specified time. the system detaches the journal receiver and creates and attaches a new journal receiver. The remote journal receiver is changed automatically by the IBM i remote journal function when the receiver on the source system is changed. see “Tips for journal definition parameters” on page 179. Any change management values you specify for the target journal definition are ignored. Additional parameters in the journal definition control the size at which to change (THRESHOLD). You can also customize how MIMIX performs journal receiver change management through the use of exit programs. For more information. When the RCVSIZOPT is *MAXOPT3. Delete management . the system performs a CHGJRN command to create and attach a new journal receiver and to reset the journal sequence number of journals that are not needed for commitment control recovery for that IPL or vary on. During an initial program load (IPL) or the vary on of an independent ASP. the time of day to change (TIME). • In a remote journaling configuration. see “Working with journal receiver management user exit points” on page 498. You can specify in the source journal definition whether to have receiver change management performed by the system or by MIMIX. If you do not use the default value *TIMESIZE for CHGMGT. Shipped default values allow MIMIX to perform change management and delete management. For additional information. and when to reset the receiver sequence number (RESETTHLD2 or RESETTHLD). If you choose MIMIX ha1. and how long to keep detached journal receivers (KEEPJRNRCV). perform delete management only from MIMIX replicate1. For example. For more information. a target journal receiver cannot be deleted until it is processed by the database reader (DBRDR) process and it meets the other criteria defined in the journal definition. Delete management of the source and target receivers occur independently from each other. The IBM i remote journal function does not allow a receiver to be deleted until it is replicated from the local journal (source) to the remote journal (target). how many detached journal receivers to keep (KEEPRCVCNT). see “Working with journal receiver management user exit points” on page 498. If both products scrape from the same journal. If you choose to manage journal receivers yourself. the journal manager for each installation can delete the journal regardless of whether the other installations are finished with it. see change management for available options that can be specified in the journal definition. It is highly recommended that you configure the journal definitions to have MIMIX perform journal delete management. This will prevent MIMIX ha1 deleting receivers before MIMIX replicate1 is finished with them. the system may delete a journal receiver before MIMIX has completed its use. you need to choose only one product to perform change management activities for a specific journal. This can occur in the following scenarios: • When performing a clear pending start of the data group while also specifying a 38 . the journal receivers are only deleted after MIMIX is finished with them and all other criteria specified on the journal definition are met. Processing from an earlier journal receiver It is possible to have a situation where the operating system attempts to retransmit journal receivers that already exist on the target system. MIMIX operations can be affected if you allow the system to handle delete management. Although both MIMIX replicate1 and MIMIX ha1 support receiver change management. the remote journal function ends with an error and transmission of entries to the target system stops. including system managed receivers. Note: If more than one MIMIX installation uses the same journal. When this situation occurs. If you choose MIMIX replicate1. Interaction with other products that manage receivers If you run MIMIX replicate1 on the same system as MIMIX ha1 (or MIMIX ha Lite) there may be considerations for journal receiver management. your MIMIX ha1 journal definition should specify CHGMGT(*NONE). The criteria includes how long to retain unsaved journal receivers (KEEPUNSAV). When MIMIX manages deletion. you need to ensure that journals are not removed before MIMIX has finished processing them.recommended that you use the value *YES to allow MIMIX to perform delete management. The journal definition within MIMIX ha1 should specify DLTMGT(*NO). If you have this scenario. When MIMIX performs delete management. you need to use the journal receiver delete management exit points to control deleting the journal receiver. 39 . the IBM i remote journal function begins transmitting journal entries from the just changed journal receiver. the journal receiver is changed before the data group is started. these additional journal receivers can become stranded on the backup system following a switch. Replication ended while processing journal entries in target receiver 2. the remote journal function attempts to retransmit source journal receivers 1 through 4. Figure 2. If the data group is started (STRDG) with a starting journal sequence number for an entry that is in journal receiver 1. deleting target receiver 2 would prevent or resolve the problem. For example. As part of the switch processing. To remove these stranded journal receivers. Target journal receiver 1 is deleted through the configured delete management options. However. Example of processing from an earlier journal receiver. refer to Figure 2. This journaling on the target system makes it easier and faster to start replication from the backup system following a switch.Journal receiver management sequence number that is earlier in the journal stream than the last processed sequence number • When starting a data group while specifying a database journal receiver that is earlier in the receiver chain than the last processed receiver. You can prevent this situation before starting that data group if you delete any target journal receivers following the receiver that will be used as the starting point. In this example. Source Journal Receivers Target Journal Receivers 4 3 2 1 1 2 Considerations when journaling on target The default behavior for MIMIX is to have journaling enabled on the target systems for the target files. beginning with receiver 1. Because the backup system is now temporarily acting as the source system. an error occurs and the transmission to the target system ends. recovery is simply to remove the target journal receivers and let remote journaling resend them. In a remote journaling environment. MIMIX writes the journal entry to a separate journal on the target system. the remote journal function interprets any earlier receivers as unprocessed source journal receivers and prevents them from being deleted. receiver 2 already exists on the target system. After a transaction is applied to the target system. When the operating system encounters receiver 2. If you encounter the problem. When starting a data group after a switch. you need to use the IBM command DLTJRNRCV with *IGNTGTRCV specified as the value of the DLTOPT parameter. Newer MIMIX functions may only be available through this user interface. The files and objects must be initially synchronized between the systems participating in replication. all replication jobs for all data groups. the STRMMX and ENDMMX commands are preferred because they ensure that processes are started or ended in the appropriate order. While other commands are available to perform these functions individually. Journaling must be active for the database files and objects configured for user journal replication. as well as the master monitor and jobs that are associated with it. At least one communications link must be in place for each pair of systems between which replication will occur. day-to-day operations for MIMIX can be performed from either the web-based MIMIX Availability Manager or from a 5250 emulator. the following requirements must be met through the installation and configuration processes: • • • • • • MIMIX software must be installed on each system in the MIMIX installation. These commands provide the flexibility to start or end selected processes and apply sessions associated with a data group. These commands include MIMIX services and manager jobs. the object auditing environment must be set up. and data groups to monitor. see the Using MIMIX book. MIMIX Availability Manager is easy to use and preferable for daily operations. In the following paragraphs. installations. The Start MIMIX (STRMMX) and End MIMIX (ENDMMX) commands provide the ability to start and end all elements of a MIMIX environment. 40 . only 5250 command names are used for simplicity. Once MIMIX is configured and files and objects are synchronized. For more information about both sets of commands. The corresponding windows have the same names as the commands to which they pass information. For objects to be replicated from the system journal. Support for starting and ending replication MIMIX Availability Manager and the 5250 emulator can be used to start and end replication.Operational overview Before replication can begin. The Start Data Group (STRDG) and End Data Group (ENDDG) commands operate at the data group level to control replication processes. Through preferences. individuals have the ability to customize what systems. which can be helpful for balancing workload or resolving problems. The MIMIX operating environment must be configured and be available on each system. By using function keys. and Services. refer to the Using MIMIX book. The initial view summarizes replication errors and the status of user journal (database) and system journal (object) processes for both source and target systems. Audits and Notification. Detailed status: When checking detailed status for a data group. Problems that cannot be resolved are reported like any other replication error. Color and informational messages identify the most severe problem present in an area and identify the action to take to start problem isolation. Many options are available for taking action at the data group level and for drilling into detailed status information. Error recovery during replication: MIMIX AutoGuard also provides the ability to have MIMIX check for and correct common problems during user journal and system journal replication that would otherwise cause a replication error. the MIMIX Availability Status display reports the prioritized status of a single installation. Support for automatically detecting and resolving problems The functions provided by MIMIX AutoGuard are fully integrated into MIMIX user interfaces. Status icons and flyover text start the problem resolution process by guiding you to the appropriate action for the most severe problem present.Operational overview Support for checking installation status Only MIMIX Availability Manager provides the ability to monitor multiple installations of MIMIX at once from a single interface. For detailed information about MIMIX AutoGuard. Status from each installation ‘bubbles up’ to the Enterprise View. Audits can also be invoked manually and automatic recovery can be optionally disabled. you can display additional detailed views of only database or only object status. The Data Group Status window in MIMIX Availability Manager and the Work with Data Groups (WRKDG) display provide status of replication jobs and indication of any replication errors for the data groups within an installation. From a 5250 emulator. The Work with Audits display (WRKAUD) provides a summary view for audit status and a compliance view for adherence to auditing best practices. These audits check for common problems and automatically correct any detected problems within a data groups. MIMIX Availability Manager provides significant benefits over 5250 emulator commands. Automatic recovery can be optionally disabled. where you can quickly see whether a problem exists on the systems you are monitoring. Status from the installation is reported in three areas: Replication. Similar windows exist in MIMIX Availability Manager. the command DSPDGSTS (option 8 from the Work with Data groups display) accesses the Data Group Status display. 41 . Audits: MIMIX ships with a set of audits and associated audit monitors that are automatically scheduled to run daily. In the 5250 emulator. Support for working with data groups Data groups are central to performing day-to-day operations. Status icons or highlighted text indicates whether problems exist. 51=IFS trk entries not active. It includes information about the replication of user journal transactions. MIMIX will direct you to the correct system when this is required. including journaled files. such as on the source system where the journal resides or on the target system if the problem is related to the apply process.Status This window identifies all of the replication jobs and services jobs needed by the data group and provides their status. and spooled file activity. 13=Objects in error. performance.User Journal This window represents replication performed by user journal replication processes. and 53=Obj trk entries not active. performance. and recent activity. Options on the Work with Data Group Activity display allow you to see messages associated with an entry. Similar information is available from database views of the Data Group Status display. Data Group Details . Similar information is available from object views of the Data Group Status display. and data queues. Support for resolving problems MIMIX includes functions that can assist you in resolving a variety of problems. Object. IFS objects. or Object Tracking. You can often take action to resolve problems directly from these detailed status windows. and recent activity. IFS. Data Group Details . Depending on the type of problem. Data Group Details . MIMIX Availability Manager provides similar capabilities to those of WRKDGACT from the following windows: Data Group Details . This window displays only one type of problem at a time. Similar information is available from the merged view of the Data Group Status display. Similar information is available in the 5250 emulator when you use the following options from the Work with Data Groups display: 12=Files not active. including journal progress. data areas. DLO. Data Group Details - 42 . synchronize the entry between systems. including journal progress.Activity This window summaries activity for the selected data group that is experiencing replication problems.System Journal This window represents replication performed by system journal replication processes. You can also see an error view that identifies the reason why the object is in error. Action lists include only the appropriate choices for the problem and only those available from the system you are viewing. MIMIX Availability Manager provides superior assistance for problem resolution.System Journal.When you choose to display detailed status for a data group from MIMIX Availability Manager. and remove a failed entry with or without related entries. some problem resolution tasks may need to be performed from the system where the problem occurs. Object activity: The Work with Data Group Activity (WRKDGACT) command allows you to track system journal replication activity associated with a data group. Problems are grouped by type of activity: File. the highest priority problem that exists for the data group determines which of several possible views of the Data Group Details window will be displayed. which can help you determine the cause of an error. Data Group Details . IFS Tracking. based on the activity type selected from the navigation bar. You can see the object. MIMIX will attempt a third retry cycle using the settings from the Number of third delay/retries (OBJRTY) and Third retry interval (min. system journal replication processes may encounter object requests that cannot be processed due to an error. thereby delaying the retry attempt until a time when it is more likely to succeed. Data Group Details Activity. it is not always possible to determine this until the failed system has been recovered. Files on hold: When the database apply process detects a data synchronization problem. However. Default filtering options in MIMIX Availability Manager only display problems with replicating objects from the system journal. Even if the 43 . When the Automatic object recovery policy is enabled.User Journal. From the Work with Data Group Activity or Work with Data Group Activity Entries displays. you can view and work with the entry for which the error was detected and work with all other entries following the entry in error. MIMIX Availability Manager supports manually retrying activities from appropriate windows by providing Retry as an available action in the Action List. and File Activity Details. and Object Activity Details. Some errors may require user intervention. you can see the status of an entry and use a number of options to assist in resolving the error. You can manually request that MIMIX retry processing for a data group activity entry that has a status of *FAILED. it places the file (individual member) on “error hold” and logs an error. This option calls the Retry Data Group Activity Entries (RTYDGACTE) command. you can use the retry option to resubmit individual failed entries or all of the entries for an object. File entries are in held status when an error is preventing them from being applied to the target system. An alternative view shows the database error code and journal code. Often the error is due to a transient condition. These entries can be viewed using the Work with Data Group Activity (WRKDGACT) command.Operational overview Activity. The WRKDGFEHLD command allows you to work with file entries that are in a held status.) (OBJRTYITV) policies. From the Work with Data Group Activity display. requests may still result in a Failed status. you can also specify a time at which to start the request. such as a never-ending process that holds a lock on the object. failed entries can be resubmitted and they will succeed. Default filtering options in MIMIX Availability Manager only display problems with replicating objects from the user journal. When this option is selected from the target system. Available options include access to the Work with DG Files on Hold (WRKDGFEHLD) command. when the system that is the source of replicated data fails. You need to analyze the cause of the problem in order to determine how to correct and release the file and ensure that the problem does not occur again. Although MIMIX will attempt some automatic retries. such as when an object is in use by another process at the time the object retrieve process attempts to gather the object data. In many cases. it is possible that some of the generated journal entries may not have been transmitted to or received by the target system. MIMIX Availability Manager provides similar capabilities to those of WRKDGFEHLD from the following windows: Data Group Details . From the Work with DG File Entries display. Journal analysis: With user journal replication. An option on the Work with Data Groups display provides quick access to the subset of file entries that are in error for a data group. These policies can be set for the installation or adjusted for a specific data group. Failed requests: During normal processing. In an unplanned switch. For additional information about switching. In either case. Once the source system is available again. see the Using MIMIX book. When you perform a planned switch. The SWTDG command supports both planned and unplanned switches. You can only perform journal analysis on the system where a journal resides. You may need to take the system offline to perform maintenance on its hardware or software. In a planned switch. you can use the journal analysis function to help determine what journal entries may have been missed and to which files the data belongs. you perform a switch using the MIMIX Switch Assistant or by using commands to call a customized implementation of MIMIX Model Switch Framework. the production system (the source of replication) is available. damage to a disk unit or to the journal itself may prevent an accurate analysis of any missed data. you must run the SWTDG command from the target system. “Journal definition considerations” on page 184 contains examples of how to set up these journal definitions. You can specify whether to end the RJ link during a switch. the Switch Data Group (SWTDG) command is called programmatically to change the direction in which replication occurs between systems defined to a data group. if there is no damage to the disk unit or journal and its associated journal receivers. For additional information about MIMIX Model Switch Framework. To enable a switchable data group to function properly for default user journal replication processes.failed system is recovered. Most likely the production system is no longer available. In a planned switch. The next time you start the data group. Support for switching a data group Typically. you should be aware of how MIMIX supports unconfirmed entries and the state of the RJ link following a switch. When you perform an unplanned switch. For more information. 44 . The next time you start the data group. see the Using MIMIX Monitor book. see “Support for unconfirmed entries during a switch” on page 67 and “RJ link considerations when switching” on page 67. Default behavior for a planned switch is to leave the RJ link running. Once you have a properly configured data group that supports switching. data group processing is ended on both the source and target systems. it will be set to replicate in the opposite direction. you are purposely changing the direction of replication for any of a variety of reasons. Default behavior during an unplanned switch is to end the RJ link. four journal definitions (two RJ links) are required. it will be set to replicate in the opposite direction. Data group processing is ended on the target system. or you may be testing your disaster recovery plan. data areas and data queues that are replicated through the user journal will not be detected by journal analysis. Missed transactions for IFS objects. you are changing the direction of replication as a response to a problem. However. placing messages into the message log file secures a second level of information concerning MIMIX operations. The system manager deletes entries from the message log file based on the value of the Keep system history parameter in the system definition. These messages are sent to both the primary and secondary message queues that are specified for the system definition. 45 . On a network system. The MIMIX message log provides a powerful tool for problem determination. MIMIX automatically performs cleanup of the message log on a regular basis. When messages are issued. if you process an unusually high volume of replicated data. the message log provides robust subset and filter capabilities. Maintaining a message log file allows you to keep a record of messages issued by MIMIX as an audit trail.Operational overview Support for working with messages MIMIX sends a variety of system message based on the status of MIMIX jobs and processes. and a powerful debug tool. In addition. The system manager is responsible for collecting messages from all network systems. the ability to locate and display related job logs. you may want to also periodically delete unnecessary message log entries since the file grows in size depending on the number of messages issued in a day. they are initially sent to the specified primary and secondary message queues. The message log on the management system contains messages from the management system and each network system defined within the installation. the message log contains only those messages generated by MIMIX activity on that system. In addition to these message queues. You can view messages generated by MIMIX from either the Message Log window or from the Work with Message Log (WRKMSGLOG) display. In the event that these message queues are erased. message entries are recorded in a MIMIX message log file. “Cooperative processing introduction” on page 49 describes three variations available for performing replication activities using a coordinated effort between user journal processing and system journal processing. MIMIX uses a series of processes. • Configuration choices determine the degree of cooperative processing used between the system journal and user journal replication paths when replicating files. • The user journal replication path captures changes to critical files and objects configured for replication through the user journal using the IBM i remote journaling function. The system journal replication path handles replication of critical system objects (such as user profiles or spooled files). data areas. and data queues. “User journal replication of IFS objects. and document library object (DLOs) using the IBM i system journal. data queues” on page 69 describes a technique which allows replication of changed data for certain object types through the user journal.Replication process overview CHAPTER 2 Replication process overview In general terms. represent the critical path on which data to be replicated moves from its origin to its destination. In previous versions MIMIX Object Replicator provided this function. data areas. In previous versions. a replication path is a series of processes that. This chapter describes the replication paths and the processes used in each. The topics in this chapter include: • “Replication job and supporting job names” on page 47 describes the replication paths for database and object information. “System journal replication” on page 51 describes the system journal replication path which is designed to handle the object-related availability needs of your system through system journal processing. MIMIX uses two replication paths to accommodate differences in how replication occurs for databases and objects. MIMIX DB2 Replicator provided this function. “Lesser-used processes for user journal replication” on page 73 describes two lesser used replication processes. Included is a table which identifies the replication job names for each of the processes that make up the replication path. IFS objects. integrated file system (IFS) objects. “User journal replication” on page 58 describes remote journaling and the benefits of using remote journaling with MIMIX. Within each replication path. • • • • • 46 . together. MIMIX source-send processing for database replication and the data area poller process. These paths operate with configurable levels of cooperation or can operate independently. The replication path for object information includes the object send process. 3 1.Replication job and supporting job names Replication job and supporting job names The replication path for database information includes the IBM i remote journal function. For more information. or renames an object. 3 1. MIMIX automatically restarts the jobs in Table 3 to maintain the MIMIX environment. 3 ---3 1. the replication path also includes the object retrieve. and one or more database apply processes. 3 3 3. When a data retrieval request is replicated. 3 3 1. the object receive process. see “Configuring restart times for MIMIX jobs” on page 285. 2 Abbreviation CNRRCV CNRSND DAPOLL DBAPY DBRCV DBRDR DBSND JRNMGR MXCOMMD MXOBJSELPR OBJAPY OBJRTV OBJSND OBJRCV STSSND SYSMGR 47 .). Table 3. then the processes include the database send process. A data retrieval request is an operation that creates or changes the content of an object. or that changes the authority or ownership of an object. The default is to restart these MIMIX jobs daily at midnight (12:00 a. the database receive process. and the object apply process. 3 1. If MIMIX source-send processes are used instead of remote journaling. A self-contained request is an operation that deletes. 3 1. and one or more database apply processes. Except as noted. 4 1. and container receive processes. moves. MIMIX processes and their corresponding job names Description Container receive process Container send process Data area polling Database apply process Database receive process Database reader Database send process Journal manager MIMIX Communications Daemon Object selection process Object apply process Object retrieve process Object send process Object receive process Status send System manager Runs on Target Source Source Target Target Target Source System System System Target Source Source Target Target System Job name sdn_CNRRCV sdn_CNRSND sdn_DAPOLL sdn_DBAPYs sdn_DBRCV sdn_DBRDR sdn_DBSND JRNMGR MXCOMMD MXOBJSELPR sdn_OBJAPY sdn_OBJRTV sdn_OBJSND sdn_OBJRCV sdn_STSSND SM******** Notes 1. 3 1. the MIMIX database reader process. container send.m. you can configure a different time to restart the jobs. Table 3 identifies the job names for each of the processes that make up the replication path. If this time conflicts with scheduled workloads. 3. The ******** in the job name format indicates the name of the system definition. 5 Abbreviation SYSMGRRCV STSRCV TEUPD Note: 1. Send and receive processes depend on communication. The alias is defined on the service table entry. 4. (Continued) MIMIX processes and their corresponding job names Description System manager receive process Status receive Tracking entry update process Runs on Network Source Source or Target Job name SR******** sdn_STSRCV sdn_TEUPD Notes 1. 2. 3 3. The characters sdn in a job name indicate the short data group name. The system manager runs on both source and target systems. OptiConnect job names start with APIA* in the QSOC subsystem.Table 3. 48 . The SNA job name is derived from the remote location name. 2 1. TCP/IP uses a job name port number or alias as the job name. The character s is the apply session letter. depending on the transfer protocol. The job is used only for replication with advanced journaling and is started only when needed. The job name varies. 5. cooperative processing enables MIMIX to perform replication in the most efficient way by evaluating the object type and the MIMIX configuration to determine whether to use the system journal replication processes. user journal replication processes. data areas.Cooperative processing introduction Cooperative processing introduction Cooperative processing is when the MIMIX user journal processes and system journal processes work in a coordinated effort to perform replication activities for certain object types. any PF-DTA or PF38-DTA files properly configured for cooperative processing will be replicated using legacy cooperative processing. In all variations of cooperative processing. All other types of files are processed using system journal replication. and high availability by ensuring the complete replication of newly created or redefined files and objects. or data queues that can be journaled are not automatically configured for advanced journaling. the system journal is used to replicate the following operations: • • • The creation of new objects that do not deposit an entry in a user journal when they are created. any logical files and physical (source and data) files properly identified for cooperative processing will be processed via MIMIX Dynamic Apply unless a known restriction prevents it. Restores of objects on the source system Move and rename operates from a non-replicated library or path into a library or path that is configured for replication. When a data group definition meets the requirements for MIMIX Dynamic Apply. When a data group definition does not meet the requirements for MIMIX Dynamic Apply but still meets legacy cooperative processing requirements. MIMIX supports the following variations of cooperative processing for these object types: • • • MIMIX Dynamic Apply (files) Legacy cooperative processing (files) Advanced journaling (IFS objects. Object types that can be journaled to a user journal are eligible to be processed cooperatively when properly configured to MIMIX. MIMIX Dynamic Apply is the most efficient way to perform cooperative processing of logical and physical files. or a combination of both. MIMIX Dynamic Apply Most environments can take advantage of cooperatively processed operations for journaled *FILE objects that are journaled primarily through a user (database) journal. IFS objects. data management efficiency. MIMIX Dynamic Apply intelligently handles files with 49 . data areas. Cooperative processing also provides a greater level of data protection. and data queues). These object types must be manually configured to use advanced journaling. When configured. by default. data areas. and data queues” on page 79. while all other transactions are replicated through system journal processes. and restore processes necessary for system replication. record and member operations of *FILE objects are replicated through user journal processes. data areas. Another benefit of MIMIX Dynamic Apply is more efficient hold log processing by enabling multiple files to be processed through a hold log instead of just one file at a time. It is recommended to use MIMIX Dynamic Apply for cooperative processing. This is more efficient than replicating an entire object through the system journal each time changes occur. or data queues that are configured for cooperative processing. This configuration requires data group object entries and data group file entries. For more information. send. For more information. Existing data groups configured to use legacy cooperative processing can be converted to use MIMIX Dynamic Apply. and renames. and data queues with database journal entries. data areas. data areas. Legacy cooperative processing supports only data files (PF-DTA and PF38-DTA). New data groups created with the shipped default configuration values are configured to use MIMIX Dynamic Apply. even for equal amounts of data. Legacy cooperative processing In legacy cooperative processing. see “User journal replication of IFS objects. see “Requirements and limitations of legacy cooperative processing” on page 102. When these objects are configured for cooperative processing. These terms are the same. and data queues” used interchangeably with the term advanced journaling. see “Identifying logical and physical files for replication” on page 96 and “Requirements and limitations of MIMIX Dynamic Apply” on page 101. deletes. In addition. moves. 50 . Advanced journaling The term advanced journaling refers to journaled IFS objects. replication of changed bytes of the journaled objects’ data occurs through the user journal.relationships by assigning them to the same or appropriate apply sessions. processing time for these object types may be reduced. data queues” on page 69 and “Planning for journaled IFS objects. Such a configuration also allows for the serialization of updates to IFS objects. Data groups that existed prior to upgrading to MIMIX version 5 are typically configured with legacy cooperative processing which requires data group object entries and data group file entries. Frequently you will see the phrase “user journal replication of IFS objects. data areas. For more information. as user journal replication eliminates the separate save. It is also much better at maintaining data integrity of replicated objects which previously needed legacy cooperative processing in order to replicate some operations such as creates. Object receive process: receives control information and waits for notification that additional source system processing. programs. or system journal). is complete before passing the control information to the object apply process. If any data group is configured to replicated spooled files. *OBJMGT. when you use MIMIX commands to build the journaling environment. The system journal replication path in MIMIX uses the following processes: • Object send process: alternates between identifying objects to be replicated and transmitting control information about objects ready for replication to the target system. MIMIX also sets *SPLFDTA and *PRTDTA. MIMIX uses the journal entries generated by the operating system’s object auditing function to identify the changes to objects on production systems and replicates the changes to backup systems. MIMIX is not aware of the operation and cannot replicate it. or renamed into the MIMIX name space. When a data group is started. and data group IFS entries. You identify the critical system objects that you want to replicate. moved. and *SAVRST. • • 51 . data group DLO entries. MIMIX sets the values *CREATE. MIMIX creates the journal and correctly sets system values related to auditing. While in the MIMIX name space. MIMIX checks for values *SECURITY. MIMIX checks the settings of the following system values. If you are not already using the system’s security audit journal (QAUDJRN. if any. such as user profiles. each process used in the replication path waits for its predetermined event to occur then begins its activity.System journal replication System journal replication The system journal replication path is designed to handle the object-related availability needs of your system. along with the object audit value of each object. • These system value settings. obtains it and places it in a holding area. control what journal entries are created in the system journal (QAUDJRN) for an object. MIMIX sets the values *OBJAUD and *AUDLVL. QAUDCTL (Auditing control) system value. The processes are interdependent and run concurrently. and *SECVLDL and will set them only if the value *SECURITY is not already set. Replication through the system journal is event-driven. restored. *SECRUN. making changes as necessary: • QAUDLVL (Security auditing level) system value. *DELETE. *SECCFG. An object is replicated when it is created. Object retrieve process: if any additional information is needed for replication. and DLOs. changes to the object or to the authority settings of the object are also replicated. This process is also used when additional processing is required on the source system prior to transmission to the target system. If an operation on an object is not represented by an entry in the system journal. The system objects you want to replicate are defined to a data group through data group object entries. The term name space refers to this collection of objects that are identified for replication by MIMIX using the system journal replication processes. Status send process: notifies the source system of the status of the replication. An activity entry includes a copy of the journal entry and any related information associated with a replication operation for an object. The structures in the work log consist of log spaces. There are two categories of activity entries: those that are self-contained and those that require the retrieval of additional information. it performs the following actions: • • • Sets the status of the entry to PA (pending apply) Adds the “sent” date and time to the activity entry Writes the activity entry to the log space and adds a record to the distribution status file 52 . including the status of the entry. User interaction with activity entries is through the Work with Data Group Activity display and the Work with DG Activity Entries display. a corresponding journal entry is created in the security audit journal. passes control information back to the object send process. the object send process creates an activity entry in the work log. the object send process reads journal entries and determines if they represent operations to objects that are within the name space. Processing self-contained activity entries For a self-contained activity entry. MIMIX uses a collection of structures and customized functions for controlling these structures during replication. the copied journal entry contains all of the information required to replicate the object. work lists (implemented as user queues). and distribution status file. After the object send process determines that an entry is to be replicated. “Processing data-retrieval activity entries” on page 53 describes the object replication scenario in which additional data must be retrieved from the source system and sent to the target system. Creation of an activity entry includes adding the entry to the log space and adding a record to the distribution status file. such as it is being accessed or changed. Object apply process: replicates objects according to the control information and any required additional information that is retrieved from the holding area. For each journal entry for an object within the name space. Container receive process: receives any additional information and places it into a holding area on the target system. “Processing self-contained activity entries” on page 52 describes the simplest object replication scenario.• • • • • Container send process: transmits any additional information from a holding area to the target system and notifies the control process of that action. Collectively the customized functions and structures are referred to as the work log. When a data group is started. Status receive process: updates the status on the source system and. Examples of journal entries include Change Authority (T-CA). if necessary. MIMIX uses the security audit journal to monitor for activity on objects within the name space. Object Move or Rename (T-OM). As journal entries are added to the journal receiver on the source system. When activity occurs on the object. and Object Delete (T-DO). The status receive process updates the activity entry in the work log and the distribution status file. Processing data-retrieval activity entries In a data retrieval activity entry. changes the status of the entry to CP (completed processing). adds a record to the distribution status file. writes the activity entry to the log space. Now each system has a copy of the activity entry. The actual content of the change is not recorded in the journal entry. must be retrieved and transmitted to the target system. 53 . Now each system has a copy of the activity entry. The object receive process adds the “received” date and time to the activity entry. The object apply process adds the “applied” date and time to the activity entry.System journal replication • Transmits the activity entry to a corresponding object receive process job on the target system. The status send process retrieves the activity entry from the status send work list and transmits the updated entry to a corresponding status receive process on the source system. or both. these objects in the data library are known as containers. it performs the following actions: • • • • • Sets the status of the entry to PR (pending retrieve) Adds the “sent” date and time to the activity entry Writes the activity entry to the log space and adds a record to the distribution status file Transmits the activity entry to a corresponding object receive process on the target system. writes the activity entry to the log space. The object receive process adds the “received” date and time to the activity entry. Save commands store the object data in a save file (*SAVF) in the data library. To properly replicate the object. After the object send process determines that an entry is to be replicated and that additional processing or information on the source system is required. The object receive process waits until the source system processing is complete before it adds the activity entry to the object apply work list. and places the activity entry on the object apply work list. Collectively. The copied journal entry indicates that changes to an object affect the attributes or data of the object. additional data must be gathered from the object on the source system in order to replicate the operation. APIs store the data in one or more user spaces (*USRSPC) in a data library associated with the MIMIX installation. MIMIX may retrieve this data by using APIs or by using the appropriate save command for the object type. and adds a record to the distribution status file. The next available object apply process job for the data group retrieves the activity entry from the object apply work list and replicates the operation represented by the entry. attributes. and adds the entry to the status send work list. its content. Adds the entry to the object retrieve work list on the source system. the object send process reads the object send work list. such as if an updated container is needed on the target system. then adds the “container sent” date and time to the activity entry. The status receive process updates the activity entry in the log space and the distribution status file. If necessary. which may be to send the entry to the target system. The object apply process adds the “applied” date and time to the activity entry. The object identified by the activity entry is packaged into a container in the data library. 54 . If the activity entry requires further processing. The container receive process places the container in a data library on the target system. its status is updated. The container send job transmits the container to a corresponding job of the container receive process on the target system. changes the status of the entry to CP (completed processing). From there the object send job takes the appropriate action for the activity. The next available job for the container send process for the data group retrieves the activity entry from the container send work list and retrieves the container for the packaged object from the data library.” The activity entry is added to the object send work list. cooperative processing activities.Concurrently. and adds the entry to the object send work list. the activity entry is routed to the container send work list. are performed. This may be one step in retrieving the object or it may be the primary function required of the retrieve process. The object retrieve process may perform some or all of the following steps: • • • Retrieve the extended attribute of the object. and a “retrieved” date and time is added to the activity entry. When the object send process finds an activity entry in the object send work list. On the source system the next available object retrieve process for the data group retrieves the activity entry from the object retrieve work list and processes the referenced object. The activity entry is transmitted to the target system. • The container send and receive processes are only used when an activity entry requires information in addition to what is contained within the journal entry. and adds the entry to the status send work list. the object send process performs one or more of the following additional steps on the entry: • • If an object retrieve job packaged the object. add the entry to the container send work list. the status receive job adds the entry to the object send work list. In addition to retrieving additional information for the activity entry. locates the container for the object in the data library. The object retrieve process adds the “retrieved” date and time to the activity entry and changes the status of the entry to “pending send. The next available object apply process job for the data group retrieves the activity entry from the object apply work list. and replicates the operation represented by the entry. The status send process retrieves the activity entry from the status send work list and transmits the updated entry to a corresponding job for status receive process on the source system. such as adding or removing a data group file entry. changes the status of the activity entry to PA (pending apply). The container send process waits for confirmation from the container receive job. or both. additional processing may be required on the source system. Regular monitoring and timely responses to error conditions significantly reduce the amount of time and effort required in the event that you need to switch a data group. and object apply processes all consist of one or more asynchronous jobs. During periods of peak activity. and the associated failed entries. you need to monitor the status of the replication processes and respond to any error conditions. MIMIX provides an indication of high level status of the processes used in object replication and error conditions. Managing object auditing 55 . You can also subset directly to the activity entries in error from the Work with Data Groups display. up to the maximum number. These jobs stay active as long as the data group is active. and determine the appropriate action. By doing this. the activity entry may go to a failed state. You can access detailed status information through the Data Group Status window in MIMIX Availability Manager or the MIMIX Availability Status display in a 5250 emulator. You may retry or delete one or all of the failed entries for an object. The minimum number indicates how many permanent jobs should be started for the process. You can check the progress of activity entries and take corrective action through the Work with Data Group Activity display and the Work with DG Activity Entries display. Before any new data group entries can be replicated. the temporary jobs end after a period of inactivity elapses. you need to add data group entries for them. additional temporary jobs. This load leveling feature allows system journal replication processes to react automatically to periodic heavy workloads. Objects with at least one failed entry outstanding are considered to be “in error. The system manager removes old activity entries from the work log on each system after the time specified in the system definition passes. if more requests are backlogged than are specified in the threshold. If you have new objects to replicate that are not within the MIMIX name space. you must end and restart the system journal replication processes in order for the changes to take effect. but some failures require manual intervention.” You should periodically review the objects in error. When system activity returns to a reduced level. You can specify the minimum and maximum number of asynchronous jobs you want to allow MIMIX to run for each process and a threshold for activating additional jobs. MIMIX attempts to rectify many failures automatically. the replication process stays current with production system activity. Containers in the data libraries are deleted after the time specified in the Keep MIMIX data (days) parameter (KEEPMMXDTA). The Keep data group history (days) parameter (KEEPDGHST) indicates how long the activity entries remain on the system. may also be started. container send and receive. When an operation cannot complete on either the source or target system (such as when the object is in use by another process and cannot be accessed). Tracking object replication After you start a data group. You can also manually delete activity entries.System journal replication Processes with multiple jobs The object retrieve. To ensure that objects configured for this replication path retain an object auditing value that supports replication. The OBJAUD parameter supports object audit values of *ALL. When the command is invoked.Regardless of how the object auditing evaluation is invoked. Data group entries are processed in order from most generic to most specific. This evaluation process can also be invoked manually for all objects identified for replication by a data group.The system journal replication path within MIMIX relies on entries placed in the system journal by IBM i object auditing functions. During replication . Otherwise. restored. Evaluation processing . MIMIX evaluates and changes the objects’ auditing value when necessary. The SETDGAUD command also supports optionally forcing a change to a configured value that is lower than the existing value through its Force audit value (FORCE) parameter. IFS. If you would rather set the auditing level for replicated objects yourself. When MIMIX determines that an object’s auditing value is lower than the configured value. MIMIX evaluates and may change an object’s auditing value when specific conditions exist during object replication or during processing of a Start Data Group (STRDG) request. moved. Invoking manually . To do this. or library-based). it changes the object to have the higher configured value specified in the data group entry that is the closest match to the object. The SETDGAUD command is used during initial configuration of a data group. DLO. DLO) configured for the system journal replication path. or DLO). MIMIX employs a configuration value that is specified on the Object auditing value (OBJAUD) parameter of data group entries (object. or renamed into the MIMIX name space (the group of objects defined to MIMIX). MIMIX may find that an object is identified by more than one data group entry within the same class of object (IFS. *CHANGE. IFS entries are processed using the unicode character set.MIMIX may change the auditing value during replication when an object is replicated because it was created. or *NONE. IFS. It is important to understand the order of precedence for processing data group entries.MIMIX may change the auditing value while processing a STRDG request if the request specified processes that cause object send (OBJSND) jobs to start and the request occurred after a data group switch or after a configuration change to one or more data group entries (object.The Set Data Group Auditing (SETDGAUD) command provides the ability to manually set the object auditing level of existing objects identified for replication by a data group. MIMIX checks the audit value of existing objects identified for system journal replication. While starting a data group . it is not necessary for normal operations and should only be used under the direction of a trained MIMIX support representative. Shipped command defaults for the STRDG command allow MIMIX to set object auditing if necessary. you can specify *NO for the Set object auditing level (SETAUD) parameter when you start data groups. object entries and DLO entries 56 . Shipped default values on the command cause MIMIX to change the object auditing value of objects to match the configured value when an object’s actual value is lower than the configured value. System journal replication are processed using the EBCDIC character set. The entry that most specifically matches the object is used to process the object. When MIMIX processes a data group IFS entry and changes the auditing level of objects which match the entry. In the case of an IFS entry with a generic name. all descendents of the IFS object may also have their auditing value changed. if necessary. all of the directories in the object’s directory path are checked and. For more information and examples of setting auditing values with the SETDGAUD command. For example. see “Setting data group auditing values manually” on page 270. MIMIX sets object auditing for all objects identified by the data group’s DLO entries. 57 . When you change a data group entry. but not for its object entries or IFS entries. it is set to the configured auditing value specified in the data group entry that most specifically matches the object. MIMIX updates all objects identified by the same type of data group entry in order to ensure that auditing is set properly for objects identified by multiple entries with different configured auditing values. The first entry (more generic) found that matches the object is used until a more specific match is found. if a new DLO entry is added to a data group. changed to the new auditing value. If the object has a lower audit value. Newly created data groups use remote journaling as the default configuration. The MIMIX Remote Journal support allows MIMIX to take advantage of the cross-journal communications functions provided by the IBM i remote journal function instead of using the internal communications provided by MIMIX.User journal replication MIMIX Remote Journal support enables MIMIX to take advantage of the cross-journal communications capabilities provided by the IBM i remote journal function instead of using internal communications. After the journals and journal receivers are established on both systems. You can find these books online at the IBM eServer iSeries Information Center. If the 58 . “The benefits of remote journal function include: • It lowers the CPU consumption on the source machine by shifting the processing required to receive the journal entries from the source system to the target system. What is remote journaling? Remote journaling is a function of the IBM i that allows you to establish journals and journal receivers on a target system and associate them with specific journals and journal receivers on a source system. the remote journal function can replicate journal entries from the source system to the journals and journal receivers located on the target system. Benefits of using remote journaling with MIMIX MIMIX has internal send and receive processing as part of its architecture. As stated in the AS/400 Remote Journal Function for High Availability and Data Replication redbook. This realtime operation is called the synchronous delivery mode. The remote journal function supports both synchronous and asynchronous modes of operation. This is true when asynchronous delivery is selected. it significantly improves the replication performance of journal entries and allows database images to be sent to the target system in realtime. More information about the benefits and implications of each mode can be found in topic “Overview of IBM processing of remote journals” on page 60. The IBM redbooks AS/400 Remote Journal Function for High Availability and Data Replication (SG24-5189) and Striving for Optimal Journal Performance on DB2 Universal Database for iSeries (SG24-6286) provide an excellent overview of remote journaling in a high availability environment. You should become familiar with the terminology used by the IBM i remote journal function. • It eliminates the need to buffer journal entries to a temporary area before transmitting them from the source machine to the target machine. This translates into less disk writes and greater DASD efficiency on the source system. • Since it is implemented in microcode. The Backup and Recovery and Journal management books are good sources for terminology and for information about considerations you should be aware of when you use remote journaling. the journal entries are guaranteed to be in main storage on the target system prior to control being returned to the application on the source machine. Users who require this type of environment may use multiple installations of MIMIX. implementing apply side journaling in one installation and using remote journaling to replicate the applied transactions to a third system.” Restrictions of MIMIX Remote Journal support The IBM i remote journal function does not allow writing journal entries directly to the target journal receiver. 59 . the resource utilization on the source machine can be reduced. MIMIX user journal replication does not support a cascading environment in which remote journal receivers on the target system are also source journal receivers for a third system. • It allows the journal receiver save and restore operations to be moved to the target system. This restriction severely limits the usefulness of cascading remote journals in a managed availability environment. This way.User journal replication synchronous delivery mode is used. When the source system receives notification of the delivery to the target journal receiver. When the remote journal function is activated and all journal entries from the source are requested. This is known as catchup mode. A local-remote journal pair refers to the relationship between a configured source journal and target journal.Overview of IBM processing of remote journals Several key concepts within the IBM i remote journal function are important to understanding its impact on MIMIX replication. the journal entry is placed in the source journal receiver (2) and the source database is updated (3). Once the existing journal entries are delivered to the target system. Each journal entry is first replicated to the target journal receiver in main memory on the target system (1 in Figure 3). The key point about a local-remote journal pair is that data flows only in one direction within the pair. journal entries that have been written to memory on the target system are considered unconfirmed entries until they have been written to 60 . the system begins sending new entries in continuous mode according to the delivery mode specified when the remote journal function was started. With synchronous delivery. existing journal entries for the specified journal receiver on the source system which have not already been replicated are replicated as quickly as possible. New journal entries can be delivered either synchronously or asynchronously. Synchronous delivery In synchronous delivery mode the target system is updated in real time with journal entries as they are generated by the source applications. from source to target. The source applications do not continue processing until the journal entries are sent to the target journal. 61 . Source System Applications 2 Source Journal Receiver (Local) 3 Production Database 1 Source Journal Message Queue 4 Target Journal Receiver (Remote) Target System Target Journal Message Queue Unconfirmed journal entries are entries replicated to a target system but the state of the I/O to auxiliary storage for the same journal entries on the source system is not known. a minimum of a dedicated 100 megabyte ethernet connection is recommended for synchronous remote journaling. Once the confirmation is received. Confirmed journal entries are entries that have been replicated to the target system and the I/O to auxiliary storage for the same journal entries on the source system is known to have completed. They are held in the data portion of the target journal receiver. There is some performance impact to the application when it is moved from asynchronous mode to synchronous mode for high availability purposes. Unconfirmed entries only pertain to remote journals that are maintained synchronously. the entries are considered confirmed journal entries. Since delivery is synchronous to the application layer.auxiliary storage on the source system and confirmation of this is received on the target system (4). In general. These entries are not processed with other journal entries unless specifically requested or until confirmation of the I/O for the same entries is received from the source system. the most recent copy of the data is on the target system. If the source system becomes unavailable. there are application performance and communications bandwidth considerations. Synchronous mode sequence of activity in the IBM remote journal feature. Confirmation typically is not immediately sent to the target system for performance reasons. This impact can be minimized by ensuring efficient data movement. With synchronous delivery. you can recover using data from the target system. Figure 3. An independent job sends the journal entries from a buffer (C) to the target system journal receiver (D) at some time after control is returned to the source applications that generated the journal entries. Default values used in configuring MIMIX for remote journaling use asynchronous delivery. Asynchronous delivery In asynchronous delivery mode. Performance critical applications frequently use asynchronous delivery. the most recent copy of the data is on the source system. Because the journal entries on the target system may lag behind the source system’s database. Source System Applications A Source Journal Receiver (Local) B Production Database C Source Journal Message Queue Buffer Target System D Target Journal Message Queue Target Journal Receiver (Remote) With asynchronous delivery. in the event of a source system failure. entries may become trapped on the source system. 62 . Asynchronous mode sequence of activity in the IBM remote journal feature. Figure 4. the journal entries are placed in the source journal first (A in Figure 4) and then applied to the source database (B). For more information.MIMIX includes special switch processing for unconfirmed entries to ensure that the most recent transactions are preserved in the event of a source system failure. This delivery mode is most similar to the MIMIX database send and receive processes. see “Support for unconfirmed entries during a switch” on page 67. User journal replication processes Data groups created using default values are configured to use remote journaling support for user journal replication. The database reader process performs the filtering that is identified in the data group definition parameters and file and tracking entry options. The replication path for database information includes the IBM i remote journal function. Once an RJ link is defined and other configuration elements are properly set. The Work with RJ Links display makes it easy to identify the state of the IBM i remote journaling environment defined by the RJ link. The RJ link To simplify tasks associated with remote journaling. MIMIX implements the concept of a remote journal link. the MIMIX database reader process. Primary and secondary transfer definitions for the communications path for use by MIMIX. user journal replication processes will use the IBM i remote journaling environment within its replication path. The database reader process (DBRDR) process reads journal entries from the target journal receiver of a remote journal configuration and places those journal entries that match replication criteria for the data group into a log space. A “target” journal definition that defines a remote journal. Transactions are applied in real-time to generate a duplicate image of the journaled objects being replicated from the source system. The concept of an RJ link is integrated into existing commands. Whether the IBM i remote journal function sends journal entries asynchronously or synchronously. MIMIX uses multiple apply processes in parallel for maximum efficiency. Remote journaling does not allow entries to be filtered from being sent to the remote system. The IBM i remote journal function transfers journal entries to the target system. data groups should only share an RJ link if they are intended to be switched together or if they are non-switchable data groups. Otherwise. A remote journal link (RJ link) is a configuration element that identifies an IBM i remote journaling environment. However. Sharing RJ links among data groups It is possible to configure multiple data groups to use the same RJ link. An RJ link identifies: • • • • A “source” journal definition that identifies the system and journal which are the source of journal entries being replicated from the source system. The database apply process applies the changes stored in the target log space to the target system’s database. All entries deposited into the source journal will be transmitted to the target system. there is additional communications overhead from data groups replicating in opposite directions and the potential for 63 . and one or more database apply processes. The Start Remote Journal Link (STRRJLNK) and the End Remote Journal Link (ENDRJLNK) commands provide this capability. Journal entries that are already queued for transmission are not sent before the target journal is deactivated. *IMMED End option values on the End Remote Journal Link (ENDRJLNK) command. These options on the ENDRJLNK command do not have the same meaning as on the ENDDG command. Both commands include an end option (ENDOPT parameter) to specify whether to end immediately or in a controlled manner. At any time.journal entries for database operations to be routed back to their originating system. 64 . the ENDOPT parameter has the following values: Table 4. Any journal entries that are queued for transmission to the target journal will be transmitted before the IBM i remote journal function is ended. The STRDG and ENDDG commands automatically determine whether the data group uses remote journaling and select the appropriate replication path processes. Differences between ENDDG and ENDRJLNK commands You should be aware of differences between ending data group replication (ENDDG command) and ending only the remote journal link (ENDRJLNK command). as needed. Two MIMIX commands provide the ability to use an RJ link without performing data replication. including the RJ link. When the remote journal function is performing catch-up processing. The End Remote Journal Link (ENDRJLNK) command ends only the RJ link. it may take a significant amount of time to transmit the queued entries before actually ending the target journal. The target journal is deactivated immediately. the journal entries that were queued but not sent are prepared again for transmission to the target journal. *CNTRLD The ENDRJLNK command’s ENDOPT parameter is ignored and an immediate end is preformed when either of the following conditions are true: • • When the remote journal function is running in synchronous mode (DELIVERY(*SYNC)). RJ links within and independently of data groups The RJ link is integrated into commands for starting and ending data group replication (STRDG and ENDDG). the remote journal function may have one or more journal entries prepared for transmission to the target journal. See “Support for unconfirmed entries during a switch” on page 67 and “RJ link considerations when switching” on page 67 for more details. If an asynchronous delivery mode is used over a slow communications line. The next time the remote journal function is started. You will primarily use the End Data Group (ENDDG) command to end replication processes and to optionally end the RJ link when necessary. For ENDRJLNK. Once the problem is resolved. Both the source and target RJ link monitor processes appear on this display. MIMIX Monitor commands can be used to see the status of your RJ link monitors. Users can end the monitors by using the Work with Monitors (WRKMON) command and selecting the End option. RJ link monitors . The source RJ link monitor is named after the source journal definition and the target RJ link monitor is named after the target journal definition. The operating system issues messages to these journal message queues when a failure is detected in IBM i remote journal processing. each over its own remote journal link. Each RJ link monitor uses information provided in the messages to determine which remote journal link is affected and to try to automatically recover that remote journal link. The RJ link monitor for the source does not end once it is started.) There is a limit on the number of times that a link will be recovered in a particular time period. They monitor messages put on the message queues associated with the source and target journals. they will be started when you start a remote journal link. you can start the RJ link monitors again the using the Work with Monitors (WRKMON) command and selecting the Start option.operation The RJ link monitors are automatically started when the master monitor is started. The WRKMON command lists all monitors for a MIMIX installation and displays whether the monitor is active or inactive. The display shows whether or not the monitor processes are active. One source RJ link monitor handles this broadcast. the RJ link monitor status appears as unknown on the Display Data Group Status display.RJ link monitors User journal replication processes monitor the journal message queues of the journals identified by the RJ link. Typically this occurs when there are communications problems. The RJ link monitors are MIMIX message queue monitors. and to automatically recover the link when possible. in a cascade scenario an intermediate system can have both a source RJ link monitor and a target RJ link monitor running on it for the same journal definition. a continually failing link will eventually be marked failed and recovery will end. a single source journal definition can link to multiple target journal definitions. since there is one source RJ monitor per source journal definition communicating via a remote journal link. This intermediate system has the target journal definition for the system that 65 . If MIMIX Monitor is not installed as recommended. RJ link monitors in complex configurations In a broadcast scenario. These monitors provide added value by allowing MIMIX to automatically monitor the state of the remote journal link. You can also view the status of your RJ link monitors on the DSPDGSTS status display (option 8 from the Work with Data Groups display). The monitors are created if they do not already exist. Alternately. to notify the user of problems. If for some reason the monitors are not already started. since more than one remote journal link can use a source monitor. Two RJ link monitors are created automatically. (The state of a remote journal link can be seen by using the Work with RJ Links (WRKRJLNK) command. one on the source system and one on the target system. originated the replication and holds the source journal definition for the next system in the cascade. For more information about configuring for these environments. 66 . see “Data distribution and data management scenarios” on page 327. This reduces the potential for and the degree of manual intervention when an unplanned outage occurs. these repeated entries cause additional resources to be used within MIMIX and in communications. Maintaining this data on the target system is critical to your managed availability solution. the unconfirmed entries are processed before any new journal entries generated by the application are processed. In addition. MIMIX Model Switch Framework considerations . Furthermore. to ensure full data integrity. Sharing an RJ link among multiple data groups is only recommended for the conditions identified in “Sharing RJ links among data groups” on page 63. If journaling is still active on the original production database. RJ link considerations when switching By default. you will see the database apply process jobs run longer than they would under standard switch processing. however. These new journal entries are essentially a repeat of the same operation just performed against the database.Support for unconfirmed entries during a switch The MIMIX Remote Journal support implements synchronous mode processing in a way that reduces data latency in the movement of journal entries from the source to the target system. the unconfirmed entries are routed to the MIMIX database apply process to be applied to the backup database. If the RJ link is not used by any other application or data group. MIMIX applies the entries to the original production database. Whenever an RJ link failure is detected MIMIX saves any unconfirmed entries on the target system so they can be applied to the backup database if an unplanned switch is required. MIMIX checks whether the apply jobs are caught up. MIMIX prevents these repeat entries from being reapplied. The unconfirmed entries are the most recent changes to the data. default values 67 . In the event of an unplanned switch. MIMIX will restart the apply jobs to preserve these entries. If the apply process is ended by a user before the switch. Remote journaling causes the entries to be transmitted back to the backup system. Then. when a data group is ended or a planned switch occurs. As part of the unplanned switch processing. unconfirmed entries are applied to the target database and added to a journal that will be transferred to the source system when that system is brought back up. As a result. the link should be ended to prevent communications and processing overhead. When you are temporarily running production applications on the backup system after a planned switch. journal entries generated on the backup system are transmitted to the remote journal receiver (which is on the production system). When the backup system is brought online as the temporary the source system. you need to consider the implications of sharing an RJ link. the RJ link remains active. new journal entries are created for the entries that were just applied. once the original source system is operational these unconfirmed entries are the first entries replicated back to that system. If the RJ link is used by another application or data group. the RJ link must remain active.When remote journaling is used in an environment in which MIMIX Model Switch Framework is implemented. You need to consider whether to keep the original RJ link active after a planned switch of a data group. You may need to end the RJ link after a planned switch.used during a planned switch cause the RJ link to remain active. 68 . User journal replication of IFS objects. For more information. and data queues. data queues IBM provides journaling support for IFS objects as well as for data areas and data queues. data queues User journal replication of IFS objects. assume that a hotel uses a database application to reserve rooms. MIMIX replicates only changed bytes of the data for IFS objects. In addition to data group object entries and IFS entries. those using large files or making frequent small byte-level changes can be negatively impacted by the additional data transmission. A data group that replicates some or all configured IFS objects. data area. see “Planning for journaled IFS objects. This requires that the objects and database are configured to the same data group and the same database apply session. data areas. advanced journaling for IFS objects and data areas. data areas. see “Replication choices by object type” on page 88 You may need to consider how much data is replicated through the same apply session for user journal replication processes and whether any transactions need to be serialized with database files. and data queues is that transactions can be applied in lock-step with a database file. For example. and system journal processes for data queues and other library-based objects. and data queues” on page 79. the entire object is shipped across the communications link. or data queue changes. the 69 . data areas. a data group could be configured to support MIMIX Dynamic Apply for *FILE objects. For example. This support within MIMIX is often referred to as advanced journaling and is enabled by explicitly configuring data group object entries for data areas and data queues and data group IFS entries for IFS objects. Benefits of advanced journaling One of the most significant benefits of using advanced journaling is that IFS objects. Another significant benefit of using advanced journaling for IFS objects. a data area contains a counter to indicate the number of rooms reserved for a particular day and a database file contains detailed information about reservations. Each time an IFS object. data areas. This capability allows transactions to be journaled in the user journal (database journal). or data queues through a user journal may also replicate files from the same journal as well as replicate objects from the system journal. MIMIX enables you to take advantage of this capability of the IBM i when replicating these journaled objects. Each time a room is reserved. much like transactions are recorded for database record changes. data areas. data areas. If these updates do not occur in the same order on the target system. both the counter and the database file are updated. data areas. For more information. when IFS objects. While this may be sufficient for many applications. MIMIX uses tracking entries to uniquely identify each object that is configured for advanced journaling. and data queues are processed by replicating only changed bytes. only changed bytes are recorded in the journal entry. When these objects are configured to allow user journal replication. data areas. Within the application. For example. or data queues are replicated through the system journal. the MIMIX database reader process1. as long as the database file and data area are configured to be processed by the same apply session. • • • • • Restrictions and configuration requirements vary for IFS objects and data area or data queue objects. Processing time may be reduced. Database replication touches the user journal only. Additional benefits of replicating IFS objects. If one or more of the configuration requirements are not met. Changes to objects replicated from the user journal may be replicated to the target system in a more timely manner. 70 . MIMIX serializes these transactions on the target system by updating both the file and the data area through user journal processing. The objects replicated from the user journal can reduce burden on object replication processes when there is a lot of activity being replicated through the system journal. send. serialization of these transactions cannot not be guaranteed on the target system due to inherent differences in MIMIX processing from the user journal (database file) and the system journal (default for objects). the system journal replication path is used. and data queues are properly configured. In traditional object replication. even for equal amounts of data. updates occur on the target system in the same order they were originally made on the source system. Advanced journaling can be used in configurations that use either remote journaling or MIMIX source-send processes for user journal replication. For detailed information. and restore processes necessary for object replication. Database replication eliminates the separate save. and data queues from the user journal include: • Replication is less intrusive. including supported journal entry types. see “Identifying data areas and data queues for replication” on page 103 and “Identifying IFS objects for replication” on page 106. Replication processes used by advanced journaling When IFS objects.hotel risks reserving too many or too few rooms. Thus. the save/restore process places locks on the replicated object on the source system. 1. replication occurs through the user journal replication path. and one database apply process (session A). In traditional object replication. system journal replication processes must contend with potential locks placed on the objects by user applications. Processing occurs through the IBM i remote journal function. With advanced journaling. data areas. leaving the source object alone. Data groups can also be configured for MIMIX source-send processing instead of MIMIX RJ support. data areas. Commitment control is supported for B journal entry types for IFS objects journaled to a user journal. Without advanced journaling. data areas. 71 . including the source and target file ID (FID). MIMIX requires a tracking entry for each of the eligible objects to identify how it is defined for replication and to assist with tracking status when it is replicated. while object tracking entries identify data areas or data queues. It is also possible for tracking entries to be automatically created. Error messages indicate that journaling must be started and the objects must be synchronized between systems. The data group configuration changes so that an object is no longer identified for replication using advanced journaling.User journal replication of IFS objects. start journaling for the objects which they identify.This can significantly increase the amount of time needed to start a data group. MIMIX places the tracking entries in *HLDERR state. and data queue that is replicated using advanced journaling. Once a tracking entry exists. this method has disadvantanges. it remains until one of the following occurs: • • The object identified by the tracking entry is deleted from the source system and replication of the delete action completes on the target system. the collection of data group object entries determines the subset of existing data areas and data queues on the source system that are eligible for replication using advanced journaling techniques. data area. When you initially configure a data group you must load tracking entries. After creating or changing data group IFS entries or object entries that are configured for advanced journaling. and synchronize the objects with the target system. The collection of data group IFS entries for a data group determines the subset of existing IFS objects on the source system that are eligible for replication using advanced journaling techniques. However. Similarly. IFS tracking entries identify IFS stream files. tracking entries are created the next time the data group is started. The same is true when you add new or change existing data group IFS entries or object entries. If the objects you intend to replicate with advanced journaling are not journaled before the start request is made. data queues Tracking entries A unique tracking entry is associated with each IFS object. The FID is machine-specific. and the resultant list of tracking entries created by MIMIX. You can also perform operations on tracking entries. When the data group is switched. to address replication problems. Their status is included with other data group status. such as holding and releasing. and member name) in the journal entries. the include and exclude processing selected for objects within that structure. 72 . whether the objects are journaled. when dealing with objects and database files. it is impractical to put the name of the IFS object in the header of the journal entry due to potentially long path names.Figure 5 shows an IFS user directory structure. IFS object file identifiers (FIDs) Normally. library name. the source and target FID associations are reversed. The FID is used to identify IFS objects in journal entries. allowing MIMIX to successfully replicate transactions to IFS objects. meaning that IFS objects with the same path name may have different FIDs on different systems. You also can see what objects they identify. For IFS objects. you have the ability of seeing the name of the object (filename. IFS tracking entries produced by MIMIX Viewing tracking entries is supported in both 5250 emulator and MIMIX Availability Manager interfaces. Figure 5. Each IFS object on a system has a unique 16-byte file ID (FID). and their replication status. MIMIX tracks the FIDs for all IFS objects configured for replication with advanced journaling via IFS tracking entries. the journal entries are filtered there by the apply process. Transactions are applied in realtime to generate a duplicate image of the files and data areas replicated from the source system. the database receive process transfers the data received over the communications line from the source system into a log space on the target system. it is better to use *ALL as the member name in that data group file entry. Using remote journaling support offers many benefits over using MIMIX source-send processes. if all journal entries are sent to the target system. If individual members are specified. Journal entries for which a match is found for the file and library are then transported to the target system for replication according to the DB journal entry processing parameter (DBJRNPRC) filtering specified in the data group definition. The journal definition default operation specifies that MIMIX automatically create the next journal receiver when the journal receiver reaches the threshold size you specified in the journal definition. reorganizations. After MIMIX finishes reading the entries from the current journal receiver. also indicates whether to send only the after-image of the change or both before-image and after-images. only those members you identify are processed. MIMIX source-send processing for database replication and the data area poller process. On the target system. deletes) or file level (clears. library. MIMIX uses multiple apply processes in parallel for maximum efficiency. Throughout this process.Lesser-used processes for user journal replication Lesser-used processes for user journal replication This topic describes two lesser used replication processes. transactions are applied at record level (puts. and member level. the database send process collects data from journal entries on the source system and compares them to the data group file entries defined for the data group. Note: If an application program adds or removes members and all members within the file are to be processed by MIMIX. As journal entries are added to the journal receiver. User journal replication with source-send processing This topic describes user journal replication when data groups are configured to use MIMIX source-send processes. MIMIX uses journaling to identify changes to database files and other journaled objects to be replicated. it deletes this receiver (if configured to do so) 73 . member deletes). For database files. Alternatively. The matching for the apply process is at the file. The database apply process applies replicated database transactions from the log space to the appropriate database physical file member or data area on the target system. updates. MIMIX manages the journal receiver unless you have specified otherwise. Note: New data groups are created to use remote journaling support for user journal replication when shipped default values on commands are used. specified either at the data group level or on individual data group file entries. The Data group file entries (FEOPT) parameter. Files can also be put on hold (*HLD) manually. The data group file entry can also specify a particular apply session to use for processing on the target system. This file entry option can be specified on the data group definition or on individual data group entries. MIMIX puts the member in hold error (*HLDERR) status so that no further transactions are applied. MIMIX supports the following data area types: Table 5. equal to 1 byte. up to 24 bytes in length and 9 decimal positions logical. This eliminates excessive use of disk storage and allows valuable system resources to be available for other processing. You define a data group data area entry for each data area that you want MIMIX to manage. data group file entries identify additional information used by database processes. When a data group is configured to use the data area polling process. If you expect to synchronize files at a later time. polling programs capture changes to data areas defined to the data group at specified intervals. MIMIX checks for changes to the data area type and length as well as to the contents of the data area. journal entries for the file in the log spaces are deleted and additional entries received from the target system are discarded. The file entry option Lock member during apply indicates whether or not to allow only restricted access (read-only) to the file on the backup system.and begins reading entries from the next journal receiver. the data area polling process retrieves the data area and converts it into a journal entry. If a data area has changed. The data area polling process Note: The preferred way to replicate data areas is through the user journal. it is better to put the file in an ignored state. Besides indicating the mapping between source and target file names. character. If a replication problem is detected. Putting a file on hold causes MIMIX to retain all journal entries for the file in log spaces on the target system. This process retrieves each data area defined to a data group at the interval you specify and determines whether or not a data area has changed. *CHAR *DEC *LGL Data area types supported by the data area polling process. MIMIX creates a journal entry when there is a change to a data area. This keeps the log spaces to a minimal size and improves efficiency for the apply process. Data areas can alternatively be replicated through system journal replication processes or with the data area poller. The data group definition determines how frequently the polling programs check for changes to data areas. up to 2000 bytes decimal. By setting files to an ignored state. The data area polling process runs on the source system. This 74 . A status code in the data group file entry also stores the status of the file or member in the MIMIX process. Lesser-used processes for user journal replication journal entry is sent through the normal user journal replication processing and is used to update the data area on the target system. the data area polling process will capture the new attributes and recreate the data area on the target system. For example. if a data area that is defined to MIMIX is deleted and recreated with new attributes. 75 . General security considerations for all MIMIX products can be found in the License and Availability Manager book. Information about setting security for common functions is also found in the License and Availability Manager book. data areas.Preparing for MIMIX CHAPTER 3 Preparing for MIMIX This chapter outlines what you need to do to prepare for using MIMIX. “Accessing the MIMIX Main Menu” on page 84 describes the MIMIX Main Menu and its two assistance levels. Give special attention to planning and implementing security for MIMIX. The topics in this chapter include: • “Checklist: pre-configuration” on page 77 provides a procedure to follow to prepare to configure MIMIX on each system that participates in a MIMIX installation. but now you must consider the security implications of common functions used by each product. Preparing for the installation and use of MIMIX is a very important step towards meeting your availability management requirements. • • • • 76 . it is best to determine IBM System i requirements for user journal and system journal processing in the context of your total MIMIX environment. data areas. and data queues” on page 79 describes considerations when planning to use advanced journaling for IFS objects. “Data that should not be replicated” on page 78 describes how to consider what data should not be replicated. “Planning for journaled IFS objects. or data queues. Each product has its own productlevel security. In addition. “Starting the MIMIXSBS subsystem” on page 83 describes how to start the MIMIXSBS subsystem which all MIMIX products run in. you can make your systems more secure with MIMIX product-level and command-level security. basic and intermediate which provide options to help simplify daily interactions with MIMIX. Because of their shared functions and their interaction with other MIMIX products. Do the following: 1. 6. 3. beginning with the management system. 2. 4. Once you complete the configuration process you choose. Verify any exit programs that are called by MIMIX. • • • • 77 . you may need to write exit programs for monitoring activity and you may want to ensure that your monitor definitions are replicated. At this time. If it is not already active. Update any automation programs you use with MIMIX and verify their operation. Verify the configuration. The chapter “Configuration checklists” on page 123 identifies the primary options you have for configuring MIMIX. see the Using MIMIX Monitor book. For more information about switching and policies. By now. you may also need to do one or more of the following: • If you plan to use MIMIX Monitor in conjunction with MIMIX. If you plan to use switching support. In order to use MIMIX Switch Assistant. a default model switch framework must be configured and identified in MIMIX policies. For detailed information see the chapter “Planning choices and details by object class” on page 86. 5. Configure each system in the MIMIX installation.Checklist: pre-configuration Checklist: pre-configuration You need to configure MIMIX on each system that participates in a MIMIX installation. see the Using MIMIX book. For more information about MIMIX Model Switch Framework. Decide what replication choices are appropriate for your environment. start the MIMIXSBS subsystem using topic “Starting the MIMIXSBS subsystem” on page 83. you should review the information in “Data that should not be replicated” on page 78. See the Using MIMIX book for more information. you should have completed the following tasks: • • The checklist for installing MIMIX software in the License and Availability Manager book You should have also turned on product-level security and granted authority to user profiles to control access to the MIMIX products. you or your Certified MIMIX Consultant may need to take additional action to set up and test switching. MIMIXQGPL. Objects that are in these libraries must be placed in a different library before installing software. or MIMIX data libraries. where x is a letter or number. Note: MIMIX is the default name for the MIMIX installation library -. MIMIX environment . • System environment . MIMIX data libraries are associated with a MIMIX installation library and have names in the format installation-library-name_x. but you also need to consider data that should not be replicated. work files. Job descriptions.Consider the following: • Do not replicate the LAKEVIEW library. any MIMIX installation libraries.As you identify your critical data. • Do not place user created objects or programs in LAKEVIEW. If you place such objects or programs in these libraries. including DLOs and stream files. QSYSOPR and QSECOFR should not be replicated. MIMIX installation libraries. can continue to be placed into the MIMIXQGPL library.Consider the following: • • Do not replicate system user profiles from one system to another. and temporary objects. and other objects for System i typically begin with the prefix letter Q.the library in which MIMIX ha1 or MIMIX ha Lite is installed. files. the MIMIXQGPL library. User environment . 78 . consider the following: • You may not need to replicate temporary files. Do not replicate IBM System i objects from one system to another. This includes any programs created as part of your MIMIX Model Switch Framework.Data that should not be replicated There are some considerations to keep in mind when defining data for replication. Evaluate how your applications use such files to determine if they need to be replicated. they may be deleted during the installation process. such as the MIMIX Port job. Do not replicate the LAKEVIEW or MIMIXOWN user profiles. or any MIMIX data libraries. For example. Not only do you need to determine what is critical to replicate. IBM-supplied libraries. What release of IBM i is in use? On some operating system releases. Since MIMIX uses apply session A for all objects configured for advanced journaling. These considerations affect whether journals should be shared. the types of operations that can be replicated from a user journal are limited. Examples of more dynamic objects include temporary objects. data queue objects. or data queues. see “Identifying data areas and data queues for replication” on page 103 and “Identifying IFS objects for replication” on page 106. or data queue objects using user journal replication processes. If you require serialization. data areas. • The benefits of user journal replication are described in “Benefits of advanced journaling” on page 69. data areas. which are created. it may not be appropriate for your environment. whether objects should be replicated in a data group shared with database files. In addition to configuration and journaling requirements and the restrictions that apply. serialization may require that you change the configuration for database files to ensure that they use the same apply session. and data queues Planning for journaled IFS objects. Is user journal replication appropriate for your environment? While user journal replication has significant advantages. data areas. may be better suited to replication from the system journal. data areas. while their data may change. session A. or data queues) can be serialized with one another when they are applied to objects on the target system. Serialized transactions with database files Transactions completed for database files and objects (IFS objects. See “Database apply session balancing” on page 81. and whether exit programs need to be updated. these objects and database files must share the same data group as well as the same database apply session.Planning for journaled IFS objects. whether configuration changes are needed to change apply sessions for database files. and deleted frequently. Consider the following: • Do the objects remain relatively static? Static objects typically persist after they are created. Load balancing may also become a concern. Objects for some applications. Converting existing data groups When converting an existing data group consider the following: 79 . For restrictions and limitations. and data queues You can choose to use the cooperative processing support within MIMIX to replicate any combination of journaled IFS objects. Or. renamed. you need to address several other considerations when planning to replicate journaled IFS objects. it may be appropriate for only some of the supported object types. like those which heavily use *DTAQs. The IBM i release in use may influence whether objects are considered static or dynamic for replication purposes. Changing the replication mechanism of IFS objects. you change the data group object entry to have the following values: LIB1(PRODLIB) OBJ1(*ALL) OBJTYPE(*ALL) PRCTYPE(*INCLD) COOPDB(*YES) COOPTYPE(*FILE *DTAARA *DTAQ) When the data group is started. consider the overall replication performance and throughput requirements when choosing a configuration. You will need the data group object entry described in Example 1 80 . Example 2 . assume that the systems defined to data group KEYAPP are running on IBM i V5R4. data areas. • • • Conversion examples To illustrate a simple conversion. data areas. This may include creating entries that exclude objects from replication. XYZ. When converting an existing data group to use advanced journaling. or data queue objects configured for advanced journaling to an existing database replication environment may increase replication activity and affect performance. Adding IFS. However. must remain replicated from the system journal. data area. You may need to create additional data group IFS or object entries in order to achieve the desired results. improves replication latency. or data queues from system journal replication to user journal replication generally reduces bandwidth consumption.• You may have previously used data groups with a Data group type (TYPE) value of *OBJ to separate replication of IFS. You have confirmed that the data group definition specifies TYPE(*ALL) and does not need to change. The data group has one data group object entry which has the following values: LIB1(PRODLIB) OBJ1(*ALL) OBJTYPE(*ALL) PRCTYPE(*INCLD) COOPDB(*YES) COOPTYPE(*FILE) Example 1 . all objects in the IFS path or the library specified that match the selection criteria are selected. data area. You use this data group for system journal replication of the objects in library PRODLIB. and eliminates the locking contention associated with the save and restore process. or data queues to the replication environment will increase bandwidth consumption and processing workload. object tracking entries are loaded and journaling is started for the data area and data queue objects in PRODLIB. If a large amount of data is to be replicated. The data group definition and existing data group entries must be changed to the values required for advanced journaling. After performing a controlled end of the data group. the addition of IFS byte stream files. Those objects will now be replicated from a user journal.You decide to use advanced journaling for all *DTAARA and *DTAQ objects replicated with data group KEYAPP.You want to use advanced journaling for data group KEYAPP but one data area. Converting these data groups to use advanced journaling will not cause problems with the data group. if these objects have never been replicated. Any other object types in PRODLIB continue to be replicated from the system journal. or data queue objects from other activity. In data groups that also replicate IFS objects. The apply session can be changed in the file entry options (FEOPT) on the data group object and file entries. or data queues configured for replication processing from a user journal. new journal entry codes are provided to the user exit program. If the user exit program interprets the journal code. and data queues LIB1(PRODLIB) OBJ1(*ALL) OBJTYPE(*ALL) PRCTYPE(*INCLD) COOPDB(*YES) COOPTYPE(*FILE *DTAARA *DTAQ) You will also need a new data group object entry that specifies the following so that data area XYZ can be replicated from the system journal: LIB1(PRODLIB) OBJ1(XYZ) OBJTYPE(*DTAARA) PRCTYPE(*INCLD) COOPDB(*NO) Database apply session balancing In each data group. For more information see “Considerations for LF and PF files” on page 96. changes may be required. User exit programs that rely on the library and file names in the journal entry may need to be changed to either ignore IFS journal entries or process them by resolving the FID to a path name using the IBM-supplied APIs. The path name for IFS objects cannot be interpreted in the same way as it can for database files. newly created database files are distributed to apply session A by default. In configurations using legacy cooperative processing. data areas. • • User exit program considerations When new or different journaled object types are added to an existing data group. one database apply session. data areas. Consider the following: • In MIMIX Dynamic Apply configurations. data areas or data queues through the user journal. it may be necessary to change the apply session to which cooperatively processed files are directed when the database files are created to prevent apply session A from becoming overloaded. This ensures that the files are distributed in a way that will not overload any one apply session. session A. For • • 81 . newly created database files are distributed evenly across database apply sessions by default. is used for all IFS objects. the way in which files are configured for replication can also affect how much data is processed by apply session A. user exit programs may be affected. data areas. you may need adjust the configured apply session in data group object and file entries to either ensure that files that should be serialized remain in the same apply session or to move files to another apply session to manually balance loads. • When IFS objects. In some cases. Logical files and physical files with referential constraints also have apply session requirements to consider. or data queues are journaled to a user journal. If you also replicate database files in the same data group. data areas. MIMIX uses the file ID (FID) to identify the IFS object being replicated. Be aware of the following exit program considerations when changing an existing configuration to include IFS objects.Planning for journaled IFS objects. Journaled IFS objects and data queues can have incomplete journal entries. and data queues replicated from a user journal. data areas. original journal entry. This may be a performance consideration relative to user exit program design. 82 .incomplete journal entries. Contact your Certified MIMIX Consultant for assistance with user exit programs. • Journal entries for journaled IFS objects. MIMIX provides two or more journal entries with duplicate journal entry sequence numbers and journal codes and types to the user exit program when the data for the incomplete entry is retrieved. and data queues will be routed to the user exit program. Programs need to correctly handle these duplicate entries representing the single. Note: You can ensure that the MIMIX subsystem is started after each IPL by adding this command to the end of the startup program for your system. Due to the unique requirements and complexities of each MIMIX implementation. If the MIMIXSBS is not already active. all MIMIX products run in the MIMIXSBS subsystem that is created when you install the product. it is strongly recommended that you contact your Certified MIMIX Consultant to determine the best way in which to design and implement this change. start the subsystem by typing the command STRSBS SBS(MIMIXQGPL/MIMIXSBS) and pressing Enter.Starting the MIMIXSBS subsystem Starting the MIMIXSBS subsystem By default. 83 . This subsystem must be active before you can use the MIMIX products. Any autostart job entries listed in the MIMIXSBS subsystem will start when the subsystem is started. do the following: 1. with its options designed to simplify day-to-day interaction with MIMIX. as follows: Type the command library-name/MIMIX and press Enter. you can use the name to library-qualify the command. which can only be selected from the MIMIX Basic 84 . In either assistance level. If you do not know the name of the library. the available options also depend on the MIMIX products installed in the installation library and their licensing. Type the command LAKEVIEW/WRKPRD and press Enter. Type a 9 (Display product menu) next to the product in the library you want on the Lakeview Technology Installed Products display and press Enter. The command defaults to the basic assistance level. The default name of the installation library is MIMIX.If you know the name of the MIMIX installation you want. The products installed and the licensing also affect subsequent menus and displays. Accessing the menu . Changing the assistance level . shown in Figure 6. 2. basic and intermediate. The options on the menu vary with the assistance level.Accessing the MIMIX Main Menu The MIMIX command accesses the main menu for a MIMIX installation. Figure 7 shows the intermediate assistance level.The F21 key (Assistance level) on the main menu toggles between basic and intermediate levels of the menu. Note: Procedures are written assuming you are using the MIMIX Availability Status (WRKMMXSTS) display. The MIMIX Main Menu has two assistance levels. You can also specify the the Assistance Level (ASTLVL) parameter on the MIMIX command. MIMIX Basic Main Menu MIMIX Basic Main Menu System: MIMIX Select one of the following: 1. 3. and synchronize menu 13. Inc. Utilities menu 31. We recommend you use the MIMIX Basic Main Menu unless you must access the MIMIX Intermediate Main Menu. Start MIMIX 3. Start or complete switch 11. End MIMIX 5. 2008.. 1990. Product management menu WRKMMXSTS SYSTEM1 WRKMON WRKMSGLOG LAKEVIEW/PRDMGT Selection or command ===>__________________________________________________________________________ ______________________________________________________________________________ F3=Exit F4=Prompt F9=Retrieve F21=Assistance level F12=Cancel (C) Copyright Vision Solutions. 2008. Figure 6. Configuration menu 12. MIMIX Intermediate Main Menu MIMIX Intermediate Main Menu System: SYSTEM1 MIMIX Select one of the following: 1. Work Work Work Work with with with with data groups systems messages monitors WRKDG WRKSYS WRKMSGLOG WRKMON 11. Figure 7. Configuration menu 12. 1990. verify. Work with monitors 13. Inc. 2.Accessing the MIMIX Main Menu Main Menu.. Work with messages 31. Compare. Availability status 2. 85 . Product management menu LAKEVIEW/PRDMGT Selection or command ===>__________________________________________________________________________ ______________________________________________________________________________ F3=Exit F4=Prompt F9=Retrieve F21=Assistance level F12=Cancel (C) Copyright Vision Solutions. 4. “Configured object auditing value for data group entries” on page 89 describes how MIMIX uses a configured object auditing value that is identified in data group entries and when MIMIX will change an object’s auditing value to match this configuration value. each data group entry you create identifies one or more objects to be considered for replication or to be explicitly excluded from replication. MIMIX evaluates all of the data group entries for the class to which the object belongs. such as how MIMIX interprets the data group object entries defined for a data group. and configuration requirements of MIMIX Dynamic Apply and legacy cooperative processing. This topic also provides examples and additional detail about configuring entries to replicate spooled files and user profiles. Each class of information is identified for replication by a corresponding class of data group entries. “Identifying IFS objects for replication” on page 106 identifies supported and unsupported file systems. and document library objects (DLOs). A data group can have any combination of data group entry classes. limitations. When you configure MIMIX. “Identifying data areas and data queues for replication” on page 103 identifies the replication choices and configuration requirements for library-based objects of type *DTAARA and *DTAQ. If the object is within the name space determined by the existing data group entries. When determining whether to replicate a journaled transaction.Planning choices and details by object class CHAPTER 4 Planning choices and details by object class This chapter describes the replication choices available for objects and identifies critical requirements. Some classes even support multiple choices for replication. “Identifying logical and physical files for replication” on page 96 identifies the replication choices and considerations for *FILE objects with logical or physical file extended attributes. library-based objects. This topic also identifies restrictions for replication of these object types when user journal processes (advanced journaling) is used. This topic also identifies • • • • 86 . In each class. limitations. This topic identifies the requirements. replication choices. the transaction is replicated. integrated file system (IFS) objects. “Identifying library-based objects for replication” on page 91 includes information that is common to all library-based objects. and configuration considerations for those choices. The topics in this chapter include: • • “Replication choices by object type” on page 88 identifies the available replication choices for each object class. and considerations such as long path names and case sensitivity for IFS objects. Many MIMIX processes are customized to provide optimal handling for certain classes of related object types and differentiate between database files. a data group entry identifies a source of information that can be replicated by a specific data group. restrictions and configuration requirements for replication of these object types when user journal processes (advanced journaling) is used. and restore operations. • “Identifying DLOs for replication” on page 111 describes how MIMIX interprets the data group DLO entries defined for a data group and includes examples for documents and folders. delete. data queues. “Processing of newly created files and objects” on page 114 describes how new IFS objects. and files that have journaling implicitly started are replicated from the user journal. “Processing variations for common operations” on page 117 describes configuration-related variations in how MIMIX replicates move/rename. • • 87 . data areas. a new configuration of MIMIX that uses shipped defaults for all configuration choices will use remote journaling support for replication from user journals.Replication choices by object type With version 5. system journal) Default: For other files. Table 6. extended attributes: • PF (data. legacy cooperative processing2. User journal replication can be configured for either remote journaling or MIMIX source-send processes. Replication choices by object class Replication Options Default: user journal with MIMIX Dynamic Apply1 Other: For PF data files. (For PF source and LF files. system journal Default: system journal Other: advanced journaling2 Other: Data area polling process associated with user journal2 Objects of type *DTAQ Default: system journal Other: advanced journaling2 Default: system journal Required Classes of DG Entry Object entries and File entries Object entries and File entries More Information “Identifying logical and physical files for replication” on page 96 Object Class and Type Objects of type *FILE. You can optionally use other replication processes as described in Table 6. Default configuration choices result in physical files (data and source) as well as logical files to be processed through user journal replication and all other supported object types and classes to be replicated using system journal replication. Existing data groups can be converted to this method of cooperative processing. source) • LF • *FILE. other extended attributes Objects of type *DTAARA Object entries “Identifying library-based objects for replication” on page 91 “Identifying data areas and data queues for replication” on page 103 Object entries Object entries and Object tracking entries Data area entries Object entries Object entries and Object tracking entries Object entries “Identifying library-based objects for replication” on page 91 “Identifying IFS objects for replication” on page 106 Other library-based objects IFS objects Default: system journal Other: advanced journaling2 IFS entries IFS entries and IFS tracking entries DLO entries DLOs 1. 88 . Default: system journal “Identifying DLOs for replication” on page 111 New data groups are created to use remote journaling and to cooperatively process files using MIMIX Dynamic Apply. 2. For files configured for MIMIX Dynamic Apply and any IFS objects. Specifically. the value *NONE can improve MIMIX performance by preventing unneeded entries from being written to the system journal. 89 . you can specify an object auditing value within the configuration. ensures that all changes to the object by all users are recorded in the system journal. This configured value is associated with all objects identified for processing by the data group entry. The Object auditing value (OBJAUD) parameter defines a configured object auditing level for use by MIMIX. The value *ALL ensures that all changes or read accesses to the object by all users are recorded in the system journal. The value *NONE results in no entries recorded in the system journal when the object is accessed or changed. MIMIX sets the object to the configured value so that future changes to the object will be recorded as expected in the system journal and therefore can be replicated. Changes that generate other types of journal entries are not affected by this parameter. This configured object auditing value affects how MIMIX handles changes to attributes of objects. Note: MIMIX only considers changing an object’s auditing value when the data group object entry is configured for system journal replication. An object’s actual auditing level determines the extent to which changes to the object are recorded in the system journal and replicated by MIMIX. *CHANGE. IFS objects. The configured value is used during initial configuration and during processing of requests to compare objects that are identified by configuration data. If the actual value is lower than the configured value. When MIMIX changes the audit level. In specific scenarios. MIMIX does not change the object’s value for files that are configured for MIMIX Dynamic Apply or legacy cooperative processing or for data areas and data queues that are configured for user journal replication. the possible values have the following results: • • The default value. objects configured for system journal replication.Configured object auditing value for data group entries Configured object auditing value for data group entries When you create data group entries for library-based objects. or data queues configured for user journal replication. The value *NONE prevents replication of attribute and data changes for the identified object or DLO because T-ZC and T-YC entries are not recorded in the system journal. data areas. The journal entries generated by read accesses to objects are not used for replication and their presence can adversely affect replication performance. but not limited to. • The values *CHANGE and *ALL result in replication of T-ZC and T-YC journal entries. or DLOs. It is particularly important for. MIMIX evaluates whether an object’s auditing value matches the configured value of the data group entry that most closely matches the object being processed. the configured value can affect replication of T-ZC journal entries for files and IFS objects and T-YC entries for DLOs. The configured value specified in data group entries can affect replication of some journal entries generated when an object attribute changes. For more information about manually setting values and examples. see “Managing object auditing” on page 55.#IFSATR audit” on page 569 90 .#FILATR.#OBJATR audit” on page 561 – “Attributes compared and expected results . To see what attributes can be compared and replicated.#DLOATR audit” on page 571. see “Setting data group auditing values manually” on page 270. You may also want to read the following: • • • For more information about when MIMIX sets an object’s auditing value. – “Attributes compared and expected results . #FILATRMBR audits” on page 556 – “Attributes compared and expected results . any differences found for attributes that could generate T-ZC or T-YC journal entries are reported as *EC (equal configuration).When a compare request includes an object with a configured object auditing value of *NONE. see the following topics: – “Attributes compared and expected results . Each method varies in its efficiency. *DTAARA. See “Identifying logical and physical files for replication” on page 96 for additional details. Also. the object entries identify which library-based objects can be replicated by a particular data group. MIMIX caches extended file attribute information for a fixed set of *FILE objects. and *DTAQ. An object entry can specify either a specific or a generic name for the library and object. For *FILE objects. and in additional configuration requirements. in its supported extended attributes. see “Caching extended attributes of *FILE objects” on page 313 and “Omitting T-ZC content from system journal replication” on page 350. Replication options for object types journaled to a user journal . defines a configured object auditing level for the identified objects. and indicates whether the identified objects are to be included in or excluded from replication. For most supported object types which can be identified by data group object entries. A configuration that uses the user journal is also called an advanced journaling configuration. This list includes information about what can be specified for the extended attributes of *FILE objects. • For logical and physical files. For a list of object types. In addition. the extended attribute and other configuration data are considered when MIMIX determines what replication path to use for identified objects. A limited number of object types which use the system journal replication path have unique configuration requirements.For objects of type *FILE. Each data group object entry identifies one or more library-based objects. MIMIX supports only system journal replication. For more information. These are described in are described in “Identifying spooled files for replication” on page 93 and “Replicating user profiles and associated message queues” on page 95. For these object types. the Omit content (OMTDTA) parameter provides the ability to omit a subset of data-changing operations from replication. MIMIX supports replication using either system journal or user journal replication processes.Identifying library-based objects for replication Identifying library-based objects for replication MIMIX uses data group object entries to identify whether to process transactions for library-based objects. MIMIX supports several methods of replication. see “Configuring data group entries” on page 241. For detailed procedures. • For *FILE objects configured for replication through the system journal. additional configuration data is evaluated when determining what replication path to use for the identified objects. each object entry also identifies the object types and extended object attributes (for *FILE and *DEVD objects) to be selected. Collectively. only the system journal replication path is available. MIMIX supports multiple replication methods. For *DTAARA and *DTAQ object types. Only data group object entries are required to identify these files for replication. Additional information. see “Supported object types for system journal replication” on page 505. including configuration requirements are described in “Identifying data areas and data queues for replication” on page 103. For other extended attribute types. 91 . The data group object entries are checked from the most specific to the least specific.How MIMIX uses object entries to evaluate journal entries for replication The following information and example can help you determine whether the objects you specify in data group object entries will be selected for replication. Library Name Exact Exact Exact Exact Exact Exact Exact Exact Exact Exact Exact Exact Generic* Generic* Generic* Generic* Generic* Generic* Generic* Generic* Generic* Generic* Generic* Generic* Object Type Exact Exact Exact Exact Exact Exact *ALL *ALL *ALL *ALL *ALL *ALL Exact Exact Exact Exact Exact Exact *ALL *ALL *ALL *ALL *ALL *ALL Attribute1 Exact Exact Exact *ALL *ALL *ALL Exact Exact Exact *ALL *ALL *ALL Exact Exact Exact *ALL *ALL *ALL Exact Exact Exact *ALL *ALL *ALL Object Name Exact Generic* *ALL Exact Generic* *ALL Exact Generic* *ALL Exact Generic* *ALL Exact Generic* *ALL Exact Generic* *ALL Exact Generic* *ALL Exact Generic* *ALL Search Order 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 1. with the most significant (library name) at left and the least significant (object name) at right. 92 . The most significant match found (if any) is checked to determine whether to include or exclude the journal entry in replication. and the object name. When determining whether to process a journal entry for a library-based object. attribute (for files and device descriptions). The columns are arranged to show the priority of the elements within the object entry. Table 7. MIMIX looks for a match between the object information in the journal entry and one of the data group object entries. The library name is the first search element. then followed by the object type. MIMIX determines which replication process will be used only after it determines whether the library-based object will be replicated. The extended object attribute is only checked for objects of type *FILE and *DEVD. Matching order for library-based object names. Table 7 shows how MIMIX checks a journal entry for a match with a data group object entry. an Exclude entry. an exact match for object type. MIMIX will replicate this object since it fits the criteria of the first data group object entry shown in Table 9. When an output queue (*OUTQ) is identified for replication by a data group object entry. Example . Although the transaction fits both the second and third entries shown in Table 9. say you that you have a data group configured with data group object entries like those shown in Table 9. Identifying spooled files for replication MIMIX supports spooled file replication on an output queue basis. a transaction for data area ACCOUNT1 in library FINANCE would not be replicated. A transaction for file ACCOUNTG in library FINANCE would also be replicated since it fits the third entry. Table 10 identifies the values required for spooled file replication. Entry 1 2 3 Sample of data group object entries.Identifying library-based objects for replication When configuring data group object entries. the flexibility of the generic support allows a variety of include and exclude combinations for a given library or set of libraries. Table 8. generic name support can also cause unexpected results if it is not well planned. A transaction for data area BALANCE in library FINANCE would not be replicated since it fits the second entry.For example. When MIMIX processes an output 93 . its spooled files are not automatically replicated when default values are used. Consider the search order shown in Table 7 when configuring data group object entries to ensure that objects are not unexpectedly included or excluded in replication. But. Table 9. The journal entries MIMIX is evaluating for replication are shown in Table 8. arranged in order from most to least specific Source Library Finance Finance Finance Object Type *PGM *DTAARA *ALL Object Name *ALL *ALL acc* Attribute *ALL *ALL *ALL Process Type *INCLD *EXCLD *INCLD Likewise. The second entry provides an exact match for the library name. an additional data group object entry with process type *INCLD could be added for object type of *DTAARA with an exact name of ACCOUNT1 or a generic name ACC*. and a object name match to *ALL. In order for MIMIX to process the data area ACCOUNT1. the second entry determines whether to replicate because it provides a more significant match in the second criteria checked (object type). Sample journal transactions for objects in the system journal Library FINANCE FINANCE FINANCE FINANCE Object BOOKKEEP ACCOUNTG BALANCE ACCOUNT1 Object Type *PGM *FILE *DTAARA *DTAARA A transaction is received from the system journal for program BOOKKEEP in library FINANCE. *HLD All replicated spooled files are put on hold on the target system regardless of their status on the source system. Most likely. you want to limit the spooled files that you replicate to mission-critical information. moved. all spooled files for the output queue (*OUTQ) are replicated by system journal replication processes. Additional choices for spooled file replication MIMIX provides additional options to customize your choices for spooled file replication. or its attributes are changed. Keeping deleted spooled files: You can also specify to keep spooled files on the target system after they have been deleted from the source system by using the Keep deleted spooled files parameter on the data group definition. the resulting entries in the system journal are processed by a MIMIX object send job and are replicated. The Spooled file options (SPLFOPT) parameter is only available on commands to add and change data group object entries. deleted. Spooled files on the source system which have other status values will have the same status on the target system. MIMIX ensures that the values *SPLFDTA and *PRTDTA are included in the system value for the security auditing level (QAUDLVL). This parameter can be helpful if your environment includes programs which automatically process spooled files on the target system. if you have a 94 . For example. Some output queues contain a large number of non-critical spooled files and probably should not be replicated. When a spooled file is created. When an output queue is selected for replication and the data group object entry specifies *YES for Replicate spooled files. *HLDONSAV All replicated spooled files that have a saved status on the source system will be put on hold on the target system. This causes the system to generate spooled file (T-SF) entries in the system journal. Table 10. It may be useful to direct important spooled files that should be replicated to specific output queues instead of defining a large number of output queues for replication. The parameter is also available on commands to add and change data group object entries. Options for spooled file status: You can specify additional options for processing spooled files. Spooled files on the target system will have the same status as on the source system.queue that is identified by an object entry with the appropriate settings. The following values support choosing how status of replicated spooled files is handled on the target system: *NONE This is the shipped default value. Data group object entry parameter values for spooled file replication Value *ALL or *OUTQ *YES Parameter Object type (OBJTYPE) Replicate spooled files (REPSPLF) Is it important to consider which spooled files must be replicated and which should not. For example. Entry 1 2 3 4 Sample data group object entries for maintaining private authorities of message queues associated with user profiles Source Library QSYS QUSRSYS QSYS QUSRSYS Object Type *USRPRF *MSGQ *USRPRF *MSGQ Object Name A* A* ABC ABC Process Type *INCLD *INCLD *EXCLD *EXCLD 95 . the user profile ABC and its associated message queue are excluded from replication. MIMIX replicates the objects using system journal replication processes.Identifying library-based objects for replication program that automatically prints spooled files. the message queue (*MSGQ) objects associated with the *USRPRF objects may also be created automatically on the target system as a result of replication. Table 11 shows the data group object entries required to replicate user profiles beginning with the letter A and maintain identical private authorities on associated message queues. Table 11. If the *MSGQ objects are not also configured for replication. If you move a spooled file between output queues which have different configured values for the SPLFOPT parameter. you may want to use one of these values to control what is printed after replication when printers writers are active. consider the following: • Spooled files moved from an output queue configured with SPLFOPT(*NONE) to an output queue configured with SPLFOPT(*HLD) are placed in a held state on the target system. it is recommended that *MSGQ objects associated with *USRPRF objects be configured for replication. In this example. If it is necessary for the private authorities for the *MSGQ objects be identical between the source and target systems. • Replicating user profiles and associated message queues When user profile objects (*USRPRF) are identified by a data group object entry which specifies *ALL or *USRPRF for the Object type parameter. the private authorities for the *MSGQ objects may not be the same between the source and target systems. When MIMIX replicates user profiles. Spooled files moved from an output queue configured with SPLFOPT(*HLD) to an output queue configured with SPLFOPT(*NONE) or SPLFOPT(*HLDONSAV) remain in a held state on the target system until you take action to release them. PF-SRC. The entire member is updated with each replicated transaction. record data and member data operations are replicated through user journal processes. In this configuration. In this configuration. and PF38-SRC files. The following configurations are possible: • MIMIX Dynamic Apply . moves.Legacy cooperative processing supports only data files (PF-DTA and PF38-DTA). files are identified by data group object entries and file entries. In this configuration. It does not support source physical files or logical files. Legacy cooperative processing . User journal (database) only configurations . files are identified by data group object entries and file entries. For this information. see “Configured object auditing value for data group entries” on page 89 and “How MIMIX uses object entries to evaluate journal entries for replication” on page 92. while all other file transactions such as creates. PF-DTA. moves.MIMIX Dynamic Apply is strongly recommended. The database processes can use either remote journaling or MIMIX source-send processes. renames. and deletes are replicated through system journal processes.Data group definitions which specify TYPE(*OBJ) are less efficient at processing logical and physical files. • • • You should be aware of common characteristics of replicating library-based objects.Identifying logical and physical files for replication MIMIX supports multiple ways of replicating *FILE objects with extended attributes of LF. For detailed procedures. MIMIX configuration data determines the replication method used for these logical and physical files. This configuration is the most efficient way to replicate LF. PF38-SRC. files are identified by data group object entries. See “Configuring advanced replication techniques” on page 320 for additional information. see “Creating data group object entries” on page 242. files are identified by data group file entries. such when the configured object auditing value is used and how MIMIX interprets data group entries to identify objects eligible for replication. restores. and some copy operations.Environments that do not meet MIMIX Dynamic Apply requirements but which have data group definitions that specify TYPE(*DB) can only replicate data changes to physical files. PF-DTA. In legacy cooperative processing. logical files and physical files (source and data) are replicated primarily through the user (database) journal. PF-SRC. System journal (object) only configurations . Members must be closed in order for replication to occur. Some advanced techniques may require specific configurations. PF38-DTA. In this configuration. making legacy cooperative processing the recommended choice for physical data files when the remote journaling environment required by MIMIX Dynamic Apply is not possible. renames. PF38-DTA. In this configuration. These configurations may not be able to replicate other operations such as creates. Considerations for LF and PF files Newly created data groups are automatically configured to use MIMIX Dynamic Apply when its requirements and restrictions are met and shipped command defaults are 96 . If a data group is configured for only system replication (TYPE is *OBJ). When a data group definition meets the requirements for MIMIX Dynamic Apply. Otherwise. data files are replicated using legacy cooperative processing if those requirements are met.Consider the following for physical files • Physical files (source and data) are replicated through the user journal when MIMIX Dynamic Apply requirements are met.The value specified for the Cooperative journal (COOPJRN) parameter in the data group definition is critical to determining how files are cooperatively processed. any logical files and physical (source and data) files properly identified for cooperative processing will be processed via MIMIX Dynamic Apply unless a known restriction prevents it. • • Logical files are replicated through the user journal when MIMIX Dynamic Apply requirements are met. If a data group definition specifies TYPE(*DB) and the configuration meets other MIMIX Dynamic Apply requirements. If a data group is configured for only user journal replication (TYPE is *DB) and does not meet other configuration requirements for MIMIX Dynamic Apply. Any data group object entries configured for cooperative processing will be replicated through the • • • 97 . When the MIMIX Dynamic Apply requirements are not met. MIMIX changes the value *DFT to *USRJRN.Identifying logical and physical files for replication used. source files should be identified by only data group file entries. When a data group definition does not meet the requirements for MIMIX Dynamic Apply but still meets legacy cooperative processing requirements. MIMIX changes *DFT to *SYSJRN. logical and physical files are processed primarily from the user journal. and source files are replicated through the system journal. any PF-DTA or PF38-DTA files properly configured for cooperative processing will be replicated using legacy cooperative processing. any source files should be identified by only data group object entries. With this configuration. they are replicated through the system journal.Consider the following for logical files. All other types of files are processed using system journal replication. The installation process sets the value of COOPJRN to *SYSJRN and this value remains in effect until you take action as described in “Converting to MIMIX Dynamic Apply” on page 133. Otherwise. When creating a new data group. When requirements are met. Physical file considerations . Logical file considerations . It is strongly recommended that logical files reside in the same data group as all of their associated physical files. Note: Data groups created prior to upgrading to version 5 continue to use their existing configuration. source files need to be identified by both data group object entries and data group file entries. you can explicitly specify a value or you can allow MIMIX to automatically change the default value (*DFT) to either *USRJRN or *SYSJRN based on whether operating system and configuration requirements for MIMIX Dynamic Apply are met. Cooperative journal . See “Requirements and limitations of MIMIX Dynamic Apply” on page 101 and “Requirements and limitations of legacy cooperative processing” on page 102 for additional information. commitment control maintains database integrity by not exposing a part of a database transaction until the whole transaction completes. LOBs can greatly increase the amount of data being replicated. For more information about load balancing apply sessions. MIMIX fully simulates commitment control on the target system. journal entries for database files containing unchanged LOB data may be complete and therefore processed like any other complete journal entry. When commitment control is used on a source system in a MIMIX environment. If the source system becomes unavailable. This technique is also useful in the event that a partially updated transaction must be removed.system journal and should not have any corresponding data group file entries. replication of the create operation may fail if a commit cycle is open when MIMIX tries to save the file. If minimized journal entry data is enabled. throughput. IBM support for minimized journal entry data can be extremely helpful when database records contain static. This ensures that there are no partial updates when the process is interrupted prior to the completion of the transaction.This database technique allows multiple updates to one or more files to be considered a single transaction. If minimized journal entry is used with files containing LOBs. The amount of degradation you see is proportionate to the amount of journal entries with LOBs that are applied per hour. All physical files in a referential constraint structure must be in the same database apply session. MIMIX maintains the integrity of the database on the target system by preventing partial transactions from being applied until the whole transaction completes. This can significantly improve performance. When used. use MIMIX Dynamic Apply for replication. MIMIX will not have applied incomplete transactions on the target system. This is also true during switch processing if you are using remote journaling and have unconfirmed entries with LOB data. In the event of an incomplete (or uncommitted) commitment cycle. or rolled back. Commitment control . keyed replication is not supported. For more information. see “Minimized journal entry data” on page 307. you may see some degradation in your replication activity. very large objects. • Physical files with referential constraints require a field in another physical file to be valid. see “Database apply session balancing” on page 81. The save operation will be delayed and may fail if the file being saved has uncommitted transactions. and storage requirements. you should consider using the minimized journal entry data function along with LOB replication. Since the volume of data to be replicated can be very large. If your application dynamically creates database files that are subsequently used in a commitment control environment. from the files or when updates identified as erroneous need to be removed. 98 . Files with LOBs Large objects (LOBs) in files that are configured for either MIMIX Dynamic Apply or legacy cooperative processing are automatically replicated. the integrity of the database is maintained. As a result. Without MIMIX Dynamic Apply. original journal entry. two or more entries with duplicate journal sequence numbers and journal codes and types will be provided to the user exit program when the data for the incomplete entry is retrieved and segmented. including entries which specify a Process type of *EXCLD. You may need to create additional entries to achieve the desired results. Non-minimized LOB data produces incomplete entries. • Configuration requirements for LF and PF files MIMIX Dynamic Apply and legacy cooperative processing have unique requirements for data group definitions as well as many common requirements for data group object entries and file entries. Most collision detection classes compare the journal entries with the content of the record on the target system. the F-RC entry generated by the IBM command Remove Journaled Changes (RMVJRNCHG) cannot be applied on the target system. • • 99 . The identified existing objects must be journaled to the journal defined for the data group. Although you can compare the actual content of the record. For incomplete journal entries. In both configurations. you cannot compare the content of the LOBs. Journaled changes cannot be removed for files with LOBs that are replicated by a data group that does not use remote journaling (RJLNK(*NO)).Identifying logical and physical files for replication User exit programs may be affected when journaled LOB data is added to an existing data group. Data group file entries for the items identified by data group object entries. Processing cannot occur without these corresponding data group file entries. You should also be aware of the following restrictions: • • Copy Active File (CPYACTF) and Reorganize Active File (RGZACTF) do not work against database files with LOB fields. you must have: • • A data group definition which specifies the required values. One or more data group object entries that specify the required values. Programs need to correctly handle these duplicate entries representing the single. In this scenario. These entries identify the items within the name space for replication. There is no collision detection for LOB data. as indicated in Table 12. opts: (FEOPT) Replication type Data Group Object Entries Object type (OBJTYPE) Attribute (OBJATR) *YES *DFT or *USRJRN any value *DFT or *SYSJRN See cooperative journal is default. opts: (FEOPT) Replication type *YES *FILE See Corresponding data group file entries required. PF38SRC *YES *FILE *ALL or *FILE *ALL. *POSITION any value See “Requirements and limitations of MIMIX Dynamic Apply” on page 101. *POSITION any value *ALL or *FILE *ALL or one of the following: LF. the following are also required: • The object entry must enable the cooperative processing of files by specifying 100 . Key configuration values required for MIMIX Dynamic Apply and legacy cooperative processing MIMIX Dynamic Apply Required Values Legacy Cooperative Processing Required Values Configuration Notes Critical Parameters Data Group Definition Data group type (TYPE) *ALL or *DB *ALL See “Requirements and limitations of MIMIX Dynamic Apply” on page 101. PF38-DTA. PF-DTA. or PF38-DTA Cooperate with database (COOPDB) Cooperating object types (COOPTYPE) File and tracking ent. Corresponding data group file entries . When a file is identified by both a data group object entry and an data group file entry. PF-SRC.Both MIMIX Dynamic Apply and legacy cooperative processing require that existing files identified by a data group object entry which specifies *YES for the Cooperate with DB (COOPDB) parameter must also be identified by data group file entries. PF-DTA. See “Requirements and limitations of MIMIX Dynamic Apply” on page 101. LF38.Table 12. Use remote journal link (RJLNK) Cooperative journal (COOPJRN) File and tracking ent. For example. the values specified in the data group file entry take precedence. The #DGFE audit can be used to determine whether corresponding data group file entries exist for the files identified by data group object entries.The following restrictions apply: 101 . Requirements and limitations of MIMIX Dynamic Apply MIMIX Dynamic Apply requires that user journal replication be configured to use remote journaling. Files in library .Identifying logical and physical files for replication COOPDB(*YES) and COOPTYPE(*FILE). the above actions are fully supported. Referential constraints . If you require object name mapping. the data group object entry and file entry must have the same name mapping defined. it is supported in legacy cooperative processing configurations.MIMIX Dynamic Apply configurations that specify TYPE(*DB) in the data group definition will not be able to replicate the following actions: • • • • Files created using CPYF CRTFILE(*YES) on OS V5R3 into a library configured for replication Files restored into a source library configured for replication Files moved or renamed from a non-replicated library into a replicated library Files created which are not otherwise journaled upon creation into a library configured for replication Files created by these actions can be added to the MIMIX configuration by running the #DGFE audit.It is recommended that files within a single library be replicated using the same user journal. • • If name mapping is used between systems. Files defined by data group file entries must have journaling started and must be synchronized. In data groups that specify TYPE(*ALL).Data group file entries (DGFE) for specific member names are not supported unless they are created by MIMIX. MIMIX cannot replicate activity for the file. MIMIX Dynamic Apply configurations have the following limitations. The audit recovery will synchronize the file as part of adding the file entry to the configuration. MIMIX may create these for error hold processing. MYLIB/MYOBJ mapped to MYLIB/OTHEROBJ is not supported. Entries with object name mapping are not supported. If the data group object entry and file entry specify different values for the File and tracking ent.MIMIX Dynamic Apply configurations support name mapping at the library level only. Specific data group definition and data group entry requirements are listed in Table 12. Name mapping . opts (FEOPT) parameter. data group object entries are created during initial configuration and are then used as the source for loading the data group file entries. Data group file entries for members . TYPE(*DB) data groups . If journaling is not started. • Typically. • Positional replication only . MIMIX may ignore the specification in order to satisfy this restriction.Legacy cooperative processing supports only data files (PF-DTA and PF38-DTA). All member and data changes are logged and replicated through user journal replication processes. MIMIX source-send processing for database replication is also supported. All physical files in a referential constraint structure must be in the same database apply session. 102 . All physical files in a referential constraint structure must be in the same apply session. When a *FILE object is configured for legacy cooperative processing. If a particular preferred apply session has been specified in file entry options (FEOPT).If a file is moved or renamed and both names are defined by a data group file entry. Requirements and limitations of legacy cooperative processing Legacy cooperative processing requires that data groups be configured for both database (user journal) and object (system journal) replication. Specific data group definition and data group entry requirements are listed in Table 12. While remote journaling is recommended.Physical files with referential constraints require a field in another physical file to be valid. The value *KEYED cannot be used. contact CustomerCare. Data group definitions. Physical files with referential constraints require a field in another physical file to be valid. Supported extended attributes . only file and member attribute changes identified by T-ZC journal entries with a subclass of 7=Change are logged and replicated through system journal replication processes. the file entry options must be the same in both data group file entries. File entry options . data group object entries. Referential constraints .Keyed replication is not supported by MIMIX Dynamic Apply.• If using referential constraints with *CASCADE or *SETNULL actions you must specify *YES for the Journal on target (JRNTGT) parameter in the data group definition. and data group file entries must specify *POSITION for the Replication type element of the file and tracking entry options (FEOPT) parameter. Legacy cooperative processing configurations have the following limitations. If this is not possible. also called advanced journaling. has significant advantages. For detailed procedures. Data areas can also be replicated by the data area poller process associated the user journal. • • The data group definition and data group object entries must specify the values indicated in Table 13 for critical parameters. objects configured for system journal replication. see “Configured object auditing value for data group entries” on page 89. you can specify an object auditing value within the configuration. For detailed information. It is particularly important for. For more information. the configured value can affect MIMIX performance. see “Planning for journaled IFS objects. and data queues” on page 79. Object tracking entries must exist for the objects identified by properly configured object entries. While user journal replication. • • Additional requirements for user journal replication . However. When you create data group object entries. Typically these are created automatically when the data group is started. Configuration requirements . You may need to create additional entries to achieve the desired results. Journaling must be started on both the source and target systems for the objects • 103 .The following additional requirements must be met before data areas or data queues identified by data group object entries can be replicated with user journal processes. Specifying *ALL or a generic name for the System 1 object (OBJ1) parameter will select multiple objects within the library specified for System 1 library (LIB1). See “Creating data group data area entries” on page 261. this type of replication is the least preferred and requires data group data area entries. but not limited to. When specifying objects in data group object entries. Object entries can be configured so that these object types can be replicated from journal entries recorded in the system journal (default) or in a user journal (optional). The configured object auditing value affects how MIMIX handles changes to attributes of library-based objects. consider the following: • You must have at least one data group object entry which specifies a a Process type of *INCLD. For objects configured for user journal replication.data areas and data queues For any data group object entries you create for data areas or data queues. data areas.Identifying data areas and data queues for replication Identifying data areas and data queues for replication MIMIX uses data group object entries to determine whether to process transactions for data area (*DTAARA) and data queue (*DTAQ) object types. see “Configuring data group entries” on page 241. you must decide whether it is appropriate for your environment. specify only the objects that need to be replicated. This may include entries which specify a Process type of *EXCLD. Apply session load balancing . Serialized transactions . Furthermore. is used for all data area and data queue objects are replicated from a user journal. Table 13. changes to data area and data queue content. Additionally. are recognized and supported through user journal replication. • • • Restrictions .identified by object tracking entries.If you use user exit programs that process user journal entries. User exit programs . session A. Critical configuration parameters for replicating *DTAARA and *DTAQ objects from a user journal Required Values Configuration Notes Critical Parameters Data Group Definition Data group type (TYPE) Data Group Object Entry Cooperate with database (COOPDB) Cooperating object types (COOPTYPE) *ALL *YES *DTAARA *DTAQ The appropriate object types must be specified to enable advanced journaling. and cannot perform data integrity checks on the target system to ensure that data being replaced on the target system is an exact match to the data replaced on the source system.user journal replication of data areas and data queues For operating systems V5R4 and above. You may need to adjust the configuration accordingly. be aware of the following restrictions: • MIMIX does not support before-images for data updates to data areas. Other replication activity can use this apply session. Otherwise. you may need to adjust the configuration for the replicated files. data areas.When converting an existing data group to use or add advanced journaling. you may need to modify your programs. When considering replicating data areas and data queues using MIMIX user journal replication processes. as well as changes to structure (such as moves and renames) and number (such as creates and deletes). and may cause it to become overloaded. see “Planning for journaled IFS objects.If you need to serialize transactions for database files and data area or data queue objects replicated from a user journal.One database apply session. and data queues” on page 79 for additional details if any of the following apply: • Converting existing configurations . you must consider whether journals should be shared and whether data area or data queue objects should be replicated in a data group that also replicates database files. MIMIX does not provide a mechanism to prevent 104 . system journal replication results. If this occurs. use standard system journal replication methods. • The apply of data area and data queue objects is restricted to a single database apply job (DBAPYA). The ability to replicate Distributed Data Management (DDM) data areas and data queues is not supported. you should run MIMIX AutoGuard on a regular basis. this job may fall behind in the processing of journal entries. If you need to replicate DDM data areas and data queues.Identifying data areas and data queues for replication users or applications from updating replicated data areas on the target system accidentally. Pre-existing data areas and data queues to be selected for replication must have journaling started on both the source and target systems before the data group is started. • • • 105 . If a data group has too much replication activity. To guarantee the data integrity of replicated data areas between the source and target systems. you should load-level the apply sessions by moving some or all of the database files to another database apply job. The subset of E and Q journal code entry types supported for user journal replication are listed in “Journal codes and entry types for journaled data areas and data queues” on page 590. For more information. you want to limit the IFS objects you replicate to mission-critical objects. Differences in implementation details are described in “Processing variations for common operations” on page 117. and what replication path is used. IFS objects configured to be replicated from a user journal must be in the Root (‘/’) or QOpenSys file systems. The following object types are supported: • • • Directories (*DIR) Stream Files (*STMF) Symbolic Links (*SYMLNK) Table 14 identifies the IFS file systems that are not supported by MIMIX and cannot be specified for either the System 1 object prompt or the System 2 object prompt in the Add Data Group IFS Entry (ADDDGIFSE) command. also called advanced journaling. and rename operations. Objects configured for user journal replication may have create. For detailed procedures.Identifying IFS objects for replication MIMIX uses data group IFS entries to determine whether to process transactions for objects in the integrated file system (IFS). While user journal replication has significant advantages. which are used as virtual disks by IXS and IXA technology. move. One of the most important decisions in planning for MIMIX is determining which IFS objects you need to replicate. IFS entries can be configured so that the identified objects can be replicated from journal entries recorded in the system journal (default) or in a user journal (optional). Therefore. /QDLS /QFileSvr.LIB /QSR Journaling is not supported for files in Network Work Storage Spaces (NWSS). Most likely. and data queues” on page 79. see “Creating data group IFS entries” on page 255.400 /QFPNWSSTG IFS file systems that are not supported by MIMIX /QLANSrv /QNetWare /QNTC /QOPT /QSYS. Table 14. User journal replication. data areas. is well suited to the dynamic environments of IFS objects. see “Planning for journaled IFS objects. 106 . restore. you must decide whether it is appropriate for your environment. Refer to the IBM book OS/400 Integrated File System Introduction for more information about IFS. delete. Supported IFS file systems and object types The IFS objects to be replicated must be in the Root (‘/’) or QOpenSys file systems. • The root file system on the System i is generally not case sensitive. The QOpenSys file system on the System i is generally case sensitive. MIMIX may present path names as all upper case or all lower case. MIMIX preserves the character case of IFS object names. the creation of /AbCd on the source system will be replicated as /AbCd on the target system. Integrated File System Introduction V5R4. For example. you can create /AbCd or /ABCD. For example. but not both. changes to /AbCd will be replicated to /ABCD. refer to the IBM book. Long IFS path names MIMIX currently replicates IFS path names of 512 characters.Identifying IFS objects for replication Considerations when identifying IFS objects The following considerations for IFS objects apply regardless of whether replication occurs through the system journal or user journal. while the WRKDGIFSE display shows all upper case. When character case is not a concern (root file system). You must specify the correct character case when referring to an object. be aware of the following information about character case sensitivity for specifying IFS object names. /abcd. such as /AbCd. • During replication. MIMIX processing order for data group IFS entries Data group IFS entries are processed in order from most generic to most specific. any MIMIX command that takes an IFS path name as input may be susceptible to a 506 character limit. 107 . The first entry (more generic) found that matches the object is used until a more specific match is found. you can create both /QOpenSys/AbCd and /QOpenSys/ABCD. Upper and lower case IFS object names When you create data group IFS entries. However. You can refer to the object by any mix of character case. This character limit may be reduced even further if the IFS path name contains embedded apostrophes ('). For example. /AbCd and /ABCD are equivalent names. If /ABCD exists as such on the target system. Except for "QOpenSys" in a path name. subsetting WRKDGACTE by /AbCd and /ABCD will produce the same result. Names can be entered in either case. or /ABCD. but otherwise character case is ignored. For example. but the object name will not be changed to /AbCd on the target system. For example. the WRKDGACTE display shows all lower case. all characters in a path name are case sensitive. Character case is preserved when creating objects. Replication will not alter the character case of objects that already exist on the target system (unless the object is deleted and recreated). IFS entries are processed using the unicode character set. the supported IFS path name length is reduced by four characters for every apostrophe the path name contains. In the root file system. In this case. For information about IFS path name naming conventions. When character case does matter (QOpenSys file system). The configured object auditing value affects how MIMIX handles changes to attributes of IFS objects. For example. you can specify an object auditing value within the configuration. When specifying which IFS objects in data group IFS entries. Critical Parameters Data Group Definition Data group type (TYPE) Data Group IFS Entry *ALL 108 . This may include entries which specify a Process type of *EXCLD. • • • The data group definition and data group IFS entries must specify the values indicated in Table 15 identifies for critical parameters. Configuration requirements . For details. For example.The following additional requirements must be met before IFS objects identified by data group IFS entries can be replicated with user journal processes. Journaling must be started on both the source and target systems for the objects identified by IFS tracking entries. MIMIX presents path names in the appropriate case. • • Additional requirements for user journal replication . Configured object auditing value for IFS objects When you create data group IFS entries. For IFS objects configured for user journal replication. specify only the IFS objects that need to be replicated. You may need to create additional entries to achieve the desired results. Typically these are created automatically when the data group is started. if that is the actual object path. Critical configuration parameters for replicating IFS objects from a user journal Required Values Configuration Notes Table 15. For detailed information. You can specify an object auditing value within the configuration. objects configured for system journal replication. see “Configured object auditing value for data group entries” on page 89. subsetting the WRKDGACTE display by /QOpenSys/ABCD will not find /QOpenSys/AbCd. It is particularly important for. see “Configured object auditing value for data group entries” on page 89. consider the following: • You must have at least one data group IFS entry which specifies a a Process type of *INCLD. The System 1 object (OBJ1) parameter selects all IFS objects within the path specified. the WRKDGACTE display and the WRKDGIFSE display would show /QOpenSys/AbCd. the configured value can affect MIMIX performance. IFS tracking entries must exist for the objects identified by properly configured IFS entries. but not limited to.IFS objects For any data group IFS entry you create. Names must be entered in the appropriate character case. As such. *NO. such as an IFS object. you may need to modify your programs. you may need to adjust the configuration for the replicated files. be aware of the following restrictions: • The operating system does not support before-images for data updates to IFS objects. session A. The apply of IFS objects is restricted to a single database apply job (DBAPYA). MIMIX cannot perform data integrity checks on the target system to ensure that data being replaced on the target system is an exact match to the data replaced on the source system. Other replication activity can use this apply session. this job may fall behind in the processing of journal entries. For journaled IFS objects. • • • Restrictions .If you use user exit programs that process user journal entries. Serialized transactions . results in system journal replication Critical Parameters Cooperate with database (COOPDB) Additionally. User exit programs . If a data group has too much replication activity. A physical object. Typically. is used for all IFS objects that are replicated from a user journal. and data queues” on page 79 for additional details if any of the following apply: • Converting existing configurations . • • • 109 .If you need to serialize transactions for database files and IFS objects replicated from a user journal. is identified by a hard link. you must consider whether journals should be shared and whether IFS objects should be replicated in a data group that also replicated database files.user journal replication of IFS objects When considering replicating IFS objects using MIMIX user journal replication processes. and may cause it to become overloaded. see “Planning for journaled IFS objects. an unlimited number of hard links can be created as identifiers for one object. You may need to adjust the configuration accordingly. Apply session load balancing . MIMIX will check the integrity of the IFS data through the use of regularly scheduled audits. Critical configuration parameters for replicating IFS objects from a user journal Required Values *YES Configuration Notes The default.One database apply session. data areas.Identifying IFS objects for replication Table 15.When converting an existing data group to use or add advanced journaling. Pre-existing IFS objects to be selected for replication must have journaling started both the source and target systems before the data group is started. MIMIX does not support the replication of additional hard links because doing so causes the same FID to be used for multiple names for the same IFS object. specifically the #IFSATR audit. If this occurs. you should load-level the apply sessions by moving some or all of the database files to another database apply job. Because this option does not remove the associated tracking entries. orphan tracking entries can accumulate on the system. The subset of B journal code entry types supported for user journal replication are listed in “Journal codes and entry types for journaled IFS objects” on page 590. The ability to use the Remove Journaled Changes (RMVJRNCHG) command for removing journaled changes for IFS tracking entries is not supported.• The ability to “lock on apply” IFS objects in order to prevent unauthorized updates from occurring on the target system is not supported when advanced journaling is configured. It is recommended that option 14 (Remove related) on the Work with Data Group Activity (WKRDGACT) display not be used for failed activity entries representing actions against cooperatively processed IFS objects. • • • 110 . document name. see “Configured object auditing value for data group entries” on page 89. and an include or exclude indicator. A/B/C/D). the lowest path element is removed and the process is repeated. For example. Each DLO entry for a data group includes a folder path. When you create data DLO object entries. For detailed procedures. an object auditing level. If a second data group DLO entry with a folder path of “ACCOUNT/J*” were added. owner. MIMIX supports generic names for DLOs. it would take precedence because it is more specific.Identifying DLOs for replication Identifying DLOs for replication MIMIX uses data group DLO entries to determine whether to process system journal transactions for document library objects (DLOs). If there is still no match. a data group DLO entry with a folder path of “ACCOUNT” would also apply to a transaction for a document in folder path ACCOUNT/JANUARY. In a data group DLO entry. The data group DLO entries are checked from the most specific to the least specific. A/B/C/D is reduced to A/B/C and is rechecked. you can specify an object auditing value within the configuration. Matching order for document names Folder Path Exact Exact Exact Document Name Exact Exact Generic* Owner Exact *ALL Exact Search Order 1 2 3 111 . the folder path and document can be generic or *ALL. In addition to specific names. then the owner. The folder path is the most significant search element. For a folder path with multiple elements (for example. followed by the document name. For example. The most significant match found (if any) is checked to determine whether to process the entry. This process continues until a match is found or until all elements of the path have been removed. How MIMIX uses DLO entries to evaluate journal entries for replication How items are specified within a DLO determines whether MIMIX selects or omits them from processing. Sequence and priority order for documents Table 16 illustrates the sequence in which MIMIX checks DLO entries for a match. The configured object auditing value affects how MIMIX handles changes to attributes of DLOs. see “Creating data group DLO entries” on page 259. For detailed information. If no match is found. An exact or generic folder path name in a data group DLO entry applies to folder paths that match the entry as well as to any unnamed child folders of that path which are not covered by a more explicit entry. When determining whether to process a journal entry for a DLO. Table 16. MIMIX looks for a match between the DLO information in the journal entry and one of the data group DLO entries. the exact checks and generic checks against data group DLO entries are performed on the path. This information can help you understand what is included or omitted. then checks for folder path *ALL are performed. or in a child folder of that path. If SMITHA owned ACCOUNTS in FINANCE1.Table 17 illustrates some sample data group DLO entries. A transaction for document ACCOUNTS in FINANCE1 owned by JONESB would be replicated because it matches entry 4. Folders are replicated based on whether there are any data group DLO entries with a process type of *INCLD that would require the folder to exist on the target system. the transaction would be blocked by entry 3. documents LEDGER. arranged in order from most to least specific Folder Path FINANCE1 FINANCE1 FINANCE1 FINANCE1 FINANCE2/Q1 FIN* Document PAYROLL LEDGER* *ALL *ALL *ALL *ALL Owner *ALL *ALL SMITHA *ALL *ALL *ALL Process Type *EXCLD *EXCLD *EXCLD *INCLD *INCLD *EXCLD Sequence and priority order for folders Folders are treated somewhat differently than documents.Table 16. Matching order for document names Folder Path Exact Exact Exact Generic* Generic* Generic* Generic* Generic* Generic* *ALL *ALL *ALL *ALL *ALL *ALL Document Name Generic* *ALL *ALL Exact Exact Generic* Generic* *ALL *ALL Exact Exact Generic* Generic* *ALL *ALL Owner *ALL Exact *ALL Exact *ALL Exact *ALL Exact *ALL Exact *ALL Exact *ALL Exact *ALL Search Order 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Document example . such as FINANCE2/Q1/FEB. However. If a folder needs to exist to satisfy the folder path of an include entry. For example. transactions for documents in FINANCE2/Q1. would be replicated because of entry 5. Likewise.JUL and LEDGER. Table 17. the folder will be replicated even if a different exclude entry prevents replication of the contents of the folder.AUG in FINANCE1 would be blocked by entry 2 and document PAYROLL in FINANCE1 would be blocked by entry 1. Entry 1 2 3 4 5 6 Sample data group DLO entries. a transaction for any document in a folder named FINANCE would be blocked from replication because it matches entry 6. 112 . A transaction for any document in FINANCE2 would be blocked by entry 6. Identifying DLOs for replication There is one exception to the requirement of replicating folders to satisfy the folder path for an include entry. Entry 1 2 3 4 5 Sample data group DLO entries. A transaction for folder FINANCE1 would be replicated because of entry 4. Note that the exception holds true even if ACCOUNT is owned by user profile JONESB (entry 4) because the more specific folder name match takes precedence. A folder will not be replicated when the only include entry that would cause its replication specifies *ALL for its folder path and the folder matches an exclude entry with an exact or a generic folder path name. a transaction for a folder named FINANCE would be blocked from replication because it matches entry 6. Table 17 and Table 18 illustrate the differences in matching folders to be replicated. The exception also affects all child folders in the ACCOUNT folder path. The exception does not apply because entry 1 does not specify document *ALL. and an owner of *ALL. above. In Table 17. only FINANCE2 itself must exist to satisfy entry 5. ACCOUNT matches an exclude entry with an exact folder path. This is because of the exception described above. a transaction for folder ACCOUNT would be blocked from replication because it matches entry 2. In Table 18. Note that any transactions for documents in FINANCE2 or any child folders other than those in the path that includes Q1 would be blocked by entry 6. This would also affect all folders within FINANCE. and the only include entry that would cause it to be replicated specifies folder path *ALL. Entry 5 requires that ACCOUNT2 exist on the target system to satisfy the folder path requirements for document names other than LEDGER* and for child folders of ACCOUNT2. a transaction for folder FINANCE2 would be replicated because of entry 5. document value of *ALL. folder example Folder Path ACCOUNT2 ACCOUNT *ALL *ALL *ALL Document LEDGER* *ALL ABC* *ALL *ALL Owner *ALL *ALL *ALL JONESB *ALL Process Type *EXCLD *EXCLD *INCLD *INCLD *INCLD A transaction for folder ACCOUNT2 would be replicated even though it is an exact path name match for exclude entry 1. 113 . Likewise. Table 18. a document value of *ALL and an owner of *ALL. although entry 5 is an include entry. MIMIX replicates the create operation. Newly created files When newly created *FILE objects are implicitly journaled and are eligible for replication.MIMIX Dynamic Apply When a data group definition meets configuration requirements for MIMIX Dynamic Apply and data group object and file entries are properly configured. see topic ‘Notifications for newly created objects’ in the Using MIMIX book. Replication 114 . Optionally. The following briefly describes the events that occur for newly created files on the source system which are configured for MIMIX Dynamic Apply: • • • System journal replication processes ignore the creation entry. For more information about requirements and restrictions for implicit starting of journaling as well as examples of how MIMIX determines whether to replicate a new object. The MMNFYNEWE monitor is a shipped journal monitor that watches the security audit journal (QAUDJRN) for newly created libraries. When properly configured. the monitor will automatically start with the master monitor. User action is required to enable this monitor on the source system within your MIMIX environment. Configurations that replicate files. Processing variations exist based on how the data group and the data group entry with the most specific match to the object are configured. New file processing . see “What objects need to be journaled” on page 294.Processing of newly created files and objects Your production environment is dynamic. User journal replication processes create the file on the target system. This monitor is shipped disabled. new files created on the source system that are eligible for replication will be re-created on the target system by MIMIX. When a configuration enables journaling to be implicitly started on new objects. folders. the replication processes used depend on how the data group definition is configured and how the data group entry with the most specific match to the file is configured. data areas. Once enabled. These variations are described in the following subtopics. MIMIX can also notify you of newly created objects not eligible for replication so that you can choose whether to add them to the configuration. MIMIX automatically recognizes entries in the user journal that identify new create operations and replicates any that are eligible for replication. a newly created object is already journaled. User journal replication processes dynamically add a file entry for a file when a file create is seen in the user journal. or directories that are not already included or excluded for replication by a data group and sends warning notifications when its conditions are met. or IFS objects from user journal entries require journaling to be started on the objects before replication can occur. knowing that user journal replication processes will get a create entry as well. The file entry is added with a status of *ACTIVE. For more information about the conditions that are checked. When the journaled object falls within the group of objects identified for replication by a data group. New objects continue to be created after MIMIX is configured and running. data queues. The status of the file entry changes to *ACTIVE. newly created objects that are eligible for replication are automatically replicated. then communicates with user journal replication processes to issue a release wait request against the file. and data queues. and data queues When journaling is implicitly started for IFS objects. there are some situations where constraints are added dynamically between two files already assigned to different apply sessions. The file entry is added with the status of *HLD.legacy cooperative processing When a data group definition meets configuration requirements for legacy cooperative processing and data group object and file entries are properly configured. changes. data areas. • All subsequent file changes including moves or renames. In the case of cascading constraints. Note: Non-journaled objects are replicated through the system journal. For MIMIX Dynamic Apply configurations. MIMIX configurations can be enabled to permit the automatic start of journaling for newly created data areas and data queues in libraries journaled 115 . System journal replication processes save the created file. For data areas and data queues. data areas. and removes). • • • • Newly created IFS objects. to ensure that the modification is done. file changes. The following briefly describes the events that occur when files are created that have been defined for legacy cooperative processing: • System journal replication processes communicate with user journal replication processes to add a data group file entry for the file (ADDDGFE command). and file deletes are replicated through the user journal. whether the constraint is enabled or disabled. the constraint may need to be disabled to avoid the constraint violations. However. member operations (adds. automatic journaling of new *DTAARA or *DTAQ objects is supported. where a modification to one file cascades operations to related files. and then makes the file active. restores it on the target system. A user journal transaction is created on the source system and is transferred to the target system to dynamically add the file to active user journal processes. member data updates. authority changes. Configuration values specified in the data group IFS entry or object entry that most specifically matches the new object determines what replication processes are used. The database apply process waits for the save point in the journal. MIMIX will always attempt to apply the cascading entries.Processing of newly created files and objects proceeds normally after the file has been created. In this case. The status of the file entry changes to *RLSWAIT. This eliminates the possibility of constraint violations that would otherwise occur if apply sessions processed the files independently. MIMIX always attempts to place files that are related due to referential constraints into the same apply session. • New file processing . files created on the source system will be saved and restored to the target system by system journal replication processes. Journaling on the file is started if it is not already active. 2. The user journal entries contain all the information necessary for replication without needing to retrieve information from the object on the source system. 116 . see “What objects need to be journaled” on page 294. On the Data Group Activity Entries (WRKDGACTE) display. If the specified values in data group entry that identified the object as eligible for replication do not allow the object type to be cooperatively processed. do the following: 1. For requirements for implicitly starting journaling on new objects. If the object is not journaled to the user journal. Determining how an activity entry for a create operation was replicated To determine whether a create operation of a given object is being replicated through user journal processes or through system journal processes. If *YES appears for an activity entry representing a create operation. the create of the object and subsequent operations are replicated through system journal processes. If the object is journaled to the user journal. the create timestamp (*CRTTSP) attribute may differ between the source and target systems. Create operations have a value of T-CO in the Code column. MIMIX user journal replication processes can fully replicate the create operation. the create operation is being replicated through the user journal.to a user journal. New MIMIX installations that are configured for MIMIX Dynamic Apply of files automatically have this behavior. check the value of the Requires container send field. the create operation is being replicated through the system journal. then the create of the object is processed with system journal processing. If *NO appears in the field. On the resulting details display. MIMIX creates a tracking entry for the newly created object and an activity entry representing the T-CO (create) journal entry. When MIMIX replicates a create operation through the user journal. Use option 5 (Display) next to an activity entry for a create operation. 3. locate the entry for a create operation that you want to check. user journal replication also offers full support of these operations for data area and data queue objects. and restores. or a combination of both journals. and move and rename operations. deletes. the customer is assumed not to care if the target object is replicated. Advanced journaling (user journal replication of data areas. Current object move actions New Name or Location Within name space of objects to be replicated Excluded from or not identified for replication Within name space of objects to be replicated Excluded from or not identified for replication MIMIX Action on Target System Create Object 1 Delete Object 2 Move Object None Original Source Object Excluded from or not identified for replication Identified for replication Identified for replication Excluded from or not identified for replication 1. user journal. user journal replication offers full support of create. For IFS objects. since it is not defined with an Include entry. To ensure the integrity of the target (backup) system. If the source system object is not defined to MIMIX or if it is defined by an Exclude entry. The variations are based on the configuration of the data group entry used for replication. Table 19. data queues and IFS objects). MIMIX uses system journal replication processes DLOs and for IFS objects and library-based objects which are not explicitly identified for user journal replication. renames. The Action column indicates the operation that MIMIX will attempt on the target system. Further.Processing variations for common operations Processing variations for common operations Some variation exists in how MIMIX performs common operations such as moves.system journal replication Table 19 describes how MIMIX processes a move or rename journal entry from the system journal. it is not guaranteed that an object with the same name exists on the backup system or that it is really the same object as on the source system. so deleting the object is the most straight forward approach. If the target object is not defined to MIMIX or if it is defined by an Exclude entry. delete. Configurations specify whether these operations are processed through the system journal. In environments using V5R4 and higher operating systems. Move/rename operations . 2. and MIMIX Dynamic Apply utilize both journals. there is no guarantee that the target library exists on the target system. legacy cooperative processing. however MIMIX Dynamic Apply primarily processes through the user journal. The Original Source Object and New Name or Location columns indicate whether the object is identified within the name space for replication. restore. a copy of the source object must be brought over from the source system. 117 . If the object is a library or directory. If the new location or new name on the source system remains within the set of objects identified as eligible for replication. Not identified for replication Within name space of objects to be replicated with user journal processing 118 .Move/rename operations . Creates tracking entry for the object using the new name or location. MIMIX may use a create or delete operation and may need to add or remove tracking entries. The object will no longer be replicated. See example 2. data area. data queues. When a move or rename operation starts with or results in an object that is not within the name space for user journal replication. MIMIX creates tracking entries for those objects within the library or directory that are also within name space for user journal replication. See example 3. Table 20. Synchronizes all of the objects identified by these new tracking entries. Source object Identified for replication with user journal processing Not identified for replication Identified for replication with user journal processing Identified for replication with user journal processing None. MIMIX creates tracking entries for those objects within the library or directory that are also within name space for user journal replication and synchronizes those objects.user journaled data areas. MIMIX actions when processing moves or renames of objects when user journal replication processes are involved New name or location Within name space of objects to be replicated with user journal processing Not identified for replication Not identified for replication Within name space of objects to be replicated with system journal processing Within name space of objects to be replicated with user journal processing MIMIX action Moves or renames the object on the target system and renames the associated tracking entry. MIMIX will perform the move or rename operation on the object on the target system. MIMIX may need to perform additional operations in order to replicate the operation. Moves or renames the object using system journal processes and removes the associated tracking entry. Each row in Table 20 summarizes a move/rename scenario and identifies the action taken by MIMIX. See example 6. See example 4. See example 5. Identified for replication with system journal processing Creates tracking entry for the object using the new name or location and moves or renames the object using user journal processes. Deletes the target object and deletes the associated tracking entry. If the object is a library or directory. See example 1. IFS objects IFS. and data queue objects replicated by user journal replication processes can be moved or renamed while maintaining the integrity of the data. The object is not eligible for replication. the old name is eligible for replication. and that the IFS stream file /TEST/stmf1 was renamed to /TEST/stmf2. the old and new names fall within advanced journaling name space. For example. and source IFS objects for examples Data Group IFS Entries /TEST/STMF* /TEST/DIR* Source System IFS Objects in Name Space /TEST/stmf1 /TEST/dir1/doc1 Associated Data Group IFS Tracking Entries /TEST/stmf1 /TEST/dir1 /TEST/dir1/doc1 system journal replication /TEST/NOTAJ* /TEST/notajstmf1 /TEST/notajdir1/doc1 Configuration Supports advanced journaling advanced journaling Example 1. moves/renames outside name space: When MIMIX encounters a journal entry for a source system object outside of the name space that has been renamed or moved to another location also outside of the name space. as indicated in Table 20. MIMIX encounters user journal entries indicating that the source system IFS directory /TEST/dir1 was renamed to /TEST/dir2. Results of move/rename operations within name space for advanced journaling Resulting data group IFS tracking entries /TEST/stmf2 /TEST/dir2 /TEST/dir2/doc1 Resulting Target IFS objects /TEST/stmf2 /TEST/dir2/doc1 Example 2. The rename operations are replicated and names are changed on the target system objects. The resulting changes on the target system objects and MIMIX configuration are shown in Table 22. Table 22. The tracking entries for these objects are also renamed. In both cases. Table 21. moves/renames within advanced journaling name space: The most common move and rename operations occur within advanced journaling name space. Initial data group IFS entries. The MIMIX behavior described is the same as that for data areas and data queues that are within the configured name space for advanced journaling. Thus. MIMIX is aware of only the original names. MIMIX ignores the transaction. moves/renames from advanced journaling name space to outside name space: In this example. Example 3. IFS tracking entries. 119 . and IFS tracking entries before the move/rename operation occurs.Processing variations for common operations The following examples use IFS objects and directories to illustrate the MIMIX operations in move/rename scenarios that involve user journal replication (advanced journaling). data group IFS entries. MIMIX encounters user journal entries indicating that the source system IFS directory /TEST/dir1 was renamed to /TEST/xdir1 and IFS stream file /TEST/stmf1 was renamed to /TEST/xstmf1. Table 21 identifies the initial set of source system objects. as indicated in Table 20. Results of move/rename operations from system journal to advanced journaling name space Resulting data group IFS tracking entries /TEST/stmf1 /TEST/dir1 /TEST/dir1/doc1 Resulting target IFS objects /TEST/stmf1 /TEST/dir1/doc1 Example 6. Example 4. Table 23 shows these results. The objects identified by these tracking entries are individually synchronized from the source to the target system. Table 24. MIMIX deletes the IFS directory and IFS stream file from the target system. MIMIX is aware that the old names are within the system journal name space and that the new names are within the advanced journaling name space. moves/renames from outside to within advanced journaling name space: In this example MIMIX encounters journal entries indicating that the source system IFS directory /TEST/xdir1 was renamed to /TEST/dir1 and that IFS stream file /TEST/xstmf1 was renamed to /TEST/stmf1. MIMIX removes the tracking entries associated with the original names and performs the rename operation for the objects on the target system. The original names are outside of the name space and are not eligible for replication. As a result. Table 24 illustrates the results on the target system. MIMIX encounters user journal entries indicating that the source system IFS directory /TEST/dir1 was renamed to /TEST/notajdir1 and that IFS stream file /TEST/stmf1 was renamed to /TEST/notajstmf1. MIMIX also creates tracking entries for any objects that reside within the moved or renamed IFS directory (or library in the case of data areas or data queues). Table 23.but the new name is not. moves/renames from advanced journaling to system journal name space: In this example. MIMIX also deletes the associated IFS tracking entries. the new names are within 120 . the new names fall within the name space for replication through the system journal. MIMIX treats this as a delete operation during replication processing. MIMIX encounters journal entries indicating that source system IFS directory from /TEST/notajdir1 was renamed to /TEST/dir1 and that IFS stream file /TEST/notajstmf1 was renamed to /TEST/stmf1. However. MIMIX is aware that both the old names and new names are eligible for replication as indicated in Table 20. moves/renames from system journal to advanced journaling name space: In this example. However. MIMIX creates tracking entries for the names and then performs the rename operation on the target system using advanced journaling. Results of move/rename operations from advanced journaling to system journal name space Resulting data group IFS tracking entries (removed) (removed) Resulting target IFS objects /TEST/notajstmf1 /TEST/notajdir1/doc1 Example 5. • • • Delete operations . If the dynamic update option is not used.Processing variations for common operations the name space for advanced journaling as indicated in Table 20. or data queue object is restored. The transaction is transferred dynamically.files configured for legacy cooperative processing The following briefly describes the events that occur in MIMIX when a file that is defined for legacy cooperative processing is deleted: • System journal replication processes communicate with user journal replication processes that a file has been deleted on the source system and indicates that the file should be deleted from the target system. With user journal replication. MIMIX system journal replication processes generate an activity entry representing the delete operation and handle the delete of the object from the target system. Table 25. data area.user journaled data areas. See “Newly created files” on page 114. Restore operations . data area. MIMIX processes the operations as creates during replication. MIMIX system journal replication processes delete the file on the target system. and data queue objects on the source system are 121 . Table 25 illustrates the results. Because the objects were not previously replicated. IFS objects When an IFS. If the data group file entry is set to use the option to dynamically update active replication processes. A journal transaction which identifies the deleted file is created on the source system.user journaled data areas. the file and associated file entry will be dynamically removed from the replication processes. The objects identified by these tracking entries are individually synchronized from the source to the target system. the pre-existing object is replaced by a backup copy on the source system. IFS objects When a T-DO (delete) journal entry for an IFS. data queues. restores of IFS. the data group changes are not recognized until all data group processes are ended and restarted. data queues. or data queue object is encountered in the system journal. The user journal replication processes remove the corresponding tracking entry. MIMIX also creates tracking entries for any objects that reside within the moved or renamed IFS directory (or library in the case of data areas or data queues). data area. Results of move/rename operations from outside to within advanced journaling name space Resulting data group IFS tracking entries /TEST/stmf1 /TEST/dir1 /TEST/dir1/doc1 Resulting target IFS objects /TEST/stmf1 /TEST/dir1/doc1 Delete operations . supported through cooperative processing between MIMIX system journal and user journal replication processes. Provided the object was journaled when it was saved. or data queue object match the data group definition. During cooperative processing. or data queue object. or data queue object is also journaled . data area. Meanwhile. data area. or end and restart journaling on the object so that the journaling characteristics of the IFS. data area. 122 . user journal replication processes handle the management of the corresponding IFS or object tracking entry. system journal replication processes generate an activity entry representing the T-OR (restore) journal entry from the system journal and perform a save and restore operation on the IFS. a restored IFS. MIMIX may also start journaling. IFS objects to user journaling” on page 136 changes the configuration of an existing data group to use user journal replication processes for these objects. advanced techniques. and data groups that make up the replication environment. controllers. “Checklist: Change *DTAARA. For additional information see “Configuring advanced replication techniques” on page 320. • “Checklist: New remote journal (preferred) configuration” on page 125 uses shipped default values to create a new installation. Also. Unless you explicitly configure them otherwise. • • Upgrades and conversions: You can use any of the following topics. such as keyed replication. use topic ‘Choosing the correct checklist for MIMIX for MQ’ in the MIMIX for IBM WebSphere MQ book. as appropriate. New data groups will use MIMIX source-send processes in user journal replication. *DTAQ. journals. new data groups will use the IBM i remote journal function as part of user journal replication processes. system-level configuration for communications (lines. To configure a new installation that is to use the integrated MIMIX support for IBM WebSphere MQ (MIMIX for MQ). have additional configuration requirements.CHAPTER 5 Configuration checklists MIMIX can be configured in a variety of ways to support your replication needs. New installations: Before you start configuring MIMIX. to change a configuration: • • “Checklist: Converting to remote journaling” on page 131 changes an existing data group to use remote journaling within user journal replication processes. For available options. Definitions identify systems. “Checklist: Converting to legacy cooperative processing” on page 138 changes the configuration of an existing data group so that logical and physical source files • • • 123 . refer to the MIMIX for IBM WebSphere MQ book. “Converting to MIMIX Dynamic Apply” on page 133 provides checklists for two methods of changing the configuration of an existing data group to use MIMIX Dynamic Apply for logical and physical file replication. Data groups that existed prior to installing version 5 must use this information in order to use MIMIX Dynamic Apply. “Checklist: New MIMIX source-send configuration” on page 128 configures a new installation and is appropriate when your environment cannot use remote journaling. Choose one of the following checklists to configure a new installation of MIMIX. Each configuration requires a combination of definitions and data group entries. IP interfaces) must already exist between the systems that you plan to include in the MIMIX installation. Data group entries identify what to replicate and the replication option to be used. To add integrated MIMIX support for IBM WebSphere MQ (MIMIX for MQ) to an existing installation. see “Replication choices by object type” on page 88. communications. Configuration checklists are processed from the system journal and physical data files use legacy cooperative processing. Other checklists: The following configuration checklist employs less frequently used configuration tools and is not included in this chapter. • Use “Checklist: copy configuration” on page 509 if you need to copy configuration data from an existing product library into another MIMIX installation. 124 . If you are using the TCP protocol. If you are using the TCP protocol. If you have TCP configured and plan to use it for your transfer protocol. a. If communications is not configured. If your transfer definitions prevent this. 8. Use topic “Checking DDM password validation level in use” on page 280. ensure that the Lakeview TCP server is running on each system defined in the transfer definition. configuration information for data groups will be automatically replicated to the other system as you create it. Create transfer definitions to define the communications protocol used between pairs of systems. Verify that the communications link defined in each transfer definition is operational using topic “Verifying a communications link for system definitions” on page 173. Use topic “Creating a transfer definition” on page 163. use topic “Starting the TCP/IP server” on page 168. To configure your system manually. When the system manager is running. 9. Create system definitions for the management system and each of the network systems for the MIMIX installation. 6. ensure that the DDM TCP server is running using topic “Starting the DDM TCP/IP server” on page 279. perform the following steps on the system that you want to designate as the management system of the MIMIX installation: 1. 4. Note: Default values for transfer definitions enable MIMIX to create and manage autostart job entries for the server. 125 . you can create and manage your own autostart job entries. If the Lakeview TCP server is not active on a system. 7. Use topic “Creating system definitions” on page 150. If you have implemented DDM password validation. 3. b. refer to “System-level communications” on page 140 for more information. A pair of systems consists of a management system and a network system. Start the MIMIX managers using topic “Starting the system and journal managers” on page 269. 2. Communications between the systems must be configured and operational before you start configuring MIMIX.Checklist: New remote journal (preferred) configuration Checklist: New remote journal (preferred) configuration Use this checklist to configure a new installation of MIMIX. 5. The referenced topic creates a data group definition with appropriate values to support MIMIX Dynamic Apply. You can use the Work with Active Jobs (WRKACTJOB) command to look for a job under the MIMIXSBS subsystem with a function of PGM-LVSERVER. This checklist creates the preferred configuration that uses IBM i remote journaling and uses MIMIX Dynamic Apply to cooperatively process logical and physical files. Create the data group definitions that you need using topic “Creating a data group definition” on page 221. For more information see “Using autostart job entries to start the TCP server” on page 169. verify that is it is operational using the PING command. verify that your environment will allow MIMIX RJ support to work properly. Planning and Requirements Information “Identifying library-based objects for replication” on page 91 “Identifying logical and physical files for replication” on page 96 “Identifying data areas and data queues for replication” on page 103 3. Do the following to confirm and automatically correct any problems found in file entries associated with data group object entries: a. For information. temporarily change the Action for running audits policy using the following command: SETMMXPCY DGDFN(name system1 system2) RULE(*NONE) RUNAUDIT(*CMPRPR) b. For other object types or classes. “Tips for journal definition parameters” on page 179. If the data group is switchable. be sure to build the journaling environments for both directions--source system A to target system B (target journal @R) and for source system B to target system A (target journal @R). you should still create file entries for PF data files to ensure that legacy cooperative processing can be used. After creating object entries. Note: If you cannot use MIMIX Dynamic Apply for logical files or PF data files. and “Journal definition considerations” on page 184. load IFS tracking entries for IFS objects to be replicated from a user journal. any replication options identified in planning topic “Replication choices by object type” on page 88 are supported. After creating object entries. Confirm that the journal definitions which have been automatically created have the values you require. From the source system. 11. load file entries for LF and PF (source and data) *FILE objects using “Loading file entries from a data group’s object entries” on page 247. Table 26. 12. see “Journal definitions created by other processes” on page 178. Use “Loading IFS tracking entries” on page 257. After creating IFS entries. 2. “Identifying IFS objects for replication” on page 106 DLOs “Identifying DLOs for replication” on page 111 13. Use Table 26 to create data group entries for this configuration. This configuration requires object entries and file entries for LF and PF files. type WRKAUD RULE(#DGFE) and press Enter. IFS objects 1. Do the following: 1. Create DLO entries using “Creating data group DLO entries” on page 259.10. Build the necessary journaling environments for the RJ links using “Building the journaling environment” on page 195. Create IFS entries using “Creating data group IFS entries” on page 255. Create object entries using. Use “Loading object tracking entries” on page 258. From the management system. Use“Creating data group object entries” on page 242. Class Librarybased objects How to configure data group entries for the remote journal (preferred) configuration. 126 . load object tracking entries for any *DTAARA and *DTAQ objects to be replicated from a user journal. 2. 18. (The default value is *INST. • • • For user journal replication. Check the audit status for a value of *NODIFF or *AUTORCVD. f. Topic “Performing the initial synchronization” on page 442 identifies options available for synchronizing and identifies how to establish a synchronization point that identifies the journal location that will be used later to initially start replication. Start journaling using the following procedures as needed for your configuration. Doing this now ensures that objects to be replicated have the object auditing values necessary for replication and that any transactions which occur between configuration and starting replication processes can be replicated. For data areas or data queues configured for user journal replication.Checklist: New remote journal (preferred) configuration c. Then press Enter. For additional information. 19. use “Journaling for IFS objects” on page 300. Next to the data group you want to confirm. If the audit results in any other status. folders and directories contain expected objects on both systems. configured for user journal replication. d. Confirm that the systems are synchronized by checking the libraries. On the Run Rule (RUNRULE) display specify *NO for the Use run rule on system policy prompt. For IFS objects. be sure to specify *SRC for the Start journaling on system (JRNSYS) parameter in the commands to start journaling. see “Resolving audit problems . Ensure that object auditing values are set for the objects identified by the configuration before synchronizing data between systems. e. 17.) Use the command: SETMMXPCY DGDFN(name system1 system2) RULE(*NONE) RUNAUDIT(*INST) 14. Start the data group using “Starting data groups for the first time” on page 282.5250 emulator” on page 543 and “Interpreting results for configuration data .#DGFE audit” on page 546. From the management system. use “Journaling for physical files” on page 297 to start journaling on both source and target systems. 127 . 16. Synchronize the database files and objects on the systems between which replication occurs. use “Journaling for data areas and data queues” on page 303. 15. resolve the problem. set the Action for running audits policy to its previous value. Note: If the objects do not yet exist on the target system. Topic “Verifying the initial synchronization” on page 447 identifies the additional aspects of your configuration that are necessary for successful replication. type 9 (Run rule) and press F4 (Prompt). Use the procedure “Setting data group auditing values manually” on page 270. Verify the configuration. For more information see “Using autostart job entries to start the TCP server” on page 169.Checklist: New MIMIX source-send configuration Best practices for MIMIX are to use MIMIX Remote Journal support for database replication. Be sure to specify *NO for the Use remote journal link prompt. Start the MIMIX managers using topic “Starting the system and journal managers” on page 269. 8. 6. Confirm that the journal definitions which have been automatically created have the values you require. A pair of systems consists of a management system and a network system. If you have TCP configured and plan to use it for your transfer protocol. Create the data group definitions that you need using topic “Creating a data group definition” on page 221. ensure that the Lakeview TCP server is running on each system defined in the transfer definition. configuration information for data groups will be automatically replicated to the other system as you create it. Communications between the systems must be configured and operational before you start configuring MIMIX. System journal replication is also configured. When the system manager is running. If communications is not configured. 7. b. refer to “System-level communications” on page 140 for more information. Create transfer definitions to define the communications protocol used between pairs of systems. you can create and manage your own autostart job entries. 2. 4. However. Use topic “Creating a transfer definition” on page 163. “Tips for journal definition parameters” on page 179. 3. 5. You can use the Work with Active Jobs (WRKACTJOB) command to look for a job under the MIMIXSBS subsystem with a function of PGM-LVSERVER. use topic “Starting the TCP/IP server” on page 168. Note: Default values for transfer definition enable MIMIX to create and manage autostart job entries for the server. verify that is it is operational using the PING command. perform the following steps on the system that you want to designate as the management system of the MIMIX installation: 1. To configure a source-send environment. Verify that the communications link defined in each transfer definition is operational using topic “Verifying a communications link for system definitions” on page 173. this checklist will configure a new installation that uses MIMIX source-send processes for database replication. Create system definitions for the management system and each of the network systems for the MIMIX installation. 128 . If your transfer definitions prevent this. Use topic “Creating system definitions” on page 150. For information. If the Lakeview TCP server is not active on a system. If you are using the TCP protocol. and “Journal definition considerations” on page 184. see “Journal definitions created by other processes” on page 178. a. in cases where you cannot use remote journaling. temporarily change the Action for running audits policy using the following command: SETMMXPCY DGDFN(name system1 system2) RULE(*NONE) RUNAUDIT(*CMPRPR) b. resolve the problem. d. see “Resolving audit problems . type WRKAUD RULE(#DGFE) and press Enter. For other object types or classes. For additional information. From the source system. Use “Loading IFS tracking entries” on page 257. Class Librarybased objects How to configure data group entries a new MIMIX source-send configuration.5250 emulator” on page 543 and “Interpreting results for configuration data . c. Do the following to confirm and automatically correct any problems found in file entries associated with data group object entries: a. Use Table 27 to create data group entries for this configuration. 10. type 9 (Run rule) and press F4 (Prompt). If the journaling environment does not exist. load object tracking entries for *DTAARA and *DTAQ objects to be replicated from a user journal. Use “Loading object tracking entries” on page 258. From the management system. 129 . Next to the data group you want to confirm. any replication options identified in planning topic “Replication choices by object type” on page 88 are supported. On the Run Rule (RUNRULE) display specify *NO for the Use run rule on system policy prompt. load IFS tracking entries for IFS objects to be replicated from a user journal. After creating IFS entries. Then press Enter.Checklist: New MIMIX source-send configuration 9. Check the audit status for a value of *NODIFF or *AUTORCVD.#DGFE audit” on page 546. load file entries for PF (data) *FILE objects using “Loading file entries from a data group’s object entries” on page 247. After creating object entries. Planning and Requirement Information “Identifying library-based objects for replication” on page 91 “Identifying logical and physical files for replication” on page 96 “Identifying data areas and data queues for replication” on page 103 IFS objects “Identifying IFS objects for replication” on page 106 DLOs “Identifying DLOs for replication” on page 111 11. Do the following: 1. 2. e. 2. Create IFS entries using “Creating data group IFS entries” on page 255. This configuration requires object entries and file entries for legacy cooperative processing of PF data files. After creating object entries. Create object entries using “Creating data group object entries” on page 242. 3. Table 27. 1. use topic “Building the journaling environment” on page 195 to create the journaling environment. Create DLO entries using “Creating data group DLO entries” on page 259. If the audit results in any other status. Topic “Verifying the initial synchronization” on page 447 identifies the additional aspects of your configuration that are necessary for successful replication. configured for user journal replication. Topic “Performing the initial synchronization” on page 442 identifies options available for synchronizing and identifies how to establish a synchronization point that identifies the journal location that will be used later to initially start replication. 13. Confirm that the systems are synchronized by checking the libraries. For data areas or data queues configured for user journal replication. 17. (The default value is *INST. 16. 14. folders and directories contain expected objects on both systems. 130 . 15. Verify your configuration.) Use the command: SETMMXPCY DGDFN(name system1 system2) RULE(*NONE) RUNAUDIT(*INST) 12. set the Action for running audits policy to its previous value. • • • For user journal replication. From the management system. be sure to specify *SRC for the Start journaling on system (JRNSYS) parameter in the commands to start journaling. Start the data group using “Starting data groups for the first time” on page 282. use “Journaling for data areas and data queues” on page 303. Note: If the objects do not yet exist on the target system. Synchronize the database files and objects on the systems between which replication occurs. Use the procedure “Setting data group auditing values manually” on page 270. use “Journaling for IFS objects” on page 300. Start journaling using the following procedures as needed for your configuration. Doing this now ensures that objects to be replicated have the object auditing values necessary for replication and that any transactions which occur between configuration and starting replication processes can be replicated. use “Journaling for physical files” on page 297 to start journaling on both source and target systems.f. Ensure that object auditing values are set for the objects identified by the configuration before synchronizing data between systems. For IFS objects. 3. you need to end the data group you are converting to remote journaling and start it again as follows: a. Use topic “Checking DDM password validation level in use” on page 280. 6. Perform these tasks from the MIMIX management system unless these instructions indicate otherwise. data queues. files configured for legacy processing prior to this conversion will continue to be replicated with legacy cooperative processing. Modify the data group definition as follows: a. 8. Specify *YES for the Use remote journal link prompt. and IFS objects are processed. Connect the journal definitions for the local and remote journals using “Adding a remote journal link” on page 202. From the Work with DG Definitions display. Perform a controlled end of the data group (ENDDG command). you need to verify that your environment will allow MIMIX RJ support to work properly. 7. type a 2 (Change) next to the data group you want and press Enter. Build the journaling environment on each system defined by the RJ pair using “Building the journaling environment” on page 195. Do the following to ensure that you have a functional transfer definition: a. c. This procedure also creates the target journal definition. If you are using the TCP protocol. Use topic “Changing a transfer definition to support remote journaling” on page 165. make the modifications to the program described in “Changes to startup programs” on page 278. press Enter. b. 1. Verify the communications link using “Verifying the communications link for a data group” on page 174. To make the configuration changes effective. d. When you are ready to accept the changes. For example. Modify the transfer definition to identify the RDB directory entry.Checklist: Converting to remote journaling Checklist: Converting to remote journaling Use this checklist to convert an existing data group from using MIMIX source-send processes to using MIMIX Remote Journal support for user journal replication. 131 . Refer to topic “Ending all replication in a controlled manner” in the Using MIMIX book. b. If you use a startup program. 4. ensure that the DDM TCP server is running using topic “Starting the DDM TCP/IP server” on page 279. Press Enter to see additional prompts. 2. If you have implemented DDM password validation. 5. Note: This checklist does not change values specified in data group entries that affect how files are cooperatively processed or how data areas. specifying *ALL for Process and *CNTRLD for End process. The Change Data Group Definition (CHGDGDFN) display appears. 132 . Be sure to specify *ALL for Start processes prompt (PRC parameter) and *LASTPROC as the value for the Database journal receiver and Database large sequence number prompts.b. Start data group replication using the procedure “Starting selected data group processes” in the Using MIMIX book. Requirements: Before starting. For a complete list of required and recommended IBM PTFs.Converting to MIMIX Dynamic Apply Converting to MIMIX Dynamic Apply Use either procedure in this topic to change a data group configuration to use MIMIX Dynamic Apply. As of version 5. 133 . Perform the following steps from the management system on an active data group: 1. Keyed replication cannot be present in the data group configuration. consider the following: • Any data group that existed prior to installing version 5 must use one of these procedures in order to use MIMIX Dynamic Apply. • • “Converting using the Convert Data Group command” on page 133 automatically converts a data group configuration. objects of type *FILE (LF. PF source and data) are replicated using primarily user journal replication processes. This configuration is the most efficient way to process these files. The conversion is complete when you see message LVI321A. Any data group to be converted must already be configured to use remote journaling. The data group must be active when starting the conversion. From a command line enter the command: CVTDG DGDFN(name system1 system2) 2. log in to Support Central and refer to the Technical Documents page. Any data group to be converted must have *SYSJRN specified as the value of Cooperative journal (COOPJRN). A minimum level of IBM i PTFs are required on both systems. It is recommended that you contact your Certified MIMIX Consultant for assistance before performing this procedure. This command will automatically attempt to perform the steps described in the manual procedure and will issue diagnostic messages if a step cannot be performed. “Checklist: manually converting to MIMIX Dynamic Apply” on page 134 enables you to perform the conversion yourself. The conversion must be performed from the management system. Converting using the Convert Data Group command The Convert Data Group (CVTDG) will automatically convert the configuration of specified data groups to enable MIMIX Dynamic Apply. newly created data groups are automatically configured to use MIMIX Dynamic Apply when its requirements and restrictions are met and shipped command defaults are used. In a MIMIX Dynamic Apply configuration. • • • • • For additional information about configuration requirements and limitations of MIMIX Dynamic Apply. see “Identifying logical and physical files for replication” on page 96. Watch for diagnostic messages in the job log and take any recovery action indicated. For more information. Use the command: CHGDGDFN DGDFN(name system1 system2) COOPJRN(*USRJRN) 9. See “Requirements and limitations of MIMIX Dynamic Apply” on page 101. 134 . This can be done by running the following command from the source system: SETDGAUD DGDFN(name system1 system2) OBJTYPE(*AUTOJRN) Note: The QDFTJRN data area is created in libraries identified by data group object entries which are configured for cooperatively processing of files. To ensure that new files created while the data group is inactive are automatically journaled. 8. From the management system.Checklist: manually converting to MIMIX Dynamic Apply Perform the following steps from the management system to enable an existing data group to use MIMIX Dynamic Apply: 1. 5. Apply any IBM PTFs (or their supersedes) associated with IBM i releases as they pertain to your environment. 3. Follow the steps for “Confirming the end request completed without problems” in the Using MIMIX book. You may need to create additional entries to achieve desired results. Note: Topic “Ending a data group in a controlled manner” in the Using MIMIX book includes subtask “Preparing for a controlled end of a data group” and the other subtasks needed for Step 6 and Step 7. subject to some limitations For a list of restricted libraries and other details of requirements for implicitly starting journaling. the QDFTJRN data areas must be created in the libraries configured for replication of cooperatively processed files. Ensure that you have one or more data group object entries that specify the required values. 4. Log in to Support Central and refer to the Technical Documents page for a list of required and recommended IBM PTFs. see “Identifying logical and physical files for replication” on page 96. Use the Work with Data Groups display to ensure that there are no files on hold and no failed or delayed activity entries. 7. These entries identify the items within the name space for replication. Refer to topic “Preparing for a controlled end of a data group” in the Using MIMIX book. Ensure that there are no open commit cycles for the database apply process. Verify that data group is synchronized by running the MIMIX audits. 6. See “Verifying the initial synchronization” on page 447. Follow the procedure for “Performing the controlled end” in the Using MIMIX book. 2. change the data group definition so that the Cooperative journal (COOPJRN) parameter specifies *USRJRN. Verify that the System Manager jobs are active. Perform a controlled end of the data group you are converting. see “What objects need to be journaled” on page 294. See “Starting the system and journal managers” on page 269. 10. Verify the environment meets the requirements and restrictions. See “Starting journaling for physical files” on page 297. 135 . From the management system. 12. Start journaling for all files not previously journaled. Ensure that the value you specify (*SYS1 or *SYS2) for the LODSYS parameter identifies the target system. See “Verifying the initial synchronization” on page 447. see “Loading file entries from a data group’s object entries” on page 247. Start the data group specifying the command as follows: STRDG DGDFN(name system1 system2) CLRPND(*YES) 14. Verify that data groups are synchronized by running the MIMIX audits. use the following command to load the data group file entries from the target system. LODDGFE DGDFN(name system1 system2) CFGSRC(*DGOBJE) UPDOPT(*ADD) LODSYS(value) SELECT(*NO) For additional information about loading file entries. 13.Converting to MIMIX Dynamic Apply 11. *DTAQ. To convert existing data groups to use advanced journaling. 5. see “Restrictions . and data queues should be replicated in a data group shared with other objects undergoing database replication. Verify the value in the data group definition is correct. Use the command WRKDGACTE STATUS(*ACTIVE) to display any pending activity entries. including examples Database apply session balancing User exit program considerations 2. the journal definitions and journaling environment for user journal replication may not exist. Be sure to specify *YES for the Cooperate with database prompt in procedure “Adding or changing a data group IFS entry” on page 255. IFS objects to user journaling Use this checklist to change the configuration of an existing data group so that IFS objects. data areas. It also identifies the MIMIX processes used for replication and the purpose of tracking entries.Checklist: Change *DTAARA. Determine if IFS objects.) The procedure in this checklist assumes that the data group already includes user journal replication for files. 6. (This environment is also called advanced journaling. Perform a controlled end of the data groups that will include objects to be replicated using advanced journaling. Add or change data group object entries for the data areas and data queues you want to replicate using the procedure “Adding or changing a data group object 136 . Topic “Planning for journaled IFS objects. and data queues must specify *ALL as the value for Data group type (TYPE). or if these objects should be in a separate data group. The data group definitions used for user journal replication of IFS objects. *DTAARA and *DTAQ objects can be replicated from entries in a user journal. See the Using MIMIX book for how to end a data group in a controlled manner (ENDOPT(*CNTRLD)).user journal replication of IFS objects” on page 109. data areas. For additional information. data areas. Any activities that are still in progress will be listed. do the following: 1. and data queues” on page 79 provides guidelines for the following planning considerations: • • • • Serializing transactions with database files Converting existing data groups. If necessary. create the journal definitions (“Creating a journal definition” on page 192) and build the journaling environment (“Building the journaling environment” on page 195). change the value. Add or change data group IFS entries for the IFS objects you want to replicate. Note: If you have to change the Data group type. 3. If necessary. Topic “User journal replication of IFS objects. Ensure that all pending activity for objects and IFS objects has completed. data areas. 4. data queues” on page 69 describes the benefits and restrictions of replicating these objects from user journal entries. For data areas and data queues. 10. If you ever plan to switch the data groups. perform the steps in “Verifying journal receiver size options” on page 191 to ensure journaling is configured appropriately. 14. For more information about starting data groups. data areas and data queues between the source and target systems. 8. object. see “Verifying journaling for data areas and data queues” on page 305. See “User exit program considerations” on page 81. start the data groups. or file entries and starting the data group. IFS objects to user journaling entry” on page 243. use the SETDGAUD command before synchronizing data between systems. Verify that journaling is started correctly. This step is important to ensure the IFS objects. see “Restrictions . For IFS objects. data areas and data queues are actually replicated. Change any journal receiver size options necessary using “Changing journal receiver size options” on page 191. Start journaling using the following procedures as needed for your configuration. Use the procedure “Setting data group auditing values manually” on page 270. you should specify IBM i journal receiver size options that provide large journal receivers and large journal entries. For additional information. If you anticipate a delay between configuring data group IFS. 12. After IFS objects are configured. 11. Journals created by MIMIX are configured to allow maximum amounts of data. 137 . b. 7. 13. • • For IFS objects. Once you have completed the preceding steps. see the Using MIMIX book. Doing so will ensure that replicated objects are properly audited and that any transactions for the objects that occur between configuration and starting the data group are replicated. For IFS objects. If you are replicating large amounts of data. follow the Synchronize Object (SYNCOBJ) procedures. Use the procedures in “Loading tracking entries” on page 257. Refer to chapter “Synchronizing data between systems” on page 431 for additional information. For data areas and data queues. see “Verifying journaling for IFS objects” on page 302.user journal replication of data areas and data queues” on page 104. use “Starting journaling for data areas and data queues” on page 303 9. you must start journaling on both the source system and on the target system.Checklist: Change *DTAARA. Synchronize the IFS objects. follow the Synchronize IFS Object (SYNCIFS) procedures. Load the tracking entries associated with the data group IFS entries and data group object entries you configured. Journals that already exist may need to be changed. If you have database replication user exit programs. *DTAQ. use “Starting journaling for IFS objects” on page 300 For data areas or data queues. a. changes may need to be made. newly created data groups are configured for MIMIX Dynamic Apply when default values are taken and configuration requirements are met. Verify that data group is synchronized by running the MIMIX audits. Note: Topic “Ending a data group in a controlled manner” in the Using MIMIX book includes subtask “Preparing for a controlled end of a data group” and the subtask needed for Step 3. 2. This checklist does not convert user journal replication processes from using remote journaling to MIMIX source-send processing. End the data group you are converting by performing a controlled end. Follow the procedure for “Performing the controlled end” in the Using MIMIX book. 138 . use this checklist to change the configuration of an existing data group so that user journal replication (MIMIX Dynamic Apply) is no longer used. 4. See “Verifying the initial synchronization” on page 447. consider the following: • • • As of version 5. change the data group definition so that the Cooperative journal (COOPJRN) parameter specifies *SYSJRN. This checklist changes the configuration so that physical data files can be processed using legacy cooperative processing. LODDGFE DGDFN(name system1 system2) CFGSRC(*DGOBJE) UPDOPT(*REPLACE) LODSYS(value) SELECT(*NO) For additional information about loading file entries. The configuration of any other *DTAARA. Refer to topic “Preparing for a controlled end of a data group” in the Using MIMIX book. Perform the following steps to enable legacy cooperative processing and system journal replication: 1. Save the data group file entries to an outfile.Checklist: Converting to legacy cooperative processing If you find that you cannot use MIMIX Dynamic Apply for logical and physical files. From the management system. This checklist only affects the configuration of *FILE objects. 3. Important! Before you use this checklist. Ensure that the value you specify (*SYS1 or *SYS2) for the LODSYS parameter identifies the target system. From the management system. For more information. *DTAQ. Use the Work with Data Groups display to ensure that there are no files on hold and no failed or delayed activity entries. or IFS objects that are replicated through the user journal are not affected. see “Loading file entries from a data group’s object entries” on page 247. Logical files and physical source files will be processed using the system journal. use the following command to load the data group file entries from the target system. Use the command: WRKDGFE DGDFN(DGDFN SYS1 SYS2) OUTPUT(*OUTFILE) 6. see “Requirements and limitations of legacy cooperative processing” on page 102. Use the command: CHGDGDFN DGDFN(name system1 system2) COOPJRN(*SYSJRN) 5. 8. Start the data group specifying the command as follows: STRDG DGDFN(name system1 system2) CRLPND(*YES) 139 . Examine the data group file entries with those saved in the outfile created in Step 5. run the following command from each system: DLTDTAARA DTAARA(library/QDFTJRN) 9. Such a difference will be detected by the file attributes (#FILATR) audit. These data areas automatically start journaling for newly created files. Optional step: Delete the QDFTJRN data areas.Checklist: Converting to legacy cooperative processing 7. Any differences need to be manually updated. This may not be desired because the journal image (JRNIMG) value for these files may be different than the value specified in the MIMIX configuration. To delete these data areas. MIMIX supports the following communications protocols: • • • Transmission Control Protocol/Internet Protocol (TCP/IP) Systems Network Architecture (SNA) OptiConnect MIMIX should have a dedicated communications line that is not shared with other applications. For TCP/IP. MIMIX IntelliStart can help you determine your communications requirements.System-level communications CHAPTER 6 System-level communications This information is provided to assist you with configuring the IBM PowerTM Systems communications that are necessary before you can configure MIMIX. or users on the production system. “Configuring APPC/SNA” on page 144 describes basic requirements for SNA communications. but if your primary communications protocol is TCP/IP. you need to consider additional aspects that may affect the communications speed. The topics in this chapter include: • • • “Configuring for native TCP/IP” on page 140 describes using native TCP/IP communications and provides steps to prepare and configure your system for it. user spaces. A dedicated path will make it easier to fine-tune your MIMIX environment and to determine the cause of problems. Your Certified MIMIX Consultant can assist you in determining your communications requirements and ensuring that communications can efficiently handle peak volumes of journal transactions. 140 . this can simplify your network configuration. If you plan to use system journal replication processes. jobs. This allows users with TCP communications on their networks to use MIMIX without requiring the use of IBM ANYNET through SNA. These aspects include the type of objects being transferred and the size of data queues. it is recommended that the TCP/IP host name or interface used be in its own subnet. Using TCP/IP communications may or may not improve your CPU usage. For SNA. it is recommended that MIMIX have its own communication line instead of sharing an existing SNA device. Configuring for native TCP/IP MIMIX has the ability to use native TCP/IP communications over sockets. “Configuring OptiConnect” on page 144 describes basic requirements for OptiConnect communications and identifies MIMIX limitations when this communications protocol is used. and files defined to cooperate with user journal replication processes. you can begin the MIMIX configuration process. and follow the instructions to configure the system to use TCP/IP communications. Creating Ports. In this example. The procedure for configuring a system to use TCP/IP is documented in the information included with the IBM i software. MIMIX installations vary according to the needs of each enterprise. Preparing your system to use TCP/IP communications with MIMIX requires the following: 1. Port aliases-simple example Before using the MIMIX TCP/IP support. 2. Figure 9 shows a MIMIX installation with two network systems. Configure both systems to use TCP/IP. A more complex MIMIX installation may consist of one management system and multiple network systems. Figure 9.Configuring for native TCP/IP Native TCP/IP communications allow MIMIX users greater flexibility and provides another option in the communications available for use on their PowerTM Systems. If you need to use port aliases. b. a MIMIX installation consists of one management system and one network system. 3. Creating Ports. SC41-5430. the MIMIX installation consists of two systems. At a minimum. Refer to the IBM TCP/IP Fastpath Setup book. A large enterprise may even have multiple MIMIX installations that are interconnected. the MIMIX installation consists of three systems. you must first configure the system to recognize the feature. In this example. Figure 8 shows a simple MIMIX installation in which the management system (LONDON) and a network system (HONGKONG) use the TCP communications protocol through the port number 50410. MIMIX users can also continue to use IBM ANYNET support to run SNA protocols over TCP networks. The port identifiers used depend on the configuration of the MIMIX installations. Create the port aliases for each system using the procedure in topic “Creating port aliases” on page 143. Once the system-level communication is configured. 141 . Figure 8. do the following: a. Refer to the examples “Port aliases-simple example” on page 141 and “Port aliases-complex example” on page 142. This involves identifying the ports that will be used by MIMIX to communicate with other systems. you need to have a service table entry on each system that equates the port number to the port alias. Figure 10 shows an example of such an environment with two MIMIX installations. Figure 10. For example. Port aliases-complex example If a network system communicates with more than one management system (it participates with multiple MIMIX installations).System-level communications two of which are network systems. one for each MIMIX installation in which it participates. it must have a different port for each management system with which it communicates. the port 50410 is used to communicate between LONDON (the management system) and HONGKONG and CHICAGO (network systems). you might have a service table entry on system LONDON that defines an alias of MXMGT for port number 50410. In the LIBB cluster. if you need to use port aliases for port 50410. Creating Port Aliases. the port 50411 is used to communicate between CHICAGO (the management system for this cluster) and MEXICITY and CAIRO. In this example. The CHICAGO system has two port numbers defined. Similarly. the system CHICAGO participates in two 142 . you might have service table entries on systems HONGKONG and CHICAGO that define an alias of MXNET for port 50410. You would use these aliases in the PORT1 and PORT2 parameters in the transfer definition. In the LIBA cluster. In both Figure 8 and Figure 9. • Do the following to create a port alias on a system: 1. you need to add port aliases for both systems in the pair on each system. Select option 21 (Configure related tables) and press Enter. You might use an alias of LIBBMGT for port 50411 on CHICAGO and an alias of LIBBNET for port 50411 on both CAIRO and MEXICITY. From a command line. Notes: • • Perform this procedure on each system in the MIMIX installation that will use the TCP protocol. If you need to use port aliases in an environment such as Figure 10. 2. In this example. you might use a port alias of LIBAMGT for port 50410 on LONDON and an alias of LIBANET for port 50410 on both HONKONG and CHICAGO. 143 . such as between a management system and a network system. For example. To allow communications in both directions between a pair of systems. type the command CFGTCP and press Enter.Configuring for native TCP/IP MIMIX installations and uses a separate port for each MIMIX installation. Creating port aliases The following procedure describes the steps for creating port aliases which allow MIMIX installations to communicate through TCP/IP. If you are using more than one MIMIX installation. you need to have a service table entry on each system that equates the port number to the port alias. The Configure TCP/IP menu appears. define a different set of aliases for each MIMIX installation. You would use these port aliases in the PORT1 and PORT2 parameters on the transfer definitions. CHICAGO would require two port aliases and two service table entries. In the blank at the top of the Port column. type TCP to identify this entry as using TCP/IP communications. c. Configuring APPC/SNA Before you create a transfer definition that uses the SNA protocol. Configuring OptiConnect If you plan to use the OptiConnect protocol. Type a 1 in the Opt column next to the blank lines at the top of the list. The Work with Service Table Entries display appears. 5. Do the following: a. consult your network administrator before continuing. and device do not exist. Verify that the information shown for the alias and port is what you want. and then press Enter. 4. In the blank at the top of the Protocol column. Use the 144 . and device must exist between the systems that will be identified by the transfer definition. b. Select option 1 (Work with service table entries) and press Enter. Attention: MIMIX requires that you restrict the length of port aliases to 14 or fewer characters and suggests that you specify the alias in uppercase characters. a functioning OptiConnect line must exist between the two system that you identify in the transfer definition You can use the OptiConnect® product from IBM for all communication for most1 MIMIX processes. Vision Solutions recommends that you use the same port number or same port alias on each system in the MIMIX installation. You can page down through the list to ensure that the number is not being used by the system. enclosed in apostrophes. controller. In the blank at the top of the Service column. type a description of the port alias.System-level communications 3. controller. Note: Port alias names are case sensitive and must be unique to the system on which they are defined. a functioning SNA (APPN or APPC) line. Press Enter. d. At the Text 'description' prompt. use uppercase characters to specify the alias that the System i will use to identify this port as a MIMIX native TCP port. The Add Service Table Entry (ADDSRVTBLE) display appears. Use the IBM book OptiConnect for OS/400 to install and verify OptiConnect communications. Then you can do the following: • Ensure that the QSOC library is in the system portion of the library list. e. The Configure Related Tables display appears. For environments that have only one MIMIX installation. specify the number of an unused port ID to be associated with the alias. If a line. The port ID can be any number greater than 1024 and less than 55534 that is not being used by another application. The #FILDTA audit and the Compare File Data (CMPFILDTA) command require TCP/IP communicaitons. specify *OPTI for the transfer protocol. use the CHGSYSVAL command to add this library to the system library list. • When you create the transfer definition.Configuring OptiConnect command DSPSYSVAL SYSVAL(QSYSLIBL) to verify whether the QSOC library is in the system portion of the library list. 1. 145 . If it not. 146 . “Changing a system definition” on page 151 provides the steps to follow for changing a system definition. It is recommended that you avoid naming system definitions based on their roles. and backup change upon switching. When you create a system definition.Configuring system definitions CHAPTER 7 Configuring system definitions By creating a system definition. production. you identify to MIMIX characteristics of IBM PowerTM Systems that participate in a MIMIX installation. MIMIX automatically creates a journal definition for the security audit journal (QAUDJRN) for the associated system. “Multiple network system considerations” on page 152 describes recommendations when configuring an environment that has multiple network systems. The topics in this chapter include: • • • • “Tips for system definition parameters” on page 147 provides tips for using the more common options for system definitions. target. This journal definition is used by MIMIX system journal replication processes. System roles such as source. “Creating system definitions” on page 150 provides the steps to follow for creating system definitions. $. You can also control the severity and type of messages that are sent to each message queue.). Context-sensitive help is available online for all options on the system definition commands. If you specify a Secondary transfer definition. the primary message queue. By default. #.Z. The system (node) will not be added to the cluster until the system manager is started the first time. Message handling (PRIMSGQ. MIMIX does not automatically create transfer definitions. it will be used by MIMIX if communications path specified by the primary transfer definition is not available. or @. MIMIX. #. The remaining characters can be alphanumeric and can contain a $. Transfer definitions (PRITRFDFN. Only one system in the MIMIX installation can be a management system. SYSMGRDLY) Two parameters define the delay times used for all journal management and system management jobs. the first character must be either A . System type (TYPE) This parameter indicates the role of this system within the MIMIX installation. SECMSGQ) MIMIX uses the centralized message log facility which is common to all MIMIX products. is located in the MIMIXQGPL library. A system can be a management (*MGT) system or a network (*NET) system. Manager delay times (JRNMGRDLY. @. The communications path and protocol are defined in the transfer definitions. System definition (SYSDFN) This parameter is a single-part name that represents a system within a MIMIX installation. a period (. SECTFRDFN) These parameters identify the primary and secondary transfer definitions used for communicating with the system. Note: In the first part of the name. You must specify *TCP as the transfer protocol. or an underscore (_). You can specify a different message queue or optionally specify a secondary message queue. The value of the journal manager delay parameter determines how often the journal manager process checks for work to perform. For MIMIX to be operational. The value of the system manager delay parameter determines how often the system manager process checks for work to perform. the transfer definition names you specify must exist. Cluster member (CLUMBR) You can specify if you want this system definition to be a member of a cluster. If you accept the default value primary for the Primary transfer definition.Tips for system definition parameters Tips for system definition parameters This topic provides tips for using the more common options for system definitions. These parameters provide additional flexibility by allowing you to identify the message queues associated with the system definition and define the message filtering criteria for each message queue. This name is a logical representation and does not need to match the system name that it represents. 147 . Cluster transfer definition (CLUTFRDFN) You can specify the transfer definition that cluster resource services will use to communicate to the node and for the node to communicate with other nodes in the cluster. create a transfer definition by that name. For libraries created in a user ASP. The management or network role of the system affects the results of the time you specify on a system definition. all objects in the library must be in the same ASP as the library.Output queue values (OUTQ. DSKSTGLMT) Three parameters define information about MIMIX data libraries on the system. restart daily to maintain the MIMIX environment. DFTJOBD) MIMIX runs under the MIMIXOWN user profile and uses several job descriptions to optimize MIMIX processes. ASP group (ASPGRP) This parameter is used for installing MIMIX into a switchable independent ASP. The default job descriptions are stored in the MIMIXQGPL library. including the system manager and journal manager. Keep notifications (KEEPNEWNFY. You can change the time at which these jobs restart. The Disk storage limit (GB) parameter specifies the maximum amount of disk storage that may be used for the MIMIX data libraries. MIMIX system history includes the system message log. Keep history (KEEPSYSHST. KEEPACKNFY) Two parameters specify the number of days to retain new and acknowledged notifications. HOLD. COPIES) These parameters control characteristics of printed output. MGRJOBD. The Keep MIMIX data (days) parameter specifies the number of days to retain objects in the MIMIX data library. The only time this parameter should be used is in the case of an INTRA system (which is handled by the default value) or in replication environments where it is necessary to have extra MIMIX system definitions that will “switch locations” along with the switchable independent ASP. User profile and job descriptions (SBMUSR. including the container cache used by system journal replication processes. DTALIBASP. KEEPDGHST) Two parameters specify the number of days to retain MIMIX system history and data group history. and allows you to specify a MIMIX installation library that does not match the library name of the other system definitions. changing the product library is considered an advanced technique and should not be attempted without the assistance of a Certified MIMIX Consultant. and defines the ASP group (independent ASP) in which the product library exists. LPI. this parameter should only be used in replication 148 . SAVE) These parameters identify an output queue used by this system definition and define characteristics of how the queue is handled. You can hold spooled files on the queue and save spooled files after they are printed. storage limit (KEEPMMXDTA. Product library (PRDLIB) This parameter is used for installing MIMIX into a switchable independent ASP. You can keep both types of history information on the system for up to a year. The Keep new notifications (days) parameter specifies the number of days to retain new notifications in the MIMIX data library. MIMIX data library. Printing (CPI. Again. Changing the job restart time is considered an advanced technique. FORMLEN. The MIMIX data library ASP parameter identifies the auxiliary storage pool (ASP) from which the system allocates storage for the MIMIX data library. The Keep acknowledged notifications (days) parameter specifies the number of days to retain acknowledged notifications in the MIMIX data library. Due to its complexity. OVRFLW. Any MIMIX functions that generate reports use this output queue. Data group history includes time stamps and distribution history. Job restart time (RSTARTTIME) System-level MIMIX jobs. Due to its complexity. changing the ASP group is considered an advanced technique and should not be attempted without the assistance of a Certified MIMIX Consultant.Tips for system definition parameters environments involving a switchable independent ASP. 149 . Specify the names of the transfer definitions you want at the Primary transfer definition and. press F10 (Additional parameters). If you want to verify or change values for additional parameters.Creating system definitions To create a system definition. type a brief description of the system definition. 7. If you want use to a secondary message queue. do the following: a. 9. Type a 1 (Create) next to the blank line at the top of the list area and press Enter. 5. b. The Create System Definition (CRTSYSDFN) display appears. Once created. 6. 8. The Work with System Definitions display appears. Specify the appropriate value for the system you are defining at the System type prompt. To create the system definition. Verify that the value of the Cluster transfer definition is what you want. the Secondary transfer definition prompts. Specify *YES at the Cluster member prompt. If necessary. 150 . 2. 10. do the following: 1. 3. Specify a name at the System definition prompt. If the system definition is for a cluster environment. From the MIMIX Configuration Menu. change the value. 4. the name can only be changed by using the Rename System Definition command. if desired. select option 1 (Work with system definitions) and press Enter. At the Description prompt. press Enter. at the prompts for Secondary message handling specify the name and library of the message queue and values indicating the severity and the Information type of messages to be sent to the queue. Changing a system definition Changing a system definition To change a system definition. 3. Press F10 (Additional parameters) 4. To save the changes press Enter. 2. Locate the prompt for the parameter you need to change and specify the value you want. The Change System Definition (CHGSYSDFN) display appears. From the MIMIX Configuration Menu. do the following: 1. 151 . select option 1 (Work with system definitions) and press Enter. Type a 2 (Change) next to the system definition you want and press Enter. 5. Press F1 (Help) for more information about the values for each parameter. The Work with System Definitions display appears. 1=Create 2=Change 3=Copy 11=Verify communications link 13=Data group definitions 4=Delete 5=Display 6=Print 12=Journal definitions 14=Transfer definitions Cluster Member *NO *NO *NO LONDON 7=Rename Opt __ __ __ __ System _______ CHICAGO NEWYORK LONDON Type *NET *NET *MGT -Transfer DefinitionsPrimary Secondary PRIMARY PRIMARY PRIMARY *NONE *NONE *NONE Figure 12. Figure 12 shows the recommended transfer definition configuration which uses the value *ANY for both systems identified by the transfer definition. The management system (LONDON) specifies the value PRIMARY for the primary transfer definition in its system definition. The management system can communicate with the other systems using any transfer definition named PRIMARY that has a value for System 1 or System 2 that resolves to its system name (LONDON). Similarly. Work with System Definitions System: Type options. If you use a different name. it is recommended that each system definition in the environment specify the same name for the Primary transfer definition prompt. it is recommended that each system definition in the multiple network environment specifies the same name for the Secondary transfer definition prompt. This configuration is necessary for the MIMIX system managers to communicate between the management system and all systems in the network. if you use secondary transfer definitions. press Enter. The management system LONDON could also use any transfer definition that specified the name LONDON as the value for either System 1 or System 2. you need to specify that name as the value for the Primary transfer definition prompt in all system definitions in the environment. The default value for the name of a transfer definition is PRIMARY. Data groups can use the same transfer definitions that the system managers use. or they can use differently named transfer definitions.) Figure 11 shows system definitions in a multiple network system environment. Example of system definition values in a multiple network system environment. (The value of the Secondary transfer definition should be different than the value of the Primary transfer definition.Multiple network system considerations When configuring an environment that has multiple network systems. Figure 11. Example of a contextual (*ANY) transfer definition in use for a multiple network 152 . Work with Transfer Definitions System: Type options.Multiple network system considerations system environment. press Enter. 1=Create 2=Change 3=Copy 11=Verify communications link 4=Delete 5=Display 6=Print LONDON 7=Rename Opt __ ---------Definition--------Name System 1 System 2 __________ _______ ________ PRIMARY *ANY *ANY Protocol *TCP Threshold (MB) *NOMAX 153 . MIMIX can automatically use a secondary transfer definition if the path defined in your primary transfer definition is not available. If you want to be able to use different transfer protocols between a pair of systems.Configuring transfer definitions CHAPTER 8 Configuring transfer definitions By creating a transfer definition. The topics in this chapter include: • • • • “Tips for transfer definition parameters” on page 156 provides tips for using the more common options for transfer definitions. You need at least one transfer definition for each pair of systems between which you want to perform replication. • • • • 154 . you identify to MIMIX the communications path and protocol to be used between two systems. Once transfer definitions exist for MIMIX. “Starting the TCP/IP server” on page 168 provides the steps to follow if you need to start the Lakeview TCP/IP server. This topic also includes sub-task for how to changing a transfer definition when converting to a remote journaling environment. A pair of systems consists of a management system and a network system. System-level communication must be configured and operational before you can use a transfer definition. “Finding the system database name for RDB directory entries” on page 167 provides the steps to follow for finding the system database name for RDB directory entries. a transfer definition defines a communications path and protocol to be used between the two product libraries used by Intra. refer to “Configuring Intra communications” on page 514. For detailed information about configuring an Intra environment. “Creating a transfer definition” on page 163 provides the steps to follow for creating a transfer definition. “Using contextual (*ANY) transfer definitions” on page 160 describes using the value (*ANY) when configuring transfer definitions. In an Intra environment. they can be used for other functions. create a transfer definition for each protocol. such as the Run Command (RUNCMD). “Changing a transfer definition” on page 165 provides the steps to follow for changing a transfer definition. You can also define an additional communications path in a secondary transfer definition. or by other MIMIX products for their operations. If configured. “Using autostart job entries to start the TCP server” on page 169 provides the steps to configure the Lakeview TCP server to start automatically every time the MIMIX subsystem is started “Verifying a communications link for system definitions” on page 173 provides the steps to verify that the communications link defined for each system definition is operational. 155 .• “Verifying the communications link for a data group” on page 174 provides a procedure to verify the primary transfer definition used by the data group. a period (. for the HOST2 parameter.nnn. Short transfer definition name (TFRSHORTN) This parameter specifies the short name of the transfer definition to be used in generating a relational database (RDB) directory name. HOST2) These two parameters specify the host name or address of system 1 and system 2.nnn.Z). For the HOST1 parameter. or an underscore (_). the first character must be either A . the last character of the system 1 name. Context-sensitive help is available online for all options on the transfer definition commands. For the *TCP protocol the following parameters apply: • System x host name or address (HOST1. a letter (A . respectively. the special value *SYS1 indicates that the host name is the same as the name specified for System 1 in the Transfer definition parameter. see “Using contextual (*ANY) transfer definitions” on page 160.9). For more information about allowing MIMIX to resolve the system names. $.). or a single digit number (0 . It is recommended that you use the default value *GEN to generate the name. Note: In the first part of the name. 156 . For more information. a transfer definition must identify the two systems that will be used by the data group.Z. #. Transfer protocol (PROTOCOL) This parameter specifies the communications protocol to be used. If you change the protocol specified after you have created the transfer definition. four-character name if you specify to have MIMIX manage your RDB directory entries. To support replication.nnn) and can be up to 256 characters in length. The name is a mixed-case host alias name or a TCP address (nnn. see “Naming convention for remote journaling environments with 2 systems” on page 185. the last character of the system 2 name. or @. The generated name is a concatenation of the first character of the transfer definition name. It is recommended that you use PRIMARY as the name of one transfer definition. The second and third parts of the name identify two different system definitions which represent the systems between which communication is being defined. Transfer definition (TFRDFN) This parameter is a three-part name that identifies a communications path between two systems. the special value *SYS2 indicates that the host name is the same as the name specified for System 2 in the Transfer definition parameter. Similarly. The HOST parameter on the STRSVR command is limited to 80 or fewer characters. You can explicitly specify the two systems. Note: The specified value is also used when starting the Lakeview TCP Server (STRSVR command). The remaining characters can be alphanumeric and can contain a $.Tips for transfer definition parameters This topic provides tips for using the more common options for transfer definitions. or you can allow MIMIX to resolve the names of the systems. The first part of the name identifies the transfer definition. and the fourth character will be either a blank. #. @. Each protocol has a set of related parameters. The short transfer definition name must be a unique. MIMIX saves information about both protocols. For the *SNA protocol the following parameters apply: • System x location name (LOCNAME1. respectively. respectively. the default special value *PORT1 indicates that the value specified on the System 1 port number or alias (PORT1) parameter is used. for the LOCNAME2 parameter. LOCNAME2) These two parameters specify the location name or address of system 1 and system 2. the special value *SYS1 indicates that the location name is the same as the name specified for System 1 on the Transfer definition (TFRDFN) parameter. The default value *LOC indicates that the network identifier for the location name associated with the system is used. • • The following parameters apply for the *OPTI protocol: • System x location name (LOCNAME1. specify the alias name instead of the port number. System x network identifier (NETID1. Valid values range from 1 through 9999999. NETID2) These two parameters specify name of the network for system 1 and system 2. the special value *NETID1 indicates that the network identifier specified on the System 1 network identifier (NETID1) parameter is used. Similarly. the special value *SYS1 indicates that the location name is the same as the name specified for System 1 on the Transfer definition (TFRDFN) parameter. it is recommended that you use values between 40000 and 55500.Tips for transfer definition parameters • System x port number or alias (PORT1. The special 157 . The special value *NETATR indicates that the value specified in the system network attributes is used. respectively. The value of each parameter is the unique location name that identifies the system to remote devices. the PORT1 parameter uses the port 50410. If you configured TCP using port aliases in the service table. For the PORT2 parameter. PORT2) These two parameters specify the port number or port alias of system1 and system 2. the special value *SYS2 indicates that the location name is the same as the name specified for System 2 on the Transfer definition (TFRDFN) parameter. Threshold size (THLDSIZE) This parameter is accessible when you press F10 (Additional parameters). The value of each parameter can be a 14-character mixed-case TCP port number or port alias with a range from 1000 through 55534. For the LOCNAME1 parameter. The special value *NONE indicates that the network has no name. Similarly. To avoid potential conflicts with designations made by the operating system. The Relational database (RDB) parameter also applies to *TCP protocol. for the LOCNAME2 parameter. If the file or object exceeds the threshold it is not sent. The default name is MIMIX. respectively. By default. The special value *NETATR indicates that the value specified in the system network attributes is used. the special value *SYS2 indicates that the location name is the same as the name specified for System 2 on the Transfer definition (TFRDFN) parameter. This controls the size of files and objects by specifying the maximum size of files and objects that are sent. LOCNAME2) These two parameters specify the location name or address of system 1 and system 2. The value of each parameter is the unique location name that identifies the system to remote devices. For the LOCNAME1 parameter. SNA mode (MODE) This parameter specifies the name of mode description used for communication. For the NETID2 parameter. The default value *GEN causes MIMIX to create an RDB entry and add it to the relational database. For a given port number or alias. The parameter consists of a four relational database values. • 158 . Note: For remote journaling that uses an independent ASP. where nnnnnnnnnn is the 10-character installation name. and no directory entry is generated. This parameter creates two RDB directory entries. a directory entry is generated if you use the value *ANY for only one of the systems on the transfer definition. one on each system identified in the transfer definition. If you are managing the RDB directory entries and you need to determine the system database name. When you specify the special value *NONE. If MIMIX is managing your RDB directory entries.value *NOMAX indicates that no maximum value is set. whereby MIMIX will add. and ssss is the transfer definition short name. The four elements of the relational database parameter are: • Directory entry This element specifies the name of the relational database entry. The generated name is in the format MX_nnnnnnnnnn_ssss. An autostart job entry is created on each system related to the transfer definition. specify the database name for the independent ASP. The default value *SYSDB specifies that MIMIX will determine the relational database name. or remove an autostart job entry based on changes to this transfer definition. If you specify a value for the RDB parameter. only one autostart job entry will be created regardless of how many transfer definitions use that port number or alias. change. the directory entry is not added or changed by MIMIX. This directory entry is generated for the system that is specified as something other than *ANY. refer to “Finding the system database name for RDB directory entries” on page 167. see “Using contextual (*ANY) transfer definitions” on page 160. especially for slow communication lines. For more information about the use of the value *ANY on transfer definitions. Transmitting large files and objects can consume excessive communications bandwidth and negatively impact communications performance. and a management indicator for directory entries. Note: If you use the value *ANY for both system 1 and system 2 on the transfer definition. two system database names. The shipped default is *YES. *NONE is used for the directory entry name. Relational database (RDB) This parameter is accessible when you press F10 (Additional parameters) and is valid when default remote journaling configuration is used. Each entry identifies the other system’s relational database. System 1 relational database This element specifies the name of the relational database for System 1. which identify the communications path used by the IBM i remote journal function to transport journal entries: a relational database directory entry name. Manage autostart job entries (MNGAJE) This parameter is accessible when you press F10 (Additional parameters). This determines whether MIMIX will use this transfer definition to manage an autostart job entry for starting the TCP server for the MIMIXQGPL/MIMIXSBS subsystem description. it is recommended that you limit its length to 18 characters. This parameter only affects transfer definitions for TCP protocol which have host names of 80 or fewer characters. refer to “Finding the system database name for RDB directory entries” on page 167. If they do exist. the directory entry is also changed. If you are managing the RDB directory entries and you need to determine the system database name. If the relational database directory entries do not exist. When any of the transfer definition relational database values change. Management of the relational database directory entries consists of adding. specify the database name for the independent ASP. MIMIX adds them and sets any needed system values. The special value *YES indicates that the directory entries on each system are managed by MIMIX. Note: For remote journaling that uses an independent ASP. The special value *DFT indicates that MIMIX manages the relational database directory entries only when the name is generated using the special value *GEN on the Directory entry element of this parameter. changed.Tips for transfer definition parameters • System 2 relational database This element specifies the name of the relational database for System 2. the directory entries are also deleted. and deleting the directory entries on both systems. 159 . When the transfer definition is deleted. or deleted. when the transfer definition is created. The default value *SYSDB specifies that MIMIX will determine the relational database name. as needed. • Manage directory entries This element specifies that MIMIX will manage the relational database directory entries associated with the transfer definition whether the directory entry name is specified or whether the directory entry name is generated by MIMIX. MIMIX changes them to match the values specified by the Relational database (RDB) parameter. changing. a contextual transfer definition may be an aid in configuration. they are not recommended. best practice is to use transfer definitions that identify specific system definitions in the thee-part transfer definition name. INTRA) represents three transfer definitions: • • • PRIMARY SYSA SYSA PRIMARY SYSA SYSB PRIMARY SYSA INTRA Search and selection process Data group definitions and system definitions include parameters that identify associated transfer definitions. PRIMARY *ANY *ANY When you specify *ANY in the three-part name of a transfer definition. In MIMIX source-send configurations. MIMIX uses the context of the operation to determine the fully qualified name. PRIMARY *ANY SYSA 6. one for each system definition. For example.Using contextual (*ANY) transfer definitions When the three-part name of transfer definition specifies the value *ANY for System 1 or System 2 instead system names. SYSB. PRIMARY *ANY SYSB 3. a transfer definition PRIMARY SYSA *ANY in an installation that has three system definitions (SYSA. When an operation requires a transfer definition. and you have specified *TFRDFN for the Protocol parameter on such commands as RUNCMD or VFYCMNLNK. Such a transfer definitions is called contextual transfer definition. see “Considerations for remote journaling” on page 161. MIMIX searches your system and selects those systems with a 160 . The *ANY value represents several transfer definitions. PRIMARY SYSA *ANY 4. PRIMARY SYSB *ANY 7. when starting a data group. if you create a transfer definition named PRIMARY SYSA *ANY. to derive the fully qualified transfer definition name. For more information. For remote journaling environments. MIMIX uses information from the context in which the transfer definition is called to resolve to the correct system. Although you can use contextual transfer definitions with remote journaling. the systems specified in the data group name and the specified transfer definition name. MIMIX uses information in the data group definition. For example. PRIMARY SYSA SYSB 2. PRIMARY SYSB SYSA 5. For example. If MIMIX is still unable to find an appropriate transfer definition the following search order is used: 1. This definition can be used to provide the necessary parameters for establishing communications between SYSA and any other system. If there is an Intra system definition defined. The command would look like this: CRTTFRDFN TFRDFN(PRIMARY name *ANY) TEXT('description') MIMIX Remote Journal support requires that each transfer definition that will be used has a relational database (RDB) directory entry to properly identify the remote system. (PRIMARY SYSA SYSB). An RDB directory entry cannot be added to a transfer definition using the value *ANY for the remote system. the transfer definition can be used for replication from either direction. For example. By specifying both systems. the value *ANY can be used for the system where the local journal (source) resides. For example. where name identifies the system definition for the system where the remote journal (target) resides. A transfer definition of PRIMARY *ANY name is also valid. using the naming conventions for contextual systems.Using contextual (*ANY) transfer definitions transfer definition that matches the transfer definition that you specified. a transfer definition of PRIMARY name *ANY is valid in a remote journaling environment. For an Intra environment. Considerations for remote journaling Best practice for a remote journaling environment is to use a transfer definition that identifies specific system definitions in the thee-part transfer definition name. the command would look like this: CRTTFRDFN TFRDFN(PRIMARY *ANY *ANY) TEXT('Recommended configuration') Note: Ensure that you consult with your site TCP administrator before making these changes. This value can be either the second or third parts of the three-part name. Considerations for MIMIX source-send configurations When creating a transfer definition for a MIMIX source-send configuration that uses contextual system capability (*ANY) and the TCP protocol. To support a switchable data group when using contextual transfer definitions. The following is an example of an additional transfer definition that uses port number 42345 to establish communications with the Intra system: CRTTFRDFN TFRDFN(PRIMARY *ANY INTRA) PORT2(42345) TEXT('Recommended configuration') 161 . for example. For example. If you do use a contextual transfer definition in a remote journaling environment. you would need a transfer definition named PRIMARY NEWYORK *ANY as well as a transfer definition named PRIMARY CHICAGO *ANY. the transfer definition must specify a unique port number to communicate with Intra. an environment with systems NEWYORK and CHICAGO. take the default values for other parameters on the CRTTFRDFN command. each system in the remote journaling environment must be defined by a contextual transfer definition. an additional transfer definition is needed. However. For example. *OPTI protocol: The MIMIX system definition names must match the OptiConnect names for the systems (DSPOPCLNK). a SYSA controller would be necessary. Conversely.Naming conventions for contextual transfer definitions The following suggested naming conventions make the contextual (*ANY) transfer definitions more useful in your environment. you will receive an error message if the transfer definition has the value *ANY for either system 1 or system 2. entered from a command line. *SNA protocol: The MIMIX system definition names must match SNA environment (controller names) for the respective systems. When the VFYCMNLNK command is called from option 11 on the Work with System Definitions display or option 11 on the Work with Data Groups display. on the SYSA system there would have to be a controller called SYSB that is used for SYSA to SYSB communications. or included in automation programs. when the command is called from option 11 on the Work with Transfer Definitions display. The MIMIX system definitions should match the net attribute system name (DSPNETA). *TCP protocol: The MIMIX system definition names should correspond to DNS or host table entries that tie the names to a specific TCP address. MIMIX determine the specific system names. on SYSB. with two MIMIX systems called SYSA and SYSB. These commands do not handle transfer definitions that specify *ANY in the three-part name. Additional usage considerations for contextual transfer definitions The Run Command (RUNCMD) and the Verify Communications Link (VFYCMNLNK) commands requires specific system names to verify communications between systems. 162 . enclosed in apostrophes. do the following: 1. press F10 (Additional parameters). b. At the Threshold size (MB) prompt. then press Enter. If you are creating a transfer definition for a cluster environment. select option 21 (Work with transfer definitions) and press Enter. Optional step: If you need to set a maximum size for files and objects to be transferred. 5. From the MIMIX Cluster Menu. 4. specify the communications protocol you want. Make any necessary changes. you must accept the default of *TCP for the Transfer protocol prompt. 7. c.Creating a transfer definition Creating a transfer definition System-level communication must be configured and operational before you can use a transfer definition. At the Transfer protocol prompt. Type 1 (Create) next to the blank line at the top of the list area and press Enter. At the Transfer definition prompts. Optional step: If you need to change the relational database information. To create the transfer definition. specify a name and the two system definitions between which communications will occur. The Create Transfer Definition display appears. select option 2 (Work with transfer definitions) and press Enter. press F10 (Additional parameters). This short transfer definition name is used in generating relational database directory entry names if you specify to have MIMIX manage your RDB directory entries. 2. To create a transfer definition. If MIMIX is not managing the RDB directory entries. Access the Work with Transfer Definitions display by doing one of the following: • • From the MIMIX Configuration Menu. it may be necessary to change the RDB values. press Enter. Verify that the values shown are what you want. The Work with Transfer Definitions display appears. 8. Do the following: a. At the Description prompt. 163 . type a text description of the transfer definition. 3. See “Tips for transfer definition parameters” on page 156 for details about the Relational database (RDB) parameter. At the Short transfer definition name prompt. 6. Additional parameters for the protocol you selected appear on the display. accept the default value *GEN to generate a short transfer definition name. specify a valid value. 164 . press F10 (Additional parameters). specify a valid value. specify the value you want.Changing a transfer definition Changing a transfer definition To change a transfer definition. change. Press F10 165 . 6. Press Enter to display the parameters for the specified transfer protocol. only one autostart job entry will be created regardless of how many transfer definitions use that port number or alias. specify the desired values for each of the four elements and press Enter. From the MIMIX Configuration menu. 8. If you need to set a maximum size for files and objects to be transferred. 2. press F10 (Additional parameters). If you need to change your relational database information. Type 2 (Change) next to the definition you want and press Enter. press Enter. When *YES is specified. 3. At the Relational database (RDB) prompt. At the Manage autostart job entries prompt. 5. The Change Transfer Definition (CHGTFRDFN) display appears. An autostart job entry is created on each system related to the transfer definition. Locate the prompt for the parameter you need to change and specify the value you want. do the following: 1. If you want to change which protocol is used between the specified systems. At the Threshold size (MB) prompt. For special considerations when changing your transfer definitions that are configured to use RDB directory entries see “Tips for transfer definition parameters” on page 156. select option 2 (Work with transfer definitions) and press Enter. modify the transfer definition you plan to use as follows: 1. The Work with Transfer Definitions display appears. Press F1 (Help) for more information about the values for each parameter. or remove the autostart entry based on changes to the transfer definition. If you need to create or remove an autostart job entry for the TCP server. 7. 4. Type a 2 (Change) next to the definition you want and press Enter. MIMIX will add. The Work with Transfer Definitions display appears. before you complete this procedure refer to “Using contextual (*ANY) transfer definitions” on page 160. Contextual transfer definitions are not recommended in a remote journaling environment. Changing a transfer definition to support remote journaling If the value *ANY is specified for either system in the transfer definition. The Change Transfer Definition (CHGTFRDFN) display appears. For a given port number or alias. specify the value you want for the Transfer protocol prompt. press F10 (Additional parameters). 2. To support remote journaling. select option 2 (Work with transfer definitions) and press Enter. Access the Work with Transfer Definitions display by doing one of the following: • From the MIMIX Configuration Menu. To save changes to the transfer definition. 3. Note: See “Tips for transfer definition parameters” on page 156 for detailed information about the Relational database (RDB) parameter. At the Relational database (RDB) prompt. Also see “Finding the system database name for RDB directory entries” on page 167 for special considerations when changing your transfer definitions that are configured to use RDB directory entries. then press Page Down.(Additional parameters). specify the desired values for each of the four elements and press Enter. 166 . 4. If you did not accept default values of *GEN for the Directory entry element and *DFT for the Manage directory entries element of the RDB parameter when you created your transfer definition. 167 . do the following: 1. 2. Login to the system that was specified for System 1 in the transfer definition.Finding the system database name for RDB directory entries Finding the system database name for RDB directory entries To find the system database name. Using IBM i commands to work with RDB directory entries The Manage directory entries element of the Relational Database (RDB) parameter in the transfer definition determines whether MIMIX manages RDB directory entries. 3. or if you specified *NO for the Manage directory entries element. From the command line type DSPRDBDIRE and press Enter. Repeat steps 1 and 2 to find the system database name for System 2. you can use IBM i commands to add and change RDB directory entries. 2=Change. You can also use these options from the Work with Relational Database Directory entries display (WRKRDBDIRE command): 1=Add. Look for the relational database directory entry that has a corresponding remote location name of *LOCAL. and 5=Display details. The Change RDB Directory Entry (CHGRDBDIRE) command will change an existing RDB directory entry. The Add RDB Directory Entry (ADDRDBDIRE) command will add an entry. Press Enter. You can also start the TCP/IP server automatically through an autostart job entry. You can use the Work with Active Jobs (WRKACTJOB) command to look for a job under the MIMIXSBS subsystem with a function of PGM-LVSERVER. From a 5250 emulator. Verify that the server job is running under the MIMIX subsystem on that system. Either you can change the transfer definition to allow MIMIX to create and manage the autostart job entry for the TCP/IP server. The Start Lakeview TCP Server display appears. MIMIX only manages entries for the server when they are created by transfer definitions. or you can add your own autostart job entry. 4. Once the TCP communication connections have been defined in a transfer definition. the TCP server must be started on each of the systems identified by the transfer definition. 3. do the following on the system on which you want to start the TCP server: 1.Starting the TCP/IP server Use this procedure if you need to manually start the TCP/IP server. specify the host name or address for the local system as defined in the transfer definition. The Utilities Menu appears. 5. 168 . From the MIMIX Intermediate Main Menu. select option 13 (Utilities menu) and press Enter. At the Host name or address prompt. 6. specify the port number or alias as defined in the transfer definition for the local system. Note: Use the host name and port number (or port alias) defined in the transfer definition for the system on which you are running this command. At the Port number or alias prompt. you must have an entry in the service table on this system that equates the alias to the port number. 2. Note: If you specify an alias. Select option 51 (Start TCP server) and press Enter. Type 3 (Autostart job entries) and press enter. Changing an autostart job entry and its related job description When the host or port information for a system identified in a transfer definition changes. MIMIX supports automatically creating and managing autostart job entries for the TCP server with the MIMIXSBS subsystem. If you prefer. Identifying the current autostart job entry information This procedure enables you to identify the autostart job entry for the STRSVR command in the MIMIXSBS subsystem and display the current information within the job description associated with the entry. do the following: a. Locate the name and library of the job description for the autostart job entry for the STRSVR. this job description name is either the port alias name or PORTnnnnn where nnnnn is the port number and the library name is the name of the MIMIX installation library. The transfer definition must specify MNGAJE(*NO) and you must have an autostart job entry on each system that can use the transfer definition. The Display Autostart Job Entries display appears. The Display with Job Descriptions display appears. type the command DSPJOBD library/job_description and press Enter.Using autostart job entries to start the TCP server Using autostart job entries to start the TCP server To use TCP/IP communications. MIMIX automatically updates this information for MIMIX-managed autostart job entries when the transfer definition is updated. To display the STRSVR details specified in the job description. 4. b. Type the command DSPSBSD MIMIXQGPL/MIMIXSBS and press Enter. Press Enter. 169 . Using the job description information identified in Step 3. Because this can become a time consuming task that can be mistakenly forgotten. the MIMIX TCP/IP server must be started each time the MIMIX subsystem (MIMIXSBS) is started. The Display Subsystem Description display appears. do the following: 1. Job Description. To display the autostart job entry information. The information in this field shows the current values of the STRSVR command used by the autostart job entry. Page down to view the Request data field. you can create and manage autostart job entries yourself. and Library identify autostart job names and their job description information. The autostart job entry uses a job description that contains the STRSVR command which will automatically start the Lakeview TCP server when the MIMIXSBS subsystem is started. The STRSVR command is defined in the Request data or command (RQSDTA) parameter of the job description. 3. those changes must be also be reflected in autostart job entries for the STRSVR command and in their associated job descriptions. 2. The columns Job. MIMIX does this when transfer definitions for TCP protocol specify *YES for the Manage autostart job entries (MNGAJE) parameter. Typically. Change the JOBD parameter shown to specify the library and job description you want. Press F10 (Additional parameters). Identify the job description and library for the autostart job entry using the procedure in “Identifying the current autostart job entry information” on page 169. a. For the Job description and Library prompts. the following changes to a transfer definition require changing a user-managed autostart job entry or its associated job description on the local system: • • • A change to the port number or alias identified in the PORT1 or PORT2 parameters requires replacing the job description and autostart job entry. Important! Change only the JOBD information for the STRSVR command specified within the RQSDTA parameter. you can do the following: 1. Updating host information for a user-managed autostart job entry Use this procedure to update a user-managed autostart job entry which starts the STRSVR command with the MIMIXSBS subsystem so that the request is submitted with the correct host information. Press Enter. you must update them when the host or port information for a system in the MIMIX environment changes. Do not change the HOST or PORT values when the autostart job entry that is managed by MIMIX. if the transfer definition specifies MNGAJE(*NO) and you are managing the autostart job entries for the STRSVR command and their associated job descriptions yourself. A change to the host name or address identified in the HOST1 or HOST2 parameters requires changing the job description. the job description must be changed. If you want the STRSVR request to run using a different job description. Type CHGJOBD and press F4 (Prompt). If the transfer definition was renamed or copied so that the value of HOST1(*SYS1) or HOST2(*SYS2) no longer resolves to the same system definition system. 2. Important! Do not use this procedure for MIMIX-managed autostart job entries. the default job description used to submit the job is named MIMIXCMN in library MIMIXQGPL. Do the following: a. The Change Job Description display appears. Using a different job description for an autostart job entry When MIMIX manages autostart job entries for the STRSVR command. Autostart job entries for the server are usermanaged when the transfer definition specifies MNGAJE(*NO). c. Specifically. specify the job description and library names from in Step 1. then Page Down. The the Request data or command prompt shows the current values of the STRSVR command. 170 . b.However. This information is needed in the following step. which is the system for which information changed within the transfer definition. Important! Do not use this procedure for MIMIX-managed autostart job entries. This information is needed in the following steps. Autostart job entries for the server are user-managed when the transfer definition specifies MNGAJE(*NO). The Change Job Description display appears. specify the job description and library names from in Step 1. Updating port information for a user-managed autostart job entry This procedure identifies how to update the port information for a user-managed autostart job entry that starts the Lakeview TCP server with the MIMIXSBS subsystem. 2. The Request data or command prompt shows the current values of the STRSVR command in the following format. For the Job description and Library prompts. Type CHGJOBD and press F4 (Prompt). Remove the old job description by specify the job description name and library from Step 1 in the following command: DLTJOBD JOBD(library/job_description) 4. Do the following: 1. a. Press F10 (Additional parameters). 'installation_library/STRSVR HOST(''local_host_name'') PORT(nnnnn) JOBD(MIMIXQGPL/MIMIXCMN)' c. 2. then Page Down to locate Request data or command (RQSDTA). job description. and library for the autostart job entry using the procedure in “Identifying the current autostart job entry information” on page 169. Do the following: 1. Identify the job name. b.Using autostart job entries to start the TCP server Perform this procedure from the local system. Identify the job description and library for the autostart job entry using the procedure in “Identifying the current autostart job entry information” on page 169. Change the value specified for HOST so that the local_host-name is the host name or address specified for the local system in the transfer definition. Create a new job description for the autostart job entry using the following command: CRTDUPOBJ OBJ(MIMIXCMN) FROMLIB(MIMIXQGPL) OBJTYPE(*JOBD) TOLIB(installation-library) NEWOBJ(job_description_name) where installation_library is the name of the library for the MIMIX installation and where job_description_name follows the recommendation to 171 . Do the following: a. which is the system for which information changed within the transfer definition. Remove the old autostart job entry by specifying the job name from Step 1 for job_name in the following command: RMVAJE SBSD(MIMIXQGPL/MIMIXSBS) JOB(job_name) 3. Perform this procedure from the local system. Press Enter. specified as either the port number or the port alias. d. c. specify the STRSVR command in the following format: 'installation_library/STRSVR HOST(''local_host_name'') PORT(nnnnn) JOBD(MIMIXQGPL/MIMIXCMN)' Where the values to specify are: • installation_library is the name of the library for the MIMIX installation • local_host_name is the host name or address from the transfer definition for the local system • nnnnn is the new port information from the transfer definition for the local system. e. The job description is changed. 172 . The Change Job Description display appears. Press Enter. Create a new autostart job entry using the following command: ADDAJE SBSD(MIMIXQGPL/MIMIXSBS) JOB(autostart_job_name) JOBD(installation_library/job_description_name) Where installation_library/job_description_name specifies the job description from Step 4 and autostart_job_name specifies the same port information and format as specified for the job description name. At the Request data or command prompt. Press F10 (Additional parameters). Page Down to locate Request data or command (RQSDTA). specify the job description and library you created in Step 4. b. 6. 5. For the Job description and Library prompts. Type CHGJOBD and press F4 (Prompt).identify the port for the local system by specifying the port number in the format PORTnnnnn or the port alias. Do the following: a. 173 . 2. 4. From the Work with System Definitions display. You should see a message indicating the link has been verified. From the MIMIX Configuration Menu. do not check the link from the local system. then MIMIX uses the Verify Communications Link command to validate the information that has been specified for the Relational database (RDB) parameter. MIMIX also uses VFYCMNLNK to verify that the System 1 and System 2 relational database names exist and are available on each system. type an 11 (Configuration menu) and press Enter. type an 11 (Verify communications link) next to the system definition you want and press Enter. From the MIMIX Basic Main Menu.Verifying a communications link for system definitions Verifying a communications link for system definitions Do the following to verify that the communications link defined for each system definition is operational: 1. 3. Note: If your transfer definition uses the *TCP communications protocol. type a 1 (Work with system definitions) and press Enter. this process will only verify that communications to the remote system is successful. Note: If the system manager is not active." This indicates that the remote system could not return communications to the local system. If the communications link defined for a system definition uses SNA protocol. Repeat this procedure for all system definitions. You will also see a message in the job log indicating that "communications link failed after 1 request. 3. From the MIMIX Configuration Menu. From the MIMIX Basic Main Menu. press Enter. You should see a message "VFYCMNLNK command completed successfully. ensure that the communications link for the data group is active. You will see the Verify Communications Link display for each transfer definition you selected. 5. 2. You should see a message "VFYCMNLNK command completed successfully. you will receive an error message if the transfer definition specifies the value *ANY for either system 1 or system 2. type an 11 (Verify communications link) next to the data group you want and press F4. 2. If you are checking a Transfer definition with the value of *ALL. From the Work with Data Group Definitions display. type an 11 (Verify communications link) next to all transfer definitions and press Enter. 6. be sure to check communications for each data group definition. When the command is called from option 11 on the Work with Transfer Definitions display or when entered from a command line. Do the following: 1. 1. type a 4 (Work with data group definitions) and press Enter. The Verify Communications Link display appears. use the following procedure to check all communications links. type an 11 (Configuration menu) and press Enter. For transfer definitions using TCP protocol: MIMIX uses the Verify Communications Link (VFYCMNLNK) command to validate the values specified for the Relational database (RDB) parameter." 174 . 4. The Verify Communications Link display appears. When the command is called from option 11 on the Work with System Definitions display or option 11 on the Work with Data Groups display. MIMIX identifies the specific system names. 3. MIMIX also uses VFYCMNLNK to verify that the System 1 and System 2 relational database names exist and are available on each system. If your configuration requires multiple data groups. From the Work with Transfer Definitions display. This procedure verifies the primary transfer definition used by the data group. Ensure that the values shown for the prompts are what you want. Verifying all communications links The Verify Communications Link (VFYCMNLNK) command requires specific system names to verify communications between systems.Verifying the communications link for a data group Before you synchronize data between systems. you need to specify a value for the System 1 or System 2 prompt. Ensure that the values shown for the prompts are what you want and then press Enter." If your data group definition specifies a secondary transfer definition. To start the check. Verifying the communications link for a data group 175 . the RJ link is automatically created for you when you follow the steps of the configuration checklists. “Adding a remote journal link” on page 202 describes how to create a MIMIX RJ link. The procedure is appropriate for changing a journal receiver library for the target journal in a remote journaling environment or for any other changes that affect the target journal. and if necessary. “Creating a journal definition” on page 192 provides the steps to follow for creating a journal definition. MIMIX uses the journal definition to manage the journaling environment. Configuration checklists indicate when to build the journal environment. “Journal definition considerations” on page 184 provides things to consider when creating journal definitions for remote journaling. “Building the journaling environment” on page 195 describes the journaling environment and provides the steps to follow for building it. This can be done after the journal definition is created. In most configurations. A journal definition does not automatically build the underlying journal environment that it defines. it must be built. which will in turn create a target journal definition with appropriate values to support remote journaling. “Changing a journal definition” on page 194 provides the steps to follow for changing a journal definition. to change the receiver size options. “Changing the remote journal environment” on page 200 provides steps to follow when changing an existing remote journal configuration. “Changing the journaling environment to use *MAXOPT3” on page 196 describes considerations and provides procedures for changing the journaling environment to use the *MAXOPT3 receiver size option. “Journal receiver size for replicating large object data” on page 191 provides procedures to verify that a journal receiver is large enough to accommodate large IFS stream files and files containing LOB data. “Changing a remote journal link” on page 204 describes how to change an existing RJ link. including journal receiver management. “Temporarily changing from RJ to MIMIX processing” on page 205 describes how • • • • • • • • • • • 176 . If the journal environment does not exist.Configuring journal definitions CHAPTER 9 Configuring journal definitions By creating a journal definition you identify to MIMIX a journal environment that can be used in the replication process. “Tips for journal definition parameters” on page 179 provides tips for using the more common options for journal definitions. The topics in this chapter include: • “Journal definitions created by other processes” on page 178 describes the security audit journal (QAUDJRN) and other journal definitions that are automatically created by MIMIX. • “Changing from remote journaling to MIMIX processing” on page 206 describes how to change a data group that uses remote journaling so that it uses MIMIX send processing. Remote journaling is preferred. • 177 .to change a data group configured for remote journaling to temporarily use MIMIX send processing. “Removing a remote journaling environment” on page 207 describes how to remove a remote journaling environment that you no longer need. it will be created when the first data group that replicates from the system journal is started. When you create a data group definition. 178 . Any journal definitions that are created in this manner will be named with the value specified in the data group definition. In an environment that uses MIMIX Remote Journal support.Journal definitions created by other processes When you create system definitions. If you do not already have a journaling environment for the security audit journal. the process of creating a data group definition creates a remote journal link which in turn creates the journal definition for the target journal. MIMIX automatically creates a journal definition for the security audit journal (QAUDJRN) on that system. Any journal definitions created by another process can be changed if necessary. The QAUDJRN is used only by MIMIX system journal replication processes. The target journal definition is created using values appropriate for remote journaling. MIMIX automatically creates a journal definition if one does not already exist. 179 . otherwise. the first part of the name is QAUDJRN. or @. For the journal name. When a journal definition for the security audit journal (system journal) is automatically created as a result of creating a system definition. @.Tips for journal definition parameters Tips for journal definition parameters This topic provides tips for using the more common options for journal definitions. For the journal library. The value *CRTDFT indicates that the command default value for the IBM i Create Library (CRTLIB) command is used to determine the auxiliary storage pool (ASP) from which the system allocates storage for the library. The remaining characters can be alphanumeric and can contain a $. the default library name is #MXJRN. its name is the first eight characters from the name of the source journal definition followed by the characters @R. it can become part of the receiver number and no longer match the journal name. Journal (JRN) This parameter specifies the qualified name of a journal to which changes to files or objects to be replicated are journaled. If a journal definition name is already in use. Journal definition (JRNDFN) This parameter is a two-part name that identifies a journaling environment on a system. #. @U. MIMIX uses the first six characters of the journal definition name to generate the journal receiver prefix. or an underscore (_). $. the first character must be either A . There are additional specific naming conventions for journal definitions that are used with remote journaling. Context-sensitive help is available online for all options on the journal definition commands. or @W. The first part of the name identifies the journal definition. MIMIX uses #MXJRNIASP for the default journal library name. all objects in the library must be in the same ASP as the library. #. @V. The second part of the name identifies a system definition which represents the system on which you want the journal to reside. @T. Journal library ASP (JRNLIBASP) This parameter specifies the auxiliary storage pool (ASP) from which the system allocates storage for the journal library. the name may include @S. the default value *DFT allows MIMIX to determine the library name based on the ASP in which the journal library is allocated. the default value *JRNDFN uses the name of the journal definition for the name of the journal. If that parameter specifies *ASPDEV. Note: In the first part of the name. If the last character of a prefix resulting from the journal definition name is numeric. as specified in the Journal library ASP parameter. a period (. For libraries that are created in a user ASP. MIMIX restricts the last character of the prefix from being numeric. You can use the default value *CRTDFT or you can specify the number of an ASP in the range 1 through 32.). Journal definition names cannot be UPSMON or begin with the characters MM. If the target journal definition is configured by MIMIX for use with MIMIX RJ support.Z. Target journal state (TGTSTATE) This parameter specifies the requested status of the target journal. See “Journal definition considerations” on page 184. If that parameter specifies *ASPDEV. For more information. and can be used with active journaling support or journal standby state. TIME. The prefix must be unique to the journal definition and cannot end in a numeric character. Use the value *STANDBY to journal objects on the target system while preventing most journal entries from being deposited into the target journal. Journal receiver library ASP (RCVLIBASP) This parameter specifies the auxiliary storage pool (ASP) from which the system allocates storage for the journal receiver library. The value *DFT for the journal receiver library allows MIMIX to determine the library name based on the ASP in which the journal receiver is allocated. THRESHOLD. You can use the default value *CRTDFT or you can specify the number of an ASP in the range 1 through 32. Otherwise. If the journal definition will be used in a configuration which broadcasts data to multiple systems. MIMIX uses #MXJRNIASP for the default journal receiver library name. see “Configuring for high availability journal performance enhancements” on page 309.Journal receiver prefix (JRNRCVPFX) This parameter specifies the prefix to be used in the name of journal receivers associated with the journal used in the replication process and the library in which the journal receivers are located. Note: Journal standby state and journal caching require that the IBM feature for High Availability Journal Performance be installed. The Receiver change management (CHGMGT) parameter controls whether MIMIX performs change management operations for the journal receivers used in the 180 . which usually is the first six characters of the journal definition name with any trailing numeric characters removed. RESETTHLD2 or RESETTHLD) Several parameters control how journal receivers associated with the replication process are changed. The value *CRTDFT indicates that the command default value for the IBM i Create Library (CRTLIB) command is used to determine the auxiliary storage pool (ASP) from which the system allocates storage for the library. there are additional considerations. You can also specify values *SRC. Receiver change management (CHGMGT. For libraries that are created in a user ASP. a unique six character prefix name is derived from the definition name. *TGT. all objects in the library must be in the same ASP as the library. You can specify a different name or specify the value *JRNLIB to use the same library that is used for the associated journal. The default value *GEN for the name prefix indicates that MIMIX will generate a unique prefix. or *NONE. Use the recommended default value *BOTH to perform journal caching on both the source and the target systems. If that prefix is already used in another journal definition. Journal caching (JRNCACHE) This parameter specifies whether the system should cache journal entries in main storage before writing them to disk. as specified in the Journal receiver library ASP parameter. Use the default value *ACTIVE to set the target journal state to active when the data group associated with the journal definition is journaling on the target system (JRNTGT(*YES)). the default library name is #MXJRN. This value is used when MIMIX or the system changes the receivers. The default value is 6600 MB. see “Journal receiver management” on page 37 Receiver delete management (DLTMGT. Reset large sequence threshold (RESETTHLD2) You can specify the sequence number (in millions) at which to reset the receiver sequence number. KEEPRCVCNT. • • 181 . RESETTHLD2 is recommended. Note: RESETTHLD2 accepts larger sequence number values than RESETTHLD. By default. For example. KEEPJRNRCV) Four parameters control how MIMIX handles deleting the journal receivers associated with the replication process. if you specify 2 and there are 10 journal receivers including the attached receiver (which is number 10). • Time of day to change receiver (TIME) You can specify the time of day at which MIMIX changes the journal receiver. MIMIX retains two detached receivers (8 and 9) and deletes receivers 1 through 7. You can specify a value for only one of these parameters. the change is effective with the next receiver change. Retaining unsaved receivers allows you to back out (rollback) changes in the event that you need to recover from a disaster. The shipped default value of *TIMESIZE results in MIMIX changing journal receivers by both threshold size and time of day. • Receiver threshold size (MB) (THRESHOLD) You can specify the size. if another process deletes a journal receiver before MIMIX is finished with it. the next receiver change resets the sequence number to 1. If you change the journal receiver threshold size in the journal definition.Tips for journal definition parameters replication process. All of the requirements that you specify in the following parameters must be met before MIMIX deletes a journal receiver: • Keep unsaved journal receivers (KEEPUNSAV) You can specify whether or not to have MIMIX retain any unsaved journal receivers. The default value *YES causes MIMIX to keep unsaved journal receivers until they are saved. For information about how change management occurs in a remote journal environment and about using other change management choices. For example. The time is based on a 24 hour clock and must be specified in HHMMSS format. KEEPUNSAV. Keep journal receiver count (KEEPRCVCNT) You can specify the number of detached journal receivers to retain. MIMIX performs the delete management operations. MIMIX operations can be adversely affected if you allow the system or another process to handle delete management. The following parameters specify conditions that must be met before change management can occur. replication can be adversely affected. If you decide to decrease the size of the Receiver threshold size you will need to manually change your journal receiver to reflect this change. of the journal receiver at which it is changed. When the threshold is reached. in megabytes. The Receiver delete management (DLTMGT) parameter specifies whether or not MIMIX performs delete management for the journal receivers. You can specify a value for this parameter or for the RESETTHLD2 parameter. The exit program will be called when a journal receiver is changed or deleted by the MIMIX journal manager. you might want to use an exit program to save journal receivers as soon as MIMIX finishes with them so that they can be removed from the system immediately.• Keep journal receivers (days) (KEEPJRNRCV) You can specify the number of days to retain detached journal receivers. When the value *MAXOPT3 is used. see “Changing the journaling environment to use *MAXOPT3” on page 196 Minimize entry specific data (MINENTDTA) This parameter specifies which object types allow journal entries to have minimized entry-specific data. Receiver size option (RCVSIZOPT) This parameter specifies what option to use for determining the maximum size of sequence numbers in journal entries written to the attached journal receiver. the deletion may occur within a few hours after the 7 days have passed. Reset sequence threshold (RESETTHLD) You can specify the sequence number (in millions) at which to reset the receiver sequence number. it will be deleted after 7 days have passed from the time of its creation. For example. RESETTHLD2 is recommended. but not both. For information see “Journal receiver management” on page 37 Journal receiver ASP (JRNRCVASP) This parameter specifies the auxiliary storage pool (ASP) from which the system allocates storage for the journal receivers. Exit program (EXITPGM) This parameter allows you to specify the qualified name of an exit program to use when journal receiver management is performed by MIMIX. The default value *LIBASP indicates that the storage space for the journal receivers is allocated from the same ASP that is used for the journal receiver library. For additional information about improving journaling performance with this capability. For example. see “Minimized journal entry data” on page 307. When the threshold is reached. In order for a change to take effect the journaling environment must be built. Changing this value requires that you change to a new journal receiver. For example. The exact time of the deletion may vary. For additional information. a change to this parameter requires more than one journal definition to be changed. Threshold message queue (MSGQ) This parameter specifies the qualified name of the threshold message queue to which the system sends journal-related messages such as threshold messages. the next receiver change resets the sequence number to 1. if you specify to keep the journal receiver for 7 days and the journal receiver is eligible for deletion. 182 . The value *JRNLIB for the library name indicates that the message queue uses the library for the associated journal. the journal receivers cannot be saved and restored to systems with operating system releases earlier than V5R3M0. The default value *JRNDFN for the queue name indicates that the message queue uses the same name as the journal definition. To support a switchable data group. Tips for journal definition parameters 183 . Journal entries flow from the local journal to the remote journal. The existing definition is likely to be used for journaling and therefore is not appropriate as the target journal definition for a remote journal link. you need to create journal definitions for two remote journal links (four journal definitions). The direction of a defined pair of journals cannot be switched. using an existing journal definition for the target journal definition is not recommended. If you are configuring MIMIX for a scenario in which you have one or more target systems. MIMIX recognizes the receiver change management parameters (CHGMGT.Journal definition considerations Consider the following as you create journal definitions for remote journaling: • The source journal definition identifies the local journal and the system on which the local journal exists. a new receiver with the same name is automatically attached to the remote journal. and several other values. Each remote journal link defines a local-remote journal pair that functions in only one direction. For more information. After the journal environment is built for a target journal definition. However. use the default value *GEN for the prefix name for the JRNRCVPFX on a target journal definition. attempts to start the remote journals will fail with message CPF699A (Unexpected journal receiver found). THRESHOLD. RESETTHLD2 or RESETTHLD) specified in the source journal definition and ignores those specified in the target journal definition. MIMIX ensures that the same prefix is not used more than once on the same system but cannot determine if the prefix is used on a target journal while it is being configured. Therefore. TIME. the target journal definition identifies the remote journal and the system on which the remote journal exists. the source journal definition identifies the source system of the remote journal process and the target journal definition identifies the target system of the remote journal process. Each source journal definition must specify a unique value for the Journal receiver prefix (JRNRCVPFX) parameter. see “Example journal definitions for a switchable data group” on page 185. The receiver name for source and target journals will be the same on the • • • • • 184 . there are additional considerations for the names of journal receivers. Similarly. You can use an existing journal definition as the source journal definition to identify the local journal. When you create a target journal definition instead of having it generated using the Add Remote Journal Link (ADDRJLNK) command. MIMIX cannot change the value of the target journal definition’s Journal receiver prefix (JRNRCVPFX) or Threshold message queue (MSGQ). When a new receiver is attached to the local journal. If the prefix defined by the source journal definition is reused by target journals that reside in the same library and ASP. The receiver prefix specified in the target journal definition is ignored. If you want to use the RJ process in both directions for a switchable data group. To change these values see the procedure in the IBM topic “Library Redirection with Remote Journals” in the IBM eServer iSeries Information Center. In this example. • The System is the value entered in the target journal definition system field. Example journal definitions for a switchable data group To support a switchable data group in a remote journaling environment. a switchable data group named PAYABLES is created between systems CHICAGO and NEWYORK. The Journal library ASP will be copied from source journal definition. The Journal library will use the first eight characters of the name of the source journal library followed by the characters @R. MIMIX implements the following naming conventions for the target journal definition and for the objects in its associated journaling environment. If a journal definition name is already in use. @U. System 1 (CHICAGO) is the data source. Naming convention for remote journaling environments with 2 systems If you allow MIMIX to generate the target journal definition when you create a remote journal link. and two for the RJ link used for replication in the opposite direction. or @W. @V. The Message queue library will use the first eight characters of the name of the source message queue library followed by the characters @R. the target journal definition will be named MYJRN@R CHICAGO. The two-part name of the target journal definition is generated as follows: • The Name is the first eight characters from the name of the source journal definition followed by the characters @R when the journal definition is created for MIMIX RJ support. The Journal receiver prefix will be copied from the source journal definition. follow these same naming conventions to reduce the potential for confusion and errors. the name may instead include @S.Journal definition considerations systems but will not be the same in the journal definitions. If you specify your own target journal definition. the prefix will be the same as that specified in the source journal definition. you need to have four journal definitions configured: two for the RJ link used for normal production-to-backup operations. For example. The Journal receiver library will use the first eight characters of the name of the source journal receiver library followed by the characters @R. In the target journal. Command defaults 185 . The data group definition specifies *YES to Use remote journal link. @T. Note: Journal definition names cannot be UPSMON or begin with the characters MM. if the source journal definition name is MYJRN and you specified TGTJRNDFN(*GEN CHICAGO). The value for the Receiver change management (CHGMGT) parameter will be *NONE. The target journal definition will have the following characteristics and associated new objects: • • • • • • • The Journal name will have the same name as the source journal. This is the source journal definition for normal operations. 1=Create 2=Change 3=Copy 4=Delete 5=Display 6=Print 10=Add RJ link 12=Work with RJ links 14=Build 17=Work with jrn attributes 24=Delete jrn environment ---. Figure 13. To create the RJ link and associated definitions for replication in the opposite direction. Example journal definitions for a switchable data group. Then that definition is used to create second RJ link.Journal ------Name Library PAYABLES MIMIXJRN PAYABLES MIMIXJRN PAYABLES MIMIXJRN@R PAYABLES MIMIXJRN@R . a new source journal definition. press Enter. To create the RJ link and associated journal definitions for normal operations. which in turn generates the target journal definition PAYABLES@R CHICAGO (the third entry listed in Figure 13). is created (the second entry listed in Figure 13). Work with Journal Definitions CHICAGO Type options.create the data group using a generated short data group name and using the data group name for the system 1 and system 2 journal definitions. PAYABLES NEWYORK. The process of adding the link creates the target journal definition PAYABLES@R NEWYORK (the last entry listed in Figure 13). option 10 (Add RJ link) on the Work with Journal Definitions display is used on an existing journal definition named PAYABLES CHICAGO (the first entry listed in Figure 13).Definition ---Name System PAYABLES CHICAGO PAYABLES NEWYORK PAYABLES@R CHICAGO PAYABLES@R NEWYORK -----.Management Change Delete *SYSTEM *YES *SYSTEM *YES *NONE *YES *NONE *YES 7=Rename Opt RJ Link *SRC *SRC *TGT *TGT F3=Exit F12=Cancel F4=Prompt F18=Subset F5=Refresh F21=Print list Bottom F6=Create F22=Work with RJ links 186 . Example of RJ links for a switchable data group. it is possible that each node that is a management system is also both a source and target for replication activity. specify journal library and receiver library names that include a two-character identifier. Work with RJ Links System: Type options. like this: nn@R. the Work with RJ Links display (Figure 14) shows the association between journal definitions much more clearly. the following is strongly recommended: • Limit the data group name to six characters. 1. more than one system serves as the management system for MIMIX operations. nn. Library name-mapping . to represent the node of the associated source (local journal).In target journal definitions. The following manually implemented naming convention ensures that journal receivers have unique names. Also include this identifier at the end of the target journal definition name. 187 . This convention allows for the use of the same local journal name for all data groups and places all journals and receivers from the same source in the same library. In a MIMIX environment that uses multimanagement functions1. A Vision Cluster1 access code is required for multimanagement functions. Figure 14. press Enter. To ensure that journal receivers in a multimanagement environment have unique names. In a multimanagement environment.Journal definition considerations Identifying the correct journal definition on the Work with Journal Definition display can be confusing. Fortunately. 1=Add 2=Change 4=Remove 14=Build 15=Remove RJ connection 24=Delete target jrn environment ---Source Jrn Def--Name System PAYABLES PAYABLES CHICAGO NEWYORK 5=Display 6=Print 9=Start 17=Work with jrn attributes CHICAGO 10=End Opt ---Target Jrn Def--Name System PAYABLES@R PAYABLES@R NEWYORK CHICAGO Priority *SYSDFT *SYSDFT Dlvry *ASYNC *ASYNC State *INACTIVE *INACTIVE Bottom Parameters or command ===> F3=Exit F4=Prompt F12=Cancel F13=Repeat F5=Refresh F6=Add F16=Jrn Definitions F9=Retrieve F18=Subset F11=View 2 F21=Print list Naming convention for multimanagement environments The IBM i remote journal function requires unique names for the local journal receiver and the remote receiver. Place this identifier before the remote journal indicator @R at the end of the name. This will simplify keeping an association between the data group name and the names of associated journal definitions by allowing space for the source node identifier within those names. Each graphic identifies one node as a replication source. when SYS01 is the source. In each graphic. Journal definitions created when a data group is created may not have unique names and will not create all the necessary target journal definitions. Once the appropriately named journal definitions are created for source and target systems. The data group name ABC. manually create the remote journal links between them (ADDRJLNK command). Figure 15 also includes a list of all the journal definitions associated with all nodes from this example as they would appear on the Work with Journal definitions display. all three nodes are designated as management systems. When implementing the naming convention. journal definition ABC SYS01 identifies the local journal on SYS01. The source identifier 01 appears target journal definitions ABC01@R SYS02 and ABC01@R SYS03 and in the library names defined within each. 188 .• Manually create journal definitions (CRTJRNDFN command) using the library name-mapping convention. • Example journal definitions for three management nodes The following figures illustrate the library-mapping naming convention for journal definitions in a multimanagement environment with three nodes. library name-mapping is evident in the names shown for the target journal definitions and their journal and receiver libraries. a three node environment is shown in three separate graphics. This technique is illustrated in the example. Library-mapping example: In Figure 15. with arrows pointing to the possible target nodes and lists the journal definitions needed to replicate from that source. it is helpful to consider one source node at a time and create all the journal definitions necessary for replication from that source. For example. In this example. three node environment.Journal definition considerations Figure 15. All nodes are management systems 189 . Library-mapped journal definitions . Library-mapped names as shown within the RJ links for a three node environment 190 . Figure 16.Figure 16 shows the RJ links needed for this example. From a command line. 3. Enter the command installation-library/WRKJRNDFN 2. do the following from the system where the source journal definition is located: 1.. View the Receiver size options field to see how the journal is configured. 3. 2. For data groups that can be switched. the journal receivers on both the source and target systems must be large enough to accomodate the data. specify a value that indicates support for large journal entries. At the Journal prompt. You may need to change your journal receiver size in order to accommodate the data. type a 17 (Work with journal attributes). The value should indicate support for large journal entries. Changing journal receiver size options To change the journal receiver size. Note: Make sure the other systems in your environment are compatible in size. such as *MAXOPT2 or *MAXOPT3. Verifying journal receiver size options To display the current journal receiver size options for journals used by MIMIX. type CHGJRN (Change Journal) and press F4 to prompt. enter the journal and library names for the journal you wish to change. At the Receiver size option prompt. do the following: 1. Next to the journal definition for the system you are on. it is important that your journal receiver is large enough to accommodate the data. The values *MAXOPT2 and *MAXOPT3 support journal entries up to 4 GB. 191 .Journal receiver size for replicating large object data Journal receiver size for replicating large object data For potentially large IFS stream files and files containing LOB data. as follows: a. 2. The recommended default value is *BOTH. specify whether the system should cache journal entries in main storage before writing them to disk. type an 11 (Configuration menu) and press Enter. Verify that the values shown are what you want and. 7. c. This value can be used with active journaling support or journal standby state. Verify that the following prompts contain the values that you want. is required for journal standby state in Step 6 and journal caching in Step 7. Type 1 (Create) next to the blank line at the top of the list area and press Enter. 6. b. specify a two-part name. 8. From the MIMIX Configuration Menu select option 3 (Work with journal definitions) and press Enter. specify the value you want. Note: Journal definition names cannot be UPSMON or begin with the characters MM. Receiver threshold size (MB) 192 . For more information see “Configuring for high availability journal performance enhancements” on page 309. Set the values you need to manage changing journal receivers. 4. If you have not journaled before.Creating a journal definition Do the following to create a journal definition: 1. 3. The default value is *ACTIVE. if necessary. Journal Library Journal library ASP Journal receiver prefix Library Journal receiver library ASP Important! The IBM feature for High Availability Journal Performance. specify the information you need. At the Target journal state prompt. press F1 (Help). At the Receiver change management prompt. The Create Journal Definition display appears. At the Journal caching prompt. change the values. 5. Press Enter. If you need to identify an existing journaling environment to MIMIX. For more information about valid combinations of values. At the Journal definition prompts. One or more additional prompts related to receiver change management appear on the display. The Work with Journal Definitions display appears. specify the requested status of the target journal. The default values are recommended. the default values are appropriate. From the MIMIX Basic Main Menu. press F10 (Additional parameters). Press Enter. Press Enter. 9. This step is optional. 193 . press Enter. If you want to access additional parameters that are considered advanced functions. One or more additional prompts related to receiver delete management appear on the display. type a brief text description of the journal definition. 12. c. At the Description prompt. as follows: a. Set the values you need to manage deleting journal receivers. To create the journal definition.Creating a journal definition Time of day to change receiver Reset large sequence threshold d. Keep unsaved journal receivers Keep journal receiver count Keep journal receivers (days) 10. If necessary. It is recommended that you accept the default value *YES for the Receiver delete management prompt to allow MIMIX to perform delete management. Make any changes you need to the additional prompts that appear on the display. 11. change the values. b. Before a change to any other parameter is effective. Type 2 (Change) next to the definition you want and press Enter. When the Work with System Definitions display appears. 6. 5. from the MIMIX Configuration Menu select option 3 (Work with journal definitions) and press Enter. • 2. In a standard MIMIX environment. Rebuilding the journal environment ensures that it matches the journal definition and prevents problems starting the data group. type 12 (Journal Definitions) next to the system name you want and press Enter. The Change Journal Definition (CHGJRNDFN) display appears. from the MIMIX Cluster Menu select option 20 (Work with system definitions) and press Enter. Note: Changes to the Receiver threshold size (MB) (THRESHOLD) are effective with the next receiver change. you must rebuild the journal environment. do the following: 1. 4. To accept the changes. Press F1 (Help) for more information about the values for each parameter. Make any changes you need to the prompts. The Work with Journal Definitions display appears. press Enter. When the additional parameters appear on the display.Changing a journal definition To change a journal definition. If you need to access advanced functions. press F10 (Additional parameters). 3. Press Enter twice to see all prompts for the display. 194 . Access the Work with Journal Definitions display according to your configuration needs: • In a clustering environment. make the changes you need. you must change it to an unused value. The Build Journal Environment (BLDJRNENV) command is used to build the journal environment objects for a journal definition. To build the journaling environment. message queue and library. From the MIMIX Configuration Menu. the Source for values (JRNVAL) parameter of the BLDJRNENV command is used to determine the source for the values of these objects. If you do not build either source or target journal environments. A journaling environment includes the following objects: library. it is recommended to build the source journaling environments for both directions of replication so the environments exist for data group replication after switching. select one of the following and press Enter: • • Select 8 (Work with remote journal links) to build the journaling environments for remote journaling. From the MIMIX Main Menu. type 14 (Build) next to the journal definition you want 195 . If the journal receiver prefix in the specified library is already used. The journal receiver prefix and library. For switchable data groups not specified to journal on the target system. they are created based on what is specified in the journal definition. the values specified in the journal definition (*JRNDFN) are only applicable to the source journal. Specifying *JRNDFN for the JRNVAL parameter changes the values of the journal environment objects to match the values of the objects in the journal definition. Select 3 (Work with journal definitions) to build all other journaling environments. 3. journal. From the Work with display. 1. select 11 (Configuration menu) and press Enter. Note: When building a journal environment. If the journal exists. the journal environment for all journal definitions used by that data group must be created on each system. All previous steps in your configuration checklist must be complete before you use this procedure. 2. journal receiver. perform this procedure for both the source and target systems. When the BLDJRNENV command is run. if the objects do not exist. the journal environment must be built on each system that will be a target system for replication of that data group.Building the journaling environment Building the journaling environment Before replication for a data group can occur. In a remote journal environment. ensure the journal receiver prefix in the specified library is not already used. do the following: Note: If you are journaling on the target system. Specifying *JRNENV for the JRNVAL parameter changes the values of the objects in the journal definition to match the values in the existing journal environment objects. the first time the data group starts MIMIX will automatically build the journal environments for you. and threshold parameters are updated from the source specified in the JRNVAL parameter. and threshold message queue on the system specified in the journal definition. If the data group definition specifies to journal on the target system. e. the command is called twice (first for the source journal definition and then for the target journal definition). From the Work with DG Definitions display. Option 14 calls the Build Journal Environment (BLDJRNENV) command.to build and press Enter. When a journal definition for the system journal (QAUDJRN) is changed to use *MAXOPT3 support. The Work with Journal Definitions display is subsetted to the journal definitions for the data group. 4. Before you use this procedure. For environments using remote journaling. d. Type the command CHGJRN and press F4 (Prompt): b. specify the name of the journal from the journal definition. Press Enter. Enter the command WRKDGDFN b. If you plan to journal access paths. c. do the following: a. To do this. Specify *NONE for the RCVSIZOPT parameter. consider the following: • • • • Determine which journal definitions must be changed. A journal definition that is changed to use *MAXOPT3 support affects all data groups which use the journal definition. For the JRN parameter. do the following from each system in the data group: a. c. Doing so prevents sequence numbers from being reset unexpectedly. The default value for the journal sequence reset threshold changes when using • 196 . Type 17 (Work with jrn attributes) next to the definition that is the source for the local system. A status message is issued indicating that the journal environment was created for each system. 5. you need to change the value of the receiver size options. Changing the journaling environment to use *MAXOPT3 This procedure changes journal definitions and builds the journaling environments necessary in order to use a journal with a receiver size option of *MAXOPT3. To verify that the source journals have been created for a data group. Specify *GEN for the JRNRCV parameter. Table 28 identifies requirements according to the data group configuration. The additional MIMIX installations must be running version 6 software and must have their journal definitions for the system journal changed to use *MAXOPT3 support. any additional MIMIX installations on the same system must also use *MAXOPT3 support for the system journal. type 12 (Journal definitions) next the data group and press Enter. Switchable data groups require that journal definitions be changed for both source and target journals. • When the value *MAXOPT3 is used.When ending. Procedures within this topic will direct how to: • Prepare for a controlled end of a data group • Perform the controlled end . 2. Data Group Configuration Replicates From User journal with remote journaling Switchable Yes Journal definition for normal source system (local) Journal definition for normal target system (remote. Updates should be made to any automation that uses journal sequence numbers with MIMIX and any journal receiver management exit programs or monitors with an event class (EVTCLS) of *JRN.This includes how to check for and resolve any open commits. do the following: a. Journal definitions to change when converting to *MAXOPT3. If commitment control is used. End replication in a controlled manner using topic “Ending a data group in a controlled manner” in the Using MIMIX book. @R) Journal definition for source system (local) Journal definition for target system (remote. Journal Definitions to Change Table 28.Changing the journaling environment to use *MAXOPT3 *MAXOPT3. For data groups which use the journal definitions that will be changed. From the management system. Note: Resolve any open commits before continuing. @R) Journal definition for switched source system (local) Journal definition for switched target system (remote. select option 11 (Configuration menu) on the 197 . If your sequence numbers will exceed 10 digits. updates must be made to use the MIMIX command and outfile fields that support sequence numbers with more than 10 digits. @R) Journal definition for source system Journal definition for target system Journal definition for source system QAUDJRN journal definition for source system QAUDJRN journal definition for target system QAUDJRN journal definition for source system No User journal with MIMIX source-send processing System journal (QAUDJRN) Yes No Yes No Do the following: 1. the journal receivers cannot be saved and restored to systems with operating system releases earlier than V5R3M0. • Confirm the end request completed without problems . specify *ALL for the Process prompt and *CNTRLD for the End process prompt. b. ensure that there are no open commit cycles. From the appropriate system (source or target). as indicated in Table 28. d. From the Work with Journal Definitions display. From the Work with Journal Definitions display. do the following to a journal definition: a.MIMIX Main Menu. Do the following: a. 6. Verify that *MAXOPT3 is specified for the Receiver size option. MIMIX will automatically use the default value associated the value you specify for the receiver size option in Step 3d. c. the value should be between 9901 and 18446640000000. Do the following: a. b. Verify that *MAXOPT3 is specified as one of the values for the Receiver size options field. e. 198 . Type option 2 (Change) next to a journal definition and press Enter. Repeat Step 3 for each of the journal definitions you need to change. Then select option 3 (Work with journal definitions) to access the Work with Journal Definitions display. • From the target system. type 17 (Work with jrn attributes) next to a changed target journal definition and press Enter. access the Work with Journal Definitions display. b. Note: For remote journaling environments. After all the necessary journal definitions are changed. If no new value is specified. type a 5 (Display) next to each changed journal definition and press Enter. Optionally. 3. If you did not specify a value. specify *MAXOPT3. type a 14 (Build) next to the journal definitions you changed and press Enter. Verify that the changed journal definitions have appropriate values. From the Work with Journal Definitions display. c. only perform this step for a source journal definition. b. f. 5. Building the environment for the source journal will automatically result in the building of the environment for the associated target journal definition. Then do the following: • From the source system. type 17 (Work with jrn attributes) next to a changed source journal definition and press Enter. continue with the next step. 4. 7. Verify that the journals have been changed and now have appropriate values. Update any automation programs. Press Enter. Press F10 (Additional parameters). specify a value for the Reset large sequence threshold prompt. At the Receiver size option prompt. Any programs that include journal sequence numbers must be changed to use the Reset large sequence threshold (RESETTHLD2) and the Receiver size option (RCVSIZOPT) parameters. Verify that the Reset large sequence threshold prompt contains the value you specified for Step 3b. Refer to topic “Starting selected data group processes” in the Using MIMIX book. 199 . Start the data groups using default values.Changing the journaling environment to use *MAXOPT3 8. Verify that the remote journal link is not in use on both systems. From the Work with RJ Links display. 3. Verify that no other data groups use the RJ link using topic “Identifying data groups that use an RJ link” on page 283. Specify the following on the ENDDG command: • • • *ALL for the Process prompt *CNTRLD for the End process prompt *YES for the End remote journaling prompt. 5. Remove the connection to the remote journal as follows: a. Type a 24 (Delete target jrn environment) next to the link that you want and press Enter. Access the journal definitions for the data group whose environment you want to change. 200 . From the Work with Data Groups display. do the following to delete the target system objects associated with the RJ link: Note: The target journal definition will end with @R. b. You can select either the source or target journal definition. c. press Enter. 4. 2. These steps can be used for synchronous or asynchronous remote journals. From the Work with RJ Links display. For example. To continue removing the connections for the selected links. type a 45 (Journal definitions) next to the data group that you want and press Enter. 1. Note: The target journal definition will end with @R. Use topic “Displaying status of a remote journal link” in the Using MIMIX book. The remote journal link should have a state value of *INACTIVE before you continue. choose the link based on the name in the Target Jrn Def column. Use topic “Ending a data group in a controlled manner” in the Using MIMIX book to prepare for and perform a controlled end of the data group and end the RJ link. A confirmation display appears. a. Type a 12 (Work with RJ links) next to either journal definition you want and press Enter. Failure to follow the proper sequence can introduce errors in replication and journal management. Important! Changing the RJ environment must be done in the correct sequence.Changing the remote journal environment Use the following checklist to guide you through the process of changing an existing remote journal configuration. Perform these tasks from the MIMIX management system unless these instructions indicate otherwise. Type a 15 (Remove RJ connection) next to the link with the target journal definition you want and press Enter d. this procedure is appropriate for changing a journal receiver library for the target journal in a remote journaling (RJ) environment or for any other changes that affect the target journal. Start the data group using default values Refer to topic “Starting selected data group processes” in the Using MIMIX book. 10. 6. and the journal receiver. b. A confirmation display appears. Press F12 to return to the Work with Journal Definitions display. Return to the Work with Data Groups display. To continue deleting the journal. From the Work with Journal Definitions display. b. its associated message queue. From the Work with Data Groups display. 9. Specify the receiver name from Step 8b as the value for the Starting journal receiver (STRRCV) and press Enter. press Enter. Type a 9 (Start) next to the link with the target journal definition and press F4 (Prompt) c. Locate the link you want based on the name in the Target Jrn Def column.Changing the remote journal environment b. Type an 8 (Display status) next to the data group you want and press Enter. type a 44 (RJ links) next to the data group you want and press Enter. The Start Remote Journal Link (STRRJLNK) appears. to change the target (remote) journal definition to a new receiver library. Make the changes you need for the target journal. do the following: a. For example. type a 14 (Build) next to the target journal definition and press Enter. Do the following to start the RJ link: a. Then do the following: a. 7. b. 201 . Locate the name of the receiver in the Last Read field for the Database process. 8. Type option 2 (Change) next to the journal definition for the target system you want and press Enter. Note: The target journal definition will end with @R. enclosed in apostrophes. 7. The journal definition you selected in the previous step appears in the prompts for the Source journal definition. Refer to the related topic on considerations for creating journal definitions for remote journaling for more information. To create the link between journal definitions. Before you create the RJ link you should be familiar with the “Journal definition considerations” on page 184. At the Description prompt. • • • • • Delivery Sending task priority Primary transfer definition Secondary transfer definition If you are using an independent ASP in this configuration you also need to identify the auxiliary storage pools (ASPs) from which the journal and journal receiver used by the remote journal are allocated. 4. If necessary.Adding a remote journal link This procedure requires that a source journal definition exists. do the following: 1. To create a link between journal definitions. the definition must exist and you are responsible for ensuring that its values comply with the recommended values. and Journal receiver lib ASP dev as needed. Type a 10 (Add RJ link) next to the journal definition you want and press Enter. At the Target journal definition prompts. 202 . 6. The process of creating an RJ link will create the target journal definition with appropriate values for remote journaling. 5. Note: If you specify the name of a journal definition. Journal receiver library ASP. press Enter. specify *GEN as the Name and specify the value you want for System. select option 3 (Work with journal definitions) and press Enter. Verify that this is the definition you want as the source for RJ processing. Journal library ASP device. Verify and change the values for Journal library ASP. type a text description of the link. 2. The Work with Journal Definitions display appears. Verify that the values for the following prompts are what you want. From the MIMIX Configuration menu. The Add Remote Journal Link (ADDRJLNK) display appears. 3. change the values. Adding a remote journal link 203 . you need to use topic “Building the journaling environment” on page 195. Start the data group which uses the RJ link. If you removed the RJ connection in Step 1. 204 . press Enter. type a 2 (Change) next to the entry you want and press Enter. The Change Remote Journal Link (CHGRJLNK) display appears. To make the changes effective. do the following: 1. From the Work with RJ Links display. do the following: a. Note: If you plan to change the primary transfer definition or secondary transfer definition to a definition that uses a different RDB directory entry.Changing a remote journal link Changes to the delivery and sending task priority take effect only after the remote journal link has been ended and restarted. The Using MIMIX book describes how to end only the RJ link. Use topic “Removing a remote journaling environment” on page 207 before changing the remote journal link. To change characteristics of the link between source and target journal definitions. 3. When you are ready to accept the changes. 5. Before you change a remote journal link. b. 2. end activity for the link. you also need to remove the existing connection between objects. Specify the values you want for the following prompts: • • • • • Delivery Sending task priority Primary transfer definition Secondary transfer definition Description 4. 205 . Use the procedure “Ending a data group in a controlled manner” in the Using MIMIX book to prepare for and perform a controlled end of the data group and end the RJ link. The Change Data Group Definition (CHGDGDFN) display appears. For the data group you want to change. b. From the Work with DG Definitions display. 2. 4. Modify the data group definition as follows: a. you must complete the procedure in “Checklist: Converting to legacy cooperative processing” on page 138 before you remove remote journaling. On the Work with Data Groups display. the data group should change to show a red “L” in the Source DB column. Specify *NO for the Use remote journal link prompt. Specify the following on the ENDDG command: • • • *ALL for the Process prompt *CNTRLD for the End process prompt *YES for the End remote journaling prompt. temporarily need to revert to MIMIX send processing. specifying *ALL for the Start Process prompt. Important! If the data group is configured for MIMIX Dynamic Apply. c. Use the procedure “Starting selected data group processes” in the Using MIMIX book. Press Enter to see additional prompts. 3. for some reason. Verify that the process is ended. To accept the change press Enter. type a 2 (Change) next to the data group you want and press Enter. do the following: 1. d.Temporarily changing from RJ to MIMIX processing Temporarily changing from RJ to MIMIX processing This procedure is appropriate for when you plan to continue using remote journaling as your primary means of transporting data to the target system but. Step 2 verifies that the RJ link is not in use by any other processes or data groups before ending and removing the RJ environment. From the Work with DG Definitions display.Changing from remote journaling to MIMIX processing Use this procedure when you no longer want to use remote journaling for a data group and want to permanently change the data group to use MIMIX send processing. Press Enter to see additional prompts. 4. specify the following: • • *ALL for the Process prompt *CNTRLD for the End process prompt Note: Do not end the RJ link at this time. Perform these tasks from the MIMIX management system unless these instructions indicate otherwise. you must complete the procedure in “Checklist: Converting to legacy cooperative processing” on page 138 before you remove remote journaling. 2. type a 2 (Change) next to the data group you want and press Enter. To accept the change. Modify the data group definition as follows: a. On the ENDDG command. Important! If the data group is configured for MIMIX Dynamic Apply. Perform a controlled end for the data group that you want to change using topic “Ending a data group in a controlled manner” in the Using MIMIX book. Start data group replication using the procedure “Starting selected data group processes” in the Using MIMIX book and specify *ALL for the Start processes prompt (PRC parameter). 206 . 3. The Change Data Group Definition (CHGDGDFN) display appears. 1. Specify *NO for the Use remote journal link prompt. press Enter. c. b. d. Perform the procedure in topic “Removing a remote journaling environment” on page 207. If the data group needs to remain operable using remote journaling. b. do the following to remove the connection to the remote journal: a. You can select either the source or target journal definition. press Enter. When the data group is ended. A confirmation display appears. From the Work with Data Groups display. type a 15 (Remove RJ connection) next to the link that you want and press Enter. d. Possible courses of action are: • If the data group is being converted to use MIMIX send processing or if the data group will no longer be used. This procedure removes configuration elements and system objects necessary for data group replication with remote journaling. • 207 . ensure that you choose the link you want. This procedure removes configuration elements and system objects necessary for replication with remote journaling 2. Refer to topics “Ending a remote journal link independently” and “Checking status of a remote journal link” in the Using MIMIX book. End the remote journal link and verify that it has a state value of *INACTIVE before you continue. 1. Note: If more than one RJ link is available for the data group.Removing a remote journaling environment Removing a remote journaling environment Use this procedure when you want to remove a remote journaling environment that you no longer need. continue with Step 2 of this procedure. do the following to delete the target system objects associated with the RJ link: a. 3. Type a 24 (Delete target jrn environment) next to the link that you want and press Enter. To continue removing the connections for the selected links. perform a controlled end of the data group. From the management system. type a 45 (Journal definitions) next to the data group that you want and press Enter. do not continue with this procedure. From the Work with RJ Links display. check with your MIMIX administrator and determine how to proceed. Access the journal definitions for the data group whose environment you want to change. From the Work with RJ Links display. Use “Identifying data groups that use an RJ link” on page 283. Type a 12 (Work with RJ links) next to either journal definition you want and press Enter. c. Verify that the remote journal link is not used by any data group. Attention: Do not continue with this procedure if you identified a data group that uses the remote journal link and the data group must continue to be operational. 4. If you identify a data group that uses the remote journal link. its link to the source journal definition is removed. its associated message queue. Delete the target journal definition using topic “Deleting a Definition” in the Using MIMIX book. To continue deleting the journal. 6. the journal receiver.b. Use option 4 (Delete) on the Work with Monitors display to delete the RJLNK monitors which have the same name as the RJ link. press Enter. A confirmation display appears. When you delete the target journal definition. and to remove the connection to the source journal receiver. 208 . 5. CHAPTER 10 Configuring data group definitions By creating a data group definition. Once data group definitions exist for MIMIX. “Changing a data group definition” on page 225 provides the steps to follow for changing a data group definition. you identify to MIMIX the characteristics of how replication occurs between two systems. “Fine-tuning backlog warning thresholds for a data group” on page 225 describes what to consider when adjusting the values at which the backlog warning thresholds are triggered. “Creating a data group definition” on page 221 provides the steps to follow for creating a data group definition. You must have at least one data group definition in order to perform replication. 209 . In an Intra environment. The topics in this chapter include: • • • • “Tips for data group parameters” on page 210 provides tips for using the more common options for data group definitions. a data group definition defines how replication occurs between the two product libraries used by INTRA. they can also be used by the MIMIX Promoter product. Data group names (DGDFN.Z. MIMIX recommends using the value *RCYDMN in System 1 and System 2 fields for Peer CRGs. you need to have second data group with 210 . or @. a period (. you might name your data group SUPERAPP MEXICITY CHICAGO. Allow to be switched (ALWSWT) This parameter determines whether the direction in which data is replicated between systems can be switched. If you do not allow switching directions. @. where the backup system is defined as the management system for MIMIX. Context-sensitive help is available online for all options on the data group definition commands.Tips for data group parameters This topic provides tips for using the more common options for data group definitions. MIMIX will generate this prefix for you when the default *GEN is used. Data group names cannot be UPSMON or begin with the characters MM. For many users normal replication occurs from a production system to a backup system. The short name must be unique to the MIMIX cluster and cannot be changed after the data group is created. Shipped default values for the Create Data Group Definition (CRTDGDFN) command result in data groups configured for MIMIX Dynamic Apply. the first character must be either A . For additional information see Table 12 in “Considerations for LF and PF files” on page 96. The Data group definition (DGDFN) is a three-part name that uniquely identifies a data group. use the default value *YES. The Short data group name (DGSHORTNAM) parameter indicates an abbreviated name used as a prefix to identify jobs associated with a data group. Notes: • In the first part of the name. you may find it helpful if you specify them in the order in which replication occurs during normal operations. #.). If you plan to use the data group for high availability purposes. if you normally replicate data for an application from a production system (MEXICITY) to a backup system (CHICAGO) and the backup system is the management system for the MIMIX cluster. $. For Clustering environments only. Data source (DTASRC) This parameter indicates which of the systems in the data group definition is used as the source of data for replication. The three-part name must be unique to a MIMIX cluster. This allows you to use one data group for replicating data in either direction between the two systems. For example. The remaining characters can be alphanumeric and can contain a $. The first part of the name identifies the data group. The second and third parts of the name (System 1 and System 2) specify system definitions representing the systems between which the files and objects associated with the data group are replicated. DGSHORTNAM) These parameters identify the data group. • One of the system definitions specified must represent a management system. Refer to “Additional considerations for data groups” on page 220 for more information. Although you can specify the system definitions in any order. #. or an underscore (_). MIMIX uses the name PRIMARY for a value of the primary transfer definition (PRITFRDFN) parameter and for the first part of the name of a transfer definition. ASPGRP1. in the event of a switch to the direction of replication. NBRDBAPY. Replication of files with some types of referential constraint actions may require a value of *YES. see “Requirements and limitations of MIMIX Dynamic Apply” on page 101 Note: In Clustering environments only. of the data group. it is used if the communications path specified in the primary transfer definition is not available. ASPGRP2. Data group types of *ALL may also include tracking entries. JRNDFN2. Jobs wait for the time you specify even when new entries arrive in the journal. Journal on target (JRNTGT) The default value *YES enables journaling on the target system. Data group type (TYPE) The default value *ALL indicates that the data group can be used by both user journal and system journal replication processes. respectively. JRNDFN1. and data queues. If you specify a secondary transfer definition (SECTRFDFN). By default. activity against those files may not be properly recorded for replication. Data group types of *ALL or *DB include database files. you manually start journaling on the target system before allowing users to access the files. DBJRNPRC) These parameters apply to data groups that can include database files or tracking entries. If you specify *NO. it continues to use it even after the primary communication path becomes available again. The name you specify in these parameters must match the first part of a transfer definition name. RJLNK. MIMIX Dynamic Apply also supports the value *DB. you must ensure that.Tips for data group parameters similar attributes in which the roles of source and target are reversed in order to support high availability. For more information. The value *ALL is required for user journal replication of IFS objects. data areas. System 1 journal definition (JRNDFN1) and System 2 journal definition (JRNDFN2) parameters identify the user journal definitions associated with the systems defined as System 1 and System 2. The value *DGDFN indicates that the journal definition has the same name as the data 211 . Common database parameters (JRNTGT. Reader wait time (seconds) (RDRWAIT) You can specify the maximum number of seconds that the send process waits when there are no entries available to process. This enables you to use the same data group for all of the replicated data for an application. COOPJRN. Otherwise. Jobs go into a delay state when there are no entries to process. Once MIMIX starts using the secondary transfer definition. This provides you with support for system values and other system attributes that MIMIX currently does not support. SECTFRDFN) These parameters identify the transfer definitions used to communicate between the systems defined by the data group. Transfer definitions (PRITFRDFN. For additional information. the data group value of *PEER is available. see “Considerations for LF and PF files” on page 96. A value of 0 uses more system resources. which allows you to switch the direction of a data group more quickly. If those requirements are not met. For more information see “Benefits of independent ASPs” on page 519. When ADDRJLNK is run during the creation of a data group. *YES. Specify a value when you want to replicate IFS objects from a user journal or when you want to replicate objects from ASPs 33 or higher. Each element of the parameter identifies a criteria that can be set to either *SEND or *IGNORE. JRNDFN1. You may need to build the journaling environment for these journal definitions. Number of DB apply sessions (NBRDBAPY) You can specify the number of apply sessions allowed to process the data for the data group. a journal definition is created. This value results in the automatic creation of the journal definitions (CRTJRNDFN command) and the RJ link (ADDRJLNK command).group definition. DB journal entry processing (DBJRNPRC) This parameter allows you to specify several criteria that MIMIX will use to filter user journal entries before they reach the database apply (DBAPY) process. MIMIX Dynamic Apply requires the value *YES. the shipped default value *DFT resolves to *USRJRN (user journal) when configuration requirements for MIMIX Dynamic Apply are met. When you create the data group definition. The value *NONE allows replication from libraries in the system ASP and basic user ASPs 2-32. and JRNDFN2 parameters interact to automatically create as much of the journaling environment as possible. ALWSWT. If you specify to journal on the target system and the journal definition for the target system does not exist. The value *NO is appropriate when MIMIX source-send processes must be used. The DTASRC. if needed. System 1 ASP group (ASPGRP1) and System 2 ASP group (ASPGRP2) parameters identify the name of the primary auxiliary storage pool (ASP) device within an ASP group on each system. The names of journal definitions created in this way are taken from the values of the JRNDFN1 and JRNDFN2 parameters according to which system is considered the source system at the time they are created. For data groups configured to use MIMIX 212 . *DFT resolves to *SYSJRN and cooperative processing is performed through system journal replication processes. Cooperative journal (COOPJRN) This parameter determines whether cooperatively processed operations for journaled objects are performed primarily by user (database) journal replication processes or system (audit) journal replication processes. For data groups created on version 5. JRNTGT. The default value. Use remote journal link (RJLNK) This parameter identifies how journal entries are moved to the target system. if the journal definition for the source system does not exist. The DTASRC parameter determines whether system 1 or system 2 is the source system for the data group. the data group transfer definition names are used for the ADDRJLNK transfer definition parameters. The RJ link defines the source and target journal definitions and the connection between them. Cooperative processing through the user journal is recommended and is called MIMIX Dynamic Apply. that journal definition is also created. The value *SEND causes the journal entries meeting the criteria to be processed and sent to the database apply process. uses remote journaling to transfer data to the target system. the before-images are often required and you should specify *SEND. When you specify a value for the interval. Synchronization check interval (SYNCCHKITV) This parameter. For MIMIX to use this feature. Remote journaling threshold (RJLNKTHLD) This parameter specifies the backlog threshold criteria for the remote journal function. the journal image file entry option (FEOPT parameter) must allow before-image journaling (*BOTH). in minutes. These parameters are considered advanced configuration topics. *SEND is also required for the IBM RMVJRNCHG (Remove Journal Change) command. a synchronization check entry is sent to the apply process on the target system. For files not in data group This criteria determines whether journal entries for files not defined to the data group are filtered out. Time stamps are used to evaluate performance. If *NONE is specified for a criterion. The threshold can be specified as a time difference. Not used by MIMIX This criteria determines whether journal entries not used by MIMIX are filtered out. between the timestamp of the last source journal entry and the timestamp of the last remote journal entry. such as keyed replication. *SEND can minimize the amount of data that is sent over a communications path. Certain database techniques. When the backlog reaches any of the specified criterion. allows you to specify the number of entries to process before MIMIX creates a time stamp entry. a number of journal entries.Tips for data group parameters source-send processes. If you use keyed replication. the value is the number of journal entries that have not been sent from the local journal to the remote journal. Generated by MIMIX activity This criteria determines whether journal entries resulting from the MIMIX database apply process are filtered out. The value *IGNORE prevents the entries from being sent to the database apply process. may require that an element be set to a specific value. MIMIX puts the data group file entry on hold and stops applying journal entries. If there is a synchronization problem. • • • Additional parameters: Use F10 (Additional parameters) to access the following parameters. The following available elements describe how journal entries are handled by the database reader (DBRDR) or the database send (DBSND) processes. byte for byte). The apply process compares the before-image to the image in the file (the entire record. allows you to specify how many before-image entries to process between synchronization checks. The synchronization check transactions still occur even if you specify to ignore before-images in the DB journal entry processing (DBJRNPRC) parameter. 213 . the value is amount of time. • Before images This criteria determines whether before-image journal entries are filtered out before reaching the database apply process. which is only valid for database processing. When a number of journal entries is specified. When a time difference is specified. which is only valid for database processing. the threshold exceeded condition is indicated in the status of the RJ link. that criterion is not considered when determining whether the backlog has reached the threshold. Time stamp interval (TSPITV) This parameter. See “Additional considerations for data groups” on page 220 for more information. Note: The TSPITV parameter does not apply for remote journaling (RJ) data groups. or both. A lower value results in more accurate status information. high-volume systems should have higher values. A higher value uses less system resources. When the value specified is reached. A lower value provides more timely reaction to error conditions. It is normal for some pending activity entries to undergo delay retry processing—for example. Parameters for automatic retry processing: MIMIX may use delay retry cycles when performing system journal replication to automatically retry processing an object that failed due to a locking condition or an in-use condition. 214 . First retry delay interval (RTYDLYITV1) This parameter specifies the amount of time.Verify interval (VFYITV) This parameter allows you to specify the number of journal transactions (entries) to process before MIMIX performs additional processing. or through the system journal. in seconds. Journal at creation (JRNATCRT) This parameter specifies whether to start journaling on new objects of type *FILE. and *DTAQ when they are created. The preferred methods of replicating data areas require that data group object entries be used to identify data areas. when a conflict occurs between replicated objects in MIMIX and another job on the system. including those not replicated by the data group. Second retry delay interval (RTYDLYITV2) specifies the amount of time. in seconds. For additional information. the value specified in them for cooperative processing (COOPDB) determines whether the data areas are processed through the user journal with advanced journaling. This value also affects how often the status is updated with the "Last read" entries. The following parameters define the scope of two retry cycles: Number of times to retry (RTYNBR) This parameter specifies the number of attempts to make during a delay retry cycle. to wait before retrying a process in the second (long) delay retry cycle. The poller process is only used when configured data group data area entries exist. only allow one data group to use journal at object creation (*YES or *DFT). If multiple data groups include the same library in their configurations. Note: There are some IBM library restrictions identified within the requirements for implicit starting of journaling described in “What objects need to be journaled” on page 294. *DTAARA. The default for this parameter is *DFT which allows MIMIX to determine the objects to journal at creation. The decision to start journaling for a new object is based on whether the data group is configured to cooperatively process any object of that type in a library. Data area polling interval (DTAARAITV) This parameter specifies the number of seconds that the data area poller waits between checks for changes to data areas. This is only used after all the retries for the RTYDLYITV1 parameter have been attempted. Larger. All new objects of the same type are journaled. MIMIX verifies that the communications path between the source system and the target system is still active and that the send and receive processes are successfully processing transactions. to wait before retrying a process in the first (short) delay retry cycle. see “Processing of newly created files and objects” on page 114. When object entries identify data areas. Adaptive caching is a technique by which MIMIX caches data into memory before it is needed by user journal replication processes. If the object identified by the entry is in use (*INUSE) after the first and second retry cycle attempts have been exhausted. See “Additional considerations for data groups” on page 220 for more information. If the object cannot be saved after all attempts in the first cycle. After all attempts have been performed. Omit open/close entries This option allows you to specify whether open and close entries are omitted from the journal. if the object still cannot be processed because of contention with other jobs. MIMIX uses the number of seconds specified in the Second retry delay interval (RTYDLYITV2) parameter and repeats the save attempt for the specified number of times (RTYNBR). The options are as follows: • Journal image This option allows you to control the kinds of record images that are written to the journal when data updates are made to database file records. *BOTH is also required for the IBM RMVJRNCHG (Remove Journal Change) command. The values in effect for the Number of third delay/retries policy and the Third retry interval (min. All database file entries. The default value *AFTER causes only after-images to be written to the journal. data areas or data queues. a third retry cycle is attempted if the Automatic object recovery policy is enabled. If you specify *NO. File and tracking entry options (FEOPT) This parameter specifies default options that determine how MIMIX handles file entries and tracking entries for the data group. Replication type This option allows you to specify the type of replication to use for database files defined to the data group. Using adaptive caching provides greater elapsed time performance by using additional memory. The default value *YES indicates that open and close operations on file members or IFS tracking entries defined to the data group do not create open and close journal entries and are therefore omitted from the journal. In the second retry cycle. and IFS tracking entries defined to the data group use these options unless they are explicitly overridden by values specified in data group file or object entries. such as keyed replication. IFS stream files. Some database techniques. object tracking entries. The default value *POSITION indicates that each file is replicated based on the position of the record within the file. Positional replication uses the values of the relative record number (RRN) found in the journal entry header to locate a database record that is being updated or • • 215 .) policy determine the scope of the third retry cycle.Tips for data group parameters After the initial failed save attempt. MIMIX delays for the number of seconds specified for the First retry delay interval (RTYDLYITV1) before retrying the save operation. File entry options in data group object entries enable you to set values for files and tracking entries that are cooperatively processed. the status of the entry will be changed to *FAILED. This is repeated for the specified number of times (RTYNBR). Adaptive cache (ADPCHE) This parameter enables adaptive caching for a data group. may require the use of both before-image and after-images. MIMIX enters the second retry cycle. The value *BOTH causes both before-images and after-images to be written to the journal. journal entries are created for open and close operations and are placed in the journal. only apply session A is valid. A collision resolution class allows you to specify how to handle a variety of collision types. Apply session With this option. MIMIX Dynamic Apply requires the value *POSITION. The value of the key is used to locate a database record that is being deleted or updated. The value *AUTOSYNC indicates that MIMIX will attempt to automatically synchronize the source and target file. Files defined using keyed replication must have at least one unique access path defined. For additional information see “Database apply session balancing” on page 81. The default value *HLDERR indicates that a file is put on hold if a collision is detected. The value *KEYED indicates that each file is replicated based on the value of the primary key defined to the database file. you can assign a specific apply session for processing files defined to the data group. When the backlog reaches any of the specified criterion. • Lock member during apply This option allows you to choose whether you want the database apply process to lock file members when they are being updated during the apply process. • • • Collision resolution This option determines how data collisions are resolved. If the data group is configured for MIMIX source-send processing instead of remote journaling. Members are locked only when the apply process is active. The default value *YES indicates that journal entries generated by triggers should be processed. Notes: • Any changes made to the apply session option are not effective until the data group is started with *YES specified for the clear pending and clear error parameters. The default value *YES indicates that triggers should be disabled by the database apply process while the file is opened. The default value *ANY indicates that MIMIX determines which apply session to use and performs load balancing. Process trigger entries This option determines if MIMIX should process any journal entries that are generated by triggers. MIMIX strongly recommends that any file configured for keyed replication also be enabled for both beforeimage and after-image journaling. see “Keyed replication” on page 322. • Database reader/send threshold (DBRDRTHLD) This parameter specifies the backlog threshold criteria for the database reader (DBRDR) process. This prevents inadvertent updates on the target system that can cause synchronization errors. See the online help for the Create Collision Resolution Class (CRTCRCLS) command for more information. For IFS and object tracking entries. For additional information.deleted. • Disable triggers during apply This option determines if MIMIX should disable any triggers on physical files during the database apply process. You can also specify the name of the collision resolution class (CRCLS) to use. Note: The *AUTOSYNC value should not be used if the Automatic database recovery policy is enabled. including calling exit programs to handle them. the threshold exceeded condition is indicated in the status of the DBRDR process. this threshold applies to 216 . The threshold can be specified as time. Apply history log spaces You can specify the maximum number of history log spaces that are kept after the journal entries are applied. • • • • • Object processing (OBJPRC) This parameter allows you to specify defaults for object replication. DLO transmission method You can specify the method used to transmit the DLO content and attributes to the target system. Keep journal log user spaces You can specify the maximum number of journal log spaces to retain after the journal entries are applied. If *NONE is specified for a criterion. The areas for which you can specify defaults are as follows: • Force data interval You can specify the number of records that are processed before MIMIX forces the apply process information to disk from cache memory. A lower value reduces disk usage by the apply process. Once the limit specified is reached. the value is the number of journal entries that have not been read from the journal. When the threshold is reached. Only the number of user spaces you specify are kept. When a journal entry quantity is specified. that criterion is not considered when determining whether the backlog has reached the threshold. The *SAVRST uses IBM i save and restore commands. in minutes. A lower value provides easier recovery for major system failures. A higher value provides more efficient processing because MIMIX does not open and close files as often. Database apply processing (DBAPYPRC) This parameter allows you to specify defaults for operations associated with the database apply processes. Larger log spaces provide better performance. The value *OPTIMIZED uses IBM i APIs. Each configured apply session uses the values specified in this parameter. • 217 . Log user spaces are automatically deleted by MIMIX. A higher value provides for more efficient processing. Threshold warning You can specify the number of entries the apply process can have waiting to be applied before a warning message is sent. Size of log user spaces (MB) You can specify the size of each log space (in megabytes) in the log space chain. the threshold exceeded condition is indicated in the status of the database apply process and a message is sent to the primary and secondary message queues. Any value other than zero (0) affects performance of the apply processes. the value is the amount of time. or both. the apply process selectively closes one file before opening a new file. When time is specified. The product default uses QDFTOWN for the owner user profile. Maximum open members You can specify the maximum number of members (with journal transactions to be applied) that the apply process can have open at one time. The areas for which you can specify defaults are as follows: • Object default owner You can specify the name of the default owner for objects whose owning user profile does not exist on the target system.Tips for data group parameters the database send (DBSND) process. Log spaces are used as a staging area for journal entries before they are applied. between the timestamp of the last journal entry read by the process and the timestamp of the last journal entry in the journal. journal entries. The value *SAVRST uses IBM i save and restore commands. MIMIX does not perform any clean-up of these spooled files. • User profile status You can specify the user profile Status value for user profiles when they are replicated. The system object name is only preserved if the DLO is not being redirected during the replication process. Keep DLO system object name You can specify whether the DLO on the target system is created with the same system object name as the DLO on the source system. • • • Object send threshold (OBJSNDTHLD) This parameter specifies the backlog threshold criteria for the object send (OBJSND) process. between the timestamp of the last journal entry read by the process and the timestamp of the last journal entry in the journal. the replicated spooled files are deleted from the target system when they are deleted from the source system. that criterion is not considered when determining whether the backlog has reached the threshold.• IFS transmission method You can specify the method used to transmit IFS object content to the target system. The IBM i save and restore method guarantees that all attributes of an IFS object are replicated. Note: It is recommended that you use the *OPTIMIZED method of IFS transmission only in environments in which the high volume of IFS activity results in persistent replication backlogs. Object retrieval delay You can specify the amount of time. If you specify *NO. the value is the number of journal entries that have not been read from the journal. if 218 . This delay provides time for your applications to complete their access of the object before MIMIX begins packaging the object. in seconds. You must delete them manually when they are no longer needed. When time is specified. journal entries. If the DLO from the source system is being directed to a different name or folder on the target system. then the system object name will not be preserved. The value *OPTIMIZED uses IBM i APIs. During periods of peak activity. or both. The IFS optimization method does not currently replicate digital signatures or other attributes that have been added in recent IBM i releases. user profiles can then be enabled or disabled as needed as part of the switching process. in minutes. The threshold can be specified as time. If operations are switched to the backup system. to wait after an object is created or updated before MIMIX packages the object. When you specify *YES. When the backlog reaches any of the specified criterion. Object retrieve processing (OBJRTVPRC) This parameter allows you to specify the minimum and maximum number of jobs allowed to handle object retrieve requests and the threshold at which the number of pending requests queued for processing causes additional temporary jobs to be started. Keep deleted spooled files You can specify whether to retain replicated spooled files on the target system after they have been deleted from the source system. If *NONE is specified for a criterion. the replicated spooled files are retained on the target system after they are deleted from the source system. the threshold exceeded condition is indicated in the status of the OBJSND process. the value is the amount of time. When a journal entry quantity is specified. This allows you to replicate user profiles with the same status as the source system in either an enabled or disabled status for normal operations. The specified minimum number of jobs will be started when the data group is started. When the backlog is handled and activity returns to normal. Reorganize job description (RGZJOBD) This parameter. the threshold exceeded condition is indicated in the status of the object retrieve (OBJRTV) process. if the number of pending requests exceeds the backlog threshold. If the backlog reaches the warning message threshold. the extra jobs will automatically end. If *NONE is specified for the warning message threshold. the process status will not indicate that a backlog exists. the extra jobs will automatically end. up to the maximum. additional jobs. 219 . if the number of pending requests exceeds the backlog jobs threshold. up to the maximum. The product default uses MIMIXAPY in library MIMIXQGPL for the apply job description. allows you to specify the name and library of the job description used to submit reorganize jobs. You can also specify a threshold for warning message that indicates the number of pending requests waiting in the queue for processing before a warning message is sent.Tips for data group parameters the number of pending requests exceeds the backlog jobs threshold. Apply job description (APYJOBD) This parameter allows you to specify the name and library of the job description used to submit apply requests. If the backlog reaches the warning message threshold. Object apply processing (OBJAPYPRC) This parameter allows you to specify the minimum and maximum number of jobs allowed to handle object apply requests and the threshold at which the number of pending requests queued for processing triggers additional temporary jobs to be started. During periods of peak activity. When the backlog is handled and activity returns to normal. The product default uses MIMIXSND in library MIMIXQGPL for the send job description. The product default uses MIMIXRGZ in library MIMIXQGPL for the reorganize job description. the threshold exceeded condition is indicated in the status of the container send (CNRSND) process. additional jobs. The value *CURRENT indicates that the same user profile used by the job that is currently running is used for the submitted job. When the backlog is handled and activity returns to normal. Send job description (SNDJOBD) This parameter allows you to specify the name and library of the job description used to submit send jobs. the threshold exceeded condition is indicated in the status of the object apply process and a message is sent to the primary and secondary message queues. The specified minimum number of jobs will be started when the data group is started. are started to handle the extra work. used by database processing. Container send processing (CNRSNDPRC) This parameter allows you to specify the minimum and maximum number of jobs allowed to handle container send requests and the threshold at which the number of pending requests queued for processing causes additional temporary jobs to be started. The specified minimum number of jobs will be started when the data group is started. are started to handle the extra work. When the threshold is reached. up to the maximum. If *NONE is specified for the warning message threshold. additional jobs. the process status will not indicate that a backlog exists. The default value *JOBD indicates that the user profile named in the specified job description is used for the job being submitted. During periods of peak activity. the extra jobs will automatically terminate. User profile for submit job (SBMUSR) This parameter allows you to specify the name of the user profile used to submit jobs. are started to handle the extra work. In order to use this command. see “Removing journaled changes” in the Using MIMIX book. Recovery window (RCYWIN) Configuring a recovery window1 for a data group specifies the minimum amount of time. Additional considerations for data groups If unwanted changes are recorded to a journal but not realized until a later time. Job restart time (RSTARTTIME) MIMIX data group jobs restart daily to maintain the MIMIX environment. in minutes. You should also disable auditing for any data group that has a configured recovery window. Consider the effect of the duration you specify on the data group's ability to meet your required RTO. Recovery windows and recovery points are supported with the MIMIX CDP™ feature. A recovery window introduces a delay in the specified processes to create a minimum time during which you can set a recovery point. that a recovery window is available and identifies the replication processes that permit a recovery window. 220 . see “Preventing audits from running” in the Using MIMIX book. For more information. which requires an additional access code. Results may also be affected if you specify a value that uses the job restart time in a system definition defined to the data group. you can backtrack to a time prior to when the changes were made by using the Remove Journal Changes (RMVJRNCHG) command provided by IBM. your configuration must meet certain criteria including specific values for some of the data group definition parameters. Changing the job restart time is considered an advanced technique. By its nature.Synchronize job description (SYNCJOBD) This parameter. You can change the time at which these jobs restart. Once a recovery point is set. 1. used by database processing. The product default uses MIMIXSYNC in library MIMIXQGPL for synchronization job description. they are suspended so that any corruption in the transactions after that point will not automatically be processed. For more information. a recovery window can affect the data group's recovery time objective (RTO). allows you to the name and library of the job description used to submit synchronize jobs. This is valid for any synchronize command that does not have JOBD parameter on the display. The source or target role of the system affects the results of the time you specify on a data group definition. When the processes reach the recovery point. you can react to anticipated problems and take action to prevent a corrupted object from reaching the target system. If you want a specific prefix to be used for jobs associated with the data group. c. select option 4 (Work with data group definitions) and press Enter. 3. Note: Data group names cannot be UPSMON or begin with the characters MM. From the MIMIX Configuration Menu. data areas. skip to Step 9. type a 1 (Create) next to the blank line at the top of the list area and press Enter. 5. For additional information see Table 12 in “Considerations for LF and PF files” on page 96. MIMIX will generate a prefix. Specify a valid three-part name at the Data group definition prompts. For the remaining prompts on the display. a.Creating a data group definition Creating a data group definition Shipped default values for the Create Data Group Definition (CRTDGDFN) command result in data groups configured for MIMIX Dynamic Apply. type 11 (Configuration menu) and press Enter b. MIMIX Dynamic Apply requires either *ALL or *DB. Verify that the value of the Primary transfer definition prompt is what you want. 4. e. change the values. These data groups use remote journaling as an integral part of the user journal replication processes. If you want MIMIX to have access to an alternative communications path. do the following: 1. From the Work with Data Group Definitions display. b. see “Tips for data group parameters” on page 210. Verify that the value shown is what you want and press Enter. h. g. specify a value for the Secondary transfer definition prompt. The Create Data Group Definition (CRTDGDFN) display appears. Press Enter. Verify that the value of the Allow to be switched prompt is what you want. c. Ensure that the value of the Data source prompt represents the system that you want to use as the source of data to be replicated. To access the appropriate command. Legacy cooperative processing and user journal replication of IFS objects. f. do the following: a. d. For information about command parameters. verify the values shown are what you want. 2. specify a value at the Short data group name prompt. The Journal on target prompt appears on the display. If you specified *OBJ for the Data group type. If necessary. From the From the MIMIX Basic Main Menu. Verify that the value of the Data group type prompt is what you need. Otherwise. Verify that the value of the Reader wait time (seconds) prompt is what you want. and data queues require *ALL. 221 . To create a data group. you should perform a save and restore operation on the target system prior to loading the data group file entries. you have specified *NO for both the Allow to be switched prompt and the Journal on target prompt. specify the number of apply sessions you want to use. enclosed in apostrophes. b. Note: *SEND is required for the IBM RMVJRNCHG (Remove Journal Change) command. You may need to use the Page Down key to see the prompts. 8. c. MIMIX creates a transfer definition and an RJ link. For new data groups. You will synchronize as part of the configuration checklist. The value *USRJRN processes through the user (database) journal while the value *SYSJRN processes through the system (audit) journal. change the value to *NO. If you have an existing journaling environment that you have identified to MIMIX in a journal definition. 6. See “Additional considerations for data groups” on page 220 for more information. To create a data group definition for a source-send configuration. More prompts appear on the display that identify journaling information for the data group. Verify that the values shown for the DB journal entry processing prompts are what you want. 9. At the Cooperative journal (COOPJRN) prompt. which required for MIMIX Dynamic Apply and preferred for other configurations. it is not necessary to perform a save and restore operation. specify values for System1 ASP group and System 2 ASP group as needed. d. 10. The journal definition prompt that appears is for the source system as specified in the Data source prompt. specify the journal for cooperative operations. If any objects to replicate are located in an auxiliary storage pool (ASP) group on either system. the value *DFT automatically resolves to *USRJRN when Data group type is *ALL or *DB and Remote journal link is *YES. type a text description of the data group definition. 7.Note: If you specify *YES and you require that the status of journaling on the target system is accurate. the value *DGDFN is appropriate. Do one of the following: 222 . Ensure that the values of System 1 journal definition and System 2 journal definition identify the journal definitions you need. • If you only see one of the journal definition prompts. Notes: • If you have not journaled before. The default for the Use remote journal link prompt is *YES. specify the name of the journal definition. If you are performing your initial configuration. At the Number of DB apply sessions prompt. if needed. however. The ASP group name is the name of the primary ASP device within the ASP group. At the Description prompt. Do the following: a. and data queues that are configured for user journal replication. opts (FEOPT) parameter. To access prompts for advanced configuration. The journal image value *BOTH is required for the IBM RMVJRNCHG (Remove Journal Change) command. Specify the values you need for each of the prompts on the File and tracking ent. Press Enter. Specify the values you need for the following prompts associated with user journal replication: • • • • • • Remote journaling threshold Synchronization check interval Time stamp interval Verify interval Data area polling interval Journal at creation 12. Because IBM i does not allow additional parameters to be prompt-controlled. Most users can accept the default values for the remaining parameters. press F10 (Additional Parameters) and continue with the next step. For more information see “Database apply session balancing” on page 81. you will see all parameters regardless of the value specified for the Data group type prompt. Accept the value *YES for the Adaptive cache prompt unless the system is memory constrained. • 15. • Advanced Data Group Options: The remaining steps of this procedure are only necessary if you need to access options for advanced configuration topics. data areas. 14. Specify the values you need for each element of the following parameters: • • • Database reader/send threshold Database apply processing Object processing 223 . Apply session A is used for IFS objects.Creating a data group definition • To accept the basic data group configuration. Specify the values you need for the following prompts associated with system journal replication: • • • Number of times to retry First retry delay interval Second retry delay interval 13. See “Additional considerations for data groups” on page 220 for more information. The data group is created when you press Enter. 11. The prompts are listed in the order they appear on the display. Notes: • • Replication type must be *POSITION for MIMIX Dynamic Apply. 224 . change the values for the following prompts: • • • • • • User profile for submit job Send job description and its Library Apply job description and its Library Reorganize job description and its Library Synchronize job description and its Library Job restart time 17. If necessary. When you are sure that you have defined all of the values that you need. press Enter to create the data group definition.• • • • Object send threshold Object retrieve processing Container send processing Object apply processing 16. When a job has a backlog that reaches or exceeds the specified threshold. Fine-tuning backlog warning thresholds for a data group MIMIX supports the ability to set a backlog threshold on each of the replication jobs used by a data group. When you are ready to accept the changes. a threshold condition which occurs after starting a process that was temporarily ended or while processing an unusually large object which rarely changes may be an acceptable risk. Press Enter to see additional prompts. For example. 2. From the Work with DG Definitions display. Each threshold represents only one process in either the user journal replication path or the system journal replication path. The Change Data Group Definition (CHGDGDFN) display appears. the threshold condition is indicated in the job status and reflected in user interfaces. type a 2 (Change) next to the data group you want and press Enter. What is an acceptable risk for some data groups may not be acceptable for other data groups or in some environments. a process that is continuously in a threshold condition or having multiple processes frequently in threshold conditions may indicate a more serious exposure that requires attention. Page Down to see more of the prompts. press Enter. a condition exists that could become a problem.Changing a data group definition Changing a data group definition For information about command parameters. press F10 (Additional parameters). do the following: 1. each threshold setting must be a balance between allowing normal fluctuations to occur while ensuring that a job status is highlighted when a backlog approaches an unacceptable level of risk to your recovery time objectives (RTO) or risk of data loss. while normal replication processes are active. Make any changes you need for the values of the prompts. 4. If you need to access advanced functions. Consider the cumulative effect that having multiple processes in 225 . Threshold settings are meant to inform you that. 3. a backlog for that process may not result in a threshold condition while being sufficiently large to cause subsequent processes to have backlogs which exceed their thresholds. To change a data group definition. see “Tips for data group parameters” on page 210. Ultimately. Note: If you change the Number of DB apply sessions prompt (NBRDBAPY). you need to start the data group specifying *YES for the Clear pending prompt (CLRPND). Important! When evaluating whether threshold settings are compatible with your RTO. 5. If the threshold for one process is set higher than its shipped value. you must consider all of the processes in the replication paths for which the data group is configured and their thresholds. However. Make any changes you need for the values of the prompts. all journal entries in the database reader backlog are physically located on the target system but MIMIX has not started to replicate them. Option 3 Option 4 Database reader/send threshold 10 minutes Option 2 Option 3 Option 4 Database apply warning message threshold 100. Table 29 lists the shipped values for thresholds available in a data group definition.000 entries Option 2 Option 3 Option 4 226 . All of the entries in the database apply backlog are waiting to applied to the target system. these entries need to be applied before switching. you may need to use multiple options or adjust one or more threshold values multiple times before finding an appropriate setting. For each data group. and identifies available options to address a persistent threshold condition. The backlogged journal entries exist only in the source system and are at risk of being lost if the source system fails. For data groups that use MIMIX source-send processing. all journal entries in the database send backlog. journal analysis may be required. For data groups that use remote journaling. After the source system becomes available again. Shipped threshold values for replication processes and the risk associated with a backlog Risk Associated with a Backlog Options for Resolving Persistent Threshold Conditions Replication Process Backlog Threshold and its Shipped Default Values Note: Select a name to view a description Remote journaling threshold 10 minutes All journal entries in the backlog for the remote journaling function exist only in the source system journal and are waiting to be transmitted to the remote journal.threshold conditions would have on RTO and your tolerance for data loss in the event of a failure. After the source system becomes available again. If the source system fails. identifies the risk associated with a backlog for each replication process. journal analysis may be required. If the source system fails. A large backlog can also affect performance. These entries cannot be processed by MIMIX user journal replication processes and are at risk of being lost if the source system fails. these entries need to be read and applied before switching. Table 29. are waiting to be read and to be transmitted to the target system. Fine-tuning backlog warning thresholds for a data group Table 29. subsequent processes may have backlogs as replication progresses. All of the packaged objects associated with journal entries in the container send backlog are waiting to be sent to the target system. and a warning message threshold. If the source system fails. As this backlog clears. the process status reflects the threshold condition. The latest changes to these objects exist only in the source system and are at risk of being lost if the source system fails. This option is available only for the object retrieve. listed in order of preference. As this backlog clears. Shipped threshold values for replication processes and the risk associated with a backlog Risk Associated with a Backlog Options for Resolving Persistent Threshold Conditions Option 2 Option 3 Option 4 Replication Process Backlog Threshold and its Shipped Default Values Object send threshold 10 minutes All of the journal entries in the object send backlog exist only in the system journal on the source system and are at risk of being lost if the source system fails. If the number of entries in a backlog divided by the number of active jobs exceeds the job threshold. Each of these processes have a configurable minimum and maximum number of jobs. The latest changes to these objects exist only in the source system and are at risk of being lost if the source system fails. If the backlog reaches the higher value specified in the warning message threshold. container send. subsequent processes may have backlogs as replication progresses All of the entries in the object apply backlog are waiting to be applied to the target system. the 227 . these entries need to be applied before switching. extra jobs are automatically started in an attempt to address the backlog. Object retrieve warning message threshold 100 entries Option 1 Option 2 Option 3 Option 4 Container send warning message threshold 100 entries Option 1 Option 2 Option 3 Option 4 Object apply warning message threshold 100 requests Option 1 Option 2 Option 3 Option 4 The following options are available. All of the objects associated with journal entries in the object retrieve backlog are waiting to be packaged so they can be sent to the target system. Any related objects for which an automatic recovery action was collecting data may be lost. MIMIX may not have determined all of the information necessary to replicate the objects associated with the journal entries. Option 1 . If the process frequently shows a threshold status. and object apply processes. a threshold at which more jobs are started. As this backlog clears. Some options are not available for all thresholds. subsequent processes may have backlogs as replication progresses.Adjust the number of available jobs. The changes do not persist if the job is ended manually or by nightly cleanup operations resulting from the configured job restart time (RESTARTTIME) on the data group definition. if the quantity of entries is more of a concern than time. some processes support specifying additional threshold criteria not used by shipped default settings.Change threshold values or add criterion. Changes to threshold values are effective the next time the process status is requested. It may be necessary to change configurations to adjust what is defined to each data group or to make permanent work management changes for specific jobs.maximum number of jobs may be too low or the job threshold value may be too high. Option 4 . or in conjunction with a time value. contact your Certified MIMIX Consultant for assistance. In addition. If both time and entries are specified. the first criterion reached will trigger the threshold condition. 228 . you can adjust the threshold so that a number of journal entries is used as criteria instead of. For the remote journal.Temporarily increase job performance.Get assistance. Use work management functions to increase the resources available to a job by increasing its run priority or its timeslice (CHGJOB command). If you tried the other options and threshold conditions persist. and object send processes. All processes support changing the threshold value. Option 2 . Adjusting either value in the data group configuration can result in more throughput. database reader (or database send). This option is available for all processes except the RJ link. These changes are effective only for the current instance of the job. Option 3 . journal definition.Copying a definition CHAPTER 11 Additional options: working with definitions The procedures for performing common functions. journal definition. transfer definition. If you specify *YES for the Replace definition prompt. journal definition. the To journal defining prompt must exist. Notes for journal definitions: • The journal definition identified in the From journal definition prompt must exist before it can be copied. “Deleting a definition” on page 230 provides a procedure for deleting a system definition. or a data group definition. displaying. Specific procedures are included for renaming each type of definition and for swapping system definition names. or a data group definition. Before you copy a data group definition. transfer definition. journal definition. and printing definitions. The journal definition identified in the To journal defining prompt cannot exist when you specify *NO for the Replace definition prompt. Notes for data group definitions: • • The data group entries associated with a data group definition are not copied. or a data group definition. such as renaming a system definition which is typically done as a result in a change of software. It is possible to introduce conflicts in your configuration when replacing an existing journal definition. ensure that activity is ended for the definition to which you are copying. The topics in this chapter include: • • • • “Copying a definition” on page 229 provides a procedure for copying a system definition. such as copying. The generic procedures in this topic can be used for copying. transfer definition. “Renaming definitions” on page 232 provides procedure for renaming definitions. • • Copying a definition Use this procedure on a management system to copy a system definition. transfer definition. are very similar for all types of definitions used by MIMIX. “Displaying a definition” on page 231 provides a procedure for displaying a system definition. displaying. or a data group definition. deleting. and renaming. “Swapping system definition names” on page 238 provides a procedure to swap system definition names. journal definition. or a data group definition. “Printing a definition” on page 232 provides a procedure for creating a spooled file which you can print that identifies a system definition. transfer definition. These conflicts are automatically resolved • 229 . 4. and the journal receivers are not deleted. transfer definition. Type a 3 (Copy) next to definition you want and press Enter. 2. 7. specify *YES.Additional options: working with definitions or an error message is sent when the journal environment for the definition is built. To copy the definition. only the definition is deleted. information associated with the definition is also deleted. and data group definitions with all associated data group entries. Deleting a definition Use this procedure on a management system to delete a system definition. 6. To copy a definition. or a data group definition. 1. See “Accessing the 230 . the display has additional prompts. The Copy display for the definition type you selected appears. This includes journal definitions. all of its associated data group entries are also deleted. select the option for the type of definition you want and press Enter. See “Accessing the MIMIX Main Menu” on page 84 for information about using these. If you are copying a journal definition or a data group definition. From the MIMIX Main Menu. do the following: Note: The following procedure includes using MIMIX menus. all other configuration elements associated with that definition are deleted. The delete function does not clean up any records for files in the error/hold file. If you delete a data group definition. 5. The "Work with" display for the definition type appears. transfer definitions. do the following: Note: The following procedure includes using MIMIX menus. press Enter. To delete a definition. The value *NO for the Replace definition prompt prevents you from replacing an existing definition. If you want to replace an existing definition. Verify that the values of prompts are what you want. journal definition. specify a name for the definition to which you are copying information. • • When you delete a journal definition. At the To definition prompt. From the MIMIX Configuration Menu. Attention: When you delete a system or data group definition. the journal. 3. Ensure that the definition you delete is not being used for replication and be aware of the following: • If you delete a system definition. select option 11 (Configuration menu) and press Enter. The files being journaled. c. on the Work with Systems display. select option 11 (Configuration menu) and press Enter. journal definition. use option 10 (End data group). Type a 5 (Display) next to definition you want and press Enter. transfer definition. 4. 1. 2. From the MIMIX Configuration Menu. 231 . The result is a list of data groups for the system you selected. 3. Before deleting a system definition. do the following: Note: The following procedure includes using MIMIX menus. A confirmation display appears with a list of definitions to be deleted. use option 10 (End journaling). From the MIMIX Configuration Menu. select option 11 (Configuration menu) and press Enter. e. The "Work with" display for the definition type appears. The "Work with" display for the definition type appears. Do the following: a. Page Down to see all of the values. d. The definition display appears. From the MIMIX Main Menu. or a data group definition. From the MIMIX Main Menu. 4. select the option for the type of definition you want and press Enter. See “Accessing the MIMIX Main Menu” on page 84 for information about using these. 5. 1. 3. From the MIMIX Main Menu. On the Work with Data Groups display. Type a 4 (Delete) next to definition you want and press Enter. Displaying a definition Use this procedure to display a system definition. Ensure that the definition you want to delete is not being used for replication.Displaying a definition MIMIX Main Menu” on page 84 for information about using these. select option 2 (Work with systems) and press Enter. f. 2. If necessary. On the Work with DG File Entries display. Type a 17 (File entries) next to the data group you want and press Enter. uses option 10 (End managers). To display a definition. Type an 8 (Work with data groups) next to the system you want and press Enter. To delete the definitions press Enter. verify that the status of the file entries is *INACTIVE. select the option for the type of definition you want and press Enter. b. select the option for the type of definition you want and press Enter. transfer definition. journal definition. You can print the spooled file according to your standard print procedures. ensure that MIMIX activity is ended by using the End Data Group (ENDDG) and End MIMIX Manager (ENDMMXMGR) commands. This section includes the following procedures: • • • • “Renaming a system definition” on page 232 “Renaming a transfer definition” on page 235 “Renaming a journal definition with considerations for RJ link” on page 236 “Renaming a data group definition” on page 237 Renaming a system definition System definitions are typically renamed as a result of a change in hardware.Additional options: working with definitions Printing a definition Use this procedure to create a spooled file which you can print that identifies a system definition. data group definitions. or a data group definition. ensure that all other configuration elements related to it are not active. See “Accessing the MIMIX Main Menu” on page 84 for information about using these. When you rename a system definition. This includes journal definitions. 1. The "Work with" display for the definition type appears. transfer definitions. or data group definition must be run from a management system. 4. Attention: Before you rename a system definition. 2. select option 11 (Configuration menu) and press Enter. transfer definition. do the following. Type a 6 (Print) next to definition you want and press Enter. all other configuration information that references the system definition is automatically modified to include the updated system name. 232 . 3. From the MIMIX Main Menu. A spooled file is created with a name of MX***DFN. To print a definition. Note: The following procedure includes using MIMIX menus. where *** indicates the type of definition. Attention: Before you rename any definition. journal definition. From the MIMIX Configuration Menu. Renaming definitions The procedures for renaming a system definition. and associated data group entries. do the following for each system whose definition you are renaming: from the management system unless noted otherwise: Note: The following procedure includes using MIMIX menus. select option 8 (Work with data groups) on the system whose definition you are renaming. From the Work with Data Groups display. Press F10 to access additional parameters. select option 2 (Work with transfer definitons) and press Enter. For all systems. ensure communications before continuing. From the Work with Systems Definitions (WRKSYSDFN) display type a 7 233 . From the MIMIX Configuration Menu. 8. Specify the System 1 host name or address and System 2 host name or address as the actual host names or IP addresses of the systems and press Enter. Otherwise. do the following: a. If changing the host name or IP address. use the host name or IP address specified in Step 6. 4. 6. b. 7. If you changed these. 9. Autostart entries must be reviewed for possible updates of a new system name or IP address. See “Accessing the MIMIX Main Menu” on page 84 for information about using these. The Work with Transfer Definitions display appears. For each data group listed. 3.Renaming definitions To rename system definitions. Note: Many installations will have an autostart entry for the STRSVR command. Start the MIMIXSBS subsystem and the port jobs on all systems using the host names or IP addresses. see “Identifying the current autostart job entry information” on page 169 and “Changing an autostart job entry and its related job description” on page 169. Perform a controlled end of the MIMIX installation. From the MIMIX Intermediate Main Menu. b. select option 2 (Work with systems) and press Enter. 5. do the following steps. d. select option 11 (Configuration menu) and press Enter. The Change Transfer Definition (CHGTFRDFN) display appears. Record the Last Read Receiver name and Sequence # for both database and object. From the MIMIX Intermediate Main Menu. continue with Step 7. e. a. End the MIMIXSBS subsystem on all systems. Follow the steps in topic “Verifying all communications links” on page 174. select option 8 (Display status) and press Enter. 1. See the Using MIMIX book for procedures for ending MIMIX. See the Using MIMIX book for procedures for ending the MIMIXSBS subsystem. and press Enter. c. From the Work with Systems display. Select option 2 (Change) and press Enter. For more information. 2. At the Manager prompt. Press Enter. do the following: a. Press Enter. The Start MIMIX Managers (STRMMXMGR) display appears. Press F3 to return to the Work with Systems display. Type a 9 (Start) next to each network system you want and press Enter. The Start Data Group (STRDG) display appears. For each network system. that were recorded in Step 5b for both database and object. Press Enter. b. From the Work with Data Groups display. 21. Type a 9 (Start) next to the management system you want and press Enter. b. 14. 19. 12. Press Enter again to start the data groups. Refer to the Using MIMIX book for more information. press F12. 15. The Start Data Group (STRDG) display appears. For each data group listed. 20. Ensure all data groups are active. Press F10 to display additional parameters. From the Work with Systems display. 24. From the Work with Data Groups display. From the Work with Systems display. Do the following: a. The Start MIMIX Managers (STRMMXMGR) display appears. specify *ALL. select option 8 (Work with data groups) on the management system and press Enter. The Rename System Definitions (RNMSYSDFN) display appears. The Work with Systems display appears. 16. 13. b. select option 9 (Start DG) and press Enter. At the To system definition prompt. d. In the Reset configuration prompt. Press F12 again to return to the MIMIX Intermediate Main Menu. Press Enter. The Work with data groups display reappears. Press F10 to access additional parameters. Additional parameters are displayed. 18. c. specify *YES. 23. 10. do the following: a. select option 9 (Start DG) for data groups (highlighted red) that are not active and press Enter. specify the new name for the system whose definition is being renamed and press Enter. The Work with Systems display appears. 11. c. select option 8 (Work with data groups) on the system whose definition you have renamed and ensure all data groups are active.Additional options: working with definitions (Rename) next to the system whose definition is being renamed and press Enter. From the Work with Systems display. 22. adding 1 to the sequence #s. Type the Receiver names and Sequence #s. Select option 2 (Work with systems) and press Enter. Once this is complete. 234 . 17. select option 8 (Work with data groups) on the system whose definition you have renamed and press Enter. select option 2 (Work with transfer definitions) and press Enter. type a 2 (Change) next to the system name whose transfer definition needs to be changed and press Enter. To rename a transfer definition. From the Change Data Group Definition display. From the MIMIX Configuration Menu. All of the steps must be completed. From the MIMIX Configuration Menu.Renaming definitions Press F5 to refresh data. From the MIMIX Configuration Menu. Press F12 to return to the MIMIX Configuration Menu. type a 2 (Change) next to the data group name whose transfer definition needs to be changed and press Enter. The following procedure renames the transfer definition and includes steps to update the other configuration information that references the transfer definition including the system definition. The Rename Transfer Definition display for the definition type you selected appears. select option 8 (Work with remote journal links) and press Enter. From the Work with Transfer Definitions menu. Refer to the Using MIMIX book for more information. At the To transfer definition prompt. From the Work with System Definitions menu. 3. Renaming a transfer definition When you rename a transfer definition. Press F12 to return to the MIMIX Configuration Menu. 9. and remote journal link. 7. press F11 to display the transfer definitions. Press F12 to return to the MIMIX Configuration Menu. 235 . 4. You must manually update other information which references the transfer definition. other configuration information which references it is not updated with the new name. 2. From the Work with DG Definitions menu. 11. select option 11 (Configuration menu) and press Enter. 8. 13. specify the values you want for the new name and press Enter. select option 1 (Work with system definitions) and press Enter. See “Accessing the MIMIX Main Menu” on page 84 for information about using these. specify the new name for the transfer definition and press Enter until the Work with DG Definitions display appears. 12. data group definition. From the MIMIX Configuration Menu. 1. 14. 15. 10. select option 4 (Work with data group definitions) and press Enter. 6. From the Change System Definition display. do the following from the management system: Note: The following procedure includes using MIMIX menus. 5. From the Work with RJ Links menu. specify the new name for the transfer definition and press Enter. From the MIMIX Intermediate Main Menu. type a 7 (Rename) next to the definition you want to rename and press Enter. Perform a controlled end for the data group in your remote journaling environment. other configuration information which references it is not updated with the new name. 2. At the To journal definition prompts. 1. If you do not want the journal name to be renamed. Press F12 to return to the MIMIX Configuration Menu. type a 15 (Remove RJ connection) next to the link that you want and press Enter. including considerations when an RJ link is used. The remote journal link should have a state value of *INACTIVE before you continue. From the MIMIX Configuration Menu. Verify that the remote journal link is not in use on both systems. e. From the Work with Journal Definitions menu. select option 11 (Configuration menu) and press Enter. Otherwise. The Rename Journal Definition display for the definition you selected appears. do the following from the management system: Note: The following procedure includes using MIMIX menus. you must specify the journal name rather than the default of *JRNDFN for the journal (JRN) parameter. Renaming a journal definition with considerations for RJ link When you rename a journal definition. If you rename a journal definition. select option 8 (Work with remote journal links) and press Enter. 5. To continue removing the connections for the selected links. End the remote journal link in a controlled manner. This procedure includes steps for renaming the journal definition in the data group definition. Use topic “Ending all replication in a controlled manner” in the Using MIMIX book. d. 3. select option 3 (Work with journal definitions) and press Enter. From the MIMIX Intermediate Main Menu. b. specify the new name for the transfer definition and press Enter. do the following. type a 7 (Rename) next to the journal definition names you want to rename and press Enter. Use topic “Ending a remote journal link independently” in the Using MIMIX book. 17. From the Change Remote Journal Link display. press Enter. See “Accessing the MIMIX Main Menu” on page 84 for information about using these. 236 . c. specify the values you want for the new name. the journal name will also be renamed if you used the default value of *JRNDFN when configuring the journal definition. Remove the remote journal connection (the RJ link).Additional options: working with definitions 16. From the MIMIX Configuration Menu. To rename a journal definition. A confirmation display appears. Type a 2 (Change) next to the RJ link where you changed the transfer definition and press Enter. From the Work with RJ Links display. continue with Step 3: a. If using remote journaling. 4. f. Use topic “Displaying status of a remote journal link” in the Using MIMIX book. Press Enter. Otherwise. select option 4 (Work with data group definitions) and press Enter. From the MIMIX Configuration Menu. 1. 11. type a 2 (Change) next to the data group name that uses the journal definition you changed and press Enter. Specify the values entered in Step 5 and press Enter. ensure that there are no journal receiver prefixes in the specified library whose names start with the journal receiver prefix. 2. See “Building the journaling environment” on page 195 for more information. b. 10. 6. 12. ensure that the data group has a status of *INACTIVE. 13. do the following to change the corresponding definition for the remote journal. The Work with Journal Definitions display appears. select option 4 (Work with data group definitions) and press Enter. type a 14 (Build) next to the journal definition names you changed and press F4. You should see a message that indicates the journal environment was created. select option 11 (Configuration menu) and press Enter. From the MIMIX Intermediate Main Menu. The Build Journaling Environment display appears. From the Work with DG Definitions menu. 8. If the journal name is *JRNDFN. At the Source for values prompt. Type a 2 (Change) next to the corresponding remote journal definition name you changed and press Enter. 3. Press F12 to return to the MIMIX Configuration Menu. continue with Step 8: a. 14. 237 . Press F10 to access additional parameters. If using remote journaling. From the Work with Journal Definitions menu. end it using the procedure “Ending a data group in a controlled manner” in the Using MIMIX book. From the MIMIX Configuration Menu. Attention: Before you rename a data group definition. Press Enter. 9. If the data group is active. specify the new name for the System 1 journal definition and System 2 journal definition and press Enter twice. From the Work with DG Definitions menu. specify *JRNDFN.Renaming definitions a. Renaming a data group definition Do the following to rename a data group definition: Note: The following procedure includes using MIMIX menus. type a 7 (Rename) next to the data group name you want to rename and press Enter. 4. See “Accessing the MIMIX Main Menu” on page 84 for information about using these. 7. Ensure that the data group is ended. From the Change Data Group Definition display. Ensure each step is successful before proceeding to the next step. Enter a temporary name for the network system (SYSTEMA) in the To system definition prompt. Port jobs must be running on both systems. The Start MIMIX Managers (STRMMXMGR) display appears. 4. Enter *YES for Reset configuration and press Enter. Attention: Before you swap system definition names. Refer to the following requirements before beginning this procedure: Requirements for swapping system definition names • • • • • This procedure must be run from the management system. ensure that MIMIX activity is ended by using the End Data Group (ENDDG) and End MIMIX Manager (ENDMMXMGR) commands. select option 1 (Work with system definitions) and press Enter. Press F12. Press Enter. 6. 10. To swap system definition names. 238 . Press F12 again to return to the MIMIX Intermediate Main Menu. 3. The Rename System Definitions (RNMSYSDFN) display appears. Record system definition names. 9. 2. including temporary names used for this procedure. From the Rename Data Group Definition display. 8. On the temporary system.Additional options: working with definitions 5. 7. See “Accessing the MIMIX Main Menu” on page 84 for information about using these. Swapping system definition names Use the procedure in this section to swap system definition names. Type a 7 (Rename) next to the network system definition (SYSTEMA) and press Enter. Select option 2 (Work with systems) and press Enter. select option 11 (Configuration menu) and press Enter. Use either the IP addresses or the actual host names in the transfer definition. The Work with Systems display appears. 1. do the following: Note: The following procedure includes using MIMIX menus. specify the new name for the data group definition and press Enter. The following procedure uses SYSTEMA for the network system definition and SYSTEMB for the management system definition. The Work with System Definitions (WRKSYSDFN) display appears. Press F10 to display additional parameters. From the MIMIX Intermediate Main Menu. From the MIMIX Configuration Menu. 5. select option 9 (Start) and press Enter. select option 11 (Configuration menu) and press Enter. 25. The Start MIMIX Managers (STRMMXMGR) display appears. From the MIMIX Configuration Menu. Type a 7 (Rename) next to the temporary network system definition and press Enter. 19. 21. 12. 13. 26. 29. 31. Select option 2 (Work with systems) and press Enter. On both systems. Press F12. Press F10 to display Additional parameters. 30. On both systems. Type a 7 (Rename) next to the management system definition (SYSTEMB) and press Enter. 28. 32. 23. 33. Press F10 to 239 . Press Enter. Enter the old network system definition name (SYSTEMA) in the To system definition prompt. select option 9 (Start) and press Enter. The Work with System Definitions (WRKSYSDFN) display appears. Press F12. select option 9 (Start) and press Enter. The Rename System Definitions (RNMSYSDFN) display appears. select option 11 (Configuration menu) and press Enter. Press F12 to return to the MIMIX Intermediate Main Menu. From the MIMIX Intermediate Main Menu. The Work with Systems display appears. select option 1 (Work with system definitions) and press Enter. Enter *YES for Reset configuration and press Enter for both systems. 17. From the MIMIX Configuration Menu. Select option 10 (End) for both systems and press Enter. 24. Press Enter. 22. Press F12 to return to the MIMIX Intermediate Main Menu. Press F12 again to return to the MIMIX Intermediate Main Menu. select option 1 (Work with system definitions) and press Enter. 16. Enter the old management system definition name (SYSTEMB) in the To system definition prompt. 15. The Rename System Definitions (RNMSYSDFN) display appears. 20. 27. 18. Press F12 to return to the MIMIX Intermediate Main Menu. The Start MIMIX Managers (STRMMXMGR) display appears. Ensure the systems are ended before proceeding. Select option 2 (Work with systems) and press Enter. From the MIMIX Intermediate Main Menu. From the Work with Systems display select option 10 (End) for both systems and press Enter. 14. The Work with Systems display appears.Swapping system definition names 11. The Work with System Definitions (WRKSYSDFN) display appears. 240 . 34.Additional options: working with definitions display Additional parameters. Enter *YES for Reset configuration and press Enter. The topics in this chapter include: • “Creating data group object entries” on page 242 describes data group object entries which are used to identify library-based objects for replication. Procedures for creating these are included. “Creating data group data area entries” on page 261 describes data group data area entries which identify data areas to be replicated by the data area poller process. Procedures for creating these are included. Procedures for creating these are included. “Creating data group file entries” on page 246 describes data group file entries which are required for user journal replication of *FILE objects. You can add individual data group entries. “Loading tracking entries” on page 257 describes how to manually load tracking entries for IFS objects. data areas. and data queues that are configured for user journal replication. “Additional options: working with DG entries” on page 263 provides procedures for performing data group entry common functions. “Creating data group IFS entries” on page 255 describes data group IFS entries which identify IFS objects for replication.CHAPTER 12 Configuring data group entries Data group entries can identify one or many objects to be replicated or excluded from replication. • • • • • • The appendix “Supported object types for system journal replication” on page 505 lists IBM i object types and indicates whether each object type is replicated by MIMIX. removing. Procedures for creating these are included. load entries from an existing source. such as copying. 241 . and change entries as needed. Procedures for creating these are included. and displaying. “Creating data group DLO entries” on page 259 describes data group DLO entries which identify document library objects (DLOs) for replication by MIMIX system journal replication processes. you can select multiple objects for which MIMIX will create appropriate data group object entries. Press F19 (Load). From the Work with Data Groups display. if necessary. For object types that can be journaled (*FILE. 3. The Work with DG Object Entries display appears. you can select from a list of data areas in the library to create exclude entries for the objects you do not want replicated. The custom load function can simplify creating data group entries. This function generates a list of objects that match your specified criteria.Creating data group object entries Data group object entries are used to identify library-based objects for replication. you can tailor them to meet your requirements. How replication is performed for the objects identified depends on the object type and configuration settings. For example. Loading data group object entries In this procedure. and *DTAQ). 242 . see the following topics: • • • “Identifying library-based objects for replication” on page 91 “Identifying logical and physical files for replication” on page 96 “Identifying data areas and data queues for replication” on page 103 When you configure MIMIX. From the management system. you could use the Add Data Group Object Entry (ADDDGOBJE) command to create a single data group object entry that includes all data areas in the library. from which you can selectively create data group object entries. You can customize individual entries later. some of which also require data group file entries to be configured. You can also use the #DGFE audit or the Check Data Group File Entries (CHKDGFE) command to ensure that the correct file entries exist for the object entries configured for the specified data group. you can create data group object entries by adding individual object entries or by using the custom load function for library-based objects. using the same object selection criteria with the custom load function. Once you have created data group object entries. From the list. From the MIMIX Intermediate Main Menu. values specified in the object entry and other configuration information determine whether the object is replicated through the system journal or is cooperatively processed with the user journal. several configuration options are available. if you want to replicate all but a few of the data areas in a specific library. system journal replication processes are used. For object types that cannot be journaled to a user journal. For *FILE objects. do the following to create a custom load of object entries: 1. *DTAARA. For detailed concepts and requirements for supported configurations. you specify selection criteria that results in a list of objects with similar characteristics. type a 20 (Object entries) next to the data group you want and press Enter. Then. 2. type a 1 (Work with data groups) and press Enter. From the management system. This includes after the nightly restart of MIMIX jobs. you may need to press Enter multiple times. Either type a 1 (Select) next to the objects you want or press F21 (Select all). b. Identify the library and objects to be considered. Press F9 (All parameters). If necessary. To generate the list of objects. and data queues will be replicated from the user journal. The entries will be available to replication processes after the data group is ended and restarted. e. data areas. and System 2 object prompts. IFS objects to user journaling” on page 136. c. type a 1 (Work with data groups) and press Enter. do the following to add a new data group object entry or change an existing entry: 1. If necessary. c. Specify values for the System 1 library and System 1 object prompts. press Enter. specify values for the Object type. d. At the Process type prompt. Specify appropriate values for the Cooperate with database and Cooperating object types prompts. Then press Enter. Attribute. Adding or changing a data group object entry Note: If you are converting a data group to use user journal replication for data areas or data queues. To ensure that journaled files. Specify the values you need on the elements of the File entry options prompt. you must specify the object types. Note: If you skipped Step 5. 8. b. The Load DG Object Entries display appears with the list of objects that matched your selection criteria. Ensure that the remaining prompts contain the values you want for the data group object entries that will be created. From the MIMIX Intermediate Main Menu. do the following: a.Creating data group object entries 4. use this procedure when directed by “Checklist: Change *DTAARA. *DTAQ. System 2 library. 6. specify whether resulting data group object entries should include or exclude the identified objects. Press Page Down until you locate the File entry options prompt. Synchronize the objects identified by data group entries before starting replication processes or running MIMIX audits. The Load DG Object Entries (LODDGOBJE) display appears. Do the following to specify the selection criteria: a. 7. 5. The entries will be available to MIMIX audits the next time an audit runs. Press Page Down to see all of the prompts. you can use “Adding or changing a data group object entry” on page 243 to customize values for any of the data group object entries. To specify file entry options that will override those set in the data group definition. 243 . System 2 object. or data queues will be replicated from the user journal. type a 2 (Change) next to the entry you want and press Enter. If necessary. Synchronize the objects identified by data group entries before starting replication processes or running MIMIX audits. The entries will be available to replication processes after the data group is ended and restarted. 9. To specify file entry options that will override those set in the data group definition. and Object auditing value prompts. 8. do the following: a. 6. If necessary. If necessary. Ensure that the remaining prompts contain the values you want for the data group object entries that will be created. System 2 library. 3. make sure that you specify only the objects you want to enable for the System 1 object prompt. data areas. you must specify values for the System 1 library and System 1 object prompts. Specify the values you need on the elements of the File entry options prompt. 11. type a 1 (Add) next to the blank line at the top of the list and press Enter. 5. return to Step 7 in procedure “Checklist: Change *DTAARA. To change an existing entry. 10. When adding an entry. specify values for the Attribute. specify a value for the Object type prompt. Note: When changing an existing object entry to enable replication of data areas or data queues from a user journal (COOPDB(*YES)). b.2. At the Process type prompt. Specify appropriate values for the Cooperate with database and Cooperating object types prompts. 13. Do one of the following: • • To add a new entry. Press Page Down to locate the File entry options prompt. Press Page Down to see more prompts. specify whether resulting data group object entries should include (*INCLD) or exclude (*EXCLD) the identified objects. This includes after the nightly 244 . Note: To ensure that journaled files. IFS objects to user journaling” on page 136 to complete additional steps necessary to complete the conversion. From the Work with Data Groups display. Otherwise. For object entries configured for user journal replication of data areas or data queues. 4. *DTAQ. The appropriate Data Group Object Entry display appears. type a 20 (Object entries) next to the data group you want and press Enter. all objects in the library specified for System 1 library will be enabled. The Work with DG Object Entries display appears. you must specify *YES for Cooperate with database and you must specify the appropriate object types for Cooperating object types. Press F9 (All parameters). Press Enter. 12. 7. Creating data group object entries restart of MIMIX jobs. 245 . The entries will be available to MIMIX audits the next time an audit runs. When you configure MIMIX. as determined by the specified for System 1 library (LIB1). *JRNDFN . • • • When loading from a data group. Any file entry option with a value of *DFT is loaded from the specified source. you can have MIMIX create the entries for you using the Load Data Group File Entries (LODDGFE) command. The Configuration source (CFGSRC) parameter supports loading from a variety of sources. you can also specify the source from which file entry options are loaded. Note: If you plan to use either MIMIX Dynamic Apply or legacy cooperative processing.File entry information is loaded from a journal specified in the journal definition associated with the specified data group.File entry information is loaded from the information in data group object entries configured for the data group. File entries will be created for all files currently journaled to the journal specified in the journal definition. and Load from system (LODSYS) parameters. see the following topics: • • “Identifying library-based objects for replication” on page 91 “Identifying logical and physical files for replication” on page 96 Loading file entries If you need to create data group file entries for many files. you can tailor them to meet your requirements. This option supports loading from version 5 and version 6 data groups on the same system. System 2 library (LIB2). This value is typically used when loading file entries from a data group in a different installation of MIMIX. 246 . If you are configuring to use MIMIX Dynamic Apply or legacy cooperative processing. Once you have created the file entries. The Default FE options source (FEOPTSRC) parameter determines whether file entry options are loaded from the specified configuration source (*CFGSRC) or from the data group definition (*DGDFT). *DGFE . It is strongly recommended that you create data group object entries first. this value is recommended. Then. load the data group file entries from the object entry information defined for the files. and override elements if needed. For detailed concepts and requirements for supported configurations.File entry information is loaded from data group file entries defined to another data group.Creating data group file entries Data group file entries are required for user journal replication of *FILE objects. listed below in order most commonly used: • *DGOBJE . *NONE .File entry information is loaded from a library on either the source or target system. you can create data group file entry information by creating data group file entries individually or by loading entries from another source. You can use the #DGFE audit or the Check Data Group File Entries (CHKDGFE) command to ensure that the correct file entries exist for the object entries configured for the specified data group. Any values specified on elements of the File entry options (FEOPT) parameter override the values loaded from the FEOPTSRC parameter for all data group file entries created by a load request. files must be defined by both data group object entries and data group file entries. The data group definition specifies *SYS1 as its data source (DTASRC). Since all files identified by object entries are wanted.Load from the same data group This example illustrates how to create file entries when converting a data group to use MIMIX Dynamic Apply. with file entry options loaded from multiple sources.Creating data group file entries Regardless of where the configuration source and file entry option source are located. data group DGDFN1 is being converted.Load from another data group with mixed sources for file entry options The file entries for data group DGDFN1 are created by loading from the object entries for data group DGDFN2. Loading file entries from a data group’s object entries This topic contains examples and a procedure. LODDGFE DGDFN(DGDFN1) CFGSRC(*DGOBJE) UPDOPT(*ADD) LODSYS(*SYS2) SELECT(*NO) Since no value was specified for FROMDGDFN. In order to accurately determine whether files are being journaled to the target system. Note: The Load Data Group File Entries (LODDGFE) command performs a journal verification check on the file entries using the Verify Journal File Entries (VFYJRNFE) command. Entries are added (UPDOPT(*ADD) to the existing configuration. Because the command specified the first element (Journal image) and third element (Replication type) of the file entry options (FEOPT) as *CFGSRC. you should first perform a save and restore operation to synchronize the files to the target system before loading the data group file entries. its default value *DGDFN causes the file entries to load from existing object entries for DGDFN1. The rest of the file entry options are loaded from the configuration source (object entries for DGDFN2). Procedure: Use this procedure to create data group file entries from the object entries defined to a data group. with file entry options coming from multiple sources. The examples illustrate the flexibility available for loading file entry options. In this example. these elements are loaded from the data group definition. file entries will be loaded from the target system to take advantage of a known synchronization point at which replication will later be started. in this example. the resulting file entries have the same values for those elements as the data group object entries for DGDFN2. LODDGFE DGDFN(DGDFN1) CFGSRC(*DGOBJE) FROMDGDFN(DGDFN2) FEOPT(*CFGSRC *DGDFT *CFGSRC *DGDFT) The data group file entries created for DGDFN1 are loaded from the configuration information in the object entries for DGDFN2. However. the Load Data Group File Entries (LODDGFE) command must be used from a system designated as a management system. The value *SYS2 for LODSYS causes this example configuration to load from its target system. Example . 247 . The data group file entries for DGDFN1 created have file entry options which match those found in the object entries because no values were specified for FEOPTSRC or FEOPT parameters. SELECT(*NO) bypasses the selection list. Example . Because the command specified the second element (Omit open/close entries) and the fourth element (Lock member during apply) as *DGDFT. (This value should be the same as the value specified for Data source in the data group definition. From the management system.) c. Press Enter. Press F10 (Additional parameters). Each element in the file entry options is loaded from the specified location unless you explicitly specify a different value for an element in Step 6. The Work with DG File Entries display appears. files should be loaded from the source system of the data group you are loading. 2. From the MIMIX Intermediate Main Menu.Note: The data group must be ended before using this procedure. The LODDGFE Entry Selection List display appears with a list of the files identified by the specified configuration source. From data group definition . Specify appropriate values. Load from system . type a 1 (Work with data groups) and press Enter. The name of the data group for which you are creating file entries and the Configuration source value of *DGOBJE are pre-selected. Specify values as needed for the elements of the File entry options prompts. Press F19 (Load). d. Each generated file entry includes all members of the file.If necessary. specify the three-part name of the data group. press Enter. The Load Data Group File Entries (LODDGFE) display appears.To load from entries defined to a different data group. 3. 9. you can use “Changing a data group file entry” on page 253 to customize values for any of the data group file entries. Do the following: a.Ensure that the value specified is appropriate. do the following: 1. you can specify a file entry option value to override those loaded from the configuration source. specify the value you want. From the Work with Data Groups display. All selected files identified from the configuration source are represented in the resulting file entries. 7. To create the file entries.Specify the source for loading values for default file entry options. For most environments. The following prompts appear on the display. b. 5. 6. Press Enter. 8. Default FE options source . Update option . Any values you specify will be used for all of the file entries created with this procedure. If necessary. Either type a 1 (Load) next to the files that you want or Press F21 (Select all). type a 17 (File entries) next to the data group you want and press Enter. Configuration changes resulting from loading file entries are not effective until the data group is restarted. a. 4. 248 . b. Optionally. If necessary. Because there is no MIMIX configuration source specified. 5. Procedure: Use this procedure to create data group file entries from a library on either the source system or the target system. At the Configuration source prompt. Press F19 (Load). From the MIMIX Intermediate Main Menu. Press F10 (Additional parameters). 8. type a 1 (Work with data groups) and press Enter. the resulting data group file entries are created with a value of *DFT for all of the file entry options. LODDGFE DGDFN(DGDFN1) CFGSRC(*NONE) LIB1(TESTLIB) Since the FEOPT parameter was not specified. 249 . specify the values you want for the following: Update option prompt Add entry for each member prompt 7. From the Work with Data Groups display. do the following: a. 6. This example assumes the configuration is set up so that system 1 in the data group definition is the source for replication. b. The Work with DG File Entries display appears. specify *NONE and press Enter. From the management system. To optionally specify file entry options. 4. 2. Note: The data group must be ended before using this procedure. The value of the Default FE options source prompt is ignored when loading from a library. The LODDGFE Entry Selection List display appears with a list of the files identified by the specified configuration source. you can accomplish this by specifying a library name at the System 1 library prompt and accepting the default values for the System 2 library. Load from system. The Load Data Group File Entries (LODDGFE) display appears with the name of the data group for which you are creating file entries. the value *DFT results in the file entry options specified in the data group definition being used. and File prompts. For common configurations. Configuration changes resulting from loading file entries are not effective until the data group is restarted. do the following: 1. Identify the location of the files to be used for loading. If you are using system 2 as the data source for replication or if you want the library name to be different on each system. Press Enter.Creating data group file entries Loading file entries from a library Example: The data group file entries are created by loading from a library named TESTLIB on the source system. Any values you specify will be used for all of the file entries created with this procedure. then you need to modify these values to appropriately reflect your data group defaults. 3. Specify values as needed for the elements of the File entry options prompts. type a 17 (File entries) next to the data group you want and press Enter. From the management system. From the MIMIX Intermediate Main Menu. Note: The data group must be ended before using this procedure. the value that corresponds to the source system of the data group you are loading should be used. For common configurations. 7. do the following: 1. Press F10 (Additional parameters). Procedure: Use this procedure to create data group file entries from the journal associated with a journal definition specified for the data group. The Work with DG File Entries display appears. To create the file entries. This example assumes the configuration is set up so that system 1 in the data group definition is the source for replication. 3. the value *DFT results in the file entry options specified in the data group definition being used.9. do the following: a. ensure that the value specified represents the appropriate system. From the Work with Data Groups display. 4. If necessary. At the Configuration source prompt. If necessary. the resulting data group file entries are created with a value of *DFT for all of the file entry options. Press F19 (Load). All selected files identified from the configuration source are represented in the resulting file entries. File and library names on the source and target systems are set to the same names for the load operation. The value of the Default FE options source prompt is ignored when loading from a journal definition. To optionally specify file entry options. At the Load from system prompt. (This value should match the value specified for Data source in the data group definition. type a 1 (Work with data groups) and press Enter. The Load Data Group File Entries (LODDGFE) display appears with the name of the data group for which you are creating file entries. you can use “Changing a data group file entry” on page 253 to customize values for any of the data group file entries.) 6. specify *JRNDFN and press Enter. LODDGFE DGDFN(DGDFN1) CFGSRC(*JRNDFN) LODSYS(*SYS1) Since the FEOPT parameter was not specified. specify the value you want for the Update option prompt. 250 . Because there is no MIMIX configuration source specified. 5. Configuration changes resulting from loading file entries are not effective until the data group is restarted. Either type a 1 (Load) next to the files that you want or Press F21 (Select all). press Enter. Loading file entries from a journal definition Example: The data group file entries are created by loading from the journal associated system 1 of the data group. The journal definition associated with the specified system is used for loading. The journal definition 1 specified in the data group definition identifies the journal. 10. 2. type a 17 (File entries) next to the data group you want and press Enter. the value *DFT results in file entry options which match those specified in DGDFN2. 4. the value *DFT results in file entry options which match those specified in DGDFN2 in installation MXTEST. Loading file entries from another data group’s file entries Example 1: The data group file entries are created by loading from file entries for another data group. DGDFN2 in another installation MXTEST. LODDGFE DGDFN(DGDFN1) CFGSRC(*DGFE) PRDLIB(MXTEST) FROMDGDFN(DGDFN2) Since the FEOPT parameter was not specified. Each generated file entry includes all members of the file. Note: The data group must be ended before using this procedure. Any values you specify will be used for all of the file entries created with this procedure. 9. the resulting data group file entries for DGDFN1 are created with a value of *DFT for all of the file entry options. Procedure: Use this procedure to create data group file entries from the file entries defined to another data group. Because the configuration source is another data group. If necessary. Configuration changes resulting from loading file entries are not effective until the data group is restarted. 8. Press F19 (Load). From the Work with Data Groups display. From the MIMIX Intermediate Main Menu. the resulting data group file entries for DGDFN1 are created with a value of *DFT for all of the file entry options. The Work with DG File Entries display appears. LODDGFE DGDFN(DGDFN1) CFGSRC(*DGFE) FROMDGDFN(DGDFN2) Since the FEOPT parameter was not specified. All selected files identified from the configuration source are represented in the resulting file entries. you can use “Changing a data group file entry” on page 253 to customize values for any of the data group file entries. Specify values as needed for the elements of the File entry options prompts. At the Configuration source prompt. 251 .Creating data group file entries b. specify *DGFE and press Enter. The LODDGFE Entry Selection List display appears with a list of the files identified by the specified configuration source. type a 1 (Work with data groups) and press Enter. 3. Either type a 1 (Load) next to the files that you want or Press F21 (Select all). Example 2: The data group file entries are created by loading from file entries for another data group. From the management system. press Enter. 2. Press Enter. type a 17 (File entries) next to the data group you want and press Enter. 10. Because the configuration source is another data group in another installation. The Load Data Group File Entries (LODDGFE) display appears with the name of the data group for which you are creating file entries. To create the file entries. DGDFN2. do the following: 1. 5. the configuration is dynamically updated and MIMIX automatically starts journaling of the file on the source system if the file exists and is not already journaled. 7. 4. Press Enter. If necessary. All selected files identified from the configuration source are represented in the resulting file entries. For each MIMIX process. At the System 1 File 252 . Special entries are inserted into the journal data stream to enable the dynamic update. type a 1 (Add) next to the blank line at the top of the list and press Enter. The LODDGFE Entry Selection List display appears with a list of the files identified by the specified configuration source 11. specify the three-part name of the data group from which you are loading. Each element in the file entry options is loaded from the specified location unless you explicitly specify a different value for an element in Step 9. The added data group file entry is recognized by MIMIX as soon as each active process receives the special entries. do the following specify a file entry option value to override those loaded from the configuration source: a. Use this procedure to add a data group file entry to a data group. do the following: 1. Each generated file entry includes all members of the file. Either type a 1 (Load) next to the files that you want or Press F21 (Select all). there may be a delay before the addition is recognized. If necessary. Adding a data group file entry When you add a single data group file entry to a data group definition. Specify the source for loading values for default file entry options at the Default FE options source prompt. either accept *CURRENT or specify the name of an installation library from which the data group you are copying is located. If necessary. At the Production library prompt. At the From data group definition prompts. type a 1 (Work with data groups) and press Enter. From the management system. you can use “Changing a data group file entry” on page 253 to customize values for any of the data group file entries. 9. press Enter. This is true especially for very active data groups. 2. The Add Data Group File Entry (ADDDGFE) display appears. 6. 12. Any values you specify will be used for all of the file entries created with this procedure. To create the file entries. Specify values as needed for the elements of the File entry options prompts. 8. Press F10 (Additional parameters). From the Work with Data Groups display. specify the value you want for the Update option prompt. b. From the Work with DG File Entries display. 10. From the MIMIX Intermediate Main Menu. type a 17 (File entries) next to the data group you want and press Enter. 3. 7. change the values as needed. Specify values as needed for the elements of the File entry options prompts. Any values you specify will be used for all of the file entries created with this procedure 8. 2. do not change the values specified for To system 1 file (TOFILE1) and To member (TOMBR1). then press Page Down. For data groups configured for multiple apply sessions. specify the apply session on the File entry options prompt. type a 17 (File entries) next to the data group you want and press Enter. From the MIMIX Intermediate Main Menu. Press F10 (Additional parameters). Type a 2 (Change) next to the entry you want and press Enter. specify its name at the Member prompt. type a 1 (Work with data groups) and press Enter. Changing a data group file entry Use this procedure to change an existing data group file entry. Locate the file entry you want on the Work with DG File Entries display. From the Work with Data Groups display. From the management system. all members in the file are replicated. Notes: • • If you change the value of the Dynamically update prompt to *NO.Creating data group file entries and Library prompts. 5. If you change the value of the Start journaling of file prompt to *NO and the file is not already journaled. do the following: 1. If you want to replicate only a specific member. Press Enter to create the data group file entry. 6. The Change Data Group File Entry (CHGDGFE) display appears. Notes: • If the file is currently being journaled and transactions are being applied. MIMIX will not be able to replicate changes until you start journaling the file. you can specify file entry options that will override those defined for the data group. If necessary. you need to end and restart the data group before the addition is recognized. Note: All replicated members of a file must be in the same database apply session. By default. Do the following: a. 253 . You can change any of the values shown on the display. Press F10 (Additional parameters) to see all available prompts. b. specify the file that you want to replicate. 3. 4. Optionally. Verify that the values of the remaining prompts on the display are what you want. See Step 7. 5. For data groups configured for multiple apply sessions. The replication processes do not recognize the change until the data group has been ended and restarted. press Enter. To accept your changes. specify the apply session on the File entry options prompt. 254 .• All replicated members of a file must be in the same database apply session. 2. Changes become effective after one of the following occurs: • • • The data group is ended and restarted Nightly maintenance routines end and restart MIMIX jobs A MIMIX audit that uses IFS entries to select objects to audit is started. Do one of the following: • • To add a new entry. do the following to add a new data group IFS entry or change an existing IFS entry: 1. Adding or changing a data group IFS entry Note: If you are converting a data group to use user journal replication for IFS objects. a name that is qualified with the name of the directory in which the object is located. The object name can be a simple name. as well as examples of the effect that multiple data group IFS entries have on object auditing values. To change an existing entry. 4. Notes: • The object name must begin with the '/' character and can be up to 512 characters in total length. type a 2 (Change) next to the entry you want and press Enter.Creating data group IFS entries Creating data group IFS entries Data group IFS entries identify IFS objects for replication. type a 22 (IFS entries) next to the data group you want and press Enter. From the Work with Data Groups display. use this procedure when directed by “Checklist: Change *DTAARA. From the MIMIX Intermediate Main Menu. such as /ABC*. From the management system. • 255 . you must specify a value for the System 1 object prompt. Topic “Identifying IFS objects for replication” on page 106 provides detailed concepts and identifies requirements for configuration variations for IFS objects. or a generic name that contains one or more characters followed by an asterisk (*). The Work with Data Group IFS Entries display appears. All objects in the specified path are selected. Supported file systems are included. The appropriate Data Group IFS Entry display appears. 3. When adding an entry. type a 1 (Work with data groups) and press Enter. The identified objects are replicated through the system journal unless the data group IFS entries are explicitly configured to allow the objects to be replicated through the user journal. Any component of the object name contained between two '/' characters cannot exceed 255 characters in length. *DTAQ. IFS objects to user journaling” on page 136. When changing an existing IFS entry to enable replication from a user journal (COOPDB(*YES)). type a 1 (Add) next to the blank line at the top of the display and press Enter. make sure that you specify only the IFS objects you want to enable. The entries will be available to replication processes after the data group is ended and restarted. specify whether resulting data group object entries should include (*INCLD) or exclude (*EXCLD) the identified objects. specify a value for the Object retrieval delay prompt. If necessary. This includes after the nightly restart of MIMIX jobs. 256 . IFS objects to user journaling” on page 136 to complete additional steps necessary to complete the conversion. The entries will be available to MIMIX audits the next time an audit runs. For IFS entries configured for user journal replication. 10. return to Step 7 in procedure “Checklist: Change *DTAARA. specify *YES. To replicate from the system journal. 8. If necessary. 7. Synchronize the objects identified by data group entries before starting replication processes or running MIMIX audits. At the Process type prompt.5. Press Page Down to see more prompts. 9. 11. specify *NO. Ensure that the remaining prompts contain the values you want for the data group object entries that will be created. To ensure that journaled IFS objects can be replicated from the user journal. 6. Press Enter to create the IFS entry. specify values for the System 2 object and Object auditing value prompts. Specify the appropriate value for the Cooperate with database prompt. *DTAQ. Loading IFS tracking entries After you have configured the data group IFS entries for advanced journaling. Ensure that the data group is ended. This procedure uses the Load DG IFS Tracking Entries (LODDGIFSTE) command. 8. If you will see additional prompts for Job description and Job name. At that prompts for Data group definition. 257 . tracking entries for any additional IFS objects. the request is processed. At the Submit to batch prompt. specify the value you want. if you add new or change existing data group IFS entries or object entries. data area. On a command line. 7. Configuration changes resulting from loading tracking entries are not effective until the data group is restarted. 3.Loading tracking entries Loading tracking entries Tracking entries are associated with the replication of IFS objects. do the following: 1. The Load DG IFS Tracking Entries (LODDGIFSTE) command appears. or data queue identified for replication. From the management system. Similarly. Similarly. 5. you must load tracking entries and start journaling for the objects which they identify. specify the three-part name of the data group for which you want to load IFS tracking entries. specify different values and press Enter. 6. Press Enter. IFS tracking entries identify existing IFS stream files on the source system that have been identified as eligible for replication with advanced journaling by the collection of data group IFS entries defined to a data group. specify a different value. If the data group is active. Verify that the value specified for the Load from system prompt is appropriate for your environment. type LODDGIFSTE and press F4 (Prompt). If necessary. specify a different value. 4. Note: The data group must be ended before using this procedure. When you initially configure a data group. or data queues must be loaded and journaling must be started on the objects which they identify. If you specified *NO for batch processing. If necessary. Default values for the command will load IFS tracking entries from objects on the system identified as the source for replication without duplicating existing IFS tracking entries. object tracking entries identify existing data areas and data queues on the source system that have been identified as eligible for replication using advanced journaling by the collection of data group object entries defined to a data group. 2. If necessary. use this procedure to load IFS tracking entries which match existing IFS objects. end it using the procedure “Ending a data group in a controlled manner” in the Using MIMIX book. Verify that the value specified for the Update option prompt is appropriate for your environment. data areas. data areas. A tracking entry must exist for each existing IFS object. and data queues with advanced journaling techniques. If you specified *NO for batch processing. Loading object tracking entries After you have configured the data group object entries for advanced journaling. use this procedure to load object tracking entries which match existing data areas and data queues. do the following: 1. specify the value you want. If necessary. Default values for the command will load object tracking entries from objects on the system identified as the source for replication without duplicating existing object tracking entries. If necessary. the request is processed. This procedure uses the Load DG Obj Tracking Entries (LODDGOBJTE) command. Configuration changes resulting from loading tracking entries are not effective until the data group is restarted. 7. 2. If you will see additional prompts for Job description and Job name. 6. specify the three-part name of the data group for which you want to load object tracking entries. end it using the procedure “Ending a data group in a controlled manner” in the Using MIMIX book. The Load DG Obj Tracking Entries (LODDGOBJTE) command appears. Note: The data group must be ended before using this procedure. specify different values and press Enter. Start journaling for the tracking entries when indicated by your configuration checklist. specify a different value. From the management system. Verify that the value specified for the Update option prompt is appropriate for your environment.9. Note: The command used in this procedure does not start journaling on the tracking entries. You should receive message LVI3E2B indicating the number of tracking entries loaded for the data group. You should receive message LVI3E2B indicating the number of tracking entries loaded for the data group. 4. On a command line. If the data group is active. Press Enter. type LODDGOBJTE and press F4 (Prompt). At the Submit to batch prompt. If necessary. 9. Verify that the value specified for the Load from system prompt is appropriate for your environment. 258 . 8. Note: The command used in this procedure does not start journaling on the tracking entries. 3. specify a different value. 5. Start journaling for the tracking entries when indicated by your configuration checklist. At that prompts for Data group definition. Ensure that the data group is ended. 1. Specify values for the System 1 folder and System 1 document prompts. or by creating individual DLO entries. you can specify information so that MIMIX will create the data group DLO entries for you. When you configure MIMIX. Loading DLO entries from a folder If you need to create data group DLO entries for a group of documents within a folder. see “Identifying DLOs for replication” on page 111. e. type a 21 (DLO entries) next to the data group you want and press Enter. and Object auditing value prompts. Do the following to specify the selection criteria: a. 2. Press F19 (Load). If necessary. Note: The MIMIXOWN user profile is automatically added to the system directory when MIMIX is installed. (You can customize individual entries later. you can tailor them to meet your requirements. 6. System 2 folder.) The user profile you use to perform this task must be enrolled in the system distribution directory on the management system. specify a value for the Object retrieval delay prompt. Additional prompts appear to optionally use batch processing and to load entries without load without selecting entries from a list. If necessary. type a 1 (Work with data groups) and press Enter. specify whether resulting data group DLO entries should include or exclude the identified documents d. System 2 object. b. Either type a 1 (Select) next to the documents you want or 259 . The Work with DG DLO Entries display appears. 4.Creating data group DLO entries Creating data group DLO entries Data group DLO entries identify document library objects (DLOs) for replication by MIMIX system journal replication processes. Press Enter. The Load DG DLO Entries (LODDGDLOE) display appears. do the following to create DLO entries by loading from a list. From the MIMIX Intermediate Main Menu. For detailed concepts and requirements. Press Enter. c. if necessary. 3. The Load DG DLO Entries display appears with the list of document that matched your selection criteria. Identify the documents to be considered. At the Process type prompt. This entry is required for DLO replication and should not be removed. specify values for the Owner. From the Work with Data Groups display. Once you have created the DLO entries. you can create data group DLO entries by loading from a generic entry and selecting from documents in the list. From the management system. 5. Identify the library and objects to be considered. At the Process type prompt. The Work with DG DLO Entries display appears. Synchronize the DLOs identified by data group entries before starting replication processes or running MIMIX audits. type a 1 (Add) next to the blank line at the top of the list and press Enter. The entries will be available to MIMIX audits the next time an audit runs. 6. 5. This includes after the nightly restart of MIMIX jobs. 4. If necessary. specify a value for the Object retrieval delay prompt. If necessary. System 2 object. b. System 2 folder. Synchronize the DLOs identified by data group entries before starting replication processes or running MIMIX audits. do the following to add or change a DLO entry: 1. 7. type a 21 (DLO entries) next to the data group you want and press Enter. This includes after the nightly restart of MIMIX jobs. If you are adding a new DLO entry. Press Enter. To change an existing entry. type a 1 (Work with data groups) and press Enter. Then press Enter. 2. the Add Data Group DLO Entry display appears. From the MIMIX Intermediate Main Menu. Adding or changing a data group DLO entry The data group must be ended and restarted before any changes can become effective. Specify values for the System 1 folder and System 1 document prompts. type a 2 (Change) next to the entry you want and press Enter. Then skip to Step 5. Do one of the following: • • To add a new entry. If necessary. and Object auditing value prompts. Do the following: a. The entries will be available to replication processes after the data group is ended and restarted. you can use “Adding or changing a data group DLO entry” on page 260 to customize values for any of the data group DLO entries. specify whether resulting data group DLO entries should include or exclude the identified documents c. 260 . specify values for the Owner. From the Work with Data Groups display. 3. From the management system. The entries will be available to MIMIX audits the next time an audit runs.press F21 (Select all). The entries will be available to replication processes after the data group is ended and restarted. The preferred method of replicating data areas is with user journal replication processes using advanced journaling. The Load DG Data Area Entries (LODDGDAE) display appears. The data area entries can be created from libraries on either system. The next best method is identifying them with data group object entries for system journal replication processes. you can tailor them to meet your requirements by adding. changing. Verify that the remaining prompts on the display contain the values you want. 6. or deleting entries. change the values. do the following to load data area entries for use with the data area poller: 1. A completion message is sent when the load has 261 . 3. The Work with DG Data Area Entries display appears. To create the data group data area entries. Press F19 (Load). The values of the System 1 library and System 2 library prompts indicate the name of the library on the respective systems. type a 19 (Data area entries) next to the data group you want and press Enter. If necessary. type a 1 (Work with data groups) and press Enter. From the management system. Loading data area entries for a library Before any addition or change is recognized. 5. From the Work with Data Groups display. From the MIMIX Intermediate Main Menu. Ensure that the value of the Load from system prompt indicates the system from which you want to load data areas. Note: The data area poller method is not the preferred way to replicate data areas. 2. If the system manager is configured and running. Once the data group data area entries are created. You must define data group data area entries from the management system. For detailed concepts and requirements for supported configurations. all created and changed data group data area entries are sent to the network systems automatically.Creating data group data area entries Creating data group data area entries This procedure creates data group data area entries that identify data areas to be replicated by the data area poller process. see the following topics: • • “Identifying library-based objects for replication” on page 91 “Identifying data areas and data queues for replication” on page 103 You can load all data group data area entries from a library or you can add individual data area entries. 4. you need to end and restart the data group. If you submitted the job for batch processing. 7. press Enter. MIMIX sends a message indicating that a data areas load job has been submitted. Specify a name for the System 1 library prompt and verify that the value shown for the System 2 library prompt is what you want. type a 19 (Data area entries) next to the data group you want and press Enter.finished. From the Work with DG Data Area Entries display do one of the following • • To add a new data area entry. 262 . 2. To change an existing data area entry. 5. From the MIMIX Intermediate Main Menu. 4. 3. type a 2 (Change) next to the data group data area entry you want and press Enter. Specify the values you want at the prompts for System 1 data area and Library and System 2 data area and Library. The Change Data Group Data Area Entry display appears. From the management system. The Add Data Group Data Area Entry display appears. From the Work with Data Groups display. Adding or changing a data group data area entry Before any addition or change is recognized. do the following to add a new entry or change an existing data area entry for use with the data area poller: 1. you need to end and restart the data group. type a 1 (Add) at the blank line at the top of the list and press Enter. Press Enter to create the data area entry or accept the change. type a 1 (Work with data groups) and press Enter. provide: 263 . To File 1 To Member To File 2 To system 1 data area To system 2 data area System 1 library System 1 object Object type Attribute System 1 folder System 1 document Owner For file entries. such as copying. are very similar for all types of data group entries used by MIMIX. and displaying. provide: For data area entries. The values of these prompts define the data to be replicated by the definition to which you are copying. Specify a name for the To definition prompt. provide: For object entries. Ensure that the prompts identify the necessary information.Additional options: working with DG entries Additional options: working with DG entries The procedures for performing common functions. The "Work with" display for the entry you selected appears. do the following: 1. Additional prompts appear on display that are specific for the type of entry. Values to specify for each type of data group entry. Type a 3 (Copy) next to the entry you want and press Enter. From the Work with DG Definitions display. Any of these options will allow an entry to be copied: Option 17 (File entries) Option 19 (Data area entries) Option 20 (Object entries) Option 21 (DLO entries) Option 22 (IFS entries) 2. 4. 3. Copying a data group entry Use this procedure from the management system to copy a data group entry from one data group definition to another data group definition. Table 30. removing. type the option you want next to the data group from which you are copying and press Enter. provide: For DLO entries. Each generic procedure in this topic indicates the type of data group entry for which it can be used. The data group definition to which you are copying must exist. The Copy display for the entry appears. To copy a data group entry to another data group definition. it is best to use *YES. provide: 5. If you specify Dynamically update (*YES). do the following: 1. The change is recognized as soon as each active process receives the update. you do not need to end the processes for the data group when you use the default. When you specify Dynamically update (*NO). To system 1 object For IFS entries. Any of these options will allow an entry to be removed: Option 17 (File entries) Option 19 (Data area entries) Option 20 (Object entries) Option 21 (DLO entries) Option 22 (IFS entries) 2. receive.Table 30. This forces all currently held entries to be deleted. the remove function does not clean up any records in the error/hold log. Values to specify for each type of data group entry. and apply processes for the associated data group and ended and restarted. The "Work with" display for the entry you selected appears. type the option for the entry you want next to the data group and press Enter. Type a 4 (Remove) next to the entry you want and press Enter. specify *YES. all current entries to be ignored. Note: For all data group entries except file entries. Removing a data group entry Use this procedure from the management system to remove a data group entry from a data group definition. Data group file entries support dynamic removals if you prompt the RMVDGFE command and specify Dynamically update (*YES). 7. To copy the entry. and prevents additional entries from accumulating. If an entry is held when you delete it. If you want to replace an existing entry. If a file is on hold and you want to delete the data group file entry. press Enter. 264 . its information remains in the error/hold log. From the Work with DG Definitions display. the change is not recognized until after the send. Additional transactions for the file or member can be accumulating in the error/hold log or will be applied to the file. and apply processes for the associated data group are ended and restarted. end and restart the data group being copied. 6. the change is not recognized until after the send receive. For file entries. You may want to remove an entry when you no longer need to replicate the information that the entry identifies. To remove an entry. The value *NO for the Replace definition prompt prevents you from replacing an existing entry in the definition to which you are copying. If you accept the default of Dynamically update (*NO). Additional options: working with DG entries 3. 4. Page Down to see all of the values. Printing a data group entry Use this procedure to create a spooled file which you can print that identifies a system definition. type the option for the entry you want next to the data group and press Enter. Type a 6 (Print) next to the entry you want and press Enter. From the Work with DG Definitions display. press Enter. Displaying a data group entry Use this procedure to display a data group entry for a data group definition. A spooled file is created with a name of MXDG***E. From the Work with DG Definitions display. Specify the values you want and press Enter. For data group file entries. where *** is the type of entry. The appropriate data group entry display appears. You can print the spooled file according to your standard print procedures. 3. The "Work with" display for the entry you selected appears. To display a data group entry. type the option for the entry you want next to the data group and press Enter. transfer definition. journal definition. 265 . The "Work with" display for the entry you selected appears. A confirmation display appears with a list of entries to be deleted. do the following. Any of these options will allow an entry to be printed: Option 17 (File entries) Option 19 (Data area entries) Option 22 (IFS entries) 2. 1. a display with additional prompts appears. do the following: 1. To delete the entries. or a data group definition. 3. Not all types of entries support the print function. Type a 5 (Display) next to the entry you want and press Enter. Any of these options will allow an entry to be displayed: Option 17 (File entries) Option 19 (Data area entries) Option 20 (Object entries) Option 21 (DLO entries) Option 22 (IFS entries) 2. To print a data group entry. see “Interpreting results for configuration data . This topic describes the processing resulting from combinations of values specified for the • • • • • 266 . • • • “Changes to startup programs” on page 278 describes changes that you may need to make to your configuration to support remote journaling. “Checking file entry configuration manually” on page 276 provides a procedure using the CHKDGFE command to check the data group file entries defined to a data group. Always use the configuration checklists to guide you though the steps of standard configuration scenarios.#DGFE audit” on page 546.Additional supporting tasks for configuration CHAPTER 13 Additional supporting tasks for configuration The tasks in this chapter provide supplemental configuration tasks. “Using file identifiers (FIDs) for IFS objects” on page 284 describes the use of FID parameters on commands for IFS tracking entries. When IFS objects are configured for replication through the user journal. • • “Accessing the Configuration Menu” on page 268 describes how to access the menu of configuration options from a 5250 emulator. For additional information. “Starting data groups for the first time” on page 282 describes how to start replication once configuration is complete and the systems are synchronized. This topic also describes options for ensuring that systems in a MIMIX configuration have the same password and the implications of these options. Use this only when directed to by a configuration checklist. which calls the CHKDGFE command and can automatically correct detected problems. “Setting data group auditing values manually” on page 270 describes when to manually set the object auditing level for objects defined to MIMIX and provides a procedure for doing so. “Starting the system and journal managers” on page 269 provides procedures for starting these jobs. System and journal manager jobs must be running before replication can be started. Note: The preferred method of checking is to use MIMIX AutoGuard to automatically schedule the #DGFE audit. commands that support IFS tracking entries can specify a unique FID for the object on each system. “Identifying data groups that use an RJ link” on page 283 describes how to determine which data groups use a particular RJ link. “Starting the DDM TCP/IP server” on page 279 describes how to start this server that is required in configurations that use remote journaling. “Checking DDM password validation level in use” on page 280 describes how to check the whether the DDM communications infrastructure used by MIMIX Remote Journal support requires a password. MIMIX jobs restart daily to ensure that the MIMIX environment remains operational. 267 . • “Configuring restart times for MIMIX jobs” on page 285 describes how to change the time at which MIMIX jobs automatically restart.object and FID prompts. do the following: 1.Accessing the Configuration Menu The MIMIX Configuration Menu provides access to the options you need for configuring MIMIX. Access the MIMIX Basic Main Menu. 2. 268 . See “Accessing the MIMIX Main Menu” on page 84. select option 11 (Configuration menu) and press Enter. To access the MIMIX Configuration Menu. From the on the MIMIX Basic Main Menu. Press Enter to complete this request. Type a 9 (Start) next to each of the system definitions you want and press Enter. Do the following: a. The Work with Systems display appears with a list of the system definitions. journal managers. 5. cluster services. b. they will automatically send configuration information to the network system as you complete configuration tasks.Starting the system and journal managers Starting the system and journal managers If the system managers are running. journal managers. Repeat Step 5 for each system definition that you selected. and. To start all of the system managers. This will start all managers on all of these systems in the MIMIX environment. 2. From the MIMIX Basic Main Menu press the F21 key (Assistance level) to access the MIMIX Intermediate Main Menu. Verify that *ALL appears as the value for the Manager prompt. do the following: 1. The Start MIMIX Managers (STRMMXMGR) display appears. and cluster services must be active to start replication. and cluster services (for a cluster environment) during configuration. 269 . 3. 4. If you selected more than one system definition in Step 4. Select option 2 (Work with Systems) and press Enter. This procedure starts all the system managers. journal managers. if the system is participating in a cluster. The system managers. the Start MIMIX Managers (STRMMXMGR) display will be shown for each system definition that you selected. 6. See “Accessing the MIMIX Main Menu” on page 84. Access the MIMIX Basic Main Menu. Doing so will ensure that replicated objects will be properly audited and that any transactions for the objects that occur between configuration and starting the data group will be replicated. do the following on each system defined to the data group: 1. you can optionally force a change to a configured value that is lower than the existing value through the command’s Force audit value (FORCE) parameter. data group DLO entries. MIMIX does not change the value. Processing options .If you anticipate a delay between configuring data group entries and starting the data group. Specify the name of the data group you want. For more information see “Examples of changing of an IFS object’s auditing value” on page 271. The object auditing level of an existing object is set to the auditing value specified in the data group entry that most specifically matches the object. For example.MIMIX checks for existing objects identified by data group entries for the specified data group. you can use the Set Data Group Auditing (SETDGAUD) command. 270 . To manually set the system auditing level of replicated objects.Setting data group auditing values manually Default behavior for MIMIX is to change the auditing value of IFS. MIMIX will change the auditing value even if it is lower than the existing value. The Set Data Group Auditing (SETDGAUD) appears. • For IFS objects. DLO. or to force a change to a lower configured level. Default behavior is that MIMIX only changes an object’s auditing value if the configured value is higher than the object’s existing value. You can also use the SETDGAUD command to reset the object auditing level for all replicated objects if a user has changed the auditing level of one or more objects to a value other than what is specified in the data group entries. it is particularly important that you understand the ramifications of the value specified for the FORCE parameter. • The default value *NO for the FORCE parameter prevents MIMIX from reducing the auditing level of an object. If you specify *YES for the FORCE parameter. and librarybased objects configured for system journal replication as needed when starting data groups with the Start Data Group (STRDG) command. Procedure -To set the object auditing value for a data group. if the SETDGAUD command processes a data group entry with a configured object auditing value of *CHANGE and finds an object identified by that entry with an existing auditing value of *ALL. and data group IFS entries. you should use the SETDGAUD command before synchronizing data between systems. When to set object auditing values manually . The SETDGAUD command can be used for data groups configured for replicating object information (type *OBJ or *ALL). However. The SETDGAUD command allows you to set the object auditing level for all existing objects that are defined to MIMIX by data group object entries. 2. Type the command SETDGAUD and press F4 (Prompt). Examples of changing of an IFS object’s auditing value The following examples show the effect of the value of the FORCE parameter when manually changing the object auditing values of IFS objects configured for system journal replication. The auditing values resulting from the SETDGAUD command can be confusing when your environment has multiple data group IFS entries. 4. Because the change is to a lower auditing level. Table 31. Similarly. 5. At the Object type prompt. each with different auditing levels. Note: This may affect the operation of your replicated applications. If you want to allow MIMIX to force a change to a configured value that is lower than the object’s existing value. The following examples illustrate how these conditions affect the results of setting object auditing for IFS objects. Example 1: This scenario shows a simple implementation where data group IFS entries have been modified to have a configured value of *CHANGE from a previously configured value of *ALL. specify *YES for the Force audit value prompt. the change must be forced with the SETDGAUD command. The entries are listed in the order in which they are processed by the SETDGAUD command. IFS entries are processed using the unicode character set. running the SETDGAUD command with FORCE(*NO) does not change the auditing values for this scenario. all descendents of the IFS object may also have their auditing value changed. and more than one entry references objects sharing common parent directories. We recommend that you force auditing value changes only when you have specified *ALLIFS for the Object type. When MIMIX processes a data group IFS entry and changes the auditing level of objects which match the entry. In the case of an IFS entry with a generic name.Setting data group auditing values manually 3. Example 1 configuration of data group IFS entries Specified object /DIR1/* /DIR1/DIR2/* /DIR1/STMF Object auditing value OBJAUD(*CHANGE) OBJAUD(*CHANGE) OBJAUD(*CHANGE) Process type PRCTYPE(*EXCLD) PRCTYPE(*INCLD) PRCTYPE(*INCLD) Order processed 1 2 3 Simply ending and restarting the data group will not cause these configuration changes to be effective. 271 . Data group entries are processed in order from most generic to most specific. if necessary. changed to the new auditing value. Press Enter. The first entry (more generic) found that matches the object is used until a more specific match is found. specify the type of objects for which you want to set auditing values. all of the directories in the object’s directory path are checked and. Table 31 identifies a set of data group IFS entries and their configured auditing values. In this scenario there are multiple configured values. Running the command with FORCE(*YES) does change the existing objects’ values. Example 2: Table 33 identifies a set of data group IFS entries and their configured auditing values. Example 2 configuration of data group IFS entries Specified object /DIR1/* /DIR1/DIR2/* /DIR1/STMF Object auditing value OBJAUD(*CHANGE) OBJAUD(*NONE) OBJAUD(*ALL) Process type PRCTYPE(*INCLD) PRCTYPE(*INCLD) PRCTYPE(*INCLD) Order processed 1 2 3 For this scenario. Table 33. Intermediate audit values which occur during FORCE(*YES) processing for example 1. The entries are listed in the order in which they are processed by the SETDGAUD command. running the SETDGAUD command with FORCE(*NO) does not change the auditing values on any existing IFS objects because the configured values from the data group IFS entries are the same or lower than the existing values. object auditing processing does not apply. The existing value is the same as the configured value of the third entry at the time it is processed. This object’s auditing value is evaluated when the third data group IFS entry is processed but the entry does not cause the value to change. Data group IFS entry #3 in Table 33 272 .Table 32 shows the intermediate and final results as each data group IFS entry is processed by the force request. Because the first data group IFS entry excludes objects from replication. 2. Table 34 shows the intermediate values as each entry is processed by the force request and the final results of the change. Existing value Auditing values while processing SETDGAUD FORCE(*YES) Changed by 1st entry Note 1 Note 1 Note 1 Note 1 Note 1 *CHANGE *CHANGE Changed by 2nd entry *CHANGE Changed by 3rd entry Note 2 *CHANGE Final results of FORCE(*YES) *CHANGE *CHANGE *ALL *CHANGE *CHANGE Existing objects /DIR1 /DIR1/STMF /DIR1/STMF2 /DIR1/DIR2 /DIR1/DIR2/STMF *ALL *ALL *ALL *ALL *ALL Notes: 1. Table 32. In this scenario. Intermediate audit values which occur during FORCE(*YES) processing for example 3. Intermediate audit values which occur during FORCE(*YES) processing for example 2. Existing value Auditing values while processing SETDGAUD FORCE(*YES) Changed by 1st entry *CHANGE *CHANGE *CHANGE *CHANGE *CHANGE *NONE *NONE Changed by 2nd entry *NONE Changed by 3rd entry *ALL *ALL Final results of FORCE(*YES) *ALL *ALL *CHANGE *NONE *NONE Existing objects /DIR1 /DIR1/STMF /DIR1/STMF2 /DIR1/DIR2 /DIR1/DIR2/STMF *ALL *ALL *ALL *ALL *ALL Example 3: This scenario illustrates why you may need to force the configured values to take effect after changing the existing data group IFS entries from *ALL to lower values. running the SETDGAUD command with FORCE(*NO) does not change the auditing values on any existing IFS objects because the configured values from the data group IFS entries are lower than the existing values. Table 36. Table 36 shows the intermediate values as each entry is processed by the force request and the final results of the change. Table 35 identifies a set of data group IFS entries and their configured auditing values. Table 35. SETDGAUD FORCE(*YES) must be run to have the configured auditing values take effect. Table 34. The entries are listed in the order in which they are processed by the SETDGAUD command. Example 3: configuration of data group IFS entries Specified object /DIR1/* /DIR1/DIR2/* /DIR1/STMF Object auditing value OBJAUD(*CHANGE) OBJAUD(*NONE) OBJAUD(*NONE) Process type PRCTYPE(*INCLD) PRCTYPE(*INCLD) PRCTYPE(*INCLD) Order processed 1 2 3 For this scenario.Setting data group auditing values manually prevents directory /DIR1 from having an auditing value of *CHANGE or *NONE because it is the last entry processed and it is the most specific entry. Existing value Auditing values while processing SETDGAUD FORCE(*YES) Changed by 1st entry *CHANGE *CHANGE *CHANGE Changed by 2nd entry *NONE *NONE Changed by 3rd entry Final results of FORCE(*YES) *NONE *NONE *CHANGE Existing objects /DIR1 /DIR1/STMF /DIR1/STMF2 *ALL *ALL *ALL 273 . 274 . This scenario is quite possible as a result of a normal STRDG request. which may be undesirable. Existing value Auditing values while processing SETDGAUD FORCE(*YES) Changed by 1st entry *CHANGE *CHANGE Changed by 2nd entry *NONE *NONE Changed by 3rd entry Final results of FORCE(*YES) *NONE *NONE Existing objects /DIR1/DIR2 /DIR1/DIR2/STMF *ALL *ALL Example 4: This example begins with the same set of data group IFS entries used in example 3 (Table 35) and uses the results of the forced change in example 3 as the auditing values for the existing objects in Table 37.Table 36. Complex data group IFS entries and multiple configured values cause these potentially undesirable results. the objects’ auditing values will be set to those shown in Table 37 for FORCE(*NO). we recommend that you configure a consistent auditing value of *CHANGE across data group IFS entries which identify objects with common parent directories. Example 4: comparison of object’s actual values Auditing value Existing values /DIR1 /DIR1/STMF /DIR1/STMF2 /DIR1/DIR2 /DIR1/DIR2/STMF *NONE *NONE *CHANGE *NONE *NONE After SETDGAUD FORCE(*NO) *CHANGE *CHANGE *CHANGE *CHANGE *CHANGE After SETDGAUD FORCE(*YES) *NONE *NONE *CHANGE *NONE *NONE Existing objects There is no way to maintain the existing values in Table 37 without ensuring that a forced change occurs every time SETDGAUD is run. Table 37. Any addition or change to the data group IFS entries can potentially cause similar results the next time the data group is started. the next time data groups are started. Note: Any addition or change to the data group IFS entries can cause these results to occur. Intermediate audit values which occur during FORCE(*YES) processing for example 3. To avoid this situation. Table 37 shows how running the SETDGAUD command with FORCE(*NO) causes changes to auditing values. In this example. The value *USRPRF is not in the range of valid values for MIMIX. Example 5: comparison of object’s actual values Auditing value Existing values /DIR1/STMF *USRPRF After SETDGAUD FORCE(*NO) *USRPRF After SETDGAUD FORCE(*YES) *NONE Existing objects 275 . Therefore. Table 38 shows the configured data group IFS entry. Table 39. Running the command with FORCE(*YES) does force a change because the existing value and the configured value are not equal. Example 5 configuration of data group IFS entries Specified Object /DIR1/STMF Object auditing value OBJAUD(*NONE) Process type PRCTYPE(*INCLD) Order processed 1 Table 39 compares the results running the SETDGAUD command with FORCE(*NO) and FORCE(*YES).Setting data group auditing values manually Example 5: This scenario illustrates the results of SETDGAUD command when the object’s auditing value is determined by the user profile which accesses the object (value *USRPRF). Running the command with FORCE(*NO) does not change the value. an object with an auditing value of *USRPRF is not considered for change. Table 38. Checking file entry configuration manually The Check DG File Entries (CHKDGFE) command provides a means to detect whether the correct data group file entries exist with respect to the data group object entries configured for a specified data group in your MIMIX configuration. When file entries and object entries are not properly matched, your replication results can be affected. Note: The preferred method of checking is to use MIMIX AutoGuard to automatically schedule the #DGFE audit, which calls the CHKDGFE command and can automatically correct detected problems. For additional information, see “Interpreting results for configuration data - #DGFE audit” on page 546. To check your file entry configuration manually, do the following: 1. On a command line, type CHKDGFE and press Enter. The Check Data Group File Entries (CHKDGFE) command appears. 2. At the Data group definition prompts, select *ALL to check all data groups or specify the three-part name of the data group. 3. At the Options prompt, you can specify that the command be run with special options. The default, *NONE, uses no special options. If you do not want an error to be reported if a file specified in a data group file entry does not exist, specify *NOFILECHK. 4. At the Output prompt, specify where the output from the command should be sent—to print, to an outfile, or to both. See Step 6. 5. At the User data prompt, you can assign your own 10-character name to the spooled file or choose not to assign a name to the spooled file. The default, *CMD, uses the CHKDGFE command name to identify the spooled file. 6. At the File to receive output prompts, you can direct the output of the command to the name and library of a specific database file. If the database file does not exist, it will be created in the specified library with the name MXCDGFE. 7. At the Output member options prompts, you can direct the output of the command to the name of a specific database file member. You can also specify how to handle new records if the member already exists. Do the following: a. At the Member to receive output prompt, accept the default *FIRST to direct the output to the first member in the file. If it does not exist, a new member is created with the name of the file specified in Step 6. Otherwise, specify a member name. b. At the Replace or add records prompt, accept the default *REPLACE if you want to clear the existing records in the file member before adding new records. To add new records to the end of existing records in the file member, specify *ADD. 8. At the Submit to batch prompt, do one of the following: • If you do not want to submit the job for batch processing, specify *NO and press Enter to check data group file entries. 276 Checking file entry configuration manually • To submit the job for batch processing, accept *YES. Press Enter and continue with the next step. 9. At the Job description prompts, specify the name and library of the job description used to submit the batch request. Accept MXAUDIT to submit the request using the default job description, MXAUDIT. 10. At the Job name prompt, accept *CMD to use the command name to identify the job or specify a simple name. 11. To start the data group file entry check, press Enter. 277 Changes to startup programs If you use startup programs, ensure that you include the following operations when you configure for remote journaling: • • If you use TCP/IP as the communications protocol you need to start TCP/IP, including the DDM server, before starting replication. If you use OptiConnect as the communications protocol, the QSOC subsystem must be active. 278 Starting the DDM TCP/IP server Starting the DDM TCP/IP server Use this procedure if you need to start the DDM TCP/IP server in an environment configured for MIMIX RJ support. From the system on which you want to start the TCP server, do the following: 1. Ensure that the DDM TCP/IP attributes allow the DDM server to be automatically started when the TCP/IP server is started (STRTCP). Do the following: a. Type the command CHGDDMTCPA and press F4 (Prompt). b. Check the value of the Autostart server prompt. If the value is *YES, it is set appropriately. Otherwise, change the value to *YES and press Enter. 2. To prevent install problems due to locks on the library name, ensure that the MIMIX product library is not in your user library list. 3. To start the DDM server, type the command STRTCPSVR(*DDM) and press Enter. Verifying that the DDM TCP/IP server is running Do the following: 1. Enter the command NETSTAT OPTION(*CNN) 2. The Work with TCP/IP Connection Status appears. Look for these servers in the Local Port column: • • ddm ddm-ssl 3. These servers should exist and should have a vale of Listen in the State column. 279 Checking DDM password validation level in use MIMIX Remote Journal support uses the DDM communications infrastructure. This infrastructure can be configured to require a password to be provided when a server connection is made. The MIMIXOWN user profile, which establishes the remote journal connection, ships with a preset password so that it is consistent on all systems. If you have implemented DDM password validation on any systems where MIMIX will be used, you should verify the DDM level in use. If the MIMIXOWN password is not the same on both systems, you may need to change the MIMIXOWN user profile or the DDM security level to allow MIMIX Remote Journal support to function properly. These changes have security implications of which you should be aware. To check the DDM password validation level in use, do the following on both systems: 1. From a command line, type CHGDDMTCPA and press F4 (prompt). 2. Check the value of the Password required field. • • If the value is *NO or *VLDONLY, no further action is required. Press F12 (Cancel). If the field contains any other value, you must take further action to enable MIMIX RJ support to function in your environment. Press F12, then continue with the next step. 3. You have two options for changing your environment to enable MIMIX RJ support to function. Each option has security implications. You must decide which option is best for your environment. The options are: • “Option 1. Enable MIMIXOWN user profile for DDM environment” on page 280. MIMIX must be installed and transfer definitions must exist before you can make the necessary changes. For new installations this should automatically configured for you. “Option 2. Allow user profiles without passwords” on page 281. You can use this option before or after MIMIX is installed. However, this option should be performed before configuring MIMIX RJ support. • Option 1. Enable MIMIXOWN user profile for DDM environment This option changes the MIMIXOWN user profile to have a password and adds server authentication entries to recognize the MIMIXOWN user profile. Do the following from both systems: 1. Access the Work with Transfer Definitions (WRKTFRDFN) display. Then do the following: a. Type a 5 (Display) next to each transfer definition that will be used with MIMIX RJ support and press Enter. b. Page down to locate the value for Relational database (RDB parameter) and record the value indicated. 280 Checking DDM password validation level in use c. If you selected multiple transfer definitions, press Enter to advance to the next selection and record its RDB value. Ensure that you record the values for all transfer definitions you selected. Note: If the RDB value was generated by MIMIX, it will be in the form of the characters MX followed by the System1 definition, System2 definition, and the name of the transfer definition, with up to 18 characters. 2. On the source system, change the MIMIXOWN user profile to have a password and to prevent signing on with the profile. To do this, enter the following command: CHGUSRPRF USRPRF(MIMIXOWN) PASSWORD(user-defined-password) INLMNU(*SIGNOFF) Note: The password is case sensitive and must be the same on all systems in the MIMIX network. If the password does not match on all systems, some MIMIX functions will fail with security error message LVE0127. 3. Verify that the QRETSVRSEC (Retain server security data) system value is set to 1. The value 1 allows the password you specify in the server authentication entry in Step 4 to take effect. DSPSYSVAL SYSVAL(QRETSVRSEC) If necessary, change the system value. 4. You need a server authentication entry for the MIMIXOWN user profile for each RDB entry you recorded in Step 1. To add a server authentication entry, type the following command, using the password you specified in Step 2 and the RDB value from Step 1. Then press Enter. ADDSVRAUTE USRPRF(MIMIXOWN) SERVER(recorded-RDB-value) PASSWORD(user-defined-password) 5. Repeat Step 2 through Step 4 on the target system. Option 2. Allow user profiles without passwords This option changes DDM TCP attributes to allow user profiles without passwords to function in environments that use DDM password validation. Do the following: 1. From a command line on the source system, type CHGDDMTCPA PWDRQD(*VLDONLY) and press Enter. 2. From a command line on the target system, CHGDDMTCPA PWDRQD(*VLDONLY) and press Enter. 281 Starting data groups for the first time Use this procedure when a configuration checklist directs you to start a newly configured data group for the first time. You should have identified the starting point in the journals with “Establish a synchronization point” on page 442 when you synchronized the systems. 1. From the Work with Data Groups display, type a 9 (Start DG) next to the data group that you want to start and press Enter. 2. The Start Data Group (STRDG) display appears. Press Enter to access additional prompts. Do the following: a. Specify the starting point for user journal journal replication. For the Database journal receiver and Database large sequence number prompts specify the information you recorded in Step 5 of “Establish a synchronization point” on page 442. b. Specify the starting point for system journal journal replication. For the Object journal receiver and Object large sequence number prompts specify the information you recorded in Step 6 of “Establish a synchronization point” on page 442. c. Specify *YES for the Clear pending prompt. 3. Press Enter. 4. A confirmation display appears. Press Enter. 5. A second confirmation display appears. Press Enter to start the data group. 282 Identifying data groups that use an RJ link Identifying data groups that use an RJ link Use this procedure to determine which data groups use a remote journal link before you end a remote journal link or remove a remote journaling environment. 1. Enter the command WRKRJLNK and press Enter. 2. Make a note of the name indicated in the Source Jrn Def column for the RJ Link you want. 3. From the command line, type WRKDGDFN and press Enter. 4. For all data groups listed on the Work with DG Definitions display, check the Journal Definition column for the name of the source journal definition you recorded in Step 2. • If you do not find the name from Step 2, the RJ link is not used by any data group. The RJ link can be safely ended or can have its remote journaling environment removed without affecting existing data groups. If you find the name from Step 2 associated with any data groups, those data groups may be adversely affected if you end the RJ link. A request to remove the remote journaling environment removes configuration elements and system objects that need to be created again before the data group can be used. Continue with the next step. • 5. Press F10 (View RJ links). Consider the following and contact your MIMIX administrator before taking action that will end the RJ link or remove the remote journaling environment. • When *NO appears in the Use RJ Link column, the data group will not be affected by a request to end the RJ link or to end the remote journaling environment. Note: If you allow applications other than MIMIX to use the RJ link, they will be affected if you end the RJ link or remove the remote journaling environment. • When *YES appears in the Use RJ Link column, the data group may be affected by a request to end the RJ link. If you use the procedure for ending a remote journal link independently in the Using MIMIX book, ensure that any data groups that use the RJ link are inactive before ending the RJ link. 283 Using file identifiers (FIDs) for IFS objects Commands used for user journal replication of IFS objects use file identifiers (FIDs) to uniquely identify the correct IFS tracking entries to process. The System 1 file identifier and System 2 file identifier prompts ensure that IFS tracking entries are accurately identified during processing. These prompts can be used alone or in combination with the System 1 object prompt. These prompts enable the following combinations: • Processing by object path: A value is specified for the System 1 object prompt and no value is specified for the System 1 file identifier or System 2 file identifier prompts. When processing by object path, a tracking entry is required for all commands with the exception of the SYNCIFS command. If no tracking entry exists, the command cannot continue processing. If a tracking entry exists, a query is performed using the specified object path name. • Processing by object path and FIDs: A value is specified for the System 1 object prompt and a value is specified for either or both of the System 1 file identifier or System 2 file identifier prompts. When processing by object path and FIDs, a tracking entry is required for all commands. If no tracking entry exists, the command cannot continue processing. If a tracking entry exists, a query is performed using the specified FID values. If the specified object path name does not match the object path name in the tracking entry, the command cannot continue processing. • Processing by FIDs: A value is specified for either or both of the System 1 file identifier or System 2 file identifier prompts and, with the exception of the SYNCIFS command, no value is specified for the System 1 object prompt. In the case of SYNCIFS, the default value *ALL is specified for the System 1 object prompt. When processing by FIDs, a tracking entry is required for all commands. If no tracking entry exists, the command cannot continue processing. If a tracking entry exists, a query is performed using the specified FID values. 284 Configuring restart times for MIMIX jobs Configuring restart times for MIMIX jobs Certain MIMIX jobs are restarted, or recycled, on a regular basis in order to maintain the MIMIX environment. The ability to configure this activity can ease conflicts with your scheduled workload by changing when the MIMIX jobs restart to a more convenient time for your environment. The default operation of MIMIX is to restart MIMIX jobs at midnight (12:00 a.m.). However, you can change the restart time by setting a different value for the Job restart time parameter (RSTARTTIME) on system definitions and data group definitions. The time is based on a 24 hour clock. The values specified in the system definitions and data group definitions are retrieved at the time the MIMIX jobs are started. Changes to the specified values have no effect on jobs that are currently running. Changes are effective the next time the affected MIMIX jobs are started. For a data group definition you can also specify either *SYSDFN1 or the *SYSDFN2 for the Job restart time (RSTARTTIME) parameter. Respectively, these values use the restart time specified in the system definition identified as System 1 or System 2 for the data group. Both system and data group definition commands support the special value *NONE, which prevents the MIMIX jobs from automatically restarting. Be sure to read “Considerations for using *NONE” on page 287 before using this value. Configurable job restart time operation To make effective use of the configurable job restart time, you may need to set the job restart time in as few as one or as many as all of these locations: • • • One or more data group definitions The system definition for the management system The system definitions for one or more network systems. MIMIX system-level jobs affected by the Job restart time value specified in a system definition are: system manager (SYSMGR), system manager receive (SYSMGRRCV), and journal manager (JRNMGR). MIMIX data group-level jobs affected by the Job restart time value specified in a data group definition are: object send (OBJSND), object receive (OBJRCV), database send (DBSND), database receive (DBRCV), database reader (DBRDR), object retrieve (OBJRTV), container send (CNRSND), container receive (CNRRCV), status send (STSSND), status receive (STSRCV), and object apply (OBJAPY). Also, the role of the system on which you change the restart time affects the results. For system definitions, the value you specify for the restart time and the role of the system (management or network) determines which MIMIX system-level jobs will restart and when. For data group definitions, the value you specify for the restart time and the role of the system (source or target) determines which data group-level jobs will restart and when. Time zone differences between systems also influence the results you obtain. MIMIX system-level jobs restart when they detect that the time specified in the system definition has passed. 285 The system manager jobs are a pair of jobs that run between a network system and the management system. The management and network systems both have journal manager jobs, but the jobs operate independently. The job restart time specified in the management system’s system definition determines when to restart the journal manager on the management system. The job restart time specified in the network system’s system definition determines when to restart the journal manager job on the network system, when to restart the system manager jobs on both systems, and also affects when cleanup jobs on both systems are submitted. Table 40 shows how the role of the system affects the results of the specified job restart time. Table 40. System Definition Role Management System Effect of the system’s role on changing the job restart time in a system definition. Effect on Jobs by the value specified Jobs System managers Cleanup jobs Journal managers Collector services Network System System managers Time *NONE Specified value is not used to determine restart time. Restart is determined by value specified for network system. Job on management system restarts at time specified. Jobs on both systems restart when time on the management system reaches the time specified. Jobs are submitted on both systems by system manager jobs after they restart. Job on network system restarts at time specified. Job on management system is not restarted. Jobs are not restarted on either system. Cleanup jobs Jobs are submitted on both systems when midnight occurs on the management system. Job on network system is not restarted. Journal managers Collector services For MIMIX data group-level jobs, a delay of 2 to 35 minutes from the specified time is built into the job restart processing. The actual delay is unique to each job. By distributing the jobs within this range the load on systems and communications is more evenly distributed, reducing bottlenecks caused by many jobs simultaneously attempting to end, start, and establish communications. MIMIX determines the actual restart time for the object apply (OBJAPY) jobs based on the timestamp of the system on which the jobs run. For all other affected jobs, MIMIX determines the actual start time for object or database jobs based on the timestamp of the system on which the OBJSND or the DBSND job runs. Table 41 shows how these key jobs affect when 286 Configuring restart times for MIMIX jobs other data group-level jobs restart. Table 41. Systems on which data group-level jobs run. In each row, the highlighted job determines the restart time for all jobs in the row. Source System Jobs Object send (OBJSND) Object retrieve (OBJRTV) Container send (CNRSND) Status receive (STSRCV) Database send (DBSND) 1 Target System Jobs Object receive (OBJRCV) Container receive (CNRRCV) Status Send (STSSND) Database receive (DBRCV) 1 Database reader (DBRDR) 1 Object apply (OBJAPY) When MIMIX is configured for remote journaling, the DBSND and DBRCV jobs are replaced by the DBRDR job. The DBRDR job restarts when the specified time occurs on the target system. 1 For more information about MIMIX jobs see “Replication job and supporting job names” on page 47. Considerations for using *NONE Attention: The value *NONE for the Job restart time parameter is not recommended. If you specify *NONE in a system definition or a data group definition, you need to develop and implement alternative procedures to ensure that the affected MIMIX jobs are periodically restarted. Restarting the jobs ensures that long running MIMIX jobs are not ended by the system due to resource constraints and refreshes the job log to avoid overflow and abnormal job termination. If you specify the value *NONE for the Job restart time in a data group definition, no MIMIX data group-level jobs are automatically restarted. If you specify the value *NONE for the Job restart time in a system definition, the cleanup jobs started by the system manager will continue to be submitted based on when midnight occurs on the management system. All other affected MIMIX systemlevel jobs will not be restarted. Table 40 shows the effect of the value *NONE. Examples: job restart time “Restart time examples: system definitions” on page 288 and “Restart time examples: system and data group definition combinations” on page 288 illustrate the effect of using the Job restart time (RSTARTTIME) parameter. These examples assume that the system configured as the management system for MIMIX operations is also the target system for replication during normal operation. For each example, consider the effect it would have on nightly backups that complete between midnight and 1 a.m. on the target system. 287 Restart time examples: system definitions These examples show the effect of changing the job restart time only in system definitions. Example 1: MIMIX is running Monday noon when you change the job restart time to 013000 in system definition NEWYORK, which is the management system. The network system’s system definition uses the default value 000000 (midnight). MIMIX remains up the rest of the day. Because the current jobs use values that existed prior to your change, all the MIMIX system-level jobs on NEWYORK automatically restart at midnight. As a result of your change, the journal manager on NEWYORK restarts at 1:30 a.m. Tuesday and thereafter. The network system’s journal manager restarts when midnight occurs on that system. The system manager jobs on both systems restart and submit the cleanup jobs when the management system reaches midnight. Example 2: It is Friday evening and all MIMIX processes on the system CHICAGO are ended while you perform planned maintenance. During that time you change the job restart time to 040000 in system definition CHICAGO, which is a network system. You start MIMIX processing again at 11:07 p.m. so your changes are in effect. The MIMIX system-level jobs that restart Saturday and thereafter at 4 a.m. Chicago time are: • • • The journal manager job on CHICAGO The system manager jobs on the management system and on CHICAGO The cleanup jobs are submitted on the management system and on CHICAGO Because the management system’s system definition uses the default value of midnight, the journal manager on the management system restarts when midnight occurs on that system. Example 3: Friday afternoon you change system definition HONGKONG to have a job restart time value of *NONE. HONGKONG is the management system. LONDON is the associated network system and its system definition uses the default setting 000000 (midnight). You end and restart the MIMIX jobs to make the change effective. The journal manager on HONGKONG is no longer restarted. At midnight (00:00 a.m. Saturday and thereafter) HONGKONG time, the system manager jobs on both systems restart and submit cleanup jobs on both systems. In your runbook you document the new procedures to manually restart the journal manager on HONGKONG. Example 4: Wednesday evening you change the system definitions for LONDON and HONG KONG to both have a job restart time of *NONE. HONGKONG is the management system. You restart the MIMIX jobs to make the change effective. At midnight HONGKONG time, only the cleanup jobs on both systems are submitted. In your runbook you document the new procedures to manually restart the journal managers and system managers. Restart time examples: system and data group definition combinations These examples show the effect of changing the job restart time in various combinations of system definitions and data group definitions. 288 Configuring restart times for MIMIX jobs Example 5: You have a data group that operates between SYSTEMA and SYSTEMB, which are both in the same time zone. Both the system definitions and the data group definition use the default value 000000 (midnight) for the job restart time. For both systems, the MIMIX system-level jobs restart at midnight. The data group jobs on both systems restart between 2 and 35 minutes after midnight. Example 6: 10:30 Tuesday morning you change data group definition APP1 to have a job restart time value of 013500. The data group operates between SYSTEMA and SYSTEMB, which are both in the same time zone. Both system definitions use the default restart time of midnight. MIMIX jobs remain up and running. At midnight, the system-level jobs on both systems restart using the values from the preexisting configuration; the data group-level jobs restart on both systems between 0:02 and 0:35 a.m. On Wednesday and thereafter, APP1 data group-level jobs restart between 1:37 and 2:10 a.m. while the MIMIX system-level jobs and jobs for other data groups restart at midnight. Example 7: You have a data group that operates between SYSTEMA and SYSTEMB which are both in the same time zone and are defined as the values of System 1 and System 2, respectively. The data group definition specifies a job restart time value of *SYSDFN2. The system definition for SYSTEMA specifies the default job restart time of 000000 (midnight). SYSTEMB is the management system and its system definition specifies the value *NONE for the job restart time. The journal manager on SYSTEMB does not restart and the data group jobs do not restart on either system because of the *NONE value specified for SYSTEMB. The journal manager on SYSTEMA restarts at midnight. System manager jobs on both systems restart and submit cleanup jobs at midnight as a result of the value in the network system and the fact that the systems are in the same time zone. Example 8A: You have a data group defined between CHICAGO and NEWYORK (System 1 and System 2, respectively) and the data group’s job restart time is set to 030000 (3 a.m.). CHICAGO is the source system as well as a network system; its system definition uses the default job restart time of midnight. NEWYORK is the target system as well as the management system; its system definition uses a job restart time of 020000 (2 a.m.). There is a one hour time difference between the two systems; said another way, NEWYORK is an hour ahead of CHICAGO. Figure 17 shows the effect of the time zone difference on this configuration. The journal manager on CHICAGO restarts at midnight Chicago time and the journal manager on NEWYORK restarts at 2 a.m. New York time. The system manager jobs on both systems restart when the management system (NEWYORK) reaches the restart time specified for the network system (CHICAGO). The cleanup jobs are submitted by the system manager jobs when they restart. With the exception of the object apply jobs (OBJAPY), the data group jobs restart during the same 2 to 35 minute timeframe based on Chicago time (between 2 and 35 minutes after 3 a.m. in Chicago; after 4 a.m. in New York). Because the OBJAPY jobs are based on the time on the target system, which is an hour ahead of the source 289 290 . In this scenario. the MIMIX environment is configured to use MIMIX Remote Journal support.m. New York time.system time used for the other jobs. This environment is configured to use MIMIX Remote Journal support. Results of Example 8A. This is configured as a standard MIMIX environment. Because the database send (DBSND) and database receive (DBRCV) jobs are not used in a remote journaling environment. Results of example 8B. those jobs do not restart. Figure 18 shows that the database reader (DBRDR) job restarts based on the time on the target system. Figure 18. the OBJAPY jobs restart between 3:02 and 3:35 a. Figure 17. Example 8B: This scenario is the same as example 8A with one exception. The value for the Job restart time is retrieved from the system definition at the time the jobs are started. the complete time format must be specified. do the following: 1.). On the Work with Data Group Definitions display. see “Considerations for using *NONE” on page 287. The value 000000 is the default and is equivalent to midnight (00:00:00 a. Valid values range from 000000 to 235959. specify the value you want. For more information. The change is effective the next time the jobs are started. If you specify *NONE. 2. cleanup jobs are submitted on both the network and management systems based on when midnight occurs on the management system. the complete time format must be specified. Notes: • The time is based on a 24 hour clock. type a 2 (Change) next to the system definition you want and press F4 (Prompt). and must be specified in HHMMSS format. 3. Although seconds are ignored. At the Job restart time prompt. On the Work with System Definitions display. 2. Notes: • The time is based on a 24 hour clock. • 291 . System manager and journal manager jobs will not restart. then scroll down to the bottom of the display. type a 2 (Change) next to the data group definition you want and press F4 (Prompt). specify the value you want. and must be specified in HHMMSS format.m. 3. press Enter. Press F10 (Additional parameters). At the Job restart time prompt. Valid values range from 000000 to 235959. Press F10 (Additional parameters). Configuring the restart time in a data group definition To configure the restart time for MIMIX data group-level jobs in an existing environment. do the following: 1. For more information. • 4. The value 000000 is the default and is equivalent to midnight (00:00:00 a. You need to consider the effect of any time zone differences between the systems defined to the data group. You need to consider the role of the system definition (management or network system) and the effect of any time zone differences between the management system and the network system.m. The value *NONE is not recommended. see “Considerations for using *NONE” on page 287. Although seconds are ignored.Configuring restart times for MIMIX jobs Configuring the restart time in a system definition To configure the restart time for MIMIX system-level jobs in an existing environment. then scroll down to the bottom of the display. To accept the change. The change has no effect on jobs that are currently running.). The value *NONE is not recommended. 4. The value for the Job restart time is retrieved at the time the jobs are started. The change is effective the next time the jobs are started. 292 . Changes have no effect on jobs that are currently running. To accept the change. press Enter. ending. and verifying journaling for physical files identified by data group file entries. However. “Journaling for IFS objects” on page 300 includes procedures for displaying journaling status. and verifying journaling This chapter describes procedures for starting and ending journaling. • • • • 293 . as well as the authority requirements necessary for user profiles that create the objects to be journaled when they are created.CHAPTER 14 Starting. for supported configuration scenarios. IFS objects. and verifying journaling for IFS objects replicated cooperatively (advanced journaling). what types of objects must have journaling started before replication can occur. ending journaling. Journaling must be active on all files. there are times when you may need to start or end journaling on items identified to a data group. Normally. It also describes when journaling is started implicitly. starting journaling. The topics in this chapter include: • “What objects need to be journaled” on page 294 describes. IFS tracking entries are used in these procedures. data areas and data queues that you want to replicate through a user journal. starting journaling. ending journaling. and verifying journaling for data area and data queue objects replicated cooperatively (advanced journaling). starting journaling. “Journaling for data areas and data queues” on page 303 includes procedures for displaying journaling status. ending journaling. “MIMIX commands for starting journaling” on page 296 identifies the MIMIX commands available for starting journaling and describes the checking performed by the commands. IFS tracking entries are used in these procedures. “Journaling for physical files” on page 297 includes procedures for displaying journaling status. journaling is started during configuration. Object auditing is automatically set for all objects defined to a data group when the data group is first started. inheritance is permitted. Although MIMIX commands for starting journaling are preferred. STRJRNOBJ) to start journaling if you have the appropriate authority for starting journaling. data queues. Starting journaling ensures that changes to the objects are recorded in the user journal. specify INHERIT(*YES). you can also use IBM commands (STRJRNPF. Database files created by SQL statements . data queues and IFS objects. and DLO entries are configured. data queues. or IFS objects when certain requirements are met. each entry specifies an object auditing value that determines the type of activity on the objects to be logged in the journal. Requirements for implicit starting of journaling . or IFS objects also require that journaling be started on the associated object tracking entries and IFS tracking entries. or DLO entries for the data group. IFS entries. The user ID creating the new objects must have the required authority to start journaling and the following requirements must be met: • IFS objects . Typically.A new file created by a CREATE • 294 . Both MIMIX Dynamic Apply and legacy cooperative processing use data group file entries and therefore require journaling to be started. Configurations that include advanced journaling for replication of data areas. When data group object entries. and STRJRNOBJE simplify the process of starting journaling. no special action is need. During initial configuration. data areas.A new IFS object is automatically journaled if the directory in which it is created is journaled as a result of a request that permitted journaling inheritance for new objects. STRJRNIFSE. and object tracking entries. data areas. IFS entries.What objects need to be journaled A data group can be configured in a variety of ways that involve a user journal in the replication of files. STRJRN. the configuration checklists direct you when to start journaling for objects identified by data group file entries. Because security auditing logs the object changes in the system journal. see “MIMIX commands for starting journaling” on page 296. Journaling must be started for any object to be replicated through a user journal or to be replicated by cooperative processing between a user journal and the system journal. and are therefore available for MIMIX to replicate. For more information about these commands. if MIMIX started journaling on the parent directory. Events are logged in this journal to create a security audit trail. the security audit (QAUDJRN) journal. Requirements for user journal replication . The MIMIX commands STRJRNFE. respectively. This will allow IFS objects created within the journaled directory to inherit the journal options and journal state of the parent directory. or any time a change is made to the object entries.Journaling can be automatically started for newly created database files. IFS tracking entries. If you manually start journaling on the parent directory using the IBM command STRJRN.System journal replication processes use a special journal.User journal replication processes require that the journaling be started for the objects identified by data group file entries. Requirements for system journal replication . The default value (*DFT) for the Journal at creation (JRNATCRT) parameter in the data group definition enables MIMIX to create the QDFTJRN data area in a library and enable the data area for automatic journaling for an object type. STRJRNOBJE) to start journaling. If necessary.The operating system will automatically journal a new object if it is created in a library that contains a QDFTJRN data area and the data area has enabled automatic journaling for the object type. QRCL*. MIMIX evaluates all data group object entries for each object type.) Entries properly configured to allow cooperative processing of the object type determine whether MIMIX will create the QDFTJRN data area. MIMIX uses the data group entry with the most specific match to the object type and library that also specifies *ALL for its System 1 object (OBJ1) and Attribute (OBJATR). QRPL*. QGPL. For example. (Entries for *FILE objects are only evaluated when the data group specifies COOPJRN(*USRJRN). Note: MIMIX prevents the QDFTJRN data area from being created the following libraries: QSYS*. Authority requirements must be met to enable the automatic journaling of newly created objects and if you use IBM commands to start journaling instead of MIMIX commands. When the QDFTJRN data area in a library is enabled for an object type. 295 . *DTAQ objects . data areas. QRCY*. not just those which are eligible for replication. LIB1(MYLIB) OBJ1(*ALL) OBJTYPE(*FILE) OBJATR(*ALL) COOPDB(*YES) PRCTYPE(*INCLD) LIB1(MYLIB) OBJ1(MYAPP) OBJTYPE(*FILE) OBJATR(DSPF) COOPDB(*YES) PRCTYPE(*INCLD) Authority requirements for starting journaling Normal MIMIX processes run under the MIMIXOWN user profile.What objects need to be journaled TABLE statement is automatically journaled if the library in which it is created contains a journal named QSQJRN. MIMIX changes public authority so the user ID in use has the appropriate authority to start journaling. QUSR*. The second entry is not considered in the determination because its OBJ1 and OBJATR values do not meet these requirements. MIMIX checks the public authority (*PUBLIC) for the journal. which ships with *ALLOBJ special authority. *DTAARA. it is not necessary for other users to account for journaling authority requirements when using MIMIX commands (STRJRNFE. it would use the first entry when determining whether to create the QDFTJRN data area because it is the most specific entry that also meets the OBJ1(*ALL) and OBJATR(*ALL) requirements. • New *FILE. or data queues for which you expect automatic journaling at creation. QRPL*. When the MIMIX journal managers are started. or when the Build Journaling Environment (BLDJRNENV) command is used. QTEMP and SYSIB*. Therefore. QRECOVERY. the user ID creating these objects must have the required authority to start journaling. all new objects of that type are journaled. When the data group is started. STRJRNIFSE. • If you create database files. QSPL*. if MIMIX finds only the following data group object entries for library MYLIB. or object tracking entries associated with the command’s object class must be loaded.This command starts journaling of data area and data queue objects configured for advanced journaling. Start Journaling Obj Entries (STRJRNOBJE) . IFS tracking entry. If the file or object is journaled to the correct journal. MIMIX commands for starting journaling Before you use any of the MIMIX commands for starting journaling. The MIMIX commands for starting journaling are: • • Start Journal Entry (STRJRNFE) .This command starts journaling of IFS objects configured for advanced journaling. one of the following authority requirements must be satisfied: • • • The user profile of the user attempting to start journaling for an object must have *ALLOBJ special authority. Public authority (*PUBLIC) must have *OBJALTER. *OBJMGT. For journaling to be successfully started on an object. and *OBJOPR object authorities for the journal to which the object is to be journaled.This command starts journaling for files identified by data group file entries. If the file or object is not journaled to the correct journal or the attempt to start journaling fails. the user ID that performs the start journaling request must have the appropriate authority requirements. • If you attempt to start journaling for a data group file entry. IFS tracking entries. or data queue is journaled to the journal associated with the data group. an error occurs and the journaling status is changed to *NO. STRJRNOBJ) to start journaling. the journaling status of the data group file entry. the data group file entries. IFS object. Data group IFS entries must be configured and IFS tracking entries be loaded (LODDGIFSTE command) before running the STRJRNIFSE command to start journaling. IFS tracking or object tracking entry is changed to *YES. STRJRN.• If you use the IBM commands (STRJRNPF. MIMIX checks that the physical file. data area. The user profile of the user attempting to start journaling for an object must have explicit *ALL object authority for the journal to which the object is to be journaled. or object tracking entry and the files or objects associated with the entry are already journaled. 296 . Data group object entries must be configured and object tracking entries be loaded (LODDGOBJTE command) before running the STRJRNOBJE command to start journaling. Start Journaling IFS Entries (STRJRNIFSE) . On the Work with Data Groups display. end. Do the following: 1. press Enter. Then do one of the following: • • To start journaling using the command defaults. This procedure invokes the Start Journal Entry (STRJRNFE) command. The Data group definition prompts and the System 1 file prompts identify your selection. At the right side of the display. or verify journaling for physical files. they may have an initial status of *ACTIVE. From the Work with DG File Entries display. The initial view shows the current and requested status of the data group file entry. Note: Logical files will have a status of *NA. Do the following: 1. the Journaled System 1 and System 2 columns indicate whether the physical file associated with the file entry is journaled on each system. In order for replication to occur. The Start Journal Entry (STRJRNFE) display appears. Accept these values or specify the values you want. journaling must be started for the file on the source system. 3. 2. type 17 (File entries) next to the data group you want and press Enter. type a 9 (Start journaling) next to the file entries you want. Data group file entries exist for logical files only in data groups configured for MIMIX Dynamic Apply. The Work with DG File Entries display appears. 297 . From the MIMIX Intermediate Main Menu. type 1 and press Enter to access the Work with Data Groups display. In order for replication to occur. When data group file entries are added to a configuration. press F4 (Prompt) then continue with the next step. Starting journaling for physical files Use this procedure to start journaling for physical files identified by data group file entries. journaling must be started for the files on the source system. The command can also be entered from a command line.Journaling for physical files Journaling for physical files Data group file entries identify physical files to be replicated. 2. 3. Access the journaled view of the Work with DG File Entries display as described in “Displaying journaling status for physical files” on page 297. and to start. Displaying journaling status for physical files Use this procedure to display journaling status for physical files identified by data group file entries. To modify command defaults. Press F10 (Journaled view). This topic includes procedures to display journaling status. However. the physical files which they identify may not be journaled. To start journaling for the physical file associated with the selected data group. 4. 6. For example. If you want to end journaling outside of MIMIX. *SRC. press Enter. use the ENDJRNPF command. specify *YES for the Submit to batch prompt.4. to prepare for upgrading MIMIX software. If you want to end journaling for all files in the library. or *TGT is specified. To modify additional prompts for the command. • • To end journaling using command defaults. To end journaling. any changes to that file are not captured and are not replicated. This procedure invokes the End Journaling File Entry (ENDJRNFE) command. If you want to use batch processing. press F4 (Prompt) and continue with the next step. When *DGDFN. 5. press Enter. The command can also be entered from a command line. specify *ALL at the System 1 file prompt. 5. Access the journaled view of the Work with DG File Entries display as described in “Displaying journaling status for physical files” on page 297. or to correct an error. press Enter. MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and ends or prevents journaling from ending as required. Press F4 to see a list of valid values. Journaling is ended. Specify the value you want for the Start journaling on system prompt. Ending journaling for physical files Use this procedure to end journaling for a physical file associated with a data group file entry. Once journaling for a file is ended. If you want to use batch processing. Press F4 to see a list of valid values. MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and starts or prevents journaling from starting as required. type a 10 (End journaling) next to the file entry you want and do one of the following: Note: MIMIX cannot end journaling on a file that is journaled to the wrong journal. 3. You may need to end journaling if a file no longer needs to be replicated. From the Work with DG File Entries display. specify *YES for the Submit to batch prompt. 298 . The End Journal File Entry (ENDJRNFE) display appears. 2. do the following: 1. The system returns a message to confirm the operation was successful. a file that does not match the journal definition for that data group. When *DGDFN. 6. To end journaling. Specify the value you want for the End journaling on system prompt. or *TGT is specified. *SRC. The Verify Journaling File Entry (VFYJRNFE) display appears. Access the journaled view of the Work with DG File Entries display as described in “Displaying journaling status for physical files” on page 297. do the following: 1. The Data group definition prompts and the System 1 file prompts identify your selection. 4. press Enter. Specify the value you want for the Verify journaling on system prompt. When these conditions are met. 2. 299 .Journaling for physical files Verifying journaling for physical files Use this procedure to verify if a physical file defined by a data group file entry is journaled correctly. This procedure invokes the Verify Journaling File Entry (VFYJRNFE) command to determine whether the file is journaled and whether it is journaled to the journal defined in the journal definition. To modify additional prompts for the command. When *DGDFN is specified. To verify journaling for a physical file. Accept these values or specify the values you want. type a 11 (Verify journaling) next to the file entry you want and do one of the following: • • To verify journaling using command defaults. The command can also be entered from a command line. specify *YES for the Submit to batch prompt 6. Press Enter. MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) when determining where to verify journaling. If you want to use batch processing. 3. press F4 (Prompt) and continue with the next step. 5. the journal status on the Work with DG File Entries display is set to *YES. From the Work with DG File Entries display. the Journaled System 1 and System 2 columns indicate whether the IFS object identified by the tracking is journaled on each system. type 1 and press Enter to access the Work with Data Groups display. You should be aware of the information in “Long IFS path names” on page 107 Displaying journaling status for IFS objects Use this procedure to display journaling status for IFS objects identified by IFS tracking entries. press Enter. Do the following: 1. Access the journaled view of the Work with DG IFS Trk. The command can also be entered from a command line. type 50 (IFS trk entries) next to the data group you want and press Enter. or verify journaling for IFS objects identified for replication through the user journal. To modify the command defaults. 2. The initial view shows the object type and status at the right of the display. The Work with DG IFS Trk. 4. and to start. Starting journaling for IFS objects Use this procedure to start journaling for IFS objects identified by IFS tracking entries. 3. However. Then do one of the following: • • To start journaling using the command defaults. journaling must be started on the source system for the IFS objects identified by IFS tracking entries. type a 9 (Start journaling) next to the IFS tracking entries you want. 2. 3. The Data group 300 . In order for replication to occur. To start journaling for IFS objects. Entries display as described in “Displaying journaling status for IFS objects” on page 300. At the right side of the display. end. This procedure invokes the Start Journaling IFS Entries (STRJRNIFSE) command. do the following: 1. From the Work with DG IFS Trk. This topic includes procedures to display journaling status. Entries display appears.Journaling for IFS objects IFS tracking entries are loaded for a data group after the data group IFS entries have been configured for replication through the user journal (advanced journaling). Press F10 (Journaled view). On the Work with Data Groups display. The Start Journaling IFS Entries (STRJRNIFSE) display appears. Entries display. load the IFS tracking entries for the data group. Use the procedure in “Loading IFS tracking entries” on page 257. loading IFS tracking entries does not automatically start journaling on the IFS objects they identify. From the MIMIX Intermediate Main Menu. If you have not already done so. These references go to different files in different books. press F4 (Prompt) and continue with the next step. Either accept the default values or specify other values.Journaling for IFS objects definition and IFS objects prompts identify the IFS object associated with the tracking entry you selected. When the command is invoked from a command line. When *DGDFN. specify *YES for the Submit to batch prompt and press Enter. 3. *SRC. 1. Access the journaled view of the Work with DG IFS Trk. 6. MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and ends or prevents journaling from ending as required. Specify the value you want for the Start journaling on system prompt. you can change values specified for the IFS objects prompts. When the command is invoked from a command line. The command can also be entered from a command line. You cannot change the values2. Then do one of the following: • • To end journaling using the command defaults. To modify the command defaults. press F4 (Prompt) and continue with the next step. You cannot change the values shown for the IFS objects prompts1. To end journaling for IFS objects. *SRC. Entries display as described in “Displaying journaling status for IFS objects” on page 300. type a 10 (End journaling) next to the IFS tracking entries you want. Specify the value you want for the End journaling on system prompt. 5. The System 1 file identifier and System 2 file identifier prompts identify the file identifier (FID) of the IFS object on each system. Also. MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and starts or prevents journaling from starting as required. press Enter. 2. Entries display. The FID values can be used alone or in combination with the IFS object path name. press Enter. or *TGT is specified. Additional prompts for Job description and Job name appear. 7. Then you can optionally specify the unique FID for the IFS object on either system. you can specify as many as 300 object selectors by using the + for more values prompt. 301 . This procedure invokes the End Journaling IFS Entries (ENDJRNIFSE) command. Press F4 to see a list of valid values. To use batch processing. do the following: 1. From the Work with DG IFS Trk. The Data group definition and IFS objects prompts identify the IFS object associated with the tracking entry you selected. To start journaling on the IFS objects specified. or *TGT is specified. The End Journaling IFS Entries (ENDJRNIFSE) display appears. use F10 to see the FID prompts. When *DGDFN. You cannot change the values shown for the IFS objects prompts1. 2. Press F4 to see a list of valid values. Ending journaling for IFS objects Use this procedure to end journaling for IFS objects identified by IFS tracking entries. 4. 8. 302 . To use batch processing. Press F4 to see a list of valid values. 4. Additional prompts for Job description and Job name appear. Either accept the default values or specify other values. You cannot change the values shown for the IFS objects prompts1. and whether it is journaled with the attributes defined in the data group definition. The System 1 file identifier and System 2 file identifier identify the file identifier (FID) of the IFS object on each system. 6. When *DGDFN is specified. do the following: 1. To modify the command defaults. This procedure invokes the Verify Journaling IFS Entries (VFYJRNIFSE) command to determine whether the IFS object is journaled.5. specify *YES for the Submit to batch prompt and press Enter. whether it is journaled to the journal defined in the data group definition. 7. press Enter. You cannot change the values shown2. The Verify Journaling IFS Entries (VFYJRNIFSE) display appears. specify *YES for the Submit to batch prompt and press Enter. press F4 (Prompt) and continue with the next step. To use batch processing. 7. Either accept the default values or specify other values. Specify the value you want for the Verify journaling on system prompt. Access the journaled view of the Work with DG IFS Trk. 2. 6. 5. Entries display. The System 1 file identifier and System 2 file identifier identify the file identifier (FID) of the IFS object on each system. To verify journaling on the IFS objects specified. Verifying journaling for IFS objects Use this procedure to verify if an IFS object identified by an IFS tracking entry is journaled correctly. You cannot change the values shown2. To end journaling on the IFS objects specified. 3. press Enter. Then do one of the following: • • To verify journaling using the command defaults. To verify journaling for IFS objects. From the Work with DG IFS Trk. press Enter. type a 11 (Verify journaling) next to the IFS tracking entries you want. “Using file identifiers (FIDs) for IFS objects” on page 284. Additional prompts for Job description and Job name appear. The Data group definition and IFS objects prompts identify the IFS object associated with the tracking entry you selected. Entries display as described in “Displaying journaling status for IFS objects” on page 300. MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and verifies journaling on the appropriate systems as required. The command can also be entered from a command line. From the Work with DG Obj. Starting journaling for data areas and data queues Use this procedure to start journaling for data areas and data queues identified by object tracking entries. Trk. press F4 (Prompt) and continue with the next step. the Journaled System 1 and System 2 columns indicate whether the object identified by the tracking is journaled on each system. The initial view shows the object type and status at the right of the display. 2. end. The Data group definition and Objects prompts identify the object associated with the 303 . Entries display. This topic includes procedures to display journaling status. The Start Journaling Obj Entries (STRJRNOBJE) display appears. From the MIMIX Intermediate Main Menu. If you have not already done so. Use the procedure in “Loading object tracking entries” on page 258. and to start. This procedure invokes the Start Journaling Obj Entries (STRJRNOBJE) command. On the Work with Data Groups display. To modify the command defaults. 3. Trk. At the right side of the display. 3. or verify journaling for data areas and data queues identified for replication through the user journal. The command can also be entered from a command line. journaling must be started for the objects on the source system for the objects identified by object tracking entries. Displaying journaling status for data areas and data queues To check journaling status for data areas and data queues identified by object tracking entries. press Enter. In order for replication to occur.Journaling for data areas and data queues Journaling for data areas and data queues Object tracking entries are loaded for a data group after the data group object entries have been configured replication through the user journal (advanced journaling). loading object tracking entries does not automatically start journaling on the objects they identify. Entries display appears. Then do one of the following: • • To start journaling using the command defaults. 2. To start journaling for data areas and data queues. type 1 and press Enter to access the Work with Data Groups display. load the object tracking entries for the data group. Access the journaled view of the Work with DG Obj. The Work with DG Obj. do the following: 1. Press F10 (Journaled view). type 52 (Obj trk entries) next to the data group you want and press Enter. Entries display as described in “Displaying journaling status for data areas and data queues” on page 303. 4. Do the following: 1. However. Trk. type a 9 (Start journaling) next to the object tracking entries you want. Additional prompts for Job description and Job name appear. 2. Ending journaling for data areas and data queues Use this procedure to end journaling for data areas and data queues identified by object tracking entries. press F4 (Prompt) and continue with the next step. Specify the value you want for the Start journaling on system prompt. From the Work with DG Obj. do the following: 1. The command can also be entered from a command line. press Enter. When *DGDFN. it is not recommended unless the command was invoked from a command line. it is not recommended unless the command was invoked from a command line. MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and starts or prevents journaling from starting as required. *SRC. 4. To end journaling for data areas and data queues. 304 . Either accept the default values or specify other values. type a 10 (End journaling) next to the object tracking entries you want. MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and ends or prevents journaling from ending as required. *SRC. or *TGT is specified. Although you can change the values shown for these prompts. 3. Then do one of the following: • • To verify journaling using the command defaults. Trk. press Enter. Entries display. or *TGT is specified. Press F4 to see a list of valid values. 7. The Data group definition and IFS objects prompts identify the object associated with the tracking entry you selected. 5. To modify the command defaults. specify *YES for the Submit to batch prompt and press Enter. Press F4 to see a list of valid values. When *DGDFN. 6. To end journaling on the objects specified. Access the journaled view of the Work with DG Obj. 5. To use batch processing. This procedure invokes the End Journaling Obj Entries (ENDJRNOBJE) command. Specify the value you want for the End journaling on system prompt. Although you can change the values shown for these prompts. Either accept the default values or specify other values. Trk. Entries display as described in “Displaying journaling status for data areas and data queues” on page 303. To use batch processing. Additional prompts for Job description and Job name appear.tracking entry you selected. The End Journaling Obj Entries (ENDJRNOBJE) display appears. specify *YES for the Submit to batch prompt and press Enter. To start journaling on the objects specified. press Enter. 6. MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and verifies journaling on the appropriate systems as required. From the Work with DG Obj. and whether it is journaled with the attributes defined in the data group definition. To verify journaling for objects. Entries display as described in “Displaying journaling status for data areas and data queues” on page 303. Press F4 to see a list of valid values. Either accept the default values or specify other values. Trk. Access the journaled view of the Work with DG Obj. Trk. 5. it is not recommended unless the command was invoked from a command line. The Data group definition and Objects prompts identify the object associated with the tracking entry you selected. press F4 (Prompt) and continue with the next step. The command can also be entered from a command line. type a 11 (Verify journaling) next to the object tracking entries you want. whether it is journaled to the journal defined in the data group definition. To use batch processing. Entries display. Although you can change the values shown for these prompts. To verify journaling on the objects specified. The Verify Journaling Obj Entries (VFYJRNOBJE) display appears. Specify the value you want for the Verify journaling on system prompt. specify *YES for the Submit to batch prompt and press Enter. Additional prompts for Job description and Job name appear. 2. 305 . This procedure invokes the Verify Journaling Obj Entries (VFYJRNOBJE) command to determine whether the object is journaled. When *DGDFN is specified. 4. press Enter. Then do one of the following: • • To verify journaling using the command defaults. 6. To modify the command defaults. 3. press Enter.Journaling for data areas and data queues Verifying journaling for data areas and data queues Use this procedure to verify if an object identified by an object tracking entry is journaled correctly. do the following: 1. • • • 306 . “Configuring high volume objects for better performance” on page 317 describes how to change your configuration to improve system journal performance. “Configuring for high availability journal performance enhancements” on page 309 describes journal caching and journal standby state within MIMIX to support IBM’s High Availability Journal Performance IBM i option 42. Journal Standby feature and Journal caching. • MIMIX performance: The following topics describe how to improve MIMIX performance: • “Caching extended attributes of *FILE objects” on page 313 describes how to change the maximum size of the cache used to store extended attributes of *FILE objects replicated from the system journal. “Increasing data returned in journal entry blocks by delaying RCVJRNE calls” on page 314 describes how you can improve object send performance by changing the size of the block of data from a receive journal entry (RCVJRNE) call and delaying the next call based on a percentage of the requested block size.Configuring for improved performance CHAPTER 15 Configuring for improved performance This chapter describes how to modify your configuration to use advanced techniques to improve journal performance and MIMIX performance. Requirements and restrictions are included. Journal performance: The following topics describe how to improve journal performance: • “Minimized journal entry data” on page 307 describes benefits of and restrictions for using minimized user journal entries for *FILE and *DTAARA objects. “Improving performance of the #MBRRCDCNT audit” on page 318 describes how to use the CMPRCDCNT commit threshold policy to limit comparisons and thereby improve performance of this audit in environments which use commitment control. A discussion of large object (LOB) data in minimized entries and configuration information are included. For example. With *FLDBDY. Minimized journal entries cannot be used when MIMIX support for keyed replication is in use. When database files have records with static LOB values. file data for modified fields is minimized on field boundaries. Configuring for minimized journal entry data may affect your ability to use the Work with Data Group File Entries on Hold (WRKDGFEHLD) command. Factors in your environment such as the percentage of journal entries that are updates (R-UP). entry-specific data is viewable and may be used for auditing purposes. In a MIMIX replication environment. The benefit of using minimized journal entries is that less data is stored in the journal. the number of bytes typically changed in an update. Restrictions of minimized journal entry data The following MIMIX and operating system restrictions apply: • If you plan to use keyed replication do not use minimized journal entry data. the size of database records. This support is enabled in the MIMIX create or change journal definitions commands and built using the Build Journal Environment (BLDJRNENV) command. The minimizing resulting from specifying *FILE does not occur on field boundaries. do not configure for minimized entry data. The IBM i provides the ability to create journal entries using an internal format that minimizes the data specific to these object types that are stored in the journal entry. since the key may not be present in a minimized journal entry. When *FLDBDY is specified. If MINENTDTA(*FILE) or MINENTDTA(*FLDBDY) is in effect and a database record includes LOB fields. LOB data is journaled only when that LOB is changed. When a journal entry for one of these object types is generated. the entry specific data may not be viewable and may not be used for auditing purposes. Minimized before-images cannot be selected for automatic before-image synchronization checking. Therefore.Minimized journal entry data Minimized journal entry data MIMIX supports the ability to process minimized journal entries placed in a user journal for object types of file (*FILE) and data area (*DTAARA). • 307 . the system compares the size of the minimized format to the standard format and places whichever is smaller in the journal. will result in failure when applied. you also benefit by having less data sent over communications lines and saved in MIMIX log spaces. For database files. minimized journal entries can produce considerable savings. may influence how much benefit you achieve. consider the effect of how data is minimized. Even if you do not rely on full image captures for auditing purposes. only update journal entries (R-UP and RUB) and rollback-type update entries (R-BR and R-UR) can be minimized. using option 2 (Change) on WRKDGFEHLD to convert a minimized record update (RUP) to a record put (RPT). Changes to other fields in the record will not cause the LOB data to be journaled unless the LOB is also changed. • Your environment may impose additional restrictions: • • If you rely on full image captures in the receiver as part of your auditing rules. 4. 2. Backup and Recovery for restrictions and usage of journal entries with minimized entry-specific data. type 14 (Build) next to the definition you just modified on the Work with Journal Definitions display and press Enter.RPTs requires the presence of a full. use option 2 (Change) to access the journal definition you want. 3. Press F10 (Additional parameters) to access the Minimize entry specific data prompt. Page down to the bottom of the display. From the Work with Journal Definitions display. press Enter twice to see all prompts for the display. Configuring for minimized journal entry data By default. To do this. Specify the values you want at the Minimize entry specific data prompt and press Enter. On the following display. do the following: 1. See the IBM book. non-minimized. you must build the journaling environment using the updated journal definition. 308 . 5. In order for the changes to be effective. To enable MIMIX to use minimized journal entry data for specific object types. MIMIX user journal replication processes use complete journal entry data. record. is to change the journal state to active. also see the topics on journal management and system performance in the IBM eServer iSeries Information Center. although when used together. see “Restrictions of high availability journal performance enhancements” on page 311. All that is necessary prior to switching. Journal standby state minimizes replication impact on the target system by providing the benefits of an active journal without writing the journal entries to disk.Configuring for high availability journal performance enhancements Configuring for high availability journal performance enhancements MIMIX supports IBM’s High Availability Journal Performance IBM i option 42. then using journal standby state may offer a benefit in reduced switch time. commitment control cannot be used for files that are journaled to any journal in standby state. Journal standby state and journal caching can be used in source send configuration environments as well as in environments where remote journaling is enabled. Journal Standby feature and Journal caching. As such. Journal caching is particularly helpful during batch operations when large numbers of add. These high availability performance enhancements improve replication performance on the target system and provide significant performance improvement by eliminating the need to start journaling at switch time. journal standby state is particularly helpful in saving disk space in environments that do not rely on journal entries for other purposes. Most referential constraints cannot be used when the journal is in standby state. When a journal is in standby state. When journal standby state is not an option because of these 309 . MIMIX support of IBM’s high availability performance enhancements consists of two independent components: journal standby state and journal caching. journal standby state minimizes switch times by retaining the journal relationship for replicated objects. However. journal standby state can provide a performance improvement on the apply session. it is not necessary to start journaling for objects on the target system prior to switching. These components work individually or together. If you are not using journaling on target and want to have a switchable data group. If you are journaling on apply. Journal caching provides a means by which to cache journal entries and their corresponding database records into main storage and write to disks only as necessary. Journal standby state Journal standby state minimizes replication impact by providing the benefits of an active journal without writing the journal entries to disk. Moreover. As such. Note: For more information. Moreover. update. journal standby state is particularly helpful in saving disk space in environments that do not rely on journal entries for other purposes. and delete operations against journaled objects are performed. You can start or stop journaling while the journal standby state is enabled. each component must be enabled separately. For restrictions of MIMIX support of IBM’s high availability performance enhancements. Note: For purposes of this document. update. which allows you to change the target access path recovery time for the system. and delete operations against journaled objects are performed. Because most database transactions must no longer wait for a synchronous write of the journal entries to disk. For example. Minimizing potential performance impacts of standby state It is possible to experience degraded performance of database apply (DBAPY) processing after enabling journal standby state. only MIMIX parameters are described in detail. Deciding to use standby state is a trade off between run-time performance and IPL duration. The default value for journal caching is *BOTH. For example. or file end of data. it can cause potentially longer initial program loads (IPL). Journal caching Journal caching is an attribute of the journal that is defined. the performance gain can be significant. close. You can reduce potential impacts by using the Change Recovery for Access Paths (CHGRCYAP) command. This means that neither the journal entries nor their corresponding database records are written to disk until an efficient disk write can be scheduled. the system caches journal entries and their corresponding database records into main storage.restrictions. type the following and press Enter: CHGRCYAP 2. Journal caching can be helpful during batch operations when large numbers of add. offers equivalent and complementary function to the MIMIX parameter Target journal state (TGTSTATE). MIMIX processing of high availability journal performance enhancements You can enable both journal standby state and journal caching using a combination of MIMIX and IBM commands. On a command line. To enable journal standby state or journal caching in a MIMIX environment. It is recommended that you use the default value of *BOTH to perform journal caching on both the source and the target systems. specify *ELIGIBLE to include only eligible access paths in the recovery time specification. Note: While this procedure improves performance. batch operations must usually wait for each new journal entry to be written to disk. available on the IBM command Change Journal (CHGJRN). see IBM’s Redbooks Technote””Journal Caching: Understanding the Risk of Data Loss”. When journal caching is enabled. See “Journal caching” on page 310. journal caching can be used as an alternative. the Journal state (JRNSTATE) parameter. two parameters have been added to the Create Journal Definition (CRTJRNDFN) and 310 . At the Include access paths prompt. Do the following: 1. For more information about journal caching. This usually occurs when the buffer is full. or at the first commit. be aware of the following restrictions documented by IBM: • Do not use these high availability performance enhancements in conjunction with commitment control. When *STANDBY is specified. An additional value. Valid values for the TGTSTATE parameter are *ACTIVE and *STANDBY. When *ACTIVE is specified and the data group associated with the journal definition is journaling on the target system (JRNTGT(*YES)). As such. When journaling is used on the target system. it is recommended to be performed on both (*BOTH) the target system and source system. or both. *SAME. the target journal state is set to active when the data group is started. *BOTH. i5/OS Option 42 . An additional value. Make sure that you are aware of these restrictions before using journal standby state or journal caching in your MIMIX environment. the TGTSTATE parameter specifies the requested status of the target journal.HA Journal Performance. but most journal entries are prevented from being deposited into the target journal. Restrictions of high availability journal performance enhancements MIMIX support of IBM’s high availability performance enhancements has a unique set of restrictions and high availability considerations. is required in order to use MIMIX support of IBM’s high availability performance enhancements. or *SRC. *SAME. The recommended value of *BOTH is the default. The JRNCACHE parameter specifies whether the system should cache journal entries in main storage before writing them to disk. which indicates the JRNCACHE value should remain unchanged. For journals in standby mode. Each system in the replication environment must have this software installed and be up to date with the latest PTFs and service packs applied. Also be aware of the following additional restrictions: 311 . commitment control entries are not sent to or deposited in the journal. When using journal standby state or journal caching. MIMIX support of IBM’s high availability performance enhancements can be configured on the target system even if commitment control is being used on the source system. is valid for the CHGJRNDFN command. Note: MIMIX does not use commitment control on the target system. with the exception of referential constraint types of *RESTRICT. *NONE. Valid values for the JRNCACHE parameter are *TGT. See “Creating a journal definition” on page 192 and “Changing a journal definition” on page 194. • Do not use these high availability performance enhancements in conjunction with referential constraints. is valid for the CHGJRNDFN command. objects are journaled on the target system. Although journal caching can be configured on the target system. which indicates the TGTSTATE value should remain unchanged. source system. Requirements of high availability journal performance enhancements Feature 5117.Configuring for high availability journal performance enhancements Change Journal Definition (CHGJRNDFN) commands: Target journal state (TGTSTATE) and Journal caching (JRNCACHE). Journal caching is also not allowed on remote journals. Do not use MIMIX support of IBM’s high availability performance enhancements in a cascading environment.• Do not change journal standby state or journal caching on IBM-supplied journals. These journal names begin with “Q” and reside in libraries which names also begin with “Q” (not QGPL). Attempting to change these journals results in an error message. • • 312 . Do not place a remote journal in journal standby state. RCVJRNE_delay_values') Notes: • The four RCVJRNE delay values are specified in this string along with the cache size. Type the following command: CHGDTAARA DTAARA(installation_library/MXOBJSND) VALUE('xx. If the data area is not created or does not exist in the MIMIX product library. such as PF.Caching extended attributes of *FILE objects Caching extended attributes of *FILE objects In order to accurately replicate actions against *FILE objects. The maximum size of the cache is controlled though the use of a data area in the MIMIX product library. Specify the cache size (xx). See topic “Increasing data returned in journal entry blocks by delaying RCVJRNE calls” on page 314 for more information. The cache size indicates the number of entries that can be contained in the cache. The result is a potential reduction of CPU consumption by the object send job and a significant performance improvement. Create the data area on the systems on which the object send jobs are running. To configure the extended attribute cache. • Using 00 for the cache size value disables the extended attribute cache. Whenever large volumes of journal entries for *FILE objects are replicated from the security audit journal (system journal). This function can be tailored to suit your environment. the size of the cache defaults to 15. Type the following command: CRTDTAARA DTAARA(installation_library/MXOBJSND) TYPE(*CHAR) LEN(2) 2. 313 . LF or DSPF. it is sometimes necessary to retrieve the extended attribute of a *FILE object. MIMIX caches this information for a fixed set of *FILE objects to prevent unnecessary retrievals of the extended attribute. Valid cache values are numbers 00 through 99. do the following: 1. a small block is defined as any journal entry block consisting of 10 percent of the RCVJRNE block size of 200 Kb. as well as specify the percentage of that block size to use for both a small delay block and a medium delay block in the data area. Medium blocks are then delayed for 1 second assuming the default RDRWAIT value is used. a medium block is defined as any journal entry block containing between 10 and 30 percent of the RCVJRNE block size. also reduces CPU consumption by the object send job. The following defines each segment and includes the number of characters that particular segment can contain: DTAARA VALUE(‘cache_size2.01. Journal entries are received in configurable-sized blocks that have a default size of 99.000 bytes. between 20. Through additional controls added to the MXOBJSND *DTAARA objects within the MIMIX installation library. The RCVJRNE block size is specified in kilobytes. If not specified.001 and 60. unnecessary overhead is created. the default size is 99. See “Caching extended attributes of *FILE objects” on page 313 for related information. which determines how long the previously specified journal entry block is delayed. Doing so increases the probability of receiving a full journal entry block and improves object send performance—reducing the number of RCVJRNE calls while simultaneously increasing the quantity of data returned in each block. let us assume the following: DTAARA VALUE(‘15. medium_multiplier2.999 bytes. This delay. block_size4’) To illustrate the effect of specific delay and multiplier values. ranging from 32 Kb to 4000 Kb. Each block segment is followed by a multiplier value. small_multipler2.999 bytes. These values are added in segments to the string of characters used by the file attribute cache size.02. medium_block_percentage2.Increasing data returned in journal entry blocks by delaying RCVJRNE calls Enhancements have been made to MIMIX to increase the performance of the object send job when a small number of journal entries are present during the Receive Journal Entry (RCVJRNE) call. Understanding the data area format This enhancement allows you to provide byte values for the block size to receive data from RCVJRNE. Similarly. The RDRWAIT default value is 1 second.000 bytes. The duration of the delay is the multiplier value multiplied by the value specified on the Reader wait time (seconds) (RDRWAIT) parameter in the data group definition. small_block_percentage2. or 20. When multiple RCVJRNE calls are performed and each block retrieved is less than 99. you can now specify the size of the block of data received from RCVJRNE and delay the next RCVJRNE call based on a percentage of the requested block size. small journal entry blocks will be delayed for 2 seconds before the next RCVJRNE call. Assuming the RDRWAIT default is in effect. along with the extended file attribute cache capability.10. 314 .30.0200’) In this example.999 bytes (100 Kb -1). 25%=221. If the resulting messages indicate that you are processing full journal entry blocks. Large=46. 60%=5.000 bytes. Medium=60 LVI0001 OM2120 Block Counts: Small=129. there is no need to add a delay to the RCVJRNE call. By default. it is recommended that you contact a Certified MIMIX Consultant for assistance with running object send processing with diagnostic messages enabled.000 bytes. Configuring the RCVJRNE call delay and block values To configure the delay and block values when retrieving journal entry blocks. Full=1 OM2120 File Attr Cache: Size= 30. Making changes to the delay multiplier or altering the small or medium block size specification would probably make sense in this scenario. 50%=4. no delays will be applied to blocks larger than 30 percent of the RCVJRNE block size.000 bytes and the medium block value set to 20. do the following: Note: Prior to configuring the RCVJRNE call delay. Type the following command: CRTDTAARA DTAARA(installation_library/MXOBJSND) TYPE(*CHAR) LEN(20) Note: Although you will see improvements from the file attribute cache with the default character value (LEN(2)). Note: Reviewing these messages can also be helpful once you have changed the default values. In the previous example.999 bytes. Review the set of LVI0001 messages returned as a result. no cache lookup attempts In the above example. Note that a block is considered full when the next journal entry in the sequence cannot fit within the size limitations of the block currently being processed. 15%=56. 636 blocks were sent but only one of the sent blocks were full. Recommendations for changing the block size values are provided in “Configuring the RCVJRNE call delay and block values” on page 315.Range Counts: 40%=10. the RCVJRNE block size is 99. Full=1 LVI0001 OM2120 Using RCVJRNE Block Size (in Kb): 200 LVI0001 OM2120 . to ensure that the object send job is operating efficiently. In this case. Create the data area on the systems on which the object send jobs are running. 90%=1.Increasing data returned in journal entry blocks by delaying RCVJRNE calls Note: Delays are not applied to blocks larger than the specified medium block percentage. 1.Range Counts: 0%=80. or 60. carefully read the information provided in “Understanding the data area format” on page 314 and “Determining if the data area should be changed” on page 315. 70%=3. 2%=28. 20%=161. The following are examples of LVI0001 messages: LVI0001 OM2120 Block Sizes (in Kb): Small=20. Medium=461. Determining if the data area should be changed Before changing the data area. 5%=21. the object send job is already running as efficiently as possible. with the small block value set to 5. 80%=0. 30%=23 LVI0001 OM2120 . enhancements are maximized by 315 . 10%=23. Recommendations for changing the block size values are provided in “Configuring the RCVJRNE call delay and block values” on page 315.01. Making changes to the delay multiplier or altering the small or medium block size specification would probably make sense in this scenario. see “Caching extended attributes of *FILE objects” on page 313.0100’) Note: For information about the cache size.recreating the MXOBJSEND data area as a LEN(20) to use the RCVJRNE call delays.02. 636 blocks were sent but only one of the sent blocks were full. 2. In the above example. CHGDTAARA DTAARA(installation_library/MXOBJSND) VALUE(‘cache_size.10. 316 .30. For each journal entry. MIMIX contains redundancy logic that eliminates multiple journal entries for the same object when the entire object is replicated.Configuring high volume objects for better performance Configuring high volume objects for better performance Some objects. MIMIX then individually applies each *DTAQ entry using the QSNDDTAQ API. Defaults can be used for the other object data group jobs. such as data areas and data queues can have significant activity against them and can cause MIMIX to use significant CPU resource. 317 . you should: • • Place all *DTAQs in the same object-only data group Limit the maximum number of object retrieve jobs for the data group to one. system journal replication processes package all of the entries of the *DTAQ and sends it to the apply system. then several object retrieve jobs could be started (up to the maximum configured) to handle the activity against the *DTAQ. When you configure a data group for system journal replication. One or several programs can use the QSNDDTAQ and QRCVDTAQ APIs to generate thousands of journal entries for a single *DTAQ. If the data group is configured for multiple Object retrieve processing (OBJRTVPRC) jobs. When a numeric value is specified. Each database apply session is evaluated against the threshold independently. the comparison is performed. A numeric value for the CMPRCDCMT parameter defines the maximum number of uncommitted record operations that can exist for files waiting to be applied in an apply session at the time a compare record count request is invoked. When a threshold is specified for the CMPRCDCNT commit threshold policy. If your environment cannot tolerate a long-running request. MIMIX will not attempt to compare members from that apply session. The shipped default values for this policy (CMPRCDCMT parameter) permit record count comparison requests without regard to commit cycle activity on the source system. In such an environment. If the threshold is exceeded. you can specify a numeric value for the CMPRCDCMT parameter for either the MIMIX installation or for a specific data group. Note: Equal record counts suggest but do not guarantee that files are synchronized. as illustrated in the following example. record count comparisons can have a higher number of file members that are not compared. or that can tolerate a long-running comparison. 318 . and can improve performance of #MBRRCDCNT and CMPRCDCNT requests. As a result. If an apply session has not reached the threshold. This is possible in environments that use commitment control with long-running commit transactions that include large numbers (tens of thousands) of record operations within one transaction. it is possible for record counts to be compared for files in one apply session but not be compared in another apply session. indicating that commit cycle activity on the source system prevented active processing from comparing counts of current records and deleted records in the selected member. the results will display the *CMT value for the difference indicator. MIMIX recognizes whether the number of uncommitted record operations for an apply session exceeds the threshold at the time a compare request is invoked. The Set MIMIX Policies (SETMMXPCY) command includes the policy CMPRCDCNT commit threshold policy (CMPRCDCMT parameter) that provides the ability to specify a threshold at which requests to compare record counts will no longer perform the comparison due to commit cycle activity on the source system. a request to run the #MBRRCDCNT audit or the Compare Record Count (CMPRCDCNT) command can be extremely long-running. in some conditions. These policy default values are suitable for environments that do not have the commitment control environment indicated. This must be taken into consideration when using the comparison results to gauge of whether systems are synchronized. This will change the behavior of MIMIX by affecting what is compared.Improving performance of the #MBRRCDCNT audit Environments that use commitment control may find that. The number specified must be representative of the number of uncommitted record operations. Instead. the compare request can be long running when the number of members to be compared is very large and there are uncommitted changes present at the time of the request. files processed by apply sessions A and C are not compared. Table 42.000 50 500 Apply Session Total > 10. Table 42 shows the files replicated by each of the apply sessions used by the data group and the result of comparison.000 0 7. Because of the number of uncommitted record operations present at the time of the request. *CMT Compared Compared Result 319 . Apply Session A B C D Sample results with a policy threshold value of 10.000 > 10.000.000 6. *CMT Not compared.Improving performance of the #MBRRCDCNT audit Example: This example shows the result of setting the policy for a data group to a value of 10.000 0 5.000 < 10. *CMT Compared Compared Not compared. *CMT Not compared. Files Uncommitted Record Operation Per File A01 A02 B01 B02 C01 C02 D01 D02 11.000 Not compared.000.000 < 10. are included. This topic includes several examples. This topic also describes how to configure keyed replication at the data group or file entry level as well as how to verify key attributes. file merging. Requirements and considerations for replication of triggers. “Trigger support” on page 334 describes how MIMIX handles triggers and how to enable trigger support. This topic also describes delete rules for referential constraints that can cause dependent files to change and MIMIX considerations for replication of constraint-induced modifications. “Collision resolution” on page 345 describes available support within MIMIX to automatically resolve detected collisions without user intervention and its requirements. “Handling SQL identity columns” on page 338 describes the problem of duplicate identity column values and how the Set Identity Column Attribute (SETIDCOLA) command can be used to support replication of SQL tables with identity columns. including considerations for synchronizing files with triggers.Configuring advanced replication techniques CHAPTER 16 Configuring advanced replication techniques This chapter describes how to modify your configuration to support advanced replication techniques for user journal (database) and system journal (object) replication. • • • • • System journal replication: The following topics describe advanced techniques for system journal replication: • “Omitting T-ZC content from system journal replication” on page 350 describes considerations and requirements for omitting content of T-ZC journal entries from replicated transactions for logical and physical files. Requirements and limitations of the SETIDCOLA command as well as alternative solutions are included. file sharing. “Configuring to replicate SQL stored procedures and user-defined functions” on • • 320 . broadcasting. User journal replication: The following topics describe advanced techniques for user journal replication: • “Keyed replication” on page 322 describes the requirements and restrictions of replication that is based on key values within the data. “Data distribution and data management scenarios” on page 327 defines and identifies configuration requirements for the following techniques: bi-directional data flow. and cascading. file combining. “Selecting an object retrieval delay” on page 354 describes how to set an object retrieval delay value so that a MIMIX lock on an object does not interfere with your applications. This topic also describes how to define and work with collision resolution classes. “Constraint support” on page 336 identifies the types of constraints MIMIX supports. page 356 describes the requirements for replicating these constructs and how configure MIMIX to replicate them. 321 . • “Using Save-While-Active in MIMIX” on page 358 describes how to change type of save-while-active option to be used when saving objects. You can view and change these configuration values for a data group through an interface such as SQL or DFU. allowing replication to be based on key values within the data instead of by the position of the data within the file. You also need to be aware that data “collisions” can occur when an attempt is made to simultaneously update the same data from two different sources. When the file on the source system is updated. MIMIX user journal replication processes use positional replication. you must use the value *BOTH. However. Key replication support is subject to the requirements and restrictions described. file routing. MIMIX finds the data in the exact location on the target system and updates that data with the changes. If the unique key fields of the database file are updated by applications. User journal replication processes support the update of files by key. You can change from positional replication to keyed replication for database files. If data exists in a file on the source system. some configurations require both beforeimages and after-images. such as file sharing.The access path can be either part of the physical file itself or it can be defined in a logical file dependent on the physical file.MIMIX may need to be configured so that both before and after images of the journal transaction are placed in the journal. It is recommended that you use the Journal image value of *BOTH whenever there are file entries with keyed replication to prevent before images from being filtered out by the database send process.At least one unique access path must exist for the file being replicated.Keyed replication By default. Keyed vs positional replication In data groups that are configured for user journal replication. but you may notice greater CPU usage when MIMIX must search each file for the specified key. Keyed file replication offers a greater level of flexibility. in the file member. Positional replication is recommended for most high availability requirements. Unique access path . The Journal image element of the File and tracking entry options (FEOPT) parameter controls which journal images are placed in the journal. Positional file replication provides the best performance. 322 . Default values result in only an after-image of the record. In positional file replication. default values use positional replication. data on the target system is identified by position. The Journal image value specified in the data group definition is in effect unless a different value is specified for the FEOPT parameter in a file entry or object entry. Keyed replication is best used for more flexible scenarios. or file combining. Requirements for keyed replication Journal images . an exact copy must exist in the same position in a file on the target system. or relative record number (RRN). the journal and journal definition cannot be configured to allow object types to support minimized entry specific data. Restrictions of keyed replication MIMIX does not support keyed replication in data groups that are configured for MIMIX Dynamic Apply. For more information. If you configure a data group for keyed replication. Implementing keyed replication You can implement keyed replication for an entire data group or for individual data group file entries. the data group must be configured so that cooperative processing activity occurs primarily through the system journal. For more information. See “Verifying key attributes” on page 326. The Compare File Data (CMPFILDTA) command cannot compare files that are configured for keyed replication. Ensure the data group is configured so that cooperative processing occurs primarily through the system journal.Keyed replication You can use the Verify Key Attributes (VFYKEYATR) command to determine whether a physical file is eligible for keyed replication. the files are excluded from the comparison and a message indicates that files using *KEYED replication were not processed. Data groups configured for MIMIX Dynamic Apply have *USRJRN specified as the value for the Cooperative Journal (COOPJRN) parameter. see “Minimized journal entry data” on page 307. Attempting to change from keyed to positional replication can result in a mismatch of the relative record numbers (RRN) between the target system and source system. a warning message will be returned that indicates that the position of the file may not match the position of the file on the backup system. the values you define in the data group file entry override the defaults used by the data group for the associated file. Before you change a data group definition to support keyed replication. When keyed replication is in use. MIMIX uses keyed replication as the default for all processing of all associated data group file entries. Changing a data group configuration to use keyed replication You can define keyed replication for a data group when you are initially configuring MIMIX or you can change the configuration later. Attention: If you attempt to change the file replication from *KEYED to *POSITION. If you run the the #FILDTA audit or the CMPFILDTA command against keyed files. see “Checklist: Converting to legacy cooperative processing” on page 138. To use keyed replication for all database replication defined for a data group. Consult your MIMIX administrator to 323 . do the following: a. the following requirements must be met: 1. To replicate files that are updated by key. If you configure individual data group file entries for keyed replication. The files identified by the data group file entries for the data group must be eligible for keyed replication. If the files are not currently journaled correctly. Consult your MIMIX administrator to verify this. If you have modified file entry options on individual data group file entries. Changing a data group file entry to use keyed replication By default. In the data group definition used for replication you must specify the following: • • • • • Data group type of *ALL or *DB. Verify that you have the value you need specified for the Journal image element of the File and tracking ent. for example the data group file entry is not set as described in Step 4. If you want to use keyed replication for one or more individual data group file entries defined for a data group. the values you define in the data group file entry override the defaults used by the data group for the associated file. The data group must be configured so that cooperative processing occurs primarily through the system journal. For more information. see “Checklist: Converting to legacy cooperative processing” on page 138. b. DB journal entry processing must have Before images as *SEND for source send configurations. If the file is not being journaled correctly. Refer to the checklist referenced in Step 1a. c. 2. Start journaling for the file entries using “Starting journaling for physical files” on page 297. 5. data group file entries use the same file entry options as specified in the data group definition. See topic “Verifying Key Attributes” in the Using MIMIX book. If you configure individual data group file entries for keyed replication. you need to end journaling for the file entries defined to the data group. 3. ensure the following: a. you need to ensure that the values used are compatible with keyed replication. Do not continue until this is verified. *SYSJRN for the Cooperative journal (COOPJRN) parameter. Use topic “Ending Journaling” in the Using MIMIX book. For more information. options. b. File and tracking ent. you will need to end journaling for the file entries. Before you change a data group file entry to support keyed replication. see “Checklist: Converting to legacy cooperative processing” on page 138. 4. options must specify *KEYED for the Replication type element.verify this. When using remote journaling. The data group definition used for replication must have a Data group type of 324 . all journal entries are sent. you need the following: 1. *BOTH is recommended. Verify that the files defined to the data group are journaled correctly. 2. 4. When using remote journaling. the data group file entries can use the default value *DGDFT for both Journal image and Replication type. See topic “Verifying Key Attributes” in the Using MIMIX book. The files identified by the data group file entries for the data group must be eligible for keyed replication. 325 . DB journal entry processing must have Before images as *SEND for source send configurations. you need to start journaling for the file entries using “Starting journaling for physical files” on page 297.Keyed replication *ALL or *DB. all journal entries are sent. After you have changed individual data group file entries. • Use topic “Adding a data group file entry” on page 252 to create a new file entry. If you are modifying existing file entries in this way. • Use topic “Changing a data group file entry” on page 253 to modify an existing file entry. The data group file entry must have File and tracking ent. If you are using keyed replication at the data group level. 5. 6. 3. verify that you have the value you need specified for the Journal image (*BOTH is recommended) and specify *KEYED for the Replication type. • Note: You can use any of the following ways to configure data group file entries for keyed replication: • Use either procedure in topic “Loading file entries” on page 246 to add or modify a group of data group file entries. you should specify *UPDADD for the Update option parameter. options set as follows: • To override the defaults from the data group definition to use keyed replication on only selected data group file entries. To verify all files in a library. On a command line. specify *MIMIXDFN for the File prompt and press Enter. 326 . Do one of the following: • • • To verify a file in a library. You can use keyed replication for the file if *BOTH appears in the Replication Type Allowed column. 4. The Verify Key Attributes display appears. Press Enter. 2. specify a file name and a library. Display the spooled file (WRKSPLF command) or use your standard process for printing. verify that the file or files you for which you want to use keyed replication are actually eligible. specify *ALL and a library. Prompts for the Data group definition appear. To verify files associated with the file entries for a data group. If a value appears in the Replication Type Defined column. A spooled file is created that indicates whether you can use keyed replication for the files in the library or data group you specified. Specify the name of the data group that you want to check. type VFYKEYATR (Verify Key Attributes). the file is already defined to the data group with the replication type shown. 3. Do the following to verify that the attributes of a file are appropriate for keyed replication: 1.Verifying key attributes Before you configure for keyed replication. MIMIX implements file sharing among systems defined to the same MIMIX installation. but their implementations and configuration requirements are distinct. You may need to consider the technical aspects of implementing a technique as well as how your business practices may be affected. this support requires a combination of advanced replication techniques as well as customizing. System journal replication processing supports the bi-directional flow of objects between two systems. but it does not support simultaneous (bi-directional) updates to the same object on multiple systems. file sharing.Data distribution and data management scenarios Data distribution and data management scenarios MIMIX supports a variety of scenarios for data distribution and data management including bi-directional data flow. and cascading. collision resolution classes allow you to specify different resolution methods for each collision point. • File sharing is a scenario in which a file can be shared among a group of systems and can be updated from any of the systems in the group. MIMIX provides options within the data group definition and for individual data group file entries for resolving most collision points. and file merging. each system is both a source system and a target system. Additionally. bi-directional data flow is a data sharing technique in which the same named database file can be replicated between databases on two systems in two directions at the same time. To enable file sharing. Often. These techniques require additional planning before you configure MIMIX. MIMIX must be configured to allow bi-directional data flow. Bi-directional requirements: system journal replication To configure system journal replication processes to support bi-directional flow of objects. you need the following: 327 . When MIMIX user journal replication processes are configured for bi-directional data flow. • In user journal replication processing. Also. An example of file sharing is when an enterprise maintains a single database file that must be updated from any of several systems. Consider the following: • • • • • Can each system involved modify the data? Do you need to filter data before sending to it to another system? Do you need to implement multiple techniques to accomplish your goal? Do you need customized exit programs? Do any potential collision points exist and how will each be resolved? MIMIX user journal replication provides filtering options within the data group definition. Configuring for bi-directional flow Both MIMIX user journal and system journal replication processes allow data to flow bi-directionally. MIMIX also supports data distribution techniques such as broadcasting. Updating the same object from two systems at the same time can cause a loss of data integrity. file combining. set the DB journal entry processing (DBJRNPRC) parameter so that its Generated by MIMIX element is set to *IGNORE. In the other data group. • • • 328 . Consider the following: – Can the collision be resolved using the collision resolution methods provided in MIMIX or do you need customized exit programs? See “Collision resolution” on page 345. Bi-directional requirements: user journal replication To configure user journal replication processes to support bi-directional data flow. say that you have an order entry application that updates shared inventory records such as Figure 19. to be replicated back to its original source system. In the other data group. Analyze your environment to determine the potential collision points in your data. Each data group definition should specify *NO for the Allow to be switched (ALWSWT) parameter. If two locations attempt to access the last item in stock at the same time. In one data group. you need the following: • Configure two data group definitions between the two systems. Use topics “Keyed replication” on page 322 and “Verifying key attributes” on page 326 to determine if files can use keyed replication. which location will be allowed to fill the order? Does the other location automatically place a backorder or generate a report? Figure 19. You need to understand how each collision point will be resolved. • Note: In system journal replication. Once an object is replicated to a target system. The files defined to each data group must be configured for keyed replication. This prevents any journal entries that are generated by MIMIX from being sent to the target system and prevents looping. system journal replication processes prevent looping by not allowing the same object.• Configure two data group definitions between the two systems. MIMIX does not support simultaneous updates to the same object on multiple systems and does not support conflict resolution for objects. specify *SYS1 for the Data source (DTASRC) parameter. In one data group. specify *SYS1 for the Data source (DTASRC) parameter. For each data group definition. specify *SYS2 for this parameter. regardless of name mapping. Example of bi-directional configuration to implement file sharing. specify *SYS2 for this parameter. – How will your business practices be affected by collision scenarios? For example. The example in Figure 20 329 . MIMIX implements file combining between multiple source systems and a target system that are defined to the same MIMIX installation. see topic “Configuring for bi-directional flow” on page 327. Will users update the data from only one or both systems? If users can update data from both systems. The way in which data is used can affect the configuration requirements for a file routing or file combining operation. An example of file combining is when many locations within an enterprise update a local file and the updates from all local files are sent to one location to update a composite file. • • File combining is a scenario in which all or partial information from files on multiple systems can be sent to and combined in a single file on a target system. Evaluate the needs for each pair of systems (source and target) separately. Evaluate the requirements for each technique separately for a pair of systems (source and target). Consider the following: • Does the data need to be updated in both directions between the systems? If you need bi-directional data flow. you need to prevent the original data from being returned to its original source system (recursion).Data distribution and data management scenarios Configuring for file routing and file combining File routing and file combining are data management techniques supported by MIMIX user journal replication processes. Is the file routing or file combining scenario a complete solution or is it part of a larger solution? Your complete solution may be a combination of multiple data management and data distribution techniques. MIMIX determines what data from the multiple source files is sent to the target system based on the contents of a journal transaction. In its user journal replication processes. Each technique that you need to implement may have different configuration requirements. you need to prevent it from returning to the system on which it originated. the file combining operation effectively becomes a file routing operation. • • File routing is a scenario in which information from a single file can be split and sent to files on multiple target systems. The user exit program determines what data from the source file is sent to each of the target systems based on the contents 330 . To enable file routing. MIMIX user journal replication must be configured as follows: • • Configure the data group definition for keyed replication.shows file combining from multiple source systems onto a composite file on the management system. In user journal replication processes. To ensure that the data group will perform file combining operations after a switch. After the combining operating is complete. If you allow the data group to be switched (by specifying *YES for Allow to be switched (ALWSWT) parameter) and a switch occurs. See topic “Keyed replication” on page 322. If only part of the information from the source system is to be sent to the target system. Example of file combining To enable file combining between two systems. MIMIX calls a user exit program that makes the file routing decision. you need an exit program that allows the appropriate transactions to be processed regardless of which system is acting as the source for replication. if the combined data will be replicated or distributed again. you need an exit program to filter out transactions that should not be sent to the target system. MIMIX implements file routing between a source system and multiple target systems that are defined to the same MIMIX installation. Figure 20. The example in Figure 21 shows the management system routing only the information relevant to each network system to that system. the file routing operation effectively becomes a file combining operation. An example of file routing is when one location within an enterprise performs updates to a file for all other locations. the paths differ in their implementation. MIMIX supports cascading in both its user journal and system journal replication paths. MIMIX user journal replication processes must be configured as follows: • • • Configure the data group definition for keyed replication. If you allow the data group to be switched (by specifying *YES for Allow to be switched (ALWSWT) parameter) and a switch occurs. Example of file routing To enable file routing. you need an exit program that allows the appropriate transactions to be processed regardless of which system is acting as the source for replication. but only updated information relevant to a location is sent back to that location. However. See topic “Keyed replication” on page 322. The data group definition must call an exit program that filters transactions so that only those transactions which are relevant to the target system are sent to it. Configuring for cascading distributions Cascading is a distribution technique in which data passes through one or more intermediate systems before reaching its destination. Figure 21. 331 .Data distribution and data management scenarios of a journal transaction. To ensure that the data group will perform file routing operations after a switch. you need to use keyed replication. Example of a simple cascading scenario To enable cascading you must have the following: • • Within a MIMIX installation. Note: Once an object is replicated to a target system. To do this. you also need the following: – The data groups should be configured to send journal entries that are generated by MIMIX. specify *SEND for the Generated by MIMIX element of the DB journal entry processing (DBJRNPRC) parameter. Exit programs are required for the • 332 .Data can pass through one intermediate system within a MIMIX installation. Figure 23 shows an example where the Chicago system is a management system in a MIMIX installation that collects data from the network systems and broadcasts the updates to the other participating systems. Figure 23 is a cascading scenario because changes that originate on the Hong Kong system pass through an intermediate system (Chicago) before being distributed to the Mexico City system and other network systems in the MIMIX installation. Configure a data group between the originating system (a network system) to the intermediate (management) system. Cascading may be used with other data management techniques to accomplish a specific goal. When this is the case. Figure 22. Figure 22 shows the basic cascading configuration that is possible within one MIMIX installation. Additional MIMIX installations will allow you to support cascading in scenarios that require data to flow though two or more intermediate systems before reaching its destination. MIMIX system journal replication processes prevent looping by not allowing the same object. MIMIX performs the database updates. the management system must be the intermediate system. to be replicated back to its original source system. For user journal replication. The network systems send unfiltered data to the management system. regardless of name mapping. – If it is possible for the data to be routed back to the originating or any intermediate systems. Configure another data group for the flow from the intermediate (management) system to the destination system. Bi-directional example that implements cascading for file distribution. 333 .Data distribution and data management scenarios data groups acting between the management system and the destination systems and need to prevent updates from flowing back to their system of origin. Figure 23. the object replication will replicate trigger-induced object changes from the source system. However. When positional replication is used and triggers fire on the target system they can cause trigger-induced modifications to the files being replicated. You should prevent the triggers from firing on the target system and replicate the trigger-induced modifications from source to the target system.Trigger support A trigger program is a user exit program that is called by the database when a database modification occurs. Because of this. Trigger programs can be used to make other database modifications which are called trigger-induced database modifications. The value of the relative record number used in the journal entry is used to locate a database record being updated or deleted. the files being updated by these triggers should be replicated using the same apply session as the parent files to avoid lock contention. if non-database changes occur and you are using object replication. How MIMIX handles triggers The method used for handling triggers is determined by settings in the data group definition and file entry options. A slight performance advantage may be achieved by replicating the triggerinduced modifications instead of ignoring them and allowing the triggers to fire. the triggers should not be permitted to fire. Considerations when using triggers You should choose only one of these methods for each data group file entry. triggers should not be allowed to fire on the target system. Which method you use depends on a variety of considerations: • The default replication type for data group file entry options is positional replication. Ignoring trigger-induced modifications found in the replication stream and allowing the triggers to fire on the target system. you may want the triggers to fire on the target system. These trigger-induced modifications can change the relative record number of the records in the file because the relative record numbers of the trigger-induced modifications are not likely to match the relative record numbers generated by the same triggers on the source system. you may choose to allow them to fire on the target system. MIMIX supports database trigger replication using one of the following ways: • • Using IBM i trigger support to prevent the triggers from firing on the target system and replicating the trigger-induced modifications. each file is replicated based on the position of the record within the file. When trigger-induced modifications are made by replicated files to files not replicated by MIMIX. This will ensure that the files that are not replicated receive the same trigger-induced modifications on the target system as they do on the source system. When triggers are allowed to fire on the target system. In this case. With positional replication. When triggers do not cause database record changes. • • • • 334 . you must specify *DATA on the Sending mode parameter on the Synchronize DG File Entry (SYNCDGFE) command. Synchronizing files with triggers When you are synchronizing a file with triggers and you are using MIMIX trigger support. which will use the value indicated for the data group file entry. Enabling trigger support Trigger support is enabled for user journal replication by specifying the appropriate file entry option values for parameters on the Create Data Group Definition (CRTDGDFN) and Change Data Group Definition (CHGDGDFN) commands. triggers will be disabled on the target system during synchronization. If you specify *YES. you can specify if you want the triggers disabled on the target system during file synchronization. A value of *NO will leave triggers enabled. see “About synchronizing file entries (SYNCDGFE command)” on page 439. For more information on synchronizing files with triggers. 335 . and firing the trigger adds additional overhead to database processing. If you already have a trigger solution in place you can continue to use that implementation or you can use the MIMIX trigger support. You can also enable trigger support at a file level by specifying the appropriate file entry options associated with the file. The default is *DGFE. On the Disable triggers on file parameter.Trigger support This is because the database apply process checks each transaction before processing to see if filtering is required. Referential constraints defined with the following delete rules cause dependent files to change: • • *CASCADE: Record deletion in a parent file causes records in the dependent file to be deleted when the parent key value matches the foreign key value. unique.Constraint support A constraint is a restriction or limitation placed on a file. all null capable fields in the foreign key are set to null. Because the parent record was already applied. For those dependent records that meet the preceding criteria. *SETNULL: Record deletion in a parent file updates those records in the dependent file where the value of the parent non-null key matches the foreign key value. There are four types of constraints: referential. With the exception of files that have been placed on hold. For example. however. MIMIX always enables constraints and applies constraint entries. Foreign key fields with the non-null attribute are not updated. these constraint changes will be replicated to the target system. For those dependent records that meet the preceding criteria. removed or changed on files replicated by MIMIX. primary key and check constraints are single file operations transparent to MIMIX. Unique. • Referential constraints with delete rules Referential constraints can cause changes to dependent database files when the parent file is changed. you could use a referential constraint to: • • Ensure when an employee record is added to a personnel file that it has an associated department from a company organization file. the same constraint will be met for the replicated database operation on the target. Referential constraints. MIMIX tolerates mismatched before images or minimized journal entry data CRC failures when applying constraint-generated activity. the foreign key field or fields are set to their corresponding default values. To use this support: • Ensure that your target system is at the same release level or greater than the source system to ensure the target system is able to use all of the IBM i function that is available on the source system. *SETDFT: Record deletion in a parent file updates those records in the dependent file where the value of the parent non-null key matches the foreign key value. ensure the integrity between multiple files. If an earlier IBM i level is installed on the target system the operation will be ignored. • 336 . If a constraint is met for a database operation on the source system. entries with mismatched before images are applied and entries with minimized journal entry data CRC failures are ignored. You must have your MIMIX environment configured for either MIMIX Dynamic Apply or legacy cooperative processing. Empty a shopping cart and remove the order records if an internet shopper exits without placing an order. When constraints are added. primary key and check. 00. 1. Earlier levels of MIMIX provided the Process constraint entries element in the File entry options (FEOPT) parameter. enabling the same constraints on the target system will allow changes to be made to the dependent files. When referential constraints cause changes to dependent files not replicated by MIMIX. 337 . this can be done through automation. This would cause a significant performance impact on large files and could impact switch performance.Constraint support Referential constraint handling for these dependent files is supported through the replication of constraint-induced modifications. which now is removed. MIMIX does not provide the ability to disable constraints because IBM i would check every record in the file to ensure constraints are met once the constraint is reenabled. The considerations for replication of constraint-induced modifications are: • • Files with referential constraints and any dependent files must be replicated by the same apply session.08.0. This element was removed in version 5 service pack 5. Replication of constraint-induced modifications MIMIX always attempts to apply constraint-induced modifications. If the need exists.1 Any previously specified value is now mapped to *YES so that processing always occurs. the value used for the next row added. However. • Nothing prevents identity column values from being generated more than once. Following certain actions which transfer table data from one system to another. 338 . Cycle/No Cycle. including one that is outside of the range defined by the minimum and maximum values. rows can be inserted on the backup system using identity column values other than the next expected value. Any SQL table with an identity column that is replicated by a switchable data group can potentially experience this problem. Cache amount. unique key and set to not cycle. This can occur after a MIMIX switch and after other actions such as certain save/restore operations on the backup system. Journal entries used to replicate inserted rows on the production system do not contain information that would allow the value generator to remain synchronized. in typical usage. This can be any value.the amount by which each new row’s identity column differs from the previously inserted row. the identity column is also a primary. incrementing the value with each insertion. Maximum value. Cycle/No Cycle . also do not keep the value generator synchronized. This can result in the reuse of identity column values which in turn can cause a duplicate key exception.indicates whether or not values cycle from maximum back to minimum. The value generator for the identity column is stored internally with the table. prevents the problem from occurring. Similarly. Several attributes define the behavior of the identity column. This can be a positive or negative value. including: Minimum value. or from minimum to maximum if the increment is negative. This command is useful for handling scenarios that would otherwise result in errors caused by duplicate identity column values when inserting rows into tables. The starting value for the value generator on the backup system is used instead of the next expected value based on the table’s content. This discussion is limited to the following attributes: • • Increment amount . When rows are inserted into the table. if possible. The result is that after a switch to the backup system. Increment amount. Start value . In some cases. a table may have a single numeric column which is designated an identity column.Handling SQL identity columns MIMIX replicates identity columns in SQL tables and checks for scenarios that can cause duplicate identity column values after switching and. the database automatically generates a value for this column. identity columns will need to be processed by manually running the Set Identity Column Attribute (SETIDCOLA) command. the next identity column value generated on the receiving system may not be as expected. Start value. The identity column problem explained In SQL. other actions such as applying journaled changes (APYJRNCHG). After performing a switch to the backup system. run the command on the system on which you performed the restore. If you cannot use the SETIDCOLA command. 339 . it may not restart the identity column at a useful value. SETIDCOLA command limitations In general. By doing this. specify ACTION(*CHECKONLY) on the command. default values on the SETIDCOLA command are appropriate for use following a planned switch to the backup system to ensure that the identity column values inserted on the backup system start at the proper point. Limited support for unplanned switch ." For this scenario. the backup system may not be caught up with all the changes that occurred on the production system. and no cycles are allowed. see “Alternative solutions” on page 340. Careful selection of the value of the INCREMENTS parameter can minimize the likelihood of this problem. Examples of when you may need to run the SETIDCOLA command are: • The SETIDCOLA command can be used to determine whether a data group replicates tables which contain identity columns and report the results. For this scenario. Look in the Database section for the SQL Reference for CREATE TABLE and ALTER TABLE statements. You may want to perform this type of check whenever new tables are created that might contain identity columns. • • • Also. See “Examples of choosing a value for INCREMENTS” on page 342. To do so. run the command from the backup system before starting replication in the reverse direction. See “Checking for replication of tables with identity columns” on page 343. When the SETIDCOLA command is useful Important! The SETIDCOLA command should not be used in all environments. but the value chosen must be valid for all tables in the data group.Handling SQL identity columns Detailed technical descriptions of all attributes are available in the IBM eServer iSeries Information Center. After a restore (RSTnnn command) from a "save of backup machine. Before saving files to tape or other media from the backup system.Following an unplanned switch. the SETIDCOLA command is needed in any environment in which you are attempting to restore from a save that was created while replication processes were running. SETIDCOLA only works correctly for the most typical scenario where all values for identity columns have been generated by the system. you avoid the need to run the command after restoring. For many environments. Its use is subject to the limitations described in “SETIDCOLA command limitations” on page 339. It is recommended that you initially use this capability before setting values. In other scenarios. run the command from the backup system. Using the SETIDCOLA command on the backup system may result in the generation of identity column values that were used on the production system but not yet replicated to the backup system. An application may require that an identity column value never be generated twice. This must be handled manually. In this scenario.000. Because cycles are allowed. The application may also require that the value always locate either the original row or. the identity column values of the deleted rows will be re-generated for newly inserted rows. These application-generated identity values may be outside the minimum and maximum values set for the identity column. the value may be stored in a different table. you have these options. Manually reset the identity column starting point: Following a switch to the backup system. 340 .000. the restart value is reset to the beginning of the range. For example.000 but an application occasionally supplies values in the range of 200. For example. Because the result would be problematic.000.If there are no rows in the table on the backup system.000 through 500. the assumption is that duplicate keys will not be a problem. No rows in backup table . the restart value will be set to the initial start value. you can manually reset the restart value for tables with identity columns. if the row is deleted. Rows deleted on production table . • • • Alternative solutions If you cannot use the SETIDCOLA command because of its known limitations.Optionally. applications can supply identity column values at the time they insert rows into a table. The SETIDCOLA command cannot address this scenario.Not supported -The following scenarios are known to be problematic and are not supported. it must be handled manually. The SQL statement ALTER TABLE name ALTER COLUMN can be used for this purpose. This must be handled manually. given to another application. The SETIDCOLA command cannot address this scenario. data area or data queue. no row at all. the SETIDCOLA command is not recommended for tables which allow application-generated identity values. the ideal starting point would be wherever there is the largest gap between existing values. or given to a customer. Application generated values . a table’s identity column range may be from 1 through 100. If rows with values at the end of the range are deleted and you perform a switch followed by the SETIDCOLA command. The SETIDCOLA command is not recommended for this environment.000. However. Running the SETIDCOLA command on the backup system may result in re-generating values that were previously used. consider the “Alternative solutions” on page 340. it must be handled manually.If an identity column allows cycling and adding a row increments its value beyond the maximum range. unexpected behavior may occur when cycles are allowed and old rows are removed from the table with a frequency such that the identity column values never actually complete a cycle. • Columns that have cycled . If cycling is permitted and the SETIDCOLA command is run. the command would recognize the higher values from the application and would cycle back to the minimum value of 1. If you cannot use the SETIDCOLA command in your environment. The value specified is used for all tables which meet the criteria for processing by the command. Only tables which can be replicated by the specified data group are acted upon. Valid values are 1 through 2. You can specify as many as 30 jobs. *CHECKONLY The command checks for tables which have identity columns. This is the default value. message LVE3E2C will be issued. The data area for the sequence object must be configured for replication through the user journal (cooperatively processed). Be sure to read the information in “Examples of choosing a value for INCREMENTS” on page 342. If you use Lakeview-provided product-level security. If no tables are affected. The Action (ACTION) parameter specifies what action is to be taken by the command. the new restart value determines the identity column value for the next row added to the table. Following an unplanned switch. A table will only be updated by one job. is currently set to one job. The default value.647. the identity column starting values exceed the last values used prior to the switch or save/restore operation. Possible values are: *SET The command checks and sets the attribute of the identity column of each table which meets the criteria. number-of-increments-to-skip Specify the number of increments to skip. Only tables that are identified for replication by the specified data group are addressed. each job can update multiple tables.483. 341 . the minimum authority level for this command is *OPR. when applications are started. SQL sequence objects can be used instead of identity columns. The Number of increments to skip (INCREMENTS) parameter specifies how many increments of the counter which generates the starting value for the identity column to skip. It does not set the attributes of the identity columns. For each table. currently set to 1 increment. Possible values are: *DFT Skips the default number of increments. Following a planned switch where tables are synchronized. you can usually use *DFT. use a larger value to ensure that you skip any values used on the production system that may not have been replicated to the backup system. message LVI3E26 will be issued. The Number of jobs (JOBS) parameter specifies the number of jobs to use to process tables which meet the criteria for processing by the command. If there are affected tables. Sequence objects are implemented using a data area which can be replicated by MIMIX. Careful selection of values can ensure that.147. The result of the check is reported in the job log.Handling SQL identity columns Convert to SQL sequence objects: To overcome the limitations of identity column switching and to avoid the need to use the SETIDCOLA command. The Data group definition (DGDFN) parameter identifies the data group against which the specified action is taken. *DFT. SETIDCOLA command details The Set Identity Column Attribute (SETIDCOLA) command performs a RESTART WITH alteration on the identity column of any SQL tables defined for replication in the specified data group. If any statement fails. Each row added to table A increases the identity value by 1 and each row added to table B increases the identify value by 1. You need to approximate how long it would take for this value to become zero (0) if application activity were to be stopped on the production system. Specifying a higher number of jobs (JOBS) can reduce this time. results in an increment of 500. Evaluation of your environment to determine an appropriate increment value is highly recommended before using the command. if the rate of the fastest file is 1. this value is the size of the backlog. See “When the SETIDCOLA command is useful” on page 339 for details. consider the rate at which each table consumes its available identity values. Account for the needs of the table which consumes numbers at the highest rate. If you have available numbers to use. add a safety factor of at least 100 percent.25) being skipped. This is especially true when affected identity columns do not have indexes over them or when they are referenced by constraints. as well as any backlog in MIMIX processing and the activity causing you to run the command.Usage notes • • The reason you are using this command determines which system you should run it from. The SETIDCOLA library is not deleted so that it can be used for any error analysis. Adding 100% to 250. on the production system the latest value for table A was 75 and the latest value for table B was 30. Prior to a switch. Rows are inserted into table A at a rate of approximately 600 rows per hour. along with any error messages received.000.000 numbers per hour and MIMIX is 15 minutes behind (0. data group ORDERS contains tables A and B. Note: The MIMIX backlog. sometimes called the latency of changes being transferred to the backup system. Rows are inserted into table B at a rate of approximately 20 rows per hour. the value you specify for INCREMENTS needs to result in at least 250 numbers (1000 x 0.000. This command can be long running when many files defined for replication by the specified data group contain identity columns.25 hours). It does not include the time it takes for MIMIX to apply the entry. • • • Examples of choosing a value for INCREMENTS When choosing a value for INCREMENTS. For example. This command creates a work library named SETIDCOLA which is used by the command. RUNSQLSTM produces spooled files showing the ALTER TABLE statements executed. the RUNSQLSTM will also fail. the SETIDCOLA command builds RUNSQLSTM scripts (one for each job specified) and uses RUNSQLSTM in spawned jobs to execute the scripts. Consider the following scenarios: 342 . and return the failing status back to the job where SETIDCOLA is running and an escape message will be issued. is the amount of time from when an operation occurs on the production system until it is successfully sent to the backup system by MIMIX. For example. Internally. Use the DSPDGSTS command to view the Unprocessed entry count for the DB Apply process. The command can be invoked manually or as part of a MIMIX Model Switch Framework custom switching program. specify the data group to check in the following command: SETIDCOLA DGDFN(name system1 system2) ACTION(*CHECKONLY) 2. 1. Message LVI3E26 indicates that no tables were found with identity columns. The next rows added to table A and B will have values of 75+(300*1) = 375 and 30. 2. See “Examples of choosing a value for INCREMENTS” on page 342. since all measurements are approximations or based on historical data. In 15 minutes. From previous experience. as defined in “When the SETIDCOLA command is 343 . Before starting replication in the reverse direction you run the SETIDCOLA command with an INCREMENTS value of 1. You may want to plan for the time required for investigation steps and time to run the command to set values. 3. do the following. You performed an unplanned switch. Message LVE3E2C identifies the number of tables found with identity columns. See “SETIDCOLA command limitations” on page 339. Because replication of all transactions completed before the switch and no users have been allowed on the backup system. Also consider the MIMIX backlog at the time you plan to use the command. the steps you need to perform to set the identity columns of files being replicated by a data group are listed below. you know that the latency of changes being transferred to the backup system is approximately 15 minutes. This suggests an INCREMENTS value of 150. this amount should be adjusted by a factor of at least 100% to 300 to ensure that duplicate identity column values are not generated on the backup system.000 respectively. Scenario 2. See “Checking for replication of tables with identity columns” on page 343. 1. Setting the identity column attribute for replicated files At a high level. respectively. • Checking for replication of tables with identity columns To determine whether any files being replicated by a data group have identity columns.000 + (300*1000)= 330. If the results found tables with identity columns. Rows are inserted into Table A at the highest rate. the backup system has the same values as the production.25 hours). You performed a planned switch for test purposes. Check the job log for the following messages. Run the SETIDCOLA command in check only mode first to determine if you need to set values. Determine what increment value is appropriate for use for all tables replicated by the data group. However. 3. you need to evaluate the tables and determine whether you can use the SETIDCOLA command to set values. Determine whether limitations exist in the replicated tables that would prevent you from running the command to set values.000. approximately 150 rows will have been inserted into Table A (600 rows/hour * 0. 4. From the appropriate system. The next rows added to table A and B will have values of 76 and 31.Handling SQL identity columns • Scenario 1. From the production system. Consider the needs of each table. useful” on page 339 specify a data group and the number of increments to skip in the command: SETIDCOLA DGDFN(name system1 system2) ACTION(*SET) INCREMENTS(number) 344 . The file member is synchronized using copy active file processing. you can specify one or more resolution method to use for each collision point. Automatic synchronization: (*AUTOSYNC) MIMIX attempts to automatically synchronize file members when an error is detected. you can customize what resolution method to use at each collision point. MIMIX flags file collisions as errors and places the file entry on hold. it is used for all 12 of the collision points. • • Additional methods available with CR classes Automatic synchronization (*AUTOSYNC) and held due to error (*HLDERR) are essentially predefined resolution methods. Normal processing will continue for all other members in the file. that method is used for all 12 of the collision points. unless the collision occurred at the compare attributes collision point.Collision resolution Collision resolution Collision resolution is a function within MIMIX user journal replication that automatically resolves detected collisions without user intervention. you can specify how to handle collision resolution at each of the 12 collision points. If the file entry specifies member *ALL. Additionally. the file is synchronized using save and restore processing. If you specify a named collision resolution class in a data group definition or data group file entry. MIMIX uses the next method specified for that collision point. When held due to error is specified in the data group definition or the data group file entry. MIMIX supports the following choices for collision resolution that you can specify in the file entry options (FEOPT) parameter in either a data group definition or in an individual data group file entry: • Held due to error: (*HLDERR) This is the default value for collision resolution in the data group definition and data group file entries. Collision resolution class: A collision resolution class is a named definition which provides more granular control of collision resolution. This results in the journal entries being replicated to the target system but they are not applied to the target database. Some collision points also provide additional methods of resolution that can only be accessed by using a collision resolution class. If the first method specified does not resolve the problem. a temporary file entry is created for the member in error and only that file entry is held. When automatic synchronization is specified in the data group definition or data group file entry. Any data group file entry for which a collision is detected is placed in a "held due to error" state (*HLDERR). With a defined collision resolution class. *AUTOSYNC and *HLDERR are available for use at each collision point. Within a collision resolution class. You can specify multiple methods of collision resolution to attempt at each collision point. You must take action to apply the changes and return the file entry to an active state. In the latter case. The member is put on hold while the database apply process continues with the next transaction. it is used for all 12 of the collision points. When you specify *HLDERR or *AUTOSYNC in a data group definition or a data group file entry. the following resolution methods are also available: • Exit program: (*EXITPGM) A specified user exit program is called to handle the 345 . the transaction is ignored because the record does not exist. The MXCCUSREXT service program is shipped with MIMIX and runs on the target system. copy the RCD field data into the RUP record. If the RUB does not equal the RUP and the RUB does not equal the RCD. This method is available for all collision points. you must have the following: • The data group definition used for replication must specify a data group type of *ALL or *DB. In the following algorithms. The exit program is called on three occasions. If the RUB equals the RUP and the RUB equals the RCD. This call allows the exit program to handle any initialization or set up you need to perform. If multiple collision resolution methods are specified and do not resolve the problem MIMIX will always use *HLDERR as the last resort. If the RUB equals the RUP and the RUB does not equal the RCD.data collision. 346 . If the RUB does not equal the RUP and the RUB equals the RCD. The first occasion is when the data group is started. the exit program is called when the data group is ended. Requirements for using collision resolution To use a collision resolution other than the default *HLDERR. • Applied: (*APPLIED) This method is only available for the update collision point 3 and the delete collision point 1. • Field merge: (*FLDMRG) This method is only available for the update collision point 3. used with keyed replication. fields from the afterimage are merged with the current image of the file to create a merged record that is written to the file. The MXCCUSREXT service program (and your exit program) is called if a collision occurs at a collision point for which you have indicated that an exit program should perform collision resolution actions. The MXCCUSREXT service program dynamically links your exit program. fail the field-level merge. d. placing the file on hold. Each field within the record is checked using the series of algorithms below. these abbreviations are used: RUB = before-image of the source file RUP = after-image of the source file RCD = current record image of the target file a. For delete collision point 1. do not change the RUP field data. c. b. Finally. If certain rules are met. the transaction is ignored if the record to be updated already equals the data in the updated record. For update collision point 3. do not change the RUP field data. • If you plan to use an exit program for collision resolution. specify the value for the type of collision resolution processing you want to use. specify the value for the type of collision resolution processing you want to use. you must first create a named collision resolution class. select option 5 (Work with collision resolution classes) and press Enter. 3. specify the name and library of program to use at the Exit point prompt. 5. – If you want to implement collision resolution for only specific files. Class (CRTCRCLS) display appears. specify a value in the parameter within the data group definition. do the following: 1.Collision resolution • You must specify either *AUTOSYNC or the name of a collision resolution class for the Collision resolution element of the File entry option (FEOPT) parameter. specify *EXITPGM for each of the collision points that you want to be handled by the exit program and specify the name of the exit program. The Work with CR Classes display appears. Note: You can specify more than one method of collision resolution for each prompt by typing a + (plus sign) at the prompt. In the collision resolution class. From the MIMIX Main Menu. the member is placed on hold due to error. *HLDERR is always the last method attempted. Note: Ensure that data group activity is ended before you change a data group definition or a data group file entry. 2. 2. Working with collision resolution classes Do the following to access options for working with collision resolution: 1. From the MIMIX Configuration Menu. At each of the collision point prompts on the display. Specify the value as follows: – If you want to implement collision resolution for all files processed by a data group. Press F1 (Help) to see a description of the collision point. With the exception of the *HLDERR method. 4. select option 11 (Configuration menu) and press Enter. the methods are attempted in the order you specify. At each of the collision point prompts on the second display. type a 1 (Create) next to the blank line at the top of the display and press Enter. If you specified *EXITPGM at any of the collision point prompts. If all other methods fail. Press Page Down to see additional prompts. Creating a collision resolution class To create a collision resolution class. 6. specify a value in the parameter within an individual data group file entry. If the first method you specify does not successfully resolve the collision. then the next method is run. 347 . Specify a name at the Collision resolution class prompt. From the Work with CR Classes display. The Create Collision Res. Verify that the collision resolution class shown on the display is what you want to delete. specify the number of times to try to automatically synchronize a file. Press Page Down to see all of the values. Note: If a file encounters repeated failures. 3. You can specify as many as 3 values for each collision point prompt. Make any changes you need. A confirmation display appears. do the following: 1.7. press Enter. Changing a collision resolution class To change an existing collision resolution class. Page Down to see all of the prompts. Press Enter. 3. If this number is exceeded in the time specified in the Retry time limit. To accept the changes. Deleting a collision resolution class To delete a collision resolution class. From the Work with CR Classes display. Provide the required values in the appropriate fields. 2. type a plus sign (+) in the entry field opposite the phrase "+ for more" and press Enter. Inspect the default values shown on the display and either accept the defaults or change the value. To create the collision resolution class. the file will be placed on hold due to error 8. do the following: 1. 2. Allowing excessive synchronization requests can cause communications bandwidth degradation and negatively impact communications performance. 4. specify the number of maximum number of hours to retry a process if a failure occurs due to a locking condition or an in-use condition. The Display CR Class Details display appears. To expand this field for multiple entries. At the Retry time limit prompt. an error condition that requires manual intervention is likely to exist. type a 4 (Delete) next to the collision resolution class you want and press Enter. At the Number of retry attempts prompt. The Change CR Class Details display appears. 348 . From the Work with CR Classes display. do the following: 1. 2. From the Work with CR Classes display. 5. type a 2 (Change) next to the collision resolution class you want and press Enter. 9. type a 5 (Display) next to the collision resolution class you want and press Enter. press Enter. Displaying a collision resolution class To display a collision resolution class. 2. 1. From the Work with CR Classes display.Collision resolution Printing a collision resolution class Use this procedure to create a spooled file of a collision resolution class which you can print. type a 6 (Print) next to the collision resolution class you want and press Enter. 349 . A spooled file is created with the name MXCRCLS on which you can use your standard printing procedure. The access type field within the T-ZC journal entry indicates what type of change operation occurred. PF38-SRC. Table 43. the T-ZC is a member operation. PF-SRC. Clear Initialize Open Reorganize Remove Rename Add constraint Change constraint Remove constraint These T-ZC journal entries may or may not have a member name associated with them. and LF-38 file types. Change Logical File (CHGLF). These T-ZC journal entries are eligible for replication through the system journal. the T-ZC is assumed to be a file operation. PF38-DTA. Change Object Description (CHGOBJD) X X X X X X X X X Clear member for physical files (CLRPFM) Initialize member for physical files (INZPFM) Opening member for write for physical files Reorganize member for physical files (RGZPFM) Remove member for physical files and logical files (RMVM) Rename member for physical files and logical files (RNMM) Adding constraint for physical files (ADDPFCST) Changing constraint for physical files (CHGPFCST) Removing constraint for physical files (RMVPFCST) Operations that Generate T-ZC Access Type 10 25 30 36 37 38 62 63 64 1. If no member name is associated with the journal entry. Table 43 lists the T-ZC journal entry access types that are generated by PF-DTA. While 350 . If a member name is associated with the journal entry. MIMIX replicates file attributes and file member data for all T-ZC entries generated for logical and physical files configured for system journal replication. Default T-ZC processing: Files that have an object auditing value of *CHANGE or *ALL will generate T-ZC journal entries whenever changes to the object attributes or contents occur. Access Type 1 7 T-ZC journal entry access types generated by file objects. MIMIX provides the ability to prevent replication of predetermined sets of TZC journal entries associated with changes to object attributes or content changes.Omitting T-ZC content from system journal replication For logical and physical files configured for replication solely through the system journal. By default. Change Logical File Member (CHGLFM). LF. Change Physical File Member (CHGPFM). Access Type Description Add Change1 X Operation Type File Member X X Data Add member for physical files and logical files (ADDPFM) Change Physical File (CHGPF). The file must have an object auditing value of *CHANGE or *ALL in order for any T-ZC journal entry resulting from a change operation to be created in the system journal. If COOPDB is *YES. The OMTDTA parameter can also help you reduce the number of transactions that require substantial processing time to replicate.Omitting T-ZC content from system journal replication MIMIX recreates attribute changes on the target system. send. 351 . Omitting T-ZC entries: Through the Omit content (OMTDTA) parameter on data group object entry commands. especially in environments where the replication of file data transactions is not necessary. and data operations in transactions for the access types listed in Table 43 are replicated. This can cause unnecessary replication of data and can impact processing time. it may be desirable to replicate the file layout but not the file members or data. then COOPTYPE cannot specify *FILE.Member and data operations are omitted from replication. The OMTDTA parameter is useful when a file or member’s data does not need to be the replicated. Only file operations in transactions with access type 7 (Change) are replicated. – Omit content (OMTDTA) must be either *FILE or *MBR. *MBR . T-ZC journal entries with access types within the specified set are omitted from processing by MIMIX. File and member operations in transactions for the access types listed in Table 43 are replicated. and restore processes. such as T-ZC journal entries with access type 30 (Open). Each of the following values for the OMTDTA parameter define a set of access types that can be omitted from replication: *NONE . member additions and data changes require MIMIX to replicate the entire object using save. The file for which you want to omit transactions must be identified by a data group object entry that specifies the following: – Cooperate with database (COOPDB) must be *NO when Cooperating object types (COOPTYPE) specifies *FILE. Configuration requirements and considerations for omitting T-ZC content To omit transactions. This is the default value. logical and physical files must be configured for system journal replication and meet these configuration requirements: • • The data group definition must specify *ALL or *OBJ for the Data group type (TYPE). when replicating work files and temporary files. member.Data operations are omitted from replication. All file. *FILE . the data group object entry should also specify *CHANGE or *ALL for the Object auditing value (OBJAUD) parameter. Access type 7 (Change) for both file and member operations are replicated. you can specify a predetermined set of access types for *FILE objects to be omitted from system journal replication.No T-ZCs are omitted from replication. To ensure that changes to the file continue to be journaled and replicated. Object auditing value considerations . Only file operations in transactions for the access types listed in Table 43 are replicated. For example. and 64 (Remove constraint). 62 (Add constraint). 63 (Change constraint). When using MIMIX Dynamic Apply for cooperative processing.When MIMIX evaluates a system journal entry and finds a possible match to a data group object entry which specifies an attribute in its Attribute (OBJATR) parameter. This may affect whether replicated files on the source and target systems are identical. any changes to the file will no longer generate T-ZC entries in the system journal. the file on the target system reflects the original state of the file on the source system when it was retrieved for replication. When using legacy cooperative processing. while most other transactions are replicated by user journal replication. However. it is not retrieved. If the configured value specified for the OBJAUD parameter is higher than the object’s actual value. If the object attribute is not needed to determine the most specific match to a data group object entry. After determining which data group object entry has the most specific match. File attribute transactions are T-ZC journal entries with access types 7 (Change). some T-ZC journal entries for file objects are omitted from system journal replication. see “Managing object auditing” on page 55. recall how a file with an object auditing attribute value of *NONE is processed. the performance of the object send job may improve. system journal replication processes select only file attribute transactions. As a result. Omit content (OMTDTA) and cooperative processing The OMTDTA and COOPDB parameters are mutually exclusive. Legacy cooperative processing replicates only physical data files. If you use the SETDGAUD command to force the object to have an auditing level of *NONE and the data group object entry also specifies *NONE. when OMTDTA is enabled by specifying *FILE or *MBR. According to the configuration 352 .For all library-based objects. When the matching object entry specifies *FILE or *MBR for OMTDTA. Object attribute considerations . For more information about object auditing. Omit content (OMTDTA) and comparison commands All T-ZC journal entries for files are replicated when *NONE is specified for the OMTDTA parameter. MIMIX does not need to consider the object attribute in any other evaluations. These transactions are replicated by system journal replication during legacy cooperative processing. MIMIX will change the object to use the higher value. MIMIX evaluates that entry to determine how to proceed with the journal entry. logical files and physical files (source and data) are replicated primarily through the user journal. However. any subsequent changes to file data are not replicated to the target system. MIMIX allows only a value of *NONE for OMTDTA when a data group object entry specifies cooperative processing of files with COOPDB(*YES) and COOPTYPE(*FILE). For example. After MIMIX replicates the initial creation of the file through the system journal. MIMIX must retrieve the attribute from the object in order to determine which object entry is the most specific match. MIMIX evaluates the object auditing level when starting data a group after a configuration change. files that are configured to omit data will report those omitted attributes as *EC (equal configuration). Running a comparison command without specifying a data group will report all the synchronized-but-not-identical attributes as *NE (not equal) because no configuration information is considered. if *MBR is specified for OMTDTA. When CMPFILDTA is run without specifying a data group. As a result. The file is not identical between source and target systems. which call comparison commands with a data group specified.Omitting T-ZC content from system journal replication information. the synchronized-but-not-identical attributes are reported as *NE (not equal). For example. When CMPFILA is run without specifying a data group. Comparison commands will report these attributes as *EC (equal configuration) even though member data is different. the files are synchronized between source and target systems. the file and member attributes are replicated to the target system but the member data is not. The Compare Object Attributes (CMPOBJA) command can be used to check for the existence of a file on both systems and to compare its basic attributes (those which are common to all object types). when a data group is specified on the command. but the files are not the same. but it is synchronized according to configuration. Consider how the following comparison commands behave when faced with nonidentical files that are synchronized according to the configuration. This command never compares filespecific attributes or member attributes and should not be used to determine whether a file is synchronized. MIMIX audits. the synchronized-but-notidentical file member attributes are reported as *NE (not equal). • The Compare File Attributes (CMPFILA) command has access to configuration information from data group object entries for files configured for system journal replication. The Compare File Data (CMPFILDTA) command uses data group file entries for configuration information. will have the same results. • • 353 . When a data group is specified on the command. any file objects configured for OMTDTA will not be compared. A similar situation can occur when OMTDTA is used to prevent replication of predetermined types of changes. Object retrieval delay considerations and examples You should use care when choosing the object retrieval delay. contention for an object between MIMIX and your applications if the object retrieval processing is delayed for a predetermined amount of time before obtaining a lock on the object to retrieve it for replication. You can reduce. but small enough to allow MIMIX to maintain a suitable high availability environment. If the object retrieval latency time is greater than the configured delay value. Too short a delay may allow MIMIX to retrieve an object before an application is finished with it.The object retrieval delay value is configured to be 3 seconds: • • Object A is created or changed at 9:05:10. A long delay may impact the ability of system journal replication processes to move data from a system in a timely manner. MIMIX will obtain a lock on the object that can prevent your applications from accessing the object in a timely manner. particularly documents (*DOC) and stream files (*STMF). You can specify a delay time from 0 through 999 seconds. or eliminate. MIMIX will not delay and will continue with the object retrieval processing. Example 2 . It retrieves the “last change date/time” attribute from the object and determines that the delay time (object last changed date/time of 9:05:10 + configured delay value of :03 = 9:05:13) is less than the current date/time (9:05:14).Selecting an object retrieval delay When replicating objects. then MIMIX will delay its object retrieval processing until the difference between the time the object was last changed and the current time exceeds the configured delay value. The Object Retrieve job encounters the create/change journal entry at 9:05:14. 354 . You can use the Object retrieval delay element within the Object processing parameter on the change or create data group definition commands to set the delay time between the time the object was last changed on the source system and the time MIMIX attempts to retrieve the object on the source system. Some of your applications may be unable to recover from this condition and may fail in an unexpected manner. the object retrieve job continues normal processing and attempts to package the object. The default is 0. Because the object retrieval delay time has already been exceeded. You should make the value large enough to reduce or eliminate contention between MIMIX and applications. Example 1 . you can override the data group value at the object level by specifying an Object retrieval delay value on the commands for creating or changing data group entries. Although you can specify this value at the data group level.The object retrieval delay value is configured to be 2 seconds: • Object A is created or changed at 10:45:51. If the object retrieval latency time (the difference between when the object was last changed and the current time) is less than the configured delay value. the object retrieve job continues with normal processing and attempts to package the object. Because the object retrieval delay value has been met. It retrieves the “last change date/time” attribute from the object and determines that the delay time (object last changed date/time of 13:20:26 + configured delay value of :04 = 13:20:30) exceeds the current date/time (13:20:27) and delays for 3 seconds to satisfy the configured delay value. the object retrieve job continues with normal processing and attempts to package the object.The object retrieval delay value is configured to be 4 seconds: • • Object A is created or changed at 13:20:26. Because the object retrieval delay value has now been met. The Object Retrieve job encounters the create/change journal entry at 13:20:27. It retrieves the “last change date/time” attribute from the object and determines that the delay time (object last changed date/time of 10:45:51 + configured delay value of :02 = 10:45:53) exceeds the current date/time (10:45:52). While the object retrieve job is waiting to satisfy the configured delay value. • Example 3 . the object retrieve job delays for 1 second to satisfy the configured delay value. the Object Retrieve job again retrieves the “last change date/time” attribute from the object and determines that the delay time (object last changed date/time of 10:45:51 + configured delay value of :02 = 10:45:53) is equal to the current date/time (10:45:53). the Object Retrieve job again retrieves the “last change date/time” attribute from the object and determines that the delay time (object last changed date/time of 13:20:28 + configured delay value of :04 = 13:20:32) is equal to the current date/time (13:20:32). Because the object retrieval delay value has not be met or exceeded. After the delay (at time 13:20:32). After the delay (at time 10:45:53). • • • 355 . the object is changed again at 13:20:28. the Object Retrieve job again retrieves the “last change date/time” attribute from the object and determines that the delay time (object last changed date/time of 13:20:28 + configured delay value of :04 = 13:20:32) again exceeds the current date/time (13:20:30) and delays for 2 seconds to satisfy the configured delay value. After the delay (at time 13:20:30).Selecting an object retrieval delay • The Object Retrieve job encounters the create/change journal entry at 10:45:52. MIMIX replicates these operations correctly. such as CREATE PROCEDURE (create). 356 . For example. To correctly replicate a create operation. The program object usually shares the name of the procedure and resides in the same library with which the procedure is associated. A DROP PROCEDURE statement for an SQL procedure removes the procedure from the catalog and deletes the external program object. Requirements for replicating SQL stored procedure operations The following configuration requirements and restrictions must be met: • Apply any IBM PTFs (or their supersedes) associated with IBM i releases as they pertain to your environment. MIMIX can replicate operations related to stored procedures that are written in SQL (SQL stored procedures). An appropriately configured data group object entry must identify the object to which the stored procedure is associated. and REVOKE PRIVILEGES ON PROCEDURE (authority). it cannot be seen by looking at the library. SQL stored procedures are defined entirely in SQL and may contain SQL control statements.Configuring to replicate SQL stored procedures and user-defined functions DB2 UDB for IBM PowerTM Systems supports external stored procedures and SQL stored procedures. The COMMENT statement cannot be replicated. Log in to Support Central and refer the Technical Documents page for a list of required and recommended IBM PTFs. This information is specifically for replicating SQL stored procedures and user-defined functions. the following statements create program SQLPROC in LIBX and establish it as a stored procedure associated with LIBX: CREATE PROCEDURE LIBX/SQLPROC(OUT NUM INT) LANGUAGE SQL SELECT COUNT(*) INTO NUM FROM FILEX For SQL stored procedures. Because information about the procedure is stored in the database catalog and not the library. GRANT PRIVILEGES ON PROCEDURE (authority). DROP PROCEDURE (delete). An SQL procedure is a program created and linked to the database as the result of a CREATE PROCEDURE statement that specifies the language SQL and is called using the SQL CALL statement. GRANT and REVOKE only affect the associated program object. Use System i Navigator to view the stored procedures associated with a particular library (select Databases > Libraries). an independent program object is created by the system and contains the code for the procedure. name mapping cannot be used for either the library or program name. Procedures are associated with a particular library. • • • • Stored procedures or other system table concepts that have non-deterministic ties to a library-based object cannot be replicated. See “Requirements for replicating SQL stored procedure operations” on page 356. For example: ADDDGOBJE DGDFN(name system1 system2) LIB1(library) OBJ1(*ALL) OBJTYPE(*PGM) 357 .Configuring to replicate SQL stored procedures and user-defined functions To replicate SQL stored procedure operations Do the following: 1. 2. Ensure that the replication requirements for the various operations are followed. Ensure that you have a data group object entry that includes the associated program object. and 3 attempts using the second delay value of 300 seconds). you can specify to have MIMIX attempt saves of DLOs and IFS objects using save-while-active. save-while-active capabilities will be used unless it is disabled. save-while-active is only used when saving *FILE objects. By default. attempts to save any type of object will use a normal save. In addition to providing the ability to enable the use of save-while-active for object types other than *FILE. This assumes that the file being saved does not have uncommitted transactions. MIMIX uses save-while-active with a wait time of 120 seconds on the initial save attempt. If the object cannot be saved after the attempts specified in RTYNBR. After the initial failed save attempt. However. When specifying to use save-while-active. the initial save of the object may fail. or and IFS object. For more information on retry processing. You can configure the save-while-active wait time when specifying to use save-whileactive for the initial save attempt of a *FILE. MIMIX then uses normal (non save-while-active) processing on all subsequent save attempts if the initial save attempt fails. MIMIX delays for the number of seconds specified in the RTYDLYITV1 value. Save-while-active wait time For the default (*FILE objects). This is repeated for the number of times that is specified for the RTYNBR value in the data group definition. If there is conflict for the use of an object between MIMIX and some other process. before retrying the save operation. 3 attempts using the first delay value of 5 seconds. Values for retry processing are specified in the First retry delay interval (RTYDLYITV1) and Number of times to retry (RTYNBR) parameters in the data group definition. If you disable save-while-active. it is not used when saving other library-based object types. The save is then attempted for the number of retries specified in the RTYNBR parameter. or IFS objects.Using Save-While-Active in MIMIX MIMIX system journal replication processes use save/restore when replicating most types of objects. the first attempt to save the object after delaying the amount of time configured for the Second retry delay interval (RTYDLYITV2) 358 . a DLO. this calculates to be 7 save attempts (1 initial attempt. MIMIX will attempt to process the object by automatically starting delay or retry processing using the values configured in the data group definition. then the file may be successfully saved by using a normal (non savewhile-active) save. When such a failure occurs. For the initial save of *FILE objects. Considerations for save-while-active If a file is being saved and it shares a journal with another file that has uncommitted transactions. then MIMIX uses the delay interval value which is specified in the RTYDLYITV2 parameter. MIMIX provides the abilities to control the wait time when using save-while-active or to disable the use of save-while-active for all object types. For the initial default values for a data group. in a time frame of approximately 20 minutes. DLOs. see the parameters for automatic retry processing in “Tips for data group parameters” on page 210. SYS2. 359 . DGSWAT: Save-while-active type. DLOs and IFS objects.Modifying: If you want to modify a data group definition to enable use of save-while-active with a wait time of 30 seconds for files. Normal saves will always be used to save any type of object. such as when passed to the SAVACTWAIT parameter on the SAVOBJ and SAVDLO commands. DGSWAT FROM MIMIX/DM0200P WHERE DGDGN=’MYDGDFN’ AND DGSYS=’SYS1’ AND DGSYS2=’SYS2’ Example . you could use the following statement: UPDATE MIMIX/DM0200P SET DGSWAT=-1 WHERE DGDGN=’MYDGDFN’ AND DGSYS=’SYS1’ AND DGSYS2=’SYS2’ Example . • • Example configurations The following examples describe the SQL statements that could be used to view or set the configuration settings for a data group definition (data group name. All other attempts to save the object will use a normal save. For DLOs and IFS objects. system 1 name. which can be configured using the DLO transmission method under Object processing in the data group definition. the network system will be automatically updated by MIMIX. you could use the following statement: UPDATE MIMIX/DM0200P SET DGSWAT=30 WHERE DGDGN=’MYDGDFN’ AND DGSYS=’SYS1’ AND DGSYS2=’SYS2’ Note: You only have to make this change on the management system. A value of 1 through 99999 indicates that save-while-active is to be used when saving files. Types of save-while-active options MIMIX uses the configuration value (DGSWAT) to select the type of save-while-active option to be used when saving objects. You can specify the following values: • A value of 0 (the default) indicates that save-while-active is to be used when saving files. DGSYS. DLOs and IFS objects.Using Save-While-Active in MIMIX value will also use save-while-active. DLOs or IFS objects. SYS1. with a save-while-active wait time of 120 seconds.Disabling: If you want to modify the values for a data group definition to disable use of save-while-active for a data group and use a normal save. The value specified will be used as the savewhile-active wait time. You can view and change these configuration values for a data group through an interface such as SQL or DFU.Viewing: Use this SQL statement to view the values for the data group definition: SELECT DGDGN. it is recommended that DLOs be replicated using optimized techniques. a normal save will be attempted. system 2 name) of MYDGDFN. Example . DGSYS2. A value of -1 indicates that save-while-active is disabled and is not to be used when saving files. Note: Although MIMIX has the capability to replicate DLOs using save/restore techniques. which provide underlying support for MIMIX AutoGuard. “Report types and output formats” on page 378 describes the output of compare commands: spooled files and output files (outfiles). 360 . use an enhanced set of common parameters and a common processing methodology that is collectively referred to as ‘object selection. and subtree rules. or a combination. object selection parameter. • • • Object selection process It is important to be able to predict the manner in which object selection interacts with your input from a command so that the objects you expect are selected for processing. Object selection supports four classes of objects: files. and DLOs. object selection parameter. granular capability for selecting objects by data group. IFS objects. object order precedence.’ Object selection provides powerful. objects. The following commands use the MIMIX object selection capability: • • • • • • • • • Compare File Attributes (CMPFILA) Compare Object Attributes (CMPOBJA) Compare IFS Attributes (CMPIFSA) Compare DLO Attributes (CMPDLOA) Compare File Data (CMPFILDTA) Compare Record Count (CMPRCDCNT) Synchronize Object (SYNCOBJ) Synchronize IFS Object (SYNCIFS) Synchronize DLO (SYNCDLO) The topics in this chapter include: • “Object selection process” on page 360 describes object selection which interacts with your input from a command so that the objects you expect are selected for processing. The object selection capability provides you with the option to select objects by data group. “Parameters for specifying object selectors” on page 363 describes object selectors and elements which allow you to work with classes of objects “Object selection examples” on page 368 provides examples and graphics with detailed information about object selection processing. or a combination.Object selection for Compare and Synchronize commands CHAPTER 17 Object selection for Compare and Synchronize commands Many of the Compare and Synchronize commands. Object selection process The object selection process takes a candidate group of objects. and produces a list of objects to be processed. Object selection process flow Candidate objects are those objects eligible for selection. candidate objects consist of all objects on the 361 . They are input to the object selection process. Figure 24 illustrates the process flow for object selection. Figure 24. Initially. subsets them as defined by a list of object selectors. In that case. IFS object. Order precedence Object selectors are always processed in a well-defined sequence. The data group entries subset the list of candidate objects for the class to only those objects that are eligible for replication by the data group. The first major selection step is optional and is performed only if a data group definition is entered on the command. data group entries are the source for object selectors. Depending on what is specified on the command. Data group entries represent one of four classes of objects: files. the possible object selectors are 1 to N. The selection parameter is separate and distinct from the data group configuration entries. The remaining candidate objects make up the resultant list of objects to be processed. or both. the set of candidate objects may be narrowed down to objects of a particular class (such as IFS objects). The second major object selection step subsets the candidate objects based on Object selectors from the command’s object selector parameter (file. Object selectors can come from the configuration information for a specified data group. and name mapping for dual-system and single-system environments. The second step then uses the input specified on the object selection parameter to further subset the objects selected by the data group entries. an indicator of whether the objects should be included in or omitted from processing. That intermediate set is input to the second major selection step. or DLO). where N is defined by the number of data group entries. If none are specified. which serve as filters on the object selector. Only those entries that correspond to the class associated with the command are used. object. IFS objects. the object selection parameter can be used independently to select from all objects on the system. Elements provide information about the object such as its name. library-based objects.Object selection for Compare and Synchronize commands system. An object selector identifies an object or group of objects. which is important when an object matches more than one selector. Each object selector consists of multiple object selector elements. If the command specifies a data group and items on the object selection parameter. Based on the command. Note: A single object selector can select multiple objects through the use of generic names and special values such as *ALL. from items specified in the object selector parameter. If no data group is specified on the data group definition parameter. The values specified on the command determine the object selectors used to further refine the list of candidate objects in the class. the data group entries are processed first to determine an intermediate set of candidate objects that are eligible for replication by the data group. one or both steps may occur. 362 . Up to 300 object selectors may be specified on the parameter. See Table 44 for a list of object selector elements by object class. the default is to select all candidate objects. The object selector elements vary by object class. If a data group is specified. MIMIX processing for object selection consists of two distinct steps. so the resulting object list can easily exceed the limit of 300 object selectors that can be entered on a command. and DLOs. Library-based selection allows you to work with files or objects based on object name. or object attribute. Directory-based selection allows you to work with objects based on a IFS object path name and includes a subtree option that determines the scope of directory-based objects to include.Parameters for specifying object selectors Selectors from a data group follow data group rules and are processed in most.to least-specific order. directory-based. the specific object selector elements that you can specify on the command is determined by the class of object. A generic name is a character string that contains one or more characters followed by an asterisk (*). and may describe name mapping for those objects. then the subsequent elements are checked according to their priority. object type. For all classes of objects. Selectors from the object selection parameter are always processed last to first. including 363 . for example. Folder-based selection allows you to work with objects based on DLO path name. In an IFS-based command. you can specify as many as 300 object selectors. all candidate objects that match the generic name are selected. see the following topics: • • • • “How MIMIX uses object entries to evaluate journal entries for replication” on page 92 “Identifying IFS objects for replication” on page 106 “How MIMIX uses DLO entries to evaluate journal entries for replication” on page 111 “Processing variations for common operations” on page 117 Parameters for specifying object selectors The object selectors and elements allow you to work with classes of objects. Object selector elements provide three functions: • Object identification elements define the selected object by name. “Object selection examples” on page 368 illustrates the precedence of object selection. The most specific element is checked for a match first. library name. When a generic name is specified. Object selection supports generic object name values for all object classes. These objects can be library-based. An object selector consists of several elements that identify an object or group of objects. As a general rule when specifying items on an object selection parameter. If a candidate object matches more than one object selector. For each object selector. detailed information about order precedence and priority of elements. member name. For additional. However. first specify selectors that have a broad scope and then gradually narrow the scope in subsequent selectors. include /A/B* and then omit /A/B1. Folder-based selection also includes a subtree object selector. the last matching selector in the list is used. depending on the class of objects with which a particular command works. or folder-based. the elements are checked according to a priority defined for the object class. The elements vary. indicates if those objects should be included in or omitted from processing. These elements allow you to choose a specific name. a value of *ALL results in the selection of files and objects defined to that data group by the respective data group file entries or data group object entries. Name mapping elements are required primarily for environments where objects exist in different libraries or paths. When a data group is also specified on the command. • • • Filtering elements provide additional filtering capability for candidate objects. Class Commands: Object selection parameters and parameter elements by class File CMPFILA. only the objects that reside within the given library are selected.Object selection for Compare and Synchronize commands generic name specifications. SYNCDLO DLO Path Subtree Name Pattern Type Owner Include/Omit System 2 path System 2 name pattern Parameter: Identification elements: Filtering elements: Processing elements: Name mapping elements: 1. CMPRCDCNT1 FILE File Library Member Attribute1 Include/Omit System 2 file1 System 2 library1 Library-based object CMPOBJA. CMPFILDTA. When no data group is specified on the command. or the special value *ALL. Using a generic name. Library name element: The library name element specifies the name of the library that contains the files or objects to be included or omitted from the resultant list of 364 . for example. To process all files within the related selection criteria. File name and object name elements: The File name and Object name elements allow you to identify a file or object by name. Table 44 lists object selection elements by function and identifies which elements are available on the commands. you would specify A* for the object name. Include or omit elements identify whether the object should be processed or explicitly excluded from processing. If you want to work with all objects beginning with the letter A. a generic name. you can select a group of files or objects based on a common character string. SYNCOBJ OBJ Object Library Type Attribute Include/Omit System 2 object System 2 library IFS CMPIFSA. Table 44. SYNCIFS OBJ Path Subtree Name Pattern Type Include/Omit System 2 path System 2 name pattern DLO CMPDLOA. select *ALL for the file or object name. The Compare Record Count (CMPRCDCNT) command does not support elements for attributes or name mapping. specifying *ALL and a library name. a generic name. Directory or folder hierarchy 365 . Refer to the individual commands for detailed information on member processing. The Member element can be a specific name. this element allows you to define a library a specific name. all descendants of the named objects are also selected. or the special value *ALL. Figure 25 illustrates the hierarchical structure of folders and directories prior to processing. which combines the folder path and the DLO name. Object path name (IFS) and DLO path name elements: The Object path name (IFS) and DLO path name elements identify an object or DLO by path name. and is used as the basis for the path. or the special value *ALL. By default. If you specify a data group. only those objects defined to that data group by the respective data group IFS entries or data group DLO entries are selected. or the special value *ALL. Traditionally. Directory subtree and folder subtree elements: The Directory subtree and Folder subtree elements allow you to expand the scope of selected objects and include the descendants of objects identified by the given object or DLO path name. DLOs are identified by a folder path and a DLO name. and subtree examples shown later in this document. if *ALL is used. a generic path. They allow a specific path. a generic name. Figure 25. However. Like the file or object name. the subtree element is *NONE. Note: The library value *ALL is supported only when a data group is specified. Object selection uses an element called DLO path. pattern. see the graphics and examples beginning with “Example subtree” on page 371. the Member element provides a means to select specific members. Member element: For commands that support the ability to work with file members. and only the named objects are selected. For more information.Parameters for specifying object selectors objects. Table 45. the object selector will identify no objects. Table 46. Keep in mind that improper use of the Name pattern element can have undesirable results. Let us assume you specified a path name of /corporate. a subtree of *NONE. IFS objects. DLO type *ALL *DOC *FLR Supported DLO types for CMPDLOA and SYNCDLO Description All documents and folders are selected Documents Folders 366 . Object type element: The Object type element provides the ability to filter objects based on an object type. see the “Example Name pattern” on page 375. only the objects in the file system specified will be included. or the special value *ALL. For more information. however you will need to specify if you want to include objects from other file systems. Since the path name. Object selection will not cross file system boundaries when processing subtrees with IFS objects. only those candidate objects with names beginning with $ that reside in the named DLO path or IFS object path are selected. If you specify a pattern of $*. The list of allowable values varies by object class. see “Supported object types for system journal replication” on page 505. The object type is valid for library-based objects. /corporate. Objects from other file systems do not need to be explicitly excluded. a generic name. see the graphic and examples beginning with “Example subtree for IFS objects” on page 376. or DLOs. The Name pattern element can be a specific name. and symbolic links are selected Directories Stream files Symbolic links Object type *ALL *DIR *STMF *SYMLNK Supported object types for CMPDLOA and SYNCDLO are listed in Table 46. Supported object types for CMPIFSA and SYNCIFS Description All directories. Thus. Supported object types for CMPIFSA and SYNCIFS are listed in Table 45. and pattern of $*. For a list of replicated object types. Name pattern element: The Name pattern element provides a filter on the last component of the object path name. When you specify *ALL. only those object types which MIMIX supports for replication are included. For more information. the Name pattern element is generally most useful when subtree is *ALL.Object selection for Compare and Synchronize commands Directory subtree elements for IFS objects: When selecting IFS objects. does not match the pattern of $*. stream files. and can be a specific value or *ALL. for example. SAVF. and program attributes include CLP and RPG. see the individual commands. LF. This element may be a specific name or the special value *FILE1 for files or *OBJ1 for objects. Generic values are not supported for the system 2 value if a generic value was specified on the Library object selector. These values indicate that the name of 367 . file attributes include PF. Although any value can be entered on the Object attribute element. The attribute can be a specific value. Name mapping is useful when working with multiple sets of files or objects in a dual-system or single-system environment. Omitted entries are not added to the list and are excluded from further processing. Owner element: The Owner element allows you to filter DLOs based on DLO owner. This specification indicates that the name of the library on system 2 is the same as on system 1 and that no name mapping occurs. or *ALL. System 2 object path name and system 2 DLO path name elements: The System 2 object path name and System 2 DLO path name elements support name mapping for the path specified in the Object path name or DLO path name element. Object attribute element: The Object attribute element provides the ability to filter based on extended object attribute. Name mapping is useful when working with two sets of IFS objects or DLOs in different paths in either a dual-system or single-system environment. If the System 2 library element is not a specific name. Instead. Included entries are added to the resultant list and become candidate objects for further processing. If the File or Object element is not a specific name. Refer to the individual commands for the list of supported attributes. This element may be a specific name or the special value *LIB1. Only candidate DLOs owned by the designated user profile are selected.Parameters for specifying object selectors For unique object types supported by a specific command. a generic value. Generic values are not supported for the system 2 value if you specified a generic value for the IFS Object or DLO element. then you must use the default value of *LIB1. System 2 file and system 2 object elements: The System 2 file and System 2 object elements provide support for name mapping. For example. you must choose the default values of *OBJ1 for IFS objects or *DLO1 for DLOs. The Owner element can be a specific name or the special value *ALL. This specification indicates that the name of the file or object on system 2 is the same as on system 1 and that no name mapping occurs. a list of supported attributes is available on the command. providing name mapping between files or objects in different libraries. Generic values are not supported for the system 2 value if a generic value was specified on the File or Object parameter. System 2 library element: The System 2 library element allows you to specify a system 2 library name that differs from the system 1 library name. Include or omit element: The Include or omit element determines if candidate objects or included in or omitted from the resultant list of objects to be processed by the command. then you must use the default value of *FILE1 or *OBJ1. and DSPF. The default provides support for a two-system environment without name mapping. Object selection examples In this section.Object selection for Compare and Synchronize commands the file or object on system 2 is the same as that value on system 1. For simplicity. Table 48. Table 47. The System 2 name pattern element may be a specific name or the special value *PATTERN1. all candidate objects in this example are defined to library LIBX. examples and graphics provide you with detailed information about object selection processing. then you must use the default value of *PATTERN1. Processing example with a data group and an object selection parameter Using the CMPOBJA command. If the Object path name or DLO path name element is not a specific name. Generic values are not supported for the System 2 name pattern element if you specified a generic value for the Name pattern element. let us assume you want to compare the objects defined to data group DG1. and subtree rules. Objects are evaluated against data group entries in the same order of precedence used by replication processes. Object selectors from data group entries for data group DG1 Object A* ABC* Library LIBX LIBX Object type *ALL *FILE Include or omit *INCLUDE *OMIT Order Processed 3 2 368 . Table 48 represents the object selectors based on the data group object entry configuration for data group DG1. System 2 name pattern element: The System 2 name pattern provides support for name mapping for the descendents of the path specified for the Object path name or DLO path name element. This specification indicates that no name mapping occurs. These illustrations show how objects are selected based on specific selection criteria. Object ABC AB A DEF DE D Candidate objects on system Library LIBX LIBX LIBX LIBX LIBX LIBX Object type *FILE *SBSD *OUTQ *PGM *DTAARA *CMD Next. Table 47 lists all candidate objects on your system . object order precedence. Table 51. Perhaps you now want to include or omit specific objects from the filtered candidate objects listed in Table 49. Table 50 shows the object selectors to be processed based on the values specified on the object selection parameter. 369 . Object selectors for CMPOBJA object selection parameter Object *ALL *ALL *ALL Library LIBX LIBX LIBX Object type *OUTQ *SBSD *JOBQ Include or omit *INCLUDE *INCLUDE *OMIT Order Processed 1 2 3 The objects compared by the CMPOBJA command are shown in Table 51. These commands are required to identify or report candidate objects that do not exist. Table 50. Object A AB DEF Objects selected by data group DG1 Library LIBX LIBX LIBX Object type *OUTQ *SBSD *JOBQ Note: Although job queue DEF in library LIBX did not appear in Table 47. it would be added to the list of candidate objects when you specify a data group for some commands that support object selection. Object selectors from data group entries for data group DG1 Object DEF Library LIBX Object type *JOBQ Include or omit *INCLUDE Order Processed 1 The object selectors from the data group subset the candidate object list. This list is internal to MIMIX and not visible to users. These object selectors serve as an additional filter on the candidate objects.Object selection examples Table 48. Object A AB Resultant list of objects to be processed Library LIBX LIBX Object type *OUTQ *SBSD In this example. No data group is specified. Table 49. These are the result of the candidate objects selected by the data group (Table 49) that were subsequently filtered by the object selectors specified for the Object parameter on the CMPOBJA command (Table 50). The input source is a selection parameter. resulting in the list of objects defined to the data group shown in Table 49. the CMPOBJA command is used to compare a set of objects. Thus. Specific entries should be specified last. such as A*. The sequence column identifies the order in which object selectors were entered. The object selectors serve as filters to the candidate objects listed in Table 52. Sequence Entered 1 2 3 4 5 Object selectors entered on CMPOBJA selection parameter Object A* D* ABC* *ALL DEFG Library LIBX LIBX LIBX LIBX LIBX Object type *ALL *ALL *ALL *PGM *PGM Include or omit *INCLUDE *INCLUDE *OMIT *OMIT *INCLUDE Table 54 illustrates how the candidate objects are selected. Table 53. Table 54. Table 52 lists all the candidate objects on your system. The last object selector entered on the command is the first one used when determining whether or not an object matches a selector. generic object selectors with the broadest scope. Object ABC AB A DEFG DEF DE D Candidate objects on system Library LIBX LIBX LIBX LIBX LIBX LIBX LIBX Object type *FILE *SBSD *OUTQ *PGM *PGM *DTAARA *CMD Table 53 represents the object selectors chosen on the object selection parameter. such as ABC*.Object selection for Compare and Synchronize commands The data in the following tables show how candidate objects would be processed in order to achieve a resultant list of objects. Candidate objects selected by object selectors Object DEFG *ALL Library LIBX LIBX Object type *PGM *PGM Include or omit *INCLUDE *OMIT Selected candidate objects DEFG DEF Sequence Processed 5 4 370 . Table 52. should be specified ahead of more specific generic entries. the shaded area shows the objects identified by the combination of the Object path name and Subtree elements of the Object parameter for an IFS command. Circled objects represent the final list of objects selected for processing. Candidate objects selected by object selectors Object ABC* D* A* Library LIBX LIBX LIBX Object type *ALL *ALL *ALL Include or omit *OMIT *INCLUDE *INCLUDE Selected candidate objects ABC D. AB Sequence Processed 3 2 1 Table 55 represents the included objects from Table 54. Table 55. 371 . Object A AB D DE DEFG Resultant list of objects to be processed Library LIBX LIBX LIBX LIBX LIBX Object type *OUTQ *SBSD *CMD *DTAARA *PGM Example subtree In the following graphics.Object selection examples Table 54. DE A. This filtered set of candidate objects is the resultant list of objects to be processed by the CMPOBJA command. a pattern value of *ALL. and an object type of *ALL. and an object type of *ALL.Object selection for Compare and Synchronize commands Figure 26 illustrates a path name value of /corporate/accounting. a subtree specification of *NONE. The candidate objects selected include /corporate/accounting and all descendants. Figure 26. Directory of /corporate/accounting/ Figure 27 shows a path name of /corporate/accounting/*. no additional 372 . a pattern value of *ALL. a subtree specification of *ALL. In this case. Object selection examples filtering is performed on the objects identified by the path and subtree. Figure 27. The candidate objects selected consist of the specified objects only. Subtree *NONE for /corporate/accounting/* 373 . a pattern value of *ALL.Object selection for Compare and Synchronize commands Figure 28 displays a path name of /corporate/accounting/*. a subtree specification of *ALL. Subtree *ALL for /corporate/accounting/* 374 . Figure 28. All descendants of /corporate/accounting/* are selected. and an object type of *ALL. a pattern value of $*. and an object type of *ALL.Object selection examples Figure 29 is a subset of Figure 28. and an object type of *ALL. Figure 29. a pattern value of *ALL. Figure 30 specifies a path name of /corporate/accounting. a subtree specification of *NONE. Figure 29 shows a path name of /corporate/accounting. a subtree specification of *ALL. In this 375 . Subtree *NONE for /corporate/accounting Example Name pattern The Name pattern element acts as a filter on the last component of the object path name. where only the specified directory is selected. only the objects in the file system specified will be included. 376 . Figure 30. only those candidate objects which match the generic pattern value ($123. $236. Pattern $* for /corporate/accounting Example subtree for IFS objects In the following graphic. The non-generic part of a path name indicates the file system to be searched.Object selection for Compare and Synchronize commands scenario. Object selection does not cross file system boundaries when processing subtrees with IFS objects. and $895) are selected for processing. When selecting objects in file systems that contain IFS objects. the shaded areas show file systems containing IFS objects. Directory with a subtree containing IFS objects. Examples of specified paths and objects selected for Figure 31 File system Root file system Root file system in independent ASP PARIS Root file system Objects selected /qsyabc /PARIS/qsyabc None Path specified /qsy* /PARIS/* /PARIS* 377 . . The shaded areas are the file systems. Table 56.Object selection examples Figure 31 illustrates a directory with a subtree that contains IFS objects. Table 56 contains examples showing what file systems would be selected with the path names specified and a subtree specification of *ALL. Figure 31. including the data group value (DGDFN). the object selection list section. and the summary section. the Compare File Data (CMPFILDTA) command.Report types and output formats The following compare commands support output in spooled files and in output files (outfiles): the Compare Attributes commands (CMPFILA. It also provides a legend that provides a description of special values used throughout the report. on the other hand. The level of information in the output is determined by the value specified on the Report type parameter. include details about specific attribute differences. and CMPDLOA commands. objects. number of files. and *ALL. IFS objects or DLOs compared. comparison level (CMPLVL). *SUMMARY does not. Spooled files The spooled output is generated when a value of *PRINT is specified on the Output parameter. The *RRN value allows you to output. and the Check DG File Entries (CHKDGFE) command. the Compare Record Count (CMPRCDCNT) command. report type (RPTTYPE). but you are unsure which system contains the correct data. CMPOBJA. Specifying *ALL for the report type will provide you with information found on both *DIF and *SUMMARY reports. Specifying *ALL for the report type will provide you with information found on all objects and attributes that were compared. First. For the CMPFILA.000 objects that failed to compare. The CMPRCDCNT command supports the *DIF and *ALL report types. The spooled output consists of four main sections—the input or header section. the differences section. attributes to compare (CMPATR). CMPIFSA. The CMPFILDTA supports the *DIF and *ALL report types. In this case. actual attributes compared. the levels of output available are *DIF. These values vary by command. The report type of *DIF includes information on objects with detected differences. The output file. The spooled output is a human-readable print format that is intended to be delivered as a report. CMPOBJA. The report type of *DIF includes information on objects with detected differences. *SUMMARY. 378 . CMPDLOA). as well as *RRN. the *RRN value provides information that enables you to display the specific records on the two systems and to determine the system on which the file should be repaired. Using this value can help resolve situations where a discrepancy is known to exist. however. CMPIFSA. is primarily intended for automated purposes such as automatic synchronization. and number of detected differences. It is also a format that is easily processed using SQL queries. A report type of *SUMMARY provides a summary of all objects compared as well as an object-level indication whether differences were detected. the relative record number of the first 1. using the MXCMPFILR outfile format. the header section of the spooled report includes all of the input values specified on the command. and system 1 and system 2 values. a special value of *INDONLY will be displayed in the value columns. or row. A comparison level value of *DIF will list details only for those objects with detected attribute differences. data group name. which provides a one row summary for each object compared. Following the summary row. each attribute compared is listed—along with the status of the attribute and the attribute value. Outfiles The output file is generated when a value of *OUTFILE is specified on the Output parameter. command name. In the event the attribute compared is an indicator. 379 . and provides details on the objects and attributes compared. the level of output in the output file is dependent on the report type value specified on the Report type parameter. Each command is shipped with an outfile template that uses a normalized database to deliver a self-defined record.Report types and output formats The second section of the report is the object selection list. helps define each row. for every attribute you compare. including the attribute type. The summary row indicates the overall status of the object compared. A summary row precedes the attribute rows. timestamp. The normalized database feature ensures that new object attributes can be added to the audit capabilities without disruption to current automation processing. The detail section is the third section of the report. and will begin with a summary status that indicates whether or not differences were detected. Similar to the spooled output. A report type value of *ALL will list all objects compared. Each row includes an indicator that indicates whether or not attribute differences were detected. Similar to the header section. The fourth section of the report is the summary. The level of detail in this section is determined by the report type specified on the command. A value of *SUMMARY will not include the detail section for any object. This section lists all of the object selection entries specified on the comparison command. Key information. it provides details on the input values specified on the command. The template files for the various commands are located in the MIMIX product library. Each command generates a candidate list of objects on both systems and can detect objects missing from either system. constraints. or characteristics. Together. of the objects within your environment and report on the status of replicated objects. • • • • About the Compare Attributes commands With the Compare Attributes commands (CMPFILA. The topics in this chapter include: • “About the Compare Attributes commands” on page 380 describes the unique features of the Compare Attributes commands (CMPFILA. the compare attributes commands provide robust functionality to help you determine whether your system is in a state to ensure a successful rollover for planned events or failover for unplanned events. the command checks for the existence of the object on the source and target systems and then compares the attributes specified on the command. authority. and CMPDLOA). and CMPDLOA. these command are collectively referred to as the compare attributes commands. deleted records. When used in combination with the automatic recovery features in MIMIX AutoGuard. CMPOBJA. CMPOBJA. “Comparing DLO attributes” on page 393 includes the procedure to compare DLO attributes. CMPIFSA. and Compare DLO Attributes (CMPDLOA). You may already be using the compare attributes commands when they are called by audit functions within MIMIX AutoGuard. the attributes to be compared. database relationships. and the like. CMPIFSA.Comparing attributes CHAPTER 18 Comparing attributes This chapter describes the commands that compare attributes: Compare File Attributes (CMPFILA). The results from the comparisons performed are placed in a report. “Comparing object attributes” on page 387 includes the procedure to compare object attributes. it does check attributes such as record counts. These commands are designed to audit the attributes. and the format in which the resulting report is created. “Comparing IFS object attributes” on page 390 includes the procedure to compare IFS object attributes. Although the CMPFILA command does not specifically compare the data within the database file. ownership. “Comparing file and member attributes” on page 384 includes the procedure to compare the attributes of files and members. Each command offers several unique features as well. 380 . Compare IFS Attributes (CMPIFSA). Compare Object Attributes (CMPOBJA). For each object compared. • CMPFILA provides significant capability to audit file-based attributes such as triggers. you have significant flexibility in selecting objects for comparison. you define a name space—the library for CMPFILA or CMPOBJA. all of the objects of the same class as the command that are within the name space configured for the data group are compared. This parameter is ignored when a data group is specified. respectively. the object selection parameters. the value specified on the Member element is only used when *MBR is also specified on the Comparison level parameter. Detailed information about object selection is available in “Object selection for Compare and Synchronize commands” on page 360. By object selection parameters only: You can compare objects that are not replicated by a data group. Extended attributes are attributes unique to given objects. see “CMPFILA supported object attributes for *FILE objects” on page 383 and “CMPOBJA supported object attributes for *FILE objects” on page 383. including extended attributes. or the directory path for CMPIFSA or CMPDLOA. • Choices for selecting objects to compare You can select objects to compare by using a data group. By specifying *NONE for the data group and specifying objects on the object selection parameters. Object attribute: The Object attribute element enables you to select particular characteristics of an object or file. such as auto-start job entries for subsystems. The CMPIFSA and CMPDLOA commands provide enhanced audit capability for IFS objects and DLOs. the values specified in object selection parameters act as a filter for the items defined to the data group. Comparing these attributes provides you with assurance that files are most likely synchronized. • The CMPOBJA command supports many attributes important to other librarybased objects. • System 2: The System 2 parameter identifies the remote system name. For example. The compare attributes commands do not require active data groups to run.About the Compare Attributes commands and others that check the size of data within a file. • By data group only: If you specify only by data group. • • Unique parameters The following parameters for object selection are unique to the compare attributes commands and allow you to specify an additional level of detail when comparing objects or files. specifying a data group on the CMPIFSA command would compare all IFS objects in the name space created by data group IFS entries associated with the data group. For details. or both. and represents the system to which objects on the local system are compared. since the system 2 381 . By data group and object selection parameters: When you specify a data group name as well as values on the object selection parameters. and provides a level of filtering. Unique File and Object elements: The following are unique elements on the File parameter (CMPFILA command) and Objects parameter (CMPOBJA command): • Member: On the CMPFILA command. There are many cases where a specific comparison attributes are only valid for a particular object type. Comparison attributes not supported by a given object type are ignored. System 1 ASP group and System 2 ASP group (CMPFILA and CMPOBJA only): The System 1 ASP group and System 2 ASP group parameters identify the name of the auxiliary storage pool (ASP) group where objects configured for replication may reside. A value is required if no data group is specified. Comparison level (CMPFILA only): The Comparison level parameter indicates whether attributes are compared at the file level or at the member level. Therefore.Comparing attributes information is derived from the data group.#IFSATR audit” on page 569 “Attributes compared and expected results . For example.#FILATR. For all other object types selected as a result of running the 382 . CMPOBJA supports a large number of object types and related comparison attributes.#DLOATR audit” on page 571 All comparison attributes supported by a specific compare attribute command may not be applicable for all object types supported by the command. auto-start job entries is a valid comparison attribute for object types of subsystem description (*SBSD). such as the create timestamp (CRTTSP) attribute. The extended set of attributes includes the basic set of attributes and some additional attributes. The comparison commands take this factor into consideration and check the creation date for only those objects whose values are retained during replication. The following topics list the supported attributes for each command: • • • • “Attributes compared and expected results . #FILATRMBR audits” on page 556 “Attributes compared and expected results . the creation date established on the source system is not maintained on the target system during the replication process. all supported attributes. Each command provides the ability to select pre-determined sets of attributes (basic or extended). for example. Choices for selecting attributes to compare The Attributes to compare parameter allows you to select which combination attributes to compare. Some objects. Each compare attribute command supports an extensive list of attributes. The ASP group name is the name of the primary ASP device within the ASP group. The basic set of attributes is intended to compare attributes that provide an indication that the objects compared are the same. For example. as well as any other unique combination of attributes that you require. cannot be replicated using IBM's save and restore technology.#OBJATR audit” on page 561 “Attributes compared and expected results . This parameter is ignored when a data group is specified. while avoiding attributes that may be different but do not provide a valid indication that objects are not synchronized. and PF38-DTA Files of type PF38-DTA Files of type PF38-SRC Object attribute *ALL LF LF38 PF PF-DTA PF-SRC PF38 PF38-DTA PF38-SRC CMPOBJA supported object attributes for *FILE objects When you specify a data group to compare. When differences are detected on attributes of such an object. Any value is supported. the CMPFILA command obtains information from the configured data group entries for all PF and LF files and their subtypes. they are reported as *EC (equal configuration) instead of being reported as *NE (not equal). its attribute changes are not replicated. and PF-DTA Files of type PF-DTA Files of type PF-SRC Files of type PF38. Those objects defined to the data group object entries are compared. Table 57 lists the extended attributes for objects of type *FILE that are supported as values on the Object attribute element. configuration data is used when comparing objects that are identified for replication through the system journal. Those files that are within the name space created by data group entries are compared. which represents the entire list of supported attributes. CMPFILA supported extended attributes for *FILE objects Description All physical and logical file types are selected for processing Logical file Files of type LF38 Physical file types. CMPFILA supported object attributes for *FILE objects When you specify a data group to compare.About the Compare Attributes commands report. If a data group is specified on a compare request. The default value on the Object attribute element is *ALL. PF-SRC. 383 . Table 57. If an object’s configured object auditing value (OBJAUD) is *NONE. For *FILE objects configured for replication through the system journal and configured to omit T-ZC journal entries. including PF38. but a list of recommended attributes is available in the online help. the auto-start job entry attribute is ignored for object types that are not of type *SBSD. also see “Omit content (OMTDTA) and comparison commands” on page 352. including PF. PF38-SRC. the CMPOBJA command obtains data group information from the data group object entries. do the following: 1. Verify. At the File prompts. At the Data group definition prompts. e. You can specify as many as 300 object selectors by using the + for more prompt. accept the defaults. From the MIMIX Intermediate Main Menu. For each selector. At the Member prompt. Note: If you have automation programs monitoring escape messages for differences in file attributes. 2. if the file and library names on system 2 are equal to system 1. be aware that differences due to active replication (Step 16) are signaled via a new difference indicator (*UA) and escape message. select option 1 (Compare file attributes) and press Enter. To compare the attributes of files and members. At the File and library prompts. specify the name or the generic value you want. and synchronize menu) and press Enter. b. do one of the following: • To compare attributes for all files defined by the data group file entries for a particular data group definition. At the Include or omit prompt. 384 . To compare files by name only. specify the data group name and continue with the next step. f. At the Object attribute prompt. • • 4. select option 12 (Compare. Otherwise. You can optionally specify that results of the comparison are placed in an outfile. specify *NONE and continue with the next step. d. For more information. Note: The System 2 file and System 2 library values are ignored if a data group is specified on the Data group definition prompts. and Synchronize menu. do the following: a. At the System 2 file and System 2 library prompts. c. specify the value you want. The Compare File Attributes (CMPFILA) command appears. specify the name of the file and library to which files on the local system are compared. see “Object selection for Compare and Synchronize commands” on page 360. specify the data group name and skip to Step 6. Press Enter. See the auditing and reporting topics in this book. you can specify elements for one or more object selectors that either identify files to compare or that act as filters to the files defined to the data group indicated in Step 3.Comparing file and member attributes You can compare file attributes to ensure that files and members needed for replication exist on both systems or any time you need to verify that files are synchronized between systems. 3. accept *ALL to compare the entire list of supported attributes or press F4 to see a valid list of attributes. From the MIMIX Compare. verify. accept *ALL or specify a member name to compare a particular member within a file. To compare a subset of files defined to a data group. At the File to receive output prompts. Press F4 to see a valid list of attributes. specify *BOTH and press Enter. You can also specify *NONE. specify the name of the ASP group that contains objects to be compared on system 2. Otherwise. specify the level of detail for the output report. At the Comparison level prompt.Comparing file and member attributes 5. specify the file and library to receive the output. 10. accept the default to compare files at a file level only. or enter the attributes to exclude from the comparison. Note: This parameter is ignored when a data group definition is specified. At the System 2 ASP group prompt. b. To generate an outfile. Skip to Step 14. 13. 6. accept *NONE to compare all attributes specified in Step 7. At the Attributes to compare prompt. Note: If *FILE is specified. (Press F1 (Help) to see the name of the supplied database file. At the Member to receive output prompt. which indicates that comparisons should occur without consideration for replication in progress. 14. The System 2 parameter prompt appears if you are comparing files not defined to a data group. At the Attributes to omit prompt. specify the name of the database file member to receive the output of the command. 12. specify the name of the remote system to which files on the local system are compared. do one of the following • • • To generate print output. The User data prompt appears if you selected *PRINT or *BOTH in Step 12. specify the name of the ASP group that contains objects to be compared on system 1. specify whether new records should replace existing file members or be added to the existing list. the Member prompt is ignored (see Step 4b). accept *PRINT and press Enter. At the Output member options prompts. Note: This parameter is ignored when a data group definition is specified. or accept *DFT to use the default maximum time of 300 seconds (5 minutes). 385 . specify *MBR to compare files at a member level. accept the default if no objects from any ASP group are to be compared on system 2. specify the maximum amount of time between when a file in the data group changes and when replication of the change is expected to be complete. Otherwise. If necessary. 9. 7. Accept the default to use the command name to identify the spooled output or specify a unique name. 11. Skip to Step 14. Skip to Step 18. accept the default if no objects from any ASP group are to be compared on system 1. At the Replace or add prompt. At the Output prompt. Otherwise. do the following: a. specify *OUTFILE and press Enter. accept *BASIC to compare a pre-determined set of attributes based on whether the comparison is at a file or member level or press F4 to see a valid list of attributes.) 15. 16. At the System 1 ASP group prompt. 8. To generate both print output and an outfile. At the Maximum replication lag prompt. At the Report type prompt. At the Submit to batch prompt. 20. At the Job description and Library prompts. Press Enter continue with the next step. specify the name and library of the job description used to submit the batch request. To submit the job for batch processing. specify *CMD to use the command name to identify the job or specify a simple name.Note: This parameter is only valid when a data group is specified in Step 3. When used as part of shipped rules. press Enter. To start the comparison. the default value is *OMIT since the results are already placed in an outfile. specify whether you want detail messages placed in the job log. The value *INCLUDE places detail messages in the job log. At the Job name prompt. 21. and is the default used outside of shipped rules. 386 . 17. 18. At the Object difference messages prompt. do one of the following: • • If you do not want to submit the job for batch processing. specify *NO and press Enter to start the comparison. 19. accept the default. For more information. Note: The System 2 file and System 2 library values are ignored if a data 387 . specify the data group name and skip to Step 6. if the object and library names on system 2 are equal to system 1. specify the value you want. You can specify as many as 300 object selectors by using the + for more prompt. c. 2. see “Object selection for Compare and Synchronize commands” on page 360. The Compare Object Attributes (CMPOBJA) command appears. accept *ALL or specify a specific object type to compare. At the Object attribute prompt. verify. b. specify the data group name and skip to continue with the next step. do one of the following: • To compare attributes for all objects defined by the data group object entries for a particular data group definition. and synchronize menu) and press Enter. Verify. e. accept the defaults. 3. To compare the attributes of objects.Comparing object attributes Comparing object attributes You can compare object attributes to ensure that objects needed for replication exist on both systems or any time you need to verify that objects are synchronized between systems. and Synchronize menu. be aware that differences due to active replication (Step 15) are signaled via a new difference indicator (*UA) and escape message. From the MIMIX Intermediate Main Menu. For each selector. To compare a subset of objects defined to a data group. select option 12 (Compare. See the auditing and reporting topics in this book. Note: If you have automation programs monitoring escape messages for differences in object attributes. select option 2 (Compare object attributes) and press Enter. At the Include or omit prompt. accept *ALL to compare the entire list of supported attributes or press F4 to see a valid list of attributes. At the Object type prompt. specify *NONE and continue with the next step. At the Object and library prompts. Otherwise. At the Data group definition prompts. specify the name or the generic value you want. you can specify elements for one or more object selectors that either identify objects to compare or that act as filters to the objects defined to the data group indicated in Step 3. d. At the System 2 file and System 2 library prompts. From the MIMIX Compare. You can optionally specify that results of the comparison are placed in an outfile. do the following: a. specify the name of the object and library to which objects on the local system are compared. To compare objects by object name only. • • 4. do the following: 1. At the Object prompts. The User data prompt appears if you selected *PRINT or *BOTH in Step 11. specify the name of the remote system to which objects on the local system are compared. Note: This parameter is ignored when a data group definition is specified. 12. do the following: a. 10. Note: This parameter is only valid when a data group is specified in Step 3. 8. Press Enter. If necessary. Otherwise. Press F4 to see a valid list of attributes. specify the name of the ASP group that contains objects to be compared on system 1. b. At the Replace or add prompt. 6. specify the maximum amount of time between when an object in the data group changes and when replication of the change is expected to be complete. f.) 14. At the Report type prompt. or enter the attributes to exclude from the comparison. (Press F1 (Help) to see the name of the supplied database file. 9. Note: This parameter is ignored when a data group definition is specified. At the File to receive output prompts. specify the name of the ASP group that contains objects to be compared on system 2. Accept the default to use the command name to identify the spooled output or specify a unique name. 7. At the Output prompt. accept *NONE to compare all attributes specified in Step 6. To generate an outfile. At the System 2 ASP group prompt. At the Attributes to omit prompt. accept *PRINT and press Enter. At the Attributes to compare prompt. specify the file and library to receive the output. do one of the following • • • To generate print output.group is specified on the Data group definition prompts. accept the default if no objects from any ASP group are to be compared on system 1. 5. specify *BOTH and press Enter. At the Member to receive output prompt. specify the level of detail for the output report. 11. 388 . To generate both print output and an outfile. The System 2 parameter prompt appears if you are comparing objects not defined to a data group. Skip to Step 13. accept the default if no objects from any ASP group are to be compared on system 2. Skip to Step 17. or accept *DFT to use the default maximum time of 300 seconds (5 minutes). accept *BASIC to compare a pre-determined set of attributes or press F4 to see a valid list of attributes. Otherwise. specify the name of the database file member to receive the output of the command. You can also specify *NONE. Skip to Step 13. specify whether new records should replace existing file members or be added to the existing list. 15. At the Maximum replication lag prompt. 13. At the Output member options prompts. specify *OUTFILE and press Enter. At the System 1 ASP group prompt. which indicates that comparisons should occur without consideration for replication in progress. At the Job name prompt. 17. Press Enter and continue with the next step. press Enter. To submit the job for batch processing. 19. specify *NO and press Enter to start the comparison. When used as part of shipped rules. the default value is *OMIT since the results are already placed in an outfile. To start the comparison. At the Job description and Library prompts. 20. accept *CMD to use the command name to identify the job or specify a simple name. At the Submit to batch prompt. accept the default.Comparing object attributes 16. do one of the following: • • If you do not want to submit the job for batch processing. 18. specify the name and library of the job description used to submit the batch request. 389 . At the Object difference messages prompt. and is the default used outside of shipped rules. specify whether you want detail messages placed in the job log. The value *INCLUDE places detail messages in the job log. At the Include or omit prompt.Comparing IFS object attributes You can compare IFS object attributes to ensure that IFS objects needed for replication exist on both systems or any time you need to verify that IFS objects are synchronized between systems. specify a value if you want to place an additional filter on the last component of the IFS object path name. b. From the MIMIX Compare. accept *ALL or specify the name or the generic value you want. you can specify elements for one or more object selectors that either identify IFS objects to compare or that act as filters to the IFS objects defined to the data group indicated in Step 3. You can specify as many as 300 object selectors by using the + for more prompt. At the Data group definition prompts. do the following: 1. See the auditing and reporting topics in this book. Verify. For each selector. verify. accept *ALL or specify a specific IFS object type to compare. At the Object type prompt. Note: The *ALL default is not valid if a data group is specified on the Data group definition prompts. To compare a subset of IFS objects defined to a data group. Note: If you have automation programs monitoring for differences in IFS object attributes. c. and synchronize menu) and press Enter. select option 12 (Compare. accept *NONE or specify *ALL to define the scope of IFS objects to be processed. specify the value you want. For more information. • • 4. specify the data group name and continue with the next step. The Compare IFS Attributes (CMPIFSA) command appears. do one of the following: • To compare attributes for all IFS objects defined by the data group IFS object entries for a particular data group definition. specify *NONE and continue with the next step. 390 . e. d. 3. To compare the attributes of IFS objects. At the IFS objects prompts. You can optionally specify that results of the comparison are placed in an outfile. do the following: a. 2. At the Name pattern prompt. and Synchronize menu. At the Directory subtree prompt. select option 3 (Compare IFS attributes) and press Enter. see “Object selection for Compare and Synchronize commands” on page 360. be aware that differences due to active replication (Step 13) are signaled via a new difference indicator (*UA) and escape message. specify the data group name and skip to Step 6. At the Object path name prompt. From the MIMIX Intermediate Main Menu. To compare IFS objects by object path name only. 14. If necessary. specify whether you want detail messages placed in the job log. 9. 11.Comparing IFS object attributes f. specify *OUTFILE and press Enter. specify the file and library to receive the output. At the Object difference messages prompt. To generate an outfile. Note: The System 2 object path name and System 2 name pattern values are ignored if a data group is specified on the Data group definition prompts. Press Enter. accept *NONE to compare all attributes specified in Step 6. At the Report type prompt. At the System 2 object path name and System 2 name pattern prompts. specify the name of the remote system to which IFS objects on the local system are compared. When used as part of 391 . At the Output member options prompts. Skip to Step 11. At the Member to receive output prompt. 5. do the following: a. 8. (Press F1 (Help) to see the name of the supplied database file. At the Output prompt. which indicates that comparisons should occur without consideration for replication in progress. specify the name of the database file member to receive the output of the command. 6. or accept *DFT to use the default maximum time of 300 seconds (5 minutes). and is the default used outside of shipped rules. To generate both print output and an outfile. At the Maximum replication lag prompt. The value *INCLUDE places detail messages in the job log. The User data prompt appears if you selected *PRINT or *BOTH in Step 9. specify *BOTH and press Enter. Skip to Step 11. Otherwise. Note: This parameter is only valid when a data group is specified in Step 3. At the Attributes to omit prompt. b. Press F4 to see a valid list of attributes. 7. 13.) 12. or enter the attributes to exclude from the comparison. do one of the following • • • To generate print output. accept *BASIC to compare a pre-determined set of attributes or press F4 to see a valid list of attributes. accept *PRINT and press Enter. At the File to receive output prompts. specify the name of the path name and pattern to which IFS objects on the local system are compared. At the Attributes to compare prompt. specify the maximum amount of time between when an IFS object in the data group changes and when replication of the change is expected to be complete. The System 2 parameter prompt appears if you are comparing IFS objects not defined to a data group. if the IFS object path name and name pattern on system 2 are equal to system 1. You can also specify *NONE. Skip to Step 15. specify whether new records should replace existing file members or be added to the existing list. Accept the default to use the command name to identify the spooled output or specify a unique name. At the Replace or add prompt. g. specify the level of detail for the output report. 10. accept the defaults. At the Submit to batch prompt. 18. 392 . To start the comparison. specify *NO and press Enter to start the comparison. 16. Press Enter continue with the next step. accept the default. do one of the following: • • If you do not want to submit the job for batch processing. 17. the default value is *OMIT since the results are already placed in an outfile. specify the name and library of the job description used to submit the batch request. press Enter. At the Job description and Library prompts.shipped rules. At the Job name prompt. To submit the job for batch processing. accept *CMD to use the command name to identify the job or specify a simple name. 15. verify. At the Folder subtree prompt. At the Name pattern prompt.Comparing DLO attributes Comparing DLO attributes You can compare DLO attributes to ensure that DLOs needed for replication exist on both systems or any time you need to verify that DLOs are synchronized between systems. To compare DLOs by path name only. d. Note: If you have automation programs monitoring escape messages for differences in DLO attributes. To compare a subset of DLOs defined to a data group. do one of the following: • To compare attributes for all DLOs defined by the data group DLO entries for a particular data group definition. c. • • 4. specify *NONE and continue with the next step. At the Data group definition prompts. For more information. From the MIMIX Compare. 2. and Synchronize menu. 393 . See the auditing and reporting topics in this book. At the Owner prompt. do the following: 1. be aware that differences due to active replication (Step 13) are signaled via a new difference indicator (*UA) and escape message. specify the data group name and continue with the next step. Note: The *ALL default is not valid if a data group is specified on the Data group definition prompts. and synchronize menu) and press Enter. At the DLO path name prompt. see “Object selection for Compare and Synchronize commands” on page 360. 3. accept *ALL or specify the name or the generic value you want. At the DLO type prompt. You can specify as many as 300 object selectors by using the + for more prompt. For each selector. do the following: a. accept *NONE or specify *ALL to define the scope of IFS objects to be processed. The Compare DLO Attributes (CMPDLOA) command appears. specify the data group name and skip to Step 6. select option 12 (Compare. From the MIMIX Intermediate Main Menu. At the Document library objects prompts. accept *ALL or specify a specific DLO type to compare. select option 4 (Compare DLO attributes) and press Enter. You can optionally specify that results of the comparison are placed in an outfile. specify a value if you want to place an additional filter on the last component of the DLO path name. b. To compare the attributes of DLOs. e. accept *ALL or specify the owner of the DLO. Verify. you can specify elements for one or more object selectors that either identify DLOs to compare or that act as filters to the DLOs defined to the data group indicated in Step 3. At the Object difference messages prompt. specify the maximum amount of time between when a DLO in the data group changes and when replication of the change is expected to be complete. specify the level of detail for the output report. do one of the following • • • To generate print output. Note: The System 2 DLO path name and System 2 DLO name pattern values are ignored if a data group is specified on the Data group definition prompts. specify the name of the path name and pattern to which DLOs on the local system are compared. if the DLO path name and name pattern on system 2 are equal to system 1. (Press F1 (Help) to see the name of the supplied database file. At the Report type prompt. which indicates that comparisons should occur without consideration for replication in progress. If necessary. or accept *DFT to use the default maximum time of 300 seconds (5 minutes).f. 10. At the Maximum replication lag prompt. The System 2 parameter prompt appears if you are comparing DLOs not defined to a data group. specify the name of the remote system to which DLOs on the local system are compared. h. b. specify *OUTFILE and press Enter. 6. At the File to receive output prompts. Press F4 to see a valid list of attributes. specify whether you want detail messages placed in the job log. accept *PRINT and press Enter. Skip to Step 11. g. 11.) 12. 8. accept the defaults. At the Output prompt. 13. 7. do the following: a. The value *INCLUDE places detail messages in 394 . specify the name of the database file member to receive the output of the command. At the Attributes to compare prompt. You can also specify *NONE. At the Output member options prompts. To generate an outfile. Otherwise. specify the file and library to receive the output. Accept the default to use the command name to identify the spooled output or specify a unique name. 14. specify whether new records should replace existing file members or be added to the existing list. At the Replace or add prompt. To generate both print output and an outfile. At the Include or omit prompt. Skip to Step 11. At the System 2 DLO path name and System 2 DLO name pattern prompts. accept *NONE to compare all attributes specified in Step 6. accept *BASIC to compare a pre-determined set of attributes or press F4 to see a valid list of attributes. At the Attributes to omit prompt. Skip to Step 15. or enter the attributes to exclude from the comparison. 9. specify *BOTH and press Enter. specify the value you want. Note: This parameter is only valid when a data group is specified in Step 3. The User data prompt appears if you selected *PRINT or *BOTH in Step 9. Press Enter. 5. At the Member to receive output prompt. specify the name and library of the job description used to submit the batch request. Press Enter continue with the next step. 17. the default value is *OMIT since the results are already placed in an outfile. At the Job name prompt. accept *CMD to use the command name to identify the job or specify a simple name. At the Job description and Library prompts. do one of the following: • • If you do not want to submit the job for batch processing. At the Submit to batch prompt. 18. press Enter. specify *NO and press Enter to start the comparison. To submit the job for batch processing. 16. To start the comparison. When used as part of shipped rules. 395 . 15. and is the default used outside of shipped rules. accept the default.Comparing DLO attributes the job log. “Advanced subset options for CMPFILDTA” on page 410 describes how to use the capability provided by the Advanced subset options (ADVSUBSET) parameter. as well as comparing records with unique keys.basic procedure (non-active)” on page 415 describes how to compare file data in a data group that is not active.Comparing file record counts and file member data CHAPTER 19 Comparing file record counts and file member data This chapter describes the features and capabilities of the Compare Record Counts (CMPRCDCNT) command and the Compare File Data (CMPFILDTA) command. triggers. use with firewalls. The topics in this chapter include: • • • “Comparing file record counts” on page 396 describes the CMPRCDCNT command and provides a procedure for performing the comparison. “Comparing and repairing file member data . “Comparing and repairing file member data . This topic also describes considerations for security. “Ending CMPFILDTA requests” on page 414 describes how to end a CMPFILDTA request that is in progress and describes the results of ending the job. comparing records that are not allocated.basic procedure” on page 418 describes how to compare and repair file data in a data group that is not active. This command compares the number of current records (*CURRDS) and the number of 396 . and constraints. • • • • • • • • Comparing file record counts The Compare Record Counts (CMPRCDCNT) command allows you to compare the record counts of members of a set of physical files between two systems. “Comparing file member data . “Specifying CMPFILDTA parameter values” on page 404 provides additional information about the parameters for selecting file members to compare and using the unique parameters of this command. “Considerations for using the CMPFILDTA command” on page 400 describes recommendations and restrictions of the command. “Comparing file member data using active processing technology” on page 424 describes how to use active processing to compare file member data. “Comparing file member data using subsetting options” on page 427 describes how to use the subset feature of the CMPFILDTA command to compare a portion of member data at one time.members on hold (*HLDERR)” on page 421 describes how to compare and repair file members that are held due to error using active processing. “Significant features for comparing file member data” on page 399 identifies enhanced capabilities available for use when comparing file member data. the #MBRRCDCNT audit does not have an associated recovery phase. • 3. Any repairs must be undertaken manually. this capability provides a less-intensive means to gauge whether files are likely to be synchronized. Differences detected by this audit appear as not recovered in the Audit Summary user interfaces. The Compare Record Counts (CMPRCDCNT) display appears. To check for file data differences. User journal replication processes must be active when this command is used. To check for attribute differences. use the Compare File Attributes (CMPFILA) command. Members on both systems can be actively modified by applications and by MIMIX apply processes while this command is running. You can specify as many as 300 object selectors by using the + for more prompt for each selector. For more information. To compare file record counts Do the following to compare record counts for an active data group: 1. 2. For each selector. type installation_library/CMPRCDCNT and press F4 (Prompt). Members to be processed must be defined to a data group that permits replication from a user journal. Run the Synchronize DG File Entry (SYNCDGFE) command to correct problems. use the Compare File Data (CMPFILDTA) command.Comparing file record counts deleted records (*NBRDLTRCDS) for members of physical files that are defined for replication by an active data group. For information about the results of a comparison. Unlike other audits. Note: Equal record counts suggest but do not guarantee that members are synchronized. At the Data group definition prompts. in the following ways: • • • In MIMIX Availability Manager. repair actions are available for specific errors when viewing the output file for the audit. specify the data group name and skip to Step 4. do the following: 397 . From a command line. specify the data group name and continue with the next step. do one of the following: • To compare data for all files defined by the data group file entries for a particular data group definition. At the File prompts. The #MBRRCDCNT calls the CMPRCDCNT command during its compare phase. Run the #FILDTA audit for the data group to detect and correct problems. In resource-constrained environments. Journaling is required on the source system. To compare a subset of files defined to a data group. see “Object selection for Compare and Synchronize commands” on page 360. you can specify elements for one or more object selectors to act as filters to the files defined to the data group indicated in Step 2. see “What differences were detected by #MBRRCDCNT” on page 550. 4. To generate an outfile and spooled output that is printed. accept *CMD to use the command name to identify the job or specify a simple name. 12. At the Object difference messages prompt. (Press F1 (Help) to see the name of the supplied database file. b. specify *BOTH. do one of the following: • • • • To generate spooled output that is printed. At the Member to receive output prompt.) 7. At the File to receive output prompts.Comparing file record counts and file member data a. specify the value you want. Press Enter and continue with the next step. If you do not want to generate output. do one of the following: • • If you want all compared objects to be included in the report. At the Replace or add prompt. 11. To start the comparison. c. At the Member prompt. At the Output prompt. 5. do one of the following: • • If you do not want to submit the job for batch processing. At the Submit to batch prompt. At the Report type prompt. 9. press Enter. accept the default. At the Output member options prompts. specify *NONE. b. 8. 10. 6. Press Enter continue with the next step. To generate an outfile. specify *DIF. 398 . accept *ALL or specify a member name to compare a particular member within a file. specify *NO and press Enter to start the comparison. specify the name or the generic value you want. specify whether you want detail messages placed in the job log. Press Enter and continue with the next step. The value *INCLUDE places detail messages in the job log. accept the default. Press Enter and continue with the next step. specify *OUTFILE. Press Enter and skip to Step 9. At the Job description and Library prompts. At the Job name prompt. specify the name and library of the job description used to submit the batch request. specify the file and library to receive the output. specify whether new records should replace existing file members or be added to the existing list. When used as part of shipped rules. specify the name of the database file member to receive the output of the command. do the following: a. accept the default. At the Include or omit prompt. If you only want objects with detected differences to be included in the report. and is the default used outside of shipped rules. *PRINT. the default value is *OMIT since the results are already placed in an outfile. At the File and library prompts. To submit the job for batch processing. Unique features of the CMPFILDTA command include active server technology and isolated data correction capability. these features enable the detection and correction of file members that are not synchronized while applications and replication processes remain active. (In contrast. the Synchronize DG File Entry (SYNCDGFE) command would resynchronize the file by transferring all data for the file from the source system to the target system. In non-active mode. You can also use the CMPFILDTA command interactively or call it from a program. the CMPFILDTA command works cooperatively with the database apply 399 . the CMPFILDTA command provides the ability to resynchronize the file at the record level by sending only the data for the incorrect member to the target system. the command will also repair the target file member if *YES was specified on the Repair parameter. Instead. During active processing of a member. In active mode. CMPFILDTA checks the mismatched records against the activity that is happening on the source system and the apply activity that is occurring on the target. CMPFILDTA will then report the error. This list is not reported. The CMPFILDTA command is called programmatically by MIMIX AutoGuard functions that help you determine whether files are synchronized and whether your MIMIX environment is prepared for switching. processing begins in the same manner. At that time. Two modes of operation are available: active and non-active. the DB apply threshold (DBAPYTHLD) parameter can be used to specify what action CMPFILDTA should take if the database apply session backlog exceeds the threshold warning value configured for the database apply process. however. When files are not synchronized. Repairing data You can optionally choose to have the CMPFILDTA command repair differences it detects in member data between systems. If there is a member that needs repair. CMPFILDTA assumes that all files are quiesced and performs file comparisons and repairs without regard to application or replication activity. Together. performing an internal compare and generating a list of records that are not synchronized.Significant features for comparing file member data Significant features for comparing file member data The Compare File Data (CMPFILDTA) command provides ability to compare data within members of physical files. When members in *HLDERR status are processed.) Active and non-active processing The Process while active (ACTIVE) parameter determines whether a requested comparison can occur while application and replication activity is present. Processing members held due to error The CMPFILDTA command also provides the ability to compare and repair members being held due to error (*HLDERR). File members that are held due to an error can also be compared and repaired. The member then changes to *ACTIVE status if compare and repair processing is successful.CMPFILDTA requires a TCP/IP transfer definition—you cannot use SNA. The CMPFILDTA command cannot compare files configured for *KEYED replication. you should be aware of the information in this topic. and incoming journal entries continue to be applied in forgiveness mode. Keyed replication . multiple “thread groups” break up the file into smaller units of work. restore them to an active state. but then you must override CMPFILDTA to 400 . To repair members in *HLDERR status. To support the cooperative efforts of CMPFILDTA and DBAPY.The file in *HLDERR status has been released. Use the CMPFILA command to determine whether you have a matching set of files and attributes on both systems and use the CMPFILDTA command to compare the actual data within the files.The journal entry backlog has been applied. In the event that compare and repair processing is unsuccessful. SNA environments . When a member held due to error is being processed by the CMPFILDTA command. the entry transitions from *HLDERR status to *CMPRLS to *CMPACT. Parallel processing uses multi-threaded jobs to break up file processing into smaller groups for increased throughput. DBAPY will clear the journal entry backlog by applying the file entries in catch-up mode. the command only supports files configured for *POSITIONAL replication. the member-level entry is set back to *HLDERR. Subsetting and advanced subsetting options provide a significant degree of flexibility for performing periodic checks of a portion of the data within a file. Additional features The CMPFILDTA command incorporates many other features to increase performance and efficiency.Comparing file record counts and file member data (DBAPY) process to compare and repair the file members—and when possible. Recommendations and restrictions It is recommended that the CMPFILDTA command be used in tandem with the CMPFILA command. you must also specify that the repair be performed on the target system and request that active processing be enabled. You can be configured for SNA. *CMPACT .Although you can run the CMPFILDTA command on keyed files. the following transitional states are used for file entries undergoing compare and repair processing: • • *CMPRLS . CMPFILDTA and DBAPY are cooperatively repairing the member previously in *HLDERR status. Considerations for using the CMPFILDTA command Before you use the CMPFILDTA command. This technology can benefit environments with multiple processors as well as systems with a single processor. Rather than having a single-threaded job on each system. you should open at least 10 ports in your firewall—minimally. Using the CMPFILDTA command with firewalls The CMPFILDTA command uses a communications port based on the port number specified in the transfer definition. records are added to make the members the same size. or has exceeded a threshold limit. a distinct escape message is issued. CMPFILDTA starts a remote process using RUNCMD. you must have read access on both systems. Second. If the member to be repaired is the larger of the two members. no error is generated nor is the member placed on error hold. which requires two conditions to be true. One member may have allocated records. If active processing and repair is requested. 401 . When MIMIX replication encounters these situations. only read access is needed. the excess records are deleted. the repair processing would be done by the database apply process. those jobs will fail. For example. ports 5001 through 5010. Comparing allocated records to records not yet allocated In some situations. CMPFILDTA builds upon the RUNCMD support in MIMIX. if the port number in your transfer definition is 5000 and you want to run 10 CMPFILDTA jobs at once. For more information. while the corresponding records of the other member are not yet allocated. If the member to be repaired is the smaller of the two members.Do not compare data using active processing technology if the apply process is 180 seconds or more behind. you may wish to monitor these escape messages specifically. however. you must open the equivalent number of ports in your firewall. members differ in the number of records allocated. the user profile of the job that is invoking CMPFILDTA must exist on the remote system and have the same password on the remote system as it does on the local system.Considerations for using the CMPFILDTA command refer to a transfer definition. Apply threshold and apply backlog . write access on the system to be repaired may also be necessary when active technology is not used. In this case. If one or more members differ in the manner described above. To compare file data. If you use CMPFILDTA in a CL program. see “System-level communications” on page 140. If you attempt to run more jobs than there are open ports. First. When using the repair function. If you need to run simultaneous CMPFILDTA jobs. Security considerations You should take extra precautions when using CMPFILDTA’s repair function. as it is capable of accessing and modifying data on your system. the user profile must have appropriate read or update access to the members to be compared or repaired. Table 58. update. and delete Update. Triggers should be disabled if this action is not desired by the user. insert. and delete Update. active triggers. and constraints If members being repaired have unique keys. An updated or insert repair action that results in one or more duplicate key exceptions automatically results in the deletion of records with duplicate keys. Table 58 describes the interaction of triggers with CMPFILDTA repair and active processing. and delete Avoiding issues with triggers It is possible to avoid potential trigger restrictions.Comparing file record counts and file member data Comparing files with unique keys. CMPFILDTA and trigger support Trigger activation group (ACTGRP) *NEW NAMED or *CALLER *NEW *NEW *NEW NAMED or *CALLER CMPFILDTA Repair on system (REPAIR) Any value Any value *NONE Any value other than *NONE Any value other than *NONE Any value CMPFILDTA Process while active (ACTIVE) Any value Any value Any value *NO *YES Any value CMPFILDTA support Not supported Supported Supported Not supported Supported Supported Trigger type Read Read Update. insert. special care should be taken. any compare or repair action causes the applicable trigger to be invoked. If triggers are enabled. If repair action is specified. Attention: If an attempt is made to use one of the unsupported situations listed in Table 58. insert. You will see a CEE0200 information message in the job log shortly before the job ends. or constraints. insert. and delete triggers are invoked as records are repaired. and delete Update. Note: The records that could be deleted include those outside the subset of records being compared. insert. specifying the ACTGRP(*CALLER) or 402 . You can use any one of the following techniques. which are listed in the preferred order: • Recreate the trigger program. When a compare is specified. the job that invokes the trigger will end abruptly. You may also see an MCH2004 message. read triggers are invoked as records are read. triggers. Deletion of records with duplicate keys is not recorded in the outfile statistics. Like triggers. use the 403 . or “set default” can cause records in other tables to be modified or deleted as a result of a repair action. a repair action may be prevented due to referential integrity constraints. a delete rule of “cascade”. Because of this. the remote CMPFILDTA job uses the run priority of the local CMPFILDTA job. Job priority When run. the run priority of either CMPFILDTA job is superseded if a CMPFILDTA class object (*CLS) exists in the installation library of the system on which the job is running. It will not be possible for CMPFILDTA repair processing to add a row to the employee table if the corresponding parent row is not present in the department table. Repairing the parent department table first may present its own problems. Otherwise. and then again for the dependant table. See the IBM Database Programming manual (SC41-5701) for more information on referential integrity. CMPFILDTA uses the priority of the local job to set the priority of the remote job. Note: Use the Change Job (CHGJOB) command on the local system to modify the run priority of the local job. the row deletion may fail if the employee table still contains records corresponding to the department to be deleted. Consider the case where a foreign key is defined between a “department” table and an “employee” table.Considerations for using the CMPFILDTA command ACTGRP(NAMED) • • • • • • Use the Update Program (UPDPRG) command to change to ACTGRP(NAMED) Disable trigger programs on the file Use the Synchronize Objects (SYNCOBJ) command rather than CMPFILDTA Use the Synchronize Data Group File Entries (SYNCDGFE) command rather than CMPFILDTA Use the Copy Active File (CPYACTF) command rather than CMPFILDTA Save and restore outside of MIMIX Referential integrity considerations Referential integrity enforcement can present complex CMPFILDTA repair scenarios. CMPFILDTA may not be able to make all repairs. or “set default”. However. so that both jobs have the same run priority. “set null”. you should use CMPFILDTA to repair parent tables before using CMPFILDTA to repair dependant tables. To set the remote job to run at a different priority than the local job. If CMPFILDTA attempts to delete a row in the department table and the delete rule for the constraint is “restrict”. The referential integrity constraint requires that records in the employee table only be permitted if the department number of the employee record corresponds to a row in the department table with the same department number. Such constraints should use a delete rule of “cascade”. “set null”. so you must issue the command once for the parent table. Note that the order you specify the tables on the CMPFILDTA command is not necessarily the order in which they will be processed. In other situations. or both. the list of candidate objects to compare is determined by the data group configuration. Table 59. the object selection parameters. To prevent this from occurring. you can use the Change TCP/IP Attributes (CHGTCPA) command to change the TCP Keep Alive (TCPKEEPALV) value so that it is lower than the network inactivity timeout value. causing the CMPFILDTA job to end. there may be an extended period of communications inactivity.Comparing file record counts and file member data Create Class (CRTCLS) command to create a *CLS object for the job you want to change. CMPFILDTA and network inactivity When the CMPFILDTA command processes large object selection lists. Specifying file members to compare The CMPFILDTA command allows you to work with physical file members only. the network timeout will terminate the communications session. including PF. You can select the files to compare by using a data group. If the period of inactivity exceeds the timeout value of any network inactivity timer in effect. PF-SRC. and PF-DTA Files of type PF-DTA Object attribute PF PF-DTA 404 . The Object attribute element on the File parameter enables you to select particular characteristics of a file. Detailed information about object selection is available in “Object selection for Compare and Synchronize commands” on page 360. CMPFILDTA supported extended attributes for *FILE objects Description Physical file types. • • By data group only: If you specify only by data group. Specifying CMPFILDTA parameter values This topic provides information about specific parameters of the CMPFILDTA command. you define a name space on the each system from which a list of candidate objects is created. By specifying *NONE for the data group and specifying file and member information on the object selection parameters. the values specified in object selection parameters act as a filter for the items defined to the data group. By object selection parameters only: You can compare file members that are not replicated by a data group. Table 59 lists the extended attributes for objects of type *FILE that are supported as values for the Object attribute element • By data group and object selection parameters: When you specify a data group name as well as values on the object selection parameters. If you specify *NO for the Process while active parameter in combination with repairing the file. File entry status: The File entry status parameter provides options for selecting members with specific statuses. Refer to the “Process while active” section. *DFT is the same as *NO. local. CMPFILDTA supported extended attributes for *FILE objects Description Files of type PF-SRC Files of type PF38. However. target. it is always best to perform active repairs during a period of low activity. The *NO option should be used when the files being compared are not actively being updated by either application activity or MIMIX replication activity. Note: *TGT and *SRC are only valid when a data group is specified. system 2. All file repairs are handled directly by CMPFILDTA. uses a mechanism that retries comparison activity until it detects no interference from active files. Note: Do not compare data using active processing technology if the apply process is 180 seconds or more behind. all file repairs are routed through the data group and require that the data group is active. or has exceeded a threshold limit. Three values are allowed on the Process while active parameter—*DFT. and *YES. CMPFILDTA allows you to select the system on which the repair should be made. or you can specify the system definition name. *NO. For efficiency’s sake. File repairs can be performed on system 1. the default value of *DFT is equivalent to *YES. Specifying *NO for the Process while active parameter is the recommended option for running in a quiesced environment. however. it assumes there is no application activity and MIMIX replication is current.Specifying CMPFILDTA parameter values Table 59. 405 . the data group apply process must be configured not to lock the files on the apply system. *YES is only allowed when a data group is specified and should be used when the files being compared are actively being updated by application activity or MIMIX replication activity. If a data group is not specified. CMPFILDTA. source. If a data group is specified. you cannot select *SRC when *YES is specified for the Process while active parameter. and PF38-DTA Files of type PF38-DTA Files of type PF38-SRC Object attribute PF-SRC PF38 PF38-DTA PF38-SRC Tips for specifying values for unique parameters The CMPFILDTA command includes several parameters that are unique among MIMIX commands. This parameter allows you to indicate whether compares should be made while file activity is taking place. Process while active: CMPFILDTA includes while-active support. PF38-SRC. This configuration can be accomplished by specifying *NO on the Lock on apply parameter of the data group definition. In this case. including members held due to error (*HLDERR). Repair on system: When you choose to repair files that do not match. including PF38. When used in combination with an active data group. For more information. To specify 1. This value allows you to compare a selected number of records at the end of all selected members. restore them to an active state. Subsetting option: The Subsetting option parameter provides a robust means by which to compare a subset of the data within members. If *ALL is specified. use *RANGE. In this situation. *ACTIVE. the Records at end of file parameter specifies how many trailing records are compared. all data within all selected files is compared. use *ENDDTA. The ASP group name is the name of the primary ASP device within the ASP group. The value *ACTIVE processes only those members that are active1. If you select *ENDDTA. *ALL. see the section titled “Records at end of file. you can compare a random sample using *ADVANCED. When *HLDERR is specified. Several options are available on this parameter: *ALL. and *HLDERR.Comparing file record counts and file member data When members in *HLDERR status are processed. use *ADVANCED. For more information. You must be running on OS V5R2 or greater to use these parameters. only member-level entries being held due to error are selected for processing.” Advanced subsetting can be used to audit your entire database over a number of days or to request that a random subset of records be compared. or *RANGE. 406 . The other options compare only a subset of the data. *ENDDTA. is primarily modified with insert operations. only recently inserted data needs to be compared. see the “Subset range” section. *ADVANCED. When a member. the value you select will determine which additional elements are used when comparing data. A data group must also be specified on the command or the parameter is ignored. The File entry status parameter was introduced in V4R4 SPC05SP2. If you want to preserve previous behavior. The following are common scenarios in which comparing a subset of your data is preferable: • • • • If you only need to check a specific range of records. To repair members held due to error using *ALL or *HLDERR. and no additional subsetting is performed. The default value. In some instances. specify STATUS(*ACTIVE). indicates that all supported entry statuses (*ACTIVE and *HLDERR) are included in compare and repair processing. you must also specify that the repair be performed on the target system and request that active processing be used. This parameter is ignored when a data group is specified. If time does not permit a full comparison. such as a history file. *RANGE indicates that the Subset range parameter will be used to specify the subset of records to be compared. the CMPFILDTA command works cooperatively with the database apply (DBAPY) process to compare and repair members held due to error—and when possible. If you do not have time to perform a full comparison all at once but you want all data to be compared over a number of days. System 1 ASP group and System 2 ASP group: The System 1 ASP group and System 2 ASP group parameters identify the name of the auxiliary storage pool (ASP) group where objects configured for replication may reside. Valid values for the File entry status parameter are *ALL. These elements allow you to specify a range of records to compare. and continues through until the end of the larger member. Thus.Specifying CMPFILDTA parameter values advanced subsetting select *ADVANCED. 407 . The Last record element can be specified as *LAST or as a relative record number. The ENDDTA value is always applied to the smaller of the System 1 and System 2 members. If some records are selected by both by the ENDDTA parameter and another subsetting option. records in the member are compared up to. When *NONE is specified. those records are only processed once. records in the member are compared beginning with the first record. This parameter is also valid if values other than *ENDDTA were specified in the Subsetting option. all members are compared using the same relative record number range. see “Advanced subset options for CMPFILDTA” on page 410. and including. Two elements are included. Subset range: Subset range is enabled when *RANGE is specified on the Subsetting option parameter. records at the end of the members are not compared unless they are selected by other subset criteria. using the range specification is usually only useful for a single member or a set of members with related records. Advanced subset options: The Advanced subset options (ADVSUBSET) provides the ability to use sophisticated comparison techniques. For detailed information and examples. both records at the end of the file as well as any additional subsetting options factor into the compare. Records at end of file: The Records at end of file (ENDDTA) parameter allows you to compare recently inserted data without affecting the other subsetting criteria. In this case. In the case of *LAST. First record and Last record. as described in the “Subsetting option” section. If you specified *ENDDTA in the Subsetting option parameter. In the case of *FIRST. If more than one member is selected for processing. The First record element can be specified as *FIRST or as a relative record number. only those records specified in the Records at end of file parameter will be processed. If one system has 1000 records while the other has 1100. relative records 801-1100 would be checked. For more information see “Advanced subset options for CMPFILDTA” on page 410. Let us assume that you specify 200 for the ENDDTA value. To compare particular records at the end of each member. The relative record numbers of the last 200 records of the smaller file are compared as well as the additional 100 relative record numbers due to the difference in member size. Using the Records at end of file parameter in daily processing can keep you from missing records that were inserted recently. the last record. The Records at end of file parameter can be specified as *NONE or number-ofrecords. you must specify the number of records. as indicated in the “Subsetting option” section. System to receive output The System to receive output (OUTSYS) parameter indicates the system on which the output will be created. the outfile will be updated as the database apply encounters journal entries relating to possible mismatched records. Re-issued messages will not have the original “from” and “to” program information. CMPFILDTA generates a batch immediate job to do the bulk of the processing. outfiles and files to be compared may not reside in QTEMP. you need to be aware of the following issues when a batch immediate job is generated: • • The identity of the job will be issued in a message in the original job. In this case. For additional details. Interactive and batch processing On the Submit to batch parameter. A batch immediate job is not processed through a job queue and is identified with a job type of BCI on the WRKACTJOB screen. Similarly. the original job waits for the batch immediate job to complete and re-issues any messages generated by CMPFILDTA. complete outfile information is only available if the System to receive output parameter indicates that the output file is on the data group target system. see “Report types and output formats” on page 378. the *YES default submits a multi-thread capable batch job. if CMPFILDTA is issued from a batch job whose ALWMLTTHD attribute is *NO. When *NO is specified for the parameter. and the contents of the reported differences are similar to that provided for other MIMIX compare commands. These parameters are available by pressing F10 (Additional parameters). you must view the job log of the generated job to determine this information. Canceling the interactive request will not cancel the batch immediate job. output format. The Wait time (seconds) parameter can be used to ensure that all such outfile updates are complete before the command completes. 408 . • • • Using the additional parameters The following parameters allow you to specify an additional level of detail regarding CMPFILDTA command processing. Interactive jobs are not permitted to have multiple threads. Since the batch immediate job cannot access the interactive job’s QTEMP library. By default. which are required for CMPFILDTA processing. Instead. even when CMPFILDTA is issued from a multi-thread capable batch job. In cases where a batch immediate job is generated. and type of processing The options for selecting processing method. Thus. a batch immediate job will also be spawned.Comparing file record counts and file member data Specifying the report type. output. Escape messages created prior to the final message will be converted to diagnostic messages. When Output is *OUTFILE and Process while active is *YES. the output is created on the local system. If no data group was specified. multiple threads may be utilized to improve performance. 409 . for example. the value *CALC does not calculate more than 25 thread groups. You can specify from 1 to 100 thread groups. The default. If your data group is configured for SNA. will determine the number of thread groups automatically. override the SNA configuration by specifying the name of the transfer definition on the command. The actual number of threads used in the comparison is based on the result of the formula 2x + 1. If a data group was specified. When *CALC is specified. any repair actions that have not been completed are lost. or the default *NOMAX. Continuing processing when the apply process has a large backlog may adversely affect performance of the CMPFILDTA job and its ability to compare a file with an excessive number of outstanding entries. Therefore. The number of threads used during setup will not exceed the total number of threads used for primary compare processing. CMPFILDTA processing waits the specified time for all pending compare operations processed through the MIMIX replication path to complete. During active processing. *NOMAX should only be used in exceptional circumstances. the default uses the transfer definition associated with the data group. To maximize processing efficiency. the *NOMAX default is highly recommended. The value *NOMAX allows the compare and repair action to continue even when the database apply threshold has been reached. If active processing is enabled and a wait time is specified. In most cases. *CALC. Wait time (seconds): The Wait time (seconds) value is only valid when active processing is in effect and specifies the amount of time to wait for active processing to complete. depending on the number of members selected for processing. Number of thread groups: The Number of thread groups parameter indicates how many thread groups should be used to perform the comparison. where x is the value specified or the value calculated internally as the result of specifying *CALC. You can specify from 0 to 3600 seconds. If you increase the number of thread groups in order to reduce processing time. The default value *END stops the requested compare and repair action when the database apply threshold is reached. only one thread will be used. When using this parameter. The CMPFILDTA command requires that you have a TCP/IP transfer definition for communication with the remote system.Specifying CMPFILDTA parameter values Transfer definition: The default for the Transfer definition parameter is *DFT. the CMPFILDTA command displays a message showing the value calculated as the number of thread groups. the transfer definition associated with system 2 is used. DB apply threshold: The DB apply threshold parameter is only valid during active processing and requires that a data group be specified. The parameter specifies what action CMPFILDTA should take if the database apply session backlog exceeds the threshold warning value configured for the database apply process. Note: Thread groups are created for primary compare processing only. During setup. you also increase processor and memory use. it is important to balance the time required for processing against the available resources. However. The second 10 percent.Comparing file record counts and file member data Change date: The Change date parameter provides the ability to compare file members based on the date they were last changed or restored on the source system. if a member contains 1000 records on Monday. which is omitted from results when the requested report type is *DIF. Note: Exercise caution when specifying actual date and time values. A specified timestamp that is later than the start of the last audit can result in one or more file members not being compared. it is always best to compare a random representative sampling of data. to be processed on Tuesday. as the following example demonstrates. These techniques provide additional assurance that files are replicated correctly. but have the requirement to assure that all data is compared over the course of a week. However. Advanced subsetting makes it simple to accomplish this task by comparing 10 percent of your data each weeknight and completing the remaining 50 percent over the weekend. Using the advanced CMPFILDTA capability. All available dates are considered when determining whether to include or exclude a file member. The shipped default value is *ALL. let us assume you have a limited batch window. If the audit level is lower. will contain records 410 . you can divide this work over a number of days. Any member changed between the time of its last audit and the specified timestamp will not be compared and therefore cannot be reported if it is not synchronized. perhaps the member has grown to 1500 records. Members that have not been updated or restored since the specified timestamp will not be compared. The *AUDIT value can only be used if audit level *LEVEL30 was in effect at the time the last audit was performed. You do not have time to run a total compare everyday. the compare start timestamp of the #FILDTA audit is used in the determination. The Advanced subset options also provides this capability. By Tuesday. The audit level is available by displaying details for the audit (WRKAUD command). When *AUDIT is specified. For example. records 1 through 100 will be compared on Monday. The command must specify a data group when this value is used. the last changed and last restored timestamps are ignored by the decision process. the value specified for Time is ignored. Advanced subset options for CMPFILDTA You can use the Advanced subset options (ADVSUBSET) parameter on the Compare File Data (CMPFILDTA) command for advanced techniques such as comparing records over time and comparing a random sample of data. When *ALL or *AUDIT is specified for Date. For example. an error message is issued. Only members changed or restored after the specified date and time will be processed. This parameter specifies the date and time that MIMIX will use in determining whether to process a file member. These members are identified in the output by a difference indicator value of *EQ (DATE). The recommended values for this parameter are either *ALL or *AUDIT. If you wish to compare all records over the course of a few days. Advanced subset options are applied independently for each member processed. These bins are numbered from 1 up to the number specified (N). Records 101 through 150 will not get checked at all. Interleave: The Interleave factor specifies the mapping between the relative record number and the bin number. It also permits a full compare to be partitioned into multiple CMPFILDTA requests that. Records that were once assigned to bin 2 may in the future be assigned to bin 1. The Number of subsets element is the number of approximately equal-sized bins to define. It also allows a specified range of these subsets to be compared. in combination. A specific Interleave value is preferable in this case. The advanced subset function assigns the data in each member to multiple nonoverlapping subsets in one of two ways. the mapping also changes. For example: Table 60. records in each member are divided on a percentage basis. Interleave *NONE Member A on Monday Total records in member: Number of subsets (bins): Interleave: Records assigned to bin 1: Records assigned to bin 2: Records assigned to bin 3: 30 3 *NONE 1-10 11-20 21-30 Member A on Tuesday 45 3 *NONE 1-15 16-30 31-45 Note that when the total number of records in a member changes. Using bytes. The Interleave element specifies the manner in which members are assigned to a bin.Advanced subset options for CMPFILDTA 151 through 300. To use advanced subsetting. Once the last bin is 411 . If you specify *NONE. There are two approaches that can be used. assures that all data that existed at the time of the first request is compared. You must specify at least one bin. the changing mapping may cause you to miss records. Each record is assigned to one of these bins. Advanced subsetting provides you with an alternative that does not skip records when members are growing. which permits a representative sample subset of the data to be compared. the Interleave value specifies a number of contiguous records that should be assigned to each bin before moving to the next bin. you will need to identify the following: • • • The number of subsets or “bins” to define for the compare The manner in which records are assigned to bins The specific bins to process Number of subsets: The first issue to consider when performing advanced subset options is how many subsets or bins to establish. 412 . In most circumstances. Because every bin is eventually selected. The following example is based on the one provided in Table 60: Table 61. the system determines how many contiguous bytes are assigned to each bin before subsequent bytes are placed in the next bin. comparisons made over several days will compare every record that existed on the first day. This calculated value will not change due to member size changes. Interleave(20) Member A on Monday Total records in member: Record length: Number of subsets (bins): Interleave (bytes): Interleave (records): Records assigned to bin 1: 30 10 bytes 3 20 2 1-2 7-8 13-14 19-20 25-26 Member A on Tuesday 45 10 bytes 3 20 2 1-2 7-8 13-14 19-20 25-26 31-32 37-38 43-44 3-4 9-10 15-16 21-22 27-28 33-34 39-40 45 5-6 11-12 17-18 23-24 29-30 35-36 41-42 Records assigned to bin 2: 3-4 9-10 15-16 21-22 27-28 Records assigned to bin 3: 5-6 11-12 17-18 23-24 29-30 If the Interleave and Number of Subsets is constant. *CALC is recommended for the interleave specification. When you select *CALC.Comparing file record counts and file member data filled. despite the growth of member size. Let us assume you have specified in interleave value of 20 bytes. assignment restarts at the first bin. the mapping of relative record numbers to bins is maintained. you would keep the subset value and interleave factor a constant. If the number of subsets are 100. suppose you wish to compare seven percent of your data. The next parameters. If you select *FIRST. can be long running and may exceed the time which you have available for it to run. If you wish to compare a random sample. allow you to specify which bin to process. Refer to the MIMIX Monitor documentation for more information. When you specify *LAST. The following settings could be used over the course of a week to compare all of your data: Table 62. For example. Last subset has similar values. the First subset and the Last subset. seven percent of the data is compared. a smaller interleave factor provides a more random. or a rule which calls it. the first subset is 1. 413 . the highest numbered bin is the last one processed. For example. the range to compare will start with bin 1. since data in each bin is processed sequentially. and the last subset is 7. A first subset value of 21 and a last subset value of 27 would also compare seven percent of your data. To compare all your data over the course of several days. First and last subset: The First subset and Last subset values work in combination to determine a range of bins to compare. *LAST and subset-number. but vary the First and Last subset values each day. sample to compare. To compare a random sample of your data. Using First and last subset to compare data Number of subsets (bins) 100 100 100 100 100 100 100 Interleave *CALC *CALC *CALC *CALC *CALC *CALC *CALC First subset 1 11 21 31 41 51 66 Last subset 10 20 30 40 50 65 100 Percentage compared 10 10 10 10 10 15 35 Day of week Monday Tuesday Wednesday Thursday Friday Saturday Sunday Note: You can automate these tasks using MIMIX Monitor. Specifying a very small interleave factor can greatly reduce efficiency. specify a range of subsets that represent the size of the sample.Ending CMPFILDTA requests Specifying *NONE or a very large interleave factor maximizes processing efficiency. or scattered. as little sequential processing can be done before the file must be repositioned. but it would compare a different seven percent than the first example. the possible values are *FIRST and subset-number. Ending CMPFILDTA requests The Compare File Data (CMPFILDTA) command. For the First subset. specify the number of subsets and interleave factor that allows you to size each day’s workload as your needs require. the value *UN (unknown) is placed in the Difference Indicator. The output may not be accurate because the full CMPFILDTA request did not complete. 414 . The default value of 30 seconds may not be adequate in these circumstances. The report and output file contain as much information as possible with the data available at the step in progress when the job ended. Messages indicate the step within CMPFILDTA processing at which the end was requested. If processing did not complete to a point where MIMIX can accurately determine the result of the compare. The output may be incomplete if the end occurred earlier. Note: If the CMPFILDTA command has been long running or has encountered many errors. you may need to specify more time on the ENDJOB command’s Delay time.Comparing file record counts and file member data The CMPFILDTA command recognizes requests to end the job in a controlled manner (ENDJOB OPTION(*CNTRLD)). if *CNTRLD (DELAY) parameter. The content of the report and output file is most valuable if the command completed processing through the end of phase 1 compare. accept the defaults. specify *NONE and continue with the next step. verify. and security considerations described in “Considerations for using the CMPFILDTA command” on page 400. d. From the MIMIX Compare. At the File and library prompts. do one of the following: • To compare data for all files defined by the data group file entries for a particular data group definition. if the file and library names on system 2 are equal to system 1. specify the data group name and continue with the next step. At the Data group definition prompts. At the File prompts. You can optionally specify that results of the comparison are placed in an outfile. and Synchronize menu. Before you begin. Verify. specify the value you want. 3. At the Object attribute prompt.Comparing file member data . At the Member prompt. The Compare File Data (CMPFILDTA) command appears. do the following: 1. 2. For more information. see “Object selection for Compare and Synchronize commands” on page 360. b. From the MIMIX Intermediate Main Menu. specify the name of the file and library to which files on the local system are compared. At the Include or omit prompt. You can specify as many as 300 object selectors by using the + for more prompt for each selector. restrictions. At the System 2 file and System 2 library prompts. To compare a subset of files defined to a data group. accept *ALL to compare the entire list of supported attributes or press F4 to see a valid list of attributes. • • 4. c. specify the name or the generic value you want. For each selector. you can specify elements for one or more object selectors that either identify files to compare or that act as filters to the files defined to the data group indicated in Step 3.basic procedure (non-active) Comparing file member data . accept *ALL or specify a member name to compare a particular member within a file. You should also read “Specifying CMPFILDTA parameter values” on page 404 for additional information about parameters and values that you can specify. e.basic procedure (nonactive) You can use the CMPFILDTA command to ensure that data required for replication exists on both systems and any time you need to verify that files are synchronized between systems. and synchronize menu) and press Enter. specify the data group name and skip to Step 6. see the recommendations. Otherwise. Note: The System 2 file and System 2 library values are ignored if a data 415 . select option 7 (Compare file data) and press Enter. To compare data by file name only. select option 12 (Compare. To perform a basic data comparison. do the following: a. At the System 1 ASP group prompt. Otherwise. At the Subsetting option prompt. specify the name of the remote system to which files on the local system are compared. If necessary. The System 2 parameter prompt appears if you are comparing files not defined to a data group. Press Enter. specify *ALL to select all data and to indicate that no subsetting is performed. 416 . Note: This parameter is ignored when a data group definition is specified. specify *DIF. do one of the following: • • • If you want all compared objects to be included in the report. *PRINT. accept the default if no objects from any ASP group are to be compared on system 1. 8. If you want to include the member details and relative record number (RRN) of the first 1. 7. At the File entry status prompt. • The *RRN value outputs to a unique outfile (MXCMPFILR). 10. At the Report type prompt. Otherwise. At the Process while active prompt. specify *RRN. 9. Notes: • The *RRN value can only be used when *NONE is specified for the Repair on system prompt and *OUTFILE is specified for the Output prompt. 13. do one of the following: • To generate spooled output that is printed. f. At the System 2 ASP group prompt. specify the name of the ASP group that contains objects to be compared on system 2. accept the default if no objects from any ASP group are to be compared on system 2. This value provides the information that enables you to display the specific records on the two systems and determine the system on which the file should be repaired. accept the default. accept *NONE to indicate that no repair action is done. specify *ACTIVE to process only those file members that are active. Specifying *RRN can help resolve situations where a discrepancy is known to exist but you are unsure which system contains the correct data. 5. 11. 12. specify *NO to indicate that active processing technology should not be used in the comparison. At the Repair on system prompt. 6. Press Enter and continue with the next step.000 objects that have differences. If you only want objects with detected differences to be included in the report.group is specified on the Data group definition prompts. Note: This parameter is ignored when a data group definition is specified. specify the name of the ASP group that contains objects to be compared on system 1. At the Output prompt. accept the default. At the Member to receive output prompt.basic procedure (non-active) • • • To generate an outfile and spooled output that is printed. Press Enter and continue with the next step. When used as part of shipped rules. Press Enter and skip to Step 18. 16. At the Replace or add prompt. and is the default used outside of shipped rules. At the File to receive output prompts. (Press F1 (Help) to see the name of the supplied database file.Comparing file member data . To start the comparison. 417 . specify the system on which the output should be created. At the Submit to batch prompt. At the Job description and Library prompts. specify the file and library to receive the output. At the Object difference messages prompt. The value *INCLUDE places detail messages in the job log. specify whether you want detail messages placed in the job log. Note: If *YES is specified on the Process while active prompt and *OUTFILE was specified on the Outfile prompt. do the following: a. 20. To generate an outfile. specify whether new records should replace existing file members or be added to the existing list. 14. 21. To submit the job for batch processing. specify *OUTFILE. 19. 17. If you do not want to generate output. you must select *SYS2 for the System to receive output prompt. b. Press Enter and continue with the next step. do one of the following: • • If you do not want to submit the job for batch processing. At the Output member options prompts. specify the name and library of the job description used to submit the batch request. accept the default. specify *BOTH. specify *NONE. Press Enter continue with the next step. At the Job name prompt. accept *CMD to use the command name to identify the job or specify a simple name. 18. specify the name of the database file member to receive the output of the command. press Enter.) 15. the default value is *OMIT since the results are already placed in an outfile. specify *NO and press Enter to start the comparison. At the System to receive output prompt. 2. To compare data by file name only. e. For more information. specify the name or the generic value you want. accept the defaults. accept *ALL or specify a member name to compare a particular member within a file. do the following: 1. do one of the following: • To compare data for all files defined by the data group file entries for a particular data group definition. and synchronize menu) and press Enter. Press Enter. You should also read “Specifying CMPFILDTA parameter values” on page 404 for additional information about parameters and values that you can specify. you can specify elements for one or more object selectors that either identify files to compare or that act as filters to the files defined to the data group indicated in Step 3.Comparing and repairing file member data . At the File prompts. do the following: a.basic procedure You can use the CMPFILDTA command to repair data on the local or remote system. At the File and library prompts. Note: The System 2 file and System 2 library values are ignored if a data group is specified on the Data group definition prompts. At the Member prompt. accept *ALL to compare the entire list of supported attributes or press F4 to see a valid list of attributes. c. Otherwise. 3. restrictions. 418 . To compare and repair data. and security considerations described in “Considerations for using the CMPFILDTA command” on page 400. Verify. From the MIMIX Intermediate Main Menu. specify *NONE and continue with the next step. To compare a subset of files defined to a data group. At the Object attribute prompt. see the recommendations. b. specify the data group name and skip to Step 6. At the Include or omit prompt. verify. specify the name of the file and library to which files on the local system are compared. specify the value you want. d. select option 7 (Compare file data) and press Enter. Before you begin. You can specify as many as 300 object selectors by using the + for more prompt for each selector. • • 4. At the System 2 file and System 2 library prompts. For each selector. select option 12 (Compare. The Compare File Data (CMPFILDTA) command appears. if the file and library names on system 2 are equal to system 1. From the MIMIX Compare. and Synchronize menu. At the Data group definition prompts. see “Object selection for Compare and Synchronize commands” on page 360. specify the data group name and continue with the next step. f. If you do not want to generate output. *LOCAL. specify the file and library to receive the output. do one of the following: • • If you want all compared objects to be included in the report. 11. 6. do one of the following: • • • • To generate spooled output that is printed. The System 2 parameter prompt appears if you are comparing files not defined to a data group. *PRINT.basic procedure 5. 9. To generate an outfile. *TGT. accept the default if no objects from any ASP group are to be compared on system 1. 7. accept the default if no objects from any ASP group are to be compared on system 2. specify *BOTH. specify *DIF. Otherwise. specify *ACTIVE to process only those file members that are active. 12. Note: This parameter is ignored when a data group definition is specified. 8. At the Report type prompt. At the System 2 ASP group prompt. Press Enter and continue with the next step. At the Process while active prompt. specify *NONE. If you only want objects with detected differences to be included in the report. specify *ALL to select all data and to indicate that no subsetting is performed. At the Subsetting option prompt. or the system definition name to indicate the system on which repair action should be performed. (Press F1 (Help) to see the name of the supplied database file. At the Output member options prompts.) 15. do the following: 419 . Otherwise. specify *OUTFILE. 10. Press Enter and skip to Step 18. Note: *TGT and *SRC are only valid if you are comparing files defined to a data group.Comparing and repairing file member data . accept the default. At the File entry status prompt. Press Enter and continue with the next step. Press Enter and continue with the next step. specify *SYS1. specify the name of the ASP group that contains objects to be compared on system 1. specify the name of the ASP group that contains objects to be compared on system 2. At the File to receive output prompts. 13. At the System 1 ASP group prompt. *SYS2. At the Output prompt. If necessary. 14. *SRC. At the Repair on system prompt. To generate an outfile and spooled output that is printed. *SRC is not valid if active processing is in effect. specify *NO to indicate that active processing technology should not be used in the comparison. Note: This parameter is ignored when a data group definition is specified. accept the default. specify the name of the remote system to which files on the local system are compared. At the Member to receive output prompt. specify *NO and press Enter to start the comparison. accept the default. At the Object difference messages prompt. do one of the following: • • If you do not want to submit the job for batch processing. and is the default used outside of shipped rules. 16. When used as part of shipped rules. At the Replace or add prompt. specify the system on which the output should be created. 17. Press Enter. press Enter. specify whether you want detail messages placed in the job log. To submit the job for batch processing. The value *INCLUDE places detail messages in the job log. 18. 20. 19. 420 .a. specify the name of the database file member to receive the output of the command. you must select *SYS2 for the System to receive output prompt. At the Job name prompt. At the System to receive output prompt. 21. At the Job description and Library prompts. the default value is *OMIT since the results are already placed in an outfile. specify whether new records should replace existing file members or be added to the existing list. b. specify the name and library of the job description used to submit the batch request. accept *CMD to use the command name to identify the job or specify a simple name. Note: If *YES is specified on the Process while active prompt and *OUTFILE was specified on the Outfile prompt. At the Submit to batch prompt. To start the comparison. see “Object selection for Compare and Synchronize commands” on page 360. verify. do the following: 1. Note: The System 2 file and System 2 library values are ignored when a data group is specified on the Data group definition prompts. At the Member prompt. Verify. You should also read “Specifying CMPFILDTA parameter values” on page 404 for additional information about parameters and values that you can specify. The Compare File Data (CMPFILDTA) command appears. d. You can specify as many as 300 object selectors by using the + for more prompt for each selector. restore them to an active state. see the recommendations. you must specify a data group name. Note: If you want to compare data for all files defined by the data group file entries for a particular data group definition. select option 12 (Compare.members on hold (*HLDERR) Comparing and repairing file member data . Press Enter. From the MIMIX Intermediate Main Menu. accept *ALL to compare the entire list of supported attributes or press F4 to see a valid list of attributes. From the MIMIX Compare. b. 421 .members on hold (*HLDERR) Members that are being held due to error (*HLDERR) can be repaired with the Compare File Data (CMPFILDTA) command during active processing. For more information. skip to Step 5. 3. When members in *HLDERR status are processed. you can optionally specify elements for one or more object selectors that act as filters to the files defined to the data group indicated in Step 3. if significant activity has occurred on the source system that has not been replicated on the target system. restrictions. do the following: a. At the Data group definition prompts. and security considerations described in “Considerations for using the CMPFILDTA command” on page 400. As such. For each selector. this method is generally faster than other methods of repairing members in *HLDERR status that transmit the entire member or file. To repair a member with a status of *HLDERR. the CMPFILDTA command works cooperatively with the database apply (DBAPY) process to compare and repair the members—and when possible. c. At the File prompts. specify the name or the generic value you want. and Synchronize menu. specify the value you want. At the Object attribute prompt. select option 7 (Compare file data) and press Enter. At the Include or omit prompt. e. However. Before you begin. 2. At the File and library prompts. and synchronize menu) and press Enter.Comparing and repairing file member data . 4. it may be faster to synchronize the member using the Synchronize Data Group File Entry (SYNCDGFE) command. accept *ALL or specify a member name to compare a particular member within a file. The following procedure repairs a member without transmitting the entire member. b. 14.5. do one of the following: • If you do not want to submit the job for batch processing. At the Replace or add prompt. At the Member to receive output prompt. To generate an outfile and spooled output that is printed. 10. specify *NO and press Enter to start the comparison. accept the default. To generate an outfile. specify *TGT to indicate that repair action be performed on the target system. At the Output prompt. Note: This parameter is ignored when a data group definition is specified. At the System 1 ASP group prompt. Otherwise. 13.) 12. specify the name of the ASP group that contains objects to be compared on system 2. accept the default if no objects from any ASP group are to be compared on system 1. Otherwise. specify whether new records should replace existing file members or be added to the existing list. At the Submit to batch prompt. At the Output member options prompts. specify whether you want detail messages placed in the job log. At the Process while active prompt. Press Enter and skip to Step 15. Press Enter and continue with the next step. 15. specify the file and library to receive the output. At the System to receive output prompt. do the following: a. At the File to receive output prompts. At the Object difference messages prompt. At the Repair on system prompt. the default value is *OMIT since the results are already placed in an outfile. At the System 2 ASP group prompt. specify *OUTFILE. At the File entry status prompt. 8. (Press F1 (Help) to see the name of the supplied database file. Note: This parameter is ignored when a data group definition is specified. specify the name of the database file member to receive the output of the command. specify *HLDERR to process members being held due to error only. specify *BOTH. The value *INCLUDE places detail messages in the job log. 11. Press Enter and continue with the next step. specify *YES to indicate that active processing technology should be used in the comparison. specify *NONE. 7. specify the system on which the output should be created. *PRINT. 6. Press Enter and continue with the next step. When used as part of shipped rules. If you do not want to generate output. accept the default if no objects from any ASP group are to be compared on system 2. do one of the following: • • • • To generate spooled output that is printed. specify the name of the ASP group that contains objects to be compared on system 1. 422 . 9. and is the default used outside of shipped rules. accept *CMD to use the command name to identify the job or specify a simple name. 423 . Press Enter. 18. 17. accept the default. 16. At the Job name prompt.members on hold (*HLDERR) • To submit the job for batch processing. To compare and repair the file.Comparing and repairing file member data . press Enter. specify the name and library of the job description used to submit the batch request. At the Job description and Library prompts. and security considerations described in “Considerations for using the CMPFILDTA command” on page 400. At the System 2 file and System 2 library prompts. select option 12 (Compare. To compare data using the active processing. or has exceeded a threshold limit. You should also read “Specifying CMPFILDTA parameter values” on page 404 for additional information about parameters and values that you can specify. Verify. specify *YES or *DFT to indicate that active 424 . At the Member prompt. and Synchronize menu. verify. e. accept *ALL or specify a member name to compare a particular member within a file. 6. To compare a subset of files defined to a data group. and synchronize menu) and press Enter. specify *TGT to indicate that repair action be performed on the target system of the data group. select option 7 (Compare file data) and press Enter. see “Object selection for Compare and Synchronize commands” on page 360. see the recommendations. At the Object attribute prompt. At the File and library prompts. do one of the following: • To compare data for all files defined by the data group file entries for a particular data group definition. At the File prompts. Press Enter. From the MIMIX Intermediate Main Menu. Before you begin. specify the value you want. d. specify the data group name and continue with the next step. At the Repair on system prompt. you can specify elements for one or more object selectors that either identify files to compare or that act as filters to the files defined to the data group indicated in Step 3. 2. accept *ALL to compare the entire list of supported attributes or press F4 to see a valid list of attributes. At the Process while active prompt. c. At the Data group definition prompts. You can specify as many as 300 object selectors by using the + for more prompt for each selector. For more information. • 4. b. 3. specify the data group name and skip to Step 6. From the MIMIX Compare. At the Include or omit prompt. Note: Do not compare data using active processing technology if the apply process is 180 seconds or more behind. f. 5. do the following: 1. For each selector. accept the defaults. restrictions. specify the name or the generic value you want. The Compare File Data (CMPFILDTA) command appears. do the following: a.Comparing file member data using active processing technology You can set the CMPFILDTA command to use active processing technology when a data group is specified on the command. specify the system on which the output should be created. 13. At the System 1 ASP group prompt. At the Subsetting option prompt. do one of the following: • • If you want all compared objects to be included in the report. If you do not want to generate output. *PRINT. 10. At the Object difference messages prompt.) 14. Note: This parameter is ignored when a data group definition is specified. At the File to receive output prompts. Note: This parameter is ignored when a data group definition is specified. At the File entry status prompt. To generate an outfile. 15. At the System to receive output prompt. 12. At the Member to receive output prompt. Press Enter and skip to Step 17. accept the default. (Press F1 (Help) to see the name of the supplied database file. accept the default if no objects from any ASP group are to be compared on system 2. Press Enter and continue with the next step. specify the name of the ASP group that contains objects to be compared on system 2. To generate an outfile and spooled output that is printed. 11. Otherwise. At the Output member options prompts. At the Output prompt. it is recommended that you select *SYS2 for the System to receive output prompt. specify whether new records should replace existing file members or be added to the existing list. If you only want objects with detected differences to be included in the report. 7. At the System 2 ASP group prompt. do one of the following: • • • • To generate spooled output that is printed. 9. At the Replace or add prompt.Comparing file member data using active processing technology processing technology be used in the comparison. accept the default. specify *ALL to select all data and to indicate that no subsetting is performed. At the Report type prompt. Note: If *OUTFILE was specified on the Outfile prompt. *DFT will render the same results as *YES. specify *DIF. specify the file and library to receive the output. specify *NONE. specify whether you want detail 425 . b. specify *ACTIVE to process only those file members that are active. Since a data group is specified on the Data group definition prompts. accept the default if no objects from any ASP group are to be compared on system 1. specify *OUTFILE. specify *BOTH. do the following: a. specify the name of the database file member to receive the output of the command. specify the name of the ASP group that contains objects to be compared on system 1. Press Enter and continue with the next step. 8. Otherwise. Press Enter and continue with the next step. 16. and is the default used when the command is invoked from outside of shipped audits. 19. 17. specify *NO and press Enter to start the comparison. 20. press Enter. Press Enter continue with the next step. accept the default. At the Submit to batch prompt. When used as part of shipped audits. 426 . 18. do one of the following: • • If you do not want to submit the job for batch processing. To submit the job for batch processing. the default value is *OMIT since the results are already placed in an outfile. At the Job description and Library prompts. At the Job name prompt.messages placed in the job log. accept *CMD to use the command name to identify the job or specify a simple name. To start the comparison. specify the name and library of the job description used to submit the batch request. The value *INCLUDE places detail messages in the job log. d. You should also read “Specifying CMPFILDTA parameter values” on page 404 for additional information about parameters and values that you can specify. or has exceeded a threshold limit. you can specify elements for one or more object selectors that either identify files to compare or that act as filters to the files defined to the data group indicated in Step 3. Note: Do not compare data using active processing technology if the apply process is 180 seconds or more behind. see the recommendations. At the Data group definition prompts. b. specify the data group name and continue with the next step. specify the name of the file and library to which files on the local system are compared. The Compare File Data (CMPFILDTA) command appears. To compare data using the subsetting options. and security considerations described in “Considerations for using the CMPFILDTA command” on page 400. e. • • 4. specify the value you want. and synchronize menu) and press Enter. specify the data group name and skip to Step 6. At the System 2 file and System 2 library prompts. For more information. At the File and library prompts. To compare a subset of files defined to a data group. restrictions. accept *ALL or specify a member name to compare a particular member within a file. At the Object attribute prompt. 2. specify the name or the generic value you want. verify. if the file and library names on system 2 are equal to system 1. Otherwise. To compare data by file name only. 427 . You can specify as many as 300 object selectors by using the + for more prompt for each selector. For each selector. accept *ALL to compare the entire list of supported attributes or press F4 to see a valid list of attributes. At the File prompts. select option 7 (Compare file data) and press Enter. select option 12 (Compare. see “Object selection for Compare and Synchronize commands” on page 360. At the Member prompt. do the following: a. 3. Note: The System 2 file and System 2 library values are ignored if a data group is specified on the Data group definition prompts. Verify. From the MIMIX Compare. accept the defaults.Comparing file member data using subsetting options Comparing file member data using subsetting options You can use the CMPFILDTA command to audit your entire database over a number of days. specify *NONE and continue with the next step. c. From the MIMIX Intermediate Main Menu. do one of the following: • To compare data for all files defined by the data group file entries for a particular data group definition. and Synchronize menu. At the Include or omit prompt. Before you begin. do the following: 1. c. b. Skip to Step 10. At the Process while active prompt. To process members being held due to error only. specify *HLDERR. Notes: • To process members in *HLDERR status. 8. See Step 8. Do one of the following: a. 7. or has exceeded a threshold limit. The System 2 parameter prompt appears if you are comparing files not defined to a data group. To process both active members and members being held due to error (*ACTIVE and *HLDERR). Skip to Step 11. you can select files with specific statuses for compare and repair processing. 6. do the following: a. specify *ENDDTA and press Enter to see additional prompts. 9. At the Subset range prompts. To define how many subsets should be established. Do one of the following: • • To compare a fixed range of data. At the File entry status prompt. you must specify *TGT. Press Enter. specify the name of the remote system to which files on the local system are compared. specify a value if you want repair action performed. • If you are comparing files associated with a data group. To indicate that only data specified on the Records at end of file prompt is compared. • 10. specify *RANGE then press Enter to see additional prompts. specify the default value *ALL. To process active members only. *DFT does not use active processing. Skip to Step 12.f. specify the relative record number of the first record to compare in the range. At the Repair on system prompt. how member data is assigned to the subsets. specify *ADVANCED and press Enter to see additional prompts. 428 . If necessary. Note: When *ALL or *HLDERR is specified for the File entry status prompt. See Step 8. specify *ACTIVE. Note: To process members in *HLDERR status. you must specify a value other than *ALL to use additional subsetting. At the First record prompt. • Do not compare data using active processing technology if the apply process is 180 seconds or more behind. *TGT must also be specified for the Repair on system prompt (Step 6) and *YES must be specified for the Process while active prompt (Step 7). At the Subsetting option prompt. *DFT uses active processing. you must specify *YES. and which range of subsets to compare. specify whether active processing technology should be used in the comparison. If you are comparing files not associated with a data group. 5. c. do one of the following: • • • To generate spooled output that is printed.Comparing file member data using subsetting options b. To generate an outfile and spooled output that is printed. specify *DIF. accept the default. At the Last subset prompt. Press Enter and continue with the next step. Specifying *RRN can help resolve situations where a discrepancy is known to exist but you are unsure which system contains the correct data. At the Output prompt. • The *RRN value outputs to a unique outfile (MXCMPFILR). 13. b. accept the default. Press Enter and skip to Step 19. *PRINT. 14. the default *CALC is highly recommended. specify the relative record number of the last record to compare in the range. you must specify a value other than *NONE. c. At the Interleave prompt. Press Enter and continue with the next step. Skip to Step 12. If you want to include the member details and relative record number (RRN) of the first 1. In most cases. Notes: • The *RRN value can only be used when *NONE is specified for the Repair on system prompt and *OUTFILE is specified for the Output prompt. specify *BOTH. specify *NONE. At Number of subsets prompt. Subsets are numbered beginning with 1. specify the first subset in the sequence of subsets to compare. specify the last subset in the sequence of subsets to compare. If you do not want to generate output. 11.000 objects that have differences. specify the number of approximately equalsized subsets to establish. At the Records at end of file prompt. d. Note: If *ENDDTA is specified on the Subsetting option prompt. If you only want objects with detected differences to be included in the report. do the following: a. At the Last record prompt. At the First subset prompt. specify the interleave factor. specify *RRN. These records are compared regardless of other subsetting criteria. 12. This value provides the information that enables you to display the specific records on the two systems and determine the system on which the file should be repaired. 429 . do one of the following: • • • If you want all compared objects to be included in the report. At the Report type prompt. specify the number of records at the end of the member to compare. At the Advanced subset options prompts. When used as part of shipped rules. At the Job name prompt. Press Enter continue with the next step. 430 . accept *CMD to use the command name to identify the job or specify a simple name. specify whether new records should replace existing file members or be added to the existing list. press Enter. To submit the job for batch processing. At the Object difference messages prompt.• To generate an outfile. Note: If *YES is specified on the Process while active prompt and *OUTFILE was specified on the Outfile prompt. 18. At the Submit to batch prompt. specify the file and library to receive the output. specify whether you want detail messages placed in the job log. 20. At the Job description and Library prompts. specify the system on which the output should be created. specify the name of the database file member to receive the output of the command. 19. At the File to receive output prompts. the default value is *OMIT since the results are already placed in an outfile. 21. accept the default. At the Member to receive output prompt. you must select *SYS2 for the System to receive output prompt. At the System to receive output prompt. 15. do the following: a. specify *OUTFILE. 17. specify *NO and press Enter to start the comparison.) 16. 22. do one of the following: • • If you do not want to submit the job for batch processing. To start the comparison. specify the name and library of the job description used to submit the batch request. (Press F1 (Help) to see the name of the supplied database file. and is the default used outside of shipped rules. b. At the Output member options prompts. At the Replace or add prompt. The value *INCLUDE places detail messages in the job log. Press Enter and continue with the next step. The automatic recovery features of MIMIX® AutoGuard™ also use synchronize commands to recover differences detected during replication and audits. For information about initial synchronization. and DLOs. the objects must be synchronized. Additionally. see the MIMIX for IBM WebSphere MQ book. • • • • During initial configuration of a data group. how large objects are handled. and Synchronize DLO (SYNCDLO) provide robust support in MIMIX environments. as well as their associated object authorities. If automatic recovery policies are disabled. these commands are often called by other functions. or by using the Synchronize Data Group (SYNCDG) command. You may also need to synchronize a file or object if an error occurs that causes the two systems to become not synchronized. The data that MIMIX replicates must by synchronized on several occasions. Topic “Considerations for synchronizing using MIMIX commands” on page 433 describes subjects that apply to more than one group of commands. and how user profiles are addressed. see these topics: • • “Performing the initial synchronization” on page 442 describes how to establish a synchronization point and identifies other key information. you need to ensure that the data to be replicated is synchronized between both systems defined in a data group. for synchronizing library-based objects. The SYNCDG command is intended especially for performing the initial synchronization of one or more data groups and uses the auditing and automatic recovery support provided by MIMIX AutoGuard.CHAPTER 20 Synchronizing data between systems This chapter contains information about support provided by MIMIX commands for synchronizing data between two systems. The command can be long-running. such as the maximum size of an object that can be synchronized. If you change the configuration of a data group to add new data group entries. Environments using MIMIX support for IBM WebSphere MQ have additional requirements for the initial synchronization of replicated queue managers. you may need to use synchronize commands to correct a file or object in error or to correct differences detected by audits or compare commands. Each command has considerable flexibility for selecting objects associated with or independent of a data group. such as by the automatic recovery features of MIMIX AutoGuard and by options to synchronize 431 . Synchronize commands: The commands Synchronize Object (SYNCOBJ). Synchronize IFS Object (SYNCIFS). IFS objects. The synchronize commands provided with MIMIX can be loosely grouped by common characteristics and the level of function they provide. Initial synchronization: Initial synchronization can be performed manually with a variety of MIMIX and IBM commands. For more information. Additional options provide the means to address triggers. the best approach is to use the options provided on the displays where they are appropriate to use. see “About synchronizing file entries (SYNCDGFE command)” on page 439. For additional information. Synchronize Data Group File Entry: The Synchronize DG File Entry (SYNCDGFE) command provides the means to synchronize database files associated with a data group by data group file entries. and related files. path. or directory. The options call the appropriate command and. see “About synchronizing data group activity entries (SYNCDGACTE)” on page 438. Typically. see: • • “About MIMIX commands for synchronizing objects. and Send Network DLO (SNDNETDLO) commands support fewer usage options and usability benefits than the Synchronize commands. pre-select some of the fields. Send Network commands: The Send Network Object (SNDNETOBJ). The contents of the object and its attributes and authorities are synchronized. These commands do not support synchronizing based on a data group name. For more information about this command. when you need to synchronize individual items in your configuration. Verify. The following procedures are included: • • • • • • • • • “Synchronizing database files” on page 449 “Synchronizing objects” on page 451 “Synchronizing IFS objects” on page 455 “Synchronizing DLOs” on page 459 “Synchronizing data group activity entries” on page 462 “Synchronizing tracking entries” on page 464 “Sending library-based objects” on page 465 “Sending IFS objects” on page 467 “Sending DLO objects” on page 468 432 . IFS objects. For additional information. respectively. logical files.Synchronizing data between systems objects identified in tracking entries used with advanced journaling. Procedures: The procedures in this chapter are for commands that are accessible from the MIMIX Compare. These commands may require multiple invocations per library. and DLOs” on page 437 “About synchronizing tracking entries” on page 441 Synchronize Data Group Activity Entry: The Synchronize DG Activity Entry (SYNCDGACTE) command provides the ability to synchronize library-based objects. in many cases. and DLOs that are associated with data group activity entries which have specific status values. referential constraints. and Synchronize menu. Send Network IFS Object (SNDNETIFS). IFS objects. the policies in effect determine the value used for the command’s MAXSIZE parameter.Considerations for synchronizing using MIMIX commands Considerations for synchronizing using MIMIX commands For discussion purposes. the synchronize commands are grouped as follows: • • • Synchronize commands (SYNCOBJ. Before you synchronize you should be aware of information in the following topics: • • • • • “Limiting the maximum sending size” on page 433 “Synchronizing user profiles” on page 433 “Synchronizing large files and objects” on page 435 “Status changes caused by synchronizing” on page 435 “Synchronizing objects in an independent ASP” on page 436 Limiting the maximum sending size The Synchronize commands (SYNCOBJ. or AUDRCY). Synchronizing user profiles User profile objects (*USRPRF) can be synchronized explicitly or implicitly. When any of the automatic recovery policies are enabled (DBRCY. You can also specify the value *TFRDFN to use the threshold size from the transfer definition associated with the data group1.999 megabytes (MB). SYNCIFS. or specify a value between 1 and 9. OBJRCY. You can adjust the SYNCTHLD policy value for the installation or optionally set a value for a specific data group. and SYNCDLO) Synchronize Data Group Activity Entry (SYNCDGACTE) Synchronize Data Group File Entry (SYNCDGFE) The following subtopics apply to more than one group of commands. specify *TFRDFN. The Set MIMIX Policies (SETMMXPCY) command sets policies for automatic recovery actions and for the synchronize threshold used by the commands MIMIX invokes to perform recovery actions. and SYNCDLO) and the Send Network Objects (SNDNETOBJ) command can synchronize user profiles either 1. When automatic recovery actions initiate a Synchronize or SYNCDGFE command. By default. SYNCIFS. SYNCIFS. threshold size (SYNCTHLD) policy is used for the MAXSIZE value on the command. The Synchronize commands (SYNCOBJ.999. the value of the Sync. 433 . To preserve behavior prior to changes made in V4R4 service pack SPC05SP4. and SYNCDLO) and the Synchronize Data Group File Entry (SYNCDGFE) command provide the ability to limit the size of files or objects transmitted during synchronization with the Maximum sending size (MAXSIZE) parameter. On the SYNCDGFE command. the value *TFRDFN is only allowed when the Sending mode (METHOD) parameter specifies *SAVRST. no maximum value is specified. and user profiles that have private authorities to an object are implicitly synchronized. • • • Synchronizing user profiles with the SNDNETOBJ command The Send Network Objects (SNDNETOBJ) command explicitly synchronizes user profiles when you specify *USRPRF for the object type on the command. The status of the user profile on the target system is set to *DISABLED. 434 . is specified on these commands. and SYNCDLO commands implicitly synchronize user profiles associated with the object if they do not exist on the target system. it is synchronized and its status on the target system is set to *DISABLED. The status of the user profile on the target system is set to match the value from the data group object entry. the owning user profile. the SYNCOBJ. the following occurs: – If the user profile exists on the target system. its status on the target system remains unchanged. When the Synchronize command specifies a data group and that data group does not have a data group object entry for the user profile. the object and the user profile are synchronized. Although only the requested object type. such as *PGM. the object and the associated user profile are synchronized. If a data group object entry excludes the user profile from replication. the object is synchronized and its owner is changed to the default owner indicated in the data group definition. The following information describes slight variations in processing. – If the user profile does not exist on the target system. If the user profile does not exist on the target system. it is synchronized and its status on the target system is set to *DISABLED. the primary group profile. If you specified a user profile but did not specify a data group.implicitly or explicitly. The status of the user profile on the target system is affected as follows: • If you specified a data group and a user profile which is configured for replication. SYNCIFS. The status of the user profile on the target system is affected as follows: • • If the user profile exists on the target system. The user profile is not synchronized. When synchronizing other object types. Synchronizing user profiles with SYNCnnn commands The SYNCOBJ command explicitly synchronizes user profiles when you specify *USRPRF for the object type on the command. its status on the target system remains unchanged. the status of the user profile on the target system is the value specified in the configured data group object entry. as follows: • When the Synchronize command specifies a data group and that data group has a data group object entry which includes the user profile. 435 . large files or objects can negatively impact performance by consuming too much bandwidth. is specified on the command. MIMIX adds the system distribution directory entry for the user profile on the target system and specifies these values: • • • • • User ID: same value as retrieved from the source system Description: same value as retrieved from the source system Address: local-system name User profile: user-profile name All other directory entry fields are blank Synchronizing large files and objects When configured for advanced journaling. this command implicitly synchronizes user profiles associated with the object if they do not exist on the target system. Although only the requested object type. Certain commands for synchronizing provide the ability to limit the size of files or objects transmitted during synchronization. MIMIX automatically adds any missing system distribution directory entries for user profiles. The object and associated user profiles are synchronized. On certain commands. Status changes caused by synchronizing In some circumstances the Synchronize Data Group Activity Entry (SYNCDGACTE) command changes the status of activity entries when the command completes. the owning user profile. The status of the user profile on the target system is set to *DISABLED. large objects (LOBs) can be synchronized through the user (database) journal. If advanced journaling is not used in your environment. you may want to consider synchronizing large files or objects (over 1 GB) outside of MIMIX. The synchronize (SYNCnnn) and the SNDNETOBJ commands provide this capability. the primary group profile. The Threshold size (THLDSIZE) parameter on the transfer definition can be used to limit the size of objects transmitted with the Send Network Object commands. For additional details. such as *PGM. Missing system distribution directory entries automatically added When a missing user profile is detected during replication or synchronization of an object.Considerations for synchronizing using MIMIX commands When synchronizing other object types. If replication or a synchronization request determines that a user profile is missing on the target system and a system directory entry exists on the source system for that user profile. and user profiles that have private authorities to an object are implicitly synchronized. see “About synchronizing data group activity entries (SYNCDGACTE)” on page 438. See “Limiting the maximum sending size” on page 433 for more information. You can synchronize a database file that contains LOB data using the Synchronize Data Group File Entry (SYNCDGFE) command. it is possible to control the size of files and objects sent to another system. During traditional synchronization. and System 2 ASP device number parameters. each replicated activity has associated tracking entries. 436 . the status of the tracking entry will be updated once the data group is restarted. the status of the tracking entry will remain in its original status or have a status of *HLD. When advanced journaling is configured. the status of the tracking entry will change to *ACTIVE upon successful completion of the synchronization request. you must specify values for the System 1 ASP group or device. SYNCIFS and SYNCDLO) do not change the status of activity entries associated with the objects being synchronized. Synchronizing objects in an independent ASP When synchronizing data that is located in an independent ASP. Activity entries retain the same status after the command completes. When you use the SYNCOBJ or SYNCIFS commands to synchronize an object that has a corresponding tracking entry. • In order for the Send Network Object (SNDNETOBJ) command to access objects that are located in an independent auxiliary storage pool (ASP) on the source system. do one of the following on the Synchronize Object (SYNCOBJ) command: – Specify the data group definition. Note: The SYNCIFS command will change the status of an activity entry for an IFS object configured for advanced journaling. be aware of the following: • In order for MIMIX to access objects located in an independent ASP. If the synchronization is not successful. you must first use the IBM command Set ASP Group (SETASPGRP) on the local system before using the SNDNETOBJ command.The Synchronize commands (SYNCOBJ. If the data group is not active. – If no data group is specified. System 2 ASP device number. When using the SYNCIFS command for a data group configured for advanced journaling. the additional parameter information is used to filter the list of objects identified for the data group. You can also synchronize only the object or only the authority attributes of an object. When you use the SYNCOBJ command to synchronize only the authorities for an object and a data group name is not specified.About MIMIX commands for synchronizing objects. the local system becomes the source system and a target system must be identified. and SYNCDLO commands during off-peak usage or when the objects being synchronized are in a quiesced state reduces contention for object locks. a subset of a data group. IFS objects. see “Object selection for Compare and Synchronize commands” on page 360. 437 . IFS objects. For more information about the object selection criteria used when no data group is specified on these commands. or by specifying objects independently of a data group. The objects to be synchronized by the command are the same as those identified for replication by the data group. and DLOs The Synchronize Object (SYNCOBJ). and DLOs About MIMIX commands for synchronizing objects. You can synchronize objects whether or not the data group is active. you must specify the name of a data group to avoid overwriting the objects on the source system. Authority attributes include ownership. authorization list. the data group can be active but it should not have a backlog of unprocessed entries. if any files processed by the command are cooperatively processed and a data group that contains these files is active. When to run: Each command can be run when the data group is in an active or an inactive state. If you specify a data group as well as specify additional object information in command parameters. will synchronize the same library-based objects as those configured for replication by the data group. Identifying what to synchronize: On each command. However. The list of objects to synchronize is generated on the local system. Synchronize IFS (SYNCIFS). SYNCIFS. public and private authorities. • When you specify a data group. the object and all authority-related attributes are synchronized. primary group. • • Each command has a Synchronize authorities parameter to indicate whether authority attributes are synchronized. For example. Using the SYNCOBJ. specifying a data group on the SYNCOBJ command. and Synchronize DLO (SYNCDLO) commands provide versatility for synchronizing objects and their authority attributes. if you run these commands from a target system. the command could fail if the database apply job has a lock on these files. When no data group is specified. Where to run: The synchronize commands can be run from either system. you can identify objects to synchronize by specifying a data group. By default. its source system determines the objects to synchronize. The data group can either be active or inactive during the synchronization request. For more information. Note: From the 5250 emulator. *COMPLETED. The specific status of individual activity entries appear on the Work with DG Activity Entries display (WRKDGACTE command). delayed. The same SYNCDGACTE request will then find the next non-completed entry and synchronize it. and subsequent delayed entries). Any existing active. the SYNCDGACTE command will find the first noncompleted activity entry and synchronize it. If a lock is not obtained in the specified time. the save operation ends and the synchronization attempt fails. IFS objects. or DLOs associated with data group activity entries. 438 . its attributes. Not supported: Spooled files and cooperatively processed files are not eligible to be synchronized using the SYNCDGACTE command. see “Limiting the maximum sending size” on page 433. Activity entries whose status falls in the following categories can be synchronized: *ACTIVE. • • About synchronizing data group activity entries (SYNCDGACTE) The Synchronize Data Group Activity Entry (SYNCDGACTE) command supports the ability to synchronize library-based objects. When all activity entries are completed for the specified object. If a commit boundary is not reached in the specified time. • The Save active parameter provides the ability to save the object in an active environment using IBM's save while active support. The SYNCDGACTE request will continue to synchronize these non-completed entries until all entries for that object have been synchronized. If the item you are synchronizing has multiple activity entries with varying statuses (for example. followed by a failed entry. the object is not saved. an entry with a status of completed. The Maximum sending size (MB) parameter specifies the maximum size that an object can be in order to be synchronized. the following parameters provide additional control of the synchronization process.Additional parameters: On each command. or *FAILED. The Save active wait time parameter specifies the amount of time to wait for a commit boundary or for a lock on an object. The contents of the object. data group activity and the status category of the represented object are listed on the Work with Data Group Activity display (WRKDGACT command). and its authorities are synchronized between the source and target systems. or failed activity entries for the specified object are processed and set to ‘completed by synchronization’ (PZ) when the synchronization request completes successfully. only the status of the very last completed entry is changed from complete (CP) to ‘completed by synchronization’ (CZ). *DELAYED. when the synchronization request completes successfully. Values supported are the same as those used in related IBM commands. The content and attributes are replicated using the IBM i save and restore commands. or optionally for a data group file entry. the status of the activity entries remains either ‘pending synchronization’ (PZ) or ‘pending completion’ (PC) when the synchronization request completes. MIMIX uses save and restore operations to create the file on the target system and then uses copy active file processing to fill it with data from the file on the source system. This method allows save-while-active operations. the synchronization will fail. the status of the activity entries is set to either ‘completed by synchronization’ (CZ) or to ‘failed synchronization’ (FZ). The value *YES will disable triggers on the target system during synchronization. Only the physical file attributes are replicated and synchronized. Only the physical file data is replicated using MIMIX Copy Active File processing. the data group must be active when the command is used. Only the authorities for the physical file are replicated and synchronized. File attributes are not replicated using this method. The Disable triggers on file (DSBTRG) parameter specifies whether the database apply process (used for synchronization) disables triggers when processing a file. the status of the activity entries being synchronized are set to a status of ‘pending synchronization’ (PZ) and then to ‘pending completion’ (PC). if the data group is active. MIMIX refreshes its contents. This method also has the capability to save associated logical files. Table 63. If the data group is inactive. allow MIMIX to replicate trigger-generated entries and disable the triggers. If the file format is different on the target system. Active data group required: Because the SYNCDGFE command runs through a database apply job. The default value *DGFE uses data group file entry to determine whether triggers should be disabled.About synchronizing file entries (SYNCDGFE command) Status changes during to synchronization: During synchronization processing. 439 . When the synchronization request completes. If the file does not exist on the target system. when synchronizing a file with triggers you must specify *DATA as the sending mode. *ATR *AUT *SAVRST Files with triggers: The SYNCDGFE command provides the ability to optionally disable triggers during synchronization processing and enable them again when processing is complete. If configuration options for the data group. When the data group is restarted. If the file exists on the target system. *DATA Sending mode (METHOD) choices on the SYNCDGFE command. Table 63 describes the choices. Choice of what to synchronize: The Sending mode (METHOD) parameter provides granularity in specifying what is synchronized. the status of the activity entries is set to either ‘completed by synchronization’ (CZ) or to ‘failed synchronization’ (FZ). About synchronizing file entries (SYNCDGFE command) The Synchronize Data Group File Entry (SYNCDGFE) command synchronizes database files associated with a data group by data group file entries. This is the default value. The Include related (RELATED) parameter defaults to *NO. This parameter is only valid when *SAVRST is specified for the Sending mode prompt. In some environments. A physical file being synchronized cannot be name mapped if it is not in the same library as the logical file associated with it. Logical files may be mapped by using object entries. Related files are those physical files which have a relationship with the selected physical file by means of one or more join logical files.Including logical files: The Include logical files (INCLF) parameter allows you to include any attached logical files in the synchronization request. Including related files: You can optionally choose whether the synchronization request will include files related to the file specified by specifying *YES for the Include related (RELATED) parameter. Doing so will ensure the integrity of synchronization points. specifying *YES could result in a high number of files being synchronized and could potentially strain available communications and take a significant amount of time to complete. When synchronizing physical files with referential constraints. 440 . Join logical files are logical files attached to fields in two or more physical files. ensure all files in the referential constraint structure are synchronized concurrently during a time of minimal activity on the source system. Physical files with referential constraints: Physical files with referential constraints require a field in another physical file to be valid. Object tracking entries represent data areas or data queues. IFS tracking entries also track the file identifier (FID) of the object on the source and target systems. For IFS tracking entries. When the apply session receives notification that the object represented by the tracking entry is synchronized successfully. data areas. the tracking entry status changes to *ACTIVE. • Tracking entries may not exist for existing IFS objects. IFS tracking entries represent IFS objects. the data group must be active. any existing objects to be replicated from the source system must be synchronized to the target system. the option calls the Synchronize Object (SYNCOBJ) command.About synchronizing tracking entries About synchronizing tracking entries Tracking entries provide status of IFS objects. you must create them by doing one of the following: • • Change the data group IFS entry or object entry configuration as needed and end and restart the data groups . the option calls the Synchronize IFS Object (SYNCIFS) command. and data queues that are replicated using MIMIX advanced journaling. attributes. or data queues that have been configured for replication with advanced journaling since the last start of the data group. data areas. • 441 . The contents. For object tracking entries. and authorities of the item are synchronized between the source and target systems. Load tracking entries using the Load DG IFS Tracking Entries (LODDGIFSTE) or Load DG Obj Tracking Entries (LODDGOBJTE) commands. If tracking entries do not exist. Notes: • • Before starting data groups for the first time. For status changes to be effective for a tracking entry that is being synchronized. See “Loading tracking entries” on page 257. You can synchronize the object represented by a tracking entry by using the synchronize option available on the Work with DG Object Tracking Entries display or the Work with DG IFS Tracking Entries display. the size of the data.Performing the initial synchronization Ensuring that data is synchronized before you begin replication is crucial to successful replication. Establish a synchronization point Just before you start the initial synchronization. Record the new receiver names shown in the posted message. For each data group that will replicate from a user journal. Note: If you have configured or migrated a MIMIX configuration to use integrated support for IBM WebSphere MQ. “Resources for synchronizing” on page 443 identifies available options. Change the system journal receiver and record the new receiver name shown in the posted message. Table 64 shows values which identify save actions associated 442 . 5. a. the complexity of describing the data. From the source system. On a command line. type: CHGJRN JRN(QAUDJRN) JRNRCV(*GEN) 4. establish a known start point for replication by changing journal receivers. and specify a time just before the first synchronize request for hh:mm:ss in the following command: DSPJRN JRN(library/jounal_name) RCVRNG(*CURRENT) FROMTIME('mm/dd/yyyy' 'hh:mm:ss') Note: You can also specify values for the ENTTYP parameter to narrow the search. record the time at which you submit the synchronization requests as this information is needed when determining the journal location at which to initially start replication. When you synchronize the database files and objects between systems. Large IBM WebSphere MQ environments should plan to perform this during off-peak hours. Quiesce your applications before continuing with the next step. specify the date of the first synchronize request for mm/dd/yyyy. This information will be needed when starting replication. On a command line. Identify the synchronization starting point in the source user journal. do the following: 1. type: (installation-library-name)/CHGDGRCV DGDFN(data-group-name) TYPE(*DB) 3. as well as time. Specify the source user journal for library/journal_name. use the following command to change the user journal receiver. The information gathered in this procedure will be used when you start replication for the first time. How you perform the initial synchronization can be influenced by the available communications bandwidth. you must use the procedure ‘Initial synchronization for replicated queue managers’ in the MIMIX for IBM WebSphere MQ book. 2. SYNC commands: The Synchronize commands (SYNCOBJ. This should be the same name as recorded in Step 3. a synchronize request is represented by a journal entry for a save operation. Identify the synchronization starting point in the source system journal. Record the exact time and the sequence number of the journal entry associated with the first synchronize request. Page down to locate the Receiver name. SYNCIFS. Table 64. 6. SS ES. Press F10 (Display only entry details). e. QY FS. in order of preference: • IBM Save and Restore commands: IBM save and restore commands are best suited for initial synchronization and are used when performing a manual synchronization. EW QX. FW Journaled Object Type File Data Area Data Queue IFS object b. Specify the date from Step 5a for mm/dd/yyyy and specify the time from Step 5b for hh:mm:ss in the following command: DSPJRN JRN(QSYS/QAUDJRN) RCVRNG(*CURRENT) FROMTIME('mm/dd/yyyy' 'hh:mm:ss') b. While MIMIX SYNCDG. Page down to locate the Receiver name. a. d. This should be the same name as recorded in Step 2. c. and SNDNET commands can be used. d. SYNCDLO) should be your starting point. e. c. Press F10 (Display only entry details). Record the sequence number associated with the first journal entry with the specified time stamp. Common values for using ENTTYP Journal Code F E Q B Common ENTTYP Values MS. This information will be needed when starting replication. The Display Journal Entry Details display appears. Type 5 (Display entire entry) next to the entry and press Enter. Type 5 (Display entire entry) next to the entry and press Enter.Performing the initial synchronization with synchronizing. Resources for synchronizing The available choices for synchronizing are. the communications bandwidth required for the size and quantity of objects may exceed capacity. Typically. These commands provide significantly • 443 . SYNC. The Display Journal Entry Details display appears. Entries display and the Work with DG Obj. This command provides the ability to choose between MIMIX copy active file processing and save/restore processing and provides choices for handling trigger programs during synchronization. You can also use the Synchronize Data Group File Entry (SYNCDGFE) to synchronize database files and members. This command can be long-running. The SYNDG command utilizes the auditing and automatic recovery functions of MIMIX® AutoGuard™ to synchronize an enabled data group between the source system and the target system. it may not be appropriate for some environments. The SYNCDG command can only be run on the management system. You can also use options to synchronize objects associated with tracking entries from the Work with DG IFS Trk. and only one instance of the command per data group can be running at any time. This command submits a batch program that can run for several days. SYNCOBJ procedures for data areas and data queues. The initial synchronization ensures that data is the same on each system and reduces the time and complexity involved with starting replication for the first time. SNDNET commands: The Send Network commands (SNDNETIFS. SNDNETDLO. • This chapter (“Synchronizing data between systems” on page 431) includes additional information about the MIMIX SYNC and SNDNET commands. The SYNCDG command synchronizes by using the auditing and automatic recovery support provided by MIMIX AutoGuard. and SYNCDGFE procedures for files containing LOB data. respectively. 444 . These commands may require multiple invocations per path. or library. follow the SYNCIFS procedures for IFS objects. folder. The SYNCDG command is intended to be used for initial synchronization of a data group and can be used in other situations where data groups are not synchronized.more flexibility in object selection and also provide the ability to synchronize object authorities. Entries display. SNDNETOBJ) support fewer options for selecting and specifying multiple objects and do not provide a way to specify by data group. If you have configured or migrated to integrated advanced journaling. Because this command requires that journaling and data group replication processes be started before synchronization starts. Using SYNCDG to perform the initial synchronization This topic describes the procedure for performing the initial synchronization using the Synchronize Data Group (SYNCDG) command prior to beginning replication. The SYNCDG command can be performed automatically through MIMIX IntelliStart. you can synchronize the data defined by its data group entries. By specifying a data group on any of these commands. • SYNCDG command: The SYNCDG command is intended especially for performing the initial synchronization of one or more data groups by MIMIX IntelliStart™. Trk. Click Advanced and specify the following values by pressing F4 for valid options on each parameter or use the drop-down menu: 445 . select Start All from the Action drop-down.select the system for which you want to perform the initial synchronization. Ensure the following conditions are met for each data group that you want to synchronize. b. Collector services has been started. Systems . Log in to Support Central and access the Technical Documents page for a list of required and recommended IBM PTFs. From the upper portion of the Data Groups Status window. before running this command: • Apply any IBM PTFs (or their supersedes) associated with IBM i releases as they pertain to your environment.select the installation for which you want to perform the initial synchronization. Details . This feature is in use if a recovery window is configured or when a recovery point is set for a data group. From the Details section of the navigation bar. • • • • • While the synchronization is in progress. Also. Select the following from the navigation bar: a. select Command History. MIMIX Availability Manager displays initialization mode on the Audit Summary and Compliance interfaces while running this command if the data group definition (DGDFN) specifies *ALL. The Start Data Groups window appears.Using SYNCDG to perform the initial synchronization Note: The SYNCDG command will not process a request to synchronize a data group that is currently using the MIMIX CDP™ feature. 4. The user ID submitting the SYNCDG has *MGT authority in product level security if it is enabled for the installation. Installations . The MIMIX CDP feature may not protect data under these circumstances. Journaling is started on the source system for everything defined to the data group. To perform the initial synchronization using the SYNCDG command defaults From MIMIX Availability Manager. The Synchronize Data Group (SYNCDG) command prompt opens. All replication processes are active. 5. c. No other audits (comparisons or recoveries) are in progress when the SYNCDG is requested. In the Command History window type SYNCDG and click on the Prompt button. do not configure a recovery window or set a recovery point if a SYNCDG request is in progress for the data group. other audits for the data group are prevented from running. 6. do the following: 1. 2. Accept the defaults and click OK.select Data Groups. 3. • Data group definition (DGDFN). Type the command SYNCDG and press Enter. • Job description (JOBD). 8. do the following: 1. From a 5250 emulator. Verify your configuration is using MIMIX AutoGuard. 4. See “Verifying the initial synchronization” on page 447 for more information. Audits automatically check for and attempt to correct differences found between the source system and the target system. Specify the following values. See “Verifying the initial synchronization” on page 447 for more information. • Job description (JOBD). Click on OK to perform the initial synchronization. Verify your configuration is using MIMIX AutoGuard. 446 . pressing F4 for valid options on each parameter: • Data group definition (DGDFN). 3. Press Enter to perform the initial synchronization. 7. This step includes performing audits to verify that journaling and other aspects of your environment are ready to use. This step includes performing audits to verify that journaling and other aspects of your environment are ready to use. Audits automatically check for and attempt to correct differences found between the source system and the target system. Use the command STRDG DGDFN(*ALL) 2. Use F18 (Subset) to subset the audits by the name of the rule you want to run. If your configuration permits user journal replication of IFS objects. Do the following: a. shown in Table 65. you need to perform a subset of the available audits for each data group in a specific order. Enter the following command: (installation-library-name)/DSPDGSTS DGDFN(data-group-name) VIEW(*DBFETE) On the File and Tracking Entry Status display. Audits will detect potential problems with synchronization and attempt to automatically recover differences found. c. enter the following command: (installation-library-name)/WRKAUD 3. the Tracking Entries columns provide similar information. When verifying an initial configuration. You should not use this procedure if you have already synchronized your systems using the Synchronize Data Group (SYNCDG) command or the automatic synchronization method in MIMIX IntelliStart. Verify that data is synchronized between systems. To change the number of active audits at any one time. Shipped policy settings for MIMIX allow audits to automatically attempt recovery actions for any problems they detect. 2. • Do the following: 1.Verifying the initial synchronization Verifying the initial synchronization This procedure uses MIMIX AutoGuard™ to ensure your environment is ready to start replication. enter the following command: CHGJOBQE SBSD(MIMIXQGPL/MIMIXSBS) JOBQ(MIMIXQGPL/MIMIXVFY) MAXACT(*NOMAX) b. To access the audits. The audits used in this procedure will: • Verify that journaling is started on the source and target systems for the items you identified in the deployed replication patterns. data areas. Use MIMIX AutoGuard to audit your environment. Each audit listed on the Work with Audits display is a unique combination of data group and MIMIX rule. the File Entries column identifies how many file entries were configured from your replication patterns and indicates whether any file entries are not journaled on the source or target systems. 447 . Check whether all necessary journaling is started for each data group. Without journaling. Type a 9 (Run rule) next to the audit for each data group and press Enter. or data queues. replication will not occur. Then check the results and resolve any problems. Rules for initial validation. Action is required.Repeat Step 3b and Step 3c for each rule in Table 65 until you have started all the listed audits for all data groups. see “Interpreting audit results” on page 540. 448 . #FILATR 4. Some audits may take time to complete. Table 65. Some of the differences were not automatically recovered. #DLOATR d. Wait for all audits to complete. check the Audit Status column for the following value: *NOTRCVD . You may need to change subsetting values again so you can view all rule and data group combinations at once. #IFSATR 5. View notifications for more information and resolve the problem. Note: For more information about resolving reported problems. #DGFE 2. #OBJATR 3. Reset the number of active audit jobs to values consistent with regular auditing: CHGJOBQE SBSD(MIMIXQGPL/MIMIXSBS) JOBQ(MIMIXQGPL/MIMIXVFY) MAXACT(5) 4. listed in the order to be performed. On the Work with Audits display. #FILATRMBR 6.The comparison performed by the rule detected differences. Rule Name 1. In Step 8 and Step 9. specify its name at the Member prompt. see “About synchronizing file entries (SYNCDGFE command)” on page 439. select option 12 (Compare. 2. 449 . use the procedure from the source system to send database files to the target system. specify the name of the data group to which the file is associated. If you want to hold the file entry for your intervention. Then it will change the status to active. 4. you will need to make choices about the sending mode and trigger support. and Synchronize menu. Alternative Process: You will need to identify the data group and data group file entry in this procedure. select option 41 (Synchronize DG File Entry) and press Enter. verify. 6. all file entries will be synchronized. 7. You should be aware of the information in the following topics: • • “Considerations for synchronizing using MIMIX commands” on page 433 “About synchronizing file entries (SYNCDGFE command)” on page 439. If you use this command when performing the initial synchronization of a data group. 5. From the Work with DG Definitions display. To synchronize a database file between two systems using the SYNCDGFE command defaults. At the Data group definition prompts. ensure that the value matches the system that you want to use as the source for the synchronization. 3. If you want to synchronize only one member of a file. you can type 16 next to the first file entry and then press F13 (Repeat). 2. between two systems. Verify. From the MIMIX Intermediate Main Menu. When you press Enter. At the System 1 file and Library prompts. The Synchronize DG File Entry (SYNCDGFE) display appears. From the MIMIX Compare. The default value *YES for the Release wait prompt indicates that MIMIX will hold the file entry in a release-wait state until a synchronization point is reached. do the following or use the alternative process described below: 1. and synchronize menu) and press Enter.Synchronizing database files Synchronizing database files The procedures in this topic use the Synchronize DG File Entry (SYNCDGFE) command to synchronize selected database files associated with a data group. 1. At the Data source prompt. The Work with DG File Entries display appears. type 17 (File entries) next to the data group to which the file you want to synchronize is defined and press Enter. Type 16 (Sync DG file entry) next to the file entry for the file you want to synchronize and press Enter. specify the name of the database file you want to synchronize and the library in which it is located on system 1. Note: If you are synchronizing file entries as part of your initial configuration. specify *NO. For additional information. press Enter 450 . At the Save active wait time prompt. 9. At the Disable triggers on file prompt. 14. specify whether the database apply process should disable triggers when processing the file. accept *NO so that objects in use are not saved. To synchronize the file. accept the default or specify *YES to indicate whether certain differences encountered during the restore of the object on the target system should be allowed. To change any of the additional parameters. accept the default or *NO to indicate whether you want to include attached logical files when sending the file. specify the value for the type of data to be synchronized. At the Sending mode prompt. At the Include logical files prompt. press F10 (Additional parameters). specify the number of seconds to wait for a commit boundary or a lock on the object before continuing the save. 12.8. 15. or. Accept *DGFE to use the value specified in the data group file entry or specify another value. At the Allow object differences prompt. Verify that the values shown for Include related files. Maximum sending file size (MB) and Submit to batch are what you want. 11. At the Save active prompt. 13. specify another value. Skip to Step 14. 10. At the Data group definition prompts. 2. The objects to be synchronized can be defined to a data group or can be independent of a data group. accept *ALL to synchronize the entire list of supported attributes or press F4 to select from a list of attributes. accept *INCLUDE to include the object for synchronization or specify *OMIT to omit the object from synchronization. skip to Step 5. At the Include or omit prompt. To synchronize a subset of objects defined to the data group. do the following: 1. You can specify as many as 300 object selectors by using the + for more prompt for each selector. and DLOs” on page 437 To synchronize library-based objects associated with a data group To synchronize objects between two systems that are identified for replication by data group object entries. specify the data group for which you want to synchronize objects. For each selector. From the MIMIX Intermediate Main Menu. At the Object type prompt. IFS objects. specify the name or the generic value you want. At the Object attribute prompt. To synchronize all objects identified by data group object entries for this data group. 3. Note: if you run this command from a target system. b. From the MIMIX Compare. at the Object prompts specify elements for one or more object selectors to act as filters to the objects defined to the data group. For more information. select option 12 (Compare. Press Enter. see see “Object selection for Compare and Synchronize commands” on page 360. Note: The System 2 object and System 2 library prompts are ignored when a data group is specified. At the Synchronize authorities prompt. and synchronize menu) and press Enter. c. and Synchronize Menu. accept *ALL or specify a specific object type to synchronize. select option 42 (Synchronize object) and press Enter. do the following: a. The Synchronize Object (SYNCOBJ) command appears. d. Verify. At the Object and library prompts. accept *YES to synchronize both 451 . you must specify the name of a data group to avoid overwriting the objects on the source system. 4. You should be aware of the information in the following topics: • • “Considerations for synchronizing using MIMIX commands” on page 433 “About MIMIX commands for synchronizing objects. 5. e. verify.Synchronizing objects Synchronizing objects The procedures in this topic use the Synchronize Object (SYNCOBJ) command to synchronize library-based objects between two systems. authorities and objects or specify another value. 6. At the Save active prompt, accept *NO to specify that objects in use are not saved. Or, specify another value. 7. At the Save active wait time, specify the number of seconds to wait for a commit boundary or a lock on the object before continuing the save. 8. At the Maximum sending size (MB) prompt, specify the maximum size that an object can be and still be synchronized. Note: When a data group is specified the following parameters are ignored: System 1 ASP group or device, System 2 ASP device number, and System 2 ASP device name. 9. Determine how the synchronize request will be processed. Choose one of the following: • • To submit the job for batch processing, accept the default value *YES for the Submit to batch prompt and press Enter. Continue with the next step. To not use batch processing for the job, specify *NO for the Submit to batch prompt and press Enter. The request to synchronize will be started. 10. At the Job description and Library prompts, specify the name and library of the job description used to submit the batch request. 11. At the Job name prompt, accept *CMD to use the command name to identify the job or specify a simple name. 12. To start the synchronization, press Enter. To synchronize library-based objects without a data group To synchronize objects between two systems, do the following: 1. From the MIMIX Intermediate Main Menu, select option 12 (Compare, verify, and synchronize menu) and press Enter. 2. From the MIMIX Compare, Verify, and Synchronize Menu, select option 42 (Synchronize object) and press Enter. The Synchronize Object (SYNCOBJ) command appears. 3. At the Data group definition prompts, specify *NONE. 4. At the Object prompts, specify elements for one or more object selectors that identify objects to synchronize. You can specify as many as 300 object selectors by using the + for more prompt for each selector. For more information, see “Object selection for Compare and Synchronize commands” on page 360. For each selector, do the following: a. At the Object and library prompts, specify the name or the generic value you want. b. At the Object type prompt, accept *ALL or specify a specific object type to synchronize. 452 Synchronizing objects c. At the Object attribute prompt, accept *ALL to synchronize the entire list of supported attributes or press F4 to see a valid list of attributes. d. At the Include or omit prompt, accept *INCLUDE to include the object for synchronization or specify *OMIT to omit the object from synchronization. e. At the System 2 object and System 2 library prompts, if the object and library names on system 2 are equal to the system 1 names, accept the defaults. Otherwise, specify the name of the object and library on system 2 to which you want to synchronize the objects. f. Press Enter. 5. At the System 2 parameter prompt, specify the name of the remote system to which to synchronize the objects. 6. At the Synchronize authorities prompt, accept *YES to synchronize both authorities and objects or specify another value. Note: When you specify *ONLY and a data group name is not specified, if any files that are processed by this command are cooperatively processed and the data group that contains these files is active, the command could fail if the database apply job has a lock on these files. 7. At the Save active prompt, accept *NO to specify that objects in use are not saved or specify another value. 8. At the Save active wait time, specify the number of seconds to wait for a commit boundary or a lock on the object before continuing the save. 9. At the Maximum sending size (MB) prompt, specify the maximum size that an object can be and still be synchronized. 10. At the System 1 ASP group or device prompt, specify the name of the auxiliary storage pool (ASP) group or device where objects configured for replication may reside on system 1. Otherwise, accept the default to use the current job’s ASP group name. 11. At the System 2 ASP device number prompt, specify the number of the auxiliary storage pool (ASP) where objects configured for replication may reside on system 2. Otherwise, accept the default to use the same ASP number from which the object was saved (*SAVASP). Only the libraries in the system ASP and any basic user ASPs from system 2 will be in the library name space. 12. At the System 2 ASP device name prompt, specify the name of the auxiliary storage pool (ASP) device where objects configured for replication may reside on system 2. Otherwise, accept the default to use the value specified for the system 1 ASP group or device (*ASPGRP1). 13. Determine how the synchronize request will be processed. Choose one of the following • • To submit the job for batch processing, accept the default value *YES for the Submit to batch prompt and press Enter. To not use batch processing for the job, specify *NO for the Submit to batch prompt and press Enter. The request to synchronize will be started. 453 14. At the Job description and Library prompts, specify the name and library of the job description used to submit the batch request. 15. At the Job name prompt, accept *CMD to use the command name to identify the job or specify a simple name. 16. To start the synchronization, press Enter. 454 Synchronizing IFS objects Synchronizing IFS objects The procedures in this topic use the Synchronize IFS Object (SYNCIFS) command to synchronize IFS objects between two systems. The IFS objects to be synchronized can be defined to a data group or can be independent of a data group. You should be aware of the information in the following topics: • • “Considerations for synchronizing using MIMIX commands” on page 433 “About MIMIX commands for synchronizing objects, IFS objects, and DLOs” on page 437 To synchronize IFS objects associated with a data group To synchronize IFS objects between two systems that are identified for replication by data group IFS entries, do the following: 1. From the MIMIX Intermediate Main Menu, select option 12 (Compare, verify, and synchronize menu) and press Enter. 2. From the MIMIX Compare, Verify, and Synchronize menu, select option 43 (Synchronize IFS object) and press Enter. The Synchronize IFS Object (SYNCIFS) command appears. 3. At the Data group definition prompts, specify the data group for which you want to synchronize objects. Note: if you run this command from a target system, you must specify the name of a data group to avoid overwriting the objects on the source system. 4. To synchronize all IFS objects identified by data group IFS entries for this data group, skip to Step 5. To synchronize a subset of IFS objects defined to the data group, at the IFS objects prompts specify elements for one or more object selectors to act as filters to the objects defined to the data group. For more information, see “Object selection for Compare and Synchronize commands” on page 360. You can specify as many as 300 object selectors by using the + for more prompt for each selector. For each selector, do the following: a. At the Object path name prompt, you can optionally accept *ALL or specify the name or generic value you want. Note: The IFS object path name can be used alone or in combination with FID values. See Step 12. b. At the Directory subtree prompt, accept *NONE or specify *ALL to define the scope of IFS objects to be processed. c. At the Name pattern prompt, specify a value if you want to place an additional filter on the last component of the IFS object path name. d. At the Object type prompt, accept *ALL or specify a specific IFS object type to synchronize. 455 e. At the Include or omit prompt, accept *INCLUDE to include the object for synchronization or specify *OMIT to omit the object from synchronization. Note: The System 2 object path name and System 2 name pattern values are ignored when a data group is specified. f. Press Enter. 5. At the Synchronize authorities prompt, accept *YES to synchronize both authorities and objects or specify another value. 6. At the Save active prompt, accept *NO to specify that objects in use are not saved or specify another value. 7. If you chose values in Step 6 to save active objects, you can optionally specify additional options at the Save active option prompt. Press F1 (Help) for additional information. 8. At the Maximum sending size (MB) prompt, specify the maximum size that an object can be and still be synchronized. 9. Determine how the synchronize request will be processed. Choose one of the following: • • To submit the job for batch processing, accept the default value *YES for the Submit to batch prompt and press Enter. Continue with the next step. To not use batch processing for the job, specify *NO for the Submit to batch prompt and press Enter. Continue with Step 12. 10. At the Job description and Library prompts, specify the name and library of the job description used to submit the batch request. 11. At the Job name prompt, accept *CMD to use the command name to identify the job or specify a simple name. 12. To optionally specify a file identifier (FID) for the object on either system, do the following: a. At the System 1 file identifier prompt, specify the file identifier (FID) of the IFS object on system 1. Values for System 1 file identifier prompt can be used alone or in combination with the IFS object path name. b. At the System 2 file identifier prompt, specify the file identifier (FID) of the IFS object on system 2. Values for System 2 file identifier prompt can be used alone or in combination with the IFS object path name. Note: For more information, see “Using file identifiers (FIDs) for IFS objects” on page 284. 13. To start the synchronization, press Enter. To synchronize IFS objects without a data group To synchronize IFS objects not associated with a data group between two systems, do the following: 1. From the MIMIX Intermediate Main Menu, select option 12 (Compare, verify, and synchronize menu) and press Enter. 456 Synchronizing IFS objects 2. From the MIMIX Compare, Verify, and Synchronize menu, select option 43 (Synchronize IFS object) and press Enter. The Synchronize IFS Object (SYNCIFS) command appears. 3. At the Data group definition prompts, specify *NONE. 4. At the IFS objects prompts, specify elements for one or more object selectors that identify IFS objects to synchronize. You can specify as many as 300 object selectors by using the + for more prompt for each selector. For more information, see the topic on object selection in the MIMIX Reference book. For each selector, do the following: a. At the Object path name prompt, you can optionally accept *ALL or specify the name or generic value you want. Note: The IFS object path name can be used alone or in combination with FID values. See Step 13. b. At the Directory subtree prompt, accept *NONE or specify *ALL to define the scope of IFS objects to be processed. c. At the Name pattern prompt, specify a value if you want to place an additional filter on the last component of the IFS object path name. d. At the Object type prompt, accept *ALL or specify a specific IFS object type to synchronize. e. At the Include or omit prompt, accept *INCLUDE to include the object for synchronization or specify *OMIT to omit the object from synchronization. f. At the System 2 object path name and System 2 name pattern prompts, if the IFS object path name and name pattern on system 2 are equal to the system 1 names, accept the defaults. Otherwise, specify the path name and pattern on system 2 to which you want to synchronize the IFS objects. g. Press Enter. 5. At the System 2 parameter prompt, specify the name of the remote system on which to synchronize the IFS objects. 6. At the Synchronize authorities prompt, accept *YES to synchronize both authorities and objects or specify another value. 7. At the Save active prompt, accept *NO to specify that objects in use are not saved or specify another value. 8. If you chose values in Step 7 to save active objects, you can optionally specify additional options at the Save active option prompt. Press F1 (Help) for additional information. 9. At the Maximum sending size (MB) prompt, specify the maximum size that an object can be and still be synchronized. 10. Determine how the synchronize request will be processed. Choose one of the following: • To submit the job for batch processing, accept the default value *YES for the Submit to batch prompt and press Enter. Continue with the next step. 457 • To not use batch processing for the job, specify *NO for the Submit to batch prompt and press Enter. Continue with Step 13. 11. At the Job description and Library prompts, specify the name and library of the job description used to submit the batch request. 12. At the Job name prompt, accept *CMD to use the command name to identify the job or specify a simple name. 13. To optionally specify a file identifier (FID) for the object on either system, do the following: a. At the System 1 file identifier prompt, specify the file identifier (FID) of the IFS object on system 1. Values for System 1 file identifier prompt can be used alone or in combination with the IFS object path name. b. At the System 2 file identifier prompt, specify the file identifier (FID) of the IFS object on system 2. Values for System 2 file identifier prompt can be used alone or in combination with the IFS object path name. Note: For more information, see “Using file identifiers (FIDs) for IFS objects” on page 284. 14. To start the synchronization, press Enter. 458 Synchronizing DLOs Synchronizing DLOs The procedures in this topic use the Synchronize DLO (SYNCDLO) command to synchronize document library objects (DLOs) between two systems. The DLOs to be synchronized can be defined to a data group or can be independent of a data group. You should be aware of the information in the following topics: • • “Considerations for synchronizing using MIMIX commands” on page 433 “About MIMIX commands for synchronizing objects, IFS objects, and DLOs” on page 437 To synchronize DLOs associated with a data group To synchronize DLOs between two systems that are identified for replication by data group DLO entries, do the following: 1. From the MIMIX Intermediate Main Menu, select option 12 (Compare, verify, and synchronize menu) and press Enter. 2. From the MIMIX Compare, Verify, and Synchronize Menu, select option 44 (Synchronize DLO) and press Enter. The Synchronize DLO (SYNCDLO) command appears. 3. At the Data group definition prompts, specify the data group for which you want to synchronize DLOs. Note: if you run this command from a target system, you must specify the name of a data group to avoid overwriting the objects on the source system. 4. To synchronize all objects identified by data group DLO entries for this data group, skip to Step 5. To synchronize a subset of objects defined to the data group, at the Document library objects prompts specify elements for one or more object selectors to act as filters to DLOs defined to the data group. For more information, see “Object selection for Compare and Synchronize commands” on page 360. You can specify as many as 300 object selectors by using the + for more prompt for each selector. For each selector, do the following: a. At the DLO path name prompt, accept *ALL or specify the name or the generic value you want. b. At the Folder subtree prompt, accept *NONE or specify *ALL to define the scope of DLOs to be processed. c. At the Name pattern prompt, specify a value if you want to place an additional filter on the last component of the DLO path name. d. At the DLO type prompt, accept *ALL or specify a specific DLO type to synchronize. e. At the Owner prompt, accept *ALL or specify the owner of the DLO. f. At the Include or omit prompt, accept *INCLUDE to include the object for synchronization or specify *OMIT to omit the object from synchronization. Note: The System 2 DLO path name and System 2 DLO name pattern values 459 are ignored when a data group is specified. g. Press Enter. 5. At the Synchronize authorities prompt, accept *YES to synchronize both authorities and objects or specify another value. 6. At the Save active prompt, accept *NO to specify that objects in use are not saved or specify another value. 7. At the Save active wait time, specify the number of seconds to wait for a lock on the object before continuing the save. 8. At the Maximum sending size (MB) prompt, specify the maximum size that an object can be and still be synchronized. 9. Determine how the synchronize request will be processed. Choose one of the following: • • To submit the job for batch processing, accept the default value *YES for the Submit to batch prompt and press Enter. Continue with the next step. To not use batch processing for the job, specify *NO for the Submit to batch prompt and press Enter. The request to synchronize will be started. 10. At the Job description and Library prompts, specify the name and library of the job description used to submit the batch request. 11. At the Job name prompt, accept *CMD to use the command name to identify the job or specify a simple name. 12. To start the synchronization, press Enter. To synchronize DLOs without a data group To synchronize DLOs between two systems, do the following: 1. From the MIMIX Intermediate Main Menu, select option 12 (Compare, verify, and synchronize menu) and press Enter. 2. From the MIMIX Compare, Verify, and Synchronize Menu, select option 44 (Synchronize DLO) and press Enter. The Synchronize DLO (SYNCDLO) command appears. 3. At the Data group definition prompts, specify *NONE. 4. At the Document library objects prompts, specify elements for one or more object selectors that identify DLOs to synchronize. You can specify as many as 300 object selectors by using the + for more prompt for each selector. For more information, see “Object selection for Compare and Synchronize commands” on page 360. For each selector, do the following: a. At the DLO path name prompt, accept *ALL or specify the name or the generic value you want. b. At the Folder subtree prompt, accept *NONE or specify *ALL to define the scope of DLOs to be processed. 460 Synchronizing DLOs c. At the Name pattern prompt, specify a value if you want to place an additional filter on the last component of the DLO path name. d. At the DLO type prompt, accept *ALL or specify a specific DLO type to synchronize. e. At the Owner prompt, accept *ALL or specify the owner of the DLO. f. At the Include or omit prompt, accept *INCLUDE to include the object for synchronization or specify *OMIT to omit the object from synchronization. g. At the System 2 DLO path name and System 2 DLO name pattern prompts, if the DLO path name and name pattern on system 2 are equal to the system 1 names, accept the defaults. Otherwise, specify the path name and pattern on system 2 to which you want to synchronize the DLOs. h. Press Enter. 5. At the System 2 parameter prompt, specify the name of the remote system on which to synchronize the DLOs. 6. At the Synchronize authorities prompt, accept *YES to synchronize both authorities and objects or specify another value. 7. At the Save active prompt, accept *NO to specify that objects in use are not saved or specify another value. 8. At the Save active wait time, specify the number of seconds to wait for a lock on the object before continuing the save. 9. At the Maximum sending size (MB) prompt, specify the maximum size that an object can be and still be synchronized. 10. Determine how the synchronize request will be processed. Choose one of the following: • • To submit the job for batch processing, accept the default value *YES for the Submit to batch prompt and press Enter. Continue with the next step. To not use batch processing for the job, specify *NO for the Submit to batch prompt and press Enter. The request to synchronize will be started. 11. At the Submit to batch prompt, do one of the following: • • If you do not want to submit the job for batch processing, specify *NO and press Enter to start the comparison. To submit the job for batch processing, accept the default. Press Enter and continue with the next step. 12. At the Job description and Library prompts, specify the name and library of the job description used to submit the batch request. 13. At the Job name prompt, accept *CMD to use the command name to identify the job or specify a simple name. 14. To start the synchronization, press Enter. 461 Synchronizing data group activity entries The procedures in this topic use the Synchronize DG Activity Entry (SYNCDGACTE) command to synchronize an object that is identified by a data group activity entry with any status value—*ACTIVE, *DELAYED, *FAILED, or *COMPLETED. You should be aware of the information in the following topics: • • “Considerations for synchronizing using MIMIX commands” on page 433 “About synchronizing data group activity entries (SYNCDGACTE)” on page 438 To synchronize an object identified by a data group activity entry, do the following: 1. From the Work with Data Group Activity Entry display, type 16 (Synchronize) next to the activity entry that identifies the object you want to synchronize and press Enter. 2. The Confirm Synchronize of Object display appears. Press Enter to confirm the synchronization. Alternative Process: You will need to identify the data group and data group activity entry in this procedure. 1. From the MIMIX Intermediate Main Menu, select option 12 (Compare, verify, and synchronize menu) and press Enter. 2. From the MIMIX Compare, Verify, and Synchronize menu, select option 45 (Synchronize DG File Entry) and press Enter. 3. At the Data group definition prompts, specify the data group name. 4. At the Object type prompt, specify a specific object type to synchronize or press F4 to see a valid list. 5. Additional parameters appear based on the object type selected. Do one of the following: • • • • For files, you will see the Object, Library, and Member prompts. Specify the object, library and member that you want to synchronize. For objects, you will see the Object and Library prompts. Specify the object and library of the object you want to synchronize. For IFS objects, you will see the IFS object prompt. Specify the IFS object that you want to synchronize. For DLOs, you will see the Document library object and Folder prompts. Specify the folder path and DLO name of the DLO you want to synchronize. 6. Determine how the synchronize request will be processed. Choose one of the following: • • To submit the job for batch processing, accept the default value *YES for the Submit to batch prompt and press Enter. Continue with the next step. To not use batch processing for the job, specify *NO for the Submit to batch prompt and press Enter. The request to synchronize will be started. 462 Synchronizing data group activity entries 7. At the Job description and Library prompts, specify the name and library of the job description used to submit the batch request. 8. At the Job name prompt, accept *CMD to use the command name to identify the job or specify a simple name. 9. To start the synchronization, press Enter. 463 Synchronizing tracking entries Tracking entries are MIMIX constructs which identify IFS objects, data areas, or data queues configured for replication with MIMIX advanced journaling. You can use a tracking entry to synchronize the contents, attributes, and authorities of the item it represents. You should be aware of the information in the following topics: • • • “Considerations for synchronizing using MIMIX commands” on page 433 “About MIMIX commands for synchronizing objects, IFS objects, and DLOs” on page 437 “About synchronizing tracking entries” on page 441 To synchronize an IFS tracking entry To synchronize an object represented by an IFS tracking entry, do the following: 1. From the Work with DG IFS Tracking Entries (WRKDGIFSTE) display, type option 16 (Synchronize) next to the IFS tracking entry you want to synchronize. If you want to change options on the command SYNCIFS command, press F4 (Prompt). 2. To synchronize the associated IFS object, press Enter. 3. When the apply session has been notified that the object has been synchronized, the status will change to *ACTIVE. To monitor the status, press F5 (Refresh). 4. If the synchronization fails, correct the errors and repeat the previous steps. To synchronize an object tracking entry To synchronize an object represented by an object tracking entry, do the following: 1. From the Work with DG Object Tracking Entries (WRKDGOBJTE) display, type option 16 (Synchronize) next to the object tracking entry you want to synchronize. If you want to change options on the SYNCOBJ command, press F4 (Prompt). 2. To synchronize the associated data area or data queue, press Enter. 3. When the apply session has been notified that the object has been synchronized, the status will change to *ACTIVE. To monitor the status, press F5 (Refresh). 4. If the synchronization fails, correct the errors and repeat the previous steps. 464 Sending library-based objects Sending library-based objects This procedure sends one or more library-based objects between two systems using the Send Network Object (SNDNETOBJ) command. Use the appropriate command: In general, you should use the SYNCOBJ command to synchronize objects between systems. For more information about differences between commands, see “Performing the initial synchronization” on page 442. You should be familiar with the information in the following topics before you use this command: • • • “Considerations for synchronizing using MIMIX commands” on page 433 “Synchronizing user profiles with the SNDNETOBJ command” on page 434 “Missing system distribution directory entries automatically added” on page 435 To send library-based objects between two systems, do the following: 1. If the objects you are sending are located in an independent auxiliary storage pool (ASP) on the source system, you must use the IBM command Set ASP Group (SETASPGRP) on the local system to change the ASP group for your job. This allows MIMIX to access the objects. 2. From the MIMIX Intermediate Main Menu, select option 13 (Utilities menu) and press Enter. 3. The MIMIX Utilities Menu appears. Select option 11 (Send object) and press Enter. 4. The Send Network Object (SNDNETOBJ) display appears. At the Object prompt, specify either *ALL, the name of an object, or a generic name. Note: You can specify as many as 50 objects. To expand this prompt for multiple entries, type a plus sign (+) at the prompt and press Enter. 5. Specify the name of the library that contains the objects at the Library prompt. 6. Specify the type of objects to be sent from the specified library at the Object type prompt. Notes: • If you specify *ALL, all object types supported by the IBM i Save Object (SAVOBJ) command are selected. The single values that are listed for this parameter are not included when *ALL is specified because they are not supported by the IBM i SAVOBJ command. To expand this field for multiple entries, type a plus sign (+) at the prompt and press Enter. • 7. Press Enter. 8. Additional prompts appear on the display. Do the following: a. Specify the name of the system to which you are sending objects at the Remote system prompt. 465 authority to the object on the remote system is determined by that system. Specifying 2 through 32 restores values to the basic user ASP specified. *JRNRCV. Specifying a value of 1 restores objects to the system ASP. place the cursor on the prompt and press F1 (Help). objects are restored to the same ASP device or number from which they were saved. The remaining prompts on the display are used for objects synchronized via a save and restore operation. Verify that the values shown are what you want. IBM restricts which object types are allowed in user ASPs. To have the authorities on the remote system determined by the settings of the local system. press F10 (Additional parameters). If the specified ASP number does not exist on the target system or if it has overflowed. By default. 466 . If the library on the remote system has a different name. then specify a value for either the Restore to ASP device prompt or the Restore to ASP number prompt. To change the location where objects are restored. Some object types may not be restored to user ASPs.b. Note: Object types *JRN. then specify *SRC at the Target authority prompt. 9. press Enter. 10. To start sending the specified objects. the objects are placed in the system ASP on the target system. press F10 (Additional parameters). 11. By default. *LIB. To see a description of each prompt and its available values. c. specify its name at the Remote library prompt. and *SAVF can be restored to any ASP. Additional parameters appear which MIMIX uses in the save and restore operations. 5. You should be familiar with the information in “Considerations for synchronizing using MIMIX commands” on page 433. At the Object prompt. you should use the SYNCIFS command to synchronize IFS objects between systems. do the following: 1. From the MIMIX Intermediate Main Menu. 4. the name of the IFS object to send. 6. For more information about differences between commands. Use the appropriate command: In general. place the cursor on the prompt and press F1 (Help). To start sending the specified IFS objects. The MIMIX Utilities Menu appears. 467 . 7. Select option 13 (Send IFS object) and press Enter. see “Performing the initial synchronization” on page 442. Press F10 (Additional parameters). To send IFS objects between two systems. Verify that the values shown for the additional prompts are what you want.Sending IFS objects Sending IFS objects This procedure uses IBM i save and restore functions to send one or more integrated files system (IFS) objects between two systems with the Send Network IFS (SNDNETIFS) command. press Enter. Note: You can specify as many as 30 IFS objects. To expand this prompt for multiple entries. Specify the name of the system to which you are sending IFS objects at the Remote system prompt. 3. select option 13 (Utilities menu) and press Enter. The Send Network IFS (SNDNETIFS) display appears. type a plus sign (+) at the prompt and press Enter. To see a description of each prompt and its available values. 2. 10. Save active. Save active wait time. 4. and Allow object differences prompts in the save and restore operations. 2. Press F10 (Additional parameters). Note: You can specify multiple DLOs. Specify a folder name in the Folder field and a network system name in the Remote system field. Use the appropriate command: In general. use this procedure from the source system to send DLOs to the target system for replication. Specify the name of the folder that contains the DLOs at the Folder prompt. By default. press Enter. 5. To expand this prompt for multiple entries. Additional parameters appear on the display. At the Document library object prompt. specify *SRC at the Target authority prompt. To start sending the specified DLOs. To have the authorities on the remote system determined by the settings of the local system. Verify that the values shown are what you want. From the MIMIX Intermediate Main Menu. To send DLO objects between systems. 468 .Sending DLO objects This procedure uses IBM i save and restore functions to send one or more document library objects (DLOs) between two systems using the Send Network DLO (SNDNETDLO) command. When you are configuring for system journal replication. 6. 3. The MIMIX Utilities Menu appears. see “Performing the initial synchronization” on page 442. Select option 12 (Send DLO object) and press Enter. specify either *ALL or the name of the DLO. To see a description of each prompt and its available values. authority to the object on the remote system is determined by that system. select option 13 (Utilities menu) and press Enter. For more information about differences between commands. you should use the SYNCDLO command to synchronize objects between systems. 9. place the cursor on the prompt and press F1 (Help). MIMIX uses the Remote folder. 7. type a plus sign (+) at the prompt and press Enter. Specify the name of the system to which you are sending DLOs at the Remote system prompt. The Send Network DLO (SNDNETDLO) display appears. do the following: 1. 8. You should be familiar with the information in “Considerations for synchronizing using MIMIX commands” on page 433. The topics in this chapter include: • • “Support for customizing” on page 470 describes several functions you can use to customize your replication environment. “Completion and escape messages for comparison commands” on page 472 lists completion. RUNCMDS” on page 487 provides procedures for using run commands with a specific protocol or by specifying a protocol through existing MIMIX configuration elements. The MIMIX message log provides a common location to see messages from all MIMIX products. “Procedures for running commands RUNCMD. including outfiles. “Displaying a list of commands in a library” on page 485 describes how to display the super set of all commands known to License Manager or subset the list by a particular library. diagnostic. MIMIX supports batch output jobs on numerous commands and provides several forms of output. “Adding messages to the MIMIX message log” on page 479 describes how you can include your own messaging from automation programs in the MIMIX message log. Commands are typically set with default values that reflect the recommendation of Vision Solutions. “Running commands on a remote system” on page 486 describes how to run a single command or multiple commands on a remote system. see “Output and batch guidelines” on page 480. For more information.CHAPTER 21 Introduction to programming MIMIX includes a variety of functions that you can use to extend MIMIX capabilities through automation and customization. and escape messages generated by comparison commands. “Changing command defaults” on page 494 provides a method for customizing default values should your business needs require it. • • • • • • • 469 . “Using lists of retrieve commands” on page 493 identifies how to use MIMIX list commands to include retrieve commands in automation. Collision resolution In the context of high availability. For more information. You can specify collision resolution methods for a data group or for individual data group file entries. MIMIX provides user exit points for journal receiver management. Examples of these detected conditions include the following: • • • • Updating a record that does not exist Deleting a record that does not exist Writing to a record that already exists Updating a record for which the current record information does not match the before image The database apply process contains 12 collision points at which MIMIX can attempt to resolve a collision. a collision is a clash of data that occurs when a target object and a source object are both updated at the same time. With MIMIX user journal replication. This process is called collision resolution.Support for customizing MIMIX includes several functions that you can use to customize processing within your replication environment. You can also specify a named collision resolution class. MIMIX provides additional ways to automatically resolve detected collisions without user intervention. If a collision does occur. “Customizing with exit point programs. When the change to the source object is replicated to the target object. With collision resolution. see Chapter 22. the data does not match and the collision is detected. MIMIX attempts the specified collision resolution methods until either the collision is resolved or the file is placed on hold. the definition of a collision is expanded to include any condition where the status of a file or a record is not what MIMIX determines it should be when MIMIX applies a journal transaction. When a collision is detected. User exit points User exit points are predefined points within a MIMIX process at which you can call customized programs. MIMIX attempts to fix any problems it detects by synchronizing the file. A collision resolution class allows you to define what type of resolution to use at each of the collision points. User exit points allow you insert customized programs at specific points in an application process to perform additional processing before continuing with the application's processing. you can specify different resolution methods to handle these different types of collisions. by default the file is placed on hold due to an error (*HLDERR) and user action is needed to synchronize the files. Collision resolution classes allow you to specify several methods of resolution to try 470 . If you specify *AUTOSYNC for the collision resolution element of the file entry options. For more information. 471 .Support for customizing for each collision point and support the use of an exit program. see “Collision resolution” on page 345. These additional choices for resolving collisions allow customized solutions for resolving collisions without requiring user action. Escape LVE3E17 – This message indicates that no object matched the specified selection criteria. CMPFILA messages The following are the messages for CMPFILA. see the Using MIMIX book. Informational LVI3E06 – This message indicates that no object was selected to be processed. Diagnostic LVE3385 – This message indicates that differences were detected for an active file. a completion or escape message is issued. For more information about using the message log. The reason the file was not compared is included in the message. a diagnostic message is issued prior to the escape message. with a comparison level specification of *MBR: • • Completion LVI3E05 – This message indicates that all members compared successfully. Escape LVE3381 – This message indicates that compared files were different but active within the time span specified on the Maximum replication lag (MAXREPLAG) parameter. You can work with the message log from either MIMIX Availability Manager or the 5250 emulator. Diagnostic LVE3E12 – This message indicates that a file was not compared. In the event of an escape message. this message also includes those differences. specify the name of the command as the process type. All completion or escape messages are sent to the MIMIX message log.Completion and escape messages for comparison commands When the comparison commands finish processing. Escape LVE3E05 – This message indicates that files were compared with differences detected. Diagnostic LVE3E0D – This message indicates that a particular attribute compared differently. • • • • The following are the messages for CMPFILA. To find messages for comparison commands. The diagnostic message provides additional information regarding the error that occurred. Escape LVE3E09 – This message indicates that the CMPFILA command ended abnormally. If the cumulative differences include files that were different but active within the time span specified on the Maximum replication lag (MAXREPLAG) parameter. Diagnostic LVE3388 – This message indicates that differences were detected for 472 . with a comparison level specification of *FILE: • • • • • Completion LVI3E01 – This message indicates that all files were compared successfully. The LVE3E06 message includes the same message data as LVI3E02. • • • The LVI3E02 includes message data containing the number of objects compared. this message also includes those differences. Escape LVE3E07 – This message indicates that IFS objects were compared with differences detected. Informational LVI3E06 – This message indicates that no object was selected to be processed. If the cumulative differences include objects that were different but active within the time span specified on the Maximum replication lag (MAXREPLAG) parameter. Escape LVE3E17 – This message indicates that no object matched the specified selection criteria. and also includes the number of differences detected. • Escape LVE3E16 – This message indicates that members were compared with differences detected. Escape LVE3E06 – This message indicates that objects were compared and differences were detected. CMPOBJA messages The following are the messages for CMPOBJA: • • • Completion LVI3E02 – This message indicates that objects were compared but no differences were detected. If the cumulative differences include IFS objects that were different but active within the time span specified on the Maximum replication lag (MAXREPLAG) parameter. and the system 2 name. • 473 . Diagnostic LVE3E0F – This message indicates that a particular attribute was compared differently. If the cumulative differences include members that were different but active within the time span specified on the Maximum replication lag (MAXREPLAG) parameter. this message also includes those differences. CMPIFSA messages The following are the messages for CMPIFSA: • • • • Completion LVI3E03 – This message indicates that all IFS objects were compared successfully. Diagnostic LVE3386 – This message indicates that differences were detected for an active IFS object.Completion and escape messages for comparison commands an active member. this message also includes those differences. The reason the IFS object was not compared is included in the message. Diagnostic LVE3E14 – This message indicates that a IFS object was not compared. Escape LVE3380 – This message indicates that compared objects were different but active within the time span specified on the Maximum replication lag (MAXREPLAG) parameter. the system 1 name. Diagnostic LVE3384 – This message indicates that differences were detected for an active object. Escape LVE3E17 – This message indicates that no object matched the specified selection criteria. The reason the DLO was not compared is included in the message. • • • • CMPRCDCNT messages The following are the messages for CMPRCDCNT: • • • Escape LVE3D4D – This message indicates that ACTIVE(*YES) outfile processing failed and identifies the reason code. • • • CMPDLOA messages The following are the messages for CMPDLOA: • • • • • Completion LVI3E04 – This message indicates that all DLOs were compared successfully. Escape LVE3E17 – This message indicates that no object matched the specified selection criteria. Escape LVE3E08 – This message indicates that DLOs were compared and differences were detected. Diagnostic LVE3E11 – This message indicates that a particular attribute compared differently. Diagnostic LVE3E15 – This message indicates that a DLO was not compared. Informational LVI3E06 – This message indicates that no object was selected to be processed.• Escape LVE3382 – This message indicates that compared IFS objects were different but active within the time span specified on the Maximum replication lag (MAXREPLAG) parameter. If the cumulative differences include DLOs that were different but active within the time span specified on the Maximum replication lag (MAXREPLAG) parameter. Escape LVE3D5F – This message indicates that an apply session exceeded the 474 . Informational LVI3E06 – This message indicates that no object was selected to be processed. Escape LVE3D5A – This message indicates that system journal replication is not active. this message also includes those differences. Diagnostic LVE3387 – This message indicates that differences were detected for an active DLO. Escape LVE3383 – This message indicates that compared objects were different but active within the time span specified on the Maximum replication lag (MAXREPLAG) parameter. Escape LVE3E0C – This message indicates that the CMPDLOA command ended abnormally. Escape LVE3E0B – This message indicates that the CMPIFSA command ended abnormally. This message indicates the name of the local system is entered on the System 2 (SYS2) prompt. another job is holding an update lock on the record and the wait time has expired. Informational LVI306D – This message identifies a child process that completed successfully. In this case. Informational LVI3D45 – This message indicates that active processing completed. Escape LVE3D72 – This message identifies a child process that ended unexpectedly. Informational LVI3D6D – This message indicates that user journal replication is not active. Diagnostic LVE3031 . Diagnostic LVE3D46 – This message indicates that a file member contains one or • • • 475 . Diagnostic LVE3D42 . Informational LVI3E06 – This message indicates that no object was selected for processing. Informational LVI306B – This message identifies a child process that started successfully. Informational LVI3D5F – This message identifies an apply session that has exceeded the unprocessed entry threshold.Completion and escape messages for comparison commands unprocessed entry threshold. Informational LVI3D5A – This message indicates that system journal replication is not active.This message indicates that a selected member cannot be processed and provides a reason code. • • • • • • • • • • • • • Escape LVE3D6D – This message indicates that user journal replication is not active. No differences were detected. Escape LVE3D6F – This message identifies the number of members compared and how many compared members had differences. Using the name of the local system on the SYS2 prompt is not valid. CMPFILDTA messages The following are the messages for CMPFILDTA: • • Completion LVI3D59 – This message indicates that all members compared were identical or that one or more members differed but were then completely repaired. Escape LVE3E17 – This message indicates that no object was found for the specified selection criteria. Informational LVI3D50 – This message indicates that work files are not deleted. Informational LVI3E05 – This message identifies the number of members compared. Diagnostic LVE3D40 – This message indicates that a record in one of the members cannot be processed. such as large objects (LOBs). Escape LVE3D56 – This message indicates that no member was selected by the object selection criteria. however. Escape LVE3D60 – This message indicates that the status of the data group could not be determined. The message provides a statistical summary of the differences found. In this case. and LVE3D59 do not apply. Escape LVE3D5F – This message indicates that the apply session exceeded the specified threshold for unprocessed entries. Escape LVE3D59 – This message indicates that significant differences were found or remain after repair. Diagnostic LVE3D65 – This message indicates that processing failed for the selected member. LVE3D5D. and is shown only when the conditions of messages LVI3D59. thereby ending the requested compare and repair action. Escape LVE3D5E – This message indicates that the compare request ended because the data group was not fully active. Output may not be complete or accurate. one member has more records allocated. Escape LVE3358 – This message indicates that the compare has ended abnormally. The compare will stop processing the affected file and will continue to • • • • • • • • • • 476 . Excess allocated records are deleted. Insignificant differences may occur when a member has deleted records while the corresponding member has no records yet allocated at the corresponding positions.more field types that are not supported for comparison. The request included active processing (ACTIVE). Escape LVE3D62 – This message indicates the number of mismatches that will not be fully processed for a file due to the large number of mismatches found for this request. or that one or more selected members could not be compared. which requires a fully active data group. The DB apply threshold (DBAPYTHLD) parameter determines what action should be taken when the threshold is exceeded. the value *END was specified for DBAPYTHLD. Diagnostic LVE3D64 – This message indicates that the compare detected minor differences in a file member. It is also possible that one or more selected members contains excluded fields. The member cannot be compared. the request to process the file member is ignored. This difference does not affect replication processing. These fields are excluded from the data compared. In this case. Specify REPAIR(*NONE) to process the file member. Files containing LOB fields cannot be repaired. In this case. • Diagnostic LVE3D50 – This message indicates that a file member contains one or more large object (LOB) fields and a value other than *NONE was specified on the Repair on system (REPAIR) prompt. Escape LVE3D5D – This message indicates that insignificant differences were found or remain after repair. The message provides a statistical summary of the differences found. Error message LVE0101 is returned. The WRKDG (MXDGSTS) outfile returned a value of *UNKNOWN for one or more fields used in determining the overall status of the data group. type. Escape LVE3D69 – This message indicates that the data group is not configured for database. The member was previously being held due to error (*HLDERR) and is now in *CMPRLS state. • Escape LVE3D67 – This message indicates that the value specified for the File entry status (STATUS) parameter is not valid. Informational LVI372D – The CMPFILDTA command exceeded the maximum rule recovery time policy and is ending. Its output may be incomplete or incorrect. Escape LVE3E41 – This message indicates that a database apply job cannot process a journal entry with the indicated code. Informational LVI3729 – This message indicates that the repair request for a specific member was not successful. The command did not complete the requested compare or repair. The command did not complete the requested compare or repair. Data groups used with the CMPFILDTA command must be configured for database. Escape LVE3D6C – This message indicates that the CMPFILDTA command ended before it could complete the requested action. The member was previously being held due to error (*HLDERR) and has been changed from *CMPRLS to *CMPACT state. Its output may be incomplete or incorrect. As a result. Informational LVI3D59 – This message indicates that the CMPFILDTA command • • • • • • • • • • • • 477 . The message provides a statistical summary of the differences found. To process members in *HLDERR status. Its output may be incomplete or incorrect. The command did not complete the requested compare or repair. and sequence number because a supporting function failed. and all processes for that data group must be active. Escape LVE3D68 – This message indicates that a switch cannot be performed due to members undergoing compare and repair processing. The processing step in progress when the end was received is indicated. See the database apply job log for details of the failed function. the CMPFILDTA command has changed the data group file entry for the member back to *HLDERR status. Informational LVI372C – The CMPFILDTA command is ending controlled because of a user request. Informational LVI372E – The CMPFILDTA command is ending unexpectedly. It received an unexpected request from the remote CMPFILDTA job to shut down and is ending. The journal information and the apply session for the data group are indicated. a data group must be specified on the command and *YES must be specified for the Process while active parameter. Informational LVI3727 – This message indicates that the database apply process (DBAPY) is currently processing a repair request for a specific member. Informational LVI3728 – This message indicates that the database apply process (DBAPY) is currently processing a repair request for a specific member.Completion and escape messages for comparison commands process any other files specified on the same request. Informational LVI3D4B – This message indicates that work files are not automatically deleted because the time specified on the Wait time (seconds) (ACTWAIT) prompt expired or an internal error occurred. system managers. the number of members compared. Results of the comparison may not be complete or accurate. including information on the types of differences that are found and the number of differences found in each member. The CMPFILDTA outfile contains more detail on the results of each member compare. or when the active wait time out occurs. Messages LVI3D59. and database send and apply processes. 478 .This message indicates that the compare request ended because the request required Active processing and the data group was not active. LVE3D5D. journal managers. The message also provides a statistical summary of compare processing. the number of members successfully repaired. system communications. In this case. • • • When active processing and ACTWAIT(*NONE) is specified.completed successfully. thereby ending the requested compare and repair action. The MXDGSTS outfile returned a value of *UNKNOWN for one or more status fields associated with systems. the number of members with unconfirmed differences. some members will have unconfirmed differences if none of the differences initially found was verified by the MIMIX database apply process.This message indicates that the status of the data group could not be determined. the value *END was specified for the DB apply threshold (DBAPYTHLD) parameter. Informational LVI3D5F – This message indicates that the apply session exceeded the specified threshold for unprocessed entries. remote journal link. journals. • Informational LVI3D5E . LVE3D59. and the number of members for which repair was unsuccessful. the number of members with confirmed differences. which determines what action should be taken when the threshold is exceeded. and LVE3D6C include message data containing the number of members selected on each system. Informational LVI3D60 . Informational LVI3E06 – This message indicates that the data group specified contains no data group file entries. Messages generated on a network system will be automatically sent to the management system. To see the parameters for this command. messages generated on a management system may not be sent to any network systems. type the command and press F4 (Prompt). The message is also sent to the primary and secondary messages queues if the message meets the filter criteria for those queues. This is helpful when you want to include messages from your automation programs into the MIMIX message log for easier tracking. 479 . The message is written to the message log file. The message can also be sent to a program message queue. However. The system manager on the management system does not send messages to network systems when it cannot determine which system should receive the message.Adding messages to the MIMIX message log Adding messages to the MIMIX message log The Add Message Log Entry (ADDMSGLOGE) command allows you to add an entry to the MIMIX message log. Help text for the parameters describe the options available. including messages. such as Compare (CMP) and Verify (VFY). print. such as Compare (CMP) and Verify (VFY).Output and batch guidelines This topic provides guidelines for display. the selection is made on the Output parameter. providing MIMIX-related information in a manner that facilitates programming automation for various purposes—such as additional monitoring support. 480 . Audit-based commands. These guidelines address the user interface as well as the mechanics of submitting batch jobs that are not part of the mainline replication process. and file-related output. Output files are also beneficial as intermediate data for advance reporting using SQL query support. and the correction of error conditions. the mechanics of selecting and producing output. are often long-running requests and do not typically provide display support. print. there are some exceptions. also support various forms of output in many cases. automatic detection. Messages. print. on the other hand. most commands in the same class support the same output formats. and content issues such as formatting are described. and file output. In these cases. or for Work (WRK) related commands that display lists of entries. all Work (WRK) commands typically support display. General output considerations Commands can produce many forms of output. This section describes the general guidelines used throughout the product. or an outfile. a printer. In addition. are intended to provide diagnostic or status-related information. the user interface. Output files are intended primarily for automation purposes. Table 66 lists the values supported by the Output parameter. In some cases. The Work (WRK) and Display (DSP) commands are the most common classes of commands that support various forms of output. and file output. which are described in the sections about specific commands. Several commands support display. auditing support. However. print. Batch job submission guidelines are also provided. or an indication of error conditions. Spooled output support provides a more easily readable form of output for print or distribution purposes. Output is generated in the form of spooled output files that can easily be printed or distributed. the output information can be selectively directed to a display. Nearly all Display (DSP) or Work (WRK) commands support this form of output. output files. display output (interactive panels). or some combination thereof. In most cases. print. As part of an on-going effort to ensure consistent capabilities across similar classes of commands. Display support is intended primarily for Display (DSP) commands for displaying detailed information about a specific entry. Output parameter Some commands can produce output of more than one type—display. printer output (spooled files). other command-specific options may affect the contents of the spooled output file. Other classes of commands. Messages are not intended for general output. For example. or output file. and output formats. This section focuses primarily on display. Commands that support combinations of output values do not support OUTPUT(*) in combination with other output values. 481 . With the exception of messages generated as a result of running a command. Displaying a panel during batch processing or when called from another program would otherwise fail. the spooled output is generated as a result of specifying OUTPUT(*PRINT). Print output Spooled output is generated by specifying OUTPUT(*PRINT). Display (DSP) and Work (WRK) commands commonly use display support. Table 66. * *NONE *PRINT *OUTFILE *BOTH Values supported by the Output parameter Display only No output is generated Spooled output is generated An output file is generated Both spooled output and an output file are generated. Commands that support OUTPUT(*) that can also run in batch are required to support the other forms of output as well. commands that support OUTPUT(*NONE) will generate no other forms of output. Work commands often provide subsetting capabilities that allow you to select a subset of information. On commands that support spooled output. Display support is required to work interactively with the MIMIX product. subsetting allows you to view the configuration entries for a specific data group. Output is generated in the form of spooled output files that can easily be printed or distributed.Output and batch guidelines Note: Not all values are supported for all commands. For some commands. Display commands typically display detailed information for a specific entity. for example. Work commands display a list of entries and provide a summary view of list of entries. such as Compare (CMP) and Verify (VFY). Display output Commands that support OUTPUT(*) provide the ability to display information interactively. Rather than viewing all configuration entries for all data groups. Most Display (DSP) or Work (WRK) commands support this form of output. also support spooled output in most cases. and is intended to provide a readable form of output for print or distribution purposes. This ability allows you to easily view data that is important or relevant to you at a given time. Other commands. Commands called from a program or submitted to batch with a specification of OUTPUT(*) default to OUTPUT(*PRINT). such as a data group definition. a combination of values is supported. definition. Specifying DETAIL(*FULL) prints each data group definition in detail. A value of *SUMMARY reports a summary of objects compared. for example. The values available for this parameter vary. A list detail report is usually obtained by specifying *PRINT on the Output parameter of a Work (WRK) command. Specifying *DIF reports only detected differences. and Compare DLO Attributes (CMPDLOA) commands. including an indication of differences detected. The list summary report contains summary information for multiple objects. the detail option determines the level of detail in the generated spool file. or entries. *ALL provides a comprehensive listing of objects compared as well as difference detail. and *SUMMARY are available on the Compare File Attributes (CMPFILA). For example. A list summary is usually obtained by pressing F21 (Print) on a Work (WRK) display. You can also get this report by specifying *BASIC on the Detail parameter on a Work (WRK) command. A detail report is usually obtained by using option 6 (Print) on a Work (WRK) display. can affect the contents of spooled output. or entry.The Report Type (RPTTYPE) parameter controls the amount of information in the spooled file. the Work with Data Group IFS Entries (WRKDGIFSE). Configuration for objects. DETAIL(*FULL or *BASIC) . *ALL. Expand support provides a means to determine that actual objects on a system are represented by a MIMIX configuration. The object entry ABC*. which vary from command to command. such as an object. Compare IFS Attributes (CMPIFSA). Specifying *NO on the EXPAND parameter prints the configured data group entries. definitions. • RPTTYPE(*DIF. or entries.The expand parameter is available on the Work with Data Group Object Entries (WRKDGOBJE).Available on the Work (WRK) commands. this specification on the Work with Data Group Definitions (WRKDGDFN) command will print a summary list of data group definitions. and the Work with Data Group DLO Entries (WRKDGDLOE) commands. including all attributes of the data group definition. The list detail report contains detailed information for multiple objects. IFS objects. or by specifying *PRINT on the Output parameter on a Display (DSP) command. Compare Object Attributes (CMPOBJA). depending on command) . The values *DIF.The Work (WRK) and Display (DSP) commands support different categories of reports. which represent one or more actual objects on the system. Specifying DETAIL(*BASIC) prints a summary list of entries. can represent many entries on a system. Note: This parameter is ignored when OUTPUT(*) or OUTPUT(*OUTFILE) is specified. The following are standard categories of reports available from these commands: • The detail report contains information for one item. The following list represents a common set of parameters that directly impact spooled output: • EXPAND(*YES or *NO) . *SUMMARY or *RRN. • • Certain parameters. and DLOs can be accomplished using generic entries. definitions. depending on the command. *ALL. • 482 . File output Output files can be generated by specifying OUTPUT(*OUTFILE).Output and batch guidelines The Compare File Data (CMPFILDTA) command supports *DIF and *ALL values. As a result of running the command. The support also allows MIMIX customers and qualified MIMIX consultants to develop and deliver solutions tailored to the individual needs of the user. Note: If a new file is created for CMPFILA.000 objects that failed to compare. The Outmember (OUTMBR) parameter allows you to specify which member to use in the output file. Outfile support is a key enabler for advanced automation purposes. As with the other forms of output. Data group object entries. output files are commonly supported across certain classes of commands. if object name ABC* for library XYZ represented 1000 actual objects on the system. the default value of *FIRST will create a member name with the same name as the file name. If no member exists. Using EXPAND(*YES) will list all objects from the local system that match the configuration specified. found in the installation library. for example. EXPAND(*YES) would add 1000 rows to the output file. IFS entries. The Work (WRK) commands commonly support output files. In addition. The text description of the created file is “Output file for CMPFILA. you must also specify the OUTFILE and OUTMBR parameters. The OUTFILE parameter requires a qualified file and library name. also provide output file support. Thus. and DLO entries can all be configured using generic name values. Specifying *RRN allows you to output the relative record number of the first 1. such as Comparison (CMP) commands. Output file support for Work (WRK) commands provides access to the majority of MIMIX configuration and status-related data. A second element on the Outmember parameter indicates the way in which information is stored for an existing member. EXPAND(*NO) would add a single generic entry. it will automatically be created. A value of *REPLACE will clear the current contents of the member and add the new records. If the file does not exist. all objects in library XYZ are replicated. the record format used is from the supplied model database file MXCMPFILA.” The file cannot reside in the product library. the specified output file will be used. many audit-based reports. When you specify OUTPUT(*OUTFILE). If you specify an object entry with an object name of ABC* in library XYZ and accept the default values for all other fields. Having full outfile support across the MIMIX product is important for a number of reasons. A value of *ADD will append the new records to the existing data. Specifying EXPAND(*NO) will write the specific configuration entries to the output files. 483 . for example. Using the *RRN value can help resolve situations where a discrepancy is known to exist. *RRN provides the information that enables you to display the specific records on the two systems and to determine the system on which the file should be repaired. In this case. but you are unsure which system contains the correct data. The Compare (CMP) commands also provide output files as a key enabler for automatic error detection and correction capabilities. as well as the value *RRN. Expand support: The Expand support was developed specifically as a feature for data group configuration entries that support generic specifications. Note: EXPAND(*YES) support locates all objects on the local system. These jobs represent the various processes required to support an active data group. The default value varies from command to command. the default will likely be *YES. and MXDFT. Jobs and related output are associated to the user profile submitting the request. some jobs. A value of *YES indicates that the request will be submitted to batch. such as the data group apply process. Commands of this type do not specifically provide a batch (BATCH) parameter since it is the only method available. The job name parameter is intended to make it easier to identify the active job as well as the spooled files generated as a result of running the command. it is important to understand the difference between BATCH(*YES) and BATCH(*NO). Job name (JOB) parameter The Job name (JOB) parameter allows the user of the command to specify the job name used for the submitted job request. Some commands. the job name is also used for the user data information. A value of *NO will cause the request to run interactively. For commands that are called from other programs. which are automatically created in the MIMIX installation library when MIMIX is installed. If a command usually requires significant resource to run. Newer MIMIX commands use the job descriptions MXAUDIT. For spooled files.General batch considerations MIMIX functions that are identified as long-running processes typically allow you to submit the requests to batch and avoid the unnecessary use of interactive resources. Refer to individual commands for default values. Older commands that provided job description support for batch processing have not been altered. and is based on the general usage of the command. specifying BATCH(*NO) allows you to monitor for specific exceptions and implement automatic correction procedures. Batch (BATCH) parameter Values supported on the Batch (BATCH) parameter include *YES and *NO. the job name defaults to the name of the command. Let us assume you are running the Compare File Attributes (CMPFILA) command as part of an audit. Implementing automatic audit detection and correction support is easier to accomplish using BATCH(*NO). such as Start Data Group (STRDG). perform a number of interactive tasks and start numerous jobs by submitting the requests to batch. Likewise. run on a continuous basis and do not end until specifically requested. If differences are detected. By default. 484 . Job description (JOBD) parameter The Job Description (JOBD) parameter allows the user of the command to specify which job description to use when submitting the batch request. MXSYNC. This capability would not be available if you submitted the request to BATCH(*YES). Parameters typically associated with the Batch (BATCH) parameter include Job description (JOBD) and Job name (JOB). Only newer features provide this capability. Displaying a list of commands in a library Displaying a list of commands in a library You can use the IBM Select Command (SLTCMD) command to display a list of all commands contained within a particular library on the system. This list includes any commands you have added to the associated library. 3. select option 1 (Select all commands). Note: This list does not indicate whether you are licensed to the command or if authority to the command exists. 2. access the MIMIX Intermediate Main Menu. including copies of other commands. 485 . From the library you want. Select option 13 (Utilities menu) and press Enter. When the MIMIX Utilities Menu is displayed. Do the following: 1. Note: Do not change the RUNCMD or RUNCMDS commands to PUBLIC(*EXCLUDE) without giving MIMIXOWN proper authority. In addition. the RUNCMDS command has options for monitoring escape and completion messages. The value *DGJRN on the Protocol prompt enables this capability. does not allow command prompting. Additionally. The RUNCMD and RUNCMDS commands replace and extend the capabilities available in the IBM commands. the When to run (RUNOPT) prompt can be used to specify when the journal entry associated with the command is processed by the target system for the specified data group. only one communications session is established. including QTEMP and the local data area. 486 . The RUNCMD command also provides the ability to prompt on any command. thereby replacing conventional U-EX support. Benefits . Submit Remote Command (SBTRMTCMD) and Run Remote Command (RUNRMTCMD). The MIMIX commands provide a protocol-independent way of running commands using MIMIX constructs such as system definitions. the RUNCMD command can be used as a convenient tool to debug base communications problems. the RUNCMD and RUNCMDS commands use the current data group direction to determine where the command is to be run. data group definitions.Running commands on a remote system The Run Command (RUNCMD) and Run Commands (RUNCMDS) commands provide a convenient way to run a single command or multiple commands on a remote system. See “Procedures for running commands RUNCMD. Centralizes the management and control of networked systems. When multiple commands are run on a single RUNCMDS command. Enables protocol-independent testing and verification of MIMIX communications setups.RUNCMD and RUNCMDS commands Individually. and transfer definitions. RUNCMDS” on page 487 for additional details about the RUNOPT parameter. This protocol is a MIMIX request that the U-MX journal entry codes send through the journal stream. is also kept intact. The target program environment. The RUNCMDS command. The MIMIX commands enable you to run commands and receive messages from the remote system. enabling you to program remote commands in the same manner as local commands. This capability simplifies automation by eliminating the need to manually enter source and target information at the time a command is run. Both RUNCMD and RUNCMDS allow you to specify commands to be sent through the journal stream and run by the database apply process. All messages are sent to the same program level as the program or command line running the command. In addition. Benefits of the RUNCMD and RUNCMDS commands also include the following: • • • Provides a convenient and consistent interface to automate tasks across a network. while supporting up to 300 commands. specify *LOCAL. Specific protocols and specifications used for RUNCMD and RUNCMDS Specify At the Protocol prompt. Specify the protocol and protocol-specific implementation using Table 67. notify. you can specify up to 300 commands. To run multiple commands on a remote system. e. type a 1 next to RUNCMD. How to run (protocol) Run on local system 487 . If you are using the RUNCMDS command. To use the commands using an existing MIMIX configuration. You can use them with a specific protocol. Allows commands to be run under other user profiles as long as the user ID and password are the same on both systems. use the procedure “Running commands using a specific protocol” on page 487. 3. The Select Command display appears. or status messages to be monitored for each command. At the Command prompt specify the command to run on the remote system. or you can use them by specifying a protocol through existing MIMIX configuration elements. RUNCMDS • • Supports sending and receiving local data area (LDA) data. select option 13 (Utilities menu). Table 67. The Run Commands (RUNCMDS) display appears. Running commands using a specific protocol 1. 4. Procedures for running commands RUNCMD. select option 1 (Select all commands).Procedures for running commands RUNCMD. The Run Command (RUNCMD) display appears. When using the RUNCMDS command. thus the user must have authority to the user profile being used. Specify the commands to run or messages to monitor for the command as follows: d. type a 1 next to RUNCMDS. Page down and do one of the following: • • To run a single command on a remote system. From the MIMIX Utilities Menu. RUNCMDS There are two ways to use the RUNCMD or RUNCMDS commands. To use the commands with a specific protocol. Specify these at the Monitor for messages prompt. use the procedure “Running commands using a MIMIX configuration element” on page 489. you can specify as many as ten escape. The password is validated before the command is run on the remote system. 2. The MIMIX Utilities Menu appears. 5. From the MIMIX Main Menu. Do the following: 1. 5. specify the name or address of the remote location. At the Check syntax prompt. 3. Specific protocols and specifications used for RUNCMD and RUNCMDS Specify Do the following: 1. Do the following: 1.Table 67. 2. specify the name of the mode description used for communications. If *YES is specified. the syntax is checked but the command is not run. 4. specify the host alias or address of the TCP protocol. specify whether to check the syntax of the command only. Press F10 (Additional parameters). 488 . specify whether to return the contents of the local data area (LDA) from the remote system after the commands are run. At the Remote network identifier prompt. specify the amount of the current local data area (LDA) to copy. 9. The product default for this parameter is MIMIX. The value specified in the Local data area length prompt in Step 9 determines how much data is returned. specify the unique location name that identifies the system to remote devices. Press Enter for additional prompts. This value is a 14-character mixed-case TCP port alias or port number. At the Return LDA prompt. 2. specify the port number or port alias on the local system to communicate with the remote system. 8. specify *SNA to run the commands using System Network Architecture (SNA) communications. 10. At the Mode prompt. press Enter. specify the name or address of the remote location. At the Protocol prompt. 2. This is useful for automating application processing that is dependent on the local data area and for passing binary information to command programs. At the Remote location prompt. At the Port number or alias prompt. At the Remote location prompt. At the Local location prompt. At the Host name or address prompt. 3. skip to Step 7. To run the commands or monitor for messages. specify *TCP to run the commands using Transmission Control Protocol/Internet Protocol (TCP/IP) communications. Do one of the following: • • To access additional options. At the Protocol prompt. Press Enter for additional prompts. At the Local data area length prompt. 7. At the Protocol prompt. specify the name or address of the remote location. Press Enter for additional prompts. How to run (protocol) Run using TCP/IP Run using SNA Run using OptiConnect 6. specify *OPTI to run the commands using OptiConnect fiber optic network communications. press Enter. 12. b. If you are using the RUNCMDS command. Page down and do one of the following: • • To run a single command on a remote system. To run the commands or monitor for messages. select option 13 (Utilities menu). specify the user profile to use when the command is run on the remote system. 5. 2. you can specify up to 300 commands. At the User prompt. Running commands using a MIMIX configuration element To use RUNCMD or RUNCMDS using a MIMIX configuration element. At the Command prompt specify the command to run on the remote system. RUNCMDS 11. To run multiple commands on a remote system. 4. MIMIX configuration protocols and specifications Protocol prompt value *SYSDFN Also specify Protocol using MIMIX configuration element Run on system defined by the default transfer definition System definition prompt: • Specify the name of the system definition or press F4 for a list of valid definitions. Specify the MIMIX configuration element using Table 68. Specify these at the Monitor for messages prompt. The Select Command display appears. select option 1 (Select all commands). From the MIMIX Main Menu. Table 68. 3.Procedures for running commands RUNCMD. do the following: 1. The MIMIX Utilities Menu appears. When using the RUNCMDS command. Specify the commands to run or messages to monitor for the command as follows: a. type a 1 next to RUNCMDS. or status messages to be monitored for each command. The Run Commands (RUNCMDS) display appears. The Run Command (RUNCMD) display appears. Press Enter for additional prompts • 489 . you can specify as many as ten escape. From the MIMIX Utilities Menu. type a 1 next to RUNCMD. notify. Run on the current target system defined for the data group *DGTGT Data group definition prompt: • Press F1 Help for assistance in specifying the three-part qualified name of the data group definition. Press Enter for additional prompts. Run on the system defined as System 1 for the data group *DGSYS1 Data group definition prompt: • Press F1 Help for assistance in specifying the three-part qualified name of the data group definition. MIMIX configuration protocols and specifications Protocol prompt value *TFRDFN Also specify Protocol using MIMIX configuration element Run on the system specified in the transfer definition (TFRDFN parameter) that is not the local system Transfer definition prompt: • Press F1 Help for assistance in specifying the three-part qualified name of the transfer definition. Run on the current source system defined for the data group *DGSRC Data group definition prompt: • Press F1 Help for assistance in specifying the three-part qualified name of the data group definition.Table 68. • Run on the system specified in the data group definition that is not the local system *DGDFN Data group definition prompt: • Press F1 Help for assistance in specifying the three-part qualified name of the data group definition. Run by the database apply process when the journal entry is processed *DGJRN Data group definition prompt: • Press F1 Help for assistance in specifying the three-part qualified name of the data group definition. 490 . If a file is not specified. press Enter. At the Check syntax only prompt. RUNCMDS Table 68. 7. database apply (DBAPY) session A is selected. 8. b. you will see the When to run prompt. At the File name prompt. 491 . At the Local data area length prompt. Note: Use these prompts if you want the command to run in the database apply job associated with the named file. you will see the File prompts. Do one of the following: • • To access additional options. specify the name of the file to use when the journal entry generated by the commands is sent. Do the following: a. specify the user profile to use when the command is run on the remote system. specify whether to return the contents of the local data area (LDA) from the remote system after the commands are run. specify whether to check the syntax of the command only. This is useful for automating application processing that is dependent on the local data area and for passing binary information to command programs. 14. 6. skip to Step 7. At the Return LDA prompt. 9. 11. 12. To run the commands or monitor for messages. specify when the journal entry associated with the command is processed by the target system for the specified data group. The value specified in the Local data area length prompt in Step 9 determines how much data is returned. specify the amount of the current local data area (LDA) to copy. MIMIX configuration protocols and specifications Protocol prompt value *DGSYS2 Also specify Protocol using MIMIX configuration element Run on the system defined as System 2 for the data group Data group definition prompt: • Press F1 Help for assistance in specifying the three-part qualified name of the data group definition. specify the name of the library associated with the file. Press F10 (Additional parameters). To run the commands or monitor for messages. the syntax is checked but the command is not run. press Enter. At the Library prompt.Procedures for running commands RUNCMD. 13. If you specified a file name for the File prompt. If you specified *DGJRN for the Protocol prompt. Using Table 69. If *YES is specified. 10. At the User prompt. specify *RCV. 2. At the When to run prompt. At the When to run prompt. specify *DGJRN. At the Protocol prompt. specify *DGJRN. Do the following: 1. 2.Table 69. Options for processing journal entries with MIMIX *DGJRN protocol Specify Do the following: 1. 492 . At the Protocol prompt. When to run (Runopt) Run when the database apply job for the specified file receives the journal entry Run in sequence with all other entries for the file. specify *APY. and a data group definition. Outfile support provides the means to generate a list of entries. You specify the list identifier to close. The CL variable for the list identifier is needed for the MIMIX retrieve commands. You are now encouraged to use the extensive outfile support now available. a CL variable to receive the list identifier. Close MIMIX List (CLOMMXLST) This command allows you to close a list of specified MIMIX definitions or data group entries opened by the Open MIMIX List (OPNMMXLST) command. they will not be enhanced. For more information. • 493 . You specify the type of definitions or data group entries to include in the list. see “Output and batch guidelines” on page 480. • Open MIMIX List (OPNMMXLST) This command allows you to open a list of specified MIMIX definitions or data group entries for use with the MIMIX retrieve commands. A close is necessary in order to free resources. The retrieve commands are primarily intended to handle retrieving information for a specific entry only.Using lists of retrieve commands Using lists of retrieve commands The following additional commands make working with retrieve commands easier: Note: Although the current retrieve commands will be supported indefinitely. 494 . Also. use the IBM Change Command Default (CHGCMDDFT) command. Be aware that by changing a command default. you may be affecting the operation of other MIMIX processes.Changing command defaults Nearly all MIMIX processes are based on commands that have been shipped with default values that reflect best practices recommendations. each update of MIMIX software will cause any changes to be lost. This ensures the easiest and best use of each command. If you wish to customize command defaults to fit a specific business need. MIMIX implements named configuration definitions through which you can customize your configuration by using options on commands without resorting to changing command defaults. This generic user exit capability is only available through a Certified MIMIX Consultant. Monitors can be set up to operate with other products. You can also use the MIMIX Monitor User Access API (MMUSRACCS) for all interfaces to MIMIX Monitor. The topics in this chapter include: • • “Summary of exit points” on page 495 provides tables that summarize the exit points available for use. MIMIX Monitor user exit points Table 71 identifies the user exit points available in MIMIX Monitor. MIMIX Monitor also contains the MIMIX Model Switch Framework. Type Journal receiver management exit points MIMIX exit points for journal receiver management Exit Point Name Receiver change management pre-change Receiver change management post-change Receiver delete management pre-check Receiver delete management pre-delete Receiver delete management post-delete MIMIX also supports a generic interface to existing database and object replication process exit points that provides enhanced filtering capability on the source system. including MIMIX.Summary of exit points CHAPTER 22 Customizing with exit point programs The MIMIX family of products provide a variety of exit points to enable you to extend and customize your operations. Summary of exit points The following tables summarize the exit points available for use. Table 70. This support provides powerful customization opportunities through a set of programs and 495 . “Working with journal receiver management user exit points” on page 498 describes how to use user exit points safely. You can use the exit points through programs controlled by a monitor. For additional information. for journal receiver management. see “Working with journal receiver management user exit points” on page 498. MIMIX user exit points MIMIX provides the exit points identified in Table 70. If you perform concurrent operations between MIMIX Promoter and MIMIX. and MIMIX Model Switch Framework. Table 72. the API.) 496 .) MIMIX Promoter exit points Exit Point Name Transfer complete Lock failure After lock Copy failure Copy finalize After temporary journal delete Data initialize Data transfer Data finalize Data exit points (The data exit service program supports these exit points. Type Interface exit points MIMIX Monitor exit points Exit Point Name Pre-create Post-create Pre-change Post-change Pre-copy Post-copy Pre-delete Post-delete Pre-display Post-display Pre-print Post-print Pre-rename Post-rename Pre-start Post-start Pre-end Post-end Pre-work with information Post-work with information Pre-hold Post-hold Pre-release Post-release Pre-status Post-status Pre-change status Post-change status Pre-run Post-run Pre-export Post-export Pre-import Post-import Condition program exit point Event program exit point After pre-defined condition check After condition check (pre-defined and user-defined) MIMIX Promoter user exit points Table 72 identifies the exit points within MIMIX Promoter. Type Control exit points (The control exit service program supports these exit points. The Using MIMIX Monitor book documents the user exit points.Customizing with exit point programs commands that are designed to provide a consistent switch framework for you to use in your switching environment. you might consider using these exit points within automation. Table 71. contact us at mimixsupport@visionsolutions. 497 .com/support.visionsolutions. Our personnel will ask about your requirements and design a customized program to work with your applications.com or through the online tools at www.Summary of exit points Requesting customized user exit programs If you need a specialized user exit program designed for your applications. Access to user exit processing is provided through the use of an exit program that can be written in any language supported by IBM i. MIMIX ignores the return code from the exit program. MIMIX also changes the journal receiver at other times. such as during a switch and when a user requests a change with the Change Data Group Receiver (CHGDGRCV) command. a user exit program that inadvertently causes an entry to be discarded that is needed by MIMIX could result in a file not being available in case of a switch. and testing. programming. Since user exit programming allows for user code to be run within MIMIX processes. (The example program in Table 73 on page 502 shows how you can determine the name of the previously attached journal by retrieving • 498 . The following user exit points are available for customizing change management processing: • Receiver Change Management Pre-Change User Exit Point. The return code from the exit program can prevent MIMIX from changing the journal receiver. when the receiver reaches a specified size. You can safely use user exit processing with proper design. Receiver Change Management Post-Change User Exit Point. such as saving the journal receiver to media. Change management exit points MIMIX can change journal receivers when a specified time is reached. you can customize change management and delete management of journal receivers according to the needs of your environment Journal receiver management exit points are enabled when you specify a exit program to use in a journal definition. This exit point is located immediately before the point in processing where MIMIX changes a journal receiver. which can be useful when the exit program changes the receiver. Services are also available to help customers implement specialized solutions. For example. You specify these values when you create a journal definition. Use caution in designing a configuration for use with user exit programming. With this support.Working with journal receiver management user exit points User exit points in critical processing areas enable you to incorporate specialized processing with MIMIX to extend function to meet additional needs for your environment. Either the user forced a journal receiver change (CHGDGRCV command) or MIMIX processing determined that the journal receiver needs to change. This exit point is located immediately after the point in processing where MIMIX changes a journal receiver. This exit point is useful for processing that does not affect MIMIX processing. or when the sequence number reaches a specified threshold. great care must be exercised to prevent the user code from interfering with the proper operation of MIMIX. Journal receiver management exit points MIMIX includes support that allows user exit programming in the journal receiver change management and journal receiver delete management processes. • • Requirements for journal receiver management exit programs This exit program allows you to include specialized processing in your MIMIX environment at points that handle journal receiver management. Receiver Delete Management Post-Delete User Exit Point. The return code from the exit program can prevent MIMIX from deleting the journal receiver and any other journal receiver in the chain. The return code from the exit program can prevent MIMIX from deleting the journal receiver. When called at this exit point. The exit program runs with the authority of the user profile that owns the exit program.) Restrictions for Change Management Exit Points: The following restriction applies when the exit program is called from either of the change management exit points: • • Do not include the Change Data Group Receiver (CHGDGRCV) command in your exit program. and how many days to retain the receivers. By not submitting journal receiver change management to a batch job. thereby conflicting with journal manager operations. This exit point is located immediately before the point in processing where MIMIX deletes a journal receiver. the number of receivers that must be retained. The following user exit points are available for customizing delete management processing: • Receiver Delete Management Pre-Check User Exit Point. The return code from the exit program can prevent MIMIX from deleting any other (newer) journal receivers attached to the journal. Do not submit batch jobs for journal receiver change or delete management from the exit program. This exit point is immediately after the point in processing where MIMIX deletes a journal receiver. For example. This exit point is located before MIMIX determines whether to delete a journal receiver. When you create a journal definition you specify whether unsaved journal receivers can be deleted. which is useful when the receiver is being used by another application. MIMIX processing determined that the journal receiver is eligible for deletion. an exit program that saves the journal receiver may make the journal receiver eligible for deletion by MIMIX processing. actions specified in a user exit program can affect conditions that MIMIX processing checks before the pre-delete exit point. Submitting a batch job would allow the in-line exit point processing to continue and potentially return to normal MIMIX journal management processing. If your exit 499 . you prevent a potential problem where the journal receiver is locked when it is accessed by a batch program. Delete management exit points MIMIX can delete journal receivers when the send process has completed processing the journal receiver and other configurable conditions are met.Working with journal receiver management user exit points the name of the first entry in the currently attached journal receiver. Receiver Delete Management Pre-Delete User Exit Point. Continue with MIMIX journal management processing. CHAR (10) The name of the journal that MIMIX is processing. When the exit program is called. 500 . System INPUT. Function INPUT.program fails and signals an exception to MIMIX. Consider placing long running processes that will not affect journal management in a batch job that is called by the exit program. CHAR (8) The name of the system defined to MIMIX on which the journal is defined. This parameter must be set. Attention: It is possible to cause long delays in MIMIX processing that are undesirable when you use this exit program. CHAR (2) The exit point from which this exit program is called. Journal Definition INPUT. Possible values are: 0 1 Do not continue with MIMIX journal management processing for this journal receiver. MIMIX passes control to the exit program. CHAR (10) The name that identifies the journal definition. Pre-change exit point for receiver delete management. MIMIX will not continue change management or delete management processing until the exit program returns. Note: Restrictions for exit programs called from the C1 and C2 exit points are described within topic “Change management exit points” on page 498. CHAR (1) This value indicates how to continue processing the journal receiver when the exit program returns control to the MIMIX process. MIMIX processing continues as if the exit program was not specified. Pre-check exit point for receiver delete management. the value of the return code is ignored. Reserved1 INPUT. When the exit program is called from Function C2. Post-change exit point for receiver change management. Post-change exit point for receiver delete management. Possible values are: C1 C2 D0 D1 D2 Pre-change exit point for receiver change management. CHAR (10) This field is reserved and contains blank characters. Journal Name INPUT. Return Code OUTPUT. Possible values are: *CONT The journal sequence number of the next journal entry created is 1 greater than the sequence number of the last journal entry in the currently attached journal receiver. The exit program must not change the threshold size for the journal receiver. CHAR (10) The name of the journal receiver associated with the specified journal. For receiver change management functions. Possible values are: 0 value Do not change the threshold value. *RESET Threshold Value INPUT. Receiver Name INPUT. The exit program must create a journal receiver with this threshold value. this always refers to the currently attached journal receiver. The exit program should either reset the sequence number or set the return code to 0 to allow MIMIX to change the journal receiver and reset the sequence number. CHAR (10) The library in which the journal receiver is located. specified in kilobytes. This is the journal receiver on which journal management functions will operate.Working with journal receiver management user exit points Journal Library INPUT. Receiver Library INPUT. this always refers to the same journal receiver. Sequence Option INPUT. 501 . CHAR (1) This field is reserved and contains blank characters. DECIMAL(15. 5) The value to use for the THRESHOLD parameter on the CRTJRNRCV command. This parameter is only used when the exit program is called at the C1 (pre-change) exit point. The journal sequence number of the first journal entry in the newly attached journal receiver is reset to 1. CHAR (6) The value of the Sequence option (SEQOPT) parameter on the CHGJRN command that MIMIX processing would have used to change the journal receiver. For receiver delete management functions. CHAR (10) The name of the library in which the journal is located. or send a return code value of 0 so that MIMIX processing can change the journal receiver. This parameter is only used when the exit program is called at the C1 (pre-change) exit point. The exit program must also change the journal to use that receiver. It is recommended that you specify this parameter to prevent synchronization problems if you change the journal receiver. Reserved2 INPUT. . the post-change exit point (C2). if the journal library is TEAMLIB. Sample journal receiver management exit program /*--------------------------------------------------------------*/ /* Program.. Journal receiver management exit program example The following example shows how an exit program can customize changing and deleting journal receivers. the exit program saves the recently detached journal receiver if the journal is in library ABCLIB..Reserved3 INPUT. When called at the post-change exit point.) When called at the pre-check exit point. or the precheck exit point (D0). (The recently detached journal receiver was the attached receiver at the pre-change exit point. Table 73. For any other journal library.: DMJREXIT */ /* Description: Example user exit program using CL */ /*--------------------------------------------------------------*/ PGM PARM(&RETURN &FUNCTION &JRNDEF &SYSTEM + &RESERVED1 &JRNNAME &JRNLIB &RCVNAME + &RCVLIB &SEQOPT &THRESHOLD &RESERVED2 + &RESERVED3) VAR(&RETURN) VAR(&FUNCTION) VAR(&JRNDEF) VAR(&SYSTEM) VAR(&RESERVED1) VAR(&JRNNAME) VAR(&JRNLIB) VAR(&RCVNAME) VAR(&RCVLIB) VAR(&SEQOPT) VAR(&THRESHOLD) VAR(&RESERVED2) VAR(&RESERVED3) TYPE(*CHAR) LEN(1) TYPE(*CHAR) LEN(2) TYPE(*CHAR) LEN(10) TYPE(*CHAR) LEN(8) TYPE(*CHAR) LEN(10) TYPE(*CHAR) LEN(10) TYPE(*CHAR) LEN(10) TYPE(*CHAR) LEN(10) TYPE(*CHAR) LEN(10) TYPE(*CHAR) LEN(6) TYPE(*DEC) LEN(15 5) TYPE(*CHAR) LEN(1) TYPE(*CHAR) LEN(1) DCL DCL DCL DCL DCL DCL DCL DCL DCL DCL DCL DCL DCL 502 . CHAR (1) This field is reserved and contains blank characters. the exit program saves the journal receiver to tape and allows MIMIX receiver delete management to continue processing. This exit program only processes journal receivers when it is called at the pre-change exit point (C1). When called at the pre-change exit point. MIMIX handles change management processing. the sample exit program handles changing any journal receiver in library MYLIB. exit program */ /* will do the changing of the receivers. Sample journal receiver management exit program /*--------------------------------------------------------------*/ /* Constants and misc.Working with journal receiver management user exit points Table 73. */ /*--------------------------------------------------------------*/ IF (&JRNLIB *EQ 'MYLIB') THEN(DO) IF (&THRESHOLD *GT 0) THEN(DO) CRTJRNRCV JRNRCV(&RCVLIB/NEWRCV0000) + THRESHOLD(&THRESHOLD) CHGJRN JRN(&JRNLIB/&JRNNAME) + JRNRCV(&RCVLIB/NEWRCV0000) SEQOPT(&SEQOPT) ENDDO /* There has been a threshold change */ ELSE (CHGJRN JRN(&JRNLIB/&JRNNAME) JRNRCV(*GEN) + SEQOPT(&SEQOPT)) /* No threshold change */ CHGVAR &RETURN &STOP /* Stop processing entry */ ENDDO /* &JRNLIB is MYLIB */ ENDDO /* &FUNCTION *EQ &PRECHG */ /*--------------------------------------------------------------*/ /* At the post-change user exit point if the journal library is */ /* ABCLIB. */ /*--------------------------------------------------------------*/ IF (&FUNCTION *EQ &PRECHG) THEN(DO) /*--------------------------------------------------------------*/ /* If the journal library is my library(MYLIB). variables */ /*--------------------------------------------------------------*/ DCL VAR(&STOP) TYPE(*CHAR) LEN(1) VALUE('0') DCL VAR(&CONTINUE) TYPE(*CHAR) LEN(1) VALUE('1') DCL VAR(&PRECHG) TYPE(*CHAR) LEN(2) VALUE('C1') DCL VAR(&POSTCHG) TYPE(*CHAR) LEN(2) VALUE('C2') DCL VAR(&PRECHK) TYPE(*CHAR) LEN(2) VALUE('D0') DCL VAR(&PREDLT) TYPE(*CHAR) LEN(2) VALUE('D1') DCL VAR(&POSTDLT) TYPE(*CHAR) LEN(2) VALUE('D2') DCL VAR(&RTNJRNE) TYPE(*CHAR) LEN(165) DCL VAR(&PRVRCV) TYPE(*CHAR) LEN(10) DCL VAR(&PRVRLIB) TYPE(*CHAR) LEN(10) /*--------------------------------------------------------------*/ /* MAIN */ /*--------------------------------------------------------------*/ CHGVAR &RETURN &CONTINUE /* Continue processing receiver*/ /*--------------------------------------------------------------*/ /* Handle processing for the pre-change exit point. */ /*--------------------------------------------------------------*/ ELSE IF (&FUNCTION *EQ &POSTCHG) THEN(DO) IF COND(&JRNLIB *EQ 'ABCLIB') THEN(DO) RTVJRNE JRN(&JRNLIB/&JRNNAME) + RCVRNG(&RCVLIB/&RCVNAME) FROMENTLRG(*FIRST) + RTNJRNE(&RTNJRNE) 503 . save the just detached journal receiver. Table 73. */ /*--------------------------------------------------------------*/ ELSE IF (&FUNCTION *EQ &PRECHK) THEN(DO) IF (&JRNLIB *EQ 'TEAMLIB') THEN( + SAVOBJ OBJ(&RCVNAME) LIB(&RCVLIB) DEV(TAP01) + OBJTYPE(*JRNRCV)) ENDDO /* &FUNCTION is &PRECHK */ ENDPGM 504 . Sample journal receiver management exit program /*----------------------------------------------------------*/ /* Retrieve the journal entry. */ /*----------------------------------------------------------*/ CHGVAR &PRVRCV (%SUBSTRING(&RTNJRNE 126 10)) CHGVAR &PRVRLIB (%SUBSTRING(&RTNJRNE 136 10)) SAVOBJ OBJ(&PRVRCV) LIB(&PRVRLIB) DEV(TAP02) + OBJTYPE(*JRNRCV) /* Save detached receiver */ ENDDO /* &JRNLIB is ABCLIB */ ENDDO /* &FUNCTION is &POSTCHG */ /*--------------------------------------------------------------*/ /* Handle processing for the pre-check exit point. extract the previous receiver*/ /* name and library to do the save with. Object Type *ALRTBL *AUTL *BLKSF *BNDDIR *CFGL *CHTFMT *CLD *CLS *CMD *CNNL *COSD *CRG *CRQD *CSI *CTLD *DDIR *DEVD *DEVNWSH *DIR *DOC *DSTMF *DTAARA *DTADCT *DTAQ *EDTD *EXITRG *FCT *FILE *FLR *FNTRSC *FNTTBL *FORMDF *FTR *GSS *IGCDCT *IGCSRT *IGCTBL *IPXD *JOBD Description Alert table Authorization list Block special file Binding directory Configuration list Chart format C locale description Class Command Connection list Class-of-service description Cluster resource group Change request description Communications side information Controller description Distributed file directory Device description Device network server host adapter Directory Document Distributed stream file Data area Data dictionary Data queue Edit description Exit registration Forms control table File Folder Font resource Font mapping table Form definition Filter Graphics symbol set Double-byte character set conversion dictionary Double-byte character set sort table Double-byte character set font table Internetwork packet exchange description Job description Replicated Yes Yes No Yes No6 No9 Yes Yes Yes Yes Yes No9 Yes Yes Yes1 No2 Yes1. Note: Not all object types exist in all releases of IBM i.13 Yes Yes2 Yes No2 Yes No Yes Yes Yes Yes Yes3. 11 Yes Yes No9 Yes Yes Yes No9 No9 No9 Yes Yes 505 .Supported object types for system journal replication APPENDIX A This list identifies IBM i object types and indicates whether MIMIX can replicate these through the system journal. Supported object types for system journal replication Object Type *JOBQ *JOBSCD *JRN *JRNRCV *LIB *LIND *LOCALE *M36 *M36CFG *MEDDFN *MENU *MGTCOL *MODD *MODULE *MSGF *MSGQ *NODGRP *NODL *NTBD *NWID *NWSD *OOPOOL *OUTQ *OVL *PAGDFN *PAGSEG *PDG *PGM *PNLGRP *PRDAVL *PRDDFN *PRDLOD *PSFCFG *QMFORM *QMQRY *QRYDFN *RCT *S36 *SBSD *SCHIDX *SOCKET *SOMOBJ *SPADCT *SPLF *SQLPKG *SQLUDT *SRVPGM *SSND *STMF *SVRSTG *SYMLNK Description Job queue Job schedule Journal Journal receiver Library Line description Locale space AS/400 Advanced 36 machine AS/400 Advanced 36 machine configuration Media definition Menu Management collection Mode description Module Message file Message queue Node group Node list NetBIOS description Network interface description Network server description Persistent pool (for OO objects) Output queue Overlay Page definition Page segment Print descriptor group Program Panel group Product availability Product definition Product load Print Services Facility (PSF) configuration Query management form Query management query Query definition Reference code translate table System/36 machine description Subsystem description Search index Local socket System Object Model (SOM) object Spelling aid dictionary Spool file Structured query language package User-defined SQL type Service program Session description Bytestream file Server storage space Symbolic link Replicated Yes4 Yes No7 No7 Yes4 Yes1 Yes No8 No8 Yes Yes Yes Yes Yes Yes Yes4 No9 Yes Yes Yes1 Yes No Yes4. 5 Yes Yes Yes Yes Yes12 Yes No6 No6 No6 Yes Yes Yes Yes No9 No9 Yes Yes No No Yes Yes Yes Yes Yes Yes Yes2 No8 Yes2 506 . QNTC. These objects are system specific. Replicating configuration objects to a previous version of IBM i may cause unpredictable results.The SQL field type of DATALINK is not supported. LF38. 507 . Contact CustomerCare if you need support for these object types. MLB. QSR. BSC. CRP. and SAVF. Files containing these types of fields must be excluded from replication. NET. DSPRMT. 3. DSPF38. RTL. should not be replicated. PF38-SRC. 8. SNPTDN. Spooled files are replicated separately from the output queue. Content is not replicated. as well as IBM supplied user profiles. 5. DSPF36. PRTF.Object Type Description Replicated *TBL Table Yes *USRIDX User index Yes *USRPRF User profile Yes14 *USRQ User queue Yes4 *USRSPC User space Yes10 *VLDL Validation list Yes *WSCST Workstation customizing object Yes Notes: 1. Duplicating these objects can potentially cause problems on the target system. FNC. OPT. and TAP.400. 4. PRTRMT. ASP. 2. QLANSrv. PF-SRC. PF-DTA. Objects in QDLS. INTR. PF38-DTA. 14.LIB. 11. DKT. PRTLAN. 6. File attribute types include: DDMF. SNPTUP. and QFPNWSSTG file systems are not currently supported via Data Group IFS Entries. PRTLCL. DSPVRT. ASC. ICFF. These object types can be supported by MIMIX for replication through the system journal. SNUF. DSPLCL. Duplicating them could cause unpredictable results on the target system.Changes made though external interfaces such as APIs and commands are replicated. DSPF. Objects in QSYS. These objects are not duplicated due to size and IBM recommendation. HOST. PRTVRT.To replicate *PGM objects to an earlier release of IBM i you must be able to save them to that earlier release of IBM i. 13. 10.Device description attributes include: APPC.LIB and QDLS are supported via Data Group Object Entries and Data Group DLO Entries. PRTF38. Excludes stream files associated with a server storage space. but are not currently included. LF. QFileSvr. Direct update of the content through a pointer is not supported. MXDF38. QNetWare. 7. QSYS. 12. 9.The MIMIX-supplied user profiles MIMIXOWN and LAKEVIEW. QOPT. Supported scenarios The Copy Configuration Data (CPYCFGDTA) command supports copying configuration data from one library to another library on the same system. you can use the CPYCFGDTA command.Copying configurations APPENDIX B Copying configurations This section provides information about how you can copy configuration data between systems. After MIMIX is installed. • • • “Supported scenarios” on page 508 identifies the scenarios supported in version 6 of MIMIX. 508 . “Checklist: copy configuration” on page 509 directs you through the correct order of steps for copying a configuration and completing the configuration. From MIMIX version 6 MIMIX version 5 1. The supported scenarios are as follows: Table 74. Supported scenarios for copying configuration To MIMIX version 61 MIMIX version 6 The installation you are copying to must be at the same or a higher level service pack. “Copying configuration procedure” on page 513 documents how to use the Copy Configuration Data (CPYCFGDTA) command. you will need to modify the journal definition using topic “Changing a journal definition” on page 194. 2. For *TCP. 3. transfer. To configure MIMIX with configuration information copied from one or more existing product libraries. and job descriptions required. Verify that the system definitions created by the CPYCFGDTA command have the correct message queue. DGDFN parameter • System definition. verify the port number. the default journal receiver prefix is AUDRCV. If you change the names of any of the system. Table 75. Be sure to check system definitions for the management system and all of the network systems. for the system journal. Verify that transfer definitions created have the correct three-part name and that the values specified for each transfer protocol are correct. If you want to use a prefix other than these defaults. 4. and journal receiver change management and delete management. 5. SYSDFN parameter Transfer definition. TFRDFN parameter Journal definition. PRITFRDFN and SECTFRDFN parameters • Data group definition.Checklist: copy configuration Checklist: copy configuration Use this checklist when you have installed MIMIX in a new library and you want to copy an existing configuration into the new library. do the following: 1. or journal definitions created by the copy configuration command. output queues. Use the procedure “Copying configuration procedure” on page 513 to copy the configuration information from one or more existing libraries. Changing named definitions after copying a configuration Also change the name in this location • Transfer definition. PRITFRDFN and SECTFRDFN parameters Data group definition. The default journal receiver prefix for the user journal is generated. verify that the SNA mode is what is defined for SNA configuration. 6. JRNDFN1 and JRNDFN2 parameters If you change this name System definition. Note: One of the transfer definitions should be named PRIMARY if you intend to create additional data group definitions or system definitions that will use the default value PRIMARY for the Primary transfer definition PRITFRDFN parameter. TFRDFN parameter • Data group definition. Verify that the journal definitions created have the information you want for the journal receiver prefix name. auxiliary storage pool. Review “Supported scenarios” on page 508. ensure that you also update that name in other locations within the configuration. JRNDFN parameter 509 . For *SNA. Do the following: 1. load object tracking entries for *DTAARA and *DTAQ objects that are journaled to a user journal. Class Librarybased objects How to configure data group entries for the preferred configuration. a. For example. For data group definitions. Use “Loading object tracking entries” on page 258. Verify the data group definitions created have the correct job descriptions. Verify that the options which control data group file entries are set appropriately. Any file entry options (FEOPT) specified in a data group file entry will override the default FEOPT values specified in the data group definition. 9. load file entries for LF and PF (source and data) *FILE objects using “Loading file entries from a data group’s object entries” on page 247. Table 76. Planning and Requirements Information “Identifying library-based objects for replication” on page 91 “Identifying logical and physical files for replication” on page 96 “Identifying data areas and data queues for replication” on page 103 3. Verify that the values of parameters for job descriptions are what you want to use. it may be simpler to have both database files and objects for an application be controlled by one data group. Check the file entry options specified in each data group file entry. you should still create file entries for PF source files to ensure that legacy cooperative processing can be used. Use the procedures in the Using MIMIX book to verify your configuration. 10.7. Check the data group entries for each data group. Be certain that you have checked the data group entries for your critical files and objects. Ensure that all of the files and objects that you need to replicate are represented by entries for the data group. After creating object entries. Note: If you cannot use MIMIX Dynamic Apply for logical files or PF data files. Note: You may have multiple data groups created that you no longer need. b. 510 . MIMIX provides default job descriptions that are tailored for their specific tasks. Create object entries using “Creating data group object entries” on page 242. You may need to adjust the apply sessions. 11. After creating object entries. Use Table 76 to entries for any additional database files or objects that you need to add to the data group. 2. Consider whether or not you can combine information from multiple data groups into one data group. ensure that the values for file entry options (FEOPT) are what you want as defaults for the data group. You may need to modify individual data group file entries. 8. Check how the apply sessions are mapped for data group file entries. If you are using SNA as a transfer protocol. After creating IFS entries. Use “Loading IFS tracking entries” on page 257. Do the following: 1. If you are using TCP as a transfer protocol.Checklist: copy configuration Table 76. Next to the data group you want to confirm. d. f. For additional information. From the management system. resolve the problem. b. (The default value is *INST. Create IFS entries using “Creating data group IFS entries” on page 255. e. load IFS tracking entries for IFS objects that are journaled to a user journal. verify that the MIMIX TCP server is started on each system (on each "side" of the transfer definition).#DGFE audit” on page 546. Look for a job under the MIMIXSBS subsystem with a function of LV-SERVER. From the source system.) Use the command: SETMMXPCY DGDFN(name system1 system2) RULE(*NONE) RUNAUDIT(*INST) 13. Then press Enter. 14. 2. see “Resolving audit problems . From the management system. temporarily change the Action for running audits policy using the following command: SETMMXPCY DGDFN(name system1 system2) RULE(*NONE) RUNAUDIT(*CMPRPR) b.5250 emulator” on page 543 and “Interpreting results for configuration data . type WRKAUD RULE(#DGFE) and press Enter. 511 . Doing this now ensures that objects to be replicated have the object auditing values necessary for replication and that any transactions which occur between configuration and starting replication processes can be replicated. type 9 (Run rule) and press F4 (Prompt). Class IFS objects How to configure data group entries for the preferred configuration. Ensure that object auditing values are set for the objects identified by the configuration before synchronizing data between systems. Verify that system-level communications are configured correctly. Planning and Requirements Information “Identifying IFS objects for replication” on page 106 DLOs “Identifying DLOs for replication” on page 111 12. On the Run Rule (RUNRULE) display specify *NO for the Use run rule on system policy prompt. c. Check the audit status for a value of *NODIFF or *AUTORCVD. If the audit results in any other status. Use the procedure “Setting data group auditing values manually” on page 270. You can use the WRKACTJOB command for this. verify that the MIMIX mode and that the communications entries are added to the MIMIXSBS subsystem. Create DLO entries using “Creating data group DLO entries” on page 259. set the Action for running audits policy to its previous value. Do the following to confirm and automatically correct any problems found in file entries associated with data group object entries: a. a. c. 18. configured for user journal replication. Topic “Performing the initial synchronization” on page 442 includes instructions for how to establish a synchronization point and identifies the options available for synchronizing. 17. 16. 19. For data areas or data queues configured for user journal replication. Use the Verify Communications Link (VFYCMNLNK) command to ensure that a MIMIX installation on one system can communicate with a MIMIX installation on another system. Note: If the objects do not yet exist on the target system. be sure to specify *SRC for the Start journaling on system (JRNSYS) parameter in the commands to start journaling. • • • For user journal replication. Ensure that there are no users on the system that will be the source for replication for the rest of this procedure. Do not allow users onto the source system until you have successfully completed the last step of this procedure. Start the system managers using topic “Starting the system and journal managers” on page 269. use “Journaling for IFS objects” on page 300. use “Journaling for data areas and data queues” on page 303. 15. 512 . Start journaling using the following procedures as needed for your configuration. Synchronize the database files and objects on the systems between which replication occurs. Start the data group using “Starting data groups for the first time” on page 282. Refer to topic “Verifying the communications link for a data group” on page 174. use “Journaling for physical files” on page 297 to start journaling on both source and target systems For IFS objects. audit schedule information is only copied from the current management system’s monitors. do the following: 1. type the command CPYCFGDTA and press F4 (Prompt). Note the following: • When using the CPYCFGDTA command and upgrading to MIMIX version 6 from version 5. This procedure addresses only some of the tasks needed to complete your configuration. 3. Sign on to the system with the security officer (QSECOFR) user profile or with a user profile that has security officer class and all special authorities. Use topic “Choices when ending replication” in the Using MIMIX book to end activity for the appropriate products. The products in the installation library that will receive the copied configuration data must be shut down for the duration of this procedure. Use this procedure only when directed from the “Checklist: copy configuration” on page 509. Audit schedules from other system’s monitors are not copied and the Set MIMIX Policies (SETMMXPCY) command must be used to reset schedules for these audits. 5. 4. Access the MIMIX Basic Main Menu in the product library that will receive the copied configuration data. By default.Copying configuration procedure Copying configuration procedure This procedure addresses only some of the tasks needed to complete your configuration. This may not be desirable. Any configuration created in the product library will be replaced with data from the specified library. To start copying configuration data. press Enter. From the command line. 513 . • To copy existing configuration data to the new MIMIX product. At the Copy from library prompt. 6. return to topic “Checklist: copy configuration” on page 509 to verify your configuration. When the copy is complete. 2. specify the name of the library from which you want to copy data. Use this procedure only when directed from the “Checklist: copy configuration” on page 509. the CPYCFGDTA command replaces all MIMIX configuration data in the current product library with the information from the specified library. you can suspend the application of the replicated changes. This provides an excellent way to have a test environment on a single machine that is similar to a multiple-system configuration. Note: Newly created data groups use remote journaling as the default configuration. The second library in effect becomes a "backup" library. Remote journaling is not compatible with intra communications. Because both libraries exist on the same system. In an Intra configuration. By using an Intra configuration you can reduce or eliminate your downtime for routine operations such as performing daily and weekly backups. When the backup completes. or directory. Intra is a special configuration that allows the MIMIX products to function fully within a singlesystem environment. Intra support replicates database and object changes to other libraries on the same system by using system facilities that allow for communications to be routed back to the same system. an Intra configuration does not provide protection from disaster. Database replication within an Intra configuration requires that the source and target files either have different names or reside in different libraries. the product is installed into two libraries on the same system and configured in a special way. you can resume operations that apply replicated changes to the "backup" library. Similarly. The Intra environment can also be used to perform backups while the system remains active. This enables you to concurrently back up the copied library to tape while your application remains active. objects cannot be replicated to the same named object in the same named library. An Intra configuration enables you to have a "live" copy of data or objects that can be used to offload queries and report generations. You can also use an Intra configuration as a test environment prior to installing MIMIX on another system or connecting your applications to another system. This section includes the following procedures: • • “Manually configuring Intra using SNA” on page 515 “Manually configuring Intra using TCP” on page 516 514 . An Intra configuration uses these libraries to replicate data to additional disk storage on the same system. When replicating changes to another library.Configuring Intra communications APPENDIX C Configuring Intra communications The MIMIX set of products supports a unique configuration called Intra. so you must use source send configuration when configuring for intra communications. folders. Add a communication entry to the MIMIXSBS subsystem for the remote location using the following command: 515 . Create the system definitions for the product libraries used for Intra as follows: a.') 7. use the local location name in the following command: CRTSYSDFN SYSDFN(local-location-name) TYPE(*MGT) TEXT(‘Manual creation’) b. Create a local device description for MIMIX using the following command: CRTDEVAPPC DEVD(MIMIX) RMTLOCNAME(INTRA1) LCLLOCNAME(INTRA2) CTL(MIMIXINTRA) MODE(MIMIX) APPN(*NO) SECURELOC(*YES) TEXT('MIMIX INTRA – Manual creation. Add a communication entry to the MIMIXSBS subsystem for the local location using the following command: ADDCMNE SBSD(MIMIXQGPL/MIMIXSBS) RMTLOCNAME(INTRA2) JOBD(MIMIXQGPL/MIMIXCMN) DFTUSR(MIMIXOWN) MODE(MIMIX) 8. use the following command: CRTSYSDFN SYSDFN(INTRA) TYPE(*NET) TEXT(‘Manual creation’) 2. Create a controller description for MIMIX Intra using the following command: CRTCTLAPPC CTLD(MIMIXINTRA) LINKTYPE(*LOCAL) TEXT('MIMIX INTRA – Manual creation. If you manually configure the communications necessary for Intra. Create a remote device description for MIMIX using the following command: CRTDEVAPPC DEVD(MIMIXI) RMTLOCNAME(INTRA2) LCLLOCNAME(INTRA1) CTL(MIMIXINTRA) MODE(MIMIX) APPN(*NO) SECURELOC(*YES) TEXT('MIMIX REMOTE INTRA SUPPORT. Create the transfer definition between the two product libraries with the following command: CRTTFRDFN TFRDFN(PRIMARY INTRA local-location-name) PROTOCOL(*SNA) LOCNAME1(INTRA1) LOCNAME2(INTRA2) NETID1(*LOC) TEXT(‘Manual creation’) 3.') 4.Manually configuring Intra using SNA Manually configuring Intra using SNA In an Intra environment.') 5. MIMIX communicates between two product libraries on the same system instead of between a local system and a remote system. MIMIXI) to be the remote system. If you need to manually configure SNA communications for an Intra environment.') 6. Create the MIMIX mode description using the following command: CRTMODD MODD(MIMIX) MAXSSN(100) MAXCNV(100) LCLCTLSSN(12) TEXT('MIMIX INTRA MODE DESCRIPTION – Manual creation. do the following: 1. consider the default product library (MIMIX) to be the local system and the second product library (in this example. For the MIMIX library (local system). For the MIMIXI library (remote system). use the command Configure TCP/IP (CFGTCP) command to access the Configure TCP/IP menu. type a 2 (Change) next to the LOOPBACK entry and add 'INTRA' to that entry. local device. consider the MIMIX library as the local system and the MIMIXI library as the remote system. the host name of the management system is Source and the host name for the network or target system is Intra. Manually configuring Intra using TCP In an Intra environment. Start the MIMIX system manager in both product libraries using the following commands: MIMIX/STRMMXMGR SYSDFN(*INTRA) MGR(*ALL) MIMIX/STRMMXMGR SYSDFN(*LOCAL) MGR(*JRN) Note: You still need to configure journal definitions and data group definitions. Select option 10 (Work with TCP/IP Host Table Entries) from the menu.Configuring Intra communications ADDCMNE SBSD(MIMIXQGPL/MIMIXSBS) RMTLOCNAME(INTRA1) JOBD(MIMIXQGPL/MIMIXCMN) DFTUSR(MIMIXOWN) MODE(MIMIX) 9. The libraries for the MIMIX installations need to have the same name with the Intra library having an 'I' appended to the end of the library name. For the MIMIX library (local system) enter the following command: MIMIX/CRTSYSDFN SYSDFN(source) TYPE(*MGT) TEXT(‘management system’) Note: You may have already configured this system. 1. From the Work with TCP/IP Host Table display. Note: If you have multiple network systems. For more information. the MIMIX library is the management system and the MIMIXI library is the network system. 516 . Vary on the controller. see “Multiple network system considerations” on page 152. To add an entry in the host name table. If you manually configure the communications necessary for Intra. All the configuration should be done in the MIMIX library on the management system. In this example. MIMIX communicates between two product libraries on the same system instead of between a local system and a remote system. Create the system definitions for the product libraries used for Intra as follows: a. and remote device using the following commands: VRYCFG CFGOBJ(MIMIXINTRA) CFGTYPE(*CTL) STATUS(*ON) VRYCFG CFGOBJ(MIMIX) CFGTYPE(*DEV) STATUS(*ON) VRYCFG CFGOBJ(MIMIXI) CFGTYPE(*DEV) STATUS(*ON) 10. For this example. You may already have a management system defined and need to add an Intra network system. you need to configure your transfer definitions to have the same name with system1 and system2 being different. You may want to add service table entries for ports 55501 and 55502 to ensure that other applications will not try and use these ports. use the following command: MIMIX/CRTSYSDFN SYSDFN(INTRA) TYPE(*NET) TEXT(‘network system’) 2. Note that the values for PORT1 and PORT2 must be unique. Within the MIMIXI library use the commands: CRTDUPOBJ OBJ(MIMIXCMN) FROMLIB(MIMIXQGPL) OBJTYPE(*JOBD) TOLIB(MIMIXI) NEWOBJ(PORT55502) CHGJOBD JOBD(MIMIXI/PORT55502) RQSDTA('MIMIXI/STRSVR HOST(INTRA) PORT(55502) JOBD(MIMIXI/PORT55502)’) ADDAJE SBSD(MIMIXQGPL/MIMIXSBS) JOB(PORT55502) JOBD(MIMIXI/PORT55502) 4. Create the transfer definition between the two product libraries with the following command. Start the system managers from the management system by entering the following command: MIMIX/STRMMXMGR SYSDFN(INTRA) MGR(*ALL) RESET(*YES) Start the remaining managers normally.Manually configuring Intra using TCP b. For the MIMIXI library (remote system). 517 . MIMIX/CRTTFRDFN TFRDFN(PRIMARY SOURCE INTRA) HOST1(SOURCE) HOST2(INTRA) PORT1(55501) PORT2(55502) 3. Create auto-start jobs in the MIMIX subsystem for the port associated with each library so that MIMIX TCP server is started automatically when the subsystem is started. Start the server for the network system (Intra) by entering the following command: MIMIXI/STRSVR HOST(INTRA) PORT(55502) JOBD(MIMIXI/PORT55502) 6. Within the MIMIX library use the commands: CRTDUPOBJ OBJ(MIMIXCMN) FROMLIB(MIMIXQGPL) OBJTYPE(*JOBD) TOLIB(MIMIX) NEWOBJ(PORT55501) CHGJOBD JOBD(MIMIX/PORT55501) RQSDTA('MIMIX/STRSVR HOST(SOURCE) PORT(55501) JOBD(MIMIX/PORT55501)’) ADDAJE SBSD(MIMIXQGPL/MIMIXSBS) JOB(PORT55501) JOBD(MIMIX/PORT55501) b. Note: You will still need to configure journal definitions and data group definitions on the management system. Start the server for the management system (source) by entering the following command: MIMIX/STRSVR HOST(SOURCE) PORT(55501) JOBD(MIMIX/PORT55501) 5. a. MIMIX also supports replication between SYSBAS and an independent ASP. Now. including journaled IFS objects. Restrictions: There are several permanent and temporary restrictions that pertain to replication when an independent ASP is included in the MIMIX configuration. See 1. Figure 33 shows that MIMIX also supports replication from SYSBAS to an independent ASP and from an independent ASP to SYSBAS. data areas and data queues.MIMIX support for independent ASPs APPENDIX D MIMIX support for independent ASPs MIMIX has always supported replication of library-based objects and IFS objects to and from the system auxiliary storage pool (ASP 1) and basic storage pools (ASPs 232). 518 . located in independent ASPs1 (33-255). The system ASP and basic ASPs are collectively known as SYSBAS. MIMIX supports replication to and from an independent ASP as well as standard replication to and from SYSBAS (the system ASP and basic ASPs). Figure 32. Figure 32 shows that MIMIX supports replication to and from SYSBAS and to and from independent ASPs. Figure 33. An independent ASP is an iSeries construct introduced by IBM in V5R1 and extended in V5R2 of IBM i. MIMIX also supports replication of library-based objects and IFS objects. You can isolate infrequently used data that does not always need to be available when the system is up and running. If you have a lot of data that is unnecessary for day-to-day business operations. 519 . Protect data that is unique to a specific environment by isolating data associated with specific applications from other groups of users. This allows you to shorten processing time for other tasks. A user ASP can either be a basic ASP or an independent ASP. for example. Independent ASPs can also be made available and unavailable at the time of your choosing. without having to make the system unavailable. The system ASP contains the system objects for the operating system and any user objects not defined to a basic or independent ASP. User ASPs are additional ASPs defined by the user. Streamline naming conventions. since the data is isolated. Decrease downtime. Each ASP on your system is a group of disk units that can be used to organize data for single-level storage to limit storage device failure and recovery time. Additional benefits of independent ASPs allow you to do the following: • • • • • Consolidate applications and data from multiple servers into a single IBM System i allowing for simpler system management and application maintenance. you can isolate it and leave it offline until it is needed. The system spreads data across the disk units within an ASP. Auxiliary storage pool concepts at a glance An independent ASP is actually a part of the larger construct of an auxiliary storage pool (ASP). enabling data on your system to be made available or unavailable without an IPL. Avoid the need to recover all data in the event of a system failure. • Using MIMIX provides a robust solution for high availability and disaster recovery for data stored in independent ASPs. such as IPLs.Benefits of independent ASPs “Requirements for replicating from independent ASPs” on page 522 and “Limitations and restrictions for independent ASP support” on page 522. since multiple instances of data with the same object and library names can coexist on a single System i in separate independent ASPs. Add storage as necessary. reclaim storage. and system start time. Benefits of independent ASPs The key characteristic of an independent ASP is its ability to function independently from the rest of the storage on a server. Figure 34 shows the types and subtypes of ASPs. The benefits of using independent ASPs in your environment can be significant. The system ASP (ASP 1) is defined by the system and consists of disk unit 1 and any other configured storage not assigned to a basic or independent ASP. UDFS independent ASPs contain only userdefined file systems and cannot be a member of an ASP group unless they are converted to a primary or secondary independent ASP. the data overflows into the system ASP. Independent ASPs are configured using iSeries Navigator. Identified by device name and numbered 33 through 255. if you make one independent ASP unavailable. such as those for spooled files. Basic ASPs are identified as ASPs 2 through 32. and ownership of an object. Types of auxiliary storage pools. data in an independent ASP cannot overflow into the system ASP. The primary independent ASP name is always the name of the ASP group in which it resides. Unlike basic ASPs. A primary independent ASP defines a collection of directories and libraries and may have associated secondary independent ASPs. the system ASP and the basic ASPs are called SYSBAS. Collectively. Before an independent ASP is made available (varied on). all primary and secondary independent ASPs in the ASP group undergo a process similar to a server restart. Figure 34. 520 . secondary. authorization. 1. Subtypes can be grouped together to function as a single entity known as an ASP group. Another type of user ASP is the independent ASP. One common use for a secondary independent ASP is to store the journal receivers for the objects being journaled in the primary independent ASP. Subtypes of independent ASPs consist of primary. Data that resides in a basic ASP is always accessible whenever the server is running. For example. Attributes. MIMIX does not support UDFS independent ASPs. When storage for a basic ASP is filled.MIMIX support for independent ASPs One type of user ASP is the basic ASP. an independent ASP can be made available or unavailable to the server without restarting the system. An ASP group consists of a primary independent ASP and zero or more secondary independent ASPs. A primary independent ASP defines a database for itself and other independent ASPs belonging to its ASP group. and user-defined file system (UFDS) independent ASPs1. stored in a basic ASP reside in the system ASP. the others in the ASP group are made unavailable at the same time. A secondary independent ASP defines a collection of directories and libraries and must be associated with a primary independent ASP. it is ready to use.Auxiliary storage pool concepts at a glance While this processing occurs. the ASP group is in an active state and recovery steps are performed. several server jobs are started in the QSYSWRK subsystem to support the independent ASP. 521 . server jobs that service the independent ASP are given their own job name when the independent ASP is made available. To ensure that their names remain unique on the server. The primary independent ASP is synchronized with any secondary independent ASPs in the ASP group. While being varied on. Once the independent ASP is made available. Completion message CPC2605 (vary on completed for device name) is sent to the history log. and journaled objects are synchronized with their associated journal. You should not place libraries in independent ASPs within the system portion of a library list. data is available only up to the last backup copy. Log in to Support Central and check the Technical Documents page for a list of IBM i PTFs that may be required. MIMIX product libraries. be aware that independent ASPs do not protect against disk failure. Also. If the disks in the independent ASP are damaged and the data is unrecoverable. SYSBAS is a component of every name space. especially for IFS objects. • • Limitations and restrictions for independent ASP support Limitations: Before using independent ASP support. MIMIX commands automatically call the IBM command SETASPGRP. Unlike basic ASPs. For example. IBM restricts the object types that can be stored in an independent ASP. If an independent ASP attached to the target system fills. be aware of the following limitations: • Although you can use the same library name between independent ASPs. • 522 . the LAKEVIEW library.Requirements for replicating from independent ASPs The following requirements must be met before MIMIX can support your independent ASP environment: • License Program 5722-SS1 option 12 (Host Server) must be installed in order for MIMIX to properly replicate objects in an independent ASP on the source and target systems. no new objects can be created into the device. DLOs cannot reside in an independent ASP. which can result in significant changes to the library list for the associated user job. A replication solution such as MIMIX is still required for high-availability and disaster recovery. so the presence of a library name in SYSBAS precludes its use in any independent ASP. • • Restrictions in MIMIX support for independent ASPs include the following: • MIMIX supports the replication of objects in primary and secondary independent ASPs only. See “Avoiding unexpected changes to the library list” on page 525. an independent ASP cannot share a library name with a library in the system ASP or basic ASPs (SYSBAS). This will affect how you configure object for replication with MIMIX. such as adding records to a file. and the MIMIXQGPL library must be installed into *SYSBAS. In addition. when an independent ASP fills. Replication of IFS objects that reside in user-defined file system (UDFS) independent ASPs is not supported. your high-availability and disaster recovery solutions are compromised. Any PTFs for IBM i that are identified as being required need to be installed on both the source and target systems. See “Configuring library-based objects when using independent ASPs” on page 524. updates to existing objects in the independent ASP. may not be successful. Display Data Group Data Area Entry (DSPDGDAE). For database replication and replication of objects through Advanced Journaling support. Planned switchovers of data groups that include an ASP group must take place while the ASP devices on both the source and target systems are available. You must run the Set ASP Group (SETASPGRP) command on the local system before running the Send Network Object (SNDNETOBJ) command if the object you are attempting to send to a remote system is located in an independent ASP. Any monitors configured for use with MIMIX must specify the ASP group. and *OUTFILE libraries specified on MIMIX commands must reside in SYSBAS. the LAKEVIEW library. and Display Data Group Activity Entry (DSPDGACTE). *JOBD libraries. and the MIMIXQGPL library must be installed into SYSBAS. the independent ASP device on the backup system (which will become the temporary production system) must be available in order for the failover to complete successfully. Data stored in an independent ASP is not accessible for replication when the independent ASP is varied off. Objects cannot be applied to an independent ASP on the target system if the device is not available. 523 . To support an unplanned switch (failover). • • Configuration planning tips for independent ASPs A job can only reference one independent ASP at a time. see the data group definition. For successful replication. This may cause error conditions when running commands. it is not possible for a single data group to replicate both SYSBAS data and ASP group data. If the ASP device for the data group on either the source or target system is unavailable at the time the planned switchover is attempted. Display Data Group Object Entry (DSPDGOBJE). Monitors of type *JRN or *MSGQ that watch for events in an independent ASP must specify the name of the ASP group where the journal or message queue exists. • • • Also be aware of the following temporary restrictions: • MIMIX does not perform validity checking to determine if the ASP group specified in the data group definition actually exists on the systems. the switchover will not complete. Information regarding independent ASPs is not provided on the following displays: Display Data Group File Entry (DSPDGFE).Configuration planning tips for independent ASPs • • • MIMIX product libraries. Objects in independent ASPs attached to the source system cannot be journaled if the device is not available. Any *MSGQ libraries. This is done with the ASPGRP parameter of the CRTMONOBJ command. Storing applications and programs in SYSBAS ensures that they are accessible by any job. These libraries cannot exist in an independent ASP. ASP devices in ASP groups that are configured in data group definitions must be made available (varied on). due to the requirement for one user journal per data group. To determine the independent ASP in which the object referenced in these displays resides. If you are using Advanced Journaling support and want to limit a data group to only replicate IFS objects from SYSBAS. With independent ASPs.For object replication of library-based objects through the system journal. you have the option of placing journal receivers in an associated secondary independent ASP. However. data to be replicated and the journal used for its replication must exist in the same ASP. an ASP group is automatically created that uses the same name you gave the primary independent ASP. carefully plan what generic library names you use when configuring data group object entries in an environment that includes independent ASPs. This applies for replication between independent ASPs as well as replication between an independent ASP and SYSBAS. For IFS replication by default object replication processes. consider what data you store there and the location of the journal and journal receivers needed to replicate the data. Make every attempt to avoid replicating both SYSBAS data and independent ASP data for objects within the same data group. there are differences in how to configure for these different environments. See the example in “Configuring librarybased objects when using independent ASPs” on page 524. 524 . When you create an independent ASP. you should configure related objects in SYSBAS and an ASP group to be replicated by the same data group. When you configure replication for independent ASP. Note: To avoid replicating an object by more than one data group. you do not need to identify an ASP group in a data group definition because an IFS object’s path includes the independent ASP device name. specify *NONE for the ASP group parameters in the data group definition. you must specify the ASP group name in the data group definition so that MIMIX can locate the appropriate user journal. otherwise you can create situations where the same object is replicated by multiple data groups. However. for IFS replication through Advanced Journaling support. Configuring IFS objects when using independent ASPs Replication of IFS objects in an independent ASP is supported through default replication processes and through MIMIX Advanced Journaling support. Journal and journal receiver considerations for independent ASPs For database replication and replication of objects through Advanced Journaling support. This precaution ensures that the data group will start and that objects residing in SYSBAS will be replicated when the independent ASP is not available. Objects in SYSBAS and an ASP group that are not related should be separated into different data groups. Configuring library-based objects when using independent ASPs Use care when creating generic data group object entries. which is not desirable. Similarly. Object XYZ in library LIBBAS is replicated by both data groups APP1 and APP2 because the data groups contain the same generic data group object entry. If the library list contains libraries for ASP groups other than those used by the ASP group for which the command was called. As a result. MIMIX resets the job's ASP group to its initial value as needed before processing is completed. if SYSBAS contains an object that matches the generic data group object entry defined for each data group. MIMIX automatically determines whether the job requires a call to the IBM command Set ASP Group (SETASPGRP). the SETASPGRP removes the extra libraries from 525 . the same object is replicated by both data groups. in this example. both data groups replicate the corresponding object. this presents a problem if you need to perform a switch. However. Avoiding unexpected changes to the library list It is recommended that the system portion of your library list does not include any libraries that exist in an ASP group. as shown in Figure 35. Figure 35 shows that object LIBBAS/XYZ meets the criteria for replication by both data groups. The SETASPGRP command may modify the library list of the current job. Figure 35. Both data groups have a generic data group object entry that includes object XZY from library names beginning with LIB*. This is considered normal behavior for replication between independent ASPs. group APP2 defines replication between ASP groups named OAK on each system. Whenever you run a MIMIX command. If object LIBASP/XYZ exists in both independent ASPs and matches the generic data group object entry defined in each data group.Configuration planning tips for independent ASPs For example. The SETASPGRP command changes the current job's ASP group environment and enables MIMIX to access objects that reside in independent ASP libraries. data group APP1 defines replication between ASP groups named WILLOW on each system. The independent ASP libraries are removed from the library list.the library list. including a library in independent ASP WILLOW in the system portion of the library list. The system portion of the library list is not restored to its initial value. The library in independent ASP WILLOW in the system portion of the library list is removed. Figure 37. Figure 36. This can affect the system and user portions of the library list as well as the current library in the library list. When a MIMIX command runs the SETASPGRP command during processing. Before a MIMIX command runs. The library list contains three independent ASP libraries. Figure 36. The libraries in independent ASP OAK in the user 526 . press Enter. and Figure 38 show how the system portion of the library list is affected on the Display Library List (DSPLIBL) display when the SETASPGRP command is run. Display Library List System: Type options. After the MIMIX command runs. press Enter. 5=Display objects in library Opt ___ ___ ___ ___ ___ ___ Library LIBSYS1 LIBSYS2 LIBSYS3 LIBCUR1 LIBUSR1 LIBUSR2 Type SYS SYS SYS CUR USR USR ASP device Text : : : : : : Bottom F3=Exit F12=Cancel F17=Top F18=Bottom CHICAGO Figure 38. MIMIX resets the user portion of the library list and the current library in the library list to their initial values. 5=Display objects in library Opt ___ ___ ___ ___ ___ ___ Library LIBSYS1 LIBSYS2 LIBSYS3 LIBCUR1 LIBUSR1 LIBUSR2 Type SYS SYS SYS CUR USR USR ASP device WILLOW Text : : : : : : Bottom F3=Exit F12=Cancel F17=Top F18=Bottom CHICAGO WILLOW OAK Figure 37. Display Library List System: Type options. During the running of a MIMIX command. press Enter. The monitor is not automatically started after MIMIX is installed. To change the threshold value. MMIASPTHLD. Detecting independent ASP overflow conditions You can take advantage of the independent ASP threshold monitor to detect independent ASP overflow conditions that put your high availability solution at risk due to insufficient storage.Detecting independent ASP overflow conditions portion of the library list and the current library are restored. Display Library List System: Type options. Notifications can be displayed from MIMIX Availability Manager or with the Work with Notifications (WRKNFY) command. When this condition is detected. 527 . The monitor is controlled by the master monitor. you must start it. The independent ASP threshold monitor is shipped with MIMIX. you must use IBM's iSeries Navigator. The independent ASP threshold monitor. If you want to use this monitor. monitors the QSYSOPR message queue in library QSYS for messages indicating that the amount of storage used by an independent ASP exceeds a defined threshold. 5=Display objects in library Opt ___ ___ ___ ___ ___ ___ Library LIBSYS1 LIBSYS2 LIBSYS3 LIBCUR1 LIBUSR1 LIBUSR2 Type SYS SYS SYS CUR USR USR ASP device Text : : : : : : Bottom F3=Exit F12=Cancel F17=Top F18=Bottom CHICAGO WILLOW OAK The SETASPGRP command can return escape message LVE3786 if License Program 5722-SS1 option 12 (Host Server) is not installed. The status of warning notifications is incorporated into overall MIMIX status. the monitor sends a warning notification that the threshold is exceeded. Each ASP defaults to 90% as the threshold value. “Creating user-generated notifications” on page 535 describes how to create a notification that can be used with custom automation. • • • • • 528 . “MIMIX rule groups” on page 539 lists the pre-configured sets of MIMIX rules that are shipped with MIMIX. “Guidelines and recommendations for auditing” on page 530 provides considerations for effectively auditing a replication environment and recommendations for using both MIMIX rules and user-defined rules. This appendix describes how to create user-defined rules and notifications. “Requirements for using audits and rules” on page 530 identifies the policy required for automatic audit recovery and the authority levels needed for working with rules when additional product and command security functions provided through License Manager are used. • • “What are rules and how they are used by auditing” on page 529 defines the differences between MIMIX rules used for auditing and user-defined rules. “Running user rules and rule groups programmatically” on page 538 describes running rules when initiated by a job scheduling task. This can be useful to perform specialized checks of your environment that augment your regularly scheduled audits. “Creating user-defined rules” on page 534 describes how to create a rule and provides an example of a user-defined rule that checks the name of the first and last member of files that have multiple members.Creating user-defined rules and notifications Creating user-defined rules and notifications APPENDIX E MIMIX provides the capability to create user-defined rules and integrate the status of those rules into status reporting for MIMIX. When user-defined rules are run. a rule defines a command to be invoked by the MIMIX Run Rule (RUNRULE) command and options for notifying you of the result. Userdefined rules do not include the automatic job scheduling support available for MIMIX rules. if needed.MIMIX AutoGuard uses MIMIX rules as the mechanism for defining and invoking audits. Specifically. called notifications. Two commands. Run Rule (RUNRULE) and Run Rule Group (RUNRULEGRP). MIMIX invokes the RUNRULE command when submitting automatically scheduled audits. user-defined rules do not support automatic recovery actions. 529 . You specify the command or program to be invoked by the rule. While MIMIX rules cannot be changed.User-defined rules are those that you create for a specific purpose either by copying a MIMIX rule or by creating a rule in MIMIX Availability Manager. You can create MIMIX monitors to handle job scheduling or use a different job scheduling mechanism. enable programmatic scheduling of rule activity. Each shipped MIMIX rule pre-defines a command invoked by the compare phase of an audit and the possible actions that can be initiated. You can also run rules on demand by using user interface options for audits and rules or by using these commands interactively.What are rules and how they are used by auditing What are rules and how they are used by auditing A rule provides the construct for defining and processing an action to detect a problem that is inconsistent with your availability requirements. even if the specified command was copied from a MIMIX rule. MIMIX rules require job scheduling support. Userdefined rules provide a way of incorporating other types of checks into your MIMIX environment. Also. In other words. in the recovery phase of an audit. MIMIX rules . There are two types of rules: MIMIX rules and user-defined rules. that are available in the MIMIX user interface and incorporates the severity of detected errors into MIMIX status. you have considerable control over audits that use MIMIX rules through policies and scheduling. MIMIX rules have names which begin with the pound sign (#) character. a rule is a check for compliance. User-defined rules . the rules framework automatically generates indicators. such as that provided by MIMIX. Running rules requires operator (*OPR) authority. consider how much data there is to compare. This section highlights the main considerations but does not make specific recommendations or provide full examples. • In some environments using commitment control. The level you choose for daily audits depends on your environment. there are a number of things to consider. Changing rules requires management (*MGT) authority. how long the audit runs. (MIMIX rules cannot be changed. 530 . See audit level. The following are key considerations: • • • How much time or system resource can you dedicate to audit processing each day. respectively. you must have the Automatic audit recovery policy enabled. Audit level: Best practice for auditing is to run the most extensive comparison possible. If you choose to run daily audits at a lower audit level. When choosing a value. Guidelines and recommendations for auditing To effectively audit a replication environment. Specifying level 30 for the Audit level policy enables this. the #MBRRCDCNT audit may be long-running. New files created during that time may not be audited. If you take advantage of the additional product and command security functions provided through License Manager. Lower audit levels may take days or weeks to completely audit file data. you should run all audits at audit level 30. you should be aware of the risks. For example: – Before switching. and how often you need to be certain that data is synchronized between source and target systems. how frequently it changes. At level 10. Refer to the MIMIX Reference book for information about improve performance of this audit. week. you may need different authority levels to work with rules.) For more information about these provided security functions.Requirements for using audits and rules To take advantage of automatic recoveries that audits invoke through MIMIX rules. The #IFSATR audit compares data when audit level 20 or 30 is used. consider when you may need to run audits manually. or month? How often should all data within the database be audited? In addition to regularly scheduled audits. see the License and Availability Manager book. how often you run the audit. MIMIX service providers are specifically trained to provide a robust audit solution that meets your needs. The #FILDTA audit compares all file member data defined for file members defined to a data group only when audit level 30 is used. and especially on the data compared by the #FILDTA and #IFSATR audits. only attributes are compared. Level 10 and level 20 compare 5 percent and 20 percent of data. Viewing rules requires display (*DSP) authority. especially when switching. Recommendations when automatic audit recovery is enabled: You should also consider the following when you use audit recoveries: • • MIMIX rules support recoveries only when the automatic audit recovery policy is enabled. • • Considerations and recommendations for rules The following considerations apply to MIMIX rules used by audits as well as to userdefined rules unless explicitly noted otherwise. investigating the environment for the cause may determine that a change is needed in the environment. consider your switching needs. where the root problem is that a library of logical files is not identified for replication. Watch for trends in the audit results. Vision Solutions strongly recommends that you perform audits at audit level 30 before the following events to ensure that 100 percent of that data is valid on the target system: • • Before performing a planned switch to the backup system. Report these scenarios to MIMIX CustomerCare. Always review the results of the audits. Trends may also indicate a MIMIX problem. even when no differences (*NODIFF) are reported. It may take multiple iterations of running audits with recoveries before the results are clean. You may need to take actions other than running an audit to correct detected issues. are only supported from MIMIX Availability Manager. For example. Some objects may not have been compared due to object activity or due to the audit level policy value in effect. such as creating new user-defined rules or rule groups. Recovering from one error may result in a different error surfacing the next time the audit is performed. In this case. in the MIMIX configuration. Trends may indicate situations that need further investigation. For example. For example. Note: Rules are not allowed to run against disabled data groups. such as reporting an object as being recovered when it was not.Guidelines and recommendations for auditing Regardless of the level you use for daily operations. you may need to change a procedure so that target system objects are only updated by replication processes. objects that are being recovered for the same reason every time you run an audit can be an indication that something in your environment is affecting the objects between audits. You can do this by creating a new case using the Case Management page in Support Central. Before switching back to the production system. Audit results reflect only what was actually compared. 531 . General recommendations: • When choosing the value for the Run rule on system policy. Automatic recovery is not supported for user-defined rules. Certain activities. or in both. Rules can be run from either user interface. a recovery that adds data group file entries may result in detecting a database relationship difference (*DBRIND) error the next time the audit is performed. Otherwise. They can also simplify outfile generation and cleanup. and possible recoveries from the rule. 532 . For the Job description and Library prompts. Considerations for the run rule commands: The RUNRULE command allows you to run multiple rules concurrently. you must specify the value for the data group definition on the RUNRULE command. • Rule-generated messages and notifications For audits. This will help you detect problems in a timely manner and when you have time to address them. This topic describes additional. The outfile is placed in a library whose name is the name of the MIMIX installation library followed by the characters _0. A limit of 100 unique rules can be specified per RUNRULE request. Replacement variables begin with an ampersand (&) and are used to pass in a value when a rule action is run. with each specified rule running in an independent process. When running a rule or rule group from MIMIX Availability Manager. the primary interface for checking results is the Audit Summary interface. If *NONE is specified on the command when the rule uses the &DGDFN replacement variable. you will not see the message log entries. MXAUDIT. When &OUTFILE is specified in a rule. The RUNRULEGRP command only allows you to specify one rule group at a time. MXAUDIT. The outfile is managed by MIMIX. means the rule will not be run against a data group. • Replacement variables Replacement variables are used to simplify the configuration and management of rules by allowing rule actions to be used for multiple data groups. When a data group name or *ALL is specified. any instance of the &DGDFN replacement variable is replaced with the data group name and each data group is run in a separate process. you will be able to view the resulting outfile from the user interface. secondary messaging for rules. In order to run a rule that contains &DGDFN. Otherwise. The &OUTFILE replacement variable passes in the name of a MIMIX generated output file (outfile). Some commonly used replacement variables include: • • The &PRDLIB replacement variable passes in the library from which the command specified in the rule is initiated.• • Run MIMIX rules on a scheduled basis. consider the following: • For the Data group definition prompts. When prompting the RUNRULE or RUNRULEGRP commands. notifications. submits the request using the default job description. The &DGDFN replacement variable identifies the data group the rule is to act upon. running the RUNRULE command results in an error condition in the audit status and a message log entry. you should ensure that you have selected the appropriate systems for viewing in the browser preferences. the default value. the default value. *NONE. this command is like the RUNRULE command. an escape message appears in the message log and an error notification is sent to the notifications user interface. an informational message appears in the message log. An informational message also appears when a rule action completes successfully. 533 .and notification-related messages.Guidelines and recommendations for auditing When the action identified in a rule is started. Rules that call MIMIX commands may result in an error notification and a message log entry if you not have a valid access code for the MIMIX product or if the access code expired. When an action initiated by a rule ends in error or runs successfully but detects differences. Rule-related messages are marked with a Process value of *NOTIFY to facilitate the filtering of rules. You can use substitution variables within the specified command so it can be used for multiple data groups.Creating user-defined rules A user-defined rule can address specific needs that are unique to your environment. From the navigation bar. you can automate customized checks of your environment and have the results incorporated into the overall status for MIMIX. the details of that rule are displayed. From MIMIX Availability Manager. or both by using the CMPFILA command. user-defined rules can be run and their results can be checked from either user interface. &dgdfn. For more information about running rules manually and checking the results of user-defined rules. If you need to perform this check often. select the System and Installation on which you want to create the rule. Note: User-defined rules can only be created through MIMIX Availability Manager. when the command is invoked by an audit using the #FILATR rule these attributes are not compared. Many windows in MIMIX Availability Manager support actions for running rules. select the Copy action and click . You can compare the name of the first member. 3. The substitution characters (&prodlib. The rule can then be submitted by a job scheduling utility. Once created. Table 77 illustrates a user-defined rule that compares the *FIRSTMBR and *LASTMBR attributes of a multi-member file. although the Compare File Attributes (CMPFILA) command supports comparing the *FIRSTMBR and *LASTMBR attributes. including those which are copies of MIMIX rules. Results are accessible from the notifications associated with the rule. See “Considerations and recommendations for rules” on page 531. Do the following: a. see the Using MIMIX book. c. b. For example. the name of the last member. If you copied a rule. At the Command prompt. specify or change the command to be run by the rule. Specify a name at the Rule prompt. you can easily automate the task by creating a user-defined rule to perform this check. and &outfile) used in the specified command allow this rule to be used to 534 . 2. Automatic recovery actions are not supported for any user-defined rules. such as a MIMIX monitor. From a 5250 emulator. do one of the following: • • Select New Rule Locate a rule to copy. In the Rules window. Specify or change the Description prompt to identify the purpose of the rule. do the following: 1. 4. rules can be run using the RUNRULE command. Then select Rules. and scheduled so that it runs periodically. Example of a user-defined rule User-defined rules can supplement auditing by checking additional attributes that are critical to your environment. A new window opens. Click Save. By creating user-defined rules. 30 &prdlib/CMPFILA DGDFN(&dgdfn) CMPLVL(*FILE) CMPATR(*FIRSTMBR *LASTMBR) OBJDIFMSG(*OMIT) OUTPUT(*OUTFILE) OUTFILE(&outfile) BATCH(*NO) Error Send a notification Notification severity: Notification on success: Creating user-generated notifications MIMIX supports the ability to create user-generated notifications for user-defined events and have their status and severity reflected within overall MIMIX status. User-generated notifications are created with a status of *NEW.Creating user-generated notifications check the first and last member name of files in any data group.Specify the severity assigned to the notification. Usergenerated notifications can be created interactively from a command line or by automation programs when user-defined events are detected. Enter the following from a command line: installation_library/ADDNFYE 2. To create a user-generated notification. default values result in a report type that includes only detected differences. enclosed in apostrophes. User-generated notifications appear in the Notifications window (MIMIX Availability Manager) and on the Work with Notifications display (5250 emulator) and their severity is reflected in MIMIX status on higher-level displays. The systems from which you can view a notification are subject to the role of the system on which the notification was created and the value that was specified for the DGDFN parameter. The specified value determines how the notification is prioritized in 535 .Specify a short description with no more than 132 characters of text. Table 77. Rule: Description: Based on audit level: Command: Sample user-defined rule to check first and last member names mbrname Compares the *FIRSTMBR and *LASTMBR names. Although not explicitly specified in the command shown in this example. Notification severity (SEVERITY) . Notification description (TEXT) . Specify values for the following prompts: a. This text will appear in the Notifications window (MIMIX Availability Manager) and Work with Notifications display (5250 emulator) b. do the following: 1. The Add Notification Entry (ADDNFYE) display appears. the role of the system (management or network) determines where the notification will be available. The role of the system (management or network) on which the monitor runs and the values specified for the Add Notification Entry command in the monitor’s event program determine where the notification will be available. Example of a user-generated notification A MIMIX administrator wants to see a notification reflected in MIMIX status when TCP communications fails. typically action is required to resolve the problem. 4. When the value *NONE is specified. Notification details (DETAIL) .If necessary. Use the default value *ERROR to indicate an error was detected.overall MIMIX status. the notification is available on either system defined to the data group. this information is available for the notification from the system on which the notification was sent.Specify information to identify what caused the notification and what users are expected to do if action is needed. The following command creates a message queue monitor named COMPROB to check for message LVE0113 (TCP communications request failed with error &1) in the MIMIX message queue in the MIMIXQGPL library: CRTMONOBJ MONITOR(COMPROB) EVTCLS(*MSGQ) EVTPGM(user_library/COMPROB) MSGQ(MIMIXQGPL/MIMIX) MSGID(LVE0113) AUTOSTR(*YES) TEXT('Issue notification entry for TCP communication problem') 536 . you must specify it now.) Because the communications problem being monitored for may also prevent the notification from reaching the appropriate systems. When a data group is specified. A monitor runs only a single system but the notification it will generate may not be available on multiple systems. see the DGDFN information in “Creating user-generated notifications” on page 535. You can optionally specify values for Job name details (JOB) and File details (FILE) to identify the job which generated the notification and an associated output file and library. d. c. The value *WARNING identifies that action may be required and the value *INFO informs of a successful operation. To add the notification. When specified. In order to have this information available to users. This information is visible when the notification details are displayed. enclosed in apostrophes. Data group definition (DGDFN) . 3. A notification with a value of *NONE added from a management system will not be available on any network systems. (For details. Note: The administrator in this example must use care when determining where to create the monitor. press Enter. This field must be no more than 512 characters of text. the administrator chose to create this monitor on multiple systems in the installation. specify the three-part name for a data group. A message queue monitor on a specific system can check for a message indicating a communications failure and issue a notification when the message occurs. A notification with a value of *NONE added from a network system will not be available on any other network systems. see the Using MIMIX Monitor book. which will add a notification to MIMIX in the specified installation library: installation_library/ADDNFYE TEXT('comm failure') SEVERITY(*ERROR) DGDFN(*NONE) DETAIL(‘TCP communications failed.’) Once the monitor is enabled and started.Creating user-generated notifications The event program includes the instruction to issue the following command. For additional information about creating monitors and writing event programs. Investigation needed. the event program COMPROB will run when the message LVE0113 is detected. 537 . From the system on which you want the rule to run. The Add Monitor Information (ADDMONINF) display appears. Example: In this example.Running user rules and rule groups programmatically The benefit of using rules is that. 538 . with them. enter the following command to create the monitor: CRTMONOBJ MONITOR(MBRNAME) EVTCLS(*TIME) EXITPGM(*CMD) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*SUN) SCDTIME(010000) AUTOSTR(*YES) TEXT(‘Monitor to run the rule MBRNAME’) 2. 1. The rule will run against all data groups. they should be run programmatically. The following procedure creates a monitor that runs the MBRNAME rule on the local system at 1:00 AM on Sundays. see the Using MIMIX Monitor book. Enable the monitor using the command: CHGMONSTS MONITOR(MBRNAME) STATUS(*ENABLED) 4. Example of creating a monitor to run a user rule You can create your own monitors to run user-defined rules automatically at scheduled intervals. The monitor is enabled to start with the master monitor so that scheduling is automatic. the user rule MBRNAME has already been created through MIMIX Availability Manager. Specify the following at the Command prompt and press Enter. Start the monitor using the command: STRMON MONITOR(MBRNAME) For more information about MIMIX Monitor. initiated by a job scheduling task. you can automate activity that would otherwise be difficult or time consuming. RUNRULE RULE(MBRNAME) DGDFN(*ALL) 3. To get the most benefit from rules. see topic How audits are scheduled automatically in the Using MIMIX book. Set of shipped IFS rules. Table 78 lists the pre-configured rule groups shipped with MIMIX. file.MIMIX rule groups MIMIX rule groups Each MIMIX rule group consists of a predetermined set of MIMIX rules. #FILATR. #MBRRCDCNT Rule group name #ALL #ALLATR Set of shipped attribute comparisons for files. #FILATRMBR. #OBJATR #DLOATR. #FILATRMBR. #ALLDTA #FILALL #FILATR #FILATR. #OBJATR #FILDTA. For a description of each MIMIX rule used by each rule group. #IFSATR. and DLOs. Set of shipped file rules that compares file and member attributes and file data. #FILDTA. IFS objects. #IFSATR. #IFSATR #DGFE. Set of shipped file rules that compares file and member attributes. #DLOATR. Pre-configured MIMIX rule groups Description Set of all shipped DLO. #FILDTA. and object rules. objects. Set of data comparisons for files and IFS objects. #FILATR. Individual rules included #DGFE. IFS. and checks configuration for files using cooperative processing. #MBRRCDCNT. Table 78. #FILATRMBR. #FILATR. #FILATRMBR #IFSALL #IFSATR 539 . • • • • • 540 .5250 emulator” on page 543 describes how to check the status of an audit and resolve any problems that occur from a 5250 emulator.Interpreting audit results APPENDIX F Interpreting audit results Audits use commands that compare and synchronize data. “Interpreting results of audits that compare attributes” on page 551 describes the Compare Attributes commands and their results. The following topics provide supporting information for interpreting data returned in the output files.#DGFE audit” on page 546 describes the #DGFE audit which verifies the configuration data defined to your configuration using the Check Data Group File Entries (CHKDGFE) command.MIMIX Availability Manager” on page 541 describes how to check the status of an audit and resolve any problems that occur from within MIMIX Availability Manager. • “Resolving audit problems . “Resolving audit problems . The results of the audits are placed in output files associated with the commands. “Interpreting results of audits for record counts and file data” on page 548 describes the audits and commands that compare file data or record counts. “Interpreting results for configuration data . “Checking the job log of an audit” on page 545 describes how to use an audit’s job log to determine why an audit failed. Table 79 provides additional information. 2.MIMIX Availability Manager Resolving audit problems . check the State and Results columns for the values shown in Table 79. Select the Run action and click . 2. If you are not certain which system is the management system. confirm that replication processes are active. Table 79. In the Audit Summary window. Confirm that data group processes are active and run the rule for the audit again. In most cases. When processes are active. 3. select Run from the action list and click . 1.Resolving audit problems . this is the management system. Rule Failed User journal replication is not active 541 . You may also need to view the output file or the job log. Select Data Groups from the navigation bar. Check the data group status. select the Start action and click . Ensure that you have selected the management system for the installation you want from the navigation bar. In the Summary area. flyover text for the status icon identifies the appropriate action to take. 3. which are only available from the system where the audits ran. refer to “Checking the job log of an audit” on page 545 for more information. To run the audit.MIMIX Availability Manager When viewing results of audits. select Summary from the navigation area. you can select Services to check. 4. select Audit Summary from the navigation bar. Do the following: 1. From the management system. Locate the audit in question.MIMIX Availability Manager Results (blank) Action Check the job log or run the rule for the audit again. 4. To see the job log. For each audit. If necessary. Audits with potential problems are at the top of the list. Then select the data group from the list. State Rule Failed Addressing audit problems . the starting point is the Audit Summary window. and *UN. such as #FILDTA. The detected differences are displayed. • If the Automatic audit recovery policy is disabled. For more information about the values displayed in the audit results. The detected differences are displayed. Look for items with a Difference Indicator value of *NE. However. if the audit is frequently not run due to this policy. see “Interpreting results for configuration data . automatic recovery is not possible. *UE. Either the data group was inactive or an apply process exceeded its threshold. To have MIMIX recover differences on subsequent audits. *NF2. 2. may correct the detected differences. select Notifications from the action list and click . To determine the cause. You may need to start the data group and wait for threshold conditions to clear. Either the Automatic audit recovery policy is disabled or the Action for running audits policy prevented recovery actions while the data group was inactive or had an apply process which exceeded its threshold. and “Interpreting results of audits that compare attributes” on page 551. Other audits. You can display details about the error or attempt the possible recovery action available.MIMIX Availability Manager Results Differences detected. you may see other values as well. You can display details about the error or attempt the possible recovery action available. If automatic audit recovery is disabled. Select Output File from the action list and click .#DGFE audit” on page 546. action may be needed to resolve the cause of the problem. This may be expected during periods of peak activity or when data group processes have been ended intentionally. The remaining detected differences must be manually resolved. 3. Select the action you want and click . Completed Successfully Completed Successfully Differences detected. or *RCYFAILED. correct any problems with the data group status.Table 79. Look for items with a Difference Indicator value of *NC or *NE. Select the action you want and click . *NF1. change the value of the automatic audit recovery policy. For the #MBRRCDCNT results. the differences must be manually resolved. Select Output File from the action list and click . also look for values of: *HLD. Then run the audit again. recovery disabled Action The detected differences must be manually resolved. To manually resolve differences. • If the Action for running audits policy was the cause. 2. *LCK. some objects not recovered Do the following: 1. Not run due to policy (any value) The audit was prevented from running by the Action for running audits policy. *NC. *SJ. 542 . 3. do the following: 1. Note: For audits using the #MBRRCDCNT rule. State Addressing audit problems . “Interpreting results of audits for record counts and file data” on page 548. or P in the Source and Target columns. Then skip to Step 6. the starting point is the Summary view of the Work with Audits display. L. If there are no problems with replication processes. use option 9 (Run rule) to run the audit. 3. 1. Reason 1: The rule called by the audit failed or ended abnormally.Resolving audit problems . Check the Audit Status column for values shown in Table 80. check whether there are any problems indicated for replication processes. use option 9 (Troubleshoot) next to the Replication activity. 5. use F10 to access the appropriate view. On the Work with Data Groups display. If there are replication problems. if processes for the data group show a red I. Do the following from the management system: 1.5250 emulator When viewing results of audits. use F20 to access a command line and type WRKAUD. 4. When processes are active. which are only available from the system where the audits ran. From the Work with Audits display. Status *FAILED Addressing audit problems . From the MIMIX Availability Status display. enter WRKAUD VIEW(*AUDSTS) From the MIMIX Availability Status display. see “Checking the job log of an audit” on page 545. this is the management system. Reason 2: The #FILDTA audit or the #MBRRCDCNT audit required replication processes that were not active. • To run the rule for the audit again. In most cases.5250 emulator Action The audit failed for these possible reasons. 6. 2. if necessary. use option 5 (Display details) next to Audits and notifications. Audits with potential problems are at the top of the list. select option 9 (Run rule). You may also need to view the output file or the job log. • To check the job log. Table 80. Take the action indicated in Table 80.5250 emulator Resolving audit problems . 2. • • From a command line. use option 9 (Start DG). 543 . use F7 to view audits. Then. Do one of the following to access the Work with Audits display. action may be needed to resolve the cause of the problem. may correct the detected differences. and “Interpreting results of audits that compare attributes” on page 551.#DGFE audit” on page 546. A subsetted list of the notifications for the audit appears. A subsetted list of the notifications for the audit appears. also look for values of: *HLD. you may see other values as well. The comparison performed by the audit detected differences. 544 . correct any problems with the data group status. Other audits. and *UN. you will need to manually resolve these issues. For any of these differences. *NF2. Either the data group was inactive or an apply process exceeded its threshold. Use option 8 to view the results in the output file. Either the Automatic audit recovery policy is disabled or the Action for running audits policy prevented recovery actions while the data group was inactive or had an apply process which exceeded its threshold. Use option 7 to view notifications for the audit. You may need to start the data group and wait for threshold conditions to clear. *NE. This may be expected during periods of peak activity or when data group processes have been ended intentionally. The remaining detected differences must be manually resolved. *NF1. *SJ. from the notification do the following: 1. However. Status Addressing audit problems . Note: For audits using the #MBRRCDCNT rule. To have MIMIX recover differences on subsequent audits. if the audit is frequently not run due to this policy. For any of these differences. see “Interpreting results for configuration data . To manually resolve differences. Some of the differences were not automatically recovered. such as #FILDTA. *LCK. 2. *NOTRUN The audit was prevented from running by the Action for running audits policy. If automatic audit recovery is disabled. No recovery actions were attempted.5250 emulator Action The comparison performed by the audit detected differences. change the value of the automatic audit recovery policy. • If the Automatic audit recovery policy is disabled. Use option 8 to view the results in the output file. To determine the cause. you will need manually resolve these problems. 2. For the #MBRRCDCNT results. Check the Difference Indicator column for values of *NC and *NE. *DIFFNORCY *NOTRCVD Do the following: 1. use option 7 to view notifications for the audit. Then run the audit again. 3. and *RCYFAILED. “Interpreting results of audits for record counts and file data” on page 548. • If the Action for running audits policy was the cause. the differences must be manually resolved. For more information about the values displayed in the audit results. *UE. automatic recovery is not possible.Table 80. Check the Difference Indicator column for values of *NC. The notifications associated with the audit are displayed on the Work with Notifications display. Typically. 4. From MIMIX Availability Manager. . do the following: 1. This choice is 2. 5. From a 5250 emulator. Do the following: 1. select the Job logs action and click only available when viewing audits from the sending system. the job log is available on the system where the audit ran. use option 12 (Display job) next to the notification. Note: If you see ‘no data available’ instead. Usually the most recent messages are at the bottom of the display. to check the job log for an audit. 545 . this is the management system. 3. Use option 5 (Display) or F22 to view the description in the Notification column. Then use option 5 (Display) from the Display Job Spooled Files display. If the notification is not sufficient to determine the problem. If it still exists. From the Work with Audits display. The Display Job menu opens. Look for a completion message from the rule with the text indicated from Step 2. you may still be able to view the job log from the 5250 emulator as described below. Look at the most recent messages to determine the cause of the audit failure. Select option 4 (Display spooled files). For the audit in question. you must display the notifications from an audit in order to view the job log. type 7 (Notification) next to the audit and press Enter. 2.Checking the job log of an audit Checking the job log of an audit An audit’s job log can provide more information about why an audit failed. The Job Log window opens. Recovered by automatic recovery actions. re-create the missing file.#DGFE audit The #DGFE audit verifies the configuration data that is defined for replication in your configuration. Table 81 shows the possible Result values and describes the action to take to resolve any reported problems. Run the audit again. copy the existing DGOBJE to a new. *RECOVERED *UA The Option column of the report provides supplemental information about the comparison. *DGFESYNC . Automatic audit recovery actions were attempted but failed to correct the detected error.The data group file entry was not synchronized between the source and target systems. This may have been resolved by automatic recovery 546 . This audit invokes the Check Data Group File Entries (CHKDGFE) command for the audit’s comparison phase. Delete the DGFE for the member or add the member to the file. Delete the DGFE or change the DGOBJE to COOPDB(*YES) Note: Changing the object entry affects all objects using the object entry. No action is needed. copy the existing DGOBJE to a new. The CHKDGFE command collects data on the source system and generates a report in a spooled file or an outfile. specific DGOBJE with the appropriate COOPDB value.Interpreting results for configuration data . If you do not want all objects changed to this value. The report is available on the system where the command ran. or restore the missing file. Table 81. *EXTRADGFE An extra file entry exists. The values in the Result column of the report indicate detected problems and the result of any attempted automatic recovery actions. File entries are in transition and cannot be compared.possible results and actions to for resolving errors Recovery Actions No file entry exists. Delete the DGFE. If you do not want all objects changed to this value. Run the audit again. *NOFILECHK .The comparison request included an option that prevented an error from being reported when a file specified in a data group file entry does not exist.No options were specified on the comparison request. *NOFILE *NOMBR *RCYFAILED No file exists for the existing file entry. specific DGOBJE with the appropriate COOPDB value. No file member exists for the existing file entry. Create the DGFE or change the DGOBJE to COOPDB(*NO) Note: Changing the object entry affects all objects using the object entry. Result *NODGFE CHKDGFE . Possible values are: *NONE . Result *NODGFE *EXTRADGFE *NOFILE *NOMBR CHKDGFE . but a member is no longer defined to that file. One possible reason why actual configuration data in your environment may not match what is defined to your configuration is that a file was deleted but the associated data group file entries were left intact. these configuration problems can be automatically detected and recovered for you. Another reason is that a data group file entry was specified with a member name. If you use the automatic scheduling and automatic audit recovery functions of MIMIX AutoGuard. Table 82 provides examples of when various configuration errors might occur.possible error conditions File exists Yes Yes No Yes Member exists Yes Yes No No DGFE exists No Yes Yes Yes DGOBJE exists COOPDB(*YES) COOPDB(*NO) Exclude No entry 547 .#DGFE audit actions for the audit.Interpreting results for configuration data . Table 82. Cannot open file.000 records of a member that fail to compare. The file or the MIMIX-created SQL view cannot be opened. Commit cycle activity on the source system prevents active processing from comparing records or record counts in the selected member. the data included for each report type is as follows: • • Difference reports (RPTTYPE(*DIF)) return information about detected differences. Values *APY *CMT Possible values for Compare File Data (CMPFILDTA) output file field Difference Indicator (DIFIND) Description The database apply (DBAPY) job encountered a problem processing a U-MX journal entry for this member.Interpreting results of audits for record counts and file data The audits and commands that compare file data or record counts are as follows: • • #FILDTA audit or Compare File Data (CMPFILDTA) command #MBRRCDCNT audit or Compare Record Count (CMPRCDCNT) command Each record in the output files for these audits or commands identifies a file member that has been compared and indicates whether a difference was detected for that member. The file uses an unsupported data type. • What differences were detected by #FILDTA The Difference Indicator (DIFIND) field identifies the result of the comparison. When viewed from a 5250 emulator. Full reports include both differences and objects that are considered synchronized. Table 83 identifies values for the Compare File Data command that can appear in this field Table 83. *CO *CO (LOB) *DT 548 . Difference reports are the default for these compare commands. You can see the full set of fields in each output file by viewing it from a 5250 emulator. Unable to process selected member containing a large object (LOB). The type of data included in the output file is determined by the report type specified on the compare command. Relative record number reports (RPTTYPE(*RRN)) return the relative record number of the first 1. MIMIX Availability Manager displays only detected differences found by each compare command using a subset of the fields from the output file. Relative record number reports apply only to the Compare File Data command. Unable to process selected member. Full reports (RPTTYPE(*ALL)) return information about all objects and attributes compared. Unable to process selected member. Indicates that a member is held or an inactive state was detected. The file or member is being processed by the Synchronize DG File Entry (SYNCDGFE) command. Unable to complete processing on selected member. The file feature is not supported for comparison. Unable to process selected member. Unable to process selected member. The file member is being processed for repair by another job running the Compare File Data (CMPFILDTA) command.Interpreting results of audits for record counts and file data Table 83. See messages preceding message LVE3D42 in job log. Messages preceding message LVE3D42 in job log may be helpful. or is journaled to the wrong journal. Member excluded from comparison because it was not changed or restored after the timestamp specified for the CHGDATE parameter. Matching entry not found in database apply table. *EQ (DATE) *EQ (OMIT) *FF *FMC *FMT *HLD *IOERR *NE *NF1 *NF2 *REP *SJ *SP *SYNC *UE *UN 549 . No difference was detected. Indicates a difference was detected. Messages preceding LVE0101 may be helpful. Unable to process selected member. Member not found on system 2. Examples of file features include materialized query tables. The source file is not journaled. Either the record length or the null capability is different. Values *EQ Possible values for Compare File Data (CMPFILDTA) output file field Difference Indicator (DIFIND) Description Data matches. No differences were detected within the data compared. Indicates that the member’s synchronization status is unknown. Reason unknown. Member not found on system 1. File formats differ between source and target files. fields with unsupported types were omitted. Global difference indicator. However. The source file is not journaled. The file feature is not supported for comparison. Indicates that the member’s synchronization status is unknown. No difference was detected within the record counts compared. Values *CMT Possible values for Compare Record Count (CMPRCDCNT) output file field Difference Indicator (DIFIND) Description Commit cycle activity on the source system prevents active processing from comparing records or record counts in the selected member. Record counts match. Messages preceding LVE3D42 in job log may be helpful. Lock prevented access to member. Member not found on system 2. Member not found on system 1. Examples of file features include materialized query tables. Global difference indicator. Indicates that a member is held or an inactive state was detected. Indicates a difference was detected. Table 84. Unable to process selected member.What differences were detected by #MBRRCDCNT Table 84 identifies values for the Compare Record Count command that can appear in the Difference Indicator (DIFIND) field. Reason unknown. or is journaled to the wrong journal. *EQ *FF *HLD *LCK *NE *NF1 *NF2 *SJ *UE *UN 550 . The Compare Attribute commands are: Compare File Attributes (CMPFILA). MIMIX Availability Manager displays summary rows in the Summary List window and detail rows in the Details window for the Compare command type. Each row in an output file for a Compare Attributes command can contain either a summary record format or a detailed record format. When comparing authorization lists. Only summary rows for objects that had detected differences are included. Detail rows for all compared attributes are included. For example. You can see the full set of fields in the output file by viewing it from a 5250 emulator. the report will indicate that differences are detected. the CMPOBJA command will first determine if both lists have the same number of entries. Difference reports are the default for the Compare Attributes commands. and Compare DLO Attributes (CMPDLOA). it will then determine whether both lists contain the same entries. Each detail row identifies a specific attribute compared for an object and the comparison results. 551 . so an indicator is returned to conserve space. When viewed from a 5250 emulator. several of the attribute selectors return an indicator (*INDONLY) rather than an actual value. 1. • • For difference and full reports of compare attribute commands. Full reports include both differences and objects that are considered synchronized. Summary reports (RPTTYPE(*SUMMARY)) return only a summary row for each object compared. MIMIX Availability Manager displays only detected differences found by Compare Attributes commands using a subset of the fields from the output file. The type of data included in the output file is determined by the report type specified on the Compare Attributes command. If the same number of entries exist. Full reports (RPTTYPE(*ALL)) return information about all objects and attributes compared. If differences in the number of entries are found or if the entries within the authorization list are not equal. Compare Object Attributes (CMPOBJA). Specific attributes compared are not included.Interpreting results of audits that compare attributes Interpreting results of audits that compare attributes Each audit that compares attributes does so by calling a Compare Attributes1 command and places the results in an output file. but the report only contains an indication of whether it is synchronized. Attributes that return indicators are usually variable in length. the attributes are checked thoroughly. For each object compared there is a summary row as well as a detail row for each attribute compared. Each summary row identifies a compared object and includes a prioritized object-level summary of whether differences were detected. an authorization list can contain a variable number of entries. the data included for each report type is as follows: • Difference reports (RPTTYPE(*DIF)) return information about detected differences. Compare IFS Attributes (CMPIFSA). In these instances. The report will not provide the list of entries—it will only indicate that they are not equal in terms of count or content. The Priority2 column in Table 85 indicates the order of precedence MIMIX uses when determining the prioritized summary value for the compared object. Not all values may be valid for every Compare command. The database apply (DBAPY) will attempt the recovery and send an *ERROR or *INFO notification to indicate the outcome of the recovery attempt. 13 1 Summary Record2 Priority 5 5 5 3 2 5 *RCYFAILED *RECOVERED *SJ 552 . Record counts match. Indicates that recovery for this object was successful. This summary value is also presented along with other object-identifying information at the top of the Details window. the value shown in the Summary List window is a prioritized summary of the status of all attributes checked for the object. Values1 *EC *EQ *NA *NC *NE *NS *RCYSBM Possible values for output file field Difference Indicator (DIFIND) Description The values are based on the MIMIX configuration settings. the summary row is the first record for each compared object and is indicated by an asterisk (*) in the Compared Attribute (CMPATR) field. For each attribute displayed on the Details window. Indicates that MIMIX AutoGuard submitted an automatic audit recovery action that must be processed through the user journal replication processes. detail rows appear below the summary row for the object compared and show the actual result for the attributes compared. The values are not equal based on the MIMIX configuration settings. Unable to process selected member. When the output file is viewed from a 5250 emulator. Indicates differences were detected. No differences were detected. the results of its comparison is shown. The summary row’s Difference Indicator value is the prioritized summary of the status of all attributes checked for the object. Indicates that the attribute is not supported on one of the systems. The actual values may or may not be equal. When included. The actual values may or may not be equal. Table 85 identifies values that can appear in this field.What attribute differences were detected The Difference Indicator (DIFIND) field identifies the result of the comparison. The source file is not journaled. The actual values may or may not be equal. Table 85. Will not cause a global not equal condition. Within MIMIX Availability Manager. The values are not compared. Global difference indicator. Used to indicate that automatic recovery attempts via AutoGuard failed to recover the detected difference. Values1 *SP *UA Possible values for output file field Difference Indicator (DIFIND) Description Unable to process selected member. Summary Record2 Priority 1 2 *UN 1. if the System 1 Indicator is *NOTFOUND and the System 2 Indicator is blank (Object found). Priorities are used to determine the value shown in output files for Compare Attribute commands. when a detailed row contains blanks in either of the System 1 Indicator or System 2 Indicator fields. Indicates that the object’s synchronization status is unknown. MIMIX determines the value of the Difference Indicator field according to Table 86. For example. the difference is seen as unknown due to object activity. Note: The Maximum replication lag prompt is only valid when a data group is specified on the command. For most attributes. 2. Difference Indicator System 1 Indicator Object *NOTCMPD *NOTFOUND *NOTSPT *RTVFAILED *DAMAGED Found (blank value) *NA Object Found *EQ / *EQ (blank value) (LOB) / *NE / *UA / *EC / *NC *NA *NE / *UA *NS *UN *NE *NE *NS *UN *NE System *NOTCMPD *NA 2 Indicator *NOTFOUND *NE / *UA *NOTSPT *NS *NE *EQ *NE *NE *NE *NS *UN *NE *NE *NE *NE *NE *NE / *UA *NE / *UA *NS *UN *NE *UN *UN *NE *RTVFAILED *UN *DAMAGED *NE For a small number of specific attributes. The object was initially found to be *NE or *NC but MIMIX autonomic functions recovered the object. Object status is unknown due to object activity. This status is only displayed in the summary record. the resultant Difference Indicator is *NE. Difference Indicator values that are derived from System Indicator values. The results returned vary according to parameters specified on the compare request and MIMIX configuration values. 3. The value *RECOVERED can only appear in an output file modified by a recovery action.Interpreting results of audits that compare attributes Table 85. If an object difference is found and the comparison has a value specified on the Maximum replication lag prompt. Table 86. See messages preceding message LVE3D42 in job log. For more information see the following topics: • “Comparison results for journal status and other journal attributes” on page 573 553 . 4 Not all values may be possible for every Compare command. the comparison is more complex. Object damaged condition. This value is not used in determining the priority of summary level records. the Data Source (DTASRC) field identifies which system is configured as the source for replication. Object not found. Summary Record1 Priority 5 3 2 N/A2 1 N/A2 *RTVFAILED 1. In MIMIX Availability Manager Details windows. 2. Due to MIMIX configuration settings. For comparisons which include a data group. Reason for failure may be a lock condition. #FILATRMBR audits” on page 556 “Attributes compared and expected results . Not all attributes are supported on all IBM i releases. Attribute not compared. While these fields are available in both summary and detail rows in the output file. What attributes were compared In each detailed row.#FILATR. the Compared Attribute (CMPATR) field identifies a compared attribute. Table 87.#IFSATR audit” on page 569 554 . Attribute not supported. MIMIX Availability Manager only displays them in the Details window. Unable to retrieve the attributes of the object. This is the value that is used to indicate an unsupported attribute has been specified. this attribute cannot be compared. Value <blank> *DAMAGED *MBRNOTFND *NOTCMPD *NOTFOUND *NOTSPT Possible values for output file fields SYS1IND and SYS2IND Description No special conditions exist for this object. 4 The priority indicates the order of precedence MIMIX uses when setting the system indicators fields in the summary record. Table 87 identifies the possible values. the direction of the arrow shown the data group field identifies the flow of replication.#OBJATR audit” on page 561 “Attributes compared and expected results . Member not found. The following topics identify the attributes that can be compared by each command and the possible values returned • • • “Attributes compared and expected results .• • • “Comparison results for auxiliary storage pool ID (*ASP)” on page 577 “Comparison results for user profile status (*USRPRFSTS)” on page 580 “Comparison results for user profile password (*PRFPWDIND)” on page 583 Where was the difference detected The System 1 Indicator (SYS1IND) and System 2 Indicator (SYS2IND) fields show the status of the attribute on each system as determined by the compare request. Interpreting results of audits that compare attributes • “Attributes compared and expected results .#DLOATR audit” on page 571 555 . KL .#FILATR.Arrival sequence access path EV . however. 2-. are file-specific attributes. *ALWRD. *MAX1TB *YES. or 4-byte vector. Most of the attributes supported are for file-level comparisons. authority.Keyed sequence access path with duplicate keys allowed. Duplicate keys are accessed in first-changed-first-out (FCFO) order. KC . *YES. KU . *ALWWRT *YES. For instance. *ALWUPD. database relationships.Attributes compared and expected results . Table 88 lists the attributes that can be compared and the value shown in the Compared Attribute (CMPATR) field in the output file. Duplicate keys are accessed in first-in-first-out (FIFO) order.Encoded vector with a 1-. Examples of filespecific attributes include triggers. *NO Group which checks attributes *ALWDLT. Duplicate keys are accessed in last-in-first-out (LIFO) order KN . Some attributes are common file attributes such as owner.Keyed sequence access path with duplicate keys allowed. Table 88.Keyed sequence access path with no duplicate keys allowed (UNIQUE).Keyed sequence access path with duplicate keys allowed. *NO *MAX4GB. a attribute could be equal (*EC) to the database configuration but not equal (*NC) to the object configuration. #FILATRMBR audits The Compare File Attribute (CMPFILA) command supports comparisons at the file and member level. constraints. KF . The difference Indicator (DIFIND) returned after comparing file attributes may depend on whether the file is defined by file entries or object entries. and creation date. The #FILATR audit and the #FILATRMBR audit each invoke the CMPFILA command for the comparison phase of the audit.Keyed sequence access path with duplicate keys allowed. and journaling information. Attribute *ACCPTH1 Compare File Attributes (CMPFILA) attributes Description Access path Returned Values (SYS1VAL. The Returned Values column lists the values you can expect in the System1 Value (SYS1VAL) and System 2 Value (SYS2VAL) columns as a result of running the comparison. No order is guaranteed when accessing duplicate keys. *NO *ACCPTHVLD2 *ACCPTHSIZ1 *ALWDLT *ALWOPS *ALWRD *ALWUPD Access path valid Access path size Allow delete operation Allow operations Allow read operation Allow update operation 556 . See “What attribute differences were detected” on page 552. SYS2VAL) AR . Most of the attributes. *NO *YES. *NONE. *NBRDLTRCD. list name 33 character name in the format: library/file(member) *AUDVAL *AUT *AUTL *BASEDONPF2 Object audit value File authorities Authority list name Name of based-on physical file member Pre-determined set of basic attributes *BASIC Group which checks a pre-determined set of attributes. *OBJATR. and *TEXT. When *FILE is specified for the Comparison level (CMPLVL). *PGP. *NBRMBR. 1-65535 Group which checks attributes *CSTIND. constraint names. For referential and check constraints. SYS2VAL) *YES. the constraint state as well as whether the constraint status is enabled or disabled is also compared. *TEXT. constraint types. *NO 1-16 (pre-V5R2) 1-255 (V5R2) 1 = System ASP See “Comparison results for auxiliary storage pool ID (*ASP)” on page 577 for details. Attribute *ALWWRT *ASP Compare File Attributes (CMPFILA) attributes Description Allow write operation Auxiliary storage pool ID Returned Values (SYS1VAL. these attributes are compared: *CURRCDS. its Difference Indicator value indicates if the number of constraints. When *MBR is specified for the Comparison level (CMPLVL). *CSTNBR No value. *CHANGE. these attributes are compared: *CST (group). *SHARE. *PUBAUTIND *NONE.Table 88. *RCDFMT. *OBJATR *CCSID1 *CST *CSTIND 3 Coded character set Constraint attributes Constraint equal indicator *CSTNBR 3 *CURRCDS *DBCSCAP *DBR Number of constraints Current number of records DBCS capable 557 . and the check pending attribute are equal. *OBJATR. *EXPDATE. *ALL Group which checks attributes *AUTL. and *TRIGGER (group). Numeric value 0-4294967295 *YES. *NO Group which checks *DBRIND. indicator only5 When this attribute is returned in output. *PRVAUTIND. its Difference Indicator value indicates if the number of database relations and the dependent file names are equal. *BOTH 10 character name. Value 0 is 19nn and 1 is 20nn. *CCSID. 10 character name *NONE if the file has no members. *OWNER. *RCDFMT. *PFSIZE (group). *AUT (group). *DBR (group). *DBRIND 3 *EXPDATE1 *EXTENDED Expiration date for member Pre-determined. *NO *NONE. *YES. *YES. where C equals the century. *SELOMT. extended set *FIRSTMBR1 4 *FRCKEY1 *FRCRATIO1 *INCRCDS1 *JOIN Name of member *FIRST Force keyed access path Records to force a write Increment number of records Join Logical file *JOURNAL Journal attributes *JOURNALED *JRN *JRNIMG *JRNLIB *JRNOMIT *LANGID1 *LASTMBR1 4 File is currently journaled Current or last journal Record images Current or last journal library Journal entries to be omitted Language ID Name of member *LAST 558 . SYS2VAL) No value. *CURRCDS. *NO Add. *MAXRCDL. *JRNIMG. *OBJATR. *JRN. *TEXT. and *TRIGGER (group). blank if never journaled *OPNCLO. *NONE 3 character ID 10 character name *NONE if the file has no members. indicator only5 When this attribute is returned in output. *JRNLIB. *MAXKEYL. *NBRMBR. Differences in these authorities do not result in an *NE condition. blank if never journaled *AFTER. Blank for *NONE or date in CYYMMDD format. update. Attribute Compare File Attributes (CMPFILA) attributes Description Database relations Returned Values (SYS1VAL. *MAXMBRS. *REUSEDLT. *NO 10 character name. Valid only for Comparison level of *FILE. *SQLTYP. and delete authorities are not checked. *CST (group). 1-32767 0-32767 *YES. The following attributes are compared: *ACCPTH. *JRNOMIT. this group compares the basic set of attributes (*BASIC) plus an extended set of attributes. Group which checks *JOURNALED. Results are described in “Comparison results for journal status and other journal attributes” on page 573.Table 88. 1-32767 *NONE. *AFTIPL. *INCRCDS. 1-32 *IPL. *NBRRCDS *NONE. *REBLD.Table 88. *NO *IMMED. 1-2147483646 8 character user-defined value User profile name Group which checks *CURRCDS. No value. indicator only5 When this attribute is returned in output. Attribute *LVLCHK1 *MAINT1 *MAXINC1 Compare File Attributes (CMPFILA) attributes Description Record format level check Access path maintenance Maximum increments Maximum key length Maximum members Max % deleted records allowed Maximum record length Current number of deleted records Number of members Initial number of records Object control level File owner File size attributes Primary group Private authority indicator Returned Values (SYS1VAL. *MAXINC. *DLY 0-32767 1-2000 *NOMAX. its Difference Indicator value indicates if the number of private authorities and private authority values are equal. *NO *YES. *NBRDLTRCD. SYS2VAL) *YES. its Difference Indicator value indicates if public authority values are equal. 1-100 1-32766 0-4294967295 0-32767 *NOMAX. user profile name No value. indicator only5 When this attribute is returned in output. *NO *MAXKEYL1 *MAXMBRS1 *MAXPCT1 *MAXRCDL1 *NBRDLTRCD1 *NBRMBR1 *NBRRCDS1 *OBJCTLLVL1 *OWNER *PFSIZE *PGP *PRVAUTIND *PUBAUTIND Public authority indicator Number of record formats Access path recovery Reuse deleted records *RCDFMT *RECOVER1 *REUSEDLT1 559 . its Difference Indicator value indicates if a trigger program exists on the system. 3. *NO *YES. SYS2VAL) *YES. and trigger condition with an event type of ‘update’ are equal. *NOMAX. Differences detected for this attribute are marked as *EC (equal configuration) when the compare request specified a data group and the file is configured for system journal replication with a configured Omit content (OMTDTA) value of *FILE. *TRGXSTIND Trigger equal indicator No value. 2. This attribute is only compared for logical file members by the #FILATRMBR audit. its Difference Indicator value indicates whether it is enabled or disabled. 560 . TABLE. trigger names. *CLS. Numeric value No value. *TRGNBR. 4. If *PRINT is specified in the comparison. When the group attribute is checked. indicator only5 When this attribute is returned in output. 1-32767 *TRIGGER *TRGIND 3 *TRGNBR 3 *TRGXSTIND 3 Number of triggers Trigger existence indicator User-defined attribute Maximum file wait time Maximum record wait time *USRATR *WAITFILE1 *WAITRCD1 1. 5. LF Types . this value may appear in the output.NONE.Table 88. Differences detected for this attribute are marked as *EC (equal configuration) when the compare request specified a data group and the object is configured for system journal replication with a configured object auditing value of *NONE. If *OUTFILE is specified. an indicator appears in the system 1 and system 2 columns. trigger time. trigger event. these values are blank. 1-32767 *IMMED. This attribute cannot be specified as input for comparing but it is included in a group attribute. *NO PF Types . however. Attribute *SELOMT *SHARE1 *SQLTYP *TEXT1 Compare File Attributes (CMPFILA) attributes Description Select / omit file Share open data path SQL file type Text description Returned Values (SYS1VAL. 10 character user-defined value *IMMED.INDEX. and if the number of triggers. NONE 50 character value Group which checks *TRGIND. indicator only5 When this attribute is returned in output. VIEW. *INFSTS. *DOMAIN. *PUBAUTIND *OWNER. Valid for subsystem descriptions only. Valid for subsystem descriptions only. 1 = System ASP See “Comparison results for auxiliary storage pool ID (*ASP)” on page 577 for details. *OBJATR. *ASSIST. user profiles. Valid for job queues only. *CHANGE. Attention key handling program Valid for user profiles only. *ALL Group which checks *AUTL. 1-16 (pre-V5R1) 1-32 (V5R1) 1-255 (V5R2). its Difference Indicator value indicates if the number of auto start job entries. Table 89 lists the attributes that can be compared by the CMPOBJA command and the value shown in the Compared Attribute (CMPATR) field in the output file. and library entry values are equal. such as subsystem descriptions.#OBJATR audit The #OBJATR audit calls the Compare Object Attributes (CMPOBJA) command and places the results in an output file. Numeric value *ASP Auxiliary storage pool ID *ASPNBR Number of defined storage pools. attention program name *AUDVAL *AUT *AUTCHK2 *AUTL *BASIC *NONE. The Returned Values column lists the values you can expect in the System1 Value (SYS1VAL) and System 2 Value (SYS2VAL) columns as a result of running the compare. Attribute *ACCPTHSIZ1 2 *AJEIND Compare Object Attributes (CMPOBJA) attributes Description Access path size Valid for logical files only.Attributes compared and expected results . Auto start job entries. The command supports attributes that are common among most library-based objects as well as extended attributes which are unique to specific object types. 561 . job entry and associated job description. indicator only3 When this attribute is returned in output. *TEXT. Authority list name Pre-determined set of basic attributes *ATTNPGM2 *SYSVAL. *PRVAUTIND. *USRPRF. Table 89. and data areas. list name Group which checks a pre-determined set of attributes. SYS2VAL) *MAX4GB and *MAX1TB No value. *PGP. and *USRATR. *DTAAUT *NONE. Returned Values (SYS1VAL. Object audit value Authority attributes Authority to check. *NONE. These attributes are compared: *CRTTSP. ccsid-value *CNTRYID2 *SYSVAL. *ALL. *SYSVAL. communication device. *LENGTH. *SYSVAL. communication mode. Communications entries Valid for subsystem descriptions only. Attribute *CCSID2 Compare Object Attributes (CMPOBJA) attributes Description Character identifier control.SS. *EXCLUDE. Object creation date Current library Valid for user profiles only.MM. Valid for libraries only. *EXCLUDE *CRTAUT2 Authority given to users who do not have specific authority to the object. *GRPPRF. Data cyclic redundancy check (CRC) Valid for data queues only. Profile that owns objects created by user Valid for user profiles only. its Difference Indicator value indicates if the number of communication entries. current-library *DATACRC2 10 character value *DDMCNV2 *KEEP. *TYPE.mmmmmm *CRTDFT. *NONE. *VALUE 562 . Object Domain Data area extended attributes *CRTOBJAUD2 *SYSVAL. Returned Values (SYS1VAL. *CHANGE. *CHANGE. Valid for user profiles only. maximum number of active jobs. *USRPRF. SYS2VAL) *SYSVAL.Table 89. *USE. associated job description and library. *ALL *CRTOBJOWN *USRPRF. *ALL. Country ID Valid for user profiles only. *CHANGE. *DROP *DECPOS *DOMAIN *DTAARAEXT 0-9 *SYSTEM. Decimal positions Valid for data areas only. *USER Group which checks *DECPOS. DDM conversation Valid for job descriptions only. country-id *COMMEIND No value. Auditing value for objects created in this library Valid for libraries only. profile-name *CRTTSP *CURLIB YYYY-MM-DD-HH. *USE. and the default user entry values are equal. indicator only3 When this attribute is returned in output. *LIBL. *ALL. indicator only3 When this attribute is returned in output. *PRTDEV 10 character name *INLMNU Initial menu Valid for user profiles only. Attribute Compare Object Attributes (CMPOBJA) attributes Description Pre-determined. The following attributes are compared: *AUT.Table 89. Initial program Valid for user profiles only. Information status *GRPAUT *NONE. *RTVFAILED (No information returned .32. *OUTQ. *EXCLUDE *GRPAUTTYP *PGP. 1 . Group authority to created objects Valid for user profiles only. library name Group which checks *DDMCNV. profile-name *INFSTS *OK (No errors occurred). *INLPGM *JOBDEXT *JOBQ2 *JOBQEIND No value. Job queue entries Valid for subsystem descriptions only. Group profile ID number Valid for user profiles only. *TEXT. *INFSTS. job queue names.*LIBL. its Difference Indicator value indicates if the number of job queue entries. *LIBLIND. *CRTTSP. *OBJATR. Menu . *LOGOUTPUT. SYS2VAL) Group which compares the basic set of attributes (*BASIC) plus an extended set of attributes. and order of entries are the same 563 .*SIGNOFF.767 1 . *CHANGE. *JOBQPRI. menu name Library . Group profile name Valid for user profiles only. *OUTQPRI.4294967294 *EXTENDED *FRCRATIO1 2 *GID Records to force a write Valid for logical files only. and *USRATR. extended set Returned Values (SYS1VAL. *DOMAIN.insufficient authority or object is locked).*NONE. *PRIVATE *GRPPRF *NONE. Job description extended attributes Job queue Valid for job descriptions only. *DAMAGED (Object is damaged or partially damaged). library name Program . *JOBQLIB. *USE. *OUTQLIB. job queue libraries. program name Library . *NONE. *JOBQ. Group authority type Valid for user profiles only. Job queue priority Valid for job descriptions only. *LENGTH *LIBEXT *LIBLIND 1-2000 (character). Attribute Compare Object Attributes (CMPOBJA) attributes Description Job queue extended attributes Job queue library Valid for job descriptions only. 1-24 (decimal). 564 . *NO 10 character name *AFTER. *JRNOMIT4.9 (lowest) *JOBQSBS2 Subsystem name *JOBQSTS2 *JOURNAL HELD. *JRNIMG. 1 (logical) Group which checks *CRTAUT. SYS2VAL) Group which checks *AUTCHK. *BOTH 10 character name *OPNCLO. Results are described in “Comparison results for journal status and other journal attributes” on page 573. Data area length Valid for data areas only Extended library information attributes Initial library list Valid for job descriptions only.Table 89. *JOBQSTS. *NONE *SYSVAL. *YES. Subsystem that receives jobs from this queue Valid for job queues only. Journal attributes Returned Values (SYS1VAL. RELEASED Group which checks *JOURNALED. *JRN. *JRNLIB. *JOBQSBS. *OPRCTL 10 character name *JOBQEXT *JOBQLIB2 *JOBQPRI2 1 (highest) . its Difference Indicator value indicates if the number of library list entries and entry list values are equal. indicator only3 When this attribute is returned in output. *CRTOBJAUD No value. language-id *JOURNALED *JRN *JRNIMG *JRNLIB *JRNOMIT *LANGID2 Object is currently journaled Current or last journal Record images Current or last journal library Journal entries to be omitted Language ID Valid for user profiles only. The comparison is order dependent. Job queue status Valid for job queues only. 1 . output queue name *OUTQLIB2 10 character name *OUTQPRI2 1 (highest) . *NOMAX (32. Message queue Valid for user profiles only. *NO *MAINT1 2 *DLY. *WRKSTN.767 *NBRMBR1 2 *OBJATR *OBJCTLLVL2 10 character object extended attribute 8 character user-defined value *OPRCTL2 *OUTQ2 *YES. Record format level check Valid for logical files only. Maximum members Valid for logical files only.Table 89. Operator controlled Valid for job queues only. Output queue library Valid for job descriptions only. Attribute *LMTCPB Compare Object Attributes (CMPOBJA) attributes Description Limit capabilities Valid for user profiles only. Object attribute Object control level Valid for object types that support this attribute5. Output queue priority Valid for job descriptions only. *JOBEND. Returned Values (SYS1VAL. *IMMED. Job log output Valid for job descriptions only. Maximum active jobs Valid for subsystem descriptions only. Number of logical file members Valid for logical files only. *PND *LVLCHK1 2 *YES. Output queue Valid for job descriptions only. *NO *USRPRF. *YES. *JOBLOGSVR.32.message queue name Library . library name 0 . *REBLD *MAXACT 2 Numeric value. *DEV.*LIBL. *NO *LOGOUTPUT2 *SYSVAL.767 Message queue .9 (lowest) 565 . Access path maintenance Valid for logical files only. SYS2VAL) *PARTIAL.32.767) *MAXMBRS1 2 *MSGQ2 *NOMAX. SYS2VAL) 10 character name *NONE. wait for job. printer device name *PRVAUTIND No value. Job queue allocation indicator Valid for subsystem descriptions only. its Difference Indicator value indicates if the number of private authorities and private authority values are equal No value. maximum users. *NOMAX. Attribute *OWNER *PGP Compare Object Attributes (CMPOBJA) attributes Description Object owner Primary group Pre-start job entries Valid for subsystem descriptions only. *WRKSTN. No password indicator Valid for user profiles only. *SYSVAL. User profile password indicator Printer device Valid for job descriptions only. job name. *PWDIND *YES (no password). 1-366 days *PUBAUTIND Public authority indicator *PWDEXPITV Password expiration interval Valid for user profiles only. its Difference Indicator value indicates if the job queue entries for a subsystem are in the same order and have the same queue names and queue library names. user profile. indicator only3 When this attribute is returned in output. its Difference Indicator value indicates if the public authority values are equal. maximum jobs. Returned Values (SYS1VAL. Private authority indicator *PRFPWDIND *PRTDEV2 See “Comparison results for user profile password (*PRFPWDIND)” on page 583 for details. indicator only3 When this attribute is returned in output. program. indicator only3 When this attribute is returned in output.Table 89. indicator only1 When this attribute is returned in output. It also compares the allocation indicator values 566 . job description. first and second class. threshold. additional jobs. start job. *DEV *PRESTIND *PRFOUTQ2 Output queue Valid for user profiles only. and number of first and second class jobs values are equal. user profile name No value. *NO (password) *QUEALCIND No value. initial jobs. *USRPRF. *SYSVAL. *LIBL/*WRKSTN. its Difference Indicator value indicates if the number of prestart jobs. Table 89. Attribute Compare Object Attributes (CMPOBJA) attributes Description Remote location entries Valid for subsystem descriptions only. Returned Values (SYS1VAL, SYS2VAL) No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the number of remote location entries, remote location, mode, job description and library, maximum active jabs, and default user entry values are equal. No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the number of routing entries, sequence number, maximum active, steps, compare start, entry program, class, and compare entry values are equal Group which checks *AJEIND, *ASPNBR, *COMMEIND, *JOBQEIND, *MAXACT, *PRESTIND, *RLOCIND, *RTGEIND, *SBSDSTS *ACTIVE, *INACTIVE *RLOCIND *RTGEIND Routing entries Valid for subsystem descriptions only. *SBSDEXT Subsystem description extended attributes Subsystem status Valid for subsystem descriptions only. Object size Special authorities Valid for user profiles only. SQL stored procedures Valid for programs and service programs only. *SBSDSTS2 *SIZE *SPCAUTIND Numeric value No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if special authority values are equal *NONE, or indicator only3 *NONE is returned when there are no stored procedures associated with the program or service program. When the indicator only is returned in output, the Difference Indicator value identifies whether SQL stored procedures associated with the object are equal. *NONE, or indicator only3 *NONE is returned when there are no user defined functions associated with the program or service program. When the indicator only is returned in output, the Difference Indicator value identifies whether SQL user defined functions associated with the object are equal. No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if supplemental group values are equal 50 character description *SQLSP *SQLUDF SQL user defined functions Valid for programs and service programs only. *SUPGRPIND Supplemental Groups Valid for user profiles only. Text description *TEXT2 567 Table 89. Attribute *TYPE Compare Object Attributes (CMPOBJA) attributes Description Data area type - data area types of DDM resolved to actual data area types Valid for data areas only. User profile ID number Valid for user profiles only. User-defined attribute User Class Valid for user profiles only. User profile extended attributes Returned Values (SYS1VAL, SYS2VAL) *CHAR, *DEC, *LGL *UID 1 - 4294967294 *USRATR2 *USRCLS 10 character user-defined value *SECOFR, *SECADM, *PGMR, *SYSOPR, *USER *USRPRFEXT Group which checks *ATTNPGM, *CCSID, *CNTRYID, *CRTOBJOWN, *CURLIB, *GID, *GRPAUT, *GRPAUTTYP, *GRPPRF, *INLMNU, *INLPGM, *LANGID, *LMTCPB, *MSGQ, *PRFOUTQ, *PWDEXPITV, *PWDIND, *SPCAUTIND, *SUPGRPIND, *USRCLS *ENABLED, *DISABLED6 For details, see “Comparison results for user profile status (*USRPRFSTS)” on page 580. Character value of data *USRPRFSTS User profile status *VALUE2 1. 2. 3. 4. 5. 6. Data area value Valid for data areas only. This attribute only applies to logical files. Use the Compare File Attributes (CMPFILA) command to compare or omit physical file attributes. Differences detected for this attribute are marked as *EC (equal configuration) when the compare request specified a data group and the object is configured for system journal replication with a configured object auditing value of *NONE. If *PRINT is specified for the output format on the compare request, an indicator appears in the System 1 and System 2 columns. If *OUTFILE is specified, these values are blank. These attributes are compared for object types of *FILE, *DTAQ, and *DTAARA. These are the only objects supported by IBM's user journals. The *OBJCTLLVL attribute is only supported on the following object types: *AUTL, *CNNL, *COSD, *CTLD, *DEVD, *DTAARA, *DTAQ, *FILE, *IPXD, *LIB, *LIND, *MODD, *NTBD, *NWID, *NWSD, and *USRPRF. The profile status is only compared if no data group is specified or the USRPRFSTS has a value of *SRC for the specified data group. If a data group is specified on the CMPOBJA command and the USRPRFSTS value on the object entry has a value of *TGT, *ENABLED, or *DISABLED, the user profile status is not compared. 568 Attributes compared and expected results - #IFSATR audit The #IFSATR audit calls the Compare IFS Attributes (CMPIFSA) command and places the results in an output file. Table 90 lists the attributes that can be compared by the CMPIFSA command and the value shown in the Compared Attribute (CMPATR) field in the output file. The Returned Values column lists the values you can expect in the System1 Value (SYS1VAL) and System 2 Value (SYS2VAL) columns as a result of running the compare. Table 90. Attribute *ALWSAV1 *ASP Compare IFS Attributes (CMPIFSA) attributes Description Allow save Auxiliary storage pool Returned Values (SYS1VAL, SYS2VAL) *YES, *NO 1-16 (pre-V5R1) 1-255 (V5R1) 1-System ASP See “Comparison results for auxiliary storage pool ID (*ASP)” on page 577 for details. *ALL, *CHANGE, *NONE, *USRPRF Group which checks attributes *AUTL, *PGP, *PUBAUTIND, *PRVAUTIND *NONE, list name Group which checks a pre-determined set of attributes. The following set of attributes are compared: *CCSID, *DATASIZE, *OBJTYPE, and the group *PCATTR. 1-65535 SAA format (YY-MM-DD-HH.MM.SS.mmmmmm) 8 character value 0-4294967295 Group which checks a pre-determined set of attributes. Compares the basic set of attributes (*BASIC) plus an extended set of attributes. The following attributes are compared: *AUT (group), *CCSID, *DATASIZE, *OBJTYPE, *OWNER, and *PCATTR (group). Groups which checks attributes *JOURNALED, *JRN, *JRNLIB, *JRNIMG, *JRNOPT. Results are described in “Comparison results for journal status and other journal attributes” on page 573. *YES, *NO 10 character name *AFTER, *BOTH *AUDVAL *AUT *AUTL *BASIC Object auditing value Authority attributes Authority list name Pre-determined set of basic attributes Coded character set Create timestamp Data cyclic redundancy check (CRC) Data size Pre-determined, extended set *CCSID1 *CRTTSP2 *DATACRC3 *DATASIZE1 *EXTENDED *JOURNAL Journal information *JOURNALED *JRN *JRNIMG File is currently journaled Current or last journal Record images 569 Table 90. Attribute *JRNLIB *JRNOPT Compare IFS Attributes (CMPIFSA) attributes Description Current or last journal library Journal optional entries Object type File owner Archived file PC Attributes Hidden file Read only attribute System file Primary group Private authority indicator Returned Values (SYS1VAL, SYS2VAL) 10 character name *YES, *NO *STMF, *DIR, *SYMLNK 10 character name *YES, *NO Group which checks *PCARCHIVE, *PCHIDDEN, *PCREADO, *PCSYSTEM *YES, *NO *YES, *NO *YES, *NO *NONE, user profile name No value, indicator only4 When this attribute is returned in output, its Difference Indicator value indicates if the number of private authorities and private authority values are equal. No value, indicator only4 When this attribute is returned in output, its Difference Indicator value indicates if the public authority values are equal. *OBJTYPE *OWNER *PCARCHIVE1 *PCATTR *PCHIDDEN1 *PCREADO1 *PCSYSTEM1 *PGP *PRVAUTIND *PUBAUTIND Public authority indicator 1. 2. 3. 4. Differences detected for this attribute are marked as *EC (equal configuration) when the compare request specified a data group and the object is configured for system journal replication with a configured object auditing value of *NONE. The *CRTTSP attribute does not compare directories (*DIR) or symbolic links (*SYMLNK). For stream files (*STMF), the #IFSATR audit omits the *CRTTSP attribute from comparison since creation timestamps are not preserved during replication. Running the CMPIFSA command will detect differences in the creation timestamps for stream files. When a stream file has Storage Freed *YES on either the source system or target system, the status of this attribute is reflected as not supported (*NS) and the data has not been compared. If *PRINT is specified in the comparison, an indicator appears in the system 1 and system 2 columns. If *OUTFILE is specified, these values are blank. 570 Attributes compared and expected results - #DLOATR audit The #DLOATR audit calls the Compare DLO Attributes (CMPDLOA) command and places the results in an output file. Table 91 lists the attributes that can be compared by the CMPDLOA command and the value shown in the Compared Attribute (CMPATR) field in the output file. The Returned Values column lists the values you can expect in the System1 Value (SYS1VAL) and System 2 Value (SYS2VAL) columns as a result of running the compare. Table 91. Attribute *ASP Compare DLO Attributes (CMPDLOA) attributes Description Auxiliary storage pool Returned Values (SYS1VAL, SYS2VAL) 1-16 (pre-V5R1) 1-32 (V5R1) 1 = System ASP See “Comparison results for auxiliary storage pool ID (*ASP)” on page 577 for details. *NONE, *USRPRF, *CHANGE, *ALL Group which checks *AUTL, *PGP, *PUBAUTIND, *PRVAUTIND *NONE, list name Group which checks a pre-determined set of attributes. The following set of attributes are compared: *CCSID, *DATASIZE, *OBJTYPE, *PCATTR, and *TEXT. 1-65535 SAA format (YY-MM-DD-HH.MM.SS.mmmmmm) 0-42949672951 Group which checks a pre-determined set of attributes. Compares the basic set of attributes (*BASIC) plus an extended set of attributes. The following attributes are compared *AUT, *CCSID, *DATASIZE, *OBJTYPE, *OWNER, *PCATTR, and *TEXT. SAA format (YY-MM-DD-HH.MM.SS.mmmmmm) *DOC, *FLR2 10 character name *YES, *NO Group which checks *PCARCHIVE, *PCHIDDEN, *PCREADO, *PCSYSTEM *YES, *NO *YES, *NO *AUDVAL *AUT *AUTL *BASIC Object audit value Authority attributes Authority list name Pre-determined set of basic attributes *CCSID *CRTTSP *DATASIZE *EXTENDED Coded character set Create timestamp Data size Pre-determined, extended set *MODTSP *OBJTYPE *OWNER *PCARCHIVE *PCATTR *PCHIDDEN *PCREADO Modify timestamp Object type File owner Archived file PC Attributes Hidden file Read only attribute 571 Table 91. Attribute Compare DLO Attributes (CMPDLOA) attributes Description System file Primary group Private authority indicator Returned Values (SYS1VAL, SYS2VAL) *YES, *NO *NONE, user profile name No value, indicator only3 When this attribute is returned in output, its Difference Indicator value if the number of private authorities and private authority values are equal No value, indicator only1 When this attribute is returned in output, its Difference Indicator value if the public authority values are equal 50 character description *PCSYSTEM *PGP *PRVAUTIND *PUBAUTIND Public authority indicator *TEXT 1. 2. 3. Text description This attribute is not supported for DLOs with an object type of *FLR. This attribute is always compared. If *PRINT is specified in the comparison, an indicator appears in the system 1 and system 2 columns. If *OUTFILE is specified, these values are blank. 572 Comparison results for journal status and other journal attributes The Compare File Attributes (CMPFILA), Compare Object Attributes (CMPOBJA), and Compare IFS Attributes (CMPIFSA) commands support comparing the journaling attributes listed in Table 92 for objects replicated from the user journal. These commands function similarly when comparing journaling attributes. When a compare is requested, MIMIX determines the result displayed in the Differences Indicator field by considering whether the file is journaled, whether the request includes a data group, and the data group’s configured settings for journaling. Regardless of which journaling attribute is specified on the command, MIMIX always checks the journaling status first (*JOURNALED attribute). If the file or object is journaled on both systems, MIMIX then considers whether the command specified a data group definition before comparing any other requested attribute. Table 92. Journaling attributes When specified on the CMPOBJA command, these values apply only to files, data areas, or data queues. When specified on the CMPFILA command, these values apply only to PF-DTA and PF38-DTA files. *JOURNAL *JOURNALED Object journal information attributes. This value acts as a group selection, causing all other journaling attributes to be selected Journal Status. Indicates whether the object is currently being journaled. This attribute is always compared when any of the other journaling attributes are selected. Journal. Indicates the name of the current or last journal. If blank, the object has never been journaled. Journal Image. Indicates the kinds of images that are written to the journal receiver for changes to objects. Journal Library. Identifies the library that contains the journal. If blank, the object has never been journaled. Journal Omit. Indicates whether file open and close journal entries are omitted. *JRN 1 *JRNIMG 1 2 *JRNLIB 1 *JRNOMIT 1 1. 2. When these values are specified on a Compare command, the journal status (*JOURNALED) attribute is always evaluated first. The result of the journal status comparison determines whether the command will compare the specified attribute. Although *JRNIMG can be specified on the CMPIFSA command, it is not compared even when the journal status is as expected. The journal image status is reflected as not supported (*NS) because the operating system only supports after (*AFTER) images. Compares that do not specify a data group - When no data group is specified on the compare request, MIMIX compares the journaled status (*JOURNALED attribute). Table 93 shows the result displayed in the Differences Indicator field. If the file or 573 object is not journaled on both systems, the compare ends. If both source and target systems are journaled, MIMIX then compares any other specified journaling attribute. Table 93. Difference indicator values for *JOURNALED attribute when no data group is specified Difference Indicator Target Journal Status 1 Yes Source No *NOTFOUND 1. Yes *EQ *NE *NE No *NE *EQ *NE *NOTFOUND *NE *NE *UN The returned values for journal status found on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field. Compares that specify a data group - When a data group is specified on the compare request, MIMIX compares the journaled status (*JOURNALED attribute) to the configuration values. If both source and target systems are journaled according to the expected configuration settings, then MIMIX compares any other specified journaling attribute against the configuration settings. The Compare commands vary slightly in which configuration settings are checked. • For CMPFILA requests, if the journaled status is as configured, any other specified journal attributes are compared. Possible results from comparing the *JOURNALED attribute are shown in Table 94. For CMPOBJA and CMPIFSA requests, if the journaled status is as configured and the configuration specifies *YES for Cooperate with database (COOPDB), then any other specified journal attributes are compared. Possible results from comparing the *JOURNALED attribute are shown in Table 94 and Table 95. If the configuration specifies COOPDB(*NO), only the journaled status is compared; possible results are shown in Table 96. • Table 94, Table 95, and Table 96 show results for the *JOURNALED attribute that can appear in the Difference Indicator field when the compare request specified a data group and considered the configuration settings. 574 Table 94 shows results when the configured settings for Journal on target and Cooperate with database are both *YES. Table 94. Difference indicator values for *JOURNALED attribute when a data group is specified and the configuration specifies *YES for JRNTGT and COOPDB Difference Indicator Target Journal Status 1 Yes Source No *NOTFOUND 1. Yes *EC *NC *NE No *EC *NC *NE *NOTFOUND *NE *NE *UN The returned values for journal status found on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field. Table 95 shows results when the configured settings are *NO for Journal on target and *YES for Cooperate with database. . Table 95. Difference indicator values for *JOURNALED attribute when a data group is specified and the configuration specifies *NO for JRNTGT and *YES for COOPDB. Difference Indicator Target Journal Status 1 Yes Source No *NOTFOUND 1. Yes *NC *NC *NE No *EC *NC *NE *NOTFOUND *NE *NE *UN The returned values for journal status found on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field. Table 96 shows results when the configured setting for Cooperate with database is *NO. In this scenario, you may want to investigate further. Even though the Difference Indicator shows values marked as configured (*EC), the object can be not journaled 575 on one or both systems. The actual journal status values are returned in the System 1 Value (SYS1VAL) and System 2 Value (SYS2VAL) fields. Table 96. Difference indicator values for *JOURNALED attribute when a data group is specified and the configuration specifies *NO for COOPDB. Difference Indicator Target Journal Status 1 Yes Source No *NOTFOUND 1. Yes *EC *EC *NE No *EC *EC *NE *NOTFOUND *NE *NE *UN The returned values for journal status found on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field. How configured journaling settings are determined When a data group is specified on a compare request, MIMIX also considers configuration settings when comparing journaling attributes. For comparison purposes, MIMIX assumes that the source system is journaled and that the target system is journaled according to configuration settings. Depending on the command used, there are slight differences in what configuration settings are checked. The CMPFILA, CMPOBJA, and CMPIFSA commands retrieve the following configurable journaling attributes from the data group definition: • The Journal on target (JRNTGT) parameter identifies whether activity replicated through the user journal is journaled on the target system. The default value is *YES. The System 1 journal definition (JRNDFN1) and System 2 journal definition (JRNDFN2) values are retrieved and used to determine the source journal, source journal library, target journal, and target journal library. Values for elements Journal image and Omit open/close entries specified in the File entry options (FEOPT) parameter are retrieved. The default values are *AFTER and *YES, respectively. • • Because the data group’s values for Journal image and Omit open/close entries can be overridden by a data group file entry or a data group object entry, the CMPFILA and CMPOBJA commands also retrieve these values from the entries. The values determined after the order of precedence is resolved, sometimes called the overall MIMIX configuration values, are used for the compare. For CMPOBJA and CMPIFSA requests, the value of the Cooperate with database (COOPDB) parameter is retrieved from the data group object entry or data group IFS entry. The default value in object entries is *YES, while the default value in IFS entries is *NO. 576 Comparison results for auxiliary storage pool ID (*ASP) The Compare File Attributes (CMPFILA), Compare Object Attributes (CMPOBJA), Compare IFS Attributes (CMPIFSA), and Compare DLO Attributes (CMPDLOA) commands support comparing the auxiliary storage pool (*ASP) attribute for objects replicated from the user journal. These commands function similarly. When a compare is requested, MIMIX determines the result displayed in the Differences Indicator field by considering whether a data group was specified on the compare request. Compares that do not specify a data group - When no data group is specified on the compare request, MIMIX compares the *ASP attribute for all files or objects that match the selection criteria specified in the request. The result displayed in the Differences Indicator field. Table 97 shows the possible results in the Difference Indicator field. Table 97. Difference Indicator values when no data group is specified Difference Indicator Target ASP Values 1 ASP1 Source ASP2 *NOTFOUND 1. ASP1 *EQ *NE *NE ASP2 *NE *EQ *NE *NOTFOUND *NE *NE *EQ The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field. Compares that specify a data group - When a data group is specified on the compare request (CMPFILA, CMPDLOA, CMPIFSA commands), MIMIX does not compare the *ASP attribute. When a data group is specified on a CMPOBJA request which specifies an object type except libraries (*LIB), MIMIX does not compare the *ASP attribute. Table 98 shows the possible results in the Difference Indicator field Table 98. Difference Indicator values for non-library objects when the request specified a data group Difference Indicator Target ASP Values 1 ASP1 Source ASP2 *NOTFOUND 1. ASP1 *NOTCMPD *NOTCMPD *NE ASP2 *NOTCMPD *NOTCMPD *NE *NOTFOUND *NE *NE *EQ The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field. 577 For CMPOBJA requests which specify a a data group and an object type of *LIB, MIMIX considers configuration settings for the library. Values for the System 1 library ASP number (LIB1ASP), System 1 library ASP device (LIB1ASPD), System 2 library ASP number (LIB2ASP), and System 2 library ASP device (LIB2ASPD) are retrieved from the data group object entry and used in the comparison. Table 99, Table 100, and Table 101 show the possible results in the Difference Indicator field. Note: For Table 99, Table 100, and Table 101, the results are the same even if the system roles are switched. Table 99 shows the expected values for the ASP attribute when the request specifies a data group and the configuration specifies *SRCLIB for the System 1 library ASP number and the data source is system 2. . Table 99. Difference Indicator values for libraries when a data group is specified and configured values are LIB1ASP(*SRCLIB) and DTASRC(*SYS2). Difference Indicator Target ASP Values 1 ASP1 Source ASP2 *NOTFOUND 1. ASP1 *EC *NC *NE ASP2 *NC *EC *NE *NOTFOUND *NE *NE *EQ The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field. Table 100 shows the expected values for the ASP attribute the request specifies a data group and the configuration specifies 1 for the System 1 library ASP number and the data source is system 2. Table 100. Difference Indicator values for libraries when a data group is specified and configured values are LIB1ASP(1) and DTASRC(*SYS2) Difference Indicator Target ASP Values 1 Source 2 *NOTFOUND 1. 1 1 *EC *EC *NE 2 *NC *NC *NE *NOTFOUND *NE *NE *EQ The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field. Table 101 shows the expected values for the ASP attribute when the request specifies a data group and the configuration specifies *ASPDEV for the System 1 library ASP 578 number, DEVNAME is specified for the System 1 library ASP device, and data source is system 2. . Table 101. Difference Indicator values for libraries when a data group is specified and configured values are LIB1ASP(*ASPDEV), LIB1ASPD(DEVNAME) and DTASRC(*SYS2) Difference Indicator Target ASP Values 1 1 Source 2 *NOTFOUND 1. DEVNAME *EC *EC *NE 2 *NC *NC *NE *NOTFOUND *NE *NE *EQ The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field. 579 Comparison results for user profile status (*USRPRFSTS) When comparing the attribute *USRPRFSTS (user profile status) with the Compare Object Attributes (CMPOBJA) command, MIMIX determines the result displayed in the Differences Indicator field by considering the following: • • • The status values of the object on both the source and target systems Configured values for replicating user profile status, at the data group and object entry levels The value of the Data group definition (DGDFN) parameter specified on the CMPOBJA command. Compares that do not specify a data group - When the CMPOBJA command does not specify a data group, MIMIX compares the status values between source and target systems. The result is displayed in the Differences Indicator field, according to Table 85 in “Interpreting results of audits that compare attributes” on page 551. Compares that specify a data group - When the CMPOBJA command specifies a data group, MIMIX checks the configuration settings and the values on one or both systems. (For additional information, see “How configured user profile status is determined” on page 581.) When the configured value is *SRC, the CMPOBJA command compares the values on both systems. The user profile status on the target system must be the same as the status on the source system, otherwise an error condition is reported. Table 102 shows the possible values. Table 102. Difference Indicator values when configured user profile status is *SRC Difference Indicator Target User profile status *ENABLED Source *DISABLED *NOTFOUND *ENABLED *EC *NC *NE *DISABLED *NC *EC *NE *NOTFOUND *NE *NE *UN When the configured value is *ENABLED or *DISABLED, the CMPOBJA command checks the target system value against the configured value. If the user profile status on the target system does not match the configured value, an error condition is reported. The source system user profile status is not relevant. Table 103 and Table 580 respectively. the CMPOBJA command does not compare the values because the result is indeterminate. Difference Indicator values when configured user profile status is *ENABLED Difference Indicator Target User profile status *ENABLED Source *DISABLED *NOTFOUND *ENABLED *EC *EC *NE *DISABLED *NC *NC *NE *NOTFOUND *NE *NE *UN Table 104. Table 103. Table 105. Any differences in user profile status between systems are not reported. Table 105 shows possible values.104 show the possible values when configured values are *ENABLED or *DISABLED. Difference Indicator values when configured user profile status *TGT Difference Indicator Target User profile status *ENABLED Source *DISABLED *NOTFOUND *ENABLED *NA *NA *NE *DISABLED *NA *NA *NE *NOTFOUND *NE *NE *UN How configured user profile status is determined The data group definition determines the behavior for replicating user profile status unless it is explicitly overridden by a non-default value in a data group object entry. The value determined after the order of precedence is resolved is sometimes called the overall MIMIX configuration value. Difference Indicator values when configured user profile status is *DISABLED Difference Indicator Target User profile status *ENABLED Source *DISABLED *NOTFOUND *ENABLED *NC *NC *NE *DISABLED *EC *EC *NE *NOTFOUND *NE *NE *UN When the configured value is *TGT. Unless specified otherwise in the data group or 581 . the status is set to *DISABLED. the status of the user profile on the target system is not altered. If an existing user profile is changed. If a new user profile is created. The status of the user profile on the source system is always used when the user profile is created or changed on the target system. Data group definitions use these values. This is the default value in the data group definition. This is the default value for object entries. The status of the user profile is set to *ENABLED when the user profile is created or changed on the target system. this indicates that the specified in the data group definition is used for the user profile statue.in an object entry. The status of the user profile is set to *DISABLED when the user profile is created or changed on the target system. *DISABLE 1 *ENABLE 1 *SRC *TGT 1. In data group object entries. Table 106. Table 106 shows the possible values at both the data group and object entry levels. the values *DISABLED and *ENABLED are used but have the same meaning. the default is to use the value *SRC from the data group definition. Configuration values for replicating user profile status *DGDFT Only available for data group object entries. 582 . If the user profile names are different. the user profile password is not compared. The System Indicator fields will indicate that the attribute was not compared (*NOTCMPD). the System Indicator fields will indicate that comparing the attribute is not supported (*NOTSPT). The following tables identify the expected results when user profile password is compared. Difference Indicator Remote System User Profile Password *ENABLED *DISABLED Local System Expired Not Found *ENABLED *EQ *NA *NA *NE *DISABLED *EQ *NA *NA *NE Expired *EQ *NA *NA *NE Not Found *NE *NE *NE *EQ 583 . User profile passwords are only compared if the user profile name is the same on both systems and the user profile of the local system is enabled and has a defined password. or if the local user profile is disabled or expired. and the remote system is defined as System 2. The Difference Indicator field will also return a value of not compared (*NA). Table 107. Table 107 shows the possible Difference Indicator values when the user profile passwords are the same on the local and remote systems and are not defined as *NONE. Difference Indicator values when user profile passwords are the same. but not *NONE. If the local or remote user profile has a password of *NONE. The Difference Indicator field will also return a value of not supported (*NS).Comparison results for user profile password (*PRFPWDIND) When comparing the attribute *PRFPWDIND (user profile password indicator) with the Compare Object Attributes (CMPOBJA) command. or if you attempt name mapping. Note that the local system is the system on which the command is being run. The CMPOBJA command does not support name mapping while comparing the *PRFPWDIND attribute. MIMIX assumes that the user profile names are the same on both systems. Difference Indicator values when user profile passwords are *NONE. but not *NONE Difference Indicator Remote System User Profile Password *ENABLED *DISABLED Local System Expired Not Found *ENABLED *NE *NA *NA *NE *DISABLED *NE *NA *NA *NE Expired *NE *NA *NA *NE Not Found *NE *NE *NE *EQ Table 109 shows the possible Difference Indicator values when the user profile passwords are defined as *NONE on the local and remote systems. Difference Indicator values when user profile passwords are different. Difference Indicator Remote System User Profile Password *ENABLED *DISABLED Local System Expired Not Found *ENABLED *NA *NA *NA *NE *DISABLED *NA *NA *NA *NE Expired *NA *NA *NA *NE Not Found *NE *NE *NE *EQ 584 . Table 108. Table 109.Table 108 shows the possible Difference Indicator values when the user profile passwords are different on the local and remote systems and are not defined as *NONE. This section also includes a list of error codes associated with files held due to error. Table 110. • Journal entry codes for user journal transactions The following sections identify journal codes associated with user journal replication. including: • “Journal entry codes for files” on page 585 identifies journal codes supported for files. “Journal codes and entry types for journaled IFS objects” on page 590 identifies what B entry types are supported for IFS objects configured for user journal replication. “Error codes for files in error” on page 587 lists the error codes that can be associated with journal entries for held due to error.Journal entry codes for user journal transactions APPENDIX G Journal Codes and Error Codes This appendix lists journal codes and error codes associated with replication activity. “Journal codes and entry types for journaled data areas and data queues” on page 590 identifies what E and Q entry types are supported for data area and data queue objects configured for user journal replication. • Journal entry codes for files Table 110 lists journal entry codes for transactions that may appear in user journal transactions with a status of on hold due to error (*HLDERR). “Journal entry codes for system journal transactions” on page 592 identifies journal codes associated with object replicated through the system journal. IFS objects. Journal entry codes and types supported for files Journal Code C C C D D Type CM RB SC AC CG Description Set of record changes committed Set of record changes rolled back Commit transaction started Add constraint Change file Notes 1 1 1 585 . Journal codes for cooperatively processed physical files are listed in Table 115. data areas. • • • “Journal entry codes for files” on page 585 lists journal codes associated with files replicated through the user journal. and data queues configured for replication through the user journal. Journal entry codes and types supported for files Journal Code D D D D D D D D D D D D D D D D D F F F F F F F F F F F F Type CT DC DH DJ DT DW FM FN GC GO GT RV TC TD TG TQ ZB CB CE CR DM EJ IT IZ JM MC MD MM MN Description Create file Remove constraint File saved Change journaled object attribute Delete file Start of save while active Move file Rename File Change constraint Change owner Grant file Revoke file Add trigger Delete trigger Change trigger Refresh table Object attribute change Physical file member change Change end of data for physical file (PF) Physical file member cleared Delete member Journaling for a physical file member ended Identity value Physical file member initialized Journaling for a physical file member started Create member Physical file member deleted Physical file containing the member moved to different library Physical file containing the member renamed Notes 586 .Journal Codes and Error Codes Table 110. Error codes for files Error code 01 02 03 04 05 Description Generic record not found Before image record not found After image record not found Record in use Allocation error 587 . Table 111. This journal code is not supported by the Display Journal Statistics (DSPJRNSTC) command Error codes for files in error Table 111 lists error codes that identify the internal reason a file replicated through the user journal is on hold due to an error.Journal entry codes for user journal transactions Table 110. Journal entry codes and types supported for files Journal Code F F F F F R R R R R R R R U Type MS RC RG RM SS DL DR PT PX UB UP UR PP MX Description Physical file member saved Journaled changes removed from a physical file member Physical file member reorganized (RGZPFM) Member reorganized Start of save of a physical file member using save-whileactive function Record deleted in the physical file member Record deleted for rollback operation Record added to a physical file member Record added directly to RRN (relative record number) physical file member Before image of a record that is updated in the physical file member After image of a record that is updated in the physical file member After image of a record that is updated for rollback information MIMIX-generated pre-apply of RPT entry MIMIX-generated entry 1 Notes Note: 1. or *CMPRPR state during a request to start data groups (STRDG command) A request to compare file data (CMPFILDTA command) ended abnormally while attempting to repair the entry Error creating cursor Change end of data operation failed Data mismatch for delete request Delete of record failed File level error File open for minimized data error General error message Get log space entry failed Error attempting to place a data group file entry on *HLDIGN status Database replicator is ignoring entries for this file entry Error attempting to retrieve the journal information for the target journal and the JS OS/400 HA performance feature is installed Length of record retrieved not same as the transactions A lock on the file caused the operation to fail Error locking member The record was not found Error opening member Error opening data group file entry file C2 CC CE DE DL FE FO GE GL I IG JS LE LK LM NF OE OF 588 . Error codes for files Error code A AD AF AI AK AM AM AO AP C1 Description Error attempting to place a data group file entry *ACTIVE status Data group initialization for apply session failed *ALL missing for file in FMC Apply initialization error Minimized journal entry found for keyed replication Minimized journal entry cannot be applied Minimized journal entry cannot be converted to R-PX or R-PT Apply already active error Minimized journal entry applied. *CMPRLS. full image needed The database apply process found the entry in *CMPACT.Journal Codes and Error Codes Table 111. Journal entry codes for user journal transactions Table 111. Error codes for files Error code R RE RI R1 R2 R3 R4 SE TG UD UE UF W W1 W2 W3 WF XX X0 X1 X2 X3 X4 X5 X6 Description Error attempting to place a data group file entry on *RLS status Error reading record Non-restrictive referential constraint exists on the file and the target journal is in standby state Error with data group file entry after the database apply reorganized a file Error removing file from *HLDRGZ Error applying held entries after the database apply reorganized a file Error occurred while the database apply was reorganizing a file Compare data group file entry mismatch error Error while attempting to disable triggers Apply of data area failed Error on update (record not updated) Error updating the data group file entry file Error attempting to place a data group file entry on *RLSWAIT status Write failed (record not written) Record written to wrong location Write of deleted record failed Error writing record to data group file entry file An unexpected error occurred Apply exception encountered Generic exception encountered Could not create a needed apply object Could not add record to hold log Could not add record to commit index Error opening timestamp file Force of apply objects failed 589 . respectively. Journal codes and entry types for journaled data areas and data queues The operating system uses journal codes E and Q to indicate that journal entries are related to operations on data areas and data queues. directories. after-image End journaling for object Change object attribute Restore object Saved IFS object Start of save-while-active Start journaling for object Change object authority Change primary group Change object owner Rename file identifier Truncated IFS object Write after-image 1 1 1 Notes Note: 1.Journal Codes and Error Codes Journal codes and entry types for journaled IFS objects The system uses journal code B to indicate that the journal entry deposited is related to an IFS operation. MIMIX recognizes specific E and Q journal entry types as eligible for replication from a user journal. Table 112. Table 112 shows the currently supported IFS entry types that MIMIX can replicate for IFS objects configured for user journal replication. The action identified in these entries are replicated cooperatively through the security audit journal. or symbolic links Move/rename object Remove link (unlink) Bytes cleared. 590 . When configured for user journal replication. Journal entry codes and types supported for IFS objects Journal Code B B B B B B B B B B B B B B B B B Type AA B1 B3 B5 B6 ET FA FR FS FW JT OA OG OO RN TR WA Description Change audit attributes Create files. Journal entry codes for user journal transactions Table 113 shows the currently supported journal entry types for data areas. Journal entry codes and types supported for data queues Journal Code Q Q Q Q Q Q Type QA QB QC QD QE QG Description Create data queue Start data queue journaling Data queue cleared. Table 113. Journal entry codes and types supported for data areas Journal Code E E E E E E E E E E E E E E E E E Type EA EB ED EE EG EH EK EL EM EN ES EW ZA ZB ZO ZP ZT Description Update data area. no key Data queue deleted End data queue journaling Data queue attribute changed 591 . before image Data area deleted Create data area Start journal for data area End journal for data area Change journaled object attribute Data area restored Data area moved Data area renamed Data area saved Start of save for data area Change authority Change object attribute Ownership change Change primary group Auditing change Table 114 shows the currently supported journal entry types for data queues. after image Update data area. Table 114. Journal Codes and Error Codes Table 114. Table 115. Object types that are configured for cooperative processing will replicate the transaction through the user journal. Journal entry codes and types supported for data queues Journal Code Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Type QJ QK QL QM QN QR QS QX QY QZ ZA ZB ZO ZP ZT Description Data queue cleared. has key Receive data queue entry. no key Start of save for data queue Data queue saved Data queue restored Change authority Change object attribute Ownership change Change primary group Auditing change For more information about journal entries.. has key Data queue moved Data queue renamed Receive data queue entry. see Journal Entry Information (Appendix D) in the iSeries Backup and Recovery guide in the IBM eServer iSeries Information Center. Journal entry codes for system journal transactions Table 115 lists the journal entry codes and subtypes that may appear in transactions replicated through the system journal. has key Send data queue entry. Journal entry codes and subtypes for system journal entries Journal entry T-AD Description Auditing change Subtypes Entry Supported subtype values D (DLO auditing) O (Object auditing) U (User auditing) 592 . no key Send data queue entry. Journal entry codes and subtypes for system journal entries Journal entry T-CA Description Change authority Subtypes Command Supported subtype values GRT (Grant) RPL (Replace) RVK (Revoke) USR (Grant user authority) N (Create) R (Replace) CHG (Change) CRT (Create) DST (Reset using DST) RPA (Reset IBM-supplied) RST (Restore) A (Object was deleted not under commitment control) D (Pending object create rolled back) P (Pending delete under commitment control) R (Pending delete rolled back) CHG (Change) CRT (Create) U (Unlink directory) M (Move) R (Rename) N (New object restored) E (Existing object restored) A (Change of object owner) A (Adopt owner authority) J (Java adopt owner) M (Change to S_USUID) A (Change primary group) T-CO T-CP Create object User profile Entry Command T-DO Delete object Entry T-JD T-LD T-OM Job description Link. unlink. or lookup directory Object management change Object restore Object ownership changed Program adopt authority Command Entry Entry T-OR T-OW T-PA Entry Entry Entry T-PG Change of an object’s primary group Authority change during restore Entry T-RA Entry A (Changes to authority for object restored) 593 .Journal entry codes for system journal transactions Table 115. Journal Codes and Error Codes Table 115. T-SE Command T-SF Spooled file change Access T-VO Validation list change Entry T-YC T-ZC DLO object change Object change Access Access 594 . Journal entry codes and subtypes for system journal entries Journal entry T-RO Description Change of object owner during restore Subsystem routing entry Subtypes Entry Supported subtype values A (Restoring objects that had ownership changed when restored) ADD (Add) CHG (Change) RMV (Remove) A (Read) C (Created) D (Deleted) H (Held) I (Created inline) R (Released) S (Spooled file restored) T (Spooled file saved) U (Changed) A (Add) C (Change) F (Find) R (Remove) U (Unsuccessful verify) V (Successful verify) Various access types are supported. Various access types are supported. For more information about audit results. You can use the Run Query (RUNQRY) command to display outfiles with column headings and data type formatting if you have the licensed program 5722QU1. you can use the Display File Field Description (DSPFFD) command to see detailed outfile information. Note: Corrective action is only available for output files associated with Notifications. 595 . installed.Outfile support in MIMIX Availability Manager APPENDIX H Outfile formats This section contains the output files (outfile) formats for those MIMIX commands that provide outfile support. Use the Display Library Description (DSPLIBD) command to see the create authority of the library. including problems and recovered items. starting position. and number of bytes. All other output files generated by other commands are shown in their entirety in the Output File Information window. MIMIX Availability Manager provides a subsetted view of the output file in a window unique to the command. Public authority to the created outfile is the same as the create authority of the library in which the file is created. MIMIX provides a model database file that defines the record format for the outfile. Otherwise. The outfile display can be customized using Preferences. These database files can be found in the product installation library. Each output file window provides options for taking actions that are appropriate for the errors detected. type. Outfile support in MIMIX Availability Manager MIMIX Availability Manager provides enhanced MIMIX output file information for the compare commands used by audits. Recovery output files only display entries that have problems or have already been recovered. such as the field length. Query. For these commands.5250 emulator” on page 543. For each command that can produce an outfile. see “Resolving audit problems .MIMIX Availability Manager” on page 541 and “Resolving audit problems . Table 116.Work panels with outfile support The following table lists the work panels with outfile support. Work panels with outfile support Panel WRKDGDFN WRKJRNDFN WRKTFRDFN WRKSYSDFN WRKDGFE WRKDGDAE WRKDGOBJE WRKDGDLOE WRKDGIFSE WRKDGACT WRKDGACTE WRKDGIFSTE WRKDGOBJTE Description Work with DG Definitions Work with Journal Definitions Work with Transfer Definitions Work with System Definitions Work with DG File Entries Work with DG Data Area Entries Work with DG Object Entries Work with DG DLO Entries Work with DG IFS Entries Work with DG Activity Work with DG Activity Entries Work with DG IFS Tracking Entries Work with DG Object Tracking Entries 596 . user-defined name *APP.MCAG outfile (WRKAG command) MCAG outfile (WRKAG command) The following fields are available if you specify *OUTFILE on the Output parameter of the Work with Application Groups (WRKAG) command. user-defined name User-defined value Column headings AGDFN NAME USER PROFILE APP NAME APP LIBRARY APP RELEASE LEVEL PARENT APP GROUP APP CRG EXIT PGM CRG EXIT PGM LIB CRG EXIT PGM JOB NAME CRG EXIT PGM DATA NUMBER OF RESTARTS PARENT Parent application group CHAR(10) *AGDFN. MCAG outfile (WRKAG command) Field AGDFN USRPRF APP APPLIB RLSLVL Description Application group definition User profile Application name Application library Application release level Type. user-defined name *APP. *PARENT. user-defined name EXITPGM EXITPGMLIB JOB Application CRG exit program Application CRG exit program library Exit program job name CHAR(10) CHAR(10) CHAR(10) EXITDTA NBRRESTART Exit program data Number of restarts CHAR(256) PACKED(5 0) User-defined value 0-3 597 . *NONE. *JOBD. Table 117. userdefined name User-defined name *APPLIB. length CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) Valid values User-defined name Any valid user profile *AGDFN. *ATTN. length CHAR(256) Valid values User-defined value Column headings TAKEOVER IP ADDRESS DESCRIPTI ON UPDATE CLUSTER ENV TEXT UPDENV Description Update cluster environment CHAR(50) CHAR(10) User-defined value *YES. MCAG outfile (WRKAG command) Field HOST Description Takeover IP address Type. *INACTIVE. *NONE. *UNKNOWN. *UNKNOWN. *ACTIVE. *NOTAVAIL. *INDOUBT. *ACTIVE. *ENDCRGPND. *DLTCMDPND. *DLTCMDPND. *UNKNOWN. *ADDNODPND. *ACTIVE. *ACTIVE. *STRCRGPND. *ATTN. *NOTAVAIL APP CRG STATUS AGSTS Application CRG status CHAR(10) AGNODS Application CRG nodes status Data CRGs status CHAR(10) APP CRG NODES STATUS DATA CRG STATUS DCSTS CHAR(10) DCNODS Data CRG nodes status CHAR(10) DATA CRG NODES STATUS 598 . *CHGPND. *NO IDA Input data area name CHAR(10) BLANK. *SWTPND BLANK. *RESTORED. *INACTIVE. *CHGPND. *NONE. *NOTAVAIL. *NOTAVAIL BLANK. *NONE. *INDOUBT. *ENDCRGPND. *ATTN. *INACTIVE. *ADDNODPND. *DLTPND. *STRCRGPND. *DLTPND. *CRTPND. *RMVNODPND. *UNKNOWN. *NONE. Name of the Input Data Area INPUT DATA AREA NAME BLANK. *CRTPND. *ATTN.MCAG outfile (WRKAG command) Table 117. *RESTORED. *SWTPND BLANK. *INACTIVE. *RMVNODPND. length CHAR(10) Valid values BLANK. User-defined name FWTIME FDFTACT PACKED(5 0) PACKED(5 0) *NOMAX. *ACTIVE. *PROCEED 599 . *UNKNOWN. *INACTIVE. User-defined name Column headings DG STATUS FAILOVER MSGQ LIBRARY FAILOVER MSGQ NAME FAILOVER WAIT TIME FAILOVER DFT ACTION FMSGQL Failover message queue library Failover message queue name Failover wait time Failover default action CHAR(10) FMSGQN CHAR(10) *NONE. *NONE. 1-32767 *CANCEL.MCAG outfile (WRKAG command) Table 117. MCAG outfile (WRKAG command) Field REPSTS Description Data group status Type. *ATTN. *NOTAVAIL *NONE. *INACTIVE. *STRCRGPND. *ACTIVE. *ATTN. *NOTAVAIL DCNODS REPSTS Data CRG nodes status Data group status CHAR(10) CHAR(10) BLANK. *DLTCMDPND. Table 118. user-defined name User-defined name *DTACRG. *ACTIVE. *CHGPND. *RESTORED. user-defined name User-defined name *DGDFN. *SYNC MMXDTACRG. user-defined name *NONE. user-defined name *DTACRG. *UNKNOWN. length CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) Valid values User-defined name *DTACRG. *ATTN. *INACTIVE. *ENDCRGPND. user-defined name Column headings DATA CRG DGDFN NAME AGDFN NAME JOURNAL JOURNAL LIBRARY OBJECT SPECIFIER FILE (OSF) OSF LIBRARY OSF MEMBER RJ MODE (DELIVER) DATA CRG EXIT PGM DATA CRG EXIT PGM LIBRARY DATA CRG STATUS OSFLIB OSFMBR DELIVERY EXITPGM EXITPGMLIB DCSTS Object specifier file library Object specifier file member RJ mode Data CRG exit program Data CRG exit program library Data CRGs status CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) *AGDFN. *RMVNODPND. *CRTPND. *ATTN. *INDOUBT. *NOTAVAIL 600 . *ASYNC. *NOTAVAIL. user-defined name *MIMIX. *UNKNOWN. *DLTPND.MCDTACRGE outfile (WRKDTARGE command) MCDTACRGE outfile (WRKDTARGE command) The following fields are available if you specify *OUTFILE on the Output parameter of the Work with Data CRG Entries (WRKDTARGE) command. MCDTACRGE outfile (WRKDTARGE command) Field DTACRG DGDFN AGDFN JRN JRNLIB OSF Description Data CRG Data group name Application group definition Journal name Journal library Object specifier file Type. *ACTIVE. *SWTPND *NONE. *NONE. *ADDNODPND. *NONE. user-defined name BLANK. *INACTIVE. DATA CRG STATUS DG STATUS BLANK. *UNKNOWN. MCDTACRGE outfile (WRKDTARGE command) Table 118. *XSM *AGDFN. User-defined name *AGDFN. User-defined name *DEV. *NONE. length CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) PACKED(5 0) PACKED(5 0) CHAR(10) Valid values User-defined name *NONE. *PEER. *CANCEL. User-defined value Column headings DEVICE CRG ASP GROUP DATA RESOURCE TYPE FAILOVER MSGQ LIBRARY FAILOVER MSGQ NAME FAILOVER WAIT TIME FAILOVER DFT ACTION CLUSTER ADMINISTRATIVE DOMAIN SYNCHRONIZATI ON DOMAIN SYNCOPT Synchronization option PACKED(10 5) *LASTCHG. *ACTDMN 601 . User-defined name *AGDFN. *NONE. 1-32767 *AGDFN. *DTA. MCDTACRGE outfile (WRKDTARGE command) Field DEVCRG ASPGRP DTATYPE FMSGQL FMSGQN FWTIME FDFTACT ADMDMN Description Device CRG name ASP Group Data resource group type Failover message queue library Failover message queue name Failover wait time Failover default action Cluster administrative domain Type. *PROCEED *NONE. *NOMAX. MCNODE outfile (WRKNODE command) MCNODE outfile (WRKNODE command) The following fields are available if you specify *OUTFILE on the Output parameter of the Work with Node Entries (WRKNODE) command. *REPLICATE. user-defined name User-defined name *PRIMARY. *REPLICATE. *REPLICATE. *BACKUP. *UNDEFINED Column headings AGDFN NAME CRG NAME NODE CURRENT ROLE CURRENT SEQUENCE CURDTAPVD Current data provider CHAR(10) CURRENT DATA PROVIDER PREFERRED ROLE PREFERRED SEQUENCE PREFROLE PREFSEQ Preferred role Preferred sequence CHAR(10) PACKED(5 0) CFGROLE Configured role CHAR(10) CONFIGURE D ROLE 602 . length CHAR(10) CHAR(10) CHAR(8) CHAR(10) PACKED(5 0) Valid values User-defined name *AGDFN. Table 119. *UNDEFINED. 0-127 (-2= *UNDEFINED) (-1 = *REPLICATE) (0 = *PRIMARY) (1-127 = *BACKUP sequence) *PRIMARY. *UNDEFINED -2. *BACKUP. *BACKUP. *UNDEFINED -2. user-defined name *PRIMARY. 0-127 (-2= *UNDEFINED) (-1 = *REPLICATE) (0 = *PRIMARY) (1-127 = *BACKUP sequence) *PRIMARY. -1. -1. MCNODE outfile (WRKNODE command) Field AGDFN CRG NODE CURROLE CURSEQ Description Data CRG CRG name System name Current role Current sequence Type. *BACKUP. *INACTIVE. *UNDEFINED. *NOTAVAIL. *ATTN.MCNODE outfile (WRKNODE command) Table 119. *UNKNOWN Column headings CONFIGURE D SEQUENCE CFGDTAPVD Configured data provider CHAR(10) CONFIGURE D DATA PROVIDER CRG NODE STATUS STATUS CRG node status CHAR(10) 603 . user-defined name *ACTIVE. 0-127 (-2= *UNDEFINED) (-1 = *REPLICATE) (0 = *PRIMARY) (1-127 = *BACKUP sequence) *PRIMARY. length PACKED(5 0) Valid values -2. -1. *BACKUP. MCNODE outfile (WRKNODE command) Field CFGSEQ Description Configured sequence Type. *NONE. *NOMBR. For additional information. *UA Note: The values *RCYFAILED and *RECOVERED may be placed in the outfile as a result of automatic audit recovery actions. *RCYFAILED.MM.The command is also called by audits which run the #DGFE rule. Column headings TIMESTAMP COMMAND NAME DGDFN SHORT NAME DGDFN NAME SYSTEM 1 SYSTEM 2 DATA SOURCE SYSTEM 1 OBJECT SYSTEM 1 LIBRARY SYSTEM 1 MEMBER OBJECT TYPE RESULT OPTION FILE2 LIB2 Option System 2 file name System 2 library name CHAR(100) CHAR(10) CHAR(10) *NONE. *DGFESYNC User-defined name User-defined name OPTION SYSTEM 2 OBJECT SYSTEM 2 LIBRARY 604 . MXCDGFE outfile (CHKDGFE command) Field TIMESTAMP COMMAND DGSHRTNM DGDFN DGSYS1 DGSYS2 DTASRC FILE LIB MBR OBJTYPE RESULT Description Timestamp (YYYY-MMDD. *EXTRADGFE. *NOFILE. *SYS2 User-defined name User-defined name User-defined name *FILE *NODGFE. *NOFILECHK. see “Interpreting results for configuration data . Table 120. length TIMESTAMP CHAR(10) CHAR(3) CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) Valid values SAA timestamp CHKDGFE Short data group name User-defined data group name User-defined system name User-defined system name *SYS1.MXCDGFE outfile (CHKDGFE command) MXCDGFE outfile (CHKDGFE command) The following fields are available if you specify *OUTFILE on the Output parameter of the Check Data Group File Entries (CHKDGFE) command.HH.#DGFE audit” on page 546. *RECOVERED.SSmmmm) Command name Data group short name Data group definition name System 1 System 2 Data source System 1 file name System 1 library name System 1 member name Object type Result Type. PF38-DTA. MXCDGFE outfile (CHKDGFE command) Field MBR2 ASPDEV Description System 2 member name Source ASP device Type. PF-SRC.if object in ASP 33-255 PF-DTA.MXCDGFE outfile (CHKDGFE command) Table 120. length CHAR(10) CHAR(10) Valid values User-defined name Column headings SYSTEM 2 MEMBER *UNKNOWN . LF. PF38-SRC. LF38 OBJECT ATTRIBUTE OBJATR Object attribute CHAR(10) 605 .if object in ASP 1-32 User-defined name .if object not found ASP DEVICE or an API error *SYSBAS . HH.MXCMPDLOA outfile (CMPDLOA command) MXCMPDLOA outfile (CMPDLOA command) For additional supporting information.MM. CMPDLOA Output file (MXCMPDLOA) Field TIMESTAMP COMMAND DGSHRTNM DGNAME SYSTEM1 SYSTEM2 DTASRC SYS1DLO SYS2DLO CCSID CNTRYID LANGID CMPATR SYS1IND Description Timestamp (CCCC-YY-MMDD. see “Interpreting results of audits that compare attributes” on page 551. Column headings TIMESTAMP COMMAND NAME DGDFN SHORT NAME DGDFN NAME SYSTEM 1 SYSTEM 2 DATA SOURCE SYSTEM 1 DLO SYSTEM 2 DLO CCSID CNTRYID LANGID COMPARED ATTRIBUTE SYSTEM 1 INDICATOR User-defined system name Note: Local system name if no DG specified. *SYS2 User-defined name User-defined name User-defined name System-defined name System-defined name See “Attributes compared and expected results #DLOATR audit” on page 571 See Table 87 in “Where was the difference detected” on page 554 606 .SSmmmm) Command name Data group short name Data group definition name System 1 System 2 Data source System 1 DLO name System 2 DLO name DLO name CCSID DLO name country ID DLO name language ID Compared attribute System 1 file indicator Type. User-defined system name Note: Local system name if no DG specified. Table 121. length CHAR(26) CHAR(10) CHAR(3) CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(76) CHAR(76) BIN(5) CHAR(2) CHAR(3) CHAR(10) CHAR(10) Valid values SAA timestamp CMPDLOA Short data group name User-defined data group name Note: Blank if not DG specified on the command. *SYS1. CMPDLOA Output file (MXCMPDLOA) Field SYS2IND DIFIND SYS1VAL SYS1CCSID SYS2VAL SYS2CCSID Description Stem 2 file indicator Differences indicator System 1 value of the specified attribute System 1 value CCSID System 1 value of the specified attribute System 1 value CCSID Type.MXCMPDLOA outfile (CMPDLOA command) Table 121. length CHAR(10) CHAR(10) VARCHAR(2048) MINLEN(50) BIN(5) VARCHAR(2048) MINLEN(50) BIN(5) Valid values See Table 87 in “Where was the difference detected” on page 554 See “What attribute differences were detected” on page 552 See “Attributes compared and expected results #DLOATR audit” on page 571 1-65535 See “Attributes compared and expected results #DLOATR audit” on page 571 1-65535 Column headings SYSTEM 2 INDICATOR DIFFERENCE INDICATOR SYSTEM 1 VALUE SYSTEM 1 CCSID SYSTEM 2 VALUE SYSTEM 2 CCSID 607 . HH. User-defined system name *remote system name if no DG specified. CMPFILA Output file (MXCMPFILA) Field TIMESTAMP COMMAND DGSHRTNM DGNAME SYSTEM1 SYSTEM2 DTASRC SYS1OBJ SYS1LIB MBR SYS2OBJ SYS2LIB OBJTYPE Description Timestamp (YYYY-MMDD. see “Interpreting results of audits that compare attributes” on page 551. Table 122.SSmmmmmm) Command name Data group short name Data group definition name System 1 System 2 Data source System 1 object name System 1 library name Member name System 2 object name System 2 library name Object type Type. length TIMESTAMP CHAR(10) CHAR(3) CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) Valid values SAA timestamp CMPFILA Short data group name User-defined data group name *blank if not DG specified on the command. *SYS1.MXCMPFILA outfile (CMPFILA command) MXCMPFILA outfile (CMPFILA command) For additional supporting information.MM. User-defined system name *local system name if no DG specified. *SYS2 User-defined name User-defined name User-defined name System-defined name System-defined name *FILE Column headings TIMESTAMP COMMAND NAME DGDFN SHORT NAME DGDFN NAME SYSTEM 1 SYSTEM 2 DATA SOURCE SYSTEM 1 FILE SYSTEM 1 LIBRARY MEMBER SYSTEM 2 FILE SYSTEM 2 LIBRARY OBJECT TYPE 608 . #FILATRMBR audits” on page 556. 1-65535 *NONE. See Table 87 in “Where was the difference detected” on page 554. CMPFILA Output file (MXCMPFILA) Field CMPATR SYS1IND SYS2IND DIFIND SYS1VAL SYS1CCSID SYS2VAL SYS2CCSID ASPDEV1 Description Compared attribute System 1 file indicator System 2 file indicator Differences indicator System 1 value of the specified attribute System 1 value CCSID System 2 value of the specified attribute System 2 value CCSID System 1 ASP device Type.MXCMPFILA outfile (CMPFILA command) Table 122. length CHAR(10) CHAR(10) CHAR(10) CHAR(10) VARCHAR(2048) MINLEN(50) BIN(5) VARCHAR(2048) MINLEN(50) BIN(5) CHAR(10) Valid values See “Attributes compared and expected results #FILATR. User-defined name Column headings COMPARED ATTRIBUTE SYSTEM 1 INDICATOR SYSTEM 2 INDICATOR DIFFERENCE INDICATOR SYSTEM 1 VALUE SYSTEM 1 CCSID SYSTEM 2 VALUE SYSTEM 2 CCSID SYSTEM 1 ASP DEVICE SYSTEM 2 ASP DEVICE ASPDEV2 System 2 ASP device CHAR(10) *NONE. See “What attribute differences were detected” on page 552. #FILATRMBR audits” on page 556. User-defined name 609 . 1-65535 See “Attributes compared and expected results #FILATR. See Table 87 in “Where was the difference detected” on page 554. See “Attributes compared and expected results #FILATR. #FILATRMBR audits” on page 556. MXCMPFILD outfile (CMPFILDTA command) MXCMPFILD outfile (CMPFILDTA command) For additional information for interpreting this outfile. Compare File Data (CMPFILDTA) output file (MXCMPFILD) Field TIMESTAMP COMMAND DGSHRTNM DGNAME Description Timestamp (YYYY-MMDD. A value other than 0 (zero) indicates that there are either missing records or data within records does not match. otherwise. If repair was requested. The following fields require additional explanation: Major mismatches before .HH. the value should equal that shown in the Major mismatches before column. Table 123.Indicates the number of mismatched records found.SSmmmmmm) Command name Data group short name Data group definition name Type.Indicates the number of mismatched records remaining.Indicates the number of records for which the database apply process has not yet performed repair processing. this value should be 0 (zero). Minor mismatches after . length TIMESTAMP CHAR(10) CHAR(3) CHAR(10) Valid values SAA timestamp “CMPFILDTA” Short data group name User-defined data group name * blank if not DG specified on the command User-defined system name *local system name if no DG specified User-defined system name *remote system name if no DG specified *SYS1. *SYS2 Column headings TIMESTAMP COMMAND NAME DGDFN SHORT NAME DGDFN NAME SYSTEM1 System 1 CHAR(8) SYSTEM 1 SYSTEM2 System 2 CHAR(8) SYSTEM 2 DTASRC Data source CHAR(10) DATA SOURCE 610 . Apply pending . see “Interpreting results of audits for record counts and file data” on page 548. Major mismatches after .MM.Indicates the number of differences remaining that do not affect data integrity. 99999999999999999999 MAJMISMAFT Major mismatches after processing DECIMAL(20) 0 . length CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) DECIMAL(20) Valid values User-defined name User-defined name User-defined name User-defined name User-defined name *FILE “What attribute differences were detected” on page 552 *SYS1. *YES.99999999999999999999 Column headings SYSTEM 1 OBJECT SYSTEM 1 LIBRARY MEMBER SYSTEM 2 OBJECT SYSTEM 2 LIBRARY OBJECT TYPE DIFFERENCE INDICATOR REPAIR SYSTEM FILE REPAIR SUCCESSFUL TOTAL RECORDS COMPARED MAJOR MISMATCHES BEFORE PROCESSING MAJOR MISMATCHES AFTER PROCESSING MINOR MISMATCHES AFTER PROCESSING MAJMISMBEF Major mismatches before processing DECIMAL(20) 0 . *NO 0 . Compare File Data (CMPFILDTA) output file (MXCMPFILD) Field SYS1OBJ SYS1LIB MBR SYS2OBJ SYS2LIB OBJTYPE DIFIND REPAIRSYS FILEREP TOTRCDS Description System 1 object name System 1 library name Member name System 2 object name System 2 library name Object type Differences indicator Repair system File repair successful Total records compared Type. *SYS2 Blank.MXCMPFILD outfile (CMPFILDTA command) Table 123.99999999999999999999 611 .99999999999999999999 MINMISMAFT Minor mismatches after processing DECIMAL(20) 0 . Compare File Data (CMPFILDTA) output file (MXCMPFILD) Field APYPENDING Description Apply pending records Type. length DECIMAL(20) Valid values 0 .99999999999999999999 Column headings ACTIVE RECORDS PENDING SYSTEM 1 ASP DEVICE SYSTEM 2 ASP DEVICE TEMPORARY TARGET SQL VIEW ASPDEV1 ASPDEV2 TMPSQLVIEW System 1 ASP device System 2 ASP device Temporary target system SQL view pathname CHAR(10) CHAR(10) CHAR(33) *NONE. User-defined name IBM i-format path name or blanks 612 . User-defined name *NONE.MXCMPFILD outfile (CMPFILDTA command) Table 123. but you are unsure which system contains the correct data. RRN report) This output file format is the result of specifying *RRN for the report type on the Compare File Data command.000 objects that failed to compare. RRN report) MXCMPFILR outfile (CMPFILDTA command. Viewing the RRN value provides information that enables you to display the specific records on the two systems and to determine the system on which the file should be repaired. User-defined name Column headings SYSTEM 1 SYSTEM 2 System 2 CHAR(8) SYSTEM 2 SYS1OBJ SYS1LIB MBR SYS2OBJ SYS2LIB RRN ASPDEV1 ASPDEV2 System 1 object name System 1 library name Member name System 2 object name System 2 library name Relative record number System 1 ASP device System 2 ASP device CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) DECIMAL(10) CHAR(10) CHAR(10) SYSTEM 1 OBJECT SYSTEM 1 LIBRARY MEMBER SYSTEM 2 OBJECT SYSTEM 2 LIBRARY RRN SYSTEM 1 ASP DEVICE SYSTEM 2 ASP DEVICE 613 .MXCMPFILR outfile (CMPFILDTA command. Compare File Data (CMPFILDTA) relative record number (RRN) output file (MXCMPFILR) Field SYSTEM 1 Description System 1 Type. Output in this format enables you to see the relative record number (RRN) of the first 1. This value is useful when resolving situations where a discrepancy is known to exist. User-defined name *NONE. length CHAR(8) Valid values User-defined system name *local system name if no DG specified User-defined system name *local system name if no DG specified User-defined name User-defined name User-defined name User-defined name User-defined name Number *NONE. Table 124. *SYS2 user-defined name user-defined name user-defined name SYSTEM1 System 1 CHAR(8) SYSTEM2 System 2 CHAR(8) ‘SYSTEM 2’ DTASRC SYS1OBJ SYS1LIB MBR Data source System 1 object name System 1 library name Member name CHAR(10) CHAR(10) CHAR(10) CHAR(10) ‘DATA’ ‘SOURCE’ ‘SYSTEM 1’ ‘OBJECT’ ‘SYSTEM 1’ ‘LIBRARY’ ‘MEMBER’ 614 . Compare Record Count (CMPRCDCNT) output file (MXCMPRCDC) Field TIMESTAMP COMMAND DGSHRTNM Description Timestamp (YYYY-MMDD. Table 125.HH.mmmmmm) Command Name Data group short name Format TIMESTAMP CHAR(10) CHAR(3) Valid values SAA timestamp “CMPFILDTA” short data group name Column headings ‘TIMESTAMP’ ‘COMMAND’ ‘NAME’ ‘DGDFN’ ‘SHORT’ ‘NAME’ ‘DGDFN’ ‘NAME’ ‘SYSTEM 1’ DGNAME Data group definition name CHAR(10) user-defined data group name * blank if not DG specified on the command user-defined system name * local system name if no DG specified user-defined system name * remote system name if no DG specified *SYS1.MXCMPRCDC outfile (CMPRCDCNT command) MXCMPRCDC outfile (CMPRCDCNT command) For additional information for interpreting this outfile.SS. see “Interpreting results of audits for record counts and file data” on page 548.MM. 99999999999999999999 SYS1DLTCNT System 1 deleted records DECIMAL(20) 0 .99999999999999999999 ASPDEV1 System 1 ASP device CHAR(10) *NONE.MXCMPRCDC outfile (CMPRCDCNT command) Table 125.99999999999999999999 SYS2DLTCNT System 2 deleted records DECIMAL(20) 0 . user-defined name ACTRCDPND Active records pending DECIMAL(20) 0 .99999999999999999999 Column headings ‘DIFFERENCE’ ‘INDICATOR’ ‘SYSTEM 1’ ‘CURRENT’ ‘RECORDS’ ‘SYSTEM 2’ ‘CURRENT’ RECORDS’ ‘SYSTEM 1’ ‘DELETED’ ‘RECORDS’ ‘SYSTEM 2’ ‘DELETED’ ‘RECORDS’ ‘SYSTEM 1’ ‘ASP’ ‘DEVICE’ ‘SYSTEM 2’ ‘ASP’ ‘DEVICE’ ‘ACTIVE’ ‘RECORDS’ ‘PENDING’ SYS2CURCNT System 2 current records DECIMAL(20) 0 . Compare Record Count (CMPRCDCNT) output file (MXCMPRCDC) Field DIFIND SYS1CURCNT Description Differences indicator System 1 current records Format CHAR(10) DECIMAL(20) Valid values Refer to differences indicator table 0 .99999999999999999999 615 . user-defined name ASPDEV2 System 2 ASP device CHAR(10) *NONE. MXCMPRCDC outfile (CMPRCDCNT command) 616 . length TIMESTAMP CHAR(10) CHAR(3) CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) CHAR(10) BIN(5) CHAR(2) CHAR(3) CHAR(10) CHAR(10) Valid values SAA timestamp CMPIFSA Short data group name User-defined data group name *blank if not DG specified on the command. User-defined system name *remote system name if no DG specified.HH.MM. Table 126. *SYS2 User-defined name User-defined name User-defined name System-defined name System-defined name See “Attributes compared and expected results #IFSATR audit” on page 569. CMPIFSA Output file (MXCMPIFSA) Field TIMESTAMP COMMAND DGSHRTNM DGNAME SYSTEM1 SYSTEM2 DTASRC SYS1OBJ SYS2OBJ CCSID CNTRYID LANGID CMPATR SYS1IND Description Timestamp (YYYY-MMDD. Column headings TIMESTAMP COMMAND NAME DGDFN SHORT NAME DGDFN NAME SYSTEM 1 SYSTEM 2 DATA SOURCE SYSTEM 1 OBJECT SYSTEM 2 OBJECT CCSID CNTRYID LANGID COMPARED ATTRIBUTE SYSTEM 1 INDICATOR 617 . see “Interpreting results of audits that compare attributes” on page 551. *SYS1. User-defined system name *local system name if no DG specified.MXCMPIFSA outfile (CMPIFSA command) MXCMPIFSA outfile (CMPIFSA command) For additional supporting information. See Table 87 in “Where was the difference detected” on page 554.SSmmmmmm) Command name Data group short name Data group definition name System 1 System 2 Data source System 1 object name System 2 object name IFS object name CCSID IFS object name country ID IFS object name language ID Compared attribute System 1 file indicator Type. length CHAR(10) CHAR(10) VARCHAR(2048) MINLEN(50) BIN(5) VARCHAR(2048) MINLEN(50) BIN(5) Valid values See Table 87 in “Where was the difference detected” on page 554. See “Attributes compared and expected results #IFSATR audit” on page 569. “What attribute differences were detected” on page 552.MXCMPIFSA outfile (CMPIFSA command) Table 126. CMPIFSA Output file (MXCMPIFSA) Field SYS2IND DIFIND SYS1VAL SYS1CCSID SYS2VAL SYS2CCSID Description System 2 file indicator Differences indicator System 1 value of the specified attribute System 1 value CCSID System 2 value of the specified attribute System 2 value CCSID Type. 1-65535 See “Attributes compared and expected results #IFSATR audit” on page 569. 1-65535 Column headings SYSTEM 2 INDICATOR DIFFERENCE INDICATOR SYSTEM 1 VALUE SYSTEM 1 CCSID SYSTEM 2 VALUE SYSTEM 2 CCSID 618 . CMPOBJA Output file (MXCMPOBJA) Field TIMESTAMP COMMAND DGSHRTNM DGNAME SYSTEM1 SYSTEM2 DTASRC SYS1OBJ SYS1LIB MBR SYS2OBJ SYS2LIB OBJTYPE Description Timestamp (YYYY-MMDD. User-defined system name *local system name if no DG specified.MM. see “Interpreting results of audits that compare attributes” on page 551. *SYS1. Table 127. *SYS2 User-defined name User-defined name User-defined name User-defined name User-defined name User-defined name Column headings TIMESTAMP COMMAND NAME DGDFN SHORT NAME DGDFN NAME SYSTEM 1 SYSTEM 2 DATA SOURCE SYSTEM 1 FILE SYSTEM 1 LIBRARY MEMBER SYSTEM 2 OBJECT SYSTEM 2 LIBRARY OBJECT TYPE 619 .SSmmmm) Command name Data group short name Data group definition name System 1 System 2 Data source System 1 object name System 1 library name Member name System 2 object name System 2 library name Object type Type.MXCMPOBJA outfile (CMPOBJA command) MXCMPOBJA outfile (CMPOBJA command) For additional supporting information.HH. User-defined system name *remote system name if no DG specified. length TIMESTAMP CHAR(10) CHAR(3) CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) Valid values SAA timestamp CMPOBJA Short data group name User-defined data group name *blank if not DG specified on the command. length CHAR(10) CHAR(10) CHAR(10) CHAR(10) VARCHAR(2048) MINLEN(50) BIN(5) VARCHAR(2048) MINLEN(50) BIN(5) CHAR(10) Valid values See “Attributes compared and expected results #OBJATR audit” on page 561 See Table 87 in “Where was the difference detected” on page 554 See Table 87 in “Where was the difference detected” on page 554 “What attribute differences were detected” on page 552 See “Attributes compared and expected results #OBJATR audit” on page 561 1-65535 See “Attributes compared and expected results #OBJATR audit” on page 561 1-65535 *NONE. User-defined name 620 . User-defined name Column headings COMPARED ATTRIBUTE SYSTEM 1 INDICATOR SYSTEM 2 INDICATOR DIFFERENCE INDICATOR SYSTEM 1 VALUE SYSTEM 1 CCSID SYSTEM 2 VALUE SYSTEM 2 CCSID SYSTEM 1 ASP DEVICE SYSTEM 2 ASP DEVICE ASPDEV2 System 2 ASP device CHAR(10) *NONE. CMPOBJA Output file (MXCMPOBJA) Field CMPATR SYS1IND SYS2IND DIFIND SYS1VAL SYS1CCSID SYS2VAL SYS2CCSID ASPDEV1 Description Compared attribute System 1 file indicator Stem 2 file indicator Differences indicator System 1 value of the specified attribute System 1 value CCSID System 1 value of the specified attribute System 1 value CCSID System 1 ASP device Type.MXCMPOBJA outfile (CMPOBJA command) Table 127. *NOTFOUND. BLANK OBJECT TYPE OBJECT ATTRIBUTE FAILURE REASON ENTRY COUNT OBJECT CATEGORY OBJECT LIBRARY OBJECT MEMBER DLO 621 TYPE OBJATR REASON COUNT OBJCAT OBJLIB OBJ OBJMBR DLO Object type Object attribute Failure reason Entry count Object category Object library Object name Member name DLO name CHAR(10) CHAR(10) CHAR(11) PACKED(5 0) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(12) . *SPLF. *ACTIVE OBJECT STATUS CATEGORY Refer to the OM5100P file for the list of valid object types Refer to the OM5200P file for the list of valid object attributes *INUSE. *RESTRICTED.MXDGACT outfile (WRKDGACT command) MXDGACT outfile (WRKDGACT command) Table 128. BLANK User-defined name. *FAILED. *IFS. *LIB User-defined name. BLANK User-defined name. length CHAR(10) CHAR(8) CHAR(8) Valid values User-defined data group name User-defined system name User-defined system name Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 DATA SOURCE *COMPLETED. MXDGACT outfile (WRKDGACT command) Field DGDFN DGSYS1 DGSYS2 DTASRC STATUS Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) Data source Object status category CHAR(10) CHAR(10) *SYS1. blank 0-9999 (9999 = maximum value supported) *DLO. *OTHER. *DELAYED. *SYS2 Type. BLANK User-defined name. BLANK Default to job CCSID. BLANK User-defined name. BLANK VARLEN(75) CCSID(13488) IFS Object (UNICODE) 622 . BLANK User-defined name. related fields will be written in Unicode Column headings FOLDER SPLF JOB SPLF NAME SPLF NUMBER OUTQ OUTQ LIBRARY IFS OBJECT CCSID IFSUCS IFS Object (UNICODE) Graphic(512) User-defined name (Unicode). BLANK User-defined name.MXDGACT outfile (WRKDGACT command) Table 128. MXDGACT outfile (WRKDGACT command) Field FLR SPLFJOB SPLF SPLFNBR OUTQ OUTQLIB IFS CCSID Description Folder name Spooled file job name Spooled file name Spooled file number Output queue Output queue library Object IFS name Object CCSID Type. length CHAR(63) CHAR(26) CHAR(10) PACKED(7 0) CHAR(10) CHAR(10) CHAR(1024) VARLEN(100) BIN(5 0) Valid values User-defined name. BLANK 1-99999. *NONE. BLANK Three part spooled file name. *NONE. If unable to convert to job's CCSID or job CCSID is 65535. BLANK User-defined name. *IFS. *SPLF. length CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) Valid values User-defined data group name User-defined system name User-defined system name *SYS1. *OTHER. *RESTRICTED. *ACTIVE Refer to on-line help for complete list Refer to the OM5100P file for the list of valid object types Refer to the OM5200P file for the list of valid object attributes *INUSE. *NOTFOUND. *LIB 1-99999999999999999999 Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 DATA SOURCE OBJECT STATUS CATEGORY OBJECT STATUS OBJECT TYPE OBJECT ATTRIBUTE FAILURE REASON OBJECT CATEGORY JOURNAL SEQUENCE NUMBER JOURNAL SEQUENCE NUMBER 623 OBJSTATUS TYPE OBJATR REASON OBJCAT SEQJRN Object status Object type Object attribute Failure reason Object category Journal sequence number CHAR(2) CHAR(10) CHAR(10) CHAR(11) CHAR(10) ZONED(20 0) SEQNBR Journal sequence number PACKED(10 0) 1-9999999999 . *FAILED. MXDGACTE outfile (WRKDGACTE command) Field DGDFN DGSYS1 DGSYS2 DTASRC STATUS Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) Data source Object status category Type. *SYS2 *COMPLETED. blank *DLO. *DELAYED.MXDGACTE outfile (WRKDGACTE command) MXDGACTE outfile (WRKDGACTE command) Table 129. length CHAR(1) CHAR(2) TIMESTAMP Valid values Valid journal codes Valid journal types YYYY-MMDD.SS.SS.mmmmmm YYYY-MMDD. *NO 0-1998 Number of retries attempted PACKED(5 0) 624 .MM.MM.mmmmmm YYYY-MMDD.SS.mmmmmm YYYY-MMDD.MM.HH.HH.MM.mmmmmm *YES.HH.HH.MM. *NO Column headings JOURNAL ENTRY CODE JOURNAL ENTRY TYPE JOURNAL ENTRY TIMESTAMP JOURNAL ENTRY SEND TIMESTAMP JOURNAL ENTRY RCV TIMESTAMP JOURNAL ENTRY RTV TIMESTAMP CONTAINER SEND TIMESTAMP JOURNAL ENTRY APY TIMESTAMP REQUIRES CONTAINER SEND WAITING FOR RETRY NUMBER OF RETRIES ATTEMPTED JRNSNDTSP Journal entry send timestamp Journal entry receive timestamp Journal entry retrieve timestamp Container send timestamp TIMESTAMP JRNRCVTSP TIMESTAMP JRNRTVTSP TIMESTAMP CNRSNDTSP TIMESTAMP JRNAPYTSP Journal entry apply timestamp Requires container TIMESTAMP REQCNRSND CHAR(10) RTYWAIT RTYATTEMPT Waiting for retry CHAR(10) *YES.mmmmmm YYYY-MMDD.HH.MM. MXDGACTE outfile (WRKDGACTE command) Field JRNCODE JRNTYPE JRNTSP Description Journal entry code Journal entry type Journal entry timestamp Type.SS.mmmmmm YYYY-MMDD.HH.MXDGACTE outfile (WRKDGACTE command) Table 129.SS.SS. SS. MXDGACTE outfile (WRKDGACTE command) Field RTYREMAIN Description Type.MM.MXDGACTE outfile (WRKDGACTE command) Table 129. BLANK User-defined name. BLANK User-defined name. BLANK Journal entry User-defined name. BLANK User-defined name.mmmmmm Valid message ID. BLANK User-defined name. BLANK User-defined name. BLANK Three part spooled file name. BLANK Job name. length Valid values 0-1998 Column headings NUMBER OF RETRIES REMAINING DELAY INTERVAL NEXT RETRY TIMESTAMP MESSAGE ID MESSAGE DATA FAILED JOB NAME JOURNAL ENTRY OBJECT LIBRARY OBJECT MEMBER DLO FOLDER SPLF NAME SPLF NUMBER OUTQ OUTQ LIBRARY IFS OBJECT Number of retries remaining PACKED(5 0) DLYITV NXTRTYTSP MSGID MSG FAILEDJOB JRNENT OBJLIB OBJ OBJMBR DLO FLR SPLFJOB SPLF SPLFNBR OUTQ OUTQLIB IFS Delay interval Next retry timestamp Message ID Message data Failed job name Journal entry Object library Object name Member name DLO name Folder name Spooled file job name Spooled file name Spooled file number Output queue Output queue library Object IFS name PACKED(5 0) TIMESTAMP CHAR(7) CHAR(256) VARLEN(50) CHAR(26) CHAR(400) CHAR(10) CHAR(10) CHAR(10) CHAR(12) CHAR(63) CHAR(26) CHAR(10) PACKED(7 0) CHAR(10) CHAR(10) CHAR(1024) VARLEN(100) 1-7200 YYYY-MMDD.HH. BLANK User-defined name. *NONE. BLANK User-defined name. BLANK SPLF JOB 625 . BLANK User-defined name. BLANK 1-99999. BLANK Valid message data. *NONE. BLANK User-defined name. BLANK TARGET SPLF User-defined name. BLANK 1-999999. BLANK User-defined name. BLANK JOB TARGET SPLF NUMBER TARGET OUTQ TARGET OUTQ LIBRARY TARGET IFS OBJECT RENAMED OBJECT LIBRARY Target system output queue CHAR(10) Target system output queue library Target system IFS name Renamed object library name CHAR(10) TGTIFS RNMOBJLIB CHAR(1024) VARLEN(100) CHAR(10) User-defined name. BLANK User-defined name. MXDGACTE outfile (WRKDGACTE command) Field CCSID Description Object CCSID Type. If unable to convert to job's CCSID or job CCSID is 65535. User-defined name. BLANK Three part spooled file name. BLANK 626 . BLANK User-defined name. related fields will be written in Unicode. BLANK User-defined name. length BIN(5 0) Valid values Default to job CCSID. BLANK Column headings CCSID TGTOBJLIB Target system object library name Target system object name Target system object member name Target system DLO name Target system object folder name Target system spooled file job name Target system spooled file name Target system spooled file job number CHAR(10) TARGET OBJECT LIBRARY TARGET OBJECT TARGET MEMBER TARGET DLO TARGET FOLDER TGTOBJ TGTOBJMBR TGTDLO TGTFLR TGTSPLFJOB TGTSPLF TGTSPLFNBR TGTOUTQ TGTOUTQLIB CHAR(10) CHAR(10) CHAR(12) CHAR(63) CHAR(26) CHAR(10) PACKED(7 0) User-defined name. BLANK User-defined name.MXDGACTE outfile (WRKDGACTE command) Table 129. BLANK Column headings RENAMED OBJECT RENAMED MEMBER RENAMED DLO RENAMED FOLDER Three part spooled file name. length CHAR(10) CHAR(10) CHAR(12) CHAR(63) CHAR(26) Valid values User-defined name. MXDGACTE outfile (WRKDGACTE command) Field RNMOBJ RNMOBJMBR RNMDLO RNMFLR RNMSPLFJOB RNMSPLF RNMSPLFNBR Description Renamed object name Renamed object member name Renamed DLO name Renamed object folder name Renamed spooled file job name Type. BLANK RNMIFS RNMOBJLIB CHAR(1024) VARLEN(100) CHAR(10) User-defined name. BLANK RENAMED SPLF JOB User-defined name. BLANK 627 . BLANK RENAMED SPLF NAME RENAMED SPLF NUMBER RENAMED OUTQ RENAMED OUTQ LIBRARY RENAMED IFS OBJECT RENAMED TGT OBJECTS LIBRARY RENAMED TARGET OBJECT Renamed spooled file name CHAR(10) Renamed spooled file number Renamed output queue Renamed output queue library Renamed IFS object name Renamed target object library name PACKED(7 0) RNMOUTQ RNMOUTQLIB CHAR(10) CHAR(10) User-defined name. BLANK RNMTGTOBJ Renamed target object name CHAR(10) User-defined name. BLANK User-defined name.MXDGACTE outfile (WRKDGACTE command) Table 129. BLANK User-defined name. BLANK User-defined name. BLANK User-defined name. BLANK User-defined name. BLANK 1-999999. BLANK User-defined name. BLANK RNMTOUTQL CHAR(10) User-defined name. BLANK RENAMED TARGET SPLF NAME RENAMED TARGET SPLF NUMBER RENAMED TARGET OUTQ RENAMED TARGET OUTQ LIBRARY RENAMED TARGET IFS OBJECT COOPERATE WITH DATABASE IFS OBJECT FID (Binary) 628 RNTTGTSPLF CHAR(10) RNMTSPLFN PACKED(7 0) 1-999999. BLANK RNMTGTIFS Renamed target object IFS name Cooperate with DB CHAR(1024) VARLEN(100) CHAR(10) User-defined name. MXDGACTE outfile (WRKDGACTE command) Field RNMTOBJMBR Description Renamed target object member name Renamed target object DLO name Renamed target object folder name Renamed target spooled file job name Renamed target spooled file name Renamed target spooled file number Renamed target output queue Renamed target output queue library Type.MXDGACTE outfile (WRKDGACTE command) Table 129. BLANK RENAMED TARGET SPLF JOB User-defined name. BLANK Column headings RENAMED TARGET OBJ MEMBER RENAMED TARGET DLO RENAMED TARGET FOLDER RNMTGTDLO RNMTGTFLR CHAR(12) CHAR(63) User-defined name. *NO. length CHAR(10) Valid values User-defined name. BLANK RNMTGTOUTQ CHAR(10) User-defined name. BLANK RNMTSPLFJ CHAR(26) Three part spooled file name. BLANK COOPDB *YES. BLANK OBJFID IFS object file identifier (binary format) BIN(16) Binary representation of file identifier . BLANK Column headings IFS OBJECT FID (Hex) IFS Object (UNICODE) TGT IFS Object (UNICODE) RNM IFS Object (UNICODE) RNM TGT IFS Object (UNICODE) TGTIFSUCS TGT IFS Object (UNICODE) GRAPHIC(512) VARLEN(75) CCSID(13488) RNM IFS Object (UNICODE) RNM TGT IFS Object (UNICODE) GRAPHIC(512) VARLEN(75) CCSID(13488) GRAPHIC(512) VARLEN(75) CCSID(13488) RNMIFSUCS RNMTGTIFSU 629 . BLANK User-defined name (Unicode). MXDGACTE outfile (WRKDGACTE command) Field OBJFIDHEX IFSUCS Description IFS object file identifier (character format) IFS Object (UNICODE) Type. BLANK User-defined name (Unicode). length CHAR(32) GRAPHIC(512) VARLEN(75) CCSID(13488 Valid values Character representation of file identifier User-defined name (Unicode). BLANK User-defined name (Unicode).MXDGACTE outfile (WRKDGACTE command) Table 129. MXDGACTE outfile (WRKDGACTE command) 630 . MXDGDAE outfile (WRKDGDAE command) Field DGDFN DGSYS1 DGSYS2 DTAARA1 DTAARALIB1 Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) System 1 data area System 1 data area library Type. length CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) Valid values User-defined data group name User-defined system name User-defined system name User-defined name. *YES 631 .MXDGDAE outfile (WRKDGDAE command) MXDGDAE outfile (WRKDGDAE command) Table 130. *ALL User-defined name Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 SYSTEM 1 DATA AREA SYSTEM 1 DATA AREA LIBRARY SYSTEM 2 DATA AREA SYSTEM 2 DATA AREA LIBRARY DESCRIPTION RETRIEVE ERROR FIELD DTAARA2 DTAARALIB2 System 2 data area System 2 data area library CHAR(10) CHAR(10) User-defined name. *ALL User-defined name TEXT RTVERR Description Retrieve error field CHAR(50) CHAR(10) User-defined text *NO. *NO *DGDFN. *DGDFN User-defined name. blank Column Headings DGDFN NAME DGDFN NAME SYSTEM 1 DGDFN NAME SYSTEM 2 DGDFN SHORT NAME DATA SOURCE ALLOW SWITCH DG TYPE CONFIGURED PRITFRDFN CONFIGURED SECTFRDFN DB READER WAITTIME JOURNAL ON TARGET CONFIGURED SYSTEM 1 JRNDFN ACTUAL SYSTEM 1 JRNDFN JRNDFN SYSTEM 2 JRNDFN1NM Actual system 1 journal definition name CHAR(10) JRNDFN2SYS System 2 journal definition system name CHAR(8) User-defined name. user-defined name. *SYS2 *YES.MXDGDFN outfile (WRKDGDFN command) MXDGDFN outfile (WRKDGDFN command) Table 131. *NONE User-defined name. MXDGDFN outfile (WRKDGDFN command) Field DGDFN DGSYS1 DGSYS2 DGSHRTNM DTASRC ALWSWT DGTYPE PRITFRDFN SECTFRDFN RDRWAIT JRNTGT JRNDFN1 Description Data group definition name (Data group definition) System 1 (Data group definition) System 2 (Data group definition) Data group short name Data source Allow to be switched Data group type Configured primary transfer definition Secondary transfer definition Reader wait time (seconds) Journal on target Configured system 1 journal definition Type. length CHAR(10) CHAR(8) CHAR(8) CHAR(3) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) PACKED(5 0) CHAR(10) CHAR(10) Valid values User-defined data group name User-defined system name User-defined system name Short data group name *SYS1. *OBJ. blank 632 . *NONE 0-600 *YES. *NO *ALL. *DB User-defined name. 999999 (0=*NONE) 0 . *SEND *BLANK. *NO 1-6 RQSDBAPY Requested number of DB apply sessions PACKED(3 0) 1-6 DBBFRIMG Before images (DB journal entry processing) CHAR(10) *IGNORE.MXDGDFN outfile (WRKDGDFN command) Table 131. blank *YES. MXDGDFN outfile (WRKDGDFN command) Field JRNDFN2 Description Configured system 2 journal definition Type. user-defined name. *NONE User-defined name. *SEND DBNOTUSED TEXT SYNCCHKITV TSPITV CHAR(10) CHAR(50) PACKED(5 0) PACKED(5 0) *IGNORE. length CHAR(10) Valid values *DGDFN. *SEND DBMMXGEN CHAR(10) *IGNORE.999999 (0=*NONE) 633 . blank Column Headings CONFIGURED SYSTEM 2 JRNDFN ACTUAL SYSTEM 2 JRNDFN JRNDFN SYSTEM 2 RJ LINK CURRENT NUMBER OF DB APPLIES REQUESTED NUMBER OF DB APPLIES DBJRNPRC BEFORE IMAGES DBJRNPRC FILES NOT IN DG DBJRNPRC GEN’D BY MIMIX ACT DBJRNPRC NOT USED BY MIMIX DESCRIPTION SYNC CHECK INTERVAL TIME STAMP INTERVAL JRNDFN2NM Actual system 2 journal definition name CHAR(10) JRNDFN2SYS RJLNK NBRDBAPY System 2 journal definition system name User remote journal link Number of DB apply sessions CHAR(8) CHAR(10) PACKED(3 0) User-defined name. *SEND DBNOTINDG For files not in data group (DB journal entry processing) Generated by MIMIX activity (DB journal entry processing) Not used by MIMIX (DB journal entry processing) Description Synchronization check interval Time stamp interval CHAR(10) *IGNORE. user-defined text 0 . A-F *HLDERR. userdefined name 634 . *NO *ANY.MXDGDFN outfile (WRKDGDFN command) Table 131. *YES *POSITION. *AUTOSYNC. *NO User-defined name. *KEYED DFTAPYLOCK DFTAPYSSN DFTCRCLS Lock member during apply (File entry options) Configured apply session (File entry options) Collision resolution (File entry options) CHAR(10) CHAR(10) CHAR(10) *YES. length PACKED(5 0) PACKED(5 0) Valid values 1000-999999 1-7200 Column Headings VERIFICATION INTERVAL DATA AREA POLLING INTERVAL NUMBER OF RETRIES FIRST RETRY INTERVAL SECOND RETRY INTERVAL USE ADAPTIVE CACHE DATA CRG FEOPT JOURNAL IMAGES FEOPT OMIT OPEN CLOSE FEOPT REPLICATION TYPE FEOPT LOCK MBR ON APPLY FEOPT CFG APPY SESSION FEOPT COLLISION RESOLUTION RTYNBR RTYDLYITV1 RTYDLYITV2 Number of times to retry First retry delay interval Second retry delay interval PACKED(3 0) PACKED(5 0) PACKED(5 0) 0-999 1-3600 10-7200 ADPCHE DATACRG DFTJRNIMG Adaptive cache Data cluster resource group Journal image (File entry options) CHAR(10) CHAR(10) CHAR(10) *YES. *NONE *AFTER. blank. *BOTH DFTOPNCLO DFTREPTYPE Omit open / close entries (File entry options) Replication type (File entry options) CHAR(10) CHAR(10) *NO. MXDGDFN outfile (WRKDGDFN command) Field VFYITV DTAARAITV Description Verify interval Data area polling interval Type. MXDGDFN outfile (WRKDGDFN command) Table 131. *OPTIMIZED 635 . *SAVRST OBJIFSMTH IFS transmission method (Object processing) CHAR(10) *SAVRST. 100-9999999 DBAPYHST DBKEEPLOG DBLOGSIZE Apply history log spaces (Database apply processing) Keep journal log spaces (Database apply processing) Size of log spaces (MB) (Database apply processing) Object default owner (Object processing) PACKED(5 0) PACKED(5 0) PACKED(5 0) 0-9999 0-9999 1-16 OBJDFTOWN CHAR(10) User-defined name OBJDLOMTH DLO transmission method (Object processing) CHAR(10) *OPTIMIZED. length CHAR(10) CHAR(10) Valid values *YES. *NO *YES Column Headings FEOPT DISABLE TRIGGERS FEOPT PROCESS CONSTRAINT DBAPYPRC FORCE DATA DBAPYPRC MAX OPEN MEMBERS DBAPYPRC THRESHOLD WARNING DBAPYPRC HISTORY DBAPYPRC KEEP JRN DBAPYPRC SIZE OF LOG SPACES OBJPRC DEFAULT OWNER OBJPRC DLO TRANSFER METHOD OBJPRC IFS TRANSFER METHOD DBFRCITV DBMAXOPN Force data interval (Database apply processing) Maximum open members (Database apply processing) Threshold warning (Database apply processing) PACKED(5 0) PACKED(5 0) 1-99999 50 . MXDGDFN outfile (WRKDGDFN command) Field DFTSBTRG DFTPRCCST Description Disable triggers during apply (File entry options) Process constraint entries (File entry options) Type.32767 DBAPYTWRN PACKED(7 0) 0. *DISABLE Column Headings OBJPRC USER PROFILE STATUS OBJPRC KEEP DELETED SPLF OBJPRC KEEP DLO SYS NAME OBJRTVPRC DELAY OBJRTVPRC MIN NUMBER OF JOBS OBJRTVPRC MAX NUMBER OF JOBS OBJRTVPRC THLD FOR MORE JOBS CNRSNDPRC MIN NUMBER OF JOBS CNRSNDPRC MAX NUMBER OF JOBS CNRSNDPRC THLD FOR MORE JOBS OBJKEEPSPL Keep deleted spooled files (Object processing) CHAR(10) *YES. *TGT.MXDGDFN outfile (WRKDGDFN command) Table 131. *NO OBJKEEPDLO Keep DLO System Name (Object Processing) CHAR(10) *YES. *ENABLE. *NO OBJRTVDLY OBJRTVMINJ Retrieve delay (Object retrieve processing) Minimum number of jobs (Object retrieve processing) Maximum number of jobs (Object retrieve processing) Threshold for more jobs (Object retrieve processing) Minimum number of jobs (Container send processing) Maximum number of jobs (Container send processing) Threshold for more jobs (Container send processing) PACKED(3 0) PACKED(3 0) 0-999 1-99 OBJRTVMAXJ PACKED(3 0) 1-99 OBJRTVTHLD PACKED(5 0) 1-99999 CNRSNDMINJ PACKED(3 0) 1-99 CNRSNDMAXJ PACKED(3 0) 1-99 CNRSNDTHLD PACKED(5 0) 1-99999 636 . MXDGDFN outfile (WRKDGDFN command) Field OBJUSRSTS Description User profile status (Object processing) Type. length CHAR(10) Valid values *SRC. MXDGDFN outfile (WRKDGDFN command) Table 131. MXDGDFN outfile (WRKDGDFN command) Field OBJAPYMINJ Description Type, length Valid values 1-99 Column Headings OBJAPYPRC MIN NUMBER OF JOBS OBJAPYPRC MAX NUMBER OF JOBS OBJAPYPRC THLD FOR MORE JOBS OBJAPYPRC THLD FOR WARNING MSGS USRPRF FOR SUBMIT JOB SEND JOBD SEND JOBD LIBRARY APPLY JOBD APPLY JOBD LIBRARY REORGANIZE JOBD REORGANIZE JOBD LIBRARY SYNC JOBD SYNC JOBD LIBRARY Minimum number of jobs (Object apply processing) PACKED(3 0) OBJAPYMAXJ Maximum number of jobs (Object apply processing) PACKED(3 0) 1-99 OBJAPYTHLD Threshold for more jobs (Object apply processing) PACKED(5 0) 1-99999 OBJAPYTWRN Threshold for warning messages (Object apply processing) PACKED(5 0) 0, 50-99999 (0 = *NONE) SBMUSR SNDJOBD SNDJOBDLIB APYJOBD APYJOBDLIB RGZJOBD RGZJOBDLIB SYNJOBD SYNJOBDLIB User profile for submit job Send job description Send job description library Apply job description Apply job description library Reorganize job description Reorganize job description library Synchronize job description Synchronize job description library CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) *JOBD, *CURRENT Job description name Job description library Job description name Job description library Job description name Job description library Job description name Job description library 637 MXDGDFN outfile (WRKDGDFN command) Table 131. MXDGDFN outfile (WRKDGDFN command) Field SAVACT Description Save while active (seconds) Type, length PACKED(5 0) Valid values -1, 0, 1-999999 (0 = Save while active for files only with a 120 second wait time) (-1 = No save while active) (1-99999 = Save while active for all object types with specified wait time) 000000 - 235959, *NONE, *SYSDFN1, *SYSDFN2 000000 = midnight (default) *NONE, User-defined name *NONE, User-defined name *SYSJRN, *USRJRN *NONE, *ALLAPY 0-99999 *DFT, *YES, *NO 0-9999 (0 = *NONE) Column Headings SAVE WHILE ACTIVE (SEC) RSTARTTIME Restart Time CHAR((8) RESTART TIME ASPGRP1 ASPGRP2 COOPJRN RCYWINPRC RCHWINDUR JRNATCRT RJLNKTHLDM System 1 ASP group System 2 ASP group Cooperative Journal Recovery Window Process Recovery Window Duration Journal at creation RJ Link Threshold (Time in minutes) CHAR(10) CHAR(10) CHAR(10) CHAR (7) PACKED (5 0) CHAR(10) PACKED(4 0) SYSTEM 1 ASP GROUP SYSTEM 2 ASP GROUP COOPERATIVE JOURNAL RECOVERY PROCESS RECOVERY DURATION JOURNAL AT CREATION RJLNK THRESHOLD (TIME IN MIN) RJLNK THRESHOLD (NBR OF JRNE) DBSND/DBRDR THRESHOLD (TIME IN MIN) RJLNKTHLDE RJ Link Threshold (Number of journal entries) PACKED(7 0) 0, 1000-9999999 (0 = *NONE) DBSNDTHLDM DB Send/Reader Threshold (Time in minutes) PACKED(4 0) 0-9999 (0 = *NONE) 638 MXDGDFN outfile (WRKDGDFN command) Table 131. MXDGDFN outfile (WRKDGDFN command) Field DBSNDTHLDE Description DB Send/Reader Threshold (Number of journal entries) Object Send Threshold (Time in minutes) Type, length PACKED(7 0) Valid values 0, 1000-9999999 (0 = *NONE) Column Headings DBSND/DBRDR THRESHOLD (NBR OF JRNE) OBJSND THRESHOLD (TIME IN MIN) OBJSND THRESHOLD (NBR OF JRNE) OBJRTV THRESHOLD CNRSND THRESHOLD OBJSNDTHDM PACKED(4 0) 0-9999 (0 = *NONE) OBJSNDTHDE Object Send Threshold (Number of journal entries) PACKED(7 0) 0, 1000-9999999 (0 = *NONE) OBJRTVTHDE CNRSNDTHDE Object Retrieve Threshold (Number of activity entries) Container Send Threshold (Number of activity entries) PACKED(5 0) PACKED(5 0) 0, 50-99999 (0 = *NONE) 0, 50-99999 (0 = *NONE) 639 MXDGDLOE outfile (WRKDGDLOE command) MXDGDLOE outfile (WRKDGDLOE command) Table 132. MXDGDLOE outfile (WRKDGDLOE command) Field DGDFN DGSYS1 Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) System 1 folder System 1 document Owner System 2 folder System 2 document Object auditing value Type, length CHAR(10) CHAR(8) Valid values User-defined data group name User-defined system name Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 SYSTEM 1 FOLDER SYSTEM 1 DLO OWNER SYSTEM 2 FOLDER SYSTEM 2 DLO OBJECT AUDITING VALUE PROCESS TYPE OBJRTVP RC DELAY DGSYS2 CHAR(8) User-defined system name FLR1 DOC1 OWNER FLR2 DOC2 OBJAUD CHAR(63) CHAR(12) CHAR(10) CHAR(63) CHAR(12) CHAR(10) User-defined name User-defined name, *ALL User-defined name, *ALL *FLR1, User-defined name *DOC1, User-defined name *CHANGE, *ALL, *NONE PRCTYPE Process type CHAR(10) *INCLD, *EXCLD OBJRTVDLY Retrieve delay (Object retrieve processing) PACKED(3 0) 0-999, *DGDFT 640 MXDGDLOE outfile (WRKDGDLOE command) 641 MXDGFE outfile (WRKDGFE command) MXDGFE outfile (WRKDGFE command) Table 133. MXDGFE outfile (WRKDGFE command) Field DGDFN DGSYS1 DGSYS2 FILE1 LIB1 MBR1 FILE2 LIB2 MBR2 TEXT JRNIMG Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) System 1 file name System 1 library name Type, length CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) Valid values User-defined data group name User-defined system name User-defined system name User-defined name User-defined name User-defined name User-defined name User-defined name User-defined name User-defined text *AFTER, *BOTH, *DGDFT Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 SYSTEM 1 FILE SYSTEM 1 LIBRARY SYSTEM 1 MEMBER SYSTEM 2 FILE SYSTEM 2 LIBRARY SYSTEM 2 MEMBER DESCRIPTION FEOPT JOURNAL IMAGE FEOPT OMIT OPEN CLOSE System 1 member name CHAR(10) System 2 file name System 2 library name CHAR(10) CHAR(10) System 2 member name CHAR(10) Description Journal image (File entry options) Omit open/close entries (File entry options) CHAR(50) CHAR(10) OPNCLO CHAR(10) *YES, *NO, *DGDFT 642 MXDGFE outfile (WRKDGFE command) Table 133. MXDGFE outfile (WRKDGFE command) Field REPTYPE Description Replication type (File entry options) Type, length CHAR(10) Valid values *POSITION, *KEYED, *DGDFT Column headings FEOPT REPLICATION TYPE FEOPT LOCK MBR ON APPLY FEOPT FILTER BFR IMAGE FEOPT CURRENT APYSSN FEOPT REQUESTED APYSSN FEOPT COLLISION RESOLUTION FEOPT DISABLE TRIGGERS FEOPT PROCESS TRIGGERS FEOPT PROCESS CONSTRAINTS CURRENT STATUS APYLOCK Lock member during CHAR(10) apply (File entry options) CHAR(10) CHAR(10) *YES, *NO, *DGDFT FTRBFRIMG Filter before image (File entry options) APYSSN Current apply session (File entry options) Configured or requested apply session (File entry options) *YES, *NO, *DGDFT A-F, *DGDFT RQSAPYSS N CRCLS CHAR(10) A-F, *DGDFT Collision resolution class CHAR(10) (File entry options) Disable triggers during CHAR(10) apply (File entry options) Process trigger entries (File entry options) Process constraint entries (File entry options) File status CHAR(10) *HLDERR, *AUTOSYNC, userdefined name *YES, *NO, *DGDFT DSBTRG PRCTRG *YES, *NO, *DGDFT PRCCST CHAR(10) *YES STATUS CHAR(10) *ACTIVE, *RLSWAIT, *RLSCLR, *HLD, *HLDIGN, *RLS, *HLDRGZ, *HLDPRM, *HLDRNM, *HLDSYNC, *HLDRTY, *HLDERR, *HLDRLTD, *CMPACT, *CMPRLS, *CMPRPR 643 MXDGFE outfile (WRKDGFE command) Table 133. MXDGFE outfile (WRKDGFE command) Field RQSSTS JRN1STS JRN2STS ERRCDE JECDE JETYPE Description Requested file status System 1 journaled System 2 journaled Error code Journal entry code Journal entry type Type, length CHAR(10) CHAR(10) CHAR(10) CHAR(2) CHAR(1) CHAR(2) Valid values *ACTIVE, *HLD, *HLDIGN, *RLS, *RLSWAIT *YES, *NO, *NA *YES, *NO, *NA Valid error codes Valid journal entry code Valid journal entry type Column headings REQUESTED STATUS SYSTEM 1 JOURNALED SYSTEM 2 JOURNALED ERROR CODE JOURNAL ENTRY CODE JOURNAL ENTRY TYPE 644 MXDGFE outfile (WRKDGFE command) 645 MXDGIFSE outfile (WRKDGIFSE command) MXDGIFSE outfile (WRKDGIFSE command) Table 134. MXDGIFSE outfile (WRKDGIFSE command) Field DGDFN DGSYS1 DGSYS2 OBJ1 OBJ2 CCSID Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) System 1 object System 2 object Object CCSID Type, length CHAR(10) CHAR(8) CHAR(8) CHAR(1024) CHAR(1024) BIN(5 0) Valid values User-defined data group name User-defined system name User-defined system name User-defined name *OBJ1, user-defined name Defaults to job CCSID. If job CCSID is 65535 or data cannot be converted to job CCSID, OBJ1 and OBJ2 values remain in Unicode *INCLD, *EXCLD *DIR, *STMF, *SYMLNK 0-999, *DGDFT *YES, *NO, blank Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 SYSTEM 1 IFS OBJECT SYSTEM 2 IFS OBJECT CCSID PRCTYPE TYPE OBJRTVDLY COOPDB Process type Object type Retrieve delay (Object retrieve processing) Cooperate with database CHAR(10) CHAR(10) CHAR(10) CHAR(10) PROCESS TYPE OBJECT TYPE OBJRTVPRC DELAY COOPERATE WITH DATABASE OBJECT AUDITING VALUE OBJAUD Object auditing CHAR(10) *NONE, *CHANGE, *ALL 646 MXDGIFSE outfile (WRKDGIFSE command) 647 MXDGSTS outfile (WRKDG command) MXDGSTS outfile (WRKDG command) The MXDGSTS outfile contains status information which corresponds to fields shown in the following interfaces: • • MIMIX Availability Manager: the data group detail status displays 5250 emulator: Work with Data Groups (WRKDG) command The Work with Data Groups (WRKDG) command generates new outfiles based on the MXDGSTSF record format from the MXDGSTS model database file supplied with MIMIX. The content of the outfile is based on the criteria specified on the command. If there are no differences found, the file is empty. Usage notes: • When the value *UNKNOWN is returned for either the Data group source system status (DTASRCSTS) field or the Data group target system status (DTATGTSTS), status information is not available from the system that is remote relative to where the request was made. For example, if you requested the report from the target system and the value returned for DTASRCSTS is *UNKNOWN, the WRKDG request could not communicate with the source system. Fields which rely on data collected from the remote system will be blank. If a data group is configured for only database or only object replication, any fields associated with processes not used by the configured type of replication will be blank. See “WRKDG outfile SELECT statement examples” on page 670 for examples of how to query the contents of this output file. You can automate the process of gathering status. If you use MIMIX Monitor to create a synchronous interval monitor, the monitor can specify the command to generate the outfile. Through exit programs, you can program the monitor to take action based on the status returned in the outfile. For information about creating interval monitors, see the Using MIMIX Monitor book. • • • Table 135. MXDGSTS outfile (WRKDG command) Field ENTRYTSP DGDFN DGSYS1 Description Entry timestamp Data group definition name (Data group definition) System 1 (Data group definition) Type, length TIMESTAMP CHAR(10) CHAR(8) Valid values SAA format: YYYY-MM-DD-hh.mm.ss.mmmuuu User-defined data group name User-defined system name Column headings TIME REQUEST PROCESSED DGDFN NAME DGDFN SYSTEM 1 648 MXDGSTS outfile (WRKDG command) Table 135. MXDGSTS outfile (WRKDG command) Field DGSYS2 STSTIME STSTIMF STSAVAIL Description System 2 (Data group definition) Elapsed time for data group status (seconds) Elapsed time for data group status (HHH:MM:SS) Data group status retrieved from these systems Data group source system Data group source system status Data group target system Data group target system status Switch mode status for system 1 Type, length CHAR(8) PACKED(10 0) CHAR(10) CHAR(10) Valid values User-defined system name Calculated, 0-9999999999 Calculated, 0-9999999 *ALL, *SOURCE, *TARGET, *NONE Column headings DGDFN SYSTEM 2 ELAPSED TIME ELAPSED TIME (HHH:MM:SS) SYS STATUS RETRIEVED FROM DG SOURCE SYSTEM DG SOURCE STATUS DG TARGET SYSTEM DG TARGET STATUS SYSTEM 1 SWITCH STATUS SYSTEM 2 SWITCH STATUS OVERALL DG STATUS CONFIGURED FOR DB REPLICATION CONFIGURED FOR OBJECT REPLICATION DTASRC DTASRCSTS DTATGT DTATGTSTS SWTSTS1 CHAR(8) CHAR(10) CHAR(8) CHAR(10) CHAR(10) User-defined system name *ACTIVE, *INACTIVE, *UNKNOWN User-defined system name *ACTIVE, *INACTIVE, *UNKNOWN *NONE, *SWITCH SWTSTS2 Switch mode status for system 2 CHAR(10) *NONE, *SWITCH DGSTS DBCFG Data group status summary Data group configured for data base replication Data group configured for object replication CHAR(10) CHAR(10) BLANK, *ERROR, *WARNING, *DISABLED *YES, *NO OBJCFG CHAR(10) *YES, *NO 649 MXDGSTS outfile (WRKDG command) Table 135. MXDGSTS outfile (WRKDG command) Field SRCSYSSTS Description Source system manager status summation (system manager Database send process status summation (DBSNDPRC) Object send process status summation (OBJSNDPRC) Data area polling process status (DTAPOLLPRC) Target System manager status summation (system manager plus journal manager status) Database apply status summation (Apply sessions A-F) Object apply status summation Total database file entries Active database file entries (FEACT) Inactive database file entries Database file entries not journaled on source Database file entries not journaled on target Database file entries held due to error Type, length CHAR(10) Valid values *ACTIVE, *INACTIVE, *UNKNOWN Column headings SOURCE MANAGER SUMMATION DB SEND STATUS OBJECT SEND STATUS DATA AREA POLLER STATUS TARGET MANAGER SUMMATION DB APPLY SUMMATION OBJECT APPLY SUMMATION TOTAL DB FILE ENTRIES ACTIVE DB FILE ENTRIES INACTIVE DB FILE ENTRIES FILES NOT JOURNALED ON SOURCE FILES NOT JOURNALED ON TARGET FILES HELD FOR ERRORS DBSNDSTS OBJSNDSTS DTAPOLLSTS CHAR(10) CHAR(10) CHAR(10) *ACTIVE, *INACTIVE, *UNKNOWN, *NONE, *THRESHOLD *ACTIVE, *INACTIVE, *UNKNOWN, *NONE, *THRESHOLD *ACTIVE, *INACTIVE, *UNKNOWN, *NONE TGTSYSSTS CHAR(10) *ACTIVE, *INACTIVE, *UNKNOWN DBAPYSTS OBJAPYSTS FECNT FEACTIVE FENOTACT FENOTJRNS CHAR(10) CHAR(10) PACKED(5 0) PACKED(5 0) PACKED(5 0) PACKED(5 0) *ACTIVE, *INACTIVE, *PARTIAL, *UNKNOWN, *NONE, *THRESHOLD *ACTIVE, *INACTIVE, *PARTIAL, *UNKNOWN, *NONE, *THRESHOLD 0-99999 0-99999 0-99999 0-99999 FENOTJRNT PACKED(5 0) 0-99999 FEHLDERR PACKED(5 0) 0-99999 650 length PACKED(5 0) PACKED(5 0) Valid values 0-99999 0-99999 Column headings FILES HELD FOR OTHER OBJECTS PENDING ON SOURCE SYSTEM OBJECTS PENDING ON TARGET SYSTEM TOTAL OBJECTS DELAYED TOTAL OBJECTS IN ERROR DLO CONFIG CHANGED IFS CONFIG CHANGED OBJECT CONFIG CHANGED PRIMARY TFRDFN SECONDARY TFRDFN LAST USED TFRDFN OBJPENDAPY Objects in pending status.MXDGSTS outfile (WRKDG command) Table 135. MXDGSTS outfile (WRKDG command) Field FEHLDOTHR OBJPENDSRC Description Database file entries held for other reasons (FEHLD) Objects in pending status. *NO *YES. *NO *YES. target system PACKED(5 0) 0-99999 OBJDELAY Objects in delayed status PACKED(5 0) 0-99999 OBJERR Objects in error PACKED(5 0) 0-99999 DLOCFGCHG IFSCFGCHG OBJCFGCHG DLO configuration changed IFS configuration changed Object configuration changed CHAR(10) CHAR(10) CHAR(10) *YES. *NO PRITFRDFN SECTFRDFN TFRDFN Primary transfer definition Secondary transfer definition Current transfer definition CHAR(10) CHAR(10) CHAR(10) User-defined transfer definition name User-defined transfer definition name User-defined transfer definition name 651 . source system Type. *INACTIVE. *UNKNOWN CNRSNDSTS OBJRTVSTS Container send process status Object retrieve process status CHAR(10) CHAR(10) *ACTIVE.MXDGSTS outfile (WRKDG command) Table 135. *UNKNOWN SRCJRNSTS Source journal manager status CHAR(10) *ACTIVE. *UNKNOWN. *THRESHOLD *ACTIVE.mm. *THRESHOLD *ACTIVE. *PARTIAL.ss. *UNKNOWN TGTMGRSTS Target system manager status CHAR(10) TGTJRNSTS Target journal manager status CHAR(10) *ACTIVE. *NONE. *INACTIVE. *UNKNOWN.mmmuuu 652 . *INACTIVE Column headings LAST USED TFRDFN STATUS SOURCE SYS MANAGER STATUS SOURCE JRN MANAGER STATUS CONTAINER SEND STATUS OBJECT RETRIEVE STATUS TARGET SYS MANAGER STATUS TARGET JRN MANAGER STATUS DB JRNRCV DB JRNRCV LIBRARY DB ENTRY TYPE AND CODE DB ENTRY SEQUENCE DB ENTRY TIMESTAMP SRCMGRSTS CHAR(10) *ACTIVE. *INACTIVE. *INACTIVE. length CHAR(10) Valid values *ACTIVE. *PARTIAL. MXDGSTS outfile (WRKDG command) Field TFRSTS Description Current transfer definition communications status Source system manager status Type. *INACTIVE. *NONE. *UNKNOWN CURDBRCV CURDBLIB CURDBCODE Current database journal entry receiver name Current database journal entry receiver library name Current database journal code and entry type Current database journal entry sequence number Current database journal entry timestamp CHAR(10) CHAR(10) CHAR(3) User-defined value User-defined value Valid journal entry types and codes CURDBSEQ CURDBTSP PACKED(10 0) TIMESTAMP 0-9999999999 SAA format: YYYY-MM-DD-hh. *INACTIVE. mmmuuu RDDBTPH DBSNDBKLG DBSNBKTIME PACKED(15 0) PACKED(15 0) PACKED(10 0) Calculated.mm.MXDGSTS outfile (WRKDG command) Table 135. MXDGSTS outfile (WRKDG command) Field CURDBTPH RDDBRCV RDDBLIB Description Current database journal entry transactions per hour Last read database journal entry receiver name (DBSNTRCV) Last read database journal entry receiver library name Last read database journal code and entry type Last read database journal entry sequence number (DBSNTSEQ) Last read database journal entry timestamp (DBSNTDATE. 0-9999999999999 User-defined value User-defined value Column headings DB ARRIVAL RATE DB READER JRNRCV DB READER JRNRCV LIBRARY DB READER TYPE AND ENTRY CODE DB READER ENTRY SEQUENCE DB READER ENTRY TIMESTAMP DB READER READ RATE DB SEND BACKLOG DB SEND BACKLOG SECONDS DB SEND BACKLOG HHH:MM:SS DB LAST RECEIVED JRNRCV RDDBCODE CHAR(3) Valid journal entry types and codes RDDBSEQ PACKED(10 0) 0-9999999999 RDDBTSP TIMESTAMP SAA format: YYYY-MM-DD-hh. length PACKED(15 0) CHAR(10) CHAR(10) Valid values Calculated. 0-999:99:99 RCVDBRCV CHAR(10) User-defined value 653 . 0-9999999999 DBSNBKTIMF CHAR(10) Calculated.ss. 0-999999999999999 Calculated. DBSNTTIME) Last read database journal entry transactions per hour Number of database entries not sent Estimated time to process database entries not sent (seconds) Estimated time to process database entries not sent (HHH:MM:SS) Last received database journal entry receiver name Type. 0-999999999999999 Calculated. mm. 0-9999999999 Calculated. length CHAR(10) Valid values User-defined value Column headings DB LAST RECEIVED JRNRCV LIB DB LAST RCV TPE AND ENTRY DB LAST RECEIVED SEQUENCE DB LAST RECEIVED TIMESTAMP DB RECEIVE ARRIVAL RATE REQUESTED DB APPLY SESSIONS CONFIGURED DB APPLY SESSIONS ACTIVE DB APPLY SESSIONS DB APPLY BACKLOG DB APPLY TIME SECONDS DB APPLY TIME HHH:MM:SS RCVDBCODE CHAR(3) See the IBM OS/400 Backup and Recovery Guide for journal and entry types 0-9999999999 RCVDBSEQ PACKED(10 0) RCVDBTSP TIMESTAMP SAA format: YYYY-MM-DD-hh.ss. MXDGSTS outfile (WRKDG command) Field RCVDBLIB Description Last received database journal entry receiver library name Last received database journal code and entry type Last received database journal entry sequence number Last received database journal entry timestamp Last received database journal entry transactions per hour Number of database apply sessions requested Number of database apply sessions configured Number of database apply session currently active (DBAPYPRC) Type. 0-999999999999999 1-6 DBAPYMAX PACKED(5 0) 1-6 DBAPYACT PACKED(5 0) 1-6 DBAPYBKLG DBAPBKTIME DBAPBKTIMF Number of database entries not applied PACKED(15 0) Estimated time to process database entries not applied (seconds) Estimated time to process database entries not applied (HHH:MM:SS) PACKED(10 0) CHAR(10) Calculated. 0-999999999999999 Calculated.mmmuuu RCVDBTPH DBAPYREQ PACKED(15 0) PACKED(5 0) Calculated.MXDGSTS outfile (WRKDG command) Table 135. 0-999:99:99 654 . 655 . 0-999:99:99 DBATPH PACKED(15 0) Calculated. length PACKED(15 0) Valid values Calculated.MXDGSTS outfile (WRKDG command) Table 135. *THRESHOLD. 0-999999999999999 Calculated. *UNKNOWN 0-9999999999 DBAPRCSEQ PACKED(10 0) 0-9999999999 DBABKLG DBABKTIME PACKED(15 0) PACKED(10 0) Calculated. *INACTIVE. 0-999999999999999 Column headings DB APPLY PROCESSING RATE DB APPLY A STATUS DB APPLY A LAST RECEIVED DB APPLY A LAST PROCESSED DB APPLY A BACKLOG DB APPLY A TIME SECONDS DB APPLY A TIME HHH:MM:SS DB APPLY A PROCESSING RATE DB APPLY A COMMIT INDICATOR DB APPLY A CURRENT COMMIT ID DB APPLY A TYPE AND ENTRY DBASTS DBARCVSEQ CHAR(10) PACKED(10 0) *ACTIVE. 0-9999999999 DBABKTIMF CHAR(10) Calculated. 0-999999999999999 DBAOPNCMT CHAR(10) *YES. *NO DBACMTID CHAR(10) Journal-defined commit ID DBAAPYCODE CHAR(3) See the IBM OS/400 Backup and Recovery Guide for journal codes and entry types. MXDGSTS outfile (WRKDG command) Field DBAPYTPH Description Database apply total transactions per hour Database apply session A status Database apply session A last received sequence number Database apply session A last processed sequence number Database apply session A number of unprocessed entries Database apply session A estimated time to apply unprocessed transactions (seconds) Database apply session A estimated time to apply unprocessed transactions (HHH:MM:SS) Database apply session A number of transactions per hour Database apply session A open commit indicator Database apply session A oldest open commit ID Database apply session A last applied journal code and entry type Type. ‘F’). MXDGSTS outfile (WRKDG command) Field DBAAPYSEQ DBAAPYTSP Description Database apply session A last applied sequence number Database apply session A last applied journal entry timestamp Database apply session A object to which last transaction was applied Database apply session A library of object to which last transaction was applied Database apply session A member of object to which last transaction was applied. where x is database apply session ‘B’ . with ‘x’ DBAAPYOBJ DBAAPYLIB CHAR(10) CHAR(10) User-defined object name User-defined object library name DBAAPYMBR CHAR(10) User-defined object member name DBAAPYTIME PACKED(10 0) Calculated. 0-999:99:99 DBAHLDSEQ PACKED(10 0) 0-9999999999 DBxSTS through DBxHLDSEQ.‘F’ CUROBJRCV 885 bytes (5 x 177) All DBx field values match the DBA field values. Database apply session A last applied journal entry clock time difference (seconds) Database apply session A last applied journal entry clock time difference (HHH:MM:SS) Database apply session A hold MIMIX log sequence number Reserved for up to 5 additional database apply sessions (‘B’ . CHAR(10) User-defined value OBJECT JRNRCV 656 .mmmuuu Column headings DB APPLY A LAST APPLIED DB APPLY A LAST TIMESTAMP DB APPLY A OBJECT NAME DB APPLY A LIBRARY NAME DB APPLY A MEMBER NAME DB APPLY A TIME DIFF SECONDS DB APPLY A TIME DIFF HHH:MM:SS DB APPLY A HOLD SEQUENCE All DBx headings match the DBA headings.mm.MXDGSTS outfile (WRKDG command) Table 135.ss. 0-9999999999 DBAAPYTIMF CHAR(10) Calculated. Contains fields for each additional apply session which correspond to fields for apply session A (DBASTS through DBAHLDSEQ). Current object journal entry receiver name Type. length PACKED(10 0) TIMESTAMP Valid values 0-9999999999 SAA format: YYYY-MM-DD-hh. MXDGSTS outfile (WRKDG command) Table 135.mmmuuu RDOBJTPH PACKED(15 0) Calculated.mm.mmmuuu CUROBJTPH Current object journal entry transactions per hour Last read object journal entry receiver name (OBJSNTRCV) Last read object journal entry receiver library name Last read object journal code and entry type Last read object journal entry sequence number (OBJSNTSEQ) Last read object journal entry timestamp (OBJSNTDATE.mm.ss. 0-9999999999 CUROBJSEQ PACKED(10 0) CUROBJTSP TIMESTAMP SAA format: YYYY-MM-DD-hh. 0-999999999999999 657 .ss. 0-9999999999 RDOBJSEQ PACKED(10 0) RDOBJTSP TIMESTAMP SAA format: YYYY-MM-DD-hh. length CHAR(10) Valid values User-defined value Column headings OBJECT JRNRCV LIBRARY OBJECT TYPE AND ENTRY CODES OBJECT JOURNAL SEQUENCES OBJECT JRN ENTRY TIMESTAMP OBJECT ARRIVAL PER HOUR OBJRDRPRC JRNRCV OBJRDRPRC JRNRCV LIBRARY OBJRDRPRC TYPE AND ENTRY CODE OBJRDRPRC JOURNAL SEQUENCE OBJRDRPRC JRN ENTRY TIMESTAMP OBJRDRPRC READ RATE CUROBJCODE CHAR(3) See the IBM OS/400 Backup and Recovery Guide for journal codes and entry types. MXDGSTS outfile (WRKDG command) Field CUROBJLIB Description Current object journal entry receiver library name Current object journal code and entry type Current object journal entry sequence number Current object journal entry timestamp Type. OBJSNTTIME) Last read object journal entry transactions per hour PACKED(15 0) 0-999999999999999 RDOBJRCV RDOBJLIB CHAR(10) CHAR(10) User-defined value User-defined value RDOBJCODE CHAR(3) See the IBM OS/400 Backup and Recovery Guide for journal entry codes and entry types. MXDGSTS outfile (WRKDG command) Table 135. 0-9999999999 OBJSBKTIMF CHAR(10) Calculated. 0-999999999999999 PACKED(15 0)) Calculated. 0-999:99:99 RCVOBJRCV CHAR(10) User-defined value RCVOBJLIB CHAR(10) User-defined value RCVOBJCODE CHAR(3) See the IBM OS/400 Backup and Recovery Guide for journal codes and entry types. MXDGSTS outfile (WRKDG command) Field OBJSNDBKLG OBJSNDNUM Description Object entries not processed Number of object entries sent Type.ss. 0-9999999999 RCVOBJSEQ PACKED(10 0) RCVOBJTSP TIMESTAMP SAA format: YYYY-MM-DD-hh.mmmuuu RCVOBJTPH OBJRTVMIN PACKED(15 0) PACKED(3 0) 0-999999999999999 1-99 658 . 0-999999999999999 OBJSBKTIME Estimated time to process object entries not sent (seconds) Estimated time to process entries not sent (HHH:MM:SS) Last received object journal entry receiver name Last received object journal entry receiver library name Last received object journal code and entry type Last received object journal entry sequence number Last received object journal entry timestamp Last received object journal entry transactions per hour Minimum number of object retriever processes PACKED(10 0) Calculated. length Valid values Column headings OBJSNDPRC BACKLOG OBJSNDPRC SENT IN TIME SLICE OBJSNDPRC BACKLOG SECONDS OBJSNDPRC BACKLOG HHH:MM:SS OBJRCVPRC LAST RCVD JRNRCV OBJRCVPRC LAST RCVD JRNRCV LIB OBJRCVPRC LAST TYPE AND ENTRY OBJRCVPRC LAST ENTRY SEQUENCE OBJRCVPRC LAST ENTRY TIMESTAMP OBJRCVPRC RECEIVE RATE OBJRTVPRC MIN NUMBER OF JOBS PACKED(15 0)) Calculated.mm. OBJRTVTIME) Type of object last processed by object retrieve Qualified name of object last processed by object retrieve Minimum number of container send processes Active number of container send processes (CNRSNDPRC) Maximum number of container send processes Type. MXDGSTS outfile (WRKDG command) Field OBJRTVACT Description Active number of object retriever processes (OBJRTVPRC) Maximum number of object retriever processes Number of object retriever entries not processed Last processed object retrieve journal code and entry type Last processed object retrieve journal sequence number Last processed object retrieve journal entry timestamp (OBJRTVDATE.ss.MXDGSTS outfile (WRKDG command) Table 135. 0-9999999999 OBJRTVSEQ PACKED(10 0) OBJRTVTSP TIMESTAMP SAA format: YYYY-MM-DD-hh. length PACKED(3 0) Valid values 1-99 Column headings OBJRTVPRC NUMBER OF JOBS OBJRTVPRC MAX NUMBER OF JOBS OBJRTVPRC BACKLOG OBJRTVPRC LAST TYPE AND ENTRY OBJRTVPRC LAST SEQUENCE OBJRTVPRC LAST TIMESTAMP OBJRTVPRC LAST OBJ TYPE OBJRTVPRC LAST OBJ NAME CNRSNDPRC MIN NUMBER OF JOBS CNRSNDPRC NUMBER OF JOBS CNRSNDPRC MAX NUMBER OF JOBS OBJRTVMAX PACKED(3 0) 1-99 OBJRTVBKLG OBJRTVCODE PACKED(15 0) CHAR(3) 0-999999999999999 See the IBM OS/400 Backup and Recovery Guide for journal codes and entry types.mm.mmmuuu OBJRTVTYPE OBJRTVOBJ CHAR(10) CHAR(1024) Object type of user-defined object User-defined object name and path Note: Variable length of 75. CNRSNDMIN PACKED(3 0) 1-99 CNRSNDACT PACKED(3 0) 1-99 CNRSNDMAX PACKED(3 0) 1-99 659 . MXDGSTS outfile (WRKDG command) Table 135.mm. CNTRSNTTIME) Type of object last processed by container send Qualified name of object last processed by container send Minimum number of object apply processes Active number of object apply processes (OBJAPYPRC) Maximum number of object apply processes Number of object apply entries not processed Type. MXDGSTS outfile (WRKDG command) Field CNRSNDBKLG CNRSNDNUM CNRSNDCPH CNRSNDCODE Description Number of container send entries not processed Number of containers sent Containers per hour Last processed container send journal code and entry type Last processed container send journal sequence number (CNRSNTSEQ) Last processed container send journal entry timestamp (CNRSNTDATE. OBJAPYMIN PACKED(3 0) 1-99 OBJAPYACT PACKED(3 0) 1-99 OBJAPYMAX PACKED(3 0) 1-99 OBJAPYBKLG PACKED(15 0) Calculated. 0-999999999999999 660 . 0-9999999999 Column headings CNRSNDPRC BACKLOG CNRSNDPRC NUMBER SENT CNRSNDPRC RATE CNRSNDPRC LAST TYPE AND ENTRY CNRSNDPRC LAST SEQUENCE CNRSNDPRC LAST TIMESTAMP CNRSNDPRC LAST OBJ TYPE CNRSNDPRC LAST OBJ NAME OBJAPYPRC MIN NUMBER OF JOBS OBJAPYPRC NUMBER OF JOBS OBJAPYPRC MAX NUMBER OF JOBS OBJAPYPRC BACKLOG CNRSNDSEQ PACKED(10 0) CNRSNDTSP TIMESTAMP SAA format: YYYY-MM-DD-hh.ss. length PACKED(15 0) PACKED(15 0) PACKED(15 0) CHAR(3) Valid values 0-999999999999999 0-999999999999999 0-999999999999999 See the IBM OS/400 Backup and Recovery Guide for journal codes and entry types.mmmuuu CNRSNDTYPE CNRSNDOBJ CHAR(10) CHAR(1024) Object type of user-defined object User-defined object name and path Note: Variable length of 75. length PACKED(15 0) Valid values Calculated. RJINUSE CHAR(10) *YES.mmmuuu OBJAPYTYPE OBJAPYOBJ CHAR(10) CHAR(1024) Object type of user-defined object User-defined object name and path Note: Variable length of 75. *NO 661 . 0-999999999999999 OBJABKTIME Estimated time to process object entries not applied (seconds) Estimated time to process object entries not applied (HHH:MM:SS) Number of object entries applied per hour Last applied object journal code and entry type Last applied object journal sequence number (OBJAPYSEQ) Last applied object journal entry timestamp (OBJAPYDATE.mm. 0-999:99:99 OBJAPYTPH OBJAPYCODE PACKED(15 0) CHAR(3) Calculated.MXDGSTS outfile (WRKDG command) Table 135.ss. OBJAPYTIME) Type of object last processed by object apply Qualified name of object last processed by object apply Remote journal (RJ) link used by data group PACKED(10 0) Calculated. 0-999999999999999 Column headings OBJAPYPRC ACTIVE BACKLOG OBJAPYPRC APPLIED IN TIME SLICE OBJAPYPRC BACKLOG SECONDS OBJAPYPRC BACKLOG HHH:MM:SS OBJAPYPRC RATE OBJAPYPRC LAST TYPE AND ENTRY OBJAPYPRC LAST SEQUENCE OBJAPYPRC LAST TIMESTAMP OBJAPYPRC LAST OBJ TYPE OBJAPYPRC LAST OBJ NAME RJ LINK USED BY DG OBJAPYNUM Number of object entries applied PACKED(15 0) Calculated. 0-9999999999 OBJAPYSEQ PACKED(10 0) OBJAPYTSP TIMESTAMP SAA format: YYYY-MM-DD-hh. 0-999999999999999 See the IBM OS/400 Backup and Recovery Guide for journal codes and entry types. MXDGSTS outfile (WRKDG command) Field OBJAPYACTA Description Number of active objects Type. 0-9999999999 OBJABKTIMF CHAR(10) Calculated. *FAILED. MXDGSTS outfile (WRKDG command) Field RJSRCDFN Description RJ link source journal definition Type. *NOTBUILT. *UNKNOWN *ASYNC.MXDGSTS outfile (WRKDG command) Table 135. *ASYNPEND. BLANK RJDLVRY RJ link delivery mode CHAR(10) RJ LINK DELIVERY MODE RJ LINK SEND PRIORITY RJSNDPTY RJ link send task priority PACKED(3 0) 0-99 0=*SYSDFT 662 . length CHAR(10) Valid values User-defined journal definition name Column headings RJ LINK SOURCE JRNDFN RJ LINK SOURCE JRNDFN RJ LINK TARGET SYSTEM RJ LINK TARGET JRNDFN RJ PRIMARY RDB ENTRY RJ PRIMARY TFRDFN RJ SECONDARY RDB ENTRY RJ SECONDARY TFRDFN RJ LINK STATE RJSRCSYS RJ link source system CHAR(8) User-defined system name RJTGTDFN RJ link target journal definition CHAR(10) User-defined journal definition name RJTGTSYS RJ link target system CHAR(8) User-defined system name RJPRIRDB RJPRITFR RJSECRDB RJ link primary RDB entry RJ link primary transfer definition name RJ link secondary RDB entry CHAR(18) CHAR(10) CHAR(18) User-defined or MIMIX generated RDB name User-defined transfer definition name User-defined or MIMIX generated RDB name RJSECTFR RJ link secondary transfer definition name RJ link state CHAR(10) User-defined transfer definition name RJSTATE CHAR(10) BLANK. *SYNC. *SYNCPEND. *SYNC. *INACTPEND. *ASYNC. *CTLINACT. *ACTIVE. *UNKNOWN. *THRESHOLD BLANK. *INACTIVE. length CHAR(10) CHAR(10) CHAR(10) PACKED(10 0) Valid values BLANK. *UNKNOWN. *ACTIVE.MXDGSTS outfile (WRKDG command) Table 135. *INACTIVE BLANK. *INACTIVE 0-999999 Column headings RJREADER STATUS RJ SOURCE MONITOR RJ TARGET MONITOR TOTAL IFS TRACKING ENTRIES ACTIVE IFS TRACKING ENTRIES INACT IFS TRACKING ENTRIES IFS TE NOT JOURNALED ON SOURCE IFS TE NOT JOURNALED ON TARGET IFS TE HELD FOR ERRORS IFS TE HELD FOR OTHER TOTAL OBJ TRACKING ENTRIES ACTIVE OBJ TRACKING ENTRIES ITEACTIVE Active IFS tracking entries PACKED(10 0) 0-999999 ITENOTACT Inactive IFS tracking entries PACKED(10 0) 0-999999 ITENOTJRNS IFS tracking entries not journaled on source IFS tracking entries not journaled on target IFS tracking entries held due to error IFS tracking entries held for other reasons Total object tracking entries PACKED(10 0) 0-999999 ITENOTJRNT PACKED(10 0) 0-999999 ITEHLDERR ITEHLDOTHR OTECNT PACKED(10 0) PACKED(10 0) PACKED(10 0) 0-999999 0-999999 0-999999 OTEACTIVE Active object tracking entries PACKED(10 0) 0-999999 663 . *UNKNOWN. MXDGSTS outfile (WRKDG command) Field RJRDRSTS RJSMONSTS RJTMONSTS ITECNT Description RJ reader task status RJ link source monitor status RJ link target monitor status Total IFS tracking entries Type. *ACTIVE. *NOFEATURE. *NONE. *NO. *INACTIVE *ERROR. *UNKNOWN *ERROR. *NOFEATURE. *WARNING. MXDGSTS outfile (WRKDG command) Field OTENOTACT Description Inactive object tracking entries Type. *OK. *UNKNOWN JRNCACHESA Journal cache source CHAR(10) *YES. *NOFEATURE. *OK.source CHAR(10) JRNSTATETS Journal state target status CHAR(10) 664 . *OK. *UNKNOWN JRNCACHESS Journal cache status . *STANDBY. length PACKED(10 0) Valid values 0-999999 Column headings INACT OBJ TRACKING ENTRIES OBJ TE NOT JOURNALED ON SOURCE OBJ TE NOT JOURNALED ON TARGET OBJ TE HELD FOR ERRORS OBJ TE HELD FOR OTHER JOURNAL CACHE TARGET JOURNAL CACHE SOURCE JOURNAL STATE TARGET JOURNAL STATE SOURCE JRN CACHE TARGET STATUS JRN CACHE SOURCE STATUS JOURNAL STATE TARGET OTENOTJRNS Object tracking entries not journaled on source Object tracking entries not journaled on target PACKED(10 0) 0-999999 OTENOTJRNT PACKED(10 0) 0-999999 OTEHLDERR OTEHLDOTHR JRNCACHETA Object tracking entries held due to error PACKED(10 0) Object tracking entries held for other reasons Journal cache target PACKED(10 0) CHAR(10) 0-999999 0-999999 *YES. *NO. *UNKNOWN *ERROR.MXDGSTS outfile (WRKDG command) Table 135. *UNKNOWN JRNSTATETA JRNSTATESA JRNCACHETS Journal state target Journal state source Journal cache status .target CHAR(10) CHAR(10) CHAR(10) *ACTIVE. *INACTIVE *ACTIVE. *NONE. *WARNING. *NONE. *STANDBY. *WARNING. *NOFEATURE.Unicode Total database file entries Type.Unicode Qualified name of object last qualified by container send . *NONE.mm. length CHAR(10) CHAR(10) CHAR(10) Valid values *ERROR.mmmuuu User-defined object name and path CNRSNDUCS User-defined object name and path OBJAPYUCS User-defined object name and path FECNT2 0-9999999999 FEACTIVE2 Active database file entries (FEACT) PACKED(10 0) 0-9999999999 665 . MXDGSTS outfile (WRKDG command) Field JRNSTATESS RJTGTRCV RJTGTLIB Description Journal state source status Last RJ target journal entry receiver name Last RJ target journal entry receiver library name Last RJ target journal code and entry type Last RJ target journal entry sequence number Last RJ target journal entry timestamp Qualified name of object last qualified by object retrieve . *OK. *WARNING.ss.MXDGSTS outfile (WRKDG command) Table 135. *UNKNOWN User-defined value User-defined value Column headings JOURNAL STATE SOURCE RJ TGT JRNRCV RJ TGT JRNRCV LIBRARY RJTGT TYPE AND ENTRY CODE RJ TGT ENTRY SEQUENCE RJ TGT ENTRY TIMESTAMP LAST OBJ RETRIEVED (UNICODE) LAST OBJ SENT (UNICODE) LAST OBJ APPLIED (UNICODE) TOTAL DB FILE ENTRIES2 ACTIVE DB FILE ENTRIES2 RJTGTCODE CHAR(3) Valid journal entry types and codes RJTGTSEQ RJTGTTSP OBJRTVUCS PACKED(10 0) TIMESTAMP GRAPHIC(512) VARLEN(75) CCSID(13488) GRAPHIC(512) VARLEN(75) CCSID(13488) GRAPHIC(512) VARLEN(75) CCSID(13488) PACKED(10 0) 0-9999999999 SAA format: YYYY-MM-DD-hh.Unicode Qualified name of object last qualified by object apply . MXDGSTS outfile (WRKDG command) Field FENOTACT2 Description Inactive database file entries Type.MXDGSTS outfile (WRKDG command) Table 135. length PACKED(10 0) Valid values 0-9999999999 Column headings INACTIVE DB FILE ENTRIES2 FILES NOT JOURNALED ON SOURCE2 FILES NOT JOURNALED ON TARGET2 FILES HELD FOR ERRORS2 FILES HELD FOR OTHERS2 FILES BEING REPAIRED2 RJLNK THRESHOLD (TIME IN MIN) RJLNK THRESHOLD (NBR OF JRNE) DBSND/DBRDR THRESHOLD (TIME IN MIN) DBSND/DBRDR THRESHOLD (NBR OF JRNE) DB APPLY A THRESHOLD FENOTJRNS2 Database file entries not journaled on source Database file entries not journaled on target Database file entries held due to error PACKED(10 0) 0-9999999999 FENOTJRNT2 PACKED(10 0) 0-9999999999 FEHLDERR2 PACKED(10 0) 0-9999999999 FEHLDOTHR2 FECMPRPR2 Database file entries held for other reasons (FEHLD) Database file entries being repaired PACKED(10 0) PACKED(10 0) 0-9999999999 0-9999999999 RJLNKTHLDM RJ Link Threshold Exceeded (Time in minutes) RJ Link Threshold Exceeded (Number of journal entries) DB Send/Reader Threshold Exceeded (Time in minutes) DB Send/Reader Threshold Exceeded (Number of journal entries) DB Apply A Threshold Exceeded (Number of journal entries) PACKED(4 0) 0-9999 RJLNKTHLDE PACKED(7 0) 0-9999999 DBRDRTHLDM PACKED(4 0) 0-9999 DBRDRTHLDE PACKED(7 0) 0-9999999 DBAPYATHLD PACKED(5 0) 0-99999 666 . length PACKED(5 0) PACKED(5 0) PACKED(5 0) PACKED(5 0) PACKED(5 0) PACKED(4 0) Valid values 0-99999 0-99999 0-99999 0-99999 0-99999 0-9999 Column headings DB APPLY B THRESHOLD DB APPLY C THRESHOLD DB APPLY D THRESHOLD DB APPLY E THRESHOLD DB APPLY F THRESHOLD OBJSND THRESHOLD (TIME IN MIN) OBJSND THRESHOLD (NBR OF JRNE) OBJRTV THRESHOLD CNRSND THRESHOLD OBJAPY THRESHOLD RJ BACKLOG DB ENTRY LARGE SEQUENCE DB READER ENTRY LARGE SEQUENCE OBJSNDTHDE PACKED(7 0) 0-9999999 OBJRTVTHDE CNRSNDTHDE OBJAPYTHDE RJBKLG CURDBSEQ2 PACKED(5 0) PACKED(5 0) PACKED(5 0) PACKED(15 0) ZONED(20 0) 0-99999 0-99999 0-99999 Calculated 0-999999999999 0-99999999999999999999 (twenty 9s) RDDBSEQ2 ZONED(20 0) 0-99999999999999999999 (twenty 9s) 667 .MXDGSTS outfile (WRKDG command) Table 135. MXDGSTS outfile (WRKDG command) Field DBAPYBTHLD DBAPYCTHLD DBAPYDTHLD DBAPYETHLD DBAPYFTHLD OBJSNDTHDM Description DB Apply B Threshold Exceeded (Number of journal entries) DB Apply C Threshold Exceeded (Number of journal entries) DB Apply D Threshold Exceeded (Number of journal entries) DB Apply E Threshold Exceeded (Number of journal entries) DB Apply F Threshold Exceeded (Number of journal entries) Object Send Threshold Exceeded (Time in minutes) Object Send Threshold Exceeded (Number of journal entries) Object Retrieve Threshold Exceeded (Number of activity entries) Container Send Threshold Exceeded (Number of activity entries) Object Apply Threshold Exceeded (Number of activity entries) RJ Backlog Current database journal entry large sequence number Last read database journal entry large sequence number Type. length ZONED(20 0) Valid values 0-99999999999999999999 (twenty 9s) Column headings DB LAST RECEIVED LARGE SEQUENCE DB APPLY A LAST RECEIVED LARGE SEQUENCE DB APPLY A LAST PROCESSED LARGE SEQUENCE DB APPLY A CURRENT LARGE COMMIT ID DB APPLY A LAST APPLIED LARGE SEQUENCE DB APPLY A HOLD LARGE SEQUENCE All DBx headings match the DBA headings.MXDGSTS outfile (WRKDG command) Table 135. with ‘x’ DBARCVSEQ2 Database apply session A last received large sequence number ZONED(20 0) 0-99999999999999999999 (twenty 9s) DBAPRCSEQ2 Database apply session A last processed large sequence number ZONED(20 0) 0-99999999999999999999 (twenty 9s) DBACMTID2 Database apply session A oldest open large commit ID CHAR(20) 0-99999999999999999999 (twenty 9s) DBAAPYSEQ2 Database apply session A last applied large sequence number ZONED(20 0) 0-99999999999999999999 (twenty 9s) DBAHLDSEQ2 Database apply session A hold MIMIX log large sequence number Reserved for up to 5 additional database apply sessions (‘B’ .‘F’ 600 bytes (5 x 120) All DBx field values match the DBA field values. Contains fields for each additional apply session which correspond to fields for apply session A (DBARCVSEQ2 through DBAHLDSEQ2) ZONED(20 0) 0-99999999999999999999 (twenty 9s) DBxRCVSEQ2 through DBxHLDSEQ2 where x is database apply session ‘B’ . MXDGSTS outfile (WRKDG command) Field RCVDBSEQ2 Description Last received database journal entry large sequence number Type.‘F’). 668 . MXDGSTS outfile (WRKDG command) Field CUROBJSEQ2 Description Current object journal entry large sequence number Type. length ZONED(20 0) Valid values 0-99999999999999999999 (twenty 9s) Column headings OBJECT JOURNAL LARGE SEQUENCE OBJRDRPRC JOURNAL LARGE SEQUENCE OBJRCVPRC LAST ENTRY LARGE SEQUENCE OBJRTVPRC LAST ENTRY LARGE SEQUENCE CNRSNDPRC LAST ENTRY LARGE SEQUENCE OBJAPYPRC LAST ENTRY LARGE SEQUENCE RJ TARGET LAST ENTRY LARGE SEQUENCE RDOBJSEQ2 Last read object journal entry large sequence number ZONED(20 0) 0-99999999999999999999 (twenty 9s) RCVOBJSEQ2 Last received object journal entry large sequence number ZONED(20 0) 0-99999999999999999999 (twenty 9s) OBJRTVSEQ2 Last processed object retrieve journal entry large sequence number ZONED(20 0) 0-99999999999999999999 (twenty 9s) CNRSNDSEQ2 Last processed container send journal entry large sequence number ZONED(20 0) 0-99999999999999999999 (twenty 9s) OBJAPYSEQ2 Last applied object journal entry large sequence number ZONED(20 0) 0-99999999999999999999 (twenty 9s) RJTGTSEQ2 Last RJ target journal entry large sequence number ZONED(20 0) 0-99999999999999999999 (twenty 9s) 669 .MXDGSTS outfile (WRKDG command) Table 135. DGSYS1. The records are listed in record arrival order. These are basic examples. in request time sequence.MXDGSTS outfile (WRKDG command) WRKDG outfile SELECT statement examples Following are some example SELECT statements that query a WRKDG outfile and produce various outfile reports. The first three examples show how to use wild cards to produce reports about specific data groups in the outfile. The statement would be entered as follows: SELECT DGDFN. there may be additional formatting options that you may want to apply to your output. DGSYS1. DGSYS2 FROM library/filename WHERE DGDFN like '%%' The outfile report produced follows: DGN INVENTORY PAYROLL ACCTPAY ORDERS ACCTREC APP1 APP2 SYS CHICAGO CHICAGO CHICAGO CHICAGO CHICAGO CHICAGO CHICAGO SYS LONDON LONDON LONDON LONDON LONDON LONDON LONDON 670 . The last example adds a few field definitions. The records are listed in record arrival order. WRKDG outfile example 1 This SELECT statement uses a single wildcard character to query the outfile to retrieve and display all of the data group names that start with an ‘A’ and have 0 or more characters following the ‘A’. The statement would be entered as follows: SELECT DGDFN. to produce outfile reports with additional data group related information. DGSYS2 FROM library/filename WHERE DGDFN like 'A%' The outfile report produced follows: DGN ACCTPAY ACCTREC APP1 APP2 SYS CHICAGO CHICAGO CHICAGO CHICAGO SYS LONDON LONDON LONDON LONDON WRKDG outfile example 2 This SELECT statement uses wildcard characters to query the outfile for all data group names that are in the outfile. DGSYS1. DGSYS2 FROM library/filename WHERE DGDFN like '%A%' The outfile report produced is follows: DGN PAYROLL ACCTPAY ACCTREC APP1 APP2 SUPERAPP SYS CHICAGO CHICAGO CHICAGO CHICAGO CHICAGO CHICAGO SYS LONDON LONDON LONDON LONDON LONDON LONDON WRKDG outfile example 4 This SELECT statement selects all records that have a data group name containing an ‘A’.051.09. All records for a data group are listed together in ascending time sequence.035. DGSYS1.842000 2001-02-06-11. The records are listed in record arrival order. DGSYS1.035. Additionally. DGSYS2. FROM library/filename WHERE DGDFN like '%A%' ORDER BY DGDFN. These records are listed in data group name order with all duplicate data group names listed by the time the entry was placed in the outfile.034.09.59.093 29. ENTRYTSP.034.59.842000 2001-02-06-11.05.MXDGSTS outfile (WRKDG command) SUPERAPP CHICAGO LONDON WRKDG outfile example 3 This SELECT statement uses wildcard characters to find all data groups with names that contain an ‘A’. The statement would be entered as follows: SELECT DGDFN.59.130 0 671 .851000 2001-02-06-14.24.49.24.09.793000 2001-02-06-11. The statement would be entered as follows: SELECT DGDFN. the time stamp that the entry was placed in the file and the current top sequence number of the object journal are also listed with the entry.095 29. DGSYS2.05.879 29.851000 2001-02-06-11.842000 SEQN 29. ENTRYTSP The outfile report produced follows: DGN PAYROLL ACCTPAY ACCTREC APP1 APP2 SUPERAPP SYS CHICAGO CHICAGO CHICAGO CHICAGO CHICAGO CHICAGO SYS LONDON LONDON LONDON LONDON LONDON LONDON ENTRYTSP 2001-02-06-11.877 29.24. CUROBJSEQ. MXDGSTS outfile (WRKDG command) 672 . MXDGSTS outfile (WRKDG command) 673 . *LIB1 *CHANGE. length CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) Valid values User-defined data group name User-defined system name User-defined system name User-defined name. generic*. generic*. *EXCLD *YES. *NO 674 . *ALL. *ALL User-defined name. generic* Refer to the OM5100P file for the list of valid values Refer to the OM5200P file for the list of valid object attributes User-defined name. *OBJ1 User-defined name. *NONE Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 SYSTEM 1 OBJECT SYSTEM 1 LIBRARY OBJECT TYPE OBJECT ATTRIBUTE SYSTEM 2 OBJECT SYSTEM 2 LIBRARY OBJECT AUDITING VALUE PROCESS TYPE COOPERATE WITH DATABASE REPLICATE SPOOLED FILES PRCTYPE COOPDB REPSPLF CHAR(10) CHAR(10) CHAR(10) *INCLD.MXDGOBJE outfile (WRKDGOBJE command) MXDGOBJE outfile (WRKDGOBJE command) Table 136. MXDGOBJE outfile (WRKDGOBJE command) Field DGDFN DGSYS1 DGSYS2 OBJ1 LIB1 TYPE OBJATR OBJ2 LIB2 OBJAUD Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) System 1 folder System 1 library Object type Object attribute System 2 object System 2 library Object auditing value (configured value) Process type Cooperate with database Replicate spooled files Type. *ALL. *NO *YES. *AUTOSYNC *YES. *KEYED Column headings KEEP DLTD SPOOLED FILES OBJRTVPRC DELAY USER PROFILE STATUS FEOPT JOURNAL IMAGE FEOPT OMIT OPEN CLOSE FEOPT REPLICATION TYPE FEOPT LOCK MBR ON APPLY FEOPT CURRENT APYSSN FEOPT COLLISION RESOLUTION FEOPT DISABLE TRIGGERS FEOPT PROCESS TRIGGERS FEOPT PROCESS CONSTRAINTS SYSTEM 1 LIBRARY ASP APYLOCK APYSSN CHAR(10) CHAR(10) *DGDFT. length CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) Valid values *YES. *DGDFT. *DGDFT *DGDFT. *ANY CRCLS Collision resolution (File entry options) Disable triggers during apply (File entry options) Process trigger entries (File entry options) Process constraint entries (File entry options) System 1 library ASP number CHAR(10) User-defined name. MXDGOBJE outfile (WRKDGOBJE command) Field KEEPSPLF OBJRTVDLY USRPRFSTS JRNIMG OPNCLO REPTYPE Description Keep deleted spooled files Retrieve delay (Object retrieve processing) User profile status Journal image (File entry options) Omit open and close entries (File entry options) Replication type (File entry options) Lock member during apply (File entry options) Apply session (File entry options) Type. *ENABLED. -1 = *ASPDEV 675 . *NO. *TGT *DGDFT. *NO A-F. 1-32. *SRC. *DGDFT *YES. *HLDERR. *DGDFT DSBTRG PRCTRG CHAR(10) CHAR(10) PRCCST CHAR(10) *YES LIB1ASP PACKED(3. *POSITION. *NO *DGDFT. *NO 0-999. *YES. *NO. *DISABLED. *YES.0) 0 = *SRCLIB. *DGDFT.MXDGOBJE outfile (WRKDGOBJE command) Table 136. *AFTER. *BOTH *DGDFT. 0) CHAR(10) 0 = *SRCLIB. User-defined name Column headings SYSTEM 1 LIBRARY ASP DEV SYSTEM 2 LIBRARY ASP SYSTEM 2 LIBRARY ASP DEV NUMBER OF OMIT CONTENT VALUES OMIT CONTENT SPOOLED FILE OPTIONS NUMBER OF COOPERATING OBJECT TYPES COOPERATING OBJECT TYPES NUMBER OF ATTRIBUTE ATTRIBUTE LIB2ASP LIB2ASPD PACKED(3. *MBR (10 characters each) *NONE. *HLD. *FILE. 1-32. 1-50 *ALL 676 . *DTAARA. MXDGOBJE outfile (WRKDGOBJE command) Field LIB1ASPD Description System 1 library ASP device (File entry options) System 2 library ASP number System 2 library ASP device (File entry options) Number of omit content (OMTDTA) values Omit content values (File entry options) Spooled file options Number of cooperating object types Cooperating object types Number of attribute options Attribute options Type. *DTAQ -1. *HLDONSAV 0-999 COOPTYPE NBRATROPT ATROPT CHAR(100) PACKED (3 0) CHAR(500) *FILE. User-defined name NBROMTDTA PACKED(3 0) 1-10 OMTDTA SPLFOPT NUMCOOPTYP CHAR(100) CHAR(10) PACKED(3 0) *NONE.MXDGOBJE outfile (WRKDGOBJE command) Table 136. -1 = *ASPDEV *LIB2ASP. length CHAR(10) Valid values *LIB1ASP. normalized to the target system (Timestamp when the journal entry is received by the journal reader on the target system when using remote journaling or received by the target system by the MIMIX send process for non-remote journaling).SS.SS. *SYS2 A-F SAA timestamp .normalized to the target system (Timestamp value is set equal to the create timestamp (CRTTSP) when using remote journaling.mmmmmm Send Timestamp (YYYY-MMDD. For non-remote journaling.HH. length CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) TIMESTAMP TIMESTAMP Valid values User-defined data group name User-defined system name User-defined system name *SYS1.mmmmmm Type.mmmmmm TIMESTAMP RECEIVE TIMESTAMP APYTSP Apply Timestamp (YYYY-MMDD.HH.mmmmmm TIMESTAMP APPLY TIMESTAMP 677 .MM.) SAA timestamp .normalized to the target system (Timestamp when the journal entry is applied on the target system. this is the time the journal entry is read on the source system and is sent by the MIMIX send process.HH.MM.) SAA timestamp .MM.) Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 DATA SOURCE APPLY SESSION CREATE TIMESTAMP SEND TIMESTAMP RCVTSP Receive Timestamp (YYYY-MMDD.HH. MXDGTSP outfile (WRKDGTSP command) Field DGDFN DGSYS1 DGSYS2 DTASRC APYSSN CRTTSP SNDTSP Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) Data source Apply session Create Timestamp (YYYY-MMDD.SS. SAA timestamp .MM.MXDGTSP outfile (WRKDGTSP command) MXDGTSP outfile (WRKDGTSP command) Table 137.normalized to the target system (Timestamp when the journal entry is created.SS. 0-9999999999 Column headings SEND ELAPSED TIME SNDRCVET Elapsed time between send and receive process (milliseconds) Elapsed time between receive and apply process (milliseconds) Elapsed time between create and apply timestamps (milliseconds) PACKED(10 0) RECEIVE ELAPSED TIME APPLY ELAPSED TIME TOTAL ELAPSED TIME RCVAPYET PACKED(10 0) CRTAPYET PACKED(10 0) SYSTDIFF The time differential between the source and target systems. Calculated. where time differential = source time target time PACKED(10 0) TIME DIFFERENCE 678 . For remote journaling. 0-9999999999 (Elapsed time between the send time and the receive time. 0-9999999999 Elapsed time between the receive time and the apply time. 0-9999999999 (Elapsed time between generation of the timestamps and the time the MIMIX send process is received on the target system for non-remote journaling. the create and send times are set equal so elapsed time will be a value of 0. length PACKED(10 0) Valid values Calculated.) Calculated. MXDGTSP outfile (WRKDGTSP command) Field CRTSNDET Description Elapsed time between create and send process (milliseconds) Type. 0-9999999999 (Elapsed time between generation of the timestamp to the time when the journal entry is applied on the target system.) -9999999999-0.) Calculated.MXDGTSP outfile (WRKDGTSP command) Table 137. MXDGTSP outfile (WRKDGTSP command) 679 . *JRNDFN Journal library Numeric value 0 = *CRTDFT 1-32 .*NONE. length CHAR(10) CHAR(8) CHAR(10) CHAR(10) PACKED(3 0) Valid values User-defined journal definition name User-defined system name Journal. *TIME. *JRNLIB Numeric value 0 = *CRTDFT 1-32 . MXJRNDFN outfile (WRKJRNDFN command) Field JRNDFN JRNSYS JRN JRNLIB JRNLIBASP Description Journal definition name (Journal definition) System name (Journal definition) Journal name (Journal) Journal library (Journal) Journal library ASP Type. *SIZE. user-defined name User-defined name.1 = *ASPDEV *GEN.1 = *ASPDEV 2 x CHAR(10) .MXJRNDFN outfile (WRKJRNDFN command) MXJRNDFN outfile (WRKJRNDFN command) Table 138. *SYSTEM The only valid combinations are: *TIME *SIZE *TIME *SYSTEM 10-1000000 Column headings JRNDFN NAME JRNDFN SYSTEM JOURNAL JOURNAL LIBRARY JOURNAL LIBRARY ASP JRNRCVPFX JRNRCVLIB RCVLIBASP Journal receiver prefix (Journal receiver prefix) Journal receiver library (Journal receiver prefix) Journal receiver library ASP CHAR(10) CHAR(10) PACKED(3 0) JRNRCV PREFIX JRNRCV LIBRARY JRNRCV LIBRARY ASP CHGMGT Receiver change management CHAR(20) RECEIVER CHANGE MANAGEMEN T RECEIVER THRESHOLD SIZE (MB) THRESHOLD Receiver threshold size (MB) PACKED(7 0) 680 . user-defined name (See field JRNLIB if this field contains *JRNLIB) RJLNK EXITPGM EXITPGMLIB Remote journal link Exit program Exit program library CHAR(10) CHAR(10) CHAR(10) *NONE. *JRNDFN MSGQLIB Threshold message queue library CHAR(10) *JRNLIB. *NO KEEPRCVCNT KEEPJRNRCV TEXT JRNRCVASP MSGQ Keep journal receiver (days) Journal receiver ASP Description Journal receiver ASP Threshold message queue PACKED(3 0) PACKED(3 0) CHAR(50) PACKED(3 0) CHAR(10) 0-999 0-999 *BLANK. user-defined name User-defined name 681 .MXJRNDFN outfile (WRKJRNDFN command) Table 138. MXJRNDFN outfile (WRKJRNDFN command) Field RCVTIME RESETTHLD Description Time of day to change receiver Reset sequence threshold Type. *SOURCE. User-defined text Numeric value (0 = *LIBASP) User-defined name. length ZONED(6 0) PACKED(5 0) Valid values Time 10-1000000 Column headings RECEIVER CHANGE TIME RESET SEQUENCE THRESHOLD RECEIVER DELETE MANAGEMEN T KEEP UNSAVED JRNRCV KEEP JRNRCV COUNT KEEP JRNRCV (DAYS) DESCRIPTION JRNRCV ASP MSGQ THRESHOLD MSGQ MSGQ THRESHOLD MSGQ LIBRARY RJ LINK EXIT PROGRAM EXIT PROGRAM LIBRARY DLTMGT Receiver delete management CHAR(10) *YES. *TARGET *NONE. *NO KEEPUNSAV Keep unsaved journal receivers CHAR(10) *YES. 000. 0) *SRC. *NONE Numeric value Column headings MIN JRN ENTRY DATA REQUESTED THRESHOLD SIZE SAVE TYPE JOURNALING LAG LIMIT (SEC) *JRNLIBASP. length CHAR(100) PACKED(7 0) Valid values Array of 10 CHAR(10) fields *DTAARA. *FILE. user-defined name TGTSTATE CHAR(10) *ACTIVE.000 682 .000. *MAXOPT3 10-100. *STANDBY JRNCACHE RCVSIZOPT RESETTHLD2 Journal cache option Receiver size option Reset large sequence threshold CHAR(10) CHAR(10) PACKED(15. *NONE *MAXOPT2. user-defined name JOURNAL LIBRARY ASP DEV JRNRCV LIBRARY ASP DEV TARGET JOURNAL STATE JOURNAL CACHING RECEIVER SIZE OPTION RESET SEQUENCE THRESHOLD2 SAVTYPE JRNLAGLMT Save type Journaling lag limit (seconds) CHAR(10) PACKED(3 0) JRNLIBASPD Journal library ASP device CHAR(10) RCVLIBASPD Journal receiver library ASP device Target journal state CHAR(10) *RCVLIBASP. *TGT. MXJRNDFN outfile (WRKJRNDFN command) Field MINENTDTA REQTHLDSIZ Description Minimal journal entry data Requested threshold size Type.MXJRNDFN outfile (WRKJRNDFN command) Table 138. *BOTH. *FLDBDY.000. MXJRNDFN outfile (WRKJRNDFN command) 683 . MXRJLNK outfile (WRKRJLNK command) MXRJLNK outfile (WRKRJLNK command) Table 139. ASP Primary Group name "0 = *CRTDFT -1 = *ASPDEV *RCVLIBASP. *ASPDEV. MXRJLNK outfile (WRKRJLNK command) Field SRCJRNDFN Description Journal definition name on source Source system name of journal definition Source Journal Library ASP Type. *ASPDEV. length CHAR(10) Valid values Journal definition name Column headings SOURCE JOURNAL DEFINITION SOURCE SYSTEM SRC JRN LIBRARY ASP SRC JRN LIBRARY ASP DEV SRC JRNRCV LIBRARY ASP SRC JRNRCV LIBRARY ASP DEV TARGET JOURNAL DEFINITION TARGET SYSTEM TGT JRN LIBRARY ASP SRCSYS SRCJEJRNA CHAR(8) DEC(3) System name "0 = *CRTDFT -1 = *ASPDEV *JRNLIBASP. ASP Primary Group name Journal definition name SRCJEJLAD Source Journal Library ASP Device Source Journal Receiver Library ASP Source Journal Receiver Library ASP Device Journal definition name on target Target system name of journal definition Target Journal Library ASP CHAR(10) SRCJERCVA DEC(3) SRCJERLAD CHAR(10) TGTJRNDFN CHAR(10) TGTSYS TGTJEJRNA CHAR(8) DEC(3) System name "0 = *CRTDFT -1 = *ASPDEV 684 . *SYNC. length CHAR(10) Valid values *JRNLIBASP. ASP Primary Group name "0 = *CRTDFT -1 = *ASPDEV *RCVLIBASP. *CTLINACT. *ASPDEV. MXRJLNK outfile (WRKRJLNK command) Field TGTJEJLAD Description Target Journal Library ASP Device Target Journal Receiver Library ASP Target Journal Receiver Library ASP Device Delivery mode of remote journaling Remote journal state Type. ASP Primary Group name *ASYNC. *SYSDFN. *SYSDFN Transfer definition name. *NONE 0=*SYSDFN. blank *ASYNC. *ASYNCPEND.MXRJLNK outfile (WRKRJLNK command) Table 139. *SYNC. *NOTBUILT. 1-99 Plain text Column headings TGT JRN LIBRARY ASP DEV TGT JRNRCV LIBRARY ASP TGT JRNRCV LIBRARY ASP DEV RJ MODE (DELIVERY) STATE TGTJERCVA DEC(3) TGTJERLAD CHAR(10) RJMODE RJSTATE CHAR(10) CHAR(10) PRITFRDFN SECTFRDFN PRIORITY TEXT Primary transfer definition Secondary transfer definition Async process priority Text description CHAR(10) CHAR(10) Packed(3 0) CHAR(50) PRIMARY TFRDFN SECONDARY TFRDFN PRIORITY TEXT 685 . *FAILED. *UNKNOWN Transfer definition name. *ASPDEV. *SYNCPEND. *INACTIVE. MXRJLNK outfile (WRKRJLNK command) 686 . *SECTFRDFN (Refer to the PRITFRNAME. *TERM. *ACTION. PRITFRSYS1 and PRITFRSYS2 fields if this field contains *PRITFRDFN) User-defined name User-defined name. *INFO. *WARNING. *NO User-defined name. *ERROR. *NET User-defined name User-defined name *YES.MXSYSDFN outfile (WRKSYSDFN command) MXSYSDFN outfile (WRKSYSDFN command) Table 140. 0-99 0-99 Column headings SYSDFN NAME SYSTEM TYPE CONFIGURED PRITFRDFN CONFIGURED SECTFRDFN CLUSTER MEMBER CLUSTER TFRDFN PRIMSGQ PRIMSGQLIB PRISEV PRISEVNBR Primary message queue (Primary message handling) Primary message queue library (Primary message handling) Primary message queue severity (Primary message handling) Primary message queue severity number (Primary message handling) Primary message queue information level (Primary message handling) Secondary message queue (Secondary message handling) CHAR(10) CHAR(10) CHAR(10) PACKED(3 0) PRIMARY MSGQ PRIMARY MSGQ LIB PRIMARY MSGQ SEV PRIMARY MSGQ SEV NBR PRIMARY MSGQ INFO LEVEL SECONDARY MSGQ PRIINFLVL CHAR(10) *SUMMARY. MXSYSDFN outfile (WRKSYSDFN command) Field SYSDFN TYPE PRITFRDFN SECTFRDFN CLUMBR CLUTFRDFN Description System definition System type Configured primary transfer definition Configured secondary transfer definition Cluster member Cluster transfer definition Type. *LIBL *SEVERE. *ALL SECMSGQ CHAR(10) User-defined name 687 . *PRITFRDFN. length CHAR(8) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(20) Valid values User-defined name *MGT. *ALERT. *NO *YES.MXSYSDFN outfile (WRKSYSDFN command) Table 140. 0 = *CRTDFT TEXT JRNMGRDLY SYSMGRDLY OUTQ OUTQLIB HOLD SAVE KEEPSYSHST KEEPDGHST KEEPMMXDTA DTALIBASP CHAR(50) PACKED(3 0) PACKED(3 0) CHAR(10) CHAR(10) CHAR(10) CHAR(10) PACKED(3 0) PACKED(3 0) PACKED(3 0) PACKED(3 0) 688 . *ACTION. 0 = *NOMAX Numeric value. *INFO. *LIBL *SEVERE. *ALERT. 0-99 0-99 Column headings SECONDARY MSGQ LIB SECONDARY MSGQ SEV SECONDARY MSGQ SEV NBR SECONDARY MSGQ INFO LEVEL DESCRIPTION JRNMGR DELAY (SEC) SYSMGR DELAY (SEC) OUTQ OUTQ LIBRARY HOLD ON OUTQ SAVE ON OUTQ KEEP SYS HISTORY (DAYS) KEEP DG HISTORY (DAYS) KEEP MIMIX DATA (DAYS) MIMIX DATA LIB ASP SECSEVNBR PACKED(3 0) SECINFLVL CHAR(10) *SUMMARY. *ALL (Refer to the TFRSYS1 field if this field contains *SYS1) *BLANK. *TERM. MXSYSDFN outfile (WRKSYSDFN command) Field SECMSGQLIB SECSEV Description Secondary message queue library (Secondary message handling) Secondary message queue severity (Secondary message handling) Secondary message queue severity number (Secondary message handling) Secondary message queue information level (Secondary message handling) Description Journal manager delay (seconds) System manager delay (seconds) Output queue (Output queue) Output queue library (Output queue) Hold on output queue Save on output queue Keep system history (days) Keep data group history (days) Keep MIMIX data (days) MIMIX data library ASP Type. length CHAR(10) CHAR(10) Valid values User-defined name. *NO 1-365 1-365 1-365. *WARNING. user-defined text 5-900 5-900 User-defined name User-defined name *YES. *ERROR. *NONE (Values are returned left-justified) 1-365.MXSYSDFN outfile (WRKSYSDFN command) Table 140. *CURRENT User-defined name User-defined name User-defined name User-defined name User-defined name 000000 . length PACKED(5 0) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(8) PACKED(3 0) PACKED(3 0) CHAR(10) Valid values 1-9999. 0 = *NOMAX 1-365.235959. User-defined name Column headings DISK STORAGE LIMIT (GB) USRPRF FOR SUBMIT JOB MANAGER JOBD MANAGER JOBD LIBRARY DEFAULT JOBD DEFAULT JOBD LIBRARY MIMIX PRODUCT LIBRARY RESTART TIME KEEP NEW NFY (DAYS) KEEP ACK NFY (DAYS) ASP GROUP 689 . MXSYSDFN outfile (WRKSYSDFN command) Field DSKSTGLMT SBMUSR MGRJOBD MGRJOBDLIB DFTJOBD DFTJOBDLIB PRDLIB RSTARTTIME KEEPNEWNFY KEEPACKNFY ASPGRP Description Disk storage limit (GB) User profile for submit job Manager job description (Manager job description) Manager job description library (Manager job description) Default job description (Default job description) Default job description library (Default job description) MIMIX product library Job restart time Keep new notification (days) Keep acknowledged notification (days) ASP Group Type. 0 = *NOMAX *JOBD. 0 = *NOMAX *NONE. MXSYSDFN outfile (WRKSYSDFN command) 690 . user-defined name. length CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(256) CHAR(256) CHAR(14) CHAR(14) CHAR(8) CHAR(8) CHAR(8) Valid values User-defined journal definition name User-defined system name User-defined system name *TCP. MXTFRDFN outfile (WRKTFRDFN command) Field TFRDFN TFRSYS1 TFRSYS2 PROTOCOL HOST1 HOST2 PORT1 PORT2 LOCNAME1 LOCNAME2 NETID1 Description Transfer definition name (Transfer definition) System 1 name (Transfer definition) System 2 name (Transfer definition) Transfer protocol System 1 host name or address System 2 host name or address System 1 port number or alias System 2 port number or alias System 1 location name System 2 location name System 1 network identifier Type. user-defined name (Refer to the TFRSYS1 field if this field contains *SYS1) *SYS2. user-defined name *SYS2. *OPTI *SYS1. user-defined name (Refer to the TFRSYS2 field if this field contains *SYS2) User-defined port number User-defined port number *SYS1. *NONE Column headings TFRDFN NAME TFRDFN NAME SYSTEM 1 TFRDFN NAME SYSTEM 2 TRANSFER PROTOCOL SYSTEM 1 HOST OR ADDRESS SYSTEM 2 HOST OR ADDRESS SYSTEM 1 PORT NBR OR ALIAS SYSTEM 2 PORT NBR OR ALIAS SYSTEM 1 LOCATION SYSTEM 2 LOCATION SYSTEM 1 NETWORK IDENTIFIER SYSTEM 2 NETWORK IDENTIFIER NETID2 System 2 network identifier CHAR(8) *LOC. Table 141.MXTFRDFN outfile (WRKTFRDFN command) MXTFRDFN outfile (WRKTFRDFN command) The Work with Transfer Definitions (WRKTFRDFN) command generates new outfiles based on the MXTFRDFN record format. *NETATR. *NONE 691 . *NETATR. user-defined name *LOC. *SNA. User-defined name. *YES. length CHAR(8) CHAR(50) PACKED(7 0) CHAR(18) CHAR(18) CHAR(18) CHAR(10) Valid values User-defined name.MXTFRDFN outfile (WRKTFRDFN command) Table 141. *NETATR *BLANK. user-defined text 0-9999999 *GEN. User-defined name *DFT. MXTFRDFN outfile (WRKTFRDFN command) Field MODE TEXT THLDSIZE RDB RDBSYS1 RDBSYS2 MNGRDB Description SNA mode Description Reset sequence threshold Relational database System 1 Relational database name System 2 Relational database name Manage RDB Directory Entries Indicator Transfer definition short name Manage Autostart Job Entry Type. *NO 692 . *NO Column headings SNA MODE DESCRIPTION THRESHOLD SIZE RELATIONAL DATABASE RELATIONAL DATABASE RELATIONAL DATABASE MANAGE DIRECTORY ENTRIES TFRDFN SHORT NAME MANAGE AJE TFRSHORTN MNGAJE CHAR(4) CHAR(10) Name *YES. user-defined name *SYS1. User-defined name *SYS2. *CRGDLTCMD. *PRIMARY. *CRGSWT. user-defined name *ANY. *REPLICATE. *CRGEND. length CHAR(10) Valid values *ANY. *BACKUP. *CRGREJOIN. *CRGSTR.MZPRCDFN outfile (WRKPRCDFN command) MZPRCDFN outfile (WRKPRCDFN command) Table 142. user-defined name Column headings PRCDFN NAME PRCDFN SYSTEM PROCESS TYPE PRCSYS TYPE CHAR(10) CHAR(10) *ANY. *CRGUNDO. *CRGRESTR. *CRGDLT. *CRGFAIL. User-defined value User-defined name User-defined value PRDLIB TEXT Product library Description CHAR(10) CHAR(50) PRODUCT LIBRARY DESCRIPTI ON 693 . *CRGENDNOD. MZPRCDFN outfile (WRKPRCDFN command) Field PRCDFN Description Process definition name (Process definition) System name (Process definition) Process type Type. *CRGCRT. *CRGCHG. *CRGADDNOD. *CRGRMVNOD. *CMP. *CMT. *CRGFAIL. *CRGDLT. *CRGUNDO. *CRGDLTCMD. *CRGADDNOD. *CMDPMT. MZPRCE outfile (WRKPRCE command) Field PRCDFN PRCSYS TYPE Description Process definition name (Process definition) System name ( Process definition) Process type Type. *GOTO.MZPRCE outfile (WRKPRCE command) MZPRCE outfile (WRKPRCE command) Table 143. User-defined value 1-999999 User-defined name *ANY. *CRGSWT. *BACKUP. user-defined name *ANY. *PRIMARY. *RTN Column headings PRCDFN NAME PRCDFN SYSTEM PROCESS TYPE SEQNBR LABEL MSGID ACTION Sequence number Label Message identifier Action PACKED(6 0) CHAR(10) CHAR(10) CHAR(10) SEQUENCE NUMBER LABEL MESSAGE ID ACTION 694 . *CRGCHG. *CRGCRT. *CRGRESTR. user-defined name *ANY. *REPLICATE. *CRGENDNOD. user-defined value *CMD. length CHAR(10) CHAR(10) CHAR(10) Valid values *ANY. *CRGSTR. *CRGREJOIN. *CRGEND. *CRGRMVNOD. *PRISTS. *LCLROLE. *REPSTS2. *PRVROL2. *REPNOD4. *PRVSTS4. *REPSTS1. *REPNOD1. *BCKNOD3. *BCKNOD5. *PRVACTCDE. *PRVROL2. *REPNOD5. *CRGNAME. *REPNOD5. *PRDLIB. *APPCRGSTS. *PRVROL5. *CLUNAME. *BCKNOD4. *REPNOD3. *BCKNOD4. *REPSTS4. *ENDOPT. *BCKNOD5.MZPRCE outfile (WRKPRCE command) Table 143. User-defined type BLANK. *PRVROL1. *ENDOPT. *BCKSTS2. *BCKSTS5. *PRISTS. *PRVROL3. *REPNOD4. *REPNOD1. *CHGROLE. *BCKNOD2. *LCLNOD. *LCLROLE. *LCLPRVROL. *APPCRGSTS. *CLUNAME. *PRINOD. *DTACRGSTS. *REPSTS4. *REPNOD3. *LCLPRVROL. *BCKSTS3. *CHGROLE. *REPSTS2. *REPSTS3. *BCKNOD2. User-defined type Column headings COMPARE OPERAND1 OPERATOR OPERAND2 Compare operator Compare operand 2 CHAR(10) CHAR(10) BLANK. *REPSTS3. length CHAR(10) Valid values BLANK. *REPNOD2. *PRVROL4. *PRVSTS3. *REPNOD2. *REPSTS5. MZPRCE outfile (WRKPRCE command) Field OPERAND1 Description Compare operand 1 Type. *PRVSTS2. *BCKSTS3. *PRVSTS5. *CRGNAME. *PRDLIB. *BCKSTS5. *LCLSTS. *ACTCODE. *PRIPRVSTS. *CHGNOD. *ROLETYPE. *LCLSTS. *ACTCODE. *CRGTYPE. *PRVSTS2. *BCKSTS1. *BCKNOD1. *PRVSTS1. *ROLETYPE. *BCKSTS2. *DTACRGSTS. *BCKSTS4. *PRVACTCDE. *PRIPRVSTS. *PRIPRVROL. *BCKNOD3. *PRVROL1. *REPSTS5. *PRVROL4. *NODCNT.*PRIPRVROL. *BCKSTS4. *REPSTS1. *NODCNT. user-defined value COMPARE OPERATOR COMPARE OPERAND2 CMD Command details CHAR(1000) COMMAND DETAILS 695 . *PRVSTS5. *PRVSTS3. *LCLPRVSTS. *BCKNOD1. *BCKSTS1. *PRVROL3. *CHGNOD. *PRINOD. *LCLNOD. *PRVSTS4. *CRGTYPE. *LCLPRVSTS. *PRVSTS1. *PRVROL5. user-defined value Column headings ACTION LABEL RETURN VALUE COMMENT TEXT 696 . MZPRCE outfile (WRKPRCE command) Field ACTLBL RTNVAL COMMENT Description Action label Return value Comment text Type. *SUCCESS BLANK. user-defined value *FAIL. length CHAR(10) CHAR(10) CHAR(50) Valid values BLANK.MZPRCE outfile (WRKPRCE command) Table 143. MXDGIFSTE outfile (WRKDGIFSTE command) Field DGDFN DGSYS1 DGSYS2 OBJ1 Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) System 1 object name (unicode) Type. 697 . length CHAR(10) CHAR(8) CHAR(8) GRAPHIC(512) VARLEN(75) BIN(16 0) Valid values User-defined data group name User-defined system name User-defined system name User-defined name Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 SYSTEM 1 IFS OBJECT (UNICODE) SYSTEM 1 FILE ID (BINARY) SYSTEM 1 FILE ID (HEX) SYSTEM 2 IFS OBJECT (UNICODE) SYSTEM 2 FILE ID (BINARY) SYSTEM 2 FILE ID (HEX) CCSID FID1 System 1 file identifier (binary) IBM i-defined file identifier FID1HEX OBJ2 System 1 file identifier (hexadecimal-readable) System 2 object name (unicode) CHAR(32) GRAPHIC(512) VARLEN(75) BIN(16 0) IBM i-defined file identifier User-defined name FID2 System 2 file identifier (binary) IBM i-defined file identifier FID2HEX CCSID System 2 file identifier (hexadecimal-readable) Object CCSID CHAR(32) BIN(5 0) IBM i-defined file identifier Defaults to job CCSID. OBJ1 and OBJ2 values remain in Unicode.MXDGIFSTE outfile (WRKDGIFSTE command) MXDGIFSTE outfile (WRKDGIFSTE command) Table 144. If job CCSID is 65535 or data cannot be converted to job CCSID. *SYMLNK *ACTIVE. *HLDIGN. Zero length if conversion not possible. MXDGIFSTE outfile (WRKDGIFSTE command) Field OBJ1CVT Description System 1 object name (converted to job CCSID) System 2 object name (converted to job CCSID) Object type Entry status Journaled on system 1 Journaled on system 2 Apply session Type. *NO ‘A’ (only supported apply session) Column headings SYSTEM 1 IFS OBJECT CONVERTED SYSTEM 2 IFS OBJECT CONVERTED OBJECT TYPE CURRENT STATUS SYSTEM 1 JOURNALED SYSTEM 2 JOURNALED APPLY SESSION OBJ2CVT TYPE STSVAL JRN1STS JRN2STS APYSSN 698 . length CHAR(512) VARLEN(75) CHAR(512) VARLEN(75) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) Valid values User-defined name converted using CCSID value. *RLSWAIT *YES. *NO *YES. *HLD. *DIR. *HLDERR. *STMF. User-defined name converted using CCSID value. Zero length if conversion not possible. *HLDRNM.MXDGIFSTE outfile (WRKDGIFSTE command) Table 144. MXDGOBJTE outfile (WRKDGOBJTE command) Field DGDFN DGSYS1 DGSYS2 OBJ1 LIB 1 TYPE OBJ2 LIB 2 STSVAL JRN1STS JRN2STS APYSSN RQSAPYSSN Description Data group name (Data group definition) System 1 name (Data group definition) System 2 name (Data group definition) System 1 object System 1 library Object type System 2 object System 2 library Entry status Journaled on system 1 Journaled on system 2 Current apply session Requested apply session Type. *NO *YES. *HLDIGN. *HLDERR. *HLD. *RLSWAIT *YES.MXDGOBJTE outfile (WRKDGOBJTE command) MXDGOBJTE outfile (WRKDGOBJTE command) Table 145. length CHAR(10) CHAR(8) CHAR(8) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) CHAR(10) Valid values User-defined data group name User-defined system name User-defined system name User-defined name User-defined name *DTAARA. *NO ‘A’ (only supported apply session) ‘A’ (only supported apply session) Column headings DGDFN NAME DGDFN SYSTEM 1 DGDFN SYSTEM 2 SYSTEM 1 OBJECT SYSTEM 1 LIBRARY OBJECT TYPE SYSTEM 2 OBJECT SYSTEM 2 LIBRARY CURRENT STATUS SYSTEM 1 JOURNALED SYSTEM 2 JOURNALED CURRENT APYSSN REQUESTED APYSSN 699 . *DTAQ User-defined name User-defined name *ACTIVE. MXDGOBJTE outfile (WRKDGOBJTE command) Field OBJ1APY Description System 1 object (known by apply) Type. length CHAR(10) Valid values User-defined name Column headings SYSTEM 1 OBJECT (APPLY) SYSTEM 1 LIBRARY (APPLY) SYSTEM 2 OBJECT (APPLY) SYSTEM 2 LIBRARY (APPLY) LIB1APY System 1 library (known by apply) CHAR(10) User-defined name OBJ2APY System 2 object (known by apply) CHAR(10) User-defined name LIB2APY System 2 library (known by apply) CHAR(10) User-defined name 700 .MXDGOBJTE outfile (WRKDGOBJTE command) Table 145. Corporate Headquarters Vision Solutions. DB2. and products. All programs contained herein are provided to you “AS IS. Inc. To illustrate them as completely as possible the examples may include names of individuals. If you are an entity of the U. mass transit. and WebSphere are trademarks of International Business Machines Corporation. ™ IntelliStart. MIMIX AutoNotify. MIMIX AutoGuard. Windows. California USA Tel: +1 (949) 253-6500 . MIMIX ha Lite. Irvine. Inc. Inc. MIMIX DB2 Replicator. and are delivered with only those rights set forth within the license agreement for such documentation and program(s). Vision Solutions. as defined in the Federal Acquisition Regulations (FAR).227-19. OS/400. therefore. for use in any nuclear. Java and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems. RJ Link.S. Examples and Example Programs: This book contains examples of reports and data used in daily operation. ® MIMIX and Vision Solutions are registered trademarks of Vision Solutions. Inc. Inc. Microsoft. i5/OS. The program(s) referred to in this document are not specifically developed. Netscape is a registered trademark of AOL LLC. IBM. Inc. iSeries. No portion of this manual may be copied or otherwise reproduced. All of these names are fictitious. aviation. UNIX is a registered trademark of The Open Group in the United States and other countries. as simple examples to provide an illustration. serviceability. This document is proprietary to Vision Solutions. MIMIX Switch Assistant. Inc. companies. in the United States and other countries. duplication or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFAR 252. brands. MIMIX Availability Manager. and may be used only as authorized in our license agreement. MIMIX ha1. from liability. makes no warranty of any kind regarding this material and assumes no responsibility for any errors that may appear in this document. Vision Solutions. Mozilla and Firefox are trademarks of the Mozilla Foundation. MIMIX dr1. you agree that this documentation and the program(s) referred to in this document are Commercial Computer Software. and the DoD FAR Supplement.227-7013 (48 CFR) or subparagraphs (c)(1) & (2) of the Commercial Computer Software Restricted Rights clause at FAR 52. Replicate1. without the express consent of Vision Solutions. These examples have not been thoroughly tested under all conditions. Vision AutoValidate. MIMIX Promoter. or transmitted in whole or part. or licensed. This book contains small programs that are furnished by Vision Solutions. MIMIX Object Replicator. Inc. and any such use shall remove Vision Solutions. Power. eServer. Internet Explorer. government. and Vision Cluster1 are trademarks of Vision Solutions. 2009. AS/400. Any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. or function of these example programs. and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Vision Solutions. cannot guarantee or imply reliability. All other trademarks are the property of their respective owners. Use.” THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Inc. Vision Solutions. All rights reserved.Notices © Copyright 1999. System i. Inc. shall not be liable for any claims or damages arising from such use of the Program(s) for any such applications. Inc. MIMIX Monitor. translated. or medical application or in any other inherently dangerous applications. The information in this document is subject to change without notice and is furnished under a license agreement.. . files on hold 94 *HLDERR. configuration tips 523 703 . secondary 520 SYSBAS 518 system 519 user 519 asynchronous delivery 62 attributes. ASP attributes 577 #FILATRMBR rule. effect on library list 525 independent. 608 #FILATR rule. ASP attributes 577 #FILATR rule 556. primary 520 independent. journal attributes 573 A access paths. 610 #IFSATR rule 569. 617 #IFSATR rule. database load balancing 81 ASP basic 520 concepts 519 group 520 independent 520 independent. ASP attributes 577 #FILATR rule. configuring 144 apply session constraint induced changes 337 default value 216 specifying 212 apply session. journal attributes 573 #FILDTA rule 548. hold error status 74 *MAXOPT3 sequence number size 196 *MSGQ. 543 #DGFE rule 546. 543 audit level best practice 530 audit results 541. requirements 522 independent. IFS objects journal receiver size 191 restrictions 109 synchronizing 464 advanced journaling. configuring 523 independent. journal attributes 573 #FILATRMBR rule 556. 604 #DLOATR rule 571. configuring IFS objects 524 independent. resolving 541. supported CMPDLOA command 571 CMPFILA command 556 CMPIFSA command 569 CMPOBJA command 561 audit authority level to run 530 automatic recovery 531 before switching 530 best practice 530 comparison levels 530 differences. ASP attributes 577 #IFSATR rule. 608 #FILATRMBR rule. limitations 522 independent. 531 requirements 530 results 541. journaling 196 access types (file) for T-ZC entries 350 accessing MIMIX Main Menu 84 active server technology 399 additional resources 18 advanced journaling add to existing data group 79 apply session balancing 81 benefits 69 conversion examples 80 convert data group to 79 loading tracking entries 257 planning for 79 replication process 70 serialized transactions with database 79 advanced journaling. held due to error 345 *HLDERR. restrictions 522 independent. 606 #DLOATR rule. maintaining private authorities 95 independent. 543 improve performance of #MBRRCDCNT 318 job log 545 recommendations 530. benefits 519 independent. configuring library-based objects 524 independent.Index Symbols *FAILED activity entry 43 *HLD. data areas and data queues synchronizing 464 advanced journaling. replication 518 independent. large objects (LOBs) journal receiver size 191 synchronizing 435 APPC/SNA. journal receiver considerations 524 independent. file data comparisons 548 resolving problems 543. user profile status attribute 580 interpreting. object used for replication 294 auditing value. 546 timestamp difference 116 troubleshooting 545 auditing and reporting. remote journaling 278 changing from RJ to MIMIX processing permanently 206 temporarily 205 checklist convert *DTAARA. by mnemonic ADDDGDAE 262 ADDMSGLOGE 479 B backlog comparing file data restriction 401 backup system 23 restricting access to files 216 basic ASP 520 batch output 484 704 . journal receivers 180 changing RJ link 204 startup programs. private 95 authority level for auditing. attribute comparisons 551 interpreting. *DTAQ to user journaling 136 convert IFS objects to user journaling 136 converting to remote journaling 131 copying configuration data 509 legacy cooperative processing 138 manual configuration (source-send) 128 MIMIX Dynamic Apply 133 new preferred configuration 125 pre-configuration 77 collision points 470 collision resolution 470 default value 216 requirements 346 working with 345 commands changing defaults 494 displaying a list of 485 commands. i5/OS object set by MIMIX 56 auditing. user profile password attribute 583 #OBJATR rule. configuring 331 catchup mode 60 change management overview 37 remote journal environment 37 change management. product 530 automatic recovery audit recommendations 531 automation 469 autostart job entry 158 changing job description 170 changing port information 171 created by MIMIX 169 identifying 169 when to change 169 benefits independent ASPs 519 LOB replication 98 best practice audit level 530 audit level before switch 531 bi-directional data flow 327 broadcast configuration 65 build journal environment after changing receiver size option 182 C candidate objects defined 361 cascade configuration 65 cascading distributions.#MBRRCDCNT rule 548. compare commands DLO attributes 393 file and member attributes 384 file data using active processing 424 file data using subsetting options 427 file data with repair capability 418 file data without active processing 415 files on hold 421 IFS object attributes 390 object attributes 387 auditing level. i5/OS object 25 performed by MIMIX 270 audits 447 authorities. journal attributes 573 #OBJATR rule. 619 #OBJATR rule. 614 #OBJATR rule 561. ASP attributes 577 #OBJATR rule. 455. 437. 437. 465 STRJRNFE 297 STRJRNIFSE 300 STRJRNOBJE 303 STRMMXMGR 269 STRSVR 168 SWTDG 25 SYNCDFE 432 SYNCDGACTE 432. by name Add Data Group Data Area Entry 262 Add Message Log Entry 479 Add Remote Journal Link 202 Change Data Group Data Area Entry 262 Change Journal Definition 194 Change RJ Link 204 Change System Definition 151 Change Transfer Definition 165 Check Data Group File Entries 276. 451. 415 Compare IFS Attributes 380 Compare Object Attributes 380 Compare Record Counts 396 Copy Configuration Data 508 705 .ADDRJLNK 202 CHGDGDAE 262 CHGJRNDFN 194 CHGRJLNK 204 CHGSYSDFN 151 CHGTFRDFN 165 CHKDGFE 276. 546 CLOMMXLST 493 CMPDLOA 380 CMPFILA 380 CMPFILDTA 399. 464 VFYCMNLNK 173. 174 VFYJRNFE 299 VFYJRNIFSE 302 VFYJRNOBJE 305 VFYKEYATR 326 WRKCRCLS 347 WRKDGDAE 261. 263 WRKDGDFN 229 WRKDGDLOE 263 WRKDGFE 263 WRKDGIFSE 263 WRKDGOBJE 263 WRKJRNDFN 229 WRKRJLNK 283 WRKSYSDFN 229 WRKTFRDFN 229 commands. 415 CMPIFSA 380 CMPOBJA 380 CMPRCDCNT 396 CPYCFGDTA 508 CPYDGDAE 263 CPYDGFE 263 CPYDGIFSE 263 CRTCRCLS 347 CRTDGDFN 221. 464 SYNCOBJ 431. 546 Close MIMIX List 493 Compare DLO Attributes 380 Compare File Attributes 380 Compare File Data 399. 438 SYNCDGFE 439. 449 SYNCDLO 431. 459 SYNCIFS 431. 225 CRTJRNDFN 192 CRTSYSDFN 150 CRTTFRDFN 163 DLTCRCLS 348 DLTDGDFN 230 DLTJRNDFN 230 DLTSYSDFN 230 DLTTFRDFN 230 DSPDGDAE 265 DSPDGFE 265 DSPDGIFSE 265 ENDJRNFE 298 ENDJRNIFSE 301 ENDJRNOBJE 304 ENDJRNPF 298 LODDGDAE 261 LODDGFE 246 LODDGOBJE 243 MIMIX 84 OPNMMXLST 493 RMVDGDAE 264 RMVDGFE 264 RMVDGFEALS 264 RMVDGIFSE 264 RMVRJCNN 207 RUNCMD 486 RUNCMDS 486 RUNRULE 529 RUNRULEGRP 529 SETDGAUD 270 SETIDCOLA 338 SNDNETDLO 468 SNDNETIFS 467 SNDNETOBJ 434. 437. 311 journaled IFS objects 70 communications APPC/SNA 144 configuring system level 140 job names 48 native TCP/IP 140 OptiConnect 144 protocols 140 starting TCP sever 168 compare commands completion and escape messages 472 outfile formats 379 report types and outfiles 378 spooled files 378 comparing DLO attributes 393 file and member attributes 384 IFS object attributes 390 object attributes 387 when file content omitted 352 comparing attributes attributes to compare 382 overview 380 706 . 451.Copy Data Group Data Area Entry 263 Copy Data Group File Entry 263 Copy Data Group IFS Entry 263 Create Collision Resolution Class 347 Create Data Group Definition 221. 263 Work with Data Group Definition 229 Work with Data Group DLO Entries 263 Work with Data Group File Entries 263 Work with Data Group IFS Entries 263 Work with Data Group Object Entries 263 Work with Journal Definition 229 Work with RJ Links 283 Work with System Definition 229 Work with Transfer Definition 229 commands. 449 Synchronize DG Activity Entry 432 Synchronize DG File Entry 432 Synchronize DLO 431. 464 Synchronize Object 431. 174 Verify Journaling File Entry 299 Verify Journaling IFS Entries 302 Verify Journaling Obj Entries 305 Verify Key Attributes 326 Work with Collision Resolution Classes 347 Work with Data Group Data Area Entries 261. 550 policy effect on compare record count 318 commitment control 98 #MBRRCDCNT audit performance 318 journal standby state. 459 Synchronize IFS 437 Synchronize IFS Object 431. 225 Create Journal Definition 192 Create System Definition 150 Create Transfer Definition 163 Delete Collision Resolution Class 348 Delete Data Group Definition 230 Delete Journal Definition 230 Delete System Definition 230 Delete Transfer Definition 230 Display Data Group Data Area Entry 265 Display Data Group File Entry 265 Display Data Group IFS Entry 265 End Journal Physical File 298 End Journaling File Entry 298 End Journaling IFS Entries 301 End Journaling Obj Entries 304 Load Data Group Data Area Entries 261 Load Data Group File Entries 246 Load Data Group Object Entries 243 MIMIX 84 Open MIMIX List 493 Remove Data Group Data Area Entry 264 Remove Data Group File Entry 264 Remove Data Group IFS Entry 264 Remove Remote Journal Connection 207 Run Command 486 Run Commands 486 Run Rule 529 Run Rule Group 529 Send Network DLO 468 Send Network IFS 467 Send Network Object 465 Send Network Objects 434 Set Data Group Auditing 270 Set Identity Column Attribute 338 Start Journaling File Entry 297 Start Journaling IFS Entries 300 Start Journaling Obj Entries 303 Start Lakeview TCP Server 168 Start MIMIX Managers 269 Switch Data Group 25 Synchronize Data Group Activity Entry 438 Synchronize Data Group File Entry 439. journal cache 309. 437. 455. 464 Verify Communications Link 173. run on remote system 486 commit cycles effect on audit comparison 548. 437. 421 referential integrity considerations 403 repairing files in *HLDERR 399 restrictions 400 security considerations 401 thread groups 409 transfer definition 409 transitional states 400 using active processing 424 using subsetting options 427 wait time 409 with repair capability 418 with repair capability when files are on hold 421 without active processing 415 comparing file record counts 396 configuration additional supporting tasks 266 copying existing data 513 results of #DGFE audit after changing 546 configuring advanced replication techniques 320 bi-directional data flow 327 cascading distributions 331 choosing the correct checklist 123 classes. physical files with apply session ignored 102 configuring 98 legacy cooperative processing 102 constraints. CMPFILA file-specific attribute 556 constraints. referential 101 contacting Vision Solutions 19 container send process 54 defaults 219 description 52 threshold 219 contextual transfer definitions considerations 162 RJ considerations 161 continuous mode 60 convert data group to advanced journaling 136 COOPDB (Cooperate with database) 104. 516 job restart time 285 keyed replication 323 library-based objects 91 message queue objects for user profiles 95 omitting T-ZC journal entry content 351 spooled file replication 93 to replicate SQL stored procedures 356 unique key replication 323 configuring. collision resolution 346 confirmed journal entries 61 considerations journal for independent ASP 524 what to not replicate 78 constraints apply session for dependent files 337 auditing with CMPFILA 380 comparing file data 402 omit content and legacy cooperative processing 352 referential integrity considerations 403 requirements 336 requirements when synchronizing 440 restrictions with high availability journal performance enhancements 311 support 336 when journal is in standby state 309 constraints. 108 cooperative journal (COOPJRN) behavior 97 cooperative processing and omitting content 352 707 . collision resolution 347 data areas and data queues 103 DLO documents and folders 111 file routing. 404 comparing file data 399 active server technology 399 advanced subsetting 410 allocated and not allocated records 401 comparing a random sample 410 comparing a range of records 407 comparing recently inserted data 407 comparing records over time 410 data correction 399 excluding unchanged members 410 first and last subset 413 interleave factor 411 job ends due to network timeout 404 keys. triggers. file combining 329 for improved performance 306 IFS objects 106 independent ASP 523 Intra communications 515. and constraints 402 multi-threaded jobs 400 network inactivity considerations 404 number of subsets 411 parallel processing 400 processing with DBAPY 399.supported object attributes 381. automatic 213 type 211 data group data area entry 261 adding individual 262 loading from a library 261 data group definition 35. legacy limitations 102 requirements and limitations 102 COOPJRN 97 COOPJRN (Cooperative journal) 212 COOPTYPE (Cooperating object types) 104 copying data group entries 263 definitions 229 create operation. 148 data management techniques 327 data queue restrictions of journaled 104 data queues journaling 69 synchronizing journaled objects 464 data source 210 database apply serialization 79 with compare file data (CMPFILDTA) 399. RJ link considerations 67 timestamps. preferred method for 49 introduction 49 journaled objects 50 legacy 50 legacy limitations 102 MIMIX Dynamic Apply limitations 101 cooperative processing.configuring files 96 file. 209 creating 221 parameter tips 210 data group DLO entry 259 adding individual 260 loading from a folder 259 data group entry 362 defined 86 description 24 object 242 procedures for configuring 241 data group file entry 246 adding individual 252 changing 253 loading from a journal definition 250 loading from a library 249. how replicated 116 CustomerCare 19 customizing 469 replication environment 470 D data area restrictions of journaled 104 data areas journaling 69 polling interval 214 polling process 74 synchronizing an object tracking entry 464 data areas and data queues verifying journaling 305 data distribution techniques 327 data group 24 convert to remote journaling 131 database only 101 determining if RJ link used 283 ending 40. 421 database apply process 73 description 63 threshold warning 217 database reader process 63 description 63 threshold 216 database receive process 73 database send process 73 description 73 filtering 212 threshold 216 708 . 64 RJ link differences 64 sharing an RJ link 63 short name 210 starting 40 starting the first time 282 switching 24 switching. 250 loading from FEs from another data group 251 loading from object entries 247 sources for loading 246 data group IFS entry 255 with independent ASPs 524 data group object entry adding individual 243 custom loading 242 independent ASP 524 with independent ASP 524 data library 34. complex 142 port alias. 543 directory entries managing 159 RDB 158 display output 481 displaying data group entries 265 definitions 231 distribution request. starting 279 defaults. subtree 376 job restart time 288 journal definitions for multimanagement environment 188 journal definitions for switchable data group 185 journal receiver exit program 502 load file entries for MIMIX Dynamic Apply 247 monitor for scheduling user rule 538 object entry matching 93 object retrieval delay 354 object selection process 368 object selection. command 494 definitions data group 35 journal 35 named 35 remote journal link 35 renaming 232 RJ link 35 system 35 transfer 35 delay times 147 delay/retry processing first and second 214 third 215 delete management journal receivers 181 overview 37 remote journal environment 38 delete operations journaled *DTAARA. 498 MIMIX Monitor 495 MIMIX Promoter 496 exit programs journal receiver management 182. subtree 371 port alias. files in error 587 example user-generated notification 536 examples convert to advanced journaling 80 DLO entry matching 112 IFS object selection. data-retrieval 53 DLOs example. 499 requesting customized programs 497 expand support 483 extended attribute cache 313 configuring 313 F failed request resolution 43 FEOPT (file and tracking entry options) 215 file 709 . resolving audit 541. simple 141 querying content of an output file 670 SETIDCOLA command increment values 342 user-defined rule 534 WRKDG SELECT statements 670 exit points 470 journal receiver management 495.DDM password validation 280 server in startup programs 278 server. IFS objects 121 legacy cooperative processing 121 deleting data group entries 264 definitions 230 delivery mode asynchronous 62 synchronous 60 detail report 482 differences. *DTAQ. entry matching 112 generic name support 111 keeping same name 218 object processing 111 duplicate identity column values 338 dynamic updates adding data group entries 252 removing data group entries 264 E ending CMPFILDTA jobs 414 ending journaling data areas and data queues 304 files 298 IFS objects 301 IFS tracking entry 301 object tracking entry 304 error code. order precedence in 369 object selection. new 294 file id (FID) 72 file identifiers (FIDs) 284 files combining 329 omitting content 350 output 483 routing 330 sharing 327 synchronizing 439 filtering database replication 73 messages 45 on database send 212 on source side 213 remote journal environment 63 firewall. created during installation 29 IFS file systems 106 unsupported 106 IFS object selection examples. journal receiver change 37 information and additional resources 18 installations. 310 journal code failed objects 592 H help. 220 system definition procedure 291 jobs. commitment control and 70 journaling 69 not supported 106 path names 107 supported object types 106 verifying journaling 302 710 . accessing 16 history retention 148 hot backup 21 I IBM i5/OS option 42 309 IBM objects to not replicate 78 IFS directory. 148 in data group definition 219 in product library 30 list of MIMIX 30 job log for audit 545 job name parameter 484 job names 47 job restart time 285 data group definition procedure 291 examples 287 overview 285 parameter 148. 464 independent ASP 520 limitations 522 primary 520 replication 518 requirements 522 restrictions 522 secondary 520 synchronizing data within an 436 independent ASP. restarted automatically 285 journal 25 improving performance of 306 maximum number of objects in 26 security audit 51 system 51 journal analysis 43 journal at create 114. multiple MIMIX 23 interleave factor 411 Intra configuration 514 IPL. journaled restrictions 109 supported operations 117 sychronizing 441. journal receiver change 37 G generic name support 363 DLOs 111 generic user exit 495 guidelines for auditing 530 J job classes 30 job description parameter 484 job descriptions 30. 214 requirements 294 requirements and restrictions 295 journal caching 180. using CMPFILDTA with 401 folder path names 111 IFS objects. subtree 376 subtree 366 IFS objects 106 file id (FID) use with journaling 72 file IDs (FIDs) 284 journaled entry types. data queues planning for 79 journaled IFS objects planning for 79 journaled object types user exit program considerations 81 journaling 25 cannot end 298 data areas and data queues 69 ending for data areas and data queues 304 ending for IFS objects 301 ending for physical files 298 IFS objects 69 IFS objects and commitment control 70 implicitly started 294 requirements for starting 294 starting for data areas and data queues 303 starting for IFS objects 300 starting for physical files 297 starting.files in error 585 system journal transactions 592 journal codes user journal transactions 585 journal definition 35 configuring 176 created by other processes 178 creating 192 fields on data group definition 211 parameter tips 179 remote journal environment considerations 184 remote journal naming convention 185 remote journal naming convention. ending. 181 prefix 180 RJ processing earlier receivers 38 size for advanced journaling 191 starting point 26 stranded on target 39 journal receiver management interaction with other products 38 recommendations 37 journal sequence number. 322 journal manager 33 journal receiver 25 change management 37. RJ environment considerations 39 journaling status data areas and data queues 303 files 297 IFS objects 300 K keyed replication 322 comparing file data restriction 400 file entry option defaults 215 preventing before-image filtering 213 restrictions 323 verifying file attributes 326 L large object (LOB) support user exit program 99 large objects (LOBs) minimized journal entry data 307 legacy cooperative processing configuring 99 limitations 102 requirements 102 libraries objects in installation libraries 78 711 . 38. 180 delete management 37. 67 journal entry codes 592 for data area and data queues 590 supported by MIMIX user journal processing 590 journal image 215. change during IPL 37 journal standby state 309 journaled data areas. multimanagement 187 remote journaling example 185 journal entries 25 confirmed 61 filtering on database send 212 minimized data 307 OM journal entry 117 receive journal entry (RCVJRNE) 314 unconfirmed 61. and verifying 293 verifying 447 verifying for data areas and data queues 305 verifying for IFS objects 302 verifying for physical files 299 journaling environment automatically creating 212 building 195 changing to *MAXOPT3 196 removing 207 source for values (JRNVAL) 195 journaling on target. 83 minimized journal entry data 307 LOBs 98 MMNFYNEWE monitor 114 monitor new objects not configured to MIMIX 114 monitors examples for creating 538 move/rename operations system journal replication 117 user journal replication 118 multimanagement journal definition naming 187 multi-threaded jobs 400 N name pattern 366 name space 51 names. displaying long 107 naming conventions data group definitions 210 journal definitions 179. contextual (*ANY) 162 transfer definitions. restart time for 285 MIMIX Model Switch Framework 495 MIMIX performance. data areas. improving 306 MIMIX rules 529 automatic audit recovery 531 command prompting 532 replacement variables 532 MIMIXOWN user profile 32.to not replicate 78 library list adding QSOC to 144 library list. 97 long IFS path names 107 M manage directory entries 159 management system 24 maximum size transmitted 157 MAXOPT3 receiver size option 182 MAXOPT3 value 191 menu MIMIX Configuration 268 MIMIX Main 84 message handling 147 message log 479 message queues associated with user profiles 95 journal-related threshold 182 messages 45 CMPDLOA 474 CMPFILA 472 CMPFILDTA 475 CMPIFSA 473 CMPOBJA 473 CMPRCDCNT 474 comparison completion and escape 472 MIMIX AutoGuard 447 MIMIX Dynamic Apply configuring 96. multiple network systems 152 network inactivity comparing file data 404 network systems 24 multiple 152 new objects automatically journal 214 automatically replicate 114 files 114 files processed by legacy cooperative processing 115 files processed with MIMIX Dynamic Apply 114 IFS object journal at create requirements 294 IFS objects. 280 MIMIXQGPL library 34 MIMIXSBS subsystem 34. configuring 91 limitations database only data group 101 list detail report 482 list summary report 482 load leveling 55 loading tracking entries 257 LOB replication 98 local-remote journal pair 60 log space 26 logical files 96. effect of independent ASP 525 library-based objects. data queues 115 712 . 187 multi-part 27 transfer definitions 156 transfer definitions. 185. 99 recommended for files 96 requirements and limitations 101 MIMIX environment 29 MIMIX installation 23 MIMIX jobs. process 368 examples.journal at create selection criteria 295 notification of objects not in configuration 114 notification retention 148 notifications user-defined 535 user-generated 528 O object journal entry codes 592 object apply process defaults 219 description 52 threshold 219 object attributes. 505 objects new 294 Omit content (OMTDTA) parameter 351 and comparison commands 352 and cooperative processing 352 open commit cycles audit results 548. data group creating 242 object locking retry interval 214 object processing data areas. subtree 371 name pattern 366 order precedence 362 parameter 362 process 360 subtree 365 object selector elements 362 by function 363 object selectors 362 object send process 52 description 51 threshold 218 object types supported 88. configuring 144 outfiles 595 MCAG 597 MCDTACRGE 600 MCNODE 602 MXCDGFE 604 MXCMPDLOA 606 MXCMPFILA 608 MXCMPFILD 610 MXCMPFILR 613 MXCMPIFSA 617 MXCMPOBJA 619 MXCMPRCDC 614 MXDGACT 621 MXDGACTE 623 MXDGDAE 631 MXDGDFN 632 MXDGDLOE 640 MXDGFE 642 MXDGIFSE 646. data queues 103 DLOs 111 IFS objects 108 library-based objects 89 omit T-ZC entry considerations 351 object entry. data queues 103 defaults 217 DLOs 111 high volume objects 317 IFS objects 106 retry interval 214 spooled files 93 object retrieval delay considerations 354 examples 354 selecting 354 object retrieve process 54 defaults 218 description 51 threshold 218 with high volume objects 317 object selection 360 commands which use 360 examples. 699 MXDGIFSTE 697 MXDGOBJE 674 MXDGOBJTE 699 MXDGSTS 648 MXDGTSP 677 MXJRNDFN 680 MXSYSDFN 687 MXTFRDFN 691 MZPRCDFN 693 713 . i5/OS manually set for a data group 270 set by MIMIX 56. 697. 270 object auditing value data areas. order precedence 369 examples. 550 OptiConnect. comparing 382 object auditing used for replication 294 object auditing level. 44 working with messages 45 files 297 IFS objects 300 problems. IBM 18 Q QAUDCTL system value 51 QAUDLVL system value 51.MZPRCE 694 user profile password 583 user profile status 580 WRKRJLNK 684 outfiles. 552 System 1 Indicator field 554 System 2 Indicator field 554 output queues 148 overview MIMIX operations 40 remote journal support 58 starting and ending replication 40 support for resolving problems 42 support for switching 24. supporting information record format 595 work with panels 596 output batch 484 considerations 480 display 481 expand support 483 file 483 parameter 480 print 481 output file querying content. 543. journaling data areas and data queues 303 R RCVJRNE (Receive Journal Entry) 314 configuring values 315 determining whether to change the value of 315 understanding its values 314 RDB 158 directory entries 158 RDB directory entry 167 reader wait time 211 receiver library. 94 QDFTJRN data area 214 restrictions 295 role in processing new objects 295 QRETSVRSEC system value 281 QSOC library 144 subsystem 278 P parallel processing 400 path names. CMPRCDCNT commit threshold 318 polling interval 214 port alias 141 complex example 142 creating 143 simple example 141 print output 481 printing controlling characteristics of 148 data group entries 265 definitions 232 private authorities. changing for RJ target journal 200 receivers 714 . *MSGQ replication of 95 problems. resolving audit results 541. IFS 107 performance improved record count compare 318 policy. object selection 360 processing defaults container send 219 database apply 217 file entry options 215 object apply 219 object retrieve 218 user journal entry 212 production system 23 publications. 546 process container send and receive 54 database apply 73 database reader 63 database receive 73 database send 73 names 47 object apply 54 object retrieve 54 object send 52 process. examples of 670 output file fields Difference Indicator 548. journaled *DTAARA. IFS objects 121 restriction journal receiver size *MAXOPT3 182 restrictions comparing file data 400 data areas and data queues 104 independent ASP 522 journal at create 295 journal receiver management 38 journaled *DTAARA. 63 remote journal link. synchronous delivery 60 MIMIX support 58 relational database 158 remote journal environment changing 200 contextual transfer definitions 161 receiver change management 37 receiver delete management 38 restrictions 59 RJ link 63 security implications 280 switch processing changes 44 remote journal link 35. asynchronous delivery 62 i5/OS function. 165 remote journal i5/OS function 25. keyed 322 process.change management 180 delete management 181 recommendation multimanagement journal definitions 187 recommendations audit automatic recovery 531 auditing 530 audits and rules 531 relational database (RDB) 158 entries 158. See also RJ link remote journaling data group definition 212 repairing file data 418 files in *HLDERR 399 files on hold 421 replacement variables 532 replication advanced topic parameters 213 by object type 88 configuring advanced techniques 320 constraint-induced modifications 337 data area 74 defaults for object types 88 direction of 23 ending data group 40 ending MIMIX 40 independent ASP 518 maximum size threshold 157 positional vs. 58 i5/OS function. *DTAQ objects 104 journaled IFS objects 109 keyed replication (unique key) 323 legacy cooperative processing 102 LOBs 99 MIMIX Dynamic Apply 101 number of objects in journal 26 QDFTJRN data area 295 715 . *DTAQ. remote journaling environment 63 retrieving extended attributes 313 spooled files 93 SQL stored procedures 356 starting data group 40 starting MIMIX 40 supported paths 21 system journal 21 system journal process 51 unit of work for 24 user journal 21 user profiles 435 user-defined functions 356 what to not replicate 78 replication path 46 reports detail 482 list detail 482 list summary 482 types for compare commands 378 requirement objects and journal in same ASP 26 requirements audits 530 independent ASP 522 journal at create 294 journaling 294 keyed replication 322 legacy cooperative processing 102 MIMIX AutoGuard 530 MIMIX Dynamic Apply 101 standby journaling 311 user journal replication of data areas and data queues 103 restarted 285 restore operations. data group activity entries 43 RJ link 35 adding 202 changing 204 data group definition parameter 212 description 63 end options 64 identifying data groups that use 283 sharing among data groups 63 switching considerations 67 threshold 213 RJ link monitors description 65 displaying status of 65 ending 65 not installed. status when 65 operation 65 rule groups MIMIX 539 rules 529 considerations for using 531 creating user-defined 534 example of user-defined 534 messages from 533 MIMIX 529 notifications from 533 relationship with rules 529 replacement variables 532 requirements 530 run command considerations 532 types 529 user-defined 528 user-generated. *ANY transfer definitions 160 security considerations. creating monitors for 538 S save-while-active 358 considerations 358 examples 359 options 359 wait time 358 search process. CMPFILDTA command 401 general information 76 remote journaling implications 280 security audit journal 51 sending DLOs 468 IFS objects 467 library-based objects 465 sequence number maximum size option 182 sequence number size option.remote journaling 59 standby journaling 311 retrying. *MAXOPT3 196 serialization database files and journaled objects 79 object changes with database 69 servers starting DDM 279 starting TCP 168 short transfer definition name 156 source physical files 96. 97 source system 23 spooled files 93 compare commands 378 keeping deleted 94 options 94 retaining on target system 218 SQL stored procedures 356 replication requirements 356 SQL table identity columns 338 alternatives to SETIDCOLA 340 check for replication of 343 problem 338 SETIDCOLA command details 341 SETIDCOLA command examples 342 SETIDCOLA command limitations 339 SETIDCOLA command usage notes 342 setting attribute 343 when to use SETIDCOLA 339 standby journaling IBM i5/OS option 42 309 journal caching 310 journal standby state 309 MIMIX processing with 310 overview 309 requirements 311 restrictions 311 starting data groups initially 282 system and journal managers 269 TCP server 168 TCP server automatically 169 starting journaling data areas and data queues 303 file entry 297 files 297 IFS objects 300 716 . data libraries 148 stranded journal on target. starting 83 QSOC 278 subtree 365 IFS objects 366 switching allowing 210 change audit level before 531 data group 24 enabling journaling on target system 211 example RJ journal definitions for 185 independent ASP restriction 523 MIMIX Model Switch Framework with RJ link 67 preventing identity column problems 338 remote journaling changes to 44 removing stranded journal receivers 39 RJ link considerations 67 synchronization check. 94 QRETSVRSEC 281 QSYSLIBL 144 system. 520 system ASP 519 system definition 35. data in an 436 initial 444 initial configuration 442 initial configuration MQ environment 442 limit maximum size 433 LOB data 435 object tracking entries 464 object. values affecting updates to 214 storage. automatic 213 synchronizing 431 activity entries overview 438 commands for 433 considerations 433 data group activity entries 462 database files 449 database files overview 439 DLOs 459 DLOs in a data group 459 DLOs without a data group 460 establish a start point 442 file entry overview 439 files with triggers 439 IFS objects 455 IFS objects by path name only 456 IFS objects in a data group 455 IFS objects without a data group 456 IFS tracking entries 464 including logical files 440 independent ASP. autostart job entry for 158 TCP/IP adding to startup program 278 configuring native 140 creating port aliases for 141 717 . 435 synchronous delivery 60 unconfirmed entries 61 SYSBAS 518.IFS tracking entry 300 object tracking entry 303 startup programs changes for remote journaling 278 MIMIX subsystem 83 QSOC subsystem 278 status journaling data areas and data queues 303 journaling files 297 journaling IFS objects 300 journaling tracking entries 300. 525 system manager 32 system user profiles 78 system value QAUDCTL 51 QAUDLVL 51. 303 status. IFS. roles 23 T target journal state 180 target system 23 TCP server. 146 changing 151 creating 150 parameter tips 147 system journal 51 system journal replication 21 advanced techniques 320 journaling requirements 294 omitting content 350 system library list 144. journal entries 39 subsystem MIMIXSBS. DLO overview 437 objects 451 objects in a data group 451 objects without a data group 452 related file 440 resources for 443 status changes caused by 435 tracking entries 441 user profiles 433. 154. 67 718 . 160 fields in data group definition 211 fields in system definition 147 multiple network system environment 152 other uses 154 parameter tips 156 short name 156 transfer protocols OptiConnect parameters 157 SNA parameters 157 TCP parameters 156 trigger programs defined 334 synchronizing files 335 triggers avoiding problems 402 comparing file data 402 disabling during synchronization 439 read 402 update. data queues 590 tracking entry 71 user profile MIMIXOWN 280 password 583 status 580 user profiles default 148 do not replicate MIMIX supplied 78 do not replicate system supplied 78 MIMIX 32 replication of 95 specifying status 218 synchronizing 433 system distribution directory entries 435 user-defined functions 356 V verifying communications link 173. physical files 299 key attributes 326 send and receive processes automatically 214 W wait time comparing file data 409 reader 211 U unconfirmed journal entries 61. 409 changing 165 contextual system support (*ANY) 28. data queues 258 loading for IFS objects 257 purpose 71 tracking entry file identifiers (FIDs) 284 transfer definition 35. automatic 213 tracking entries loading 257 loading for data areas. and delete 402 T-ZC journal entries access types 350 configuring to omit 351 omitting 350 unique key comparing file data restriction 400 file entry options for replicating 215 replication of 322 user ASP 519 user exit points 498 user exit program data areas and data queues 81 IFS objects 81 large objects (LOBs) 99 user exit.temporary files to not replicate 78 thread groups 409 threshold. IFS tracking entries 302 journaling. CMPRCDCNT commit 318 timestamps. object tracking entries 305 journaling. insert. backlog adjusting 225 container send 219 database apply 217 database reader/send 216 object apply 219 object retrieve 218 object send 218 remote journal link 213 threshold. 174 initial synchronization 447 journaling. generic 495 user journal replication 21 advanced techniques 320 journaling requirements 294 requirements for data areas and data queues 103 supported journal entries for data areas. WRKDG SELECT statement 670 719 .