pack@acd.uucp (Daniel Packman) (06/04/91)
In article <1991Jun3.173646.25682@ux1.cso.uiuc.edu> Paul-Pomes@uiuc.edu writes: >johan@dutnak2.tudelft.nl (Johan Haas) writes: > >>We are considering to replace our current Convex C1 with a mix >>of RS/6000 systems instead of upgrading to a Convex C2. > >I would closely examine the overhead of administering a RS/6000 system. >Why IBM gave us AIX instead of UNIX is beyond me. > Some of the differences in AIX seem perverse (eg, why not spell it f77 instead of xlf?), but most of the differences are attempts to make things better. I'd take the journaled file system over sys V or berekely any day. The shadow password file in /etc/security is a good thing. The philosophy of the odme database is fine in that it allows for faster binary formats for the standard ascii unix files. Some of the methods of accessing and dealing with these objects is a bit rough yet. One big unix problem is the lack of standardization of the adminstration. If smit, for example (anything that works would be ok with me), were a standard, it would help a lot of us admistrators who muck around in multi-vendor shops. One philosophical problem with smit or any high level adminstrative tool is that if anything goes wrong with an operation, one has to delve into low level error codes. Avoiding this problem almost means putting artificial intelligence into the error recovery code in smit. A problem. Dan Packman NCAR INTERNET: pack@ncar.UCAR.EDU (303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET Boulder, CO 80307-3000 DECNET SPAN: 9583::PACK
de5@ornl.gov (Dave Sill) (06/04/91)
In article <11640@ncar.ucar.edu>, pack@acd.uucp (Daniel Packman) writes: > >I'd take the journaled file system over sys V or berekely any day. How about the day one of your disks crashes? Like, maybe the one that's got pieces of /, /usr, /u, etc. on it, and instead of restoring one drive's worth of stuff, you have to restore everything? Maybe I'm missing something, and there's some easy way to recover from a crash without rebuilding all the disks that happened to have partitions shared with the one that crashed. If so, I'm sure someone will set me straight. -- Dave Sill (de5@ornl.gov) Tug on anything in nature and you will find Martin Marietta Energy Systems it connected to everything else. Workstation Support --John Muir
gs26@prism.gatech.EDU (Glenn R. Stone) (06/05/91)
In <1991Jun4.163505.29244@cs.utk.edu> de5@ornl.gov (Dave Sill) writes: >In article <11640@ncar.ucar.edu>, pack@acd.uucp (Daniel Packman) writes: >> >>I'd take the journaled file system over sys V or berekely any day. >How about the day one of your disks crashes? Like, maybe the one >that's got pieces of /, /usr, /u, etc. on it, and instead of restoring >one drive's worth of stuff, you have to restore everything? You can tell it which drive to put things on.... Granted that it takes installing the system and then immediately reloading it, but c'est la guerre.... Packman is right, though, I've pushed the Big Yellow Button on all of my '6000's on multiple occasions each; only once have I _ever_ heard a squeaky out of fsck.... it just doesn't lose stuff. Besides, I back up by logical partition, not by physical; it's not going to matter to me, anyway. I'd much rather take the extra time on the one-in-a-million head crash than take double the time out of my day every time one of my scientists 888's his machine with too many windows..... -- Glenn R. Stone glenns@eas.gatech.edu
carl@probitas.cs.utas.edu.au (Carl Lewis) (06/05/91)
In comp.unix.aix you write: >In <1991Jun4.163505.29244@cs.utk.edu> de5@ornl.gov (Dave Sill) writes: >>In article <11640@ncar.ucar.edu>, pack@acd.uucp (Daniel Packman) writes: >>> >>>I'd take the journaled file system over sys V or berekely any day. >>How about the day one of your disks crashes? Like, maybe the one >>that's got pieces of /, /usr, /u, etc. on it, and instead of restoring >>one drive's worth of stuff, you have to restore everything? >You can tell it which drive to put things on.... Granted that it >takes installing the system and then immediately reloading it, >but c'est la guerre.... Packman is right, though, I've pushed >the Big Yellow Button on all of my '6000's on multiple occasions >each; only once have I _ever_ heard a squeaky out of fsck.... >it just doesn't lose stuff. Besides, I back up by logical partition, NUP , Sorry but it does. We were having trouble with lack of space in /tmp , a few quick comparisons of df an du showed a missing 11 Mg ( a problem when the partition is 12 Meg :-). A quick fsck showed all the missing blocks marked as lost (?) . fsck WOULDN'T reclaim them, we had to destroy and recreate the partition (thankfully not to much of a headache under jfs. But jfs can and does 'loose it'. We've had other problems in which jfs is implicated but at the moment we can't quite pin it squarely through jfs alone. We tracke out problem down to one program somehow confusing hell out of jfs and so stopped using that program (screen dammit :-( :-( ). >not by physical; it's not going to matter to me, anyway. I'd >much rather take the extra time on the one-in-a-million head crash >than take double the time out of my day every time one of my >scientists 888's his machine with too many windows..... >-- Glenn R. Stone >glenns@eas.gatech.edu -- Carl : Programmer (etc) with University of Tasmania Internet : carl@cs.utas.edu.au || C.S.Lewis@cs.utas.edu.au Address || carl@probitas.cs.utas.edu.au
dls@achilleus.austin.ibm.com (David Skeen) (06/05/91)
In article <11640@ncar.ucar.edu>, pack@acd.uucp (Daniel Packman) writes: > Some of the differences in AIX seem perverse (eg, why not spell it f77 > instead of xlf?) It's important to note that xlf is NOT f77; that's not a mere spelling difference, the name change was justified. I am not an official IBM spokesman. -- Dave Skeen IBM Internal: dls@achilleus.austin.ibm.com D61/803 Zip 2603 IBM VNET: SKEEN at AUSTIN Austin, TX 78758 Internet: dls@dce.austin.ibm.com
geoff@ugc.uucp (Geoff Coleman) (06/05/91)
In article <30577@hydra.gatech.EDU> glenns@eas.gatech.edu writes: >In <1991Jun4.163505.29244@cs.utk.edu> de5@ornl.gov (Dave Sill) writes: > >>In article <11640@ncar.ucar.edu>, pack@acd.uucp (Daniel Packman) writes: >>> >>>I'd take the journaled file system over sys V or berekely any day. > >>How about the day one of your disks crashes? Like, maybe the one >>that's got pieces of /, /usr, /u, etc. on it, and instead of restoring >>one drive's worth of stuff, you have to restore everything? Yes isn't that a lot of fun. And no after the third or fourth time around I haven't found a quicker way. > >You can tell it which drive to put things on.... Granted that it >takes installing the system and then immediately reloading it, >but c'est la guerre.... Packman is right, though, I've pushed >the Big Yellow Button on all of my '6000's on multiple occasions >each; only once have I _ever_ heard a squeaky out of fsck.... And just hope you don't. On a couple of occasions I've had fsck on our 6000 totally trash a file system. I'm still waiting for System V release 4 for the 6000. Geoff Coleman
drake@drake.almaden.ibm.com (06/05/91)
In article <1991Jun4.163505.29244@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >In article <11640@ncar.ucar.edu>, pack@acd.uucp (Daniel Packman) writes: >> >>I'd take the journaled file system over sys V or berekely any day. > >How about the day one of your disks crashes? Like, maybe the one >that's got pieces of /, /usr, /u, etc. on it, and instead of restoring >one drive's worth of stuff, you have to restore everything? Well, there are tradeoffs in everything. For many people, the idea that you can expand filesystems dynamically into any unused disk space on any drive is a Big Win. The potential downside, of course, is the situation that you've mentioned. If this is a real concern for you, it's easily fixed. Make each disk drive in your system a separate "volume group", instead of putting all volumes in the same volume group ("rootvg" is the default). A logical volume (read: "filesystem") resides in one and only one volume group. If all of your disk drives are in the same volume group, then as you mentioned each drive may wind up with a bit of each filesystem. If you make each disk drive a separate volume group, on the other hand, then you always know exactly what filesystems are on each drive. Naturally, this gives up much of the beneficial flexibility of the logical volume manager that was so nice in the first place ... but if this issue really concerns you then I'm sure you'll be happy to know that it need not be an issue. Sam Drake / IBM Almaden Research Center Internet: drake@ibm.com BITNET: DRAKE at ALMADEN Usenet: ...!uunet!ibmarc!drake Phone: (408) 927-1861
dcm@plato.austin.ibm.com (06/05/91)
In article <carl.676077327@probitas> carl@probitas.cs.utas.edu.au (Carl Lewis) writes: > >NUP , Sorry but it does. We were having trouble with lack of space in /tmp >, a few quick comparisons of df an du showed a missing 11 Mg ( a problem >when the partition is 12 Meg :-). A quick fsck showed all the missing blocks >marked as lost (?) . fsck WOULDN'T reclaim them, we had to destroy and >recreate the partition (thankfully not to much of a headache under jfs. Any clue at all to what caused this? If you can recreate this and give us something to work on, I'd love to work on a REAL jfs problem. I haven't seen one yet. So far all reported jfs problems (that I'm aware of) have been user errors. Root programs unlinking directories, things like this. I haven't seen an actual bug yet (oops, take that back. saw one about 5 months ago. however, it didn't cause blocks to be lost....) >But jfs can and does 'loose it'. We've had other problems in which jfs >is implicated but at the moment we can't quite pin it squarely through >jfs alone. We tracke out problem down to one program somehow confusing >hell out of jfs and so stopped using that program (screen dammit :-( :-( ). Could you look at that program, figure out what's breaking us, and submit it as a defect? I realize that's time consuming, but that's our only chance of fixing the problem... Thanks... > Carl : Programmer (etc) with University of Tasmania >Internet : carl@cs.utas.edu.au || C.S.Lewis@cs.utas.edu.au >Address || carl@probitas.cs.utas.edu.au Craig "don't blame me for fsck" Miller -- Craig Miller Internet: dcm@aixwiz.austin.ibm.com IBM Austin Vnet: tkg007 at ausvmq AIXV3 Change Team (level3) IBM internal: dcm@littleguy.austin.ibm.com "I do not represent IBM or any other respectable company."
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (06/05/91)
In article <8191@awdprime.UUCP> dls@dce.austin.ibm.com writes: >In article <11640@ncar.ucar.edu>, pack@acd.uucp (Daniel Packman) writes: >> Some of the differences in AIX seem perverse (eg, why not spell it f77 >> instead of xlf?) > >It's important to note that xlf is NOT f77; that's not a mere spelling >difference, the name change was justified. Gratuitous changes like this cause havoc for users, and for sysadmins trying to figure out how to make it work in a reasonable way, especially for packages that include (possibly nested) Makefiles. I assume by "f77" you mean the BSD f77 - most other vendors (HP/Apollo and SGI to quote systems we have here) call their compiler f77 even though it has no connection with BSD f77. Why do you allow your "xlc" C compiler to be called as "cc" - is it really related to the original "cc", or is it because compatability with the world is a good thing? -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) (06/06/91)
In article <1991Jun5.165004.26667@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >>> Some of the differences in AIX seem perverse (eg, why not spell it f77 >>> instead of xlf?) >Gratuitous changes like this cause havoc for users, and for sysadmins >trying to figure out how to make it work in a reasonable way [...] ln -s /usr/bin/xlf /usr/bin/f77 Marc [Disclaimer: I work for IBM too.] -- Marc Andreessen___________University of Illinois Materials Research Laboratory Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl
jsalter@ibmpa.awdpa.ibm.com (06/06/91)
In article <1991Jun5.165004.26667@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >In article <8191@awdprime.UUCP> dls@dce.austin.ibm.com writes: >>It's important to note that xlf is NOT f77; that's not a mere spelling >>difference, the name change was justified. >Gratuitous changes like this cause havoc for users, and for sysadmins >trying to figure out how to make it work in a reasonable way, especially >for packages that include (possibly nested) Makefiles. I assume by "f77" >you mean the BSD f77 - most other vendors (HP/Apollo and SGI to quote >systems we have here) call their compiler f77 even though it has >no connection with BSD f77. Why do you allow your "xlc" C compiler to be >called as "cc" - is it really related to the original "cc", or is it >because compatability with the world is a good thing? I don't understand. Just add a stanza in /etc/xlf.cfg, and make a link from /bin/f77 to /bin/xlf, and now you have a f77. If you want to get into the deeper aspects of why xlf isn't the 4.3 BSD f77, you'll have to fight it out with one of the compiler folks. Invocation Actual Command (/etc/xl[cfp].cfg) ---------- -------------------------------- cc == /usr/lpp/xlc/bin/xlcentry -D_IBMR2 -D_AIX -bhalt:4 -H512 -T512 -qlanglvl=extended -qnoro -lc xlf == /usr/lpp/xlf/bin/xlfentry .... (can't find the right machine..) pascal == /usr/lpp/xlp/bin/xlpentry .... >Mike Peterson, System Administrator, U/Toronto Department of Chemistry >E-mail: system@alchemy.chem.utoronto.ca jim/jsalter IBM PSP, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: jsalter@slo.awdpa.ibm.com UUCP: ..!uunet!ibmsupt!jsalter "IBM part #23521, aka Lt. Commander Data" The stuff above is on my own.
richd@prism.gatech.EDU (Richard Dellaripa) (06/07/91)
jsalter@ibmpa.awdpa.ibm.com writes: >I don't understand. Just add a stanza in /etc/xlf.cfg, and make a link >from /bin/f77 to /bin/xlf, and now you have a f77. If you want to get into >the deeper aspects of why xlf isn't the 4.3 BSD f77, you'll have to fight >it out with one of the compiler folks. If it's so easy to do (and I don't see why it wouldn't be), why didn't IBM do it themselves? This illustrates the major problem I personally have with AIX...its developers seemed to have often changed things from the de facto Un*x standards for no (percieved at least) real reason. I'd bet I could set up a rough configuration with any other Unix-based system that would work in my environment in an afternoon, without looking in the manuals. But with AIX, I'm forced to move two steps backwards, and relearn things. Richard C. Dellaripa -- GTRI/EOL Georgia Institute of Technology, Atlanta, Georgia, 30332 Internet: richd@prism.gatech.edu Phone: (404) 894-3357
resnick@cogsci.uiuc.edu (Pete Resnick) (06/07/91)
andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) writes: >In article <1991Jun5.165004.26667@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >>>> Some of the differences in AIX seem perverse (eg, why not spell it f77 >>>> instead of xlf?) >>Gratuitous changes like this cause havoc for users, and for sysadmins >>trying to figure out how to make it work in a reasonable way [...] >ln -s /usr/bin/xlf /usr/bin/f77 **FLAME ON** Another idiotic example of the infinitely wise attitude "We're IBM, we don't have to!" Aside from the sheer stupidity of using a symbolic link as opposed to a hard link, it totally ignores the issue of this being a "gratuitous" change from the standard way of doing things. The answer, "That's the way we made it. Live with it!" is a ridiculous answer from any vendor, even IBM. **FLAME OFF** Sorry, but I get tired of this sometimes. There are other nice people at IBM. I apologize for accidentally insulting any of them with this statement. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD
dls@achilleus.austin.ibm.com (David Skeen) (06/07/91)
In article <30757@hydra.gatech.EDU>, richd@prism.gatech.EDU (Richard Dellaripa) writes: > >I don't understand. Just add a stanza in /etc/xlf.cfg, and make a link ... > If it's so easy to do (and I don't see why it wouldn't be), why didn't > IBM do it themselves? In this case, however, xlf isn't an f77 port. If we "did it ourselves", and f77 programs didn't port, we would be screamed at for having a broken f77. As I see it, the problem with the present situation is the fact we don't have a true f77 (I hope we'll get one). I am not an official IBM spokesman. -- Dave Skeen IBM Internal: dls@achilleus.austin.ibm.com D61/803 Zip 2603 IBM VNET: SKEEN at AUSTIN Austin, TX 78758 Internet: dls@dce.austin.ibm.com
grover@skybridge.SCL.CWRU.Edu (Grover Davidson) (06/07/91)
I am not a n year veteran on the RS/6000 or unix in general, but i do have several years in systems admin on many other machines. It is my opinion that IBM has tried to do some things to make unix easier to administrate for both the more advanced admins as well as the new admins. How many admins out there would like to chuck the extendable JFS? What about modifying the system while users are on? I do, however, believe that IBM DOES SUFFER from the 'WE'RE IBM AND BECAUSE WE ARE, WE WILL MAKE THE STANDARDS'. I think that if they publish some sort of 'intro to AIX Admin for experienced Unix Admins' type manual. Change is what allows us to take advantage of new ideas in both hardware and software. What if people had the same attitudes about not changing when unix was first thought of? we wouldn't have unix or alot of other things. They have listened to us some. The changes at IBM Defect support do show that. The problem that I, and many other accounts in this area, is that there is only 1 SE for over 60 sites. As a result, we get NO SUPPORT. and IBM does not seem to care about it. Our SE doesn't even have any backups. This is probably not uncommon for IBM, but it sure does irritate me! We get better support and assistance from the net that we do from IBM. Am i supprised? NO! I have NEVER SEEN IBM PROVIDE HIGH QUALITY SUPPORT FROM IT'S OWN ORGANIZATION!! Remember, they will probably listen better if we tell them not only what they keep screwing up, but also what they do fix correctly. Don't you wish people took that attitude towards you as a sys admin? -- Grover Davidson (grover@ccai.clv.oh.us) | I speek ONLY for myself. My views do Conley, Canitano, & Assoc. Inc. | not in any way relect those of my 25201 Chagrin Blvd. Ste. 390 | employer, even if they like them and Beachwood, Oh 44122 | especially if they don't.
gs26@prism.gatech.EDU (Glenn R. Stone) (06/07/91)
Grover Davidson (grover@skybridge.SCL.CWRU.Edu) writes: >It is my opinion that IBM has tried to do some things to make unix >easier to administrate for both the more advanced admins as well as the >new admins. How many admins out there would like to chuck the extendable >JFS? What about modifying the system while users are on? This is, IMHO, a Good Thing.... >I do, however, believe that IBM DOES SUFFER from the 'WE'RE IBM AND BECAUSE >WE ARE, WE WILL MAKE THE STANDARDS'. I think that if they publish some sort >of 'intro to AIX Admin for experienced Unix Admins' type manual. It's in /usr/lpp/bos/bsdadm. >They have listened to us some. The changes at IBM Defect support do show that. Yeah. It's nice to call in a problem and get a fix Airborne Expressed to you the next morning.... Big Blue's problem tracking (at least for AIX), or, more accurately, their ability to figure out what's wrong and how to fix it, has been at worst better than passable.... a damn sight better than some vendors whose names I won't mention (but it's got three letters :-) >The problem that I, and many other accounts in this area, is that there is >only 1 SE for over 60 sites. As a result, we get NO SUPPORT. and IBM does >not seem to care about it. Our SE doesn't even have any backups. This is >probably not uncommon for IBM, but it sure does irritate me! This is getting better. We just got an SE dedicated to the thirty machines scattered about Tech campus, and she and the salescritters are working with Tech's computer center in an attempt to fix problems like updates getting lost in the shuffle, etc.... >We get better support and assistance from the net that we do from IBM. >Am i supprised? NO! I have NEVER SEEN IBM PROVIDE HIGH QUALITY SUPPORT >FROM IT'S OWN ORGANIZATION!! It's the nature of the net to be able to provide good assistance fast, period. Computers are like sex: it's a lot less fun when you do it for a living. Those who post to the net are doing it for fun, and they will just by nature do a lot better job than those who have to grind thru it 8 hours a day.... besides, it's a lot different when you've done it for real five times instead of calling some guru and relaying a message.... you KNOW how it's done. That and the fact that you have ten thousand people out there looking at your question instead of one frazzled SE.... the net will always and forever give you better support than ANY commercial enterprise. If you want net.support for your OS, get GNU. That's all I can tell you. >Remember, they will probably listen better if we tell them not only what >they keep screwing up, but also what they do fix correctly. Don't you wish >people took that attitude towards you as a sys admin? Yeah. And the attitude I've been hearing the last two weeks is that they're eager beavers, all we have to do is speak up. Next thing you know, IBM'll outlaw the necktie. Naaaaah. -- Glenn R. Stone gs26@prism.gatech.edu speaking for himself
jigang@geoblue.gcn.uoknor.edu (Jigang Yang) (06/07/91)
In article <30825@hydra.gatech.EDU>, gs26@prism.gatech.EDU (Glenn R. Stone) writes: |> Grover Davidson (grover@skybridge.SCL.CWRU.Edu) writes: |> ...... |> |> >They have listened to us some. The changes at IBM Defect support do show that. |> |> Yeah. It's nice to call in a problem and get a fix Airborne Expressed to |> you the next morning.... Big Blue's problem tracking (at least for AIX), |> or, more accurately, their ability to figure out what's wrong and how |> to fix it, has been at worst better than passable.... a damn sight better |> than some vendors whose names I won't mention (but it's got three letters :-) I agree. IBM is definitely better than some damn workstation vendors. Some vendor only records your problems, then several months later they ask you if you have sovled your problem! -- Jigang Yang | jigang@geoblue.gcn.uoknor.edu Geosciences Computing Network | jigang@gcn.uoknor.edu University of Oklahoma | 830 Van Vleet Oval,Gould Hall#116 | jigang@uokgcn.bitnet Norman, Oklahoma 73019 | Telphone: 405-325-5540
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (06/08/91)
In article <30757@hydra.gatech.EDU> richd@prism.gatech.EDU (Richard Dellaripa) writes: >jsalter@ibmpa.awdpa.ibm.com writes: > >>I don't understand. Just add a stanza in /etc/xlf.cfg, and make a link >>from /bin/f77 to /bin/xlf, and now you have a f77. If you want to get into >>the deeper aspects of why xlf isn't the 4.3 BSD f77, you'll have to fight >>it out with one of the compiler folks. > >If it's so easy to do (and I don't see why it wouldn't be), why didn't >IBM do it themselves? This illustrates the major problem I personally >have with AIX...its developers seemed to have often changed things from >the de facto Un*x standards for no (percieved at least) real reason. This is of course exactly what we did, ONCE WE FIGURED OUT WHAT HAD TO BE DONE. I agree 100% with Richard Dellaripa's comments. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
johnson@aixwiz.austin.ibm.com (Fred L. Johnson) (06/08/91)
> Next thing you know, IBM'll outlaw the necktie. > > Naaaaah. > IBM may not outlaw the necktie, but I see a lot more blue jeans than neckties worn by us AIX developers (management, however, is a different story!). - Fred My remarks and opinions are mine alone... ____________________________________________________________________________ | | | | Fred L. Johnson | Internet: johnson@aixwiz.austin.ibm.com | | IBM Personal Systems Programming | inet: johnson@tanstaafl.austin.ibm.com | | AIX BOS Field Quality | vnet: FJOHNSON at AUSVMQ | | 11400 Burnet Road, 994/3401 | phone: (512) 823-4706 | | Austin, TX 78758-3493 | tie line: 793-4706 | |__________________________________|_________________________________________|
karish@mindcraft.com (Chuck Karish) (06/08/91)
In article <1991Jun7.173343.21209@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >In article <30757@hydra.gatech.EDU> richd@prism.gatech.EDU >(Richard Dellaripa) writes: >>jsalter@ibmpa.awdpa.ibm.com writes: >>>I don't understand. Just add a stanza in /etc/xlf.cfg, and make a link >>>from /bin/f77 to /bin/xlf, and now you have a f77. If you want to get into >>>the deeper aspects of why xlf isn't the 4.3 BSD f77, you'll have to fight >>>it out with one of the compiler folks. >> >>If it's so easy to do (and I don't see why it wouldn't be), why didn't >>IBM do it themselves? Because xlf is NOT f77. It is a completely different compiler. The BSD documentation describing f77 does not apply to xlf. The BSD manuals describing their FORTRAN support libraries do not apply to xlf. This is called `truth in labeling'. >>This illustrates the major problem I personally >>have with AIX...its developers seemed to have often changed things from >>the de facto Un*x standards for no (percieved at least) real reason. For that matter, BSD is not the only UNIX environment. Its universality as a de facto standard is much less profound than many of the whining BSD chauvinists we hear here would have us believe. That said, IBM has their own share of NIH syndrome. AIXv3 is more compatible than AIXr2 (RT aix) was, thanks at least in part to a lot of agitation from BSD beleivers in the development team. >This is of course exactly what we did, ONCE WE FIGURED OUT WHAT HAD TO >BE DONE. I agree 100% with Richard Dellaripa's comments. What has to be done is to put the proper conditionals at the beginnings of your makefiles. Then your programs will be easier to compile on non-UNIX systems, too. -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
madd@world.std.com (jim frost) (06/08/91)
gs26@prism.gatech.EDU (Glenn R. Stone) writes: >In <1991Jun4.163505.29244@cs.utk.edu> de5@ornl.gov (Dave Sill) writes: >>In article <11640@ncar.ucar.edu>, pack@acd.uucp (Daniel Packman) writes: >>>I'd take the journaled file system over sys V or berekely any day. >>How about the day one of your disks crashes? >only once have I _ever_ heard a squeaky out of fsck.... >it just doesn't lose stuff. JFS vs UFS: JFS wins hands down. JFS vs FFS: JFS is more reliable, but FFS is faster. The only problem I have with JFS is that it does not deal with fragmentation at all. Given the amount of research that went into filesystems that avoid or eliminate fragmentation, such as FFS or SGI Extents, I was shocked at this deficiency. Rumor has it (rumor from an IBM representative) that IBM is working on it, but it's a glaring problem which IBM has no immediate answer to. As for reliability, I've never lost anything on a JFS partition. Not even stuff that was active when the machine was down. JFS partitions are reliable, no question about it. I'd love to see that kind of reliability on other UNIX machines. jim
frank@leopard.austin.ibm.com (06/09/91)
I> > Next thing you know, IBM'll outlaw the necktie. > > Naaaaah. > Well, I haven't worn a tie after my first day! I know developers who wear T-shirts during the week (wow imagine that!). I'm here (on a Saturday) wearing shorts, a sleaveless T-shirt and I have my bike in the lab. - Frank Feuerbacher Disclaimer: I speak only for me! And I don't even do a good job of that!
shair@ux1.cso.uiuc.edu (Bob Shair) (06/09/91)
karish@mindcraft.com (Chuck Karish) writes: >Because xlf is NOT f77. It is a completely different compiler. >The BSD documentation describing f77 does not apply to xlf. The >BSD manuals describing their FORTRAN support libraries do not apply >to xlf. This is called `truth in labeling'. My recommended solution is to add the following statement as as /usr/bin/f77. echo "On this system the FORTRAN compiler is named 'xlf'." -- Bob Shair shair@chgvmic1.vnet.ibm.com Scientific Computing Specialist SHAIR@UIUCVMD (bitnet) IBM Champaign
jfh@rpp386.cactus.org (John F Haugh II) (06/10/91)
In article <8302@awdprime.UUCP> johnson@aixwiz.austin.ibm.com (Fred L. Johnson) writes: >IBM may not outlaw the necktie, but I see a lot more blue jeans than >neckties worn by us AIX developers (management, however, is a different >story!). There was a poster running around the Austin site showing a pair of blue jeans laid out horizontally with the heading "Austin's New Blue Suit". Over in PS/2 land the management wears "casual" clothes on Fridays. It really isn't that bad of an environment - most of the tales of suits and ties are grossly exagerated. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
jet@karazm.math.uh.edu (J Eric Townsend) (06/10/91)
In article <30825@hydra.gatech.EDU> gs26@prism.gatech.EDU (Glenn R. Stone) writes: >Tech's computer center in an attempt to fix problems like updates getting >lost in the shuffle, etc.... Anecdote: For 4 months or so, we never got any of the stuff we were supposed to get (software updates, etc). Then one day, a level n>2 person verified my address. My address is: University of Houston -- Deptartment of Mathematics PGH 651 4800 Calhoun Houston, Tx 77204. They had: UH 568 4800 Calhoun Houston, tx 77004 Hm. You tell me. After a *week*, they finally got the address right. They mangled the correct address into something from hell. Now they've got it right. Anyone wanna bet how long it is before it gets mangled again? >Next thing you know, IBM'll outlaw the necktie. "It could happen!" -- Judy Tenuta -- J. Eric Townsend - jet@uh.edu - bitnet: jet@UHOU - vox: (713) 749-2126 Skate UNIX! (curb fault: skater dumped) -- If you're hacking PowerGloves and Amigas, drop me a line. --
jona@iscp.Bellcore.COM (Jon Alperin) (06/10/91)
In article <8321@awdprime.UUCP>, frank@leopard.austin.ibm.com writes: |> I> |> > Next thing you know, IBM'll outlaw the necktie. |> > |> > Naaaaah. |> > |> |> Well, I haven't worn a tie after my first day! I know developers who |> wear T-shirts during the week (wow imagine that!). I'm here (on a |> Saturday) wearing shorts, a sleaveless T-shirt and I have my bike in the lab. |> |> |> - Frank Feuerbacher |> |> |> Disclaimer: I speak only for me! And I don't even do a good job of that! Yeah, but we all know that technical people (the ones doing all the work) never wear ties. I want to see my IBM CE/SE/Sales Dude in jeans and a Tee next time they are sitting in my computer lab trying to get something working. It would give me a whole new level of confidence. :-} -- Jon Alperin Bell Communications Research ---> Internet: jona@iscp.bellcore.com ---> Voicenet: (908) 699-8674 ---> UUNET: uunet!bcr!jona * All opinions and stupid questions are my own *
gs26@prism.gatech.EDU (Glenn R. Stone) (06/11/91)
I wrote: >> Next thing you know, IBM'll outlaw the necktie. >> >> Naaaaah. >> To avoid further flames: I know damn good and well you Austin types don't wear ties; my quip was directed at the REST of Big Blue.... my salescritters and service people still wear the things. The Austin project was probably the best thing that ever happened to IBM.... I'd like to see more where that came from. Thus the remark -- if the upper-level people would loosen up, they might come up with something Really Spectacular.... not that the '6000 isn't pretty impressive in its own right, for what we want them for..... Glenn R. Stone (gs26@prism.gatech.edu), working for but not representing Atmospheric Sciences, Georgia Tech, Atlanta, 30332-0340 home of 5 Risc System 6000's and one little vax.
pack@acd.uucp (Daniel Packman) (06/11/91)
drake@ibm.com writes: > >... >Well, there are tradeoffs in everything. For many people, the idea that >you can expand filesystems dynamically into any unused disk space on any >drive is a Big Win... > > The ability to expand into unused space is not as useful as it could be if you cannot easily *shrink* filesystems as well. Few of us have the luxury of having lots of unused disk space waiting around just for the flexability of exanding a filesystem. I understand this ability to shrink filesystems will be in a future AIX release. Dan Packman NCAR INTERNET: pack@ncar.UCAR.EDU (303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET Boulder, CO 80307-3000 DECNET SPAN: 9583::PACK
moody@snap.austin.ibm.com (06/12/91)
In article <11779@ncar.ucar.edu> pack@acd.uucp (Daniel Packman) writes: >The ability to expand into unused space is not as useful as it could be >if you cannot easily *shrink* filesystems as well. Few of us have the >luxury of having lots of unused disk space waiting around just for the >flexability of exanding a filesystem. I understand this ability to >shrink filesystems will be in a future AIX release. Where did you get this information? I don't believe it's true. > >Dan Packman NCAR INTERNET: pack@ncar.UCAR.EDU >(303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET > Boulder, CO 80307-3000 DECNET SPAN: 9583::PACK Opinions expressed are my own. -- James Moody aixnet:moody@moody.austin.ibm.com Personal Systems Programming Austin VNET:MOODY@AUSVMQ AIX Field Support - Level 3 internet:moody@aixwiz.austin.ibm.com
oasis@gary.watson.ibm.com (GA.Hoffman) (06/12/91)
ah ,, I know what blue jeans are .. but what's a necktie? -- gary a hoffman RISC Systems, Watson Research
shair@ux1.cso.uiuc.edu (Bob Shair) (06/12/91)
moody@snap.austin.ibm.com writes: >In article <11779@ncar.ucar.edu> pack@acd.uucp (Daniel Packman) writes: >>The ability to expand into unused space is not as useful as it could be >>if you cannot easily *shrink* filesystems as well. Few of us have the >>luxury of having lots of unused disk space waiting around just for the >>flexability of exanding a filesystem. I understand this ability to >>shrink filesystems will be in a future AIX release. >Where did you get this information? I don't believe it's true. Almost certainly, that information was gotten from his IBM representative. It is not, however, stated in the correct IBM terminology. This is not surprising... learning to talk IBM can take MANY years of practice. As one who's been speaking IBM since 1963, and hearing about our intentions to shrink AIX V3 file systems since March '89, let me see if I can use the right terms. IBM "intends" to offer the ability to shrink filesystems at some point in the future on AIX V3. I believe that's a correct statement... please take my disclaimer that I'm not authorized to represent IBM on this seriously. This is not at all (in IBM) the same as saying that IBM "plans" to offer the ability to shrink filesystems in a future release. In IBM, that would mean that an internal commitment had been made for a specific release, at a specific time. This is what Mr. Moody is denying. Sorry for the long lesson on how to understand IBM... in our next lesson, class, we'll discuss "what is a DASD?" :-) -- Bob Shair shair@chgvmic1.vnet.ibm.com Scientific Computing Specialist SHAIR@UIUCVMD (bitnet) IBM Champaign
jay@banzai.PCC.COM (Jay Schuster) (06/13/91)
grover@skybridge.SCL.CWRU.Edu (Grover Davidson) writes: >We get better support and assistance from the net that we do from IBM. >Am i supprised? NO! I have NEVER SEEN IBM PROVIDE HIGH QUALITY SUPPORT >FROM IT'S OWN ORGANIZATION!! We have clients with PS/2's running AIX and RS/6000's running AIX. The PS/2 AIX is a piece of shit. No ifs ands or buts. IBM support wasn't able to help us to get terminals or modems working. And then, of course, there's the AIX updates on the PS/2. Run through 35 disks ten times. At least we don't need to buy 3.5" floppies anymore. IBM just gives them to us. I just wanted to recount what happened the other day. One of our clients had a problem with their hard drive -- it wouldn't boot into multi user mode. fsck was coming up with an error on the /local filesystem. Two IBM techs were there, twiddling their thumbs, while we resolved the situation. Some directory was a Small Block File that was too big. After finding out that it was the /local/locks directory (/usr/spool/locks is a symbolic link to this directory), we just did a clri and fsck did the right thing. I did this knowing only the standard UFS, not the filesystem the PS/2 uses, and with the help of the fsdb, fsck, ncheck, and clri man pages. And the two IBM techs just sat there, twiddling their thumbs. I mean, what did they send them out there for anyway? -- Jay Schuster <jay@pcc.COM> uunet!uvm-gen!banzai!jay, attmail!banzai!jay The People's Computer Company `Revolutionary Programming'