Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Convert Case Revisited and Updated

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

  • Convert Case Revisited and Updated

    ** This thread discusses the article: Convert Case Revisited and Updated **
    ** This thread discusses the Content article: Convert Case Revisited and Updated **0

  • #2
    Convert Case Revisited and Updated

    ** This thread discusses the article: Convert Case Revisited and Updated ** [*]* Clear the FRCB data structure Eval FRCB=*ALLX'00'

    Comment


    • #3
      Convert Case Revisited and Updated

      ** This thread discusses the article: Convert Case Revisited and Updated **
      Thanks for notifying us. I've posted a message to the webmaster/on-line editor so it should be taken care of soon. If not, the code should be (as you implied): eval FRCB = *ALLX'00' Thanks!

      Comment


      • #4
        Convert Case Revisited and Updated

        ** This thread discusses the article: Convert Case Revisited and Updated **
        Hi Bob! As we all know, programming is a matter of balancing different trade-offs. Using CVTCASE offers the programmer the advantage of an easier to use procedure interface. But what about the extra overhead brought on by adding an extra procedure call? Could you help your readers make an informed choice by providing some relative performance numbers comparing calling CVTCASE versus calling QlgConvertCase directly? For the purposes of the comparison, just pass a simple fixed length 10 byte character field. Cheers! Hans

        Comment


        • #5
          Convert Case Revisited and Updated

          ** This thread discusses the article: Convert Case Revisited and Updated **
          I had hoped the words "overhead" and "procedure call" would never be used in the same sentence. I'll see if Rick Turner wants to run some time trials to see what the "overhead" is. Too bad there isn't a 'carbonization" process for API calls that can be used by setting up a wrapper procedure that calls the API and is then tested in some way so that the API can, at the point, be in-lined to avoid the extra call overhead.

          Comment


          • #6
            Convert Case Revisited and Updated

            ** This thread discusses the article: Convert Case Revisited and Updated **
            Well, just hoping for something doesn't make it true. Fact is, procedure calls always have at least some overhead. Normally, the additional functionality, maintainability, and modularization of procedures make the choice a no-brainer. HOWEVER, when you're dealing with 65536A VARYING return values, you're getting into an area of rather excessive call overhead. The problem is that when you return a 65535A VARYING value, the procedure is copying 65537 bytes of data. This is true regardless of the actual length of string returned. You could be returning back a 10 character long string, but the machine is still copying 65537 bytes if the procedure is defined with a return type of 65535A VARYING. (BTW, this should not be new news to you. This issue was discussed about 2 years ago on the RPG400-L mailing list. Check the link - you were there.) Elsewhere I've argued that RPG just might not be the best choice for all application domains. It may well be the best for certain things, like financial apps. But when it comes to problem domains requiring heavy duty string manipulation, there are much better choices available. Cheers! Hans

            Comment

            Working...
            X