Re: COBOL ILE

Greetings Geir;

The old adage is good - If it ain't broke, don't fix it.

Start when there is a major change to do, or a complete new system or rewrite.  Start by using the date, time and timestamp data types in your files and programs.  Utilize the intrinsic functions.  The can all be done without changing a bunch in the program.

You can simply take your old code, and change the type to CBLE (or is it CBLLE? not at work, can't remember) and recompiling.  This will USUALLY work fine, but there are some issues where ILE COBOL works different than OPM COBOL.  I don't remember what exactly they are, but it has to do with running in different activation groups.

ILE is best for modular programming, and that means breaking up the programs into modules that do a particular function. You might look at the procedures in your programs and seeing if there is common code in them.  Put the common code in to a module (each module being unique) and then putting the modules together in service programs.   (Please see the other message I posted)

Then you have to make a choice about binding the program modules together.  There is "static" binding and "dynamic" binding.  The difference in programming is how the call works.  The difference in compiling is that "static" is bound into the program at compile time and the 1st run is faster.  If you call a module 1,000,000 times each night from another program (new instances), you will get better performance with "static" binding.  You will also have to recompile all programs that have the module bound to them if/when that module changes. 

Dynamic binding happens at run time.  This means that the first call will be slower as the AS - iSeries 400 resolves the binding on the fly.  All subsequent calls to that module will be just as fast as the "static" bound program. The nice thing about "dynamic" binding is that you can change the module being called, and the next execution of the calling program will pick up the change.  This might be the best choice if a module is used in a lot of programs.  You would then have the ability to make the change one time, and then all the programs that use the module would be up to date the next time they run.  Great for those common functions such as (for our shop) interest calculation changes and applying payments to accounts.

You also can take advantage of activation groups and pointers, if you want to get into those things.  Pointers can be great for system programmers who would like to use some of IBM's API programs to get lists of spool files, users, etc.  It took some time to get my mind around the pointer concept, but I do like the function. 

There is a bunch more, but then there always is.  Hope this helps you get started.

Jim Essinger
Senior Programmer/Analyst
Student Loan Fund of Idaho
Work: 208-452-4058
Fax:    208-452-5848
A

t 09:30 AM 5/28/2001 +0200, you wrote:

Hello, Rick.

You are obviously in a situation just like a lot of us old 'OPM'ers'.  We know that ILE exists, and we recognize the advantages,  but how the h... shall we get started??  If anybody out there have good ideas, adresses to useful web-sites etc. I would greatly appreceate it. 


Mvh.

Geir Kildal




"chocolate_thunder1" <chocolate_thunder1@yahoo.com>
Sent by: owner-cobol400-l@midrange.com

26.05.01 04:50
Please respond to COBOL400-L
       
        To:        <COBOL400-L@midrange.com>
        cc:       
        Subject:        COBOL ILE



Hello All,
               I'm trying to find out more information on COBOL ILE on the AS/400.  I'm  not new to AS/400 COBOL but very new to ILE and some of the concepts. (Binding  directories, Service Programs, etc)  I have a project that is coming up and  I would love to do it in ILE but I need to get a comfort level with it  first.  I don't want to just write OPM's and then make them ILE I don't  believe you get as much bang for the buck that way.  I would really  appreciate any suggestions!! 
 
Thanks in advance
 
Rick Smith
 

+--- | This is the COBOL/400 Mailing List! | To submit a new message, send your mail to COBOL400-L@midrange.com. | To subscribe to this list send email to COBOL400-L-SUB@midrange.com. | To unsubscribe from this list send email to COBOL400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---END