System iNetwork

Is iSeries (system i) finally catching up? Oracle's RDBMS and built-in PL/SQL language had these capabilities already long time ago. That is to be more specific, in the previous century.

I think the iSeries did have this capability shortly before the turn of the century (just barely). I believe the SQL function (including the external capability) was introduced with V4R4 in 1998.

But yes, as in most things pertaining to SQL, Oracle was ahead of IBM.

"Is iSeries (system i) finally catching up? Oracle's RDBMS and built-in PL/SQL language had these capabilities already long time ago. That is to be more specific, in the previous century.

Posted by: Ugeerts at October 19, 2006 02:01 PM"

And how does this help me with my RPG functions that I want to expose to SQL. Does oracle now support RPG?

Off topic -
I spent the day reading much of this blog. (By the way, blog is just another word for message board, right?) I primarily work in legacy RPG. Much of it over flat files using I-specs and indicators turning on or off based on the first character read in a record. It appears that any modernization effort needs to start with a fully normalized database. Is this correct? I'm basing this opinion on the I/O debate back in the spring (which was fantastic. It is a wonderful forum to have the best minds in the field go at it). I am also noticing there are not many comments on the UI articles. Is this primarily because everyone is still using green screens and doesn't understand the browser/RPG interface? Or no one has an opinion? AJAX is best and there is no debate?

Thank you

Patrick wrote: AJAX is best and there is no debate?

I saw more positive statements on Flash that on AJAX. I think Java makes sense for a cross platform rich client for business apps. It doesn't matter though unless there's a common infrastructure to write to like we have with DDS.

I've only seen green screens internally wherever I've been, web pages for external, and internal has always chosen green screen over web page when given a choice. That was for web pages that were just renditions of green screens.

Of course, the customer is going to choose the richest interface, where techology and programming define the richness. A souped up 5250 could be richer than plain jane HTML. HTML with AJAX could be richer than plain jane Flash. (Is there such a thing? :)

Flat files are the entire record in one text field. You have separate fields for data in your record formats, don't you?

But whatever you have, I'm sure the converter will generate RPG IV out of it and you could output web pages. Why I don't know, but you could.

Patrick wrote: (By the way, blog is just another word for message board, right?)

blog is short for web log, and is normally more one sided with essentially an invitation to talk back. However, this blog is run just like a message board forum.

rd

I'm still off topic here. If there is another blog that I should be posting to, just let me know.

I guess I picked AJAX because it is getting most of the press lately. My point is that no one is arguing the UI. From the sidelines it appears there are two schools. Those that know how to produce the browser UI, but do not think their way is really much better than the next guys' way. Everyone in this school of thought is respecting the other guy for doing the UI differently or don't know even to argue the difference. The other school is silent because they don't know how to produce the browser UI or how to manage it. I think the silent school is waiting for a strong standard to follow. I am part of the silent school. As an independent contractor I get questions on direction all the time. I don't feel comfortable telling anyone a primary choice. We end up talking about the possible options.

Flat files, right, one text field broken down in I specs. Then there are those flat files that have a few key fields defined along with other text fields that can be parsed into 5 or 6 fields using I specs. Back to my question... Does any modernization effort need to start with a normalized db or normalizing the db? (before breaking code into modules or considering a new UI) I'm asking the ones that have experience here. I guess with a layered approach it won't matter. The better question might be should modernization start with separating the db from the bl?

Your comments are relevant and welcome, Patrick, and you raise very important issues facing the System i community.

About UI choices: This is complicated by the wealth of options. On the client side, simple browser solutions are not always adequate, but in many cases are quite sufficient. Where a richer experience is needed, we have choices like AJAX or FLEX or Lazlo or Google Toolkit (which simplies the use of AJAX), or outright client/server. The dust has certainly not settled yet.

And there is also the issue of server-side choices. Some prefer to use Java-based frameworks like Spring, which could then utilize RPG components for business logic; others are excited about bringing AJAX to RPG. Robert Cozzi is excited about this latter option.

The database question is like opening Pandora's box. A first-level answer is that yes, database modernization should be an aspect of application modernization. But whether it has to precede or can accompany business logic programming modernization will depend on the circumstances. Also, the degree of normalization required will vary according to how extensively SQL will be used and what the architectural vision is.

As we all know, many companies moved System/36 file systems onto DB2 when they went to the AS/400, and many System i databases even today are really System/36 file systems hosted on the DB2 relational database. As applications evolve and mature and are influenced by more recent ways of designing applications and RDBMS systems, database modernization will become more pressing for many of our older systems.

Beginning to segregate data access logic and components from business logic components is, in my mind, an excellent way to begin. After separating IO from BL it will be easier to alter the database design because most of the impact will be confined to the IO layer.

BTW, IBM-er Dan Cruikshank has begun a series of articles on database modernization for SystemiNews. I know he has articles in the August and September issues, and I look forward to more in the future.

>Does any modernization effort need to
>start with a normalized db or
>normalizing the db?

DB normalization should be a consideration, at least. I worked for a vendor which developed software for credit unions, and we were replacing products from a variety of other vendors at a rate of about 20-24 per year. It seems that the only consistent thing about the products we replaced was the poor normalization of the other databases. The lack of normalization leads to seemingly illogical code, which is harder to adapt and maintain.

I'm not sure what you mean by "flat" files, Patrick. I still use DDS to create most physical files, but tend to target third-normal form in my database designs. There's an innovative web application framework named Ruby on Rails which streamlines the development of Web interfaces but some of its features which are designed to improve programming productivity, break down if the database isn't normalized. The same is probably true of a lot of tools.

Nathan.

Max,
Thanks for the lead on the articles. I haven't had a chance to read the mag lately.

The next thing on my mind is naming conventions. Ten years ago when RPG IV hit the scene I worked at a shop where our naming conventions allowed us to consolidate QDDSSrc, QRPGSrc and QCLSrc to QSrc because we didn't want to add QRPGLESRC. This way we didn't have to bounce around in PDM so much. With monolithic programming a few programs and screens can be grouped together. With modularization (is that a word) it appears there is going to be a lot of bouncing around. What naming conventions are being predominate?

I meant to add to that last post that we converted all RPG III programs to RPG IV after searching for potential 'target too small errors.' The last question is 'What naming conventions are predominate?'

Nate,

Flat files. One field in a physical file that is broken down by I specs. The file will contain multiple record formats usually designated by the first character in each row. We also have physical files with a few fields defined while other fields are named F00001, F00002, etc. and again they are broken down by I specs to be two to five fields each in the RPG program.

At the recent local iSeries user group meeting that I attended I mentioned to a developer sitting next to me that we had jobs running more than 50 times faster by converting the native IO in RPG programs to SQL and by following Daniel Cruikshank's recommendations. The gentleman replied that at his shop, they had similar experience by converting programs to use SQL.

Re flat files: flat files created with CRTPF xx RCDLEN(xxx) work with SQL if you write a UDF to pull out imbedded packed data. They just do not work well--you don't get to access defined columns.

A first normal table has unique keys on all records. The majority of ISeries shops have substantial number of tables that do not meet this simple requirement, so we are using SQL on unnormalized data.