RE: MONMSG CPF2130 was: CL program

[rob@xxxxxxxxx]

Actually I like a hard halt versus the generic MONMSG CPF0000 at the top. 
I can often fix the problem, take a retry and let it continue.  However if 
I've already done a MONMSG CPF0000 at the top and bypassed the rest of the 
program I have to figure out how to restart the whole process.

An imbedded MONMSG without a DO is something that really needs to be 
analyzed also.  Just last week I had one out there that was being ignored 
for years.  Went something like.
CRTDUPOBJ FROMLIB(MYLIB) TOLIB(QTEMP)
MONMSG CPF....  no DO
CHGDSPF QTEMP/MYFILE
Yet another MONMSG CPF.... with no DO
See the issue?
Turns out the CRTDUPOBJ was failing because they had only *USE access to 
the display file in the production library and you cannot do a CRTDUPOBJ 
on something you only have *USE access.  Why?  I sure don't know.
What's the point of the MONMSG after the CRTDUPOBJ if you're just going to 
ignore it and assume it worked?  Are we "assuming" that the reason that 
the CRTDUPOBJ failed is because the object already existed in QTEMP?


Rob Berendt