Re: Deleting Cluster Using IEFBR14 or IDCAMS
In da2b203b-f8f5-439d-a16e-2a338b033...@comcast.net, on 09/17/2014 at 11:03 PM, Ed Gould edgould1...@comcast.net said: It was second nature to speak (with respect) back to people that had a higher rank. My section head would have roasted me had I found out that I knew he was making a mistake and didn't speak up. Part of respect is honesty, and he wouldn't have tolerated holding back critical information for the sake of politeness. Which is not to say that I sassed him; I wouldn't have done so even had I been able to get away with it. I was there on TDY and wanted to stay as long as I could; he was a good man to work for. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
In 37b5984c-5ec2-4fc2-a02b-70971e5b2...@comcast.net, on 09/16/2014 at 10:57 PM, Ed Gould edgould1...@comcast.net said: I guess you have to know an army type thats been in the service for over 10 years to understand the type. I worked for a WO[1] who knew where all the bodies were buried; he never would have done anything as stupid as what you described. For that matter, my company commander would have gotten rid of a top kick like yours. [1] Not somebody that I would care to cross, but I loved working for him; as long as the work got done, he bent over backwards to keep his people happy. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Sep 17, 2014, at 7:26 PM, Shmuel Metz (Seymour J.) wrote: ---snip I worked for a WO[1] who knew where all the bodies were buried; he never would have done anything as stupid as what you described. For that matter, my company commander would have gotten rid of a top kick like yours. My chain of command was Military civilians (like in GS ) they are the ones that taught me to stick up for myself . I guess they could get away with it with the military. They were the rulers and the military was there for the ride. we were a HQ company and we got away with a lot of things the rest of the members wouldn't dare. It was second nature to speak (with respect) back to people that had a higher rank. As I told one second Lt I have a job waiting for me when I get out that pays 5 times what I get out of here and I don't have to salute people straight to his face and walked away. (it helped that I sort of knew him). I had a Captain who tried to bring me up on charges 2 times and I had a solid excuse for each time. I even reported him the JAG for a poster he tore down and made him pay for it. I was sort of surprised that he ended up paying for it as I was hoping he would get court marshaled. I have several other items that I don't think this is the place to discuss them. Ed [1] Not somebody that I would care to cross, but I loved working for him; as long as the work got done, he bent over backwards to keep his people happy. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On 2014-09-16, at 02:32, R.S. wrote: Question: what is the proper purpose of IEFBR14? IMHO this is the only use of IEFBR14 by the users. OK, maybe some tricks with CONDs, but it's marginal. Somtimes because it's the only way to conditionally suppress execution of the first step in a job with COND or IF. BTW: troubles with IEFBR14 create/delete usually are clearly visible as JCL error or data set in use. Sometimes less clearly as NOT CATALOGUED 2. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Sep 16, 2014, at 6:05 AM, Elardus Engelbrecht wrote: Ed Gould wrote: The nightly production meeting was held and I had to get up and explain WTF had happened and how I fixed it. There was a grizzled old female first sergeant that didn't like my explanation as she knew everything. That old b*tch! Based on what did she made that statement? Qualification? Experience? Under-the-table-friendship with some CE? In the Army you weren't supposed to question (her) authority. I had the 2 PLM's and gave them to her and told her in no uncertain terms that she had better fight with IBM then. Everybody in the room was shocked when I stood up to her. Excellent. What happened then? Did IBM gave her a middle finger salute? That could be a good script for a horror movie! ;-) No... I had to go up two floors to the commanding officer and explain it to him, which I did, but I used nicer language :) Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, September 16, 2014 3:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting Cluster Using IEFBR14 or IDCAMS On 2014-09-16, at 02:32, R.S. wrote: BTW: troubles with IEFBR14 create/delete usually are clearly visible as JCL error or data set in use. Sometimes less clearly as NOT CATALOGUED 2. I HATE that one.(That it allocates it as non-catalogued. Can it happen anymore, BTW ? Was a long time ago...) Best Regards, Thomas Berg ___ Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Tue, 16 Sep 2014 16:22:06 +0200, Thomas Berg wrote: Sometimes less clearly as NOT CATALOGUED 2. I HATE that one.(That it allocates it as non-catalogued. Can it happen anymore, BTW ? Was a long time ago...) Non-SMS? I believe there's an option. PARMLIB? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
Ed Gould wrote: In the Army you weren't supposed to question (her) authority. Ops. No firing squad for you? ;-) No... I had to go up two floors to the commanding officer and explain it to him, which I did, but I used nicer language :) Ouch! I think most IBM-MAIN members would also use *nicer language* when explaining some difficult things. I remember your many rants about this and similar things about incompetent/useless management/colleagues/clients/etc... Good thing we can learn from you, please keep it up! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
In ea1e439b-1f07-415c-928f-367daa81e...@comcast.net, on 09/16/2014 at 05:17 AM, Ed Gould edgould1...@comcast.net said: I had to get up and explain WTF had happened and how I fixed it. Is that like explaining how to ride a bicycle. That is, did it take 20 times longer to explain than to do? There was a grizzled old female first sergeant that didn't like my explanation as she knew everything. Is that anything like the trainee that shoots himself with a rifle that he knows is unloaded? The first step to wisdom is to know what you don't know. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
In 7f788686-4633-42d3-813b-09a0abccb...@comcast.net, on 09/16/2014 at 08:46 AM, Ed Gould edgould1...@comcast.net said: On Sep 16, 2014, at 6:05 AM, Elardus Engelbrecht wrote: Ed Gould wrote: The nightly production meeting was held and I had to get up and explain WTF had happened and how I fixed it. There was a grizzled old female first sergeant that didn't like my explanation as she knew everything. That old b*tch! Based on what did she made that statement? Qualification? Experience? Under-the-table-friendship with some CE? In the Army you weren't supposed to question (her) authority. That depends on what you mean by authority. There is authority based on rank and authority based on role. Watch what happens when a 2nd Lt. pulls rank on a company clerk or first Sgt; the company commander will politely[1] ask him to stop sabotaging the smooth operation of his unit. A 1st sgt. that overrides a specialist in his area of expertise better know everything, or she will be in a world of hurt the first time that she gets it wrong. How did she reach that rank without learning that? [1] FSVO. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Sep 16, 2014, at 2:34 PM, Shmuel Metz (Seymour J.) wrote: In ea1e439b-1f07-415c-928f-367daa81e...@comcast.net, on 09/16/2014 at 05:17 AM, Ed Gould edgould1...@comcast.net said: I had to get up and explain WTF had happened and how I fixed it. Is that like explaining how to ride a bicycle. That is, did it take 20 times longer to explain than to do? I did not go into detail about how I came to figure out what the solution was. I shortened a 30 minute learning session (to me) into a 2 minute explanation as none of the audience (I know for a fact) had the slightest idea what a PLM was let alone what a CVOL was. When I was up explaining the issue the the commanding officer I dumbed it down even more (not that the CO was dumb) but he had no clue what JCL was let alone what a GDG was (you have to know the audience). BTW the JOB(s) updated a data base ( home grown) which had nothing to do with a GDG but it updated the DB that contained all the (sorry I am forgetting terms here) part numbers that the ARMY had in Europe (I know thats right but the nomenclature is just not there anymore after 30 years). There was a grizzled old female first sergeant that didn't like my explanation as she knew everything. Is that anything like the trainee that shoots himself with a rifle that he knows is unloaded? The first step to wisdom is to know what you don't know. I guess you have to know an army type thats been in the service for over 10 years to understand the type. For example its better than a civil servant, but not by much. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Sep 16, 2014, at 2:44 PM, Shmuel Metz (Seymour J.) wrote: In 7f788686-4633-42d3-813b-09a0abccb...@comcast.net, on 09/16/2014 at 08:46 AM, Ed Gould edgould1...@comcast.net said: On Sep 16, 2014, at 6:05 AM, Elardus Engelbrecht wrote: Ed Gould wrote: The nightly production meeting was held and I had to get up and explain WTF had happened and how I fixed it. There was a grizzled old female first sergeant that didn't like my explanation as she knew everything. That old b*tch! Based on what did she made that statement? Qualification? Experience? Under-the-table-friendship with some CE? In the Army you weren't supposed to question (her) authority. That depends on what you mean by authority. There is authority based on rank and authority based on role. Watch what happens when a 2nd Lt. pulls rank on a company clerk or first Sgt; the company commander will politely[1] ask him to stop sabotaging the smooth operation of his unit. A 1st sgt. that overrides a specialist in his area of expertise better know everything, or she will be in a world of hurt the first time that she gets it wrong. I was a lowly spec 5 and she (rumor had it she had been reduced in a rank a few times like all lifers) was a E-7 (sergeant - sorry don't remember her rank other than number. My boss was a GS-12 which if I recall correctly was equal to a lieutenant Colonel (or maybe a Major its been years) he trusted me to get up at meetings and explain myself and defend my actions. He was confident in me to the extent that he didn't show up in the meetings anymore and expected me to defend (or accuse) people, procedures etc that were either wrong or actions that I took and why. His boss was a GS-15 and we never talked. He expected that everyone that worked for him knew their job. How did she reach that rank without learning that? I was on a first name basis of several officers. when no one else was around we were friends but if anyone came around it was strictly business, yes sir! [1] FSVO. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
t...@harminc.net (Tony Harminc) wrote: On 2 September 2014 10:32, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: I use DSLIST, but I assume that invokes IDCAMS. (TSO DELETE also? I haven't tried that.) TSO DELETE has been an IDCAMS command since MVS 2.0; maybe even in SVS, a system I never used. My two comments (or cents) about this thread are: 1. IEFBR14, in addition to being the smallest program in z/OS as far as I know (and only one instruction longer than the smallest possible program), remains the most misused program in z/OS history in my view. Whether DD statements included in a IEFBR14 step are processed as you might wish or not does not affect the apparent success of step execution. IDCAMS, TSO/E (IJEFTxx), and other programs provide far more flexibility and tell you much more about what happened if things don't go as you expect. They also let you conditionally run steps based on success or lack thereof. Very few things require the use of JCL for data set allocation, and even fewer require it for data set deletion. 2. Tony indirectly makes a good point. At the risk of sounding more pedantic than usual, it's sometimes useful, even important, to differentiate between a TSO/E command processor (which can be supplied by anyone) and a TSO/E command, which is for all practical purposes a TSO/E command processor supplied by TSO/E itself. TSO/E command processors look, smell, and feel just like TSO/E commands, but are not necessarily part of TSO/E. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Mon, 15 Sep 2014 13:39:27 -0400, John Eells wrote: 1. IEFBR14, in addition to being the smallest program in z/OS as far as I know (and only one instruction longer than the smallest possible program), remains the most misused program in z/OS history in my view. Whether DD statements included in a IEFBR14 step are processed as you might wish or not does not affect the apparent success of step execution. PEDANTRY Sometimes. I'm certainly accustomed to seeing JCL ERROR -- DATA SET NOT FOUND. in some cases; other times not. /PEDANTRY ... IDCAMS, TSO/E (IJEFTxx), and other programs provide far more flexibility and tell you much more about what happened if things don't go as you expect. They also let you conditionally run steps based on success or lack thereof. Very few things require the use of JCL for data set allocation, and even fewer require it for data set deletion. Sometimes. Other times a utility converts an error message to what the author assumes is more familiar language, but others find it less precise. I lately ranted in MVS-OE about a vague filesystem error reported by cp(1). Looking at SYSLOG showed an ABEND SD37 trapped and obfuscated by cp. Probably the C RTL. Dammit! They could/should trap the message text and make that also available to the programmer's console. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
The utility in question is, of course, IEBEDIT. Shmuel is---of course again---a fixture here; and he once had the capacity to anger me and others. For me at least that time is past; his still combative but increasingly labored and jejune posts now inspire pity instead. This is only my personal view. It would be agreeable if others still found some at least of his posts relevant and helpful. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
In 8518961363687357.wa.paulgboulderaim@listserv.ua.edu, on 09/02/2014 at 12:39 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: (LISTSERV (or is it the sender's MUA?) does strange things to ampersands.) It's certainly not listserv; I'd guess that it's the web interface. This is an ampersand -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
In CAArMM9Q=gqqzxd-xcarolzr42p1ok9rvnuzkyv+7ywnsxxs...@mail.gmail.com, on 09/02/2014 at 03:00 PM, Tony Harminc t...@harminc.net said: TSO DELETE has been an IDCAMS command since MVS 2.0; maybe even in SVS, a system I never used. No; the DELETE command for SVS was the old OS/360 DELETE command at a higher service level; VSAM came is as an ICR for OS/VS1 and OS/VS2 R1 (SVS), so DELETE could not assume that IDCAMS was available. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
In cae1xxdeplywhcrs4hhkfftchbuo1ezsjgbj_8h8yrgiy9k8...@mail.gmail.com, on 09/02/2014 at 11:24 AM, John Gilmore jwgli...@gmail.com said: IBM provided a utility for reconstituting a job beginning with step n 1, No. Nor did one need such a utility. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
Christian D wrote: Is there a difference in using the utility IEFBR14 and IDCAMS in deleting VSAM cluster Dataset ? Absolutely! You use IDCAMS to manage VSAM datasets. IEFBR14 just simply 'does nothing'. I used to Delete the Cluster Before using IEFBR14 before but now it fails. Of course it will fail. //DEL EXEC PGM=IEFBR14 //TSDD DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,(0)), // DSN=CHRIS.TESTING.DB2.LL1 It is NOT IEFBR14 which caused the failure, but the system handling the DD statements. doesn't clear data set but raise IGD17105I CATALOG ERROR WHILE DELETING DATA SET 730 CHRIS.TESTING.DB2.LL1 RETURN CODE IS 84 REASON CODE IS 0 IGG0CLFK Of course, if you do something not supported, you will break things. The Deletion works well with IDCAMS but not with IEFBR14. This is WAD. Just use IDCAMS to manage your VSAM datasets and the catalogs. Now, you will have to examine the catalog(s) and the VTOC, VVDS, volsers to make sure you have not broken something. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
You may also have an IDC3009I message. If so, I would check those codes as well. Just a guess, that the IDCAMS handles VSAM better than IEFBR14. IDCAMS is code that works with the VSAM environment better. IEFBR14 is a do nothing program. So may not support this process. CAXWA count of active users has reached 32767, the maximum allowed. Programmer Response: Do not use the catalog until one of the current jobs allocated to it ends or logs off. You may want to open an SR with IBM. This may be a bug with either prior z/OS release, or v2.1. Try this command and see what CAXWA looks like F CATALOG,REPORT,PERFORMANCE Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Christian D Sent: Tuesday, September 02, 2014 6:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Deleting Cluster Using IEFBR14 or IDCAMS Hi Group, Is there a difference in using the utility IEFBR14 and IDCAMS in deleting VSAM cluster Dataset ? I used to Delete the Cluster Before using IEFBR14 before but now it fails. //DEL EXEC PGM=IEFBR14 //TSDD DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,(0)), // DSN=CHRIS.TESTING.DB2.LL1 doesn't clear data set but raise IGD17105I CATALOG ERROR WHILE DELETING DATA SET 730 CHRIS.TESTING.DB2.LL1 RETURN CODE IS 84 REASON CODE IS 0 IGG0CLFK Explanation from Manual : 84 Explanation: CAXWA count of active users has reached 32767, the maximum allowed. The Deletion works well with IDCAMS but not with IEFBR14. Z/OS : 2.1 Chris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
This message is less informative that it should be. The value +32767 is of course the [decimal] capacity of a signed binary halfword, and what we notionally have here is an instance of control-block field overflow; but I suspect that this message is an artefact of the use of IEFBR14---As Elardus has already pointed out, it does nothing itself and wots not of VSAM---to trigger the deletion of a VSAM dataset identified in a JCL DD statement. Use IDCAMS instead! John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Tue, Sep 2, 2014 at 9:09 AM, John Gilmore jwgli...@gmail.com wrote: This message is less informative that it should be. The value +32767 is of course the [decimal] capacity of a signed binary halfword, and what we notionally have here is an instance of control-block field overflow; but I suspect that this message is an artefact of the use of IEFBR14---As Elardus has already pointed out, it does nothing itself and wots not of VSAM---to trigger the deletion of a VSAM dataset identified in a JCL DD statement. Use IDCAMS instead! John Gilmore, Ashland, MA 01721 - USA I can only think of two reason people still use IEFBR14 in this manner. The first is that it predates the existence of IDCAMS. And so inertia has set in. The other reason is that by being in JCL, the DSN, or portion, can be a symbolic parameter. We use something like this in our JCL procedures so that a single PROC can be used for Test, Model Office, or Production just by something like: //JS010 EXEC PROC=PRODPROC,NODE=T (or M or P). And then have: //SOMEDD DD DISP=SHR,DSN=aaaNODE..REST.OF.NAME This can be emulated, with difficulty, with a PROC similar to //DELIT PROC NODE=T //DELIT EXEC PGM=IKJEFT01, // PARM='DEL aaaNODE..REST.OF.NAME' //SYSTSPRT DD SYSOUT=Z //SYSTSIN DD DUMMY // PEND But we've gotten even lazier. We just use a CA-11 step in _all_ (even programmers submitted) jobs as the first step. That lets _it_ find and delete all DISP=NEW datasets referenced in the JCL. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Tue, 2 Sep 2014 19:01:45 +0530, Christian D wrote: Hi Group, Is there a difference in using the utility IEFBR14 and IDCAMS in deleting VSAM cluster Dataset ? I used to Delete the Cluster Before using IEFBR14 before but now it fails. //DEL EXEC PGM=IEFBR14 //TSDD DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,(0)), // DSN=CHRIS.TESTING.DB2.LL1 doesn't clear data set but raise IGD17105I CATALOG ERROR WHILE DELETING DATA SET 730 CHRIS.TESTING.DB2.LL1 RETURN CODE IS 84 REASON CODE IS 0 IGG0CLFK Explanation from Manual : 84 Explanation: CAXWA count of active users has reached 32767, the maximum allowed. The Deletion works well with IDCAMS but not with IEFBR14. You looked up the wrong return/reason code. 84 Explanation: CAXWA count of active users has... is return code 4, reason code 84. This is return code 84, reason code 0: RETURN CODE 84 Explanation: Date error. Reason Code Description 0 Explanation: An unexpired purge date exists. An attempt to delete an entry failed because its expiration date has not been reached, and the DELETE command did not specify the PURGE option. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2m6c2/20.422?SHELF=all13be9 You need the PURGE/PRG-Option of IDCAMS-DELETE to delete an unexpired data set. There's no equivalent in JCL. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Tue, 2 Sep 2014 10:09:02 -0400, John Gilmore wrote: This message is less informative that it should be. I'd even say disinformative. The value +32767 is of course the [decimal] capacity of a signed binary halfword, and what we notionally have here is an instance of control-block field overflow; but I suspect that this message is an artefact of the use of IEFBR14---As Elardus has already pointed out, it does nothing itself and wots not of VSAM---to trigger the deletion of a VSAM dataset identified in a JCL DD statement. If allocation fails to delete a VSAM data set, the cause should be described clearly, with suitable Programmer Pesponse, in the message explanation. If allocation actually leaves a control block field corrupted, that bug should be fixed. Use IDCAMS instead! (That should appear as the Programmer Response.) I use DSLIST, but I assume that invokes IDCAMS. (TSO DELETE also? I haven't tried that.) I've observed IBM to be quite slow repairing misleading message texts. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Tue, 2 Sep 2014 09:27:07 -0500, John McKown wrote: I can only think of two reason people still use IEFBR14 in this manner. The first is that it predates the existence of IDCAMS. And so inertia has set in. The other reason is that by being in JCL, the DSN, or portion, can be a symbolic parameter. ... //DELIT PROC NODE=T //DELIT EXEC PGM=IKJEFT01, // PARM='DEL aaaNODE..REST.OF.NAME' //SYSTSPRT DD SYSOUT=Z //SYSTSIN DD DUMMY // PEND Of course, z/OS 2.1 provides symbol substitution in the SYSIN to IDCAMS. But we've gotten even lazier. We just use a CA-11 step in _all_ (even programmers submitted) jobs as the first step. That lets _it_ find and delete all DISP=NEW datasets referenced in the JCL. (But not, I hope, DISP=(,CATLG). Isn't the default disposition (,DELETE)?) first step? Not last? It deletes data sets about to be created? Or does it modify control blocks for the remainder of the job? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Tue, 2 Sep 2014 08:42:10 -0500, Elardus Engelbrecht wrote: Christian D wrote: Is there a difference in using the utility IEFBR14 and IDCAMS in deleting VSAM cluster Dataset ? Absolutely! You use IDCAMS to manage VSAM datasets. IEFBR14 just simply 'does nothing'. You can define (and delete) VSAM data with JCL/IEFBR14 for about 25 years now (MVS/ESA 3.1.0e ?). http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D4A0/2.2.3 Not all IDCAMS-Options are available in JCL, but you can use temporary VSAM data sets (DSN=amp;MYDSN,DISP=(,PASS)) in JCL (you can't define temporary data sets with IDCAMS) Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Tue, Sep 2, 2014 at 9:42 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On Tue, 2 Sep 2014 09:27:07 -0500, John McKown wrote: I can only think of two reason people still use IEFBR14 in this manner. The first is that it predates the existence of IDCAMS. And so inertia has set in. The other reason is that by being in JCL, the DSN, or portion, can be a symbolic parameter. ... //DELIT PROC NODE=T //DELIT EXEC PGM=IKJEFT01, // PARM='DEL aaaNODE..REST.OF.NAME' //SYSTSPRT DD SYSOUT=Z //SYSTSIN DD DUMMY // PEND Of course, z/OS 2.1 provides symbol substitution in the SYSIN to IDCAMS. But we've gotten even lazier. We just use a CA-11 step in _all_ (even programmers submitted) jobs as the first step. That lets _it_ find and delete all DISP=NEW datasets referenced in the JCL. (But not, I hope, DISP=(,CATLG). Isn't the default disposition (,DELETE)?) first step? Not last? It deletes data sets about to be created? Yes. That is its entire purpose in life. It deletes _every_ DSN (with some exceptions such as SYS1 and others in a customer supplied exclusion list) which the internal control blocks (SWA) says that the job is going to try to create. It runs as the first step so that it can scan the SWA. It checks for DSNs which the job is going to try to create (regardless of disposition of CATLG, DELETE, or KEEP) and actually, internally, uses IDCAMS DELETE to delete them in the first step. At least as I understand what I was told by one of the writers of the package. One reason for this exclusion list was the number of people who would mess up their JCL so that the DISP was missing or the JCL converter/interpreter would comment it out. This saves critical DSNs from being deleted. IIRC, it was done after a sysprog had a JOB with SYS1.LINKLIB (to which he had ALTER access) in a DD and simply forgot the DISP. Bye-bye to SYS1.LINKLIB. And then, soon thereafter, bye-bye system. Or does it modify control blocks for the remainder of the job? Well, if the job is a restart, it will mess around with the relative GDG numbers properly so that the restarted job will actually restart in the failing step. It also updates internal control block from the data base it maintains in order to post the previous run's return codes into the proper control blocks in the current run with the values from the previous run, then bypass those steps so that they don't actually run. This way, any COND= and IF statements would work just as they would have in the previous jobs, had it not abended. But we only use the restart function of CA-11 for jobs submitted by CA-7. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
Paul Gilmartin wrote: begin extract first step? Not last? It deletes data sets about to be created? /end extract Many readers here are too young to have done any great number of SYSGENs, but they provide an apposite vehicle for discussing such operations. SYSGENs were many-step jobs; and they often failed, not least frequently because the space required in some [real] DASD dataset had been underestimated and that available had been exhausted. IBM provided a utility for reconstituting a job beginning with step n 1, but it was appropriate indeed essential to delete many already allocated DISP=NEW datasets before rerunning it. It was standard practice to restore the status quo ante by doing so before retrying the SYSGEN, and there are analogous situations in which this should still be done. A tabula rasa is unproblematic, and the deletion of a non-existent data set is an innocuous operation. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Tue, 2 Sep 2014 10:13:53 -0500, Elardus Engelbrecht wrote: Norbert Friemel wrote: Not all IDCAMS-Options are available in JCL, but you can use temporary VSAM data sets (DSN=amp;amp;amp;MYDSN,DISP=(,PASS)) in JCL (you can't define temporary data sets with IDCAMS) Temp VSAM? Interesting, there must be a reason for that. Perhaps temp holdplace during creation of DB2 tables? Testing? I've run an entire SMP/E experiment in a single batch job. IDCAMS to create a CSI; GIMSMP with FUNCTION(s) in instream SMPPTFIN; IDCAMS DELETE (I had been unaware of temp VSAM; I thought VSAM requires CATALOG, and CATALOG hates temp DSN). (LISTSERV (or is it the sender's MUA?) does strange things to ampersands.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 09/02/2014 09:31:45 AM: From: Christian D christianfe...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/02/2014 09:31 AM Subject: Deleting Cluster Using IEFBR14 or IDCAMS Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi Group, Is there a difference in using the utility IEFBR14 and IDCAMS in deleting VSAM cluster Dataset ? I used to Delete the Cluster Before using IEFBR14 before but now it fails. //DEL EXEC PGM=IEFBR14 //TSDD DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,(0)), // DSN=CHRIS.TESTING.DB2.LL1 doesn't clear data set but raise IGD17105I CATALOG ERROR WHILE DELETING DATA SET 730 CHRIS.TESTING.DB2.LL1 RETURN CODE IS 84 REASON CODE IS 0 IGG0CLFK Explanation from Manual : 84 Explanation: CAXWA count of active users has reached 32767, the maximum allowed. This is reason code 84 for return code 4. You need to look up return code 84, reason code 0. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
W dniu 2014-09-02 16:49, Norbert Friemel pisze: On Tue, 2 Sep 2014 08:42:10 -0500, Elardus Engelbrecht wrote: Christian D wrote: Is there a difference in using the utility IEFBR14 and IDCAMS in deleting VSAM cluster Dataset ? Absolutely! You use IDCAMS to manage VSAM datasets. IEFBR14 just simply 'does nothing'. You can define (and delete) VSAM data with JCL/IEFBR14 for about 25 years now (MVS/ESA 3.1.0e ?). http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D4A0/2.2.3 Not all IDCAMS-Options are available in JCL, but you can use temporary VSAM data sets (DSN=amp;MYDSN,DISP=(,PASS)) in JCL (you can't define temporary data sets with IDCAMS) Just to complement: there are options/features of VSAM which are unavailable in IDCAMS, but available in SMS DATA CLASS. Of course DATACLASS can be specified in JCL ...as well as in IDCAMS. There are also features present in IDCAMS but unavailable in DATA CLASS. So, full feature set require DC and IDCAMS. Last, but not least: LIKE keyword of DDname is your friend also in VSAM realm. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On 2 September 2014 10:32, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: I use DSLIST, but I assume that invokes IDCAMS. (TSO DELETE also? I haven't tried that.) TSO DELETE has been an IDCAMS command since MVS 2.0; maybe even in SVS, a system I never used. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
