IBM's TCP/IP vs. Sun PC/NFS as an NFS client?
Dean Pentcheff
Larry Margolis <mar...@watson.ibm.com>!), I gather that the package
will let an OS/2 machine be an NFS client (as Sun's PC/NFS does under
DOS). Given the academic discount of 35%, the cost of IBM TCP/IP
Base + NFS modules comes to 35% of $350, which is quite competitive
with PC/NFS for DOS.
Is anyone out there using such a system? How does it compare to PC/NFS
under DOS? Of course, I know that OS/2 confers lots of advantages as
an OS, that's not my question. I'm asking about behavior as an NFS
client. Does it work well? Glitches? How easy/difficult is setup
compared to a DOS PC/NFS system? How is printing handled? Under
PC/NFS, LPT ports are mapped to network printers. How is this handled
under TCP/IP under OS/2?
Thanks for responses.
-Dean
--
Dean Pentcheff (Internet: de...@garnet.berkeley.edu)
Department of Integrative Biology, University of California, Berkeley CA 94720
Work Phone: (510) 643-9048 Home Phone: (510) 839-1790 Fax: (510) 643-6264
Amund Skavhaug
--
One year ago I used pc-nfs ver 3.01 , now I am using os2 2.0 (.1,77 LA) and
IBM's TCP/IP package. With PC-NFS the performance was awful (we have a VERY
hevy loaded net) and dos often refused to even copy a file bigger than 70k....
it gave up... So we bought FTP software's PCTCP, which worked better. Later we
received PC-NFS 3.5 , but still the performance was not comparable to FTP's
package. (I also bougth FTP softwares os2 package which I used together with
os2 1.3 , this was OK, but for some reason I got a "invalid filesystem" or
something like that when I tried it with os2 2.0 .149. I havn't tried later.)
Then I had the pleasure to try IBM's TCPIP package.
Installation was easy (but then I had fought with pc-nfs and FTP software's
packages earlier, and learned a lot from that).
My network drives works wonderful, and I am doing A LOT of stuff concurrently,
recently I discovered that they too could be cached (all IFS can ??? PC-NFS
drives can also be some sort of cached under dos, but I really prefer to awoid
(for example) any kind of "lazy writes" running dos......).
(Well, and of course, there is a NFS-SERVER in the package, if thats of any
interest.)
I made a little "test" now, I copied 7.2 MB ,several hundreds of files, many
subdirs from a fat-disk, to a networkdisk I just mounted. (XCOPY *.* N: /s)
This lasted 3 min 30 sec. My machine is loaded all the time, this was
added to the work it did concurrently, well I didn't do anything else while
this lasted, so the system presumably gave priority to this session. (I use
the dynamic priority option which is default.)
The speed didn't look good ? I agree,
but beleve me, it was no better with dos. (With dos the speed test of network disk
in Norton Utilities showed from 10k to 40k B /sec -writes. Both FTP's and PC-NFS)
Now I copied back from the netdisk to a local hpfs disk, this lasted 2 min 34 sec.
I have not found out how to redirect lptX to a network printer. (Please respond
anyone who has !) I know the os2 "mode" can redirect to a network printer, lpt4 -
lpt9, but how do you set up the printer ?
Well, it frankly does not matter at all. I use "lpr" which is part of the package,
the os2 printers can print to a file, and my dos apps too, so I just use
LPR filename.
There is also a LPD deamon, so if you connect the printer to one of the PC's, you
can reach it from the other pc's , our laserprinters (among them a HP III si,
17 pages/min. ) are connected to sparcstations with serial interfaces, 9600 or
19.2k baud, we could attach one of them to my pc and use the parallell interface
instead.
There are several other goodies in the package, but I understood you was not
interested, well you should be. This is truly a completly different ballgame.
RSH,FTP,TELNET deamons running are -nice-, ftppm.exe which is a pm ftp program
(I can't understand how i survived unix ftp-ing anymore)
The LAMAIL mail application (hint: try also .forward in the home dir at the unix
user)
(By the way, the proffesor I work for is in USA this year, when he needs a program
disk or something, I just drop it in my own pc...)
I am satisfied with the TCPIP package from IBM.
If the price is at all competetive then I can't see ANY reason for staying
with dos and PC-NFS. (Except the obvious ie machine requirements, lack of
drivers , VCPI based programs and so on.)
Regards, Amund Skavhaug
Division of Engineering Cybernetics : Phone +47 7 594376
The Norwegian Institute of Technology : Fax +47 7 594399
N-7034 Trondheim : Email am...@itk.unit.no
NORWAY
Paul Bash
>From reading the IBM announcement letter on IBM's TCP/IP (thank you
>Larry Margolis <mar...@watson.ibm.com>!), I gather that the package
>will let an OS/2 machine be an NFS client (as Sun's PC/NFS does under
>DOS). Given the academic discount of 35%, the cost of IBM TCP/IP
>Base + NFS modules comes to 35% of $350, which is quite competitive
>with PC/NFS for DOS.
>
>Is anyone out there using such a system? How does it compare to PC/NFS
>under DOS?
I've used FTP Software's PC/TCP Plus rather than PC-NFS but I believe
my comments will hold up there as well: basically, there is just no
comparision between running TCP/IP on OS/2 as compared to MSDOS. OS/2
is a REAL OPERATING SYSTEM and feels that way.
Under OS/2, I've used both IBM's TCP/IP 1.2 and FTP Software's PC/TCP 1.1
and prefer, by a large margin, the IBM package. I'm sure that FTP
Software will keep their OS/2 package competitive but, as of right now, the
IBM package is more complete in that it offers NFS *server* and X server
capabilities (both of which work well) along with source code for the
development libraries. 3270 emulation support is also first rate (what
else would you expect of IBM :-).
The biggest failing of IBM's product is poor support for passwords but I'm
told this will change in the next release.
>Of course, I know that OS/2 confers lots of advantages as
>an OS, that's not my question. I'm asking about behavior as an NFS
>client. Does it work well? Glitches?
The OS/2 NFS client support is particularly nice when compared to MSDOS based
systems like PC/TCP Plus and, I'm sure, PC-NFS. Both IBM and FTP Software use
OS/2's IFS when implementing NFS clients. The biggest advantage of this is the
ability to see and use 256 character file names. If your NFS server happens to
be a Sun, or some other system using the Berkeley Fast Filesystem, you know
how important that can be. The advantage IBM's product has over FTP's is
that you can request that filenames default to lower case when not
explicitely specified by the user. FTP's product always defaults to uppercase.
For example, a command like:
copy test.c m:\
where m: is an NFS mounted drive, results in a file called
test.c
when using IBM's TCP/IP and
TEST.C
when using FTP Software's TCP/IP. If your server is a Unix system,
where case is significant in filenames, this can be a problem. In both of
the above examples, had I specified
copy test.c m:\test.c
then the case I typed would be respected.
IBM's product also (I believe this is true, but I don't have the manual
close by at the moment) allows you to select carriage return/line feed
translation when files are stored or retrieved from the server. This is
particularly useful for source file repositories (you wouldn't
want to use it with binary files :-).
A major hassle with the MSDOS NFS clients I've seen has been what happens
if the server has a file that does not conform to the MSDOS 8.3 file
naming restrictions. Under OS/2 NFS clients, the names can be accessed
as-is since 256 character file names are supported. With MSDOS clients, on
the other hand, the filenames go under a transformation refered to as
"mapping". Basically, this is just an algorithm for creating a unique
8.3 filename out of the non-8.3 one. If I have a file on the server named
this.is.a.test
it might show up on an MSDOS client as something like
TH~~~121
That's unique but not exactly user friendly!
>How easy/difficult is setup
>compared to a DOS PC/NFS system?
Setup under IBM's product is a breeze. Its all driven by a PM based
installation program that takes care of everything... that is, until you
get around to installing the NDIS drivers. The installation program
(this is under TCP/IP 1.2 only) then refers you to a confusing series of
disk based text files to complete the installation. *All* of the installation
problems I've seen with IBM's product have come as a result of screwing
this part up.
When I spoke with IBM about this, the person I dealt with appologized for
this and assured me that the installation will be much more automatic in
the next release.
Once the system is installed, the other setup tasks are pretty much as
they are in Unix. There is a \tcpip\etc directory where you find most
of the familiar text files such as hosts, fstab, passwd, etc.
>How is printing handled? Under PC/NFS, LPT ports are mapped to network
>printers. How is this handled under TCP/IP under OS/2?
IBM supplies a program, lprmon, that can be used to re-direct LPT1 and LPT2
to printers on the network. At work, I have LPT1 re-directed to a postscript
queue on the server and LPT2 to an ascii queue. It is completely transparent
and works very well.
>
>Thanks for responses.
>
>-Dean
>--
>Dean Pentcheff (Internet: de...@garnet.berkeley.edu)
>Department of Integrative Biology, University of California, Berkeley CA 94720
>Work Phone: (510) 643-9048 Home Phone: (510) 839-1790 Fax: (510) 643-6264
--
Paul Bash Techware Design
ba...@tware.com Boulder, CO U.S.A.
A. Andre Asselin
I used to work in the TCP/IP development department in IBM as a co-op.
NFS client has no provisions for redirecting LPT ports-- we use the more
UNIX-like LPR/LPD combo. By the way, you can check out LPRMON, which will
set itself up as a monitor for an LPT port and redirect all output to some
LPD server. That should do what you want.
As far as NFS not supporting printers, adding printer redirection was
a hack Sun threw in in their PC-NFS. We felt that we should keep OS/2 more
like the UNIX tools, and have NFS do remote file systems ONLY, and then
provide LPR/LPD tools for printers. If you (or others) have any comments/
opinions on this, I'd be interested in hearing them...
- Andre Asselin ass...@rpi.edu
Mark Dobie
[...]
>(Well, and of course, there is a NFS-SERVER in the package, if thats of any
>interest.)
[...]
>There are several other goodies in the package, but I understood you was not
>interested, well you should be. This is truly a completly different ballgame.
>RSH,FTP,TELNET deamons running are -nice-, ftppm.exe which is a pm ftp program
>(I can't understand how i survived unix ftp-ing anymore)
Does this mean that it all works the other way round too? I could
mount the OS/2 machine's drives from somewhere else and use them. Or
maybe telnet into the OS/2 machine and run a program (text only, of
course) in an interactive session.
>I am satisfied with the TCPIP package from IBM.
It sounds very impressive.
Mark.
--
Mark Dobie M.R....@uk.ac.soton.ecs (JANET)
University of Southampton M.R....@ecs.soton.ac.uk (The World)
Richard Alan Schafer
|> Does this mean that it all works the other way round too? I could
|> mount the OS/2 machine's drives from somewhere else and use them. Or
|> maybe telnet into the OS/2 machine and run a program (text only, of
|> course) in an interactive session.
Yes, and Yes. The NFS support is both client and server, and you can
indeed telnet in and run anything you could run in a fullscreen window.
Mind you, OS/2 is still a single-user machine, so there is a single password
used for *anyone* who telnets into it, not separate password for multiple
people.
Richard
Dean Pentcheff
As far as I can tell, LPRMON would do the trick. Why have redirection
at all, you ask? I'm often in the position of recommending computers
and software to biologists. Many (not all, but many) of them are what
one might charitably call "computer naive". They know that pressing
^KP gets Wordstar to print their manuscript. Oh, data printouts?
Shift-PrtSc, of course.
If I even bring up the idea of printing to a file then LPRing the file
("What-ing? Why can't I just _print_?"), it's a non-starter. So, to
get people's feet into the water, I need to be able to assure them
that, yes, if they just select "print" in their application, the damned
thing will print. Anything else and the immediate response is "Why
should I do all this crap? I thought this 'improved' system was
supposed to be easier. This is much more complicated." Realistically,
once people start using a better OS, they quickly get hooked, but
getting them started is the trick. If I can promise that things will
be no more complicated than the old system, I can get them going.
Gary Woodman
>Mind you, OS/2 is still a single-user machine, so there is a single password
This is only part of the story: OS/2 is designed as a single-user operating
system; there is _NO_ reason to think that there won't be multi-user
extensions and/or multi-user applications.
----------------------------------------------------------------------------
Gary.W...@anu.edu.au "so many newsgroups, so little time..."
Chris Ulrich
writes:
It would seem to me that most of the necessary elements of a multiuser os
are in place in OS/2 - preemptive multitasking with threads, ea's for file
ownership. The only real limitation seems to be the platform (how would it
work to have 200 users on an ISA 386sx with 12mb of ram?) but it has been
said that OS/2 is portable...
Peter Piggott
>I've used FTP Software's PC/TCP Plus rather than PC-NFS but I believe
>my comments will hold up there as well: basically, there is just no
>comparision between running TCP/IP on OS/2 as compared to MSDOS. OS/2
>is a REAL OPERATING SYSTEM and feels that way.
I entirely agree.
The company I work for manufactures and distributes FTP products and Sun's
PC-NFS under license in the UK. I therefore have to support these products
runnunig under DOS and the OS/2 version (I'm the only one who supports the
OS/2 version). I use the OS/2 version as my work machine out of choice.
> copy test.c m:\
> test.c
> TEST.C
This isn't true.
If I copy a file such as work.cmd to a mounted drive on a Sun server, using
FTP PC/TCP for OS/2 v1.1 pl1, the file copies as work.cmd.
If I copy a file such as TEST.CMD the file copies as TEST.CMD.
This was using the method shown above.
Logging in to the Sun server the files can be seen as work.cmd and TEST.CMD
respectively.
Therefore the following statement is not true:
>when using FTP Software's TCP/IP. If your server is a Unix system,
>where case is significant in filenames, this can be a problem. In both of
>the above examples, had I specified
> copy test.c m:\test.c
>then the case I typed would be respected.
>IBM's product also (I believe this is true, but I don't have the manual
>close by at the moment) allows you to select carriage return/line feed
>translation when files are stored or retrieved from the server. This is
>particularly useful for source file repositories (you wouldn't
>want to use it with binary files :-).
>A major hassle with the MSDOS NFS clients I've seen has been what happens
>if the server has a file that does not conform to the MSDOS 8.3 file
>naming restrictions. Under OS/2 NFS clients, the names can be accessed
>as-is since 256 character file names are supported. With MSDOS clients, on
>the other hand, the filenames go under a transformation refered to as
>"mapping". Basically, this is just an algorithm for creating a unique
>8.3 filename out of the non-8.3 one. If I have a file on the server named
> this.is.a.test
>it might show up on an MSDOS client as something like
> TH~~~121
>That's unique but not exactly user friendly!
stuff deleted
Another 'nice' feature of FTP's OS/2 product is the ability to mount a drive
to a host not running PSNFSD without resorting to using username nobody.
This is achieved by the use of a local 'passwd' file which contains the relevant
UID, GID and encrypted password information.
>>How is printing handled? Under PC/NFS, LPT ports are mapped to network
>>printers. How is this handled under TCP/IP under OS/2?
>IBM supplies a program, lprmon, that can be used to re-direct LPT1 and LPT2
>to printers on the network. At work, I have LPT1 re-directed to a postscript
>queue on the server and LPT2 to an ascii queue. It is completely transparent
>and works very well.
>>
>--
>Paul Bash Techware Design
>ba...@tware.com Boulder, CO U.S.A.
Apologies for mis-spellings, I'm English therefore the command of my national
language is not good :-)
.sig - whats that?
I am biased due to the fact we sell the FTP and PC-NFS products.
Peter
Sehyo Cheng
Newsgroups: comp.os.os2.misc
Subject: Re: IBM's TCP/IP vs. Sun PC/NFS as an NFS client?
Summary:
Expires:
References: <kqjj8o...@agate.berkeley.edu> <1992Feb27.1...@tware.com>
Sender:
Followup-To:
Distribution:
Organization: Servio Corp, Beaverton Oregon, US
Keywords:
My experience with OS/2 TCP version 1.3 was pretty bad.
I strongly not recommend to buy IBM version but instead buy PCTCPIP version.
I had used their MS-DOS version and it work flawlessly (aside from 8 character
limit on file name, but that' ms-dos problem).
Reasons not buying from IBM:
(1) Lousy support. Have you try to get in touch with IBM to get support?
Unless you are one of the big corporation forget it!. Microsoft does
job much bette(I think this is one reason why I would never recommend
OS/2 2.0, it doesn't matter how good it is ). You can at least get
PCTCP guy's attention, forget about IBM.
(2) Horrible Manual. There is no comparison, PCTCP manual is magnitude
order better than IBM's manual. IBM's manual is border around
incomprehensible.
(3) Bad NFS support: I never figure out (see above 1,2) how to turn off
cr/lf translation on NFS client yet. The COPY and XCOPY it seems
doesn't respect NFS mounted volumes. Everything is mapped to
lowercase, this cause horrible problem in some DLL' which were
case sensitive. Bad performance, it seems like I was on RS-232
line instead of Ethernet
(4) Difficult installation: It was miracle that I was able to
make this thing work. Why can't they automate installation
especally difficult things like configuring IP network stacks.
Yuck!
My only regrets is not being able to use PCTCPIP version (decision
was made elsewhere), you may avoid this.
------------
Sehyo Chang
se...@techbook.com
Oliver J. Tschichold
[DOS suffering history deleted]
[NFS performance experience deleted]
>I have not found out how to redirect lptX to a network printer. (Please respond
>anyone who has !) I know the os2 "mode" can redirect to a network printer, lpt4 -
>lpt9, but how do you set up the printer ?
>Well, it frankly does not matter at all. I use "lpr" which is part of the package,
>the os2 printers can print to a file, and my dos apps too, so I just use
>LPR filename.
>There is also a LPD deamon, so if you connect the printer to one of the PC's, you
>can reach it from the other pc's , our laserprinters (among them a HP III si,
>17 pages/min. ) are connected to sparcstations with serial interfaces, 9600 or
>19.2k baud, we could attach one of them to my pc and use the parallell interface
>instead.
You can redirect the output to a LPT?-device with LPRMON, a program
that's part of IBM TCP/IP 1.2.
E.g. you could do
start lprmon -P your_queuename -S your_hostname lpt1
and then all accesses to lpt1 would be rerouted to that queue on that host.
This can be any lpd-queue on any tcp/ip-host.
To get this done with OS/2, set up a regular print queue with the print
manager (be sure to configure it as an LM-queue, not PM-queue), and
start lpd. Worked with me right away. Such an OS/2-lpd can be accessed
by a UNIX host, too, BTW.
Hope this helps
Oliver
>Regards, Amund Skavhaug
>
>Division of Engineering Cybernetics : Phone +47 7 594376
>The Norwegian Institute of Technology : Fax +47 7 594399
>N-7034 Trondheim : Email am...@itk.unit.no
>NORWAY
Oliver Tschichold, System Manager oli...@glance.ch
------------------------ How to work better ----------------------
1 Do one thing at a time 6 Accept change as inevitable
2 Know the problem 7 Admit mistakes
3 Learn to listen 8 Say it simple
4 Learn to ask questions 9 Be calm
5 Distinguish sense from nonsense 10 Smile
Paul Bash
[ a *whole* lot of stuff deleted]
>
>
>My experience with OS/2 TCP version 1.3 was pretty bad.
I'm assuming you mean IBM TCP/IP 1.2. Considering your following comments, I
just wanted to make sure you weren't getting confused with a different
product.
>
>I strongly not recommend to buy IBM version but instead buy PCTCPIP version.
>I had used their MS-DOS version and it work flawlessly (aside from 8 character
>limit on file name, but that' ms-dos problem).
>
>Reasons not buying from IBM:
>
>(1) Lousy support. Have you try to get in touch with IBM to get support?
> Unless you are one of the big corporation forget it!. Microsoft does
> job much bette(I think this is one reason why I would never recommend
> OS/2 2.0, it doesn't matter how good it is ). You can at least get
> PCTCP guy's attention, forget about IBM.
>
You are right on target here. IBM needs to consider the average Joe who
doesn't work for a Fortune 500 company when support is an issue. We
all pay the same money for each copy (hell, us independents probably
pay more since there are no site licenses to be had!).
>(2) Horrible Manual. There is no comparison, PCTCP manual is magnitude
> order better than IBM's manual. IBM's manual is border around
> incomprehensible.
>
FTP's manual is good. So is IBM's. My experience is that they are about
the same although I find IBM's *much* easier to read because of the
professional typesetting they used. FTP's manual looks like it came off
of the (high quality) copy machine on the other side of the office.
>(3) Bad NFS support: I never figure out (see above 1,2) how to turn off
> cr/lf translation on NFS client yet. The COPY and XCOPY it seems
> doesn't respect NFS mounted volumes. Everything is mapped to
> lowercase, this cause horrible problem in some DLL' which were
> case sensitive. Bad performance, it seems like I was on RS-232
> line instead of Ethernet
>
You have really screwed something up here. CR/LF translation is an
*option* as is respecting case in filenames. Read the manual a little
closer. I installed the product *without reading the manual* and
have had none of these problems. NFS has worked like a dream.
Performance for me is on a par with MSDOS based TCP/IP products
I've used.
>
>
>(4) Difficult installation: It was miracle that I was able to
> make this thing work. Why can't they automate installation
> especally difficult things like configuring IP network stacks.
> Yuck!
>
Installation is not as bad as you portray. The NDIS stuff is the bitch!
I'm told that the reason for this has to do with last minute requirements
layed upon the development group. They didn't have time to get the NDIS
stuff fully automated before the product release date. I've also been
told that this will be addressed in the next release.
Taking your time and FULLY reading the installation text files will
go a long way toward a successful install. As a last resort, email me
and I'll show you how I set it up.
>
>My only regrets is not being able to use PCTCPIP version (decision
>was made elsewhere), you may avoid this.
>
--
Paul Bash
>ba...@tware.com (Paul Bash) writes:
>
>>The OS/2 NFS client support is particularly nice when compared to MSDOS based
>>systems like PC/TCP Plus and, I'm sure, PC-NFS. Both IBM and FTP Software use
>>OS/2's IFS when implementing NFS clients. The biggest advantage of this is the
>>ability to see and use 256 character file names. If your NFS server happens to
>>be a Sun, or some other system using the Berkeley Fast Filesystem, you know
>>how important that can be. The advantage IBM's product has over FTP's is
>>that you can request that filenames default to lower case when not
>>explicitely specified by the user. FTP's product always defaults to uppercase.
>
>>For example, a command like:
>
>> copy test.c m:\
>
>>where m: is an NFS mounted drive, results in a file called
>
>> test.c
>
>>when using IBM's TCP/IP and
>
>> TEST.C
>
>This isn't true.
>
Sorry, with the PC/TCP 1.1 version being used in my office, this IS true.
Let me quote from the "Version 1.1 PC/TCP User's Guide", dated
March 29, 1991:
Page 18-8 (at the top)
"Note: OS/2 expands certain wildcard commands and capitalizes the
expansion. For example, this command causes all renamed files
to have uppercase extensions:
ren test.* newtest.*
Thus, test.txt becomes newtest.TXT. Also both the copy and xcopy
commands capitalize default targets. For example, uppercase filenames
on drive T: are created by these commands:
copy *.txt t:
xcopy c:\tmp t: /s
These are system limitations and cannot be worked around."
Hmmmmmm, "cannot be worked around"... well, I guess there is no reason
to call FTP Software to complain about this major inconvenience...
Wait a minute! You say you have a version that corrects this? How long
has this been out and why weren't registered users notified of this *major*
(if you believe the quote, IMPOSSIBLE) enhancement????
(NOTE: The version of PC/TCP I described was purchased by a co-worker in July
of 1991 directly from FTP Software. There has been *no* notification of any
enhancements.)
Unfortunately, that is the biggest problem in dealing with FTP Software: there
are *no* maintenance releases. You have to complain about every little
problem to get a fix. Even when they tell you "that's not a bug, its a
feature" you can't believe it. Almost every *new* copy of PC/TCP I have
purchased contained bug fixes and new features not offered in previous
releases. There has never been any notification of this new functionality
for existing users.
>
>stuff deleted
>
>
>Another 'nice' feature of FTP's OS/2 product is the ability to mount a drive
>to a host not running PSNFSD without resorting to using username nobody.
>This is achieved by the use of a local 'passwd' file which contains the relevant
>UID, GID and encrypted password information.
I never use the id "nobody". What is it used for? :-)
Getting serious for a moment: IBM's product allows me to specify my Unix
UID/GID combination. I can use PCNFSD (if you have it, why *not* use it????)
but I'm not forced to.
Like I said before, IBM's password support sucks. It would be really nice
if they had one password file that was used for Telnet, FTP and NFS access
but they don't. FTP Software should be commended for moving in this direction.
I'm told that the next release of IBM's product will address this problem.
Anthony Murdoch
>In article <1992Feb27.1...@rice.edu> sch...@is.rice.edu (Richard Alan Schafer) writes:
>>Mind you, OS/2 is still a single-user machine, so there is a single password
>This is only part of the story: OS/2 is designed as a single-user operating
>system; there is _NO_ reason to think that there won't be multi-user
>extensions and/or multi-user applications.
Has noone noticed that there is an option to use a UNIX style passwd file
that would allow multiple accounts etc. I don't think that there would be
any inherant account protection yet (except maybe restricting a user to a
given tree like ftp does) but it is certainly moving towards a multiuser
system.
Mind you, I think I would prefer to leave it as a single user workstation.
ant
Paul Bash
Under IBM's TCP/IP 1.2, the "Unix style" password file is only used for
telnet logins (and that is only done as an option). Since OS/2 has no concept
of user access permissions, once you are "in", there is no account
protection. Period.
Using FTP, there is a mechanism to restrict users to a certain part of the
OS/2 file tree. This has nothing to do with the passwd file used for
logins. There is the concept of anonymous FTP. Unfortunately, it requires
a directory called \anonymous. Unless you are on an HPFS file system, this
directory name is invalid (>8 characters) and FTPD rejects it.
Under NFS, there is *no* protection at all. Basically, TCP/IP 1.2 accepts any
UID/GID supplied. If you intend to run the NFS server, you *have* to be on
a secured network.
A NOTE is probably in order: if security means anything to you at all, don't
let any PC running any form of TCP/IP anywhere near your net. If your
company allows it, and your data is sensitive, you should isolate your subnet
by creating a firewall (see one of the recent issues of Unix/World for
details on doing this).
John Stone
Hi there, someone asked about a multiple user password file,
I've got that working fine with OS/2 1.3 and TCP/IP 1.2...
Just copy the unix type password checker to login.exe
Or you can make your own by writing a password program that returns a
0 for a success or a non zero for a failure, and name it login.exe and
put it in the tcpip/bin directory....
If you have any more questions, just mail me...
Later,
John E. Stone
jo...@cs.umr.edu
--
/* include <stddsclmr.h> | Member of Raytracaholics Anonymous */
/* EE/CS Junior. | All Unixes welcome!! */
/* University of Missouri - Rolla | */
/* Missouri's Technological University | UMR Solar Car Team */
Chris Ulrich
the extended attributes for storing information such as a file
ownership, access priveliges, etc?
I heard somewhere that UNIX was originally a single user OS, with
multiuser extensions in the file system. Extended attributes would
be perfect for this task (at least with my limited knowledge of
both operating systems and OS/2)
chris
Timothy F. Sipples
I suppose you could say that OS/2 2.0 is already multiuser. It's
called Citrix, and it apparently will be quite an operating system.
--
Timothy F. Sipples Keeper of the OS/2 Frequently Asked Questions
si...@ellis.uchicago.edu List, available via anonymous ftp from
Dept. of Economics 130.57.4.1, directory os2/faq, or via netmail
Univ. of Chicago 60637 from LIST...@BLEKUL11.BITNET.
Paul Bash
>
> Hi there, someone asked about a multiple user password file,
>I've got that working fine with OS/2 1.3 and TCP/IP 1.2...
>Just copy the unix type password checker to login.exe
>Or you can make your own by writing a password program that returns a
>0 for a success or a non zero for a failure, and name it login.exe and
>put it in the tcpip/bin directory....
>
>If you have any more questions, just mail me...
>
>Later,
> John E. Stone
> jo...@cs.umr.edu
>
Unfortunately, that only works for Telnet logins, not for FTP, NFS, etc.
Oleg Vishnepolsky
> ....
> Using FTP, there is a mechanism to restrict users to a certain part of the
> OS/2 file tree. This has nothing to do with the passwd file used for
> logins. There is the concept of anonymous FTP. Unfortunately, it requires
> a directory called \anonymous. Unless you are on an HPFS file system, this
> directory name is invalid (>8 characters) and FTPD rejects it.
Paul, \anonymous directory is not required for anonymous FTP.
You can set anonymous user id with any directory that you like.
Oleg Vishnepolsky
Peter Piggott
> copy *.txt t:
Please re-read the post - you are quite correct with a command such as copy tes
t.* but in your original example there were no wildcards.
Therefore if you do not use wildcards then the case will be preserved, but as
you said, with wildcards, 'this is a system limitation and cannot be worked
around'.
I'm sorry if I 'got your hopes up' but this was how I read your post.
If I read your post incorrectly then I apologise.
>(NOTE: The version of PC/TCP I described was purchased by a co-worker in July
>of 1991 directly from FTP Software. There has been *no* notification of any
>enhancements.)
>Unfortunately, that is the biggest problem in dealing with FTP Software: there
>are *no* maintenance releases. You have to complain about every little
>problem to get a fix. Even when they tell you "that's not a bug, its a
>feature" you can't believe it. Almost every *new* copy of PC/TCP I have
>purchased contained bug fixes and new features not offered in previous
>releases. There has never been any notification of this new functionality
>for existing users.
>
>>
>>stuff deleted
>>
>>
>>Another 'nice' feature of FTP's OS/2 product is the ability to mount a drive
>>to a host not running PSNFSD without resorting to using username nobody.
>>This is achieved by the use of a local 'passwd' file which contains the relevant
>>UID, GID and encrypted password information.
>I never use the id "nobody". What is it used for? :-)
>Getting serious for a moment: IBM's product allows me to specify my Unix
>UID/GID combination. I can use PCNFSD (if you have it, why *not* use it????)
>but I'm not forced to.
Yes this true, I haven't opened my copy of IBM's product yet. This does
provide the same functionality as I mentioned.
The point of saying this was that most DOS TCP/IP packages can only mount
drives on a host with PCNFSD with their username. Otherwise they need to use
the user nobody. (Try it with Netware NFS from a DOS NFS client.)
>Like I said before, IBM's password support sucks. It would be really nice
>if they had one password file that was used for Telnet, FTP and NFS access
>but they don't. FTP Software should be commended for moving in this direction.
>I'm told that the next release of IBM's product will address this problem.
>--
>Paul Bash Techware Design
>ba...@tware.com Boulder, CO U.S.A.
PeterP
pet...@unipalm.co.uk
James Justice
>In article <1992Feb28.1...@slc.com> se...@slc.com (Sehyo Cheng)
>writes:
>
>[ a *whole* lot of stuff deleted]
>>
>>
>>My experience with OS/2 TCP version 1.3 was pretty bad.
>>
>>I strongly not recommend to buy IBM version but instead buy PCTCPIP version.
>>I had used their MS-DOS version and it work flawlessly (aside from 8
>>character
>>limit on file name, but that' ms-dos problem).
We have also used their MS-DOS version. It works very well in a Unix
or VMS environment. We have had many problems with their TN3270 support.
To be honest the level of support for block mode terminals is kind of
sad! Bugs weren't fixed for a *long* time. I had the impression that
that they didn't understand 3270s nearly as well as IBM does.
We are still using several copies of their DOS software and are somewhat
satisfied with it. My only point is that support problems exist across
any vendor.
>>(1) Lousy support. Have you try to get in touch with IBM to get support?
>> Unless you are one of the big corporation forget it!. Microsoft does
>> job much bette(I think this is one reason why I would never recommend
>> OS/2 2.0, it doesn't matter how good it is ). You can at least get
>> PCTCP guy's attention, forget about IBM.
>>
>You are right on target here. IBM needs to consider the average Joe who
>doesn't work for a Fortune 500 company when support is an issue. We
>all pay the same money for each copy (hell, us independents probably
>pay more since there are no site licenses to be had!).
We (an educational institution) have had few problems with IBMs support.
We are not Fortune 500, but we do have a mainframe!
>>(2) Horrible Manual. There is no comparison, PCTCP manual is magnitude
>> order better than IBM's manual. IBM's manual is border around
>> incomprehensible.
>>
>
>FTP's manual is good. So is IBM's. My experience is that they are about
>the same although I find IBM's *much* easier to read because of the
>professional typesetting they used. FTP's manual looks like it came off
>of the (high quality) copy machine on the other side of the office.
I have read both manuals and think they both have room for improvement.
IBM's is far prettier but sometimes doesn't have information you need.
FTP Software's can be kind of hard to follow.
We had an early copy of FTP Sofware's OS/2 product and never got it to
work. I am sure, it is much improved now! To be honest, it was hell
on wheels to get our first copy of IBM's TCP/IP Version 1.1 to work as
well. With the help of a VMS system programmer, we got it going.
>>(3) Bad NFS support: I never figure out (see above 1,2) how to turn off
>> cr/lf translation on NFS client yet. The COPY and XCOPY it seems
>> doesn't respect NFS mounted volumes. Everything is mapped to
>> lowercase, this cause horrible problem in some DLL' which were
>> case sensitive. Bad performance, it seems like I was on RS-232
>> line instead of Ethernet
>>
>
>You have really screwed something up here. CR/LF translation is an
>*option* as is respecting case in filenames. Read the manual a little
>closer. I installed the product *without reading the manual* and
>have had none of these problems. NFS has worked like a dream.
>
>Performance for me is on a par with MSDOS based TCP/IP products
>I've used.
I have used the NFS product in both client and server and it works will.
In fact a 486 running OS/2 TCP/IP NFS server is faster then a small
RS/6000 doing the same. IBM's is supposed to have improved this in
latest release of OS for RS/6000. We haven't installed and tested
the newest OS yet!
>
>>
>>
>>(4) Difficult installation: It was miracle that I was able to
>> make this thing work. Why can't they automate installation
>> especally difficult things like configuring IP network stacks.
>> Yuck!
>>
Installation is kind of nasty for the NDIS stuff, but my experience with
all this Unix stuff is that installation is never very easy. Unix
programs just expect me to know a lot of stuff and the first time We had
to install this TCP/IP stuff on DOS and OS/2 with no previous Unix
TCP/IP experience was a real problem for both FTPs DOS product and IBMs
OS/2 product.
I must say that I have used IBM's TCP/IP product in both version 1.1
and version 1.2 and I think it is a fine product which I would
recommend to anyone.
Paul Bash
>ba...@tware.com (Paul Bash) writes:
>
>>In article <1992Feb28.1...@unipalm.uucp> pet...@unipalm.uucp (Peter Piggott) writes:
>>>ba...@tware.com (Paul Bash) writes:
>>>
>>>>The OS/2 NFS client support is particularly nice when compared to MSDOS based
>>>>systems like PC/TCP Plus and, I'm sure, PC-NFS. Both IBM and FTP Software use
>>>>OS/2's IFS when implementing NFS clients. The biggest advantage of this is the
>>>>ability to see and use 256 character file names. If your NFS server happens to
>>>>be a Sun, or some other system using the Berkeley Fast Filesystem, you know
>>>>how important that can be. The advantage IBM's product has over FTP's is
>>>>that you can request that filenames default to lower case when not
>>>>explicitely specified by the user. FTP's product always defaults to uppercase.
>>>
>>>>For example, a command like:
>>>
>>>> copy test.c m:\
>>>
[stuff deleted]
> Please re-read the post - you are quite correct with a command such as copy
>test.* but in your original example there were no wildcards.
>Therefore if you do not use wildcards then the case will be preserved, but as
>you said, with wildcards, 'this is a system limitation and cannot be worked
>around'.
>
Hmmm. As memory serves me, the target filename was uppercased anytime it was
not explicitely specified, wildcard or not. Unfortunately, I haven't used
the FTP product since I acquired IBM's in December, so I don't have a version
to verify it on. Since it has been so long, my memory of the exact behavior
has deteriorated.
Assuming that you are correct, it doesn't change the fact that the
behavior PC/TCP exhibits is deficient.
I use my Unix server to store source and object files, primarily. I
typically move groups of files together between my workstation and the
server for unit test under a PC resident simulator (Why not just access
the files across the net? Because it can be so slow at times as to exceed
the threshhold of tolerance. Having them local assures a constant, fast,
response time. I'm more productive as a consequence). Being forced to copy
10 or 100 files one at a time so I can control the case is not acceptable.
Being forced to take the time to write a script to move the files, then
having to remember to use it every time, then having to take the time to
repair the damage when I don't is also unacceptable.
You might think I'm just being picky but I believe my tools should work
for *me*, not the other way around. A network client should be as
transparent as possible to the user. In my situation, PC/TCP
forces me to jump through hoops to work around it. Copying files between
a server and a workstation is not exactly a rare thing to do! It should
be as straight forward and easy as possible (things don't get much easier
than "copy *.c m:\").
I have to strongly disagree that PC/TCP's behaviour 'is a system
limitation and cannot be worked around' (hence the sarcastic tone of my
post, for which I apologize). Obviously, it can be worked around since IBM
has done so.
If I don't specify the target filename, the client software is forced
to choose a default since it can't read my mind. IBM's product allows me
to specify which default I prefer: all uppercase or all lowercase. FTP
does not allow this flexibility. Were the server another OS/2 system,
this wouldn't be any big deal. On a Unix file server it most definitely is
a big deal because the case is significant ("Oh, My God! There are two copies
of *everything*. Which set is valid???"). There are a hell of a lot more
Unix NFS servers than OS/2. IBM's approach is a very effective workaround
given the problem.
>I'm sorry if I 'got your hopes up' but this was how I read your post.
>If I read your post incorrectly then I apologise.
>
Like I said, I was being sarcastic. Sorry. My hopes were never "up" because I
gave up on PC/TCP the day I installed IBM's TCP/IP.
(well, maybe the second day, after I had time to see how nice IBM TCP/IP was.
The first day, I was still annoyed about having spent so much time getting
the NDIS stuff working ;-).
Paul Bash
[stuff deleted]
>
> Please re-read the post - you are quite correct with a command such as copy
>test.* but in your original example there were no wildcards.
>Therefore if you do not use wildcards then the case will be preserved, but as
>you said, with wildcards, 'this is a system limitation and cannot be worked
>around'.
>
Peter,
Ok, I went back and re-read my post and your comment. You are right; My
example was different from the one you gave.
With a fair amount of curiosity, I went back and tried my original example
along with your example on PC/TCP 1.1 for OS/2 Patch Level 0 (none),
purchased in February '91, and Patch Level 1, purchased in July or August '91.
In fact it doesn't matter whose example is used, it still results in an
uppercase filename on the server just as I originally described.
If I remember correctly, your original post mentioned that you have
Patch Level 2. If pl2 corrects the above described behavior, then you
owe registered users at least some form of notification of its existence
since the documentation so clearly states 'this is a system limitation
and cannot be worked around'.
As I said before, IBM's TCP/IP 1.2 does not have this limitation and is
is about 1000 times more enjoyable to work with because of it (among other
things).
Paul Bash
Peter,
Before this tit-for-tat goes on forever, let me guess that you are copying
your files from an HPFS partition to the server? Right? If so, this probably
explains the discrepancy between what you and I are seeing. I am using
a FAT partition.
I know that MSDOS returns uppercase filename when an application requests
one. I would guess that OS/2 returns uppercase filenames for a FAT filesystem
but respects the case for HPFS filesystems. This would explain why your
example works as you describe and mine works as I describe.
All the more reason for FTP Software to make this an option and to remove
that dumb statement about "... cannot be worked around" from their manual.
Paul
Larry Backman
>> to call FTP Software to complain about this major inconvenience...
I wrote this; I was wrong; so hang me....
>>
>> Wait a minute! You say you have a version that corrects this? How long
>> has this been out and why weren't registered users notified of this *major*
>> (if you believe the quote, IMPOSSIBLE) enhancement????
What Peter is referring to is probably due to the fact that he is using an
HPFS drive which does the correct mapping; while the FAT file system assumes
Uppercase by default.
For whatever its worth; it really is a filesystem limitation imposed by
the FAT case conventions. As has been rubbed in my face; i will reimplement
the ini file parametr I took out 2 years ago to allow a user to select the
case of their choice. Its OS/2, whats a little more code in a driver :-).
>>
>> (NOTE: The version of PC/TCP I described was purchased by a co-worker in July
>> of 1991 directly from FTP Software. There has been *no* notification of any
>> enhancements.)
There have not been any upgrades since PCTCP for OS/2 V1.1 PL1 which was
released in June.
>>
>> Unfortunately, that is the biggest problem in dealing with FTP Software: there
>> are *no* maintenance releases. You have to complain about every little
>> problem to get a fix. Even when they tell you "that's not a bug, its a
>> feature" you can't believe it. Almost every *new* copy of PC/TCP I have
>> purchased contained bug fixes and new features not offered in previous
>> releases. There has never been any notification of this new functionality
>> for existing users.
Paul; we've previously crossed swords on pcip about this subject before.
I will stand behind FTP's support of any of our products especially
as opposed to our competitors in either DOS or OS/2.
Of course you have to complain to get action; we are not mind readers;
read our manual; it give a phone number and an email address to
direct problems to.
In addition; what is wrong with improving fucntionality in new releases;
I would think this is good not bad. To the contrary; we do notify
users as to upgrades. I assure you given my personal interest in OS/2's
success and the lower proportion of OS/2 sales of PCTCP to DOS sales of
PCTCP; we sure do go out of our way to keep our OS/2 customers happy.
Larry Backman
Chief Architect
FTP Software
Larry Backman
>> my comments will hold up there as well: basically, there is just no
>> comparision between running TCP/IP on OS/2 as compared to MSDOS. OS/2
>> is a REAL OPERATING SYSTEM and feels that way.
Recent tests at Connectathon would kind of bear out what you say; our
DOS NFS redirector is much faster than the OS/2 client (400%) on
system IO intensive operations ( tree /f of a 1300 directory tree).
However due to its ability to allocate memory, translated into 8K RPC's
rather than 1K RPC's; the OS/2 redirector can move large chunks
of data just as fast (~300Kbytes/sec.on a 386/25) as the DOS one.
>>
>> Under OS/2, I've used both IBM's TCP/IP 1.2 and FTP Software's PC/TCP 1.1
>> and prefer, by a large margin, the IBM package. I'm sure that FTP
>> Software will keep their OS/2 package competitive but, as of right now, the
>> IBM package is more complete in that it offers NFS *server* and X server
>> capabilities (both of which work well) along with source code for the
>> development libraries. 3270 emulation support is also first rate (what
>> else would you expect of IBM :-).
While IBM does have more features right now; as you surmise; FTP Software
is not standing still. I also should point out that the FTP OS/2 redirector
successfully passed interoperability testing with all working NFS servers
at Connectathon, *the* place to be seen if you do NFS. It was the only OS/2
product at the show.
>> OS/2's IFS when implementing NFS clients. The biggest advantage of this is the
>> ability to see and use 256 character file names. If your NFS server happens to
>> be a Sun, or some other system using the Berkeley Fast Filesystem, you know
>> how important that can be. The advantage IBM's product has over FTP's is
>> that you can request that filenames default to lower case when not
>> explicitely specified by the user. FTP's product always defaults to uppercase.
Message received; bug fix forthcoming......
Larry Backman
FTP Software