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.

I found this thread after encountering this exact issue with a UDF that I was experimenting with.  I look forward to seeing a solution.

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.

Hi all, I just wanted to post an update on this problem.

Pending further testing, I have a (not yet released) solution for the first two points...

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.

The third point was not feasible (largely due to internal architecture limitations in terms of processing EXEC SQL INCLUDE verses other EXEC SQL statements)

• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

What this means is that users still cannot change the SQL option between two source elements (compilation units).  However, prototypes will be entirely ignored by the SQL option, and the first non-prototype compilation unit (a program, or user-defined function) can then contain EXEC SQL statements.  Subsequent compilation units after that will have the SQL option forcefully turned OFF (similar to existing behavior where the second program in a two program batch compilation has the SQL option forcefully turned OFF).

Hopefully this solution will be sufficient.  Feedback and suggestions are welcome.

I found this thread after encountering this exact issue with a UDF that I was experimenting with.  I look forward to seeing a solution.

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.

Let me summarize what I believe you are saying is possible.

Source modules where the SQL compiler is specified will be able to contain:

• One or more function prototypes.
• The first non-prototype compilation unit can contain EXEC SQL statements.  This can be a "function" compilation unit or a "program" compilation unit.
  • If this is a program compilation unit it main contain nested programs, and EXEC SQL statements may be present within these nested program.
• Additional compilation units can follow, but none of them may contain EXEC SQL statements.

Additionally, the SQL compiler option can be specified by either:

• Placing it on the PARM parameter of the EXEC JCL statement (or corresponding PARMDD).
• Placing it in a COBOL PROCESS/CBL statement that is before any non-PROCESS/CBL statement.

Basically, the only change from existing behavior is that prototype compilation units can be present within.

So I will say that this likely satisfies the use cases that likely exist for your average COBOL programmer.  While there are what I would call "limitations", they are limitations that already exist.

I have to also say that it is disappointing that this existing limitation cannot (easily) be lifted.  I recently wrote a COBOL "subroutine" that is made up of many program and function compilation units within a single source module (and thus a single compilation unit).  Basically, I wrote COBOL "callable program" as one might write one in C or pretty much any other language.  It works because it contains no EXEC SQL statements (nor any EXEC CICS statements, though I believe it could have).

Obviously this could have been coded with each compilation units as a single compilation group (well, including function prototypes as needed), but the functions (and "sub-programs" that I  included within the one compilation group were all "business logic" compilation units, which would never be invoked by any other compilation groups.  So have each one in its own compilation group doesn't really "make sense."

But in the end, I wouldn't anticipate many other programmers coding programs in this way, as useful and sensible as I might think it would be.

Hi all, I just wanted to post an update on this problem.

Pending further testing, I have a (not yet released) solution for the first two points...

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.

The third point was not feasible (largely due to internal architecture limitations in terms of processing EXEC SQL INCLUDE verses other EXEC SQL statements)

• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

What this means is that users still cannot change the SQL option between two source elements (compilation units).  However, prototypes will be entirely ignored by the SQL option, and the first non-prototype compilation unit (a program, or user-defined function) can then contain EXEC SQL statements.  Subsequent compilation units after that will have the SQL option forcefully turned OFF (similar to existing behavior where the second program in a two program batch compilation has the SQL option forcefully turned OFF).

Hopefully this solution will be sufficient.  Feedback and suggestions are welcome.

I found this thread after encountering this exact issue with a UDF that I was experimenting with.  I look forward to seeing a solution.

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.

Hi Frank - yes your summary is correct.

I'd just like to add a few more notes.

1. This fix also applies in the same manner to the SQLIMS option and IMS coprocessor.

2. This fix does not apply to the CICS coprocessor (unfortunately the processing for the CICS option is not the same as SQL/SQLIMS) but I am working on that.

3. I can't predict if or when we can work on it, but I'm going to keep an internal issue open for lifting the limitation.

Let me summarize what I believe you are saying is possible.

Source modules where the SQL compiler is specified will be able to contain:

• One or more function prototypes.
• The first non-prototype compilation unit can contain EXEC SQL statements.  This can be a "function" compilation unit or a "program" compilation unit.
  • If this is a program compilation unit it main contain nested programs, and EXEC SQL statements may be present within these nested program.
• Additional compilation units can follow, but none of them may contain EXEC SQL statements.

Additionally, the SQL compiler option can be specified by either:

• Placing it on the PARM parameter of the EXEC JCL statement (or corresponding PARMDD).
• Placing it in a COBOL PROCESS/CBL statement that is before any non-PROCESS/CBL statement.

Basically, the only change from existing behavior is that prototype compilation units can be present within.

So I will say that this likely satisfies the use cases that likely exist for your average COBOL programmer.  While there are what I would call "limitations", they are limitations that already exist.

I have to also say that it is disappointing that this existing limitation cannot (easily) be lifted.  I recently wrote a COBOL "subroutine" that is made up of many program and function compilation units within a single source module (and thus a single compilation unit).  Basically, I wrote COBOL "callable program" as one might write one in C or pretty much any other language.  It works because it contains no EXEC SQL statements (nor any EXEC CICS statements, though I believe it could have).

Obviously this could have been coded with each compilation units as a single compilation group (well, including function prototypes as needed), but the functions (and "sub-programs" that I  included within the one compilation group were all "business logic" compilation units, which would never be invoked by any other compilation groups.  So have each one in its own compilation group doesn't really "make sense."

But in the end, I wouldn't anticipate many other programmers coding programs in this way, as useful and sensible as I might think it would be.

Hi all, I just wanted to post an update on this problem.

Pending further testing, I have a (not yet released) solution for the first two points...

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.

The third point was not feasible (largely due to internal architecture limitations in terms of processing EXEC SQL INCLUDE verses other EXEC SQL statements)

• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

What this means is that users still cannot change the SQL option between two source elements (compilation units).  However, prototypes will be entirely ignored by the SQL option, and the first non-prototype compilation unit (a program, or user-defined function) can then contain EXEC SQL statements.  Subsequent compilation units after that will have the SQL option forcefully turned OFF (similar to existing behavior where the second program in a two program batch compilation has the SQL option forcefully turned OFF).

Hopefully this solution will be sufficient.  Feedback and suggestions are welcome.

I found this thread after encountering this exact issue with a UDF that I was experimenting with.  I look forward to seeing a solution.

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.

Your bullet point 2 is...interesting.  I would think it would be preferable that the SQL and SQLIMS options be more like the CICS option, not vice versa, because the CICS option appears to me to work as I'd like it to.  That is, you can (and I'm doing this from memory, now) I believe:

1. Turn the CICS option on and off multiple times using PROCESS CICS and PROCESS NOCICS statements.
2. Include prototype compilation units in a compilation group, as long as the NOCICS option is active at the time the prototype is compiled.
3. Within a compilation group you can have multiple program and/or function compilation units that contain EXEC CICS statements, as long as the CICS option is active at the time that program/function is compiled.

Ideally SQL and SQLIMS could work this way as well, but it sounds like this is not in the cards.

Hi Frank - yes your summary is correct.

I'd just like to add a few more notes.

1. This fix also applies in the same manner to the SQLIMS option and IMS coprocessor.

2. This fix does not apply to the CICS coprocessor (unfortunately the processing for the CICS option is not the same as SQL/SQLIMS) but I am working on that.

3. I can't predict if or when we can work on it, but I'm going to keep an internal issue open for lifting the limitation.

Let me summarize what I believe you are saying is possible.

Source modules where the SQL compiler is specified will be able to contain:

• One or more function prototypes.
• The first non-prototype compilation unit can contain EXEC SQL statements.  This can be a "function" compilation unit or a "program" compilation unit.
  • If this is a program compilation unit it main contain nested programs, and EXEC SQL statements may be present within these nested program.
• Additional compilation units can follow, but none of them may contain EXEC SQL statements.

Additionally, the SQL compiler option can be specified by either:

• Placing it on the PARM parameter of the EXEC JCL statement (or corresponding PARMDD).
• Placing it in a COBOL PROCESS/CBL statement that is before any non-PROCESS/CBL statement.

Basically, the only change from existing behavior is that prototype compilation units can be present within.

So I will say that this likely satisfies the use cases that likely exist for your average COBOL programmer.  While there are what I would call "limitations", they are limitations that already exist.

I have to also say that it is disappointing that this existing limitation cannot (easily) be lifted.  I recently wrote a COBOL "subroutine" that is made up of many program and function compilation units within a single source module (and thus a single compilation unit).  Basically, I wrote COBOL "callable program" as one might write one in C or pretty much any other language.  It works because it contains no EXEC SQL statements (nor any EXEC CICS statements, though I believe it could have).

Obviously this could have been coded with each compilation units as a single compilation group (well, including function prototypes as needed), but the functions (and "sub-programs" that I  included within the one compilation group were all "business logic" compilation units, which would never be invoked by any other compilation groups.  So have each one in its own compilation group doesn't really "make sense."

But in the end, I wouldn't anticipate many other programmers coding programs in this way, as useful and sensible as I might think it would be.

Hi all, I just wanted to post an update on this problem.

Pending further testing, I have a (not yet released) solution for the first two points...

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.

The third point was not feasible (largely due to internal architecture limitations in terms of processing EXEC SQL INCLUDE verses other EXEC SQL statements)

• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

What this means is that users still cannot change the SQL option between two source elements (compilation units).  However, prototypes will be entirely ignored by the SQL option, and the first non-prototype compilation unit (a program, or user-defined function) can then contain EXEC SQL statements.  Subsequent compilation units after that will have the SQL option forcefully turned OFF (similar to existing behavior where the second program in a two program batch compilation has the SQL option forcefully turned OFF).

Hopefully this solution will be sufficient.  Feedback and suggestions are welcome.

I found this thread after encountering this exact issue with a UDF that I was experimenting with.  I look forward to seeing a solution.

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.

We have an (internal) open issue from one of our clients using the CICS option with multiple UDFs - though I admittedly haven't investigated the root cause of it yet.  My assumption was that it was similar-ish to this SQL problem - but I might be (and probably am) wrong!  Glad to hear it is working the way you expect.

Your bullet point 2 is...interesting.  I would think it would be preferable that the SQL and SQLIMS options be more like the CICS option, not vice versa, because the CICS option appears to me to work as I'd like it to.  That is, you can (and I'm doing this from memory, now) I believe:

1. Turn the CICS option on and off multiple times using PROCESS CICS and PROCESS NOCICS statements.
2. Include prototype compilation units in a compilation group, as long as the NOCICS option is active at the time the prototype is compiled.
3. Within a compilation group you can have multiple program and/or function compilation units that contain EXEC CICS statements, as long as the CICS option is active at the time that program/function is compiled.

Ideally SQL and SQLIMS could work this way as well, but it sounds like this is not in the cards.

Hi Frank - yes your summary is correct.

I'd just like to add a few more notes.

1. This fix also applies in the same manner to the SQLIMS option and IMS coprocessor.

2. This fix does not apply to the CICS coprocessor (unfortunately the processing for the CICS option is not the same as SQL/SQLIMS) but I am working on that.

3. I can't predict if or when we can work on it, but I'm going to keep an internal issue open for lifting the limitation.

Let me summarize what I believe you are saying is possible.

Source modules where the SQL compiler is specified will be able to contain:

• One or more function prototypes.
• The first non-prototype compilation unit can contain EXEC SQL statements.  This can be a "function" compilation unit or a "program" compilation unit.
  • If this is a program compilation unit it main contain nested programs, and EXEC SQL statements may be present within these nested program.
• Additional compilation units can follow, but none of them may contain EXEC SQL statements.

Additionally, the SQL compiler option can be specified by either:

• Placing it on the PARM parameter of the EXEC JCL statement (or corresponding PARMDD).
• Placing it in a COBOL PROCESS/CBL statement that is before any non-PROCESS/CBL statement.

Basically, the only change from existing behavior is that prototype compilation units can be present within.

So I will say that this likely satisfies the use cases that likely exist for your average COBOL programmer.  While there are what I would call "limitations", they are limitations that already exist.

I have to also say that it is disappointing that this existing limitation cannot (easily) be lifted.  I recently wrote a COBOL "subroutine" that is made up of many program and function compilation units within a single source module (and thus a single compilation unit).  Basically, I wrote COBOL "callable program" as one might write one in C or pretty much any other language.  It works because it contains no EXEC SQL statements (nor any EXEC CICS statements, though I believe it could have).

Obviously this could have been coded with each compilation units as a single compilation group (well, including function prototypes as needed), but the functions (and "sub-programs" that I  included within the one compilation group were all "business logic" compilation units, which would never be invoked by any other compilation groups.  So have each one in its own compilation group doesn't really "make sense."

But in the end, I wouldn't anticipate many other programmers coding programs in this way, as useful and sensible as I might think it would be.

Hi all, I just wanted to post an update on this problem.

Pending further testing, I have a (not yet released) solution for the first two points...

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.

The third point was not feasible (largely due to internal architecture limitations in terms of processing EXEC SQL INCLUDE verses other EXEC SQL statements)

• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

What this means is that users still cannot change the SQL option between two source elements (compilation units).  However, prototypes will be entirely ignored by the SQL option, and the first non-prototype compilation unit (a program, or user-defined function) can then contain EXEC SQL statements.  Subsequent compilation units after that will have the SQL option forcefully turned OFF (similar to existing behavior where the second program in a two program batch compilation has the SQL option forcefully turned OFF).

Hopefully this solution will be sufficient.  Feedback and suggestions are welcome.

I found this thread after encountering this exact issue with a UDF that I was experimenting with.  I look forward to seeing a solution.

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.

So, here's a little something we just ran in to today.

First, we were successful having (multiple) function prototype compilation units along with a single program compilation unit, all within the same compilation group.  As mentioned before, the requirement is that the NOCICS be active when the prototypes are compiled, and then a PROCESS CICS statement be placed after the prototype units and before the program unit.  This compiles and executes as desired.

However, when we attempt to execute it with the z/OS Debugger active for that program, the debugger appears unable to find the stored source code.  Specifically, when the debugger (the TCP/GUI debugger in this case, though the same issue seems to exist as well when using the CICS full-screen 3270 session type) issues something like "CRRDG3011E Source file xxx was not found.", where 'xxx' is the dataset and member name that the program was compiled as.

Interestingly, IBM Fault Analyzer appears to successfully locate the source code under the same circumstances.

All of this is using the following options:  TEST(NOEJPD,DWARF,SOURCE,NOSEPARATE).

This issue does not occur if NOCICS is set for all compilation units, and no EXEC CICS commands are present in the program.

We have an (internal) open issue from one of our clients using the CICS option with multiple UDFs - though I admittedly haven't investigated the root cause of it yet.  My assumption was that it was similar-ish to this SQL problem - but I might be (and probably am) wrong!  Glad to hear it is working the way you expect.

Your bullet point 2 is...interesting.  I would think it would be preferable that the SQL and SQLIMS options be more like the CICS option, not vice versa, because the CICS option appears to me to work as I'd like it to.  That is, you can (and I'm doing this from memory, now) I believe:

1. Turn the CICS option on and off multiple times using PROCESS CICS and PROCESS NOCICS statements.
2. Include prototype compilation units in a compilation group, as long as the NOCICS option is active at the time the prototype is compiled.
3. Within a compilation group you can have multiple program and/or function compilation units that contain EXEC CICS statements, as long as the CICS option is active at the time that program/function is compiled.

Ideally SQL and SQLIMS could work this way as well, but it sounds like this is not in the cards.

Hi Frank - yes your summary is correct.

I'd just like to add a few more notes.

1. This fix also applies in the same manner to the SQLIMS option and IMS coprocessor.

2. This fix does not apply to the CICS coprocessor (unfortunately the processing for the CICS option is not the same as SQL/SQLIMS) but I am working on that.

3. I can't predict if or when we can work on it, but I'm going to keep an internal issue open for lifting the limitation.

Let me summarize what I believe you are saying is possible.

Source modules where the SQL compiler is specified will be able to contain:

• One or more function prototypes.
• The first non-prototype compilation unit can contain EXEC SQL statements.  This can be a "function" compilation unit or a "program" compilation unit.
  • If this is a program compilation unit it main contain nested programs, and EXEC SQL statements may be present within these nested program.
• Additional compilation units can follow, but none of them may contain EXEC SQL statements.

Additionally, the SQL compiler option can be specified by either:

• Placing it on the PARM parameter of the EXEC JCL statement (or corresponding PARMDD).
• Placing it in a COBOL PROCESS/CBL statement that is before any non-PROCESS/CBL statement.

Basically, the only change from existing behavior is that prototype compilation units can be present within.

So I will say that this likely satisfies the use cases that likely exist for your average COBOL programmer.  While there are what I would call "limitations", they are limitations that already exist.

I have to also say that it is disappointing that this existing limitation cannot (easily) be lifted.  I recently wrote a COBOL "subroutine" that is made up of many program and function compilation units within a single source module (and thus a single compilation unit).  Basically, I wrote COBOL "callable program" as one might write one in C or pretty much any other language.  It works because it contains no EXEC SQL statements (nor any EXEC CICS statements, though I believe it could have).

Obviously this could have been coded with each compilation units as a single compilation group (well, including function prototypes as needed), but the functions (and "sub-programs" that I  included within the one compilation group were all "business logic" compilation units, which would never be invoked by any other compilation groups.  So have each one in its own compilation group doesn't really "make sense."

But in the end, I wouldn't anticipate many other programmers coding programs in this way, as useful and sensible as I might think it would be.

Hi all, I just wanted to post an update on this problem.

Pending further testing, I have a (not yet released) solution for the first two points...

• The compiler should not pass prototype source elements to the SQL coprocessor, even if the SQL option is set.
• The compiler should not pass to the SQL coprocessor any source elements where the NOSQL compiler option is set.

The third point was not feasible (largely due to internal architecture limitations in terms of processing EXEC SQL INCLUDE verses other EXEC SQL statements)

• The compiler should allow the SQL/NOSQL option to be changed (using a PROCESS card) between source elements in a single batch compilation.

What this means is that users still cannot change the SQL option between two source elements (compilation units).  However, prototypes will be entirely ignored by the SQL option, and the first non-prototype compilation unit (a program, or user-defined function) can then contain EXEC SQL statements.  Subsequent compilation units after that will have the SQL option forcefully turned OFF (similar to existing behavior where the second program in a two program batch compilation has the SQL option forcefully turned OFF).

Hopefully this solution will be sufficient.  Feedback and suggestions are welcome.

I found this thread after encountering this exact issue with a UDF that I was experimenting with.  I look forward to seeing a solution.

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.