Author |
Message |
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 |
|
|