In [EMAIL PROTECTED], on 04/24/2007
at 11:28 AM, Rick Fochtman [EMAIL PROTECTED] said:
Strange. ISTR using TSO under Release 18.6 of MVT. Communications
were via TCAM.
Well, communications was via TCAM.
Wrong, oh how wrong! The Master Scheduler was the boss of
allocation and was invoked by
In
[EMAIL PROTECTED],
on 04/24/2007
at 03:28 PM, Kirk Talman [EMAIL PROTECTED] said:
Was SVC 99 the other name for the DAIR (dynamic allocation interface
routine(s?)) or did it replace them?
No.
In S229-3169-3 (1971Jul no release) SVC32 shows parm of R1--UCB
list but no mention of DSN,
Paul Gilmartin wrote:
In a recent note, Rob Scott said:
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
Haven't you two guys just re-created the apocryphal IEFBR14 APAR ?
I find the word apocryphal well-chosen insofar as the many times I've heard
this story I can't
Anne Lynn Wheeler wrote:
The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.foklore.comupters as well.
[EMAIL PROTECTED] (Clem Clarke) writes:
In PCP, MFT and MVT, SVC 99 didn't even exist! Nor TSO.
Yep. TSO was, as I
Gerhard Adam wrote:
In PCP, MFT and MVT, SVC 99 didn't even exist! Nor TSO.
I guess one could say, in a round about sort of way, that IEFBR14 was
the front end to invoking the DASD allocation, scratch and catalog SVCs?
I'm sorry, but you still can't say it no matter how
snip
[EMAIL PROTECTED] (Clem Clarke) writes:
In PCP, MFT and MVT, SVC 99 didn't even exist! Nor TSO.
Yep. TSO was, as I recall, *added* to MVT somewhere along the line.
And SVC 99 was not used, again, as I recall. That came with MVS or
maybe VS2?
/snip
AFAIK, TSO was always a
In case anyone lost it, assemble this:
BR14
Just hive it a name.
Bill
From: Shmuel Metz (Seymour J.) [EMAIL PROTECTED]
Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
Date: Mon, 23
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bill Wilkie
Sent: Tuesday, April 24, 2007 7:48 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
In case anyone lost it, assemble this:
BR14
Nope,
The actual code is:
SR15,15
BRR14
Bill Wilkie wrote:
snip
In case anyone lost it, assemble this:
BR14
Just hive it a name.
/snip
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan
Sent: Tuesday, April 24, 2007 8:14 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
Nope,
The actual code is:
SR
] On
Behalf Of McKown, John
Sent: 24 April 2007 09:15
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan
Sent: Tuesday, April 24, 2007 8:14
Yup!!!
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Rob Scott
Sent: Tuesday, April 24, 2007 8:25 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
Haven't you two guys just re-created
Oops.
I think you forgot the SR 15,15
I seem to remember we apared it at Shell, Melbourne, some centuries ago!!!
Clem
PS: Others probably did the same.
Bill Wilkie wrote:
In case anyone lost it, assemble this:
BR14
Just hive it a name.
Bill
In a message dated 4/24/2007 8:14:01 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
SR 15,15
BRR14
Plus the eyecatcher and the CNOP for alignment.
** See what's free at http://www.aol.com.
Nope. Those are not there!!
snip
In a message dated 4/24/2007 8:14:01 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
SR 15,15
BRR14
Plus the eyecatcher and the CNOP for alignment.
/snip
--
For IBM-MAIN
My recollection is different. SVC 99 (Dynamic Allocation) was a
necessary element of the TSO infrastructure. When TSO went GA, SVC 99
had to be there. TSO was available when I moved from New York to
Poughkeepsie in 1972.
Steve Samson
Staller, Allan wrote:
snip
[EMAIL PROTECTED] (Clem
BR14
Actually, IBM supplied a PTF (which doubled the programme size):
SR 15,15
BR 14
The reason being bad (non-zero) return codes.
(I really don't know if this is appocryphal, or not).
-
Too busy driving to stop for gas!
-snip
In PCP, MFT and MVT, SVC 99 didn't even exist! Nor TSO.
--unsnip--
Strange. ISTR using TSO under Release 18.6 of MVT. Communications were
via TCAM.
-snip
I
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
Nope,
The actual code is:
SR15,15
BRR14
Bill Wilkie wrote:
snip
In case anyone lost it, assemble this:
BR14
Just hive it a name.
/snip
But it is a nice way to get a somewhat indeterminate return code.
--
John
In a recent note, Rob Scott said:
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
Haven't you two guys just re-created the apocryphal IEFBR14 APAR ?
I find the word apocryphal well-chosen insofar as the many times I've heard
this story I can't recall the APAR's being
I'd die - application crashes
BR14
Actually, IBM supplied a PTF (which doubled the programme size):
SR 15,15
BR 14
The reason being bad (non-zero) return codes.
(I really don't know if this is appocryphal, or not).
-
Too busy driving to stop for gas
Ed Finnell wrote:
Plus the eyecatcher and the CNOP for alignment.
TCB#7 RB#1 - z/XDC TPUT
INTERFACE
XDC ===
_ _00F09000 0s (A.S.userid) --- IEFBR14+0, @R15+0, PLPA+1C
_+0 @R15 EQU *
_+0
In a message dated 4/24/2007 12:25:00 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Plus the eyecatcher and the CNOP for alignment.
Yeah, it went away. Don't know when(used to be corporate standard). We had
to put in the CNOP for XA 1.3. Don't know if it was the OEM disks
Was SVC 99 the other name for the DAIR (dynamic allocation interface
routine(s?)) or did it replace them? I vaguely remember using DAIR
decades ago. Listings trashed/lost two moves ago.
In S229-3169-3 (1971Jul no release) SVC32 shows parm of R1--UCB list but
no mention of DSN, disp, etc.
In a recent note, Ed Finnell said:
Date: Tue, 24 Apr 2007 14:34:19 EDT
Been so long, don't remember only that it wasn't fullword aligned as we got
it. CNOP 0,4 made everything happy. As has been pointed out, relinking might
have been all it needed. Also had more fun on the OEM dasd
In [EMAIL PROTECTED], on 04/24/2007
at 07:56 AM, Steve Samson [EMAIL PROTECTED] said:
My recollection is different. SVC 99 (Dynamic Allocation) was a
necessary element of the TSO infrastructure.
Correct; if you generated OS/360 with the TSO option you got DAIR,
which uses SVC 99. Note that
In [EMAIL PROTECTED], on 04/24/2007
at 11:45 AM, Clem Clarke [EMAIL PROTECTED] said:
In PCP, MFT and MVT, SVC 99 didn't even exist! Nor TSO.
Try again; DAIR uses SVC 99. You generate OS/360 with TSO, you get SVC
99. The interface to it is different from what you're used to.
I guess one
In [EMAIL PROTECTED], on 04/16/2007
at 09:22 AM, Paul Gilmartin [EMAIL PROTECTED] said:
On the z/OS side, consider that OPEN has (yet, after 4 decades) no
way to report an error to the caller other than just crashing.
That's wrong; read up on the DCB exit list in general and on the ABEND
exit
In [EMAIL PROTECTED], on
04/17/2007
at 11:17 AM, Craddock, Chris [EMAIL PROTECTED] said:
IEFBR14 is a front-end to allocation Wow! Who knew?
Snopes.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
We don't care. We
Shmuel Metz (Seymour J.) wrote:
In
[EMAIL PROTECTED],
on 04/16/2007
at 05:45 PM, Kirk Talman [EMAIL PROTECTED] said:
As IEFBR14 is a frontend to SVC 99 (allocation),
It isn't. It does what the name suggests, with a zero return code, and
that's all it does.
In PCP, MFT and
In PCP, MFT and MVT, SVC 99 didn't even exist! Nor TSO.
I guess one could say, in a round about sort of way, that IEFBR14 was
the front end to invoking the DASD allocation, scratch and catalog SVCs?
I'm sorry, but you still can't say it no matter how round_about your
explanation. IEFBR14
The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.foklore.comupters as well.
[EMAIL PROTECTED] (Clem Clarke) writes:
In PCP, MFT and MVT, SVC 99 didn't even exist! Nor TSO.
just for laughs here is the (Hercules) build install procedure for
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Arthur T.
On 17 Apr 2007 09:34:17 -0700, in bit.listserv.ibm-main
(Jeffrey D. Smith) wrote:
They all wanted to know whether IBM would continue to
support IEFBR14 under the new MVS/XA.
At my old company,
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Craddock, Chris
Sent: Tuesday, April 17, 2007 9:17 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
As IEFBR14 is a frontend to SVC 99
[EMAIL PROTECTED] wrote:
As IEFBR14 is a frontend to SVC 99 (allocation), SVC 13 (abend) is the
frontend to RTM.
snip
I think the Allocation team would be quite surprised to learn
that IEFBR14 is a front-end to their component (smile).
DD statements, on the other hand...
--
John Eells
z/OS
On 17 Apr 2007 09:34:17 -0700, in bit.listserv.ibm-main
(Message-ID:[EMAIL PROTECTED])
[EMAIL PROTECTED] (Jeffrey D. Smith) wrote:
They all wanted to know whether IBM would continue to
support IEFBR14 under the new MVS/XA.
At my old company, I was required to open a PMR to
ask IBM if
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
Instead, the application crashes reported as flaws are
actually by design.
There's no such thing as bad publicity, as long as you spell
my name correctly!
Good press, bad press; it doesn't matter,
Instead, the application crashes reported as flaws are
actually by design.
I just installed Microsofts new security system for home owners. If anyone
tries to break in, the house bursts into flames. :-)
Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
On Mon, 16 Apr 2007 12:38:26 +, Dave Salt [EMAIL PROTECTED]
wrote:
Instead, the application crashes reported as flaws are
actually by design.
I just installed Microsofts new security system for home owners. If anyone
tries to break in, the house bursts into flames. :-)
Maybe they've
On 16 Apr 2007 05:38:40 -0700, in bit.listserv.ibm-main you wrote:
Instead, the application crashes reported as flaws are
actually by design.
I just installed Microsofts new security system for home owners. If anyone
tries to break in, the house bursts into flames. :-)
Before all of carry
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris
Sent: Monday, April 16, 2007 9:51 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application
crashes are features, not bugs!
snip
Before all
In a recent note, McKown, John said:
Date: Mon, 16 Apr 2007 09:58:48 -0500
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris
Before all of carry on in our smugness, I have seen a number of
applications with
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
In a recent note, McKown, John said:
Date: Mon, 16 Apr 2007 09:58:48 -0500
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Clark Morris
Before all of carry
On the z/OS side, consider that OPEN has (yet, after 4 decades) no way to
report an error to the caller other than just crashing.
And, what would an application after a failed open, that didn't abend?
-
Too busy driving to stop for gas!
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
On the z/OS side, consider that OPEN has (yet, after 4
decades) no way to report an error to the caller other than
just crashing.
And, what would an application after a failed open, that didn't
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
Sent: Monday, April 16, 2007 10:33 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
On the z/OS side, consider that OPEN has
OPEN failed for file name[, RC=xx, RSN=yy].
0 records processed.
Imagine standing at an auto teller / Auto Bank, and you receive the
message... 0 records processed, after it just took a deposit of
$1000,00. and swallow your card at the same time... Not a happy
customer...
Herbie
In a recent note, Ted MacNEIL said:
Date: Mon, 16 Apr 2007 15:32:42 +
On the z/OS side, consider that OPEN has (yet, after 4 decades) no way to
report an error to the caller other than just crashing.
And, what would an application after a failed open, that didn't abend?
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Van Dalsen, Herbie
OPEN failed for file name[, RC=xx, RSN=yy].
0 records processed.
Imagine standing at an auto teller / Auto Bank, and you
receive the message... 0 records processed, after it just
took a
On Mon, 2007-04-16 at 09:22 -0600, Paul Gilmartin wrote:
On the z/OS side, consider that OPEN has (yet, after 4 decades) no
way to report an error to the caller other than just crashing.
Oh, I don't know. Think of ABEND/ESTAE as a sort of crippled
throw/catch (crippled in the sense that catch
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Gilmartin
Sent: Monday, April 16, 2007 10:23 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
In a recent note, McKown, John said:
Date: Mon
As IEFBR14 is a frontend to SVC 99 (allocation), SVC 13 (abend) is the
frontend to RTM. It's a way to stop things in their tracks when fubar is
detected.
In an online program (either cics or vtam) it is a good way to begin to
attempt recovery when storage corruption or resource usage out of
- Original Message -
From: McKown, John [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: [EMAIL PROTECTED]
Sent: Friday, April 13, 2007 4:53 PM
Subject: Laugh, laugh. I thought I'd die - application crashes are features,
not bugs!
http://www.computerworld.com/action
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Justice
Sent: Sunday, April 15, 2007 12:12 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Laugh, laugh. I thought I'd die - application
crashes are features, not bugs
I'd die - application crashes are features,
not bugs!
- Original Message -
From: McKown, John [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Friday, April 13, 2007 4:53 PM
Subject: Laugh, laugh. I thought I'd die - application crashes
Instead, the application crashes reported as flaws are actually by design.
There's no such thing as bad publicity, as long as you spell my name correctly!
(8-{}
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe /
In a message dated 4/13/2007 3:55:35 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
the application crashes reported as flaws are actually by design.
Working as coded! ROTFLMAO.
Bill Fairchild
Plainfield, IL
The correct use of language must begin at the very top of
57 matches
Mail list logo
