as4/ADDLIBPATH and rfcexec

[Former Member]

Since the 7.20 kernel upgrade wipes out rfcexec and startrfc, I had to install the new nwrfc SDK. As per note 1149088, I also had to add as4/ADDLIBPATH to the instance profile. I still can't get rfcexec to work from sm59 and I'm not sure how to tell if the as4/ADDLIBPATH actually did anything. Where should it show up? In one of the environment variables? RZ11 just tells me that the parameter is unknown (which is another issue unto itself). So two questions I guess. How do I tell if the as4/ADDLIBPATH actually did anything? How do I get rfcexec to work again? I've reviewed a ton of notes on this and I'm sure I'm missing something simple. Thanks - Rick

[Former Member · Accepted solution]

Hi all,

We recently ran into the same issue, and stumbled on your thread while looking for the answer.  We think we've solved the issue.  We're working with 720 kernel, patch level 300.  Setting rfc/use_gwstart = 1 is critical.  At this patch level, as4/ADDLIBPATH seems to change both PASE_LIBPATH and PASE_PATH.  You can verify the changes after restarting with the following API call in IBM i:

#### Environment Variables of a running job ####

CALL QSYS/QP0ZMAINT PARM('30' '<jobnum>' '0' '30')

<jobnum> is the job number you can find in WRKACTJOB.  You'll presumably want to select any of the work processes for the system you're changing.

Note that it's possible to add multiple directories to ADDLIBPATH by separating each path with a colon.  Here's what our environment variables looked like after setting ADDLIBPATH to

/usr/sap/nwrfcsdk/bin:/usr/sap/nwrfcsdk/lib.

PASE_PATH=/usr/sap/SR2/SYS/exe/run:/usr/sap/SR2/SYS/exe/run/sapjvm_5/bin:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:/usr/bin:.:/sapdb/clients/SR2/bin:/usr/sap/nwrfcsdk/bin:/usr/sap/nwrfcsdk/lib

PASE_LIBPATH=/usr/sap/SR2/SYS/exe/run:/usr/sap/SR2/hdbclient:/sapdb/clients/SR2/lib/lib64:/sapdb/clients/SR2/lib:/usr/sap/nwrfcsdk/bin:/usr/sap/nwrfcsdk/lib

Note that both environment variables thus contain the binary directory (.../bin) in which our new rfcexec binary is.  We haven't tested exhaustively, but this allowed the SERVER_EXEC RFC destination to run its connectivity test successfully.

Regards,

Mike Frost

SAP on IBM i Center of Excellence

IBM Rochester

[Former Member · Accepted solution]

Mike - this is awesome! Another note - I failed to include the ../nwrfcsdk/bin directory (just the ../lib) on my ADDLIBPATH but it still worked, probably because I had the full path specified in SM59. (/RFCSDK/nwrfcsdk/bin/rfcexec). Alas, my EDI person will still not be available until the beginning of next year so I can't categorically state this solves everything but this is VERY promising. The tip about checking environment variables of running jobs is definitely a keeper no matter what.

Thanks again,

Rick

[blaw]

Try adding   rfc/use_gwstart = 1 to the instance profile - note 638701

Regards,

Brian

[Former Member]

Thanks Brian - I'll give it a try even though the system tells me the parameter name is unknown. Given that the note was for an earlier release, one would think that a 720_EXT kernel would recognize the parameter name by now. This could create other problems down the road though, if I understand these notes correctly. In short, I think I'm still missing something really simple. Where this is really going to be an issue is with EDI since the RFC destination in the outbound trigger is SERVER_EXEC. (in WE21) I'll give your suggestion a try and let you know.

[Former Member]

Hi Rick,

Were you able to solve this and did the parameter help?  We are experiencing intermittent performance issues the RFCs and looking for possible solutions.

Thanks,

Deb

[Former Member]

Hi Deb - the problem is not yet solved. However, that is due more to lack of activity than anything. I cannot tell if the parameter as4/ADDLIBPATH actually did anything since none of the PATH environment variables have that directory appended to them (i.e PATH, ILE_PATH, PASE_PATH). The parameter Brian suggested,  rfc/use_gwstart, is also implemented and I just can't tell if it helped or not. Sorry. BTW, the lack of activity is due to my EDI coordinator freaking out (not without some justification obviously). We will NOT install the 720 kernel until we have time to thoroughly test EDI with it. This is our busiest time of year so DEV is pretty much in lockdown except for emergencies until the end of the year.

[Former Member]

Hi Rick,

Thanks for sharing your update.  We are still working through our performance issue as well.

Good luck.  If we find out anything worth sharing, I will pass it on.

Deb