Hi,

We want to use User Defined Functions, using the User Defined Function Prototype.
We have a standardized COBOL compilation procedure that declares the SQL('APOSTSQL ATTACH(TSO) PERIOD VERSION(AUTO)'), even if the COBOL source code does not contain any SQL statement. This may result in a message "IGYSC0209-W DSNH053I DSNHPSRV NO SQL STATEMENTS WERE FOUND".

But more seriously, the User Defined Function fails to compile because there is a Locale-Storage Section in the source code, which is false:

==000027==> IGYDS1563-E "LOCAL-STORAGE SECTION" was found in a prototype "DATA DIVISION".
                        "LOCAL-STORAGE SECTION" and all contained paragraphs were ignored.

Problem found with IBM Enterprise COBOL for z/OS 6.4.0 P240416.

Apparently, it's the SQL compilation option that causes this problem, even in the absence of SQL order.
If we compile in NOSQL, there's no problem.
So we compile the UDFs with NOSQL, but I would like to understand the problem.

Why would using the SQL option implicitly create a Locale-Storage Section?

Thanks.

Hi,

We want to use User Defined Functions, using the User Defined Function Prototype.
We have a standardized COBOL compilation procedure that declares the SQL('APOSTSQL ATTACH(TSO) PERIOD VERSION(AUTO)'), even if the COBOL source code does not contain any SQL statement. This may result in a message "IGYSC0209-W DSNH053I DSNHPSRV NO SQL STATEMENTS WERE FOUND".

But more seriously, the User Defined Function fails to compile because there is a Locale-Storage Section in the source code, which is false:

==000027==> IGYDS1563-E "LOCAL-STORAGE SECTION" was found in a prototype "DATA DIVISION".
                        "LOCAL-STORAGE SECTION" and all contained paragraphs were ignored.

Problem found with IBM Enterprise COBOL for z/OS 6.4.0 P240416.

Apparently, it's the SQL compilation option that causes this problem, even in the absence of SQL order.
If we compile in NOSQL, there's no problem.
So we compile the UDFs with NOSQL, but I would like to understand the problem.

Why would using the SQL option implicitly create a Locale-Storage Section?

Thanks.

Here's a bit more discussion on SQL and UDFs:

https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/using-user-defined-functions-with-cics-and-sql?communityKey=dc94cb0f-7361-47d9-854f-dfcbdbbf04a3

I have a few additional observations.

• Firstly, I am guessing that the SQL coprocessor knows nothing of prototypes (or functions, for that matter), and thus treats any source element passed to it by the compiler as a program.  Thus it generates the same data division details that it would for any program source passed to it.  It looks like that includes both some working-storage fields and some local-storage fields. 
• Additionally, the SQL coprocessor appears to only be in effect for the first source until passed to it during a compilation of multiple source units.  As an example (even with UDFs out of the picture), if you do a compile with the SQL option set, and your source module contains two COBOL programs (for example, a "main" program and a subprogram which is statically called by the main program), the SQL option is in effect only for the main program.  If you put SQL statements in the "subprogram" you get 'IGYPS0225-S An "EXEC SQL" statement was found, but the "SQL" compiler option was not in effect.  The statement was discarded.'
• Interestingly, if you explicitly attempt to "unset" the SQL option (with a PROCESS NOSQL between the two programs), this is also not allowed.  'IGYOS4009-E   An attempt to change the "NOSQL" option during a batch compilation was found.  This option specification was discarded.'

My thoughts as to what needs to be done by IBM to support UDFs are:

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not (and I believe doesn't) pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.
• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

Those are just my thoughts at the moment.

Hi,

We want to use User Defined Functions, using the User Defined Function Prototype.
We have a standardized COBOL compilation procedure that declares the SQL('APOSTSQL ATTACH(TSO) PERIOD VERSION(AUTO)'), even if the COBOL source code does not contain any SQL statement. This may result in a message "IGYSC0209-W DSNH053I DSNHPSRV NO SQL STATEMENTS WERE FOUND".

But more seriously, the User Defined Function fails to compile because there is a Locale-Storage Section in the source code, which is false:

==000027==> IGYDS1563-E "LOCAL-STORAGE SECTION" was found in a prototype "DATA DIVISION".
                        "LOCAL-STORAGE SECTION" and all contained paragraphs were ignored.

Problem found with IBM Enterprise COBOL for z/OS 6.4.0 P240416.

Apparently, it's the SQL compilation option that causes this problem, even in the absence of SQL order.
If we compile in NOSQL, there's no problem.
So we compile the UDFs with NOSQL, but I would like to understand the problem.

Why would using the SQL option implicitly create a Locale-Storage Section?

Thanks.

Hi Franck,

Thank you for this detailed and relevant information, as usual.

In my case, I only have UDF prototypes in my compilation flow, and a UDF prototype contains no code, not even data, but only interface declarations.
The SQL (or CICS) compilation option should have no impact on compilation since no EXEC SQL (EXEC CICS) statements are supposed to be present in the source code of UDF prototypes... and if it might be present (as the syntax diagram of a prototype UDF suggests), it should be ignored since no code is produced by compiling a UDF prototype.

But what concerns me most is the error message that refers to a Locale-Storage Section that is declared nowhere, neither in the code of the UDF prototypes, nor in the code of the main program that references these UDF prototypes.

Besides, in the Data Division of a prototype UDF there cannot be a Working-Storage Section nor a Locale-Storage Section, (but there can be in a non-prototype UDF), the only thing there can be is a Linkage Section.

I think this is a bug in the source code analysis phase of the compiler and I will open a CASE because we are stuck with this issue.

Here's a bit more discussion on SQL and UDFs:

https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/using-user-defined-functions-with-cics-and-sql?communityKey=dc94cb0f-7361-47d9-854f-dfcbdbbf04a3

I have a few additional observations.

• Firstly, I am guessing that the SQL coprocessor knows nothing of prototypes (or functions, for that matter), and thus treats any source element passed to it by the compiler as a program.  Thus it generates the same data division details that it would for any program source passed to it.  It looks like that includes both some working-storage fields and some local-storage fields. 
• Additionally, the SQL coprocessor appears to only be in effect for the first source until passed to it during a compilation of multiple source units.  As an example (even with UDFs out of the picture), if you do a compile with the SQL option set, and your source module contains two COBOL programs (for example, a "main" program and a subprogram which is statically called by the main program), the SQL option is in effect only for the main program.  If you put SQL statements in the "subprogram" you get 'IGYPS0225-S An "EXEC SQL" statement was found, but the "SQL" compiler option was not in effect.  The statement was discarded.'
• Interestingly, if you explicitly attempt to "unset" the SQL option (with a PROCESS NOSQL between the two programs), this is also not allowed.  'IGYOS4009-E   An attempt to change the "NOSQL" option during a batch compilation was found.  This option specification was discarded.'

My thoughts as to what needs to be done by IBM to support UDFs are:

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not (and I believe doesn't) pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.
• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

Those are just my thoughts at the moment.

Hi,

We want to use User Defined Functions, using the User Defined Function Prototype.
We have a standardized COBOL compilation procedure that declares the SQL('APOSTSQL ATTACH(TSO) PERIOD VERSION(AUTO)'), even if the COBOL source code does not contain any SQL statement. This may result in a message "IGYSC0209-W DSNH053I DSNHPSRV NO SQL STATEMENTS WERE FOUND".

But more seriously, the User Defined Function fails to compile because there is a Locale-Storage Section in the source code, which is false:

==000027==> IGYDS1563-E "LOCAL-STORAGE SECTION" was found in a prototype "DATA DIVISION".
                        "LOCAL-STORAGE SECTION" and all contained paragraphs were ignored.

Problem found with IBM Enterprise COBOL for z/OS 6.4.0 P240416.

Apparently, it's the SQL compilation option that causes this problem, even in the absence of SQL order.
If we compile in NOSQL, there's no problem.
So we compile the UDFs with NOSQL, but I would like to understand the problem.

Why would using the SQL option implicitly create a Locale-Storage Section?

Thanks.

Hi Franck,

Thank you for this detailed and relevant information, as usual.

In my case, I only have UDF prototypes in my compilation flow, and a UDF prototype contains no code, not even data, but only interface declarations.
The SQL (or CICS) compilation option should have no impact on compilation since no EXEC SQL (EXEC CICS) statements are supposed to be present in the source code of UDF prototypes... and if it might be present (as the syntax diagram of a prototype UDF suggests), it should be ignored since no code is produced by compiling a UDF prototype.

But what concerns me most is the error message that refers to a Locale-Storage Section that is declared nowhere, neither in the code of the UDF prototypes, nor in the code of the main program that references these UDF prototypes.

Besides, in the Data Division of a prototype UDF there cannot be a Working-Storage Section nor a Locale-Storage Section, (but there can be in a non-prototype UDF), the only thing there can be is a Linkage Section.

I think this is a bug in the source code analysis phase of the compiler and I will open a CASE because we are stuck with this issue.

Here's a bit more discussion on SQL and UDFs:

https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/using-user-defined-functions-with-cics-and-sql?communityKey=dc94cb0f-7361-47d9-854f-dfcbdbbf04a3

I have a few additional observations.

• Firstly, I am guessing that the SQL coprocessor knows nothing of prototypes (or functions, for that matter), and thus treats any source element passed to it by the compiler as a program.  Thus it generates the same data division details that it would for any program source passed to it.  It looks like that includes both some working-storage fields and some local-storage fields. 
• Additionally, the SQL coprocessor appears to only be in effect for the first source until passed to it during a compilation of multiple source units.  As an example (even with UDFs out of the picture), if you do a compile with the SQL option set, and your source module contains two COBOL programs (for example, a "main" program and a subprogram which is statically called by the main program), the SQL option is in effect only for the main program.  If you put SQL statements in the "subprogram" you get 'IGYPS0225-S An "EXEC SQL" statement was found, but the "SQL" compiler option was not in effect.  The statement was discarded.'
• Interestingly, if you explicitly attempt to "unset" the SQL option (with a PROCESS NOSQL between the two programs), this is also not allowed.  'IGYOS4009-E   An attempt to change the "NOSQL" option during a batch compilation was found.  This option specification was discarded.'

My thoughts as to what needs to be done by IBM to support UDFs are:

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not (and I believe doesn't) pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.
• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

Those are just my thoughts at the moment.

Hi,

We want to use User Defined Functions, using the User Defined Function Prototype.
We have a standardized COBOL compilation procedure that declares the SQL('APOSTSQL ATTACH(TSO) PERIOD VERSION(AUTO)'), even if the COBOL source code does not contain any SQL statement. This may result in a message "IGYSC0209-W DSNH053I DSNHPSRV NO SQL STATEMENTS WERE FOUND".

But more seriously, the User Defined Function fails to compile because there is a Locale-Storage Section in the source code, which is false:

==000027==> IGYDS1563-E "LOCAL-STORAGE SECTION" was found in a prototype "DATA DIVISION".
                        "LOCAL-STORAGE SECTION" and all contained paragraphs were ignored.

Problem found with IBM Enterprise COBOL for z/OS 6.4.0 P240416.

Apparently, it's the SQL compilation option that causes this problem, even in the absence of SQL order.
If we compile in NOSQL, there's no problem.
So we compile the UDFs with NOSQL, but I would like to understand the problem.

Why would using the SQL option implicitly create a Locale-Storage Section?

Thanks.

I'm pretty sure I agree with what you are saying. 

Hi Franck,

Thank you for this detailed and relevant information, as usual.

In my case, I only have UDF prototypes in my compilation flow, and a UDF prototype contains no code, not even data, but only interface declarations.
The SQL (or CICS) compilation option should have no impact on compilation since no EXEC SQL (EXEC CICS) statements are supposed to be present in the source code of UDF prototypes... and if it might be present (as the syntax diagram of a prototype UDF suggests), it should be ignored since no code is produced by compiling a UDF prototype.

But what concerns me most is the error message that refers to a Locale-Storage Section that is declared nowhere, neither in the code of the UDF prototypes, nor in the code of the main program that references these UDF prototypes.

Besides, in the Data Division of a prototype UDF there cannot be a Working-Storage Section nor a Locale-Storage Section, (but there can be in a non-prototype UDF), the only thing there can be is a Linkage Section.

I think this is a bug in the source code analysis phase of the compiler and I will open a CASE because we are stuck with this issue.

Here's a bit more discussion on SQL and UDFs:

https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/using-user-defined-functions-with-cics-and-sql?communityKey=dc94cb0f-7361-47d9-854f-dfcbdbbf04a3

I have a few additional observations.

• Firstly, I am guessing that the SQL coprocessor knows nothing of prototypes (or functions, for that matter), and thus treats any source element passed to it by the compiler as a program.  Thus it generates the same data division details that it would for any program source passed to it.  It looks like that includes both some working-storage fields and some local-storage fields. 
• Additionally, the SQL coprocessor appears to only be in effect for the first source until passed to it during a compilation of multiple source units.  As an example (even with UDFs out of the picture), if you do a compile with the SQL option set, and your source module contains two COBOL programs (for example, a "main" program and a subprogram which is statically called by the main program), the SQL option is in effect only for the main program.  If you put SQL statements in the "subprogram" you get 'IGYPS0225-S An "EXEC SQL" statement was found, but the "SQL" compiler option was not in effect.  The statement was discarded.'
• Interestingly, if you explicitly attempt to "unset" the SQL option (with a PROCESS NOSQL between the two programs), this is also not allowed.  'IGYOS4009-E   An attempt to change the "NOSQL" option during a batch compilation was found.  This option specification was discarded.'

My thoughts as to what needs to be done by IBM to support UDFs are:

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not (and I believe doesn't) pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.
• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

Those are just my thoughts at the moment.

Hi,

We want to use User Defined Functions, using the User Defined Function Prototype.
We have a standardized COBOL compilation procedure that declares the SQL('APOSTSQL ATTACH(TSO) PERIOD VERSION(AUTO)'), even if the COBOL source code does not contain any SQL statement. This may result in a message "IGYSC0209-W DSNH053I DSNHPSRV NO SQL STATEMENTS WERE FOUND".

But more seriously, the User Defined Function fails to compile because there is a Locale-Storage Section in the source code, which is false:

==000027==> IGYDS1563-E "LOCAL-STORAGE SECTION" was found in a prototype "DATA DIVISION".
                        "LOCAL-STORAGE SECTION" and all contained paragraphs were ignored.

Problem found with IBM Enterprise COBOL for z/OS 6.4.0 P240416.

Apparently, it's the SQL compilation option that causes this problem, even in the absence of SQL order.
If we compile in NOSQL, there's no problem.
So we compile the UDFs with NOSQL, but I would like to understand the problem.

Why would using the SQL option implicitly create a Locale-Storage Section?

Thanks.

Hi Dennis, Frank,

I do like the three points that Frank brought up on how the behaviour should be.

---

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not (and I believe doesn't) pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.
• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

---

I'll be investigating this one to see what I can do.  At a glance I think implementing "ignore the SQL compiler option" for prototypes is reasonable (i.e. no need to turn the SQL option off).  As for UDFs, I agree there needs to be a way to turn off/turn on the SQL option between source units to make it viable to have a compilation group contain a UDF and another program (or UDF) that uses the SQL option.

I'm pretty sure I agree with what you are saying. 

Hi Franck,

Thank you for this detailed and relevant information, as usual.

In my case, I only have UDF prototypes in my compilation flow, and a UDF prototype contains no code, not even data, but only interface declarations.
The SQL (or CICS) compilation option should have no impact on compilation since no EXEC SQL (EXEC CICS) statements are supposed to be present in the source code of UDF prototypes... and if it might be present (as the syntax diagram of a prototype UDF suggests), it should be ignored since no code is produced by compiling a UDF prototype.

But what concerns me most is the error message that refers to a Locale-Storage Section that is declared nowhere, neither in the code of the UDF prototypes, nor in the code of the main program that references these UDF prototypes.

Besides, in the Data Division of a prototype UDF there cannot be a Working-Storage Section nor a Locale-Storage Section, (but there can be in a non-prototype UDF), the only thing there can be is a Linkage Section.

I think this is a bug in the source code analysis phase of the compiler and I will open a CASE because we are stuck with this issue.

Here's a bit more discussion on SQL and UDFs:

https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/using-user-defined-functions-with-cics-and-sql?communityKey=dc94cb0f-7361-47d9-854f-dfcbdbbf04a3

I have a few additional observations.

• Firstly, I am guessing that the SQL coprocessor knows nothing of prototypes (or functions, for that matter), and thus treats any source element passed to it by the compiler as a program.  Thus it generates the same data division details that it would for any program source passed to it.  It looks like that includes both some working-storage fields and some local-storage fields. 
• Additionally, the SQL coprocessor appears to only be in effect for the first source until passed to it during a compilation of multiple source units.  As an example (even with UDFs out of the picture), if you do a compile with the SQL option set, and your source module contains two COBOL programs (for example, a "main" program and a subprogram which is statically called by the main program), the SQL option is in effect only for the main program.  If you put SQL statements in the "subprogram" you get 'IGYPS0225-S An "EXEC SQL" statement was found, but the "SQL" compiler option was not in effect.  The statement was discarded.'
• Interestingly, if you explicitly attempt to "unset" the SQL option (with a PROCESS NOSQL between the two programs), this is also not allowed.  'IGYOS4009-E   An attempt to change the "NOSQL" option during a batch compilation was found.  This option specification was discarded.'

My thoughts as to what needs to be done by IBM to support UDFs are:

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not (and I believe doesn't) pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.
• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

Those are just my thoughts at the moment.

Hi,

We want to use User Defined Functions, using the User Defined Function Prototype.
We have a standardized COBOL compilation procedure that declares the SQL('APOSTSQL ATTACH(TSO) PERIOD VERSION(AUTO)'), even if the COBOL source code does not contain any SQL statement. This may result in a message "IGYSC0209-W DSNH053I DSNHPSRV NO SQL STATEMENTS WERE FOUND".

But more seriously, the User Defined Function fails to compile because there is a Locale-Storage Section in the source code, which is false:

==000027==> IGYDS1563-E "LOCAL-STORAGE SECTION" was found in a prototype "DATA DIVISION".
                        "LOCAL-STORAGE SECTION" and all contained paragraphs were ignored.

Problem found with IBM Enterprise COBOL for z/OS 6.4.0 P240416.

Apparently, it's the SQL compilation option that causes this problem, even in the absence of SQL order.
If we compile in NOSQL, there's no problem.
So we compile the UDFs with NOSQL, but I would like to understand the problem.

Why would using the SQL option implicitly create a Locale-Storage Section?

Thanks.

Hi Jeffery,

I think implementing "ignore the SQL compiler option" for prototypes is reasonable (i.e. no need to turn the SQL option off)  --> 👍

Thanks.

Hi Dennis, Frank,

I do like the three points that Frank brought up on how the behaviour should be.

---

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not (and I believe doesn't) pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.
• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

---

I'll be investigating this one to see what I can do.  At a glance I think implementing "ignore the SQL compiler option" for prototypes is reasonable (i.e. no need to turn the SQL option off).  As for UDFs, I agree there needs to be a way to turn off/turn on the SQL option between source units to make it viable to have a compilation group contain a UDF and another program (or UDF) that uses the SQL option.

I'm pretty sure I agree with what you are saying. 

Hi Franck,

Thank you for this detailed and relevant information, as usual.

In my case, I only have UDF prototypes in my compilation flow, and a UDF prototype contains no code, not even data, but only interface declarations.
The SQL (or CICS) compilation option should have no impact on compilation since no EXEC SQL (EXEC CICS) statements are supposed to be present in the source code of UDF prototypes... and if it might be present (as the syntax diagram of a prototype UDF suggests), it should be ignored since no code is produced by compiling a UDF prototype.

But what concerns me most is the error message that refers to a Locale-Storage Section that is declared nowhere, neither in the code of the UDF prototypes, nor in the code of the main program that references these UDF prototypes.

Besides, in the Data Division of a prototype UDF there cannot be a Working-Storage Section nor a Locale-Storage Section, (but there can be in a non-prototype UDF), the only thing there can be is a Linkage Section.

I think this is a bug in the source code analysis phase of the compiler and I will open a CASE because we are stuck with this issue.

Here's a bit more discussion on SQL and UDFs:

https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/using-user-defined-functions-with-cics-and-sql?communityKey=dc94cb0f-7361-47d9-854f-dfcbdbbf04a3

I have a few additional observations.

• Firstly, I am guessing that the SQL coprocessor knows nothing of prototypes (or functions, for that matter), and thus treats any source element passed to it by the compiler as a program.  Thus it generates the same data division details that it would for any program source passed to it.  It looks like that includes both some working-storage fields and some local-storage fields. 
• Additionally, the SQL coprocessor appears to only be in effect for the first source until passed to it during a compilation of multiple source units.  As an example (even with UDFs out of the picture), if you do a compile with the SQL option set, and your source module contains two COBOL programs (for example, a "main" program and a subprogram which is statically called by the main program), the SQL option is in effect only for the main program.  If you put SQL statements in the "subprogram" you get 'IGYPS0225-S An "EXEC SQL" statement was found, but the "SQL" compiler option was not in effect.  The statement was discarded.'
• Interestingly, if you explicitly attempt to "unset" the SQL option (with a PROCESS NOSQL between the two programs), this is also not allowed.  'IGYOS4009-E   An attempt to change the "NOSQL" option during a batch compilation was found.  This option specification was discarded.'

My thoughts as to what needs to be done by IBM to support UDFs are:

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not (and I believe doesn't) pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.
• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

Those are just my thoughts at the moment.

Hi,

We want to use User Defined Functions, using the User Defined Function Prototype.
We have a standardized COBOL compilation procedure that declares the SQL('APOSTSQL ATTACH(TSO) PERIOD VERSION(AUTO)'), even if the COBOL source code does not contain any SQL statement. This may result in a message "IGYSC0209-W DSNH053I DSNHPSRV NO SQL STATEMENTS WERE FOUND".

But more seriously, the User Defined Function fails to compile because there is a Locale-Storage Section in the source code, which is false:

==000027==> IGYDS1563-E "LOCAL-STORAGE SECTION" was found in a prototype "DATA DIVISION".
                        "LOCAL-STORAGE SECTION" and all contained paragraphs were ignored.

Problem found with IBM Enterprise COBOL for z/OS 6.4.0 P240416.

Apparently, it's the SQL compilation option that causes this problem, even in the absence of SQL order.
If we compile in NOSQL, there's no problem.
So we compile the UDFs with NOSQL, but I would like to understand the problem.

Why would using the SQL option implicitly create a Locale-Storage Section?

Thanks.