DB2 CHECK PENDING

Check pending status is set on following situations.

1. When you use ALTER TABLE to add a check constraint to already populated tables, and CURRENT RULES special register is DB2®, the check constraint is added to the table description but its enforcement is deferred. Because there might be rows in the table that violate the check constraint, the table is placed in CHECK-pending status.

2. When a table is LOADed with ENFORCE NO option, then the table is left in CHECK PENDING status as DB2 bypasses referential integrity and check constraints

3. An index might be placed in CHECK-pending status if you recovered an index to a specific RBA or LRSN from a copy and applied the log records, but you did not recover the table space in the same list. The CHECK-pending status can also be set on an index if you specified the table space and the index, but the recovery point in time was not a point of consistency (QUIESCE or COPY SHRLEVEL REFERENCE).

To reset this status, run the CHECK DATA utility, which locates invalid data and, optionally, removes it. If CHECK DATA removes the invalid data, the remaining data satisfies all check and referential constraints and therefore, the CHECK-pending restriction is removed.

1. If a table space is in both REORG-pending and CHECK-pending status (or auxiliary CHECK-pending status), run the REORG TABLESPACE utility first and then run CHECK DATA to reset the respective states.

2.Run the CHECK INDEX utility on the index. If any errors are found, use the REBUILD INDEX utility to rebuild the index from existing data.

3.Use the REPAIR utility with the SET STATEMENT and NOCHECKPEND option.

Following jobs remove copy pending and recovery pending status from a table space and removes copy pending, recovery pending status and rebuild pending status from an index space

//STEPO1 EXEC PGM=DSNUTILB,REGIONM, 

// PARM='DB2X,MIGRDAN, '

//STEPLIB DD DSN=XXX.XXXXX.SDSNLOAD,DISP=SHR

//SYSIN DD *    

REPAIR SET TABLESPACE XXXXX.XXXXX NOCOPYPEND 

REPAIR SET TABLESPACE XXXXX.XXXXX NORCVRPEND

REPAIR SET INDEX XXXXX.XXXXX NOCOPYPEND

REPAIR SET INDEX XXXXX.XXXXX NORCVRPEND

REPAIR SET INDEX XXXXX.XXXXX NORBDPEND

/*

//SYSPRINT DD SYSOUT=* 

//UTPRINT DD SYSOUT=*

DB2 COPY PENDING

COPY PENDING 

A state in which, an Image Copy on a table needs to be taken. In this status, the table is available only for SELECT queries(read ONLY). You cannot update the table. 

It happens in the following situations. 

1. When you load the table with LOAD TABLE LOG NO and failed to include NOCOPYPEND
2. when image copies job fails while copying the data to Tape or DASD. 

To remove the COPY PENDING status

1. you take an image copy and the Tablespace status changes from copy pending to RW

If you dont want to take image copy, you can do the below

2. use the below REPAIR command to reset the tablespace status
REPAIR SET TABLESPACE XXXXX.XXXXX NOCOPYPEND 

3. You can execute following db2 command to bring the status of tablespace to RW. This command releases most restrictions for the named objects
-START DATABASE(dbname) SPACE(tablespace-name) ACESS(FORCE) .

Following jobs remove copy pending and recovery pending status from a table space and removes copy pending, recovery pending status and rebuild pending status from an index space

//STEPO1 EXEC PGM=DSNUTILB,REGIONM, 
// PARM='DB2X,MIGRDAN, '
//STEPLIB DD DSN=XXX.XXXXX.SDSNLOAD,DISP=SHR
//SYSIN DD *    
REPAIR SET TABLESPACE XXXXX.XXXXX NOCOPYPEND 
REPAIR SET TABLESPACE XXXXX.XXXXX NORCVRPEND
REPAIR SET INDEX XXXXX.XXXXX NOCOPYPEND
REPAIR SET INDEX XXXXX.XXXXX NORCVRPEND
REPAIR SET INDEX XXXXX.XXXXX NORBDPEND
/*
//SYSPRINT DD SYSOUT=* 
//UTPRINT DD SYSOUT=*

CICS BMS MAP LOW-VALUES

Input Mapping

When BMS makes the map available to your program on a RECEIVE MAP operation it
places data in three areas for each input field. These three areas are the length
field, the flag/attribute byte and the data field.

There are several situations at execution time for which BMS allows. In the
physical map, a length for the field is specified. If more data is keyed in than
is specified in this length, the data is truncated on the right and the length
field is set to the truncated length. If less data is keyed in than the length
specified, the length field is set to the number of characters entered and the
data field is padded on the right with blanks or on the left with zeros
(depending on whether the field is alpha or numeric). However, if any data was
previously in the field and the keyed data failed to cover up the old data, the
entire field would be returned with a length representing the original field
length.

There is an exception to the right-justify, zero-fill feature for a numeric item.
If the numeric field is initialized with other characters previous to the data
you entered, your data may not come in right-justified and zero-filled.

The flag byte is almost always initialized to X'00' when the map comes to you.
The length field is usually used to tell whether or not any data has been
entered. Data has been entered in the field when the length field is not equal
low-values (nulls). However, a special situation occurs when a field is modified
but no data is sent (as when a field is modified to low values with the erase to
end-of-file key). The length field would show as zero and there would be no data
in the data field. To be able to tell when this has happened, the flag byte is
set to X'80' and the length area is set to zeros. Therefore, if the flag byte is
set to X'80', the user has cleared the field. The length and data areas of any
fields that are defined but not modified are set to low values (X'00').

Output Mapping

Do not re-use symbolic mapping areas under BMS unless they are cleared to low
values. BMS relies on x'00' in the first byte of a field to construct
an accurate output data stream.

To place data in the output map, move it to the output data field. Be careful,
however, not to let any low-value (X'00') characters begin your field or BMS will
ignore that field. If a field begins with low values, the data in the field is
not returned to the program.

It is also possible to change the attribute of the output field. This can be done
when the input and output portions of the map redefine each other. In that case,
you have to move the desired attribute byte into the input map's attribute byte
and your attribute will override what was originally specified. However, when the
map is received, that byte is reset.

You may code your own attribute constants to supplement the attributes supplied
by IBM. Sample explanation for some of the attributes followed by the COBOL
statements defining some additional attributes are shown as follows:

'I': Moving 'I' to the attribute byte for an alphanumeric field in error will
make this field high intensity, unprotected and MDT on.

'R': Moving 'R' to the attribute byte for a numeric field in error will make this
field high intensity, unprotected, numeric lock on and MDT on.

'4': Moving '4' to the attribute byte for a edited field that has passed the
edits will protect this field.

NOTE: If an attribute is needed for the FSET, BRT combination, define the
following in WORKING-STORAGE:

01  FSET-BRT            PIC X VALUE 'I'.

Using the map fields defined under the "Input Mapping" topic, the move statement
to set this attribute would be coded:

MOVE  FSET-BRT TO INFLDA.

MAPFAIL

There is an important situation that occurs under BMS called "MAPFAIL". This
occurs when a RECEIVE MAP command is issued but no data was returned to the
program. One common way this would happen is when no field is modified on a map.
When no field is modified, the length, flag and data fields are not changed or
updated in any way. You must know if data is returned or entered before you start
your edit checking.

One technique that is used to avoid the MAPFAIL condition is the code
in the mapset a one-byte dummy "autoskip" field with FSET specified so at least
one byte of date is sent to the program when the map is returned.

You can test EIBAID to ensure that data was entered via the ENTER key (or other
planned key) by checking for which AID key was pressed. The clear or PA key will
look like data entry, but no data is returned. See the "Input Mapping" topic for
more information about receiving a map with no data. There is a MAPFAIL
exceptional condition that is handled by the HANDLE CONDITION command in command-
level programming.

In command-level programming, if the HANDLE AID command is specified, it could
override the MAPFAIL handle condition specified. This could mean that the handle
aid would take precedence over the handle condition. The RESP and RESP2 options
may also be used to test for exceptional conditions. Since the use of RESP
implies NOHANDLE, you must be careful when using it with the RECEIVE command,
because NOHANDLE overrides the HANDLE AID command as well as the HANDLE CONDITION
command. The result is that PF key responses are ignored.

MQ : Conditions for a trigger event

This topic can be found at IBM site https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q026930_.htm

The queue manager creates a trigger message when the following conditions are satisfied:

1. 1. A message is put on a queue.
2. 2. The message has a priority greater than or equal to the threshold trigger priority of the queue. This priority is set in the TriggerMsgPriority local queue attribute; if it is set to zero, any message qualifies.
3. 3. The number of messages on the queue with priority greater than or equal to TriggerMsgPriority was previously, depending on TriggerType:
   • Zero (for trigger type MQTT_FIRST)
   • Any number (for trigger type MQTT_EVERY)
   • TriggerDepth minus 1 (for trigger type MQTT_DEPTH)
   Note
   

   1. a. For non-shared local queues, the queue manager counts both committed and uncommitted messages when it assesses whether the conditions for a trigger event exist. Consequently an application might be started when there are no messages for it to retrieve because the messages on the queue have not been committed. In this situation, consider using the wait option with a suitable WaitInterval, so that the application waits for its messages to arrive.
   2. b. For local shared queues, the queue manager counts committed messages only.
4. 4. For triggering of type FIRST or DEPTH, no program has the application queue open for removing messages (that is, the OpenInputCount local queue attribute is zero).
   Note
   

   1. a. For shared queues, special conditions apply when multiple queue managers have trigger monitors running against a queue. In this situation, if one or more queue managers have the queue open for input shared, the trigger criteria on the other queue managers are treated as TriggerType MQTT_FIRST and TriggerMsgPriority zero. When all the queue managers close the queue for input, the trigger conditions revert to those conditions specified in the queue definition.
      An example scenario affected by this condition is multiple queue managers QM1, QM2, and QM3 with a trigger monitor running for an application queue A. A message arrives on A satisfying the conditions for triggering, and a trigger message is generated on the initiation queue. The trigger monitor on QM1 gets the trigger message and triggers an application. The triggered application opens the application queue for shared input. From this point on the trigger conditions for application queue A are evaluated as TriggerType MQTT_FIRST, and TriggerMsgPriority zero on queue managers QM2 and QM3, until QM1 closes the application queue.
   2. b. For shared queues, this condition is applied for each queue manager. That is, a queue manager's OpenInputCountfor a queue must be zero for a trigger message to be generated for the  queue by that queue manager. However, if any queue manager in the queue-sharing group has the queue open using the MQOO_INPUT_EXCLUSIVE option, no trigger message is generated for that queue by any of the queue managers in the queue-sharing group.
      The change in how the trigger conditions are evaluated occurs when the triggered application opens the queue for input. In scenarios where there is only one trigger monitor running, other applications can have the same effect because they similarly open the application queue for input. It does not matter whether the application queue was opened by an application that is started by a trigger monitor, or by some other application; it is the fact that the queue is open for input on another queue manager that causes the change in trigger criteria.
5. 5. On WebSphere MQ for z/OS, if the application queue is one with a Usage attribute of MQUS_NORMAL, get requests for it are not inhibited (that is, the InhibitGet queue attribute is MQQA_GET_ALLOWED). Also, if the triggered application queue is one with a Usage attribute of MQUS_XMITQ, get requests for it are not inhibited.
6. 6. Either:
   • The ProcessName local queue attribute for the queue is not blank, and the process definition object identified by that attribute has been created, or
   • The ProcessName local queue attribute for the queue is all blank, but the queue is a transmission queue. As the process definition is optional, the TriggerData attribute might also contain the name of the channel to be started. In this case, the trigger message contains attributes with the following values:
     • QName: queue name
     • ProcessName: blanks
     • TriggerData: trigger data
     • ApplType: MQAT_UNKNOWN
     • ApplId: blanks
     • EnvData: blanks
     • UserData: blanks
7. 7. An initiation queue has been created, and has been specified in the InitiationQName local queue attribute. Also:
   • Get requests are not inhibited for the initiation queue (that is, the InhibitGet queue attribute is MQQA_GET_ALLOWED).
   • Put requests must not be inhibited for the initiation queue (that is, the InhibitPut queue attribute must be MQQA_PUT_ALLOWED).
   • The Usage attribute of the initiation queue must be MQUS_NORMAL.
   • In environments where dynamic queues are supported, the initiation queue must not be a dynamic queue that has been marked as logically deleted.
8. 8. A trigger monitor currently has the initiation queue open for removing messages (that is, the OpenInputCount local queue attribute is greater than zero).
9. 9. The trigger control (TriggerControl local queue attribute) for the application queue is set to MQTC_ON. To do this, set the trigger attribute when you define your queue, or use the ALTER QLOCAL command.
10. 10. The trigger type (TriggerType local queue attribute) is not MQTT_NONE.
    If all the required conditions are met, and the message that caused the trigger condition is put as part of a unit of work, the trigger message does not become available for retrieval by the trigger monitor application until the unit of work completes, whether the unit of work is committed or, for trigger type MQTT_FIRST or MQTT_DEPTH, backed out.
11. 11. A suitable message is placed on the queue, for a TriggerType of MQTT_FIRST or MQTT_DEPTH, and the queue:
    • Was not previously empty (MQTT_FIRST), or
    • Had TriggerDepth or more messages (MQTT_DEPTH)
    and conditions 2 through 10 (excluding 3) are satisfied, if in the case of MQTT_FIRST a sufficient interval (TriggerIntervalqueue-manager attribute) has elapsed since the last trigger message was written  for this queue.
    This is to allow for a queue server that ends before processing all the messages on the queue. The purpose of the trigger interval is to reduce the number of duplicate trigger messages that are generated.
    Note
    

    If you stop and restart the queue manager, the TriggerInterval timer is reset. There is a small window during which it is possible to produce two trigger messages. The window exists when the trigger attribute of the queue is set to enabled at the same time as a message arrives and the queue was not previously empty (MQTT_FIRST) or had TriggerDepth or more messages (MQTT_DEPTH).
12. 12. The only application serving a queue issues an MQCLOSE call, for a TriggerType of MQTT_FIRST or MQTT_DEPTH, and there is at least:
    • One (MQTT_FIRST), or
    • TriggerDepth (MQTT_DEPTH)
    messages on the queue of sufficient priority (condition 2), and conditions 6 through 10 are also satisfied.
    This is to allow for a queue server that issues an MQGET call, finds the queue empty, and so ends; however, in the interval between the MQGET and the MQCLOSE calls, one or more messages arrive.
    

    Note
    

    1. a. If the program serving the application queue does not retrieve all the messages, this can cause a closed loop. Each time that the program closes the queue, the queue manager creates another trigger message that causes the trigger monitor to start the server program again.
    2. b. If the program serving the application queue backs out its get request (or if the program abends) before it closes the queue, the same happens. However, if the program closes the queue before backing out the get request, and the queue is otherwise empty, no trigger message is created.
    3. c. To prevent such a loop occurring, use the BackoutCount field of MQMD to detect messages that are repeatedly backed out. For more information, see Messages that are backed out.
13. 13. The following conditions are satisfied using MQSET or a command:
    1. • TriggerControl is changed to MQTC_ON, or
       • TriggerControl is already MQTC_ON and the value of either TriggerType, TriggerMsgPriority, or TriggerDepth (if relevant) is changed,
       and there is at least:
       • One (MQTT_FIRST or MQTT_EVERY), or
       • TriggerDepth (MQTT_DEPTH)
       messages on the queue of sufficient priority (condition 2), and conditions 4 through 10 (excluding 8) are also satisfied.
       This is to allow for an application or operator changing the triggering criteria, when the conditions for a trigger to occur are already satisfied.
    2. The InhibitPut queue attribute of an initiation queue changes from MQQA_PUT_INHIBITED to MQQA_PUT_ALLOWED, and there is at least:
       • One (MQTT_FIRST or MQTT_EVERY), or
       • TriggerDepth (MQTT_DEPTH)
       messages of sufficient priority (condition 2) on any of the queues for which this is the initiation queue, and conditions 4 through 10 are also satisfied. (One trigger message is generated for each such queue satisfying the conditions.)
       This is to allow for trigger messages not being generated because of the MQQA_PUT_INHIBITED condition on the initiation queue, but this condition now having been changed.
    3. The InhibitGet queue attribute of an application queue changes from MQQA_GET_INHIBITED to MQQA_GET_ALLOWED, and there is at least:
       • One (MQTT_FIRST or MQTT_EVERY), or
       • TriggerDepth (MQTT_DEPTH)
       messages of sufficient priority (condition 2) on the queue, and conditions 4 through 10, excluding 5, are also satisfied.
       This allows applications to be triggered only when they can retrieve messages from the application queue.
    4. A trigger-monitor application issues an MQOPEN call for input from an initiation queue, and there is at least:
       • One (MQTT_FIRST or MQTT_EVERY), or
       • TriggerDepth (MQTT_DEPTH)
       messages of sufficient priority (condition 2) on any of the application queues for which this is the initiation queue, and conditions 4 through 10 (excluding 8) are also satisfied, and no other application has the initiation queue open for input (one trigger message is generated for each such queue satisfying the conditions).
       This is to allow for messages arriving on queues while the trigger monitor is not running, and for the queue manager restarting and trigger messages (which are nonpersistent) being lost.
14. 14. MSGDLVSQ is set correctly. If you set MSGDLVSQ=FIFO, messages are delivered to the queue in a First In First Out basis. The priority of the message is ignored and the default priority of the queue is assigned to the message. If TriggerMsgPriority is set to a higher value than the default priority of the queue, no messages are triggered. If TriggerMsgPriority is set equal to or lower than the default priority of the queue, triggering occurs for type FIRST, EVERY, and DEPTH. For information about these types, see the description of the TriggerType field under Controlling trigger events.
    If you set MSGDLVSQ=PRIORITY and the message priority is equal to or greater than the TriggerMsgPriority field, messages only count towards a trigger event. In this case, triggering occurs for type FIRST, EVERY, and DEPTH. As an example, if you put 100 messages of lower priority than the TriggerMsgPriority, the effective queue depth for triggering purposes is still zero. If you then put another message on the queue, but this time the priority is greater than or equal to the TriggerMsgPriority, the effective queue depth increases from zero to one and the condition for TriggerType FIRST is satisfied.

Note

1. 1. From step 12 (where trigger messages are generated as a result of some event other than a message arriving on the application queue), the trigger message is not put as part of a unit of work. Also, if the TriggerType is MQTT_EVERY, and if there are one or more messages on the application queue, only one trigger message is generated.
2. 2. If WebSphere MQ segments a message during MQPUT, a trigger event will not be processed until all the segments have been successfully placed on the queue. However, once message segments are on the queue, WebSphere MQ treats them as individual messages for triggering purposes. For example, a single logical message split into three pieces causes only one trigger event to be processed when it is first MQPUT and segmented. However, each of the three segments causes their own trigger events to be processed as they are moved through the WebSphere MQ network.

CICS : How TDQ Automatic transaction initiation works

Below content was taken from IBM manual

For intrapartition queues, CICS® provides the option of automatic transaction initiation (ATI). A basis for ATI is established by the system programmer by specifying a nonzero trigger level for a particular intrapartition destination.

When the number of entries (created by WRITEQ TD commands issued by one or more programs) in the queue reaches the specified trigger level, a transaction specified in the definition of the queue is automatically initiated. Control is passed to a program that processes the data in the queue; the program must issue repetitive READQ TD commands to deplete the queue.

When the queue has been emptied, a new ATI cycle begins. That is, a new task is scheduled for initiation when the specified trigger level is again reached, whether execution of the earlier task has ended. The exact point at which a new ATI cycle begins depends on whether the queue is defined as logically recoverable. If the queue is defined with a recoverability attribute (RECOVSTATUS) of No or Physical, the new ATI cycle begins when the queue is read to QZERO. But if the queue is defined with a recoverability attribute of Logical, the new ATI cycle begins only after the task terminates after having read the queue to QZERO.

If an automatically initiated task does not empty the queue, access to the queue is not inhibited. The task can be normally or abnormally ended before the queue is emptied (that is, before a QZERO condition occurs in response to a READQ TD command). If the contents of the queue are to be sent to a terminal, and the previous task completed normally, the fact that QZERO has not been reached means that trigger processing has not been reset and the same task is reinitiated. A subsequent WRITEQ TD command does not trigger a new task if trigger processing has not been reset.

If the contents of the queue are to be sent to a file, the termination of the task has the same effect as QZERO (that is, trigger processing is reset). The next WRITEQ TD command initiates the trigger transaction (if the trigger level has been reached).

If the trigger level of a queue is zero, no task is automatically initiated.

If a queue is logically recoverable, initiation of the trigger transaction is deferred until the next sync point.

If the trigger level has already been exceeded because the last triggered transaction abended before clearing the queue, or because the transaction was never started because the MXT limit was reached, another task is not scheduled. This is because QZERO has not been raised to reset trigger processing. If the contents of a queue are destined for a file, the termination of the task resets trigger processing and means that the next WRITEQ TD command triggers a new task.

To ensure that an automatically initiated task completes when the queue is empty, the application program should test for a QZERO condition in preference to some other application-dependent factor (such as an anticipated number of records). Only the QZERO condition indicates an emptied queue.

If the contents of a queue are to be sent to another system, the session name is held in EIBTRMID. If a transaction (started with a destination of system) abends, a new transaction is started in the same way as a terminal.

If you use ATI with a transient data trigger mechanism, it might create inter-transaction affinities that adversely affect your ability to perform dynamic transaction routing. See Affinity for more information about transaction affinity.

A trigger transaction is shunted if it suffers from an indoubt failure. Another trigger transaction is not attached until the shunted UOW commits or backs out the changes it has made following resynchronization.

Transactions that are initiated because of a transient data trigger-level transaction do not create previous hop data and are treated as executing at a point of origin. For more information about previous hop data, see Previous hop data characteristics.