MCH1210 Message

[Jerry Adams <jerry@xxxxxxxxxxxxxxx>]

Ok, I had a problem this morning that I really don't expect anyone to be 
able to help me with, but the insight of the group members never ceases 
to amaze me so here goes.


During a process, a CL program is run which does nothing more than 
create a file if it does not exist:

PGM        PARM(&LIBR &FILE)                                  
DCL        VAR(&LIBR) TYPE(*CHAR) LEN(10)                     
DCL        VAR(&FILE) TYPE(*CHAR) LEN(10)                     
                                                             
DLTF       FILE(&LIBR/&FILE)                                  
MONMSG     MSGID(CPF2105)                                     
                                                             
CRTPF      FILE(&LIBR/&FILE)                                 +
            SRCFILE(BNWPRINT/QDDSSRC) SRCMBR(PKTKNM)        +
            OPTION(*NOSRC *NOLIST *NOSECLVL                 +
            *NOEVENTF) SIZE(10000 10000 100)                 
CHGOBJD    OBJ(&LIBR/&FILE) OBJTYPE(*FILE) TEXT(&FILE)        
                                                             
ENDPGM                                                        


It blows up on the CRTPF command with an MCH1210 (Receiver value too 
small to hold result).  I have legitimately seen this error in an ILE 
RPG program when the result of an EVAL is too small to hold the 
resulting calculation.  Just to be certain that this CL was the one that 
reported the error (it is part of a 36 procedure that is full of LOAD's, 
36 commands, and CL's), I put the program under debug.  The &LIBR and 
&FILE parameters were what I expected them to be (specifically and 
respectively, QS36F and A.ONAMD2).  The 36 procedure line, by the way, 
which invokes the CL is: CALL PGM(CRTPKTKON) PARM(?FLIB? 
?L'1,1'?.ONAM?WS?); the first byte of the LDA contains the group file id 
('A' in this case).

But it gets a little weirder.  I ran this procedure three [3] times and 
received the same error.  I ran it a fourth and fifth time flawlessly. 

This is, by the way, a pretty common (several times a day) process in 
our company, and it has never reported an error of this nature.  
Although I have had no complaints from users (I was running it as part 
of a test), if there is/are any inherent bugs that anyone notices, I 
would like to correct them before I leave for COMMON tomorrow.  Or, at 
least, put my boss (an Access / VB programmer) on alert with a remedy.

Thanks.