PUI0042 - Version Mismatch

[bruceanthony]

Just finished upgrading from 4.2.4 to 4.7.2.
I have 2 instances named xxxxxA and xxxxxB and they are both at version 4.7.2.
I call a profoundUI program from a refaced screen and it works fine so long as the library for the instance is being used.
I use to be able to (I think) mix and match so long as all instances and libraries were at the same level.

Also, is there a program other than http://dns:8080/profoundui/welcome that can be used to confirm the version of each instance?

[Scott Klement]

Profound UI keeps track of "session" data in it's library. There are certain pieces of information that's remembered and communicated across multiple jobs by storing it in a physical file. If you have two instances and have the wrong library in your library list, this can cause problems because it will be looking in the wrong session info database. So you should always make sure that the library for the instance you're running in is the one in your library list, rather than the library from another instance.

Though, Profound UI does it's best to force the current instance's library to be used. But it's possible (especially in a Genie session where the *LIBL is controlled by the 5250 job) to trick it.

Another common cause for this issue occurs when people will duplicate programs from PUI into their own libraries. I guess they do this so they don't have to add PUI to their library list, but it will almost certainly cause problems as things are upgraded, etc, and so this is definitely not recomended.

The welcome screen provides an easy way to check the version, but you can also easily check the version from any PUI session with a JavaScript debugger (or JavaScript code in your display) by checking the pui.version variable -- for example, go into a JS debugger's console, and type alert(pui.version), and it will pop-up the version number. This is telling you the version of the client-side (JavaScript) code, so immediately after installing a new version, this might be wrong if your browser cache is still holding the old version.

In newer versions of PUI (but not 4.2.4, IIRC) you can check the version of the server-side code (in your xxxxA, xxxxB libraries, not the JavaScript) by opening a URL like http://x.x.x.x:8080/profoundui/PUI0009111.PGM -- this will spit out a one-liner piece of JSON code that contains the version of the PUI server running in that instance.

Let me know if that helps

[David]

The PUI0042 - Version Mismatch means that you are running Genie in library X, but then calling the RPG Open Access Handler from library Y.

Doing this would cause some features to not function, even if X and Y were at the same version, hence the validation. Before, this was not the case, and it was ''ok' to do this if both X and Y were at the same version, even though you could run into some very confusing situations if they were not.

To figure out what product installation library to put onto the library list in the Genie application job, you can call this program:

http://www.profoundlogic.com/docs/displ ... Genie+mode

This reports the library Genie is running from, and this library should then be added to the list before calling the OA Handler in the job.

[bruceanthony]

The reason I have two versions is that it makes it very easy to upgrade production versions.
Right now I have an A and a B version with A having a listening port of 8090 and B having a listening port of xxxx. Each night, the A and B versions are terminated (ENDTCPSVR. *HTTP. etc) but A is the only one terminated. Version A and B are started but only the A version gets started as B has an invalid listening port. When it is time to upgrade, I upgrade the B version using 8091 as the listening port. I test to make sure everything is working after which I change the listening port of A to xxxx and B to 8090. In the middle of the night, A is stopped and B is started.

The job descriptions for the users still has the A library which is going to cause me some problems.

I will give this some additional thought but right now it looks like I will have to manually change the job D's or redo the upgrade in the middle of the night.
Another possibility would be to automatically change the JOB D's in the middle of the night and use some kind of dtaara to indicate which library should be in the JOBD.

[David]

Bruce,

Sorry for the difficulties, and thanks for the additional info.

I understand -- testing after performing a product upgrade is very important, and sounds like you've found a creative way of making this easier to accomplish. I'm sorry to hear our changes have made this more difficult for you. We did find this change to be entirely necessary, however, in order to implement some VERY important security enhancements. These required implementation of the session database Scott mentioned before, which in turn brings about the requirement for Genie and the OA Handler to run from the same library within a session.

I hope that you don't have to spend a lot of time in the night making manual changes. I can't think of a more convenient way to manage this using job descriptions to put the product library on the list, other than what you have thought of -- a CL to 'mass update' the JOBDs with a soft-coded value.

I'm not sure if this will be of immediate or eventual help to you, but the PUI0002300 program I mentioned earlier is very useful if all the users are set up (or can be setup) to go through the same initial program when they sign on. This can be called at that time to set things up. It's harmless if the program is called when they sign into a normal 5250 emulator, the 'isGenie' flag will tell you whether this is the case or not. When 'isGenie' is true, the other parameters will be set -- including the library that Genie is currently running from. This could then be added to the initial program to take care of it automatically. Of course, I realize that you may not be set up such that you have a place to run this when all users sign on. If not, it might be something to explore for the future.

Hope some of this helps...

[Scott Klement]

I imagine a CL program that calls PUI0002300 could be written that would be called from a routing entry in the subsystem? This way it wouldn't be necessary for all users to log on through the same initial program.

[David]

Scott,

There is an idea!

I'm not sure if this would work or not -- as you could guess, I'm a bit fuzzy on routing entries. PUI0002300 communicates with Genie through the 5250 data stream. Would that be possible if called from a routing entry?

[Scott Klement]

I don't see why not? I have used it before to bring up 5250 screens that prompt people for data, like "make sure your address is up-to-date in our HR files" type screens that pop up for all users when they log on, etc.

[David]

Scott,

If you can use a routing entry to run a program that processes a screen, then yes -- it would certainly be possible to use PUI0002300 from a routing entry. That is an excellent idea.

Bruce,

I hope some of this discussion helps make your life easier. If not immediately, then at least in the long term.

[bruceanthony]

Thank you for your input.
We have decided to change the job descriptions just prior to starting up Genie. Changing the job descriptions is not that difficult and well worth the effort especially if it means enhanced security.