Re: Connection reset by peer 'loop'

[Jones, Ian H]

Alan Altmark replied  

> But if RSCS doesn't do that, it won't start promptly when they 
> power the printer on and you will get complaints.  (I am vaguely 
> surprised that RSCS doesn't treat this as an auto-dial connection 
> and use the backoff retry facility.  Maybe it's under the RESTART 
> GCS-style of control?)

Yes, we run a GCS exec that restarts links every 10 minutes, so that 
printers that have lost the automatic start attribute can be kicked
into life. Stops users complaining ;-) It doesn't account for 
RSCS restarting this link every second, all night, though 

> But what is the problem with it looping all night?  

The 1,000,000s of lines of console traffic that is being generated.

> Use automation (building your own or using a product such as IBM 
> Automated Operations for z/VM) to monitor the RSCS console and take 
> action based on what you deem important.  You can even filter out 
> restart messages if you want.  And you can avoid generating large 
> CP console logs that contain a lot of e-debris (tm).
> Automation even lets you respond to the "reset" error such that 
> you can deactivate the link if, say, it's after 7pm and then restart 
> it at 7am (or whatever).

Ok. In the absence of a neat and useful RSCS  configuration parameter, 
yes I can set something up in VM:Operator.  

Thank you both 

Regards
Ian
 
Phone: +44 (0)7790 492056

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: 28 October 2008 16:08
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Connection reset by peer 'loop'

On Tuesday, 10/28/2008 at 11:49 EDT, "Jones, Ian H"
<[EMAIL PROTECTED]>
wrote:

> RSCS is restarting the link every second or so, until the users switch

> their printer back on again. RSCS is probably trying to restart the 
> link because there is a file sitting on the queue, but I would prefer 
> it not to loop all night. I can't find a timeout value or retry 
> interval that looks relevant to this problem.

But if RSCS doesn't do that, it won't start promptly when they power the
printer on and you will get complaints.  (I am vaguely surprised that
RSCS doesn't treat this as an auto-dial connection and use the backoff
retry facility.  Maybe it's under the RESTART GCS-style of control?)

But what is the problem with it looping all night?  Use automation
(building your own or using a product such as IBM Automated Operations
for
z/VM) to monitor the RSCS console and take action based on what you deem
important.  You can even filter out restart messages if you want.  And
you can avoid generating large CP console logs that contain a lot of
e-debris (tm).

Automation even lets you respond to the "reset" error such that you can
deactivate the link if, say, it's after 7pm and then restart it at 7am
(or whatever).

Alan Altmark
z/VM Development
IBM Endicott

Connection reset by peer 'loop'

[Jones, Ian H]

All,

I have an RSCS link to an IBM 6400 dot matrix printer -  

LINKDEFINE SPSKH16  TYPE TCPASCII AST FORM *

PARM SPSKH16  EXIT=ASCXONE EP='C=TCPASCII SEP=NO' ITO=0 #

 PORT=9100 HOST=xxx.xx.xx.xx


We chose to use a TCPASCII type link because that seemed to be the most
suitable, and we couldn't get an LPR type link to work at all. The
TCPASCII link works fine, until the users switch the printer off and go
home -

09:01:16 DMTCMY700I Activating link SPSKH16 TCPASCII line= class=*
queueing=priority
09:01:16 DMTTAP012I Link SPSKH16 exit routine ASCXONE loaded at 00BBF770

09:01:16 DMTTAP181I Link SPSKH16 ready for session initiation

09:01:16 DMTAXM109I File queue reordered

09:01:16 DMTTAP182I Link SPSKH16 session established

09:01:16 DMTTAP146I Sending file 0184 (0184) on link SPSKH16 from
AESNEVM(SPCENTR), records 9594
09:01:17 DMTTAP083E Socket error on link SPSKH16 request=Recv

09:01:17 DMTTAP083E return code=- 1 error number=54 (Connection reset by
peer)  
09:01:17 DMTTAP183I Link SPSKH16 session terminated

09:01:17 DMTMAN002I Link SPSKH16 deactivated

09:01:17 DMTAXM109I File queue reordered

09:01:17 DMTAXM500I 1 file(s) closed on link SPSKH16

09:01:17 DMTCMY700I Activating link SPSKH16 TCPASCII line= class=*
queueing=priority
09:01:17 DMTTAP012I Link SPSKH16 exit routine ASCXONE loaded at 00BBF770

09:01:17 DMTTAP181I Link SPSKH16 ready for session initiation

09:01:17 DMTAXM109I File queue reordered

09:01:17 DMTTAP182I Link SPSKH16 session established

09:01:17 DMTTAP146I Sending file 0184 (0184) on link SPSKH16 from
AESNEVM(SPCENTR), records 9594
09:01:17 DMTTAP083E Socket error on link SPSKH16 request=Recv

09:01:17 DMTTAP083E return code=- 1 error number=54 (Connection reset by
peer)  
09:01:17 DMTTAP183I Link SPSKH16 session terminated

09:01:17 DMTMAN002I Link SPSKH16 deactivated

09:01:17 DMTAXM109I File queue reordered

09:01:17 DMTAXM500I 1 file(s) closed on link SPSKH16


RSCS is restarting the link every second or so, until the users switch
their printer back on again. RSCS is probably trying to restart the link
because there is a file sitting on the queue, but I would prefer it not
to loop all night. I can't find a timeout value or retry interval that
looks relevant to this problem. 

Could anyone help please ?


Regards
Ian Jones
UK Mainframe Services

EDS, an HP company

Mobile: +44 (0)7790 492056
E-mail: [EMAIL PROTECTED]


This message contains information which may be confidential and
privileged. Unless you are the intended addressee (or authorised to
receive for the addressee) you may not use, copy or disclose to anyone
the message or any information contained in this message.  If you have
received this message in error, please advise the sender by reply email
and delete the message.

Electronic Data Systems Ltd
Registered Office: Cain Road, Bracknell, Berkshire, RG12 1HN
Registered in England no: 53419
VAT number: 432 99 5915

We deliver on our commitments
so you can deliver on yours.

Re: can the cpu model be obtained from the HMC panel

[Jones, Ian H]

 
Alain Benveniste said - 
> If you are zVM530, you could try STSIUSE exec from maint. I think you
will get infos

I'm afraid I don't have STSIUSE EXEC anywhere on my system. Could it be
a locally written exec Alain ? 

Regards
Ian Jones
UKOSG - Infrastructure Specialist
EDS
ITO - UK mainframe Software Services
4 Roundwood Avenue
Uxbridge, UB11 1BQ
 
Phone: +44 (0)7790 492056

mailto:[EMAIL PROTECTED]
http://www.mainframe.uk.eds.com

This email contains information which is confidential and may be
privileged. Unless you are the intended addressee (or authorised to
receive for the addressee) you may not use, forward, copy or disclose to
anyone this email or any information contained in this email.  If you
have received this email in error, please advise the sender by reply
email immediately and delete this email.

Electronic Data Systems Ltd
Registered Office:, Lansdowne House, Berkeley Square, London  W1J 6ER 
Registered in England no: 53419
VAT number: 432 99 5915

FW: IP printing from VM

[Jones, Ian H]

 
> You still need to tell RSCS what link to process the file on. The LPR
exec uses
> link name LPR by default.  Per chance, did you group LPR1, LPR2, 
> etc together as ndoe LPR?

No, I haven't looked at grouping printers yet. 

I tried to specify a printer name and host IP address as the target, and
got the same error -

lpr profile exec a (asynchronous printer qeeple22

PRT FILE 0094 SENT TO   RSCS RDR AS  0037 RECS 0050 CPY  001 A
NOHOLD NOKEEP
RDR FILE 0095 SENT FROM RSCS RDR WAS 0037 RECS 0050 CPY  001 A
NOHOLD NOKEEP
 DMTAXM103E File 0037 (0037) rejected -- invalid destination address

Ready; T=0.04/0.04 13:10:41


lpr profile exec a (asynchronous host 10.120.72.245

PRT FILE 0096 SENT TO   RSCS RDR AS  0038 RECS 0050 CPY  001 A
NOHOLD NOKEEP
RDR FILE 0097 SENT FROM RSCS RDR WAS 0038 RECS 0050 CPY  001 A
NOHOLD NOKEEP
 DMTAXM103E File 0038 (0038) rejected -- invalid destination address

Ready; T=0.04/0.04 13:11:16


tag query file 95

LPR

Ready; T=0.01/0.01 13:12:54


tag query file 97

LPR

Ready; T=0.01/0.01 13:12:59


If my mistake is obvious then please point it out, but I think I can use
tag/spool/print to send output anyway.
 
 

Best regards
Ian Jones

Re: IP printing from VM

[Jones, Ian H]

Coding the TAG and SPOOL commands rather than using LPR EXEC has fixed
the immediate problem. Thank you
 
I hit a socket problem -

DMTLPR083E Socket error on link XRXSTD request=Bind
DMTLPR083E return code=- 1 error number=13 (Permission denied)

but I found an answer in the archives, and I have specified SECURE=NO in
the EPARM field. I'm not sure why the name of the link would need to be
different to the printer name specified in the PARM statement, so I have
changed that. 

And after a lifetime of using RSCS I have been shown that there is a
continuation character for PARM statements  ;-)
 

Regards 
Ian Jones 
UKOSG - Infrastructure Specialist 
EDS 
ITO - UK mainframe Software Services 
4 Roundwood Avenue 
Uxbridge, UB11 1BQ 
  
Phone: +44 (0)7790 492056 

mailto:[EMAIL PROTECTED] 
http://www.mainframe.uk.eds.com   

This email contains information which is confidential and may be
privileged. Unless you are the intended addressee (or authorised to
receive for the addressee) you may not use, forward, copy or disclose to
anyone this email or any information contained in this email.  If you
have received this email in error, please advise the sender by reply
email immediately and delete this email.

Electronic Data Systems Ltd 
Registered Office:, Lansdowne House, Berkeley Square, London  W1J 6ER 
Registered in England no: 53419 
VAT number: 432 99 5915 

IP printing from VM

[Jones, Ian H]

Guys,

This is probably a stupid question, but it is getting urgent and I don't have 
any more time to play with it.

We are trying to print to IP printers for the first time. This looks like it 
should have been a straight forward change; CMS users used to send output to 
type SNA3270P printers and now they want to send it to IP attached printers 
instead. There seems to be many different ways of specifying the printer name 
and IP address of the target printers and I chose what looks like the simplest. 
In the RSCS config I have coded -  

LINKDEFINE LPR1 TYPE LPR AST FORM * 
PARM LPR1 EXIT=LPRXONE EP='C=LPR' ITO=0 PR=QEEPLE22 US=YES HOST=10.120.72.245   

LINKDEFINE LPR2 TYPE LPR AST FORM * 
PARM LPR2 EXIT=LPRXONE EP='C=LPR' ITO=0 PR=QEEPLE29 US=YES HOST=10.120.73.222   


I am using the LPRXONE exit supplied in RSCSEXIT LOADLIB and the RSCSLPR CONFIG 
supplied with TCP/IP, because I don't (think I) have any additional 
requirements.. RSCS starts the printer links OK and then immediately 
deactivates them, presumably because I have specified ITO=0. 

So far, so good (?), but when I try to send a print file to them using LPR 
exec, RSCS rejects the file because it has an invalid destination address. I 
get the same result whether I use the printer name or the IP (host) address. 
LPR exec insists on using the default linkid (LPR) coded in the exec. I'm 
obviously missing something in the configuration of these things. Do I *need* a 
nicknames file ? I thought that these were one of the many options, rather than 
compulsory.
 

Regards
Ian Jones
UKOSG - Infrastructure Specialist
EDS
ITO - UK mainframe Software Services
4 Roundwood Avenue
Uxbridge, UB11 1BQ
 
Phone: +44 (0)7790 492056

mailto:[EMAIL PROTECTED]
http://www.mainframe.uk.eds.com

This email contains information which is confidential and may be privileged. 
Unless you are the intended addressee (or authorised to receive for the 
addressee) you may not use, forward, copy or disclose to anyone this email or 
any information contained in this email.  If you have received this email in 
error, please advise the sender by reply email immediately and delete this 
email.

Electronic Data Systems Ltd
Registered Office:, Lansdowne House, Berkeley Square, London  W1J 6ER 
Registered in England no: 53419
VAT number: 432 99 5915

Re: RES: VSE/VSAM for VM

[Jones, Ian H]

Thank you Mark. This is directed at IBM -

Auditors do not care tuppence whether a product is 'stable'. If a
product is used to support a production workload they expect it to be
*supported*. An auditor's reaction will vary from an 'observation' that
an unsupported product is being used, to a recommendation that use of
the product be discontinued. In a business environment where auditors'
reports can cause a company to lose a contract, no one can afford to use
unsupported software.


Ian Jones
UKOSG - Infrastructure Specialist
EDS
ITO - UK mainframe Software Services
4 Roundwood Avenue
Uxbridge, UB11 1BQ
 
Phone: +44 (0)20 8754 5636

mailto:[EMAIL PROTECTED]
http://www.mainframe.uk.eds.com


-Original Message-
From: Gillis, Mark [mailto:[EMAIL PROTECTED] 
Sent: 19 June 2006 22:24
Subject: Re: RES: VSE/VSAM for VM

I received the following reply from Gerhard Zierl from IBM in April:

"...The news is that after assessing the situation the product stays
withdrawn from market. Toady VM/VSAM is used in very stable environments
by customers who have the product already licensed and installed for a
long time, IBM hasn't seen new customers to this product for a long
time. Therefore we do not see any problem associated with the withdrawal
from market..  z/VM 5.2 customers can use their old VSAM distribution
tape which they have received with their current version of z/VM.

Same is true for end of service. The last APAR was 2001 (more than 5
years). Before that there was one (new function) APAR in 1999 and 2
defect APARs in 1996. VM/VSAM is a very stable product. In addion
VM/VSAM is used by customers in mature and stable environments, no new
applications, no major changes, etc... I would assume the same applies
to your product.  So the risk of encountering a severe problem is
extremely low.
In case customers decide they have a critical need to have service
beyond the EOS-date, then there is in general an option to ask IBM for a
charged service extension agreement."

Mark.