jdc@naucse.UUCP (John Campbell) (09/14/89)
My administrator believes in IBM so much that when we mentioned that we
needed to be able to read tapes on a mainframe and move the data down
to work stations via TCP/IP he said use our IBM mainframe (CMS, MVS, and
VM). Slightly more reasonably, he further suggested we could purchase
AIX and run it as a "virtual machine" under VM.
I know nothing of IBM. Is this reasonable? Is AIX a real unix when it
runs on a big IBM? Specifically, would Sun/Iris/Apollo users understand
the IBM world if they came in through the AIX back door? (And does
*anyone* know how good a TCP/IP internet running on ethernet implementation
will be for such users?)
--
John Campbell ...!arizona!naucse!jdc
CAMPBELL@NAUVAX.bitnet
unix? Sure send me a dozen, all different colors.ehrlich@cs.psu.edu (Daniel Ehrlich) (09/15/89)
In article <1702@naucse.UUCP> jdc@naucse.UUCP (John Campbell) writes:
My administrator believes in IBM so much that when we mentioned that we
needed to be able to read tapes on a mainframe and move the data down
to work stations via TCP/IP he said use our IBM mainframe (CMS, MVS, and
VM). Slightly more reasonably, he further suggested we could purchase
AIX and run it as a "virtual machine" under VM.
I know nothing of IBM. Is this reasonable? Is AIX a real unix when it
runs on a big IBM? Specifically, would Sun/Iris/Apollo users understand
the IBM world if they came in through the AIX back door? (And does
*anyone* know how good a TCP/IP internet running on ethernet implementation
will be for such users?)
AIX V2 (Advanced Interactive Executive) has roots in UNIX System V
Release 3 (I think). Some people believe it is UNIX. I do not. It
is sufficiently different from what I have been using for the last 10
years (BSD UNIX and it's derivatives) that I find AIX painful to use.
AIX/370 will run as a guest under VM/XA and does support TCP/IP and
NFS.
AIX V3 is supposedly `better' for people from the BSD universe. I can
not say as I have not been able to play with AIX V3 yet. Who knows,
maybe they (IBM) got it right this time.
--
John Campbell ...!arizona!naucse!jdc
CAMPBELL@NAUVAX.bitnet
unix? Sure send me a dozen, all different colors.
--
Dan Ehrlich <ehrlich@cs.psu.edu> | "A message is not a message until the
The Pennsylvania State University | rules for interpreting it are in the
Department of Computer Science | hands of the reciever."
University Park, PA 16802 | --Apollo Belvedere Smithshore@mtxinu.COM (Melinda Shore) (09/16/89)
In article <EHRLICH.89Sep15113249@shire.cs.psu.edu> ehrlich@cs.psu.edu (Daniel Ehrlich) writes: >AIX V2 (Advanced Interactive Executive) has roots in UNIX System V >Release 3 (I think). Some people believe it is UNIX. I do not. That's not to say that AIX isn't Unix - it is. There's a considerable amount of anti-SysV bigotry, particularly in the academic community. -- Melinda Shore shore@mtxinu.com Mt Xinu ..!uunet!mtxinu.com!shore
karish@forel.stanford.edu (Chuck Karish) (09/16/89)
[ Oh, wonderful! More gratuitous IBM-bashing! ] In article <EHRLICH.89Sep15113249@shire.cs.psu.edu> ehrlich@cs.psu.edu (Daniel Ehrlich) wrote: >In article <1702@naucse.UUCP> jdc@naucse.UUCP (John Campbell) writes: > Slightly more reasonably, he further suggested we could purchase > AIX and run it as a "virtual machine" under VM. > I know nothing of IBM. Is this reasonable? Is AIX a real unix when it > runs on a big IBM? Specifically, would Sun/Iris/Apollo users understand > the IBM world if they came in through the AIX back door? (And does > *anyone* know how good a TCP/IP internet running on ethernet implementation > will be for such users?) >AIX V2 (Advanced Interactive Executive) has roots in UNIX System V >Release 3 (I think). The original port (AIX 1.0) to the RT was from SysVR2. The PS/2 version, and, I believe, the 370 hosted version, are based on 4.3BSD. The user interface draws from both worlds. My understanding is that by the time 3.0 is released, all three platforms will be running the same code. >Some people believe it is UNIX. I do not. It >is sufficiently different from what I have been using for the last 10 >years (BSD UNIX and it's derivatives) that I find AIX painful to use. This says that it's not BSD, not that it's not UNIX. Adapting from AIX to SunOS should be no harder than adapting from SunOS to the Apollo's system(s). Chuck Karish karish@mindcraft.com (415) 493-9000 karish@forel.stanford.edu
kevin@msa3b.UUCP (Kevin P. Kleinfelter) (09/17/89)
The original question involved using TCP/IP to move files from a 370 to a Unix workstation... The easiest answer is to get TCP/IP for MVS (the normal large 370 operating system). Why purchase AIX/370, just to move data from the 370 to a workstation? Now don't get me wrong; when AIX/370 hits general availability soon, I plan to push hard to get it. However, I have different needs. Also, AIX/370 is a little peculiar in that you can't just hook-up a terminal to your 370, and login. It is my understanding that the ONLY things you can do with AIX/370 require either AIX for PS/2, AIX for RT, or "AIX Access for DOS" to login. Once again, when available, there is a pretty slick facility, called TCF, for sharing work with a 370. You don't need these things to move data. AIX is not particularly EASY to setup on a 370. If you just want to move data over TCP/IP, you don't need AIX. -- Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347 gatech!nanovx!msa3b!kevin
jackv@turnkey.gryphon.COM (Jack F. Vogel) (09/20/89)
In article <1127@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: > >The original question involved using TCP/IP to move files from a 370 to >a Unix workstation... The easiest answer is to get TCP/IP for MVS >(the normal large 370 operating system). Why purchase AIX/370, just to >move data from the 370 to a workstation? I agree partially, given that all you want is file storage, furthermore, there is also a TCP/IP and NFS package available for VM. But perhaps if your workstations are Unix based, it would be arguable that a Unix type filesystem on your 370 would be desirable. Especially since AIX370 comes with full NFS, it makes for a seamless filesystem integration or at least for a more intuitive one (VM/CMS and MVS have a flat filesystem). >Now don't get me wrong; when AIX/370 hits general availability soon, I >plan to push hard to get it. However, I have different needs. Also, >AIX/370 is a little peculiar in that you can't just hook-up a terminal >to your 370, and login. Glad to hear you will be a customer :-}. The reason you can't just hook up a terminal and go is because as far as VM is concerned the AIX system is just another user, just like someone who logs in and runs CMS, and since VM does not allow multiple logins...well, you see. However, if VM TCP/IP is installed the regular VM user can telnet to the IP address of the AIX370 virtual system and use it as a regular user. >It is my understanding that the ONLY things >you can do with AIX/370 require either AIX for PS/2, AIX for RT, or >"AIX Access for DOS" to login. Once again, when available, there is >a pretty slick facility, called TCF, for sharing work with a 370. This is not strictly true, there are plenty of places where a large network of Sun or other workstation users are accessing AIX370 by simply telneting in. The PS/2's are a special case in that they can make up a distributed Unix cluster with one or more 370 systems. This is what is called TCF (Transparent Computing Facility). It provides a root and maybe multiple user filesystems that transparently span up to 30 systems. It is one of the added value features that Locus provides to IBM, and your right it is very slick!! Also these PS/2's can then be outfitted with multiport serial cards and 16 or more regular terminal users can be hung off them, this is the kind of setup we actually use here at Locus. >AIX is not particularly EASY >to setup on a 370. Well, I don't know that anything is particularly easy to set up on a 370 :-)! Actually , since I can install a system in a few hours and I understand VM or MVS installs sometimes go into weeks I would rate the AIX370 install as relatively easy :-}. Also, in response to that poster who claimed AIX is not Unix, all I have to say is that the last time I looked at the source (which was a few minutes ago :-} ), it certainly looked like a combination of 5.2 and 4.3 stuff to me :-} :-}. Disclaimer: This is not an official statement, my opinions are my own. -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
dhesi@sun505.UUCP (Rahul Dhesi) (09/22/89)
In article <978@mtxinu.UUCP> shore@mtxinu.com (Melinda Shore) writes: >There's a considerable >amount of anti-SysV bigotry, particularly in the academic community. Admittedly there's a lot of SysV-bashing that goes on, but I find that it is quite justified. If you don't have time to repeatedly defragment filesystems, need longer filenames, need links that will work across partitions, wish control characters and tabs would properly echo on the screen, need some way of preventing 400 casual users from using more than 100 K of disk space each, need a decent network mailer without having to acquire and install it yourself, want to be able to use scripts interpreted by different shells, want to be able to use a screen editor to edit message headers when sending mail, want to edit the password file without race conditions, need online manuals for L.sys and uucico, et al ad nauseum, it's hardly bigotry to prefer BSD to SysV. Note that Mt Xinu itself (where Melinda Shore is posting from) has chosen to take BSD and add SysV functionality to it, rather than doing the opposite. I'm sure it is for a very simple reason: SysV simply does not have the capability to provide everything that BSD provides. The reverse is easily true. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
ekrell@hector.UUCP (Eduardo Krell) (09/22/89)
In article <868@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >SysV simply >does not have the capability to provide everything that BSD provides. Which some see as being a feature ... Bigger does not necessarily mean better. >The reverse is easily true. Clearly not. Without something like Streams, you can't easily add support for new protocols. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
guy@auspex.auspex.com (Guy Harris) (09/24/89)
>Note that Mt Xinu itself (where Melinda Shore is posting from) has >chosen to take BSD and add SysV functionality to it, rather than doing >the opposite. I'm sure it is for a very simple reason: SysV simply >does not have the capability to provide everything that BSD provides. >The reverse is easily true. This depends on what you mean by "have the capability to provide everything...". Yes, you'd have to hack the S5 source code to provide the capabilities that BSD provides, but you have to hack the BSD source code to provide the capabilities that S5 provides. It may be *easier*, by and large, to do the latter, but that's a different matter; once you've done either one, what you have isn't "S5" or "BSD", strictly speaking, and frankly I'd prefer a well-done modified system of that sort to either vanilla S5 *or* BSD. BTW, S5R4 should handle most, if not all, of what you list above, given that it'll support both the V7/S5 and BSD file systems (the latter complete with long file names and quotas), a tty driver with a nicer BSD-style user interface (derived from the SunOS 4.x one), some form of network mailer (whether "sendmail"-derived, UPAS-derived, or both, I'm not sure), and "#!" (to handle the 3 shells - Bourne, C, and Korn - which I expect S5R4 to have). (I'm surprised you didn't list job control - which S5R4 will have as well.) It should also have a dynamic linking mechanism complete with a programmatic interface (hopefully sufficient to replace 90% of the dynamic linking code used by e.g. the "class" stuff in Andrew), and a pseudo-tty driver that lets the program on the master side listen for "ioctl"s on the client side, neither of which current BSD releases have, although I hope 4.4BSD has both of them.
guy@auspex.auspex.com (Guy Harris) (09/24/89)
>>SysV simply >>does not have the capability to provide everything that BSD provides. > >Which some see as being a feature ... Bigger does not necessarily mean >better. These days, I'm not sure BSD is any "bigger" than S5.... >Clearly not. Without something like Streams, you can't easily add support >for new protocols. I shall let the people doing the OSI implementation for BSD, and doing protocol implementations for streams, fight this one out; all I'll say is that I don't see any evidence to back up a claim stated as bluntly as "without something like streams...".
dhesi@sun505.UUCP (Rahul Dhesi) (09/24/89)
In article <2486@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >BTW, S5R4 should handle most, if not all, of what you list above... When it does, if it does, and if computer systems don't crumble under the weight of its mighty kernel, we will all be happy. However, I doubt that S5R4 will really be System V, any more than SunOS is System V. I suspect it will be SunOS, based on BSD as always, with more features added. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/24/89)
In article <868@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >Note that Mt Xinu itself (where Melinda Shore is posting from) has >chosen to take BSD and add SysV functionality to it, rather than doing >the opposite. I'm sure it is for a very simple reason: SysV simply >does not have the capability to provide everything that BSD provides. >The reverse is easily true. Oh, bullshit. Neither SVR3 nor 4.3BSD is capable of fully emulating the other's services. It happened that I needed a System V environment for applications and software development and had to use Berkeley-based systems, so I designed and produced an SVR2 emulation that can be added as a layer atop 4.2BSD or 4.3BSD. I don't know what Mt. Xinu's currently offering, but they started with my System V emulation as an add-on option for the 4.nBSD systems that they offer commercial support for. As Melinda said, there is a lot of bigotry out there. Mostly I think it stems from people being annoyed when faced with environments that don't offer all the facilities they've gotten accustomed to. As one who works primarily in a System V environment, I find "raw BSD" extremely annoying. Just as Rahul is accustomed to BSD and finds raw System V annoying. The best environment is probably one that offers the facilities of both, e.g. 4.3BSD+BRL SysV emulation, or SVR4, or several vendor offerings.
ekrell@hector.UUCP (Eduardo Krell) (09/24/89)
In article <2487@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>Clearly not. Without something like Streams, you can't easily add support ^^^^^^ >>for new protocols. >all I'll say >is that I don't see any evidence to back up a claim stated as bluntly as >"without something like streams...". That depends on your own definition of "easily", doesn't it? You can agree or disagree on whether it's easier for you or not, but the statement still holds for some value of "easy" (mine, for instance), thus it's not an absolute statement (like the original one I was responding to). Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/24/89)
In article <890@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >However, I doubt that S5R4 will really be System V, any more than SunOS >is System V. I suspect it will be SunOS, based on BSD as always, with >more features added. Why should we care what you "doubt" and "suspect" when it's all guesswork? If you attended any of the SVR4 presentations, such as the AT&T BOF at the Baltimore Usenix, it would have been quite apparent that the SVR4 implementation has little in common with BSD, other than a common 7th Edition UNIX heritage. Its memory management, like SunOS's, is entirely different. Its character I/O system is entirely different. Its general filesystem support is entirely different (although one module does support BSD filesystems as a special case). Its network base is entirely different, although some of the "r-commands" may have been adapted from BSD versions. And in general it makes the current BSD release look sick.
ekrell@hector.UUCP (Eduardo Krell) (09/24/89)
In article <890@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: (about SVR4) >I suspect it will be SunOS, based on BSD as always, with >more features added. No, it's not. It might look like BSD if you're running with a BFS (Berkeley File System) and the BSD-style tty driver (supplied by a streams module) but it's really a System V kernel with lots of BSD and SunOS features and user-level utilities added. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
madd@bu-cs.BU.EDU (Jim Frost) (09/26/89)
In article <11148@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: |In article <890@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: |the SVR4 |implementation has little in common with BSD [...] |Its memory management, like SunOS's, is entirely |different. Please, please tell me it's entirely different from that of sVr3. I'm getting pretty tired of figuring out just how many of each NBLK parameter I'm going to be using before I use it, and really tired of watching my system's performance degrade the longer it stays up. These things don't happen under vanilla 4.3 or SunOS! |Its general |filesystem support is entirely different (although one module does support |BSD filesystems as a special case). Well, that's good, the current filesystem is terrible. I hope the new one is much improved. I miss both long filenames and good filesystem response when dealing with sysV. |Its network base is entirely |different, What do you mean by "entirely"? I'll be really unhappy if it only talks to other sysV machines. |And in general it makes the current BSD release look sick. That's good news, it's been too long coming. What I'd really like to know is if there are any publications which describe what's new and what's changed in sVr4. Any leads? This kind of information would go a long way towards appeasing those of us who would really like to know if the new, improved, sysV will be all that has been promised, or if we'll just have to wait until 4.3 runs on our hardware. jim frost software tool & die madd@std.com
kevin@msa3b.UUCP (Kevin P. Kleinfelter) (09/26/89)
Can we PLEASE change the "Subject:" field on this one? It no longer has ANYTHING to do with AIX! -- Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347 gatech!nanovx!msa3b!kevin
guy@auspex.auspex.com (Guy Harris) (09/26/89)
>That depends on your own definition of "easily", doesn't it? >You can agree or disagree on whether it's easier for you or not, >but the statement still holds for some value of "easy" (mine, >for instance), thus it's not an absolute statement And also not an interesting one, given that you haven't stated what your definition of "easy" is; absent that definition, one cannot accept your claim about streams as being interesting, since said definition might not be particularly useful.
guy@auspex.auspex.com (Guy Harris) (09/26/89)
>>I suspect it will be SunOS, based on BSD as always, with >>more features added. > >No, it's not. Correct, but then saying SunOS 4.x is "based on BSD" is also misleading. Both SunOS 4.x and S5R4 include code derived from BSD code. They also include code derived from V7, from S5R2, from S5R3, and written afresh for S5R4. >It might look like BSD if you're running with a BFS (Berkeley >File System) and the BSD-style tty driver (supplied by a streams >module) By "BSD-style tty driver" do you mean the streams module that supplies "tty driver" functionality ("ldterm"), or one that maps V7-style, BSD-style, and presumably Xenix-style "ioctl"s into the extended S5-style "ioctl"s that "ldterm" supports" ("ttcompat", unless they changed the name from its name in SunOS)? >but it's really a System V kernel with lots of BSD and SunOS features and >user-level utilities added. Well, yeah, since it's System V it is, by definition, a System V kernel. However: the VM subsystem is different from that of earlier S5 releases (based on SunOS 4.x, and therefore not particularly like BSD); the process management code is different from that of earlier S5 releases (written for POSIX, etc., and not particularly like BSD internally); the scheduler is different from that of earlier S5 releases (to support selectable scheduling policies - and it's not particularly like BSD internally, either); the pluggable-file-system mechanism is different from that of earlier S5 releases (based on SunOS 4.x VFS, with some grot cleaned up - and not like BSD, since current BSD doesn't *have* a pluggable-file-system mechanism); so, while it's not "BSD-based" in the sense that they didn't start with BSD, enough has changed from previous S5 releases that it's not just a minor tweak on S5R3, either.
ekrell@hector.UUCP (Eduardo Krell) (09/26/89)
In article <2497@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >And also not an interesting one, I think the readers should be left to decide what's interesting to them and what's not on their own, IMHO. I hate wasting net bandwidth on this. If you want to continue the discussion on whether you find it easier to implement communication protocols with Streams vs. adding more system calls to the kernel, we can do so by e-mail. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/27/89)
In article <38836@bu-cs.BU.EDU> madd@cs.bu.edu (Jim Frost) writes: -In article <11148@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: -|In article <890@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: -|the SVR4 -|implementation has little in common with BSD [...] -|Its memory management, like SunOS's, is entirely -|different. -Please, please tell me it's entirely different from that of sVr3. Yes, it is. SVR3 memory management was based on "regions" a la VMS; SVR4's VM is a page-based system based on SunOS's approach. -|Its network base is entirely different, -What do you mean by "entirely"? I'll be really unhappy if it only -talks to other sysV machines. I mean that BSD's fundamental networking mechanism is the "socket" while SVR4's is based on streams. The word "base", and especially the mention of "r-commands", should indicate that I wasn't talking about global protocols. TCP/IP, UDP, etc. are supposed to be supported in addition to the usual AT&T-specific facilities. -What I'd really like to know is if there are any publications which -describe what's new and what's changed in sVr4. I'm not sure I should volunteer this information, but the title foil for the "SVR4 Overview" from the Baltimore USENIX conference presentation had Marilyn Partel's name on it (mar@attunix.att.com). Perhaps she can send you the complete information packet as handed out in Baltimore, or tell you where you can get it.
guy@auspex.auspex.com (Guy Harris) (09/28/89)
>>And also not an interesting one, > >I think the readers should be left to decide what's interesting to them >and what's not on their own, IMHO. I find it impossible to take anyone seriously the assertion that "well, I can say 'x isn't easy' because my definition of 'easy' says it's not easy", if the person making this assertion doesn't bother to give their definition of "easy". If there *are* people out there who can take this seriously, I consider that their problem. It really wouldn't have been *that* hard to actually give your definition, so that people can actually decide whether it makes sense or not. I infer from your statement about "adding more system calls to the kernel" that that is the basis of your statement; had you mentioned it in the first place, it would have been a lot better. I shall simply note that the streams mechanism is having stuff added to it in S5R4 to support out-of-band data and to support TCP urgent data, and note therefore that if the current BSD socket mechanism needs change to support the ISO protocols, perhaps even including new system calls (although, frankly, I would rather take e.g. Keith Sklower's word for it that it's necessary than yours, since he's one of the people actually *implementing* the ISO protocols on BSD), this cannot necessarily be claimed as an advantage for S5 streams, since they required modification as well....