Problems With MF SE 4.0 SP2 License Manager and Oracle

I've been having a problem, and I wonder if it is unique to me.

I am running MF Server Express 4.0 SP2 on HP-UX11i.

The license manager for SE is set to automatically come up when the
machine is booted - which I have confirmed it does.

Here's the issue:

I have two applications. The first is myexe, which has an initcall to
Oracle's libraries in it. The second is stdexe, which just does some
simple displays to the screen.

When the machine is rebooted, if I try to run myexe before running
stdexe, myexe hangs. When I hit Ctrl-C to regain control of the
terminal, I get the following message from the Application Server
License Manager:

ASLM: COBOL execution would cause infinite loop
ASLM: Errno 2099
ASLM: shm open fail
ASLM: Errno 2099


As long as I run stdexe first, everything is fine and myexe will
execute without any issues.


Anybody have any ideas what may be happening here? I imagine it has
something to do with the initcall statement, but I'd like some sort of
confirmation on that.


Thanks,
Chris

re: issue with Micro Focus Application Server license manager on HP-UX.

Hi Chris,

I think you would be best to follow up on this via the forum on
http://www.cobolportal.com .

What would be useful for us is whether the callable shared object you have
created -- using cob -z, I assume -- also contains any COBOL objects, or
just pulls in Oracle modules? It would be useful also if you could provide
the command-line used to build that shared object, along with the output
from running mfsupport (mfpoll.txt) from the environment where 'myexe' is
being executed, specifically so we can see whether you're working in 32-bit
or 64-bit mode, and also so we can verify the setting of
COBDIR/SHLIB_PATH/LD_LIBRARY_PATH.

Depending on the result of the above, we *may* also require copies of any
additional -- i.e. non-Oracle/Micro Focus system -- objects/libraries you're
using to build the CSO, to aid our investigation.

Regards,
SimonT.

Thanks Simon.

I'll post to the forum, and I've opened an incident with Support Line
on this as well.

You are correct in your assumptions - the command line used to generate
the Oracle CSO is:

make LOC_RTSORA=orasqllib.sl -f insprecomp.mk orasqllib.sl

When this command is executed, the resulting 'cob' command looks like
this:

cob64 -C nolist -v -o orasqllib.sl -t -ze
/orasoft/app/oracle/product/10.1.0/precomp/lib/cobsqlintf.o
/orasoft/app/oracle/product/10.1.0/lib/scorept.o
/orasoft/app/oracle/product/10.1.0/lib/sscoreed.o
/orasoft/app/oracle/product/10.1.0/rdbms/lib/kpudfo.o -L
/orasoft/app/oracle/product/10.1.0/lib/ -lclntsh

The results of mfsupport are over 1000 lines, so I will not post it
here.

Thanks again - I look forward to your analysis.

Chris

OK - I figured I'd post the answer I got from MF Support Line here in
case anyone is interested:

It boils down to a shared memory issue between certain applications
(notably Oracle and Tuxedo) and the MF License Manager.

Apparently these other applications *may* encroach the shared memory
used for the MFLM unless MFLM's shared memory is owned by root.

So - the solution to this issue, as proposed by MF, is to run a simple
COBOL app during system startup, thus ensuring that MFLM's shared
memory is owned by root. The simple application can simply contain a
goback statement.

I've incorporated this solution, and it has corrected my problem.

I've created a self-installation script to do this if anyone finds
themselves in need.

Thanks,
Chris

OK - I figured I'd post the answer I got from MF Support Line here in
case anyone is interested:

It boils down to a shared memory issue between certain applications
(notably Oracle and Tuxedo) and the MF License Manager.

Apparently these other applications *may* encroach the shared memory
used for the MFLM unless MFLM's shared memory is owned by root.

So - the solution to this issue, as proposed by MF, is to run a simple
COBOL app during system startup, thus ensuring that MFLM's shared
memory is owned by root. The simple application can simply contain a
goback statement.

I've incorporated this solution, and it has corrected my problem.

I've created a self-installation script to do this if anyone finds
themselves in need.

Thanks,
Chris

OK - I figured I'd post the answer I got from MF Support Line here in
case anyone is interested:

It boils down to a shared memory issue between certain applications
(notably Oracle and Tuxedo) and the MF License Manager.

Apparently these other applications *may* encroach the shared memory
used for the MFLM unless MFLM's shared memory is owned by root.

So - the solution to this issue, as proposed by MF, is to run a simple
COBOL app during system startup, thus ensuring that MFLM's shared
memory is owned by root. The simple application can simply contain a
goback statement.

I've incorporated this solution, and it has corrected my problem.

I've created a self-installation script to do this if anyone finds
themselves in need.

Thanks,
Chris