At 8/28/2006 08:08 AM, PRelson wrote:
DCole wrote:
Now if only you would consider some of the other design problems
with SYSSTATE which I described to you last November and which you
ignored (specifically, my suggestion about implementing a SYSSTATE
OSREL=RUNTIMECHECK capability).
This
History of SPLEVEL, in case anyone cares.
SPLEVEL was not intended to have anything to do with the release/version
designation such as SP 1 or SP 2 or SP 3. But the values made it seem
like it might. And our documentation and commentary contributed (maybe
completely caused) the confusion.
On Thu, 31 Aug 2006 07:49:15 -0400, Peter Relson [EMAIL PROTECTED] wrote:
Well dual-path coding isn't a problem just a simple TM but assembly on any
relase is (was) for me problem. It was very easy before these zIIP FMID
comes a life and there was a seperate FMID for z/OS R6 and R7. So I still
(was Head's Up - zIIP issue OA17458/UA28419)
:I wonder what you think the rules for SPLEVEL were.
:snip
:Well, unfortunately I no longer have access to the MVS/SP2 SP3
:manuals, but as I recall, specifying SET=2 required the macros to
:generate code compatible with XA or for the MVS/XA environment
But back to STL days for me: One of the problems that we had was that
IBM internally did NOT follow their own rules for SPLEVEL.
I cannot speak for development outside of Poughkeepsie. We have always
known our responsibility for compatibility. And yes we have screwed up
on occasion. I believe
Someone said of Peter;
Perhaps you might want to re-think your attitude.
I have known Peter for a long time and have even occasionally had reason
to argue with him, but I don't think there is any reason at all to
attack his dedication - particularly with respect to maintaining
compatibility.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2006 8:44 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM's rights (was Head's Up - zIIP issue OA17458/UA28419)
snipage
Perhaps you might want to re-think your
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2006 8:44 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM's rights (was Head's Up - zIIP issue OA17458/UA28419)
But back to STL days for me: One
In [EMAIL PROTECTED], on 08/29/2006
at 12:29 AM, Robert A. Rosenberg [EMAIL PROTECTED] said:
In that case add it as port of the toleration service PTF Chain not
as a stand-alone PTF (ie: It only gets done as part of the toleration
service install).
That would complicate the service process
Your astonishment only shows your own limitations.
Maybe true.
The reason it is not reasonable and useful is for exactly the reason that
Roland ran into trouble: we might choose to roll back a definition at any
point for any reason that we feel useful.
I'm guessing that your astonishment arises
In
[EMAIL PROTECTED],
on 08/26/2006
at 05:52 AM, Schiradin,Roland HG-Dir itb-db/dc
[EMAIL PROTECTED] said:
Checking the runtime level happen during runtime but at assembly
time I would like to know what is maximum of info.
I've often used SYSPARM to control assembling for different
In [EMAIL PROTECTED], on 08/26/2006
at 09:33 PM, Edward Jaffe [EMAIL PROTECTED] said:
And, I'm astonished at your astonishment!
But Peter is right.
The technique of testing for the presence of control block fields at
assembly time e.g., AIF (NOT D'CVTH) to skip around
release-dependent
On Monday, 08/28/2006 at 08:08 AST, Peter Relson/Poughkeepsie/[EMAIL PROTECTED]
wrote:
Your astonishment only shows your own limitations.
Maybe true.
The reason it is not reasonable and useful is for exactly the reason
that
Roland ran into trouble: we might choose to roll back a definition
Thompson, Steve (SCI TW) wrote:
snip
If this pervasive and well-established technique becomes unreliable, I
predict *lots* of software will break!
snip
Shall I give two for instances?
JES2 and JES3 exits and interfacing code?
The values of EQUates and the existence of field names are
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Relson
Sent: Monday, August 28, 2006 7:08 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: IBM's rights (was Head's Up - zIIP issue OA17458/UA28419)
snip
Roland's technique is very reasonable
At 8/28/2006 08:08 AM, PRelson wrote:
DCole wrote:
Roland's technique is very reasonable considering that for many
decades you did not provide any of us with an alternative. Thank
you for finally providing SYSSTATE_OSREL.
Did anyone ever ask for this sort of thing before you did via a
At 14:43 -0300 on 08/28/2006, Shmuel Metz (Seymour J.) wrote about
Re: IBM's rights (was Head's Up - zIIP issue OA17458/UA28:
Just exercising your rights? Or did you actually have a strong
reason (I mean other than convenience) for rolling back a release
related flag name into an older z/OS
At 8/26/2006 04:04 PM, PRelson wrote:
I can only say I am astonished that someone would code based on
the presence of a field name. We have every right to define fields
in any level of macros that are convenient.
Peter,
Your astonishment only shows your own limitations. Just because you
did
In a recent note, David Cole said:
Date: Sun, 27 Aug 2006 06:03:32 -0400
At 8/26/2006 04:04 PM, PRelson wrote:
I can only say I am astonished that someone would code based on
the presence of a field name. We have every right to define fields
in any level of macros that are
On Sun, 27 Aug 2006 09:20:41 -0600 Paul Gilmartin [EMAIL PROTECTED]
wrote:
:I glanced at the doc for this. It appears less useful than it
:might be in that SYSSTATE TEST does not set values for SYSOSREL
:and SYSOSREL_NAME.
Yes, it's value is used in macro expansions, such as VSMLOC. It is more
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM's rights (was Head's Up - zIIP issue
OA17458/UA28419)
At 8/26/2006 04:04 PM, PRelson wrote:
I can only say I am astonished that someone would code
based on the
presence of a field name. We have every right to define
fields in any
level of macros
I can only say I am astonished that someone would code based on the
presence of a field name. We have every right to define fields in any level
of macros that are convenient.
This will almost certainly not be changed.
For what it's worth, you can probably use
SYSSTATE_OSREL, created via SYSSTATE
-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson
Sent: Saturday, August 26, 2006 10:05 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Head's Up - zIIP issue OA17458/UA28419
I can only say I am astonished that someone would code based
on the presence
Peter Relson wrote:
I can only say I am astonished that someone would code based on the
presence of a field name. We have every right to define fields in any level
of macros that are convenient.
And, I'm astonished at your astonishment!
The technique of testing for the presence of control
Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
Sent: Sunday, August 27, 2006 6:34 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Head's Up - zIIP issue OA17458/UA28419
Peter Relson wrote:
I can only say I am astonished that someone would code based on the
presence of a field name. We
Peter,
I concur with Ed.
Put in another light, validation for eye-catcher's, flag bit's and the likes,
have been around for decades and has thus far been a reliable
and dependant way for decades. Perhaps more importantly, it's the only reliable
avenue.
Infact, if I may, I'd have to say
products or
IBM software have the same problem.
Regards Roland
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden
Sent: Tuesday, August 22, 2006 6:07 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Head's Up - zIIP issue OA17458/UA28419
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Schiradin,Roland HG-Dir itb-db/dc
Sent: Friday, August 25, 2006 9:22 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Head's Up - zIIP issue OA17458/UA28419
Well this ptf just fix a part
Of Jeffrey D. Smith
Sent: Saturday, August 26, 2006 5:36 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Head's Up - zIIP issue OA17458/UA28419
Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
This may have been mentioned already, but according to the APAR text
the PTF is now available. It only affects systems with zIIP support
installed on z/OS 1.6 (JBB77S9).
If you are an FDRCPK user and don't get their email /newsletter
notifications, contact Innovation for details on how this
30 matches
Mail list logo
