printer problems PSM-E-WRITEERR

[Klaes-Göran Carlsson]

Hi all

The short version:
%PSM-E-WRITEERR, error writing !AS
-SYSTEM-F-HANGUP, data set hang-up

The long "detailed" version:

I have a lot of problems with my printers. Some are connected via tcp, others using old LAT. Guess the problem is not the printers itself.

Some jobs causing the printer queue to be stalled. The printfile is OK, it is printed out when reprinting it.
All printing is done from a C++ application using:
status = sys$sndjbcw(0,SJC$_ENTER_FILE,0,&item_list,0,0,0);
(I have no idea what that line is doing... just put it here so you don't have to ask:)

The application has been working for 10 years in 30 different factories, just has to be some quotas or network or what? I have adjusted "mcr sysgen sh CHANNELCNT" since autogen asked for it.

Guess your answers will be like "network related", (that's my answer to customers when I don't have any idea)
but... please give me a hint where to dig.

Thanks in advance
/Klaes-Goran


EINKGCA_BTRACK> ucx sh ver

HP TCP/IP Services for OpenVMS Alpha Version V5.4
on a AlphaServer 1200 5/533 4MB running OpenVMS V7.3-2




EINKGCA_BTRACK> sh que OBSPRINT142/all/full

Terminal queue OBSPRINT142, idle, on BTRACK::LTA629, mounted form DEFAULT

/AUTOSTART_ON=(BTRACK::LTA629) /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT)
Lowercase /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR
/SCHEDULE=(NOSIZE)

Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
4514 102_19002-2_SVV10799A23004H0JA
BAR_SFT 3 Retained on error
%PSM-E-WRITEERR, error writing !AS
-SYSTEM-F-HANGUP, data set hang-up
Submitted 21-NOV-2005 07:42:18.96 /FORM=DEFAULT /PRIORITY=100
File: _BTRACK$DRA1:[BARTRACK.062.TMP.LABEL]102_19002-2_SVV10799A23004H0
/DELETE
Completed 21-NOV-2005 07:42:18.99 on queue OBSPRINT142




EINKGCA_BTRACK> sh que z*215*/all/full
Printer queue ZBSPRINT215, idle, on BTRACK::"PSB202.bs.sw.ericsson.se:9100",
mounted form DEFAULT
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) Lowercase /OWNER=[SYSTEM]
/PROCESSOR=UCX$TELNETSYM /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR

Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
1817 4_19002-4_SVV10799A23004HGLY
BAR_SFT 19 Retained on error
%PSM-E-WRITEERR, error writing !AS
-SYSTEM-F-NOIOCHAN, no I/O channel available
Submitted 24-NOV-2005 09:35:00.77 /FORM=DEFAULT /PRIORITY=100
File: _BTRACK$DRA1:[BARTRACK.062.TMP.LABEL]4_19002-4_SVV10799A23004HGLY
/DELETE
Completed 24-NOV-2005 09:35:01.36 on queue ZBSPRINT215

[Klaes-Göran Carlsson]

Also have a lot of errors like:

1051 4_19002-4_SVV10799A23004J5KG
BAR_SFT 19 Retained on error
%PSM-E-WRITEERR, error writing !AS
-SYSTEM-F-NOIOCHAN, no I/O channel available
Completed 30-NOV-2005 07:56:41.46 on queue ZBSPRINT215
1300 4_19002-4_SVV10799A23004J5TP
BAR_SFT 19 Retained on error
%PSM-E-WRITEERR, error writing !AS
-SYSTEM-F-NOIOCHAN, no I/O channel available
Completed 30-NOV-2005 08:58:01.79 on queue ZBSPRINT215

[Uwe Zessin]

Hm, "dataset hang up" is indeed a sign of network disruptions, but NOIOCHAN most likely not. Apart from raising CHANNELCNT (which is not a dynamic parameter, so you need a reboot, but I think you know that).

It is possible that the C++ RTLs eats up too many I/O channels - does it help if you raise the system parameter PQL_MFILLM?

[Ian Miller.]

Raising CHANNELCNT and parhaps openfile quota for the symboint process should help with NOIOCHAN.

Dataset hangup from a lat connection indicates a network timeout. LAT has short timeouts, some of which can not be changed. Check for network issues between the DECserver and your VMS system.

[labadie_1]

Check the quota of the symbiont process that deals with your printer, with Amds or Availability Manager (both available at http://h71000.www7.hp.com/openvms/products/availman/index.html ) or pquota (http://h71000.www7.hp.com/freeware/freeware40/pquota/)

[Klaes-Göran Carlsson]

I have adjusted the PQL_MFILLM from 100 to 1000, have to let the system run for some hours before I know if this was the solution. Have been running 1 hour now without problem:)

Uwe: Yes, I have rebooted after changing channelcnt.

Ian: "open file quota" do you mean FILLM?

Then I need to learn some more: How to find out which process/account to adjust?

sh sys/proc=*symb* gives me a list of 5 processes. Show proc/id/cont tells me that some are running DCPS$SMB.EXE others running LATSYM.EXE
All of them with system account. Is it just to mcr authorize mod system/fillm=3000 ? It is =2000 now.



/Klaes-Göran

[labadie_1]

to find the symbiont for lta629, do
$ ana/sys
set proc/id=id_of_1st_symbiont
sh proc/chann
if you have lta629, it is this one, note the pid

[Uwe Zessin]

> Ian: "open file quota" do you mean FILLM?

I am not Ian, but I'd say yes ;-)


As far as I can tell, a symbiont is not activated in a way that takes care about a username's SYSUAF quotas - thus my suggestion to look after the system parameter PQL_MFILLM which overrules any lower values from the process quota list.

[labadie_1]

If memory serves me, a symbiont takes his quotas from jobctl process, so Uwe method is good and simple

[Ian Miller.]

Yes FILLM. Symbiont processes are detached processes so the values in the UAF do not apply. Raising PQL_MFILLM is the way to go.