Or "MOM_output_to_listing_device", which writes to the "Information" window (which you can later print for reference of the issues you have to fix).
Personally, I tend to _prefer_ to NOT use MOM_abort - as you only find the ONE error that caused the abort. User fixes that one issue, reposts, gets another MOM_abort. Fix that issue, post, another MOM_abort. - user is debugging CAM file one issue at a time.
The nice thing about MOM_output_to_listing_device is you can list all the errors. Using mom_operation_name (and/or mom_tool_name), user can be told where issues are. Post once, then user can fix a bunch of issues. Post again, fix another bunch of issues. So in in a couple "post" commands, all issues can be found/fixed.
You could set a variable, and if any issues that are serious enough, you can delete the posted code in the "end of program" event (so user can't download it to machine).
Note I *do* use MOM_abort *occasionally*- e.g. on 5 axis machine if no vald rotary axis position exists for some orientation, or other REALLY serious error.
Ken Akerboom Sr CAx Systems Engr, Moog, Inc.
Production: NX10.0.3.5 MP16/TC11.2 I'd rather be e-steamed than e-diseaseled