| Where allowed to run: All environments (*ALL) Threadsafe: No |
Parameters Examples Error messages |
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:
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).
See the Journal Management information in the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter for a complete listing of the various entries and how they are handled by this command including those entries which can stop the command.
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.
If a ROLLBACK of an object level operation occurs due to an error condition, the system may potentially be in a state where partial record-level changes have been applied and some transactions are not at a commit boundary. Careful examination of the journal and user intervention is required at this point.
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:
The command also ends for an object when illogical conditions are encountered, such as attempts to do the following:
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 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 was causing 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.
| Top |
| Keyword | Description | Choices | Notes |
|---|---|---|---|
| JRN | Journal | Qualified object name | Required, Positional 1 |
| Qualifier 1: Journal | Name | ||
| Qualifier 2: Library | Name, *LIBL, *CURLIB | ||
| FILE | Journaled file identification | Values (up to 300 repetitions): Element list | Required, Positional 2 |
| Element 1: Journaled physical file | Qualified object name | ||
| Qualifier 1: Journaled physical file | *ALL | ||
| Qualifier 2: Library | Name | ||
| Element 2: Member | *ALL | ||
| RCVRNG | Range of journal receivers | Single values: *LASTSAVE, *CURRENT Other values: Element list |
Optional, Positional 3 |
| Element 1: Starting journal receiver | Qualified object name | ||
| Qualifier 1: Starting journal receiver | Name | ||
| Qualifier 2: Library | Name, *LIBL, *CURLIB | ||
| Element 2: Ending journal receiver |
Single values: *CURRENT Other values: Qualified object name |
||
| Qualifier 1: Ending journal receiver | Name | ||
| Qualifier 2: Library | Name, *LIBL, *CURLIB | ||
| FROMENTLRG | Starting large sequence number | Character value, *LASTSAVE, *FIRST | Optional |
| TOENTLRG | Ending large sequence number | Character value, *LASTRST, *LAST | Optional |
| TOTIME | Ending date and time | Element list | Optional |
| Element 1: Ending date | Date | ||
| Element 2: Ending time | Time | ||
| TOJOBO | Fully qualified job name | Qualified job name | Optional |
| Qualifier 1: Fully qualified job name | Name | ||
| Qualifier 2: User | Name | ||
| Qualifier 3: Number | 000000-999999 | ||
| TOJOBC | Fully qualified job name | Qualified job name | Optional |
| Qualifier 1: Fully qualified job name | Name | ||
| Qualifier 2: User | Name | ||
| Qualifier 3: Number | 000000-999999 | ||
| CMTBDY | Commitment boundary | *YES, *NO | Optional |
| OPTION | Option | *NONE, *IGNINQMSG | Optional |
| OBJERROPT | Object error option | *CONTINUE, *END | Optional |
| OUTPUT | Output | *NONE, *OUTFILE | Optional |
| OUTFILE | File to receive output | Qualified object name | Optional |
| Qualifier 1: File to receive output | Name | ||
| Qualifier 2: Library | Name, *LIBL, *CURLIB | ||
| OUTMBR | Output member options | Element list | Optional |
| Element 1: Member to receive output | Name, *FIRST | ||
| Element 2: Replace or add records | *REPLACE, *ADD | ||
| DETAIL | Detail | *ALL, *ERR | Optional |
| FROMENT | Starting sequence number | 1-9999999999, *LASTSAVE, *FIRST | Optional |
| TOENT | Ending sequence number | 1-9999999999, *LASTRST, *LAST | Optional |
| Top |
Specifies the journal associated with the journal entries that are being applied.
This is a required parameter.
Qualifier 1: Journal
Qualifier 2: Library
| Top |
Specifies a maximum of 300 library/*ALL combinations entries are being applied.
This is a required parameter.
Element 1: Journaled physical file
Qualifier 1: Journaled physical file
Note: At the time the apply is started, at least one journaled file must exist in the library (and the user must have the required authority) or the apply will not start.
Qualifier 2: Library
Element 2: Member
Specify the name of the member in the file that has its journal entries applied.
| Top |
Specifies the starting and ending journal receivers used in applying the journal entries. The system begins by applying the journal entries in the first journal receiver in this journal receiver range and proceeds through the receivers until it applies the journal entries in the last journal receiver in this journal receiver range.
Note: The maximum number of receivers that can be included in a range of receivers is 1024. If more than 1024 receivers are included in the range specified, an error message is sent and no changes are applied. You can change the values specified on this parameter so that the limit is not exceeded.
Single values
Element 1: Starting journal receiver
Qualifier 1: Starting journal receiver
Qualifier 2: Library
Element 2: Ending journal receiver
Qualifier 1: Ending journal receiver
Qualifier 2: Library
| Top |
Specifies the entry that is used as the starting point for applying changes that have been journaled.
You can specify a value for either the Starting sequence number (FROMENT) parameter or the Starting large sequence number (FROMENTLRG) parameter, but not for both.
If the restored version of the object was a version that was saved using the save-while-active function, then the system will start applying changes from the corresponding start-of-save entry whether or not this was actually the last save of the object. When using save-while-active, information needed for applying journaled changes is saved with the object and restored. When all objects specified on the apply command have been restored from save versions that used save-while-active, the system does not need to scan all the journal receivers to find the save points for the objects. This can improve the performance of the apply processing.
If the restored version of the object was a version that was saved when it was not in use (normal save), then the system verifies information for each object specified, such as if the date and time of the restore is after the date and time of the last save. The system also verifies that the date and time of the saved version of the object that is restored on the system is the same as the date and time that the object was last saved, as indicated on the journal.
If the dates and times do not match, no entries are applied and an inquiry message (CPA7050) is sent to the user or system operator requesting a cancel or ignore response. If an ignore response is given to the message, the operation is attempted. A cancel response causes the operation to end, and no journal entries are applied.
If the object was last saved with the save-while-active function, the saved copy of each object includes all changes in the journal entries up to the corresponding start-of-save journal entry. In this case, the system applies changes beginning with the first journal entry following the start-of-save entry.
If the object was last saved when it was not in use (normal save), the saved copy of each object includes all changes in the journal entries up to the corresponding object saved journal entry. In this case, the system applies changes beginning with the first journal entry following the object saved entry.
Note: If any database file members were saved specifying *NOCMTBDY as the second element of the SAVACTWAIT parameter on the save command and are currently in a state where apply journaled changes is required, then *LASTSAVE must be specified. If apply journaled changes cannot be used to complete the partial transactions, then the remove journaled changes (RMVJRNCHG) command can be used to just remove the partial transactions. If neither APYJRNCHG nor RMVJRNCHG can be used, and no other version of the file can be restored, then as a last resort, the Change Journaled Object (CHGJRNOBJ) command can be used to allow the file to be used while leaving the partial transactions within the object.
Note: When entering a sequence number, the Range of journal receivers (RCVRNG) parameter cannot be *LASTSAVE and the Ending large sequence number (TOENTLRG) parameter cannot be *LASTRST.
Note: For object level entries in the journal, the FROMENTLRG used is the earliest FROMENTLRG from any file member in the selection list that exists at the start of the apply.
| Top |
Specifies the entry used as the ending point for applying changes that have been journaled.
You can specify a value for either the Ending sequence number (TOENT) parameter or the Ending large sequence number (TOENTLRG) parameter, but not for both.
If an object is created as a result of applying changes to another object, the ending apply point for the newly created object is the greatest ending point of all the objects being applied to.
This parameter value is only valid if *LASTSAVE is also specified on the Starting sequence number (FROMENT) parameter or on the Starting large sequence number (FROMENTLRG) parameter. *LASTRST is assumed if none of the following parameters are specified:
Note: For object level entries in the journal, the TOENTLRG used is the last TOENTLRG from any file member in the selection list that exists at the start of the apply.
| Top |
Specifies the time and date of the last journal entry that is applied. The first entry with that or the next earlier time is the ending point for the applying of journal entries.
The time can be specified in 24-hour format with or without a time separator:
Element 1: Ending date
Element 2: Ending time
| Top |
Specifies the job identifier of the job that, when it opens an object that is specified ends the applying of journal entries by this command. The first job open entry found for any of the specified objects, is the ending point for all the objects specified.
The TOJOBO parameter 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.
| Top |
Specifies the job identifier of the job that ends the applying of journal entries by this command. The first job close entry found for any of the specified objects, is the ending point for all objects specified. The applying of journal entries is ended when either of the following occurs:
The TOJOBC parameter 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.
| Top |
Specifies whether commitment boundaries are honored when the journal entries to which journaled changes are to be applied are part of a commitment control logical unit of work (LUW). More information on the use of commitment control is in the Database information in the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter.
Note: For purposes of this parameter description, the TO option is used to describe either the TOENT, the TOENTLRG, the TOTIME, the TOJOBO, or the TOJOBC parameter, whichever is specified.
Note: If a journal entry is encountered that causes the operation to end before the entry indicated on the TO option, commitment boundaries might not be honored. In addition, if pending object level operations exist, they are either committed or rolled back, determined by looking ahead in the journal for that transaction's Journal Code C Entry Type CM or RB journal entry. This may result in a partial transaction being applied and commitment boundaries might not be honored. If a C/CM or C/RB entry is not found in the journal, the object level operations are rolled back.
Note: If CMTBDY(*NO) is specified and any object being applied to has been restored from a saved version that contains partial transactions, the changes pending for those partial transactions will not be removed if the transactions do not complete within the specified range. The original pending changes, along with any new changes for the partial transaction will remain in the object at the end of the apply operation. The object will only be usable if all pending transactions complete within the specified range.
Note: Even with CMTBDY(*NO) specified, commitment control is used during the apply for object level operations. This does not affect the range of journal entries selected, which is still as described above. If pending object level operations exist, they are either committed or rolled back, determined by looking ahead in the journal for that transaction's C/CM or C/RB journal entry.
| Top |
Specifies whether additional checking should be done prior to applying journal changes.
| Top |
Specifies how the processing of journal entries should proceed when an error situation is encounterd.
| Top |
Specifies whether a list of information about the objects to whom changes were applied is created. The information can be directed to a database file.
Note: You must specify the database file name on the File to receive output (OUTFILE) parameter when OUTPUT(*OUTFILE) is specified.
| Top |
Specifies the database file to which the information is directed when *OUTFILE is specified on Output (OUTPUT) parameter. If the file does not exist, this command creates a database file in the specified library. If a new file is created, the system uses QAJRNCHG in QSYS with the format name QJOAPYRM as a model.
Qualifier 1: File to receive output
Qualifier 2: Library
| Top |
Specifies the name of the database file member to which the output is directed when *OUTFILE is specified for the Output (OUTPUT) parameter.
Element 1: Member to receive output
If the member exists, you can add records to the end of the existing member or clear the existing member and add the records.
Element 2: Replace or add records
| Top |
Specifies the type of information that is directed to the output file.
| Top |
Specifies the entry that is used as the starting point for applying changes that have been journaled.
You can specify a value for either the Starting sequence number (FROMENT) parameter or the Starting large sequence number (FROMENTLRG) parameter, but not for both.
If the restored version of the object was a version that was saved using the save-while-active function, then the system will start applying changes from the corresponding start-of-save entry whether or not this was actually the last save of the object. When using save-while-active, information needed for applying journaled changes is saved with the object and restored. When all objects specified on the apply command have been restored from save versions that used save-while-active, the system does not need to scan all the journal receivers to find the save points for the objects. This can improve the performance of the apply processing.
If the restored version of the object was a version that was saved when it was not in use (normal save), then the system verifies information for each object specified, such as if the date and time of the restore is after the date and time of the last save. The system also verifies that the date and time of the saved version of the object that is restored on the system is the same as the date and time that the object was last saved, as indicated on the journal.
If the dates and times do not match, no entries are applied and an inquiry message (CPA7050) is sent to the user or system operator requesting a cancel or ignore response. If an ignore response is given to the message, the operation is attempted. A cancel response causes the operation to end, and no journal entries are applied.
If the object was last saved with the save-while-active function, the saved copy of each object includes all changes in the journal entries up to the corresponding start-of-save journal entry. In this case, the system applies changes beginning with the first journal entry following the start-of-save entry.
If the object was last saved when it was not in use (normal save), the saved copy of each object includes all changes in the journal entries up to the corresponding object saved journal entry. In this case, the system applies changes beginning with the first journal entry following the object saved entry.
Note: If any database file members were saved specifying *NOCMTBDY as the second element of the SAVACTWAIT parameter on the save command and are currently in a state where apply journaled changes is required, then *LASTSAVE must be specified. If apply journaled changes cannot be used to complete the partial transactions, then the remove journaled changes (RMVJRNCHG) command can be used to just remove the partial transactions. If neither APYJRNCHG nor RMVJRNCHG can be used, and no other version of the file can be restored, then as a last restore, the Change Journaled Object (CHGJRNOBJ) command can be used to allow the file to be used while leaving the partial transactions within the object.
Note: When entering a sequence number, the Range of journal receivers (RCVRNG) parameter cannot be *LASTSAVE and the Ending sequence number (TOENT) parameter cannot be *LASTRST.
Note: For object level entries in the journal, the FROMENT used is the earliest FROMENT from any file member in the selection list that exists at the start of the apply.
| Top |
Specifies the entry used as the ending point for applying changes that have been journaled.
You can specify a value for either the Ending sequence number (TOENT) parameter or the Ending large sequence number (TOENTLRG) parameter, but not for both.
If an object is created as a result of applying changes to another object, the ending apply point for the newly created object is the greatest ending point of all the objects being applied to.
This parameter value is only valid if *LASTSAVE is also specified on the Starting sequence number (FROMENT) parameter or the Starting large sequence number (FROMENTLRG) parameter. *LASTRST is assumed if none of the following parameters are specified:
Note: For object level entries in the journal, the TOENT used is the last TOENT from any file member in the selection list that exists at the start of the apply.
| Top |
Example:
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.
| Top |
*ESCAPE Messages
| Top |