System iNetwork

To me, modernization has two aspects. I'll call them 'appplication' and 'structure'.

Applications are user driven. They exist because the company needs them. IT exists to support them, not control them. Any changes to an application, or even a serious contemplation of something new, should be driven by the user departments. IT is only providing the change capability. To that end, IT can certainly provide support on how to best structure the new or changed application, but the user does not become ancillary once IT gets involved.

IT can define data structures, flow control, suggest ergonomic design aspects, provide foresight by making suggestions about current and potential future technology ... but users run the ultimate show with respect to the final application. IT sometimes seems to forget this.

IT often forgets it is a department filled with labor intensive pure overhead. Programmer fantasies about adding new and modern languages to replace the old, stale ones are regarded by executive managers outside of IT as immature and missing the point. Modernization requires adding value that impacts the bottom line. No language can do that. Excessive variation and unnecesary complexity adds to maintenance costs without adding to company value.

IT strategy should be customer driven. How can a company best serve it's customers? What procedures, technologies, and products are required to keep customers coming back and attracting new ones? How can this be dome most effectively and at the lowest cost? IT defining it's mission is much like a tail wagging the dog.

It is entirely possible that some applications may be patched together and so unmaintainable that a change is strongly recommended. Suggesting a change would be responsible and an example of IT leadership. However, the user departments should participate in a management capacity on the replacement project.

This is an excellent point. Too often IT gets caught up in the latest craze and wants to implement it with no real thought to the ROI. It's happened over and over in my lifetime: CASE, client/server, OO, Y2K, Unix/SQL, EJB, web-enabling. Each of these was used as a reason for massive rewrites that added little if anything to the bottom line of companies but cost them billions of dollars. AJAX is the next example, and there are consultants who will push this latest techno-fad simply because they know it (and frankly, many of them won't really "know" it because they just learned it themselves).

No wonder corporations are gunshy, and C-level executives are trying to find tools that allow non-programmers to create applications. Luckily for programmers there are no such tools (yet!), but at the same time, unless we want to be replaced by VB coders, we need to be proactive about providing value.

To that end, the idea of application modernization needs to be highly tied to ROI. Where is your biggest expense? If it's the call center, then you might want to look into a B2B or B2C browser interface can do. If your telephone charges are high, see if Voice over IP might help. If it's printed invoices, maybe you want to look into PDF and email.

Don't modernize things that don't need to be modernized - just another way of saying "if it ain't broke, don't fix it." A lot of folks have perfectly good financials and production control, they just need some tweaking in the supply chain. Others have all their core business functions in place, they need new ones like CRM.

The point is that the idea of modernization for modernization's sake is unlikely to provide a proper return, except maybe for software vendors. Anybody else who has a ten-year old system that is working and at least marginally maintainable has a system with TENS of THOUSANDS of hours invested in it. No need to toss out the legacy baby with the AJAX bathwater.

Joe

In my experience, RPG programmers often don't understand web applications and assume that their RPG code must perform the commit after performing the CRUD functions. They don't understand how their code could be running in the context of a larger transaction. Java programmers who don't know RPG can't argue the point and they let the RPG programmers get away with this nonsense. This problem could also occur in a pure ILE environment. Has this been anyone else's experience?

I'm not sure I understand this. I know plenty of RPG programmers who know how to store changes from one screen to another and then make the entire set of changes in one shot after all screens have been processed. However, the commitment control boundary never crosses over a user interaction... that is, you should never start your updates then wait for user input and then commit the updates.

So in that, I'm not sure how RPG programmers are any different than anybody else.

Joe

What would "modern" RPG look like? "Modern" Java is created via iterative, test driven development, constantly refactored, DRY (and thus inexpensive to modify) and the majority of components completely independent of the database. Can RPG achieve this state? The modern RPG language is great but the majority of code I see does not interact with other ILE components to any great degree much less use callbacks and inversion of control. Seldom does the code I see from the 200 or so RPG programmers I work with even go so far as to encapsulate data and expose important behaviors; it is monolithic even when it is an ILE procedure.

It has been suggested that 1. the problem is twofold:
1. Legacy code was not designed as reusable software components.
2. Legacy coders may not know how to refactor existing code or how to write new code as reusable software componentry.

Besides the API the AS400 application presents to the remote components, the other API RPG developers need to consider is the API among the ILE components. Besides Joe, how many others see RPG that achieves all the above?

1.Denoncourt, iSeries Magazine, Feb 2006

There is no such thing as "modern Java" any more or less than there is "modern RPG". You can use nearly every technique of encapsulation and reusability in RPG as you can in Java. At the same item, I've seen plenty of poorly written, tightly bound, monolithic Java code. I can't tell you how often I see JDBC code and HTML generation in the same class... how more tightly bound can you get?

As to encapsulating RPG code, we've been doing it since the 80's at the very least. At SSA we had server programs that supported both green screen and thick PC-based clients.

There is nothing in the RPG language that stops you from designing good, modular, n-tier code. Take a look at my e-Deployment book, written back in 2000, to see examples of how you can separate UI from business logic, and write RPG code that supports both a green screen and a web interface.

When it comes down to it, the programmer is far more important than the language.

Joe

Joe and I both agree that RPG is very capable. Joe has been Agile since the Eighties but, I am simply pointing out that I never see these things implemented. And that is why programmers where I work and where Max works are today writing monolithic programs instead of using the features available to them to create better applications. How to modernize code isn't about "becoming one with the machine"; it is a people problem.

Actually, Greg, new RPG development here is modularized rather than monolithic, but as is probably the case with most iSeries departments, much of the mature code that we maintain is monolithic.

And this is our dilemma: knowing what we now know, and given the expanded capabilities of RPG IV over RPG III, we would like to rewrite much of what we maintain, but as Joe points out, this isn't always easy to cost-justify.

But it should be possible to change direction and "refactor" old code while maintaining it. This is a long evolutionary process, but since the programs need to be maintained anyway, why not also move them in a new direction? This could be done in stages, first heightening the modularity and accomplishing internal tiering within the program, later decomposing programs into program sets, etc. And this has to be a carefully managed process guided by an architectural vision.

BTW, your observations and those of Don Denoncourt are accurate and helpful, I think. But Joe is also right: good, modular n-tier applications have been written in RPG. I was on a team which did this back in 2000-2001 for a national financial company.

I think many RPG developers would like to develop in new ways, but have a primary responsibility to maintain mature applications which are of great value to their businesses.

Small building blocks of code with constantly changing (refactored) interfaces that the gentleman is so proud of is highly overrated, and monolithic highly overcriticized. Let's take some common IT happy talk and consider how much is myth and how much is true.

- Small building blocks of code is superior.

The theory here is that logic and functionality is isolated to a small set of code, the details encapsulated from everything else which only needs to know the interface calls to work with it. In theory these small building blocks perform their functionality for everything. They are all knowing in their subject matter domain.

Often otherwise very smart people additionally judge how large a section of this code should theoretically be based on whether it fits on a screen. What's the success of the theory of object building blocks, the opposite of monolithic procedural code?

In reality, this theory put into practice produces the opposite of monolithic code. Instead of knowing precisely what is being executed and being able to change that logic in that one specific program, it is, after all, monolithic, a change to a low level buildng block will affect everything that eventually calls it. Total faith is required in the discipline at the call parm interface.

Now if this was successful, then we could all kick back and say it's Miller Time, I wish all my code was in little building blocks where I "constantly refactored to make maintenance easy". And so we could look for this success.

What you actually get are people who are like any other people, knowing that everything a change can affect must at least be considered. The interface may not change, but the data flowing through may well, and so one must consider exactly what that contract is and will we break it, or someone's use of it. The enterprise is counting on that building block. And so is modification really that much easier, or actually harder? The ramifications are certainly much greater.

In fact, the other outcome of this theory was supposed to be reuse of logic, that other opposite of cloning working logic into new monolithic programs. I watched for several years for news of the success of reuse. Instead I saw studies that showed that little of this building block nirvana code is reused as the predictions go, predictions unfulfilled in the face of reality.

So there is a happy medium, a successfully proven medium point, that being at the component level. We have them in standalone RPG programs with *INLR left off to be called repeatedly within a job. This level of logic isolation is used extensively in the AS/400 world and is a practical level of logic encapsulation, runtime performance, and change exposure.

So we have done quite well long before the theorists theorized. There is a reason we did what we did, and do what we do, and we didn't do badly all these years in what we did. I have seen nothing in the theory that has achieved what we have done.

Only theory, unfulfilled.

rd

I had to smile, Ralph, when you mentioned the "fit on a screen" rule. It brought back memories of back in the late 70s when structured modular programming had moved from academia to the business world and one of the rules of thumb was that a module should "fit on a page." Now that we no longer print out our programs it has to fit on a screen!

I suspect an intellectual history of programming theory would show that the rationale for ILE service program procedures and the object oriented preference for small focused classes and methods probably share a common root. I think the rationale is basically sound, although as with any good theory, it has to be implemented with some common sense and experiential wisdom.

I am an advocate of refactoring, and Martin Fowler's book "Refactoring: Improving the Design of Existing Code" is one of my favorite books. I am intrigued by how many OO refactorings are transferable to a procedural language like RPG. A few seem to be fairly clearly transferable, with others only an abstracted insight might be transferable, and others seem limited to the OO world.

Refactoring is defined as changes to the internal structure of code which does not affect the behavior of the code, but serves to enhance the elegance and maintainability of the code. So true refactoring would not affect reusability.

Max, I've seen a lot of modular RPG developed but little of it reused. If your teams are getting reuse, your code IS modernized. To ensure we get reuse from our Java, our "Core Components" Java team is creating the classes for which architects and tech leads colaborate and plan the reuse, modification and extension. What Fowler advocates in Refactoring, our managers never allowed in the RPG. Without automated unit testing, we really had no business refactoring code because manual testing is expensive and error-prone. So, if you are refactoring, do you have automated unit testing of the RPG?

We have very limited reusability in our mature applications, Greg, although we plan to continue extending this. The RPG reusability is achieved through the use of service program procedures. To expand reusability in our mature apps we have to identify the functions, move them into service programs, and modify the using programs to use the service program procedures. This is being done gradually, on an "as we can fit it in" basis, at present.

We do not have automated unit testing for our RPG development, yet. This is an area where we need to discover what our options are and what seems best for us.

When I said I am an advocate of refactoring, I did not mean to imply that my view has been adopted here. I advocate it as a way of guiding the evolution of our mature apps as we continue to maintain them. At a high level, refactoring is a philosophy of software maintenence which holds that it is desirable to keep code elegant and easily comprehensible; that this actually reduces maintenance costs. But as you know, in the OO world the term also refers to identified refactorings which can be applied to code.

The implementation of a refactoring philosophy will be different for a procedural language like RPG than for an object oriented language like Java. I'm sure you already know this and know why. But I am intrigued by how much of OO refactoring might be transferable to, or at least give advice to, refactoring in RPG. But there will be big differences because of the different types of language.

Of keen interest to me, and to many others I am sure, is identifying useful patterns for refactoring older styles of RPG code into newer styles of RPG code, with the objective of achieving layered applications with greater reusability of IO and business logic modules/procedures/methods, and greater freedom in user interface choices.

Is RPG dead? Where's RPG's Maven? It's Rails? Dare I say it, it's Ajax?

One thing that I think business and AS/400 business developers will agree on is the secure, high performance business transaction processing that AS/400 sessions running ILE language programs provide.

Any serious discussion into excursions into running a business with stateless web page languages requires buy in from the business on how it will be able to match 5250 sessions in business processing.

Using cookies as a hope for emulating the security of a 5250 session won't cut it for a business. And in that discussion we do need to differentiate between serving all people in the ephemeral cloud versus business users with the authority to perform business transactions.

They are not the same.

rd

This is the first time I see somebody referring to the difference between external and internal users.

I think it is FUNDAMENTAL

I'm not sure this will do any good, but I'll try to respond. Chances are it will be my last in this thread, but here goes. Greg, most of the cool stuff you point to is really rehashing old ground that's been covered for decades and has been used in formal RPG development environments.

Maven is a project management system and as such we have many of them in midrange shops. It's just that rather than catering to the fad of the week (e.g., Extreme Programming), most of them are based on the traditional and extremely successful waterfall model. This includes systems such as PDLC which make use of some of the very sophisticated change management systems that are available for the System i.

Ruby on Rails is simply another syntax for doing the same thing. Funny thing is that some of the things that Ruby does that are considered whiz-bang have been around in midrange programming for a long time. For example, Ruby's idea of the ActiveRecord is actually very similar to RPG's externally described files (and something that should be required in OO languages that access a database). As for the "conventions over configuration", it's great as long as you agree with their conventions. But in any case, Ruby is hardly a replacement for RPG.

And finally, there already is an Ajax for RPG. It's called... Ajax. Ajax is a client-side technology and it doesn't matter what your server is written in: RPG, Java, or even Ruby.

Anyway, I'm not going to bother defending poor old RPG anymore. I just wanted to make sure some poor unsuspecting reader didn't stumble across this and get the idea that RPG is somehow a lesser language.

RPG is nothing short of the best language currently available for data-driven transactional processing, which is by definition the great bulk of enterprise business logic. And the System i allows you to use this most powerful of tools with just about any front end you can imagine.

Joe

RPG is not dead, of course, because it is being used in countless businesses, large and small, all over the world.

Greg's point, I think, is that the RPG world lacks the excitement and enthusiasm of the Java, .NET and Ruby on Rails communities, and that most new development is using those technologies rather than RPG. This seems to be true, but it may not mean that RPG is dead or dying, but that it is mature. (Or maybe many of us RPG developers are in denial. I hope not.)

As I understand it, Rails is great for Ruby because Ruby lacks the equivalent of a JDBC package, but it has little to offer Java. I note that there seems to be a performance battle between Ruby on Rails and Java-based Spring/Hibernate.

I have only begun to learn Ruby so I have little to say except that it is an attractive language in many respects and I don't think it is going to be merely a fad. But like Joe, I don't see it displacing RPG. It is displacing Java.

I see that Rails can be implemented on a DB2 database and there is some interest in implementing it on an iSeries, but when it is, it won't be for the benefit of RPG. It will just bring Ruby to the iSeries.

AJAX may become of great interest to the RPG community. Robert Cozzi published a very useful article on AJAX and RPG in February of this year. Google "AJAX Cozzi" and it should be at the top of the list. I highly recommend it.

Greg, I know you have a System/38 background, so maybe it would be helpful if you could point out some of the ways in which Maven is different from midrange project mgmt systems. For example, how does Maven encourage the use of best practices? Do you think something like Maven could be developed for the RPG world?

Lastly, many businesses may find that optimal solutions are achieved using a mix of technologies. Where RPG is strong, keep using RPG; where Java or Ruby on Rails is strong, use those technologies. They can coexist. It may be best in many cases to get them working together. However, for RPG apps to mix well with these newer technologies, the RPG apps will often have to be restructured (at least in crucial places) to be more modular and more services oriented.

Or it may be that "excitement" in the IT community means different things depending on what type of programmer you are. If your primary focus is the latest new technology and the ability to get cool new web applications done in the fastest time, then many of these tools are for you. Hans Boldt always raves about Python because you can create an HTTP server in about three lines of code. Those programmers don't like RPG because it doesn't earn them any "cool" points when talking with other technophiles.

For those of us who write enterprise applications, excitement comes in a different form: making business work better. In that pursuit, how often do I NEED to write a new HTTP server? The answer had better be never, otherwise I am wasting my client's time and money. And that holds true whether I'm a consultant or an employee: my client in either case is the end user, and my job is to make them as productive as possible. That's why spending two years porting a working system to another language without adding significant functionality is not a good thing to do, and why enterprise application development doesn't appeal to people who like the latest whiz-bang feature.

Hey, I like new technology as much as anybody. I wrote the first commercially available Java application for the AS/400. But I hope we've learned over the last decade that technology-driven IT is a bad investment; that you only incorporate new technology when it contributes to the bottom line, and that you design systems that make the best use of today's talent and tools. The only major difference today is that you need to always look at how you might need to integrate new features in the future.

And that, in a nutshell, is why I prefer the thin Java shell over primarily RPG business logic. It lets me use both the best talent available (experienced RPG applications developers who understand not just bits and bytes but business) as well as providing me a great hook to other technologies. By using Java as my front end, I have an instant hook to everything from email to Web Services.

Which brings me to your other point: AJAX as of great interest to the RPG community. Why do you think that is? AJAX is purely a client-side technology and as such is entirely server agnostic. It provides exactly the same functionality to a pure Java web application as it does to a pure RPG application. The same caveats of servlets vs. RPG-CGI apply, and the same answers prevail: a thin JSP Model II layer wrapper over RPG business logic provides the most flexible model available.

Joe

While a mix of technologies seems like a prudent course, having created several solutions at the behest of companies in a mix of technologies, more questions were raised than answered.

- What is the most cost effective information technology architecture for the business?

It used to be very clear. Business processing was done with 5250 terminal emulation screens, emulation technology that includes many capabilities such as windowing, mouse point and click, and menuing which were not heavily developed because of no perceptible added value.

Similarly, the screens were sometimes provided with web page overlays which again were almost universally chosen not to be used for getting in the way of real work being done.

The business, however, also compared with windows inquiry products and said that's what we want, the ability to see what we want the way want when we want it, and go from here to there with a click.

All perfectly able to be done with RPG and 5250, it's a matter of programming. The inquiry products didn't perform business transactions, and the RPG business transaction screens didn't provide for ad hoc data lookup in the midst of a transaction.

What a business really wants is integration at the business user interface. They may think windows or web interfaces do that because of inquiry products, but none of it happens without programming, seriously intense programming, often which the business doesn't have time to allow for in the need to meet the fundamentals of new business transaction processing.

Probably what would most help in moderization are core intercommunication technologies that transfer data from one screen to another with the click of a mouse or push of a function key, the underlying technology of the interface screen being irrelevant in both technology and operating system.

They just want more integration, and 5250 plays in that world where web pages don't. We need to lead, not follow.

rd

I want to add that on the AS/400 I have usually seen and done cursor positioned F4 inquiry in a window from which the person performing a transaction can select valid values. This is a widely used standard that is quite a bit more powerful than drop down lists because we have a subfile to work with in doing so.

I was referring more to the multi-window parent and children windows in GUI programming when I spoke of not providing windows with ad hoc data lookup in the midst of business transactions, and usually the concept being a nicetie among many niceties we would like to do in the midst of implementing the business's chosen priorities.

rd

IBM has pushed Sun to open source Java. Shouldn't IBM open source RPG? After iSeries Magazine published the article on adding throw and catch functionality to RPG, I submitted a Design Change Request on IBM's web site for the addition of throw and catch built in functions to RPG. Surely every developer is a little tired of checking a boolean after every procedure call. Throw and catch has been in some languages since the sixties. Shouldn't RPG have the features that are considered essential in other languages? In regards to security, sure the iSeries is secure but, once it is added to a network, it is no more secure than any other machine. I know there are companies that assumed otherwise until they were rudely enlightened. I don't think this is an either/or conversation but the majority of RPG developers defend what they've been doing for so many years without knowing a thing about what can be done outside of RPG. The caliber of work we get from the Oracle DBAs far exceeds that we have on the iSeries and the amount of code reuse we have in our Java exceeds that of our RPG. (The RPG developers I know make big claims but after ten minutes of conversation, they will be telling you why it shouldn't be done in most cases; they'll say reuse is only for 'utility' functions.) What you can do with RPG in one day is great but the cost of living with it for twenty years is making many shops make changes. RPG could be part of the solution but too often RPG developers make that impossible. RPG now lives in a bigger world and has to be a team player.

The RPG MONITOR opcode is the catch. Provides all the flexibility in error handling one would want.

The security I was referring to was not that of the operating system. That's another whole level greater than anything else that we haven't even discussed, we were just talking about modernization of applications and development. But the security of OS/400 should be a significant factor in deciding on an operating system to run a critical enterprise.

The security I was referring to is in the 5250 terminal emulation session, or in the case of web pages, the pseudo-emulation of an emulation session, or lack thereof.

Again, those running critical enterprises should have OS/400, now i5/OS, as their enterprise system if they aren't already running a mainframe OS. OS/400 is the scalable midrange mainframe for every enterprise.

Everytime you read of thousands of customers sensitive information hacked into you know the enterprise is not running on an AS/400.

We don't have DBA's on an AS/400. I'm glad your Oracle DBA'a are productive. Hard to be more productive than not needing them to start with, though.

rd

Ralph, if your argument is that there is no place for browser interfaces in the business world (and that's the only thing I see in your last couple of posts), you lost that argument ten years ago.

Greg, in the IBM midrange the exception message has been around longer than throw/catch and is the basis of all exception processing. ILE made it even stronger with the concept of activation group boundaries, but in any event you've been able to signal and percolate messages for a long time. It's not throw/catch, but in my opinion it's even better because I don't have to add a lot of try/catch or throws syntax to my business logic.

As to your continual rants about "the majority of RPG programmers", I'd really wish you would stop with the broad brush smear attacks. Talk about yourself, if you must, but don't include me or my fellow RPG programmers in your cynical over-generalizations.

I don't know why RPG programmers don't work well with you, but in the shops I work, they all work well with me and I'm the "Java/WebSphere" guy. I wonder if maybe at least part of the reason RPG prgorammers don't like you is your obvious disdain for them? Hmmmm!

In any case, since you've sort of devolved into general RPG slamming (Oracle is better, Java is better, RPG programmers are boors, RPG can't be maintained), I think it's time to extend my standard challenge to you. Let's you and I sit down and write an MRP requirements generation from scratch. I'll use RPG, you use any language you'd like. Mine will be done sooner, run more efficiently, and be easier to modify than anything you do.

If not, I'll publicly apologize.

Until then, try to keep the anti-RPG rhetoric phrased as what it really is: your personal, uncorroborated opinions.

Happy Easter, Everyone!

Joe "Bunny Ears" Pluta

One contributor says, RPG is a good language and another says it is THE BEST. One says RPG code is often monolithic and another says that it SOMETIMES IS NOT! Yes, project management software exists on platforms besides Java. I give.

Some people seem think that if something was done right once on the AS400 then that was sufficient for all time. Guess what! The world wide web doesn't run on an AS400 where having done something right once makes it freely available to all. Let's say, you use the Lucene open source project and index 10 million lines of RPG source and you can now run searches of those ten million lines (you know, like Google) in under 40 milliseconds without even connecting to an AS400. What will you hear from RPGer's? "I can do that on the AS400" but ALL you'll get is talk. RPG and the AS400 have problems - it ain't the language or the hardware, it's the programming paradigm of People That Don't Know Better. Where I work, we don't have any RPG app that doesn't have at least six people supporting it full time. The Java, if it wasn't written by RPG programmers, can be forgotten about - it won't break. For the longest time we had one girl supporting four Java apps and vs over twenty developers supporting the RPG versions of those apps. It's my guess that we can reduce staff by three quarters when we get to all Java. And Maven makes that much easier and faster.

I spoke at the local AS400 users group presenting an ILE unit testing framework. I asked, how many use ILE? One woman said at her shop they could create procedures but they were placed in copybooks and copied into the program that required them. Another person said, "Oh, that guy quit.". And, out of a room of twenty, those were two of my three positive responses. And that's the RPG programming paradigm.

One Java architect I work with is interested in reuse of RPG components. He started cataloging how many times the same functionality appeared. He found that in the RPG there might be a simple business function coded hundreds of times in in-line code but it was never encapsulated. And so, it can't be reused as a web service the way he planned. Now, let's consider the maintenance costs of failing to reuse. Instead of changing something one time, testing it and putting it in production, we now have to modify the code and test the multitude of permutations in the hundreds of places where that logic resides. Remember the number of files it may be dependent on (those fields are defined in dozens of work files the RPG programmers require) and you know its very expensive to change anything. It's the RPG programming paradigm.

RPG is a very good language but I've never seen it used to reduce those costs. Don’t blame IBM, the AS400 or RPG. The blame lies in flat file database design, monolithic code, failure to refactor, failure to create unit tests. It's the RPG programming paradigm.

Maven does what most project management does but it does so in a more coherent manner adding a flavor of Rails', convention over configuration. Like Rails, convention can be overridden. Basically, there are many conventions but, for each project, one is shared among the project's team members. For each JAR file you specify, Maven will retrieve it from your own central repository or from the repository at www.ibiblio.org.

Using Maven made it so I could think about developing business components and plug them into the framework. Its not just that one person is up and running in minutes but that your team members get both the structure and the content of the project immediately and that similar projects have similar structure. We have basic Java, basic web, Spring and web-service projects defined and they all use our infrastructure for authentication, authorization, logging, data access, etc. If someone has a soup-to-nuts, reusable RPG web service that uses standard network authentication and authorization, etc, please write an article.

With Maven, we've had RPG developers who had minimal Java training (without web or JSP) creating useful business components on the first day of the project and web pages the first week.

It seems that one person looks over the field of RPG development and notices all the great things; another looks over the same field and notices all the bad and embarrassing things. Both things are there in that field . . .

. . . as in the field of Java. I notice that the Maven website has this disclaimer at the bottom of their "What is Maven" page:

"Maven does encourage best practices, but we realise that some projects may not fit with these ideals for historical reasons. While Maven is designed to be flexible, to an extent, in these situations and to the needs of different projects, it can not cater to every situation without making compromises to the integrity of its objectives.

If you decide to use Maven, and have an unusual build structure that you cannot reorganise, you may have to forgo some features or the use of Maven altogether."

So it all comes back to what Joe said earlier: "When it comes down to it, the programmer is far more important than the language."

"The blame lies in flat file database design, monolithic code, failure to refactor, failure to create unit tests. It's the RPG programming paradigm."

This is it. I'm done. Let's take just a few statements, and then I'm just going to agree to disagree with you.

RPG has arguably single-handedly revitalized the manufacturing industry. Prior to the implementation of the IBM midrange, ERP simply didn't exist in businesses, and certainly there was no automated way to implement JIT inventory control. If you know anything about manufacturing, you know that inventory control is the number one way for manufacturing companies to reduce costs, and RPG-driven ERP systems paved the way for automated inventory control.

Nobody uses flat files; we use standard normalized databases. RPG supports both ISAM access as well as SQL, NO OTHER LANGUAGE does that.

We don't use monolithic code. We use service programs and stored procedures and called programs. All of these serve the exact same purpose: reuse. Where Java has one way to do it (inheritance), we have many.

You're right, we typically don't do a lot of refactoring. That's because we do something different: we design the code up front and write it correctly the first time. What you call refactoring we call debugging, and we don't do nearly as much of it.

We do plenty of unit testing. In fact, the more rigorous project development techniques have three different test phases: unit test, system test and acceptance test. Each addresses different issues.

About the only thing we don't do which might make some sense (and we're actually starting to do it in the n-tier web-based stuff) is automated testing. You certainly have that, but when you're constantly "refactoring" you NEED to test more often.

Okay, that's it. I'm done. RPG isn't the end-all, be-all. It stinks at generating HTML or even XML; there are far better solutions. But it also isn't some sort of second-tier language. It has been and will continue to be a strategic business language, probably when many of today's "hot" languages have bitten the dust.

Joe

I see we are back into the RPG debate. Personally I think it is a great server side language. It can be written very modular with a large degree of code reuse if enough planning and good design is performed up front. Most clients I have worked with go from one fire to the other, so there is no time to "do it right". So what ends up happening is the perpetuation of crap on top of crap.

Not to mention that it is hard to find talented programmers with any experience in true ILE environments (i.e. that understand and can code subprocedures, use service programs, understand activation groups, can use embedded SQL, triggers, stored procedures. etc.). Many come from shops with canned vendor software that was designed in the 70's and evolved through code converters from RPGII to RPGIII to RPGIV without any restructure or redesign of the application. Since this is the typical environment, this is all many programmers know. Many shops dont want to progress forward for fear of finding resources that can support the newer features the system supports.

Instead it appears many businesses are more willing to throw it all out and replace their applications with something like SAP. I know of 2 such implementations locally, both large Fortune 500 companies. Another implementation is moving forward at another large company a few hundred miles away.

Ah, back to the "TOP REASONS WHY RPG IS BAD" debate.

1. Shops are too busy to write good RPG.
2. Programmers don't know enough to write good RPG.

1. Same with Java shops. Lots of code written, little of it very good. Lots of procedural mishmash. Lots of "cloning" of classes rather than using proper inheritance. Duplication of code. Binding of tiers. Poor naming, bad documentation, you name it.

2. For every RPG programmer who doesn't know ILE, you can find at least one Java programmer who can't explain the difference between a Facade and an Adapter. In fact, I'll bet you can find one who doesn't even know that those are OO terms.

This bashing needs to stop. RPG is as good a language as Java for what it does, and any RPG written (like any Java written) is as good as the programmer. There is nothing that makes one language intrinsically "better" than another; it's just that each is best suited for a particular problem set.

Most programming problems don't come from the language; they come from people. People that insist on using the Java hammer on the OLTP screw, or the RPG screwdriver on the SOAP nail. Or people who insist that all hammers are evil and must be destroyed.

Joe

Joe: I am certainly not bashing. My comments are from personal experience. Not saying its good bad or indifferent. Just seems to be reality (at least in Central Ohio).

I am sure there is really crappy Java, C++ and C# code out there too. I bet a lot of it is very procedural in nature too.

Just an anecdote to mull over:

I was at a large client and worked on an estimate for a large business unit within their corporate structure a few years ago. IBM GS was involved to help bring more credibility to the estimate and to develop build high level solution. This client is still a large iSeries shop. Used ILE concepts, SQL, triggers, etc. We wanted to use these skill sets on the server side and develop an n-tier solution with the help of IBM GS. IBM came back with a complete Java based architecture, completely discounting a) the skillset in-house, b) the fact it would be on an iSeries and c) it didnt have to be portable across platforms. IBM can be our own worst enemy when it comes to being a proponent of power RPG can bring to the table of a large enterprise development effort.

Speaking of modernization, my understanding from what little research I've had time to do is that the vast bulk of SAP installations are on non-web page interfaces.

Given that SAP ABAP has been likened to German COBOL and one of the few ERP systems that can match RPG ERP's on the AS/400, and that it's said to run on the AS/400, although I don't know under what setup, I consider SAP to face similar questions.

The difference is I admire and respect everything I have seen SAP do and say, and I defer my comment on IBM to the above post by SteveK.

rd

By reading the past several submissions, I can conclude that modernization means absolutely nothing to the average programmer. Most don't seem to understand the concept and write about RPG or Java in generic terms.

A few seem to think modernization and rewriting, I mean refactorization, mean the same thing. I would define refactorization as busywork in most cases.

The one or two here, besides me, who appear to understand the use of IT as a means to achieve corporate objectives are wasting good effort trying to engage the language enthusiasts into a serious exploration of the topic. Is the language enthusiast class the most common type of personality now in RPG level IT, or are they just most common here in the blogs?

I can relate with Steve's comments about IT departments using packaged vendor solutions, many of which were written in the 70's and 80's. People tend to adopt the coding styles and patterns established in packaged solutions for better conformity.

And once architectural and coding patterns are established, it can be difficult to change them, especially if you're a vendor supporting a lot of clients.

But I work for an iSeries ISV that IS rewriting applications that some of my colleagues wrote, beginning in the 70's. In the new version we're following MVC design patterns, and coding reusable components. We're using HTML/CSS/JavaScript and ILE RPG now.

There is a great case for incremental modernization of legacy applications, which has been a well received business strategy for us. There is a lot of pressure on IT departments to adopt Web interfaces, or be forced to migrate to Wintel platforms.

One of my colleagues calls it "colorizing old movies", which isn't a perfect metaphor since our code and application architecture are new. We don't use screen-scraping technologies, for example.

But it is a good metaphor in the sense that we're not changing the existing database, which over the years has degraded to something akin to 1st normal form, and constrains us from significantly improving the applications.

At some point, we're going to have to bite the bullet and design a new database.

AnotherView,

[[Is the language enthusiast class the most common type of personality now in RPG level IT, or are they just most common here in the blogs?]]

What did you expect to accomplish with this topic? This has been covered endlessly in a variety of ways throughout the years. Although I'm not taking offsense you are being very presumptuous.

AFAIK "modernizing" means many things to many different people. Systems are improved continually until they are replaced usually through acquistion, platform migration or business death.

It is a somewhat meaningless phrase like many acronyms. No one "modernizes" -- they upgrade parts, fulfill new requirements, build new modules, improve old ones, etc,etc.

There is no such thing as putting a pretty face on these types of applications that actually garners substantial benefits. The iSeries code base is built from complete, single threaded applications and mindsets, albeit imposed by the OS itself. A job cannot run more than one application at a time, except of course through the attention interface and that's still single-threaded and imposes restrictions.

Yes, of course you can run all jobs in batch and have a different UI layer like web or even GUI but the fundamentals of OO and multi-threading are completely ignored in favor of a "patched" or aka modernized product. That is it looks okay but has no relation to it's modern counterpart. In other words, a single threaded RPG application taken to the web or Windows is still a single threaded application.

The only supported architecture available on the "i" machines for a true modern "sanctified" approach to app development is of course the Java support. The rest are just kludges.

I'm not saying it's the best, I'm only saying that on the newly named "i" box the only architecture supported that is equivalent to modern methodologies in their entirety is Java. The rest are assembled patch work of methods to allow one to "look" appealing but have no relationship whatsoever to modern methodologies of development.

For example, event driven processing, multi-threaded processing and mutli-tasking have been available for years on all modern languages and architectures. Without using C or Java on the "i" this is all but unknown. It's not that the machine cannot do it, it's that the support is limited and only available in restricted situations, such as server only. This of course is the design architecture, to have single thread jobs. And it's been discussed before that IBM will not develop multi-threaded job capability. However, this and the other things mentioned are a hurdle that should be overcome. In order to bring Windows weenies into the fold or have "i" perceived as modern will take a lot more than a pretty face or adding PHP support.

This is not bad, this is not condemnation, just a simple fact that all this modernization talk ignores.

That said, the "i" architecture is great and thank you IBM for continuing to improve upon a beloved machine. Amen.

What is the heartburn over single threaded applications? An application supporting the maintenance of User Profiles might be accessed only occasionally by a few people. Why not load the application when needed, run it as a single-user stateful server, and unload it when the "Exit" link is clicked? A typical ERP system calls for hundreds of applications of that type.

Refactoring (improving the internal structure while retaining the original functions) makes applications easier to maintain and more flexible. The structure I now use for most interactive applications consists of three (3) module types. (1) Controllers (2) Action Handlers and (3) Database I/O modules (including data validation and business logic).

Controllers simply route requests from clients (browsers in our case) to specific Action Handlers, which perform Screen I/O and make calls to DB I/O routines. Code separation makes modules easier to understand, fix, and change. Changes in database structure generally only has an impact on DB I/O modules. When tracking down a bug in data validation or business logic, there is no need to wade through screen I/O code, or control logic. If browsers were to become obsolete, DB I/O modules would remain intact while Controllers and Action Handlers would be replaced.

Sometimes a database and business process change so radically that it wipes out an entire application, no matter how well structured the code might be. In that case, at least you know which modules to cut and paste from ;-)

This is about modernization of our AS/400 business systems, not just the RPG language. Many languages are available, including Java and C++. If you think a threaded language is a necessity for part of the modern application system, what would you do with threads in an ERP program, and why does that make the application modern?

Threads is more of an operating system philosophy, and has been around almost as long as I have.

But if you have justifications, should the thread tasks be given to a module of an ILE program that is thread capable, all in Java, or just what? What is the basis of the philosophy, the vision?

My vision is that OS/400 handles comminications, the desktop client handles thread enabled user interaction, and good solid business programming continues with the job architecture of OS/400.

Or maybe it's just terminology. Threads in Unix, jobs in OS/400. There's a difference in granularity, and certainly there's been much discussion of Linux's handling of threads for the same granularity reasons.

But a basis of modernization? I don't even think it's a good idea for a server job, much less the bedrock core requirement, unless you have to do something like handle your own sockets communications, and the question would be, is that supposed to be better than what we do, more "modern"?

rd

Refactoring runs counter to the practical "if it ain't broke don't fix it" philosophy, but it need not be a form of busywork. As Nathan clearly points out, it makes applications easier to maintain and more flexible, and this translates into higher productivity and reduced maintenance costs. This is why the practice has become so widespread in the OO world. Although it may be more difficult to "systematize" refactoring for a procedural language like RPG, it is still a sound philosophy for maintaining the quality of software, enhancing productivity and reducing maintenance costs.

The assertion that the term "modernization" is meaningless and that it is "presumptuous" to even use the term is itself a presumptuous assertion. That would be presuming that all our colleagues who use the term don't know what they are talking about, or worse yet, are talking about nothing. I would not care to presume this.

To conflate modernization with all changes to applications is to deny a useful distinction between the motivations for changes. Many changes are performed because there has been a change to business practices or enhancements have been approved. These would normally not be called modernizations but, well, revisions or enhancements. We generally use the term modernization to refer to changes which are motivated to a significant degree by a desire to change the behavior or internal structure of an older application to take on characteristics reflective of newer practices. It might be the desire to go from green screen to GUI, or to increase modularity to better serve web enablement or services-oriented objectives. I think most IT professionals know what kinds of changes fall within the modernization category and which are more normal everyday maintenance.

The topic will not go away by declaring it meaningless. Because of the historical dimension of the iSeries world -- the prevalence of countless mature applications which retain high value -- it is a serious and legitimate concern. Many of these applications are now reaching a state where a difficult decision needs to be made: to modernize or to replace. Preservation without modernization is becoming less and less of an option as time goes on.

I think it's a fantasy world to believe that Java developers are sitting on smoothly running systems and then go in and "break" those systems and rewrite them so that there will be "less" work in changing them in the future.

Give me a break. What a crock. They are like anybody else. They are in there because of serious problems, in my opinion usually serious performance problems, and are rewriting out of need.

In our world, we call it redesign. But in our world, it takes a seriously bad CASE tool fiasco to require going back to the drawing boards and "refactoring".

This is an important distinction, as there is no business that is going to allow working systems to be broken and completely retested because Java programmers are feeling proactive.

Now, are interfaces refactored or redesigned during development? Sure, if it's broke.

Is modernization having the resources given to you to redo, retest, and reaccept working systems and interfaces in anticipation of making some possible change in the future easier?

What a brave new world. I can't see any business signing off on that ROI.

rd

Ralph: and that (ROI) is why (IMHO) "refactoring" will never be performed by most companies. No public company would commit the resources to such an endeavor with SOX requirements for the SDLC of a project being what they are today.

Off topic: anybody seen the newsline on the right "system i drop revenues 22%".

You'll probably have to reread to understand, I was referring to "system i".

Add to that the 25% drop last year in last quarter and system i has catapulted itself to the black sheep in ibm's stable. No wonder with such a name. System i is becoming history, and the figures prove it.

So for all system i consultants, the message is no longer "MOVE ON IF YOU CAN", the message is "MOVE ON NOW".

Right, Steve. That's why most solutions for modernization have been from the screens to basically web pages or Java form screens. It doesn't break the existing systems and provides new GUI'ized interfaces to those systems. The ROI is there to do just about anything you want with 5250 being a conduit to proven business transaction processing.

I did want to bring up the refactoring possibilities of that production code, sometimes referred to as modularization, to expose new interfaces to business logic without breaking any existing higher level interfaces such as program call parms.

I think just modularization for modernization sake, an internal IT thing with no functional difference to the business, is the refactoring I was talking about earlier, whatever the language, for which there is no ROI a business will accept.

But a refactoring that exposes new interfaces for things like SOA is of course potentially heavy in ROI. I think the question posed is what are some of the possibilities for doing that cost effectively, and usually the answer is a rewrite leaving the old untouched, which gets you more redundancy rather than less.

I would like to see the 5250 buffer used as an API for any interface in parallel with running as a 5250 interactive program. Then the screen I/O becomes the API for the enterprise business transaction processing.

It's a natural progression from intercepting the screens for the web. There needs to be hooks and a communications infrastructure for us to make those calls machine to machine as in SOA, do anything with the data anywhere before returning with input, and to simultaneously handle a number of types of GUI interfaces from the equivalent of virtual controllers.

The key is a solid OS/400 i5/OS infrastructure to expose that API, which appropriately then enables our API's.

rd

I have probably been mistaken in thinking that the OO practice of refactoring could be transferable to a procedural language like RPG. Although we may glean some valuable insights from refactoring literature which may help us structure our code, it may not be realistic to think we can implement a disciplined practice of refactoring in a procedural language. It is probably more realistic to rely on standards and best practices, as we have been doing for decades.

In a sense, refactoring in the OO world is just a formalization of something we have always done in a less formalized way in RPG maintenance work. Every now and then a program becomes so convoluted from layers of modifications that when we get it for yet another modification, we realize we have to clean it up, restructure it a bit, and give it back some of its original elegance -- AS we perform our maintenance task. We do this to maintain the quality of our code and to reduce future maintenance costs. The restructuring for the sake of clarity and quality is . . . refactoring.

In the OO world this activity can be formalized and even automated (with refactoring aids in IDEs) because OO languages are more structured and there is a body of identified code patterns which are known to be best practices. In procedural languages this might not even be possible.

But Ralph, I appreciate your refocusing of attention away from refactoring, to modularizing for a purpose -- whether for the purpose of GUI or SOA or portals or integration or whatever. Restructuring parts of an application to expand functionality is far more important to modernization than the pursuit of elegance (which users can't see) and reduced future maintenance costs (which are speculative and difficult to measure).

Dependency injection as provided by many Java frameworks reduces coding where it is used by 50%. Other design patterns provide flexibility as well as reducing the amount of coding. What are the patterns and anti-patterns of RPG development? When I compare my almost twenty years of RPG development with my five years of Java development, this is the question that looms largest.

No Max, you weren't mistaken in thinking that the OO practice of refactoring could be transferable to a procedural language like RPG.

Isolation, encapsulation, and reuse are as applicable to RPG as in any language. RPG may not support inheritance and polymorphism in the same way as an OO language, but those things are more likely to be misused than used properly in refactoring.

I agree that in an OO community, highly-structured design patterns are more well known and established, but many ILE developers are employing a significant amount of OO in their designs.

The problem with refactoring a procedural language like C or RPG is that there aren't very good automated refactoring tools like what you find for Java. IntelliJ IDEA, NetBeans, and Eclipse all have pretty solid refactoring support.

Sure, you can do it, but it's a tedious and error-prone process. The ROI had to be really compelling.

--Robert

p.s.--People who think that System i people should "move on" should really lead by example. :-)

Does modernization matter? The recent news that AS/400 sales are down 22% from the same quarter last year on top of other recent sales declines makes you wonder.

Also, remember Sun? I just read a story in the financial press about them having a bad quarter. I'm sorry for Sun, but the news made me remember that I had completely forgotten about them and that I don't know what they sell any more. They don't seem to be in the news very often unless you are looking for them.

Is this what the AS/400 has ahead of it? Sun used to be on fire (no pun intended). When did the Vax finally disappear?

Max, Here's some simple changes that have been suggested to me. I'd like to know which of these you'd choose:
For a critical table, important to the business, do you

1. remove F specs and replace IO w/ SQL in each PGM or module

2. move IO to a SRVPGM and have a procedure return the record format

3. move IO to a SRVPGM and have several procedures which return various data structures

4. move IO to a SRVPGM and have field getters and setters

Doesn't a company risk having its database design go stale by coupling hundreds of programs to its tables and making change expensive?

Greg, of the four options you list, I have used option 3: IO service programs with several procedures. However, rather than "returning" data structures, they are "shared": the calling program or procedure imports the data structure exported by the IO service program procedure. What is "returned" is a small data strucure containing success/fail and other control information; what is "shared" is the data set. The data set is not a record format, and the relationship of data sets to tables is many-to-many.

We used this approach to develop a layer of IO service programs for data access to be used by middle tier business logic programs or procedures. The IO procedures were all embedded SQL.

I think setters and getters could be included in this approach where it seemed appropriate, but we shared data structures between the IO and BL layers, and the business logic modules would do their getting and setting from the data structures.

This was solely an RPG and SQL application; we were not concerned with interfacing with Java. This was back in 2000/2001. An IO layer which could be used by both RPG and Java might be better implemented with internal SQL procedures which could be called by either Java or RPG. This might be an option 5 for you to consider.

I do not see options 1 and 2 as at all attractive.

And yes, of course, tightly coupling your business logic to your database makes database changes expensive. The virtues of a layered architecture are pretty clear, I would think.

BTW, Joel Cochran has some useful online articles about this at the IT Jungle website. His approach is similar to, but not identical with, the approach I have experience with.