× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Follow up on this from a couple of weeks ago: Changing the timers specified had the desired effect. Except for the CHGTCPA TCPKEEPALV: I had to drop that down to 10. The previous setting of 50 caused issues with other connections.

Now that printer has worked for three weeks straight without losing connection every Monday morning.

Thanks everyone,
Bob

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of franz9000@xxxxxxxxx
Sent: Tuesday, September 15, 2020 7:04 PM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: LAN Attached printer losing connection

I went through this about year ago - posted questions on this list.
One difference was that my situation the printers (2) had IPDS cards, which has its own settings.
But same remote situation with VPN - and ours started when the Power I moved to the remote data center..
Ultimately the change was to increase the timers as you mentioned plus I'll swear the network tech did some change in the vpn setup (to not block some of the traffic).
Let us know..

Jim Franz

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Bob Cagle
Sent: Tuesday, September 15, 2020 9:05 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: LAN Attached printer losing connection

Thanks Paul & Charles,

I had already stumbled thru some of this documentation and had previously upped the TCP idle timeout on the printer to 1800, which had no effect.

Going thru it again now, I bumped that timeout to 3600, upped my CFGTCPA TCPKEEPALV from 5 to 50 and changed the printer device description to PRTERRMSG=*INFO and increased its ACTTMR from 170 to 300.

Now I just have to wait for Monday morning again and hope this worked.

Thanks
Bob

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Charles Wilt
Sent: Monday, September 14, 2020 11:32 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: LAN Attached printer losing connection

Also the doc Paul provided a link to has a link to (assuming PJL / Paul's link also has an SNMP verions)
https://www.ibm.com/support/pages/node/644749

Check out the section about Inactivity timer and Activation timer..

Specifically,
Inactivity timer should be set at some value other than *NOMAX so that the connection will be closed during periods of no activity.

The Activation timer should be set to a value large enough to prevent posting of intervention errors due to TCP/IP transmission delays and printer processing delays. The default setting of 170 seconds is usually large enough to accomplish this unless you send large files to a printer with a slow processor that has a lot of memory.

Charles

On Mon, Sep 14, 2020 at 8:24 PM Steinmetz, Paul via MIDRANGE-L < midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

Bob,

Check out this IBM knowledge base document.


https://www.ibm.com/support/pages/writers-lan-3812-devds-end-periodica
lly-message-cpa403d

Paul


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Bob Cagle
Sent: Monday, September 14, 2020 7:03 PM
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: LAN Attached printer losing connection

I'm having an issue with this printer every Monday morning - this is
our most heavily used printer; prints orders all day long. It's an HP
M507.
Was an M402 previously, but had these same issues with the old one too.

Here's the issue: On Monday mornings, It will start printing and then
stop with a CPA403D Operator Action required - C or R - when the
output tray is full. Which is normal.

Cancel or Retry are the only options - But you can reply with an R as
much as you like, you keep getting the same message. Or sometimes the
writer will end itself after responding with an R. Every other time
you're forced to answer with a C eventually.

Either way, you're restarting the writer, which then causes the spool
to restart printing at page 1.

There's been a couple of times it's just started printing junk after
the restart and has to be ended/restarted again. Then it will print
fine
again.

Local LAN attached, but the i is hosted remotely and connected to our
local network with VPN.

Again this only occurs on Monday mornings; it behaves fine the rest of
the week. Every Sunday afternoon, the system goes into restricted
state for BRMS backups.

Monday mornings are the heaviest days so the output bin is almost
guaranteed to get full on the first print of the day.

Spools are being transformed by TLA Forms by TL Ashford, which takes
some processing time since the i is remote, so I've schedule the print
for about an hour before the user is scheduled to arrive.

I at first thought that I was printing the spool before the system
went into restricted state as I had some extra jobs scheduled for
printing over the weekend, so it would make sense it would restart the
spool over at page 1. But I have since changed the schedule so that's
not
it.

I also found the IP time-out setting on the printer itself and upped
it from 5 minutes to 30 minutes - no effect.

Nothing has worked so far. It's strange that the printer will print
fine until the output bin is full, but then not respond properly to
the Op Action required message response. We end up wasting a lot of
paper because of the duplicates.

Anyone have any other ideas I could try?

Thanks

Bob Cagle
IT Manager
Lynk


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.