I’ll share with Gill and Michael here what you and I discussed today.
My problem was that even though the latest Db2 jar was in a directory pointed to by my GERS_JARS variable, an older version was in the .m2 directory. This directory is normally updated in the build process by configBuild.sh, but this script has a bug in it. Kip has created an issue document for it in GitHub.
I’ve updated the jar version in the .m2 directory, but I’d like to do some more testing with SAFRBLD, so please don’t point to that until Monday.
You can set GERS_JARS= by replicating the “Paid-Extras” repo from on the build machine. The version 13 jars are the default ones in /main/JavaJars. Version 12 can be pointed to in a subdirectory if needed.
Hi Michael and Randall,
I am pretty sure the problem is that the build in safrbld does not have the newest db2 jars.
The build I have in /u/gillia1/git/public/Run-Control-Apps works reading from both DM12 and DM13.
When I try the same tests with the build in /u/safrbld/git/GenevaERS/Run-Control-Apps it works for DM12, but trying to read DM13 gets an SQL error.
I wonder if Ian has changed the way the db2 jars are incorporated. Ian guided me through setting that up a couple of month ago, and I think I just pointed to Ian’s copy in /u/icunnin, and maybe ran a script. Kip, do you know..?
I would note that in my .profile I have ‘GERS_JARS=’ (i.e. not set to point to anywhere), so I don’t think it’s trying to set up the db2 jars every time I run the install process.
It could be that once it’s set up it doesn’t re-install the db2 jars, unless you clear something in a POM file?
Feel free to use my build for now, as I won’t be changing it while Ian is away.
Gill
P.S. Another note – we changed VDP/XLT/JLT dd names to VDPNEW/XLTNEW/JLTNEW
Thanks, Kip.
I’ll share with Gill and Michael here what you and I discussed today.
My problem was that even though the latest Db2 jar was in a directory pointed to by my GERS_JARS variable, an older version was in the .m2 directory. This directory is normally updated in the build process by configBuild.sh, but this script has a bug in it. Kip has created an issue document for it in GitHub.
I’ve updated the jar version in the .m2 directory, but I’d like to do some more testing with SAFRBLD, so please don’t point to that until Monday.
Good sleuthing Gil:
The RC-App’s Preconfigure script checks to see if the local repository used in the build process has a DB2 jar in it. If not, it uses GERS_JARS= to put one there. https://github.com/genevaers/Run-Control-Apps/blob/main/prebuild/configBuild.sh
You can set GERS_JARS= by replicating the “Paid-Extras” repo from on the build machine. The version 13 jars are the default ones in /main/JavaJars. Version 12 can be pointed to in a subdirectory if needed.
Hi Michael and Randall,
I am pretty sure the problem is that the build in safrbld does not have the newest db2 jars. The build I have in /u/gillia1/git/public/Run-Control-Apps works reading from both DM12 and DM13. When I try the same tests with the build in /u/safrbld/git/GenevaERS/Run-Control-Apps it works for DM12, but trying to read DM13 gets an SQL error.
I wonder if Ian has changed the way the db2 jars are incorporated. Ian guided me through setting that up a couple of month ago, and I think I just pointed to Ian’s copy in /u/icunnin, and maybe ran a script. Kip, do you know..? I would note that in my .profile I have ‘GERS_JARS=’ (i.e. not set to point to anywhere), so I don’t think it’s trying to set up the db2 jars every time I run the install process. It could be that once it’s set up it doesn’t re-install the db2 jars, unless you clear something in a POM file?
Feel free to use my build for now, as I won’t be changing it while Ian is away.
Gill
P.S. Another note – we changed VDP/XLT/JLT dd names to VDPNEW/XLTNEW/JLTNEW