DB2 SQL Error: SQLCODE=-302, SQLSTATE=22001, SQLERRMC=3, DRIVER=4.32.45

[FALLAI-Denis]

LOGICAL_FILE (extract for repository).csv

Hi,

We encounter a problem during an impactBuild when accessing the MetadataStore:

com.ibm.dbb.build.BuildException: com.ibm.db2.jcc.am.SqlDataException: DB2 SQL Error: SQLCODE=-302, SQLSTATE=22001, SQLERRMC=3, DRIVER=4.32.45
        at com.ibm.dbb.metadata.jdbc.JDBCMetadataStore.createLogicalFile(JDBCMetadataStore.java:2529)
        at com.ibm.dbb.metadata.jdbc.JDBCMetadataStore.addLogicalFile(JDBCMetadataStore.java:2369)
        at com.ibm.dbb.metadata.jdbc.CollectionImpl.addLogicalFile(CollectionImpl.java:145)
        at com.ibm.dbb.metadata.jdbc.CollectionImpl.addLogicalFiles(CollectionImpl.java:152)
        at org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:318)
        at ImpactUtilities.updateCollection(ImpactUtilities.groovy:977)
        at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:465)
        at java.lang.invoke.MethodHandles$CatchHelper.helper(MethodHandles.java:2439)
        at org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:318)
        at ImpactUtilities.createImpactBuildList(ImpactUtilities.groovy:51)
        at org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:318)
        at buildBPCE.createBuildList(buildBPCE.groovy:745)
        at org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:318)
        at buildBPCE.run(buildBPCE.groovy:133)
        at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:287)
        at groovy.lang.GroovyShell.run(GroovyShell.java:393)
        at groovy.lang.GroovyShell.run(GroovyShell.java:382)
        at groovy.ui.GroovyMain.processOnce(GroovyMain.java:649)
        at groovy.ui.GroovyMain.run(GroovyMain.java:389)
        at groovy.ui.GroovyMain.access$1400(GroovyMain.java:67)
        at groovy.ui.GroovyMain$GroovyCommand.process(GroovyMain.java:313)
        at groovy.ui.GroovyMain.processArgs(GroovyMain.java:141)
        at groovy.ui.GroovyMain.main(GroovyMain.java:114)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
        at java.lang.reflect.Method.invoke(Method.java:508)
        at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:109)
        at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:132)

A userBuild with the list of components to build works, (no access to the MetadataStore).

Our research points to the LOGICAL_FILE Db2 table and more precisely the LF_LNAME column (3rd column) which is limited to 32 characters.

We are using:

• DBB version 2.0.1
• zAppbuild 3.0.1, modified by us

We noticed that the LOGICAL_FILE Db2 table lists all the files in the Git repository, and not just the components concerned by a build. For example, we find .txt and .csv files, office files (Word, Excel, etc.).
Is this normal?

So far we have not been able to identify the problematic file... none are longer than 32 characters.

A priori the problem is at the zAppbuild level, which provides data not compatible with DBB.
How could we diagnose the problem? (apart from coding println in zAppbuild scripts).

LOGICAL_FILE (extract for problem repository).csv

We also have the problem that the impactBuild retrieves files that are not in the scope requested by the property applicationSrcDirs:
applicationSrcDirs=${application}/src,${application}/pacbase

Thanks.

[dennis-behm]

@FALLAI-Denis

zAppBuild is considering 3 different groups of files in the build:

1. Files that need to be scanned and for which dependency information needs to be recorded.
2. Files that turn into build outputs (like a JCL), but which don't need to be scanned (we already know that there are no dependency records), but the user wants to record them in the metadatastore, potentially for (custom) impact analysis.
3. File that are excluded from the build.

From the bottom to the top:

• Files excluded from scanning and registering in the metadatastore need to be specified on excludeFileList.
• Files with build outputs + a record on the metadatastore, such as JCL, BUT no dependencies, is a matter of the dbb.scannermapping.
  If none of these restrictions are found, zAppBuild will scan and record these files.

Regarding your last comment on impact build finding files outside of applicationSrcDir, this sounds like data in the metadata could be incorrect .

[FALLAI-Denis]

Hi @dennis-behm,

Thank you for considering our issue.

Concerning the exclusion of files by the excludeFileList option, which generally uses file / folder name patterns, it can only handle cases identified and known in advance, but we do not control what developers can store in the Git Repositories that are used for builds.
It would be necessary to filter with a "positive" list of inclusions, (in principle file extensions), rather than with a "negative" list of exclusions. This "positive" list would allow to select only the files for which a build, direct or indirect, can be processed with a script build.

What we see during an impactBuild is that the git diff picks up all the files that are in the gap since the last successful build, regardless of the location relative to the list of folders declared in applicationSrcDirs.
Then these files are filtered, but we see that the filtering does not filter out files that are outside the folder trees defined by applicationSrcDirs.
The files that cause the SQLCODE -302 are not in the folders defined by applicationSrcDir, and yet they are recorded in the LOGICAL_FILE table.
build.createBuildList --> ImpactUtilities.createImpactBuildList --> ImpactUtilities.updateCollection
We modified the build.groovy script but basically kept its logic.
Dumping the LOGICAL_FILE table for the concerned Git repository shows that all files are saved there, whether they are in the scope of applicationSrcDirs or not.

[FALLAI-Denis]

Hi,

Sorry to come back to the subject but the management of the zAppbuild configuration is confusing for me...

What is the relationship between the applicationSrcDirs property and the excludeFileList property?

Is the excludeFileList variable taken into account on impactBuilds? The documentation only refers to fullBuild.

In our implementation applicationSrcDirs does not target Git Repositories, but multiple folders within a single Git Repository. The problematic file with a base name longer than 32 characters is located in a folder that is outside of applicationSrcDir, but in the same Git repository. Is this supported?

A diagram representing the sets of files targeted by each of these properties (and maybe others) would be welcome.

Furthermore, as the role of each Db2 table in the DBB Metadatastore is not documented (but the names remain evocative), it is difficult to understand their purpose and how they are populated.

Basically, I do not understand why an Excel file (since it is the one with a name of more than 32 characters) is affected by an insert in the LOGICAL_FILE table: it is neither affected by the build, nor an impact element to decide that a build must be done.
Note that this Excel file is placed outside the folders targeted by the applicationSrcDirs property, but it is detected by Git Diff since it is part of the Git Repository.

Thanks.