Marc,

>>  I'm seeing the following error message in some job logs.
>> Receiver value too small to hold result.
>> Function check. MCH1210 unmonitored by QEXCAFI at statement *N,
>> This is running in the 36 environment on a 620 at V4R2
>> with the latest CUM Cd.

The fact that the QEXCAFI program isn't handling this MCH1210 exception makes
it a bug, so you should call it in to support. I don't own QEXCAFI, but I did
copy the listed owner of this program on this note for their awareness. However
you should call this problem in to AS/400 support to make sure the problem gets
tracked and responded to correctly.

--------> Start rambling digression <------------
As to what the error is about ... this is another "bug or feature" of the
AS/400, depending on what end of the problem report you're viewing it from. <g>

On all the computing platforms I worked on prior to AS/400, the difference
between a signed and an unsigned binary number made a difference when doing
some conversion operations or arithmetic ops. But it was always ignored when
doing an assignment (store to memory) operation.  On an AS/400 though, this is
NOT the case. The default behavior is that the hardware will detect an attempt
to store a signed negative value into an unsigned variable. If this happens,
exception MCH1210 is signalled.

For example, the following C code would probably run just fine on a PC, but
will abend with MCH1210 on AS/400.
 signed int a = -1;
 unsigned int b;
 b = a;   /* MCH1210 -- ka-booom! *./

I originally viewed this as a bug because ... !@#$%^-it all ... the hardware
wasn't doing what I wanted it to. But now ... after maturing a little <g> ... I
view the MCH1210 as a valuable feature. A sometimes annoying feature because I
have to be extra careful to make sure my code matches my intent, but valuable
none-the-less.

The AS/400 hardware does more run-time type checking than your typical WinTel
beast. This helps ensure that some common logic errors are detected when they
occur, rather than 1,000 instructions and 3 procedure calls later.  It makes
them much easier to fix.
--------> End of  rambling digression <------------

For what it's worth,
-john martz
IBM AS/400 TCP/IP PPP development (and stuff)
Internet e-mail:                     jmartz@us.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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.