From: Mark Zelden <[EMAIL PROTECTED]>
Again, you are over simplifying and probably thinking about how you
handle this for your ISPF product, which could really be considered more of an
"application" than "system software".

You're probably right. I do tend to 'simplify' everything. It's in my nature. ;-)

If I upgrade my OS once a year when IBM comes out with new versions
(or twice a year in the past), then I still have to potentially upgrade
the vendor product twice a year or my OS will exceed the vendor
product.   It's a catch 22.

That's true. But if you're on z/OS 1.5 and you install a vendor product that's good up to and including z/OS 1.8, then if you upgrade to z/OS 1.6, 1.7 or 1.8 you *don't* need to install a new version of the vendor product. So, having a single version of a product that's downwardly compatible with all previous versions of an OS can, potentially, save customers the effort of reinstalling new versions of a product when they upgrade their OS.

I understand that if I (as Paul said) install
your current version now it will run on lower level OS version.  So what.

See above.

When I upgrade the OS 6 months from now, it still could break if IBM changes
something that you didn't expect them to and I don't keep current on your
product also.  New version, current maintenance, whatever.

If you upgrade from z/OS 1.5 to z/OS 1.7, and the vendor product you installed was developed and tested on z/OS 1.8, IBM is not going to 'introduce' anything the vendor product doesn't expect. If you upgrade to z/OS 1.9 and the vendor product is good up to and including z/OS 1.8, that's a different story and all bets are off.

What about a product that references
a control block that has moved above the line or above the bar?  Even
something as "harmless" as PDS86 broke with 1.8 because of the CAX moving
above the line.  Unless you are Carnac you can't code for a change now
that will happen in a future release that hasn't been disclosed to you from
IBM.

I'm not saying a vendor product can predict the future. I'm saying vendor products can accomodate the past. It's two completely different things.

To bring it close to home, are you willing to give me a written guarantee that if I purchase and install Simplist now that *all* functions will work when I upgrade
to the OS version that follows z/OS 1.8 without any fixes or upgrades to
your software?

If the OS exceeds the vendor product, it's impossible to guarantee that 100% of the functions would continue to work. But that doesn't negate the advantages of coding a vendor product to exceed the OS.


So in the spirit of how this thread started... you need to stay on supported
versions and sometimes you need to be on a current version if the
other software on your system is also very current.    It's the price you
pay for being bleeding edge. If not, you run the risk of something breaking.

I completely agree.

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
Your Space. Your Friends. Your Stories. Share your world with Windows Live Spaces. http://spaces.live.com/?mkt=en-ca

----------------------------------------------------------------------
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

Reply via email to