Reports not Being Produced, Following Seeing RMOSOR03 and RMOSOR04 Error Messages

Document ID : KB000124073
Last Modified Date : 03/01/2019
Show Technical Document Details
Issue:
In an application job run, the customer started receiving RMOSOR03 and RMOSOR04 error messages (with ERROR 2308), and reports stopped being produced by the job: 

 . RMOSOR03 Allocation failed bundle hold report XXXXXXXX-XXX - ERROR 0238 INFO 00
​​​​​​ . ​RMOSOR04 Allocation failed archival of report XXXXXXXX-YYY - ERROR 0238 INFO 00

The matter is an issue with the dynamic allocation of too many DD statements within the application job step.

The client has the TIOT value set to the maxium of TIOT(64).
 
Environment:
CA Deliver - All Releases
Resolution:
The RMOSOR03 and RMOSOR04 messages, with ERROR 0238, indicate that the TIOT is full.
The 0238 is the return code from Dynamic allocation, and it means that space is unavailable to the TIOT.
The default value is 32K (or 1634 DD statements), and the size of the TIOT determines how many DDs can be allocated per jobstep.

The majority of the reports in the client's database were sent to the spool, for further processing, using RMOPARM "ARCHn=A////ACIF", with very little being written directly to CA View (ARCHn=DIRECT[/...]).
Doing direct archival would mean that View would be holding the bundle holding copies, which would significantly reduce the number of data set allocations, which would reduce the number of required TIOT entries.

For a Deliver Report Definition, in the Distribution ID section, for each occurrence of an OUT field of Y a DD statement is allocated.
In one of the client's jobs in question, the allocation of DDs reached 3267 (IEF237I JES2 ALLOCATED to SYS00020 through IEF237I JES2 ALLOCATED to SYS03286), and then the first RMOSOR03 (Allocation failed) message was generated.

It was suggested to the client that they should find some way of breaking up the application job's processing, so as to have more steps, so that the number of DDs can be decreased for the problem step.

The client's group that handles the report administration, instead, performed some cleanup of old segments.
As a result, the job has since run without receiving any of the RMOSORnn messages.