wkins
Sent: Tuesday, 20 March 2012 1:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
Gerhard,
Does this ALLDATA change the access method used by DFSMSdss? For logical copy
I've found that DFSMSdss actually calls utilities like IDCAMS and IEBCOPY to
read or write the dataset. I'm
7:02 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] IEFBR14
>
> On 3/18/2012 9:03 AM, Ron Hawkins wrote:
> > And finally, my memory may be a bit dodgy nowadays, but it's my
> > recollection that the EOF for empty datasets was introduced so that
> > DFSMShsm
Paul Gilmartin
> Sent: Sunday, March 18, 2012 10:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] IEFBR14
>
> On Sun, 18 Mar 2012 10:02:28 -0400, Gerhard Postpischil wrote:
>
> >On 3/18/2012 9:03 AM, Ron Hawkins wrote:
> >> And finally, my memory may be a bit
On 3/18/2012 1:29 PM, Paul Gilmartin wrote:
When you use the ALLDATA option, DSS copies whatever exists past
the last valid EOF. ...
Presumably also past DS1LSTAR?
I didn't want to write a novel. When I make permanent backups
with DSS, I normally use ALLEXCP; that way a clobbered LSTAR
does
In <00ad01cd0507$83e56010$8bb02030$@sbcglobal.net>, on 03/18/2012
at 06:03 AM, Ron Hawkins said:
>With or without an EOF mark you have
>not changed the underlying tracks to match the DCB
Incorrect; with an EOF at the beginning of the first track there are
no records, and thus no records in th
On Sun, 18 Mar 2012 10:02:28 -0400, Gerhard Postpischil wrote:
>On 3/18/2012 9:03 AM, Ron Hawkins wrote:
>> And finally, my memory may be a bit dodgy nowadays, but it's my recollection
>> that the EOF for empty datasets was introduced so that DFSMShsm and DFSMSdss
>> could migrate, move and copy e
On 3/18/2012 9:03 AM, Ron Hawkins wrote:
And finally, my memory may be a bit dodgy nowadays, but it's my recollection
that the EOF for empty datasets was introduced so that DFSMShsm and DFSMSdss
could migrate, move and copy empty datasets. When there is no EOF for a zero
empty dataset these utili
Scott,
I wasn't sure where the best place was in this thread to reply, as like all
IEFBR14 threads it has generated a lot of conversation for a program that
does virtually nothing, so I hose your original post. My two cents worth may
already have been covered in the many replies you already
Mike Schwab wrote on 3/13/2012 5:59 AM:
On Tue, Mar 13, 2012 at 7:19 AM, Paul Gilmartin wrote:
I suppose the same could be achieved for CKD data sets by
maintaining a bitmap of used tracks, which would add only
.00025% overhead to the size of a data set.
-- gil
You have the VTOCIX free space
On 3/13/2012 10:52 AM, Paul Gilmartin wrote:
Why should this peculiarly affect IEFBR14? (Although, to be
fair, Gerhard never denied that it affected all programs.)
Given enough dd statements, on a slow processor, it will take enough
time to exceed a small standard time limit.
Wouldn
ime specified in one of the following:
> >
> >- The TIME parameter of the EXEC or JOB statement
> >
> >- The standard time limit specified in the job entry subsystem
> >
> Why should this peculiarly affect IEFBR14? (Although, to be
> fair, Ge
time limit specified in the job entry subsystem
>
Why should this peculiarly affect IEFBR14? (Although, to be
fair, Gerhard never denied that it affected all programs.)
>
>Given enough dd statements, on a slow processor, it will take enough
>time to exceed a small standard time limit.
&
I would assume that the S322 ABEND was caused by the following scenario: The
job had used up almost all its estimated time (with the TIME= parameter on the
JOB card), or else there was a very small default value. Along comes the
IEFBR14 step which, in itself, has only two instructions in it
"Paul Gilmartin" wrote in message
news:<3696066093116601.wa.paulgboulderaim@bama.ua.edu>...
> On Tue, 13 Mar 2012 10:26:33 -0400, Gerhard Postpischil wrote:
> >
> >there is one case that I have not seen mentioned - in the dark
> >ages, under release 21
On Tue, 13 Mar 2012 10:26:33 -0400, Gerhard Postpischil wrote:
>
>there is one case that I have not seen mentioned - in the dark
>ages, under release 21 of OS/360(MVT), IEFBR14 steps on our
>system abended with S322. I had to write a special exception
>into IEFUTL to allow allocat
On 3/13/2012 3:46 AM, J R wrote:
Just to be clear, IEFBR14 has no functionality per se. It's
hard to imagine circumstances where it would not or could not
execute correctly.
IEFBR14 seems to start a regular thread every year. However,
there is one case that I have not seen mentioned - i
Anthony,
Thank you, that's been my past experience also..
Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com
On Mar 13, 2012, at 9:57 AM, "Sambataro, Anthony (NIH/NBS) [E]"
wrote:
> I ran a test on my 1.11 system using IEFBR14, COBOL, and bo
On Tue, 13 Mar 2012 09:45:47 -0400, Scott Ford wrote:
>Guys,
>
>Let me say this, working mvs since 1972 , then os/vs2/hasp, I hadn't seen a
>iefbr14 except in a case where the DATASET was uncataloged, if my old memory
>is serving correctly. The situation I am asking abou
I ran a test on my 1.11 system using IEFBR14, COBOL, and both SMS and non-SMS
datasets, no problems.
-Original Message-
From: Scott Ford [mailto:scott_j_f...@yahoo.com]
Sent: Tuesday, March 13, 2012 9:46 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
Guys,
Let me say this, working
Guys,
Let me say this, working mvs since 1972 , then os/vs2/hasp, I hadn't seen a
iefbr14 except in a case where the DATASET was uncataloged, if my old memory is
serving correctly. The situation I am asking about about , was a z/os 1.11
shop.. IEFBR14 used to allocate Non-SMS DATASET,
ue, 13 Mar 2012 07:46:50 -0500
> From: m...@mzelden.com
> Subject: Re: IEFBR14
> To: IBM-MAIN@bama.ua.edu
>
> On Tue, 13 Mar 2012 03:46:18 -0400, J R wrote:
>
> >Just to be clear, IEFBR14 has no functionality per se. It's hard to imagine
> >circumstan
On Tue, Mar 13, 2012 at 7:19 AM, Paul Gilmartin wrote:
> I suppose the same could be achieved for CKD data sets by
> maintaining a bitmap of used tracks, which would add only
> .00025% overhead to the size of a data set.
>
> -- gil
You have the VTOCIX free space map, one bit per track. How abou
On Tue, 13 Mar 2012 03:46:18 -0400, J R wrote:
>Just to be clear, IEFBR14 has no functionality per se. It's hard to imagine
>circumstances where it would not or could not execute correctly.
I knew what he meant. He was referring to the downstream program that
attempted to re
On Mon, 12 Mar 2012 19:40:09 -0400, Scott Ford wrote:
>Mark:
>
>Thank you, does this account for an iefbr14 executing correctly on a 1.11 or
>above system and a program receiving an Abend s001-4 , assuming everything
>else was working correctly ?
>
>
If you're aski
On Mon, 12 Mar 2012 12:18:23 -0500, Mark Zelden wrote:
>
>>But why not write the EOF unconditionally, ...
>
>I don't know under what thread subject and when, but this has been
>discussed on IBM-MAIN before. I'm not going to try and find it,
>but you can. I'm sure there's a good reason. :-)
>
Just to be clear, IEFBR14 has no functionality per se. It's hard to imagine
circumstances where it would not or could not execute correctly.
> Date: Mon, 12 Mar 2012 19:40:09 -0400
> From: scott_j_f...@yahoo.com
> Subject: Re: IEFBR14
> To: IBM-MAIN@bama.ua.edu
>
> Mar
- I think the EOF marker is handled by SMS. If a file is
>> allocated to a non-sms volume with IEFBR14 it might be that no EOF
>> marker was created. This can result in a wrong length read when
>> trying to read from the dataset instead of going straight to EODAD.
>>
panicked messages. Sure enough, the disp on the dataset
was delete. So, I would mount the vol private and map it. Watch the job and
map it again each time it took an extent. No space release coded, so that
helped. When the monthly ended, IEFBR14 absolute track allocate the pieces of
the data
Mark:
Thank you, does this account for an iefbr14 executing correctly on a 1.11 or
above system and a program receiving an Abend s001-4 , assuming everything else
was working correctly ?
Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com
On Mar 12, 2012, at 1:18
12, 2012 11:09 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
Writing an EOF record at the beginning of the data set does indeed "help
prevent programs from reading old data when a data set is read immediately
after being allocated", but the way it does this results in preventing the
On Mon, 12 Mar 2012 11:14:27 -0500, Paul Gilmartin wrote:
>On Mon, 12 Mar 2012 10:40:27 -0500, Mark Zelden wrote:
>>
>>As John M. hinted, it does require a valid DSORG.
>>
>But why not write the EOF unconditionally, regardless of
>DSORG? The only reason I can imagine not to do so is
>if the prog
On Mon, 12 Mar 2012 16:08:39 +, Bill Fairchild
wrote:
>Writing an EOF record at the beginning of the data set does indeed "help
>prevent programs from reading old data when a data set is read immediately
>after being allocated", but the way it does this results in preventing the
>reading
On Mon, 12 Mar 2012 10:40:27 -0500, Mark Zelden wrote:
>
>As John M. hinted, it does require a valid DSORG.
>
But why not write the EOF unconditionally, regardless of
DSORG? The only reason I can imagine not to do so is
if the programmer is alocating absolute track addresses
to recover a deleted
riginal Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Mark Zelden
Sent: Monday, March 12, 2012 10:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
On Mon, 12 Mar 2012 08:21:13 -0700, Sam Siegel wrote:
>Scott - I think the EOF marker is handled by
ile is
> allocated to a non-sms volume with IEFBR14 it might be that no EOF
> marker was created. This can result in a wrong length read when
> trying to read from the dataset instead of going straight to EODAD.
> Sam
>
> On Mon, Mar 12, 2012 at 8:15 AM, glen herrmannsfeldt
&g
On Mon, Mar 12, 2012 at 8:40 AM, Mark Zelden wrote:
> On Mon, 12 Mar 2012 08:21:13 -0700, Sam Siegel wrote:
>
>>Scott - I think the EOF marker is handled by SMS. If a file is
>>allocated to a non-sms volume with IEFBR14 it might be that no EOF
>>marker was created. Th
On Mon, 12 Mar 2012 08:21:13 -0700, Sam Siegel wrote:
>Scott - I think the EOF marker is handled by SMS. If a file is
>allocated to a non-sms volume with IEFBR14 it might be that no EOF
>marker was created. This can result in a wrong length read when
>trying to read from the datase
Subject: Re: IEFBR14
In article
you wrote:
(not posted to the group)
> Did you include DSORG=PS on the DD in the IEFBR14? I am fairly sure
> this is necessary to have the system write an EOF during allocation.
But what is on the disk if you don't?
In the OS/360 days, you got left
M Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford
> Sent: Monday, March 12, 2012 10:22 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEFBR14
>
> John:
>
> Here is my 'DD'
>
> //INDD5 DD DSN=VOYAGER.CACHESAV,
> /
ineer
http://www.identityforge.com
From: "McKown, John"
To: IBM-MAIN@bama.ua.edu
Sent: Monday, March 12, 2012 11:06 AM
Subject: Re: IEFBR14
Did you include DSORG=PS on the DD in the IEFBR14? I am fairly sure this is
necessary to have the system
Scott - I think the EOF marker is handled by SMS. If a file is
allocated to a non-sms volume with IEFBR14 it might be that no EOF
marker was created. This can result in a wrong length read when
trying to read from the dataset instead of going straight to EODAD.
Sam
On Mon, Mar 12, 2012 at 8:15
In article
you wrote:
(not posted to the group)
> Did you include DSORG=PS on the DD in the IEFBR14? I am fairly sure
> this is necessary to have the system write an EOF during allocation.
But what is on the disk if you don't?
In the OS/360 days, you got left-overs from previous
Did you include DSORG=PS on the DD in the IEFBR14? I am fairly sure this is
necessary to have the system write an EOF during allocation.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone
All,
I just ran across something that didn't make sense or maybe I was under a
misconception..
I created a DATASET , Qsam file , with iefbr14 , everything looked fine. A
COBOL program goes to open the file and abends with a S001-4 , the resolution
was to create the DATASET with a
At 17:55 -0500 on 11/29/2010, J R wrote about Re: IEFBR14:
> > Date: Mon, 29 Nov 2010 16:08:33 +
> From: bi...@mainstar.com
> Subject: Re: IEFBR14
> To: IBM-MAIN@bama.ua.edu
>
> He meant three possible instructions that only occupied two
bytes of storage,
In , on 11/29/2010
at 11:44 AM, J R said:
>He also omitted Exclusive Or (XR 15,15),
The quoted text is in your reply:
There were three possible instructions that could be used to
zero R15: ``Clear Register R15'', ``Subtract Register R15,R15'',
and ``Exclusive Or Register R15,R15''.
H
Doh! How did I miss that?
I stand corrected. My apologies.
> Date: Mon, 29 Nov 2010 18:08:01 +
> From: bi...@mainstar.com
> Subject: Re: IEFBR14
> To: IBM-MAIN@bama.ua.edu
>
> Read the linked article again. He did mention XR.
>
> " There were three pos
On Mon, 29 Nov 2010 16:08:33 +, Bill Fairchild wrote:
>Each byte of "core" storage in the 1960s was extremely scarce.
True, but since a CSECT always begins on a doubleword boundary
and is an integral number of doublewords in length, it doesn't really
matter whether the program is 4 or 6 byt
Wow. Is it possible he looked at CLR R1,R2 ... and thought it meant
clear??? I mean, I don't see how even a half fast programmer wouldn't know
that, so it seems incomprehensible to me, but I can't come up with any other
plausible reasons.
-
ginal Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Chase, John
Sent: Monday, November 29, 2010 10:51 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
Wasn't there also a requirement that whatever means was chosen to zero
Reg15 also set the conditi
ay, November 29, 2010 11:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
On Mon, 29 Nov 2010 11:22:43 -0600 "McKown, John"
wrote:
:>> -Original Message-
:>> From: IBM Mainframe Discussion List :>> [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Tom Marchant :>>
is setting with
the SPM.
Bill Fairchild
Rocket Software
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Binyamin Dissen
Sent: Monday, November 29, 2010 11:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
:> CALLSOME
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant
> Sent: Monday, November 29, 2010 11:11 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEFBR14
>
> On Mon, 29 Nov 2010 10:51:19 -0600, Chase, John w
On Mon, 29 Nov 2010 10:51:19 -0600, Chase, John wrote:
>Wasn't there also a requirement that whatever means was chosen to zero
>Reg15 also set the condition code to zero?
The condition code for the step is set from the value in register 15.
There is no connection between that and the condition c
On Mon, 29 Nov 2010 11:22:43 -0600 "McKown, John"
wrote:
:>> -Original Message-
:>> From: IBM Mainframe Discussion List
:>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant
:>> Sent: Monday, November 29, 2010 11:11 AM
:>> To: IBM-MAIN@bama.
re
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
J R
Sent: Monday, November 29, 2010 10:44 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
He also omitted Exclusive Or (XR 15,15), unless that's what he meant by "Clear
Register&quo
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEFBR14
>
> He also omitted Exclusive Or (XR 15,15), unless that's what he meant
by "Clear Register".
>
>
> > Date: Mon, 29 Nov 2010 16:08:33 +
> > From: bi...@mainstar.com
> > Subject: Re: IEFBR14
> > To:
He also omitted Exclusive Or (XR 15,15), unless that's what he meant by "Clear
Register".
> Date: Mon, 29 Nov 2010 16:08:33 +
> From: bi...@mainstar.com
> Subject: Re: IEFBR14
> To: IBM-MAIN@bama.ua.edu
>
> He meant three possible instructions that o
egister.
But you are right; there is no Clear Register instruction.
Bill Fairchild
Rocket Software
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Shmuel Metz (Seymour J.)
Sent: Monday, November 29, 2010 7:25 AM
To: IBM-MAIN@bama.ua.edu
In , on 11/28/2010
at 10:57 PM, Avram Friedman said:
>http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html >From one
>of the two IBM co-authors
>Note not part of the original OS spec added as an after thought
Given the following quote, his memory is not reliable:
In , on 11/28/2010
at 10:27 PM, Avram Friedman said:
>It is reasonable to think the original IEFBR14 was customer or field
>developed in a lanuage other than assembler.
Not given the name.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://pa
At 22:27 -0600 on 11/28/2010, Avram Friedman wrote about Re: IEFBR14:
As far as the original question about IEFBR14 and its APAR history
The rummor I am aware off is 2 APARS
1 to force a zero retrun code.
1 to add a copyright notice.
I remember one to relink it as RENT so it could be placed
A few histories from an internet search
http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html
>From one of the two IBM co-authors
Note not part of the original OS spec added as an after thought
http://en.wikipedia.org/wiki/IEFBR14
A wikipedia hist
Yes DYLACOR not DYLCOR sorry about the typo.
I only mentioned the product in an effort to identify the person who told me
the story about IEFBR14's start.
It is reasonable to think the original IEFBR14 was customer or field developed
in a lanuage other than assembler.
As far as the ori
On 26 Nov 2010 22:19:10 -0800, in bit.listserv.ibm-main you wrote:
>Many years ago I met the person who claimed to be the author of IEFBR14.
>Apperently before there was a short single instruction version there was the
>Cobol version that only had a GOBACK instruction.
Since GOBACK did
Many years ago I met the person who claimed to be the author of IEFBR14.
Apperently before there was a short single instruction version there was the
Cobol version that only had a GOBACK instruction.
Don't recall the authors name but I do recall
1, He was the founder of the company that pro
"Shmuel Metz , Seymour J." wrote in
message news:<20101126013902.8ab7bf58...@smtp.patriot.net>...
> In
>
<77142d37c0c3c34da0d7b1da7d7ca34308802...@nwt-s-mbx2.rocketsoftware.com>
,
> on 11/25/2010
>at 04:59 PM, Bill Fairchild said:
>
> >I do not remember the exact date of the APAR, its fix,
On 25 November 2010 20:42, Shmuel Metz (Seymour J.)
wrote:
> In
> <77142d37c0c3c34da0d7b1da7d7ca34308802...@nwt-s-mbx2.rocketsoftware.com>,
> on 11/25/2010
> at 04:59 PM, Bill Fairchild said:
>
>>I do not remember the exact date of the APAR, its fix, release
>>number, etc. I would bet that Shm
In
<77142d37c0c3c34da0d7b1da7d7ca34308802...@nwt-s-mbx2.rocketsoftware.com>,
on 11/25/2010
at 04:59 PM, Bill Fairchild said:
>I do not remember the exact date of the APAR, its fix, release
>number, etc. I would bet that Shmuel Metz does, though. :-)
Alas, while I remember that there was suc
, 2010 9:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
Bill wrote:
> The first APAR on IEFBR14 of which I am aware occurred in the late
> 1960s in the very early days of OS/360. The error was that the
> program was not setting the return code to zero. I do not remember
> th
Bill wrote:
> The first APAR on IEFBR14 of which I am aware occurred in the late
> 1960s in the very early days of OS/360. The error was that the
> program was not setting the return code to zero. I do not remember
> the exact date of the APAR, its fix, release number, etc. I
The first APAR on IEFBR14 of which I am aware occurred in the late 1960s in the
very early days of OS/360. The error was that the program was not setting the
return code to zero. I do not remember the exact date of the APAR, its fix,
release number, etc. I would bet that Shmuel Metz does
In
,
on 11/19/2010
at 10:25 PM, "Schumacher, Otto" said:
>I was not saying that IEFBR14 changed but that when run file
>allocation would do an HDELETE.
That may be what you meant to write, but what you actually wrote was
"the IEFBR14 program using allocation act
Ed Gould wrote:
>He (president) did not have a clue what IEFBR14 really did.
Surrprize!;-D 8-D
> I was ordered to write a follow up memo explaining what it did.
Groan. You did that under some serious threat?
>Trying to dumb down (to the executive level) a memo e
Allodoxaphobia writes:
> I believe the eyecatchers evolved over time. First just the module
> name. Then some pin-head lawyer in Armonk convinced them they needed a
> copyright statement.
the other justification was the unbundling announcement and starting to
charge for software (lots of le
ld wrote:
> Gerhard:
> Long long ago I was doing some SMF number crunching and at our
> installation IEFBR14 was the highest number of executions (for the
> month I was working on). I sent an memo to the IS VP indicating that
> IEFBR14 was doing more work than any of our producti
On Sat, Nov 20, 2010 at 5:28 PM, Ed Gould wrote:
> Gerhard:
> Long long ago I was doing some SMF number crunching and at our installation
> IEFBR14 was the highest number of executions (for the month I was working
> on). I sent an memo to the IS VP indicating that IEFBR14 was doi
Gerhard:
Long long ago I was doing some SMF number crunching and at our installation
IEFBR14 was the highest number of executions (for the month I was working on).
I sent an memo to the IS VP indicating that IEFBR14 was doing more work than
any of our production jobs. He was NOT amused (grin
>What's more interesting is that this is one of these perennial threads that
>comes up every year or so.
I was told by an IBM'r that the eyecatcher existed, a long time ago, but I
think it's a myth.
(I've never checked)
-
Ted MacNEIL
eamacn...@yahoo.ca
-
The IEFBR14 that lives in SYS1.LINKLIB on our z/OS 1.11 system has an assembly
date of Dec 5, 2005, and a link-edit date of Nov. 12, 2009.
The entirety of the executable portion of the load module is still: 1BFF 07FE
.
-jc-
> -Original Message-
> From: IBM Mai
On 11/20/2010 2:08 PM, Gerhard Adam wrote:
What would be the point of an eye-catcher? So you can identify the module
in a dump?
Generally eyecatchers also contain version or PTF numbers or
dates; how could you possible use IEFBR14 unless you had the
latest and greatest?
What's
: IEFBR14
Pathlength to eg branch around an eyecatcher would be trivial compared to
just getting started.
Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM
+44-7802-245-584
email: martin_pac...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Pathlength to eg branch around an eyecatcher would be trivial compared to
just getting started.
Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM
+44-7802-245-584
email: martin_pac...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Unle
Adam
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Ed Gould
Sent: Saturday, November 20, 2010 8:09 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
--- On Fri, 11/19/10, Paul Gilmartin wrote:
It is rumored that IEFBR14 has the highest ratio of
u] On Behalf
Of Ed Gould
Sent: Saturday, November 20, 2010 8:09 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14
--- On Fri, 11/19/10, Paul Gilmartin wrote:
It is rumored that IEFBR14 has the highest ratio of APARs to
bytes of code of any MVS program supplied by IBM.
I don't know how to substan
--- On Fri, 11/19/10, Paul Gilmartin wrote:
It is rumored that IEFBR14 has the highest ratio of APARs to
bytes of code of any MVS program supplied by IBM.
I don't know how to substantiate that. I'd be more confident
that IEFBR14 has the highest ratio of lines of Friday LISTSERV
dis
On Fri, 19 Nov 2010 22:25:36 +, Schumacher, Otto wrote:
>I was not saying that IEFBR14 changed but that when run file allocation would
>do an HDELETE.
I remain skeptical. I believe it's neither IEFBR14 nor allocation,
but the initiator or reader/converter/interpreter which iss
the
> > return code. 07 is Branch on Condition to the address in R14.
> >
> > --
> > Eric Bielefeld
> > Systems Programmer
> >
>
> http://en.wikipedia.org/wiki/IEFBR14
>
> They went back to that version last year.
> --
> Mik
I was not saying that IEFBR14 changed but that when run file allocation would
do an HDELETE. I also know that HSS does dataset migrations. I was just telling
the person that allocation may be causing the issue and/or his region
specification maybe to small. As I remember there was a problem
In
,
on 11/19/2010
at 07:01 PM, "Schumacher, Otto" said:
>The IEFBR14 program using allocation actually does an hdelete on a
>dataset that has been migrated with SMS rather than requiring that
>the dataset be recalled so that the file can be deleted.
No; it's
On Fri, Nov 19, 2010 at 2:28 PM, Eric Bielefeld wrote:
> Just out of curiousity, I browsed SYS1.LINKLIB(IEFBR14). It looks the same
> as it did probably about 25 years ago when I last looked at it. The code is
> basically 8 bytes:
>
> 1BFF 07FE
>
> 1B is Subt
Just out of curiousity, I browsed SYS1.LINKLIB(IEFBR14). It looks the same as
it did probably about 25 years ago when I last looked at it. The code is
basically 8 bytes:
1BFF 07FE
1B is Subtract register - FF is subtracting R15 from itself, giving 0 - the
return code. 07 is
>The IEFBR14 program using allocation actually does an hdelete on a dataset
>that has been migrated with SMS rather than requiring that the dataset be
>recalled so that the file can be deleted.
1. I thought this was optional, and the default behavior was to not do the
HDELete.
2. SMS
On Fri, 19 Nov 2010 13:18:22 -0600, Tom Marchant wrote:
>On Fri, 19 Nov 2010 19:01:44 +, Schumacher, Otto wrote:
>
>>The IEFBR14 program using allocation actually does an hdelete
>>on a dataset that has been migrated with SMS rather than requiring
>>that the dataset
On Fri, 19 Nov 2010 19:01:44 +, Schumacher, Otto wrote:
>The IEFBR14 program using allocation actually does an hdelete
>on a dataset that has been migrated with SMS rather than requiring
>that the dataset be recalled so that the file can be deleted.
Actually, no, IEFBR14 doesn&
The IEFBR14 program using allocation actually does an hdelete on a dataset that
has been migrated with SMS rather than requiring that the dataset be recalled
so that the file can be deleted. This feature was introduced with zOS 1.11.
This new feature saves a lot of time and I/O to delete files
On 11/19/2010 12:50 PM, Kelman, Tom wrote:
Yes, it sounds interesting. Did CA7 install its own version of IEFBR14?
As Gerhard said in another post, IEFBR14 as supplied doesn't have any
instructions requiring addressability, so it can't get an S0C4.
My guess would be that the ab
Yes, it sounds interesting. Did CA7 install its own version of IEFBR14?
As Gerhard said in another post, IEFBR14 as supplied doesn't have any
instructions requiring addressability, so it can't get an S0C4.
Tom Kelman
Capacity Planning
Commerce Bank, Kansas City
-Original Message
>just to let everyone know...ca7 problem..
What does that mean?
--
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
IEFBR14 can't get a S0C4 from the instructions coded in it, since none of
them require addressability. Therefore, you're looking a modified version
of it that obviously has code added.
Adam
--
For IBM-MAIN subscribe
1 - 100 of 302 matches
Mail list logo
