I’m not really sure what you’re trying to do. But it looks to me like your STRPRTWTR command does not like what you’re giving it for the DEV parameter.

It looks like you’re passing a HEX value? (X’000015E0000000000000′)

I know where I work, we have 10(or less) character names for our writers (I.E. “USERPRT1″)

I’d look into what’s getting passed in the &JOBDEV parameter to your second program.

Dave

Hi Dave, thanks for your help.

I don´t know, the parameters was passed after the job received the new message CPF3390.

When I receive the new message CPF3390 I nedd to get the name of device printer to start a command STRPRTWTR

            PGM        PARM(&JOBNUM &JOBNAME &JOBDEV)  

Is this the PGM statement from program TEST/PRT_GET? If so, where did you see that those should be the parameters? I suspect that they came from looking at the CPF3390 message description.

A break-handling program receives three parameters.

• The first parameter is *CHAR (10). It will contain the name of the message queue that break-handler was attached to. A break-handler program can be attached to many different message queues, so it needs to know which message queue has the message that needs to be handled.
• The second parameter is also *CHAR (10). It is the library of the message queue.
• The third parameter is *CHAR (4). It will contain the “message mark” of the message that caused the break. When the break-handling program has all three parameters, it can use RCVMSG to receive a copy of the message that it needs to handle.

But you have the parameters named &JOBNUM, &JOBNAME and &JOBDEV. The values that will be in those parameters won’t be job number, job name and device.

As you can see in the joblog message, you put a value into &JOBDEV that resulted in DEV(X’000015E0000000000000′). The first four bytes came from the message mark that the system passed into your program — X’000015E0′. The remaining six bytes came from whatever was in memory after that, possibly random values.

If you need the device name, you need to receive the message that caused the break by using the message mark. Something like this:

Qsys/rcvmsg     msgq( &MsgQLib/&MsgQ )              +
                  msgkey( &MsgMrk )                 +
                  wait( &MsgWait )                  +
                  rmv( *NO )                        +
                  msg( &MsgTxt )                    +
                  msglen( &MSGLEN )                 +
                  msgdta( &MsgDta )                 +
                  msgdtalen( &MSGDTALEN )           +
                  msgid( &MsgId )                   +
                  sender( &MsgSnd )                 +
                  senderfmt( *SHORT )               +
                  msgf( &MSGF )                     +
                  msgflib( &MSGFLIB )               +
                  rtntype( &MsgRtnTyp )

You probably don’t need to receive all of those parameters, but you should familiarize yourself with each of them. If you will be writing message handling programs, you’re going to use them eventually if not in this program.

After receiving the message, you would test &MsgId to see if it was a ‘CPF3390′ message. If it was, you could probably get the device name from the &MsgDta by taking the substring %SST(&MSGDTA 1 10).

You can tell that those are the likely positions by looking at the message description for CPF3390. It shows three fields. The first field is *CHAR (10), and the message text shows that it is used as the ‘job name’ portion of the qualified job name. You could also simply have your test program dump the &MsgDta field so you could study it to figure out where the pieces are.

There may be more to it that you will want to do. You need to decide if you want to remove the message from the queue when you receive it or after you are done with or if you’re going to leave it on the queue. If you don’t remove it, you need to decide what your program might do when it starts the next time and runs across the message again. And you need to decide what to do when a second message shows up on the message queue when you break-handling program is already busy handling a message. And what will you do with messages that aren’t CPF3390?

But first things first — get your parameters defined appropriately and get the device name from the message data. And remove those four CHGVAR statements at the beginning that put values into your &MSGDTA and &MSGID variables. Let the RCVMSG command do that work.

Tom

Thanks for the help, I really wanted to monitor every time I received the message CPF3390  I execute the command STRPRTWTR with the name of the device that was in status * END

Check out the STRWCH command. We use it to handle a similar situation in our shop.

Bruce Vining published a good article about STRWCH and included a sample program. Wish I could remember where it is.

Here is the first part of the help text:
The Start Watch (STRWCH) command starts the watch for event
function, which notifies the user by calling a user specified
program when the specified event (a message, a LIC log entry or PAL
entry) occurs. PAL stands for Product Activity Log which shows
errors that have occurred (such as in disk and tape units,
communications, and work stations).

Thanks Wood, but my version is V5R3, I don´t know cause this CL not works.

 IF         COND(&MSGID = 'CPF3390') THEN(GOTO +   
              CMDLBL(STARTPRT))                    

STARTPRT:   STRPRTWTR  DEV(PRT_1)                            
            MONMSG     MSGID(CPF3310 CPA3387)                   
            STRPRTWTR  DEV(PRT_2)                            
            MONMSG     MSGID(CPF3310 CPA3387)                   
            STRPRTWTR  DEV(PRT_3)                           
            MONMSG     MSGID(CPF3310 CPA3387)

 IF         COND(&MSGID = ‘CPF3390′) THEN(GOTO +
              CMDLBL(STARTPRT))                    

STARTPRT:   STRPRTWTR  DEV(PRT_1)

A specific problem with that is that there is no ELSE statement after the IF statement. If it doesn’t GOTO STARTPRT, then it will fall through to STARTPRT. No matter what, when this program receives any message, it’s going to run through STARTPRT.

If there is a problem that happens when the program runs or if the program doesn’t run at all, we need to know what happens. If we don’t know what the problem is, we don’t know how to answer.

Tom

Ok, TOM

I have many printers, printer1,printer2,printer3...

When I receive the messae CPF3390 I need to know what printer was received that message. I do not know how to treat it in the CL program.

When I receive the message CPF3390 I start the printer, my CL will only be waiting for this message, the others will be discarded.

The printers has a queue called QUSRSYS / CHK_PRT.

BINGO !

Thanks TOM, 

Now it´s works ! You are the Best, the Great, the Maximum !!!

Thanks for all too.

It helps when those asking the original questions show their code and are also willing to clarify when asked. Many problems need a dialog from both sides to work towards a solution. If there is willingness for a dialog, it’s easier to stay with the question until it’s solved. If there are no responses or the responses come days or weeks later, it eventually gets forgotten and lost.

You’re welcome.

Tom