RE: Mysterious MCH3601 errors at V4R3M0

Dave,

Yes, you should pass definitely pass *OMIT. This is also true for the 
bound call to the date API you described in your other post.  I believe 
this is documented in the system API reference under passing 
omissible parameters.  I guess that the APIs want a *NULL pointer 
or bad stuff can happen.

David Morris

>>> "Leland, David" <dleland@Harter.com> 08/11/99 08:35AM >>>
Well, that could explain my problem.  I'm using CEEDOD and only passing
in the 6 required parameters.  Do I need to pass in *OMIT for the
seventh parameter which is omissible?

Thanks,
Dave

> ----------
> From:         David Morris[SMTP:dmorris@plumcreek.com] 
> Reply To:     MIDRANGE-L@midrange.com 
> Sent:         Tuesday, August 10, 1999 11:15 AM
> To:   MIDRANGE-L@midrange.com 
> Subject:      RE: Mysterious MCH3601 errors at V4R3M0
> 
> Hans,
> 
> Although this doesn't anser Don's question, I have seen this error 
> caused by not passing *OMIT to the CEETSTA API.  I know this can 
> type of error can be caused by simply not passing a parameter for 
> any CEE API parameter that specifies that it is omissible.  To 
> correct this error you must specify *OMIT, even if it is the last
> parameter 
> passed.  Even the people who wrote the sample code for the RPG 
> manuals incorporated this bug. Failure to pass *OMIT can cause 
> memory to be corrupted in the most unlikely places (experience tells 
> me x'0000' may pop up in user spaces or static program variables.)
> 
> David Morris
> 
> >>> <boldt@ca.ibm.com> 08/10/99 08:17AM >>>
> 
> 
> Don wrote:
> >It also doesn't explain why, when converted from RPGIV to RPGIII, it
> >magically starts working.  If there is no bug in the RPGIV compiler,
> as Hans
> >claims, why does this solution work?
> 
> Sure it explains it.  Some program in the application is
> corrupting some area of storage.  By changing the affected
> program (not the buggy program) to an RPG III program, the
> corruption is happening in some storage which does not
> manifest itself in the same way.  The problem is still
> there, lurking quietly, waiting for the opportunity to pop
> up again when some other condition changes.
> 
> As I stated before, we've seen several reports of
> "mysterious MCH3601" problems and they've all turned out to
> be bugs in the application, not in the ILE RPG compiler or
> run-time.  I'm not trying to deflect criticism away from
> RPG, but our experience tells us that the most likely
> source of the problem is somewhere in the application.  I
> know from my own experience, that this type of problem is
> the hardest to debug.
> 
> 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
+---