Why use ILE? What are the advantages & disadvantages?

[Guest.Visitor]

O.K Susan, A couple of questions here, which are : Does this project entail using ILE Cobol, or will it entail using ILE RPG IV as well? Is there existing OPM code(Cobol and/or RPG) that will be used? BTW - there's nothing wrong with that. If you are interested in binding, creating ILE programs, activation groups etc - with a ILE Cobol perspective included your shop is welcome to check out those articles that I mentioned. Those would be Oct. 1998 (Binding, creating programs etc) and March 1999 (Activation groups). The reason I included ILE Cobol examples, is that I knew that ILE Cobol were far and few between. The few "examples" of ILE Cobol that I read about, were some very pretty theories with zero practical value. Basicly they told you how to build a beautiful, exotic swimming pool complete with fancy fountains and decorated with expensive tile - but they never mentioned where to find the shovel, how to mix the concrete, or even where to get the water in the first damn place. What's a few technicalities? This is just an analogy, but my point is clear. Since I had been there, and done that, and not recieved any pity; I felt pity for those who might possibly follow. As far as an ILE primer, well there some good ones - in RPG IV, CL and a little C. If you find one in ILE Cobol let me know. Personally, what I do is read the RPG IV and/or ILE C examples and then figure out how to do it in ILE Cobol. Feel free to contact me at my home e-mail address of mvm@doitnow.com. If you don't have those articles I can fax you copies of them. On an message ending note, let me say one thing - ILE handles dates way better than OPM can even dream about. Every application that I've ever worked with required serious date manipulations. Unless your shop wants to practice OPM date routines, which by in large are very prone to serious problems(not always but I sure seem end up with the insipid date disasters), I'd go with an ILE solution. Good luck Susan, you are an adventurous and brave woman. I have confidence in you.

[nycsusan@hotmail.com]

Does this project entail using ILE Cobol, or will it entail using ILE RPG IV as well? Cobol only. No other language is allowed (not my choice). Is there existing OPM code(Cobol and/or RPG) that will be used? BTW - there's nothing wrong with that. Yes, there is a LOT of exsisting OPM Cobol and the new programs will have to interface with them peaceably. The plan is to rewrite those in ILE at some point down the road. This is an online Customer Service application with thousands of users on 3 production machines, in case that matters. I will check out the resources that you suggested. I am out of the office in a class all this week, and next week I have Jury Duty. I mention this because it may be a while before I get back to you. If I cannot find them online, I probably will need the articles faxed to me. Thanks Mario!

[Guest.Visitor]

Susan, you can't go wrong if you read href="http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3AQ702/CONTENTS"> ILE Concepts (http://publib.boulder.ibm.com:80/cgi...AQ702/CONTENTS). It's quite readable. Also, the Programmer's Guides for the various ILE languages all have some fairly straightforward basic information. I'd read the "creating a program" and "running a program" and "activation group" related bits from all three (RPG, COBOL, C) first (you'll start to see some patterns), then I'd read ILE Concepts.

[*] href="http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3AGY01/CCONTENTS"

ILE RPG Programmer's Guide[*] href="http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3AG400/CCONTENTS" ILE COBOL Programmer's Guide[*] href="http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3AT700/CCONTENTS" ILE C Programmer's Guide[/list]While a lot of IBM documentation isn't ... um ... readable, this stuff isn't too bad.

Barbara (any opinions are my own and shouldn't be taken to represent the opinions of my employer, and anyway, today is a vacation day (clearly, I have poor vacation skills))

[R.Daugherty]

Barbara wrote: "(clearly, I have poor vacation skills))" lol, maybe the first flaw we've seen, Barbara.... Ralph

[David Abramowitz]

Barbara Morris wrote: While a lot of IBM documentation isn't ... um ... readable, this stuff isn't too bad. Actually, IMO, it's very good. What I object to, is that IBM has ceased the practice of including the "Reference" guide with any language that's been ordered. Dave

[nycsusan@hotmail.com]

This is the sort of doco I was needing. Thank you Barbara.

[Guest.Visitor]

I think another advantage of using ILE is that is starts you thinking about object orientation, specifically, component reuse and modularity. If your shop does decide to do a conversion to an object oriented language, the programmers will have an easier time adapting to whatever language is decided upon.

[nycsusan@hotmail.com]

I think another advantage of using ILE is that is starts you thinking about object orientation, specifically, component reuse and modularity. This is the stated reason for dictating that the new code be written in ILE Cobol. Since I am in a philosophical mood lately - why can't regular OPM programs be written this way? I am still unclear in my head as to the difference between using lots of called subroutines and the "OO" Design. (Or "Ooooh" technology as my friend likes to call it!) I am very used to working with small and very reusable subroutines using normal Cobol, RPG, and CL. We would call them "black boxes" precisely because we didn't have to know or care how it worked, we just knew that it did. We called it and it returned the info we needed. Why is this not "OO" technology? What is the difference? I do know that Java can be coded in a procedural structure. I know because I did it in my very first Java class, accidentally of course. I don't understand why regular Cobol and RPG programs cannot be coded in an OO way. Granted, most are not, but is that because we can't code them in an OO structure? Or is i t because we won't code them in an OO way?

[Guest.Visitor]

I guess the main difference between OPM and ILE and that you can do prototyped sub procedures in ILE and I don't think it's possible in OPM. True, you can make small modular programs in OPM, where, as you said, they are black box programs, and you don't really care how they work, as long as they work. ...but, as Steve Todd stated, it's more work.

[Guest.Visitor]

Susan, regular programs CAN and should be written that way. You can use code-reuse and modularity concepts in any language. Conventional OPM wisdom said that making calls was expensive, so it was better to write a 20,000 line program than to split it up functionally into several programs(*). Maybe when ILE came along with the claim that calls were faster and smaller programs were better, this old rule was thrown out and people felt free to write the smaller programs that good programming demands. (*)A good example of one of Knuth's laws, that premature optimization is the root of all evil. With an OPM single-entry-point program, it's more difficult (but in no way impossible) to say create an abstract data type. In ILE (RPG at least - I don't think COBOL has multiple entry points), you can do an ADT the usual way, with one module having procedures for create, init, destroy, doThis, doThat etc. In an OPM program, you could do the same thing but the interface would be uglier, since you'd have to set up the parameters for the program to handle the interfaces for all the functions. Or you'd have to have several programs all talking to each other, which makes it impossible to have a truly private implementation, and makes it difficult to change the internal implementation (for example, array vs file) once the programs are in use.

 I know everyone doesn't think this way, but I think there's something about being able to code c eval x = someFunction(y) versus c call 'SOMEFUNC' c parm x c parm y or c move x somesubr1 c exsr somesubr c move somesubr2 y /copy somesubr that seems to make code-reuse more attractive. 

ADTs, modularity, and code-reuse aren't particularly OO anyway. "OO" usually entails inheritance and polymorphism. These are the OO-ish things that are difficult (but again, not impossible) to simulate using non-OO languages. Barbara