we moved them to a different queue with no change. I can see the files and they all seem to be fine. If I bring them up with Navigator, I can print to a network printer. The printers in question are Twinax connected. I don’t see anything in the log except a mention of the Performance Monitor. I need to leave it the ay it is for the work day. People can print, but they do not get any messages (align paper, etc.) before it prints. Thanks for the input.

People can print,…

Does that mean that printing is working? So, the problem would be that output reverts to ‘Held’ status instead of being removed and/or that potentially necessary messages are not appearing?

Tom

print works OK as long as we have “I” in the description instead of “H”. You are correct. When we have it set to “Hold”, and you release the file, it does not print, it reverts to “held” in a matter of seconds. With “ignore” in the description, they immediately print with no opportunity to intervene for alignment, etc.
Thanks

…as long as we have “I” in the description instead of “H”.

In what description? What message? Where are you changing it?

Tom

changing the “Hold”/”"ignore” in message description
WRKMSGD MSGID(CPA3394)

IF it is CPA3394 the correct response if most likely a “G’ to– Begin processing the current file after loading the form type. This message is not unusual the first time a job is sent to a new printer. As long as they form type is not changed it should not come up again but ‘G’ is the answer if it does. If the form type changes it will be there for every change. We use WRKRPYLE to do it for printers with multiple trays and differrent forms in each tray to keep from having to answerthe messages. ‘I’ is to ignore request to load a different for and continue with whatever is loaded. I suggest displaying the full message text to see what happens based on value to be entered.

IF it is CPA3394 the correct response if most likely a “G’…

The response is being made by default. The change was to the DFT() parameter for message ID CPA3394. ‘H’ is the IBM-supplied default. A ‘correct’ default is the value that suits the site’s environment the best.

Most likely the writer is being started with a specified message queue that is set for DLVRY(*DFT). So the writer encounters a new spooled file, finds a condition such as a change in form, sends a message to ask what action to take and immediately receives a ‘H’old response. The writer then follows the direction that it was given.

Review the status of the associated message queue first. If it shouldn’t be set for default replies, then change it to *HOLD, *NOTIFY or *BREAK, whichever is appropriate.

If it’s determined that *DFT is really what is wanted, then don’t set the message default to ‘H’ unless the spooled files really should be put on hold.

The STRPRTWTR command can be used to assign a message queue to a writer. The WRKWTR command can give access to messages for a writer, and that can show which message queue is involved.

Tom

Thanks for all the input. Still tinkering (I don’t know exactly what is going on). I’ll try the suggestions. The “H” was the setting that was in there to begin with (and it worked for years). Something went amiss when the unit was powered off and brought back up. We shut it off for Irene on Saturday. Thanks, again.

Are you trying to print a report with overlays on a non-IPDS printer?? You said that you deleted the print and recreated it. You may have to create them as IPDS and not SCS.

Hello
I am having the exact same problem, and am really struggling to find a solution.
We have moved the network around, all I have done is ended the wtr, varied it off, moved the wtr, chgdevprt rmtlocname(new ip) varied it on and strprtwtr

We have lots of different  headed paper in this printer so need to await the prompt to load the form-type, which has served us happily for years.

Now it always replies H, automatically. It is not set up in WRKRPYLE, wherein if I set it up with G it goes straight through, but I need it to wait.

I have removed the RPYLE I created, and tried CHGMSGD CPA3394 DFT(*NONE), for crying out loud, QSYSOPR *msgq then shows
Reply . . :  *N
What the hell does that mean? Looks like it has taken *N from *NONE?!

As I said, all that has changed it the IP address of  the printer.
Desperately seeking a solution…
Thanks

I

further…
I have changed *msgq QSYSOPR DLVRY(*HOLD)
This seems to work, but I am worried what implications that may have on other messages….
I would guess that I should create a different message queue for the DEVPRTs, what do others think?
Thanks

ok, sod it, I’ve created a new *msgq for the printers,
now I’ve just got to find every where that the users answer the messages…

In general, common printer messages shouldn’t be going to QSYSOPR. That message queue can be the target for many kinds of messages from many types of processes while serving many different users. That can result in contradictory needs.
 
Ideally, a printer/writer will have its own message queue. But some non-system message queue ought to be created and made available for printers (i.e., for writers). That allows better management of printer messages and eliminates many possible interferences that can mask problem causes. If a dedicated queue can be set for an individual printer, problem causes are much easier to track.
 
Tom

ha! the reason for my troubles is that we have a job which sets it to *HOLD during the day and *DFT overnight, which only runs mon – fri.I fell down this hole on Sunday morning Thanks, Tom, I agree, and will stay with the seperate msgq

Good find. When I started at my previous employer, we were selling program products that commonly used QSYSOPR as a default ‘administrator’ message queue. It’s not too terrible as a default as long as it’s a configuration item that customers set when a product is installed. But what I learned fairly early was that we needed to recommend strongly that customers create a different message queue and set that for the products. Some customers had unexpected problems with QSYSOPR quickly. Some others would run into a problem months or years later after some other unrelated system element was changed. You never know what might happen (nor when it’ll happen) when using Q* objects as part of an application. — Tom