Re: Problem Calling "kill" in threaded 64-bit MF Server Express 4.0 SP2

OK - got the answer - wanted to post to the group.

Apparently, while this works in non-threaded mode - it won't work this
way in threaded mode.

You need to actually introduce a call to the appropriate system routine
to return the address of the last errno generated. On HP - this is
"__errno", on AIX, it's "_Errno" and on Sun it's "___errno".

So after you check rc = -1, you need to add this code:

CALL OS-ERRNO-ADDR
RETURNING OS-ERRNO-PTR
END-CALL

SET ADDRESS OF OS-ERRNO TO OS-ERRNO-PTR

DISPLAY OS-ERRNO


Now you will get the appropriate results.




Chris wrote:
Hi all.

Again - I come to the group hoping to find some expertise.

Platform: HP-UX 11i (11.11)
COBOL: MF Server Express 4.0 SP2 (Fixpack40.04_46)


I have the following snippet of code:


77 int pic s9(09) comp-5 is typedef.
77 u-int pic 9(9) comp-5 is typedef.

77 errno u-int external.


01 my-pid int.
01 rc int.


MOVE <some value> TO my-pid

CALL "kill" USING
BY VALUE my-pid
BY VALUE 0
RETURNING
rc
END-CALL



Now for the fun part. In a non-threaded runtime (rts64), when I move
the value of a PID that I am not the owner of to my-pid, I get the
following results:

rc=-1
errno=1

errno=1 indicates the UNIX EPERM error, which is what I expect. The
process exists and I do not have permissions on it.


In the threaded (rts64_t) runtime, when I execute the same snip of
code, I get the following results:

rc=-1
errno=25

What's even more peculiar, is that when I animate (anim64_t) the
threaded version, I get these results:

rc=-1
errno=2


What is it about threading vs. non-threading that would cause my call
to get all out of whack?

Am I missing something obvious here? I am new to the concept of using
"threaded" runtimes, but it is the recommended solution for working
with Oracle, but I wouldn't have expected this type of behavioral
change.

The MF Support folks suggested compiling with the -D_PSTAT64 flag, but
that did not correct the situation - so I am looking to the vast pool
of knowledge here for assistance.

Thanks in advance,
Chris

.