Enterprise Cobol and multithreading with Enterprise PL/I

[saume]

Hi,

Firstly I would like to tell you that I know that that version of the Coobol can not attach a new thread to the main thread, like PL/I can do with the ATTACH statement.

BUT I try to test the following situation:

A main program in COBOL calling statically a PL/I routine that:
- attaches a thread ATTACH <another routine name> THREAD(<thread name>)
- waits its end WAIT THREAD (<thread name>)

As far as I can understand the different outputs I have produced, everything is running fine till the end of the main COBOL program ...

here are the messages I have received:

JOB17503 IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000010
TIME=16.45.56 SEQ=37679 CPU=0000 ASID=0151
PSW AT TIME OF ERROR 078D1000 899005BE ILC 4 INTC 10
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 099005B8 - 12664780 31E25870 60004107
GR 0: 00000000_000000B8 1: 00000000_00048058
2: 00000000_00047000 3: 00000000_09900402
4: 00000000_00048050 5: 00000000_00000068
6: 00000000_C5C4C5E5 7: 00000000_0004A000
8: 00000000_191B0780 9: 00000000_00000000
A: 00000000_00000000 B: 00000000_190718D8
C: 00000000_00017B10 D: 00000000_0002DDA8
E: 00000000_89900440 F: 00000001_00000000
END OF SYMPTOM DUMP
JOB17503 BPXP009I THREAD 1960940000000000, IN PROCESS 33554929, ENDED
ABNORMALLY WITH COMPLETION CODE 840C4000, REASON CODE 0000001

Someone has an idea ???

- Is that situation possible ?
- Do I forget to use some LE run-time options ?
- Do I forget to use some COBOL compilation options ?

Thanks in advance,
Olivier

PS: I have tested using a main program written in PL/I and ... it works ....

 

[WMK]

Are you using the THREAD compiler option? See:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg10/2.4.51

Bill Klein

 

[saume]

Hi,

Yes and No ...

n fact, I had understood that the THREAD option should only be used when the Cobol program program was called in a thread. But when I saw it did not work, I had tried to compile my main COBOL program with the THREAD option and the 'RECURSIVE' clause in the PROGRAM-ID as required by the documentation.

But even if compilation worked, the link-edit step failed because of the following reason:
IEW2456E 9207 SYMBOL IGZCBSP UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY.

Do you know where does that module exist ?

Thanks for your reply WMK

Best regards,
Olivier

 

[WMK]

What release of LE are you link-eding with? Also, is this a CICS or non-CICS application? (and are you using the correct LE link-edit library)?

Bill Klein

 

[saume]

Hi,

I am performing my tests using OS/390 2.10 and it is not a CICS application.

Concerning the correct LE link-edit library, I must assume that 'yes' as we are using skeletons for the compilation JCLs.

Hoping it answers your question ...

Thanks for your help.

Best regards,
Olivier

 

[WMK]

I have asked one of my &quot;usually reliable&quot; source about this, but I did want to ask about a couple of other things that MIGHT be related.

What are your compiler option settings for RENT and for DLL? If you are creating a DLL, are you storing your &quot;load module&quot; in a PDS or a PDSE?

Bill Klein

 

[WMK]

My usually reiliable source sent me the following:

&quot;IGZCBSP is the bootstrap for THREAD programs. I would guess that the customer is ...
trying to use a down level LE which is missing pre-REQ APARs for THREAD support:
OS/390 V2R10 Language Environment Plus PTFs for APARs PQ52338 and PQ52626&quot;

If you aren't the systems support person for LE, let your systems programmer know that you MUST have &quot;PQ52338 and PQ52626 applied to your LE system in order for you to use the THREAD compiler option. If it turns out that you DO have these APARs / PTF applied, let me know and I will pursue further.


Bill Klein

 

[saume]

Hi,

thanks for your support ! (thanks also to your rliable source).

I have checked my compilation options: i use the RENT and NODLL options .

For the APAR, I am waiting the feedback of someone from the MVS system team ...

Thanks a lot.

best regards,
Olivier