Library list handling calling RPGsp programs from ProfoundUI

[Scott Klement]

Hi Kevin,

The 3rd option (having us add AUTH= to the URLs automatically) would be much easier for me to do than changing PUIFNDSTR to have a 'replace' capability. I also think it's an easier option for you, because you wouldn't have to change your existing displays at all.

As for the 'cant resolve to PUISYNCR'. Here's the issue:

When your RPGsp programs begin, there's code in your program (generated by the RPGsp tool) to change your library list to whatever is in the QCOMPILED/LIBLIST member. So this is actually code inside your RPG program.

However, by default, the ILE environment locates service programs in the library list when the RPG program is activated (NOT when the service program is first called... but when the RPGsp program that calls it is loaded into memory.)

So there's a timing issue there... It's loading the service program first, and then is adding the PROFOUNDUI library to the library list (via QCOMPILED/LIBLIST). The second call works because PROFOUNDUI is still in the library list from the prior call.

There are a few different options for solving the problem:

1) Use 'deferred' binding. This is a feature added in IBM i 6.1 that allows service programs to be located on 'first call'. That way your QCOMPILED/LIBLIST would be set before the service program is loaded, which would solve the problem.

2) As you mentioned, you could hard-code the library when binding the service program.

3) You could use something like the QIBM_CGI_LIBRARY_LIST feature, or even a little CL program, to add the library before your RPGsp program is called.


Number 1 is probably the easiest... You just do something like this:

Code: Select all

    CRTBNDDIR BNDDIR(yourlib/ICSPUI)
    ADDBNDDIRE BNDDIR(yourlib/ICSPUI) OBJ((*LIBL/PUISYNCR *SRVPGM *DEFER))

Then recreate your RPGsp page using the ICSPUI binding directory instead of the PROFOUNDUI one. It should now use deferred binding, which won't check the *LIBL until it calls SyncJob() the first time.

For the second option, do the same thing as above, but leave off the *DEFER and replace *LIBL with the library name. This may be the easiest option on V5R4 and earlier systems -- unless the hard-coded library is a problem?

[kevinh]

Is there an estimate when the feature to automatically add the AUTH parameter on all Choices URLs would be available?

I created a binding directory with the entry as you mentioned, went with the qualified library of PROFOUNDUI for the entry.
I now see this error in the PROFOUNDUI CGI job the first time the RPGsp program with the SYNCJOB(*ON) is called.

Cannot resolve to object PUISSNB.

I see this object is in PROFOUNDUI bound to PUISYNCR with *LIBL.

I have library PROFOUNDUI in the QCOMPILED/LIBLIST and in my UI session library list, its just not there for the the PUISSNB service program.
Sorry, more help needed.

[Scott Klement]

Ahh, yes.. I didn't think of that. So you'll definitely need to have PROFOUNDUI in your library list.

What about the deferred binding option? Will that work for you?

[kevinh]

Scott,
I had a little trouble at first with the *defer setting where both our system and the client's are at 7.1 but I found my compile options in the RPGsp IDE were set to compile to V5R4 due to our client base not all being at 7.1 (however all our PUI installs are thankfully at 7.1). This was one of those where "it compiles but it doesn't work" scenarios due to *defer being added at 6.1 as you mentioned.

With my RPGsp program compiled to 7.1 and my binding directory entry set to qualify library PROFOUNDUI for PUISYNCR and set to *DEFER the RPGsp program is correctly returning the dropdown choices even immediately after the server instance has been started (first run of the PROFOUNDUI CGI job.) I can see that switching back and forth between the two library lists for this customer's divisions while in a PUI session is now being reflected in the call to the RPGsp program using SYNCJOB and the library list is getting changed accordingly in the PROFOUNDUI CGI job. Yea!!

So now the question of the hour - when could that feature adding the AUTH parm on the fly be made available so I can get this customer up and running for both their divisions?

Thanks again for all your help - Profound Logic continues to see us through any development issues we encounter!