Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

RPG and DB2 Will Sizzle at the Summit in Orlando

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • J.Pluta
    replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    Hi Herman! Yup, good old BPCS days. I recognized the name, that's why I wanted to make sure I commented . SQL continues to get better, but it's just common sense that a single record operation, be it READ, WRITE or UPDATE, is going to be faster using a direct access than it is using an SQL statement. With SQL, there is some amount of metadata acecss required, and onlyo after that can it then do the actual I/O, at which point it is finally doing what native I/O does right away. I haven't run my benchmarks for a couple of years, but what i found in general was that SQL started to win out over native I/O as you did more and more operations at once. For example, reading a hundred records at once in SQL is typically faster than reading those same 100 records in native I/O, because you don't have the overhead of going back and forth between the database layer and the high-level language. Anyway, in general there was a point where SQL got faster. With reads, it was typically somewhere around 10 records, while with writes and updatesd it was closer to 100 records. I didn't do any testing on opens and closes; in my experience, though, as long as you have the correct indexes created in SQL the opens are pretty much equivalent. Joe

    Leave a comment:


  • Guest's Avatar
    Guest replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    Do you have benchmarks? Like does it take 2 time longer? Is a open longer in SQL or RPG? Any Ideas on how best to implement resistence? Herman If I am correct, Long time no see since BPCS?

    Leave a comment:


  • Guest's Avatar
    Guest replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    I was confusing memories with something we used to do like below which is done way simpler now with a conditioned DO...ENDDO
    Code

    Leave a comment:


  • J.Pluta
    replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    Right. 99N99 made references to things that you didn't plan to reference but the compiler insisted upon. What Ef might be thinking of is having a big block of code at the beginning all conditioned with N99, the last line of which was "N99 SETON 99". That was the old fashioned *INZSR subroutine. Joe

    Leave a comment:


  • Guest's Avatar
    Guest replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    Those statements would never execute. An indicator cannot be both on and off at the same time. This trick was just to get a clean compile such as when you wanted to clear a record format but had to code a WRITE statement to make the compiler happy but never wanted the WRITE statement to execute. Chris

    Leave a comment:


  • Guest's Avatar
    Guest replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    I remember seeing and using RPGII calcs with conditioning indicators in positions 10-17 that would have LRNLR or 50N50 and that line of code would execute once and only once. Does anybody remember why...???

    Leave a comment:


  • J.Pluta
    replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    And I don't mean to sound like I think Dan is a crackpot. Dan is an established expert in the field, especially in SQL on the System i, so I respect his opinions. But I'm a stickler for evidence, and I think it's becoming more important rather than less that we know how our machines work. Your LR example is just one more of those statements that starts to get around even though it has no basis in fact. Joe

    Leave a comment:


  • Guest's Avatar
    Guest replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    Nice post Joe! People need to back up claims with evidence. Someone once told me that RPG is so fast now, it doesn't matter if you leave *INLR on or off in called programs. Boy was he wrong. I cranked out some test results and showed him that leaving *INLR *OFF makes subsequent calls to RPG 36 to 58 times faster, in a program that had 10 F-Spec files (opening and closing files in RPG is quite slow, even with activation groups). Regards, Chris

    Leave a comment:


  • J.Pluta
    replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    I hope you're not trying to imply that a FETCH for a single record in SQL is faster than a CHAIN. I have never seen a benchmark in which a single record FETCH outperforms a native CHAIN, and I've run thousands of benchmarks over the years. I'd love for you to provide us a definitive benchmark with source in which this happens; I'll include it in my next round of benchmarks (which I hope to do this year, but if not early next year). I understand your point about how all the data being in the index might let SQL skip an I/O, but that's rarely the case in a scenario where you're getting data from a single uniquely keyed record. Think about it: if the only data you want is the keys, and you already have the keys, then why would you try to get the record anyway? In short, unless you can provide an example otherwise, the answer is that reading a single keyed record is still faster in native I/O than it is in SQL. As is a single record update or a single record write (INSERT). Really, SQL is good for a lot of things, but fetching a single record is not one of them. Joe

    Leave a comment:


  • Guest's Avatar
    Guest replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    Herman, an RPG CHAIN operation requires 2 IOs. The first is an index probe to locate the RRN of the row you wish to retrieve. The second is a table probe to retrieve the actual row. SQL also performs an index probe, however if all of the data is in the index then the table probe is not required. In regards to opening tables, an open will have to be performed for both an RPG program or SQL statement when a persistent connection is not available. The focus at IBM is to continue to improve the performance of SQL opens.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    Do you have benchmarks of using SQL versus chain, ..etc' The time spent opening tables because the lack of persistence in Web applications. Herman J Woudenberg Concerning " RPG is the unsung hero of the IT world, and when you pair it with SQL and other System i technologies, you have all the power you need to make your applications absolutely sizzle. "

    Leave a comment:


  • RPG and DB2 Will Sizzle at the Summit in Orlando

    ** This thread discusses the article: RPG and DB2 Will Sizzle at the Summit in Orlando **
    ** This thread discusses the Content article: RPG and DB2 Will Sizzle at the Summit in Orlando **0
Working...
X