ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

node.js and RPG exported procedures.

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

  • node.js and RPG exported procedures.

    One of our developers is creating a Web UI over IBM i database using node.js. He said he needed to add the RTNPARM keyword on some existing (widely used) procedures in order for the procedure to work with node.js. For one procedure it seemed to cause no issue with the existing RPG programs using the procedure, for another it cause the calling programs to crash. Thoughts on acessing I data from node.js?

  • #2
    If you add the RTNPARM keyword to the return value of an existing function, you need to recompile all modules/programs where this function is called.
    If the RTNPARM key word is added to the return value, the return value is passed (under the cover) as first parameter.
    If you do not recompile your modules and programs, you'll get a parameter mismatch.

    Birgitta

    Comment


    • #3
      It shouldn't cause issues with any existing programs _IF_ the callers have all been recompiled AND are using a prototype that has the RTNPARM keyword included. Usually when there is a problem like this it is because someone has hard-coded protos in the callers rather than including them via /COPY or /INCLUDE and not all of them have been changed.

      There is one rider to that blanket statement concerning optional parameters. If these are in use and their presence/absence is being detected in the subproc via %Parms then be sure that the comparison value is not hard-coded but rather uses %ParmNum. Hard coded bad - soft coded good!

      I cannot tell from your question if you understand the mechanics behind RTNPARM but can explain further if it helps you to understand why this is vital. It is a great way to make general subprocedures available as web services and to other mechanisms like the web services wizards that don't accommodate anything other than integer parameters.

      Comment


      • #4
        If we wanted to avoid recompiling all the existing programs, could we embed the procedure in a wrapper procedure that has the RTNPARM?

        Comment


        • #5
          Yes. That used to be the approved solution until RPG added RTNPARM. But RTNPARM also has the side effect of improving performance for large return values. The wrapper approach will work but of course will add additional overhead.

          Or you could simply convert the returned value to a parameter in th wrapper rather than have RPG do it via RTNPARM. Might be worth testing both approaches if performance is an issue.

          Personally I'd recompile but that's just me. I gather from this question that you don't use a Change Management tool.
          Last edited by JonBoy; May 14, 2018, 09:03 AM.

          Comment

          Working...
          X