A correct quote. I know about that bit. I will rephrase my incorrect and dogmatic statement: "Keyed searches cannot be executed within a Locate Record Domain." I know of no Locate Record or Locate Record Extended command operation that involves key field comparisons. They all involve either reading or writing whole DASD records (count, key, and data), groups of whole records, whole tracks, or groups of whole tracks (and not always contiguous). When a channel program segment begins with a LR or a LRE (aka LRX) command, then that channel program begins operating in what is called a Locate Record Domain. When the end of that domain is reached, the channel program is no longer operating within a Locate Record domain. This is significant because many other sections of the IBM Control Unit Reference books describe the details of other types of operations (reads, writes, multi-track operations, etc.) in terms of whether the channel program is within a Locate Record Domain or not. It is especially significant when multi-track operations are occurring. Over the years I began referring to operating "within a LRD" (IBM's phrase) as "being in ECKD mode" (my sloppy phrase), and I didn't inform the rest of the world of my private PTF on the terminology. Special search key mode is not the same as being within a Locate Record Domain. Special search key mode involves not having to refetch the key value from central storage for each comparison operation with each new key field discovered on the track, whether those keys are in cache storage already or not. The use of the special search key mode bit requires that the immediate driver of the I/O request be authorized. Thus DB2 can use this bit, but an unauthorized QSAM application cannot when doing its QSAM macros. If the file is ever accessed directly by unauthorized applications, then the key value in central storage will be refetched for each new key comparison taking place in the control unit, in which case it should be allocated on a cylinder boundary for a small performance improvement But if it is only ever accessed by DB2 or any other authorized program, then it doesn't need to begin on a cylinder boundary for purposes of the special search key mode consideration. My term "directly" means that the applications does its own OPEN, GET, READ, EXCP, etc., rather than invoke another component, such as DB2, to do the I/O operations, which I would probably choose to characterize as the application's doing its I/O indirectly by way of using the authorized DB2 product. Doing an I/O "directly" or "indirectly" through another address space, access method, driver, etc., is more of my own private sloppy terminology. Bill Fairchild
----- Original Message ----- From: "Shmuel Metz (Seymour J.)" <[email protected]> To: [email protected] Sent: Sunday, September 7, 2014 12:07:59 AM Subject: Re: Allocation in CYLinder increments (UNCLASSIFIED) In <[email protected]>, on 09/05/2014 at 06:02 PM, DASDBILL2 <[email protected]> said: >True for some value of "basically", but not true always. Keyed >searches cannot be executed in ECKD mode, >From IBM Enterprise Storage ServerA IBM System/390 Command Reference 2105 Models E10, E20, F10, and F20. SC26-7298-01, p. 28: 10 Special Search Key Mode Byte 7, bits 0, 1, when set to '10', indicate that Search Key operations may be carried out in Special Search Key mode. Restrictions on the use of this mode are given below. By setting special search key mode, the software is responsible for ensuring: 1. That any search CCW that is encountered be in a search TIC loop 2. That the search TIC loop consists of: * Optionally a single Read Count command (may be multi-track). * A single Search Key command (may be multi-track, Search Key Equal, Search Key High, or Search Key Equal or High). * TIC * Nothing else 3. Data length of search key CCW must equal key length for all records to be searched. Warning: Failure to follow these rules when in Special Search Key mode may yield unpredictable and inconsistent results. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see <http://patriot.net/~shmuel/resume/brief.html> We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
