Multi-tasking with LE/370 
Author Message
 Multi-tasking with LE/370

Hi all,

    I'm kind of a beginner in writing LE/370 conformant application. I
use LanguageEnvironment v1.5 on OS/390 1.2 (we're soon upgrading to OS/390
2.7
& LE v1.8).

    Lately I came upon a problem concerning multitasking with LE/370.

    I'll first describe the current situation (without LE/370 active):

There is an address-space, and the name of the main program is
DFSPCC20 (yes, it's an IMS MPR...).

As this program (DFSPCC20) starts, it LINKs to a program named MYINIT.
This program does a simple thing: It attaches a subtask. The subtask's main
module is called MYTASK.

Right after MYINIT attaches MYTASK - it terminates and giving control back
to DFSPCC20, which then just WAITs.

So, now I have (in the address-space), in addition to the main task -
another
task, called MYTASK. Note that ABEND for quitting-without-detaching-tasks is
not
relevant, since that MYTASK's real "father task" is DFSPCC20, which is still
active.

All is written in ASM/370, compiled with High Level Assembler with no LE/370
involved whatsoever.

Everything's fine.

Now: I want to upgrade the program so it'll be LE/370 conformant.

However, when I run the whole business - it ABENDS S0C4 on CEEPLPKA (if I'm
not mistaken
in the module's name).

I think I'm having a deal with saving-area's problems.

How EXACTLY should this be done in LE/370?
What do I have to add?

Anybody ever tried to do such thing?

Any help will be greatly appreciated. If needed, I'll publish the code
itself.

  Regards,

--------------------------
   Itsik Shabtay



Mon, 13 Aug 2001 03:00:00 GMT  
 Multi-tasking with LE/370

Itsik Shabtay wrote
<snip>

Quote:
>Now: I want to upgrade the program so it'll be LE/370 conformant.
>However, when I run the whole business - it ABENDS S0C4 on CEEPLPKA
>(if I'm not mistaken in the module's name).

>I think I'm having a deal with saving-area's problems.

Maybe and maybe not. Exactly what abend/reason did you get?

S0C4-4 == protection exception. The code tried to store into storage with a
different key OR access fetch protected storage in another key.

S0C4-10 == segment fault. The entire megabyte segment is not
allocated/accessible
 S0C4-11 == page fault. The page is not allocated/accessible.

Each of the previous two pretty much guarantees that the program got a wild
pointer - or that it tried to access storage that had already been freed
(ignoring disablement issues).

However, when you factor LE into the picture its equally possible that it
got a 31 bit address and tried to access it in 24 bit mode, or to treat it
as a 24 bit address (ignoring the high order byte).

Either way, you are SOL without more helpful information. However, what you
are attempting to do is reasonable and should work fine. I would tend to
suspect an amode/rmode problem. What parms did you specify on the attach
macro?

Chris



Tue, 14 Aug 2001 03:00:00 GMT  
 Multi-tasking with LE/370
Hi Chris,

Sorry for the late reply and thanks for the attention...

I'm having S0C4-10.

My ATTACH has got only "EPLOC=" and "ECB=". I don't think it's the problem
here -
All of the code is written as 31/ANY.

What EXACTLY does CEEENTRY do?

I assume I don't have to deal with saveareas - the le/370 routine will
save its registers in the Operating System's provided S/A. Maybe the
saveareas
are in different formats?....

  Regards,

--------------------------
   Itsik Shabtay

Quote:

>Itsik Shabtay wrote
><snip>
>>Now: I want to upgrade the program so it'll be LE/370 conformant.
>>However, when I run the whole business - it ABENDS S0C4 on CEEPLPKA
>>(if I'm not mistaken in the module's name).

>>I think I'm having a deal with saving-area's problems.

>Maybe and maybe not. Exactly what abend/reason did you get?

>S0C4-4 == protection exception. The code tried to store into storage with a
>different key OR access fetch protected storage in another key.

>S0C4-10 == segment fault. The entire megabyte segment is not
>allocated/accessible
> S0C4-11 == page fault. The page is not allocated/accessible.

>Each of the previous two pretty much guarantees that the program got a wild
>pointer - or that it tried to access storage that had already been freed
>(ignoring disablement issues).

>However, when you factor LE into the picture its equally possible that it
>got a 31 bit address and tried to access it in 24 bit mode, or to treat it
>as a 24 bit address (ignoring the high order byte).

>Either way, you are SOL without more helpful information. However, what you
>are attempting to do is reasonable and should work fine. I would tend to
>suspect an amode/rmode problem. What parms did you specify on the attach
>macro?

>Chris



Wed, 22 Aug 2001 03:00:00 GMT  
 Multi-tasking with LE/370

Itsik Shabtay wrote

Quote:
>I'm having S0C4-10.

It still sounds like an amode issue... what EXACTLY was the PSW at the time
of the abend? Did it look like this =>  X'078D0000 8nnnnnnnnn'
or like this => X'078D0000 00nnnnnn' ?

Quote:
>My ATTACH has got only "EPLOC=" and "ECB=". I don't think it's the problem
>here ->All of the code is written as 31/ANY.

OK. no problem there. Are you sure the load module entry point is linked
that way?

Quote:
>What EXACTLY does CEEENTRY do?

It performs entry linkage for a Language Environment conformant asm program.
If the program in question is NOT a main program, it simply saves the
caller's registers and allocates the program's working storage from the LE
stack.

However, if the program is a MAIN, it will call (via a stub) CEEINT, the LE
bootstrap routine, to create the LE environment. That involves loading the
LE runtime code, allocating stack storage, building a bunch of control
blocks (CAA, PCB, EDB etc) and eventually passing control back to the
mainline of your program.

Quote:
>I assume I don't have to deal with saveareas - the le/370 routine will
>save its registers in the Operating System's provided S/A. Maybe the
>saveareas are in different formats?....

You are well past the saving of registers if the abending module was
CEEPLPKA. This is one of those annoying little problems where you will
eventually find something "obvious" (that wasn't really obvious) and it will
all suddenly start working the way you expect.

More input!
Chris



Fri, 24 Aug 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. LE/370

2. LE/370 using relink

3. PL/I in the LE/370 Environment

4. LE/370 INTERNAL ABEND. ABCODE = 4088 REASON = 00000063

5. Behaviour of FREE() changed in LE/370?

6. PL/I in the LE/370 Environment

7. LE/370 : ILC between Cobol and PL/1

8. Can LE/370 Routines be called by REXX ?

9. COBOL LE/370 upgrade

10. LIBKEEP in LE/370?

11. PL/I in the LE/370 Environment

12. COBOL LE/370 Date Routines

 

 
Powered by phpBB® Forum Software