In 9028723543071507.wa.paulgboulderaim@listserv.ua.edu, on
05/07/2015
at 11:20 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
One might make the same argument about deleting migrated data sets
without recall because PGM=IEFBR14.
No, becaue deleting scheduling a
This long thread show the danger with feature creep. IEFBR14 of nowadays is
too complicated to use.
Best Regards,
Thomas Berg
___
Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ)
Interactive is 'manual.'
Elardus,
Very funny
On Monday, May 11, 2015, Elardus Engelbrecht elardus.engelbre...@sita.co.za
wrote:
John Gilmore wrote:
I cannot detect any feature creep. IEFBR14 sets a return code of zero
and branches on the contents of R14. The rest is of no great interest.
Thomas Berg is
In 5548ccca.2040...@bremultibank.com.pl, on 05/05/2015
at 03:59 PM, R.S. r.skoru...@bremultibank.com.pl said:
What did I miss?
The ability to override PGM=.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
We don't
In 5548dec9.30...@us.ibm.com, on 05/05/2015
at 11:16 AM, John Eells ee...@us.ibm.com said:
To be fair, IEFBR14 far predates IDCAMS and TSO. IDCAMS was likely
introduced with VSAM in DFEF in the 1970's,
Earlier.
Before they were around, someone probably realized that
something to drive
Paul:
This goes back quite a while and the old memory has dropped a few
bits here and there.
Something in my memory says at one time there was an eye catcher in
the module and was swiftly taken out. As to why I wouldn't hazard a
guess . If memory serves it went something like ptf to put
In 4961505431202836.wa.paulgboulderaim@listserv.ua.edu, on
05/05/2015
at 07:29 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
But it's inappropriate that the OS create a new data set when it
knows that it will be deleted immediately, never used.
That's not clear.
In
of38b2351a.966878f7-on85257e3c.003ebdd8-85257e3c.003ee...@us.ibm.com,
on 05/05/2015
at 07:26 AM, Peter Relson rel...@us.ibm.com said:
I have heard that there were actually two APARs on IEFBR14. One
was to add setting the return code. The other was to mark the
module as reentrant.
I've
On Thu, 7 May 2015 08:36:20 -0400, Shmuel Metz (Seymour J.) wrote:
I've heard that there was an APAR because it didn't have an
eye-catcher. If so, the eye catcher disappeared when standards
changed.
The same collection of lore avers that IEFBR14 was given a special
dispensation to deviate from
Message-
From: Dave Barry [00a5644c6d08-dmarc-requ...@listserv.ua.edu
javascript:;]
Received: Tuesday, 05 May 2015, 3:54PM
To: IBM-MAIN@LISTSERV.UA.EDU javascript:; [IBM-MAIN@LISTSERV.UA.EDU
javascript:;]
Subject: Re: IEFBR14 question
Some third-party software in use here at UPS has
Of Scott Ford
Sent: Wednesday, May 06, 2015 08:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
Paul,
I like that, why not or at the least provide a mechanism that works.
Regards,
Scott
On Wednesday, May 6, 2015, Scheuer, Paul paul.sche...@emc.com wrote:
Sure! Can you drop them
On 05/05/2015 09:28 AM, Scott Ford wrote:
All,
Since I started this question, so how is one to check for the existence
of datasets if we can't really trust IEFBR14 ? Yeah, I can write an
Assembler routine, by why, when BR14 is supposed to work...I have staging
datasets we use to build our
On Mon, 4 May 2015 20:51:47 -0400, Shmuel Metz (Seymour J.) wrote:
if DSN is migrated
The OP wrote non-existent, not migrated. The message is appropriate
for a new DASD dataset with no SPACE specification.
But it's inappropriate that the OS create a new data set when it knows
that it will be
On 05/05/2015 08:29 AM, Paul Gilmartin wrote:
On Mon, 4 May 2015 20:51:47 -0400, Shmuel Metz (Seymour J.) wrote:
if DSN is migrated
The OP wrote non-existent, not migrated. The message is appropriate
for a new DASD dataset with no SPACE specification.
But it's inappropriate that the OS
On Tue, May 5, 2015 at 7:29 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu wrote:
On Mon, 4 May 2015 20:51:47 -0400, Shmuel Metz (Seymour J.) wrote:
if DSN is migrated
The OP wrote non-existent, not migrated. The message is appropriate
for a new DASD dataset with no
On Tue, 5 May 2015 07:29:07 -0500, Paul Gilmartin paulgboul...@aim.com wrote:
On Mon, 4 May 2015 20:51:47 -0400, Shmuel Metz (Seymour J.) wrote:
if DSN is migrated
The OP wrote non-existent, not migrated. The message is appropriate
for a new DASD dataset with no SPACE specification.
But it's
The problem we solved with NORECALL was that of bogging down the system
with unecessary actual recalls when HDELETEs would do, reducing
elapsed time (and generally CPU time) significantly. We did make it
optional. If you don't want the new behavior, don't code
IEFBR14_DELMIGDS(NORECALL) in an
On Tue, 5 May 2015 07:46:33 -0500, John McKown wrote:
But it's inappropriate that the OS create a new data set when it knows
that it will be deleted immediately, never used.
Is it inappropriate? Suppose, just for the sake of argument, that I am
an clever JCL coder. I know that all the NEW
On 2015-05-05 16:54, Dave Barry wrote:
Some third-party software in use here at UPS has used this technique for
years. The assumption is perfectly valid.
Think about it: If an initiator allocates a migrated dataset specifically on
behalf of IEFBR14 -- which cannot even open it, much less
@LISTSERV.UA.EDU]
Subject: Re: IEFBR14 question
Some third-party software in use here at UPS has used this technique for years.
The assumption is perfectly valid.
Think about it: If an initiator allocates a migrated dataset specifically on
behalf of IEFBR14 -- which cannot even open it, much less use
W dniu 2015-05-05 o 15:45, Steve Thompson pisze:
On 05/05/2015 08:29 AM, Paul Gilmartin wrote:
On Mon, 4 May 2015 20:51:47 -0400, Shmuel Metz (Seymour J.) wrote:
if DSN is migrated
The OP wrote non-existent, not migrated. The message is appropriate
for a new DASD dataset with no SPACE
John Eells wrote:
The recurring confusion about what IEFBR14 itself actually does (clear GPR15
and return) and what people seem to think it does from the odd post here and
their (not yours) is one reason I call IEFBR14 the most misused program in
the history of z/OS.
... and also in the
All,
Since I started this question, so how is one to check for the existence
of datasets if we can't really trust IEFBR14 ? Yeah, I can write an
Assembler routine, by why, when BR14 is supposed to work...I have staging
datasets we use to build our product, my first step is the IEFBR14 , to
delete
On Tue, May 5, 2015 at 8:59 AM, R.S. r.skoru...@bremultibank.com.pl wrote:
W dniu 2015-05-05 o 15:33, John Eells pisze:
[...]
The recurring confusion about what IEFBR14 itself actually does (clear
GPR15 and return) and what people seem to think it does from the odd post
here and their (not
r.skoru...@bremultibank.com.pl (R.S.) wrote:
W dniu 2015-05-05 o 15:33, John Eells pisze:
[...]
The recurring confusion about what IEFBR14 itself actually does (clear
GPR15 and return) and what people seem to think it does from the odd
post here and their (not yours) is one reason I call
W dniu 2015-05-05 o 15:33, John Eells pisze:
[...]
The recurring confusion about what IEFBR14 itself actually does (clear
GPR15 and return) and what people seem to think it does from the odd
post here and their (not yours) is one reason I call IEFBR14 the most
misused program in the history
On Tue, May 5, 2015 at 9:28 AM, Scott Ford idfzos...@gmail.com wrote:
All,
Since I started this question, so how is one to check for the existence
of datasets if we can't really trust IEFBR14 ? Yeah, I can write an
Assembler routine, by why, when BR14 is supposed to work...I have staging
On 05/05/2015 10:28 AM, Scott Ford wrote:
All,
Since I started this question, so how is one to check for the existence
of datasets if we can't really trust IEFBR14 ? Yeah, I can write an
Assembler routine, by why, when BR14 is supposed to work...I have staging
datasets we use to build our
.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Scott Ford
Sent: Tuesday, May 05, 2015 7:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
All,
Since I started this question, so how is one to check
W dniu 2015-05-05 o 16:28, Scott Ford pisze:
All,
Since I started this question, so how is one to check for the existence
of datasets if we can't really trust IEFBR14 ? Yeah, I can write an
Assembler routine, by why, when BR14 is supposed to work...I have staging
datasets we use to build our
John Eells wrote:
There are elements of both joking and seriousness in my assertion that
IEFBR14 is the most misused program of all time.
Indeed.
Before they were around, someone probably realized that something to drive
Allocation functions would be nice.
Coming from big blue, this little
Thanks
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-Original Message-
From: John Eells [ee...@us.ibm.com]
Received: Tuesday, 05 May 2015, 6:34AM
To: IBM-MAIN@LISTSERV.UA.EDU [IBM-MAIN@LISTSERV.UA.EDU]
Subject: Re: IEFBR14 question
The problem we solved with NORECALL
Scott Ford wrote:
Since I started this question, so how is one to check for the existence of
datasets if we can't really trust IEFBR14 ? Yeah, I can write an Assembler
routine, by why, when BR14 is supposed to work...I have staging datasets we
use to build our product, my first step is the
] On Behalf
Of Tony's Outlook via Mozilla
Sent: Tuesday, May 05, 2015 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
All priors have been snipped away. ISTR another lengthy thread devoted to
IEFBR14 cluttering the archives. While our old, trusty, favorite platform is
being eaten
On Tue, 5 May 2015 09:45:57 -0400, Steve Thompson wrote:
How does the O/S know that this data set will never be used? Is
it because of the PGM=IEFBR14?
Yes.
Can't I have a STEPLIB with IEFBR14 in it?
IBM's design decision to HDELETE withoout HRECALL is based on the
presumption that that any
On Tue, 5 May 2015 11:28:32 -0400, Steve Thompson wrote:
..., I use IEFBR14 with COND=ONLY
A co-worker once complained that a COND=ONLY step executed with
undesirable effect because a prior step (my program) ABENDed.
Use COND=(0,LE) (but not on the first step).
Another trick I use to create a
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Tuesday, May 05, 2015 11:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
On Tue, 5 May 2015 09:45:57 -0400, Steve Thompson wrote:
How does the O/S know that this data set will never be used? Is it
because of the PGM
On 2015-05-05, at 10:16, Greg Shirey wrote:
The O/S may never use the data set after the step runs, but perhaps using
the data set wasn't the point of running the step. I'd prefer the O/S not
make that assumption for me.
And yet, lately, the O/S makes such an assumption when the
data
On 05/05/2015 12:11 PM, Paul Gilmartin wrote:
On Tue, 5 May 2015 11:28:32 -0400, Steve Thompson wrote:
..., I use IEFBR14 with COND=ONLY
A co-worker once complained that a COND=ONLY step executed with
undesirable effect because a prior step (my program) ABENDed.
Use COND=(0,LE) (but not on
All priors have been snipped away. ISTR another lengthy thread devoted
to IEFBR14 cluttering the archives. While our old, trusty, favorite
platform is being eaten alive by the toy computer tribe who are more
adept at hosting EMAIL and web sites, a talent we can't or won't
accomplish, we
At 15:59 +0200 on 05/05/2015, R.S. wrote about Re: IEFBR14 question:
W dniu 2015-05-05 o 15:33, John Eells pisze:
[...]
The recurring confusion about what IEFBR14 itself actually does
(clear GPR15 and return) and what people seem to think it does from
the odd post here and their (not yours
: IEFBR14 question
And yet, lately, the O/S makes such an assumption when the data set is
migrated. Yes, as R.S. says, you can turn it off.
It should be possible to override it within a particular job, not system-wide.
OS/360 was not designed as a multi-user system. Its descendants inherit
How many of these issues would be resolved if there was a new DISP option that
meant delete this dataset if it already exists, and then allocate it as new.?
Something like:
//MYPROG EXEC PGM=MYPROG
//MYDATA DD DSN=MY.DATA.FILE,
//DISP=(RENEW,CATLG),
//
On 2015-05-05 12:50, Frank Swarbrick wrote:
How many of these issues would be resolved if there was a new DISP option
that meant delete this dataset if it already exists, and then allocate it as
new.?
I'd prefer what many (most?) other OSes provide: use this data set if it
already exists,
SPACE=(0,0) eliminates the message. I usually also use UNIT=SYSDA, but YMMV.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Scott Ford
Sent: Monday, May 04, 2015 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IEFBR14 question
All
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
javascript:;] On Behalf Of Scott Ford
Sent: Monday, May 04, 2015 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU javascript:;
Subject: IEFBR14 question
All,
I just came across something I haven't seen. I am building some canned JCL
and I was testing
[mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Scott Ford
Sent: Monday, May 04, 2015 7:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IEFBR14 question
All,
I just came across something I haven't seen. I am building some canned JCL
and I was testing a IEFBR14 step doing disp=(mod,delete,delete
Scott Ford wrote:
I just came across something I haven't seen. I am building some canned JCL and
I was testing a IEFBR14 step doing disp=(mod,delete,delete) on non-existent
datasets wanting to see the return code passed back and saw this
IGD17045I Space not specified for allocation of data
04, 2015 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
Are you using any REF= type information?
are you sure the DSN is not included in the SMS ACS code?
Did you do any internet searches on IGD17045I and did you see anything of
interest?
The message says JCL or SMS - so
On 2015-05-04, at 08:53, Scott Ford wrote:
I just came across something I haven't seen. I am building some canned JCL
and I was testing a IEFBR14 step doing disp=(mod,delete,delete) on
non-existent datasets wanting to see the return code passed back and saw
this
IGD17045I Space not
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Blaicher, Christopher Y.
Sent: Monday, May 04, 2015 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
Lizette,
I don't know the IEFBR14 you are looking at, but the one on my machine only
has 2 instructions, SR R15
On Mon, 4 May 2015 10:02:38 -0600, Paul Gilmartin paulgboul...@aim.com wrote:
I understand there have been some changes
fairly recently, I don't know whether to Initiator or to Allocation
such that if DSN is migrated an HDELETE is performed with no
recall. Apparently in your case, it still
Cc:
Sent: Monday, May 4, 2015 9:10 AM
Subject: Re: IEFBR14 question
Peter,
Thank you very much ...haven't seen the message before ...
Regards,
Scott
On Monday, May 4, 2015, Farley, Peter x23353 peter.far...@broadridge.com
wrote:
SPACE=(0,0) eliminates the message. I usually also use UNIT
-MAIN@LISTSERV.UA.EDU
Subject: IEFBR14 question
All,
I just came across something I haven't seen. I am building some canned JCL
and I was testing a IEFBR14 step doing disp=(mod,delete,delete) on non-
existent datasets wanting to see the return code passed back and saw this
IGD17045I
@LISTSERV.UA.EDU] On Behalf
Of Frank Swarbrick
Sent: Monday, May 04, 2015 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
If the dataset already exists then it doesn't try to create it and you do not
need the SPACE parm. But if it does not exist it first creats
In
ca+qm75-hgk0fxbr-tvmxt5xe_mn2j3xi14kln42wlqwmaqi...@mail.gmail.com,
on 05/04/2015
at 10:53 AM, Scott Ford idfzos...@gmail.com said:
I just came across something I haven't seen. I am building some
canned JCL and I was testing a IEFBR14 step doing
disp=(mod,delete,delete) on non-existent
In ca6f05a6-3744-4e55-a581-2c9d5b2df...@aim.com, on 05/04/2015
at 10:02 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
if DSN is migrated
The OP wrote non-existent, not migrated. The message is appropriate
for a new DASD dataset with no SPACE specification.
--
A bit of history - Originally (back in the OS/360 days) IEFBR14 was
ONLY a BR 14. One of the first APARs (at least an early one) was to
add the SR 15,15 to set the return code to 0.
At 10:29 -0700 on 05/04/2015, Lizette Koehler wrote about Re: IEFBR14 question:
x-charset UTF-8Well - I
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
If the dataset already exists then it doesn't try to create it and
you do not need the SPACE parm. But if it does not exist it first
creats it, and then deletes it. So you need the SPACE parm.
- Original Message -
From
On Mon, 4 May 2015 12:38:30 -0500, Tom Marchant wrote:
..., it still attempts Allocation.
Or at least verifies syntax of the DD statement. How silly!
Not silly at all. A special case was recognized for DELETE with
IEFBR14 because it is well known that IEFBR14 doesn't do
anything except set
IGD17045I Space not specified for allocation of data set.
I wrote:
Default space allocation is specified via ALLOC00 PARMLIB member.
I guess this does not explain a reason for IGD17045I message though.
ALLOC00 appears to apply to dynamic or VIO allocations only.
SPACE may be required in a
On 2015-05-04, at 08:53, Scott Ford wrote:
I just came across something I haven't seen. I am building some canned
JCL and I was testing a IEFBR14 step doing disp=(mod,delete,delete) on
non-existent datasets wanting to see the return code passed back and
saw this
IGD17045I Space not
@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
If the dataset already exists then it doesn't try to create it and you do
not need the SPACE parm. But if it does not exist it first creats it, and
then deletes it. So you need the SPACE parm.
- Original Message -
From: Scott Ford
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question
If the dataset already exists then it doesn't try to create it and you do not
need the SPACE parm. But if it does not exist it first creats it, and then
deletes it. So you need the SPACE parm.
- Original Message -
From
64 matches
Mail list logo
