Moving Natural from Mainframe to Unix

, , , ,
1

Hi,

The purpose of this post is to see if anyone can help validate or shoot down a few assumptions related to moving our Natural application off a mainframe, onto UNIX.

My client is running Natural/Adabase/Cobol on an IBM mainframe (z/OS). Data center costs are about $800,000/year. We are considering moving the application to UNIX-based Natural/Adabase/Cobol, to lower data center costs. We think we can run this application on Unix for $100,000/year or less, instead of the $800,000 we are paying for our share of the parent company’s IBM gear.

The biggest assumption relates to moving the application. We are thinking we should be able to copy our database and Natural source code, including online screens and batch programs, onto the UNIX Natural system, recompile and run, without changing much if any source code. Cobol is used only for batch. I have not yet looked for UNIX Cobol, I imagine our Cobol would have to change for this conversion more than the Natural would.

How realistic do these assumptions sound?

Any information that anyone can provide will be appreciated immensely.

2

I have much more experience with mainframe-to-Windows rather than mainframe-to-Unix, but the issues are much the same.

Your assumptions are valid. Moving your databases and applications across platforms should be fairly straightforward, but there are source-level differences to be resolved. Most are minor, but the level of difficulty is dependent upon how your mainframe applications were designed. For example, under certain circumstances, with Natural for Windows, you can’t use a PF key and cursor sensitivity to drill down to detail screens. This problem is much more easily resolved with Natural for Unix.

My client has a list of two dozen source code incompatibilities, involving over a thousand individual modules. And that doesn’t include JCL conversion.

I expect your Natural developers to dislike the move from mainframe to Unix due to the differences in the user interface and IDE. I recommend that you take some of your savings and invest in Natural Development Server (NDV) and one of the graphical interface products - Natural for Windows (my favorite), Natural for Eclipse, or NaturalONE. Your developers will love it, and it will boost their productivity at the same time.

Consider calling in some experienced help for the short term. It will be cheaper than figuring it all out yourself.

3

Just to add to Ralph’s comments; not only will your developers love Natural for Windows (for example), so will your client. Dialogs can be employed instead of Maps (or Input statements). The resultant interface is far more user friendly. The “unit” of input/output goes from a screen at a time to a keystroke at a time (if needed).

Add in the capabilities afforded by the eclipse platform or NaturalONE and you have not only changed platforms (saving money, a real plus for the client), you have also put a fresh coat of paint on the house, making it far more attractive to the residents.

steve

4

Hi Sven,

I can’t comment on the COBOL as in all the porting projects I’ve been involved with we’ve only had a handful of small COBOL programs that were called from Natural. We simply re-wrote them in Natural.

Most of the “issues” encountered when porting a Natural/Adabas application are related to the change from EBCDIC to ASCII. As Ralph said, the complexity of the conversion can vary widely depending on how the application was designed e.g. use of hex values, binary fields, alphas redefined as numerics, collating sequences etc. Having said that, you can expect the vast majority of your code to simply compile and run.

Depending on the size and structure of your Adabas database(s) the conversion can be a lengthy and, sometimes, complex process. If the data volumes are small and you have a large enough down-time window for the port, you should be able to use the standard conversion method (unload, decompress, transfer, compress, load). However, if there are any “clever” data structures or you are pressed for time/have large amounts of data, you might want to look at Adamagic from CCA Software (Treehouse).

A large, complicated batch environment will add considerable complexity (and cost) to the port. There is no JCL equivalent on Unix and you will need to convert to shell scripts. There are companies that have tools that can automate some of this work for you. Then there is the issue of scheduling…

I second, Ralph’s suggestion on calling in some experienced help, at least initially. I know SAG has experienced people and tools that can help in the scoping of the project. They can, of course, fly in and do it all for you as well (for a price). Much of the remediation work is sausage machine stuff and, if you have the resources, the more of your own people you can devote to the process the lower the cost; the application knowledge will help as well.

It probably isn’t unreasonable to expect a return on the investment on the porting project to occur in 3-5 years but YMMV.

Take heart from the knowledge that this process has been undertaken successfully by many others before. There are very few Natural/Adabas workloads that I know of that couldn’t run and performas well or better on an Open Systems platform. Adabas is lightning fast and scalable with SMP out-of-the-box; there are sites that average many thousands of Adabas calls per second.

Please take Ralph’s recommendation of investing in a graphically IDE seriously if you value staff retention and productivity. Except for eclipse-based Natural, I’ve worked in all the Natural development environments and I know which one that I prefer and work most productively in.

While the capital and running costs of an Open Systems platform will be lower, don’t forget to factor into your hardware design and costings, the things you take for granted on the mainframe; redundancy, availability, etc. Miss them and the savings could be costly. Have you considered staying on the mainframe and porting to z/Linux…

Good luck with the project.

Cheers,

Graeme Lane

5

Sven,

here are some related discussions:

http://tech.forums.softwareag.com/viewtopic.php?t=265
http://tech.forums.softwareag.com/viewtopic.php?t=7388

Matthias

6

Wow, these are fantastic comments with great details and supplemental sources. Thank you so much for these comments. They will help my client and the other developers here to understand what we can look forward to.

Regarding Windows vs. Unix, we might be able to test Natural on both in our shop, assuming we can get trial software from Software AG. Have not checked into that.

7

Sven,

If you get around to doing that test on Windows and UNIX, I would be very interested in the results - especially as to database performance on each platform.

I have done 2 migrations from mainframe to Windows but in some cases batch jobs run slower than the mainframe. These are intensive processing jobs with extensive CALLNATs and a lot of writes. Read only database access is blindingly fast on Windows, as are sorts and other utilites.

8

I echo the points raised above, especially the collating sequence issue and JCL to script conversion. Also things to consider are what level the source is compiled at on the mainframe. Some source will behave differently when ported if it is still compiled at 2.2 or below on the mainframe.
There are also some slight syntax differences that will be picked up in the CATALL.
Basically there will be remediation to be done.
Also be aware there is no ADASQL on UNIX so your COBOL migration might be problematical.
Another thing to bear in mind is bringing over packed data, if it is buried within a redefined alpha field it will not get converted in the unload, port, reload process.

9

Ahhh, the comfortable feeling of rational IT discussion, what a breath of fresh air. It’s been a long time.

Remediation to be Done - I can well imagine.

Giles, when you mention collating sequence, is that another way of referring to the ebcidic vs. acii character sets?

Our Natural installation is something like 4.2.3. I have no idea what our Cobol compiler is, but I can see that will be a separate branch of conversion from Natural.

Clearly there will be a lot of work. Not a snap job as I described in the post originating this thread.

Will post as this project proceeds, including info about performance asked by Garry.

10

Yes, e.g. often on the mainframe ranges are controlled by using A’s as a start point and 9’s as an end point rather than low-values and high-values. This code will not work on UNIX (ASCII).

11

Just to expand on Giles comment: programs will sometimes have comparisons (“if #a > ‘Z’ then must be numeric”) or other validations, sort breaks, etc that assume number values are greater than alpha values or that anything less than ‘A’ is an invalid character.

Also watch for comparisions, examines and such that use hex values.

Not hard to fix, just sometimes hard to find.

12

In relation to Giles last point about the packed data, if you are loading to an Adabas database and you bring the data over in binary format, Adabas will handle the packed data. Adabas has a conversion utiltiy which will simplify the data transfer, or alternatively if you are using FTP to get the data down, be sure to use the SITE=RDW option.

13

and read/histogram start and end-points. Like:

read someview by somekey starting from 'AAAAA' ending at '99999'

EDIT: Sorry, that’s just what Giles means. :oops:

14

NaturalONE Community Edition is now running on the PC at my desk. This is in Windows, not Unix, but for now this is our test platform.

Purpose of this post is to request validation or correction of my plans for copying Adabas DB from the mainframe to the PC installation of Adabas.

I was thinking I could copy the latest Adabas backup file we make each night onto my PC, then load (restore?) that database into Adabas on the PC. Is that the right idea?

Our Adabas database is comprised of about 20 “files.” File 1, File 2, etc… I don’t know if that affects the process for porting the DB from the mainframe to Windows.

The size of our DB backup file, which I think contains all the Adabas files, is about 20G, which I am thinking can be copied as one one file to the PC. Our utility for copying from mainframe to PC includes option for EBCDIC to ASCII. I understand from notes above there can be other aspects to the conversion.

Once the Adabas backup file is on the PC, I do not know how to “restore” it to the PC Adabas. I don’t know if each file has to be restored separately, of if there is a way to just restore all the files at once with a simple command. I realize this is a very basic question, that must be answered in Adabas NaturalONE documentation. I am asking, because it is my experience with other database systems that it helps to have a conceptual walk through of the process with other developers, before getting into the details provided in documentation.

On our mainframe, we have DBAs who handle all our Adabas operations. I am in our Natural programming group. We just read/find/store/update data through Natural into the files/tables/fields made available to us by the DBAs. This is why I am so unfamiliar with Adabas operations. I can get help from our DBAs, but it helps if I am certain I know what to ask for when approaching them.

Any comments, suggestions, references, etc. that anyone can provide will be extremely much appreciated.

15

I just found documentation for ADABCK, which appears to be the key the DB port I am contemplating. I think I just need to work with our DBAs to get the output file from the mainframe ADABCK operation we use to backup our database, assuming our backup uses that utility. If our backups use some other utility, I am thinking I need to work with our DBAs to run ADABCK on the mainframe, then copy the backup file to the PC with the EBCDIC/ASCII conversion, then run ADABCK to restore the DB on the PC.

I imagine there are a few wrinkles, but this seems to be the roadmap, if I am understanding correctly.

I still am looking for any comments, warnings, suggestions, alternatives, advice anyone with experience in this process has to offer.

Best regards,
Sven

16

There is a 3rd-party product that runs on Windows and reads a mainframe backup, but if you rely on Software AG products, then you need to extract the mainframe files individually.

As posted here: http://tech.forums.softwareag.com/viewtopic.php?p=66857&sid=1efa4248673fa229de7ce994a1577dc5#66857

. decompress each mainframe file with RECORD_STRUCTURE=RDW and SOURCE_ARCHITECTURE=(EBCDIC,IBM_370_FLOATING,HIGH_ORDER_BYTE_FIRST)
. transfer each file with binary FTP and SITE RDW
. compress each file on the target with RECORD_STRUCTURE=RDW and TARGET_ARCHITECTURE=(EBCDIC,IBM_370_FLOATING,HIGH_ORDER_BYTE_FIRST)

17

Thank you, Ralph. Perfect information, I am very much obliged and grateful.

This forum is so awesome. My boss granted me small amount of time to investigate the feasibility of cutting costs by moving from IBM Mainframe to Unix or Windows. I really could not be more pleased with the completeness, quality, focus, and overall excellence of the response from this forum.

For good reasons above my pay grade, our shop is putting this project into our queue, while we complete a previously-scheduled project. Based on the information from this forum, plus the research I was able to do on my own, I think this project has a chance to fly once we finish the project we are doing now (expanding one of the fields used throughout our system, including quite a few control keys and super descriptors.)

So, looking forward to getting back to this soon. I just want to thank everyone again, and pay my respects to the clarity, responsiveness, and value of this forum. Especially considering the dark where I started just a week ago, I feel I was able to get huge amount of reliable guidance in a short period of time.

Best regards,
Sven

18

We are migrating also from Mainframe to Linux, Natural will be okay, but we decided here to convert all Cobol programs into Natural.

Not having Cobol in Linux will save us a lot of money.