Hello does anyone have experience in Migration of CA-GEN from mainframe to CA-GEN on Windows J2EE. If yes then can one share the experience with regard to the following (a) Migration of the text based user interface to browser based screens on Windows (b) Migration of the encyclopedia (c) incompatibilities/ changes on Coolgen code between mainframe version of Coolgen and J2EE/Windows version (d) Any other complexities around the migration
Yes, we have direct experience of this using Rapide which provides several options for migrating a 3270 interface from the mainframe to J2EE:
1) You can use the Block Mode Option to automatically generate a browser interface directly from the screen designs without any changes to the model. This largely preserves the same functionality on the browser but also provides options to enhance the usability in the browser environment with control enhancements, like using checkboxes, drop-downs, push buttons instead of Fn keys, etc.
2) We provide a 3270-GUI conversion tool that will generate a GUI based version of the screens. This then allows you to further enhance the user interface because of the additional features offered by the GUI window designer.
You can also mix and match the above, for example automatically generate the majority of the screens without changing the model and selectively enhance screens using the window designer if there is a requirement for more advanced features.
There is a recording of a web seminar available on the IET events page at http://18.104.22.168/events which shows this process in action.
We have also helped many customers migrate from a host ency to a CSE and can discuss points (c) and (d) in detail, but a detailed response to these issues is outside the scope of a post reply on the forum, so please get in touch to discuss your specific requirements.
I will like to have a short chat with you regarding the Rapide product. Can you mail me your contact details.
If you send an email to information -at- iet.co.uk then I will reply with further contact details. Or you can call on +44 1225 863060.
In 2014 my current site converted from a HE on the mainframe to a CSE running Windows and GuardIEn.
During this process, to add to the excitement, we also re-platformed to C# from DB2/COBOL.
With a tool like GuardIEn it is easy to convert across in steps rather than an all-in-one-go approach ... and it can be very seamless for the developers.
I believe that CA Gen in C# has some very similar features to CA Gen in Java with regard to conversion from DB2/COBOL.
So, a search within the communities for some previous queries along these lines
Here is a starter - https://communities.ca.com/message/241722663#241722663
And don't skimp on your CSE!
Ok ... some more info on my current sites with regards to HE --> CSE conversion ...
Why the migrate across … the project was for the total transition of the application and related system off the mainframe onto the midrange platform.
At the same time there were still regular application releases going on … so the idea was to minimise the impact on the development.
Firstly a CSE was setup and IET GuardIEn purchased/installed. GuardIEn is to provide a replacement to some existing off-the-shelf and in-house software utilised on the mainframe for managing CA Gen.
The model environment at my current site (Department of Employment - ex DEEWR) is one main application model (around 6.5 million objects) with 3 (three) small component type models (around 82k objects each).
A first cut of the production model was made to test the migration process . This was done overnight as there is a MIPS cap during the day on the development LPAR.
It takes a few hours for the application model to have a download created for it.
This was then loaded onto the CSE. On the original CSE it took around 5 hours to load this model. On the new CSE it would probably take around 2.5hours. About the same as a model copy. (CSE performance mentioned in my previous comment)
Once we were happy with the migrate process … what we did was take a copy of the production and development models one weekend and load on the CSE.
From there … until the final cutover (another weekend) we took weekly deltas from the HE to load to the CSE. These deltas were generated via a subset download based on a ‘when changed’ report and adding the root subject area to the subset. These smaller downloads took less than 10 minutes to download from the HE and up to 30 minutes to load onto the CSE (including conversion to newer version of Gen).
After the final cutover weekend, as all the models were up-to-date on the CSE … and software already deployed (using Gen 8.5 instead of 7.6 as per the HE) to access it … the developer began their work on the CSE.
Since they were now checking out via GuardIEn and all new tools … the first week there was a little learning. However, it didn’t stop some of the resistant developer being able to continue coding on the mainframe, as we could still capture their HE changes and move them across to the CSE. We made sure we had a few developer information sessions/forums leading into this … and another one a few weeks after implementation in to discuss how things were going. These sessions were also helpful as other than the platform change and new software, migration automation was introduced and the conversion of the application to C# was well in progress.
We did ensure we had the relevant zOS software for generation of Gen8.5 on the mainframe.
Gen 8.5 runtimes were 90% compatible with the Gen 7.6 runtimes on the mainframe at the time (we had to raise a support request to fix issues with 3270) … so we were able to generate and build ok having the mixed versions
Older versions of Gen on the mainframe would have possibly required new environments created on the mainframe to support them.
Going to the CSE with GuardIEn then allowed developers to generate their code easily for the mainframe, and track their changes via CRs.
GuardIEn has a Remote Install feature, which for zOS allows the COBOL to be generated on the CSE, and then there are scripts that can be invoked via FTP/JCL (through the GuardIEn System Update process) to build, link and bind the code.
We were also able to find and easily clean up some of the discrepancies in the models with regards to ancestry.
Then with the transition to the midrange for the application, we were able to utilise parallel development features in GuardIEn to keep mainframe targeted and C# targeted models in sync until the final move across.
I think the whole project (HE -> CSE and then COBOL -> C#) was around 18 months. I think tim.dargavel1.1 from Facet did a small write-up/case study about that project which I can’t find at the moment.
Hope this info helps