VMS on/under/istead of/and UNIX

Fri May 31 22:58:32 AEST 1991

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 at DBNPIB5.BITNET. Our
    UNIX systems are not yet name served.