New mailing list: argproc
Dan Kegel
the commandline option processor getopt(), and possible successors.
Many good ideas were presented; however, the discussion eventually
degenerated into (nearly) mindless drivel.
To keep the discussion going without bothering the net, I am maintaining
a lightly-moderated mailing list. To join the list, send a message to
rochester!srs!argproc-request or srs!argproc...@cs.rochester.edu.
Submissions should be mailed to
rochester!srs!argproc or srs!arg...@cs.rochester.edu.
Flames will be deleted; all other messages will be passed on within one
working day.
--
Dan Kegel "... earn it anew if thou wouldst possess it." - Goethe: Faust
srs!d...@cs.rochester.edu rochester!srs!dan dan%srs....@harvard.harvard.edu
Jerry West
believe he still maintains some of that function. The UUCP over X.25
was indeed developed in Sun Germany, however, by Lupe Christophe.
Here is the blurb :-
Sun Germany Consulting proudly announces the availability of
a new Consulting Special Product, a variant of uucp supporting
X.25 connections.
The product consists of a new transfer program, uucico, that
supports SunLink X.25 sockets for outgoing connections and
implements the 'f'-protocol.
The 'f'-protocol has been invented by Piet Beertema, CWI, Amsterdam
in 1984 to be used over X.25 PDNs with hardware PADs. The version
incorporated in uucico is the one distributed with 4.3 BSD.
The 'f'-protocol features a 7 Bit data path as opposed to an 8 Bit
data path required by the older 'g'-protocol, relies on implicit
flow control (XON/XOFF between PAD and host), and will only check
correct transmission when the whole file has been transmitted.
It can thus only be used over very reliable links, like X.25 networks.
Since there are no per-packet acknowledgements, throughput over
PDNs is greatly enhanced while cost is much reduced.
The new version of uucico prefers this protocol when available on
both sides. It will fall back to the standard 'g'-protocol, implemented
in all versions of uucp since it's inception, if the 'f'-protocol is
not available.
This version of uucico has been tested with a direct, asynchronous
line between the two systems, a PAD with one system connecting with
SunLink X.25, and both systems connected via X.25.
The other new feature of uucico, support for SunLink X.25, affects
only outgoing calls (master mode). Incoming calls connect via the
X.29 server process and are treated like connections over asynchronous
lines. Outgoing calls use X.25 domain sockets to access the slave
system. It is not necessary to install SunLink X.25 when only the
'f'-protocol is the feature to be used.
The standard version of uucico delivered with the respective SunOS
release *can* be used with the new uucico, both over asynchronous
lines and X.25 links. In the latter case, the system with the old
uucico must be the slave system.
I suggest you contact your local Sun office for pricing and availability.
Rgds,
Jerry West
Bob Sutterfield
|Here is the blurb :-
|
|Sun Germany Consulting proudly announces the availability of
Doesn't this sound like it belongs in comp.newprod? Other vendors
with similar products didn't announce them in these newsgroups.
------
Bob Sutterfield, Department of Computer and Information Science
The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
b...@cis.ohio-state.edu or ...!att!osu-cis!bob
Rick Adams
to the customer) instead of making it part of the standard uucp they
provide.
It's especially sad when you realize how little effort it takes
to add the 'f' protocol to uucp.
---rick
Carl S. Gutekunst
In article <44...@beno.seismo.CSS.GOV> ri...@seismo.CSS.GOV (Rick Adams) writes:
>It's pretty pitiful that Sun makes this a seperate product (read extra cost
>to the customer) instead of making it part of the standard uucp they provide.
We've come full circle -- back to my original grousing four weeks ago that I
couldn't believe that Sun wasn't supporting UUCP X.25. It isn't in the SunOS
release because Sun's only UUCP guru (Bill Shannon) hasn't been given time to
do it. So the German consulting group did it. Granted adding 'f' protocol is
easy; adding all the SunLink support is not. And since the consulting groups
have their own budget and costs to justify, they charge for their work.
Note that only a handful of vendors provide 'f' support at all.
I'm treading on eggshells here, too; there is a strong sentiment at Pyramid
that we should start unbundling things that have value added, like X.25 UUCP.
I'm more the traditional UNIX hacker, rather adverse to charging for standards
that benefit the entire community. But giving everything away tends to lead to
cashflow problems. :-(
<csg>
Rick Adams
"BSD compatibility".
The current BSD release supports the UUCP 'f' protocol and SLIP for TCP/IP,
yet most "compatible" vendors don't support it.
A non-trivial number of customers are surprised when they find things like
that are not supported. Especially those who also have a "real" BSD system.
Some of the vendors rationalize it by saying that they are 4.2BSD compatible.
(including all of the 4.2bsd bugs in some cases). Why don't they
keep System V.1 compatibility? Anyone who really wants BSD compatibility
wants the CURRENT BSD system, but a 5 year old version. They seem
to realize it for System V, why can't they make the same obvious
conclusion.
--rick
Scott Schwartz
>that are not supported. Especially those who also have a "real" BSD system.
>
>Some of the vendors rationalize it by saying that they are 4.2BSD compatible.
>(including all of the 4.2bsd bugs in some cases).
Are we still talking about Sun? :-)
On one occasion, I noticed that vi couldn't handle fullscreen
shelltools with small fonts. It's buffer was too small. Sun tech
support told me that they didn't want to make the buffer bigger in
order to maintain compatability with Berkeley!
Let's not even mention subnetting.
-- Scott "desperately seeking 4.0" Schwartz
-- Scott Schwartz schw...@gondor.cs.psu.edu schw...@psuvaxg.bitnet
Bob Toxen
> The current BSD release supports the UUCP 'f' protocol and SLIP for TCP/IP,
> yet most "compatible" vendors don't support it.
>
While they're at it, Sun and friends (enemies?) should fix UUCICO to
support 4.2BSD UUCP's ability to specify ODD or EVEN parity when dialing
into the remote system. We could have used this feature. Also, Sun's
UUCICO faults if there isn't a "send" sequence after the last "expect"
sequence or if any "send" sequence consists solely of "\c". There's also
a third case where it faults. I could look it up if anyone cares. This was
a year ago, maybe it's fixed by now.
--
Bob Toxen {ucbvax!ihnp4,harvard,cloud9!es}!anvil!cavu!bob
Stratus Computer, Marlboro, MA
Pilot to Copilot: What's a mountain goat doing way up here in a cloud bank?
Joe Angelo
protocols *your* uucico supports -and- can you force a particular
protocol to be used (read: requested) with a specific connection?
--
"I'm trying Joe Angelo -- Senior Systems Engineer/Systems Manager
to think at Teknekron Software Systems, Palo Alto 415-325-1025
but nothing
happens!" uunet!tekbspa!joe -OR- tekbspa!j...@uunet.uu.net
G. Roderick Singleton
In every version of uucico I've encountered, there are some poorly
documented features, even for UNIX, that will perform exactly what
you're looking to accomplish. Try inserting P_ZERO in the first send
sequence (or P_EVEN or whatever) in your L.sys entry. You'll be amazed
it actually works and it's already built-in.
Now I have yet to personally experience SUN uucico but all the others,
4.2, v7 and SCO Xenix2.1.3, can set parity this way and I expect that
SUN's version also has this capability. I know these exist in the sources
but I can't locate an external reference as I type this so just experiment.
gerry
--
G. Roderick Singleton, gerry@{ syntron | geac | eclectic | cansun }.UUCP
"ALL animals are created equal, BUT some animals are MORE equal than others."
George Orwell
Carl S. Gutekunst
>>support 4.2BSD UUCP's ability to specify ODD or EVEN parity when dialing
>>into the remote system.
>Now I have yet to personally experience SUN uucico but all the others, 4.2,
>v7 and SCO Xenix2.1.3, can set parity this way [P_ZERO, et al] and I expect
>that SUN's version also has this capability.
This net never ceases to amaze me. Such wholesale quantities of conjecture for
such a trifling investment in fact. :-(
Truscott 4.2BSD has the P_ZERO, P_ONE, P_EVEN, P_ODD arguments, and of course
so does 4.3BSD. Neither version of v7 does, nor does any System V version, nor
does SunOS. Xenix may well, although if it does then this was added by Micro-
soft, since they were starting with the System VR2.2 VAX version.
<csg>
Robert Perlberg
> Hope this isn't a stupid question -- but just how can you tell what
> protocols *your* uucico supports -and- can you force a particular
> protocol to be used (read: requested) with a specific connection?
Log in as "uucp" (or whatever login it is that starts up uucico). When
you get the "Shere" prompt type the following:
^PShostname^@
Where:
"^P" is a control/P
"hostname" is any reasonable hostname
"^@" is a NUL character (control/@ on most terminals, control/SpaceBar
on some)
The system should respond something like:
ROKPfg
where "fg" is a list of the protocols it supports.
Robert Perlberg
Dean Witter Reynolds Inc., New York
{philabs | mancol | dasys1}!step!perl
-- "I am not a language ... I am a free man!"
Bob Toxen
> protocols *your* uucico supports -and- can you force a particular
> protocol to be used (read: requested) with a specific connection?
>
Just have someone do "/usr/lib/uucp/uucico -r1 -x9 -syursys" and
see what protocols your system announces that it has. I believe
the diagnostic message (of the caller) will say "Pgx", for example
for Protocols g and x. The caller will then say I'll take the g
with the incantation "Ug" (use g).
I tested this with one Virgin System V uucico calling another. I suspect
any uucico will yield the same info.
I believe the default algorithm is that the caller will request the first
protocol that is in both the callers and called system's list of protocols.
This can be overriden by putting a fourth field in the caller's USERFILE entry
that specifies the protocol to use.
I may eventually create a protocol that sends chunks larger than 64 bytes
for better efficiency with high speed modems with data compression as well.