The JOURNAL_INHERIT_RULES view returns the journal inherit rules for
libraries.
The rules define which objects created in a library, moved into a library, or restored into a
library should inherit the journal state of the library and the inherited journal attributes.
Each rule defines object types, object names, and operations that the rule applies to. Multiple
rules can be defined for the same set of objects. If multiple rules are defined for the same object
and operation, the last rule defined for that object will be applied.
This information is similar to the journal inherit rules returned by the Retrieve Library
Description (QLIRLIBD) API.
Authorization: The caller must have *READ authority to the library.
The following table describes the columns in the view. The system name is LIB_JRN. The schema is
QSYS2.
Table 1. JOURNAL_INHERIT_RULES view
| Column Name |
System Column Name |
Data Type |
Description |
| LIBRARY_NAME |
LIBRARY |
VARCHAR(10) |
The name of the library for this rule. |
| JOURNALED |
JOURNALED |
VARCHAR(3) |
The current journaling status of the library. Rules are only in
effect when the library is journaled.
- NO
- The library is not currently journaled.
- YES
- The library is currently journaled.
|
| IASP_NUMBER |
IASPNUMBER |
INTEGER |
The number of the auxiliary storage pool (ASP) from which the system allocates
storage for the library. 1 indicates the system ASP. |
| IASP_NAME |
IASP_NAME |
VARCHAR(10) |
The device description name of the independent auxiliary storage pool (IASP).
The special value of *SYSBAS indicates SYSBASE, which includes the system ASP (ASP 1) and the
basic user ASPs (ASPs 2-32).
|
| ORDINAL_POSITION |
ORDINAL |
INTEGER |
The order this rule was added for this library. The number starts at one for
each library and increments by one for every additional rule for that library. If more than one
rule is defined for any object, the one with the higher number will be used. |
| OBJECT_TYPE |
TYPE |
VARCHAR(7) |
Specifies the object type of the objects that are identified by this rule.
- *ALL
- This rule applies to all object types that can be journaled.
- *DTAARA
- This rule applies to data areas.
- *DTAQ
- This rule applies to data queues.
- *FILE
- This rule applies to database physical files.
|
| OPERATION |
OPERATION |
VARCHAR(10) |
The operations performed on the object type for which journaling is to be
started if other criteria specified for the object type are also satisfied.
- *ALLOPR
- Journaling is started for all objects created in, moved into, or restored into the library. This
is a combination of the values *CREATE, *MOVE, and *RESTORE.
- *CREATE
- Journaling is started for all objects created in the library.
- *MOVE
- Journaling is started for all objects moved into the library if they are not already
journaled.
- *RESTORE
- If an object is restored over a currently existing object, the restored object will retain the
same journal options and journal state of the object it was restored over. If an object was never
journaled when it was saved, journaling is started for the object when it is restored into the
library. If an object was journaled when it was saved, it will first attempt to start journaling to
the journal it was journaled to when it was saved, with the same journal options it had when it was
saved. If that journal does not exist, the object will start journaling to the same journal the
library is journaled to, with the journal options defined by this rule.
- *RSTOVRJRN
- If an object is restored over a currently existing object, the restored object will retain the
same journal options and journal state of the object it was restored over. Otherwise, journaling is
started for all objects restored into the library, regardless of the journal options and journal
state of the object when it was saved.
|
| RULE_ACTION |
ACTION |
VARCHAR(8) |
Indicates whether the objects that match the object type and operation in this
rule will be included or omitted from the list of objects that inherit the journal options and
journal state of the library.
- *INCLUDE
- All objects that match the object type and operation of this rule will inherit the journal
options and journal state of the library.
- *OMIT
- All objects that match the object type and operation of this rule will not inherit any
journaling attributes or state from the library. This overrides a *INCLUDE rule and therefore can be
used to omit a subset of a previously defined *INCLUDE rule.
|
| NAME_FILTER |
NAMEFILTER |
VARCHAR(10) Nullable
|
The object names of the objects that are identified by this rule.
- name
- This rule applies to all objects that match the other criteria and match the specified name.
- generic-name
- This rule applies to all objects that match the other criteria and match the specified generic
name.
A generic name is specified as a string that contains one or more characters followed by an
asterisk (*). If a generic name is specified, then all objects that have names with the same prefix
as the generic object name are selected.
- *ALL
- This rule applies to all objects that match the other criteria.
|
| JOURNAL_IMAGES |
IMAGES |
VARCHAR(7) Nullable
|
The kinds of journal images that are written to the journal receiver for changes
to objects that inherit the journal options and journal state from the library.
- *AFTER
- Only after images are journaled for an object for which journaling is started because it
inherits the journaling attributes from the library.
- *BOTH
- Both before and after images are journaled for an object for which journaling is started because
it inherits the journal option from the library. This value is only valid for data area (*DTAARA)
and database file (*FILE) objects. If this value is specified and *ALL is specified for object type,
the system will generate both before and after images for data areas and database files and the
system will only generate after images for all other object types.
- *OBJDFT
- The default value for each object type will be used for this journal option when an object
inherits the journaling attributes from the library. Database files (*FILE) will have both before
and after images generated by the system. All other object types will have only after images
generated by the system.
Contains the null value if RULE_ACTION is *OMIT.
|
| OMIT_JOURNAL_ENTRY |
OMIT_ENTRY |
VARCHAR(7) Nullable
|
The journal entries that are not to be written for changes to objects that
inherit the journaling options and state of the library.
- *NONE
- No journal entries will be omitted for objects that inherit the journal options and journal
state from the library.
- *OBJDFT
- The default value for each object type will be used for this journal option when an object
inherits the journal options and journal state from the library. Open and close entries will be
omitted for database files (*FILE). No other object types will omit journal entries.
- *OPNCLO
- Open and close entries are omitted for database file (*FILE) objects that inherit the journal
options and journal state from the library.
This prevents the use of TOJOBO and TOJOBC entries on
the Apply Journaled Changes (APYJRNCHG) and Remove Journaled Changes (RMVJRNCHG) commands, but it
saves some storage space in the journal receivers.
This value is only valid for object type
*FILE. If this value is specified and *ALL is specified for object type, database files will omit
the entries. All other object types will not omit any journal entries.
Contains the null value if RULE_ACTION is *OMIT.
|
| REMOTE_JOURNAL_FILTER |
RMT_FILTER |
VARCHAR(7) Nullable
|
Specifies whether the journal entries written for the objects that inherit the
journal state of the library should be eligible for remote journal filtering by object.
- *NO
- Journal entries deposited for the objects that inherit the journal state of the library will not
be eligible for remote journal filtering by object.
- *OBJDFT
- The default value for each object type will be used for this journaling attribute when an object
inherits the journal state of the library. For all object types, journal entries deposited for the
objects that inherit the journal state of the library will not be eligible for remote journal
filtering by object.
- *YES
- Journal entries deposited for the objects that inherit the journal state of the library will be
eligible for remote journal filtering by object. When using remote journal filtering by object, most
journal entries for the object will not be sent to the target system.
|