U4083 
Author Message
 U4083

I have this dead-simple PL/I program (written today) that reads a VSAM
file with a generic key then sequentially thereafter.  It compiles and
links apparently A-OK, then crashes U4083 the instant it starts.  In
desperation I yanked all the code except the DCLs and ON-units; it
runs fine.  The instant I ask it to do any real work -- POOF!

I have no clue what a U4083 is nor any idea where to go RTFM.  Any
advice gladly received.  

This is the symptom dump:
+CEE0374C CONDITION = CEE3204S TOKEN = 00030C84 59C3C5C5 00000000
          WHILE RUNNING PROGRAM UNKNOWN
          AT THE TIME OF INTERRUPT
          PSW     078D0E00 C000DB76
          GPR 0-3 000266D8 1110142C 91101200 111012E8
          GPR 4-7 0000042D 0000019C 00026390 00026390
          GPR 8-B 0000EA6A 11101700 00000001 0000EA6A
          GPR C-F 00009B10 000265E8 C000DB76 87D7C97E
IEA995I SYMPTOM DUMP OUTPUT
  USER COMPLETION CODE=4083 REASON CODE=00000004
 TIME=16.02.18  SEQ=59935  CPU=0000  ASID=0078
 PSW AT TIME OF ERROR  078D1E00   876F2E88  ILC 2  INTC 0D
   NO ACTIVE MODULE FOUND
   NAME=UNKNOWN
   DATA AT PSW  076F2E82 - 00181610  0A0D9500  C39D4770
   AR/GR 0: 00000000/84000000   1: 00000000/84000FF3
         2: 00000000/00006ED0   3: 00000000/11115740
         4: 00000000/00000000   5: 00000000/11116DB8
         6: 00000000/000265E8   7: 00000000/00000000
         8: 00000000/11116A70   9: 00000000/00000004
         A: 00000000/00000001   B: 00000000/876F2238
         C: 00000000/00009B10   D: 00000000/11115D40
         E: 809FA03C/876F2E76   F: 00000000/00000004
 END OF SYMPTOM DUMP



Sun, 03 Apr 2005 05:38:08 GMT  
 U4083

Its years (15) since I worked on a mainframe.

The msg about "no active module found" catches my attention though.

Are you (or something you call) doing a PL/I "fetch"  (or "release") ?

Quote:

>I have this dead-simple PL/I program (written today) that reads a VSAM
>file with a generic key then sequentially thereafter.  It compiles and
>links apparently A-OK, then crashes U4083 the instant it starts.  In
>desperation I yanked all the code except the DCLs and ON-units; it
>runs fine.  The instant I ask it to do any real work -- POOF!

>I have no clue what a U4083 is nor any idea where to go RTFM.  Any
>advice gladly received.  

>This is the symptom dump:
>+CEE0374C CONDITION = CEE3204S TOKEN = 00030C84 59C3C5C5 00000000
>          WHILE RUNNING PROGRAM UNKNOWN
>          AT THE TIME OF INTERRUPT
>          PSW     078D0E00 C000DB76
>          GPR 0-3 000266D8 1110142C 91101200 111012E8
>          GPR 4-7 0000042D 0000019C 00026390 00026390
>          GPR 8-B 0000EA6A 11101700 00000001 0000EA6A
>          GPR C-F 00009B10 000265E8 C000DB76 87D7C97E
>IEA995I SYMPTOM DUMP OUTPUT
>  USER COMPLETION CODE=4083 REASON CODE=00000004
> TIME=16.02.18  SEQ=59935  CPU=0000  ASID=0078
> PSW AT TIME OF ERROR  078D1E00   876F2E88  ILC 2  INTC 0D
>   NO ACTIVE MODULE FOUND
>   NAME=UNKNOWN
>   DATA AT PSW  076F2E82 - 00181610  0A0D9500  C39D4770
>   AR/GR 0: 00000000/84000000   1: 00000000/84000FF3
>         2: 00000000/00006ED0   3: 00000000/11115740
>         4: 00000000/00000000   5: 00000000/11116DB8
>         6: 00000000/000265E8   7: 00000000/00000000
>         8: 00000000/11116A70   9: 00000000/00000004
>         A: 00000000/00000001   B: 00000000/876F2238
>         C: 00000000/00009B10   D: 00000000/11115D40
>         E: 809FA03C/876F2E76   F: 00000000/00000004
> END OF SYMPTOM DUMP

Hugh Gleaves
Philadelphia
USA


Sun, 03 Apr 2005 06:34:33 GMT  
 U4083
U4083 is an LE ABEND.  Look in LE diagnostic ref (I'm not at work now,
and don't have a handy copy).  Could it be a storage overlay (=clobber)
problem?
Quote:

> I have this dead-simple PL/I program (written today) that reads a VSAM
> file with a generic key then sequentially thereafter.  It compiles and
> links apparently A-OK, then crashes U4083 the instant it starts.  In
> desperation I yanked all the code except the DCLs and ON-units; it
> runs fine.  The instant I ask it to do any real work -- POOF!

> I have no clue what a U4083 is nor any idea where to go RTFM.  Any
> advice gladly received.

> This is the symptom dump:
> +CEE0374C CONDITION = CEE3204S TOKEN = 00030C84 59C3C5C5 00000000
>           WHILE RUNNING PROGRAM UNKNOWN
>           AT THE TIME OF INTERRUPT
>           PSW     078D0E00 C000DB76
>           GPR 0-3 000266D8 1110142C 91101200 111012E8
>           GPR 4-7 0000042D 0000019C 00026390 00026390
>           GPR 8-B 0000EA6A 11101700 00000001 0000EA6A
>           GPR C-F 00009B10 000265E8 C000DB76 87D7C97E
> IEA995I SYMPTOM DUMP OUTPUT
>   USER COMPLETION CODE=4083 REASON CODE=00000004
>  TIME=16.02.18  SEQ=59935  CPU=0000  ASID=0078
>  PSW AT TIME OF ERROR  078D1E00   876F2E88  ILC 2  INTC 0D
>    NO ACTIVE MODULE FOUND
>    NAME=UNKNOWN
>    DATA AT PSW  076F2E82 - 00181610  0A0D9500  C39D4770
>    AR/GR 0: 00000000/84000000   1: 00000000/84000FF3
>          2: 00000000/00006ED0   3: 00000000/11115740
>          4: 00000000/00000000   5: 00000000/11116DB8
>          6: 00000000/000265E8   7: 00000000/00000000
>          8: 00000000/11116A70   9: 00000000/00000004
>          A: 00000000/00000001   B: 00000000/876F2238
>          C: 00000000/00009B10   D: 00000000/11115D40
>          E: 809FA03C/876F2E76   F: 00000000/00000004
>  END OF SYMPTOM DUMP



Sun, 03 Apr 2005 09:18:04 GMT  
 U4083
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/CEEA103...

explains the 4083 abend .... whether this helps you solve the problem, I
can't say.

These abends are in the 'Debugging Guide and Run-Time Messages' book in
this list

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/CEE1BK32

George
.ps the above list is for the OS/390 2.10 LE.  If you start at
www.ibm.com/os390 and follow the library link, you can find most of the
OS/390 and z/OS books.

George

Quote:

> I have this dead-simple PL/I program (written today) that reads a VSAM
> file with a generic key then sequentially thereafter.  It compiles and
> links apparently A-OK, then crashes U4083 the instant it starts.  In
> desperation I yanked all the code except the DCLs and ON-units; it
> runs fine.  The instant I ask it to do any real work -- POOF!

> I have no clue what a U4083 is nor any idea where to go RTFM.  Any
> advice gladly received.

> This is the symptom dump:
> +CEE0374C CONDITION = CEE3204S TOKEN = 00030C84 59C3C5C5 00000000
>           WHILE RUNNING PROGRAM UNKNOWN
>           AT THE TIME OF INTERRUPT
>           PSW     078D0E00 C000DB76
>           GPR 0-3 000266D8 1110142C 91101200 111012E8
>           GPR 4-7 0000042D 0000019C 00026390 00026390
>           GPR 8-B 0000EA6A 11101700 00000001 0000EA6A
>           GPR C-F 00009B10 000265E8 C000DB76 87D7C97E
> IEA995I SYMPTOM DUMP OUTPUT
>   USER COMPLETION CODE=4083 REASON CODE=00000004
>  TIME=16.02.18  SEQ=59935  CPU=0000  ASID=0078
>  PSW AT TIME OF ERROR  078D1E00   876F2E88  ILC 2  INTC 0D
>    NO ACTIVE MODULE FOUND
>    NAME=UNKNOWN
>    DATA AT PSW  076F2E82 - 00181610  0A0D9500  C39D4770
>    AR/GR 0: 00000000/84000000   1: 00000000/84000FF3
>          2: 00000000/00006ED0   3: 00000000/11115740
>          4: 00000000/00000000   5: 00000000/11116DB8
>          6: 00000000/000265E8   7: 00000000/00000000
>          8: 00000000/11116A70   9: 00000000/00000004
>          A: 00000000/00000001   B: 00000000/876F2238
>          C: 00000000/00009B10   D: 00000000/11115D40
>          E: 809FA03C/876F2E76   F: 00000000/00000004
>  END OF SYMPTOM DUMP



Sun, 03 Apr 2005 10:27:19 GMT  
 U4083


Quote:
>I have this dead-simple PL/I program (written today) that reads a VSAM
>file with a generic key then sequentially thereafter.  It compiles and
>links apparently A-OK, then crashes U4083 the instant it starts.  In
>desperation I yanked all the code except the DCLs and ON-units; it
>runs fine.  The instant I ask it to do any real work -- POOF!

Answer:  It was actually running.  It picked up the right record then
another then another....  When the key changed and the format changed,
the data on the next record was different, I picked up a bad value and
indexed into an array way the hell out yonder... S/0C4

LE, unfortunately, doesn't say "S/0C4"; it says "U/4083".  The PL/I
program's "ON ERROR SNAP BEGIN;" never gets control (why?) so I never
get diagnostics from my own code.

Is LE supposed to be an improvement?



Mon, 04 Apr 2005 06:00:38 GMT  
 U4083
Uh yes it is SUPPOSED to be.

LE intercepts almost all abend codes, and it causes more problems for
System Programmers trying to help application programs because of that.

I don't remember the exact syntax, but you can turn of LE's interrupt
handler for testing.
it is done in the Parm option of the EXEC statement and is coded before
your programs normal parm. A slash separates the two.

The only good thing about LE is that some langauges got new runtime
functions, because LE had to supply all runtime functions for all
supported high-level languages - and any supported language can use any
LE function. Figuring out that the function exists, and how to call it
is another matter - RTFM (Read The Fine Manual) is a requirement. No
manual?  Go to IBM's site. They are all there now-a-days.

The only bad thing about LE is that it sometimes actually helps with its
messages (but not often enough)!

/s/ Bill Turner, retired.

Quote:

>Is LE supposed to be an improvement?



Mon, 04 Apr 2005 11:24:58 GMT  
 U4083
Assemble and force-link (to ensure the CSECT is in the target) the following
assembler routine into your program:

[Tweak the heap and stack if you wish].

*/********************************************************************/
*/*                                                                  */
*/*  SET UP DEFAULT LANGUAGE ENVIRONMENT OPTIONS FOR COGENT/SQL      */
*/*                                                                  */
*/*  ORIGINAL VERSION: MARK YUDKIN 23/02/1998                        */
*/*                                                                  */
*/********************************************************************/
CEEUOPT  CSECT
CEEUOPT  AMODE ANY
CEEUOPT  RMODE ANY
         CEEXOPT DEPTHCONDLMT=(0),                                     X
               ERRCOUNT=(0),                                           X
               HEAP=(8M,4M,ANYWHERE,FREE,8K,4K),                       X
               INTERRUPT=(ON),                                         X
               STACK=(1024K,256K,BELOW,FREE)
         END


Quote:


> >I have this dead-simple PL/I program (written today) that reads a VSAM
> >file with a generic key then sequentially thereafter.  It compiles and
> >links apparently A-OK, then crashes U4083 the instant it starts.  In
> >desperation I yanked all the code except the DCLs and ON-units; it
> >runs fine.  The instant I ask it to do any real work -- POOF!

> Answer:  It was actually running.  It picked up the right record then
> another then another....  When the key changed and the format changed,
> the data on the next record was different, I picked up a bad value and
> indexed into an array way the hell out yonder... S/0C4

> LE, unfortunately, doesn't say "S/0C4"; it says "U/4083".  The PL/I
> program's "ON ERROR SNAP BEGIN;" never gets control (why?) so I never
> get diagnostics from my own code.

> Is LE supposed to be an improvement?



Mon, 04 Apr 2005 14:21:16 GMT  
 U4083

Quote:


> >I have this dead-simple PL/I program (written today) that reads a VSAM
> >file with a generic key then sequentially thereafter.  It compiles and
> >links apparently A-OK, then crashes U4083 the instant it starts.  In
> >desperation I yanked all the code except the DCLs and ON-units; it
> >runs fine.  The instant I ask it to do any real work -- POOF!

> Answer:  It was actually running.  It picked up the right record then
> another then another....  When the key changed and the format changed,
> the data on the next record was different, I picked up a bad value and
> indexed into an array way the hell out yonder... S/0C4

> LE, unfortunately, doesn't say "S/0C4"; it says "U/4083".  The PL/I
> program's "ON ERROR SNAP BEGIN;" never gets control (why?) so I never
> get diagnostics from my own code.

You need to enable SUBSCRIPTRANGE.  And for good measure,
STRINGRANGE, STRINGSIZE, and SIZE also.

- Show quoted text -

Quote:
> Is LE supposed to be an improvement?



Mon, 04 Apr 2005 20:56:36 GMT  
 U4083


Quote:


>> LE, unfortunately, doesn't say "S/0C4"; it says "U/4083".  The PL/I
>> program's "ON ERROR SNAP BEGIN;" never gets control (why?) so I never
>> get diagnostics from my own code.

>You need to enable SUBSCRIPTRANGE.  And for good measure,
>STRINGRANGE, STRINGSIZE, and SIZE also.

What do we do in production?   Are these supposed to be left on even
for production modules?  If so, then LE is revealed as IBM's new
strategy to get everyone to double the size and speed of their CPU and
the amount of their invoice.

"Things that always worked before
  aren't working anymore."



Tue, 05 Apr 2005 09:34:45 GMT  
 U4083
To answer the last question first, IBM *thinks* it was an improvement.
I'd like a recount please.

I looked up 4083-4 and the manual says something about the DSA not being
word-aligned. Unless you have assembler in the mix this is darn-near
impossible, and unlikely even then, so it sounds like the reality is
that your savearea backchain was clobbered by something like - as you
mention - a wild subscript.  It must be that LE checks before doing a
return, and catches this, so you never get to an 0C4.  LE's error
handling is annoying and doesn't mesh too well with PL/I.

When I get to a non-obvious problem like this I usually fall back on
'PARM=TRAP(OFF)/' and a //SYSUDUMP DD.  At least then LE doesn't walk
all over the problem before I get a chance to see it.

Quote:



> >I have this dead-simple PL/I program (written today) that reads a VSAM
> >file with a generic key then sequentially thereafter.  It compiles and
> >links apparently A-OK, then crashes U4083 the instant it starts.  In
> >desperation I yanked all the code except the DCLs and ON-units; it
> >runs fine.  The instant I ask it to do any real work -- POOF!

> Answer:  It was actually running.  It picked up the right record then
> another then another....  When the key changed and the format changed,
> the data on the next record was different, I picked up a bad value and
> indexed into an array way the hell out yonder... S/0C4

> LE, unfortunately, doesn't say "S/0C4"; it says "U/4083".  The PL/I
> program's "ON ERROR SNAP BEGIN;" never gets control (why?) so I never
> get diagnostics from my own code.

> Is LE supposed to be an improvement?



Tue, 05 Apr 2005 19:11:42 GMT  
 U4083

Quote:




> >> LE, unfortunately, doesn't say "S/0C4"; it says "U/4083".  The PL/I
> >> program's "ON ERROR SNAP BEGIN;" never gets control (why?) so I never
> >> get diagnostics from my own code.

> >You need to enable SUBSCRIPTRANGE.  And for good measure,
> >STRINGRANGE, STRINGSIZE, and SIZE also.

> What do we do in production?   Are these supposed to be left on even
> for production modules?

The overheads are generally small.  It's a small price to pay
for reslts that are reliable.  Going out-of-bounds in an array
can clobber data, giving wrong results.  Abends are just another
symptom of the problem.

Quote:
>  If so, then LE is revealed as IBM's new
> strategy to get everyone to double the size and speed of their CPU and
> the amount of their invoice.

> "Things that always worked before
>   aren't working anymore."

That's because there's a bug in the program.
There wasn't a test for a subscript out of bounds.


Tue, 05 Apr 2005 21:49:24 GMT  
 U4083


Quote:
>'PARM=TRAP(OFF)/'

Ah!   That must be what Bill Turner was talking about....


Wed, 06 Apr 2005 07:29:44 GMT  
 U4083

Quote:





> >> LE, unfortunately, doesn't say "S/0C4"; it says "U/4083".  The PL/I
> >> program's "ON ERROR SNAP BEGIN;" never gets control (why?) so I never
> >> get diagnostics from my own code.

> >You need to enable SUBSCRIPTRANGE.  And for good measure,
> >STRINGRANGE, STRINGSIZE, and SIZE also.

> What do we do in production?   Are these supposed to be left on even
> for production modules?  If so, then LE is revealed as IBM's new
> strategy to get everyone to double the size and speed of their CPU and
> the amount of their invoice.

As this matter has come up a number of times before,
it bears repeating here.
It is most important to enable SUBSCRPTRANGE in any PL/I program that
uses arrays--

(SUBSCRIPTRANGE):
        PROC OPTIONS (MAIN);

If this is not done, there is the danger of destroying your program,
or of obtaining wrong answers.
A subscript that is out of range will cause data to overwrite
something else, such as another value or some instructions.
If code is overwritten, a PROTECTION INTERRUPT can occur,
or any number of inexplicable errors (often without indication of
line number and other helpful information).  If some value(s)
are overwritten (corrupted), wrong answers may ensue.

So, do you want to waste heaps of time trying to find out where
your programming error occurred?  Do want to trust to providence
that the results are OK?

Other important PL/I conditions that need to be enabled are

STRINGRANGE, STRINGSIZE, AND SIZE.

In Enterprise PL/I in particular, STRINGSIZE needs to be enabled,
or you may find that an assignment to a string of shorter length corrupts
storage.



Fri, 08 Apr 2005 23:52:09 GMT  
 U4083
Why aren't these the defaults then?  If the overhead is small and the
benefits great it would seem that this would be a no brainer.

Am I missing something?

Randy

Quote:

> As this matter has come up a number of times before,
> it bears repeating here.
> It is most important to enable SUBSCRPTRANGE in any PL/I program that
> uses arrays--

> (SUBSCRIPTRANGE):
>    PROC OPTIONS (MAIN);

> If this is not done, there is the danger of destroying your program,
> or of obtaining wrong answers.
> A subscript that is out of range will cause data to overwrite
> something else, such as another value or some instructions.
> If code is overwritten, a PROTECTION INTERRUPT can occur,
> or any number of inexplicable errors (often without indication of
> line number and other helpful information).  If some value(s)
> are overwritten (corrupted), wrong answers may ensue.

> So, do you want to waste heaps of time trying to find out where
> your programming error occurred?  Do want to trust to providence
> that the results are OK?

> Other important PL/I conditions that need to be enabled are

> STRINGRANGE, STRINGSIZE, AND SIZE.

> In Enterprise PL/I in particular, STRINGSIZE needs to be enabled,
> or you may find that an assignment to a string of shorter length corrupts
> storage.



Sun, 17 Apr 2005 04:46:52 GMT  
 U4083

Quote:

> Why aren't these the defaults then?  If the overhead is small and the
> benefits great it would seem that this would be a no brainer.

They probably should be (the defaults).  It's mainly historical,
of course, for when PL/I first came out, memory was small,
typically 32k bytes to 128K bytes, and the extra code was significant.
Also, optimization
wasn't as great then, so savings in time could alco be obtained
by dropping the checks, especially for subscript bounds for
arrays of 2 dimensions or more.
Quote:
> Am I missing something?

> Randy


> > As this matter has come up a number of times before,
> > it bears repeating here.
> > It is most important to enable SUBSCRPTRANGE in any PL/I program that
> > uses arrays--

> > (SUBSCRIPTRANGE):
> >       PROC OPTIONS (MAIN);

> > If this is not done, there is the danger of destroying your program,
> > or of obtaining wrong answers.
> > A subscript that is out of range will cause data to overwrite
> > something else, such as another value or some instructions.
> > If code is overwritten, a PROTECTION INTERRUPT can occur,
> > or any number of inexplicable errors (often without indication of
> > line number and other helpful information).  If some value(s)
> > are overwritten (corrupted), wrong answers may ensue.

> > So, do you want to waste heaps of time trying to find out where
> > your programming error occurred?  Do want to trust to providence
> > that the results are OK?

> > Other important PL/I conditions that need to be enabled are

> > STRINGRANGE, STRINGSIZE, AND SIZE.

> > In Enterprise PL/I in particular, STRINGSIZE needs to be enabled,
> > or you may find that an assignment to a string of shorter length corrupts
> > storage.



Sun, 17 Apr 2005 08:50:09 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. COBOL Report Writer Precompiler with LE (U4083)

 

 
Powered by phpBB® Forum Software