The COBOL 20xx standard(s) do have some better support for COBOL calling to C,
but it's still not too hard with the current Enterprise COBOL. For example:
call 'regcomp' using regex
content z"^a[[:alnum:]]"
value 0
returning reti
if reti is not equal to zero
display 'Could not compile regex'
stop run
end-if
call 'regexec' using regex
content z'abc'
value 0 0 0
returning reti
Frank
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Bernd Oppolzer <[email protected]>
Sent: Thursday, April 6, 2017 12:10 PM
To: [email protected]
Subject: Re: Opinion: Using C "standard library" routines in COBOL.
Topic drift:
This is somehow easy from PL/1, for some reasons:
a) parameters to external functions can be defined in PL/1 to be
passed using NODESCRIPTOR and BYVALUE, so that the mechanisms
perfectly match the C mechanisms
b) PL/1 has a datatype CHAR (x) VARYINGZ (no typo), which means:
variable length, the length is designated by a terminating hex zero byte,
which again matches perfectly the C paradigm. This is superior to C,
because such a variable is known to have the hex zero before byte X.
CHAR (10) VARZ in fact has 11 bytes. The normal PL/1 functions like
LENGTH and SUBSTR work on VARZ like on normal VAR fields.
This said: some of the examples in the PL/1 reference and user's guide
show how to call C library functions from PL/1, which is a no-brainer.
Kind regards
Bernd
Am 06.04.2017 um 19:52 schrieb John McKown:
> This is just a curiosity poll on my part. I'm wondering if anyone out there
> has ever really used any C standard library routines (versus user written
> code) in a COBOL program. I know that many may wonder "Why? What do I get
> out of it." IMO, there are some useful routines in the standard C library
> which could be used in COBOL.
>
> One in particular which shows up quickly is the C language "cuserid()"
> function. It will return the RACF id under which the program is running.
> Now, since cuserid() plops a LOW-VALUE as an end-of-string delimiter, that
> needs to be taken into consideration. Something like the following worked
> for me:
>
> 01 USERID-PLUS-1
> 05 USERID PIC X(8).
> 05 FILLER PIC X.
> 01 CUSERID-POINTER POINTER.
>
> CALL 'CUSERID' USING USERID-PLUS-1.
>
> as did
>
> CALL 'CUSERID' USING USERID-PLUS-1
> RETURNING CUSERID-POINTER.
>
> But this latter is unnecessary since the ID will be in USERID. But it might
> have a LOW-VALUE, so it is better to do a MOVE SPACES TO USERID before the
> CALL and a INSPECT USERID REPLACING LOW-VALUES BY SPACES after the call.
>
> There are a lot more "interesting" C library functions which might be
> useful. Such as the regular expression library for advanced text scanning
> (OK, not a big COBOL thing). How about __get_cpuid() to get the CPU id of
> the processor you're running on? DES encryption of data? The sprintf()
> function to create a nicely formatted human readable message easily (not a
> lot of space padding) although STRING might do this as well. On older
> compilers, use the "calloc()" and "malloc()" function to get dynamic
> storage areas to map with the LINKAGE SECTION. How about using "popen()" to
> fire up a UNIX process to do some work for you?
>
> Well, I'm going nutso again.
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
