Windows Server Forum / Host Integration Server / June 2008
sna print service hung at SPOOLING state
|
|
Thread rating:  |
bbelle - 25 Jun 2008 17:34 GMT We have been having problems with cics (via IP) printing and recently, while evaluating/resolving multiple print problems with our system, we saw approximately 15-20 SNA print services in a SPOOLING state and when we set 129 sna printer services to an INACTIVE state (ie, we stopped the 129 services) the SPOOLING print services went to active and all the printing problems were resolved.
I can go into further detail if you like but trying to keep this short and concise.
The 129 print services are basically there to hold a connection to a dummy windows print queue (that is actually configured to a real and active print server on our network) so that to not cause errors on the CICS side. When we close out a dead printer on the network that was once used for CICS printing, we push the configured SNA print service to this dummy queue. Probably most of those 129 sna printer services were doing nothing, but i do not have a real count and it wasn't observed so nothing was recorded about their activity at the time.
We are running HIS 2004 sp1 and our SNA manager version is v6.0.2403.0
Do any of you have any idea if/why stopping those sna print services could alleviate the AIDS loading up on the CICS and causing all other printers in CICS an inability to print?
I appreciate any information you may be able to provide!
thanks
Charles Ezzell (MSFT) - 25 Jun 2008 18:33 GMT What do the event logs have to say? There are many reasons for print issues, starting with 'bad' print drivers, network issues, and I've even see where a bad network card in a printer caused problems in a Windows Print Server - locking a thread in the print spooler service which in turned locked a thread in the snaprint service since we were waiting on a response from the print spooler, which was waiting on a response from the printer.....(replacing the network card solved the problem).
Windows printing is (by design) a single threaded operation, so anything that affects a print queue could potentially cause problems with all print jobs, depending on where something fails at.
We have some ways to get around some of this, but there is a limit of what we (the snaprint service) can do.
Anyway, I whould highly suggest looking at the event logs (system and application) to see if any errors were being logged. Also, if you could (if this happens again) narrow it down to a particular print session, and look at the print queue it is communicating to, that would help.
 Signature HTH, Charles Ezzell Microsoft Host Integration
This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. Any and all views expressed are those of the writer and not Microsoft. There is no such thing as a free lunch. Peach is not a color. Violets are not blue.
> We have been having problems with cics (via IP) printing and recently, > while [quoted text clipped - 30 lines] > > thanks bbelle - 25 Jun 2008 18:35 GMT i incorrectly spoke about how the printer servers are connected.. we are using LPR for thier configuration (not IP printing).. thanks
> We have been having problems with cics (via IP) printing and recently, while > evaluating/resolving multiple print problems with our system, we saw [quoted text clipped - 24 lines] > > thanks bbelle - 25 Jun 2008 18:56 GMT I do know the particular print session and HP print queue. I
We did not capute any sniffer or SNA traces when this event occurred, unfortunately. I've never seen this happen before!
I did not find any errors, or really, any other events logged on the HIS gateway while this hung state was occuring (app or system event). Once we stopped the set of sna print services, the regular information print events started occurring (like nothing happened).
Also, can a NIC that is communicating the DLC back to the mainframe sufficiently/effectively use an auto-negotiated method, in regards to speed and duplex, or must that be hard-set to half or full duplex?
i checked the settings on the print server that we zooming in on and it does have all protocols enabled, which we have instructed deployment to not do. Our standard is to only enable IP protocol on print servers.
However, any idea why stopping several print services that most likely were doing nothing ( <2% of the entire sna print services) , alleviate a hung print system from CICS to SNA?
> i incorrectly spoke about how the printer servers are connected.. we are > using LPR for thier configuration (not IP printing).. thanks [quoted text clipped - 27 lines] > > > > thanks Neil Pike - 26 Jun 2008 16:27 GMT > Also, can a NIC that is communicating the DLC back to the mainframe > sufficiently/effectively use an auto-negotiated method, in regards to speed > and duplex, or must that be hard-set to half or full duplex? No reason it shouldn't - the negotiation happens well under the level of the protocol. Saying that, you do need to check that the switch and server nic settings are compatible. If both ends are set to auto-neg then in 99.99% of cases you'll be fine. Similarly if they're both nailed to 100/FULL then you're also 99.99% fine.
> i checked the settings on the print server that we zooming in on and it does > have all protocols enabled, which we have instructed deployment to not do. > Our standard is to only enable IP protocol on print servers. For clarification, when you say print server do you mean the HIS print server? Does this server not have any mainframe comms on it? i.e. it connects back via another HIS server, that is DLC connected to the mainframe?
> However, any idea why stopping several print services that most likely were > doing nothing ( <2% of the entire sna print services) , alleviate a hung > print system from CICS to SNA? Nope - doesn't make a lot of sense!
> > i incorrectly spoke about how the printer servers are connected.. we are > > using LPR for thier configuration (not IP printing).. thanks [quoted text clipped - 29 lines] > > > thanks > > > Neil Pike. Protech Computing Ltd Microsoft SNA/HIS MVP https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D http://www.linkedin.com/in/neilpike
Neil Pike - 25 Jun 2008 19:52 GMT You say the printing is via IP? Is that IP, as in IPDLC to the HIS Server? If so, what's the o/s on the HIS Server? Or is it DLC/SDLC to the HIS server and then the HIS Server prints IP/LPR to the printer?
> We have been having problems with cics (via IP) printing and recently, while > evaluating/resolving multiple print problems with our system, we saw [quoted text clipped - 24 lines] > > thanks Neil Pike. Protech Computing Ltd Microsoft SNA/HIS MVP https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D http://www.linkedin.com/in/neilpike
bbelle - 25 Jun 2008 21:55 GMT it is IP/LPR to the printer
I have some trace info if you would like to see that?
> You say the printing is via IP? Is that IP, as in IPDLC to the HIS Server? If > so, what's the o/s on the HIS Server? [quoted text clipped - 35 lines] > https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D > http://www.linkedin.com/in/neilpike Neil Pike - 26 Jun 2008 16:27 GMT If it's LPR to the printers then I have seen issues when there's a lot of printing, with LPR using up an artificially small range of ports it allocates itself under some Windows versions (to be RFC compliant). There's a reg key to make it use a wider ephemeral range to resolve the issue if that's part of the problem. Is the trace an sna print trace, or a sniffer/network trace? Anyway, Charles is definitely your man for SNA/printing issues. I doubt anyone else has anywhere near the knowledge he has on it!!!
> it is IP/LPR to the printer > [quoted text clipped - 43 lines] > > > > Neil Pike. Protech Computing Ltd Microsoft SNA/HIS MVP https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D http://www.linkedin.com/in/neilpike
bbelle - 26 Jun 2008 16:43 GMT Yes, we have traces - both SNA and network sniffer, but from earlier in the day right after the IPL. We tested 2 prints right after the IPL and after SNA HIS appeared to be ready for service and they both failed. It looks like the jobs never leave CICS despite communicating with SNA (per the trace files). Our work around has been to reboot the HIS print server, then stop/start document groups in CICS and THEN the printing begins. when the event described below occurred, it had been approximately 4 hours of error-free printing... we do not, however, have any traces when i stopped the 129 print service sessions (and made them inactive).
Charles, what can you glean from this? Any ideas?
> If it's LPR to the printers then I have seen issues when there's a lot of printing, > with LPR using up an artificially small range of ports it allocates itself under some [quoted text clipped - 54 lines] > https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D > http://www.linkedin.com/in/neilpike Charles Ezzell (MSFT) - 26 Jun 2008 18:35 GMT Without seeing traces (and I know you opened a case with PSS, so I probably will see them at some point), it's difficult to say.
Problems with CICS communicating is usually because the application that handles printing in CICS needs to reacquire the LUs (normally after the HIServer box is rebooted).
If the HIS print service is having problems communicating to a windows print queue, because of some OS/network/other issue, this could cause jobs to 'back up' in CICS. Without actually seeing traces, it is difficult to say.
Which traces did you capture? In this case, I would prefer to see 3270 and DLC message traces + snaprint internal & 3270 message traces.
 Signature HTH, Charles Ezzell Microsoft Host Integration
This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. Any and all views expressed are those of the writer and not Microsoft. There is no such thing as a free lunch. Peach is not a color. Violets are not blue.
> Yes, we have traces - both SNA and network sniffer, but from earlier in > the [quoted text clipped - 92 lines] >> https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D >> http://www.linkedin.com/in/neilpike
|
|
|