Start with their user profile authority, it should list *SPLCTL as a Special authority.
If they have that, they may not be authorized to the outq. Need a little more specific detail as to how they’re trying to access and move the spool file.
There is no authority to copy spooled files between systems. First, two systems are involved so two sets of authorities are needed, not necessarily for the same profile.
Second, authorities begin with access to the the spooled files. If the programmer created them, then s/he already has all necessary authority since owners are authorized to their own spooled files. If someone else owns them, then whatever authorities are needed to manipulate spooled files for that owner might be required. (Is the owner an *ALLOBJ profile?)
And authority might be needed to access the output queue or the output queue’s library. Or spooled files on that output queue.
Those authorities could be covered by allowing *SPLCTL, but that grants authority to <b>all spooled files</b> from every user, not just ones that might be copied to another system. Since it’s a development system, that’s probably not an issue.
Then would come potential communications obstacles. Is the programmer blocked from sending information out from the system? Is the programmer blocked on the remote system? Overcoming those would depend on the mechanism. Exit programs might be in place, and you’d have to look at their documentation for steps to open any blocks that would be in place.
Next, what method is used for the transfer? There would be three that would be common — SNDNETSPLF, SNDTCPSPLF and remote output queue.
SNDNETSPLF is the old SNADS method of transferring spooled files. The programmer would an entry in the system directory in order to start the request. There would also need to be an entry that would determine who the recipient would be on the remote system. (That might best be via a ‘generic’ entry on the source system.) The actual recipient would need to have an individual entry in the system directory on the target system, but that gets away from any ‘authority’ for the programmer.
SNDTCPSPLF is based on LPR/LPD, pretty much the same as remote output queue. If authority exists to access the spooled files, then basic object authority to the command itself is about all that’s needed. As long as the remote system has no communications block, there should be no authorities involved. The programmer doesn’t even need to be defined on the remote system.
Everything for SNDTCPSPLF goes as well for remote output queue.
Perhaps the question isn’t so much about what authority is needed, and it’s more “Why isn’t it working for us?” If that’s the case, then a description of what has been configured, what actions are being attempted and what error messages are seen would be useful. If error messages are given, the message identifiers need to be included.