Rehost NATURAL / ADABAS from mainframes to Windows / UNIX

, , , ,
1

Dear Experts,

I want to rehost a meduim size application built primarily on NATURAL / ADABAS from mainframes to Windows / Unix.

I have the following questions:

  1. Do we have a standard tool available from SOFTWARE AG to acheive the same?
  2. What things we must consider / be careful about for this migration?
  3. Any tips and directions to proceed?
  4. We also make use of JCL’s. Any replacement available for the same on Windows / Unix?

With best regards,
Vikas

2

This is a substantial undertaking - a huge topic. I suggest you search the Forum archives, as all your questions have already been answered. Then you can fill in the missing bits by asking specific questions that can be more easily answered (i.e. briefly).

3

Arguably the most important part of Ralph’s post are the first five words:

“This is a substantial undertaking”

Take this to heart. Your project is not just a matter of copying files and recompiling Natural code.

You will be traveling along a path (EBCDIC to ASCII) loaded with traps for the unwary. Make sure you understand all pertinent implications.

For example, in the existing code there might be code like:

FOR #LOOP = 1 TO #LENGTH
IF #ARRAY (#LOOP) = H’40’
:::::
ELSE
::::
END-IF

Clearly the program must treat blanks (H’40’ on mainframe) different than other characters. BUT, a blank is H’20’ on a PC. You would be okay if the IF said = ’ ’ since the blank would be treated properly on both platforms. However, through the years, there has been lots of such tests that are platform specific. You had better find them.

Pay careful attention to anycode that involves “sorting”. This includes logical READs, FINDs with a SORTED BY clause, SORT loops, IF statements, EXAMINES, ad nauseum.

Just for the fun of it, here is an excerpt from Wikpedia:

“ EBCDIC: /eb´s@·dik/, /eb´see`dik/, /eb´k@·dik/, n.

[abbreviation, Extended Binary Coded Decimal Interchange Code] An alleged character set used on IBM dinosaurs. It exists in at least six mutually incompatible versions, all featuring such delights as non-contiguous letter sequences and the absence of several ASCII punctuation characters fairly important for modern computer languages (exactly which characters are absent varies according to which version of EBCDIC you’re looking at). IBM adapted EBCDIC from punched card code in the early 1960s and promulgated it as a customer-control tactic (see connector conspiracy), spurning the already established ASCII standard. Today, IBM claims to be an open-systems company, but IBM’s own description of the EBCDIC variants and how to convert between them is still internally classified top-secret, burn-before-reading. Hackers blanch at the very name of EBCDIC and consider it a manifestation of purest evil.”

Another popular complaint is that the EBCDIC alphabetic characters follow a punched card encoding convention rather than a linear ordering like ASCII. One consequence of this is that incrementing the character code for “I” does not produce the code for “J”, and likewise there is a gap between the codes for “R” and “S”.

An I was a twelve (high) punch and a nine punch; a J was an eleven punch and a one punch.

These incompatibilities were also the source of many jokes. One such joke went:

Professor: "So the American government went to IBM to come up with an encryption standard, and they came up with—"
Student: "EBCDIC!"

Have fun, and be VERY careful. Do a lot more testing than you probably think would be necessary.

4