Re: S013-64-IEBGENER
--- On Sun, 10/17/10, Ted MacNEIL eamacn...@yahoo.ca wrote: From: Ted MacNEIL eamacn...@yahoo.ca Subject: Re: S013-64-IEBGENER To: IBM-MAIN@bama.ua.edu Date: Sunday, October 17, 2010, 12:13 PM escalate? By whom? Via what channel? Rarely should tech support inform the reporting programmers' management of perceived unwise programming techniques. Not necessarity programming techniques, but use of system resources can be more expensive than they should be (eg: poor blocking, especially on tape). That's an interface issue, rather than a programming issue. And, as a performance/capacity analyst, I have participated in many optimisation efforts, with recommendations that have changed programming. - Ted: A LONG time ago and far far away the programming VP asked me to look into ways (cheap) of saving CPU time so the nightly batch system would run faster. I had been peeking around here and there for other reasons so I said why not. I developed 5 or 6 programs that I would run daily to see who wasn't blocking their data and gross CPU consumption and over abundance of tape drive usage (and a few other items that I have long time forgotten). I would send him a copy of the PIG report that became known company wide.I did not put names to programmers but they were easily found so while not naming people I did attach an USERID . The VP was absolutely delighted and in his daily staff meeting with the supervisors he would hand copies out. The report became so well known I was asked by the data center manager to send him a copy as well. There was no doubt about it programmers were lazy people. I forced an issue about not using block contains 1 record and came up with a simple report showing those and simply by reblocking (recompile with one statement chamged) got us back 3.5 percent cpu time (this was 20-25 jobs) . We were really running flat out and desperatly needed a faster system. The small gain allowed us to stave off a upgrade for about 6 months. It was a difficult environment and difficult to explain on here but the jist of it we (the company) were paid on each trade that was cleared. Traders tended to be cheap so any extra money we got was hard fought for. -- 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: S013-64-IEBGENER
On Fri, 15 Oct 2010 10:46:44 -0500, Larry Macioce wrote: Do know why it would fail all the sudden, but my question is why are you defining a dummy dataset? Why not use a br14 or like(if you have another exact dataset) ? Perhaps the OP perceived a need (possibly based on outdated information) to write an EOF at the beginning of a new data set. Recommending superior techniques is appropriate in this forum. Tech support, however, has a different responsibility: to analyze and repair any reported defect, and never to question the users' choice of method, regardless of however inefficient or bizarre. -- 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: S013-64-IEBGENER
Tech support, however, has a different responsibility: to analyze and repair any reported defect, and never to question the users' choice of method, regardless of however inefficient or bizarre. I disagree to some extent. If a user is doing something inefficient, tech support has an obligation to point out alternatives, and, if serious enough, to escalate. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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: S013-64-IEBGENER
On Sun, 17 Oct 2010 15:56:36 +, Ted MacNEIL wrote: Tech support, however, has a different responsibility: to analyze and repair any reported defect, and never to question the users' choice of method, regardless of however inefficient or bizarre. I disagree to some extent. If a user is doing something inefficient, tech support has an obligation to point out alternatives, and, if serious enough, to escalate. I agree to some extent. But it should always remain the customers' prerogative to insist that the defect be addressed. escalate? By whom? Via what channel? Rarely should tech support inform the reporting programmers' management of perceived unwise programming techniques. Too often I have distilled the scenario that exposes a defect to a minimal test case, only to have tech support react, Your program appears to do nothing useful; why don't you omit [the statement that precipitates the failure] since its output appears never to be used. The OP appears to have submitted such an abbreviated example. -- 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: S013-64-IEBGENER
escalate? By whom? Via what channel? Rarely should tech support inform the reporting programmers' management of perceived unwise programming techniques. Not necessarity programming techniques, but use of system resources can be more expensive than they should be (eg: poor blocking, especially on tape). That's an interface issue, rather than a programming issue. And, as a performance/capacity analyst, I have participated in many optimisation efforts, with recommendations that have changed programming. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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: S013-64-IEBGENER
On Sun, 2010-10-17 at 10:11 -0500, Paul Gilmartin wrote: On Fri, 15 Oct 2010 10:46:44 -0500, Larry Macioce wrote: Do know why it would fail all the sudden, but my question is why are you defining a dummy dataset? Why not use a br14 or like(if you have another exact dataset) ? Perhaps the OP perceived a need (possibly based on outdated information) to write an EOF at the beginning of a new data set. Recommending superior techniques is appropriate in this forum. Tech support, however, has a different responsibility: to analyze and repair any reported defect, and never to question the users' choice of method, regardless of however inefficient or bizarre. -- gil Do you mean IBN's Tech Support, or a company's? I ask because one of my duties in Tech Support is to question why something is done that way. And suggest / recommend possible, more efficient, alternatives. -- John McKown Maranatha! -- 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: S013-64-IEBGENER
On Fri, Oct 15, 2010 at 10:46 AM, Larry Macioce mace1...@gmail.com wrote: [deleted], but my question is why are you defining a dummy dataset? Why not use a br14 or like(if you have another exact dataset) ? Mace It actually opens and closes the dataset, forceing a complete definition of the dataset. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: S013-64-IEBGENER
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mike Schwab Sent: Friday, October 15, 2010 10:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: S013-64-IEBGENER On Fri, Oct 15, 2010 at 10:46 AM, Larry Macioce mace1...@gmail.com wrote: [deleted], but my question is why are you defining a dummy dataset? Why not use a br14 or like(if you have another exact dataset) ? Mace It actually opens and closes the dataset, forceing a complete definition of the dataset. -- Mike A Schwab, Springfield IL USA SMS now does that if you include an appropriate DSORG. So the following __should__ work: //ALLOC DD PGM=IEFBR14 //NEWDSN DD DISP=(NEW,CATLG),DSN=new.dsn, // LIKE=old.dsn It should be allocated with identical DCB attributes and size. If a PDS, it gets the same number of directory blocks. If a PS, it has an EOF written at the start of the dataset. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-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: S013-64-IEBGENER
Mace Something has been inplace since...before I was here.. Having them change to br14 when error occurs..but have many to go through..other alternative is to run on other lpar...since most runs are at night and no one around to alter jcl. From: Larry Macioce mace1...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 10/15/2010 10:46 AM Subject:Re: S013-64-IEBGENER Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Do know why it would fail all the sudden, but my question is why are you defining a dummy dataset? Why not use a br14 or like(if you have another exact dataset) ? Mace -- 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 -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files 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: S013-64-IEBGENER
Paul Did that and no word as yet from ibm. From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@bama.ua.edu Date: 10/15/2010 10:49 AM Subject:Re: S013-64-IEBGENER Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On Fri, 15 Oct 2010 08:24:13 -0500, Ron Wells wrote: Anyone run across where a IEBGENER fails with a S013-64 //SYSUT1 DD DUMMY, // DISP=SHR,LRECL=4096,RECFM=FB //SYSUT2 DD DSN=XX15.TEST.DATA.SET, // DISP=(NEW,CATLG,DELETE), //UNIT=DASD, //SPACE=(15000,15000) If RECFM changed to F it works...problem is this job has run for ?? Just now failing z/os 1.11 but have been on this rel for 4mon.. MC sez: 64 An OPEN macro instruction was issued for a dummy data set using an access method other than QSAM or BSAM. Correct the DD statement to specify a real data set, or access the data set using BSAM or QSAM. ??? What access method other than QSAM or BSAM would IEBGENER use? Ever. PMR time? -- 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 -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files 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: S013-64-IEBGENER
Do know why it would fail all the sudden, but my question is why are you defining a dummy dataset? Why not use a br14 or like(if you have another exact dataset) ? Mace -- 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: S013-64-IEBGENER
On Fri, 15 Oct 2010 08:24:13 -0500, Ron Wells wrote: Anyone run across where a IEBGENER fails with a S013-64 //SYSUT1 DD DUMMY, // DISP=SHR,LRECL=4096,RECFM=FB //SYSUT2 DD DSN=XX15.TEST.DATA.SET, // DISP=(NEW,CATLG,DELETE), //UNIT=DASD, //SPACE=(15000,15000) If RECFM changed to F it works...problem is this job has run for ?? Just now failing z/os 1.11 but have been on this rel for 4mon.. MC sez: 64 An OPEN macro instruction was issued for a dummy data set using an access method other than QSAM or BSAM. Correct the DD statement to specify a real data set, or access the data set using BSAM or QSAM. ??? What access method other than QSAM or BSAM would IEBGENER use? Ever. PMR time? -- 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: S013-64-IEBGENER
Maybe BPAM while doing a FIND or BLDL? E.g., //INPUT DD DSN=MY.PDS(MEMBER),..etc. Just a guess. I never traced it with GTF, so I don't know for sure. Or maybe at the instant of OPEN the DCB access method bits were all zeroes. Or maybe since only SAM is supported the message is simply misleading. Bill Fairchild Rocket Software -Original Message- From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@bama.ua.edu Date: 10/15/2010 10:49 AM Subject:Re: S013-64-IEBGENER Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu What access method other than QSAM or BSAM would IEBGENER use? Ever. -- 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: S013-64-IEBGENER
Just for SGs ran it on my 1.6 system(still havent got 1.9 up), and it worked fine. I think as someone said before PMR time mace -- 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: S013-64-IEBGENER
On 10/15/2010 10:49 AM, Paul Gilmartin wrote: On Fri, 15 Oct 2010 08:24:13 -0500, Ron Wells wrote: Anyone run across where a IEBGENER fails with a S013-64 //SYSUT1 DD DUMMY, // DISP=SHR,LRECL=4096,RECFM=FB //SYSUT2 DD DSN=XX15.TEST.DATA.SET, // DISP=(NEW,CATLG,DELETE), //UNIT=DASD, //SPACE=(15000,15000) If RECFM changed to F it works...problem is this job has run for ?? Just now failing z/os 1.11 but have been on this rel for 4mon.. MC sez: 64 An OPEN macro instruction was issued for a dummy data set using an access method other than QSAM or BSAM. Correct the DD statement to specify a real data set, or access the data set using BSAM or QSAM. ??? What access method other than QSAM or BSAM would IEBGENER use? Ever. PMR time? -- gil Could this be running some IEBGENER replacement like ICEGENER, SYNCGENR (SP?), or some such that isn't handling DUMMY correctly. -- Richard -- 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: S013-64-IEBGENER
Richard Thought that too...and yesbut then--just to verify I steplib'd to where original IEBGENER was located...failed again.. From: Richard L Peurifoy r-peuri...@neo.tamu.edu To: IBM-MAIN@bama.ua.edu Date: 10/15/2010 01:26 PM Subject:Re: S013-64-IEBGENER Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On 10/15/2010 10:49 AM, Paul Gilmartin wrote: On Fri, 15 Oct 2010 08:24:13 -0500, Ron Wells wrote: Anyone run across where a IEBGENER fails with a S013-64 //SYSUT1 DD DUMMY, // DISP=SHR,LRECL=4096,RECFM=FB //SYSUT2 DD DSN=XX15.TEST.DATA.SET, // DISP=(NEW,CATLG,DELETE), //UNIT=DASD, //SPACE=(15000,15000) If RECFM changed to F it works...problem is this job has run for ?? Just now failing z/os 1.11 but have been on this rel for 4mon.. MC sez: 64 An OPEN macro instruction was issued for a dummy data set using an access method other than QSAM or BSAM. Correct the DD statement to specify a real data set, or access the data set using BSAM or QSAM. ??? What access method other than QSAM or BSAM would IEBGENER use? Ever. PMR time? -- gil Could this be running some IEBGENER replacement like ICEGENER, SYNCGENR (SP?), or some such that isn't handling DUMMY correctly. -- Richard -- 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 -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files 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
