Gen EDGE

As CA starts looking at what we want to do for the next release of Gen, a big part of the focus for that release will be on things that can be done which will make upgrading easier.  Since new functionality is being added into the current release faster than ever before, it makes sense that CA would like customers to stay current on the releases.  Here are a couple of ideas for things that could be done:

• What if we never changed the version numbers on the distributed runtimes that Gen provides?  For example, with 8.5, the C runtimes have the text "85" in them (like "wrf850n.dll").  Regardless of the release, this number would remain in the file name for time immemorial.  Although this might make it more difficult to run multiple releases of Gen at the same time, it would allow upgrading applications to be as easy as just replacing the runtime files
  • Java and C# both require code to be regenerated because the runtime versions are part of the generated code.  If we did not change the runtime versions, regeneration would no longer be necessary
  • Although C applications do not require regeneration, they do require relinking when the runtime version numbers change.  Again, if we did not change the runtime versions, relinking would no longer be necessary
• What if, for the Gen runtimes, we picked a version of Visual C to link our runtimes and then never changed it (i.e. we would get rid of the VS1xx directories and there would be no need to select a version of Visual Studio in the build tool profile)?  Although we would only use one version of Visual C for our runtimes, generated applications could be built with any version of Visual C as our runtimes would just be linked into the applications

Let the community know what you think about these suggestions and also if you have any other suggestions that would make upgrading on distributed platforms easier (partially for the Gen tools but mostly for the applications created by those tools).

We are totally supportive of keeping the runtime versions unchanged as this issue has been a massive overhead in all our GEN upgrades. Thank you for considering the idea https://communities.ca.com/ideas/235715064

John,

While I'm quite encouraged at the idea of making upgrades easier, it's not as simple a scenario as just picking a version of a DLL for naming reasons and sticking with it.  The C# and Java suggestions are undoubtedly handy ones, and will make the lives of those deployments much easier.

You might find there will be issues with what you're wanting to achieve with C under Windows, especially if you're tying the Gen runtimes to one version and letting applications build at another (see this article Potential Errors Passing CRT Objects Across DLL Boundaries "Potential Errors Passing CRT Objects Across DLL Boundaries").  There'd need to be some fairly strict discipline as to what you and cannot do in the runtimes and objects passed between them.  Additionally, at some point the version of Visual Studio you pick for the Gen runtimes will go out of support - especially as Microsoft move to near yearly releases of their compiler and tooling.

The bigger issue, I would argue, isn't the cost of regenerating and recompiling - while these are time consuming processes, they're not inordinately difficult to achieve, and there are processes customers can use to simplify and streamline this.  The real issue is application level changes caused by runtime behavioural changes.  Some of the functions you implement for the user change between release - and thus, even if I could just drop a new set of runtimes in, I don't have a simple upgrade.

Take VERIFY, for example.  Its behaviour changed at Gen 6, Gen 8.0, twice at Gen 8.0 IE1 and at Gen 8.5.  The effective behaviour of this function changed between releases.  So even if a customer dropped in new, compatible linkage runtimes, they'll still have to do a potential significant regression retest of their application stack, once they have find and isolated all incidents of where this function has occurred.  While it's perhaps the most obvious example, it isn't the only one (MAKE ERROR, JULDATE, SUBSTRDBCS, etc.).

Given that, I would argue you have a separate versioning issue at that point.  To be able to upgrade swiftly and drop in new runtimes would mean that a user would have to be able to rely on the application behaving as it already does in a consistent, predictable fashion.  So if you change VERIFY again, you can't update the existing implementation - you'd have to call it VERIFY2, VERIFYEX or similar, so that a customer can opt in to the new behaviour as and when they rebuild/modify their application, rather than being forced into a path of significant retest.  For functions and the like, this wouldn't be a particularly burdensome thing (though the practicalities of re-clicking all VERIFY statements would be a frustration).  But where you change things like DISABLED BY or MAKE ERROR statements, that's a harder one, as introducing new language constructs isn't great.

I guess my point is this - you can solve the technical challenge of versioning the runtimes, and I don't suspect it's overtly difficult to achieve.  However, upgrades aren't just about upgrading tool chains, but ensuring the user's built applications don't change behaviour just because of an upgrade.  And as long as function behaviour and statement behaviour can change because of a runtime upgrade, this won't simplify a customer's upgrade path in any really significant way.

And that's just Windows, not the other supported platforms.  I'm sure they have their own challenges too.

I would definitely support removing a version specific identifier in the generated Java and C# code so that you do not need to regenerate code for each new release of Gen.

I also agree that a key point is upward compatibility and no surprises with new versions of the runtime. This means that any changes in behaviour need to be either optional and controlled by some type of runtime property. For example if you want to support two different behaviours for the VERIFY function, then you could have an environment variable or some sort of property (perhaps in a user exit) to control how the function behaves.

It is also important that you do not require applications to be re-linked. A recent example was with IMS and moving one of the Gen runtime functions in 8.5 to a different DLL which required a re-link of all load modules.

The problem with an environment variable or similar concept means you end up with an all or nothing approach.  Users may not be able to universally say "Just move to latest verify", and may be upgrading models or components in a piecemeal fashion.  So they'd need the ability to opt in selectively to the process, and I don't think that fits in cleanly with a runtime option of that type.  Especially for users with hundreds or thousands of models, this becomes impractical to do in an all or nothing scenario.

A user exit might be a better fit, but it would depend on how it's structured - if it's in a common runtime for all applications and your only choice is the version of verify to select with no granularity, then it's effectively similar to an environment variable.

It certainly needs to be an opt-in default, not opt-out.

Hi John

Are you able to provide an update on this idea of not changing the version numbers in the distributed GEN runtimes, This is a very important issue for us and we hope it can be implemented in the next GEN release.

Thanks.

Hi John,

We are also waiting for a solution to the upgrade problem on the Windows client side. Preventing the need for regenerating or relinking in every upgrade and making behaviour changes with user exits optional are great ideas. I hope you can implement these features as soon as possible.

Thanks.

To everyone who has participated in this discussion, I thank you and ask you to provide some more suggestions for how CA can make Gen upgrades easier.  As it is, we are trying to come up with a few solutions mentioned in the original discussion for our 8.6 release and ask that you please participate in the customer validation program so as to ensure that what we do in attempting to make the upgrades easier is really what you need and works the way you expect.  If you are not signed up for the validation program, please visit validate.ca.com and get signed up.  If you have any questions or problems getting signed up, contact Gaurav Gohil (gohga01).  We have call-in meetings about once per month that last for about an hour to go over the progress made on the various projects and, at that time, you are able to download software so as to test the projects in your own environment.

Note that Gaurav may be reached at Gaurav.Gohil@ca.com for information about or problems with getting signed up on the customer validation site.

Thanks John.  Just applied, and it seemed to go all nice and smoothly (albeit I was already in a CA CVP so that probably helped).  Looking forward to getting a glimpse and the opportunity to test.

John,

it would definitive ease upgrading if there would be a central
change log for all files. Especially on the mainframe there are a lot of
customers who have customized a lot of clists, procedures and user exists and
it would help to know which of those (e.g. CEHBSAMP, CEHBCLS0, …) were
changed with the new release.