Mike;

There must be more to it in migrating a program (Cobol compiler ) written in C that uses many Linux components (Bison springs to mind but there is a lot more) that accesses files both in the current directory and in specific one's (e.g., /usr/local/lib/ and others).

I do not think just recompiling using the IBM C compiler is enough somehow. Otherwise it would have been done some time back - unless someone knows better ?


As it is I can use the compiler's in OS/390 or Z/OS such as :

IBM COBOL for OS/390 & VM  2.1.2

or

IBM Enterprise COBOL for z/OS  4.1.0


But there appear a lot more complex for building a few simple accounting applications that I have running under gnuCobol on Linux that I have now made Open Source on sourceoforge.

A long time ago they did use CICS (1970's) but al that was replaced using SCREEN SECTION which has its own problems if running in a GUI environment such as Linux KDE/Gnome or even - if you have to - Windows)

I am not really up to putting CICS back into them assuming is has seriously been improved for working on PC's -0 which I doubt.

Possibly better to try and change them to support using via a web browser which would be a long - process as I have never tried such, but hay, I am retired with a far bit of time on my hands.

The other issue I have is trying to work out how to get any kind of printed o/p from both O/S's to my PC and then to a PDF file as I have under MVS 3.8. JES2 only seems to understand a 3800 and not a simple one like a 1403. The former is far to fancy in its handling to just transfer over to a PC and print out without a lot of control and other junk chars getting in the way. Not helped by the JES2 paramw able to be in so many different places in the system - applies to both OS's.

There was a time - OK, MVS days when you could get 1/2 books that would cover most of what you needed to do and give references to the primary IBM docs for the others but that seems to have vanished now with the current O/S crop - or is it I am getting to old (68 shortly)!

Vince


On 24/04/15 17:26, Mike Schwab wrote:
GCC handles the differences between Open Systems and CKD disk.  Just
like z/Linux looks like open system files.

On Thu, Apr 23, 2015 at 7:42 PM, Vince Coen <vbc...@gmail.com> wrote:
Did think of that but .. as GNU Cobol is written for Linux I think migrating
over to the mainframe will take a lot of knowledge I do not have, such as:

1. Dealing with the different way files are handled.
2. Working out how to get the separate elements that make it up (along
     with the different libraries to be added and linked together.
3. any other things to get in the way.

There must be a reason why no one has done it and I was not a Systems
Programmer but an application one using in Cobol sometimes in C, ADA,
Argol68R, Fortran, REXX and BAL and Macro Assembler - a very, very long time
ago ooh, yes nearly forgot RPG for migrating unit record equipment over to
the mainframe - in the 60's. Crap am I that old,  nuts.

Must have forgotten a few

Vince


On 24/04/15 01:17, Mike Schwab wrote:

GCC370 and GCC (380) are available to compile it.

On Thu, Apr 23, 2015 at 7:11 PM, Vince Coen <vbc...@gmail.com> wrote:

Exactly, although I run it on a AMD FX8350 along with a BBS, web and ftp
servers and other stuff including links to OS/390 and Z/OS when I am in
the
mood to see what more modern stuff is about/going.

At least the later Cobol compilers tends to work a lot better than ANSI
Cobol which was always a dog at least on the site's I worked at so when
OS/VS Cobol came out it must have been the fastest migrations in history
:)

Pity I can't find a more recent compiler to use under MVS Turnkey 4 Upd
7.

Now the next trick and no I don't know how is to migrate GNU Cobol v2.n
(was
Open Cobol) over to it which has a few functions over the current IBM
offerings.

OK, may be not in my lifetime.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to