What Does IBM Need to Do with RPG?

[buck.calabro@commsoft.net]

What Does IBM Need to Do with RPG?

4. How could RPG/400, RPG IV, Code/400, and /Free not be considered a fragmentation of an industry so serious as to threaten the continued existence of software development firms developing commercial packages for the AS/400?

That's a strong sentiment, and one I can't really grasp. I am probably THE most antique of the posters on this topic, having started in the S/3 model 10/12 days. If I can handle the changes to RPG, I think anybody can. I personally have no trouble whatsoever moving from editing my /free BIF-laden code with Code/400 to a matching record program in S/3 RPG II style using SEU. I did just that last week. It reminded me of changing seats from a 3741 to a 3277 to a 5251. The keyboards were different, but as a human being, I was able to adapt to the differences and still get lots of work done. I agree with Bob that a formal public review period for change would be Nirvana, but I do not agree with the general sentiment that RPG is now too difficult to work with because I can use 4 varieties of CHAIN (as an example.) We have always seen variety in the way code was written: look at the number of "standards" for indicator usage. --buck

[buck.calabro@commsoft.net]

What Does IBM Need to Do with RPG?

I'm all for advancing the profession and the tools we have to live with. IBM should be giving us simpler, smarter ways to develop applications.

This is a very reasonable wish; requirement, even. That's why I use Code/400 instead of SEU. It's much simpler to get code changed and has triple the IQ of SEU. You have a differing opinion of Code/400 and that's okay. Perhaps there needs to be a thread on editors where people can trade ideas?

My point is that even you raving RPG Free enthusiasts need to expect more for your time and money. These little tid bits we are being given aren't worth the time and money it takes to learn to use them.

There's a lot of heat in there, but I can't see the fire. How hard is it to understand today=%date(); ?

Let RPG be RPG and let's spend some money on a new language like MS did with C#.

But isn't that exactly what is happening? 1) Nobody, anywhere is forcing anyone to use anything newer than S/36 RPG II. Anybody can load the S36EE on their machine and work in the environment that is comfortable for them. 2) V5R1 RPG IV still does matching record. You can't code using the exact same columns, but you can in fact code the same exact opcodes I used on S/3. 3) RPG IV has lots of new features and even a new name. Perhaps a better question might be "What do we mean when we say 'Let RPG be RPG'?" --buck

[Guest.Visitor]

What Does IBM Need to Do with RPG?

Bob's remark that “If I write a piece of code that utilizes a V5R1 built-in function, that code cannot be used on V4R5 or earlier. Again, nearly 85% of the RPG IV users out there would not be able to take advantage of it.” Here is my answer: ...YOU NEED to update OS/400 as soon as possible to be able to utilized its new capabilities!. How many of those same companies are running DOS 7.0 on their PC's or maybe Windows 3.1. Most likely they are on W2K or XP or moving to them. I LOVE what IBM is doing with RPG ! it is about time KEEP IT COMING !!!! I will ask IBM to continue to package RPG II (..no need for if/then, case, while/for loops, subroutines ….that is what indicators and GOTO’s are for) for those of you that want to continue to help the so called consultants and RPG haters bashing the iSeries for the shortcomings of the language. (I still have some RPG II templates and132 report column forms for reports, I will be happy to mail them to you. Remember RPG stands for Report Program generator. So ALL it can do is create reports. …”actual words from a consultant I met recently”) IBM: For those of us that welcome the updates give as a NEW LANGUAGE call it APL (Application Programming Laguage). Introduce it with V5R3 ! Now, IBM have just increased the number of languages that an iSeries box can run. COBOL, Java, C, RPGII and APL !!!! Take your pick ! (forget RPGIII and RPGIV…. too complex to use) and that my friends is my humble opinion! PS: Ford just announced some “NEW” model T’s for those of you using RPGII

[J.Wells]

What Does IBM Need to Do with RPG?

"....NEW LANGUAGE call it APL...." Sorry, APL already exists. I do not know much about it, but I do know it is supposedly an actuaries best friend. I also heard that it stands for "A Programming Language"! Joe P.S. http://www.engin.umd.umich.edu/CIS/c...0/apl/apl.html

[R.Daugherty]

What Does IBM Need to Do with RPG?

I wrote: "4. How could RPG/400, RPG IV, Code/400, and /Free not be considered a fragmentation of an industry so serious as to threaten the continued existence of software development firms developing commercial packages for the AS/400?" buck, you took fragmentation to think I meant difficulty in handling multiple versions of the RPG language for some reason. None of these syntactical variances are difficult for the typical RPG programmer working with an existing body of code. Of course, somebody wanting to do something in a newer style and not having a body of code in it has to figure everything out, and often for no benefit but their own enrichment as it would be a variation project that is sometimes not welcome or even allowed in shops. What I mean by fragmentation threatening commercial software development for the AS/400 is not that multiple versions of RPG would be too difficult to work with, nor this notion that's been repeated a few times that RPG should stay dumbed down for consultants so they don't encounter difficulties moving from shop to shop. That's actually hilarious, given what all consultants encounter in their travails. Rather I meant the body of work of green screen packages that made the Sys/3x line the workhorse of mid sized industry was in RPG II, then RPG III, with a common green screen interface and a common development environment. Packages were written and sold with RPG source code, and a rich custom code business rule industry existed to let businesses run the way they needed to compete. There was no fragmentation of development, with even case tools generating out RPG that could be modified if required. But now, are there any new RPG packages being written in any of these versions? Are there any new AS/400's being sold to run packages like businesses used to do to run the competitive AS/400 retail, warehousing, financials, and manufacturing packages that used to drive business? If one were to start a software company now, would they write the software in any version of RPG? They used to, why not now? There's no one reason, and I'd love to hear several of them, but one outcome of that I think is that I never saw RPG IV permeate the commercial package market and make its way into AS/400 shops as RPG III/400 packages did. Much custom development is driven by the base code in a shop, and if RPG IV was the base code custom code would probably be in RPG IV as well. The notion is apparently that the base code may be RPG/400, but custom code would be done in RPG IV/ILE to take advantage of better syntax and modularity. If enough custom code is written, then inertia builds, espcially with subprocedure modules that can be linked to new programs. Maybe that happens in places, I know it does at work here with RPG IV but not ILE modules, and maybe it doesn't happen so often. Certainly the base being in RPG IV/ILE would make the difference, and the fact that RPG IV/ILE not being widespread in commercial packages is really the key, in my mind, that most still work in RPG III, as I do in my customized package work here. Through the last couple of years we've had some interesting discussions here at MC about RPG being the ideal database I/O business logic engine, and developing it isolated from the interface. I did that writing the Jobs400 backend a couple of years ago in RPG ILE, including modules, and driving a web site, green screens, and batch jobs simultaneously from the same server programs. Again, though, without a commercial implementation in place developed in that manner, I think it would be more difficult than desirable for most to put that architecture into place and build on it, nothing like patterning on a commercial architecture in place. Will the new AS/400 program development environment that I read about last year become widespread enough that it will be a no brainer to develop new AS/400 commercial software in it? And if so, what will be the architecture of that commercial software? RPG programs called by JSP's generating web pages? If not that, what, and why? Or will there ever be new commercial software developed again for the AS/400? rd

[buck.calabro@commsoft.net]

What Does IBM Need to Do with RPG?

What I mean by fragmentation threatening commercial software development for the AS/400 is not that multiple versions of RPG would be too difficult to work with, nor this notion that's been repeated a few times that RPG should stay dumbed down for consultants so they don't encounter difficulties moving from shop to shop. That's actually hilarious, given what all consultants encounter in their travails.

Rather I meant the body of work of green screen packages that made the Sys/3x line the workhorse of mid sized industry was in RPG II, then RPG III, with a common green screen interface and a common development environment. Packages were written and sold with RPG source code, and a rich custom business rule industry existed to let businesses run the way they needed to compete. There was no fragmentation of development, with even case tools generating out RPG that could be modified if required.

Very eloquent! I'm getting closer to understanding your viewpoint, so if I miss something, please bear with me... The fragmentation you speak of isn't the language, it's the runtime and development environments? ("...common green screen interface and common development environment.") The green screens I've been exposed to have been a tremendous mis-mash of old-style S/36 array-based lists, S/38 style subfiles (in all three flavours) SAA CUA panels and even UIM. SDA menus and hand-rolled, no common SFLxxx indicators; you name it. It seems to me that green screen was fragmented even in the S/36 days between the people who created arrays and those who used variable start line. The development environment is a very valid point. One cannot approach ILE with the same happy go luck attitude when dealing with OPM programs, that is for sure. But I liken ILE to the introduction of external files. I remember the uproar when external files were introduced to RPG "Now we have to compile TWO things to make a program work!" Somehow, the majority of RPG folk got past that, even though we do occasionally forget to DSPFD before recompiling that printer file and lose all those attributes that live only on the CRTPRTF command, and not in the DDS. (Common external file complaint number two.) If one looks at ILE in the same vein as external printer files, it can be seen that it brings the possibility of much complexity, and many opportunities to make a mess, but it also allows for great flexibility, and managing the practical complexity is not all that difficult.

Is there any new RPG packages being written, in any of these versions? Are there any new AS/400's being sold to run packages like business used to do to run the competitive retail, warehousing, financials, or manufacturing packages taht used to drive business?

My company writes new software every day using Synon and RPG. We sell iSeries boxes to run that software and have displaced competitive Unix solutions. I would say that there are still some of us out here!

Will the new AS/400 program development environment that I read about last year become widespread enough that it will be a no brainer to develop new AS/400 commercial software in it?

Eclipse? My dim bulb just lit up another candlepower's worth. I Run Eclipse here just for Code/400, but there is a lot of cool functionality in there, and it's getting stronger all the time. Our product isn't web based (yet!) but if it were, Eclipse would be an excellent solution for bringing together all the components required to build true web apps. But for today, all I use of it is Code/400, which I love to pieces! But this isn't really part of Bob's original article...

The notion is apparently that the base code may be RPG/400, but custom code would be done in RPG IV/ILE to take advantage of better syntax and modularity. If enough custom code is written, then inertia builds, espcially with subprocedure modules that can be linked to new programs.

I've been around midrange machines since 1978, and I can easily remember how hard it was to buy any S/34 based software aside from a few large packages. S/36 had more applications, and finally saw the birth of a (very small) independent software business, but it took at least 5 years to get rolling, and that in the days when there was no real competition. Today, the PC gives all midrange software houses fits. How often do we hear that "We can put up a Linux web server for the cost of that old PC we were going to throw out." It's not true, of course, but we hear it all the time. Windows is everywhere, and the cost of a Windows box has reached the commodity level. iSeries hardware (and therefore software!) cannot easily compete based on price, and it seems pretty clear that efforts to differentiate us in other ways have not been entirely successful. I don't think that BIFs, or Code/400 or Eclipse are responsible for the recent (past 5 years) performance of iSeries software houses. It seems clearer to me that many of us sat on our laurels while the PC world was hungry and went after our market space. If few RPG applications are written today, it's because the current iSeries market is already saturated with mature products, and is too small to support more software houses. I don't blame RPG or the development environment for that. Interesting thread! --buck

[rdean400@yahoo.com]

What Does IBM Need to Do with RPG?

I don't work for ISVs, so we can use whatever we want. I can see, however, the point that changes should be backported so that ISVs can make use of them.

[D.Handy]

What Does IBM Need to Do with RPG?

Robert, I can see, however, the point that changes should be backported so i that ISVs can make use of them. What is the financial justification to IBM for doing a backport? What budget does it come from? It likely would have to come from the existing budget used to support the compiler, meaning we'd see far fewer enhancements to the language. How far back to you port it? For whatever reason, it seems a surprising number of companies still run an OS release which is not even supported by IBM anymore. Why would IBM port changes to it? There are CISC boxes which can't go beyond V3R2. There are early RISC models (mine included) which can't go beyond V5R1. Does that mean I expect IBM to continue to provide me with the language features they add in V5R2+, just because I can't upgrade? If all new features were backported to old releases, what would be the point of a new release? You'd just issue the new functionality in PTF's. But can you imagine the testing required since people may have different combinations of PTF's installed? I think IBM's current policy is very reasonable. Doug

[R.Daugherty]

What Does IBM Need to Do with RPG?

The only reasonable approach is going by the backwards compatibility of the OS, which as far as I know is what is being done. If a company doesn't want to update their AS/400 hardware and OS/400 releases, then why would we think they want to buy newer app releases? I think it's silly for both IBM and software vendors to not sell older software with limited warranty. It's just a matter of cutting a tape and shipping it. They should consider it a cash cow, but instead are forever fearful that customers won't be locked into their current software plans. So instead they sell nothing. Real smart. rd

[Guest.Visitor]

What Does IBM Need to Do with RPG?

If you were a PC programmer would you expect to make sure your programs ran on Windows 3.11? Even Microsoft gets into the act. The next version of Office, Office 11, will NOT run on anything less than Win 2K or Windows XP. It's simply too expensive, and often impossible with certain features, to make a program usable on back versions of the OS. chuck Opinions expressed are not necessarily those of my employer. "Robert Dean" wrote in message news:6ae435c7.45@WebX.WawyahGHajS... | I don't work for ISVs, so we can use whatever we want. I can see, however, the point that changes should be backported so that ISVs can make use of them.

[Guest.Visitor]

What Does IBM Need to Do with RPG?

While I agree that the radical changes leave gaps between versions of RPG, I appreciate all of the new enhancements to RPG. The gaps are a necessary side affect (read necessary evil) of implementation of newer technology. As a developer, there is nothing more frustrating to me than not having the right op-code to do that special something and having to uglify my program with a bunch of long-winded code. For example, how ugly is it to execute a CL command in RPGIII style? The whole call syntax is rediculous! Yes, if you're used to it then it is a no-brainer to waste hours of you development time trying to find the end of a controlled structure block. This is (and would have continued to be) unavoidable when you have such a limited set of op-codes (read capabilities). So why not avoid the no-brainers and use your brain to come up with more elegant solutions. It's always argued that newer syntax read more complicated but this is always the argument of developers who don't want to learn new things. In this line of business that attitude is cancer. You have to learn new things and adapt to change. That is the fundamentals of science. I relate this to medical science. You wouldn't want to wait for the cure to cancer would you just because some other group of doctors haven't had time to understand it? No, you would want the medicine yesterday especially if you or your loved one was afflicated. Well in this business we are the doctors and our customers are the patients. The customer wants these solutions yesterday. Using legacy technology, however releveant you feel it is, only boggs down and adds to development time. Let's face it, we're not stuffing envelopes here, we're building enterprise systems. There is no one solution that is good forever. There is no one solution that suffices even for the short term. Your code style should change more frequently than your clothes and if not then something is wrong. Clifton

[Guest.Visitor]

What Does IBM Need to Do with RPG?

3 examples-solution: . Jacada . http://www.gersoft.com/geras2.html . more web services by integration (BEA, Borland, Sistinet, etc) the benefits: . crash to old philosofy, today is necessary integration but also vanguard . crash to old biz, IBM migrate to opensource you are analize & discuss me, warning i'm expert llauses@yahoo.com

[Guest.Visitor]

What Does IBM Need to Do with RPG?

At speaking broken english??

[Guest.Visitor]

What Does IBM Need to Do with RPG?

** This thread discusses the article: What Does IBM Need to Do with RPG? **
** This thread discusses the Content article: What Does IBM Need to Do with RPG? **
0

[David Abramowitz]

What Does IBM Need to Do with RPG?

** This thread discusses the article: What Does IBM Need to Do with RPG? **
Robert Cozzi hits the nail on the head with his latest column. Many of the "newest" features are nothing more than a reinvention of the wheel. RPG now provides at least a dozen different ways of accomplishing the same thing. Other languages can be written in different styles, but RPG actually has redundant verbage for the same functionality. I believe that much of the impetus for the current flavor of RPG is due to turnover in Rochester, and Toronto. Many of the compiler developers who were familiar with the historic customer base are no longer there. Those now in charge are JAVA, C++, and Visual Basic enthusiasts who have spent a great deal of time and effort making RPG look a heck of a lot more like JAVA, C++, and Visual Basic. When I converted three shops to RPG IV, from RPG III, I had to provide some justification. I was able to do this by pointing out the new date data type features, available for use with RPG IV. No other feature generated as much interest among the powers that be. Having a programming language do something new, is far different from having a programming language do the same thing in a different way. Robert Cozzi is correct when he points out that code written using new features at one shop may be unusable, or undecipherable at another. Give me something substantial that I can use in day to day business applications, and I will use it. Dave