Assuming your process retains the user as the owner of the spool file, it's going to be difficult to prevent the owner from managing spool files it has created. If WRKSPLF sends a DLTSPLF command, you'd be able to examine the command using the QIBM_QCA_CHG_COMMAND exit point and change it if the command was pointed at an archive output queue, but if it calls the delete spool file api directly that won't help.

If you're using the QSPCRTSP to duplicate the spool file, you might consider changing the owner (creating the duplicate under a spool archive user profile), retain the originating job info in the USRDFNDTA, and changing the archive output queue to allow public display of its entries (AUT(*USE), DSPDTA(*YES)).

 

 

 

Change the Owner is the solution but I could swear someone told me there was a way to attach a data queue to a specific OUTQ and then monitor that data queue--I could then change the owners at things were added to the OUTQ (and even change to SAVE(*YES) so that they won't evaporate if inadvertently printed.)

Apparently there is a DTAQ parameter on OUTQ De!--script--ions. But it only signals when the SPOOL file is in RDY (ready) state. I need it even if the SPOOL file is created in SAV state.

Isn't that (DTAQ entry written only when the spool file goes to RDY state) what put you on a path to looking at the QIBM_NOTIFY_CRTSPLF environment variable? Have you considered swapping the order of events- writing the original spool file to the archive output queue under a different user profile to prevent it from being deleted, and using the data queue entry to create a duplicate spool file back to the originating user?