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
formal mechanism? You're certainly far less likely to get what you
want if you don't ask for it (not that asking for it will
necessarily get it for you)
That last parenthetical is part of the problem.
Also a part of the problem is response time. Generally when you do
decide to implement something, the delivery may be 2 or 3 z/OS
releases out, and I understand why that is, and I am not criticizing
it. But it is a reality.
However, when our need is immediate, we code an immediate workaround
and then move on. That's also just a reality.
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.
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 release where it should not have existed.
I'm guessing that your astonishment arises because you do not
distribute source code across multiple OS releases, and so you are
not all that familiar with (or sympathetic to) the issues that arise.
Your guess is wrong.
Well, it wouldn't be the first time. Anyway, I'm sorry for having
made that remark.
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 would be prohibitively expensive [...]
Really? How come?
As of z/OS R1.7, SYS1.MACLIB contains 1714 members. A search of those
members reveals that just 18(!) of them contained the string
"&SYSOSREL". (None were found in SYS1.MODGEN.) Has the use of
&SYSOSREL grown much in 1.8? In 1.9?
I think I could recode those 18 macros in less than a week or two.
(Any additional QA/doc/retrofit/etc overhead required by IBM would
not be much different for this than for any other accepted project
[such as the implementation of &SYSOSREL in the first place?].)
Ok, maybe three or four weeks if I'm tired.
[...] and will clearly never happen.
Clearly?
(Background regarding my "SYSSTATE OSREL=RUNTIMECHECK" suggestion to Peter.)
IBM has made a number of SYS1.MACLIB macros reactive to the "SYSSTATE
OSREL=releasename" setting. This makes it possible for a source file
to be distributed to multiple customers, assembled at their sites and
have the IBM macro expansions be appropriate both to the local z/OS
capabilities as well as to at least the hardware capabilities
required by that z/OS's minimum ALS. It's a good idea.
My suggestion was to extend the usefulness of the "SYSSTATE OSREL="
idea to programs that are distributed as object code (into multiple
levels of z/OS).
As it stands, a program distributed in object form, and using
"SYSSTATE OSREL=releasename" in its source, would have to specify the
lowest release name of all systems in use by targeted customers.
However, if SYSSTATE supported something like "OSREL=RUNTIMECHECK",
then the dependant IBM macros could be coded to check the CVT flags
for the presence/absence of needed hardware/software capabilities,
and then dual-path as appropriate.
FWIW, for the several macros that I examined, the dual-pathing logic
was pretty simple to implement.
Dave Cole REPLY TO: [EMAIL PROTECTED]
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
