Duncan Brown wrote: >I know that the 'official' answer from IBM is that WebSphere v7 >is not supported under z/OS 2.3, but we will not be off WebSphere >application server for z/OS v7 for at least a couple of years.
To my knowledge that statement is correct only because WebSphere Application Server for z/OS Version 7 reached End of Service on April 30, 2018. z/OS 2.3 became generally available on September 29, 2017. As far as I know, that release combination was officially IBM supported between those dates (and could still be officially IBM supported if you have obtained Extended Support for WAS for z/OS V7 from IBM, which might be possible). I don't see anything in the z/OS 2.3 Migration Guide that jumps out as a problem, although there are a couple possible migration tasks that can be indirectly related to WAS. I would strongly recommend applying the latest available fixpack(s) to bring the WAS release level up to 7.0.0.45 along with the corresponding Java fixpacks (which should be included) for both the 31-bit and 64-bit JVMs. The Java release level would then end up as SR16 FP60 with a build date of 20180213. If IBM Extended Support is available and contracted there may potentially be newer builds. (Ordinarily Extended Support is available for up to 3 years, so through April 30, 2021, in this case.) The Version 6 Java SDKs for z/OS reached End of Service on September 30, 2018. FP70 was the final release, and FP70 for z/OS still available for download here (as I write this): https://developer.ibm.com/javasdk/support/zos/ I would go grab all 4 builds (Version 6.0.0 31-bit and 64-bit, and Version 6.0.1 31-bit and 64-bit) *now*, just in case you need them. You might be able to "hack" FP70 onto a WAS 7.0.0.45 installation on z/OS, and that would cure whatever issues were resolved between Java V6 SR16 FP60 and SR16 FP70. However, 7.0.0.45 + FP70 wasn't an officially supported combination, at least not under standard service. Nonetheless, you might decide to run that custom combination, still at your own risk. I'm really not sure why you're held back on WAS V7, though. Ordinarily any "hold back," if it exists, is grounded in the underlying Java version. WAS 8.5.5 supported Java 6 -- the Java 6 part now past tense (see above), but WAS 8.5.5 is still in service. So you should be able to move all the way up as high as 8.5.5.13 with SDK 6.0.1 at the SR8 FP55 level, the very end of the standard service road for the Java 6 line in WAS. Details here: http://www-01.ibm.com/support/docview.wss?uid=swg27005002#WAS855J6 Same thing with "hacking" SR16 FP70 into your WAS 8.5.5 installation -- that might be technically possible, and it would resolve known issues in the SDK up through FP70, but the combination was never officially supported, at least under standard service. If you're indeed sticking on the SDK Version 6 part but can move forward to WAS 8.5.5, that'd be much better. There's no End of Service date announced yet for WAS 8.5.5, and it may be possible to get Extended Support just for the SDK Version 6, a narrower proposition, through September 30, 2021, if you need to go that long. Again, I'm assuming it's the Java version that's holding you back, which is ordinarily the case if anything is holding you back. My recollection is that WAS 8.5.5 + Java 6 was sufficient to run applications in Liberty Profile, and that might be a good idea. Let's suppose for example that you have one lagging application that'll take a couple years to remediate because there's something that breaks with Java 7 or higher, and code changes are required that are taking longer than you'd like. Meanwhile, your other 68 applications (or whatever number) are forging ahead and now run on WAS 9.x for z/OS. Instead of running two full, separate WAS instances (or multi-instances since you're probably clustered) at different release levels, maybe you could reduce the footprint of the laggard by running it in a smaller, backlevel-Java Liberty instance (8.5.5 + Java 6). The laggard application would need to be repackaged and redeployed, but the code wouldn't have to change. Or you might move the laggard into a backlevel-Java CICS Liberty instance. That approach, if viable, should cut down on some memory use if nothing else. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
