• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 762
  • Last Modified:

TFRJOB failes - Job not transferred. System request in effect for job.

I have a simple routing program that based on the device name it transfers the job to the appropriate subsystem.

The problem is that if the user does a system request 1 then signs on to the secondary session with a user profile that envokes my routing program the TFRJOB in my routing step fails (CPF1373 - Job not transferred. System request in effect for job) and then the routing program gets called again.

Is there a way I can tell that the signon is from a system request 1? This way I can just process the request instead of transfering the job.

/*                                                                  */
             DCL        VAR(&DEVICE) TYPE(*CHAR) LEN(10)              
             MONMSG     MSGID(CPF0000)                                
/*                                                                  */
/* If a scan device transfer to QINTERW                             */
/*                                                                  */
             RTVJOBA    JOB(&DEVICE)                                  
             IF         COND(%SST(&DEVICE 1 4) = 'SCAN') +            
               TFRJOB     JOBQ(QINTERW)                               
               GOTO       CMDLBL(@END)                                
//*                                                                  */ 
/* If not apply default routing                                     */ 
/*                                                                  */ 
             TFRJOB     JOBQ(QINTER) RTGDTA('QCMDI')                   
 @END:       ENDPGM

Open in new window

Bob Hoffman
Bob Hoffman
  • 2
1 Solution

Assuming that the first TFRJOB is correct, I don't quite get the purpose of this command:


I would expect this command instead:


What subsystem is this associated with? Actually, why is there a routing program at all if the routing is controlled by device names anyway? Why not just route via workstation name or type entries? (Perhaps because the names don't fit 'generic' expectations?)

Bob HoffmanDeveloperAuthor Commented:
Workstation name/type entries are not feesible for other reasons to complicated to explain here. The custom routing program is in QINTER, the idea was to route it back through QINTER and force it through the standard routing program if it wasn't a device the starts with 'SCAN'. The users associated with the routing programs are all on hand-helds so the system request issue never came up.  That said.. switched it to TFRCTL, works great! Thanks for the help


Minor added note... the TFRCTL not only reduces routing workload, etc., but also clears your custom routing program from the call stack. Makes for a fairly clean job all around. The TFRCTL probably ought to be enforced even for unexpected error conditions.

One use that I make is to have a "BBS" kind of display -- when I enable it (usually via a *DTAARA value), it inserts a message window with whatever text I choose, e.g., [System will be brought down at 5:30 PM for maintenance today.]

Glad it worked for you.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now