ciotti@wilbur.nas.nasa.gov (Robert B. Ciotti) (09/21/89)
If you had your wish, what would you add to UNICOS 5.0 or what in your opinion is missing? Bob
spl@mcnc.org (Steve Lamont) (09/22/89)
In article <3199@amelia.nas.nasa.gov> ciotti@orville.nas.nasa.gov (Robert B. Ciotti) writes: >If you had your wish, what would you add to UNICOS 5.0 >or what in your opinion is missing? > Shared memory between processes? spl (the p stands for processors... just throw more processors at the problem) -- Steve Lamont, sciViGuy EMail: spl@ncsc.org NCSC, Box 12732, Research Triangle Park, NC 27709 "Surrealism only comes later when it seems 'reality' becomes difficult to achieve." - E. Miya, NASA Ames Research Center
bernhold@qtp.ufl.edu (David E. Bernholdt) (09/22/89)
In article <3199@amelia.nas.nasa.gov> ciotti@orville.nas.nasa.gov (Robert B. Ciotti) writes: >If you had your wish, what would you add to UNICOS 5.0 >or what in your opinion is missing? I definitely miss ranlib. I guess this is because UniCOS is SysV based and just about everything else I run on is BSD based. Considering what it does, I could probably write one on my own. There are a few other BSDisms which I find convenient, but nothing I can't live without. Version 5 combined with the most recent compiler releases is definitely better than many of its predecessors in providing compilers, loaders, etc. which work in "the unix way" and don't require too much modification of my makefiles, etc. The Ohio Supercomputer Center has a command called iostat (or something like that) which provided statistics on I/O much in the same way hpm provides information about CPU and memory. I think this would be useful as a permenant addition. On the whole, however, I'd like other vendors to take a look at some of the things Cray *does* provide -- particularly their mathematical libraries and performance monitoring. Its quite useful, and since I don't run solely on Crays, I'd like to have these tools to help improve my code on other platforms. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
jerry@violet.berkeley.edu ( Jerry Berkman ) (09/22/89)
In article <681@orange19.qtp.ufl.edu> bernhold@orange19 (David E. Bernholdt) writes: >In article <3199@amelia.nas.nasa.gov> ciotti@orville.nas.nasa.gov (Robert B. Ciotti) writes: >>If you had your wish, what would you add to UNICOS 5.0 >>or what in your opinion is missing? > >I definitely miss ranlib. I guess this is because UniCOS is SysV >based and just about everything else I run on is BSD based. >Considering what it does, I could probably write one on my own. Why? "bld" seems to provide all the functionality of "ranlib". In addition, each time you move a "ranlib" library, you have to re-"ranlib" it; but you can move "bld" libraries. - Jerry Berkman, U.C.Berkeley
sklower@ernie.Berkeley.EDU (Keith Sklower) (09/22/89)
In article <1989Sep22.002411.6208@agate.berkeley.edu> jerry@violet.berkeley.edu ( Jerry Berkman ) writes: >In addition, each time you move a "ranlib" library, you have to >re-"ranlib" it; but you can move "bld" libraries. > - Jerry Berkman, U.C.Berkeley 1.) If you ``cp -p'' a ranlib'd library you do not need to re-ranlib 2.) If you ``mv'' a ranlib'd library within the same file system ditto. 3.) The check in ``ld'' (that the creation date of the archive is the same as the creation date of SYMDEF) is only a warning and not a fatal error in of itself. 4.) Mr. Berkman is not one of the originators of Berkeley unix -- (He didn't claim that he was, I'm not claiming to be either, and he must know a heck of a lot more about crays than I do), but I would like it understood that his article endorsing ``bld'' is in no way an offical BSD position. I agree that this is very small part of a very large picture.
malcolm@Apple.COM (Malcolm Slaney) (09/22/89)
In article <3199@amelia.nas.nasa.gov> ciotti@orville.nas.nasa.gov writes: >If you had your wish, what would you add to UNICOS 5.0 >or what in your opinion is missing? How about symbolic links? I'm maintaining sources on half a dozen different kinds of machines (from Mac to Cray) and it would be nice if I could keep sources in one directory with symbolics links to keep things tidy. Or a TTY driver that understood things like Control-W and Control-Z. We won't even start on my problems with cdbx. But things are getting better. I can put up an xterm from the Cray directly to the Mac on my desk. Malcolm
bernhold@qtp.ufl.edu (David E. Bernholdt) (09/22/89)
In article <1989Sep22.002411.6208@agate.berkeley.edu> jerry@violet.berkeley.edu ( Jerry Berkman ) writes: >"bld" seems to provide all the functionality of "ranlib". Well okay, but I can put that in my makefiles about as easily as I can replace ranlib with `lorder | tsort`. The point is that I have 60 makefiles for numerous programs and I don't want to have to modify them all. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (09/22/89)
In article <5425@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes: * In article <3199@amelia.nas.nasa.gov> ciotti@orville.nas.nasa.gov (Robert B. Ciotti) writes: * >If you had your wish, what would you add to UNICOS 5.0 * >or what in your opinion is missing? * * Shared memory between processes? Well, now, how about 15MW/s (15,000,000 Words (64 bits) per second) memory- to-memory transfer? ...up to 16*1024*1024 Words per block/transaction/call? ...any-to-any CPU-to-CPU in an 8-CPU cluster? ...all 4 pairs full speed concurrently? --- Would you like us to build one for you, too? -------------- regardz, Ken
heiser@iis.UUCP (Gernot Heiser) (09/23/89)
In article <3199@amelia.nas.nasa.gov> ciotti@orville.nas.nasa.gov (Robert B. Ciotti) writes: >If you had your wish, what would you add to UNICOS 5.0 >or what in your opinion is missing? Job control (in csh) and symbolic links!!!!!! -- Gernot Heiser Phone: +41 1/256 23 48 Integrated Systems Laboratory CSNET/ARPA: heiser%iis.ethz.ch@relay.cs.net ETH Zuerich UUCP (new): heiser@iis.uucp CH-8092 Zuerich, Switzerland UUCP (old): {uunet,mcvax,...}!iis!heiser
morreale@bierstadt.ucar.edu (Peter Morreale) (09/23/89)
In article <3199@amelia.nas.nasa.gov> ciotti@orville.nas.nasa.gov (Robert B. Ciotti) writes: >If you had your wish, what would you add to UNICOS 5.0 >or what in your opinion is missing? > > >Bob A decent Fortran/shell interface. The problem with the supplied interface (ishell) is that it reproduces the parents memory image. Users at this site (COS) are heavily dependent on Fortran-callable JCL for re-start capability. Rolling out a 5+MW job to do an " IERR=ISHELL('assign <args> ')" is an unacceptable solution. (Fortran-callable JCL also allowed access to our Mass Storage System through local extensions) Currently I am diving deep into the bowels ;-) of UNICOS to create a socket for such a purpose. Good learning experience, but I'm surprised that some type of solution wasn't part of the plan from CRI. I understand that BSD's "vfork" solves this problem, as opposed to "fork" (which ISHELL uses). -PWM ----------------- Peter W. Morreale Nat'l Center for Atmos. Research, Scientific Computing Division morreale@ncar.ucar.edu (303) 497-1293
ok@cs.mu.oz.au (Richard O'Keefe) (09/23/89)
In article <4438@ncar.ucar.edu>, morreale@bierstadt.ucar.edu (Peter Morreale) writes: > Users at this site (COS) are heavily dependent on Fortran-callable > JCL for re-start capability. Rolling out a 5+MW job to do an > " IERR=ISHELL('assign <args> ')" is an unacceptable solution. > (Fortran-callable JCL also allowed access to our Mass Storage > System through local extensions) I don't know if this works for UNICOS, but I had occasion to use a '*NIX' where large (128kb!) processes couldn't fork at all. On that machine, the fix was to write a wrapper program and a new "shell" function. The wrapper program is a _small_ program which creates a temporary file, and then forks a child to do the real job. The name of the temp file is passed to the child in the environment array. The wrapper then goes to sleep waiting for a signal or the death of the child. When the child dies the wrapper deletes the temporary file and exits with the child's status. The new "shell" function writes the command to the temporary file, and signals the wrapper. It then goes to sleep waiting for a signal. The wrapper receives the signal, and forks again to execute the command. (Remember, it's a small program.) It waits for the command to finish, then it signals the child and goes back to sleep. The child receives the wrapper's signal and returns from "shell".
rchrd@well.UUCP (Richard Friedman) (09/24/89)
Concerning bld, my understanding is that this product was supplied
in UNICOS to provide something similar to 'build' on the previous
CRAY COS system. I agree with Jerry, that ranlib is certainly not
a significant feature to worry about.
In fact, there are a number of features of UNICOS that should be
made available on standard BSD UNIX on smaller machines.
One annoying thing I have found on std unix is that the loader won't
let you create an object binary if there are outstanding unsatisfied
externals. There are times when this is perfectly ok (the code contains
references to library routines that you do not have, and you know that
the running program willnever call them in anycase). The loader on the
SUN for example wont let you create a runnable program with these
missing routines. SEGLDR on UNICOS will do the proper thing, which is
to cause calls to unsatified externals to abort the running program.
I was recently at Cray/Mendota installing software on the Cray2 on 5.0
The only problem I ran into is the debugger, cdbx, which has some problems,
altho they are being fixed. The amazing thing was that I was able to install
a software product that normally runs using X-windows on SUNs and Apollos
on the Cray2 communicating with a SUN over hyperchannel with XTERM with
minimal hassle! (Code represents over 100K lines of C). Very impressive!!
--
/s/ rchrd <=> Richard Friedman <=> rchrd@well
rchrd@well.sf.ca.us | {apple,pacbell,hplabs,ucbvax}!well!rchrd
[Pacific-Sierra Research / Berkeley CA] (415) 540-5216
(The usual disclaimers apply - I speak only for myself!)jerry@violet.berkeley.edu ( Jerry Berkman ) (09/26/89)
In article <683@orange19.qtp.ufl.edu> bernhold@orange19 (David E. Bernholdt) writes: >In article <1989Sep22.002411.6208@agate.berkeley.edu> jerry@violet.berkeley.edu ( Jerry Berkman ) writes: >>"bld" seems to provide all the functionality of "ranlib". > >Well okay, but I can put that in my makefiles about as easily as I can >replace ranlib with `lorder | tsort`. The point is that I have 60 >makefiles for numerous programs and I don't want to have to modify >them all. > I sympathize, but I don't think adopting "ranlib" as the standard way to make libraries is a good idea. I believe in portability and generally would like utilities to be universally available with the same options on all systems. However, I have always regarded "ranlib" as a kludge, not a well designed library maintenance utility, so I am glad that Cray has written "bld" to try to have a good library maintenance utility in UNICOS. My perspective is as a maintainer of large Fortran libraries, e.g. IMSL and NAG, each which contains up to 2000 subprograms. First of all, bld is a single maintenance utility; ranlib requires ar and usually both must be used in any maintenance activity. This is both a nuisance and, for large libraries, a waste of time. Second, bld allows specification of files or subprogram units; ar/ranlib only know of files. Third, bld libraries do not rely on a time stamp kludge which is easily confused. If you simply use "cp" to copy a ranlib file, it is treated as if it is not a library. In another reply, Keith Sklower notes: >3.) The check in ``ld'' (that the creation date of the archive is the > same as the creation date of SYMDEF) is only a warning > and not a fatal error in of itself. However if the entries in the archive are not properly ordered, then the load fails. For example, assume "hello.c" contains: main() { printf("hello, world\n"); } Then: cc -c hello.c ld -X /lib/crt0.o hello.o -lc correctly load a modules which will print "hello, world", but: cc -c hello.o cp /lib/libc.a libc_copy.a ld -X /lib/crt0.o hello.o libc_copy.a fails with undefined externals. If the files are ordered so that the copy can still be used as a library, the load will work, but be very slow. And I just don't like the time-stamp usage. It can be tricked, e.g., consider the following commands which are slightly out of order: % /bin/rm -f lib.a % ar rv lib.a sub1.o sub2.o % ranlib lib.a % ar rv lib.a newsub.o % f77 callnew.f lib.a If executed, quickly, i.e. sourced from a file, the loader thinks lib.a is up-to-date even though it is not, and the load of junk.f loads uses the out-of-date table of contents and fails. Worse things could happen if you are replacing a object file. - Jerry Berkman ( usually disclaimers apply: I speak only for myself, not for UC, CCS, CSRG, or anyone else )
dworkin@Solbourne.COM (Dieter Muller) (10/03/89)
In article <683@orange19.qtp.ufl.edu> bernhold@orange19 (David E. Bernholdt) writes: >Well okay, but I can put [bld] in my makefiles about as easily as I can >replace ranlib with `lorder | tsort`. The point is that I have 60 >makefiles for numerous programs and I don't want to have to modify >them all. So cheat. Pick some convenient directory that you (hey, why not everyone else while you're at it) have in your path and are allowed to add things to. Install the equivalent two-line shell script and name the result ``ranlib''. No makefiles need be modified. Or am I missing something incredibly obvious again? Dworkin -- ...for the blood is the life, and the life is but a nightmare become real. boulder!stan!dworkin dworkin%stan@boulder.colorado.edu dworkin@solbourne.com Flamer's Hotline: (303) 678-4624 (1000 - 1800 Mountain Time)
bernhold@qtp.ufl.edu (David E. Bernholdt) (10/04/89)
In article <2569@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes: >So cheat. Pick some convenient directory that you (hey, why not everyone >else while you're at it) have in your path and are allowed to add things >to. Install the equivalent two-line shell script and name the result >``ranlib''. Sure, this is what I did eventually. To make a robust work-a-like for BSD's ranlib is about 50 lines. But I would have much rather spent the time on other things. Writing a good script is time-consuming. If anybody wants it, I'll mail or post it. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365