DatacomDATACOM - ADCISCOMMON SERVICES FOR Z/OS90S SERVICESDATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OSCOMMON PRODUCT SERVICES COMPONENTCommon ServicesCA ECOMETER SERVER COMPONENT FOCEasytrieve Report Generator for Common ServicesINFOCAI MAINTENANCEIPCUNICENTER JCLCHECK COMMON COMPONENTMainframe VM Product ManagerCHORUS SOFTWARE MANAGERCA ON DEMAND PORTALCA Service Desk Manager - Unified Self ServicePAM CLIENT FOR LINUX ON MAINFRAMEMAINFRAME CONNECTOR FOR LINUX ON MAINFRAMEGRAPHICAL MANAGEMENT INTERFACEWEB ADMINISTRATOR FOR TOP SECRETXpertware
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
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.