Re: Mysterious MCH3601 errors at V4R3M0

["Robin Sapiro" <robin.sapiro@xxxxxxxx>]

Forgive me if this is a stupid question.

Below is the program stack:

      MYPGMA    ANYLIB            (This is a CLLE pgm)
      MYPGMB    ANYLIB            (This is a RPGLE pgm)
  < alogObject   QVI        0000000052
      Procedure: SimLibCatalogObject
  < eateObject   QVI        0000000378
      Procedure: SimLibCreateObject
  < MSESSIONUs   QVI        0000000850
      Procedure: GDSSendRecv__FP11_SIMSESSIONUs
    ekdcscom     QVI        0000000066
    CsParser     QVI        0000000116
    _C_pep       QVI
    main         QVI        0000000083
    _CL_PEP      ROBINS
    IMG330RG     ROBINS     0000000700

IMG330RG is the program that crashes with the MCH3601.

Given that MYPGMA calls MYPGMB that does a CALLP to the procedure
SimLibCatalogObject in service program QVIAPI in library QVI and that the
program IMG330RG is registered as the exit program for the object created
exit
(called from SimLibCreateObject), how as control passes from one program to
the next
can one of the programs in the stack only sometimes corrupt the stack before
the
first line of executable code.


----- Original Message -----
From: <boldt@ca.ibm.com>
To: <MIDRANGE-L@midrange.com>
Sent: Monday, August 09, 1999 8:48 AM
Subject: Re: Mysterious MCH3601 errors at V4R3M0


> Robin wrote:
> >Got a dump. PARM3 was not addressable. PARM1, PARM2 and PARM4 were
> >addressable and contained the expected data.
> >
> >The exit program is evoked many times a day. The program stack should
always
> >be the same (it is when the program crashes - dont get the chance to
observe
> >it when it works (could put a DSPJOB into the exit program)). If a
program
> >in the stack has changed at the 6 week mark, how does that explain the
> >intermittent failure?? The exit program should always be called in the
same
> >manner.
>
> OK, your program uses PARM3 only to move the data to some other
> field, which is then used to access the data.  So, there is a
> very short window between when the program is called and that
> MOVE happens.  If some other program is corrupting the stack,
> you would only notice the problem if the corruption happens
> during that short window.  When the corruption happens at
> other times, you won't notice it.
>
> The bug is not in the program that fails, but in some other
> program that overwrites some storage it shouldn't.  Check the
> compile dates of other programs in the application to try to
> narrow down the list of suspects.
>
> Cheers!  Hans
>
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
>
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---