Archive-Date: XXX, 4 Jun 1997 11:56:56 -0400 Subject: Re: I can PING but I can't browse Message-ID: <1997Jun4.115656@process.com> From: schreiber@process.com (Jeff Schreiber) Date: 4 Jun 97 11:56:56 -0400 References: <01bc600c$9c1c36a0$99de28ca@Sunny.hk.super.net> In article <01bc600c$9c1c36a0$99de28ca@Sunny.hk.super.net>, "Sunny Tsang" writes: > I got an new internet account from my school, I found that I can use this > account to Telnet, Read News, FTP, E-mail and Gopher. > > BUT I CAN'T use this account to BROWSE WWW site whatever I can Ping the www > IP. > -- > st@hk.super.net It could be that the system your account on doesn't allow browsing (or connecting to the http port). Ping doesn't actually test if you can connect to a remote webserver, it just checks if there is an IP route to that remote system. The best way to check if you are allowed to connect to a remote webserver (aside of asking your system manager what the problem is) is to telnet to the remote webserver and see if you can connect. This example shows that you can connect to the remote webserver. If this is what you see... then you need to discuss with your system manager what is wrong with your browser. $ telnet www.process.com http %TCPWARE_TELNET-I-TRYING, trying WWW.PROCESS.COM,http (198.115.138.3,80) ... %TCPWARE_TELNET-I-ESCCHR, escape (attention) character is "^\" (Then hit [return] to disconnect) This example shows that there is an access restriction on the system preventing users to connect to remote webservers. If the following is what you see, you need to discuss with your system manager as to why browsing is now allowed. $ telnet www.process.com http %TCPWARE_TELNET-I-TRYING, trying WWW.PROCESS.COM,http (198.115.138.3,80) ... %TCPWARE_TELNET-E-NOTOPEN, failed to open connection -SYSTEM-F-NOPRIV, insufficient privilege or object protection violation $ -Jeff Schreiber -- Jeff Schreiber, Process Software Corp. TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Sat, 07 Jun 1997 11:43:59 GMT Subject: TELNET logins taking up to one minute Message-ID: <5nbhib$62g@dfw-ixnews12.ix.netcom.com> From: royalef@aol.com (Royal E. Frazier Jr.) Date: Sat, 07 Jun 1997 11:43:59 GMT Reply-To: royalef@aol.com Sender: royalef@aol.com (Royal E. Frazier Jr.) Keywords: GIF animations, genealogy We are running tcpware 5.1D on several VAXes. Occasionally, and not consistently, there is a pause, about a minute long before we get the VAX's Username: prompt. The session get DNS immediately and recognizes some form of connect. The terminal screen clears and the cursor flashes in the upper lefthand corner for about a minute, then the prompt shows up. We are yusing WRQ's Reflection2 5.1 to connect under Windows. This happens with WFW3.11b TCP/IP and Win95 TCP/IP stacks. Any ideas? Royal Frazier ======================================== royalef@aol.com http://members.aol.com/royalef/royal.htm ======================================== Family Genealogy and GIF Animation ======================================== ================================================================================ Archive-Date: XXX, 9 Jun 1997 09:15:46 GMT Subject: Re: TELNET logins taking up to one minute Message-ID: <01bc74b5$8bae9bb0$527d61c2@caress> From: "Peter Jörg Ziegler" Date: 9 Jun 1997 09:15:46 GMT References: <5nbhib$62g@dfw-ixnews12.ix.netcom.com> Please verify your file TCPWARE:TELNET_CONTROL.COM. The setting for TELNETD_FLAGS should be 256. What happens? The telnet daemon tries to find out your internet name to set it in Terminals port info. If your PC has no entry in DNS revers mapping then you receive this time out in DNS search. -- Best Regards Joerg Ziegler Brain Force Software GmbH Phone: +49-89-317004-23 Fax: +49-89-317004-20 E-Mail: ZIEGLER@brainforce.com Royal E. Frazier Jr. schrieb im Beitrag <5nbhib$62g@dfw-ixnews12.ix.netcom.com>... > We are running tcpware 5.1D on several VAXes. > Occasionally, and not consistently, there is a pause, about a minute > long before we get the VAX's Username: prompt. > > The session get DNS immediately and recognizes some form of connect. > The terminal screen clears and the cursor flashes in the upper > lefthand corner for about a minute, then the prompt shows up. > We are yusing WRQ's Reflection2 5.1 to connect under Windows. This > happens with WFW3.11b TCP/IP and Win95 TCP/IP stacks. > > Any ideas? > > > Royal Frazier > ======================================== > royalef@aol.com > http://members.aol.com/royalef/royal.htm > ======================================== > Family Genealogy and GIF Animation > ======================================== > > ================================================================================ Archive-Date: Tue, 10 Jun 1997 21:19:21 +0000 Subject: Ethernet emulator? Message-ID: From: Olivier Bruchez Date: Tue, 10 Jun 1997 21:19:21 +0000 Reply-To: Olivier.Bruchez@iname.com Sender: Olivier Bruchez Here's my problem. I need to connect three computers or more together with null modem cables and parallel cables, under MS-DOS or, preferably, Windows 95. But I would like to make them believe that they are actually connected together via an ethernet network, in order to use then an IPX or TCP/IP protocol on this "pseudo-network". I know that it is theoretically possible to do something like that, but I need to know if there is actually a program or something that would allow me to do that. If you know the answer to this question, could you possibly send an email to the following address: olivier.bruchez@iname.com Thanks! ================================================================================ Archive-Date: XXX, 13 Jun 1997 11:36:00 GMT Subject: socklib problems Message-ID: <5nrbb0$dmn$1@mailgate.ikea.com> From: root@neurope.ikea.com (root) Date: 13 Jun 1997 11:36:00 GMT Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello tcpware'ers I have a problem with a client server app running on both Alpha/TCPware 5.0/VMS 6.2, and VAX/TCPware 4.1/VMS 5.5-2. The sympoms are the same, so I am convinced that there is something with the TCPware programming paradigm that I must have missed. The client server system consists of two processess on each machine, client -> netrouter 1 --- netrouter 2 -> server -+ ! | +<-------netrouter 1 -<---netrouter 2----------+ The first client packets works fine. The second packet "hangs" between the SERVER and netrouter 2. The third packets somehow "pushes" the netrouter 2 so it accepts the second packet and forwards it. The third packet may or may not hang as well. Logging shows that the "SOCKET_CLOSE" call in SERVER does not complete until the third packet arrives... One more thing that I have observed; when the server closes its socket, it ends up in FIN-WAIT-2 state. The netrouter-2's socket hangs in CLOSE_WAIT. Again, sending the third packets fixes it ! I'm using normal TCP sockets and are linking the TCPWARE:SOCKLIB statically. Last thing; this c/s setup works *flawlessly* on Digital Unix and Linux (development platform). If you have any clues, please let me know. I can supply the source files if needed. Anders Östling -- +--------------------------------------------------------------+ | Anders Östling IKEA Svenska AB (European IS Dept.) | | E-mail address anders.ostlingneurope.ikea.com | | Postal address Box 228 260 35 Odakra, Sweden | | Voice +46-42-25 73 45 | +-------------------------------------- Linux rules -----------+ ================================================================================ Archive-Date: XXX, 13 Jun 1997 18:25:57 -0400 Subject: Re: socklib problems Message-ID: <1997Jun13.182557@process.com> From: volz@process.com (Bernie Volz) Date: 13 Jun 97 18:25:57 -0400 References: <5nrbb0$dmn$1@mailgate.ikea.com> In article <5nrbb0$dmn$1@mailgate.ikea.com>, root@neurope.ikea.com (root) writes: > hello tcpware'ers > > I have a problem with a client server app running on both > Alpha/TCPware 5.0/VMS 6.2, and VAX/TCPware 4.1/VMS 5.5-2. > The sympoms are the same, so I am convinced that there is > something with the TCPware programming paradigm that I must > have missed. > > The client server system consists of two processess on each > machine, client -> netrouter 1 --- netrouter 2 -> server -+ > ! | > +<-------netrouter 1 -<---netrouter 2----------+ > > The first client packets works fine. The second packet "hangs" > between the SERVER and netrouter 2. The third packets somehow > "pushes" the netrouter 2 so it accepts the second packet and > forwards it. The third packet may or may not hang as well. Logging > shows that the "SOCKET_CLOSE" call in SERVER does not complete until > the third packet arrives... > > One more thing that I have observed; when the server closes its > socket, it ends up in FIN-WAIT-2 state. The netrouter-2's socket > hangs in CLOSE_WAIT. Again, sending the third packets fixes it ! > > I'm using normal TCP sockets and are linking the TCPWARE:SOCKLIB > statically. > > Last thing; this c/s setup works *flawlessly* on Digital Unix and > Linux (development platform). > > If you have any clues, please let me know. I can supply the source > files if needed. > > Anders Östling > First ... TCPware's SOCKLIB has some minor differences from the UNIX sockets. In particular, the socket_close routine waits until the connection is closed by both ends (not just initiates the close as is the case in UNIX). I'd suggest you consider using the C RTL Socket routines. These follow the UNIX socket conventions very closely, are integrated into VAX and DEC C. They are supported by TCPware via the "UCX emulation" support. We generally recommend that people use the C RTL socket routines as these are fully integrated into C and can be used like normal C file descriptors. Second ... I assume by all this that you're using TCP (STREAM) sockets. When you refer to PACKETs, I assume you mean at the application layer (not at the transport layer)? I don't understand what you mean by the packet "HANGS" at netrouter 2. What are these netrouters? Also, please understand that if you want to send PACKETs over TCP, you *MUST* implement this at the application layer. TCP is a byte stream protocol and this means that there is no implicit (or explicit) packet structure based on how you send data (the receiver may receive all, a portion, or even more than the data sent in a single send). You have to add application layer bytes to the data stream if you want to deal with packets (typically a byte count followed by the data; the receiver than loops until it reads the byte count header and then loops reading data until it has received the specified number of bytes). Third ... TCPware V4.1 is very old. I'd highly recommend upgrading to a more recent version. Nothing in what you've described indicates anything that comes to mind as a problem with V4.1, but it is much easier to support folks using recent versions. 5.2 is the current version and is supported on the VMS versions you have. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Wed, 11 Jun 1997 10:02:33 -0400 Subject: snmp subagent Message-ID: <339EAFF9.7B5@devb.scc.aepsc.com> From: CATHY GILBERT Date: Wed, 11 Jun 1997 10:02:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Has anyone written any subagents to add the mibs which are available in ucx??? ================================================================================ Archive-Date: Wed, 11 Jun 1997 10:33:54 -0400 Subject: snmp subagents Message-ID: <339EB752.2074@AEP.COM> From: CATHY GILBERT Date: Wed, 11 Jun 1997 10:33:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Has anyone written a subagent to add the MIBS available in UCX for tcpware ? ================================================================================ Archive-Date: Sat, 14 Jun 1997 12:03:49 -0500 Subject: Re: TELNET logins taking up to one minute Message-ID: <33A2CEF5.725E@process.com> From: Michael Corbett Date: Sat, 14 Jun 1997 12:03:49 -0500 References: <5nbhib$62g@dfw-ixnews12.ix.netcom.com> <01bc74b5$8bae9bb0$527d61c2@caress> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Peter J=F6rg Ziegler wrote: > = > Please verify your file TCPWARE:TELNET_CONTROL.COM. > The setting for TELNETD_FLAGS should be 256. What happens? > = > The telnet daemon tries to find out your internet name to set it > in Terminals port info. If your PC has no entry in DNS revers > mapping then you receive this time out in DNS search. > = Peter is probably correct - telnet is doing a reverse lookup on the client IP address to get the host name and it is taking a bit of time = before it gets an answer. This could be becuase of network problems, an improperly configured domain, or DNS is not set up correctly on = this host. Rather then editing TELNET_CONTROL.COM to set the = TELNETD_FLAGS you should use the TCPWARE_CONFIGURE.COM so when a = new TELNET_CONTROL.COM is put on during an upgrade you will not have to remember to make the change again. Below is some information for a FAQ on this that will shortly be on our FAQ (frequently asked questions) site. The FAQ site can be found at - http://www.process.com/support/ ---FAQ--- Question: What would cause incoming TELNET conniptions to when starting - = sometimes waiting over a minute before the username prompt is displayed? Answer: = This is probably happening because by default the TELNET server will = attempt try to find the host name of the client and use it when setting = the remote port information (ACCPORNAM) for the process. (This shows = up when you do a SHOW SYSTEM and in the accounting file.) Looking up = the host name could take some time especially if there are network = problems, problems with name servers, or if DNS is improperly configured.= = You can disable the lookup and have the TELNET server use the client IP = address for the remote port information by setting bit 8 of the T ELNETD_FLAGS logical. You can add the following line to your TCPWARE_CONFIGURE.COM to set this. = $ TELNETD_FLAGS =3D=3D 256 For more information on the TCPWARE_TELNETD_FLAGS logical refer to the = "Telnet - OpenVMS Management" chapter of the TCPware Management Guide. -- = regards Mike +-----------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: XXX, 15 Jun 1997 23:52:42 -0400 Subject: Re: snmp subagents Message-ID: <1997Jun15.235242@process.com> From: volz@process.com (Bernie Volz) Date: 15 Jun 97 23:52:42 -0400 References: <339EB752.2074@AEP.COM> In article <339EB752.2074@AEP.COM>, CATHY GILBERT writes: > Has anyone written a subagent to add the MIBS available in UCX for > tcpware ? Which MIBs are you most interested in? Host MIB? - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 16 Jun 1997 09:47:15 GMT Subject: Re: socklib problems Message-ID: <5o3233$jqf$1@mailgate.ikea.com> From: root@neurope.ikea.com (root) Date: 16 Jun 1997 09:47:15 GMT References: <5nrbb0$dmn$1@mailgate.ikea.com> <1997Jun13.182557@process.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: volz@process.com (Bernie Volz) [Posted and mailed] In article <1997Jun13.182557@process.com>, volz@process.com (Bernie Volz) writes: > In article <5nrbb0$dmn$1@mailgate.ikea.com>, root@neurope.ikea.com (root) writes: > > First ... > > I'd suggest you consider using the C RTL Socket routines. These follow > the UNIX socket conventions very closely, are integrated into VAX and > DEC C. They are supported by TCPware via the "UCX emulation" support. > Ok, I'll have a look in the manuals > Second ... > > I assume by all this that you're using TCP (STREAM) sockets. When you > refer to PACKETs, I assume you mean at the application layer (not at the > transport layer)? > Yes > I don't understand what you mean by the packet "HANGS" at netrouter 2. > What are these netrouters? Own TCP servers for multiplexing a LOT of connections over our WAN. The "Hang" is the socket in FIN-WAIT-2 between the "Server" and "Netrouter 2" after the first reply packet from server to client has been sent. The Server does a CLOSE() after sending the packet (does not wait for any ack form the Netrouter). The Netrouter also does a CLOSE() after it has read the complete packet (readPacket which reads a stream into a packet). > > Also, please understand that if you want to send PACKETs over TCP, you > *MUST* implement this at the application layer. Yes we have done this > Third ... > > TCPware V4.1 is very old. I'd highly recommend upgrading to a more I will talk to our support on upgrading. BTW, the netrouters are using the DECThreads packet (Posix 1003.1c draft 4) if that is of any significance. > > - Bernie Volz > Process Software Corporation -- +--------------------------------------------------------------+ | Anders Östling IKEA Svenska AB (European IS Dept.) | | E-mail address anders.ostlingneurope.ikea.com | | Postal address Box 228 260 35 Odakra, Sweden | | Voice +46-42-25 73 45 | +-------------------------------------- Linux rules -----------+ ================================================================================ Archive-Date: Tue, 17 Jun 1997 14:41:38 -0400 Subject: VMS Port of ntalk available ? Message-ID: <33A6DA62.4588@atlanticmutual.com> From: "Cameron C. Caffee" Date: Tue, 17 Jun 1997 14:41:38 -0400 Reply-To: Cameron_C_Caffee@atlanticmutual.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Has anyone run across a VMS port of the UNIX chat utility ntalk ? A TCPware port would REALLY be helpful ! Cameron -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I Cameron Caffee, Sr Systems Manager Atlantic Mutual Companines I +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I Internet : Cameron_C_Caffee@AtlanticMutual.Com I Snail Mail : I I +++++++++++++++++++++++++I I FAX : (540) 772-4116 I 1325 Electric Road, SW I I Voice : (540) 772-4071 I Roanoke, VA 24018 I +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ================================================================================ Archive-Date: Tue, 17 Jun 1997 18:28:51 -0500 Subject: Re: VMS Port of ntalk available ? Message-ID: <33A71DB3.2054@process.com> From: Michael Corbett Date: Tue, 17 Jun 1997 18:28:51 -0500 References: <33A6DA62.4588@atlanticmutual.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cameron C. Caffee wrote: > > Has anyone run across a VMS port of the UNIX chat utility ntalk ? > > A TCPware port would REALLY be helpful ! Talk has been added TCPware in version 5.2-3. regards Mike -- +-----------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Tue, 17 Jun 1997 22:07:55 GMT Subject: Re: VMS Port of ntalk available ? Message-ID: From: Terry Kennedy Date: Tue, 17 Jun 1997 22:07:55 GMT References: <33A6DA62.4588@atlanticmutual.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit In comp.os.vms Cameron C. Caffee wrote: > Has anyone run across a VMS port of the UNIX chat utility ntalk ? > > A TCPware port would REALLY be helpful ! Look on ftp.spc.edu in [.ucx] for the ntalk*.* files. Note that this is a "prove it works" port - it uses a select with a *short* timeout and can chew a fair amount of CPU when a conversation is in progress. This is because VMS's select() only operates on sockets, while on Unix it also works on generic file descriptors. You might want to talk to Process and see what their plans are for talk in a forthcoming release (nudge, nudge, hint, hint 8-). Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.spc.edu St. Peter's College, Jersey City, NJ USA +1 201 915 9381 (voice) +1 201 435-3662 (FAX) ================================================================================ Archive-Date: XXX, 19 Jun 1997 09:22:27 GMT Subject: please help - printing problem...... Message-ID: <5oatoj$qub$1@tst.hk.super.net> From: silee@news.hk.super.net (Mr Simon Lee) Date: 19 Jun 1997 09:22:27 GMT All, We have a printing problem after we upgraded our tcpware to version 5.1 :-(. Our remote office has one or more printers connected with a jet direct card, and create a print queue for each of the ip printer on our VAX. All the ip printers setup like the following: Server queue HPV302$MAN_LPR, idle, on HPV302::"man_lpr,9100,keep,noopcom", mounted form OR /BASE_PRIORITY=4 /DEFAULT=(FEED,FLAG=ONE,FORM=DEFAULT) /LIBRARY=MAN_LPR /OWNER=[SYS,SYSTEM] /PROCESSOR=TCPWARE_TSSYM /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR For some unknown reason, the ip printers can only accept the first job, and the rest print job will have 'retain on error' status......... For example, if I print 100 files to the above printer, only the first print job can be printed out successfully, the remaining 99 print jobs will stay in the queue with 'retain on error' status...... Does anyone know how to fix this problem ? We use vms 6.2 (VAX). Please help. Thanks very much in advance, Simon ================================================================================ Archive-Date: Thu, 19 Jun 1997 09:13:10 -0500 Subject: Re: please help - printing problem...... Message-ID: <33A93E76.7924@process.com> From: Michael Corbett Date: Thu, 19 Jun 1997 09:13:10 -0500 References: <5oatoj$qub$1@tst.hk.super.net> MIME-Version: 1.0 To: Mr Simon Lee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mr Simon Lee wrote: > > All, > > We have a printing problem after we upgraded our tcpware to > version 5.1 :-(. > > Our remote office has one or more printers connected with a > jet direct card, and create a print queue for each of the ip printer > on our VAX. > > All the ip printers setup like the following: > > Server queue HPV302$MAN_LPR, idle, on HPV302::"man_lpr,9100,keep,noopcom", mounted form OR > /BASE_PRIORITY=4 /DEFAULT=(FEED,FLAG=ONE,FORM=DEFAULT) /LIBRARY=MAN_LPR /OWNER=[SYS,SYSTEM] /PROCESSOR=TCPWARE_TSSYM > /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR > > For some unknown reason, the ip printers can only accept the > first job, and the rest print job will have 'retain on error' status. > > Does anyone know how to fix this problem ? We use vms 6.2 (VAX). Simon, This is a known problem with the TSSYM print queues introduced in TCPware V5.1-4. The TSSYM_V514P010 patch corrects this behavior. Here is the readme.txt from the patch - > ----------------------------------------------------------------------- > TSSYM Patch kit (revision 1.0) for TCPware version 5.1-4 July 23, 1996 > > Copyright (c) 1996, by Process Software Corporation > > This VMSinstallable saveset provides a new version of TCPWARE_TSSYM > SYMBIONT for TCPware for OpenVMS. All the TCPWARE_TSSYM print > queues must be stopped before the installation. > > This patch is applicable to TCPware 5.0-3 or higher on all > the supported version of VAX/VMS and OpenVMS. > > The following change has been made: > > There was a problem with timeout and retry customization > functionality added with 5.1-4. If the timeout is not > configured, symbiont does not retry in case of connection > rejection by default, which is not the default behavior > of the former version. > > The old version of componentname will be renamed to > > SYS$COMMON:[SYSEXE]TCPWARE_TSSYM.EXE_OLD > > Once installed, you may undo this patch by stopping all > the TCPWARE_TSSYM queues and rename the file back to: > > SYS$COMMON:[SYSEXE]TCPWARE_TSSYM.EXE > ----------------------------------------------------------------------- You can also define the TCPWARE_TSSYM_*_RETRY_INTERVAL or TCPWARE_TSSYM_qname_INTERVAL to avoid the problem. The logicals should be executive mode system logicals and should be defined to be the interval (delta time) at which the symbiont retries to make a connection after a failed attempt For example - $ DEFINE/SYS/EXEC TCPWARE_TSSYM_*_RETRY_INTERVAL "0 ::45" would set the retry intercav for all TSSYM printers to be 45 seconds. See page 23-15 of the TCPware Management Guide for more information on the TSSYM tuning logicals. The patch can be found at - ftp://ftp.process.com/support/51_4/TSSYM_V514P010.A regards Mike -- +-----------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: XXX, 20 Jun 1997 07:29:53 GMT Subject: Re: please help - printing problem...... Message-ID: <01bc7d4b$bda81620$0443a0c1@robek> From: "Robert Knotek" Date: 20 Jun 1997 07:29:53 GMT References: <5oatoj$qub$1@tst.hk.super.net> Mr Simon Lee schrieb im Beitrag <5oatoj$qub$1@tst.hk.super.net>... > All, > > We have a printing problem after we upgraded our tcpware to version 5.1 :-(. > > > Our remote office has one or more printers connected with a jet direct card, and create a print queue for each of the ip printer on our VAX. > > All the ip printers setup like the following: > > Server queue HPV302$MAN_LPR, idle, on HPV302::"man_lpr,9100,keep,noopcom", mounted form OR > /BASE_PRIORITY=4 /DEFAULT=(FEED,FLAG=ONE,FORM=DEFAULT) /LIBRARY=MAN_LPR /OWNER=[SYS,SYSTEM] /PROCESSOR=TCPWARE_TSSYM > /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR > > For some unknown reason, the ip printers can only accept the first job, and the rest print job will have 'retain on error' status......... For example, if I print 100 files to the above printer, only the first print job can be printed out successfully, the remaining 99 print jobs will stay in the queue with 'retain on error' status...... > > > Does anyone know how to fix this problem ? We use vms 6.2 (VAX). > > > Please help. > Thanks very much in advance, > Simon > > There are a view Patches (TSSYM_V515P020.A and VMSLPRSYM_V515P030 and LPRSYM_515P011.a) May be ther is help in the first one (TSSYM_V515P020.A) for your problem. But with this short description its just an little idea. Log this call to your distributor. ================================================================================ Archive-Date: XXX, 18 Jun 1997 09:24:29 GMT Subject: SELECT() problems with UCX emul Message-ID: <5o89gd$2nb$1@mailgate.ikea.com> From: root@neurope.ikea.com (root) Date: 18 Jun 1997 09:24:29 GMT Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi I'm trying to use the VAX C socket routines from a (formerly) TCPWARE:SOCKLIB linked app, but I have a problem with the select() call and the associated FD_* macros. I have included the needed DEC include files, and all prototypes and data structures seems to be defined properly, except the FD_* macros. I can also see that the DEC select() call does not use the fd_set datatype, but instead uses int's. Can someone explain how to use the select call properly in VAX C ? I dont have access to the manuals right now (only in bookreader format, and Motif is not properly installed on our VAX'en). We are running VMS 5.5-2 on the development system and the TCPware version is 4.1 (yes I know, and we ARE in the process of upgrading...) Thanks Anders -- +--------------------------------------------------------------+ | Anders Östling IKEA Svenska AB (European IS Dept.) | | E-mail address anders.ostlingneurope.ikea.com | | Postal address Box 228 260 35 Odakra, Sweden | | Voice +46-42-25 73 45 | +-------------------------------------- Linux rules -----------+ ================================================================================ Archive-Date: XXX, 23 Jun 1997 02:41:50 GMT Subject: Re: please help - printing problem...... Message-ID: <5oknpe$hql$1@tst.hk.super.net> From: silee@news.hk.super.net (Mr Simon Lee) Date: 23 Jun 1997 02:41:50 GMT References: <5oatoj$qub$1@tst.hk.super.net> <01bc7d4b$bda81620$0443a0c1@robek> Robert Knotek (r-knotek@brainforce.co.at) wrote: : There are a view Patches (TSSYM_V515P020.A and VMSLPRSYM_V515P030 and : LPRSYM_515P011.a) : May be ther is help in the first one (TSSYM_V515P020.A) for your problem. : But with this short description its just an little idea. Robert, Where can I find download patches ? Thanks, Simon : Log this call to your distributor. ================================================================================ Archive-Date: Mon, 23 Jun 1997 09:33:10 +0000 Subject: Re: please help - printing problem...... Message-ID: <33AE42D6.224E4D3@process.com> From: Geoff Bryant Date: Mon, 23 Jun 1997 09:33:10 +0000 References: <5oatoj$qub$1@tst.hk.super.net> <01bc7d4b$bda81620$0443a0c1@robek> <5oknpe$hql$1@tst.hk.super.net> MIME-Version: 1.0 To: Mr Simon Lee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mr Simon Lee wrote: > > Robert Knotek (r-knotek@brainforce.co.at) wrote: > > : There are a view Patches (TSSYM_V515P020.A and VMSLPRSYM_V515P030 and > : LPRSYM_515P011.a) > : May be ther is help in the first one (TSSYM_V515P020.A) for your problem. > : But with this short description its just an little idea. > > Robert, > > Where can I find download patches ? > > Thanks, > Simon > > : Log this call to your distributor. You can obtain them from our ftp server at ftp.process.com. You can set default into [pub.support]. There are directories for various TCPware versions and 00SUMMARY.TXT files in each directory with a summary of the READMEs for the patches. For the patchs you want you can try the URL: ftp://ftp.process.com/support/51_5/TSSYM_V515P020.A ftp://ftp.process.com/support/51_5/VMSLPRSMB_V515P030.A -------------------------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Mon, 23 Jun 1997 15:53:12 -0400 Subject: Re: SELECT() problems with UCX emul Message-ID: <33AED428.7BEE@process.com> From: Hiroto Shibuya Date: Mon, 23 Jun 1997 15:53:12 -0400 References: <5o89gd$2nb$1@mailgate.ikea.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit root wrote: > > Hi > > I'm trying to use the VAX C socket routines from a (formerly) > TCPWARE:SOCKLIB linked app, but I have a problem with the > select() call and the associated FD_* macros. I have included > the needed DEC include files, and all prototypes and data structures > seems to be defined properly, except the FD_* macros. > *** NOTE *** THIS INFORMATION IS RELEVANT TO THE VAX C RTL SELECT() FUNCTION WHICH USES TCPWARE'S UCX EMULATION. THESE MACROS WILL NOT WORK WITH THE TCPWARE SOCKET LIBRARY SELECT() FUNCTION. SEE NOTE 43.0 FOR MORE INFORMATION. (THE TCPWARE SOCKET LIBRARY PROVIDES THE FD_ MACROS ANYWAY, SO IT'S NOT AN ISSUE W/ THE TCPWARE SOCKET LIBRARY) *** **** *** PROBLEM: -------- VAX C does not define the FD_SET, FD_CLR, FD_ZERO, and FD_ISSET macros that are commonly used with the select() socket function. SOLUTION: --------- The VAX C RTL select() function is compatible with the UNIX select(), so a customer could simply steal the definitions of the FD_ macros from any UNIX system's /usr/include/sys/types.h, and "#ifdef VMS" these in the relevant source modules. Or they could use the following ones that we use "in-house" here: /* ** ** MACROS FOR MANIPULATING MASKS FOR SELECT() ** */ #ifdef SELECT #ifndef FD_SET typedef unsigned int fd_set; #define FD_SET(fd,pmask) (*(pmask)) |= (1<<(fd)) #define FD_CLR(fd,pmask) (*(pmask)) &= ~(1<<(fd)) #define FD_ZERO(pmask) (*(pmask))=0 #define FD_ISSET(fd,pmask) (*(pmask) & (1<<(fd))) #endif /* FD_SET */ #endif /* SELECT */ These definitions are being used by Mosaic, Lynx, and a CERN WWW server, all compiled here with UCX emulation and happily working. > I can also see that the DEC select() call does not use the fd_set > datatype, but instead uses int's. DEC select() use standard Unix notion of file descriptor for their socket, which is index into file descriptor table. TCPware socket is opaque pointer to TCPware socket structure thus file descriptor set is implemented as list of pointers instead of bit mask. -- Hiroto Shibuya Process Software Corporation