Enterprise COBOL execution & POSIX(ON) LE parm.

[John McKown]

I have compiled some C code from the Internet (sqlite) which uses UNIX
mutex functions for multithreading. I know that COBOL doesn't really
support multithreading, but this is a generic library which does. My COBOL
test job kept abending with an S0C6. I was going a bit nuts. But then I
actually read up a bit on the pthread_mutex... calls (what a concept -
RTFM!). And discovered that they listed a dependency of POSIX(ON). So I
tried the same code, but put in POSIX(ON) in the EXEC. And it ran OK. Well,
it didn't really _do_ anything, but it didn't blow up either.

Question: Has anybody out there done _anything_ in COBOL with POSIX(ON)?
And have you had any problems? Just paranoid. The FM does talk about it and
says where it is needed. But some experiences would be nice to know about.

--
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Charles Mills]

Not COBOL, but ...

I have a rather large STC written in C++. I had done it all POSIX(OFF) for
no particular reason except "if it ain't broke ..." I needed to support GSK
which requires POSIX(ON). There were a *lot* of little surprises. Lots of
little things that stopped working or worked differently. I don't remember
them all, but one for example was this: With POSIX(OFF),
fopen("DD:SYSPRINT", ...) does what you would expect. With POSIX on, believe
or not, that fopen creates a USS file named -- ta-da -- DD:SYSPRINT. To get
the results you want you have to specify "//DD:SYSPRINT". Documented, but a
little surprise nonetheless.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: Monday, August 26, 2013 8:19 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Enterprise COBOL execution & POSIX(ON) LE parm.

I have compiled some C code from the Internet (sqlite) which uses UNIX mutex
functions for multithreading. I know that COBOL doesn't really support
multithreading, but this is a generic library which does. My COBOL test job
kept abending with an S0C6. I was going a bit nuts. But then I actually read
up a bit on the pthread_mutex... calls (what a concept - RTFM!). And
discovered that they listed a dependency of POSIX(ON). So I tried the same
code, but put in POSIX(ON) in the EXEC. And it ran OK. Well, it didn't
really _do_ anything, but it didn't blow up either.

Question: Has anybody out there done _anything_ in COBOL with POSIX(ON)?
And have you had any problems? Just paranoid. The FM does talk about it and
says where it is needed. But some experiences would be nice to know about.

[Paul Gilmartin]

On Mon, 26 Aug 2013 09:06:14 -0700, Charles Mills wrote:

>Not COBOL, but ...
>
>I have a rather large STC written in C++. I had done it all POSIX(OFF) for
>no particular reason except "if it ain't broke ..." I needed to support GSK
>which requires POSIX(ON). There were a *lot* of little surprises. Lots of
>little things that stopped working or worked differently. I don't remember
>them all, but one for example was this: With POSIX(OFF),
>fopen("DD:SYSPRINT", ...) does what you would expect. With POSIX on, believe
>or not, that fopen creates a USS file named -- ta-da -- DD:SYSPRINT. To get
>the results you want you have to specify "//DD:SYSPRINT". Documented, but a
>little surprise nonetheless.
>

Hardly unexpected; merely what POSIX requires. But I may need
to re-read what POSIX says about the use of the ":", not in the
Portable Filename Character set. How else would you expect to
create or read a file named "DD:SYSPRINT"?

In fact, POSIX even deprecates the "//" construct two ways: both
implementors and programmers are cautioned against its use.
POSIX requires that "cat //etc/services" operate the same as
"cat /etc/services". IBM would have done better to reserve a
non-mountpoint such as "/Legacy" and support constructs in forms
such as: "/Legacy/DD:SYSPRINT" and "/Legacy/'SYS1.MACLIB(SPREL)'"
(The question remains of how stat("/Legacy"); should behave if
that were done.)

-- gil

[Tom Ross]

>I have compiled some C code from the Internet (sqlite) which uses UNIX
>mutex functions for multithreading. I know that COBOL doesn't really
>support multithreading, but this is a generic library which does.

COBOL does really suppport multithreading, but you need to use the
THREAD compiler option to get that support.

Cheers,
TomR >> COBOL is the Language of the Future! <<

[Elardus Engelbrecht]

Tom Ross wrote:

>COBOL does really suppport multithreading, but you need to use the THREAD compiler option to get that support.

And lose ability to use some elements (example: SORT statement). :-(

Groete / Greetings
Elardus Engelbrecht

[Paul Gilmartin]

On Tue, 27 Aug 2013 02:07:08 -0500, Elardus Engelbrecht <elardus.e...@SITA.CO.ZA> wrote:

>Tom Ross wrote:
>
>>COBOL does really suppport multithreading, but you need to use the THREAD compiler option to get that support.
>
>And lose ability to use some elements (example: SORT statement). :-(
>

> >> COBOL is the Language of the Future! <<
>

How long must we wait?

-- gil

[John McKown]

Thanks for that heads up about THREAD option. I have an example COBOL
program which is using the library already. But I am not trying to
multithread. I will put some information in my README should anybody be
silly enough to want to do multithreading in COBOL.

--
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

[ABW1101]

I've done that and it does work - spawning multiple Cobol threads from a C program using PTHREAD functions. I took it one step further and created individual DB2 threads using the RRSAF facility from each Cobol instance. I wrote it in 2015, but not sure if it was supported in 2013 when this was posted. The IBM manuals talk about it but there's not a lot of examples out there.