Open for output merges all the attributes and then REPLACES the DSCB values with the result of the merge.
On Tue, Aug 2, 2011 at 8:15 PM, CM Poncelet <ponce...@bcs.org.uk> wrote: > ... but open for output, followed by write, works - whereas open for input, > followed by read, doesn't (it fails with an "I/O ERR"): that is a fact, not > an opinion. > > So unless the "I/O ERR" is actually the desired outcome, it is an error. If > it needs to be fixed, then either the program's merged DCB or the dataset on > DASD is in error. If the dataset is thought to be in error, raise a PMR with > IBM. Otherwise it is the program's merged DCB that is in error - which is > what I am saying. As this defines the scope and boundaries of the topic - > i.e. who prevails over what (which is what I mean by 'this overrides that'), > during input and output - there is no need to examine all the entrails > in-between. > > I do not disagree with the details of the points you make about RECFMs > etc., but they are not relevant to the topic under discussion (i.e. that > 'output' works and that 'input' doesn't, and why). > > > > Joel C. Ewing wrote: > > To quote Mark Twain: "It ain’t what you don’t know that gets you into >> trouble. It’s what you know for sure that just ain’t so." >> >> After dealing with computers for 40+ years, I can tell you that some of >> the most important concepts are (1)to know when you don't know the right >> answer, (2)know where to find the right answers, and (3)have enough >> curiosity to look up the right answer, especially if multiple people tell >> you that of which you are certain is wrong. You seemed to have >> unfortunately managed to remember some false things that in your words were >> "not worth remembering". >> >> No one expects one to remember all the fields in all the system control >> blocks, much less values from specific dumps, but you do have to remember >> enough of the basics in order to make sense out of what the manuals tell >> you. The arguments in this thread over the last several weeks have >> basically boiled down to a failure to make a proper distinction between DCB >> attribute values stored in a program DCB versus similar values maintained in >> a DSCB in a DASD VTOC, and the related refusal to understand that when >> talking about overrides to DCB parameters that this is an explicit reference >> to overriding/changing/altering field values in a DCB control block and has >> nothing to do with altering data content of existing datasets or existing >> DSCB values in the VTOC. >> >> One should also remember enough of the basics to understand that it is the >> merged DCB values in the in-memory DCB that control how the access methods >> manipulate data associated with physical data blocks, not the DASD DSCB, >> which only contributes during the OPEN processing. Understanding that the >> physical DASD representation of VB sequential files contains embedded >> record/block control information and variable block sizes, versus FB files >> with no control information but physical block sizes constrained by both >> LRECL and BLKSIZE is also pretty basic stuff - and if you understand that, >> you would never expect any merge of DCB parameters that attempted to read >> existing physical data with the wrong V versus F RECFM protocol to do >> anything useful. That the attempt fails doesn't mean the DCB merge didn't >> work as documented, it means you have managed to construct a dataset, JCL, >> program combination that violates the semantic rules of MVS. It doesn't >> take much experience with MVS macros or JCL parameters to learn that >> syntactic correctness doesn't prevent semantic nonsense. >> >> To almost take pride in not having the time to consult appropriate >> references, and yet at the same time be adamant that you are right and >> others wrong when they have, is not exactly a way to win admiration among >> this group. Working with computers is not like belonging to the Tea Party. >> When it comes down to what works, only facts matter, opinions don't. >> Joel C. Ewing >> >> On 08/02/2011 02:11 PM, CM Poncelet wrote: >> >> Gerhard Postpischil wrote: >>> >>> On 8/1/2011 9:53 PM, CM Poncelet wrote: >>>> >>>> Quite possibly; but it's a contrived case where the 2nd LRECL is >>>>> a fixed length multiple of the first (so there is one BDW and >>>>> one RDW, and the records follow each other consecutively in the >>>>> buffer). >>>>> >>>> >>>> >>>> >>>> His example used RECFM=FB, so there are no BDWs and no RDWs (if there >>>> were, then the first four bytes of the second record would be the RDW, >>>> not data). >>>> >>> >>> >>> Yes ... and I am writing from memory, probably confusing >>> controlintervals (which always have a CIDF and at least one RDF) with >>> blocks. I would have to dump a non-VSAM dataset to verify this. But in >>> any case the BDW and RDW would not be loaded into the buffer. So, if >>> SORT is doing GLs to read the records from the buffer, it will have no >>> problem reading 2*80 instead of 80 bytes at a time - because the BLKSIZE >>> is a multiple of 160, the buffer size is the same as the BLKSIZE and the >>> records are fixed length. >>> >>> >>>> >>>> to avoid I/O errors. Hence, the assertion that DCB attribute >>>>> override priority is 'program -> JCL -> DASD' is true if the DCB >>>>> is opened for output; but it is false (or at least 'it does not >>>>> work', for the benefit of those who can stomach only a >>>>> politically correct version of the truth) if it is opened for >>>>> input, because it then hits I/O errors. >>>>> >>>> >>>> >>>> >>>> DCB is short for Data Control Block. These exist only in memory, and >>>> are specific to the zOS operating systems (and earlier MVS and >>>> OS/360). I can read DASD written on MVS on VSE, and vice versa. VSE >>>> has no DCBs, but it manages to read data anyway. >>>> >>> >>> >>> ... and DSCB is short for Data Set Control Block, SIOT is short for Step >>> I/O Table, JFCB is short for Job File Control Block, etc. - but thanks >>> for reminding me. >>> >>> >>>> >>>> On DASD, each block of data is preceded by a count field containing a >>>> logical (alternate track) or physical address (CCHHR), a key length, >>>> and a data length. There is no RECFM, no LRECL, and the physical block >>>> may have a length other than that specified by BLKSIZE. Regardless of >>>> how often you repeat yourself, there is no DCB on DASD. >>>> >>>> Furthermore, your discussion of I/O seems to indicate that either you >>>> do not understand English, or that you are unaware of the differences >>>> between BSAM and QSAM. I would suggest that you read up on system >>>> control blocks, notable the IOB and ICB, look at some in a dump, and >>>> get a better understanding of how I/O functions. Requisite manuals are >>>> available online. While "Using Data Sets" is a bit daunting, it >>>> contains most of the information. >>>> >>> >>> >>> I have no time for that. If something is true it can remember itself; if >>> it is false it is not worth remembering. Hence I remember what I am >>> dealing with and forget it afterwards. Do you expect me to *remember* >>> system control blocks? When I *need* to remember them, I dump them and >>> look at them - or I look at the "Data Areas" manuals or at the DSECTs - >>> and then I forget about them again, unless I am still using them that >>> is. I have been reading system dumps for more than 25 years, but don't >>> expect me to *remember* them afterwards. This topic is about the order >>> of priority of DCB attributes when opening a dataset for input v. >>> output, and not about system control blocks. If it were about the >>> latter, I would check and re-remember them beforehand: but as it isn't, >>> I don't bother (I have other things to get on with). >>> >>> 'DCB' is shorter than the 'RECFM=,LRECL=,BLKSIZE=' I am actually >>> referring to when I say 'DCB'; so I say 'DCB' for short. >>> >>> >>>> >>>> >>>> Gerhard Postpischil >>>> Bradford, VT >>>> >>> >>> >> >> >> > ------------------------------**------------------------------**---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at > http://bama.ua.edu/archives/**ibm-main.html<http://bama.ua.edu/archives/ibm-main.html> > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
