If PGMA calls RPG3P then is still interactive, and you should see the message in your joblog.
If PGMA does a SBMJOB of RPG3P, or RPG3P submits a different job then you have created a 2nd job that would be batch.
I will assume the second.
The Batch job should have a message in QSYSOPR unless you are doing a MONMSG or using SYSRPLL to automatically answer the message.
You need to change the logging level in your batch job to LOG(4 00 *SECLVL) LOGCLPGM(*YES)
You can either do that on the SBMJOB command or change it while it is running or in the job queue.
Then it should produce enough information in your joblog to tell you what is going on.
Messages sent to a program message queue can be retrieved from a job’s external message queue if the message was promoted to the external message queue. However, if the message was received and removed, then it is gone and cannot be retrieved.
If RPG3P is no longer in the call stack, then its program message queue no longer exists. Even if the message was not removed, if it wasn’t promoted, it won’t be available. “Standard error” routines commonly handle promotion of messages in order to avoid losing them.
Also, a job might abort from an exception, but no message was ever sent. (E.g., an API may return an exception message identifier in the error code data structure — there is no message in the program message queue nor the job message queue unless the caller of the API puts a message there.)
Determining the cause will require knowing how the programming detects and handles exceptions. Most often, the exception will appear in the job external message queue (often called the “joblog”).
Note that it might be better not to specify LOGCLPGM(*YES). There might be no CL in the job. There might be a lot of CL executed in a loop so that the CL requests overwhelm all other messages. CL programs might be compiled as LOGCLPGM(*NO). Just keep in mind that it might or might not be appropriate.