December Article by Ted Holt: The Death of OPNQRYF

[R.Daugherty]

December Article by Ted Holt: The Death of OPNQRYF

Russell wrote: "But you've all read it in other threads here and at the other site. Yes, IBM need to embrace the new "words" like Java and Web-Enablement, but the iron is still the best applications box around, and RPG the best language on that iron for applications development. They need to stop selling only the "words"." At the risk of sounding like an AOL'er, amen to you and Ted Holt.... Ralph

[T.Holt]

December Article by Ted Holt: The Death of OPNQRYF

Ted, YOU wrote OPNQRYF Magic?!?!? Yes, Susan, I did. I'm glad you found it helpful. It's a good tool, & I wish IBM weren't abandoning it.

[frankgw@adelphia.net]

December Article by Ted Holt: The Death of OPNQRYF

Ted - Thanks for writing the article. It appears to be a final wakeup call for not just the death of OPNQRYF but the even broader death of the native AS/400 interface. Twice in the past with clients I did recommend the purchase of your book "OPNQRYF Magic". Both times it was purchased and then frequently used. As others have already stated, it is an excellent book. And now for what really bothers me about your article - It's not that you won't be able to sell "OPNQRYF Magic". It's that you or others will have to write new books to help many of us escape from not only our dependence on OPNQRYF, but also our overall dependence on other AS/400 native interfaces. Many of us have been hooked on the use of DDS. What are you really trying to tell us in the article. You say you believe the move to SQL is a good one. Do we have any other reasonable choices? I am currently the I.S. Manager of a small shop. We have one programmer and just hired a programmer trainee (no AS/400 experience). Should we get the trainee involved with DDS or just aim him in the direction of SQL? Hmmm - first we'd have to purchase SQL. You mention that you hear IBM saying "Throw away your RPG & OPNQRYF. Use Java and SQL instead". Certainly the infamous hamburger ad suggested throwing away RPG and jumping on the Java bandwagon. However, recently IBM seems to be saying keep using RPG for traditional business applications, but use Java and new tools for your Internet interface. Of course this is not easy to do in a small, mostly custom written RPG shop with limited resources. Can anyone point me in the direction of any good articles, books or other training materials that would lead me away from my DDS dependence? Maybe we'll just have to wait for Ted to write another book. Ted, if you decide to write, do so quickly. Whatever you say may well be outdated faster than "OPNQRYF Magic"! Ted, in your article, you also state "I believe that iSeries shops that are not using SQL to build applications should rethink their development methodology". Are you planning to write more about this? Oh well, I think it's time for a nap. I'm on vacation today.

[B.Myrick]

December Article by Ted Holt: The Death of OPNQRYF

Frank, You wrote to Ted Holt about IBM and their direction towards JAVA and SQL. I am in favor of using both of these products. However, I do not use them in production code. Although I like the tenacity of SQL, when it is embedded in RPG I find it to be quite slow and cumbersome. The fact that it is readable does nothing for me as the folks I work with can read RPG quite well. The fact that I can't port an embedded SQL RPG program makes it utterly useless when transitioning platforms. As for JAVA: I do a little bit in java now and then. I'm no expert so I am sure that if I did things differently I would find more use. Gotta find some time to take a class at the local community college. Besides that however, we will not get a way from RPG (if we use it that is) as long as IBM has the compiler and operating system so closely tied. There is no substitute for opening files, reading/writing records or accessing by key fields than RPG and COBOL on the /400. The machine was designed around these languages and the johnny come lately C++, JAVA and so on are having to play catch up. IMHO: The inherent problem with complimenting these languages within the compiler and operating system is that we would lose the portability to other platforms such as UNIX, LINUX, NT, WINDOWS whatever and so on. I believe IBM wants to maintain the "native to all platforms" of JAVA and C++. This means no special op-codes, no special device/record access, etc. RPG is not dying and JAVA remains an excellent language. It is now and will remain (in my limited version of the future) a matter of matching the right tool to the right application. My 3.4 cents. (That's 2 cents rounded for inflation) -bret

[T.Holt]

December Article by Ted Holt: The Death of OPNQRYF

Frank, Thanks for your comments. I have received more feedback from that article than anything else I've ever written, I think. It appears to be a final wakeup call for not just the death of OPNQRYF but the even broader death of the native AS/400 interface. That is correct. It is the entire native interface that IBM is abandoning, not just OPNQRYF. you or others will have to write new books to help many of us escape from not only our dependence on OPNQRYF, but also our overall dependence on other AS/400 native interfaces. Midrange Computing has an SQL book coming out soon. I didn't write it. The guy who wrote it has been using SQL against the AS/400 and other servers for years. He likes the AS/400 over anything else by far. You say you believe the move to SQL is a good one. Do we have any other reasonable choices? I think it's a good move for IBM because it reduces their development efforts. When they develop something like OPNQRYF, they develop for only one machine. (I'm calling the AS/400 & the iSeries the same machine, since they are.) When they develop for SQL, they develop for all their platforms. IBM stuck the word "universal" in the name of the AS/400 DBMS, but it's not the same DBMS as the DB2 UDB that runs on their other platforms. AFAIK, it doesn't share any source code with those other UDB's. If IBM can get rid of the native interface, then they can get rid of DB2/400. Then they'll have only one DBMS product to maintain, for various platforms. I think it's a good move for people like me and you. I'm 43. I've got to work another 25 years before I can retire, assuming I ever can retire. I think we have a better chance of survival if we can work on any platform, not just one. I know too many programmers who only know RPG. Other choices? I don't think so. If you decided to go to work for a UNIX, or NT, or whatever shop today, you'd more than likely have to use SQL to communicate with a relational database (MS SQL Server, DB2 UDB, Oracle, etc.) recently IBM seems to be saying keep using RPG for traditional business applications, but use Java and new tools for your Internet interface. Of course this is not easy to do in a small, mostly custom written RPG shop with limited resources. Keep in mind that "IBM" is a lot of people. From what I can tell, there are people in IBM who wish the AS/400 had already been discontinued, and that OPNQRYF, RPG, etc. were as obsolete as punched cards. Those are the ones who say stuff like, "Use Java for everything." Then there are the more realistic ones who say, "Java is an ideal, but this isn't an ideal world we're living in. Use whatever you have to to get the job done." Ted, in your article, you also state "I believe that iSeries shops that are not using SQL to build applications should rethink their development methodology". Are you planning to write more about this? I am planning to run more articles about SQL in the Application Development section of MC. I know of people who are using SQL in their shops. Some of them only use SQL for I/O; that is, they no longer use READ/WRITE/etc. They are doing OK. Please understand that I don't like to see the native interface go away. IMO, it is one of the strengths of the AS/400 and one of the reasons the AS/400 has been so easy to develop for. Don't forget that RPG-based work is 99.99% of my resume. But when I write these one-pagers (about the only thing I have time to write any more), I try to write what I think you need to know, not about the world the way I wish it were. If I had encouraged you to cling to that native interface, I wouldn't have been doing you a service. The truth is that IBM is not putting development dollars into the native interface, so that's what I wrote.

[David Abramowitz]

December Article by Ted Holt: The Death of OPNQRYF

Frank Whittemore wrote: Certainly the infamous hamburger ad suggested throwing away RPG and jumping on the Java bandwagon. It should be remembered that IBM was also holding (sales) seminars for Domino, and other products, telling their customers, that they could not compete in the business world, unless they put their products on the web. Words like "You have to do this", and other scare tactics were used. Nobody mentioned the quagmire that would come. The expenses never ended, and ROI never happened. When it comes to web sites, ROI is only king,, in France! IBM must have checked the stock prices of dot-com companies, because they are no longer doing this. Dave

[David Abramowitz]

December Article by Ted Holt: The Death of OPNQRYF

Ted Holt wrote: Please understand that I don't like to see the native interface go away. IMO, it is one of the strengths of the AS/400 and one of the reasons the AS/400 has been so easy to develop for. This is a very important point. Without 5250, do we have an AS/400 left at all? Dave

[R.Daugherty]

December Article by Ted Holt: The Death of OPNQRYF

Ted wrote: "The truth is that IBM is not putting development dollars into the native interface, so that's what I wrote." We don't need them to put more development dollars in DB2/400. It was working fine. They need to be able to run other databases as applications on the AS/400, not only their Universal DB2 version but Oracle and the others as well. They need to leave DB2/400, its embedded relationship with OS/400, and record level access alone. It's paid for, just sell it. Ralph ralph@ee.net

[T.Holt]

December Article by Ted Holt: The Death of OPNQRYF

Ralph said: They need to leave DB2/400, its embedded relationship with OS/400, and record level access alone. It's paid for, just sell it. All the old stuff will still be there, Ralph. You'll still be able to create physical & logical files with DDS, run OPNQRYF, write RPG programs with F specs, etc. IBM is saying they're going to continue to enhance DB2/400 to bring it up to par with DB2 UDB, but the native interface won't include these enhancements. What the enhancements are, I don't know. Maybe I'll email the guy I know in database development & see what he can tell me. But I expect we'll see support for other types of joins & update thru a join. Of course, if you don't need the new stuff, you don't have to use it. I know people who still write and maintain S/36 code. They've never even made the switch to RPG III, externally described disk files, and CL.

[R.Daugherty]

December Article by Ted Holt: The Death of OPNQRYF

Thanks for the info, Ted. It sounded like they were abandoning AS/400 technologies because it was too expensive to maintain parallel products. I'm glad to hear that's not the case. Cheers, Ralph ralph@ee.net

[frankgw@adelphia.net]

December Article by Ted Holt: The Death of OPNQRYF

Using SQL for your database objects is in synch with IBM's long-term plans for DB2 UDB for AS/400. SQL is the strategic interface for DB2 UDB for AS/400, and therefore SQL has higher priority in Rochester than DDS. DDS usage won't be eliminated completely -- you'll still need DDS for creating display and printer files because no SQL equivalent exists for those file types. The most logical way to begin migrating to SQL file definition is to create your SQL database script in a source file member and then point the RUNSQLSTM (Run SQL Statement) CL command at that file member. RUNSQLSTM will execute the SQL and create your database objects. In the future, Operations Navigator will give you a graphical interface for creating and running SQL database scripts. -------------------------------------------------------- The above text has been copied from the following IBM site. For more information click here http://www.iseries.ibm.com/developer/bi/sql.html

[Guest.Visitor]

December Article by Ted Holt: The Death of OPNQRYF

I have a question about SQL. I've had clients that have files with over 7 million records. ::laughing:: Seriously, that's no lie. The nature of their business requires they keep 5 years worth of data available online. What's the performance hit using SQL on interactive maintenace programs? Thanks Teresa ;>

[frankgw@adelphia.net]

December Article by Ted Holt: The Death of OPNQRYF

What is Operations Navigator Database? Operations Navigator provides an easy to use graphical interface for many common AS/400 database operations, such as creating tables and views. Most database operations that you can access using Operations Navigator are based on SQL functions, but you don't have to be familiar with SQL to use them. Using Operations Navigator, you can quickly and easily design and manage a database using only a mouse. Here are just a few highlights: When creating a new table, you can browse existing tables to find and use your favorite column definitions. You can create a joined view using drag and drop. You can even directly edit your table data. And, in case you know and love SQL, you can use Operations Navigator to create, edit, run, and troubleshoot scripts for SQL statements. -------------------------------------------------------- The above text has been copied from the following IBM site. For more information click here http://www.iseries.ibm.com/oper_nav/OpNavInfoCenter.htm

[Guest.Visitor]

December Article by Ted Holt: The Death of OPNQRYF

Teresa, The performance hit is the same as using OPNQRYF since SQL and OPNQRYF use the same database engine. For such large files, you need to be certain that the system uses existing access paths (LF or PF) and not need to create an access path on demand, interactively. Chris

[nycsusan@hotmail.com]

December Article by Ted Holt: The Death of OPNQRYF

Teresa wrote: "I've had clients that have files with over 7 million records. ::laughing:: Seriously, that's no lie. The nature of their business requires they keep 5 years worth of data available online." Nothing funny about it. I work in a telephone billing application and we process 6 - 10 million records PER DAY, every day. It makes everything more complicated when there are that many records.