|
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 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.