z/OS compatibility 
Author Message
 z/OS compatibility

I have seen that the "Z" POPS is now available and I plan to
read that, but at a much higher level I am trying to find out
if anyone has had any experience with compatibility issues with
z/OS.  The IBM doc I have seen so far only claims compatibility
if you are running OS/390 2.10 on the new machine, I have seen
nothing that indicates that applications developed under MVS
or OS/390 will continue to run without change under the new
OS.

Thanks,

--
Tom Anderson                    | Ex ignorantia ad sapientiam
Director, PIPES Development     | e tenbris ad lucem!



Tue, 05 Aug 2003 01:50:13 GMT  
 z/OS compatibility

:>I have seen that the "Z" POPS is now available and I plan to
:>read that, but at a much higher level I am trying to find out
:>if anyone has had any experience with compatibility issues with
:>z/OS.  The IBM doc I have seen so far only claims compatibility
:>if you are running OS/390 2.10 on the new machine, I have seen
:>nothing that indicates that applications developed under MVS
:>or OS/390 will continue to run without change under the new
:>OS.

There should not be problems for most application programs.

The PSA has changed quite a bit to support the 16 byte PSW's.

--


http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Tue, 05 Aug 2003 02:18:17 GMT  
 z/OS compatibility
What? IBM Would sink into the depths of the Marianas(sp?) Trench if
word got out that old code won't run on the new machine.

TRUST ME, IT WILL RUN! (-;


wrote on 02/15/2001 09:50:

Quote:

> I have seen that the "Z" POPS is now available and I plan to
> read that, but at a much higher level I am trying to find out
> if anyone has had any experience with compatibility issues with
> z/OS.  The IBM doc I have seen so far only claims compatibility
> if you are running OS/390 2.10 on the new machine, I have seen
> nothing that indicates that applications developed under MVS
> or OS/390 will continue to run without change under the new
> OS.

> Thanks,



Tue, 05 Aug 2003 10:40:47 GMT  
 z/OS compatibility
Case in point .... BC mode PSW was still supported until recently. (And yes,
our OLD TPF system took "advantage" of that fact. We were more or less
forced into an OS upgrade because we needed faster iron, and the faster iron
wouldn't tolerate such nonsense. :-)

Fun days though.. :-)

I used to joke with management types..... "This box is SO smart it will
emulate the DUMBEST thing we have" :-)
--
Don Russell


Quote:
> What? IBM Would sink into the depths of the Marianas(sp?) Trench if
> word got out that old code won't run on the new machine.

> TRUST ME, IT WILL RUN! (-;


> wrote on 02/15/2001 09:50:

> > I have seen that the "Z" POPS is now available and I plan to
> > read that, but at a much higher level I am trying to find out
> > if anyone has had any experience with compatibility issues with
> > z/OS.  The IBM doc I have seen so far only claims compatibility
> > if you are running OS/390 2.10 on the new machine, I have seen
> > nothing that indicates that applications developed under MVS
> > or OS/390 will continue to run without change under the new
> > OS.

> > Thanks,



Tue, 05 Aug 2003 10:46:38 GMT  
 z/OS compatibility
Quote:

> I have seen that the "Z" POPS is now available and I plan to
> read that, but at a much higher level I am trying to find out
> if anyone has had any experience with compatibility issues with
> z/OS.  The IBM doc I have seen so far only claims compatibility
> if you are running OS/390 2.10 on the new machine, I have seen
> nothing that indicates that applications developed under MVS
> or OS/390 will continue to run without change under the new
> OS.

<snip>

Per Bob Rogers of IBM from the 64bit Architecture meeting this
week:

The old code will continue to function because the upper 32bits
of the registers are transparent (or opaque depending).  PSA is
now 8K, and the old areas used for PSAOLD/NEW are filled with
zeros.  So, this means that error recovery code that notices
these things have to be made aware of the new hardware changes.
LAP covers the low order of both PSA pages.

Now, as long as you are not using any of the new instructions
that will change the hi-order of the registers, you will be OK.
However, if you are expecting certain OPCODEs to give you a PIC1,
you may be surprised with a PIC2, OR, that you take no exception
at all! (I kinda fell over this some years ago, when I wanted a
PIC2 and the old SIOF instead gave a PIC1 -- what happened when
you changed to an XA system from base 370).

--
Steve Thompson
OSP LLC
330/335-9907 office
330/334-2097 fax

Remove "_" in email address to contact me -- anti-spam measures
in use



Wed, 06 Aug 2003 06:22:56 GMT  
 z/OS compatibility

Thanks all for the replys.  I now feel confident that as long
as I stick to what's on my yellow card, I won't have any
problems(?!).

The part that got me nervous was when they only claimed
compat if you run OS/390 2.x on the machine and they
were "silent" about compat if you run "z/OS".

So it sounds like i've got a few years yet to absorb the
new arch, etc. and by then we might be able to run the
new OS on a machine I can afford (a la p/390 s/390, etc).

Which causes me to wonder if there is going to be a market
for smaller clone machines.  Last I heard all of the
clone makers (Amdahl, Fujitsu, Hitachi) have all abandoned
the market, but maybe the time is ripe for someone to pick
this up, but focus on the smaller end machines.

Anyway, thanks again!

--
Tom Anderson                    | Ex ignorantia ad sapientiam
Director, PIPES Development     | e tenbris ad lucem!



Tue, 12 Aug 2003 01:01:54 GMT  
 z/OS compatibility
I have carefully reviewed z/Architecture Principles of Operations, and
I have come to the conclusion that so long as no 64 bit instructions
are inserted into the instruction stream, _all_ existing code will
work exactly the same as it does today.

OTOH, if _any_ 64-bit instruction is inserted into the instruction stream,
there is all too likely going to be a problem downstream after the 64 bit
instruction executes.

This is just my opinion, of course, and I'd like someone to challenge it!

-- Steve Myers



Wed, 13 Aug 2003 11:28:17 GMT  
 z/OS compatibility


Quote:

> This is just my opinion, of course, and I'd like someone to challenge it!

Steve, are you trying to stir up controversy or something? You throw
yourself open to a challenge like this, surely someone will jump on
it for you!

Not me, though. I've seen your posts to various newsgroups and mailing
lists and have decided there is no point... (-;

But I have one thought to add: Since there are a ton of new opcodes
thrown into the quagmire here - now over 400, right? - I wonder how
many programs with deliberate 0C1's in strategic places will now NOT
spring the trap?

Didn't IBM commit to leaving opcode X'00' for use as a self-desctruct
mechanism???

BB



Wed, 13 Aug 2003 21:41:00 GMT  
 z/OS compatibility
I agree completely.  They have more or less committed to 00 and one
other "operation code" (which I could not find) as always generating
0C1 interrupts.

-- Steve Myers

(I do goof, and people do jump on me when I do goof!)


Quote:


>> This is just my opinion, of course, and I'd like someone to challenge it!

>Steve, are you trying to stir up controversy or something? You throw
>yourself open to a challenge like this, surely someone will jump on
>it for you!

>Not me, though. I've seen your posts to various newsgroups and mailing
>lists and have decided there is no point... (-;

>But I have one thought to add: Since there are a ton of new opcodes
>thrown into the quagmire here - now over 400, right? - I wonder how
>many programs with deliberate 0C1's in strategic places will now NOT
>spring the trap?

>Didn't IBM commit to leaving opcode X'00' for use as a self-desctruct
>mechanism???

>BB



Thu, 14 Aug 2003 22:31:59 GMT  
 z/OS compatibility
So, basically what all this means is that we're going to have to write
toloration into our new code.

The term "Sufficiently paranoid" bothers me at the moment.



Quote:
> Steve Myers wrote

>> OTOH, if _any_ 64-bit instruction is inserted into the instruction
>> stream, there is all too likely going to be a problem downstream
>> after the 64 bit instruction executes.

> It depends on what you mean by downstream.  We've been running 64-bit MVS
> drivers for several years in the development lab, and compatibility for
> 31-bit mode code is a bit better than you state - intentionally.  Code
> that runs in 31-bit mode and does not explicitly use 64-bit capabilities
> has been very well isolated from errant 64-bit mode code that leaves
> things in the left side of registers.  We've been through a few such
> situations, and, what is impacted is code that gets control in 64-bit mode
> and isn't sufficiently paranoid.  I haven't seen much code exploiting
> 64-bit register arithmetic while staying in 31-bit mode, but there's
> obviously an exposure there as well.

> Bob Wright - z/OS MVS Service Aids



Sun, 17 Aug 2003 09:23:30 GMT  
 z/OS compatibility

Quote:
>So, basically what all this means is that we're going to have to write
>toloration into our new code.

Uh, not exactly - only if you write 64-bit code.

We can write 31 (and somewhat 24) code as we always have.  There is some
interesting new stuff with regards to save areas in z/OS, and this was covered
at a developer's only IBM presentation a couple of weeks ago (and a month
ago in Germany).

Quote:
>The term "Sufficiently paranoid" bothers me at the moment.

Think of all the stuff we had to cover when writing 31 bit code that
had to handle "unclean" 24 bit code.

Later,
Ray

Quote:


>> Steve Myers wrote

>>> OTOH, if _any_ 64-bit instruction is inserted into the instruction
>>> stream, there is all too likely going to be a problem downstream
>>> after the 64 bit instruction executes.

>> It depends on what you mean by downstream.  We've been running 64-bit MVS
>> drivers for several years in the development lab, and compatibility for
>> 31-bit mode code is a bit better than you state - intentionally.  Code
>> that runs in 31-bit mode and does not explicitly use 64-bit capabilities
>> has been very well isolated from errant 64-bit mode code that leaves
>> things in the left side of registers.  We've been through a few such
>> situations, and, what is impacted is code that gets control in 64-bit mode
>> and isn't sufficiently paranoid.  I haven't seen much code exploiting
>> 64-bit register arithmetic while staying in 31-bit mode, but there's
>> obviously an exposure there as well.

>> Bob Wright - z/OS MVS Service Aids

--
M. Ray Mullins Big Bear City, California home of the other MARTA ICQ# 28901695
California Transit Publications - your one stop shop for transit marketing,
publications, planning and web services at http://www.catransit.com/     TIPs:
http://socaltip.tipnetworks.org http://norcaltip.tipnetworks.org http://cencaltip.tipnetworks.org


Sun, 17 Aug 2003 10:35:42 GMT  
 z/OS compatibility

Quote:

>Steve Myers wrote
>> OTOH, if _any_ 64-bit instruction is inserted into the instruction
>> stream, there is all too likely going to be a problem downstream
>> after the 64 bit instruction executes.
> I haven't seen much code exploiting
>64-bit register arithmetic while staying in 31-bit mode, but there's
>obviously an exposure there as well.

This does sound interesting.  While there are programs that need
large data spaces, there are also programs that need 64 bit arithmetic,
more than can be easily done using ESA/390 instructions.
(Yes, a 64 bit add can be done with two 32 bit adds and some other
stuff to do the carry.  But it isn't easy.)

So, a program that does such can't expect to keep registers across
a subroutine call.  I presume interrupt routines will save all 64 bits.
Are there unexpected times that the high bits could be lost?

thanks,

-- glen



Mon, 18 Aug 2003 09:40:59 GMT  
 z/OS compatibility
Glen Herrmannsfeld wrote

Quote:
> ...a program that does such can't expect to keep registers
> across a subroutine call.  I presume interrupt routines will
> save all 64 bits.  Are there unexpected times that the high
> bits could be lost?

A program should be able to expect registers to be saved and restored
across a subroutine call.  Beware, however, of a subroutine whose author
simply inserted some 64-bit arithmetic after doing the traditional saving
of what are now the right-sides of registers, then returning to your
routine after restoring only those right sides.  When a program is
rewritten to do the kind of thing that I'm describing, the simplest change
to register saving and restoring is to use BAKR for the saving and PR to
restore and return.  That's not really new.  The same advice would apply
to a subroutine that used access registers during its processing, and the
approach let's the subroutine save registers first and ask what kind of
(recent - not System/360) system is its host later.

MVS, indeed, saves and restores the complete register set except where
interfaces call for 64-bit input/output.  The incidents referenced in my
earlier note happened early in the development cycle when someone forgot.

All subroutines that you call have the ability to forget to properly save
and restore.  Most, however, aren't going to be changed right away to
exploit the new hardware capabilities, so the list of candidates is
usually pretty small.  Old subroutines won't touch the left sides as a
result of careful hardware archictecture - the result of experience going
from 24-bit to 31-bit on the platform a few years ago.



Mon, 18 Aug 2003 22:20:27 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. os._exit(), os.kill(os.getpid(), 9)

2. Problem with any of os.system(), os.fork() & os.execp() and os.spawn()

3. Black OS/2 icons and mini-icons for VisualWorks 2.0 for OS/2

4. FORTH/OS OS/4th

5. Oberon OS/Genera Lisp OS connection?

6. OS/390 release test periods Re: default variable initialization under os/390 v2r8

7. FA: Virtual Pascal for OS/2, RexxVIM for OS/2

8. Script to change OS/2 full screen to OS/2 windowed

9. OS/2: Rexx Script from Win-OS file manager

10. Q:Using REXX under OS/2 how can you change an OS/2 window size

11. REXX-OS/2 and ECI for CICS-OS/2

12. Can OS/2 REXX call OS/2 REXX-???

 

 
Powered by phpBB® Forum Software