Ways to flush the Pipeline?

Document ID : KB000093257
Last Modified Date : 04/05/2018
Show Technical Document Details
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
z/os, CA Datacom/DB
APAR #: TB30815

  Title: * WHAT IS THE "PIPELINE" AND HOW TO FLUSH IT?                       
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             
5.  When an update becomes too old based on the LOGPEND value in the       
    MUF start-up option LOGPEND.                                           
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: