Mainframe to iSeries migration question regarding COBOL Source Code

Posted on 2007-10-03
Last Modified: 2012-05-05
I am working on a project to migrate a COBOL system from an IBM mainfarme to the iSeries platform.
 have a simple program that It is a called sub-module without input or output.  It passes information in the linkage section (parameter list) and returns a number.  Very simple.  

Can I transmit this file from the mainframe (via a company supplied clist) to the AS/400 so it can be put into a users library (?) and compiled?  I want to avoid retyping code, etc.  Further, our goal is to transmit these simple programs, compile them on the AS400, test them via an interactive application and then send the source code back to the Mainframe for compiling and releasing.  
Question by:pmac38CDS
    LVL 13

    Expert Comment


    Two options come to mind:
    1) FTP to send the source back and forth. You would need to write the scripts.
    2) Distributed Data Management (DDM) files
    Assuming they are supported in your mainframe world, these files act as pointers to files on remote systems. On the as/400, you would be able to display and copy the source files back and forth.

    If you want more details or have questions, post back!
    LVL 57

    Expert Comment

    It sounds more like you want to test the programs on the iSeries but run them inproduction on the mainframe.   There are some z/OS (assuming this is your mainframe OS) unique Cobol extentions.  If you are using any of these, then you will have problems using the iSeries platform.

    You may have other problems.  Cobol code is not always cross platform compatiable.  You need to know what enviroment the Cobol program runs in.  Examples:

    If you are running Cobol against a DB2 database, then in order to test on the iSeries, you would need to have DB2 and the same database on the iSeries.

    If you are running the programs under CICS, you would need CICS on the iSeries.

    LVL 26

    Accepted Solution


    Options for FTP and DDM/DRDA are reasonable choices for transport. Connectivity might be based on TCP/IP or SNA (possibly one encapsulated in the other). Elements such as SQL and CICS don't seem relevant to _this_ particular module based on your description, but will need attention eventually.

    In a sense, it doesn't really matter much what file-form the source is in. You could copy/paste it into a .txt file and FTP it if you wished. Once under i5/OS, it can be placed into a source file "member" for standard compilation.

    Beyond those, it wouldn't seem there'd be much problem for _this_ case; this sounds like a basic test to determine later procedures. Transfer the source and compile it, either as a module for binding into a program or as a single-module program object itself. Command CRTCBLMOD will compile the module; and CRTBNDCBL will compile it and bind it as a standalone program. (Those assume ILE, which is similar to LE. Some COBOL _might_ fit better in the OPM environment, but I wouldn't expect it. Compile for OPM with CRTCBLPGM.)

    When you get to the point of modules that require I/O or that call external procs that are mainframe-specific, all of the usual cross-platform stuff will come up. Obviously, you'll want to review the ILE COBOL (and _maybe_ the COBOL/400 for OPM) manuals for differences.

    Example differences -- REPORT RD sections don't exist under i5/OS; convert to externally-described printer files, like externally-described database and display files. And, e.g., divide by zero adheres closely to the COBOL ANSI standard rather than throwing an exception.

    In any case, as long as platform-specific issues don't arise, this should be possible without much difficulty. AS/400s were originally architected to communicate with IBM mainframes. Pretty much everything from those days still exists.


    Expert Comment

    One possible problem is that IBM COBOL is usually upwardly-compatible, but not downwardly-compatible. I.E. AS400 COBOL will nearly alway compile/run on an IBM Mainframe, but not the other way round. This is often due to the previously-mentioned unique Mainframe COBOL extensions. With simple code programs, these may work, but you can never predict when the simple programs use a code extension or unique Mainframe-specific verb format or parameter.

    Featured Post

    Better Security Awareness With Threat Intelligence

    See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

    Join & Write a Comment

    If you're not part of the solution, you're part of the problem.   Tips on how to secure IoT devices, even the dumbest ones, so they can't be used as part of a DDoS botnet.  Use PRTG Network Monitor as one of the building blocks, to detect unusual…
    The recent Microsoft changes on update philosophy for Windows pre-10 and their impact on existing WSUS implementations.
    This video is in connection to the article "The case of a missing mobile phone (". It will help one to understand clearly the steps to track a lost android phone.
    Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

    728 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    17 Experts available now in Live!

    Get 1:1 Help Now