Pl1, Memory Allocation

Ryan
#1 / 20

Memory Allocation

Hi All,

I have a newbie questions but I couldn't find an answer to it on google or
in my crappy PL1 book.

Basically, my question is how do I find out my memory allocation failed
because too much memory was requested?

What do I have to check after the command

ALLOCATE ABC;

???

Right now I just get protection exception when I attempt to allocate too
much memory. I want to be able to check that it failed and quit the program
gracefully with an error message. Thanks.

Tue, 06 Dec 2005 01:42:23 GMT

Mark Yudki
#2 / 20

Memory Allocation

If it fails, it will throw a condition. For recent compilers this will be
STORAGE, for older compilers, it will be ERROR. (If you don't handle STORAGE
it will cascade to ERROR). A special case is AREA allocation, in which case
it will throw AREA (this is not your case). If execution continues at the
statement after the ALLOCATE, and you haven't used GOTO to get there, the
allocation is _absolutely guaranteed_ to have succeeded.

I do not understand why "you just get a protection exception when your
attempt to allocate too much memory". I suspect you have a different
problem.

It is often helpful with questions if you state the compiler version and
platform.

Quote:

> Hi All,

> I have a newbie questions but I couldn't find an answer to it on google or
> in my crappy PL1 book.

> Basically, my question is how do I find out my memory allocation failed
> because too much memory was requested?

> What do I have to check after the command

> ALLOCATE ABC;

> ???

> Right now I just get protection exception when I attempt to allocate too
> much memory. I want to be able to check that it failed and quit the
program
> gracefully with an error message. Thanks.

Tue, 06 Dec 2005 14:54:21 GMT

Heinz Wiggeshof
#3 / 20

Memory Allocation

Quote:

> Basically, my question is how do I find out my memory allocation
failed
> because too much memory was requested?

Back in Ye Olden Days, I got an S80A ABEND.
Not pretty.

Tue, 06 Dec 2005 22:33:52 GMT

Heinz Wiggeshof
#4 / 20

Memory Allocation

Quote:

> If it fails, it will throw a condition. For recent compilers this
will be
> STORAGE, for older compilers, it will be ERROR. (If you don't handle
STORAGE
> it will cascade to ERROR). A special case is AREA allocation, in
which case
> it will throw AREA (this is not your case). If execution continues
at the
> statement after the ALLOCATE, and you haven't used GOTO to get
there, the
> allocation is _absolutely guaranteed_ to have succeeded.

THROW? Begone, C-thingy! B-)

Tue, 06 Dec 2005 22:34:54 GMT

Ryan
#5 / 20

Memory Allocation

Thanks for replying.

But how do I "catch" (more c-thingy) this condition? can you elaborate more
on that? Thanks.

Quote:

> If it fails, it will throw a condition. For recent compilers this will be
> STORAGE, for older compilers, it will be ERROR. (If you don't handle
STORAGE
> it will cascade to ERROR). A special case is AREA allocation, in which
case
> it will throw AREA (this is not your case). If execution continues at the
> statement after the ALLOCATE, and you haven't used GOTO to get there, the
> allocation is _absolutely guaranteed_ to have succeeded.

> I do not understand why "you just get a protection exception when your
> attempt to allocate too much memory". I suspect you have a different
> problem.

> It is often helpful with questions if you state the compiler version and
> platform.

> > Hi All,

> > I have a newbie questions but I couldn't find an answer to it on google
or
> > in my crappy PL1 book.

> > Basically, my question is how do I find out my memory allocation failed
> > because too much memory was requested?

> > What do I have to check after the command

> > ALLOCATE ABC;

> > ???

> > Right now I just get protection exception when I attempt to allocate too
> > much memory. I want to be able to check that it failed and quit the
> program
> > gracefully with an error message. Thanks.

Wed, 07 Dec 2005 04:48:27 GMT

Ryan
#6 / 20

Memory Allocation

oh ya, for platform I am using z/os. I have no idea what version I am using
for the compiler. I would assume its pretty new since its on z/os.

Quote:

> Hi All,

> I have a newbie questions but I couldn't find an answer to it on google or
> in my crappy PL1 book.

> Basically, my question is how do I find out my memory allocation failed
> because too much memory was requested?

> What do I have to check after the command

> ALLOCATE ABC;

> ???

> Right now I just get protection exception when I attempt to allocate too
> much memory. I want to be able to check that it failed and quit the
program
> gracefully with an error message. Thanks.

Wed, 07 Dec 2005 04:50:04 GMT

Seymour
#7 / 20

Memory Allocation

Quote:

>But how do I "catch" (more c-thingy) this condition? can you
>elaborate more on that? Thanks.

Read up on the words "ON" and "SIGNAL". You enable a condition and
activate an ON-unit in your code.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited bulk E-mail will be subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply

Thu, 08 Dec 2005 10:35:09 GMT

Mark Yudki
#8 / 20

Memory Allocation

Strongly recommend you RTFM.

Quote:

> Thanks for replying.

> But how do I "catch" (more c-thingy) this condition? can you elaborate
more
> on that? Thanks.

> > If it fails, it will throw a condition. For recent compilers this will
be
> > STORAGE, for older compilers, it will be ERROR. (If you don't handle
> STORAGE
> > it will cascade to ERROR). A special case is AREA allocation, in which
> case
> > it will throw AREA (this is not your case). If execution continues at
the
> > statement after the ALLOCATE, and you haven't used GOTO to get there,
the
> > allocation is _absolutely guaranteed_ to have succeeded.

> > I do not understand why "you just get a protection exception when your
> > attempt to allocate too much memory". I suspect you have a different
> > problem.

> > It is often helpful with questions if you state the compiler version and
> > platform.

> > > Hi All,

> > > I have a newbie questions but I couldn't find an answer to it on
google
> or
> > > in my crappy PL1 book.

> > > Basically, my question is how do I find out my memory allocation
failed
> > > because too much memory was requested?

> > > What do I have to check after the command

> > > ALLOCATE ABC;

> > > ???

> > > Right now I just get protection exception when I attempt to allocate
too
> > > much memory. I want to be able to check that it failed and quit the
> > program
> > > gracefully with an error message. Thanks.

Thu, 08 Dec 2005 15:20:13 GMT

Mark Yudki
#9 / 20

Memory Allocation

If it's Enterprise PL/I, you get STORAGE, if its OS PL/I or PL/I for MVS,
you get ERROR. You will not get a protection exception (8094) as a result of
a memory allocation error; you would need another bug for that.

Quote:

> oh ya, for platform I am using z/os. I have no idea what version I am
using
> for the compiler. I would assume its pretty new since its on z/os.

> > Hi All,

> > I have a newbie questions but I couldn't find an answer to it on google
or
> > in my crappy PL1 book.

> > Basically, my question is how do I find out my memory allocation failed
> > because too much memory was requested?

> > What do I have to check after the command

> > ALLOCATE ABC;

> > ???

> > Right now I just get protection exception when I attempt to allocate too
> > much memory. I want to be able to check that it failed and quit the
> program
> > gracefully with an error message. Thanks.

Thu, 08 Dec 2005 15:23:32 GMT

Glen Herrmannsfeld
#10 / 20

Memory Allocation

Quote:

> If it's Enterprise PL/I, you get STORAGE, if its OS PL/I or PL/I for MVS,
> you get ERROR. You will not get a protection exception (8094) as a result
of
> a memory allocation error; you would need another bug for that.

(snip discussion about protection exception and allocation)

Wouldn't you get a protection exception if memory allocation failed, but you
tried to use it anyway?

DCL X(1000000000) CONTROLLED;

ON ERROR;

ALLOCATE (X);

X(1)=10;

Thu, 08 Dec 2005 18:15:32 GMT

Mark Yudki
#11 / 20

Memory Allocation

You'd need to explicity GOTO out of the ERROR to a location where you then
deliberately used the memory that you'd just been told you couldn't
allocate. Not even you example is that crass, your program would never get
to the X(1) = 10.

BTW, there are easier ways to force a protection exception.

Quote:

> > If it's Enterprise PL/I, you get STORAGE, if its OS PL/I or PL/I for
MVS,
> > you get ERROR. You will not get a protection exception (8094) as a
result
> of
> > a memory allocation error; you would need another bug for that.

> (snip discussion about protection exception and allocation)

> Wouldn't you get a protection exception if memory allocation failed, but
you
> tried to use it anyway?

> DCL X(1000000000) CONTROLLED;

> ON ERROR;

> ALLOCATE (X);

> X(1)=10;

Thu, 08 Dec 2005 22:04:07 GMT

Glen Herrmannsfeld
#12 / 20

Memory Allocation

Quote:

> You'd need to explicity GOTO out of the ERROR to a location where you then
> deliberately used the memory that you'd just been told you couldn't
> allocate. Not even you example is that crass, your program would never get
> to the X(1) = 10.

That sounds familiar. For some ON units you can ignore them that way, and
some you can't?

Quote:

> BTW, there are easier ways to force a protection exception.

Yes, but the question had to do with what happens when allocation fails.

Quote:

> > DCL X(1000000000) CONTROLLED;

> > ON ERROR;

> > ALLOCATE (X);

> > X(1)=10;

Fri, 09 Dec 2005 13:58:39 GMT

Mark Yudki
#13 / 20

Memory Allocation

You need to code something like:

dcl p ptr;
dcl x (500000000) fixed bin (31) based (p);
dcl y (500000000) fixed bin (31) based (p);
on error goto BombOut;
alloc x set (p);
p = null();
alloc y set (p);
BombOut:
p -> y (1) = 0;

Quite a lot of work, you could just have easily have left out most of the
code. Note that the goto is mandatory, and the program is failing not
because of the allocation error but because of the bad error handling. This
is clearly a different sort of bug.

BTW, when I ran:
splat: proc options (main reentrant) reorder;
dcl p ptr;
dcl x (500000000) fixed bin (31) ctl;
dcl y (500000000) fixed bin (31) ctl;;
on error goto BombOut;
p = null();
alloc x; alloc y;
BombOut:
y (1) = 0;
end splat;

on W2K under VA PL/I 2.1.10, the program actually went into a loop after
issuing the message:

IBM0451I ONCODE=0451 The STORAGE condition was raised.
At offset +000000D4 in procedure with entry SPLAT

(The alloc for x succeeds, and making it >4GB leads to a compile-time error)

Quote:

> > You'd need to explicity GOTO out of the ERROR to a location where you
then
> > deliberately used the memory that you'd just been told you couldn't
> > allocate. Not even you example is that crass, your program would never
get
> > to the X(1) = 10.

> That sounds familiar. For some ON units you can ignore them that way, and
> some you can't?

> > BTW, there are easier ways to force a protection exception.

> Yes, but the question had to do with what happens when allocation fails.

> > > DCL X(1000000000) CONTROLLED;

> > > ON ERROR;

> > > ALLOCATE (X);

> > > X(1)=10;

Sat, 10 Dec 2005 13:45:06 GMT

Glen Herrmannsfeld
#14 / 20

Memory Allocation

Quote:

> You need to code something like:

> dcl p ptr;
> dcl x (500000000) fixed bin (31) based (p);
> dcl y (500000000) fixed bin (31) based (p);
> on error goto BombOut;
> alloc x set (p);
> p = null();
> alloc y set (p);
> BombOut:
> p -> y (1) = 0;

> Quite a lot of work, you could just have easily have left out most of the
> code. Note that the goto is mandatory, and the program is failing not
> because of the allocation error but because of the bad error handling.
This
> is clearly a different sort of bug.

? 1 CTL: PROC OPTIONS(MAIN);
? 2 DCL X(32000) FIXED BIN(31) CTL;
? 3 DCL I FIXED BIN(31);
? 4 ON ERROR GOTO XXX;
? 6 ON FINISH GOTO XXX;
? 8 PUT SKIP LIST('HI THERE!');
? 9 DO I=1 BY 1;
? 10 ALLOCATE X;
? 11 END;
? 12 XXX:
? PUT SKIP LIST('HI THERE!',I);
? 13 X(1)=0;
? 14 PUT SKIP LIST('HI THERE!',I);
? 15 END CTL;

I tried this with PL/I (F). Even adding the ON FINISH didn't stop it from
abend S80A, though PL/I traps that and prints out its own message telling me
that it abended 80A.

Even FINISH isn't strong enough to get control back, though.

-- glen

Sat, 10 Dec 2005 14:13:53 GMT

Mark Yudki
#15 / 20

Memory Allocation

IIRC, PLI(F) is neither LE-enabled, nor is it capable of recovering from all
ABENDs. Even OS PL/I couldn't recover from all ABENDs (the worst being the
x13 that comes from trying to read a non-existent member of a PDS). IBM once
fixed this in OS PL/I, then a customer complained that it wasn't compatible,
and IBM fixed the fix to retain the unrecoverable ABEND. The atual fix to
recover from (almost) all ABENDs (operator cancellation is not recoverable)
came woth PL/I for MVS and VM and LE. Ryan says he has z/OS.

As you say, your program does not generate a protection exception resulting
from an allocation failure, rather you get the 80A.

Quote:

> > You need to code something like:

> > dcl p ptr;
> > dcl x (500000000) fixed bin (31) based (p);
> > dcl y (500000000) fixed bin (31) based (p);
> > on error goto BombOut;
> > alloc x set (p);
> > p = null();
> > alloc y set (p);
> > BombOut:
> > p -> y (1) = 0;

> > Quite a lot of work, you could just have easily have left out most of
the
> > code. Note that the goto is mandatory, and the program is failing not
> > because of the allocation error but because of the bad error handling.
> This
> > is clearly a different sort of bug.

> ? 1 CTL: PROC OPTIONS(MAIN);
> ? 2 DCL X(32000) FIXED BIN(31) CTL;
> ? 3 DCL I FIXED BIN(31);
> ? 4 ON ERROR GOTO XXX;
> ? 6 ON FINISH GOTO XXX;
> ? 8 PUT SKIP LIST('HI THERE!');
> ? 9 DO I=1 BY 1;
> ? 10 ALLOCATE X;
> ? 11 END;
> ? 12 XXX:
> ? PUT SKIP LIST('HI THERE!',I);
> ? 13 X(1)=0;
> ? 14 PUT SKIP LIST('HI THERE!',I);
> ? 15 END CTL;

> I tried this with PL/I (F). Even adding the ON FINISH didn't stop it from
> abend S80A, though PL/I traps that and prints out its own message telling
me
> that it abended 80A.

> Even FINISH isn't strong enough to get control back, though.

> -- glen

Mon, 12 Dec 2005 13:53:38 GMT