Different library reference environments

[matt.tyler]

We just loaded version 2.2 and migrated from 2.1, I noticed that the environments I set up there was still the reference to valence21 library.

Should the conversion program vvcnv22 have altered these references?

Does this library need to exist for normal user operations (i.e. users running our apps only)?

I would like to see if another option can be used to add libraries for users. For example, I would like to have the system use the JOBD of the user currently logged in and use that *LIBL and/or allow a "startup" program for an environment (probably qualified). Just like on the subsystem property for connections in RDP 7.6, 8.0,wdsc, etc.

I am trying to get around hard coding libraries in our list, in case we add, rename or remove them from our system. One less place to have to make a change.

Thanks, Matt

[robert.swanson]

Hi Matt,

The VVCNV22 conversion routine includes a procedure (called "updateEnvs") to migrate any reference of the "from" library to the new "to" library. Indeed, it appears the procedure is doing an OVRDBF to the environment file in the "from" library rather than the "to" library, which would mean the changes are applied to the old environment rather than the new one. I'm surprised nobody else has reported this before! I suspect many sites are using the default environments rather than creating their own, so they wouldn't be affected...

Anyway, line 435.00 should be adjusted to say "toLibrary" instead of "fromLibrary" for this routine to work properly. I'll get this corrected on our end for the next maintenance release. Thanks for the heads up!

Of course, if you haven't already done so, in your 2.2 instance you should manually change your custom environment library lists that reference VALENCE21 to VALENCE22. There is no need to keep VALENCE21 in there. In fact, leaving it there could cause problems.


The CGI jobs in the Valence subsystem must handle a ton of traffic from the front-end users. So we went to great lengths to design VVCALL so as to minimize the overhead associated with all the security and environment checks that must happen with each call. Right now the program buffers in memory a lot of information regarding the active environment library lists, so there is very limited added I/O required between calls. If the program had to check the JOBD and corresponding LIBL for each back-end call, it could add a noticeable amount of time to process each call, resulting in a slower response time to the user. So I wouldn't recommend taking that approach if it's not absolutely necessary. I think it'd be better to find a way to mirror your library changes into the appropriate VVEVQ100 file records, perhaps using a variation of the "updateEnvs" procedure in VVCNV22.

Rob