Does the same problem show up if you start a new job before calling the program? There is no intelligence in the example code. If, for example, you run the program in a job that has tens of thousands of messages already in the *EXT message queue, it could take a significant amount of time for the program to look through them all.

Which “telnet” are you referring to? There are two “telnets” in the job — you start with the first telnet session, then you call a program that starts a second telnet session to another system. Which one are you ending? How are you ending it? Which system sees “60% cpu usage”?

Tom

Tanx

No, it’s just a little shortened. It tests for the condition where &MsgId equals a blank. The RCVMSG command will return a blank value in the MSGID() parameter when there are no more messages to receive and the WAIT() time is expired. The default WAIT() time is zero. You could put seven blans between the quotes since &MsgId is a 7-byte character variable, but the *EQ condition will happen if it’s one blank or seven blanks.

I just coded a DOUNTIL for the automatic looping structure. If it runs out of messages, it will drop out of the loop.

Tom

Since CPF8902 is sent as a *DIAG message, you can’t use MONMSG. You can only monitor for *ESCAPE, *STATUS and *NOTIFY messages.

For anything else, you need to receive the messages from the appropriate queue. Use the RCVMSG command or the Receive Program Message (QMHRCVPM) API to receive those messages.

Tom

pgm

   dcl   &MsgId       *char     7
   dcl   &RmtSys      *char   256     value( 'CCCAMCV' )
   dcl   &RmtVrtDsp   *char    10     value( 'OPERACAO' )

   telnet      rmtsys( &RmtSys ) rmtvrtdsp( &RmtVrtDsp )

   dountil   ( &MsgId *eq ' ' )
      rcvmsg   pgmq( *EXT ) msgtype( *DIAG ) msgid( &MsgId )
      if ( &MsgId *eq 'CPF8902' )  do
         telnet rmtsys( &RmtSys )
         leave
      enddo
   enddo

   return

endpgm

Change the value for &RmtSys when you want a different system. Change the value of &RmtVrtDsp when you want a different device.

You should be able to compare messages in your joblog to the parms for RCVMSG to learn some of what’s happening. Run TELNET from a command line a couple times and look at the message details for all messages it sends.

However, the code is not complete. It doesn’t account for what may happen if you run it multiple times in the same job, especially if other TELNET commands have been run; and it doesn’t do a good job of managing the messages in the *EXT message queue.

Part of the problem is that the information it uses comes from the job’s *EXT message queue. Messages can get placed there by anything running in the job.

Another part is that you need to look at *DIAG (diagnostic) messages. Those are received in first-in/last-out sequence. The first *DIAG messages in the *EXT message queue may have been placed there hours (or days!) before, depending on how long the job has run.

Much more sophistication is possible, but everything has to start from somewhere.

Tom