Need for documentation of .devextconfig.json file and the options within to be surfaced to the GUI
Opened this issue · 4 comments
Development environment where there is a need for more documentation
- Db2 Developer Extension version: 2.1.5
- Editor platform
- Visual Studio Code
- Eclipse Theia
- Editor platform version:
Version: 1.87.2 (user setup)
Commit: 863d2581ecda6849923a2118d93a088b0745d9d6
Date: 2024-03-08T15:20:17.278Z
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Windows_NT x64 10.0.19045 - Operating system on which your editor runs (for example, Windows 10 2004 or MacOS Catalina 10.15.7): Windows 10
- Java Version (Run
java -version
and paste the details here):
openjdk version "21.0.2" 2024-01-16
OpenJDK Runtime Environment (build 21.0.2+13-58)
OpenJDK 64-Bit Server VM (build 21.0.2+13-58, mixed mode, sharing) - Db2 for z/OS version (including function level for Db2 12): 13 - V13R1M100
- Log files attached?: No
Challenge description
I was trying to make developerextension to deploy a stored procedure by first doing a SET CURRENT SQLID to a specific name. After finding the .devextconfig.json file I concluded that there is an option called buildOwner that I can use to make this happen. The option is not surfaced to the GUI as far as I can see and still it is of great importance when we want to set the OWNER at deployment of a stored procedure. Furthermore I could not find any documentation of the .devextconfig.json file. There are other options that might be useful, but since I'm just able to guess it's not that helpful. I see options like procedureOptions : "", and uploadSource : "false" that I'm curious of.
I also noticed that 3270 tools has problems to show the source from the Db2 catalog for a stored procedure deployed by the extension. I'm talking about the SQL logic, not the definition part.
Here is an example:
APPLCOMPAT V12R1M509
CONCENTRATE STATEMENTS OFF
SPECIFIC I4SP010
P1: BEGIN.. -- ......................................................
................... -- . Set default version of the given Db2 REST se
rvice .. -- .........................................................
................ DECLARE COMMAND VARCHAR(256);.. DECLARE REBIND V
ARCHAR(22) DEFAULT 'REBIND PACKAGE("';.. DECLARE DOT VARCHAR(3) DEFAU
LT '"."';.. DECLARE MID VARCHAR(3) DEFAULT '".(';.. DECLARE LAST V
ARCHAR(27) DEFAULT ')) RESTSERVICEDEFAULT (YES)';.. DECLARE RESULTSET
RESULT_SET_LOCATOR VARYING;.. DECLARE AT_END INTEGER DEFAULT 0;..
DECLARE ROWNUM INTEGER DEFAULT 0;.. DECLARE MESSAGE VARCHAR(120);
When looking at another stored procedure it can look like the following.
APPLCOMPAT V12R1M100
CONCENTRATE STATEMENTS OFF
P1: BEGIN
DECLARE LEN INT;
-- DECLARE CURSOR
DECLARE CURSOR1 CURSOR WITH RETURN FOR
SELECT RTRIM(RESOURCE) AS RESOURCE
FROM TAB143
WHERE USERID
= UPPER(USERID)
I'm thinking of the SPUFI SQLFORMAT option where you can specify SQLPL mode that is intended primarily for SQL procedural language processing. When this option is in effect, SPUFI retains SQL comments and terminates each line of an SQL statement with a line feed character (hex 25) before passing the statement to Db2. Lines that end with a split token are not terminated with a line feed character. Use this mode to obtain improved diagnostics and debugging of SQL procedural language.
Is this an analogy to the uploadSource option in the .devextconfig.json configuration file? I actually set it to true, but there was no difference when displaying the SQL logic.
I would like to see the following.
- Full documentation on the .devextconfig.json configuration file
- All the options in .devextconfig.json configuration file to surface in the GUI
Thanks in advance, Len
Hi @db2len,
the .devextconfig.json
file is not meant to be modified by the user. It's placed in the same directory as the deployment for easier repo transfer.
In the latest 2.1.5 release that includes external SQL SP and Java SP deployment, we've added some configurations that are only relevant to the respective deployments. Currently the .devextconfig.json
includes all the configuration for all possible deployment options both relevant and irrelevant to the deployment, but we have an enhancement for the individual SP to only contain the relevant deployment options in the .devextconfig.json
coming later.
That said, if a deployment UI does not surface an option, it is not relevant to the deployment type.
However, the build owner
field you mentioned should be relevant and appear in all deployment types.
External SQL SP:
Java SP:
Native SQL SP:
The documentation for individual deployment options surfaced on the UI can be found here:
Native SQL SP:
https://ibm.github.io/db2forzosdeveloperextension-about/docs/working-with-stored-procedures/deploying-debugging-running-native-sql-stored-procedures
Java SP:
https://ibm.github.io/db2forzosdeveloperextension-about/docs/working-with-stored-procedures/deploying-running-external-java-stored-procedures
External SQL SP:
https://ibm.github.io/db2forzosdeveloperextension-about/docs/working-with-stored-procedures/deploying-running-external-sql-stored-procedures
Regarding the issue with 3270 tools display part, we will need to investigate further.
Hi @b-tsao,
Many thanks for your reply!
I must say that I really like the Db2 Developer Extension, it gets new features with a high pace and it is very useful. I'm sorry I missed the GUI option "Build owner", it was really obvious that I did not need to edit the .devextconfig.json file for that purpose... There are also other situations where I hoped for some useful option in the file. But that will be reported as a separate issue. I will try to keep myself from editing the file...
Best regards, Len (running 2.1.5)
Regarding the issue with 3270 tools display part, we will need to investigate further.
Hi again @b-tsao,
I'm grateful if you could look into this. The tool I was using was Broadcoms RC/Query and its DDL function - it takes the stored procedure definition out of the Db2 catalog and presents it. And it looks quite awkward. Apart from that, the deployed stored procedure works perfectly well.
Best regards, Len