Re: BLOCK CONTAINS
On 23 May 2009 12:32:09 -0700, paulgboul...@aim.com (Paul Gilmartin) wrote: You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Would you be willing to go so far as to side with me and say that we fundamentally disagree with Mr. Thompson? The CoBOL should be more independent than JCL. There is no reason that CoBOL should care about blocksize, that isn't its function. Whatever we code in the CONFIGURATION SECTION along with FD clauses such as BLOCKSIZE RECORDING MODE should be overridable in the JCL or REXX. -- 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
Re: BLOCK CONTAINS
On 25 May 2009 18:23:38 -0700, joa...@swbell.net (John McKown) wrote: I agree, except for truly direct access data sets. What I have fought with here is the mindset of I must allocate in CYLINDERS in order to be efficient. I want them to allocate in RECORDS (or millions of records). But, oh, no! that is not good because I understand what a cylinder is, but I don't know how much space 1 million records requires. Then when I ask them how many records they'll get in that CYLinder allocation, I get the deer in the headlights look. And of course, people cut and paste their SORTWK* files often without thinking. After all, they are temporary anyway, make them all very, very large and we won't be called in. -- 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
Re: BLOCK CONTAINS
And of course, people cut and paste their SORTWK* files often without thinking. We made it even more turnkey than that. We cleaned up all the Production JCL, and made them dynamic. After all, they are temporary anyway, make them all very, very large and we won't be called in. With SYNCSORT, at least, there is a facility to monitor memory usage and determine whether a disk, or a memory, sort is warranted. At one shop, we had the PIPESORT add-on. That was the kitty's butt, to coin a phrase. - Too busy driving to stop for gas! -- 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
Re: BLOCK CONTAINS
On 25 May 2009 19:16:25 -0700, in bit.listserv.ibm-main you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John McKown Sent: Monday, May 25, 2009 6:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS On Sat, 23 May 2009, Ted MacNEIL wrote: You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Not at all. There are at least two device types -- tape and disk. And, I can convert to either without re-compiling. That is device independent. - Too busy driving to stop for gas! I agree, except for truly direct access data sets. What I have fought with here is the mindset of I must allocate in CYLINDERS in order to be efficient. I want them to allocate in RECORDS (or millions of records). But, oh, no! that is not good because I understand what a cylinder is, but I don't know how much space 1 million records requires. Then when I ask them how many records they'll get in that CYLinder allocation, I get the deer in the headlights look. OK, but how is this desire not satisfied via AVGREC allocations? Oh, it is and you'll claim your applications folks can't handle the concept. Supply and teach DATACASS with no SPACE at all in the JCL, tell them it's magic :) Route most if not all allocations to extended format multivolume in the ACS routines. Use a Big and a not Big set of Storage groups. Migrate aggressively and route recalls to a pool with less aggressive free space defined. If you don't specify round allocation is converted to tracks, not cylinders for non-VSAM. This used to have performance implications before define extent. For VSAM you can get some ugly CA sizes if you specify in records or kilobytes. And it would be valuable for IBM to make ALL FBA type data areas (PDSE's, etc.) readable at NIP and start doing what is necessary to move into the FBA world. VSE can handle FBA. VM can handle FBA. I've seen hardly any x37 abends in more than a decade. In today's world, if all JCL were allocated in records (not blocks), (and use ROUND if really necesary), then __most__ people wouldn't care one bit about the number of bytes per track or tracks per cylinder or cylinders per volume. They'd care about something more reasonable like number of records or even gigabytes. And I could have my beloved FBA architecture mapped onto standard SAN resident storage. Oh, except for some things like PDSes. PDSes are the legacy of the devil, IMO. But the cost to eliminate them would likely be horrendous for things like IPL and NIP. -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- 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 -- 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 -- 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
Re: BLOCK CONTAINS
On Mon, 25 May 2009 19:13:43 -0700, Gibney, Dave wrote: OK, but how is this desire not satisfied via AVGREC allocations? Oh, it is and you'll claim your applications folks can't handle the concept. AVGREC is: o Woefully misleading; it seems to abbreviate AVeraGe RECord size, with which it appears to have nothing to do (or is there another etymology I'm missing totally?) o A desperate measure to deal with an inadequate sized bit field in some control block; a bizarre base-1024 floating point. Why can't I code: SPACE=(133,2048) and have the converter do the algebra rather than be forced to do the computation myself and code: SPACE=(133,2),AVGREC=K Isn't that what computers are supposed to be for? And I could have my beloved FBA architecture mapped onto standard SAN resident storage. Oh, except for some things like PDSes. PDSes are the legacy of the devil, IMO. But the cost to eliminate them would likely be horrendous for things like IPL and NIP. Nowadays, many of the despised squatty boxes can boot from the network. Why should our beloved z/OS be so far behind? Yah, it _is_ rocket science, but this _is_ the 21st century. -- gil -- 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
Re: BLOCK CONTAINS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2009 3:23 PM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS On Mon, 25 May 2009 19:13:43 -0700, Gibney, Dave wrote: OK, but how is this desire not satisfied via AVGREC allocations? Oh, it is and you'll claim your applications folks can't handle the concept. AVGREC is: o Woefully misleading; it seems to abbreviate AVeraGe RECord size, with which it appears to have nothing to do (or is there another etymology I'm missing totally?) o A desperate measure to deal with an inadequate sized bit field in some control block; a bizarre base-1024 floating point. Why can't I code: SPACE=(133,2048) and have the converter do the algebra rather than be forced to do the computation myself and code: SPACE=(133,2),AVGREC=K Isn't that what computers are supposed to be for? Misleading or kludgy, it does work. In my DATACLASs, I use 1 for the size, leading me to easy xK and xM allocations. Then, make them bigger anyway and be sure to use RLSE. Now, If I was to complain, I'd wonder why RLSE doesn't play well with Multi-Volume striping? And I could have my beloved FBA architecture mapped onto standard SAN resident storage. Oh, except for some things like PDSes. PDSes are the legacy of the devil, IMO. But the cost to eliminate them would likely be horrendous for things like IPL and NIP. Nowadays, many of the despised squatty boxes can boot from the network. Why should our beloved z/OS be so far behind? Yah, it _is_ rocket science, but this _is_ the 21st century. -- gil -- 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 -- 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
Re: BLOCK CONTAINS
On Sat, 23 May 2009, Ted MacNEIL wrote: You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Not at all. There are at least two device types -- tape and disk. And, I can convert to either without re-compiling. That is device independent. - Too busy driving to stop for gas! I agree, except for truly direct access data sets. What I have fought with here is the mindset of I must allocate in CYLINDERS in order to be efficient. I want them to allocate in RECORDS (or millions of records). But, oh, no! that is not good because I understand what a cylinder is, but I don't know how much space 1 million records requires. Then when I ask them how many records they'll get in that CYLinder allocation, I get the deer in the headlights look. In today's world, if all JCL were allocated in records (not blocks), (and use ROUND if really necesary), then __most__ people wouldn't care one bit about the number of bytes per track or tracks per cylinder or cylinders per volume. They'd care about something more reasonable like number of records or even gigabytes. And I could have my beloved FBA architecture mapped onto standard SAN resident storage. Oh, except for some things like PDSes. PDSes are the legacy of the devil, IMO. But the cost to eliminate them would likely be horrendous for things like IPL and NIP. -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- 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
Re: BLOCK CONTAINS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John McKown Sent: Monday, May 25, 2009 6:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS On Sat, 23 May 2009, Ted MacNEIL wrote: You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Not at all. There are at least two device types -- tape and disk. And, I can convert to either without re-compiling. That is device independent. - Too busy driving to stop for gas! I agree, except for truly direct access data sets. What I have fought with here is the mindset of I must allocate in CYLINDERS in order to be efficient. I want them to allocate in RECORDS (or millions of records). But, oh, no! that is not good because I understand what a cylinder is, but I don't know how much space 1 million records requires. Then when I ask them how many records they'll get in that CYLinder allocation, I get the deer in the headlights look. OK, but how is this desire not satisfied via AVGREC allocations? Oh, it is and you'll claim your applications folks can't handle the concept. Supply and teach DATACASS with no SPACE at all in the JCL, tell them it's magic :) Route most if not all allocations to extended format multivolume in the ACS routines. Use a Big and a not Big set of Storage groups. Migrate aggressively and route recalls to a pool with less aggressive free space defined. I've seen hardly any x37 abends in more than a decade. In today's world, if all JCL were allocated in records (not blocks), (and use ROUND if really necesary), then __most__ people wouldn't care one bit about the number of bytes per track or tracks per cylinder or cylinders per volume. They'd care about something more reasonable like number of records or even gigabytes. And I could have my beloved FBA architecture mapped onto standard SAN resident storage. Oh, except for some things like PDSes. PDSes are the legacy of the devil, IMO. But the cost to eliminate them would likely be horrendous for things like IPL and NIP. -- Trying to write with a pencil that is dull is pointless. Maranatha! John McKown -- 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 -- 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
Re: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
--- On Sat, 5/23/09, Eric Bielefeld eric-ibmm...@wi.rr.com wrote: From: Eric Bielefeld eric-ibmm...@wi.rr.com Subject: Re: Submitting a Marketing REQUEST (was: BLOCK CONTAINS To: IBM-MAIN@bama.ua.edu Date: Saturday, May 23, 2009, 9:26 AM Ed, And yet, IBM is hiring 1,300 people in Dubuque Iowa. I'm sure they will hire some who got laid off in other areas of the country, but it is a good sign. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 Eric: That only is the surface story. What happened to the people that their jobs were outsourced to IBM? (both to INDIA and the US)? I am *GUESSING* and it is a guess. That some companies are not stupid enough to send their data overseas as the people in other countries will steal their sensitive data. I am well know of one bank who did so. I know I certainly would never trust a bank that did that would you? China is probably the worst option as the government will have inside knowledge of all transactions. The people are probably somewhat trustworthy but when you mix in politics it is a whole different story, IMO. The scandal(s) in INDIA are (from what I was told by a person who does business outsourcing) just starting to begin to surface. I am not suggesting U.S. citizens are any better (look at MADOFF) but at least our laws (loose as they are) can prosecute the crooks. Other countries are rife with corruption (much like our political system). In a letter the other day I wrote that we are becoming a 3rd world country because of our crooked politicians. Lets get back semi on topic. With any news story puff like the item you described never look at it like it is the whole story. The backgrounds speaks reams and you *MUST* know the back ground. -- 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
Re: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
Ed, And yet, IBM is hiring 1,300 people in Dubuque Iowa. I'm sure they will hire some who got laid off in other areas of the country, but it is a good sign. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Ed Gould ps2...@yahoo.com Excellent question. Although you might end up getting told to call the 1-800 IBM number. Chuckle they wouldn't know it if it cut their head in half. IBM really screwed the customer over when they got rid of the people x many years ago. I am happy to be far far far away from that IBM mess. If people ask me if IBM is a good investment, I tell them to run run run away as fast as you can as sometime soon it is going to belly up. If they have any business left it will probably be in INDIA. If they are doing short term its a 50-50 gamble as far as I can see. Ed -- 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
Re: BLOCK CONTAINS
Paul Gilmartin wrote: On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote: Welcome to the MVS world. In the MVS world, we are not device dependant, nor are we data definition locked/blocked. We generally don't have to recompile our programs, change the DTF contents (DCB in MVS), etc. just because the file attributes change (xSAM to VSAM is the exception). Huh??? If we are not device dependant, why is there such intense trepidation and resistance to the mere suggestion of a device with a novel geometry such as more bytes per track or more tracks per cylinder? It doesn't appear that you and I have been living in the same MVS world. -- gil It would be a rarity for application programs themselves to be device dependent in the z/OS world, but once you start dealing with instances of data used by those programs on DASD the dependency creeps back in in both obvious and subtle ways, in both the physical representation of the data and in the JCL which references or allocates that data set. I think it would be fair to say that a systems programmer who has to design and implement a migration strategy and deal with effects that are more often than not performance and resource usage issues would see many more issues with DASD architecture migration than an applications programmer. Just changing the number of cylinders per device, complicates DASD migration strategies and may require JCL adjustments to optimize allocations when the typical free space per volume or size of typical free space extents changes. If you change the capacity of a track or cylinder, then all JCL, IDCAMS, or TSO dataset space allocations in those units are obviously suspect. A change in track size raises issues in both block size and number of blocks per track that in general defy a completely automated solution and require some analysis to resolve. Even with an ordinary sequential dataset, there is no guarantee that all access is via standard (QSAM) access methods with no use of pointers dependent in some way on track geometry. And even if all access is QSAM, do you leave the block size alone and risk performance issues, or re-optimize block size and risk having to adjust JCL REGION sizes to allow for larger buffers? Data set types that are known to be direct access, and which may contain internal relative track pointers cannot be copied without some internal modification. Changes in track size or tracks per cylinder have especially subtle side effects when dealing with VSAM KSDS files. VSAM Control Area (CA) size is tied to the physical cylinder architecture, optimum index CI-size is tied to the number of Data CIs per CA, which in turn is tied to both track size and cylinder size. Failure to adjust a sub-optimum Index CI size when copying a KSDS to a new architecture could seriously degrade CA space utilization and increase total dataset space requirements, but automatically adjusting Index CI size for online files could have adverse side effects on manually defined LSR buffer pools in the online regions that access these KSDS files. So again, any attempt to automatically migrate such files to a new architecture carries risks. Having been through several architecture conversions in the past -- 3330 3350 3380(various models) 3390(various models) -- there is no doubt that (1)it can be done (but any old code with datasets that are tied to one architecture with no source or no support is a definite problem!), (2) a migration that changes the track/cylinder architecture takes more person hours to do correctly, (3) and having two different architectures in house during a transition is more complicated to manage. All things being equal, I would much rather not use my scarce time dealing with DASD architecture migration. Joel C Ewing -- 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
Re: BLOCK CONTAINS
All things being equal, I would much rather not use my scarce time dealing with DASD architecture migration. Having gone from 3330 -- 3350 -- 3380 -- 3390 (emulation mode) -- 3390 (native), I agree 100%! IBM promised, years ago, to not change the geometry again. Better the devil you know; I have other things to waste my time on. - Too busy driving to stop for gas! -- 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
Re: BLOCK CONTAINS
On Sat, 23 May 2009 19:12:19 +, Ted MacNEIL wrote: All things being equal, I would much rather not use my scarce time dealing with DASD architecture migration. Having gone from 3330 -- 3350 -- 3380 -- 3390 (emulation mode) -- 3390 (native), I agree 100%! IBM promised, years ago, to not change the geometry again. Better the devil you know; I have other things to waste my time on. - Too busy driving to stop for gas! You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Would you be willing to go so far as to side with me and say that we fundamentally disagree with Mr. Thompson? -- gil -- 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
Re: BLOCK CONTAINS
You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Not at all. There are at least two device types -- tape and disk. And, I can convert to either without re-compiling. That is device independent. - Too busy driving to stop for gas! -- 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
Re: BLOCK CONTAINS
Ted MacNEIL pisze: You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Not at all. There are at least two device types -- tape and disk. And, I can convert to either without re-compiling. That is device independent. IMHO more definitions of the independence can be formulated. For me it is track size in SMS. As long you use track size as physical paramter of the disk you are device dependent. When you think about it as just some chunk of disk space (maybe even FBA) then you are independent. BTW: When we compare MVS to other systems in this context it is good to know what they understand as device dependency. IMHO no need for recompilation is not independency. My $0.02 -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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
Re: BLOCK CONTAINS
At 20:24 -0300 on 05/18/2009, Clark Morris wrote about Re: BLOCK CONTAINS: On 18 May 2009 13:35:40 -0700, in bit.listserv.ibm-main you wrote: Ah! NOBLOCK had F/80/80 whereas BLOCK1 had FB/80/80. BLOCK0 still had FB/80/27920. But it is still interesting, to me, that BLOCK CONTAINS 1 and no BLOCK CONTAINS at all can still create an optimally block dataset with little effort in the JCL and no program changes. This is weird because the normal merge is DCB overrides JCL and JCL overrides data set label (DSCB or tape label). The code to distinguish between BLKSIZE=0 in JCL and BLKSIZE not supplied must be interesting to say the least. If I get energetic, I'll check the COBOL Programmers Guide. Talk about ways to confuse the applications programmers and subtle ways to screw up. JCL BLKSIZE=0 gives SDB, no BLKSIZE gives 0. By the time the merge happens the FD has generates a DCB with F/80/80 for no Block Contains, FB/80/80 for Block Contains 1, and FB/80/0 for Block Contains 0 (thus only the last has a Blksize that can be filled in by the Merge). -- 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
Re: BLOCK CONTAINS
At 16:07 -0500 on 05/18/2009, Paul Gilmartin wrote about Re: BLOCK CONTAINS: On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote: On Monday 18 May 2009 18:04, Paul Gilmartin wrote: What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! What happens if the programmer pre-allocates the data set? It's still a stupid necessity, but it might help in dealing with situations where recompilation is impractical. Well, pre-allocation is not very compatible with HSM, GDG, and a few other I believe I understand the concern with GDG. (Actually, my understanding of GDG is so rudimentary I'm not qualified to doubt the concern.) GDG will get the blocksize from the DCB= clause, a DCB=DSN reference, or a DSCB with the DSNAME (without the .GVyy suffix) on the volume where the Catalog lives (or has this last last source become no longer relevant). Thus this information is always there for the predefined file. -- 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
Re: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
--- On Wed, 5/20/09, Martin Packer martin_pac...@uk.ibm.com wrote: --SNIP--- Do you suppose it has to be YOUR Marketing Rep? Or just a friendly IBMer in the field? Cheers, Martin (still striving to be a friendly IBMer after all these years) :-) Excellent question. Although you might end up getting told to call the 1-800 IBM number. Chuckle they wouldn't know it if it cut their head in half. IBM really screwed the customer over when they got rid of the people x many years ago. I am happy to be far far far away from that IBM mess. If people ask me if IBM is a good investment, I tell them to run run run away as fast as you can as sometime soon it is going to belly up. If they have any business left it will probably be in INDIA. If they are doing short term its a 50-50 gamble as far as I can see. Ed -- 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
Re: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
The IBM requirements database has a field for a SHARE requirement# and the SHARE Requirements database has a field for an IBM #. We usually submit a marketing requirement directly to IBM but also go through the slightly longer process to submit a SHARE requirement. These two requirements may even diverge slightly after discussion of the SHARE requirement. Take the time to have both tied together. If you really want IT take the time to go all in Lock, Stock and Two Smoking Barrels! Your companies voice may matter to IBM but may have a greater impact if you get others to also confirm they share the concern. Group discussion may help you to refine your requirement to be clearer and more likely to be moved forward. Talking about it on IBM-MAIN never hurts either but do take the time to complete the formal processes. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Klein Sent: Tuesday, May 19, 2009 10:35 PM To: IBM-MAIN@bama.ua.edu Subject: Submitting a Marketing REQUEST (was: BLOCK CONTAINS Frank Swarbrick fswarbr...@gmail.com wrote in message news:listserv%200905191643164240.0...@bama.ua.edu... snip By the way, any pointers on how to submit a marketing requirement? VSE actually has a submit a requirement web page (https://www- 03.ibm.com/servers/eserver/zseries/zvse/contact/requirement.html). Does z/OS have anything similar? Thanks! Frank As the saying goes, I have good news and I have bad news G The good news is The procedure for submitting a Marketing REQUEST is easy. Just contact your IBM Marketing Representative and explain what you want THEM to submit. This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
Re: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
Do you suppose it has to be YOUR Marketing Rep? Or just a friendly IBMer in the field? Cheers, Martin (still striving to be a friendly IBMer after all these years) :-) Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter ID: MartinPacker They're figuring out that collaboration isn't a productivity hit, it makes them smarter. Sam Palmisano on BlogCentral, 26 November 2008 From: Bill Klein wmkl...@ix.netcom.com To: IBM-MAIN@bama.ua.edu Date: 20/05/2009 03:36 Subject: Submitting a Marketing REQUEST (was: BLOCK CONTAINS Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Frank Swarbrick fswarbr...@gmail.com wrote in message news:listserv%200905191643164240.0...@bama.ua.edu... snip By the way, any pointers on how to submit a marketing requirement? VSE actually has a submit a requirement web page (https://www- 03.ibm.com/servers/eserver/zseries/zvse/contact/requirement.html). Does z/OS have anything similar? Thanks! Frank As the saying goes, I have good news and I have bad news G The good news is The procedure for submitting a Marketing REQUEST is easy. Just contact your IBM Marketing Representative and explain what you want THEM to submit. The bad news is, Try finding out who your IBM marketing rep is. In many cases this is QUITE difficult - it is even hard for many customers to figure out who (how to contact) their local IBM branch. Once you find your local branch and/or your IBM marketing rep, then getting a REQUEST submitted should be a piece of cake. If your IBM Marketing Rep does not know how to submit a REQUEST, then come back to us here (and someone should be able to get your marketing rep in contact with someone who can help them) -- 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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
Re: BLOCK CONTAINS
On 18 May 2009 12:41:15 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: I don't think it's a lie. Historically, ZERO has always had a special meaning. In COBOL's case, it just means that the programme is not going to determine the blocksize, but leaves a place-holder for it when it's decided elsewhere. Other computers have compilers that say if the programmer isn't going to determine the blocksize - the programmer leaves out that clause. Historically. -- 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
Re: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
We have had a couple of rep changes over the past few years. When having trouble finding out who the new one is, I call 1 800 IBM SERVE. I have always gotten a phone call or email by the next day. Linda - Original Message - From: Bill Klein wmkl...@ix.netcom.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, May 19, 2009 7:35:16 PM GMT -08:00 US/Canada Pacific Subject: Submitting a Marketing REQUEST (was: BLOCK CONTAINS Frank Swarbrick fswarbr...@gmail.com wrote in message news:listserv%200905191643164240.0...@bama.ua.edu... snip By the way, any pointers on how to submit a marketing requirement? VSE actually has a submit a requirement web page (https://www- 03.ibm.com/servers/eserver/zseries/zvse/contact/requirement.html). Does z/OS have anything similar? Thanks! Frank As the saying goes, I have good news and I have bad news G The good news is The procedure for submitting a Marketing REQUEST is easy. Just contact your IBM Marketing Representative and explain what you want THEM to submit. The bad news is, Try finding out who your IBM marketing rep is. In many cases this is QUITE difficult - it is even hard for many customers to figure out who (how to contact) their local IBM branch. Once you find your local branch and/or your IBM marketing rep, then getting a REQUEST submitted should be a piece of cake. If your IBM Marketing Rep does not know how to submit a REQUEST, then come back to us here (and someone should be able to get your marketing rep in contact with someone who can help them) -- 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 -- 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
BLOCK CONTAINS
Actually, I don't think the Standard has much opinion on the entire BLOCK CONTAINS clause. The fact is that MOST existing conforming COBOL compilers run in environments where blocking doesn't exist any more. For most conforming compilers, this phrase is documented as syntax checked but has no effect on application behavior - or something similar. I suspect that if one asked (via an official interpretation request) what happens when the BLOCK CONTAINS clause is omitted - and you are in an environment where blocking MAY exist, then the answer would be whatever the hardware and/or OS says will happen, happens. However, this is only my opinion of the current status. I strongly doubt that the would find the IBM behavior non-conforming. However, if anyone actually wants to find out, please contact me off-list and I can tell you how to submit an interpretation request. Of possible interest is the fact that the '85 COBOL Standard is no longer an official ANSI or ISO Standard. The current version is the 2002 ISO (or ANSI) Standard - and IBM does NOT even claim to conform to that. Alternatively, you might want to ask about this (as it relates to the Standard) via the Standards Forum section of the IBM COBOL Cafe. See: http://www-949.ibm.com/software/rational/cafe/community/cobol/standard?view= discussions Paul Gilmartin paulgboul...@aim.com wrote in message news:listserv%200905190056357954.0...@bama.ua.edu... On Mon, 18 May 2009 22:56:05 -0500, Bill Klein wrote: The actual phrasing of the current Standard is, 1) This clause is required except when one or more of the following conditions exist: ... c) The number of records or characters contained in a block is specified in the operating environment I think that leaving it out to get unblocked MAY be considered an extension. I think a reasonable person can conclude that for z/OS, specified in the operating environment means either as BLKSIZE on the JCL DD statement or available from SDB, and it is the intent of the Standard that when the BLOCK CONTAINS clause is omitted, that externally specified (by DD or SDB) value should prevail. And thus that z/OS COBOL deviates from the Standard on this matter. -- gil -- 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
Re: BLOCK CONTAINS
On Mon, 18 May 2009 11:03:05 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 18 May 2009 17:48:44 +0200, Gilbert Saint-Flour wrote: On Friday 15 May 2009 04:47, Clark Morris wrote: I submitted a SHARE requirement back in the 1990's to have a compile option that the default be BLOCK 0. Great idea, and I wish IBM added that option to the compiler. What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! What happens if the programmer pre-allocates the data set? It's still a stupid necessity, but it might help in dealing with situations where recompilation is impractical. I am unsure as to the issue. BLOCK CONTAINS 0 works fine with pre-allocated datasets. And in fact, as I mentioned before, with a pre-allocated dataset it appears to not even matter what BLOCK CONTAINS specifies, or if it is even present. The file can still be written to. It seems to take the blocking from the dataset label. Perhaps I have misunderstood your concern? Frank -- 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
Re: BLOCK CONTAINS
On Mon, 18 May 2009 13:08:28 -0500, John McKown joa...@swbell.net wrote: I just ran a quick test using Enterprise COBOL 3.4.1. I had one input FD and three output FDs. The output FDs were: (1) No BLOCK CONTAINS at all; (2) BLOCK CONTAINS 0 RECORDS; and (3) BLOCK CONTAINS 1 RECORDS. I directed each to a separate SMS managed disk dataset. On the JCL for each output file, I specified: // RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS I then dumped the records using IDCAMS, but with the JCL looking like: //JS010EXEC PGM=IDCAMS, // REGION=20M //SYSPRINT DD SYSOUT=* //I1 DD DISP=SHR,DSN=TSH009.MYCOPY.BLOCK0,RECFM=U,BLKSIZE=32760 //I2 DD DISP=SHR,DSN=TSH009.MYCOPY.BLOCK1,RECFM=U,BLKSIZE=32760 //I3 DD DISP=SHR,DSN=TSH009.MYCOPY.NOBLOCK,RECFM=U,BLKSIZE=32760 //SYSINDD * PRINT INFILE(I1) DUMP COUNT(30) PRINT INFILE(I2) DUMP COUNT(30) PRINT INFILE(I3) DUMP COUNT(30) // All three outputs were IDENTICAL and showed that each file was identically blocked. That is: the BLOCK CONTAINS 1 RECORDS did not result in an unblock file! This was run on z/OS 1.10. Those results agree with all of my tests. Frank -- 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
Re: BLOCK CONTAINS
On Mon, 18 May 2009 16:07:12 -0500, Paul Gilmartin paulgboul...@aim.com wrote: Is default unblocked an ANSI Standard requirement? (Of course this doesn't preclude an extension implemented via compiler option.) From the 2002 standard (I don't have the 1985 standard): - 13.16.10 BLOCK CONTAINS clause The BLOCK CONTAINS clause specifies the size of a physical record. 13.16.10.1 General format 13.16.10.2 Syntax rules 1) If integer-1 is specified, integer-2 shall be greater than integer-1. 13.16.10.3 General rules 1) This clause is required except when one or more of the following conditions exist: a) A physical record contains one and only one complete logical record. b) The hardware device assigned to the file has one and only one physical record size. c) The number of records or characters contained in a block is specified in the operating environment. 2) The size of a physical record may be stated in terms of records unless one or more of the following situations exists, in which case the RECORDS phrase shall not be used: a) In mass storage files, logical records may extend across physical records. b) The physical record contains padding (area not contained in a logical record). c) Logical records are grouped in such a manner that an inaccurate physical record size would be implied. 3) If the CHARACTERS phrase is specified, the physical record size is specified in terms of the number of bytes required to store the physical record, regardless of the types of characters used to represent the items within the physical record. 4) If integer-1 is not specified, integer-2 represents the exact size of the physical record. If integer-1 and integer-2 are both specified, they refer to the minimum and maximum size of the physical record, respectively. - I would say that 3c indicates that the clause can be omitted and still not default to unblocked. But perhaps that's just my wishful interpretation. Frank -- 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
Re: BLOCK CONTAINS
On Mon, 18 May 2009 23:00:02 -0500, Bill Klein wmkl...@ix.netcom.com wrote: Ted, The issue that I think you are missing is that this entire conversation started with a site trying to do a VSE to z/OS conversion. For this site, this is a major concern. Certainly not the only one, but it is important to understand exactly does happen/when/how under z/OS - so the requirements for the conversion are resourced and met. As I have said previously, I do think that having Block Contains 0 is the best solution - as it gives desirable results when the phrase is used and doesn't hurt when it isn't used. Being the shop in question, and the originator of this thread, I just thought I'd mention that we are going to globally (for non-VSAM files) specify BLOCK CONTAINS 0. This includes SYSIN and SYSOUT files where BLOCK CONTAINS 0 means even less. But who wants to go through the pain of figuring out what files are SYSIN and SYSOUT files and what files are not. Which is why I wanted to be able to eliminate BLOCK CONTAINS 0 and have that as the default behavior. Ah well. By the way, any pointers on how to submit a marketing requirement? VSE actually has a submit a requirement web page (https://www- 03.ibm.com/servers/eserver/zseries/zvse/contact/requirement.html). Does z/OS have anything similar? Thanks! Frank -- 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
Submitting a Marketing REQUEST (was: BLOCK CONTAINS
Frank Swarbrick fswarbr...@gmail.com wrote in message news:listserv%200905191643164240.0...@bama.ua.edu... snip By the way, any pointers on how to submit a marketing requirement? VSE actually has a submit a requirement web page (https://www- 03.ibm.com/servers/eserver/zseries/zvse/contact/requirement.html). Does z/OS have anything similar? Thanks! Frank As the saying goes, I have good news and I have bad news G The good news is The procedure for submitting a Marketing REQUEST is easy. Just contact your IBM Marketing Representative and explain what you want THEM to submit. The bad news is, Try finding out who your IBM marketing rep is. In many cases this is QUITE difficult - it is even hard for many customers to figure out who (how to contact) their local IBM branch. Once you find your local branch and/or your IBM marketing rep, then getting a REQUEST submitted should be a piece of cake. If your IBM Marketing Rep does not know how to submit a REQUEST, then come back to us here (and someone should be able to get your marketing rep in contact with someone who can help them) -- 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
Re: BLOCK CONTAINS
On 15 May 2009 18:08:22 -0700, cfmpub...@ns.sympatico.ca (Clark Morris) wrote: I checked the reference you gave and for QSAM files, if the BLOCK CONTAINS clause is omitted, BLOCK 1 RECORD is assumed. This stupidity has aggravated me for years. The whole idea of (IBM mainframe) CoBOL still caring about blocksize is irritating. The fix of making BLOCK CONTAINS 0 is IMHO, not the way fixes should be. -- 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
Fw: BLOCK CONTAINS
I may (a while ago - in the past) have mislead Clark. There is DEFINITELY a difference between coding Block Contains 1 versus omitting the Block CONTAINS clause (for output files) The former creates a RECFM=FB/BM file (with one record per block) while the latter produces a RECFM=F/V file Personally, neither are USUALLY the desired results, but they are different. howard.bra...@cusys.edu wrote in message news:jps215p3ha8d7g7qvn2j1cigaqq8939...@4ax.com... On 15 May 2009 18:08:22 -0700, cfmpub...@ns.sympatico.ca (Clark Morris) wrote: I checked the reference you gave and for QSAM files, if the BLOCK CONTAINS clause is omitted, BLOCK 1 RECORD is assumed. This stupidity has aggravated me for years. The whole idea of (IBM mainframe) CoBOL still caring about blocksize is irritating. The fix of making BLOCK CONTAINS 0 is IMHO, not the way fixes should be. -- 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
Re: BLOCK CONTAINS
On Friday 15 May 2009 04:47, Clark Morris wrote: I submitted a SHARE requirement back in the 1990's to have a compile option that the default be BLOCK 0. Great idea, and I wish IBM added that option to the compiler. What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ -- 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
Fw: BLOCK CONTAINS
I don't know about Clark submitting a requirement in the 90's, but there is an existing SHARE requirement: SSLNGC03003 Compiler option to make BLOCK CONTAINS clause SMS sensitive (Part of the Description) The current default for when the BLOCK CONTAINS x RECORDS clause is omitted is for unblocked files. If this default is taken, the result is an unblocked file with very poor I/O performance. This may not be obvious since the JCL may be correctly coded, but any JCL BLKSIZE specification will be ignored without notification. Coding BLOCK CONTAINS 0 RECORDS is the preferred solution, since it allows DFSMS to pick blocking with the optimal BLKSIZE. This requirement requests a compiler option that would allow the default for when the BLOCK CONTAINS clause is omitted to be set to the same processing as the current handling of BLOCK CONTAINS 0 RECORDS instead of creating/reading unblocked files. * * * * * This was submitted in 2003 and in 2004, IBM responded with ACCEPT. There is currently a push within the comp.lang.cobol group to get AS MANY AS POSSIBLE of existing Enterprise COBOL sites to submit a Marketing REQUEST that references this SHARE requirement and asking for implementation sooner than later. I would suggest that ALL of those in IBM-MAIN who are interested in seeing this enhancement, should also contact their IBM marketing representative and have such a REQUEST submitted from your site. (And no, don't ask ME how to find an IBM marketing representative) Gilbert Saint-Flour usenet5...@yahoo.com wrote in message news:200905181748.44799.usenet5...@yahoo.com... On Friday 15 May 2009 04:47, Clark Morris wrote: I submitted a SHARE requirement back in the 1990's to have a compile option that the default be BLOCK 0. Great idea, and I wish IBM added that option to the compiler. What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ -- 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
Re: BLOCK CONTAINS
On Mon, 18 May 2009 17:48:44 +0200, Gilbert Saint-Flour wrote: On Friday 15 May 2009 04:47, Clark Morris wrote: I submitted a SHARE requirement back in the 1990's to have a compile option that the default be BLOCK 0. Great idea, and I wish IBM added that option to the compiler. What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! What happens if the programmer pre-allocates the data set? It's still a stupid necessity, but it might help in dealing with situations where recompilation is impractical. -- gil -- 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
Re: BLOCK CONTAINS
On Monday 18 May 2009 18:04, Paul Gilmartin wrote: What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! What happens if the programmer pre-allocates the data set? It's still a stupid necessity, but it might help in dealing with situations where recompilation is impractical. Well, pre-allocation is not very compatible with HSM, GDG, and a few other things. So I believe the combination between DISP=(,NEW,CATLG) and BLOCK CONTAINS 0 is the best choice to solve potential problems. And believe it or not, but many years ago, I wrote a utility to update load-modules and force BLKSIZE=0. I probably only used it only once. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ -- 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
Re: BLOCK CONTAINS
Curiousity question: would using the IFG0EX0B exit be a Good Idea(tm)? From my initial reading, it can change the BLKSIZE. And likely the RECFM as well (to change F/V to FB/VB). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: BLOCK CONTAINS
I just ran a quick test using Enterprise COBOL 3.4.1. I had one input FD and three output FDs. The output FDs were: (1) No BLOCK CONTAINS at all; (2) BLOCK CONTAINS 0 RECORDS; and (3) BLOCK CONTAINS 1 RECORDS. I directed each to a separate SMS managed disk dataset. On the JCL for each output file, I specified: // RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS I then dumped the records using IDCAMS, but with the JCL looking like: //JS010EXEC PGM=IDCAMS, // REGION=20M //SYSPRINT DD SYSOUT=* //I1 DD DISP=SHR,DSN=TSH009.MYCOPY.BLOCK0,RECFM=U,BLKSIZE=32760 //I2 DD DISP=SHR,DSN=TSH009.MYCOPY.BLOCK1,RECFM=U,BLKSIZE=32760 //I3 DD DISP=SHR,DSN=TSH009.MYCOPY.NOBLOCK,RECFM=U,BLKSIZE=32760 //SYSINDD * PRINT INFILE(I1) DUMP COUNT(30) PRINT INFILE(I2) DUMP COUNT(30) PRINT INFILE(I3) DUMP COUNT(30) // All three outputs were IDENTICAL and showed that each file was identically blocked. That is: the BLOCK CONTAINS 1 RECORDS did not result in an unblock file! This was run on z/OS 1.10. Oh, for fun, I also put the output onto non-SMS managed DASD with the same result. -- John McKown -- 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
Re: BLOCK CONTAINS
The whole idea of (IBM mainframe) CoBOL still caring about blocksize is irritating. The fix of making BLOCK CONTAINS 0 is IMHO, not the way fixes should be. I really don't think this qualifies as a 'fix'. I learned COBOL in 1976, and was taught, back then, to always use BLOCK CONTAINS 0 RECORDS (I don't think that the last keyword was optional, then). That was long before System Determined Blocksize was even dreamed about. We used it so we could easily move from disk (for testing) to tape (for real), without re-compiling. - Too busy driving to stop for gas! -- 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
Re: BLOCK CONTAINS
What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! What a stupid necessity that REXX programmers have to code: PARSE (UPPER) ARG var1 var2 ... What a stupid necessity to have to code extra volumes in JCL/IDCAMS (or in your ACS) routines. What a stupid necessity that ... (well, you get the picture). There are a lot of warts (still) in z/OS. Some are trivial, some are complex, and some are not truly worth the effort to address. But, z/OS is the most robust OS out there, so I'm willing to live with some of its quirks. - Too busy driving to stop for gas! -- 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
Fw: BLOCK CONTAINS
John, What happens if you run the exact same test, but instead of having the JCL for your output as: // RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS you instead JUST coded // DSORG=PS i.e. you leave out the JCL (overrides) for RECCFM, LRECL, and BLKSIZE) - I think that this is when/where the different BLOCK CONTAINS clauses make a difference. John McKown joa...@swbell.net wrote in message news:listserv%200905181308288278.0...@bama.ua.edu... I just ran a quick test using Enterprise COBOL 3.4.1. I had one input FD and three output FDs. The output FDs were: (1) No BLOCK CONTAINS at all; (2) BLOCK CONTAINS 0 RECORDS; and (3) BLOCK CONTAINS 1 RECORDS. I directed each to a separate SMS managed disk dataset. On the JCL for each output file, I specified: // RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS I then dumped the records using IDCAMS, but with the JCL looking like: //JS010EXEC PGM=IDCAMS, // REGION=20M //SYSPRINT DD SYSOUT=* //I1 DD DISP=SHR,DSN=TSH009.MYCOPY.BLOCK0,RECFM=U,BLKSIZE=32760 //I2 DD DISP=SHR,DSN=TSH009.MYCOPY.BLOCK1,RECFM=U,BLKSIZE=32760 //I3 DD DISP=SHR,DSN=TSH009.MYCOPY.NOBLOCK,RECFM=U,BLKSIZE=32760 //SYSINDD * PRINT INFILE(I1) DUMP COUNT(30) PRINT INFILE(I2) DUMP COUNT(30) PRINT INFILE(I3) DUMP COUNT(30) // All three outputs were IDENTICAL and showed that each file was identically blocked. That is: the BLOCK CONTAINS 1 RECORDS did not result in an unblock file! This was run on z/OS 1.10. Oh, for fun, I also put the output onto non-SMS managed DASD with the same result. -- John McKown -- 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 -- 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
Re: BLOCK CONTAINS
On 18 May 2009 11:30:02 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: The whole idea of (IBM mainframe) CoBOL still caring about blocksize is irritating. The fix of making BLOCK CONTAINS 0 is IMHO, not the way fixes should be. I really don't think this qualifies as a 'fix'. I learned COBOL in 1976, and was taught, back then, to always use BLOCK CONTAINS 0 RECORDS (I don't think that the last keyword was optional, then). That was long before System Determined Blocksize was even dreamed about. We used it so we could easily move from disk (for testing) to tape (for real), without re-compiling. Yes, even before System Determined Blocksize, the system had places where the program didn't determine blocksize. It is a lie to say BLOCK CONTAINS 0 RECORDS, it would have been better to have done that by leaving out the line altogether. -- 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
Re: BLOCK CONTAINS
It is a lie to say BLOCK CONTAINS 0 RECORDS, it would have been better to have done that by leaving out the line altogether. I don't think it's a lie. Historically, ZERO has always had a special meaning. In COBOL's case, it just means that the programme is not going to determine the blocksize, but leaves a place-holder for it when it's decided elsewhere. I honestly don't think that it's so onerous to have to worry about coding it (it's a nit). Most shops have standard templates (or programmers copy existing code) that are modified to meet current needs. Very little code is written from scratch. (I know I rarely do it for any language). - Too busy driving to stop for gas! -- 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
Re: BLOCK CONTAINS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Klein Sent: Monday, May 18, 2009 1:45 PM To: IBM-MAIN@bama.ua.edu Subject: Fw: BLOCK CONTAINS John, What happens if you run the exact same test, but instead of having the JCL for your output as: // RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS you instead JUST coded // DSORG=PS i.e. you leave out the JCL (overrides) for RECCFM, LRECL, and BLKSIZE) - I think that this is when/where the different BLOCK CONTAINS clauses make a difference. Ah! NOBLOCK had F/80/80 whereas BLOCK1 had FB/80/80. BLOCK0 still had FB/80/27920. But it is still interesting, to me, that BLOCK CONTAINS 1 and no BLOCK CONTAINS at all can still create an optimally block dataset with little effort in the JCL and no program changes. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: BLOCK CONTAINS
On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote: On Monday 18 May 2009 18:04, Paul Gilmartin wrote: What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! What happens if the programmer pre-allocates the data set? It's still a stupid necessity, but it might help in dealing with situations where recompilation is impractical. Well, pre-allocation is not very compatible with HSM, GDG, and a few other I believe I understand the concern with GDG. (Actually, mu understanding of GDG is so rudimentary I'm not qualified to doubt the concern.) But what of HSM? Why should there be a problem? Simply preface an IEFBR14 step with attributes and DISP=(,CATLG) things. So I believe the combination between DISP=(,NEW,CATLG) and BLOCK ??? What's the omitted positional subparameter? Primary disposition NEW, secondary disposition CATLG? CONTAINS 0 is the best choice to solve potential problems. Yah. It should be done by the access method; the application should be oblivious to the entire blocking process. And believe it or not, but many years ago, I wrote a utility to update load-modules and force BLKSIZE=0. I probably only used it only once. By re-linking? I thought that was the only way. (Well, massive RYO.) Is default unblocked an ANSI Standard requirement? (Of course this doesn't preclude an extension implemented via compiler option.) -- gil -- 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
Re: BLOCK CONTAINS
Yah. It should be done by the access method; the application should be oblivious to the entire blocking process. We have 45 years of baggage. Woulda, coulda, shoulda. Most people/shops have templates with these things already specified. Copy, and move on. If BLOCK CONTAINS is an issue, you don't have the weight of the world on your shoulders. I don't mean to sound deprecating, but there are more important issues. - Too busy driving to stop for gas! -- 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
Re: BLOCK CONTAINS
On 18 May 2009 13:35:40 -0700, in bit.listserv.ibm-main you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Klein Sent: Monday, May 18, 2009 1:45 PM To: IBM-MAIN@bama.ua.edu Subject: Fw: BLOCK CONTAINS John, What happens if you run the exact same test, but instead of having the JCL for your output as: // RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS you instead JUST coded // DSORG=PS i.e. you leave out the JCL (overrides) for RECCFM, LRECL, and BLKSIZE) - I think that this is when/where the different BLOCK CONTAINS clauses make a difference. Ah! NOBLOCK had F/80/80 whereas BLOCK1 had FB/80/80. BLOCK0 still had FB/80/27920. But it is still interesting, to me, that BLOCK CONTAINS 1 and no BLOCK CONTAINS at all can still create an optimally block dataset with little effort in the JCL and no program changes. This is weird because the normal merge is DCB overrides JCL and JCL overrides data set label (DSCB or tape label). The code to distinguish between BLKSIZE=0 in JCL and BLKSIZE not supplied must be interesting to say the least. If I get energetic, I'll check the COBOL Programmers Guide. Talk about ways to confuse the applications programmers and subtle ways to screw up. -- 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
Re: BLOCK CONTAINS
On 18 May 2009 14:10:36 -0700, in bit.listserv.ibm-main you wrote: On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote: On Monday 18 May 2009 18:04, Paul Gilmartin wrote: What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! What happens if the programmer pre-allocates the data set? It's still a stupid necessity, but it might help in dealing with situations where recompilation is impractical. Well, pre-allocation is not very compatible with HSM, GDG, and a few other I believe I understand the concern with GDG. (Actually, mu understanding of GDG is so rudimentary I'm not qualified to doubt the concern.) But what of HSM? Why should there be a problem? Simply preface an IEFBR14 step with attributes and DISP=(,CATLG) things. So I believe the combination between DISP=(,NEW,CATLG) and BLOCK ??? What's the omitted positional subparameter? Primary disposition NEW, secondary disposition CATLG? CONTAINS 0 is the best choice to solve potential problems. Yah. It should be done by the access method; the application should be oblivious to the entire blocking process. And believe it or not, but many years ago, I wrote a utility to update load-modules and force BLKSIZE=0. I probably only used it only once. By re-linking? I thought that was the only way. (Well, massive RYO.) Is default unblocked an ANSI Standard requirement? (Of course this doesn't preclude an extension implemented via compiler option.) Implementor defined according to Bill Klein. Since COBOL had no way of specifying UNBLOCKED, I suspect that IBM chose the lack of the BLOCK [CONTAINS] clause to mean unblocked. The current handling is confusing because the BLOCK [CONTAINS] clause isn't specified for VSAM which came after the 1968 standard. -- gil -- 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
Re: BLOCK CONTAINS
On Mon, 18 May 2009 21:28:02 +, Ted MacNEIL wrote: We have 45 years of baggage. Woulda, coulda, shoulda. Most people/shops have templates with these things already specified. Copy, and move on. Whenever I hear this diachronic rationale for some deficiency of z/OS, I think of the political unrest in the U.S. in the 1960's when bumper stickers: America: Love it or leave it! were countered with: America: Change it or lose it! C 'America' 'z/OS' ALL -- gil -- 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
Re: BLOCK CONTAINS
We have 45 years of baggage. Woulda, coulda, shoulda. Most people/shops have templates with these things already specified. Copy, and move on. Whenever I hear this diachronic rationale for some deficiency of z/OS, I think of the political unrest in the U.S. in the 1960's when bumper stickers: America: Love it or leave it! were countered with: America: Change it or lose it! C 'America' 'z/OS' ALL You missed my point(s): 1. The existance of templates can/does handle the requirement for BLOCK CONTAINS. 2. Some things are way to trivial to lose sleep over. 3. There are more important things to worry about than something that has been around for so long, and we have a solution for. 4. Copy and move on! - Too busy driving to stop for gas! -- 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
Fw: BLOCK CONTAINS
Paul Gilmartin paulgboul...@aim.com wrote in message news:listserv%200905181607125082.0...@bama.ua.edu... On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote: snip Is default unblocked an ANSI Standard requirement? (Of course this doesn't preclude an extension implemented via compiler option.) The actual phrasing of the current Standard is, 1) This clause is required except when one or more of the following conditions exist: a) A physical record contains one and only one complete logical record. b) The hardware device assigned to the file has one and only one physical record size. c) The number of records or characters contained in a block is specified in the operating environment I think that leaving it out to get unblocked MAY be considered an extension. -- 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
BLOCK CONTAINS
Ted, The issue that I think you are missing is that this entire conversation started with a site trying to do a VSE to z/OS conversion. For this site, this is a major concern. Certainly not the only one, but it is important to understand exactly does happen/when/how under z/OS - so the requirements for the conversion are resourced and met. As I have said previously, I do think that having Block Contains 0 is the best solution - as it gives desirable results when the phrase is used and doesn't hurt when it isn't used. Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1311180719-1242704268-cardhu_decombobulator_blackberry.rim.net-1990313 5...@bxe1305.bisx.prod.on.blackberry... We have 45 years of baggage. Woulda, coulda, shoulda. Most people/shops have templates with these things already specified. Copy, and move on. Whenever I hear this diachronic rationale for some deficiency of z/OS, I think of the political unrest in the U.S. in the 1960's when bumper stickers: America: Love it or leave it! were countered with: America: Change it or lose it! C 'America' 'z/OS' ALL You missed my point(s): 1. The existance of templates can/does handle the requirement for BLOCK CONTAINS. 2. Some things are way to trivial to lose sleep over. 3. There are more important things to worry about than something that has been around for so long, and we have a solution for. 4. Copy and move on! - Too busy driving to stop for gas! -- 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 -- 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
Re: Fw: BLOCK CONTAINS
On Mon, 18 May 2009 22:56:05 -0500, Bill Klein wrote: The actual phrasing of the current Standard is, 1) This clause is required except when one or more of the following conditions exist: ... c) The number of records or characters contained in a block is specified in the operating environment I think that leaving it out to get unblocked MAY be considered an extension. I think a reasonable person can conclude that for z/OS, specified in the operating environment means either as BLKSIZE on the JCL DD statement or available from SDB, and it is the intent of the Standard that when the BLOCK CONTAINS clause is omitted, that externally specified (by DD or SDB) value should prevail. And thus that z/OS COBOL deviates from the Standard on this matter. -- gil -- 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
Fw: BLOCK CONTAINS
Frank Swarbrick fswarbr...@gmail.com wrote in message news:listserv%200905151108397984.0...@bama.ua.edu... On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: snip It depends on if the file is pre-defined. If it is not, and I don't include DCB stuff on the DD, then it does what Cobol tells it to do (because there is no other place to get that information!). However if the file *is* predefined then *that* information appears (for blocking only, not for RECFM (V vs B) or LRECL) to override what Cobol states. Examples... If I predefine a file as RECFM=VB, BLKSIZE=1, LRECL=4004 then 1) If Cobol says BLOCK CONTAINS 1 it works (of course). 2) If Cobol says BLOCK CONTAINS 0 it works. 3) If Cobol says BLOCK CONTAINS 12345 it works (!!!) 4) If Cobol does not have a BLOCK CONTAINS clause it works (!!!) This is the case no matter if I am reading from the file or writing to it. I am glad it works no matter what. But the documentation seems to me to indicate that conditions 3 and 4 should not work, even though they do. That is where I am getting confused. snip Frank, (Some private email also sent on this), I think that the current COBOL documentation *ASSUMES* (possibly erroneously) that for OUTPUT files A) For QSAM, that they are NOT pre-defined and that the combination of the COBOL FD information and the JCL information will CREATE the file B) For VSAM (KSDS, ESDS, *and* RRDS) that the file IS predefined (e.g. IDCAMS). The statement at: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/1.9.4.3.2 that says, If your COBOL program writes records to a new file that will be made available before the program runs, ensure that the file attributes in the DD statement, the environment variable, or the allocation do not conflict with the attributes in the program. seems to be saying that if you do predefine QSAM files that you should make certain that the attributes match. The UNSTATED implication (or my inference) is that your case 3 and 4 may work today and it may work tomorrow, but there is no GUARANTEE that they will work with the next release or even service level. My guess is that they will, but I certainly do not see any place in the existing COBOL documentation that guarantees this. From my experience (and as a personal opinion), I would NOT pre-allocate QSAM files - but instead would use BLOCK CONTAINS 0 in the COBOL program. I can't think of when this would ever hurt and I can certainly see lots of times that it would help. -- 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
Re: VSE I/O Performance VS MVS [was BLOCK CONTAINS]
On 15 May 2009 17:24:25 -0700, in bit.listserv.ibm-main you wrote: Frank, I suggest you download the Redbook, VSAM De-Mystified. It will answer your questions concerning VSAM performance. As my instructor told the class years ago - Don't take the defaults! Specify CI sizes that give the best space utilization for your record size. Choose a large enough Index CI Size to avoid 'dead areas' in your data component. Specify a robust value for your Bufferspace parameter, in most cases the larger the better. (I'm sure someone will volunteer a 'war story' where this wasn't the case but generally a large buffer space improves throughput.) For batch processing look into BLSR. While I did a lot with BLSR, from what I read in the manual there are other parameters available for managing VSAM access that give at least as good results. Check the JCL manual. The constructs may only apply to SMS managed data sets. For CICS use LSRpools, again be generous. The more data stored in memory the fewer physical I/O. HTH, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick [fswarbr...@gmail.com] Sent: Friday, May 15, 2009 6:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: VSE I/O Performance VS MVS [was BLOCK CONTAINS] On Fri, 15 May 2009 14:09:33 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: Because of past conversions, I think this needs to be said: 1) VSE/ESA got to use XA I/O just like MVS. This means, to the VSE shop, that some slick stuff that got offloaded to the I/O Subsystem (shall we say parts of VM's and MVS' I/O Supervisor code) became available w/o any JCL or application coding changes. Things like dual (or multi) pathing with dynamic pathing. What does this have to do with anything? Well, the typical throughput performance gains seen in the past when going from VSE to MVS don't happen because what was giving those (for the most part) has already been realized. 2) VSAM is implemented in VSE differently than in MVS. So, the way sharing and buffer management is done changes and WILL cause performance issues when you get to MVS. 3) CICS is impacted by these changes, and you may see less throughput. Although, with the ability to have more storage than z/VSE allows, you may over come it. But be sure to have sufficient page volumes. Are you saying the MVS VSAM is less efficient then VSE VSAM? Hmmm! One might start to wonder why we are migrating at all! :-) Thanks for the info. I will pass it on to our systems programmers (who hopefully already know what you are talking about anyway, but it couldn't hurt). Frank -- 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 -- 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 -- 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
Re: BLOCK CONTAINS
Clark, Wow, 1998, that was a while ago! SyncSort processing has changed. Unless told specifically to leave the output unblocked, we will create the output data set as a blocked data set when the input is VSAM. I'm not sure when the change occurred but it was some time ago. John Reda Syncsort, Inc. 201-930-8260 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Clark Morris Sent: Thursday, May 14, 2009 10:45 PM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS snip While blocked input files may be read successfully if neither the block size nor BLOCK 0 is specified provided record descriptions match, lack of BLOCK CONTAINS causes the default blocksize on output to be ONE record. I believe I submitted a SHARE requirement back in the 1990's to have a compile option that the default be BLOCK 0. Either is a perfectly valid default according to the COBOL standard. BLOCK would be the default consistent with VSAM handling. The whole issue is a sore point with me and possibly others. Incidentally be careful to specify BLKSIZE=0 on the DD statements of output files from sorts that sort or copy VSAM files. Unless things have changed from 1998, SYNCSORT defaulted to one record per block. snip -- 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
Re: BLOCK CONTAINS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, May 14, 2009 7:03 PM To: IBM-MAIN@bama.ua.edu Subject: BLOCK CONTAINS I have been a bit of experimenting with z/OS QSAM files from a Cobol program and I find that the manuals don't exactly agree with my results. The manuals seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or something else) then the file has a RECFM of either VB or FB. And if you don't include it then it's either V or B. SNIPPAGE Welcome to the MVS world. In the MVS world, we are not device dependant, nor are we data definition locked/blocked. We generally don't have to recompile our programs, change the DTF contents (DCB in MVS), etc. just because the file attributes change (xSAM to VSAM is the exception). We do not have to link PIOCS or LIOCS routines to our programs to handle I/O. The access method itself handles these things (particularly at the QSAM level). If you are using a vendor to help you migrate, you should spend a bit of time with them discussing all the changes to the environment and different concepts between VSE and MVS. As you have seen with your experiments, the information on the DD statement will override what you have in your program. And the label from the file in MVS actually contains the LRECL, BLKSIZE and RECFM, which as I recall, is not the case with VSE (for disk or tape). However, what happens if the DD statement only contains the UNIT, SPACE, DISP, and DSN? Does what you specify in the COBOL program then behave the way the manual says? Your ESDS files being taken to SAM: Just make sure that you don't actually depend on VSAM functions. And as far as your ASSIGN clause on the SELECT: you can probably leave them as they are -- but I haven't used the latest COBOL for a migration. In fact it has been a few years since I've done a migration. So unless it is going to enforce something, as I recall, only what is after the last - is paid attention to. And if you end with -SYS112 (or some such), then the DD being looked for is SYS112. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- 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
Re: BLOCK CONTAINS
On Friday 15 May 2009 02:05, Frank Swarbrick wrote: We are migrating from VSE to z/OS, and at the same time we are going to convert most of our existing ESDS files to regular sequential files. I see no reason to add BLOCK CONTAINS 0 to all of our FD's if it has no affect (our VSAM FD's do not (generally!) specify the BLOCK CONTAINS clause, because it has no meaning to VSAM). IIRC, BLOCK CONTAINS 0 is only needed for OUTPUT files in COBOL, but I think it's better to put it everywhere, so programmers later don't have to remember where it's needed. In 1991, I started to convert VSE applications to MVS/ESA and stopped to generate DCB attributes on DD statements, except for output files in IDCAMS REPRO and QUIKJOB programs, and a few others ones. A few years later, I started to convert IDCAMS REPRO to something else, for several advantages, among them not having to specify DCB info in the JCL. I'm convinced that coding DCB attributes on DD statements is something almost always useless and archaic. This is something all my customers agreed with, except an outsourcing company that absolutely had to have DCB information on all output DD statements, like this: DCB=(RECFM=xx,LRECL=yy,BLKSIZE=zzz). This was in 2007 ! In z/OS ! See examples here: http://gsf-soft.com/Prism-CS/Samples.shtml and you won't see many DD statements that contain DCB info. This is very similar to what I generated since 1991. As for the conversion of ESDS files to non-VSAM in COBOL programs, changing AS-filename to S-ddname is not always the only thing you need to do. Trust me ! -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ -- 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
Re: BLOCK CONTAINS
What if a new device came out and there was a better optimum blocksize for it? Wouldn't you have to recompile everthing that used that file to get the optimum blocksize? I don't know I'm just asking. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gilbert Saint-Flour Sent: Friday, May 15, 2009 8:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS On Friday 15 May 2009 02:05, Frank Swarbrick wrote: We are migrating from VSE to z/OS, and at the same time we are going to convert most of our existing ESDS files to regular sequential files. I see no reason to add BLOCK CONTAINS 0 to all of our FD's if it has no affect (our VSAM FD's do not (generally!) specify the BLOCK CONTAINS clause, because it has no meaning to VSAM). IIRC, BLOCK CONTAINS 0 is only needed for OUTPUT files in COBOL, but I think it's better to put it everywhere, so programmers later don't have to remember where it's needed. In 1991, I started to convert VSE applications to MVS/ESA and stopped to generate DCB attributes on DD statements, except for output files in IDCAMS REPRO and QUIKJOB programs, and a few others ones. A few years later, I started to convert IDCAMS REPRO to something else, for several advantages, among them not having to specify DCB info in the JCL. I'm convinced that coding DCB attributes on DD statements is something almost always useless and archaic. This is something all my customers agreed with, except an outsourcing company that absolutely had to have DCB information on all output DD statements, like this: DCB=(RECFM=xx,LRECL=yy,BLKSIZE=zzz). This was in 2007 ! In z/OS ! See examples here: http://gsf-soft.com/Prism-CS/Samples.shtml and you won't see many DD statements that contain DCB info. This is very similar to what I generated since 1991. As for the conversion of ESDS files to non-VSAM in COBOL programs, changing AS-filename to S-ddname is not always the only thing you need to do. Trust me ! -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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
Re: BLOCK CONTAINS
Blocksize=0 invokes system determined blocking which results in 2 blocks per track. It won't matter what DASD device is used. Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S [mw...@ssfcu.org] Sent: Friday, May 15, 2009 9:37 AM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS What if a new device came out and there was a better optimum blocksize for it? Wouldn't you have to recompile everthing that used that file to get the optimum blocksize? I don't know I'm just asking. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gilbert Saint-Flour Sent: Friday, May 15, 2009 8:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS On Friday 15 May 2009 02:05, Frank Swarbrick wrote: We are migrating from VSE to z/OS, and at the same time we are going to convert most of our existing ESDS files to regular sequential files. I see no reason to add BLOCK CONTAINS 0 to all of our FD's if it has no affect (our VSAM FD's do not (generally!) specify the BLOCK CONTAINS clause, because it has no meaning to VSAM). IIRC, BLOCK CONTAINS 0 is only needed for OUTPUT files in COBOL, but I think it's better to put it everywhere, so programmers later don't have to remember where it's needed. In 1991, I started to convert VSE applications to MVS/ESA and stopped to generate DCB attributes on DD statements, except for output files in IDCAMS REPRO and QUIKJOB programs, and a few others ones. A few years later, I started to convert IDCAMS REPRO to something else, for several advantages, among them not having to specify DCB info in the JCL. I'm convinced that coding DCB attributes on DD statements is something almost always useless and archaic. This is something all my customers agreed with, except an outsourcing company that absolutely had to have DCB information on all output DD statements, like this: DCB=(RECFM=xx,LRECL=yy,BLKSIZE=zzz). This was in 2007 ! In z/OS ! See examples here: http://gsf-soft.com/Prism-CS/Samples.shtml and you won't see many DD statements that contain DCB info. This is very similar to what I generated since 1991. As for the conversion of ESDS files to non-VSAM in COBOL programs, changing AS-filename to S-ddname is not always the only thing you need to do. Trust me ! -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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 -- 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
Re: BLOCK CONTAINS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Friday, May 15, 2009 8:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS What if a new device came out and there was a better optimum blocksize for it? Wouldn't you have to recompile everthing that used that file to get the optimum blocksize? I don't know I'm just asking. SNIPPAGE Under VSE that would be true for other than VSAM access. Under MVS you would have to go out of your way to get into this problem of being blocksize dependent. Granted, this was done in days when there were different device geometries (2314, 3330, 3340, 3375, 3380, 3390). But as has been and will be pointed out, as long as you specify BLKSIZE=0, you will get System Determined Blocksize which will handle this situation. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- 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
Re: BLOCK CONTAINS
On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote: Welcome to the MVS world. In the MVS world, we are not device dependant, nor are we data definition locked/blocked. We generally don't have to recompile our programs, change the DTF contents (DCB in MVS), etc. just because the file attributes change (xSAM to VSAM is the exception). Huh??? If we are not device dependant, why is there such intense trepidation and resistance to the mere suggestion of a device with a novel geometry such as more bytes per track or more tracks per cylinder? It doesn't appear that you and I have been living in the same MVS world. -- gil -- 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
Re: BLOCK CONTAINS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Friday, May 15, 2009 9:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote: Welcome to the MVS world. In the MVS world, we are not device dependant, nor are we data definition locked/blocked. We generally don't have to recompile our programs, change the DTF contents (DCB in MVS), etc. just because the file attributes change (xSAM to VSAM is the exception). Huh??? If we are not device dependant, why is there such intense trepidation and resistance to the mere suggestion of a device with a novel geometry such as more bytes per track or more tracks per cylinder? It doesn't appear that you and I have been living in the same MVS world. SNIP In the VSE world, if you set up to read tape, you can not change your JCL to instead read Disk. A DTFSD (Define The File - Sequential Disk) can not be used to read a tape (DTFMT - Define The File - Magnetic Tape). If you did use the DTFDI (Define The File - Device Independent) it is only good for limited situations. In the MVS world, DCB is DCB -- We don't have DCBSD for Data Control Block - Sequential Disk. The Access Method connects you to the device and handles it (unless you went out of your way to make the DCB specific to a device, such as a card reader). As you can see, there is device dependence and then there is device dependence. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- 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
Re: BLOCK CONTAINS
If we are not device dependant, why is there such intense trepidation and resistance to the mere suggestion of a device with a novel geometry such as more bytes per track or more tracks per cylinder? That is a different issue. If you code BLOCK CONTAINS 0, your application does not need to concern itself with the device (tape or disk), or with whatever the disk geometry is. So, if we ever get a new disk type, the programme will not need recompiling. - Too busy driving to stop for gas! -- 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
Re: BLOCK CONTAINS
On Thu, 14 May 2009 23:45:14 -0300, Clark Morris cfmpub...@ns.sympatico.ca wrote: On 14 May 2009 17:05:53 -0700, in bit.listserv.ibm-main you wrote: I have been a bit of experimenting with z/OS QSAM files from a Cobol program and I find that the manuals don't exactly agree with my results. The manuals seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or something else) then the file has a RECFM of either VB or FB. And if you don't include it then it's either V or B. While blocked input files may be read successfully if neither the block size nor BLOCK 0 is specified provided record descriptions match, lack of BLOCK CONTAINS causes the default blocksize on output to be ONE record. I believe I submitted a SHARE requirement back in the 1990's to have a compile option that the default be BLOCK 0. Either is a perfectly valid default according to the COBOL standard. BLOCK would be the default consistent with VSAM handling. The whole issue is a sore point with me and possibly others. So are you saying that if I create a file (using, say, ISPF 3.2) and specify VB with a particular block size, if my Cobol program that writes data to this (empty) file does *not* have BLOCK CONTAINS 0 (or BLOCK CONTAINS whatever the actual block size is) the actual I/O will *not* be blocked? It definitely works, but I don't know how to tell what the actual blocking factor is. Frank -- 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
Re: BLOCK CONTAINS
On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, May 14, 2009 7:03 PM To: IBM-MAIN@bama.ua.edu Subject: BLOCK CONTAINS I have been a bit of experimenting with z/OS QSAM files from a Cobol program and I find that the manuals don't exactly agree with my results. The manuals seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or something else) then the file has a RECFM of either VB or FB. And if you don't include it then it's either V or B. SNIPPAGE Welcome to the MVS world. In the MVS world, we are not device dependant, nor are we data definition locked/blocked. We generally don't have to recompile our programs, change the DTF contents (DCB in MVS), etc. just because the file attributes change (xSAM to VSAM is the exception). We do not have to link PIOCS or LIOCS routines to our programs to handle I/O. The access method itself handles these things (particularly at the QSAM level). If you are using a vendor to help you migrate, you should spend a bit of time with them discussing all the changes to the environment and different concepts between VSE and MVS. We are not using a vendor. We have systems and applications programmers that come from the MVS world, so we're going with that expertise. Though I suppose the fact that I am asking these questions here might indicate that said expertise is perhaps not sufficient? Hmmm... As you have seen with your experiments, the information on the DD statement will override what you have in your program. And the label from the file in MVS actually contains the LRECL, BLKSIZE and RECFM, which as I recall, is not the case with VSE (for disk or tape). However, what happens if the DD statement only contains the UNIT, SPACE, DISP, and DSN? Does what you specify in the COBOL program then behave the way the manual says? It depends on if the file is pre-defined. If it is not, and I don't include DCB stuff on the DD, then it does what Cobol tells it to do (because there is no other place to get that information!). However if the file *is* predefined then *that* information appears (for blocking only, not for RECFM (V vs B) or LRECL) to override what Cobol states. Examples... If I predefine a file as RECFM=VB, BLKSIZE=1, LRECL=4004 then 1) If Cobol says BLOCK CONTAINS 1 it works (of course). 2) If Cobol says BLOCK CONTAINS 0 it works. 3) If Cobol says BLOCK CONTAINS 12345 it works (!!!) 4) If Cobol does not have a BLOCK CONTAINS clause it works (!!!) This is the case no matter if I am reading from the file or writing to it. I am glad it works no matter what. But the documentation seems to me to indicate that conditions 3 and 4 should not work, even though they do. That is where I am getting confused. Your ESDS files being taken to SAM: Just make sure that you don't actually depend on VSAM functions. Any hints as to what VSAM functions I might be depending on? The only case we've come upon so far is if the file is defined to CICS we have to leave it as an ESDS. We have about two dozen of those, but plan on converting all others to SAM. And as far as your ASSIGN clause on the SELECT: you can probably leave them as they are -- but I haven't used the latest COBOL for a migration. In fact it has been a few years since I've done a migration. So unless it is going to enforce something, as I recall, only what is after the last - is paid attention to. And if you end with -SYS112 (or some such), then the DD being looked for is SYS112. Both VSE and z/OS require the AS- prefix in order for Cobol to distinguish between between a VSAM ESDS and a regular SAM file. Other than that, yes, only the last node has any meaning. Nonetheless our conversion program is going to remove all of the superfluous stuff. I have been trying to get my fellow programmers to cut out this information for years, but with little success. Hopefully this way people will have fewer bad examples to follow! Thanks! Frank -- 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
Re: BLOCK CONTAINS
Perhaps this explains the observed action? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/5.2.4 quote BLOCK CONTAINS 0 can be specified for QSAM files. If BLOCK CONTAINS 0 is specified for a QSAM file, then: * The block size is determined at run time from the DD parameters or the data set label. If the RECORD CONTAINS 0 CHARACTERS clause is specified and the BLOCK CONTAINS 0 CHARACTERS clause is specified (or omitted), the block size is determined at run time from the DD parameters or the data set label of the file. For output data sets, with either of the above conditions, the DCB used by Language Environment will have a zero block size value. If you do not specify a block size value, the operating system might select a system-determined block size (SDB). See the operating system specifications for further information about SDB. /quote -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: BLOCK CONTAINS
On Fri, 15 May 2009 15:28:37 +0200, Gilbert Saint-Flour usenet5...@yahoo.com wrote: On Friday 15 May 2009 02:05, Frank Swarbrick wrote: We are migrating from VSE to z/OS, and at the same time we are going to convert most of our existing ESDS files to regular sequential files. I see no reason to add BLOCK CONTAINS 0 to all of our FD's if it has no affect (our VSAM FD's do not (generally!) specify the BLOCK CONTAINS clause, because it has no meaning to VSAM). IIRC, BLOCK CONTAINS 0 is only needed for OUTPUT files in COBOL, but I think it's better to put it everywhere, so programmers later don't have to remember where it's needed. What I'm getting at is that it appears to not even be required for OUTPUT files *as long as that information can be determined by other means*. In 1991, I started to convert VSE applications to MVS/ESA and stopped to generate DCB attributes on DD statements, except for output files in IDCAMS REPRO and QUIKJOB programs, and a few others ones. A few years later, I started to convert IDCAMS REPRO to something else, for several advantages, among them not having to specify DCB info in the JCL. I'm convinced that coding DCB attributes on DD statements is something almost always useless and archaic. This is something all my customers agreed with, except an outsourcing company that absolutely had to have DCB information on all output DD statements, like this: DCB=(RECFM=xx,LRECL=yy,BLKSIZE=zzz). This was in 2007 ! In z/OS ! I agree that DCB et al is generally not needed. The exceptions being 1) if IEFBR14 is being used to create the file. 2) if a Cobol program is being used to create the file and one wants a blocked file but did not specify a BLOCK CONTAINS statement. It's this latter one that is my only cause for concern. We'd have to use RECFM and BLKSIZE statements if we wanted to override Cobol's default of non-blocked. Probably in the end we'll probably decide to include BLOCK CONTAINS 0 for all non-VSAM sequential files. It just bugs me that I have to do that when 95% of the time it's meaningless, because it's overriden by information retrieved elsewhere. See examples here: http://gsf-soft.com/Prism-CS/Samples.shtml and you won't see many DD statements that contain DCB info. This is very similar to what I generated since 1991. As for the conversion of ESDS files to non-VSAM in COBOL programs, changing AS-filename to S-ddname is not always the only thing you need to do. Trust me ! Now you have me curious. What other gotchas do you think we might run in to? We already use FILE STATUS for file I/O error checking, so that should not be a problem. We have SELECT OPTIONAL for the cases where we want to be able to open for input an empty VSAM file. This does not (thank god!) appear to be an issue for SAM files, but leaving OPTIONAL does not appear to hurt either. I have not decided yet if we'll keep or remove the OPTIONAL clause. Probably remove it, since it has no meaning for SAM, but... To be honest, I was personally against migrating our ESDS files to SAM. I thought why take the chance? The one thing that has convinced me is the fact that we have quite a few cases in VSE where we sort several ESDS files together in to a single ESDS output file. DFSORT on z/OS does not allow this! Thus we have to use sequential files at least as intermediate files, so we figured we'd just convert almost all of them (we'll leave the ones defined to CICS as ESDS). Additionally we will want to use GDGs and I've been told (though I have not researched it) that you can't have GDG ESDS files. There may be other reasons, but I can't recall what they are at the moment... Frank -- 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
Re: BLOCK CONTAINS
On Fri, 15 May 2009 10:34:31 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Friday, May 15, 2009 9:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote: Welcome to the MVS world. In the MVS world, we are not device dependant, nor are we data definition locked/blocked. We generally don't have to recompile our programs, change the DTF contents (DCB in MVS), etc. just because the file attributes change (xSAM to VSAM is the exception). Huh??? If we are not device dependant, why is there such intense trepidation and resistance to the mere suggestion of a device with a novel geometry such as more bytes per track or more tracks per cylinder? It doesn't appear that you and I have been living in the same MVS world. SNIP In the VSE world, if you set up to read tape, you can not change your JCL to instead read Disk. A DTFSD (Define The File - Sequential Disk) can not be used to read a tape (DTFMT - Define The File - Magnetic Tape). If you did use the DTFDI (Define The File - Device Independent) it is only good for limited situations. I don't know what assembler stuff is done under the covers, but in Cobol for VSE/ESA (and VS COBOL II) you can use a single SELECT statement that will work with printers, tape files, sequential files and VSAM-managed SAM files. SELECT MY-FILE ASSIGN TO SYS005-MYFILE. Frank -- 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
Re: BLOCK CONTAINS
Frank Swarbrick wrote: [snip] On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: I have been a bit of experimenting with z/OS QSAM files from a Cobol program and I find that the manuals don't exactly agree with my results. The manuals seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or something else) then the file has a RECFM of either VB or FB. And if you don't include it then it's either V or B. We are not using a vendor. We have systems and applications programmers that come from the MVS world, so we're going with that expertise. Though I suppose the fact that I am asking these questions here might indicate that said expertise is perhaps not sufficient? Hmmm... [snip] Both VSE and z/OS require the AS- prefix in order for Cobol to distinguish between between a VSAM ESDS and a regular SAM file. Other than that, yes, only the last node has any meaning. Nonetheless our conversion program is going to remove all of the superfluous stuff. I have been trying to get my fellow programmers to cut out this information for years, but with little success. Hopefully this way people will have fewer bad examples to follow! Frank, I've been watching this thread evolve and I'd like to throw in some thoughts here. There was some change in behavior in COBOL + QSAM a few years ago, and the documentation never did, to my perception, do a good job of pointing this out. Here is an extract from one page in our course Enterprise COBOL Update I: Essentials: While not strictly a change to the language, there has been a change to the way OPEN works that is worthwhile knowing about * Historically, coding BLOCK CONTAINS ensured the value in your program would be used for block size * If you wanted to obtain the existing block size (for input files) or to set the blocksize in JCL (for output files) you coded BLOCK CONTAINS 0 RECORDS in your FD The new behavior is this: * Block size in the label overrides BLOCK CONTAINS value in the program * The implications are: + For input files, may now simply omit the BLOCK CONTAINS clause: it will be ignored / overridden + For output files, BLOCK CONTAINS 0 is required if DSORG, LRECL, and RECFM are not specified on the DD statement + BLOCK CONTAINS 0 is not necessary if you code DSORG, LRECL, and RECFM on the DD statement (the system will choose blocksize for you) -- [of course, if you pre-allocate the file using ISPF 3.2 or some other mechanism, existing label information will be used there, too.] -- Regarding your systems and applications programmers with MVS experience: COBOL has gone through extensive changes of late, and the experience of these people may be somewhat out of date. I really recommend the course mentioned above. It's only two days but it catches experienced programmers up to speed in terms of new features and approaches. The details are here: http://www.trainersfriend.com/COBOL_Courses/d704descr.htm As with all our course descriptions, this page has further links to more detail, especially note the links to the pages with more detailed course objectives and the very detailed topical outline. - Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- 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
Re: BLOCK CONTAINS
--snip What if a new device came out and there was a better optimum blocksize for it? Wouldn't you have to recompile everthing that used that file to get the optimum blocksize? I don't know I'm just asking. -unsnip No, you're not going to have to recompile everything. That's why BLOCK CONTAIN 0 RECORDS is so important. Let the OPEN/CLOSE and access method routines handle the differences under the covers and they'll manage just fine. :-) -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- 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
Re: BLOCK CONTAINS
On Fri, 15 May 2009 11:31:19 -0500, McKown, John jmck...@healthmarkets.com wrote: Perhaps this explains the observed action? http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/IGY3LR31/5.2.4 quote BLOCK CONTAINS 0 can be specified for QSAM files. If BLOCK CONTAINS 0 is specified for a QSAM file, then: * The block size is determined at run time from the DD parameters or the data set label. If the RECORD CONTAINS 0 CHARACTERS clause is specified and the BLOCK CONTAINS 0 CHARACTERS clause is specified (or omitted), the block size is determined at run time from the DD parameters or the data set label of the file. For output data sets, with either of the above conditions, the DCB used by Language Environment will have a zero block size value. If you do not specify a block size value, the operating system might select a system-determined block size (SDB). See the operating system specifications for further information about SDB. /quote That quote specifically refers to use of BLOCK CONTAINS 0. It does not seem to explain why the same results are seen if there is no BLOCK CONTAINS clause at all. ... Wait, it does say or omitted. So I guess this does explain it. This gives me one more reason to not have BLOCK CONTAINS 0. That as well as BLOCK CONTAINS can be omitted for SYSIN files and for SYSOUT files. The blocking is determined by the operating system. Though of course specifying BLOCK CONTAINS 0 there would not hurt. But again I don't like to have it there if it's just going to be ignored. Oy! Frank -- 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
Re: BLOCK CONTAINS
3) If Cobol says BLOCK CONTAINS 12345 it works (!!!) I'll bet you 3) If Cobol says BLOCK CONTAINS doesn't :) Dave Gibney Information Technology Services Washington State University -- 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
Re: BLOCK CONTAINS
On Fri, 15 May 2009 10:53:52 -0600, Steve Comstock st...@trainersfriend.com wrote: I've been watching this thread evolve and I'd like to throw in some thoughts here. There was some change in behavior in COBOL + QSAM a few years ago, and the documentation never did, to my perception, do a good job of pointing this out. Here is an extract from one page in our course Enterprise COBOL Update I: Essentials: While not strictly a change to the language, there has been a change to the way OPEN works that is worthwhile knowing about * Historically, coding BLOCK CONTAINS ensured the value in your program would be used for block size * If you wanted to obtain the existing block size (for input files) or to set the blocksize in JCL (for output files) you coded BLOCK CONTAINS 0 RECORDS in your FD The new behavior is this: * Block size in the label overrides BLOCK CONTAINS value in the program * The implications are: + For input files, may now simply omit the BLOCK CONTAINS clause: it will be ignored / overridden + For output files, BLOCK CONTAINS 0 is required if DSORG, LRECL, and RECFM are not specified on the DD statement + BLOCK CONTAINS 0 is not necessary if you code DSORG, LRECL, and RECFM on the DD statement (the system will choose blocksize for you) -- [of course, if you pre-allocate the file using ISPF 3.2 or some other mechanism, existing label information will be used there, too.] -- You are the man, Steve! I think that almost totally covers it. What I would add is something specifically addressing the pre-existing file issue that you mention in your epilog above. I would word it this way * The implications are: + For input files, may now simply omit the BLOCK CONTAINS clause: it will be ignored / overridden + For output files, BLOCK CONTAINS 0 is only if 1) the file is not already defined and 2) RECFM and BLKSIZE are not specified on the DD statement. + in all other cases BLOCK CONTAINS 0 is ignored / overridden I don't, however, thing that the following is strictly true. + BLOCK CONTAINS 0 is not necessary if you code DSORG, LRECL, and RECFM on the DD statement (the system will choose blocksize for you) Well, it is true in that it is not necessary to have BLOCK CONTAINS 0. However if it is not present it appears to behave as if BLOCK CONTAINS 1 was specified, unless there is also an explicit BLKSIZE on the DD. Regarding your systems and applications programmers with MVS experience: COBOL has gone through extensive changes of late, and the experience of these people may be somewhat out of date. I really recommend the course mentioned above. It's only two days but it catches experienced programmers up to speed in terms of new features and approaches. If it were my decision I would do it. Let me see if I can convince TPTB. Only a few of us are working on the z/OS project right now. Would you think that those few should get this education now and do the rest when we are closer to cutover? I worry about cost (having the class twice), but we're doing that in other situations, so I guess we could do that here as well. (Probably makes sense to respond to me directly at frank.swarbr...@efirstbank.com.) Thanks again Steve!! Frank -- 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
VSE I/O Performance VS MVS [was BLOCK CONTAINS]
Because of past conversions, I think this needs to be said: 1) VSE/ESA got to use XA I/O just like MVS. This means, to the VSE shop, that some slick stuff that got offloaded to the I/O Subsystem (shall we say parts of VM's and MVS' I/O Supervisor code) became available w/o any JCL or application coding changes. Things like dual (or multi) pathing with dynamic pathing. What does this have to do with anything? Well, the typical throughput performance gains seen in the past when going from VSE to MVS don't happen because what was giving those (for the most part) has already been realized. 2) VSAM is implemented in VSE differently than in MVS. So, the way sharing and buffer management is done changes and WILL cause performance issues when you get to MVS. 3) CICS is impacted by these changes, and you may see less throughput. Although, with the ability to have more storage than z/VSE allows, you may over come it. But be sure to have sufficient page volumes. Bottom line: To get the same or better performance from a well tuned VSE shop that goes to MVS, you will need people who are well versed in all the tricks. And they will need to understand what was happening on the VSE system to effect similar results on the MVS system. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- 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
Re: BLOCK CONTAINS
On Fri, 15 May 2009 10:05:48 -0700, Gibney, Dave gib...@wsu.edu wrote: 3) If Cobol says BLOCK CONTAINS 12345 it works (!!!) I'll bet you 3) If Cobol says BLOCK CONTAINS doesn't :) Sorry, you lose that bet. That does work. The only things that I've been able to determine simple do not work are if you specify a block size that 1) for RECFM=VB is not either 0 or at least 8 bytes more than the maximum record length, or 2) for RECFM=FB is not either 0 or a multiple of the record length. If you violate item 1 you get this: IGYGR1243-S FILE MY-FILE HAD A RECORDING MODE OF V, BUT THE BLOCK SIZE WAS LESS THAN 8 PLUS THE MAXIMUM RECORD SIZE OF 500. THE FILE DEFINITION WAS DISCARDED. If you violate item 2 you get this: IGYGR1212-W THE MAXIMUM INTEGER IN THE BLOCK CONTAINS CLAUSE WAS NOT A MULTIPLE OF THE CALCULATED RECORD SIZE. THE CLAUSE WAS ACCEPTED. If you ignore the warning for number 2 you get an IEC141I 013-20. For number 1 we get RC 4 so we don't even try to create the load module, much less run it! :-) Frank -- 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
Re: BLOCK CONTAINS
By fail, I would have expected you to get an I/O error reading an existing file where the COBOL BLOCK CONTAINS is less. But, now I think about it, recent DFP, like somewhere in the last coupe decades (Probably around os390 1.4 or 2.5 for us) OPEN got smarter and handles unlike block sizes much better. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Friday, May 15, 2009 11:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS On Fri, 15 May 2009 10:05:48 -0700, Gibney, Dave gib...@wsu.edu wrote: 3) If Cobol says BLOCK CONTAINS 12345 it works (!!!) I'll bet you 3) If Cobol says BLOCK CONTAINS doesn't :) Sorry, you lose that bet. That does work. The only things that I've been able to determine simple do not work are if you specify a block size that 1) for RECFM=VB is not either 0 or at least 8 bytes more than the maximum record length, or 2) for RECFM=FB is not either 0 or a multiple of the record length. If you violate item 1 you get this: IGYGR1243-S FILE MY-FILE HAD A RECORDING MODE OF V, BUT THE BLOCK SIZE WAS LESS THAN 8 PLUS THE MAXIMUM RECORD SIZE OF 500. THE FILE DEFINITION WAS DISCARDED. If you violate item 2 you get this: IGYGR1212-W THE MAXIMUM INTEGER IN THE BLOCK CONTAINS CLAUSE WAS NOT A MULTIPLE OF THE CALCULATED RECORD SIZE. THE CLAUSE WAS ACCEPTED. If you ignore the warning for number 2 you get an IEC141I 013-20. For number 1 we get RC 4 so we don't even try to create the load module, much less run it! :-) Frank -- 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 -- 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
Re: VSE I/O Performance VS MVS [was BLOCK CONTAINS]
On Fri, 15 May 2009 14:09:33 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: Because of past conversions, I think this needs to be said: 1) VSE/ESA got to use XA I/O just like MVS. This means, to the VSE shop, that some slick stuff that got offloaded to the I/O Subsystem (shall we say parts of VM's and MVS' I/O Supervisor code) became available w/o any JCL or application coding changes. Things like dual (or multi) pathing with dynamic pathing. What does this have to do with anything? Well, the typical throughput performance gains seen in the past when going from VSE to MVS don't happen because what was giving those (for the most part) has already been realized. 2) VSAM is implemented in VSE differently than in MVS. So, the way sharing and buffer management is done changes and WILL cause performance issues when you get to MVS. 3) CICS is impacted by these changes, and you may see less throughput. Although, with the ability to have more storage than z/VSE allows, you may over come it. But be sure to have sufficient page volumes. Are you saying the MVS VSAM is less efficient then VSE VSAM? Hmmm! One might start to wonder why we are migrating at all! :-) Thanks for the info. I will pass it on to our systems programmers (who hopefully already know what you are talking about anyway, but it couldn't hurt). Frank -- 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
Re: VSE I/O Performance VS MVS [was BLOCK CONTAINS]
Frank, I suggest you download the Redbook, VSAM De-Mystified. It will answer your questions concerning VSAM performance. As my instructor told the class years ago - Don't take the defaults! Specify CI sizes that give the best space utilization for your record size. Choose a large enough Index CI Size to avoid 'dead areas' in your data component. Specify a robust value for your Bufferspace parameter, in most cases the larger the better. (I'm sure someone will volunteer a 'war story' where this wasn't the case but generally a large buffer space improves throughput.) For batch processing look into BLSR. For CICS use LSRpools, again be generous. The more data stored in memory the fewer physical I/O. HTH, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick [fswarbr...@gmail.com] Sent: Friday, May 15, 2009 6:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: VSE I/O Performance VS MVS [was BLOCK CONTAINS] On Fri, 15 May 2009 14:09:33 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: Because of past conversions, I think this needs to be said: 1) VSE/ESA got to use XA I/O just like MVS. This means, to the VSE shop, that some slick stuff that got offloaded to the I/O Subsystem (shall we say parts of VM's and MVS' I/O Supervisor code) became available w/o any JCL or application coding changes. Things like dual (or multi) pathing with dynamic pathing. What does this have to do with anything? Well, the typical throughput performance gains seen in the past when going from VSE to MVS don't happen because what was giving those (for the most part) has already been realized. 2) VSAM is implemented in VSE differently than in MVS. So, the way sharing and buffer management is done changes and WILL cause performance issues when you get to MVS. 3) CICS is impacted by these changes, and you may see less throughput. Although, with the ability to have more storage than z/VSE allows, you may over come it. But be sure to have sufficient page volumes. Are you saying the MVS VSAM is less efficient then VSE VSAM? Hmmm! One might start to wonder why we are migrating at all! :-) Thanks for the info. I will pass it on to our systems programmers (who hopefully already know what you are talking about anyway, but it couldn't hurt). Frank -- 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 -- 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
Re: BLOCK CONTAINS
On 15 May 2009 09:32:23 -0700, in bit.listserv.ibm-main you wrote: Perhaps this explains the observed action? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/5.2.4 quote BLOCK CONTAINS 0 can be specified for QSAM files. If BLOCK CONTAINS 0 is specified for a QSAM file, then: * The block size is determined at run time from the DD parameters or the data set label. If the RECORD CONTAINS 0 CHARACTERS clause is specified and the BLOCK CONTAINS 0 CHARACTERS clause is specified (or omitted), the block size is determined at run time from the DD parameters or the data set label of the file. For output data sets, with either of the above conditions, the DCB used by Language Environment will have a zero block size value. If you do not specify a block size value, the operating system might select a system-determined block size (SDB). See the operating system specifications for further information about SDB. /quote I checked the reference you gave and for QSAM files, if the BLOCK CONTAINS clause is omitted, BLOCK 1 RECORD is assumed. This stupidity has aggravated me for years. -- 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
Re: VSE I/O Performance VS MVS [was BLOCK CONTAINS]
--- On Fri, 5/15/09, Frank Swarbrick fswarbr...@gmail.com wrote: SNIP-- What does this have to do with anything? Well, the typical throughput performance gains seen in the past when going from VSE to MVS don't happen because what was giving those (for the most part) has already been realized. SNIP OK I will be the first to admit it but I have not seen DOS in 40(?) years. So if DOS has improved I would be very surprised (as far as I/O improvements). Did DOS finally as a default support 5 I/O buffers on QSAM? I remember when SAM-e came out for MVS in the '70's) and it made a HUGE impact on I/O and all for the good (mind you). My vague memory of DOS was a DTFxx and you had to specify the 1st and 2nd IOareas and that was needed (IIRC) just to get two buffers. In MVS when we added SAM-e we saw a *SIGNIFICANT* improvement in job elapsed time. Like I said it was 30+ years ago my memory says it decreased run time by 50% to 66% typically and of course some were less and some where more so I do not want to say average but it was in the area of 50-66 percent. I distinctly remember getting a call from production support at something in the morning says something was wrong as jobs were running way to fast. I assured them it was a performance enhancement and they would see most jobs running a lot faster. Fast forward 5 years in the 80's Change of job. We brought up MVS and were running VS1 and jobs were running so fast the operator could not keep up with the manual log he had. Again same call from production support(different company) as production got done at 630AM normally on VS1 and on MVS (with SAMe) they were done at 430AM. The only thing the operators didn't like was that tape drive selection was set at random so they couldn't premount tapes. In VS1 (IIRC) the lowest tape drive address was always 380 and the drive was getting beat up on and failing more often. The CE (customer Engineer) was ecstatic as he wasn't fixing the same tape drive all the time. IIRC SAMe was $15 a month charge option then. After a while practically every flavor of MVS that was being shipped was ordered with SAMe and it became standard (don't ask me what year). The bottom line is the MVS had SAMe and I do not recall it ever being offered in DOS (pick your flavor), are you suggesting that it was, if so how? The DOS I was used to (granted old) would never have allowed it. Ed -- 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
BLOCK CONTAINS
I have been a bit of experimenting with z/OS QSAM files from a Cobol program and I find that the manuals don't exactly agree with my results. The manuals seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or something else) then the file has a RECFM of either VB or FB. And if you don't include it then it's either V or B. However, I have been able to read and write to a RECFM=VB file with a Cobol program that does not have the BLOCK CONTAINS clause. Additionally, I can read a RECFM=V file with a Cobol program that *does* have a BLOCK CONTAINS clause. I also can read and write files where BLOCK CONTAINS is specified (non-zero) but does not match the actual block size of the file. It just does not appear to matter. It seems to me that the RECFM and BLKSIZE information that is specified on the DD or in the catalog overrides whatever you tell Cobol anyway, so it seems to not matter what you tell Cobol. Basically (and I know this is something so small that you'd wonder why I even care) I can't see any reason to ever specify the BLOCK CONTAINS clause. If the file is already cataloged I definitely don't need it. And even if I want to create a new VB or FB file I can just put the RECFM option on the DD. One thing I haven't checked is if tapes will cause me any problems. But our applications all backup to disk files instead of tape, so I'm not really concerned. If you do wonder why I care, it's this... We are migrating from VSE to z/OS, and at the same time we are going to convert most of our existing ESDS files to regular sequential files. I see no reason to add BLOCK CONTAINS 0 to all of our FD's if it has no affect (our VSAM FD's do not (generally!) specify the BLOCK CONTAINS clause, because it has no meaning to VSAM). (Yes, I do know we need to remove the AS- prefix from the ASSIGN clause of the SELECT statement.) Thanks! Frank -- 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
Re: BLOCK CONTAINS
On 14 May 2009 17:05:53 -0700, in bit.listserv.ibm-main you wrote: I have been a bit of experimenting with z/OS QSAM files from a Cobol program and I find that the manuals don't exactly agree with my results. The manuals seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or something else) then the file has a RECFM of either VB or FB. And if you don't include it then it's either V or B. While blocked input files may be read successfully if neither the block size nor BLOCK 0 is specified provided record descriptions match, lack of BLOCK CONTAINS causes the default blocksize on output to be ONE record. I believe I submitted a SHARE requirement back in the 1990's to have a compile option that the default be BLOCK 0. Either is a perfectly valid default according to the COBOL standard. BLOCK would be the default consistent with VSAM handling. The whole issue is a sore point with me and possibly others. Incidentally be careful to specify BLKSIZE=0 on the DD statements of output files from sorts that sort or copy VSAM files. Unless things have changed from 1998, SYNCSORT defaulted to one record per block. Coding RECFM=FB or RECFM=VB also might have forced the output to be blocked. Subtle gotchas lurk. I know having been bitten. However, I have been able to read and write to a RECFM=VB file with a Cobol program that does not have the BLOCK CONTAINS clause. Additionally, I can read a RECFM=V file with a Cobol program that *does* have a BLOCK CONTAINS clause. I also can read and write files where BLOCK CONTAINS is specified (non-zero) but does not match the actual block size of the file. It just does not appear to matter. It seems to me that the RECFM and BLKSIZE information that is specified on the DD or in the catalog overrides whatever you tell Cobol anyway, so it seems to not matter what you tell Cobol. Basically (and I know this is something so small that you'd wonder why I even care) I can't see any reason to ever specify the BLOCK CONTAINS clause. If the file is already cataloged I definitely don't need it. And even if I want to create a new VB or FB file I can just put the RECFM option on the DD. One thing I haven't checked is if tapes will cause me any problems. But our applications all backup to disk files instead of tape, so I'm not really concerned. If you do wonder why I care, it's this... We are migrating from VSE to z/OS, and at the same time we are going to convert most of our existing ESDS files to regular sequential files. I see no reason to add BLOCK CONTAINS 0 to all of our FD's if it has no affect (our VSAM FD's do not (generally!) specify the BLOCK CONTAINS clause, because it has no meaning to VSAM). (Yes, I do know we need to remove the AS- prefix from the ASSIGN clause of the SELECT statement.) Thanks! Frank -- 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
