Re: newer opcodes

2011-10-12 Thread Peter Relson
Not evil, just can't use them since the customer may not have the
hardware support. The current program I am working on requires z/VSE 4
so I was attempting to use some of the halfword-imm stuff. I just picked
the wrong instructions. So, again, back to using old instructions.

I'm curious. Are there actually customers out there who are running a
machine that is older than the minimum required for OS/390 R10 (namely
machines which support the initial relative/immediate support)?
We know that such customers would not be running a supported level of
z/OS, but they might be running something other than z/OS, or something
that is no longer supported.

Peter Relson
z/OS Core Technology Design


Re: newer opcodes

2011-10-12 Thread Ray Mullins

On 2011-10-12 12:22, Edward Jaffe wrote:

On 10/12/2011 5:08 AM, Tony Thigpen wrote:

Our customers base is VSE. We have customers that are running (in
production) old levels back as far as VSE 2.1. We have customers running
hardware as far back as MP2000 boxes. Until last year, we actually had a
VSE 1.4 customer. When you consider the fact that some of our customers
are running non-Y2K compliant systems, it is a little scary! But, they
keep sending in the checks. :-)


We all have back-level customers. The real question is whether those
customers--who won't upgrade their hardware and/or install new releases
of the
operating system--are upgrading to the latest releases of our software.

When I looked at this a few years back, the answer was a resounding No.
Back-level customers were back-level on everything. And, when and if
they did
upgrade, they tended to upgrade everything at the same time.

As long as we continue to support the highest release of our software
that did
not require newer instructions, the back-level customers continue to get
what
they pay for (support for their current release and access to new releases
should they ever choose to upgrade) and we can develop the latest
releases using
newer hardware facilities.


My internal rule-of-thumb (usually ignored) is to support the minimum
hardware level that supports the last z/OS level to go EOS, and likewise
the minimum supported z/OS level is the same. (If you need earlier, then
you have to pay for it, just like you're doing with IBM, and you
probably won't get a new release anyway.) This goes with both assembler
(OPTABLE) and C (ARCH/TARGET) code.

I haven't looked in about a year, but I'm pretty sure z/OS 1.8 and maybe
1.9 could still run on z800/z900. (In fact, I got a note from my former
employer about a month ago concerning an LLH that sneaked into some
assembler code in a maintenance branch.)

As new releases come out, the release notes say what the minimum
hardware and z/OS levels are, and also state that possible future
releases may not support these levels.

In the case of C, I set the TUNE parameter to one less than the current
highest level for the most recent z/OS, because that usually aligns with
the most common machine out there in The Real World â„¢.

IIRC, z/VSE can run on even older architecture levels than z800/z900.

I've written some assembler macros that simulate newer instructions and
are loaded in based on the OPTABLE settings. It's kind of fun, actually,
to rewrite newer instructions using only old.


[Aside: No facility in recent memory has been more liberating to our
programmers
than the relative-immediate facility.]


Amen. And when I've taught co-workers about the magic of relative
branches when they need a new base register, their gratitude is bountiful.

Later,
Ray

--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/

German is essentially a form of assembly language consisting entirely of
far calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling.
 --Robert B Wilson
English is essentially French converted to 7-bit ASCII.  ---Christophe
Pierret [for Alain LaBonté]