Library list handling calling RPGsp programs from ProfoundUI

[kevinh]

We make extensive use of RPGsp programs to populate dropdowns for PUI pages using the Choices URL property. Works great, but we have run into an issue where we have one customer that has two divisions of their company and stores their database files in different libraries. With PUI we can control the user’s session library list with their initial program CL, very similar to how done on the green screen. What I am finding out though is that when we call the RPGsp programs to populate the dropdowns the library list used for the RPGsp program is what is in file QCOMPILED member LIBLIST in our main PUI program library. This is only allowing the RPGsp program to find the data from one of the division libraries.

Generally a customer’s PUI session would have a library list as below with UI programs/screens in UI program libs, their data library as their current library, and then non-UI programs.
DIV1UIPGMS
BASEUIPGMS (where the RPGsp programs also exist and the QCOMPILED/LIBLIST file)
DIV1DATA (curlib)
DIV1PGMS
BASEPGMS

In PUI I can control the library list of the PUI session changing the Customer customized program libraries and Customer Data library as needed for the session.

The QCOMPILED/LIBLIST file in the BASEUIPGMS library has the library list as:
DIV1DATA
BASEUIPGMS

The problem comes when I have changed the PUI session’s library list to their other division as:
DIV2UIPGMS
BASEUIPGMS (where the RPGsp programs also exist and the QCOMPILED/LIBLIST file)
DIV2DATA (curlib)
DIV2PGMS
BASEPGMS

Because the RPGsp program being called is in BASEUIPGMS it is setting the libl of the RPGsp program run to be over DIV1DATA which is not what I need.

Our software is installed at several customers and for better maintenance we keep the RPGsp programs in the BASEUIPGMS library and each customer’s QCOMPILED/LIBLIST file on their system handles what data library to use for the dropdown values.

What I need is a way to force the library to be used when the RPGsp program runs to be the current library of the PUI session. All the jobs for all divisions run through the one PROFOUNDUI server instance. There are division settings in the PUI session’s LDA and of course the libl and current library is different when in different divisions. I'm hoping some of that can be used to trigger a different library list to be used. How can I get the RPGsp programs to use the division’s data library that I need it to use?

[Scott Klement]

Profound UI provides an API called SyncJob() that can be called from your RPGsp program. The idea is that it will synchronize the library list of your RPGsp program with the PUI program that called it.

To use it, you'll need to /COPY PROFOUNDUI/QRPGLEINC,PUISYNCR this has the prototypes for the SyncJob(), ResetJob() and RtvJobInfo() APIs.

Then, in your RPGsp program, you'll want to call SyncJob(*ON) somewhere in your RPGsp program. Probably do it at the top. You'll need to make your F-spec files USROPN files and open them separately after doing the SyncJob().

Also, there can be problems if you don't un-sync your job when you're done. This can be done easily, just do ResetJob() before your program exits.

This is provided by a service program in Profound UI, so you'll need to have Profound UI in your library list in order to do SyncJob(). If you are adding the Profound UI library inside the RPGsp program, you may have to use deferred binding -- but if that's something that's needed, let me know and we can discuss it further.

Anyway, will that help? Seems like it should make your RPGsp library list the same as your PUI library list (temporarily) which is what you want, right?

[kevinh]

Scott,
I've added the code to my RPGsp program (I had to change the /COPY to be from QRPGLEINC where PUISYNCR is found.)

The RPGsp IDE compiler erred with

Module compiled successfully but the compiler was unable to create the RPG/CGI program.

It instructed me to compile manually with the command below resulting in the errors below:

CRTPGM PGM(TESTICSUI/SELCLAIM) MODULE(TESTICSUI/SELCLAIM) BNDSRVPGM(*LIBL/RPGSPSP) AUT(*USE) USRPRF(*OWNER) TEXT('SELCLAIM in ICSUI/QRPGSPSRC') ACTGRP(*NEW)
*SRVPGM object QZDMMDTA in library QSOC not found.
Definition not found for symbol 'RESETJOB'.
Definition not found for symbol 'SYNCJOB'.
Program SELCLAIM not created.

Message details:

Additional Message Information

Message ID . . . . . . : CPD5D1D Severity . . . . . . . : 20
Message type . . . . . : Diagnostic
Date sent . . . . . . : 07/09/13 Time sent . . . . . . : 10:34:45

Message . . . . : *SRVPGM object QZDMMDTA in library QSOC not found.
Cause . . . . . : *SRVPGM object QZDMMDTA in library QSOC was specified in
binding directory QUSAPIBD in library *LIBL, but was not found for binding.
Recovery . . . : Contact your application provider or service
representative.

I do not have a library QSOC on the system.
What next?

[Scott Klement]

Ah, yes.. thanks.. it should be QRPGLEINC, I knew that, but typed QRPGLESRC out of force-of-habit.

You will also need to bind to the PUISYNCR service program, which can be done by including the PROFOUNDUI binding directory when you do the compile.

The "*SRVPGM object QZDMMDTA in library QSOC not found." is harmless, and would occur any time you specified a procedure without binding to the appropriate service program (no matter what the procedure is.) What's happening is that the system doesn't know where the 'SYNCJOB' and 'RESETJOB' procedures are. I know that they are in the PUISYNCR service program, and I know that you can locate this with the PROFOUNDUI binding directory -- but the system doesn't know that. Since it can't find them, it's searching every entry in the IBM-supplied system binding directory for them. In that binding directory is the QSOC/QZDMMDTA service program -- which is for optional IBM software that you do not have installed. So it can't look inside that program for SYNCJOB or RESETJOB -- well, it wouldn't find them there, anyway... but it doesn't know that. This type of message is commonplace in ILE.

Anyway, add the PROFOUNDUI binding directory to your program, and you should be all set.

[kevinh]

Scott,
Adding the binding directory got my RPGsp program to compile, but I'm not seeing the results I was expecting.
My RPGsp program is still only pulling data from the "Division 1" data library as it was before, even when my UI session is set to the library list for "Division 2."
I know its calling PUISYNCB because of joblogs showing the sync_SetLibraryList procedure addling libraries to the libl. I fought with it a while to get past an error in the PROFOUNDUI CGI jobs for "Cannot resolve to object PUISYNCR" where I found that PROFOUNDUI wasn't in the user portion of the library list and have added that to the initial signon program.

How exactly does the library list get set on the PROFOUNDUI CGI jobs I see servicing the RPGsp programs for the dropdowns when using SYNCJOB(*ON)?
As I worked with this it almost looks like the initial signon program specified for PROFOUNDUI sessions is getting called by these CGI jobs to set the library list.

I tried to simplify my process and just have a user signing on for Division 2 set its library list for the Division 2 libraries but when a UI page loads the dropdowns by calling a RPGsp program in my Base program library it is still using the Division 1 data library. It still appears to be using the QCOMPILED/LIBLIST in the Base program library or somehow using a library list established by something other than the user's PUI session.

[Scott Klement]

Hi Kevin,

My RPGsp program is still only pulling data from the "Division 1" data library as it was before, even when my UI session is set to the library list for "Division 2."

Are your files defined as USROPN, and being opened only after the SyncJob(*ON) is complete?

How exactly does the library list get set on the PROFOUNDUI CGI jobs I see servicing the RPGsp programs for the dropdowns when using SYNCJOB(*ON)?
As I worked with this it almost looks like the initial signon program specified for PROFOUNDUI sessions is getting called by these CGI jobs to set the library list.

It retrieves the job information from the PUI session (this is done by calling the IBM-supplied API, QUSRJOBI) to get the library list that's currently set in that PUI session. It then clears the library list and uses ADDLIBLE to add each library to the list, resulting in the same library list that's in the PUI job.

This occurs at the time that you call SyncJob(*ON). So the library list in QCOMPILED/LIBLIST is in effect prior to the call to SyncJob(). That's why you need to make your files USROPN and open them after the SyncJob() is complete.

We at Profound internally for many of our server jobs. For example, data-driven controls like drop-downs, build an SQL statement and run it to get the data that's supplied for the drop-down, but before we run the SQL statement, we use SyncJob to set up the library list. Same for things like auto-complete boxes, SQL-driven grids, exit programs, etc.

I tried to simplify my process and just have a user signing on for Division 2 set its library list for the Division 2 libraries but when a UI page loads the dropdowns by calling a RPGsp program in my Base program library it is still using the Division 1 data library.

That's strange... all I can think of off the top of my head is that you're opening the file before calling SyncJob(*ON), so the library list is searched before it has been synced with the PUI job. Is that possible?

Another possibility might be that SyncJob() is failing for some reason... though, you did say that it was adding libraries with ADDLIBLE, right?

One other thing -- my fault, I didn't think to tell you this -- you need to pass a parameter of AUTH=XXXXX where XXXX is the current PUI auth string, since this is how you tell SyncJob() which job to synchronize with. To do that, you'll want your URL for your RPGsp page to look something like this:

Code: Select all

script: "/path/to/yourpgm?AUTH=" + encodeURIComponent(pui["appJob"]["auth"])

Does that help?

[kevinh]

Yes, the files are user open and opened after the SYNCJOB.

This was the solution:

One other thing -- my fault, I didn't think to tell you this -- you need to pass a parameter of AUTH=XXXXX where XXXX is the current PUI auth string, since this is how you tell SyncJob() which job to synchronize with. To do that, you'll want your URL for your RPGsp page to look something like this:

Code: Select all

script: "/path/to/yourpgm?AUTH=" + encodeURIComponent(pui["appJob"]["auth"])

I added the AUTH parameter as above to my current Choices URL string and it works now. I knew the PROFOUNDUI CGI jobs were not consistently showing the correct libl as I expected and that makes sense that something had to tie the CGI job back to the PUI session, but I was hoping it was under the covers.

Unfortunately this solution is going to require a substantial amount of work to implement as we probably have over a thousand screens that have one or more dropdowns making use of the choices URL calling a RPGsp program. We do already pass the PUI session's six digit job number in the URL just for caching issues we saw early on. We only have about 40 of these RPGsp programs used for dropdowns so I may look at changes within them to handle this issue if possible without having to update every dropdown choices url on the system.

Do you know of anything available within the PUI files that with the PUI session's job# I would be able to access the AUTH string from within the RPGsp program and satisfy the parameters needed by SYNCJOB?
My choices URL looks like this after adding the AUTH parameter:

Code: Select all

/icsui/selclaim.pgm?COMPANY=I&UIMFGC=ATD&icsjob=500151&AUTH=A0F2FB49939D2EF91F2B2B62B97060E0FDB86CB5C8BB5E0F26D8DE8D9CC47A68

What I'm asking is, is there a way to retrieve the AUTH value in the RPGsp program using the job# passed in icsjob? If so would just setting the AUTH variable before the SYNCJOB work the same as passing it in the URL?
Getting a little deeper here. Thanks for all your help.

[Scott Klement]

Do you know of anything available within the PUI files that with the PUI session's job# I would be able to access the AUTH string from within the RPGsp program and satisfy the parameters needed by SYNCJOB?

I do know of a way, but it's not good or elegant. The PUI session database is not intended to be used this way. It has a "generic" field for metadata that will have the job number in it sometimes, but sometimes not. Plus, that metadata is subject to change in any future updates/releases/patches of PUI without notice to customers, since it's considered an "internal" thing. But, ti's possible :-)

Then, as you've started to realize, SyncJob() gets the AUTH= from the URL, so if we were to look up the AUTH value in the session database, we wouldn't be able to use it with SyncJob(), we'd have to call lower-level APIs within PUI, which are also not intended for customers, and are subject to chagne wtihout notice.

So there would be a huge risk here of your code breaking with any update to PUI, and we wouldn't even warn you that it would break because we don't consider these interfaces available to customers. I definitely think this would be a bad way to do it.

What I'm asking is, is there a way to retrieve the AUTH value in the RPGsp program using the job# passed in icsjob? If so would just setting the AUTH variable before the SYNCJOB work the same as passing it in the URL?
Getting a little deeper here. Thanks for all your help.

I can think of three solutions:

1. The solution I mentioned above, but I do not recommend.
2. You could write your own version SyncJob() (ICSSyncJob?) based on the job number instead of AUTH=. I could help you with some of the details, here... but, one big problem with this approach is security. The job number is easy for a hacker to guess since it's a well-known, sequential number. So he could potentially guess at other job numbers and get data that he shouldn't. That's why we do not use the actual jobid for our AUTH= string.
3. We could modify Profound UI to automatically add the AUTH= into your 'Choices URL' so that you do not have to modify your screens.

Personally, I think the 3rd option is the most elegant. It is secure, and you won't have to write your own special routines or muck about with internal PUI stuff.

Does this sound good to you? If so, I can create a feature request for you.

[kevinh]

Your option 3 for a feature would be the best for us. I assume a system wide setting for automatically adding AUTH to choices URL strings?

The only other option I could think of is if the PUIFNDSTR had a "replace" option we could scan our QDDSSRC members for the Choices URL property to search for our current string that sets the icsjob parameter and replace it with the AUTH string. It appears the AUTH string will give us the same "caching feature" that passing the job number does where we needed the values returned to be reloaded for each new session and then cached for the life of the session for better performance, so we wouldn't really need our icsjob parm anymore and replacing it wouldn't hurt.
I'm sure with the meta data that sounds easier than it is.

[kevinh]

Scott,
I am noticing one problem now that I have my dropdown loading the correct data after adding SYNCJOB to the RPGsp program. I'm able to reproduce the problem only after the PROFOUNDUI server instance has been ended and restarted which we do as part of End-of-Day processing.
The first time I go into the PUI program that has the dropdown that is using the choices URL calling the RPGsp program with the SYNCJOB(*ON) the dropdown is empty. I find a PROFOUNDUI CGI job that has ended with this error immediately after the job starts

Cannot resolve to object PUISYNCR.

I'm sure this is a library list issue with PROFOUNDUI not in the library list of the PROFOUNDUI CGI job. I also see where Service Program PUISYNCR is set to *LIBL where it is bound to my RPGsp program. I know we've had issues like this before with our own binding directories and service programs where we ended up qualifying the library of the service program entry.
This problem goes away if I open another PUI program that has different dropdowns using RPGsp programs not yet changed for SYNCJOB then I go back to the PUI program using the updated dropdown RPGsp program that is using SYNCJOB. I then find an active PROFOUNDUI CGI job showing where the library list was updated by a successful run of SYNCJOB.
Its like at some point library PROFOUNDUI is getting added to the library list of the PROFOUNDUI CGI jobs but it is not in the libl initially when the CGI jobs are first started. We are on PUI version 4.6.1 and iOS 7.1.

I'm thinking this has to do with your comment in your first reply where you stated

This is provided by a service program in Profound UI, so you'll need to have Profound UI in your library list in order to do SyncJob(). If you are adding the Profound UI library inside the RPGsp program, you may have to use deferred binding -- but if that's something that's needed, let me know and we can discuss it further.

So I'm thinking I need that further discussion now. I'm concerned that once all our RPGsp programs are using SYNCJOB that we'll have a massive amount of dropdowns not loading first thing each day.