Gen EDGE

Any thoughts on how to start this process?  We have never converted in CA Gen from one language to another so I'm trying to figure out how to get the process started.

Are you just concerned with back-end servers or is there also a block mode or other type of user interface involved as well?

We want to convert from Gen Cobol for a Mainframe system that uses a DB2 database to Gen .Net that uses a Windows based platform.

Is the user interface of the Mainframe system block mode or GUI? If it is block mode, you might want to consider a transformation into a GUI with a web front end. This can be achieved with a very high level of automation using the Rapide Block Mode Option. Please send me a mail if you would like more information on this approach.

Hi &kenfoo1 - I've got a paper on this from CA World a couple of years back that walks through precisely how to approach this - drop me a note (tim.dargavel@facet.com.au) if you'd like a copy - happy to share that.  Cheers, Tim

Hi,

I would like a copy of the paper.

Can you please send it to mehtab47@gmail.com.

Thanks in advance.

That would be great Tim.  I might have that paper already but can you send it to kenfoo1@yahoo.com.  Thanks.

In Aug we completed a move from a backend MF cobol/db2 to Windows C#/MSSQL at our site. The project went for under 18months from start to running live in Production. It processes around 5-6 million transactions/day.

A brief summary:

A proof of concept project was the first step to determine the viability and start to build the road - so to speak.

A parallel sdlc was then created to keep prod and normal releases going - leaving the excitement of a conversion separate.

A quick summary of key things learnt - MSSQL and DB2 work differently in Gen; ASCII vs EBDCIC; differing null processing; EAB conversion; don't be afraid to raise support calls.

There are 3rd party vendors that can provide products/services that can help in identifying some of the challenges for a conversion/upgrade ... if you don't already have the impact analysis tools or experience in-house.

Do you have any more info on your process?  A more in-depth step by step?  Thanks.

I cannot really outline things step by step ... each worksite usually has a different project management paradigm to follow.

This is also a process of discovery ... as each site would have their own standards and unique coding techniques.

So the general process would be similar to an upgrade experience and will depend on what impact analysis tools you have at hand to make things easier.

Firstly would be to approach CA and discuss licensing ... if you haven't already. You will need access to the C#/.NET generators in CA Gen.

Next would be to cut a small model with some key functionality to test as a proof of concept ... to see locally (on a single workstation with Gen Toolset installed) what can be generated and executed. This is where you work out the feasibility of a conversion and it will give you a slight indication on how big/small a project it will be to convert across platforms.

Then you scale forwards from there and begin to find all the Action Blocks that will need to be reworked to execute correctly in C#.

This is where Impact Analysis tools help greatly ... also having experienced people in both the target application and future platform does help greatly.

Also, working with a CSE would be easier than a HE in this process as well.

Another thought - if you also have batch (JCL, etc) you will have to think of how you are going to replace that functionality ... as Online and Batch Procedure steps are not supported in C# (only co-operative processing).

Once again, there are a number of 3rd parties that specialise in providing these services ... and it never hurts to approach your CA account manager and discuss what CA support services can provide.

I agree that there are many concerns and issues when going from a COBOL/DB2 mainframe system to a non-mainframe, but these issues are not insurmountable.  We have been targeting for several backend platforms with the same CA Gen models for years (COBOL/DB2, C/Windows/Oracle, C/Windows/MSSQL(as ODBC), and C/Unix/Oracle).  You do need to pay attention to ASCII vs. EBCDIC and how timestamps and RI are supported on the various DBMS and your EABs may need some care or recoding.

We have both batch and online servers.  You can run batch off of the mainframe, but you may have to package it under non-display procedure steps as Windows load module or Online load module.  As mentioned, you will need to consider all of the things that your current JCL does for you and replace that in command scripting (allocate files to 'DD' names, path to your runtimes, define DBMS connection, start your load module, etc).

Best of luck with your project!

Hi

We have done some tests moving a batch application från Z/OS Cobol/DB2 to Windows/SQL Server. We are seeing extremly poor performance on Windows/MSSQL. We are not quite sure why this is the case. What are your experiences converting to Windows/MSSQL server? How does MSSQL server compare to UDB2 on Windows? Any other things to consider?

There are a number of factors that can influence performance.  Are you running the application program on the same machine as the DBMS or does it need to make a network hop for each SQL?  We sometimes unit test connected to a remote DBMS and it is slow.  We have used Windows/Oracle with some high volumes in the past on a high powered server and found the performance to be acceptable.

The application is running on the same box as the DBMS. The box is fairly highspec (I'm told). We have not been able to pinpoint exactly what is causing the problem but it looks like the FETCHes are very slow. Also when we run a complicated query in the MSSQL SQL interface. it is Quick but as soon as we open a cursor it takes a very long time.Is this something anyone else has seen?

Be aware that .NET MS SQLServer processing in Gen is not cursor based. It is set based.

What does this mean? It means that your regular Gen query will retrieve all rows that qualify in one hit, not just open a cursor and retrieve one by one (or in the case of bulk fetch in DB2, the specifically coded amount at a time)

This may mean recoding your Gen queries to utilise Limit (so indexes are better utilised) and sometimes changing logic for paging/repositioning purposes.

I know that we had our code component performing extremely poorly as each call was returning over 17k rows until we approached our DBAs for a trace and then looked at the Gen source assemblies to figure out what was really going on.

Our application is a C windows online no screen application that is accessing MSSQL server and we are seeing extremely poor performance. Are you saying that the set based processing applies to C (ODBC) programs as well as to .NET ?

Ah. C applications are still cursor based with Gen. We did some side by side testing of the C# code and C code, finding the C code was a little bit faster even taking into account fixes made to cater for set based processing in C#.

However, throughout our application we found a lot of locking issues with MS SQLServer when we converted across the mainframe COBOL code ... as there is no 'with UR' equivalent out of the box in Gen for MS SQLServer/ODBC. The workaround for those statements we could not recode the logic, was to code 'with (nolock)' manually in each statement by post processing the C/C# source code (not necessarily an approach endorsed by CA). Overall, throughout our diagnosis of issues during the conversion project, we found that the tools on the MS platform are not as mature as those on the MF, so it can be cumbersome to identify performance issues but more than possible to find and solve them.

There isn't a nice convenient check button for "With UR", but it is doable within Gen by the native toolset.

MS/SQL allows the addition of Query Hints, which are appended to the generated code (and only if it's MS/SQL).  You have a few choices, I think, if you want to not post-process.

1) Write a query to identify all the "With UR" clauses you have and the ABs, they're in, then subset those ADs, check them out, and add "WITH (nolock)" as your query hint

2) You could write a query (or collection thereof) to find the READs with the WITH UR clause, and add a DTXT entry for the right prop code to add the "WITH (nolock)".  You'll probably need to do some session management to ensure the AD's been flagged as updated, and you shouldn't do it on anything checked out.

The generated code for C# does add the right portion, as per:

if ( Globdata.GetDBMSData().GetDBMSManager().IsDBMS(IefRuntimeParm2, "IEFDB", "MSSQL") )

{

  SQLStatement.Append(" OPTION (WITH (nolock)) ");

}

Generated C is almost the same:

if (TiodbcIsDBMS("MSSQL"))

{

strcat(odbc_stmt, " OPTION (WITH (nolock)) ");

}