System iNetwork

Chris,

I'm glad to see someone stepping up to move ahead with the work started in Japan. It will be interesting to see what kind of support Martin gathers.

It is great to see more grassroots effort to promote System i.


Undoubtedly, System i has a great group of loyal supporters and devoted fans.

I dont see how these initiatives can work if IBM does not invest in the platform. For user and vendor groups to help the platform they have to first see to it that the OS gets improved. Either open source IBM i or sell it.

An example of where the OS needs improvement is long name support and integration of SQL. You cant use SQL from CL. Result sets are not supported in RPG. Object names are limited to 10 characters. SQL column names make for cumbersome coding in RPG.

A list of needed improvements could go on for pages. Service programs, activation groups, binding source, command definitions, spooled files - all need a heavy dose of modernization. Then of course there is the glaring absence of IBM's alternative to the .NET framework.

Not that I'm responding to Richter, but we have to counter his FUD everytime.

IBM i is state of the art. No, we don't run .NET, that's Windows. We are not Windows. We don't want Windows servers. .NET is a me-too Windows thing to have a Microsoft answer to Java and ILE. No, we are not interested in Microsoft me-too. We have much better, and we had it first.

CL is a command language. What is this guy doing griping about SQL not being in a command language? You can call RPG or REXX from CL to run your SQL, or i5 has a nice SQL object in QMQRY to call from CL.

I just wrote an open source example file maintenance subfile program (WEBVISITOR) using ILE architecture such as the bnddir he gripes about.

http://code.google.com/p/rdwrites/

It's in a savf archive, I'll add a text file download of the source tonight.

Excellent, excellent architecture we have in the IBM i ILE programming architecture. I am quite pleased with it and more enhancements are on the way i 6.1 I haven't seen yet.

Activation groups are quite powerful. This guy is just reading off his laundry list of perpetual complaints. Is there any way we can make it clear that we're not interested in Windows, the iseries is a real server and the best there is?

Just wondering.

rd

Responding to Mr. Richter: It is obvious you have not really been in programming long, nor have you actaully used any of the tools on the i, or most probably the .NET garbage for long. Your problem is most likely that you got a programming job after going to school for computer science, thought you were going to retire at age 30. You havent actually been in this business long enough to actually know the difference between BEST and adequate. Windows, is adequate, but only if you are not talking about transaction volume capability, security, and reliability. I have NEVER, EVER seen weekly security patches for System i on an ongoing basis. NEVER, EVER seen a weekly or periodic re-boot schedule required for system i to "clean things up", and NEVER ever seen a system i that could not handle the load it was designed for. On top of that, all the things that you griped about are there on the i in some form or other. In most cases, the implementation is more complete, reliable and scalable on the i that you can EVER get in windows.. Been there...done that for over 30 years. From UNIX to APL to I5/OS to snobol to cobol to C sharp C++ to what have you , I have been there and done that. The i has it! Most businesses that actually plan to have a future, plan for reliability, security and scalabilty. Thus, most of the fortune 500 and most global companies use anything other than windows for mission critical applications.

Regardless of the "truth" the fact is that outside of hardcore of loyal supporters the IBM i has an image problem. There are many organizations whose data processing needs are sufficiently complex and demanding that WinTel is simply not the best combination. But such organizations can't justify the cost (or simply don't have the money) for big TP environments like a mainframe. The IBM midrange platform has always been a good fit-for-purpose in the classic mid-market space and its value proposition is as relevant today as it has ever been. What we are facing is a marketing challenge, of some considerable proportions, and that is where the iManifest coalition hopes to make a difference. The hardware architecture of an IBM i server is state-of-the-art so the chances are that any 'legacy' jibes mean that you have a software problem, not a hardware problem (and, yes, I acknowledge a skills availability issue as well). And there isn't much in the way of useful business-related software that you can't run on an IBM i, so we just need to bust a few myths and misdirections - easy to say, huh?

Martin

I have been using the tools and languages on the i for about three years now. Prior to that I completed a computing degree encompassing all the latest techniques including OOAD, Java, J2EE, .net, PHP etc etc.

The i (or whatever it's called now) is a capable little box but I wouldn't call it state of the art! Some underlying aspects of the OS are very good indeed and much superior to UNIX or Windows. However, the version of DB2 is a stripped down version that doesn't include all of the functionality you would get with Oracle, SQL server or even full blown DB2. In most cases it is adequate but it has limited me on about 2-3 occasions, or about once a year.

Also, the main languages on the platform really let it down. RPG is easily the worst language I have used for writing structured, maintainable code. My main gripes are these:

1. The language influences the database design. Files end up being created in a way that is convenient for RLA. Then a few years down the road you need to do something a bit more advanced where RLA comes unstuck so you switch to SQL but by this time it's too late and the database performs badly. I've seen fields and even whole tables get reused just to save a re-compile. There's a reason the rest of the industry use SQL!
2. All fields in RPG have to be a fixed size. Including array dimensions! This is a terrible restriction compared to other languages. It forces you to guess how your program might be used and then either write messy defensive code or just accept that one day it will fall over.
3. There aren't that many free tools available with RPG whereas there are an infinite number for Java etc. This means any time you have to do something other than the usual database operations Java has to be called from RPG. This always winds up being far messier than if Java had just been used from the outset.
4. Source control is rubbish on the i. On other platforms developers usually code and test on their local machine and then upload the changes using CVS or SVN. RPG only compiles and runs on the i so it makes this model impossible. Consequently you end up fighting over the same objects and pulling the rug out from other people.
5. I once heard someone say how great it is on the i that you can set live changes separately because they're all in different objects. In practice hundreds of different objects becomes cumbersome to set live and setting live just one is fraught with danger because of signature co-dependencies etc. It's not all it's cracked up to be!

That's just my opinion of course but all of the other graduates I have met working on the i have said the same. I think the platform will eventually die out with the current generation.

To achieve the maximum impact and effectiveness, it would be good to align and coordinate the marketing, advertising, and promotion effort of the IBM i community with the goals and strategies of IBM. Uncoordinated, incongruent, and disparate effort may not be useful and may even confuse the IT industry.


Ultimately, IBM i belongs to IBM.

"...What we are facing is a marketing challenge, of some considerable proportions, and that is where the iManifest coalition hopes to make a difference. ..."

This POV about the need for better marketing does not explain why so many shops leave the platform. If the need for better marketing implies that the public only needs to be told how good the i is and they will buy the system, what is the reason that companies that know the system so well, leave it?

Being someone who has held positions of management both at software companies and in-house shops, I just have to reply to Ben's post. It is quite evident that his education did not equip him for a transaction-processing world. I thought it would be best to simply respond to his points...

1. Language should in no way influence database design. The database should be based on business needs, dependencies, and all of the *typical database design* stuff (don't they teach concepts like normalization any more?). In those cases where an RDBM model is not suited (i.e. in some of the new web 2.0 models), then perhaps the database design could be adjusted based upon the language. Reusing columns or even entire tables is just bad application management, and is not isolated to the System i architecture. Further, the origins of RPG started in batch processing (I know - that is how I was taught to use it! ^-^). To say that RLA is a limiting factor is a bit confusing to me. We have the ability to run SQL (within RPG) should we need some kind of *mass change* to a table, but rarely do we set a column to be the same value in all rows.


2. RPG does not require fixed-length fields, nor does it require them to be all uppercase. DDS-defined tables limit field names to 10 characters, but RPG is not restricted to using DDS-defined tables and/or views.


3. I am not quite sure what types of *free tools* Ben is looking for here. If he is referring to code samples, then he just hasn't looked very hard. Should Ben be referring to service programs and/or API's to provide convenient methods and/or functions, then again I submit he hasn't done his research (then again, I don't see RPG needing as many pre-built objects as would a language such as Java may).


4. Source control is as lax or advanced as the shop wants to make it. In addition to third-party products, IBM used to have its own change management system. I am not sure if it is still supported, and I haven't looked into what is available in the new version of WDSC / Rational in V6R1 (we have our own and it works just fine). If people are working on the same program at the same time then you have bigger issues than just change management.


5. Signature co-dependencies? In RPG? I don't know about you Ben, but we rarely change the parameters on existing programs (which to me would be the only thing that you could mean by signature co-dependencies). When we do, then usually the programs calling it are also affected and would be included in the deployment. Further, I will take my object-separated applications over a single executable and its related DLL's any day (and I am responsible for both kinds). Could this be a result of Ben's dealing with a limited number of objects in classroom assignments versus the real world of hundreds or thousands of objects being required to meet the needs of business?

While I certainly appreciated some of the functionality provided in Microsoft's VB / .NET environments (like a pop-up for exposing methods / attributes of a referenced object), the reliability, ease of development, and ease of maintenance on the System i far outweigh anything I have seen in the x86 world.

in reply to Tim and Ralph I can only give more examples of my experience writing apps for IBM i. When my SQL code runs within an RPG program or SQL procedure I get minimal info written to the joblog. Also, when my sql code fails the job continues to run because an exception message was not sent and I did not check for the return code.( there are only a few thousand to check for. I should know better! ) IBM i is a great platform for problem determination. I cant say the same for SQL on the i. Debugging sql procedures is cumbersome. When an sql procedure bombs I cant see in the joblog what statement failed. The LOGCLPGM(*YES) feature works great for problem determination. CHGJOB LOGSQLSTMT(*YES) would be awesome.

My recent experiences working with VIOS on a JS12 blade in the BC-S is convincing me that IBM does not know how to be a software company. Every component of the system, and there are many, works differently and is cumbersome to use. It took 3 days and many support calls to get the TS2240 tape drive to work on the system.

The only way our platform has a future is if "IBM" is taken out of IBM i.

Steve, you can treat your SQL errors much like your RLA (record level access) errors where %error is used. You just need to do some front end work.

-- Write service program procedures using SQL's "Get Diagnostics" to get virtually any information you could want.

-- Write information to a log file and/or

-- Write another service program procedure using API QMHSNDPM. QMHSNDPM acts like SndPgmMsg so that info ends up in the job log.

-- Use SqlState to diagnose problems. If sqlState starts with '02' and the entire sqlState <> '02000', guess what? You had a problem. You do not need to check each and every sqlState.



Our shop wrote a procedure called sqlError(context) that does most of the monitoring work for us. Depending on the context, it can: log the error; send messages; send break messages; and/or stop the program and wait for a response (which also pages people).



Additionally, you can run SQL from CL programs. There was a "MySql" command making its rounds a few years ago. We downloaded it, enhanced it --yep, using sqlError() -- and it works great for us. However Scott Klement recently wrote a much more cool QShell command called SQLQSH. See this article:
http://systeminetwork.com/article/improved-db2-command-qshell



I guess my point is: a liitle imagination, a little elbow grease, and a good attitude eliminates many problems.



Happy programming :)

"... I guess my point is: a liitle imagination, a little elbow grease, and a good attitude eliminates many problems. ..."

Craig,

I appreciate you showing some workarounds for the problems I described. I guess that is what programmers do on all platforms, code workarounds to get the system to do what the end user wants. In regard to using SQL from CL, yes with not too much workaround code you can run SQL from CL. However, getting output parameter values back from an sql procedure is an order of magnitude harder. And even harder still, using RPG or CL to read the rows of a result set returned by a stored procedure. This is far from the integrated simplicity of CL which made the AS400 king back in 1990.

Look at the just announced IBM quarterly financial report. Sales of servers and operating systems is down for the 3rd consecutive quarter. IBM consulting services, esp services to government, health and education institutions is up. IBM i is not in the new IBM's plans. Better for all that they spin us off.

To uncle Dave

1. "don't they teach concepts like normalization any more?" This is precisely what they teach! I've just not seen it used much on the i. I have on the other hand seen RLA techniques such as a chain influence table design. I have also seen RLA problems such as programs needing re-compiles influence table design. I have also seen highly convoluted and consequently hard to maintain code using RLA where the same could have been achieved with a few lines of SQL.
2. Urmmm... yes it does! Ok, so you can have an array sized at runtime but you have to monkey around using pointers and assigning the memory yourself. Also, a character field or data structure can only be up to 64k which again means you have to monkey around with pointers. Do'able but the code becomes unnecessarily complicated and harder to maintain. Also, if you change a field size in the database you then have a nightmare going through and finding all the places that field is used including work fields.
3. I wasn't referring to code samples but there certainly is a lack for the i. The RPG community is very small so there is significantly less documentation and examples on the web than for the more popular languages. What I was referring to are the myriad open source utilities that exist in the Java world. If you want to write web pages using RPG you have CGIDEV2 which is very crude and really only half finished. Java has the Java EE framework which is the market leader. That's just the start though, there are open source tools for virtually anything you could want e.g. security, logging, relational database mapping, dependency injection, aspects, graphing, image handling, MS office documents, PDF's etc etc...
4. Your point is absolutely true. However, change control management has moved on and left the i behind a bit. In the 21st century there are all kinds of tools such as automated build tools and documenters and unit testing that can become part of the build with continuous integration etc. I have yet to see anything as advanced on the i.
5. I have dealt with some larger applications both using Java and .net. To be fair it can be a right pain trying to sort out dll or jar dependencies. My main objection is that AS400 bods see object deployment as the bees knees when in reality it's no better or worse and suffers just as many problems. This is largely down to process though.

In response to Ben's post a few posts earlier.

Ben comes from another working IT background and is only in an iseries enviroment for the last 3 years.
I think the iseries community should be gratefull for his testimony, since it is rare to find someone with such a curriculum.

0) the main languages on the platform really let it down. RPG is easily the worst language I have used for writing structured, maintainable code.

I guess you arrived in an oldfashioned iseries shop where most of your colleguaes have a track record of 15 to 25 years. Naturally, you have to follow that shop's standards. If this is the case, I can understand your gripes. You could try to push the usage of SQL (as a replacememnt for RLA), the usage of service programs and foremost, replace the green screen PDM with the RDi 7.5 (formerly Wdsc7) graphical development environment. You also want to code in free format rpgle and be not afraid to call java methods from your source. But even then, I consider other languages like fi. Oracle PL/SQL more advanced and more productive. The PL/SQL language scores higher on readability, effectiveness, uniformity and productivity then iseries embedded sql in rpg or cobol. As an example:

rpgle free:
if %subst(field1: 10 : 1) = 'A' or field2 = 'B' or field2 = 'C';
exec sql select field3 into :field5 from table1
where field3 = substring(:field1, 10, 1) = 'X' ;

pl/sql:
if substring(field1, 10, 1) = 'A' or field2 in ('B', 'C') then;
select field3 into field5 from table1
where field3 = substring(field1, 10, 1) = 'X' ;

This example shows pl/sql has applied the sql syntax to the pl (procedural language) part of the language, so there is no need for multiple versions of the same function like an sql variant and a rpgle variant with noisy '%' and ':' characters.

1.The language influences the database design.

Yes I agree. In theory it shouldn't, but in practice it does. Due to the inflexibility in DB design and RLA-only support in the early RPG years,
I've seen countless flat files, files with "reserve" fields named A001, A002..., files with obsoleted data columns being re-used (like a 6-digit date now containing a unit price). Shops with that kind of messy software are usual prime targets for migration to other platforms.

2.All fields in RPG have to be a fixed size. Including array dimensions!

Not so for the past 10 years. Whether you define a table tru DDS or SQL, you have varchar support at your fingertips.
Most rpg prgrammers aren't even aware of it (and if they do, they don't see a reason to use it). Other RDBMS'ses use mostly varchar columns and occasionaly fixed char. When using binary large objects (blob), you would implicit use varchar. Incidently, seen any AS/400 DB2 database using columns containing a picture, video or audio stream? I've yet to see a table 'employee' which contains next to the traditional name, address, age columns, also a picture column and a video+sound column of his interview with the personal manager. In DB2 technically possible but unthinkable, in other RDBMS (Oracle, MS SQL server) slowy becoming common nowadays. Or think of an product table, were you want to store next to the product information, pictures and technical (pdf) documents. Trow that in a web browser and you have an 'ebay' like interface, plus all sql features at your disposal for searching, selecting and sorting.

3.There aren't that many free tools available with RPG whereas there are an infinite number for Java etc. This means any time you have to do something other than the usual database operations Java has to be called from RPG.

Rpg was always a proprietary language, so the lack of free tools is understandable, but the situation is improving.
You can hide the 'messy' and lengthy definitions to call a java method by storing them in a service program for example. I've wrapped all java functions to create an excel file in a service program, so the interface from the rpg program is simplified.

4.Source control is rubbish on the i.

Use a 3th party (non IBM) change management system like Aldon Turnover for example.
But I think your point is all software platforms should generate a "build" version of an application wereby all components are tagged with that build version.
Whether this should become a de-facto standard I'm not (yet) convinced. The Turnover framework for example is suitable for typical 5250 applications, but as soon a mixed technology comes in like IFS files, CGI or other Web related frames, a better tool is needed.

5.I once heard someone say how great it is on the i that you can set live changes separately because they're all in different objects.

This points probably relates to above. When generating a "build" version, you end up with a relative few number of executables compared to the number of components.

5 continued. ... with danger because of signature co-dependencies etc. It's not all it's cracked up to be!

Yes, service program functions are very sensitive to changes in their signatures, even if their call interface is not changed (for example, when a new function is inserted at the top of the list in the service program). Remedies are to use an export source and force the signatures to a fixed value therein.
On a side note, in Oracle, you could retrieve them using 'select * from where packagestatus = 'invalid'. Consider the power of this statement.

6. I think the 'i' platform will eventually die out with the current generation

I'm afraid this is the case, given the average age of the developer on this platform being around 50, and the inflow (except you, Ben) being neglictible.

But to all 50 year old's out their, what is the best developer job in IT to work in?
Programming Visual Basic surrounded by a bunch of 25 year old colleguaes?
Right, choose the as/400, you start as a junior at the age of 35!

Cheers.

In reply to Steve Richter,

Steve, there are several ways to handle errors in an sql rpgle program, I just offer you mine as an example.

Suppose you have:
exec sql open c1; // say c1 is a cursor declared earlier
My next statement is:
checksql('open c1').

Checksql() is a function that simply does the following:
select;
when sqlcod = 100; //eof
return *on
when sqlcod send escape message 'sqlnnnn occurred, in program xxxx, tag 'open c1'. See joblog etc...' (nnnn = - sqlcod)
endsel;

An improvement is to let the handler do a rcvmsg of the first diagnostic message and put this in the escape message, which makes it more informative.

Other example:
exec sql fetch c1 into :xxxx;
c1_eof = checksql('fetch c1');

Makes it easy to use c1_eof as an end-of-file indicator of cursor c1.
Suppose we had a mapping problem during the fetch, then checksql() sends an escape like 'field abc cannot be mapped to result xyz' occured at statement 'fetch c1'

I saw this saying somewhere a while back...

If you coded in RPGIV/ILE you'd be done by now.

Ben,

At first you statement turned me off but as I thought about it, I agree wholeheartedly--IBM i is not state of the art. State of the art is frequent security patching and workarounds; daily (or more frequent) reboots; mandatory virus protection with updates at least daily--better if they come several times a day; routine upgrades which force you to rewrite and retool your applications; these same upgrades also require retraining of your users because the interface has so radically changed--only to benefit the pockets of those providing the mandatory upgrade; and full time staff positions to administer the: Networking, Security, and Database. IBM i shops deal with none of this.

A few responses on your specific points:

1) Database design and normalization--"I've just not seen it used much on the i." Then you have a very limited scope and experience on IBM i. I've been involved in design meetings discussing proper normalization for 25 years--that's dating back to IBM i's forerunner of the System/38. There was no possibility of an SQL interface back in those days. RLA or native database access has nothing to do with proper database design and implementation. People using SQL can write crap the same is people using native access--I've seen it done. Don't blame the car if the driver points it over the cliff.

2) Array and variable sizing--Try COBOL, it's had the OCCURS DEPENDING ON clause for decades. Even "monkey{ing} around using pointers and assigning the memory yourself" isn't that big a price to pay with procedural logic and it's business programming gains. If your background is computer science rather than business information systems, you probably are more biased to objected oriented constructs. Try changing the size of an array in Java once you've assigned it. Java does have many great functions for sorting, searching, and manipulating arrays. Every language has strengths and weaknesses.

3) Free utilities--I gather you're looking for libraries and functions to accomplish a function. RPG and COBOL have many built-in functions and there are a ton of free utilities available if you take the time to look. With Java, the challenge is probably more as to which one to pick. Either way, it takes some research to make your choice. Without knowing the specific function, it's hard to say. But IBM i can't be blamed for its lack of capability. It's much like the situation under point one. And one of the beauties of the system is you can access any other language to accomplish a function--granted that some are easier to interface with than others.

4) Source control--Dude, you just haven't seen what is available. "If your only tool is a hammer, all your problems will look like nails." Check out some of the fine tooling from the likes of Aldon, MKS, Arcad, et al. Don't blame the system if your shop wants to focus on making the best buggy whips. The market has plenty of solutions to handle the software development life cycle.

5) Deployment and promotion--Again, you just have to have the right tools. There's an abundance available. Our shop has made due with a home-grown system tied with a commercial cross-referencing and documentation package. I don't remember the last time we had a successful promotion using the available tools that caused a level check or signature violation. Modularization is the only way to keep from drowning in over sized programs.

Lastly, "I think the platform will eventually die out with the current generation."--Ahh, did you see any of the press about COBOL passing it's 50th birthday? Not that I think COBOL is the savior of IBM i. But there are some pertinent parallels. During the early years of COBOL someone had a tombstone engraved to the essence of "RIP COBOL" because he didn't believe that COBOL could survive--it was so poorly designed and implemented. Well, today you can't really make a financial transaction without COBOL being involved somewhere. Statistics say the average person deals with 13 COBOL processed transactions per day. Is the COBOL code being used really the most effective way to handle the transaction? Quite possibly not. But the point is a system which is developed over several decades isn't replaced easily. There are too many companies and there is too much investment in systems on IBM i to easily replace them. Especially when it runs on a platform that is so stable and secure. (I love David Gibbs' tag line IBM i on Power - For when you can't afford to be out of business. I said it before in another recent column and I'll say it again, My prediction/opinion: IBM i will long outlive you and me.