System iNetwork

So what are you saying? Are you telling us it is all about the code or all about the best way to solve problems?

One fundamental problem solving technique is called problem decomposition. Basically, it means that within each large problem is a set of smaller problems that want to come out. The concept is about as old as dirt and preceeds computers.

If you do a good job of decomposition, then after you solve the smaller problems, you solve the large one. If you do a good job, you also have a set of modules that can be used for other purposes.

Problem solvers do this as a matter of second nature. The AS/400 of 1989 was capable of doing this extremely well using called programs and RPG/400. Programs that operate as code generators do this as a matter of function in probably all languages.

The AS/400 started downhill when IBM decided to promote various coding methods as being the same as modularity, as opposed to coming up with better means to solve business problems. The fussy coder became commonplace and the AS/400 started to become history.

What I was trying to say was that there are different strategies for problem decomposition or application modularization, and that the same strategy which played a role in the development of object-oriented programming also played a role in IBM's redesign of RPG with RPG IV.

I remember reading books about modular programming back in the mid-to-late 1970s which seemed to follow the conventional flowchart-type strategy, and I think this conventional approach did dominate the COBOL and RPG communities through the 70s and 80s, and perhaps into the 90s. This type of modularity worked very well under many circumstances, but didn't seem to be very agile to accommodate change. This inflexibility or "brittleness" is one of the reasons why the alternate strategy of composite applications or SOA has gained ground in recent years.

Problem decomposition which follows too closely, in a flowchart-type manner, the business processes at a given point in time may lead to a modularization which is too tightly coupled to that time-bound state of affairs, and might then be difficult to modify to accommodate later changes. This was one of the points Parnas was making, and I still read people making this point when they advocate solution assembly or SOA alternatives to "traditional" system design practices. This does not mean that many RPG system designers have not been designing agile systems for many years, even prior to RPG IV. But I think RPG IV is a much better version of RPG for this type of system design.

Lastly, I am suggesting that although RPG IV is not an object-oriented language, it does have features and capabilities which enable it to be used to develop agile applications characterized by many design practices popular in the OO world today. And I think this is because IBM was influenced by many of the ideas which also influenced the development of OO languages.

AS400 downhill! Balderdash!

__The IBM midrange community has always had a variety of programmers, good and bad, and varieties of programs.

__IBM has adapted ILE, and RPGLE, and the other languages very well IMHO to accomodate better programming techniques on a continuing basis.

__And it never lost its legendary built-in database, and its legendary built-in superiority in security capabilities. The database (and the OS and the system) now accomodates various others as well.

__The problems that the midrange community has today are pretty much the same as always. Too many programmers and/or IT managers are too comfortable with its 5250 interface and with the older programming styles, and at status quo, without getting into utilizing the new programming methods and tools available.

__And, decision-makers at the budget level often are not aware of the productivity multiplication that can come from new techniques.

__And yep, that includes the old, old techniques that are old to the general IT community.

__Get with it guys! Do your RPGLE programs with subprocedures, find out what the action groups are, what ILE can do for you, ACTGRP(*NEW) and (*CALLER), and get some mileage out of service programs! Never repeat that date manipulation code again!

"Get with it guys! Do your RPGLE programs with subprocedures, find out what the action groups are, what ILE can do for you, ACTGRP(*NEW) and (*CALLER), and get some mileage out of service programs! Never repeat that date manipulation code again! '

And why could this not be done with old RPG using 'called' programs...I have been using this method since the inception of the AS400....why is this approach so new and exciting? it's been done for years and if any PROGRAMMER worth his salt understands the business and "listens' to users he will be a good programmer....and if he is trained properly and spends the time LEARNING....I can write all the code I need to in good old simple plain RPG to handle most circumstance...I can call variable "called" programs...I can have many versions in many libraries...what is the advantage of binding programs? only thing the AS400 lacks is the GUI interface...other than that learning and doing something just for the sake of it being new is ridiculous....I have been studying and learning C# and Java and the rest and to tell you the truth plain OLD RPG is better than all combined....What the prgramming community lacks is people that understand the business they are in and they lack communication skills to deal with the user....that will not change with newer technologies...in fact the programmers are so far removed from the business...that's why ENTERPRISE SOFTWARE development is such a failure.....yes....the Googles and other web programs are fantastic...but take a look at the programmers that now abound for the regular mid -large sized business....i laugh when I read the SQL via normal RPG chain command logic...and how pitiful the discussions are about which is faster....that's not the point the point is what is better for the indiviual business....if more computer language had built in database support like the AS400 the world would be much better off....but companies like ORACLE and even IBM won't allow it....it's a cash cow...too bad IBM has taken the approach it has...the AS400 was a great machine with a great built in database....but the machine can't sell because the machine lacks the Microsoft look and feel....and Microsoft has failed miserably in it's attempt to enter and control the Enterprise environment....I have looked and looked and understand I need to take my apps of the AS400 inorder to sell but each time i come back to the fact that there is little else to move to!!!!!!!

"....I have been studying and learning C# and Java and the rest and to tell you the truth plain OLD RPG is better than all combined"

Then you just haven't learned enough about C# or Java.

RPG is good for the Q&D and native DB interface, but it has no place in the GUI-fied SQL-DB world of today. You can borrow enough C++ code from the Internet to perform nearly any task having to do with cross-platform computing and execute it on the Series i. It's all been written-to-death, peer reviewed, deployed and exercised/excised.

Computing in the modern era is more than languages and the OS. It is flexibility, incremental improvement, code reuse, Open Source and platform transportability. (Go to boost.org to get a gigantic idea of what is out there.)

There aren't a hell of a lot of RPGIV frameworks that I am aware of. On the other hand, Java is tomes thick of them as are .NET and other choices.

You owe it to your paycheck to step back and take a look at the big view to either modernize your design and programming approaches or discard them completely in sync with what will be happening in 10 years. The biggest mistake IBM made was further modernizing RPG in the face of what it was doing with the OS when it reprogrammed it in a *nix flavour.

/End of rant

Obviously (I think), many social aspects of application development can dominate the programming techniques, languages, and tools that are used; but if your job is to write code, you should be able to evaluate techniques, languages, and tools, and use the right ones effectively.

These things DO matter if you're a programmer!

In that vein, I would argue that RPG/400 isn't as capable a language as ILE RPG, and ILE RPG lacks important contemporary language features that make a difference.

First off, ILE static binding gives up precious flexibility in order to avoid the performance of OS/400 dynamic program calls and thus make the use of fine-grained "procedures" more practical in RPG.

When procedures were introduced in ILE RPG, IBM also chose to implement procedure prototypes (and chose a wonderfully cumbersome syntax to boot). The purpose of prototypes is to let the compiler check that a call is properly formed, an important safeguard for typical business programming.

Bound procedures weren't a bad "quick-and-dirty" fix for RPG's deficiencies, but they are hardly an up-to-date solution, and weren't even the best approach at the time RPG subprocedures were introduced.

First off, modern compilers, such as Java, simply inspect code in the compiled version of a procedure (or method) to determine the information needed when the compiler processes a call to that procedure. This can be done even if the procedure is in a different module (or class) simply by listing the places to search (e.g., the class path).

This approach eliminates the need for prototypes and assures that the "signature" check is done against the actual executable code for the procedure, rather than some "include" source code that may be out of date.

Why IBM introduced all the unnecessary pain of prototypes to ILE RPG remains a mystery to me.

As far as run time goes, ILE does provide dynamic procedure calls, bound at runtime, but they're not convenient to code in RPG.

OTOH, dynamic method calls are just an inherent part of Java, C#, and other contemporary languages. JVMs can even "inline" procedure code during run time as one way to optimize method calls.

= = = =

Back to Parnas, who truly shined a light on how to think about designing and implementing large software systems. Many of his points were about "interfaces," perhaps the most important being that you should design -- and refactor -- code so that interfaces implement fairly stable design decisions and the body of a procedure implements the design decisions that are likely to change. (This simple and profound insight is one of the reasons it makes sense to "hide" I/O within functional modules.)

Parnas (and others) also recognized the concept of modules and procedures (what he calls subroutines) being able to be inter-mixed in layered code. A module was (and is) simply some shared data accesible to one or more procedures.

What Parnas didn't fully express back then was that a module actually describes a "data type". However, with a normal module, you could have only one instance of this data type in your application (unless you wrote the plumbing code to allow for more than one).

Programmers and language designers soon realized that it would be nice if you could have an "Order" data type with some shared (and hidden) data operated on by a set of relevant procedures. And, most importantly, you could then declare more than one "Order" variable, or you could have a set of "Orders" and each such "Order" variable or instance would have the same set of operations, but private data values.

If you like the iSeries and the S/38 that started the whole line, one of the reasons is probably because the system architects had learned this concept and created an "object-based" machine interface and operating system.

When you use CrtPF, you're using the concept of a "File" data type (with respect to the operating system) and creating a new instance of that type that has private data, but a common set of operations (DltF, DspF, etc.)

So at the same time IBM was putting out a brain-dead HLL (the first version of RPG/400) for this amazing new system, their engineers were already using -- not just talking about -- one of the most important concepts of all contemporary languages -- except ILE RPG, of course.

Why didn't IBM add object support to RPG/400? Simply -- The marketing weenies wanted something that looked like RPG II.

= = = =

At the same time object-based concepts were arising from "modules", it was a natural to see the advantages of letting the application programmer define new data types to fit his or her application needs, and that was (and is) one of the foundations of "object-oriented" programming. Truly one of the most important fundamental elements of a credible application language.

Another "core" OO feature is inheritance, which has two flavors:

* Interface inheritance allows for subtypes that share common capabilities (a source physical file is a subtype of physical file, which is a subtype of file).

* Implementation inheritance, which is a code reuse mechanism.

(The two are not the same, although languages like C++ conflate them, creating significant problems.)

= = = =

Now let's look at the "integration" of the iSeries database and HLLs. Back in the 1980's, this was truly a nicely done job which was possible because IBM controlled the only S/38 compilers, as well as the operating system. There is an enormous advantage to this arrangement, in contrast to most other languages.

What IBM did was really pretty simple:

* Have the database store each file's record layout (and some other info) with the file itself.

* Have the compilers read this description and generate a record structure for the file buffer within the program.

Voila! You read file, and all the fields are right where they should be.

There's more, of course. In a similar vein, the compiler can know key fields and generate code to assemble the right structure to pass to the HLL runtime's I/O routine.

On other systems, this was handled less elegantly, e.g., with "Copy books" that held record and key structures.

With languages, like C++ and Java, that aren't single-compiler, single-OS languages, the route taken has been to do the DB "integration" with tooling (and support libraries) that result in generated source code that's passed to the compiler.

This is essentially what underlies many Java solutions, and pretty much all application generators; and the result can be as effective as the iSeries HLL compiler approach.

Back in the 1980's I found the S/38 Cobol and PL/I compilers very nice compared to alternatives on other IBM, DEC, and HP systems I worked on.

Now, these HLLs are long in the tooth, although of necessity, you can still flog them down the road to get the job done.

The job is easier, though, when you appreciate the practical benefit of independent compilation (no prototypes), runtime binding (no bind step), and programmer-defined data types (i.e., objects).

-- Paul

Adding bound procedures in ILE didn't take away dynamic calling, which was already inherent. Nor does adding bound procedures mean that dynamic calling shouldn't be used when helpful. Bound procedures are simply one more tool in the toolkit. Binding simply makes the call more efficient, which is particularly helpful for functions that are called repeatedly.

Contrast bound procedures with OO languages that REQUIRE code to be generated to inspect parameter types and values at runtime, just to make a call. That's part of the reason that OO languages are so inefficient in comparison. Making RPG a fully OO language was hotly debated in Toronto, but I believe they made the right decision to approach OO in a more limited way.

It's too easy to throw out terms like "modern" when comparing object oriented languages to procedurally oriented ones. In my book, the value of procedural interfaces are just as significant today as they ever were.

------------------

If you prefer object oriented interfaces, they're fairly easily coded in RPG without throwing out RPG's procedurally oriented roots. Consider code like:

my_car = carNew(make : model: year);

Where your carNew procedure returns a pointer to a data structure containing make, model, and year, so you can use getter / setter procedures for retrieving /setting Car attributes.

// retrieve Car attributes

my_make = carGetMake(my_car);
my_model = carGetModel(my_car);
my_year = carGetYear(my_car);

Or you can simplify the interface of getter procedures with code like:

// set a pointer to your car data structure

carSetInstance(my_car);

// returns a value from the current instance of Car

my_make = carGetMake();
my_model = carGetModel();
my_year = carGetYear();

Or if you want a generic getter procedure to return values based on inspection of parameters, you can store pointers in make, model, and year so that returned values are based on a pointer inspection:

// get car attributes

my_make = carGetAttribute(make);
my_model = carGetAttribute(model);
my_year = carGetAttribute(year);

You can have essentially all the fun of object oriented interfaces without REQUIRING the overhead of object oriented languages. I can practically guarantee that when developers master these concepts, they'll begin thinking of ways to do things programmatically that books on object oriented languages might theorize about, but are incapable of implementing.

------------------

Regarding the topic of data access, consider the efficiency of sharing memory with, and binding to low-level OS routines that perform database I/O vs. distributed architectures where the path to data is lengthened, where possible failure points are added, where data is transformed from simple memory addresses to structures complying with ODBC / JDBC communications then back again to memory addresses of client components implementing such interfaces. And they call that "modern".

Of course you can still use dynamic program calls on the iSeries; I never said otherwise.

I explained the tradeoff IBM made in providing built-in support within RPG only for static binding.

It was unfortunate that IBM didn't at least provide for independent compilation and dynamic (runtime) binding of subprocedures. You can't, after all, code multiple programs in a single source member, which -- in addition to performance considerations -- makes programs poorly suited to fine-grained decomposition.

JVMs perform runtime optimizations, including in-lining, which take care of some of the overhead associated with the more flexible calls supported by Java. But the larger point is that Java supports early type checking and late binding which is a flexible combination for many (not all) applications. (Java also supports other useful features, like subtyping, that require a more complex call mechanism.)

Your snippets of "OO" programming in RPG are excellent examples to support the use of languages which inherently support OO features.

There's value in the techniques you suggest (I used them in my implementation of Log4i). It's just simpler and less error prone in a language like Java.

You also didn't address garbage collection which is a significant issue. Or subtyping. Or introspection. Etc.

I can't figure out what you mean by "books on OO theorizing, but incapable of implementing."

There is clearly a potential performance advantage -- for some types of routines -- to having a language tightly couple to the hardware. Assembler fits the bill better tnan anything in some cases -- just not most application programming.

But tightly coupling a language to the hardware (or operating system) is simply not the only, or necessarily pivotal, consideration for a general-purpose language design.

You mention one of the other considerations -- support for distributed applications. Another is platform independence. Not necessarily just for portability of a specific piece of code, but more so for wider applicability of skills and for reaching critical mass for tooling, education, qualified and experienced labor pool, etc.

I should say, though, that I'm not enthralled with the idea that all I/O is funneled through JDBC and would have liked to have seen a Java framework that implemented a more direct path to local I/O. This is a case where Java implementors followed a similar path as the ILE RPG implementors and Java was dragged down by "legacy" approaches (i.e., ODBC), just as RPG has been for decades.

I also think J2EE suffers from "legacy drag" -- mainly the HTTP concept of session and some CICS transaction concepts. OS/400's way of letting each interactive transaction program be written as a single-user program, yet work in a multi-user environment spoils you, and RPG (and Cobol and PL/I) benefited from this operating system design.

The great shame is that IBM never released a language that was well designed and that fully exploited the underlying system capabilities.

I give Microsoft credit that they stepped up with both VB and C#, in turn. If IBM had done the same at some point, the industry story might have been different.

When RPG still doesn't support such elementary language features as multi-dimension arrays and user-defined types, not to mention more (yes) "modern" and useful features, IMO it's hard to make the case for it being a competitive advantage of the iSeries.

-- Paul

Paul: "It was unfortunate that IBM didn't at least provide for independent compilation and dynamic (runtime) binding of subprocedures."

They did, they're called service programs.

Paul: "When RPG still doesn't support such elementary language features as multi-dimension arrays"

You can achieve the same result with nested data structures.

Julian = Month(m).Day(d)

Joe

Why RPG Survives

Paul: "...it's hard to make the case for it being a competitive advantage of the iSeries."

Perhaps for new development this is often true, but the persistence of RPG testifies to its continuing attractiveness to many.

The perfect computer language has not been designed yet, or is well hidden in academia. Many Java developers are eager for a better replacement to come; some are rushing to and gushing over Ruby.

RPG survives for at least two reasons. First, it has been a productive language and there are mountains of working code out there keeping the business world alive day to day. This code is constantly changing in small ways and occasionally changing in big ways, but rarely being rewritten in a new language. As long as IBM continues to enhance RPG, there will be incentive enough for businesses to continue to use it where it is already the dominant language.

Secondly, IBM's continuing enhancement of RPG is another major reason why it survives. For all its faults (and Java has its faults too), ILE RPG IV is a strong and flexible language capable of rendering agile and elegant applications.

On the iSeries, where the two most popular choices are RPG or Java, to choose RPG still can make good sense. To use both in productive coexistence may be an even better choice.

I sometimes think IBM should take the free form version of RPG IV and give it a new name, make it free form from top to bottom, cure some of its noted defects, and make it cross-platform. Maybe such a new hybrid OO/procedural language could find success in a world of imperfect choices.

RPG is a server side language and as such I don't think it is fair to compare it with C#, C++, Java, etc.

It does compare more than favorably with other server side languages i.e. SQL stored procedures, C, COBOL, etc.

I was a hardcore supporter of RPG IV with regular "Call Program" architecture instead of CALLB or CALLP. I used to consider each of my programs as being one module completely separate from each other. They did wonderful jobs for me since last 5 years until I had to design a very complex application.

Fortunately/Unfortunately my company asked us to learn Java because we got a big project where we had to integrate Java as front end + (EJB at as400 side) and UDB/400 at back end. As you know, you can't get developers with this mixture of knowledge so easily for a big project with as many as 40 resources. So only option was to venture into each other's area.

Effectively, it took less time to learn AS/400 (including some RPG stuff) for the Java programmers than for us to learn Java. It was hard for me to understand "why do these guys want me to declare another class when I can do it with a few more functions". All the jargons such as encapsulation, polymorphisms, etc., were no way coming to our mind to understand "where/why/how am I going to use all these nonsense stuffs for my order management application?"

However, as a proof of concept assignment, we were asked to design some Java program to run a few invoice jobs and convert database files to .Exl (not .CSV) in AS/400. At the end of the assignment I felt good that I had learned OO. Immediately we were asked to write the same application in RPGLE to do a code comparison (100 source code of JAVA = ? RPGLE code approx). We could finish the latter more quickly than Java. But I could feel the change in myself.

Changes are:

1. I was asking myself about the usage of each variable before I declared it.

2. I was getting more cautious about the global variable/file usage which contributes to 60% of bugs in a minor changed application.
I was getting worried about initialization of variables, flags before I write another subroutine or I had to land up in declaring N number of variables, they started looking like #count1, #count2 etc which I hate.

3. The most important thing I was getting worried about was, so many Chains, so many Reade ... so I was thinking of using SQLRPGLE but I was instructed not to mix SQLRPGLE with regular native IO programs.

4. Even with SQRPGLE I was going nuts without having the try/catch exception handling.

I had to depend upon my fellow programmers to complete some service program to use APIs. Here I faced the biggest drawback of RPG as such:

a. IBM has developed so many APIs but they are really very difficult to use unless you find sample code from somewhere. Why they have so less BIFs in RPGLE? They have N number of BIFs in C/400. Why do they expect us to write the procedure prototype for them? The compilers should able to take care that. It is the same AS/400, dude.

b. Look at the documentation of Java applications. Any jar file you want to use: go to the net, you will find the same structured way of documentation.

c. Look at the reusability stuff. You need not to do much buddy. Get the jar files, put them in your directory, use them with classpath. That's all. Now think of this in terms of ILE service program that you got from your friend. There is a big pain to know which procedures are theire inside it unless somebody provides you the source code or detailed documentation and you never know how he is going to document it. Secondly you will fill your D specs by declaring with prototype or you need to maintain the /Copybooks (which is a pain to go thru once it becomes huge).

d. I really could find a reason to tell my developers to say "Why they should use a module and when". I started thinking modular not restricting myself to CALL only.

As a novice java programmer I could see this much . . .

I should have said: "It was unfortunate that IBM didn't at least provide for _separate_ compilation and dynamic (runtime) binding of subprocedures."

Loosely, "separate compilation" means you can compile a unit and the compiler will check references to procedures in other units by inspecting the compiled version of the other unit.

ILE RPG doesn't do this, and requires cumbersome, unnecessary, and potentially out-of-synch prototypes.

ILE RPG's standard procedure call doesn't support runtime binding. As a condition of creating an ILE RPG program that uses standard procedure calls (not API calls), you must bind the modules that contain the called programs.

You can bind by copy or bind by reference (i.e., to a service program), but the binding still occurs at program creation time, not runtime. At runtime, the service program must be found and loaded when the program is loaded, even if no procedures in the service program are called.

Contrast this with dynamic program calls, which do support runtime binding.

Nested DS's do provide a RPG an alternative to multi-dimensional arrays, although by further encumbering the language (and programmer) with additional syntactic kludges.

-- Paul

Paul, this argument is moving into the absurd. You're complaining about a specific architectural detail that really doesn't affect application programming, and to top it all off you're wrong about it anyway.

First, what is the business goal of dynamic runtime binding of procedures that is not met by traditional service program binding? Please give an example of an application programming business requirement that cannot be met by service programs.

Second, despite your impassioned disdain, as it turns out you can indeed dynamically activate service programs using QleActBndPgm and QleGetExp. If you actually came up with a business reason that met the first question, you could address it with this technique.

>

You ought to learn about this ILE stuff, Paul, you might actually like it.

Joe

I didn't quite follow the debate or rant or whatever you call it here, closely.
But from what I understand from Paul, is that he emphasizes the uselessness of the prototype construct. Why declare the parameters of a procedure (either called within the program or outside in a service program), when the compiler could do that for you?
After all, you don't declare all the column names of a table in the source, do you? If you use an invalid column name or a valid one but with a mismatching data type, the compiler will be happy to point that out.
Same thing should happen when you call a procedure and your parameterlist doesn't match the list of the actual procedure itself.

JMHO.

Joe,

Your constant mis-stating of my and other posters' comments in this and other threads is simply too counterproductive to respond to.

-- Paul

Just a few quick items:

1. Steve: "RPG is a server side language and as such I don't think it is fair to compare it with C#, C++, Java, etc." Well, Java, C++ and C# are also used for server-side applications, so I think the real distinction here is between older "procedural" languages and newer "object-oriented" languages. Whether it is fair or not, it is difficult to avoid making comparisons between Java and RPG when both are present and you're using both of them. I think it can be insightful, and if you like both languages you try to be fair.

2. Jagannath,

a) Many of your experiences and reflections seem commonplace among RPG developers who learn Java. Several of us in our shop fall in that category and we have often talked about how Java affects how we now think and code in ILE RPG. (BTW, RPG has something like try/catch with the monitor construct).

b) One effect is a tendency to design solutions which make use of SQL more and native IO less; for example, a Read loop containing Chains would likely be replaced with fetching through a cursor built from joining the relevant tables, and use of IO procedures whould separate the IO activity from business logic activity.

c) Another effect is a change in modularization tendencies somewhat like I was trying to describe at the start of this thread. Of course ILE RPG IV encourages this even without the influence of Java, but learning Java seems to accentuate that effect.

Ugeerts: "If you use an invalid column name or a valid one but with a mismatching data type, the compiler will be happy to point that out."

Well, if you use RPG it will, but not if you use SQL. With SQL you won't get an error until runtime.

Anyway, I wasn't talking about prototypes, I was talking about binding. I'm not sure what Paul is complaining about; I didn't "misstate" his position on anything, I simply pointed out that despite his comments to the contrary you can perform dynamic runtime binding of service programs.

As to prototypes, I personally have no problem with them since I only define them once (in the called module). I use compiler directives to conditionally include the protoypes and the calling program simply includes the source of the called module. This allows me to syntax check my source on, say, a workstation without having to have access to the actual modules on the host.

Your opinion that the compiler sucks because it doesn't do introspection of called modules is simply that: an opinion. In my opinion, RPG does so many things correctly that it simply blows away any other language for business application development.

Joe

Max: "One effect is a tendency to design solutions which make use of SQL more and native IO less; for example, a Read loop containing Chains would likely be replaced with fetching through a cursor built from joining the relevant tables, and use of IO procedures whould separate the IO activity from business logic activity."

And of course I disagree with this entirely. A good RPG programmer will use SQL when appropriate. What Java centricity will do is cause programmers to use SQL INAPPROPRIATELY because they don't understand the power of ISAM access, and separation of IO logic can be done just as easily through RPG procedures as anything else.

No language will make SQL access appropriate all the time, but some people will still insist that you always use SQL and those people cause programmers to program bad code regardless of the language.

Joe

Procedure prototypes are very useful in my opinion. They DOCUMENT procedure interfaces. They're roughly comparable to JavaDocs, but more useful because the compiler identifies discrepancies between prototype definitions and procedure calls. It's better to find a bug in a procedure call at compile time, rather than at runtime.

There are times when it's helpful to have hidden interfaces in procedures, where some of the parameters are omissible, where omissible parameters are left off the prototype distributed to some developers, but made available to others. In such cases it would NOT be helpful to provide a means for tools to inspect procedure interfaces and document them. Let the developer of the interface control how it's documented.

There may be cases when it's helpful to dynamically bind to procedures at runtime. If so, Joe Pluta already made reference to QleActBndPgm() and QleGetExp(), which make that possible. Consider having one service program implementing one set of behaviors and another implementing others, but both having the same procedure names, etc.

If you're a tool developer, you might care about stuff like this. Average developers and managers however tend to jump on the bandwagon of whatever language or framework IBM and Microsoft are promoting at the moment, whether it's the best tool for the job, or not.

Joe and I have our disagreements about when to use native IO and when to use SQL, but we at least agree that both have their places.

In the situation I expressly mentioned, where you have a read loop containing subsequent chains executed (conditionally or unconditionally) during each iteration, the power of ISAM is likely to be overwhelmed by the power of the SQL engine. Recent benchmarking here showed SQL consistently outperforming native IO (SETLL, READE and CHAINSs) with selective processing over large (multi-million row) files.

One can design a solution with native IO or SQL in mind, depending on what seems to be the best approach for the task. When in doubt, benchmark.

Joe mentions that the influence of Java might encourage the inappropriate use of SQL. He may very well be right about that. But I think one can also be concerned about RPG developers who resort to native IO, out of habit, where an SQL solution might be better. The challenge of choice cuts both ways.

I agree with Joe that RPG is a great language, and it is really nice to have the choice between SQL and native IO operations. The choice is sometimes challenging to make, depending on how the solution may be designed. I have listened to Joe and have even moderated my admittedly pro-SQL position somewhat in response to his points, but one thing Joe and I agree on is this: we both like and respect this venerable old language.

"Joe mentions that the influence of Java might encourage the inappropriate use of SQL. He may very well be right about that. But I think one can also be concerned about RPG developers who resort to native IO, out of habit, where an SQL solution might be better. The challenge of choice cuts both ways."

Absolutely right, Max. Thus my point that a good RPG programmer will use SQL when appropriate. In your example, SQL will almost always be more appropriate, and at the very least the programmer needs to consider it. And that's the REAL point: the best programmers (or smiths of any type) use all the tools at their disposal as apporpriate. They won't force the use of a single tool when different and better tools exist.

And that's why I advocate RPG, and the iSeries. Unlike any other platform and language, these "venerable old" tools integrate the power of time tested techniques with powerful new technologies.

Unlike the latest "fad of the day", you don't get locked into a technology that will be gone in a couple of years (witness Struts -- gone from the cutting edge to the cutting floor in the space of a couple of years). Instead, you can expand your skills and use whatever is the best for the job.

I can't understand what sane human being would pick another strategy.

Joe

I saw the comment about Java try catch as opposed to RPG the other day but I've been too busy writing heavy duty RPG systems with bullet proof error recovery strategies to respond.

First of all, I write in Java at home for my own projects so yes, I use try catch when required by Java or when required for the situation, just as in any other language and operating system.

I usually put the minimum of printStackTrace when required, more if I'm using it to provide error recovery. And others may use an advanced error recovery strategy in all cases. All good. But let's do a reality check here.

RPG and OS/400 provide far more robust error recovery at a minimum that a stack trace. That is the level provided by DOS. So just saying try catch doesn't mean a thing. What does catch do? If you're doing what DOS and others have done for decades, you're wasting your time trying to impress us.

And blowing out to OS/400 with enterprise level error handling and security is usually enough. Yeah, there's a stack trace there, and a whole lot more. But what do we have in RPG for error handling and recovery that keeps us in check from being awed by try catch?

Well, last I checked there were at least four error handling strategies at the program level.

At a more local level like try catch, we have MONITOR.

At more fine grained statement levels we have the %error function or error indicator.

And lastly, we have many test instruction capabilities to detect and handle errors before they happen.

With all of these, we have file, interface, and error data structures with a fully audited snapshot of our program to use in handling the error situation.

And so what might what we do with all that?

I've had my programs message everyone in a file if the file needed to be allocated and was in use to ask them to get out of their program for a few minutes, or

message an individual who had a record locked on screen if the record was needed, or

handle errors, print details to an error report, and continue processing.

There is nothing you can do with try catch that we can't do better in RPG.

Next time send a man.

rd

I have dynamically bound service program procedures in various batch processes with great success using the API's above. It makes design of table-based rules processing using service programs very easy to implement.

1. Steve: "RPG is a server side language and as such I don't think it is fair to compare it with C#, C++, Java, etc." Well, Java, C++ and C# are also used for server-side applications, so I think the real distinction here is between older "procedural" languages and newer "object-oriented" languages. Whether it is fair or not, it is difficult to avoid making comparisons between Java and RPG when both are present and you're using both of them. I think it can be insightful, and if you like both languages you try to be fair.

Max: to the best of my knowledge C# and C++ do not run on a System in an i5/OS partition. Java does, however unless portability is part of your business case I am not sure why you would exclusively write a new applications backend processes on a System i running i5/OS in Java.

It seems to me that many here are advocating moving away from this operating system (i5/OS) on the System i. Or away from the platform entirely.

I was only making the point that it is reasonable to compare the general features of the RPG and Java languages, without regard to platform issues.

Under i5/OS RPG clearly remains a very strong and attractive choice, IMHO. There are many types of applications I would rather write in ILE RPG than in Java. I don't think you need to go OO to achieve high modularity (which I believe was one of the motivations behind the development of OO languages).

Just as we can use both SQL and native IO where each seems to be the better choice, so too we should be able to use RPG and Java where each seems to be the better choice, under our particular circumstances.