Dear collective wisdom,

as we are about to upgrade our IBM i operating system, we are investigating Vagen and EGL support. Our library lists typically include both QVGEN and QEGL In doing so, I investigated whether library QVGEN is actually needed. So, here are my findings. First, for easy access I listed all objects in QVGEN and QEGL into files.

DSPOBJD OBJ(QVGEN/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) OUTFILE(MYHOMELIB/VGNFILES)DSPOBJD OBJ(QEGL/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) OUTFILE(MYHOMELIB/EGLFILES)

Then I queried possible unique objects in QVGEN.

SELECT * FROM MYHOMELIB/VGNFILES WHERE ODOBNM NOT IN (SELECT ODOBNM FROM MYHOMELIB/EGLFILES)

It turned out that only object QVGN of type *BNDDIR is unique in QVGEN. (Just for the record, I also checked names combined with object types as well.) So in principle, if QEGL is before QVGEN in library list, objects in QVGEN are never used. However, it also turned out that some objects in QVGEN are actually used: QVGNEXTF, QVGNHS, QVGNMEM, QVGNWEB, QVGNMSGF and QVGNPRNT. I can think of two explanations: either those objects are hard coded somewhere or somewhere we have old (old as in Vagen age) library lists that are missing QEGL.

So my question is, is QEGL backwards compatible so that old Vagen programs can safely use objects in QEGL instead of QVGEN? And a related question, do you have any information whether these runtimes are supported in IBM i versions 7.2 and 7.3.

All the best,

Tuukka

Tuukka,

The short answer is that VAGen generated programs still do have a need for the QVGEN runtime (for the items you mentioned).   Also, it has its own unique activation group which can randomly cause machine checks if you are mixing VAGen and EGL in calls (not 100% of the time).

But there is a solution, but need to ask a question first... what version of ibm i are you running now?

Mark

Hello Mark,

we are running IBM i 7.1 now.

All the best,

Tuukka

Ok..the reason for the earlier question was to make sure you had a version of QVGEN that could run on something after V5.4. 

We do have a solution to allow QVGEN and QEGL to coexist and some customers are using it  But we need to check to make sure it is still current, so it might take a week or two to get that done.

My suggestion is to open a PMR and request it.

The readme would be something like this and the real work was to make sure the activation groups were the same since we do use shared memory. 

Also, you would include QEGL ahead of QVGEN in the library list (or at least have QVGEN accessible on the system).  If I remember right (it has been a couple of years)... the only reference to QVGEN is hard coded....so it will not search the library list.  

Sample readme;

1) copy qvgen/qvgnmem to qvgen/qvgnmemold so that you have a backup
2) copy qegl/qvgnmem to qegl/qvgnmemold so that you have a backup
3) on the iSeries, you need to create a save file so you can restore the file I am attaching. You do this by issuing this iSeries command: CRTSAVF FILE(QGPL/EGLVAGSHR)
4) transfer the attached savf file as binary to your iSeries, by using ftp and the following commands:
[

ftp your_iseries_name_or_ip_address
(enter your userid and password)
bin
quote site namefmt 0
put EGLVAGSHR.SAVF QGPL/EGLVAGSHR

once the upload completes, then continue with these commands:

5) create a new library with the CRTLIB command for library EGLVAGSHR
6) unpack the save file by using this command: RSTLIB SAVLIB(EGLVAGSHR) DEV(*SAVF) SAVF(QGPL/EGLVAGSHR)

You will now have our replacement modules. To install them, do the following:

7) copy eglvagshr/qvgnmemegl to qegl/qvgnmem
8) copy eglvagshr/qvgnmemvag to qvgen/qvgnmem

You will probably need to logoff/logon again if you are using the same userid to run your application.

Execute the applications and make sure things work, including other VAG programs that are standalone.

Hello Mark,

we are currently using old legacy third-party Vagen software while our own software has been written in EGL for 11 years now. So, in that sense we are currently running QVGEN and QEGL successfully at the same time. Our worry is that VGEN might go out-of-support in upcoming IBM i releases. Therefore I started investigating the relation between QVGEN and QEGL libraries, aiming to gain some more understanding who is using QVGEN even if the same objects exist in QEGL. But if reference to QVGEN is hard-coded, then we will simply need to keep the library -- and hope that the programs still work in the upcoming IBM i releases.

Tuukka

Thanks for the background.  

The issue that requires the change mentioned above arises when a VAGen and EGL program call each other.   Even then, errors do not always occur.     It sounds like you don't have this situation though...and they are more separate.

And yes, as long as the VAGen generated code is used, then you will need a copy of QVGEN available.   Assuming no other major changes in structure like there was between V5.4 and V6, then I would guess it would continue to be usable.     Of course, you could migrate the old legacy system to EGL (if you have the source) :-).

Mark