Detail Equipment User Society presents this recording from the 1990 Fall Symposium, December 10th through 14th, in Las Vegas, Nevada.
The following is for informational purposes only and is subject to change without notice.
Neither DECUS nor its authors assume any responsibilities for the material, its use, or its applications.
Okay, if you want to leave your card up here with me or with Franz,
our speaker, he'll see that you get more notes.
He'll send them to you.
Okay, should I say that?
Yeah, we may also have them published in the newsletter as well.
Whatever your address is here.
I'm sure he'll give it a shot.
I'm a fellow countryman, as I understand.
I can officially say good afternoon at this exact moment.
Everyone here, you are in Unisig Session 8.
The title is Migration of Software from VMS to Unix.
Our speaker today is Franz Hubber, and he's from Accelerate.
Okay, Franz, take it over.
How about now?
Yeah, that's better.
Accelerate Technology Corporation is a company that specializes in providing migration tools
for going from VMS to Unix.
We're based in Denver, Colorado.
And I'm going to be talking about this problem that you're facing,
all the obstacles that you're facing when you're moving from VMS to Unix.
And in a sense, I'm talking a little bit more on the practical side.
I'll show you what you have to overcome.
And you have heard in the previous talk some of the difficulties of how to implement
some of the things that you need to do.
I'm not going into that detail.
But I'll give you a little bit more of how difficult it is to take really a program
to compile it on the other side with a compiler that's available on a tech station, for instance.
So in that sense, I almost feel like it would have been maybe better to have my talk first
and then have your talk because you went into some more of the detail
of how to implement those constructions.
Okay.
Now, when we are...
Obviously, we're looking at two operating systems.
On one end, there's VMS.
And you're familiar with that.
And it's a very extensive operating system.
It contains all the facilities that you need.
On the other hand, we're looking at the Unix operating system,
which, as you have heard also, it kind of gives you the basics.
And then many of the things you have to build around it.
So it's not as extensive.
On the other hand, that has always been said that that is one of its strengths.
That makes it so nicely supportable.
You can do everything that you want to do with it.
But nevertheless, for the practical purposes for the user,
you find yourself looking for tools, for add-ons,
for adding things to the operating system many times.
And the reasons why we want to migrate was also pointed out.
We share the same view.
It is strictly the cost benefit.
And now, what areas and who is impacted by the migration?
I like to characterize this and put it into three groups.
Affected are the users, obviously.
And that is, I mean, here the programmers.
I mean, the more casual user, like a scientist,
is running his programs that was written on a wax
and now suddenly it has been moved to a DexStation 3100, say, that has Alteryx.
And now he's running the same program on that.
And the areas where the users are impacted,
as immediately as the command line, which is a very visible obstacle to overcome.
On one hand, we're looking at, on the VMS, TCL,
which is a very basic looking type language.
Everything is nicely spelled out.
On Unix, we're looking at a more cryptic command language.
And obviously, the next thing that you immediately run into is,
you have a different set of editors.
You are used to EDT and those kind of editors.
On the Unix, you have different editors,
and it's just a shame to yet learn another editor.
And nowadays, all the computers are networked together on local area networks,
and again, there's different tools available.
There's TechNet on one side, there's TCPIP on the other side.
The tools that come with it are a little bit different, et cetera.
So those are kind of the things that are immediately visible to the users, to the programmers.
I'm not talking much more about this here, what goes on,
except just to say there are products out there in the marketplace.
They should be fairly easy to find for you and to evaluate.
There are some command language interpreters that give you VMS commands on a Unix platform.
There are EDT emulators that give you the EDT editor on a Unix platform.
So you can look into those, and they can help you greatly in that area.
The second area that we're running into is that we want to migrate and move programs
that were originally written on VMS running on a VAX,
and now are being moved over to a Texas 3100, say, on the Alteryx.
Now, there are obstacles to that.
And the two obstacles are the VMS extensions to the languages,
and then the use of the VMS runtime libraries and system service calls.
And those we go into some more.
And then, lastly, I want to just talk to you a little bit about the data.
Usually, after we have moved a program and a whole application,
there will be some data files that need to go with that application.
There's either some input data that is needed,
or in many cases, also, we find that not always a whole application is moved off.
Only a part of the application is moved from a VAX to the Unix.
And usually, it is the computationally intensive part.
And some other part may stay on the VAX.
So the data that the programs generate have to then go back to the VAX,
where they are then post-processed, plotted, et cetera.
So we have some data movement that needs to take place.
And between the VAX architectures and the Unix architectures,
there are obstacles with that.
And I'm going to point those out and suggest some solutions to that.
Okay, now that's the agenda.
Let's start with the moving programs from VMS to Unix.
There are, of course, various ways.
One way, as was pointed out in the talk before, is you can translate.
You can use translators and say,
I'm going to translate the same of my program that was written in Fortran into C.
And C is a more portable language,
and C compiler is available on my deck station, and I use that.
Another way, of course, is by saying, well, let's look what's available.
And I'm using here as an example of Fortran.
It applies to practically all the other languages, high-level languages.
But Fortran seems to be the easiest language to describe what goes on here.
So the other way of going about it would be saying,
well, let's look what is available as a Fortran compiler on the deck station.
And let's move the source over to the deck station,
then compile it over there and do it that way.
So we have one barrier there, and those are what we call the VMS extensions.
As you are familiar with,
digital has made extensions to the languages, practically all the languages,
beyond the standards.
In the case of Fortran, the standard that nowadays everybody works with
is the Fortran 77.
Digital has made extensions beyond the Fortran 77.
And those VMS extensions are going to create some problems.
And the second area then would be the use of the VMS libraries and system services.
That is when your programs contain calls to the lib dollars, the sys dollars,
OTS dollars, string dollars, math dollars, SMGs, those kind of things.
A little bit more to the VMS extensions.
I like to characterize the VMS extensions into three levels.
It kind of suggests the difficulty they are going to present
if they are not available on your compiler.
The first level, the syntactical extensions,
those are just merely some extensions that were done
to make the program more readable and easier to document.
The simplest example I can give you there is
the use of the exclamation mark to make a comment on the same line.
That is not a standard Fortran 7.
You have to make a separate line starting with the C in column one.
The debug line is also an extension.
So those are simply syntactical extensions.
The reason I characterize those into level one
is not that I am saying those are not as important.
Obviously they are, because if you have a million lines of code,
you are going to have a lot of work to do if those extensions are not there.
Because all those lines have to be decoded.
However, at least those extensions can be getting rid of in a mechanical fashion.
What I mean here is somebody can sit down and just go and do it.
You don't have to understand the program.
You don't have to tear apart the logic and put the program together again.
You can just go in and or if you want to you could also write yourself a program that does that.
So that is why I characterize those into level one.
Just to give you a little bit more idea, another one would be the length of variable names,
which is 31 characters on the VMS.
While it is still the seven characters on Fortran as it always was.
So very, very short in the way VMS programmers are used to naming things.
Seven characters just does not make it.
Dollar signs are not allowed.
VMS loves dollar signs and names everywhere.
So those kind of things would be syntactical extensions.
The level two, extended facilities and differences in implementation.
Extended facilities here means something that was added to the whole new constructs
that were added to the language.
Again, to make it easier to use.
The example there is structures and records.
A facility that comes in very handy because it lets you put all the variables that logically go together
into a structure and refer to it by one name.
Especially handy when you're using index files.
This is, for instance, how the CI some routines like to handle things.
So a very handy concept.
If that is not available, you will have to recode those things into common blocks,
work that way or find some other way, listing them all out.
So extended facilities would be one example, records and structures.
Differences in implementation.
That gets now a little bit more difficult because usually it's not so visible.
Differences in implementation comes about because the standards, any language standard,
as you know, does not specify of how you have to implement things.
A standard only defines what has to be implemented.
The example and the things that you should know about,
it's something that you will find in many programs that VMS does,
that's an example because it's important, is a logical variable.
The standard defines that there is something called a logical variable.
And if a variable is declared as logical, then it can have two values.
It can be true or it can be false.
However, a standard doesn't go beyond that of saying how such a thing has to be implemented in a compiler.
So implementers are free to choose how to do that.
You could represent a false as a word that is all zeros and a true that's all ones, for instance.
Or you could implement it as zero and a minus one.
Wide open.
Whatever works because it needs to only have two kind of states.
However, the VMS implementations have chosen to implement logical variables by only one bit.
One bit is sufficient.
And so all the if statements in a Fortran that's written under VMS,
they test only the least significant bit.
That means all the rest and all the 31 bits are now open for other information.
You can put other things in it and it will not disturb the value of the logical variable.
And that is used extensively.
This is what digital does with condition codes.
If you look at the condition codes, you will notice that the least significant bit toggles are around very conveniently
with the severity of the error so that you can put it just into an if statement and it will work.
And then all the rest of the word contains facility number and the error code,
those things that let you then formulate this nice error message.
So those would be one example of a difference in implementation.
And I'll show you actually a segment of code in the next slide so that you can see some more of what that looks like.
Level 3 is probably the most bothersome.
And the only title I could think of to put to this would be idiosyncrasies of the VMS Fortran.
Obviously, any implementation, any compiler, any translator has its own idiosyncrasies.
I do not mean here to fault digital on saying it's bad, because they're always there.
However, we have to be aware of them.
And I give you on the next slide the example that you will most likely run into.
Now, on this slide, let me just point out, like I said, the testing of the integer variables in an if statement.
You're probably very familiar in the documentation, in the manuals, in digital manuals,
where it shows how to write a program.
It shows that this is a typical sequence here.
When you say status, it's declared as an integer, by the way, is equal.
We're making a lip dollar call.
And now this lip dollar call returns a status.
In the next line, you just do an if not status.
And we go to call lip dollar signal, let it handle the error.
Now, such a statement will not work on a compiler that is on a UNIX platform.
And the reason again is because this statement relies on the fact that you're only testing the least significant bit,
because status contains all kinds of other information.
It's not only a zero or a one.
So this statement here, when you have that in your program, that will have to be recoded.
Another obstacle that you will run into is omitted arguments.
Omitted arguments are very useful in the use of the, especially SysDollars and the LipDollar routines,
because they have a very large number of arguments, and not all of them are always needed.
Remember, in a lip dollar, you can even lop them off.
You don't have to put in all the trailing commas.
If a lip dollar call has 10 arguments, for say, but you need to only specify the first one and the rest, you say,
use the default values, you just need to put in the first argument, close the parenthesis, and you're done.
Now, that creates another problem for Fortran compilers, and that leads us to the next one,
which is it creates actually a call with a variable number of parameters.
In this case, as I said, we're passing one parameter.
However, if you specified more, then again, the compiler would have to generate that call
so that the routine that's being called can find out how many actual parameters were passed.
And that is not something that Fortran compilers do that are based on Unix.
The next one that I listed here is something that we have learned by experience
that seems that just everybody seems to have in their code without even knowing.
And that is passing an integer that was declared as an integer star 4.
It's a 4-byte wide integer.
And you're passing that into a subroutine, and that subroutine was written to expect a 2-byte integer, an integer star 2.
And usually, well, let me explain it this way.
This will work on a vax for two reasons, normally.
One is the reason that this parameter was declared in the subroutine as integer star 2
is because the coder knew that only small numbers are going to come over here.
It's probably a mode parameter that only has a value of 0, 1, 2, or 3.
And then there's a computed go-to to branch to three different locations.
So he knows there's only small values coming over, so why waste the space?
Let's declare this integer star 2.
Now, the other programmer that's calling this routine, he may not remember that or not even know that.
He just knows this is an integer and that it's a mode parameter.
Well, he might just put there a literal.
He might just put there 1, while the literal 1 is translated by the compiler into a 4-byte wide integer.
Now, that 4-byte wide integer, what's going to happen now is to do the vax architecture,
which is a, you may not know this, but the little Indian byte ordering.
It's such that the subroutine will actually fetch the least significant half of that integer.
And since you're normally working with small numbers in this situation, you've got the right value.
Now, everybody else in the world out there, except for DEC and a few exceptions,
but by and large everybody else has a byte ordering which is referred to as the big Indian.
And the big Indian is just the opposite.
So your routine now suddenly on the DEC station 3100, you will not have the problem
because DEC selected to run the MIPS computer chip in the little Indian mode.
But if you're going to a MIPS computer system, which is basically the same internal machine,
you will run into the problem because now it will fetch the upper half of that integer,
which you'll find out will always be 0.
And suddenly everything compiled, everything loaded, everything seems fine,
except that you get runtime errors or you get wrong values.
And it's a very bothersome idiosyncrasy that's happening
because compilers cannot give you any warning of this.
They don't know when you're doing that.
Fortran is not a strongly typed language.
It doesn't let you declare of what parameters have to be.
And therefore compilers cannot give you any help.
And usually you find those things one by one by trying out to run your program.
Another obstacle, of course, is the use of index files.
If you're using programs that need to read and write index files,
then again on Unix you do not have, Unix itself does not have the support for index files
because Unix just does not go beyond the flat file
and doesn't implement any structure beyond the bytes.
And so you have to find a solution to that.
The solutions to that would be most people are going to the CI some routines, adding that, do that.
And again, we've already heard for those of you who have been in the previous talk,
that isn't as easy either.
Interfacing to the ISAM some routines will take some time to get used to also.
And then lastly here I've put something down that I've also found in very many applications
and many people complaining about the following,
that Unix base compilers do not allow you multiple initializations of data in common blocks.
Now that is something which again standard FORTRAN doesn't say you can do.
However, you can do it under VMS.
And the reason that people are running into this so frequently is
because it's very convenient to make an include file
and declare all the comments that you need in that include file
and put the data statements also in that include file.
Well, but that means then whenever you use this include in every program,
the data statement is going to be there and you're trying to initialize that common area multiple times.
And that is absolutely no problem under VMS.
You get, if you do that, even if the values would change in the data statements, no problem.
You will get the values that were put into this common area with the first program that you hit,
that you're loading, that's what you get.
Well, I do not know any Unix base compiler except for some translators,
but not compilers that let you do that.
They will all generate load errors.
And that means you have to go in there and change all your include files around
and find another way of writing your programs.
So again, it is not that you can't do it, it's just making you a lot of work.
So I just want to point out to you that you have a little bit of a flavor of what goes on here.
If you're going from, if it's a Fortran application and you're going, it's running on a VMS,
you have acquired a Textation 3100.
On there is a Fortran compiler that originally was developed by Mepps Computer Systems.
And I know that compiler real well.
I've worked with Mepps on that compiler.
I know the extensions.
The extensions are fairly good.
You have the records and structures.
You have the omitted arguments.
And the index file support, for instance, was taken out.
So on the Textation 3100, Fortran does not allow you,
there is no such thing as key access is equal, keyed.
There is no such thing.
So that was taken out.
There's a few other small errors or problems, bugs that I'm aware of.
For instance, you cannot use a comma, an omitted argument,
if that is the first one in the list of arguments.
That would just generate a syntax error.
But it works everywhere else.
So there are certain problems still.
And I have worked a lot with those compilers.
And all I'm telling you is if you get to the point where you want to do this,
I will be happy, if you give me a call,
I'll be happy to tell you what to expect and what to avoid.
Now going on, the next step of making our program run
would of course be then to load the program together.
And this is where we hit then the next obstacles.
And those were the use of the VMS library and system service routines.
The SysDollars, the LipDollars, the SMGDollars, StringDollars,
MathDollars, all those wonderful things.
The VMS concepts of logical names, event flags, mailboxes,
the ASTs, the QIOs, the process handling, LipDollar, Spawn,
screen management, those are the SMG routines,
string and math routines, all those things are not on UNIX,
at least not in the same form as you were used to and had on the VMS.
So there we have to, again, we have to do something to work around them.
And if you were here in the previous talk,
we had a very good description of some of the things that you have to do,
what the problems are to implement event flags,
what the problems are to implement or do a really good AST implementation.
Not all that easy on UNIX.
Not that UNIX can do all those things.
Sure, you can do it, but it has to be done in a different way.
What that means is that you would have to tear apart your program.
So far I've been talking about VMS extensions,
and I've told you this kind of mechanical thing.
The compiler will give you errors.
You have to go in the code and maybe change lines around.
I've told you a few things to look out for.
Now it gets real serious.
If you have used a programming structure that expects those ASTs and works that way,
you don't have them on UNIX in that form,
you will have to really rethink of how to do this thing on UNIX.
And you would have to tear the program apart, put it back together again,
and that usually comes close to rewriting it.
In those cases, we tell everybody that you should look at the tools that are available to do this.
There's a small number of companies that are making this VMS system services
and libraries that run on UNIX.
They should be fairly easy for you to find out who they are,
and you can evaluate them.
I believe that a good implementation of some of the things,
like mailbox event flags, ASTs, is probably beyond the individual user.
It takes a lot of working and working with many users after using it
and finding out what the problems are to get this thing right.
So that's that hurdle.
Once we have done that and have added the VMS system services to it,
we should have now a running program,
and it should produce the same results as we had on the VMS.
That's the ideal outcome, of course.
I'm not telling you that this will go without any problems.
Unfortunately, it's not a very automatic thing.
You may have to go in there and tweak things here and there in order to get it really to run.
Okay.
Now, once we're at that stage,
we have a program that runs now on our DeX station 3100, say.
Usually, it needs some input data, which is also now still on the VAX,
and it may produce some output that needs to go back to the VAX.
And let's look into this area of the data sharing between VMS and UNIX environments.
By now, there are tools available to move data around.
It means the connectivity issue is pretty much solved.
We have network tools.
In the arena we're talking about, when we're talking about UNIX,
maybe with the exception of the Cray computers,
UNIX and VMS, you're finding that you will have an Ethernet-based network.
And there will be, on that Ethernet, you will either have a TCP IP protocol running,
or you'll have the TECnet running on it.
In some cases, they may be running both on the same Ethernet.
And nowadays, both TCP IP and TECnet are readily available for each end.
You can buy from about half a dozen manufacturers TECnet implementations for UNIX computers.
And again, there's half a dozen manufacturers that make TCP IP,
including digital, TCP IP, for VMS, for VAXs.
So you can choose whichever way you go.
You can buy the things off the shelf to solve the connectivity issue.
Now, with these network software, there always come tools.
And those tools will be, if you have one of those, they will be familiar to you.
The tools are, well, the digital one is called the VMS Alteryx Connection.
That really consists of an FTP and an NFS.
You know, the FTP, which is the Fire Transfer Protocol,
which is part of, it's one of the applications of TCP IP.
In TECnet, you have the copy command with the equivalent of that.
NFS, the network file sharing, which was pioneered by Sun,
that lets you mount files on a remote computer and read and write to them.
Those tools are readily available.
You can buy them from several sources.
So the connectivity issue is solved.
What I mean here is that we can use those tools to move the files physically from one end to the other.
Well, however, there are barriers.
And those come to, if we want to use them,
then we might find out that these tools leave us with something that's not quite ideal to use.
To explain this, let me go a little bit into, as you're aware of,
on VMS, we're dealing with a very well-defined file organization and record structure,
because it is part of the operating system, the RMS files.
It's very well-defined.
On UNIX, there is no such thing.
UNIX doesn't define beyond a stream of bytes of what files else might look like.
So there's a problem there.
What should the files, when we're moving a sequential organized file from a VAX to a UNIX,
what should it look like on the other end?
UNIX doesn't define such a thing.
So what does it look like?
Fortunately, they have some de facto standards involved.
For instance, I'll give you just one instance.
And that is, take a text file.
A text file that was generated with an EDT editor on a VAX.
That is in a variable length record format.
What that means is there is a byte count, and then come all the characters that are in that line.
Now, when you use FTP to move that file over to the UNIX platform,
it will look at that byte count, and it will throw it away,
and it will put the characters in, and then put the line feed at the end.
So it's changed the record format into a stream line feed record format.
And that is what every text processing type thing that's out there in the market for UNIX,
the VI editor, as an example, what it expects.
So that is the logical thing to translate something into.
Now, in other areas, we're not as fortunate.
In index files, there isn't really a really good de facto standard,
except that everybody seems to be adding the CISAM package to UNIX when they need to do the index files.
Or the other alternative, which you have mentioned earlier, the DISAM.
So we could use that to reproduce index files on UNIX.
However, what I want to point out is that FTP will make the translation for text files
from the VMS format into UNIX format.
And that's why you'll be very happy with FTP moving around program files
or files that were written with formatted statements in FORTRAN.
You can move those back and forth, and you won't have any problem.
The problem comes in when you're dealing with binary files.
Binary files, now suddenly we're talking about not just characters with it.
There may be characters, there may be integers, there may be a floating point in the binary representation in there.
And in these cases, FTP will, because FTP does have a verbatim mode,
it will let you move such a file, but it will not do anything to the content.
It will just move it as is, byte for byte.
And that means if you're moving an index file from the VAX with FTP in verbatim mode over to a UNIX platform,
you get the tree structure, bytes and pointers, everything.
That means it would take somebody to know what that structure is,
to figure out on the other end, on the UNIX end, to know what to do with it.
So that is the problem.
Beyond those problems there are, and that is what I'm referring to the barriers as the file organization.
Now beyond that, we have differences in the computer architectures.
And those differences are, we have different, well, in most UNIX machines,
I told you we have differences in the byte ordering.
One is called the little Indian, the other one is called the big Indian.
We have differences in the floating point representation itself.
UNIX uses the IEEE format, which is not exactly the same as your F floating point and the D and the G and the H floating points.
In some cases they're very similar, but not the same.
So we have those problems.
And then we have data alignment problems.
Look out whenever your program, if you do this, whenever your program doesn't work, it runs, but it gives you weird data.
Look for alignment problems.
VAXs do not align data.
Any other machine, the modern architectures that are out there, especially RISC architectures, will align data.
That means data cannot start at just any given byte address.
An integer star 4, for instance, will have to start at a byte address that's divisible by 4.
So that means we're creating gaps in the data.
And that's what's expected on the other side.
So look out for that.
And that's another barrier when you're transporting a binary file from VMS that has no alignment in it.
Now, on the other end, you need the data aligned.
Who is that going to do for you?
So those would be the areas that we need to find solutions to are the architectural differences and then the differences in the file organizations.
There are some solutions that are available commercially out there.
And those are file transfer and translate programs.
So in other words, programs that are not unlike FTP, that are just moving this thing over byte for byte,
but that actually go in and change the content around so that then on the Unix platform is usable.
And going back from Unix to VMS, making the required changes again.
In order for such tools to work, you have to realize that there's no magic out there.
If you need to go into a data file and you need to change its internal representation of it,
you have to know what these bytes represent.
In other words, you have to know what the data looks like inside the files.
And somehow that has to be described to those programs.
It has to be described as an example that the first four integers are an integer.
Because if they're an integer, then they have to be byte swapped.
If the first four bytes are characters, nothing is done to them.
And there's absolutely nothing in binary files that will let you get any clue of what bytes represent.
There's no data typing within binary data files.
So there has to be an external description for that.
So for any of these tools to work, unfortunately you have to know what this data represents.
If this data has been generated by your own programs,
well, if you don't remember what's in there, you can go back to the source code and figure it out.
Just look at the right statements and you see what's being written out.
The problem only comes into when those data files are generated by some third-party software,
and that information therefore is not readily available either because the company doesn't exist anymore,
or if you call them up and say, no, this is highly proprietary, this is our knowledge,
we're not giving that away, then you're finding that you're going to have problems in translating those kind of files.
Another way of dealing with it would be instead of transferring a whole file and translating it,
to leave the file, say, on the VAX, have the VAX as your central depository of all data,
and then the programs running on the Unix workstations should be able to, whenever they need to read a record,
just go over to the VAX and get that record translated in the form that is needed
and presented to the program so they can handle it.
So that would be a remote file and record access.
Again, now that is similar to the concept, if you're familiar with, the concept would be similar to NFS,
but NFS, again, would not do any data translation.
NFS will let you write files onto a VAX, but they will be in Unix format.
That means a VAX program can read them.
So if you want to have a file that's readable by both the VAX and the Unix workstation, then you need more.
You need not only the remote file capability that NFS gives you,
but in addition to that, you need this translation that needs to take place.
And again, there are commercial solutions out there for both of that,
for the file transfer and translate and for the remote file access and translation.
So I urge you to look into those areas when you get to that.
Okay, that's the end of my forum presentation. I invite any questions that you have.
Please step up to the mic here and state your name and the company you're affiliated with.
Turn the tape over now to continue with this program.
Compact Computers.
Isn't VAX 11 Fortran compiled for the RISC architecture at this point?
For the RISC architecture, there are two kinds of compilers available.
The one from digital I'm talking about.
You're talking about the one from digital?
I'm not sure which one you're talking about because I've always been told by digital it's not been released yet,
and I'm not even supposed to know about it.
But I've read some time ago that digital is working on a VMS Fortran compiler for the RISC platforms.
And as much as I know, they're fairly close to it.
Two symposia ago, someone from IMSL got up and talked about their cross-migration of VAX deck architecture to their RISC MIPS box using the VAX 11 Fortran compiler.
I was just wondering, I really thought that had been released. I mean, I've got a copy of it in a house.
Yeah, maybe that is another one that I'm not familiar with.
I know the MIPS Fortran compiler, which is very good in the VMS extensions,
but of course it doesn't solve some of these idiosyncrasies like testing of the if statements.
It doesn't do that in the way VMS does.
I thought the VAX compiler was there.
Oh, the VAX, okay.
David Jones, Tom Software.
You mentioned that the CISAM is available under UNIX.
Do you know of any RMS emulation packages available under UNIX or any other alternatives for index files?
I don't know any personally, but you may want to ask the representative here from Software Solutions.
They have talked about some RMS implementation.
I have never used any. I have not gotten any.
Michelangelo, Compact Computers.
Why would you want to actually port a Fortran code over to the VAX?
I mean, it'd be like taking gasoline and putting it in a jet, I mean, moving it onto a RISC platform.
It'll run, but it won't run well.
It's not optimized for, or the compilers don't optimize as well for the operating system.
Well, I didn't have the impression that they don't optimize as well.
I mean, the technology, I mean, the RISC box has only been out, what, a year and a half now?
Right, right.
The way I see it, what I see it out there is the, you know, in all the languages,
all the compilers are anymore implemented in the form of a language preprocessor and a code generator.
And the code generators are the optimizers.
The optimizer, for instance, in the case of the MIPS-based platforms,
the optimizer technology is one of the most crucial technology for that particular RISC implementation.
It's as important as the silicon implementation of it.
And on top of that sits a Fortran compiler that just translates into this intermediary code.
And so the optimizer, all the languages share.
A C program on a MIPS computer system, for instance, will share, will have the same optimizer, run the same optimizers.
So the deficiency usually comes in the front end.
You know, does the language have all the constructs that you need?
And in the case of moving from VMS to Fortran, it's those VMS extensions.
I guess I'll step to the end of the line.
Yeah.
Michael Angel Compact, still.
The current implementation of the UNIX file system doesn't include the extensions that AFS is going to provide that digital is working towards.
Once that comes into play, this is just information.
Once that comes into play, that should take care of some of the RMS problems.
I was just curious.
You mentioned that logical names, QIO, event flags, mailboxes, process handling, screen management resources,
string and math functions, and several other things aren't available under UNIX.
Actually, they are.
They're just called different things from what DEC does.
They're there very well, very properly implemented, very highly optimized.
They're actually in the kernel, and they work reasonably well.
The other question I had is, does the Fortran 77 option to the VAX 11 VMS Fortran compiler still work?
I mean, if you're going to write code that you want portable, you typically don't include a lot of LibDollar mumble frats on it or stuff like that.
You typically write it, and you put your Fortran 77 option on it, and you say,
okay, yes, this works, no, it doesn't work, and you do it that way.
Yeah, that would work.
If you've done it that way, you probably experience many less problems than people have used everything that you can do on VMS.
Last thing, there are a lot of public domain database management things that will create ISAM files,
the stuff from GNU or UUNet source tapes.
You can get the public domain stuff.
It's reasonably well optimized, and that's why they wrote it.
Have you had any experience with that?
No, I have no experience with that at all.
I have some experience with the CISAMs, but I have no experience with the others.
Yeah, thanks.
Mike, Cory Conoco, Incorporated.
Could you clarify the discussion you had just a little earlier about the digital Fortran product?
I was under the impression that DEC had one, and I think that that would be only for the VAX in the line and not the RISC in from what you said.
Is that correct?
No, what I said is that presently the only announced Fortran compiler on the RISC platforms is the compiler that's based on the MIPS compiler technology.
That one is pretty good in the VMS extensions, but it doesn't have all the idiosyncrasies that the VMS Fortran compiler has.
It differs there.
What I know is, and it has been written up in some trade papers as kind of like a rumor,
that digital is working to take a VMS Fortran compiler that has all the VMS extensions, everything there,
a VMS Fortran compiler, and make it work on the RISC platforms.
But that one, to my knowledge, has not been released.
However, they're fairly close because I know one salesman in an office has a copy and is working with it.
But he told me I'm not supposed to know about it.
Michael Angel, Compact.
Actually, what they started off doing was they took the Fortran compiler from MIPS and they retrofitted a lot of things.
The actual developer for that compiler happens to be out on the exhibit hall floor, and if you want to hunt him down, his name is Sid Maxwell.
Sid Maxwell, yes.
You can go beat him up about it and complain about it.
Okay, I will.
I talked to him on the phone several times.
Glad to hear he's here.
Well, thank you.
Applause.
That concludes our program.
Now fast forward to the end of this side.