Re: PIC Z is for zero suppression was Re: A slight regression
On Thu, Jun 1, 2017 at 12:04 AM, Peter Hunkeler wrote: > > > > What is special about COBOL's standard: Truncation also silently occurs > with computational fields. > > @John: > There's the DIAGTRUNC compiler option which causes truncation to be > flagged. > Only applies to MOVE statements with _numeric receivers_ per https://www.ibm.com/support/knowledgecenter/SS6SG3_6.1.0/com.ibm.cobol61.ent.doc/custom/igycch220.html Causes the compiler to issue a severity-4 (warning) diagnostic message for MOVE statements with numeric receivers when the receiving data item has fewer integer positions than the sending data item or literal. > > -- > Peter Hunkeler > > -- Windows. A funny name for a operating system that doesn't let you see anything. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: PIC Z is for zero suppression was Re: A slight regression
>I agree that is a likely to astonish but it is standard COBOL, no? No >different than if you did MOVE 'GOODBYE' TO SOME-VAR. You'd end up with less >than you might have expected. This is standard behaviour in PL/1 as well, if not explicitly caught with STRSIZE. And it is standard assembler behaviour as well. The target field determines the length of an MVC. What is special about COBOL's standard: Truncation also silently occurs with computational fields. @John: There's the DIAGTRUNC compiler option which causes truncation to be flagged. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PIC Z is for zero suppression was Re: A slight regression
On Wed, May 31, 2017 at 4:43 PM, Charles Mills wrote: > I agree that is a likely to astonish but it is standard COBOL, no? No > different than if you did MOVE 'GOODBYE' TO SOME-VAR. You'd end up with > less than you might have expected. > Yes, it is standard. In fact, I wish the compiler would flag the MOVE with at least a (suppressible?) warning level message. The main reason that I consider it worse than usual is the fact that the ending x'00' is not explicit in the constant. So a COBOL programmer who is not used to this "new" facility is not as likely to see a problem. Also, s?he is likely to count the number of characters in the string and compare it directly with the value in the PIC. I'm more worried about a programmer who sees something like: 77 SOME-VAR PIC X(6). 77 VAR-LENGTH PIC S9(9) BINARY. MOVE Z'HOUSE' TO SOME-VAR. CALL 'strlen' USING SOME-VAR RETURNING VAR-LENGTH. Who says to themselves: "I need to make that plural. Well, HOUSES is 6 characters. That will fit in the existing allocation, so I'm good". (i.e. ignorant or in a hurry) The original program gets back a 5. After the change to HOUSES, the program gets back a number equal or greater than 6, depending on what comes after in memory. The COBOL program now has insane data. Also, it might be that the C routine does something which could possibly get an S0C4 abend as it "goes wild". Heck, even strlen() might get an S0C4 as it runs amok. I may be a bit disparaging of COBOL programmers, but I've seen some really bad COBOL code. A good IDE would be helpful. That is NOT the editor in ISPF! Perhaps what I'm getting at is that mixing COBOL and C is more dangerous than just plain COBOL. Of course, I'm well aware of the "dangers" of index out of bound or a bad reference modification. Maybe I'm just "death" on "buffer overflows" after reading how they are often used in malware. I _love_ PL/I! > > Charles > > > -- Windows. A funny name for a operating system that doesn't let you see anything. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PIC Z is for zero suppression was Re: A slight regression
I agree that is a likely to astonish but it is standard COBOL, no? No different than if you did MOVE 'GOODBYE' TO SOME-VAR. You'd end up with less than you might have expected. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Wednesday, May 31, 2017 11:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PIC Z is for zero suppression was Re: A slight regression On Wed, May 31, 2017 at 12:41 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Apologies, the Z literal constant was indeed what I mis-remembered as > a PICTURE type. The Z picture type is for zero-suppression of a > numeric field and has no relation to the Z literal constant. > > Sorry for my confusion. > > Peter > It's easy to do. And I'm waiting for some COBOL programmer to ask why the following doesn't work: 77 SOME-VAR PIC X(5). MOVE Z'HELLO' TO SOME-VAR. In COBOL 4.2, there is no error. Not even a warning (unless I've missed a compile option). But the trailing x'00' is quietly truncated. And so if the variable is passed to a C routine as a "char *", you are in a world of hurt. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PIC Z is for zero suppression was Re: A slight regression
On Wed, May 31, 2017 at 12:41 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Apologies, the Z literal constant was indeed what I mis-remembered as a > PICTURE type. The Z picture type is for zero-suppression of a numeric > field and has no relation to the Z literal constant. > > Sorry for my confusion. > > Peter > It's easy to do. And I'm waiting for some COBOL programmer to ask why the following doesn't work: 77 SOME-VAR PIC X(5). MOVE Z'HELLO' TO SOME-VAR. In COBOL 4.2, there is no error. Not even a warning (unless I've missed a compile option). But the trailing x'00' is quietly truncated. And so if the variable is passed to a C routine as a "char *", you are in a world of hurt. -- Windows. A funny name for a operating system that doesn't let you see anything. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PIC Z is for zero suppression was Re: A slight regression
Apologies, the Z literal constant was indeed what I mis-remembered as a PICTURE type. The Z picture type is for zero-suppression of a numeric field and has no relation to the Z literal constant. Sorry for my confusion. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Alan Young Sent: Wednesday, May 31, 2017 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PIC Z is for zero suppression was Re: A slight regression Clark Morris wrote: > [Default] On 30 May 2017 12:35:46 -0700, in bit.listserv.ibm-main > peter.far...@broadridge.com (Farley, Peter x23353) wrote: >> >> COBOL does have PICTURE usage type "Z" for zero-terminated strings, so you >> don't have to use the STRING verb to construct constant strings with a >> zero-byte terminator to call C modules. I haven't experimented with moving >> "normal" COBOL strings (PIC X) to a PIC Z variable, so I do not know if that >> would work properly. >> > Picture type Z is for zero suppression so in a PIC Z, if 0 is > moved to it the result is 5 blanks, if 01234 is moved the result is > blank1234 and if 12345 is moved the result is 12345. I don't know oof > anyway to specify a zero terminated field. I believe the reference is to the Z literal constant specification. I think it may be an IBM extension. MOVE Z'NULL TERMED STRING' TO WS-STRING Moves "NULL TERMED STRING*" (where * is a x'00' byte) to WS-STRING. 05 ANOTHER-NULL-TERM-STRING PIC X(05) VALUE Z'NULL'. Sets the storage to "NULL*'. Alan -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A slight regression
On 31/05/2017 11:03 PM, Tony Harminc wrote: On 30 May 2017 at 20:48, David Crayford wrote: If you download IBMs beta nodejs port you will get a free C compiler and runtime 🙂 I noticed that. I'm probably missing a big chunk here, but why does a Node.js implementation require its own (or any) C compiler? Because the package manager npm can compile C/C++ programs when installing package sand heaps of node modules are written in C/C++. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PIC Z is for zero suppression was Re: A slight regression
If I understood what you were saying correctly, one specifies a
field at the end of the string and moves LOW-VALUES to it. This
effectively sets that byte to X'00' which is the "zero" I think
you are looking for.
Or one defines a byte containing LOW-VALUE and then STRINGs it to
the end of string of data.
HTHs
Steve Thompson
On 05/31/2017 09:23 AM, Clark Morris wrote:
[Default] On 30 May 2017 12:35:46 -0700, in bit.listserv.ibm-main
peter.far...@broadridge.com (Farley, Peter x23353) wrote:
Scott,
That exchange between John and I (around April 7) was about calling C library
functions directly from COBOL. It works if you use a static call (COBOL
literal for the entry point name in UPPER CASE, NODYNAM COBOL compiler option)
because the C library function load modules (in CEE.SCEELKED) have an external
reference to the LE initialization subroutine CEESG003 which will do C language
startup initialization in the enclave. A dynamic COBOL CALL to a C library
function (variable name in the CALL or DYNAM COBOL compiler option) will not
work unless you manually use an INCLUDE SYSLIB(CEESG003) link edit control card
for your link step to get the C language initialization performed, and include
CEE.SCEELKED in the link edit SYSLIB DD.
Your code example below should "just work" in terms of getting the C language initialization done
because your C subroutine will have an external reference to CEESG003, but passing strings and integers is
trickier, because the C language uses (mostly) "pass by VALUE" instead of the COBOL default of
"pass by REFERENCE (i.e., pointers)". You have to carefully use the BY REFERENCE and BY VALUE
attributes for the COBOL USING variables. Integers (and probably floats/doubles as well) must be BY VALUE.
Any structures or arrays (including strings!) or function pointers must be BY REFERENCE.
COBOL does have PICTURE usage type "Z" for zero-terminated strings, so you don't have to
use the STRING verb to construct constant strings with a zero-byte terminator to call C modules. I
haven't experimented with moving "normal" COBOL strings (PIC X) to a PIC Z variable, so I
do not know if that would work properly.
Picture type Z is for zero suppression so in a PIC Z, if 0 is
moved to it the result is 5 blanks, if 01234 is moved the result is
blank1234 and if 12345 is moved the result is 12345. I don't know oof
anyway to specify a zero terminated field.
Clark Morris
HTH
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of scott Ford
Sent: Tuesday, May 30, 2017 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A slight regression
John,
I didnt realize you could call C library functions directly, very cool , here
is what i would like to do:
FILE SECTION.
WORKING-STORAGE SECTION.
77 TESTSTR PIC X(30) VALUE SPACES.
77 VAR1 PIC S9(9) BINARY VALUE 5.
PROCEDURE DIVISION.
-MAIN.
* MOVE 1 TO P1.
* DISPLAY 'P1: ' P1
* CALL 'CFUNC' USING P1 RETURNING P2
* DISPLAY 'P1: ' P1
* DISPLAY 'P2: ' P2
STRING 'TEST STRING' ,
LOW-VALUE
DELIMITED BY SIZE INTO TESTSTR
DISPLAY 'CALL CENTRY USING: ' TESTSTR
CALL 'CENTRY' USING TESTSTR.
GOBACK.
#include
#include
#include
void CENTRY(char* mystring)
{
printf("my string: %s \n",mystring);
}
I am trying to understand how to perform the call and pass a string and or a
integer ...
Thanks John..
Regards.
Scott
On Tue, May 30, 2017 at 2:19 PM, John McKown
wrote:
On Tue, May 30, 2017 at 1:07 PM, scott Ford wrote:
All:
I saw a thread between Peter Fairley and John in April, this year
speaking
about a cobol program calling C ..I am in the same board but did not
see the C code. Can some one help me out and point me to the C
routine or function ?
?Minor example at:
https://gist.github.com/JohnArchieMckown/5b973d46108bd24e0c6f9233c9617
6b0
Calls the C subroutines: cuserid(), strlen(). and sscanf(). I don't
have a C compiler, so I don't have an example of any "user written" C code.
Thanks and I appreciate it
--
*IDMWORKS *
Scott Ford
z/OS Dev.
--
Windows. A funny name for a operating system that doesn't let you see
anything.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PIC Z is for zero suppression was Re: A slight regression
Clark Morris wrote: [Default] On 30 May 2017 12:35:46 -0700, in bit.listserv.ibm-main peter.far...@broadridge.com (Farley, Peter x23353) wrote: COBOL does have PICTURE usage type "Z" for zero-terminated strings, so you don't have to use the STRING verb to construct constant strings with a zero-byte terminator to call C modules. I haven't experimented with moving "normal" COBOL strings (PIC X) to a PIC Z variable, so I do not know if that would work properly. Picture type Z is for zero suppression so in a PIC Z, if 0 is moved to it the result is 5 blanks, if 01234 is moved the result is blank1234 and if 12345 is moved the result is 12345. I don't know oof anyway to specify a zero terminated field. I believe the reference is to the Z literal constant specification. I think it may be an IBM extension. MOVE Z'NULL TERMED STRING' TO WS-STRING Moves "NULL TERMED STRING*" (where * is a x'00' byte) to WS-STRING. 05 ANOTHER-NULL-TERM-STRING PIC X(05) VALUE Z'NULL'. Sets the storage to "NULL*'. Alan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A slight regression
On 30 May 2017 at 20:48, David Crayford wrote: > If you download IBMs beta nodejs port you will get a free C compiler and > runtime 🙂 I noticed that. I'm probably missing a big chunk here, but why does a Node.js implementation require its own (or any) C compiler? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PIC Z is for zero suppression was Re: A slight regression
[Default] On 30 May 2017 12:35:46 -0700, in bit.listserv.ibm-main
peter.far...@broadridge.com (Farley, Peter x23353) wrote:
>Scott,
>
>That exchange between John and I (around April 7) was about calling C library
>functions directly from COBOL. It works if you use a static call (COBOL
>literal for the entry point name in UPPER CASE, NODYNAM COBOL compiler option)
>because the C library function load modules (in CEE.SCEELKED) have an external
>reference to the LE initialization subroutine CEESG003 which will do C
>language startup initialization in the enclave. A dynamic COBOL CALL to a C
>library function (variable name in the CALL or DYNAM COBOL compiler option)
>will not work unless you manually use an INCLUDE SYSLIB(CEESG003) link edit
>control card for your link step to get the C language initialization
>performed, and include CEE.SCEELKED in the link edit SYSLIB DD.
>
>Your code example below should "just work" in terms of getting the C language
>initialization done because your C subroutine will have an external reference
>to CEESG003, but passing strings and integers is trickier, because the C
>language uses (mostly) "pass by VALUE" instead of the COBOL default of "pass
>by REFERENCE (i.e., pointers)". You have to carefully use the BY REFERENCE
>and BY VALUE attributes for the COBOL USING variables. Integers (and probably
>floats/doubles as well) must be BY VALUE. Any structures or arrays (including
>strings!) or function pointers must be BY REFERENCE.
>
>COBOL does have PICTURE usage type "Z" for zero-terminated strings, so you
>don't have to use the STRING verb to construct constant strings with a
>zero-byte terminator to call C modules. I haven't experimented with moving
>"normal" COBOL strings (PIC X) to a PIC Z variable, so I do not know if that
>would work properly.
Picture type Z is for zero suppression so in a PIC Z, if 0 is
moved to it the result is 5 blanks, if 01234 is moved the result is
blank1234 and if 12345 is moved the result is 12345. I don't know oof
anyway to specify a zero terminated field.
Clark Morris
>
>HTH
>
>Peter
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of scott Ford
>Sent: Tuesday, May 30, 2017 2:27 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: A slight regression
>
>John,
>
>I didnt realize you could call C library functions directly, very cool , here
>is what i would like to do:
>
> FILE SECTION.
> WORKING-STORAGE SECTION.
> 77 TESTSTR PIC X(30) VALUE SPACES.
> 77 VAR1 PIC S9(9) BINARY VALUE 5.
> PROCEDURE DIVISION.
> -MAIN.
> * MOVE 1 TO P1.
> * DISPLAY 'P1: ' P1
> * CALL 'CFUNC' USING P1 RETURNING P2
> * DISPLAY 'P1: ' P1
> * DISPLAY 'P2: ' P2
>STRING 'TEST STRING' ,
> LOW-VALUE
>DELIMITED BY SIZE INTO TESTSTR
>DISPLAY 'CALL CENTRY USING: ' TESTSTR
>CALL 'CENTRY' USING TESTSTR.
>GOBACK.
>
>
>
>#include
>#include
>#include
>void CENTRY(char* mystring)
>{
> printf("my string: %s \n",mystring);
>}
>
>I am trying to understand how to perform the call and pass a string and or a
>integer ...
>
>Thanks John..
>
>Regards.
>Scott
>
>On Tue, May 30, 2017 at 2:19 PM, John McKown
>wrote:
>
>> On Tue, May 30, 2017 at 1:07 PM, scott Ford wrote:
>>
>> > All:
>> >
>> > I saw a thread between Peter Fairley and John in April, this year
>> speaking
>> > about a cobol program calling C ..I am in the same board but did not
>> > see the C code. Can some one help me out and point me to the C
>> > routine or function ?
>> >
>>
>> ?Minor example at:
>> https://gist.github.com/JohnArchieMckown/5b973d46108bd24e0c6f9233c9617
>> 6b0
>>
>> Calls the C subroutines: cuserid(), strlen(). and sscanf(). I don't
>> have a C compiler, so I don't have an example of any "user written" C code.
>>
>>
>>
>> >
>> > Thanks and I appreciate it
>> >
>> > --
>> >
>> > *IDMWORKS *
>> >
>> > Scott Ford
>> >
>> > z/OS Dev.
>> >
>>
>>
>> --
>> Windows. A funny name for a operating system that doesn't let you see
>> anything.
>>
>> Maranatha! <><
>> John McKown
>>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A slight regression
On Tue, May 30, 2017 at 7:48 PM, David Crayford wrote: > > > > If you download IBMs beta nodejs port you will get a free C compiler and > runtime 🙂 > The beta nodejs port requires z/OS 2.2 or above. I'm stuck on z/OS 1.12. -- Windows. A funny name for a operating system that doesn't let you see anything. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A slight regression
> On 31 May 2017, at 2:19 am, John McKown wrote: > >> On Tue, May 30, 2017 at 1:07 PM, scott Ford wrote: >> >> All: >> >> I saw a thread between Peter Fairley and John in April, this year speaking >> about a cobol program calling C ..I am in the same board but did not see >> the C code. Can some one help me out and point me to the C routine or >> function ? >> > > Minor example at: > https://gist.github.com/JohnArchieMckown/5b973d46108bd24e0c6f9233c96176b0 > > Calls the C subroutines: cuserid(), strlen(). and sscanf(). I don't have a > C compiler, so I don't have an example of any "user written" C code. > If you download IBMs beta nodejs port you will get a free C compiler and runtime 🙂 > > >> >> Thanks and I appreciate it >> >> -- >> >> *IDMWORKS * >> >> Scott Ford >> >> z/OS Dev. >> > > > -- > Windows. A funny name for a operating system that doesn't let you see > anything. > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A slight regression
Peter/John:
Thanks for the help I got my Cobol call to C working fine...This made my
day guys.
Much appreciated.
Regards,
Scott
On Tue, May 30, 2017 at 2:51 PM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:
> Scott,
>
> That exchange between John and I (around April 7) was about calling C
> library functions directly from COBOL. It works if you use a static call
> (COBOL literal for the entry point name in UPPER CASE, NODYNAM COBOL
> compiler option) because the C library function load modules (in
> CEE.SCEELKED) have an external reference to the LE initialization
> subroutine CEESG003 which will do C language startup initialization in the
> enclave. A dynamic COBOL CALL to a C library function (variable name in
> the CALL or DYNAM COBOL compiler option) will not work unless you manually
> use an INCLUDE SYSLIB(CEESG003) link edit control card for your link step
> to get the C language initialization performed, and include CEE.SCEELKED in
> the link edit SYSLIB DD.
>
> Your code example below should "just work" in terms of getting the C
> language initialization done because your C subroutine will have an
> external reference to CEESG003, but passing strings and integers is
> trickier, because the C language uses (mostly) "pass by VALUE" instead of
> the COBOL default of "pass by REFERENCE (i.e., pointers)". You have to
> carefully use the BY REFERENCE and BY VALUE attributes for the COBOL USING
> variables. Integers (and probably floats/doubles as well) must be BY
> VALUE. Any structures or arrays (including strings!) or function pointers
> must be BY REFERENCE.
>
> COBOL does have PICTURE usage type "Z" for zero-terminated strings, so you
> don't have to use the STRING verb to construct constant strings with a
> zero-byte terminator to call C modules. I haven't experimented with moving
> "normal" COBOL strings (PIC X) to a PIC Z variable, so I do not know if
> that would work properly.
>
> HTH
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of scott Ford
> Sent: Tuesday, May 30, 2017 2:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: A slight regression
>
> John,
>
> I didnt realize you could call C library functions directly, very cool ,
> here is what i would like to do:
>
> FILE SECTION.
>WORKING-STORAGE SECTION.
>77 TESTSTR PIC X(30) VALUE SPACES.
>77 VAR1 PIC S9(9) BINARY VALUE 5.
>PROCEDURE DIVISION.
>-MAIN.
> * MOVE 1 TO P1.
> * DISPLAY 'P1: ' P1
> * CALL 'CFUNC' USING P1 RETURNING P2
> * DISPLAY 'P1: ' P1
> * DISPLAY 'P2: ' P2
> STRING 'TEST STRING' ,
>LOW-VALUE
> DELIMITED BY SIZE INTO TESTSTR
> DISPLAY 'CALL CENTRY USING: ' TESTSTR
> CALL 'CENTRY' USING TESTSTR.
> GOBACK.
>
>
>
> #include
> #include
> #include
> void CENTRY(char* mystring)
> {
> printf("my string: %s \n",mystring);
> }
>
> I am trying to understand how to perform the call and pass a string and or
> a integer ...
>
> Thanks John..
>
> Regards.
> Scott
>
> On Tue, May 30, 2017 at 2:19 PM, John McKown >
> wrote:
>
> > On Tue, May 30, 2017 at 1:07 PM, scott Ford wrote:
> >
> > > All:
> > >
> > > I saw a thread between Peter Fairley and John in April, this year
> > speaking
> > > about a cobol program calling C ..I am in the same board but did not
> > > see the C code. Can some one help me out and point me to the C
> > > routine or function ?
> > >
> >
> > Minor example at:
> > https://gist.github.com/JohnArchieMckown/5b973d46108bd24e0c6f9233c9617
> > 6b0
> >
> > Calls the C subroutines: cuserid(), strlen(). and sscanf(). I don't
> > have a C compiler, so I don't have an example of any "user written" C
> code.
> >
> >
> >
> > >
> > > Thanks and I appreciate it
> > >
> > > --
> > >
> > > *IDMWORKS *
> > >
> > > Scott Ford
> > >
> > > z/OS Dev.
> > >
> >
> >
> > --
> > Windows. A funny name for a operating system that doesn't let you see
> > anything.
> >
> > Maranatha! <><
> > John McKown
> >
> --
>
>
> This message and any attachments are intended only for the use of the
> addressee and may cont
Re: A slight regression
Scott,
That exchange between John and I (around April 7) was about calling C library
functions directly from COBOL. It works if you use a static call (COBOL
literal for the entry point name in UPPER CASE, NODYNAM COBOL compiler option)
because the C library function load modules (in CEE.SCEELKED) have an external
reference to the LE initialization subroutine CEESG003 which will do C language
startup initialization in the enclave. A dynamic COBOL CALL to a C library
function (variable name in the CALL or DYNAM COBOL compiler option) will not
work unless you manually use an INCLUDE SYSLIB(CEESG003) link edit control card
for your link step to get the C language initialization performed, and include
CEE.SCEELKED in the link edit SYSLIB DD.
Your code example below should "just work" in terms of getting the C language
initialization done because your C subroutine will have an external reference
to CEESG003, but passing strings and integers is trickier, because the C
language uses (mostly) "pass by VALUE" instead of the COBOL default of "pass by
REFERENCE (i.e., pointers)". You have to carefully use the BY REFERENCE and BY
VALUE attributes for the COBOL USING variables. Integers (and probably
floats/doubles as well) must be BY VALUE. Any structures or arrays (including
strings!) or function pointers must be BY REFERENCE.
COBOL does have PICTURE usage type "Z" for zero-terminated strings, so you
don't have to use the STRING verb to construct constant strings with a
zero-byte terminator to call C modules. I haven't experimented with moving
"normal" COBOL strings (PIC X) to a PIC Z variable, so I do not know if that
would work properly.
HTH
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of scott Ford
Sent: Tuesday, May 30, 2017 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A slight regression
John,
I didnt realize you could call C library functions directly, very cool , here
is what i would like to do:
FILE SECTION.
WORKING-STORAGE SECTION.
77 TESTSTR PIC X(30) VALUE SPACES.
77 VAR1 PIC S9(9) BINARY VALUE 5.
PROCEDURE DIVISION.
-MAIN.
* MOVE 1 TO P1.
* DISPLAY 'P1: ' P1
* CALL 'CFUNC' USING P1 RETURNING P2
* DISPLAY 'P1: ' P1
* DISPLAY 'P2: ' P2
STRING 'TEST STRING' ,
LOW-VALUE
DELIMITED BY SIZE INTO TESTSTR
DISPLAY 'CALL CENTRY USING: ' TESTSTR
CALL 'CENTRY' USING TESTSTR.
GOBACK.
#include
#include
#include
void CENTRY(char* mystring)
{
printf("my string: %s \n",mystring);
}
I am trying to understand how to perform the call and pass a string and or a
integer ...
Thanks John..
Regards.
Scott
On Tue, May 30, 2017 at 2:19 PM, John McKown
wrote:
> On Tue, May 30, 2017 at 1:07 PM, scott Ford wrote:
>
> > All:
> >
> > I saw a thread between Peter Fairley and John in April, this year
> speaking
> > about a cobol program calling C ..I am in the same board but did not
> > see the C code. Can some one help me out and point me to the C
> > routine or function ?
> >
>
> Minor example at:
> https://gist.github.com/JohnArchieMckown/5b973d46108bd24e0c6f9233c9617
> 6b0
>
> Calls the C subroutines: cuserid(), strlen(). and sscanf(). I don't
> have a C compiler, so I don't have an example of any "user written" C code.
>
>
>
> >
> > Thanks and I appreciate it
> >
> > --
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
>
>
> --
> Windows. A funny name for a operating system that doesn't let you see
> anything.
>
> Maranatha! <><
> John McKown
>
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A slight regression
On Tue, May 30, 2017 at 1:26 PM, scott Ford wrote:
> John,
>
> I didnt realize you could call C library functions directly, very cool ,
> here is what i would like to do:
>
> FILE SECTION.
>WORKING-STORAGE SECTION.
>77 TESTSTR PIC X(30) VALUE SPACES.
>77 VAR1 PIC S9(9) BINARY VALUE 5.
>PROCEDURE DIVISION.
>-MAIN.
> * MOVE 1 TO P1.
> * DISPLAY 'P1: ' P1
> * CALL 'CFUNC' USING P1 RETURNING P2
> * DISPLAY 'P1: ' P1
> * DISPLAY 'P2: ' P2
> STRING 'TEST STRING' ,
>LOW-VALUE
> DELIMITED BY SIZE INTO TESTSTR
> DISPLAY 'CALL CENTRY USING: ' TESTSTR
> CALL 'CENTRY' USING TESTSTR.
> GOBACK.
>
>
>
> #include
> #include
> #include
> void CENTRY(char* mystring)
> {
> printf("my string: %s \n",mystring);
> }
>
> I am trying to understand how to perform the call and pass a string and or
> a integer ...
>
> Thanks John..
>
> Regards.
> Scott
>
>
>
You example above should work fine. The standard COBOL parameter list
USING TESTSTR passes a single parameter which is the pointer to TESTSTR
which, in C speak, is char *. In general, for me, I think of "what code
does the sending language's compiler generate?" and "what does the
receiving language expect?". Inter-operating with C is set up in the
current COBOL compilers. At least back to 4.2. The reference is:
https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rlpscall.htm
What you need to remember is that C is a "call by value" language. That is,
the C languages expects the _value_ (not a pointer to a value) to be in the
calling list pointed to by GPR1. So when you see a definition like: *data_name; the C program is expecting a _pointer_. But if you see
something like: data_name, the C program is expecting the
actual value (however long) to be at the relative position in the calling
sequence. This is _not_ standard OS linkage! If you look at the above, you
will see that the CALL verb has three clauses you can use. The historic one
is "BY REFERENCE", which means "pass a pointer to the actual data are in
storage". This allows the CALL'ed routine to update the area and have that
changed value available to the caller. The one for C will often be "BY
VALUE". This tells the COBOL compiler to copy the current _value_ of the
variable named directly into the calling parameter. This is compatible with
the standard way of passing integers ( e.g. CALL 'CENTRY2' USING BY VALUE
INT-VALUE. 77 INT-VALUE PIC S9(9) COMP. and the prototype: void centry2(int
some-value);). The last is "BY CONTENT" and I don't know why it exists.
Basically, the COBOL compiler reserves an area in dynamic storage, copies
the contents of the named variable into that area, then passes the address
of the dynamic area to the subroutine. This basically makes the original
content in the caller unalterable.
really cut down examples:
77 INT-VALUE PIC S9(9) COMP. *> C language int32_t
77 INT-VALU2 PIC S9(9) COMP.
77 CHAR-VALUE PIC X(40). *> C language char x[40];
CALL 'CENTRY' USING BY REFERENCE CHAR-VALUE,
BY VALUE INT-VALUE,
BY REFERENCE INT2-VALUE
END-CALL
== C prototype for above:
void centry (char *char_value, int int_value, int *int2_value);
//
// note you can change char_value which will affect calling variable
// note you can change int_value which DOES NOT affect calling variable
// note you can change int2_value which DOES affect calling variable
Note that you could do something like:
CALL 'CENTRY' USING BY VALUE CHAR-VALUE, INT-VALUE, BY REFERENCE
INT2_VALUE.
with
void centry (char char_value[40], int int_value, int *int2_value);
But it most likely _won't_ be what you want!!! What the COBOL compiler
will do is create a calling list area. Copy the 40 bytes from CHAR-VALUE
directly into the calling parameter list. Follow that by the 4 bytes value
in INT-VALUE. Followed by a 4 byte address of INT2-VALUE. That is, the GPR1
will point to 48 bytes of data. In addition, changing char_value does NOT
change the value back in the COBOL program. So, in ever case that I've ever
see, I've seen C "string" values (actually array of chars) passed by
address not value.
I hope this was of some value. And that I didn't mess up.
--
Windows. A funny name for a operating system that doesn't let you see
anything.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A slight regression
John,
I didnt realize you could call C library functions directly, very cool ,
here is what i would like to do:
FILE SECTION.
WORKING-STORAGE SECTION.
77 TESTSTR PIC X(30) VALUE SPACES.
77 VAR1 PIC S9(9) BINARY VALUE 5.
PROCEDURE DIVISION.
-MAIN.
* MOVE 1 TO P1.
* DISPLAY 'P1: ' P1
* CALL 'CFUNC' USING P1 RETURNING P2
* DISPLAY 'P1: ' P1
* DISPLAY 'P2: ' P2
STRING 'TEST STRING' ,
LOW-VALUE
DELIMITED BY SIZE INTO TESTSTR
DISPLAY 'CALL CENTRY USING: ' TESTSTR
CALL 'CENTRY' USING TESTSTR.
GOBACK.
#include
#include
#include
void CENTRY(char* mystring)
{
printf("my string: %s \n",mystring);
}
I am trying to understand how to perform the call and pass a string and or
a integer ...
Thanks John..
Regards.
Scott
On Tue, May 30, 2017 at 2:19 PM, John McKown
wrote:
> On Tue, May 30, 2017 at 1:07 PM, scott Ford wrote:
>
> > All:
> >
> > I saw a thread between Peter Fairley and John in April, this year
> speaking
> > about a cobol program calling C ..I am in the same board but did not see
> > the C code. Can some one help me out and point me to the C routine or
> > function ?
> >
>
> Minor example at:
> https://gist.github.com/JohnArchieMckown/5b973d46108bd24e0c6f9233c96176b0
>
> Calls the C subroutines: cuserid(), strlen(). and sscanf(). I don't have a
> C compiler, so I don't have an example of any "user written" C code.
>
>
>
> >
> > Thanks and I appreciate it
> >
> > --
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
>
>
> --
> Windows. A funny name for a operating system that doesn't let you see
> anything.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
*IDMWORKS *
Scott Ford
z/OS Dev.
“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”
www.idmworks.com
scott.f...@idmworks.com
Blog: www.idmworks.com/blog
*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A slight regression
On Tue, May 30, 2017 at 1:07 PM, scott Ford wrote: > All: > > I saw a thread between Peter Fairley and John in April, this year speaking > about a cobol program calling C ..I am in the same board but did not see > the C code. Can some one help me out and point me to the C routine or > function ? > Minor example at: https://gist.github.com/JohnArchieMckown/5b973d46108bd24e0c6f9233c96176b0 Calls the C subroutines: cuserid(), strlen(). and sscanf(). I don't have a C compiler, so I don't have an example of any "user written" C code. > > Thanks and I appreciate it > > -- > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > -- Windows. A funny name for a operating system that doesn't let you see anything. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A slight regression
All: I saw a thread between Peter Fairley and John in April, this year speaking about a cobol program calling C ..I am in the same board but did not see the C code. Can some one help me out and point me to the C routine or function ? Thanks and I appreciate it -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
