Ways to flush the Pipeline?
Article ID: 93257
Updated On:
Products
Datacom
DATACOM - AD
CIS
COMMON SERVICES FOR Z/OS
90S SERVICES
DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
COMMON PRODUCT SERVICES COMPONENT
Common Services
CA ECOMETER SERVER COMPONENT FOC
Easytrieve Report Generator for Common Services
INFOCAI MAINTENANCE
IPC
UNICENTER JCLCHECK COMMON COMPONENT
Mainframe VM Product Manager
CHORUS SOFTWARE MANAGER
CA ON DEMAND PORTAL
CA Service Desk Manager - Unified Self Service
PAM CLIENT FOR LINUX ON MAINFRAME
MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
GRAPHICAL MANAGEMENT INTERFACE
WEB ADMINISTRATOR FOR TOP SECRET
Xpertware
Issue/Introduction
1) Unless my memory is failing me, I could have sworn that once upon a time. I wrote an informational solution that listed several ways that a client could flush the pipeline. Unfortunately, so far I have not been able to find it. However, I have found numerous search hits that had either broken or expired links to other informational articles that would have still been applicable. I hope they are not gone for good.
2) If a client issued a LOGPEND=0 from the console and then issued LOGPEND=1000 back to it's original value, would the LOGPEND=0 also flush the pipeline?
Client trying to remember how to flush the pipeline
2) If a client issued a LOGPEND=0 from the console and then issued LOGPEND=1000 back to it's original value, would the LOGPEND=0 also flush the pipeline?
Client trying to remember how to flush the pipeline
Environment
z/os, CA Datacom/DB
Resolution
APAR #: TB30815
Title: * WHAT IS THE "PIPELINE" AND HOW TO FLUSH IT?
BACKGROUND INFORMATION OF IMMEDIATE MODE PROCESSING
---------------------------------------------------
Prior to r7.4 of Datacom/DB each maintenance command followed a rigid
sequence of physical writes to the LXX log, index area, and the data area.
In general most maintenance commands (ADDIT, UPDAT, and DELET) required
a minimum of three (3) writes of blocks from a buffer pool to DASD.
This method of processing is referred to as the IMMEDIATE MODE. For a
single user request from a given application program this may seem
to be fast and addresses the immediate need. However, in a multiple user
environment, the process of single threading writes to DASD actually slows
down the overall throughput.
OBJECTIVES OF PIPELINE MODE PROCESSING
--------------------------------------
Pipelining reduces writes to the LXX log, index and data areas for
maintenance commands and is functionally transparent to the application
programs. It's purpose is to reduce over-all Datacom/DB I/O to DASD by
holding or pending individual record writes until such time as multiple
blocks can be written with a single or fewer physical I/Os.
WHEN ARE LOG BLOCKS WRITTEN:
----------------------------
1. When associated data or index blocks are written.
(LOG Records are written prior to data and index entries)
2. When the LOG BLOCK fills.
3. At transaction boundaries, DEQUE, LOGCP, LOGIT, LOGTB, COMIT,
forced checkpoint, etc...
In general application terms a log block will be written as a result
of the exit of a CICS task, checkpoint being issued by a batch job, etc.
WHEN ARE DATA and INDEX BLOCK NORMALLY WRITTEN?
-----------------------------------------------
1. When updated buffers are required for reads.
2. When an AREA closes all pending writes are completed.
3. When an INDEX BLOCK splits.
4. When a SPILL fo the LXX log occurs, all pending writes are
completed.
5. When an update becomes too old based on the LOGPEND value in the
MUF start-up option LOGPEND.
HOW CAN THE BLOCKS IN THE PIPELINE BE MANUALLY FLUSHED TO DASD?
---------------------------------------------------------------
This can be accomplished by executing DBUTLTY with one of the following:
1. a LOCK OPTION=MOVER,DBID=nnn,AREA=aaa followed by an UNLOCK,
2. an ACCESS STATUS=xxxxxx,DBID=nnn, or
3. a COMM OPTION=STATS
4. a COMM OPTION=CLOSE,DBID=ALL
5. a COMM QUIESCE REQ or TXN (console only command)
Note: Although any one of these will flush out the write pended buffers at
that point, another request could pull in another record from the
data area and update it.
Title: * WHAT IS THE "PIPELINE" AND HOW TO FLUSH IT?
BACKGROUND INFORMATION OF IMMEDIATE MODE PROCESSING
---------------------------------------------------
Prior to r7.4 of Datacom/DB each maintenance command followed a rigid
sequence of physical writes to the LXX log, index area, and the data area.
In general most maintenance commands (ADDIT, UPDAT, and DELET) required
a minimum of three (3) writes of blocks from a buffer pool to DASD.
This method of processing is referred to as the IMMEDIATE MODE. For a
single user request from a given application program this may seem
to be fast and addresses the immediate need. However, in a multiple user
environment, the process of single threading writes to DASD actually slows
down the overall throughput.
OBJECTIVES OF PIPELINE MODE PROCESSING
--------------------------------------
Pipelining reduces writes to the LXX log, index and data areas for
maintenance commands and is functionally transparent to the application
programs. It's purpose is to reduce over-all Datacom/DB I/O to DASD by
holding or pending individual record writes until such time as multiple
blocks can be written with a single or fewer physical I/Os.
WHEN ARE LOG BLOCKS WRITTEN:
----------------------------
1. When associated data or index blocks are written.
(LOG Records are written prior to data and index entries)
2. When the LOG BLOCK fills.
3. At transaction boundaries, DEQUE, LOGCP, LOGIT, LOGTB, COMIT,
forced checkpoint, etc...
In general application terms a log block will be written as a result
of the exit of a CICS task, checkpoint being issued by a batch job, etc.
WHEN ARE DATA and INDEX BLOCK NORMALLY WRITTEN?
-----------------------------------------------
1. When updated buffers are required for reads.
2. When an AREA closes all pending writes are completed.
3. When an INDEX BLOCK splits.
4. When a SPILL fo the LXX log occurs, all pending writes are
completed.
5. When an update becomes too old based on the LOGPEND value in the
MUF start-up option LOGPEND.
HOW CAN THE BLOCKS IN THE PIPELINE BE MANUALLY FLUSHED TO DASD?
---------------------------------------------------------------
This can be accomplished by executing DBUTLTY with one of the following:
1. a LOCK OPTION=MOVER,DBID=nnn,AREA=aaa followed by an UNLOCK,
2. an ACCESS STATUS=xxxxxx,DBID=nnn, or
3. a COMM OPTION=STATS
4. a COMM OPTION=CLOSE,DBID=ALL
5. a COMM QUIESCE REQ or TXN (console only command)
Note: Although any one of these will flush out the write pended buffers at
that point, another request could pull in another record from the
data area and update it.
Additional Information
See CA Datacom/DB for more information:
https://docops.ca.com/ca-datacom/15-1/en
https://docops.ca.com/ca-datacom/15-1/en
Feedback
Yes
No
Powered by
