If you want to selectively reject allocation requests, you can set installation reject reason codes in the exit parameter list and allow the IEF274I and IEF275I messages or the corresponding dynamic allocation reason codes (X'47B0' and X'47B4') to appear, rather than creating your own messages from the exit. It might be better to have a message or code that is documented in a standard publication and then document the rejection reason codes locally, than to have a completely new message. That way the user can look up the IEF messages in z/OS MVS System Messages, Vol 8 (IEF-IGD) to understand why the job failed. If you do create your own message, make the contents self-explanatory so that separate documentation is not necessary.

Sometimes it helps to provide additional information. For example, if you are monitoring how much DASD space is used by a specific user or set of users, you might want to document the current running space total issued when you reject a job that asked for space that would make its total too high. Then the user has some basis on which to make a decision- perhaps to resubmit the job and ask for less space on that DD statement. This type of space management function is better performed using ACS routines, which are described in z/OS DFSMSdfp Storage Administration.

If your installation has someone who monitors I/O-related messages, you might want to produce a warning message when a running space total is getting close to being exceeded. There is little point in putting this message on the user's listing unless that user is the only one whose space is being accumulated against that identifier. A warning message sent to the appropriate routing code alerts a space manager that a space shortage problem is imminent.