"jochen%[131.220.221.30]"@olymp.informatik.uni-bonn.de (05/31/91)
Dear UNIX world,
I would like to offer the following to your discussion since I think
that some of you will be in the same situation as we are. Up to the
end of 1989 all of the (important - those who MAKE the opionions)
computer people in our institute (physics institute of the university
of bonn, germany) think that VMS is THE operating systems for all
users. As far as I saw it - the view of a programmer - VMS has
some very handy tools for me (command definition language, message
utility, logical names, batch system,...) but was somewhat strange
when programming in C (system call interface, string descriptors ...).
Since we need more computer power for the analysis of our experiments
data (at the level of 100 VAX 11/750 units) we had to check for some
cheeper solutions and came to RISC machines with UNIX (we bought two
AViiON 300 with 17 MHZ 88100 from Data General). Now we had to learn
UNIX and my summary of UNIX (from my point of view) was that
programming with system and library calls is more clear to me
(VAX does provide UNIX C libraries, too but only TOO) and more
easy to learn, using the command interpreter is much more elegant
than VMS (thinking of pipes or non-command-file loops with
foreach) but commands are somewhat cryptic and hard to learn for
many people (try to make a DIRECTORY/SINCE=YESTERDAY using find).
You can do MANY things with UNIX in commands but you have to learn
MANY things before you can do so. And people which have been worked
with VMS some time like the VMS feeling. If you are not doing very
special things VMS is GOOD (enough) for developing programs (better
than UNIX? I don't know).
We want to use our machines as batch only machines in the following
way: users should program and test their programs using VMS (using
the better tools) and then run the processing jobs (analysing some
Gigabytes of event data) on the UNIX machines. These machines got
the task to balance the load on all machines involved. So we decided
to port the following tools to UNIX:
* users should take advantage of what the learn in VMS. So DCL
command files and CLD utility should be useable in the batch
jobs. CLD, CDU and DCL will be needed for that.
* job starts should be similiar to VMS. So a job controller similiar
(not more) to VMS (SUBMIT, SHOW QUEUE, etc.) has been constructed
to server a couple of machines using load balancing.
* logical names can be very helpfull (especially if you use DCL
command files).
* if you have one file/tape and will have some machines analyzing
the data from it, you need a mechanism to split the datastream
as a multiplexor does. This can be done with TCP/IP in a very
simple way. But if you have your program written in FORTRAN
(we use some CERN libraries in good old FORTRAN 77) you get
problems with OPEN. So we need a tool mapping TCP channels
to file names.
In this text I will shortly show the components of our VMS support
for UNIX (perhaps there will be VMS on UNIX in future BUT I will
not program using VMS. I will only take advantage of some VMS tools.
You know the sampler: the best of ...?). Perhaps some of you is
interested in using it for some reason and will have the time and
is willing to work on this. Up to know it is running under DG/UX
4.32 in our special environment and since UNIX is not UNIX and
DG/UX is not UNIX (System V.3 and BSD compatibily and some special
tricks) there may be some work on it. We will not make some further
enhancements of those things because we do not have the time to do
do. But since the project has some interesting features (as I think...)
I would like to offer it to you (as first to those able to port it
to their local UNIX system). If some of you are interested in getting
the source please contact me. If some of you are interested in
discussing VMS on/for UNIX I would prefer to see thos discussion
in the UNIX digests (I'm not receiving mails from the i-unix directly)
since I think they are of common interest.
Now to the feature in short. If you are not using VMS and do not
know about some library routines and their usage (LIB$GET_INPUT
or so) you should skip this.
1. PARSE
Implementation of LIB$TPARSE (final state machine using predefined
tokens for hex, symbols, ...). Interface to C, tables can be
stored outside the program in files. Support for call of other
tables (modules).
** Ported to AmigaDOS, VMS 5.4 and DG/UX 4.32
2. Command language definition CLD and CDU
Most features of CLD, library routines LIB$DCL_PARSE. Uses 1.
Allows image activation to be used in own programs.
** Ported to DG/UX 4.32 and partial to AmigaDOS
** Not ported to VMS since the original is still better.
3. Logical names
Logical name manager using RPC. Full support of name tables and
name hierarchie. System routines SYS$TRNLNM etc. provided.
4. VMS tools and VMS related tools
Translate a VMS filename to UNIX using logical names, LIB$GET_INPUT,
LIB$GET_FOREIGN and the things usefull for workig with commandlines.
5. DCL command shell
Uses CLD. Implements - beside normal commands as SHOW LOGICAL,
FORTRAN, etc. - symbols, foreign commands and command procedures.
Symbol replacement similiar to VMS (VMS has MANY undocumented
features...), library support for symbols LIB$SET_SYMBOL etc.
DCL called images may be coded in a command language (I use csh)
which can do CLI$GET_VALUE and CLI$PRESENT. This makes execution
slower but support very easy.
6. TCP mapper
A STREAMS pseudo device which maps filenames to TCP/IP channels
after a preconfiguration step.
7. Batch queue system
First version of load balancing (easy). Support for processing
loosely coupled (processing time per "event" in the order of one
second) parallel jobs. You can set up a multiplexed job connected
to one tape unit. The system will start the job multiple time as
long as resources allow it to do so. The programs in this
environment can be coded using logical names so that the run
without any change under VMS, non-parallel queue and in the
parallel environment.
All Programs are - as VMS does - interfaced for FORTRAN. This may be
a problem in porting since FORTRAN C interface in UNIX is not well
defined and usage of CHARACTER variables is somewhat strange (see
VMS descriptors). We use Green Hills FORTRAN 77 which is very
compatible to VMS and easy to connect to C. One more problem will
be the documentation (documen.. WHAT?). The implementation of the
project is level one, i.e. level zero has been tested an improved
and I do not expect to have some major changes the next time (one
year or so).
If you want more information please contact me. This letter shall
only give a hint to those people you think they need such tools on
their UNIX systems. Perhaps we can make a PD set out of it?
I'm hoping on some response!
Jochen
PS: If you can't REPLY to this mail, sent it to MANNS@DBNPIB5.BITNET. Our
UNIX systems are not yet name served.mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/02/91)
In article <27075@adm.brl.mil>, "jochen%[131.220.221.30]"@olymp.informatik.uni-bonn.de writes: > [We used to be all-VMS] [UNIX is different] > (try to make a DIRECTORY/SINCE=YESTERDAY using find). I'm not sure find is the right tool; ls -l | grep might be better. But you can come close with find -mtime -1, though that's not quite the same; that's DIR/SINCE=<24-hours-ago>. > You can do MANY things with UNIX in commands but you have to learn > MANY things before you can do so. And people which have been worked > with VMS some time like the VMS feeling. If you are not doing very > special things VMS is GOOD (enough) for developing programs (better > than UNIX? I don't know). Yes; VMS is a reasonably good system. So is UNIX, only for different things. Both have camps of fanatically religious adherents. My perception of the difference is that VMS is better at what it does but is less flexible. If you want to do something that they have thought to support, you will find it fairly easy. If you want to do something they *didn't* think to support, it will range from difficult to impossible. UNIX has less built-in support but more potential for those who want to do their own thing. > Now to the feature in short. > 1. PARSE > Implementation of LIB$TPARSE (final state machine using predefined > tokens for hex, symbols, ...). Interface to C, tables can be > stored outside the program in files. Support for call of other > tables (modules). Interesting. I also wrote something similar to LIB$TPARSE for UNIX. Mine is a program that takes the state machine definition as input and produces a .c file as output, which sounds rather different from yours. > [...] You have obviously done quite a lot of work. I am most impressed. Do you intend to make the result available when you've got something stable? I imagine there are quite a lot of people out there who would love to get hold of it. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
Dan_Jacobson@ATT.COM (06/02/91)
>>>>> On 31 May 91 12:58:32 GMT, >>>>> "jochen%[131.220.221.30]"@olymp.informatik.uni-bonn.de said: jochen> Perhaps we can make a PD set out of it? As far as migrating VMS-->UNIX, some VMS-like public domain like tools for UNIX would be jochen> 4. VMS tools and VMS related tools GNU Emacs editor (which also runs on VMS) has EDT editor emulation built in. It lives on prep.ai.mit.edu. Here's an additional shred for emacs: tpu 88-11-01 Jeffrey Kowalski, <kowalski@svax.cs.cornell.edu> tut.cis.ohio-state.edu:pub/gnu/emacs/elisp-archive/packages/tpu.el.Z EDT/TPU Emulator jochen> 5. DCL command shell I believe the BASH shell lets you use the arrow keys just like DCL. See newsgroup gnu.bash.bug. Also, to emulate the VMS DISCONNECT command, try "screen" by Oliver Laumann (ftp prep.ai.mit.edu:pub/gnu/screen-2.1.tar.Z (works on Berkeley style UNIXes)). Allows up to 10 character based windows, and you can logoff, go home, log back in, and get your windows back, etc.