System iNetwork

What the Heck is EGL??

I've just been coming to grips with the fact that I should be learning Java/PHP/eclipse and now there's something new?? Give me a freakin' break. That's one reason why I think I've stayed so long in the RPG world - it's easy to program, there's nothing it can't do (for business users) and it works rock solid. Every other thing that came up since I was in College has been interesting, but not important.

I doubt that EGL thrown in with the software development license would get any more use than those who will choose to pay to use this CASE tool for J2EE development.

If they want to go that route, in terms of ease of generating J2EE apps, given the publicized complexity of that process it obviously has the potential to have significant value.

But we have the choice of a lot of CASE environments, choices that have better System i vision than IBM's cross platform middleware vision.

That is, if you want a CASE environment at all.

rd

I agree about programmers dragging their feet. I was at COMMON over 15 years ago and some people were talking about RPG/Free. I grew up using Fortran, PL/I, COBOL, etc, and was used seeing the program structure via indentation. I was shocked to find quite a number of people who said they preferred having things in columns.

Right now, I think one of the big factors in moving forward is infrastructure. Most of the tools out there haven't kept up, and with the advent of SOX, many companies are required to use formalized tools for development and implementation.

Examples:
I have /COPYs that include libraries of procedures. They makes groups of procedures AVAILABLE in to programs. The cross reference tool we use though thinks that every procedure is USED in every program - giving many false references.

IBM still hasn't given us the capability of including all the various compile options in the header of a program, so you have to remember which options to use for which programs - or put together your own pre-processor - which may or may not work nicely with your change management tool.

There has been no (simple) standard come out for a user interface (GUI or browser). There are a dozen different ways of tackling the problem, but no clean, supported standard.

On the iSeries, the database, security, etc. are all built in. They are standard on every box, so everyone uses them. If you have a package that runs on the iSeries, it will probably run on EVERY iSeries, because everyone uses the same underlying objects. There is no standard for a GUI interface though. People are dragging their feet because they don't know which ones will win out - Which ones will be supported - and which ones they'll have to throw away.

Change management tools sometimes don't handle the new object types easily. They may require the user to create their own, or require multiple steps to implement a single object.

Data driven applications require a different kind of change management - managing changes to specific rows (or groups of rows) within tables (a data dictionary for example). Most change management tools don't do that well.

Before free format, I didn't like RPG. I considered it to be a self-undocumenting language. With the changes of recent years though, I love it. There are many more built in functions that would be nice, and there are some quirky limitations, but I don't know of a better business language available.

This is one of the more balanced and least vitriolic threads of dialogue I have seen on this subject for a while, starting with Paul's comments. I think from a programmers point of view RPG in any form is still uncontested as the best way to write business logic for a business application.

From the company who employs the programmer's point of view, the question in almost every instance is how to take 1 million lines plus of existing RPG, get rid of the UI logic and reuse the business logic in RPG. If that happens in the mainstream, then RPG would stand a much better chance of survival. It would also mean the debate about the appropriate UI view and controller logic langauge to use could (and should be) held at a specific case level, whereby the access to resources determines the outcome. Each of them: PHP/Java/VB/C# have their own merits that largely balance out overall anyway.

RPG is by far the most efficient business programming language in use today. IBM software engineers have done a super admirable job in crafting a language which is C like in its efficiency but with none of C's rough edges ( file handling, external program calls, string handling ).

But placing a premium on program efficiency makes sense only in the quarter to quarter profit world of the IBM product placement exec. RPG does not support classes, instance methods, garbage collection, object references. All of these features require a level of indirection which would bog down the typical single and partial core system i. Without these features, the RPG programmer has limited access to the rich frameworks used by the Java and .NET programmer.

-Steve

Based on what I've read in other posts in the last several days (fabulous reading, thanks to all) I have this collective suggestion to IBM:

• Give us a version of Client Access that has a browser-like interface . . . but accepts a rich GUI-enhanced 5250 data stream and presents it like an HTML browser.
  
• Give us GUI Design Aid to plan and organize a nice GUI screen that I can work with in WSYWIG, or in SEU. It's not a big leap . . . we already have radio buttons, check-boxes, drop down menus, scroll bars, and so forth in SDA -- why not add more functions like imaging, sizing, bullets, fonts, etc?
  
• Give us GUI opcodes, bifs and data formats/structures in the RPG language to manage the GUI 5250 screen functions. Again -- this was already done in VageRPG -- so just bring that into regular RPG.
  

Viola! A native System i GUI!

I know, I just described some kind of unwieldy, proprietary cross between VageRPG and Web 2.0. But if the shoe fits, I'll definitely wear it. And don't tell me IBM wouldn't do it . . . they DID do VageRPG, so they CAN do this, too.

I think us holdouts all need to face something -- if some version of the above suggestions don't fly, then we are doomed to either stay in green screen or learn something new. . . .

Navel staring and more....

One of the problems with System i is that developers have a tendency for navel staring of which this interview with RPG expert Paul Tuohy is an example.

Suppose you were involved with the development of a product for many years, it is likely you will say things like 'tremendeous achievements' were obtained, this is the best system or product ever made and more of these extatic remarks. Next thing that happens, the community members fall into each other arms, crying, saying man, we did it, the best product ever (and next, the usual quarter showstopper with the 20% decline in sales). Ok, we're no dummies, so we have to balance the euphoria with some criticism, which in this case is the innocent "rpg programmers are slow to adopt the new features".

I would prefer a more balanced discussion, whereby RPG is compared with other IT languages.

Recently, I came across Oracle PL/SQL. The experience I have with this language is about 1 year for 10 years of RPG.

What is PL/SQL? It is just plain SQL that Oracle enhanced with Procedural Language features like loop constructs and it-then-else logic (hence the PL in its name).

Let's see how a substring works in PL/SQL:
if substring(some_field, 1, 3) = 'ABC' then...

Let's see how we do it in RPG:
if %subst(some_field:1:3) = 'ABC'
in CLP: if %sst(&some_field, 1, 3)...
in SQL: same like PL/SQL

PL/SQL has the advantage to define one ansi sql language based construction for a given function instead of the multiple flavors of the RPG/CLP world.

Let's see another:
PL/SQL: if some_field in ('A', 'B', 'C') then...
RPG/COBOL/CLP: if some_field ='A' or some_field='B' etc...

And another:
In PL/SQL, we don't bother anymore with field lengths (although you still can). We have datatype NUMBER, DATE and VARCHAR2. Character fields are variable length, so a maximum length of 64K can always be choosen without disk space loss.
In PL/SQL many databases start using Large binary object datatypes. So for example, in a hospital patient database, you could store the patient's picture in the table. DB2 has that possibility too, but I've never seen it used. Can RPG exploit it?

In short, I do appreciate the opinion of an expert, but it gets much more weight if he or she is able to do a comparative analysis with competing products.

IBM is hosting their big fall technical conference in Orlando right now and I was very favorably impressed with the number of sessions centered around RPG.

I've done a lot of development under Z/OS and Windows, and quite a bit under Unix, but ILE RPG and the I5 native virtual machine are the best. I've done a lot of development with OO languages but I hope IBM doesn't turn RPG into another one of them, or turn the native virtual machine into an equivalent of the Java virtual machine.

As far as a native GUI interface for RPG is concerned, I've responded in the other blog in a somewhat chiding way to those who keep calling for one. I personally finally bit the bullet and learned HTML, Javascript, CSS, the browser document object model, and Web 2.0 interfaces. I still use RPG exclusively for the server side code, but I didn't get stuck in a rut waiting for IBM to come up with the type of native interface that several people are calling for.

While IBM may charge for EGL, the cost will probably be offset by falling hardware prices. IBM is simply un-bundling the software from the hardware because there are so many choices available now. I understand that some people will find that hard to deal with but they should be able to start thinking and acting for themselves - outside the box.

"a better business language available"
COBOL been here for years, has the most lines of code in use today and runs on all platforms

HTML and CSS only replaces the 5250 rendering of business applications. The question isn't just what should be the System i's default user interface be, it's what can or should replace our DDS driven interactive programming environment?

Is the answer nothing, as in pay for some other software development license other than IBM's for an interface such as BCD or PHP or JSP, or any other development environment that can generate web pages, as something that each System i owner must choose, and everyone go their separate ways?

Or perhaps we agree that IBM's DDS oriented development licensing including WHDT Webfacing and/or HATS to convert to web pages is at least the default interface, with other development options as listed above?

If there had never been DDS and 5250, can anyone possibly believe we would have had the success we had all these years with everyone rolling their own solution from a hodgepodge of development solutions? Not a chance.

Quite frankly, 5250 still beats the crap out of these shaky web environments but no one but people who actually have to use this stuff cares.

I agree that interactive logic needs to be externalized from our RPG programming going forward, and I think that from an external program multiple interfaces should be supported by open source service programs.

I'll be experimenting on that end, unless something more coherent than HTML and CSS is arrived at as the answer in the meantime.

rd

First, I love the I-Series/AS400. It is the only platform that I'm aware of that I can take full advantage of the latest and greatest hardware WITHOUT recompiling my code. Of course that ride is about to end after many years with the newest release of the operating system. With that said, let's talk about RPG and other languages. RPG is NOT the end all, be all of the entire programming world. AND neither is any other language. Each language was developed with a particular need in mind and each should be used according to what is trying to be accomplished COUPLED with the knowledge and experience of the programming staff. Green screen was great in its day however I can no longer see the need to develop NEW green screen at all. Please note I said develop NEW green screens. Whether we accept it or not the user is used to the browser or browser like interface. Therefore, each shop needs to decide what they want to use for development of the browser pages. I’ll refer to this as the front-end.

There are lots of choices and development environments. Again the decision has to be made based upon the knowledge and experience of the programming staff. Now the back end is definitely the arena for RPG/free/IV/ILE. And While I might agree that more COBOL code is in use in the world than RPG, I don't believe that to be true on the I-series. RPG was developed after COBOL and was more finely tuned to OS400 than COBOL ever was.

In addition, there have been more developments/additional features added for RPG over the years and to my knowledge little added for COBOL. COBOL still has a major draw back in my mind in that it does not inherently open or close files. In RPG, the compiler understands by default that I want to open all the files at the start and close them all at the end. And if I have a file that I want to personally control I can do that too like my COBOL brethren. I usually implicitly open/close log files or error messages so they are only used when needed. I'm sure we can start a whole long discussion about which language is better for back-end processing but again I refer back to my first comments about what each language was developed for AND the experience and knowledge of the programming staff. Even if one language is better than another, if your programmers don't know it, it won't get done well in a timely fashion.

Oh and let's not forget what I'll call the language of CL. There is one heck of a lot that can be done very well in CL. This is one area where the front-end languages like JAVA don't even compete. And let's not forget that most SQL of whatever flavor can usually be copied and pasted into RPG/SQL/ILE procedures without any changes and get the same result. Only now the code has been compiled and optimized for OS400 with great results.

Is SEU dead? I'd say for the newer and younger programmers YES. I applaud IBM's new development interface. Here's what we should have had all along. A single development environment that no matter which language is used the interface is the same. IBM went out and bought what was considered by many as the best development environment in Eclipse and took other parts of their best development environments and combined it into one really great hybrid. So now, even though we might have different programmer groups using different languages, they are all using the same interface and this leads to greater understanding and collaboration between the groups. As for old fogy’s like me I'm learning the new environment and still rely upon PDM and SEU to get my work done.

Is RPG dead or dying? Well, the idea that IBM is considering big changes (per-seat charges) for the I-Series community bodes badly for RPG and the I-Series in general. One of the reasons that the I-Series was worth its salt was all the bundled software and compilers that came with the machine. I agree that this is radically different than other platforms. AND IT NEEDS TO STAY THE SAME. This is one of the inherent values in the I-Series. If IBM starts to whittle away the core values in the I-Series then the more the I-Series becomes like the platforms it competes against. One of the great values for the I-Series is that I can have as many programmers as I need without additional charge. So if all of a sudden I have a large project there aren't additional costs for the extra seats. Also, all the development software I need is present. This is an understated value that should not be changed. Believe me as this changes I see this as the death knell for the I-Series.

As to the other comments about PL/SQL and not bothering to have field lengths. First all of the field types that are standard in SQL including large objects are handled by RPG ILE. So I'm not sure what you are talking about. As I said I've taken whole SQL code from other platforms including field definitions and pasted them in RPG/SQL/ILE procedures and compiled and used them without problems. As to not having field lengths, that makes sense for date & time fields where we have a standard of 26 bytes. But for many fields having a length makes sense, otherwise the database always has to set aside extra space because it never knows how much will be there. For text type fields that are notes/sentences, this makes sense, for another field say a 2 byte field for the State it should be only 2 bytes and that's all the compiler or database should set aside. Even the lines for an address should have limits. I certainly wouldn't want a field that represents the any line of an address to be VARCHAR without a limit. Eventually I'll need to print the address and if they were stored without limits I'll be cutting off data. And the same can be said for numbers. If a numeric field represents a 10 digit phone number then it should be defined as 10 bytes. Believe me there is associated overhead in both the database and the compiled program when storage to hold a 32 digit number is set aside when only 10 digits will ever be used. Part of Database 101 is data integrity and that starts with defining a field for what is really is so that you can't have 12 digit numbers in a field designed for a 10 digit phone number.

The I-Series handles large objects in RPG/ILE very well. I did a project in 2004 for one of the largest banks in the US in 2004 and we stored the head/shoulder shots of more than 20 million customers all on the I-Series IFS. That's right I said more than 20 million customers. We had sub second response time access by more than 30,000 concurrent users/tellers around the country to any of the 40 million images. The front-end was java and the servers were UNIX boxes that called ILE service programs that included sql procedures on the I-series. There were 2 pictures of each customer, the most recent one and the one taken before that. When the teller called up the customer the last 2 images of the customer appeared in less than a second. More than 8 years ago I completed a project where we stored all kinds of large objects on the IFS for an insurance company. We created subdirectories for each customer for each type of policy they had and then created additional sub-directories within the customer's policy directory for each claim. We stored any mail they sent after it was scanned, we stored x-rays and other images from the radiology departments of the hospitals (these were very big), and the pictures taken by adjustors and people at the scene and just about anything else. I don't know who you talked to or read, but the I-Series and RPG have been handling large objects well for years and on a large scale. I mention these 2 projects because I managed one and was the chief designer and implementer for the other.

And last but not least, I have no problem thinking outside the box. I have no problem with having lots of choices. I DO HAVE A BIG PROBLEM WHEN OUTSIDE THE BOX COSTS ME SIGNIFICANTLY MORE MONEY. More choices should mean more competition and lower prices not the reverse. If more choices means it costs me more then I don't want the choices and I'll keep my head and wallet in the box, thank you very much.

"...Recently, I came across Oracle PL/SQL. The experience I have with this language is about 1 year for 10 years of RPG. ..."


"...What is PL/SQL? It is just plain SQL that Oracle enhanced with Procedural Language features like loop constructs and it-then-else logic (hence the PL in its name). ..."


ugeerts,
I dont have much knowledge of the history and variants of SQL procedure language, but all of that highly functional looking PL/SQL code you posted will compile as is as an sql procedure on your neighborhood as400.


In my experience, once an as400 programmer starts coding sql procedures they have little use for their rpg skills.


-Steve

Hello P N Robert,

I've not much time so I ll send you a quick reply.

1) About Field lengths.
(I refer to my observation that in PL/SQL much less emphasis lies on field lengths).
By convention, most PL/SQL shops split characterfields in arbitrary lengths, fi. short (20 digits), long (200 digits) and very long field (4000 digits). 200 digits fields usually contain person-, street-, community names or item descriptions. 4000 fields are usually text notes. So what about displaying or printing these fields when not enough room is available? Well, for screens, you forgot about the decade's long standard in the graphical world to be able to scroll horizontally in a field (look at the Url address field of your browser fi.). As for printing, yes, as I said, you can still/and should impose more severe field contraints on names and addresses, but you also need to take into account the print font being used which affects available space.

2) Binary large object datatype (BLOB datatypes).
You confused the IFS file system with storing images, video, audio DIRECTLY as a field into a table.
What I mean is you have fi. a
person table, with columns
person-id,
person-picture,
person-introduction-speech.
The option of either storing multimedia files either in a hierachical file structure (IFS or Unix/Windows directory structure) or storing them as table fields, is tilting in the Oracle world to the latter. Reasons are clear; faster index search (in comparison with OS API's who have to scan a directory for a certian file) and better integration with the data.