gen 8.6 upgrade regen required or not?

[Ron Harris]

now that 8.5 is going end of life am looking at a 8.5 to 8.6 upgrade 
have a large application that runs mostly on zos ( cics and batch).
With clients on windows 10.
Broadcom recommends that we regen the whole thing , does anybody have any experience/ alternate opinions or lessons learned ?


Also any feedback on Response Systems upgrade tool ?

[Tim Dargavel]

Hi Ron,

We've delivered a dozens of upgrades, including the r7.6 to r8.6 jumps, and the r7.6 application runtimes are typically executable in an r8.6 environment - with the correct patches applied. Generally the upgrade of CA Gen is very straight-forward, it's the ballet of moving parts for the infrastructure software levels (dependencies), and application incompatibilities that can cause grief.

Re: the Upgrade Console tool from Response Systems - happy to demonstrate that for you if you like - the core product objective is to identify any lines of code, in any cab in any model, that require alteration in order to function equivalently after the upgrade. With that knowledge up front, you can plan the required development and testing effort before you start.

Hope some of that helps,

Tim

[e-mail]

[GARY DONOGHUE]

Hi Ron,

Our experience with customers who have embarked upon that specific upgrade path (from CA Gen 8.5 Windows client/z/OS server and batch) to CA Gen 8.6 is that it is definitely not necessary, given the high degree of backward compatibility support built into the CA Gen 8.6 z/OS CICS and Batch runtimes (and the requisite CA Gen 8.6 communications middleware (MQ, TCP/IP Listener, Communications Bridge etc.)), to regenerate/build the entire application on the z/OS server side. However, client side, it is probably sensible to plan to regenerate/rebuild the entirety of your application at the new level once you have upgraded, using the later supported releases of Visual Studio, to ensure forward compatibility of the client elements of your application going forward. 

This, of course, assumes that your present CA Gen 8.5 application (on the z/OS server side in particular) is wholly regenerated/installed from the CA Gen 8.5 code generators and does not, as an example, still retain code from previous CA Gen releases including pre-CA Gen r7 legacy support via CA Gen's 'compatibility' option. 

I'd be interested why Broadcom recommended a full regeneration, including the z/OS server, though? Did they cite a specific reason for doing that? 

Anyway, hope this helps further.

Kindest Regards

Gary Donoghue

------------------------------
Senior Consultant/Developer
Information Engineering Technology
------------------------------

[Lynn Williams]

Just some added points:

For the client side, you cannot use older version generated code (8.5 in this case) with newer runtimes (8.6) because until the version removal in Gen 8.6, there is a version dependency in the runtimes. For 8.6 & above that dependency will not exist. More details in the GA Release Notes section of the Gen 8.6 techdocs:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/devops/ca-gen/8-6/release-notes/ca-gen-8_6-ga/ca-gen-release-8-6.html
(see "Runtime Library Name Changes")

Also, just a reminder that even if technically the older version generated z/OS code (8.5 in this case)  is supported with the newer version runtimes (8.6), when the old version generated code becomes End Of Service (for 8.5 that will be June 30, 2021), that combination will no longer be supported.
https://support.broadcom.com/external/content/release-announcements/CA-Gen-Release-and-Support-Lifecycle-Dates/4784

Hope that helps

------------------------------
Lynn Williams
Senior Principal Support Engineer
Broadcom
Australia
------------------------------

[GARY DONOGHUE]

Hi Lynn,

Yep. It's a good point well made viz the client side (and the windows CA Gen 8.6 runtimes therein) though I was more thinking about the interoperability between the client code (at 8.5 still running against CA Gen 8.5 windows runtimes) and the server side in terms of the regeneration requirement. During upgrades, in our experience, most sites take a view to regenerate/rebuild their entire client side - to ensure forward compatibility with Windows systems software moving forward (both development and runtime) but also with the server side code base that, typically, will only be altered as changes are applied/required to parts of the server side application. 

An interesting point about formal support of older generated/built z/OS code though - I wonder how this fits with CA Gen's compatibility support on that basis given the compatibility option, in effect, provides backwards compatibility to (and therefore support for) legacy code? 

Kindest Regards

Gary

------------------------------
Senior Consultant/Developer
Information Engineering Technology
------------------------------

[DARIUS PANAHY]

Lynn,

Can I pick up on the point about support for older releases and the need to regenerate. 

Many sites take the view that if the code is regenerated then needs to be retested, and it is the retest effort coupled with the risk that a regeneration has an undesirable effect that significantly increases the cost and perceived risk of upgrades.

A major reason for changing the distributed runtimes so that they were no longer version specific and the move to a dynamic runtime on z/OS was specifically to allow new releases of Gen to be installed without the need to re-generate code and thus reduce the cost and risk of upgrades.

However if this is not the case once the older release moves off support, then does this not force customers to have to regenerate code and negate the benefits of the dynamic / version independent runtime?

I can understand that code generated with an out of support release might not itself be supported, but I would argue that the runtimes should still support old code and as long as any problem is diagnosed to be with the runtime and not the generated code, the new versions of the runtimes should still explicitly support the old code.

------------------------------
Darius Panahy
Information Engineering Technology Ltd
------------------------------

[Teresa Bredenkamp]

All, 
The point about supporting multiple releases is a good question but for now I would want to address Ron's original request about regeneration requirement as part of upgrading to Gen 8.6. 

Ron, 
My response to this is that there is not enough information for me to comment on upgrade requirements for your specific application. 
Originally you mention upgrading from Gen 7.6 and later changed that to upgrading from Gen 8.5. 
On z/OS Targeting both CICS and batch, as long as you do not use the Compatibility feature you may be able to upgrade without having to re-generate. Also if you use Compatibility feature, depending what PTFs you have applied you may or may not need to re-generate. So the generic answer is it depends. 

We could not find a specific case documenting the details of your requirement so I could figure out why you got advice to regenerate, but I will reach out to you to more detailed information and I will try to clarify what the requirements are. 

------------------------------
Teresa Bredenkamp
CA Gen Development
Broadcom
------------------------------

[Lynn Williams]

Hi @GARY DONOGHUE, @DARIUS PANAHY,
@Tim Dargavel also raised similar points directly with me on EOS version generated code support with supported version runtimes.
Per Teresa's reply above, I have also highlighted this subject with Gen Product Owner @Kim Peelman, and we will come back to the Community on this in due course.

Regards,

Lynn

​​​​​

------------------------------
Lynn Williams
Senior Principal Support Engineer
Broadcom
Australia
------------------------------

[Kim Peelman]

@Lynn Williams  ​

Thank you for inviting me to the conversation.

Our policy is documented HERE and states: All modules within an application are subject to the support policy of the product release in which they are produced. Using the Compatibility feature without selecting the Process modules marked for Compatibility option does not change the support policy or support time frame that is associated with those modules that are marked for Compatibility. Therefore, modules that are marked for Compatibility and their components are supported at the release level at which they are built.

We have tested to ensure backward compatibility back to v7.6, but we can only support current versions. While v8.5 will go out of service June 30, 2021, it is our intent to keep v8.6 in support for a long time as a part of our continuous delivery strategy.

Note: This discussion thread has revealed the need to make this documented policy easier to find, so we're going to add it to our our Technical Requirements.

------------------------------
Kim Peelman
Product Owner, CA Gen
Broadcom
Plano,TX
------------------------------

[Douglas Seaver]

To add a little bit to the discussion,

We have a very similar environment to Ron's. z/OS, CICS, DB2, client-server apps on Windows 10, java proxy for WebSphere (WAS).

We did little or no regeneration of z/OS code for our 8.6 upgrade. We did regenerate all 520 of our client Psteps to "upgrade" from VS2010 C++ to VS2015. And to get to the runtime-independent code (no version numbers in the name or directory structure).

The main advantage (other than staying on supported versions) is that we can focus our regression testing on the client side without worrying about the z/OS code. So the testing time is reduced substantially.
The main disadvantage is, if we have a problem, we may have to regenerate some code before we can open a problem ticket with support. And, sometimes, doing that might resolve the issue.
So, it's a mixed bag.

------------------------------
Doug Seaver
Systems Development Services Specialist
CA Gen Tool Support
WisDOT
Madison, WI, USA
------------------------------