Printers will not release files AS/400

45 pts.
Tags:
AS/400
AS/400 Printer File
AS/400 printing
I've made a "work-around" but, after  a power off, none of the printers will release "held" files. I'v deleted a printer and reinstalled. IPL'd, varied on and off, I had to force the "vary on" as I could not lock onto the printer. I'm fairly sure it has something to do with the writer, but I'm at a loss as to where to look. After everything I try, if I release a file, it reverts to "Held". Thanks for any help. PS... the "work around" was to change the message descriotion from Hled (H) to Ignore(I)

Software/Hardware used:
as/400 v4r5

Answer Wiki

Thanks. We'll let you know when a new response is added.

If you released a spool queue entry and it went back on hold, there is a message in your joblog with an explanation.
Have you tried moving them to a different queue?
Can you still display the contents fo the SPLF?
Do new reports print OK?

Discuss This Question: 16  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Agates
    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.
    45 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • Agates
    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
    45 pointsBadges:
    report
  • TomLiotta
    ...as long as we have “I” in the description instead of “H”. In what description? What message? Where are you changing it? Tom
    125,585 pointsBadges:
    report
  • Agates
    changing the "Hold"/""ignore" in message description WRKMSGD MSGID(CPA3394)
    45 pointsBadges:
    report
  • Bigmac46
    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.
    1,000 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • Agates
    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.
    45 pointsBadges:
    report
  • MDratwa
    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.
    785 pointsBadges:
    report
  • Agates
    [...] 9. TomLiotta, CharlieBrowne, Bigmac46, and MDratwa gave tips on dealing with a printer that will not release AS/400 files. [...]
    0 pointsBadges:
    report
  • AdrianBu

    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

    40 pointsBadges:
    report
  • AdrianBu
    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
    40 pointsBadges:
    report
  • AdrianBu
    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...
    40 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • AdrianBu
    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
    40 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following