If anyone cares, here are the working-storage fields used in my example below:
working-storage section.
01 regex display pic x(364).
01 redefines regex.
05 re_nsub comp-5 pic s9(8).
05 re_comp pointer.
05 re_cflags comp-5 pic s9(8).
05 re_erroff comp-5 pic s9(8).
05 re_len comp-5 pic s9(8).
05 re_ucoll comp-5 pic s9(4) occurs 2.
05 re_lsub pointer occurs 10.
05 re_esub pointer occurs 10.
05 re_map display pic x(256).
05 re_shift comp-5 pic s9(4).
05 re_dbcs comp-5 pic s9(4).
77 reti comp-5 pic s9(8).
77 msgbuf display pic x(100).
Frank
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Frank Swarbrick <[email protected]>
Sent: Thursday, April 6, 2017 12:32 PM
To: [email protected]
Subject: Re: Opinion: Using C "standard library" routines in COBOL.
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
