× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Mysterious MCH3601 errors at V4R3M0
  • From: "Robin Sapiro" <robin.sapiro@xxxxxxxx>
  • Date: Sat, 7 Aug 1999 22:57:03 -0400

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.


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


>
>
> Robin wrote:
> >I have an ILE RPG program that is a registered exit program for one of
the
> >VI/400 exit points. It is called with 4 parameters. It is called MANY
times
> >every day. For the first 6 weeks after implementation it ran without
> >failure. Since then it has experienced intermittent failures. Sometimes
> >several times a day, sometimes only every 3-4 days. The failure is always
> >the same. MCH3601. It always occurs on the first line of executable code.
> >
> >C                 MOVE   PARM3    DATASTRUCTURE
> >
> >PARM3 is unreferenced.
> >
> >Any good ideas would be greatly appreciated.
>
> I assume you asked for a dump when you got the error?  Was PARM3
> actually addressable?  In other words, was there really a parameter
> passed?  That's the obvious interpretation.  If a parameter really
> was passed on the call, then I have no idea what could be causing
> the problem.
>
> One more thing:  Have you determined what changed after the first
> six weeks?  It could be some other program clobbering the stack
> space of this program.  So, check the compile dates of other
> programs and modules in the application.  As you know, these types
> of bugs are the most challenging ones to solve.  The difficulty in
> debugging these problems is that the bug is not normally where the
> failure occurs.  In addition to checking for parameter mismatches
> and mismatched import/export, also check how based variables are
> used.
>
> 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.