Kurt Actually I know nothing about this topic and, even in the days when I used to teach "TCP/IP for MVS" and some of the server and command functions, I don't believe I ever played with the LPD server and the LPR command.
However, I noticed an odd feature of your messages. Because I noticed an odd feature and because you have the problem with a DR system and not with a production system, would it not be enormously helpful to show the equivalent trace from the production system as well as the DR system for the simple purposes of comparison?[1] The odd feature I noticed was that, in the "host name" field, you have the characters "NODENAME". This "rang a bell" because I recently did a study of what the consequences for z/OS Communications Server IP component customers were when they no longer actually need the pesky, <inherited from TCP/IP for VM at the beginning of recorded time>, VMCF/TNF clutter in their systems.[2] Having conducted this study and being aware that the LPR command - as well as the LPD server - is a fossil relic written in Pascal, I can guess that the characters "NODENAME" appear because, when setting up your VMCF/TNF definitions using the antediluvian "non-restartable" flavour with, very probably, the "positional parameter" form - as may very well be the case when quickly clobbering together a DR system, you overlooked specifying the "nodename" parameter attached to the "VMCF" statement and you are using the default characters present - I guess - in the sample which you are expected to modify. If you had been using the newer - how "new" in OS/390 V2R6 (1998)? - "restartable" flavour of VMCF/TNF, by default, the "nodename" parameter would assume the value of &SYSNAME which is I would expect generally a very sensible choice - particularly if, if still actually using the old SMTP in place of the newer CSSMTP, you used the NJENODENAME statement in order that this SMTP parameter has no dependency on the VMCF parameter. It may be that not having properly defined the VMCF/TNF PITA has nothing to do with your problem. But on the other hand ... Incidentally, in a crowded field, the authors of the explanations to the LPR messages are contending well in the most useless category. For example, where the <several expletives deleted> is one supposed to go for an explanation of the codes in the EZB1016E message? Chris Mason [1] It was nevertheless interesting to compare your trace with the trace given here: 3.7.2.2 Step for creating client trace output http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/f1a1c5a0/3.7.2.2 [2] The study, "A proposed Technote: System_name without VMCF", - which has seemingly attracted no comments from the "critical" public - can be found at the following URL - which is incidentally a reference within the archives of the IBMTCP-L list to which, I believe, Miklos Szigetvari intended to direct you with "ask maybe in the TCP/IP news group": http://www2.marist.edu/htbin/wlvtype?IBMTCP-L.44824 On Wed, 6 Oct 2010 01:02:56 -0700, Kurt Eastwood <kurtms...@yahoo.com> wrote: >Hello, > >I would appreciate any help I can get from anyone on this issue. I am attempting to execute an LPR command from a DR machine to a print server and am receiving the following error in trace below. This LPR command works fine from the production machine. I cannot find any difference in the TCPIP setups of the two machines. > >I sent a packet trace to IBM and they said, based on the packet trace, that the print server software or print server hardware appears to be refusing the LPR command. I have been informed by VISTA print server software support that the print server software will not refuse a machine that can access it. I have also been told by the UNIX admin person that the VISTA print server that the VISTA print server software is running on does not have anything to refuse the DR machine from accessing it. > >Has anyone run into the problem I am having, based on the error messages? > >Any suggestions at all will be appreciated. > >Thanks, >Kurt > >===> TSO LPR OFILE.LIST AT 10.0.1.766 P VISTA TRACE > > > > >EZB0915I Begin "LPR" to printer "VISTA" at host "10.0.1.766" >EZB1057I Loaded translation table from "TCPIP.STANDARD.TCPXLBIN". >EZB0920I Requesting TCP/IP service at 10278 15:29:24 >EZB0921I Granted TCP/IP service at 10278 15:29:24 >EZB0922I Resolving 10.0.1.766 at 10278 15:29:24 >EZB0924I Host 10.0.1.766 name resolved to 10.0.1.766 at 10278 15:29:24 >EZB0925I TCP/IP turned on. >EZB0926I Host "NODENAME" Domain "" TCPIP Service Machine TCPIP >EZB0927I Trying to open with local port 721 to foreign host address 10.0.1.766 >EZB0928I Connection open from local port 721 to foreign host address 10.0.1.766 >EZB0961I Control file name is cfA630NODENAME >EZB0962I Data file name is dfA630NODENAME Port Number = 721. Remote IP Addr >= > > 10.0.1.766 >EZB0916I Sending command 2 argument: VISTA Port Number = 721. Remote IP Addr >= 10.0.1.766 >EZB0917I Command successfully sent Port Number = 721. Remote IP Addr = 10.0. >1 > >.232 >EZB1012I Receiving ACK Port Number = 721. Remote IP Addr = 10.0.1.766 >EZB1016E Did not receive an ACK for command. Code=4294967295 Return Code = -1 >. > > Error Number = 90. Port Number = 721. Remote IP Addr = 10.0.1.766 >EZB1006E Host 10.0.1.766 did not accept printer name VISTA. Port Number = 721. > Remote IP Addr = 10.0.1.766 >*** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
