New to these boards and just starting a new project where we are planning to move our very old Mainframe system to a very new Unix system.
We didnt really have the choice of the versions we were going to, just told that this it.
I am wondering, has anyone made this big of a change. There is a lot of versions of Natural, Adabas and Perdict we are skipping. Plus a whole new environment.
Just looking for some major problems we may run into with this kind of project. We are in the very very earily stages, but would just like to get a feel for what I will be in store for.
Forgot to mention that the Unix system is already up and running, it is our task to transfer all the files, programs and everything else over to the new system.
First of all: I’m not the expert on migration from mainframe to Unix. I never did such a project. But is sounds like an interesting and challenging work.
we made such a (big) change 5 years ago from OS/390 to HP-UX with our SCM-Software (SupplyChainManagement). Starting from scratch, we moved the systems within 6 months.
The big issues we had to solved i remember are
a) EBCDIC to ASCII conversion. this have influences on the collating-sequence, e.g. in find with … starting from or from … thru or in all sorting-tasks.
aa) using of hexadecimal values/constants in source-code
b) redefines of alpha-Database-Fields with binary or packed data. ADABAS ist not able to convert this automatically.
c) Usage of external COBOL/ASSEMBLER etc. programs.
d) converting the JCL to shell-scripts (we used a conversion program and a template-engine for our 2000 batch-jobs)
e) Usage of GDGs (generation data sets) which are not available unter unix (we had to “invent” it for unix again)
f) Batch-Jobs started by the users (tracing, logging)
ff) tracing and logging of batch-jobs
g) output-management und -archiving including sending output via mail to the user
To analyze all our sources we wrote a visual-basic (VB6) program.
Our systems are running with actually up to 20000 Natural-Objects, 400 Users worldwide, approx. 3500 batch-Jobs per day.
Sorry it has been a long time, been away and very busy. The problem I am investigating right now is that we are suppose to be going backwards when we go to the new system.
Right now we use the ASCII table on the mainframe, but when we go to the new UNIX box it will be using the EBCDIC table. Odd I know since that table is older.
I know that the tables are reversed when it comes to 0-9 A-Z a-z. I am wondering how this will affect our AT BREAK and SORT statements.
We are going from Mainframe 2.2.8.+++ to Unix 6.1.1 or so, and the platform is a IBM Midframe P570 Box using VT100 emulation. On the mainframe we use 3270.
the UNIX-World is “speaking” ASCII, EBCDIC is used on the (IBM-)mainframe (/370-architecture).
anyway, the difference in the collating-sequence is real. The sequence of Letters and digits is reversed.
As far as i remember the “at break” and “sort” was not a big issue for us. but with find- or read-statements with a starting- and/or ending-value you will have troubles with statements like
"read xxxx starting from “AAA” ending at “999”
. This works on mainframe with ebcdic, but not on unix with an ascii-character-set, because “A” is greater than the digit “9”.
The same problems occurrs using operators like greater, less on characters/Alphanumeric Fields.
imho the only way to fix this problem is you have to scan the sources for such statements and rewrite the code. Sometimes it is best practice to use named-variables like “#Low-Value” or “#Hig-value” instead of “AAAA” or “9999”. Then you only have to change the init-values for this variables.
"the UNIX-World is “speaking” ASCII, EBCDIC is used on the (IBM-)mainframe (/370-architecture). "
We have already asked them 100 times why we are going backwards in technology when we are moving forward in everything else. It is to be the EBCDIC table and VT100 emulation on the Unix box.
i assume, you will have AIX on the p570 machine, right?
We have already asked them 100 times …
Who do you asked? IBM or SAG or someone else?
… why we are going backwards in technology …
indead, the 3270 and vtxxx-Technology are different from a technical point of view (vtxxx is an asyncronous 7/8-bit ascii Terminal, based on the TelNet protocol).
but vt100 is not the first choice if you come from 3270. With our vt-Terminal-Emulation we are “using” a vt340+ Terminal, which has full ANSI Color support and it is nearly like the 327x Emulation, as we use with “IBM Personnel Communication”. We are using all the PF-Keys we have on the 3270 and the capabilities of the mouse on the client-pc.
Its not a matter of the vtxxx, but its functionality of the Terminal-Emulation-Program on the client (we are using KEA!340, but there are many other Emulators with a similar functionality on the market)
with vt340+, natural (6.1.1.17) gives you the full color-support like a 327x-emulation on Unix.
One of the biggest issues with telnet/vtxxx is the distance and the speed (bandwith) between the Client-PC and the the Unix-Server, because every character is first send to the server and from there send back to the screen. We have users around the world, all working with the Servers located in Germany. Users in asia and australia are using the vt340±emulation via citrix, due to the better speed of citrix.
ebcdic: it is possible to receive data in ebcdic. we have a lot of interfaces where we receive the data (e.g. from MVS) und translate “field by field” the records into ascii, due to the “decimal-packed” field-formats used on some interfaces. imho is these the only reason, to handle ebcdic-data on unix.
I just wondering how you managed your cobol programs calls from Natural; through a shared library I guess.
However, the only examples provided by SAG are in C language.
Can you tell me please what modification I have to do in the cobol source to be called fro a natural program on Unix ? I think about the natuser.h equivalent, the NATFCT declaration, …
I just wondering how you managed your cobol programs calls from Natural; through a shared library I guess.
However, the only examples provided by SAG are in C language.
Can you tell me please what modification I have to do in the cobol source to be called fro a natural program on Unix ? I think about the natuser.h equivalent, the NATFCT declaration, …
Yes, if you don’t want to link the subprograms static to the natural nucleus, you have to use a shared library.
I suggest to use a shared library (.sl/.so).
It should be not a big issue for software ag to provide some examples for Cobol.
I don’t know the reason why the didn’t.
I would suggest to let the cobol-source unchanged (if it is possible to compile the source without errors).
To use this subprograms from Natural, you have to “write” an interface/adaptor-program in c for each cobol-program.
Thats the way we did. We used “HP Micro Focus Object COBOL”.
The name of the c-program should be the same as used in the CallNat-Statement (to avoid a lot of changes in the Nat-sources).
The name of the cobol-Programm has to be changed (give them a suffix/prefix).
To make the creation of the c-program as easy as possible you should use the macro-capabilities of c or a template-engine.
The general functionality of such an adaptor-module is
a) check parameters (number, types, sizes) if desired,
b) initialize cobol-environment
c) call cobol-module with (translated) paramlist
d) check return-code
e) terminate cobol-environment
f) return to natural
The initialization of the cobol-environment could be done by startup of the application (on MVS we had to call IGZERRE once).
Interesting, we in JTF are just experimentimng with Natural ADABAS on Windows XP Pro.
JTF has written some applications - prototypes (almost full blown apps) that can be moved between mainframe and laptops (some with very minimal changes - eg. list box).
You seem to be based in Canada. Give me a call 905 828 4142 or email f_imtiaz@hotmail.com for me to see if it possible for me to demonstrate and share experiences.