CL Command Reference - APYJRNCHGX
CL Command List > APYJRNCHGX Reference
Description:
The Apply Journaled Changes Extend (APYJRNCHGX) command applies the changes that have been journaled for a particular journaled object to a saved version of the object to recover it after an operational error or some form of damage.
There are slight differences between this command and the Apply Journaled Changes (APYJRNCHG) command. This command only applies entries for database files and requires entries to be applied for all files in a library. This command will also apply entries for logical files found in the library, and it will apply the create file (D CT) journal entry. The APYJRNCHG command will not apply entries for logical files, or the create file entry.
Some object level changes that are applied are entries from SQL statements. The replay of these entries can cause the Apply Journaled Changes (APYJRNCHGX) command to run for a long time. The default time-out for the replaying of the ALTER TABLE, REFRESH TABLE or the reorganizing physical file entry is 24 hours. The default time-out for commit, rollback or cancel rollback entry is 12 hours. The default time-out for the replaying of the DROP TABLE entry is 1 hour. The default time-out for other object level change entries from SQL statements is 5 minutes.
If you want to change these default values to a higher or lower value, then add an environment variable called:
. QIBM_JO_APPLY_ALTER_TABLE_TIMEOUT - alter table (D CG) entry
. QIBM_JO_APPLY_REFRESH_TABLE_TIMEOUT - refresh table (D TQ) entry
. QIBM_JO_APPLY_DROP_TABLE_TIMEOUT - drop table (F DM) entry
. QIBM_JO_APPLY_REORG_TIMEOUT - reorganize physical file (F RM) entry
. QIBM_JO_APPLY_TIMEOUT - for other object level change entries
. QIBM_JO_APPLY_CM_RB_CN_TIMEOUT - commit (C CM), rollback (C RB), cancel rollback (C CN) entry
The value for all the environment variables is in seconds.
The minimum for any of these environment variable is 60 seconds. If a value of less than 60 is specified for any of these environment variables, a value of 60 seconds will be used.
Environment variables must be in all capital letters and set before issuing the APYJRNCHGX command.
Note: The commands to manipulate environment variables are Add Environment Variable (ADDENVVAR), Change Environment Variable (CHGENVVAR) and Work with Environment Var (WRKENVVAR).
APYJRNCHGX has nearly the same parameter list as APYJRNCHG for compatibility purposes but the OBJ and OBJPATH parameters are not available. Also, the file specification is restricted to library/*ALL, and the member specification is restricted to *ALL
A secondary thread is used to apply the object level changes. The apply of some journal entries may fail if the QMLTTHDACN system value is set to 3 (*NORUN). The recommended setting for QMLTTHDACN during an APYJRNCHGX operation is 2. The status of the secondary thread may be monitored using WRKJOB option 20.
The journaled changes are applied from the specified starting point, either the point at which an object was last saved or a particular entry on the journal, until the specified ending point has been reached. The ending point can be the point at which the object has had all changes applied, the object was last restored, a specified entry has been reached, a specified time has been reached, or the object was opened or closed by a job (the CMTBDY parameter is used for handling changes that are still pending).
Note: If you delete any files prior to restoring the database library as part of your recovery scenario, you must be careful when selecting the range of journal entries to apply. Remember that ¡åDELETE FILE¡å entries in the journal will be applied, if they are included in the specified range. In this case, it is recommended that you specify either a specific ending journal sequence number, or recover to a specific date and time (which would be prior to starting any recovery steps).
Note: The Display Journal (DSPJRN) command can be used to help determine the desired starting and/or ending points.
A list of journaled objects can be specified. The journaled changes are applied in the order that the journal entries are found on the journal, which is the same order in which the changes were made to the objects.
Like the APYJRNCHG command, record-level operations are not performed under commitment control. However, any object level operations that were originally performed under commitment control are also performed under commitment control during the apply. If the commitment control transaction was originally committed, the object level operations will be committed when the corresponding commit entry is applied. If the commitment control transaction was originally rolled back, the object level operations will be rolled back when the corresponding rollback entry is applied.
If an error occurs during the apply before the corresponding commit or rollback entry is applied, any pending object level operations are either committed or rolled back, depending on whether the transaction was originally committed or rolled back. Since pending object level operations prior to that journal sequence number may be rolled back, careful examination of the journal and user intervention is required before starting the apply again.
For example, a transaction contains several inserts, followed by an ALTER TABLE to add a column, followed by several more inserts (with the new record length), but ends in a ROLLBACK. If the apply operation was interrupted just after the ALTER TABLE, the system would recognize that the transaction ended in a ROLLBACK and would roll back the ALTER TABLE. If the apply operation were restarted in this case, the second set of inserts would fail due to a record length mismatch. While this scenario is unlikely, it is important to understand the mechanics behind the apply, in order to continue the apply after an error.
If a journal code J entry type SI (Enter JRNSTATE(*STANDBY)) entry is found, the operation ends for all objects specified regardless of the OBJERROPT value specified. Objects may be only partially updated from the journal entries.
Additionally, the command can end applying for an individual object when journal entries list operations which cannot be replayed by the command. If additional changes for this particular object are encountered during this apply, then those changes will not be applied. However, the operation will continue for the other objects specified if OBJERROPT(*CONTINUE) is specified. For example, the command ends for an object when a journal entry is found that indicates one of the following has occurred:
. A physical database file member was restored.
. Journaling was ended for a physical database file.
. The system had already applied or removed the changes through the Apply Journaled Changes (APYJRNCHG or APYJRNCHGX) command or the Remove Journaled Changes (RMVJRNCHG) command.
The command also ends for an object when illogical conditions are encountered, such as attempts to do the following:
. To add a record to an existing relative record number for a database file member
. To add a record beyond the next record position after the end of the database file
. To add a record that has a duplicate key for a database file member
. To delete a deleted record for a database file member
. To update a nonexistent record for a database file member
Most illogical conditions are caused by starting the apply journaled changes operation at the wrong place in the journal with respect to the current contents of the objects.
If the command ends due to illogical conditions and it is logically possible to restart the apply operation, you can issue the command again specifying a new starting sequence number.
It is possible to apply changes even if the sequence numbers have been reset. The system sends an informational message and continues to apply the changes.
Restrictions:
. This command is shipped with public *EXCLUDE authority and the QPGMR and QSRV user profiles have private authorities to use the command. If FILE(library-name/*ALL) or OBJ(library-name/*ALL) is specified, the journal entries for objects to which a user is not authorized will be ignored.
. The objects specified on this command must currently have their changes journaled.
. If a restore operation occurs before the apply operation, the object being restored must have been journaled at the time of the save operation.
. The objects indicated on the command are allocated exclusively while the changes are being applied. If an object cannot be allocated, the command ends and no journaled changes are applied.
. If there is no journal entry that corresponds to the period indicated on the command, the command ends and no journaled changes are applied.
. If the journal sequence numbers have been reset in the range of the receivers specified, and a sequence number is specified on the FROMENT, FROMENTLRG, TOENT, or TOENTLRG parameter, the first occurrence of the sequence number specified on any of the parameters is used.
. The TOJOBO and TOJOBC parameters cannot be used to specify when the apply journaled changes operation is to end if one or more journal receivers in the specified receiver range was attached to a journal with RCVSIZOPT(*MINFIXLEN) in effect.
. The TOJOBO and TOJOBC parameters cannot be used if the object for which changes are being applied was not recording open and close entries. For further clarification, refer to the Omit journal entry (OMTJRNE) parameter for the STRJRN, STRJRNPF, and CHGJRNOBJ commands.
. The maximum number of objects that can have changes applied with this command is 12,000,000. If more than 12,000,000 objects are included in the specifications, an error message is sent and no changes are applied. This limit will include any objects which are created as a result of applying object level operations. If this limit is reached, the new member will not be created. The apply will end for the object that wascausing the create (a database file) at that point (and all entries up to that point will be applied). The apply will continue with other members in the file and other files if OBJERROPT(*CONTINUE) was specified. When applying changes for a database file, there is one object associated with each member and one additional object associated with the file.
. Using APYJRNCHGX to apply changes from a journal receiver with journal entries deposited from another release (either previous or later) may cause unexpected results.
Examples:
APYJRNCHGX JRN(MYCOLL/QSQJRN) FILE(MYCOLL/*ALL)
This command causes the system to apply all journaled changes to all files in the MYCOLL collection since the last save. The receiver range is determined by the system. The changes are applied beginning with the first journaled change on the receiver chain after each file was last saved and continue through all applicable journal entries to the point at which the files were last restored.
All object level entries (e.g.,CREATE/DROP/ALTER TABLE) for the MYCOLL collection are included. Commitment control boundaries are honored, because the default value for the CMTBDY parameter, *YES, is used.