Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Practical RPG: Using Callbacks to Reduce Complexity

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

  • Practical RPG: Using Callbacks to Reduce Complexity

    ** This thread discusses the article: Practical RPG: Using Callbacks to Reduce Complexity **
    ** This thread discusses the Content article: Practical RPG: Using Callbacks to Reduce Complexity **
    0

  • #2
    Re:Practical RPG: Using Callbacks to Reduce Complexity

    ** This thread discusses the article: Practical RPG: Using Callbacks to Reduce Complexity **
    Performance would depend on the implementation. Obviously in the example given, there would be the extra overhead of an additional external program call each time you used the the API. However, if I were doing it, I would write all of my wrapper routines with callbacks as procedures in a service program. Then the only extra overhead is load the service program once on the first use of an API. Then as long as the activation group remains active, the performance should be basically the same as if you had coded it all in the same program object. My $.02

    Comment


    • #3
      Re:Practical RPG: Using Callbacks to Reduce Complexity

      ** This thread discusses the article: Practical RPG: Using Callbacks to Reduce Complexity **
      The performance overhead is negligible. Since you're passing the pointer to the callback procedure, the calls are as fast as a normal procedure call. The only resolution is on the initial call to the program and to be honest, the startup time on many of the IBM APIs is far larger than the time for a dynamic call to a program.

      Comment


      • #4
        Re:Practical RPG: Using Callbacks to Reduce Complexity

        ** This thread discusses the article: Practical RPG: Using Callbacks to Reduce Complexity **
        As I noted to the OP, the overhead of the initial call to the wrapper is likely to be far less than the call to the API itself; this is especially true of the various list APIs. As to the issue of service program vs. simple bound program it's a larger question. I would avoid binding wrappers together that aren't used together; the additional overhead of loading a procedure you will never use is unnecessary. Another nitpick is that the Java Toolbox support for service programs lags far behind the support for program calls. On the other hand, service programs provide multiple entry points even for the same wrapper, and as you expand your library of wrapper programs I think you will eventually find service programs to be a more useful approach. But let's address service programs another day, eh?

        Comment


        • #5
          Re:Practical RPG: Using Callbacks to Reduce Complexity

          ** This thread discusses the article: Practical RPG: Using Callbacks to Reduce Complexity **
          I agree that subdividing the API's into related service programs would have it's advantages, but as you say, that could be a topic for another day.

          Comment


          • #6
            Re:Practical RPG: Using Callbacks to Reduce Complexity

            ** This thread discusses the article: Practical RPG: Using Callbacks to Reduce Complexity **
            Joe: Why not use a dynamically allocated array? The calling program can allocate memory for it and pass a pointer to it; the called program can reallocate memory as necessary. The calling program is responsible for deallocating the memory, of course.

            Comment


            • #7
              Re:Practical RPG: Using Callbacks to Reduce Complexity

              ** This thread discusses the article: Practical RPG: Using Callbacks to Reduce Complexity **
              Dynamic arrays are a great tool, and I plan to address them in a followup to my earlier article on initializing and sorting arrays. But since the called program has to allocate memory anyway (if the number of entries is larger than will fit in the array initially passed), I think I'd prefer to let the called program handle all of the memory management tasks; let the program simply create an unallocated based array and let the called program do it's dirty work. Because at some point, there's still the practical limit of 32767 for the number of entries in an array; it's easy to blow that particular limit. And then the dynamic array becomes a paged array and you're back to the same old issue of an EOF flag. So I guess my take on it is to learn this technique first; it works on everything. You can always use dynamic arrays when it makes sense - that is when you can guarantee the size of the data being read.

              Comment


              • #8
                Re:Practical RPG: Using Callbacks to Reduce Complexity

                ** This thread discusses the article: Practical RPG: Using Callbacks to Reduce Complexity **
                Cool way to keep the narly details away from the programmers who might not need, or who are not ready yet to use API's as-is. Beforehand I had generally created a module of procedure interfaces to API calls that would only include necessary parameters for most common API's. Real simple example like encapsulating the QCMDEXC call into a procedure called ExecuteCmd which simply takes the command string...and returns success or failure indication. The procedure figures out the length of the command (which we all know by now uses the command-string and length parameters). Very easy to simplify API calls this way and with callbacks you can get even more slickery and flexible.

                Comment

                Working...
                X