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