start	end	text
0	8000	Digital Equipment User Society presents this recording from the 1990 Fall Symposium, December 10th through 14th, in Las Vegas, Nevada.
8000	13000	The following is for informational purposes only and is subject to change without notice.
13000	19000	Neither DECUS nor its authors assume any responsibilities for the material, its use, or its applications.
19000	24000	By introducing software translations on what we do and why we feel we're qualified to speak here,
24000	35000	for the last three and a half years, software translation has been involved in moving VMS software off of the banks and VMS onto Unix.
35000	47000	Now we've decided to approach this by writing effectively all the LIB and SIS and SMG and CLI dollar commands and system calls that you guys are so used to using under VMS
47000	51000	and implementing them under the Unix operating system.
52000	55000	Come on, there we go.
55000	63000	Right, now the original slideshow was really talking about Unix and why it's great and all these type of things.
63000	65000	So I've decided to change it a little bit.
65000	75000	We're going to quickly run through the obvious parts of Unix and then really get down to how do we emulate the SIS and LIB dollar calls under Unix
75000	78000	and what are the in-depth internals of doing such a thing and what are the problems.
78000	84000	For instance, how do you get RMS code running under Unix without having to recode all your application?
84000	92000	And as most of you know, the VAC software written to use RMS, really the structure of it is determined by the RMS system calls.
92000	100000	And as Unix doesn't give this to you, the straight translation into using something like CISAM, which is an industry standard package, really doesn't work.
100000	102000	And we'll go into the details of this a bit later on.
103000	105000	I think this slide's pretty obvious.
105000	107000	VMS is a very rich operating system.
107000	108000	It does a lot for you.
108000	112000	It's a great operating system and everyone I've spoken to doesn't really want to move off of it.
112000	115000	So the question really is why the hell does anyone want to go to Unix?
115000	117000	And it's a good question.
117000	123000	Really, from our point of view, it all comes down to one of cost.
123000	130000	In other words, you can pick up a 386 box running at 33 megahertz for the 200 meg disk and you can probably run about, let's say with our software,
130000	135000	you could put about 10 to 11 users on that for around four or five, maybe $6,000.
135000	138000	Now, I asked you what the equivalent price of a VMS machine is.
138000	142000	So ultimately, and I think everyone would agree, it comes down to price.
142000	144000	Unix isn't a great operating system.
144000	146000	It just happens to be handy and cheap.
146000	151000	So what we're looking at here.
151000	156000	So the best discussion really is going to be how do we move it across?
156000	158000	What are our obstacles?
158000	161000	And how do we get over them?
161000	166000	I'm sorry if I keep reading these things, but I'm really seeing them for the first time as well.
166000	168000	This really just sums up what I said before.
168000	173000	VMS, great operating system, plenty of utilities, all that type of stuff.
173000	178000	And Unix, and this is all the typical Unix sales stuff you hear so often.
178000	183000	The only real points that I personally think, I've been working with Unix for about 15 years,
183000	187000	the only really interesting points there are, one is the technology independence.
187000	192000	The fact that if you do have software running under Unix, you can pretty much guarantee it's going to be future proof.
192000	198000	Anything they do, the chip architectures, and you've often seen the 286s go to 386s to 486s.
198000	200000	They're talking about the 586 now.
200000	202000	The processor architecture is becoming incredibly powerful,
202000	210000	but the nice thing about Unix means that the operating system stuff stays the same.
210000	214000	And really, if you look at this, this is really designed for ISVs in a way.
214000	219000	People tend to sell their software under VMS, but theoretically this could also be applied to people
219000	222000	that do want to move large amounts of software to Unix.
222000	224000	And we're looking at two things here.
224000	227000	One, why would we translate emulate?
227000	231000	And why would we effectively rewrite our software?
231000	235000	The four points for the method that we propose,
235000	241000	i.e. you just effectively purchase a bunch of Sys dollar live subroutines and link it in and run it.
241000	246000	One is obviously you have one code base, and this seems to be of primary importance to most people.
246000	249000	The way we propose is that you only maintain on the VAX,
249000	252000	and effectively when you want a Unix offering,
252000	256000	you simply move it across overnight, run it through a black box,
256000	262000	and then at the end of it, out pops your software running under Unix with no changes whatsoever.
262000	265000	Your code is still configured to run with VMS, it just happens now to run under Unix.
265000	268000	Your software doesn't know the difference.
268000	270000	Quick to market, that's obviously very important.
270000	273000	The whole process can be done in a matter of months.
273000	277000	The flat learning curve, well, I'm not quite sure I totally agree with those.
277000	279000	You do have to get into Unix somewhere along the line.
279000	284000	And cost-effective, I'm sure some of the people in the audience who know us may not agree with that.
284000	288000	We believe it's very cost-effective.
288000	291000	Against, well, yeah, there's the overhead.
291000	296000	And there's no doubt that in doing this, whenever you move software onto VAX,
296000	300000	you have to emulate the IMS libraries, the SysDollar libraries, the LiveDollars,
300000	303000	SOR, SMG, CLI, the whole bunch of them.
303000	308000	And in most versions of Unix, all except Unix 5.4,
308000	311000	this has to be included as part of the executable.
311000	316000	So in other words, you don't have the ability like you do on the VAX to have a runtime linkable library.
316000	321000	Unix 5.4 does, but currently that and AIX are the only two that do.
321000	325000	Runtime dependencies, well, of course, you would be very dependent on the runtime supplied to you,
325000	331000	and then, of course, the obvious question of royalties and licenses.
331000	335000	And conversely, what are we looking at here?
335000	338000	The rewriting, there's the performance aspect.
338000	342000	And again, I wouldn't disagree with anyone that says if you took your code,
342000	349000	whether it be written in Basic, C, Fortran, and rewrote around all the VMS operating system libraries,
349000	351000	it wouldn't perform better.
351000	355000	I suspect that our way of doing things probably degrades the system by about 40%.
355000	360000	So in other words, you could probably run around six users on a typical system.
360000	363000	If you've rewritten it from scratch, you could probably run around 10.
363000	368000	But of course, the timing involved is quite significant in that.
370000	375000	The languages that are available under Unix, C, obviously.
375000	377000	And if anyone's thinking of moving to Unix,
377000	380000	and if you are considering rewriting, C is the only one you should really be thinking about.
380000	383000	Very portable, very powerful.
383000	386000	Basic, there are no VaxBasics under Unix.
386000	389000	I don't know how many of you here are programming in VaxBasic.
389000	391000	I know at least one person is.
391000	395000	Our approach to moving VaxBasic across was we wrote what we call a transpiler.
395000	401000	Effectively, we have another black box that you put in VaxBasic and out squirt C.
401000	406000	The transpilation rate or the translation rate is pretty much 100%.
406000	409000	What goes in comes out in C and runs exactly the same way under Unix
409000	411000	that it would do under VMS.
411000	413000	I don't want to get too much into that now,
413000	418000	as we are doing other sessions on moving VaxBasic to C, both on VMS and under Unix.
418000	422000	There are a number of different COBOLs available that will enable you to move across.
422000	424000	Pascal, Fortran.
424000	426000	Interestingly enough, there's even a Dibol to C translator,
426000	430000	which I've heard is extremely good, that will enable you to get your Dibol code across.
430000	432000	And 4GLs, generally you don't have too many problems with.
432000	436000	4GLs are pretty standard.
436000	440000	The other one we've marked down in the corner there is DCL,
440000	442000	which can cause a lot of problems.
442000	446000	There are DCL emulators available for Unix.
446000	449000	Some of them are very good and some of them are quite average.
449000	451000	But you do have a lot of choice there.
451000	454000	You can certainly shop around and find one that suits you.
457000	461000	Typically now we're looking at really the whole thing.
461000	464000	If we're taking a basic program, and this slide is really up there
464000	466000	because it fits into some of our other talks,
466000	468000	if we look at a typical VMS application,
468000	470000	and we've made it more difficult by assuming it's basic,
470000	473000	the one language that will not translate across,
473000	478000	under the Vax you have the basic compiler running with the basic runtime system.
478000	480000	Of course that's sitting on top of VMS,
480000	485000	which is supplying the STR dollar routines, find files, and all manner of other things.
485000	487000	And of course in the middle you have Vax.
487000	490000	The way we do things in this particular application
490000	492000	is that we would take the VaxBasic and turn it into C.
492000	497000	We would sit that on top of our VMS emulator for Unix.
497000	500000	And of course that then sits on the Unix operating system.
500000	503000	The slide you saw first, if you did actually manage to read it,
503000	506000	said Unix is great at doing absolutely nothing for you.
506000	509000	And that really does sum it up.
509000	511000	The good thing about Unix is it gives you very little,
511000	514000	but what it does give you is at such a low level
514000	518000	that you can implement pretty much anything you want to do on top of it.
518000	521000	There isn't, well we'll come to it a bit later on,
521000	524000	but there's pretty much nothing on the Vax that cannot be implemented under Unix.
524000	528000	The only exceptions that prove difficult or at least inefficient
528000	533000	are the synchronous IO operations, QIO mailboxes, that type of thing.
533000	536000	If you're not expecting to do asynchronous IO,
536000	540000	sorry, asynchronous IO, then you will not have a problem.
542000	545000	And again, this really just sums up the two roots.
545000	548000	One has the application running under VMS at the top there,
548000	550000	and you have two choices.
550000	553000	You either rewrite your application and run it under native Unix,
553000	556000	or as you can see the other roots, which we call the emulated roots,
556000	560000	is the application sitting on top of a VMS emulator running on top of Unix.
563000	567000	Assuming that we've got over the problem of what do we do with our languages,
567000	569000	now again I skipped over that pretty quickly,
569000	572000	because this session really is more about the operating system features.
572000	575000	And we have managed to get our code into object code format,
575000	577000	or under Unix, as we call .o files.
577000	579000	What do we do with it?
579000	581000	As you can see from the slides,
581000	584000	the way we've arranged things is we link in the SysDollar routines there,
584000	586000	and you can see a good example of what we've implemented,
586000	588000	mailboxes, QIO, et cetera, et cetera.
588000	590000	I'm not saying we've implemented more fully.
590000	592000	We've really done the 80-20 of all,
592000	595000	and we've implemented most of what people need.
595000	599000	And on the other hand, we've implemented the live LBRs, et cetera, et cetera.
602000	606000	And really, this really is a schematic of our system, the way it works.
606000	610000	It's no real different from VMS, except we have a Unix kernel.
610000	613000	We've kind of incorporated the STRDollar routines, RMS,
613000	615000	and the SysI routines in the inner level.
615000	618000	Logically, that's where we saw they should be placed.
618000	623000	And then our other routines, such as SMG, the MTH and OTS stuff, on the outside.
628000	631000	Really, now we're going to get more detailed.
631000	634000	This is where it's really going to start going to free format.
634000	636000	Nothing's really prepared.
636000	639000	I'll be getting down there next to that overhead,
639000	642000	and we'll go through some of the more difficult functions.
642000	644000	In other words, what do you do with your RMS
644000	646000	should you not want to go out route?
646000	648000	How would you get your RMS running under Unix?
648000	650000	I'll explain how we did it
650000	654000	and show you some of the problems involved and how to get over them.
654000	656000	At the end of this session, you should have a good idea
656000	658000	how to take any of your Sys and LiveDollar calls
658000	660000	and get them running yourselves under Unix,
660000	662000	which I'm not quite sure is a good idea for us,
662000	664000	but that's the way we'll proceed.
666000	668000	Okay, I'll just go down there now.
688000	691000	Feel free to move if you don't have a good view
691000	693000	from where you're sitting of the screen.
700000	702000	Can everyone hear me?
702000	704000	No, you have to hold that up.
704000	706000	Can you hear me now?
706000	707000	Okay.
707000	710000	We'll start with RMS, as this really has turned,
710000	714000	really seems to be the really difficult one out of all of them.
714000	717000	When we looked at it, we wanted to find a way
717000	720000	of making RMS work under Unix
720000	723000	and yet still give you the capability
723000	727000	of linking in 4GLs, databases, and this type of thing
727000	729000	into your applications.
729000	731000	In other words, we had to implement it on top of
731000	734000	what we hope would be an industry standard package.
734000	736000	Now, currently in the Unix world,
736000	738000	there is only one industry standard ISAM package,
738000	740000	and that would be RMS.
740000	742000	Now, currently in the Unix world,
742000	744000	there is only one industry standard ISAM package,
744000	746000	and that really is called CISAM
746000	748000	from a company called Relational Database.
748000	751000	It used to be the kernel for Informix,
751000	754000	which some of you may have heard of.
754000	757000	So we decided to use that to start with,
757000	760000	but it became apparent that CISAM in its native form
760000	764000	simply would not let you do what you want to do with RMS.
764000	767000	The record locking is totally incompatible.
767000	769000	A lot of the file modes are totally incompatible.
769000	771000	Yet my RFA really doesn't work
771000	773000	or isn't really feasible to implement.
773000	775000	So we took another package
775000	778000	that's freely available on the market called DISAM.
778000	782000	Now, this was available from a company in Canada
782000	785000	called Byte Designs,
785000	789000	and they actually sold the source code of this package
789000	792000	for about $600, which made a lot of sense to us.
792000	796000	So we got that, and then we had to look at
796000	800000	how do we implement RMS on top of DISAM?
800000	802000	Now, we had a number of problems.
802000	805000	One of them was, of course, was the record formats.
811000	816000	Under VMS, you're very used to opening up a file
816000	819000	and letting VMS fill in the details for you.
819000	821000	Is it fixed length, variable length,
821000	824000	stream LF, stream CI, et cetera, et cetera?
824000	826000	Unix doesn't let you do this.
826000	828000	Unix gives you a flat file system.
828000	831000	All you have really is a byte offset into a file
831000	833000	and the ability to read a number of bytes.
833000	835000	And that effectively goes to locking as well.
835000	839000	You have a byte offset, and you can lock a number of bytes.
839000	841000	So the problem was, how do we implement
841000	844000	even the standard RMS features, sequential files,
844000	847000	fixed length files, on top of Unix?
847000	853000	Well, we actually decided to create a file header.
853000	855000	Now, this file header, as it happens,
855000	860000	pretty much emulates the format of the ZABFHC
860000	862000	that you're also used to under RMS.
862000	865000	We effectively write that to the first block.
865000	868000	We pad it out to 512 bytes to do,
868000	872000	so that Unix can do at least reasonable disk IO with it
872000	876000	rather than having each cross byte boundaries.
876000	879000	Of course, in the ZABFHC, we have the type,
879000	881000	the record length, all this type of thing.
881000	884000	So on top of this now, we started with this,
884000	888000	and we then had to look at the different record formats
888000	890000	and how do we go about implementing them.
890000	892000	Some of the easier ones, probably,
892000	894000	are the variable length formats,
894000	896000	where, of course, we just implemented.
900000	902000	I mean, it's something that's pretty obvious, really.
902000	904000	We implemented the size of the field
904000	906000	followed by the actual data.
906000	908000	For fixed length records, of course,
908000	910000	one can get away with just simply writing the record.
910000	912000	You know the byte offset.
912000	914000	You can actually read it quite easily.
914000	917000	Relative files pose more of a problem
917000	920000	because, of course, they can be deleted, filled, or empty.
920000	922000	So, again, the simplest way around that
922000	924000	and the way we used was to write a header byte
924000	926000	at the beginning of each relative record.
926000	928000	I'm still using a flat file system at this point,
928000	930000	and I'm not really talking about index files yet.
930000	932000	And we put an FE, for instance,
932000	934000	which meant empty, filled, FF deleted,
934000	937000	and zero meant empty, and the data followed.
937000	940000	That gave us pretty much all you needed
940000	942000	with RMS when it came to flat files.
942000	944000	We could certainly open a file in any format,
944000	946000	read it in the correct format,
946000	948000	get all the information that we needed out of it.
948000	954000	The real tricky bit came with indexed and keyed files.
954000	956000	Unfortunately, most of the packages under UNIX
956000	959000	are going to assume a fixed length index sequential size.
959000	961000	So, if you want variable length,
961000	963000	the only way to do it is to assume a maximum record size
963000	965000	and write the count at the beginning of the record.
966000	969000	This may not be the most efficient way,
969000	971000	but I'm afraid it's really the only way
971000	973000	if you're going to remain consistent
973000	975000	with other index ISAM packages.
975000	977000	That's pretty much what we did.
977000	979000	We implemented two types of index files,
979000	981000	variables and fixed.
981000	983000	For the variable length, we simply wrote a header
983000	985000	on the front of the record as to how many bytes were in it
985000	987000	and read it back.
987000	989000	Now, one of the big problems
989000	991000	that we then came across
991000	993000	were, funnily enough, RFAs.
993000	995000	This actually
995000	997000	crept back
997000	999000	into the whole philosophy of DecRMS
999000	1001000	and, effectively,
1001000	1003000	why they did things the way they did.
1003000	1005000	I've always wondered why Dec enabled you
1005000	1007000	to maybe reorganize a file.
1007000	1009000	It didn't seem, in today's world,
1009000	1011000	that it would really be any need to.
1011000	1013000	But when you start getting into RFA processing,
1013000	1015000	you quickly realize that
1015000	1017000	if they use standard
1017000	1019000	node
1019000	1021000	accessing in their index databases,
1021000	1023000	then you do have to keep a primary key hanging around
1023000	1025000	so you don't lose current position.
1025000	1027000	This causes a lot of problems
1027000	1029000	when it comes to Unix.
1029000	1031000	The first thing we had to get around,
1031000	1033000	really, was what do we do with RFAs?
1033000	1035000	Under the CISAM system
1035000	1037000	or DISAM, it wasn't a problem.
1037000	1039000	We could get back the record number.
1039000	1041000	But, and this is the big but,
1041000	1043000	you suddenly lose current position.
1043000	1045000	Many of you are used to doing
1045000	1047000	a get by RFA and a get next
1047000	1049000	or even a get by key.
1049000	1051000	Doing it this way,
1051000	1053000	the actual ISAM package lost
1053000	1055000	its key information when you did a get by record number.
1055000	1057000	So we had to do some modification
1057000	1059000	internally to that to enable us to save
1059000	1061000	in a context block the current key information
1061000	1063000	effectively.
1063000	1065000	Once we did that,
1065000	1067000	things got a little bit easier.
1067000	1069000	Once we did that, it took about a year to get this far.
1069000	1071000	Then we had
1071000	1073000	other minor little problems.
1073000	1075000	I really just want to go into some of the trickier things.
1075000	1077000	Take it as read that most of the things you want to do
1077000	1079000	are simply implemented.
1079000	1081000	Now, I'm not going to assume record locking at this time.
1081000	1083000	We'll go into that later. That's a whole bag of worms
1083000	1085000	which takes a long time
1085000	1087000	to sort out and it really is not compatible.
1087000	1089000	You're going to have to put a lot of thought into record locking.
1089000	1091000	Other minor problems,
1091000	1093000	things like get next and delete.
1093000	1095000	Again, because CISAM or DISAM
1095000	1097000	is using a balance B plus tree
1097000	1099000	to do all its indexing.
1099000	1101000	The get next is no problem, but the delete
1101000	1103000	deletes the current node.
1103000	1105000	It then reshuffles and leaves you without the current record position.
1105000	1107000	The next get next
1107000	1109000	effectively leaves you in the middle of nowhere.
1109000	1111000	That has to be sorted out.
1111000	1113000	You have to rewrite your code or do as we did
1113000	1115000	and get into the ISAM package
1115000	1117000	and effectively do as
1117000	1119000	exactly what DECC do
1119000	1121000	and not really delete the record.
1121000	1123000	Effectively, mark it as deleted
1123000	1125000	and not return the bitmap
1125000	1127000	into the free list.
1127000	1129000	All of a sudden we found ourselves
1129000	1131000	getting pretty much like DECC.
1131000	1133000	When we were swearing at them before and saying
1133000	1135000	why are they so crazy? Why do they have to do reorganizing?
1135000	1137000	Suddenly we find ourselves in that exact same position.
1137000	1139000	It's unfortunate,
1139000	1141000	but it's a way of life.
1141000	1143000	If we want to do 100% emulation of RMS,
1143000	1145000	which is vital, if you consider that we've
1145000	1147000	translated around
1147000	1149000	2 million lines of basic,
1149000	1151000	some 20 major
1151000	1153000	applications
1153000	1155000	and I guess around
1155000	1157000	half a million lines of C code,
1157000	1159000	something like that.
1159000	1161000	You can't really afford to be different
1161000	1163000	from RMS. Whatever RMS does,
1163000	1165000	we have to do as well.
1165000	1167000	Otherwise we're going to end up recoding every program
1167000	1169000	which is not something we could do feasibly.
1169000	1171000	We now found ourselves in a position
1171000	1173000	where we have to reorganize
1173000	1175000	if you do want this particular feature.
1175000	1177000	We left it as an option.
1177000	1179000	If you don't want to
1179000	1181000	do a get next delete, if you don't need to
1181000	1183000	reorganize or use features that cause us
1183000	1185000	to reorganize, then you can use the balanced
1185000	1187000	noting of the actual ISAM package.
1187000	1189000	I'm sorry I'm not going to
1189000	1191000	write these down, but I'm not really going to be able to
1191000	1193000	really get finished in time
1193000	1195000	and write these at the same time.
1195000	1197000	I'll be happy to go into more detail at the end of this.
1197000	1199000	If anyone does want any of these
1199000	1201000	nodes, we'll be happy to send them to them.
1205000	1207000	We have a trade-off
1207000	1209000	between RMS
1209000	1211000	having to reorganize
1211000	1213000	or something like CISAM
1213000	1215000	DISAM, an industry standard,
1215000	1217000	use it as it is and you get
1217000	1219000	no current position, which has ramifications
1219000	1221000	into a lot of code.
1221000	1223000	Or, take the other option
1223000	1225000	and use DISAM and you have to
1225000	1227000	reorganize, which means, of course, you've got the same
1227000	1229000	painful exercise you do on the deck.
1233000	1235000	That was RMS skipped over really quickly.
1237000	1239000	We're now going to move on to
1239000	1241000	some other points that make it difficult
1241000	1243000	and really quite painful.
1243000	1245000	This one really is ridiculous,
1245000	1247000	but it can cause us the most problems.
1247000	1249000	That's file names.
1249000	1251000	Most of you know that Deck have brought out
1251000	1253000	the RISC-based machines
1253000	1255000	based on the MIPS processors.
1255000	1257000	They're based on
1257000	1259000	BSD 4.3, which gives you
1259000	1261000	255 character file names.
1261000	1263000	That really isn't a problem.
1263000	1265000	On the other hand, Deck now have brought out the
1265000	1267000	Deck 333, the 486 machines.
1267000	1269000	They're all based on SCO Unix.
1269000	1271000	SCO Unix, 5.3 as it is
1271000	1273000	currently, only enables you to have
1273000	1275000	14 character file names.
1279000	1281000	Add on to this
1281000	1283000	that when you're using one of these standard
1283000	1285000	CISAM packages, it's going to throw on
1285000	1287000	a .IDX onto the end of it as well.
1287000	1289000	That brings you down to 11.
1291000	1293000	Unfortunately, we experimented
1293000	1295000	with a number of ways of getting around this
1295000	1297000	file translation tables.
1297000	1299000	It really didn't work.
1299000	1301000	The only real way to do it is to rewrite your code,
1301000	1303000	get rid of the large file names,
1303000	1305000	or at least turn them into logical names
1305000	1307000	where they can then be mapped to shorter file names
1307000	1309000	on the SCO systems.
1309000	1311000	I don't know when SCO are going to bring out
1311000	1313000	5.4 Unix. I hope it's soon.
1315000	1317000	I'll go to transparency now.
1317000	1319000	If we look at typical
1319000	1321000	file name mapping, if we take a typical
1321000	1323000	VAX file name,
1331000	1333000	one of the first problems
1333000	1335000	we come across is
1335000	1337000	the disk.
1337000	1339000	Again, this all may sound pretty trivial,
1339000	1341000	but it does cause real problems when you're
1341000	1343000	trying to get your software working under Unix
1343000	1345000	with a minimum of hassle.
1345000	1347000	The first thing you have to do, effectively,
1347000	1349000	is create yourself a device mapping table.
1349000	1351000	Originally, we started off having this in a file
1351000	1353000	that we used to read in at the beginning of each process.
1353000	1355000	That just turned out to be too inefficient.
1355000	1357000	We traded off and eventually put it into shared memory.
1357000	1359000	Unix does give you
1359000	1361000	shared memory capabilities. It's very, very primitive.
1361000	1363000	Effectively, you give it a key
1363000	1365000	and numeric key and it gives you back an address.
1365000	1367000	Then you start using it.
1367000	1369000	You give it a length and it gives you
1369000	1371000	a segment of the size you request.
1371000	1373000	We created a table like this.
1373000	1375000	This table is reasonably important because it's designed
1375000	1377000	also to handle sys$assign and sys$dassign,
1377000	1379000	which, of course, a lot of you are using.
1383000	1385000	The first thing, obviously,
1385000	1387000	in the table would be the VAX file name.
1387000	1389000	Then the mapping file,
1389000	1391000	then it's going to go to Unix.
1391000	1393000	In this case, we can call it
1393000	1395000	slash disk one.
1395000	1397000	Other information that you'll want in the table,
1397000	1399000	things like device type,
1399000	1401000	the block size,
1401000	1403000	other operations you may want to emulate,
1403000	1405000	things like the process ID.
1405000	1407000	I guess we get more importantly now,
1407000	1409000	we added in the number of links
1409000	1411000	so that you can also do as many assigns
1411000	1413000	as you wish to
1413000	1415000	and as many as deassigns
1415000	1417000	and eventually totally deassign any devices.
1417000	1419000	We're not saying this table here
1419000	1421000	is specifically for disks, it can be for mailboxes,
1421000	1423000	any absolute device on the VAX.
1423000	1425000	We added in as well
1425000	1427000	some of the Fab L dev stuff
1427000	1429000	which made it easy for us
1429000	1431000	to pass back the device types
1431000	1433000	to the programs.
1433000	1435000	Once you have this table,
1435000	1437000	once you have it set up there,
1437000	1439000	this becomes quite easy.
1439000	1441000	DUA0 simply maps to disk one.
1441000	1443000	And I think
1443000	1445000	as most of you can see,
1445000	1447000	the directory path name
1447000	1449000	under VMS is pretty similar to Unix
1449000	1451000	and doesn't present too much of a problem.
1453000	1455000	And of course the file name.
1457000	1459000	That's one way of course.
1459000	1461000	Now don't forget you're going to have to go
1461000	1463000	back the other way as well.
1463000	1465000	When you're using things like lib.findfile,
1465000	1467000	it's no good passing in a VAX specification
1467000	1469000	and getting back a Unix path name.
1469000	1471000	Most of you
1471000	1473000	look for a semicolon
1473000	1475000	and then try to chop off the version numbers
1475000	1477000	so you know you've got to the end of the file name.
1477000	1479000	You're not going to get that back under Unix.
1479000	1481000	Also don't forget there are no version numbers
1481000	1483000	under Unix.
1483000	1485000	So don't forget the converse side of this.
1485000	1487000	When you call lib.findfile,
1487000	1489000	you must also make that system recode
1489000	1491000	back to a VAX file name
1491000	1493000	and effectively stuff a version number on the end.
1493000	1495000	Just to make things easy.
1495000	1497000	We're going to move on again now
1497000	1499000	to the assign and deassign I mentioned before.
1499000	1501000	Obviously when you have a table like this
1501000	1503000	built up in shared memory, it becomes rather easy now
1503000	1505000	to implement sys$assign, sys$deassign.
1505000	1507000	And what I'm trying to get at here
1507000	1509000	is the core of the system,
1509000	1511000	if you are thinking of moving across to Unix
1511000	1513000	with the minimum Vs, is design your data structures correctly.
1513000	1515000	This is the most important part.
1515000	1517000	You often know this time and time again
1517000	1519000	in programming, but it really is
1519000	1521000	essential in this exercise.
1521000	1523000	And also make them shared and don't forget
1523000	1525000	locking of them.
1525000	1527000	Create yourself all the tables you'll need in shared memory
1527000	1529000	and then you can use the actual native Unix
1529000	1531000	locking to
1531000	1533000	lock the bytes in the table to enable you to access
1533000	1535000	the table without getting two processes accessing
1535000	1537000	the same thing at the same time.
1537000	1539000	We then,
1539000	1541000	that gave us assign, deassign.
1541000	1543000	And I'm really going through some of the
1543000	1545000	trickier ones here.
1545000	1547000	The next one really was ENQ and
1547000	1549000	DEQ locking, which was
1549000	1551000	resource locking, which is used by a lot of people.
1551000	1553000	Unix,
1553000	1555000	for some reason,
1555000	1557000	only lets you
1557000	1559000	do things with numbers.
1559000	1561000	It has no concept of alphanumeric
1561000	1563000	locking, alphanumeric resource
1563000	1565000	sharing, anything like that.
1565000	1567000	So again, we're back to data structures and shared
1567000	1569000	memory. Effectively, if you're going to do DEQ
1569000	1571000	locking, ENQ locking,
1571000	1573000	you have to create yourself a bit of shared memory
1573000	1575000	that has the resource name.
1575000	1577000	Obviously, now if you're talking
1577000	1579000	about shared memory, you don't want to start getting into variable length
1579000	1581000	data structures. So make it
1581000	1583000	fixed length, and also
1583000	1585000	of course, make it long enough.
1585000	1587000	And then add to that, obviously, the process
1587000	1589000	ID, the one who locked it, and
1589000	1591000	any other information you want about that.
1591000	1593000	And you can see I'm getting back to what I said
1593000	1595000	before, make sure your data structures are correct.
1601000	1603000	Okay, now we come
1603000	1605000	to some real fun. ASTs.
1605000	1607000	Yeah.
1607000	1609000	Now these were interesting.
1609000	1611000	We'll start off by
1611000	1613000	saying that ASTs are
1613000	1615000	very difficult to do under UNIX.
1615000	1617000	Extremely difficult. And again, it goes back
1617000	1619000	to your data structures.
1619000	1621000	You're not going to do it easily.
1621000	1623000	If you want one process to interrupt another
1623000	1625000	process, and that process to then leap off to an
1625000	1627000	address somewhere, obviously
1627000	1629000	you've got to store the address you want to leap off to.
1629000	1631000	And have some way of signalling
1631000	1633000	between the processes.
1633000	1635000	Now again, we implemented this using shared memory.
1635000	1637000	Enabling one process to see if
1637000	1639000	another process was waiting on an AST.
1639000	1641000	Send the signal, that process would know where to
1641000	1643000	jump to. And it kind of
1643000	1645000	worked reasonably well, until we realised our first
1645000	1647000	big mistake. And that was
1647000	1649000	that we hadn't put any critical region
1649000	1651000	stuff in the RMS code.
1651000	1653000	So there we were, processing nicely through a sequential
1653000	1655000	file. We got an AST.
1655000	1657000	The AST routine then went on
1657000	1659000	and started reading through that same
1659000	1661000	sequential file, and totally
1661000	1663000	axed every single bit of information that the ISAM
1663000	1665000	package had accumulated about where it was at the time.
1665000	1667000	So one thing that's important to remember
1667000	1669000	again with this stuff, under Unix, is
1669000	1671000	don't forget your critical regions.
1671000	1673000	Lock yourself, make sure you have information there
1673000	1675000	that says, I'm in a critical region, I cannot be
1675000	1677000	interrupted. So when you come out,
1677000	1679000	you can then get on and do it. It's a lot easier
1679000	1681000	saying it, than it actually is to do it.
1681000	1683000	Because Unix does not
1683000	1685000	give you any easy way to say,
1685000	1687000	I'm now out of a critical region.
1687000	1689000	Allow any interrupts to come on. You cannot
1689000	1691000	do clock events, you cannot
1691000	1693000	clue any type of interrupts or signals, they're called
1693000	1695000	under Unix. Now under 5.4,
1695000	1697000	again, you can do this.
1697000	1699000	But in what
1699000	1701000	we've done, we've effectively tried to program for
1701000	1703000	the very minimum, which is a standard
1703000	1705000	which we're going to call XPG3.
1705000	1707000	Which really says,
1707000	1709000	this is the kernel part, this is what Unix really is.
1709000	1711000	We're going to ignore the Berkeley enhancements,
1711000	1713000	we're going to ignore the system 5.4 enhancements,
1713000	1715000	we're going to ignore the Xenix enhancements,
1715000	1717000	and we're simply going to program for the bare
1717000	1719000	minimum. And the bare minimum unfortunately says you cannot
1719000	1721000	queue signals.
1721000	1723000	So again, we had to implement this
1723000	1725000	with a background process, which I'm
1725000	1727000	pleased that we eventually got rid of
1727000	1729000	in favour of a better shared memory
1729000	1731000	data structure.
1731000	1733000	It can be done, it's extremely difficult.
1733000	1735000	The other thing that don't forget is that
1735000	1737000	Unix cannot, as I said before, Unix cannot
1737000	1739000	queue up signals or interrupts.
1739000	1741000	And that goes for the timer as well.
1741000	1743000	You can only have one timer interrupt.
1743000	1745000	So if you want to have three processes scheduled for
1745000	1747000	one minute, two minutes, and three minutes,
1747000	1749000	you have to do your own timer queuing.
1749000	1751000	And again, we implemented most of these things
1751000	1753000	ourselves, because we had to. Unix doesn't give you any
1753000	1755000	ability to do this.
1755000	1757000	It's simply going to tell you, you have a clock interrupt.
1757000	1759000	If the last one you told it was clock interrupt in three minutes,
1759000	1761000	that's the one you're going to get. You're going to miss out
1761000	1763000	the first two.
1763000	1765000	So again, what do you do with these type of things?
1765000	1767000	Well, we eventually implemented
1767000	1769000	this time a local shared memory structure,
1769000	1771000	specifically for ASTs to do with set timer and cancel
1771000	1773000	timer.
1773000	1775000	Obviously, one thing you need is the address you're going to jump to.
1775000	1777000	Sorry about my writing.
1777000	1779000	And the time
1779000	1781000	to interrupt, and that's important.
1783000	1785000	Because what you're going to have to do
1785000	1787000	internally is sort
1787000	1789000	this list.
1789000	1791000	When you get an interrupt happening,
1791000	1793000	when you want something happening in two minutes, you've got one happening
1793000	1795000	in one minute, you've got to rethought the list and
1795000	1797000	reschedule the interrupt.
1797000	1799000	So it's important to keep the time to interrupt inside the list.
1799000	1801000	And the last thing which you're going to need, of course, is the event number.
1801000	1803000	That gets passed by value to the set time
1803000	1805000	and by reference to the
1805000	1807000	routine that it calls.
1807000	1809000	And many people use that to distinguish
1809000	1811000	which particular AST
1811000	1813000	they're expecting the event to happen on.
1813000	1815000	This address, really,
1815000	1817000	if you're looking in terms of C,
1817000	1819000	is star address
1819000	1821000	and percent
1821000	1823000	event.
1823000	1825000	Which means, really, go indirect on that
1825000	1827000	address and pass the value of the event flag.
1827000	1829000	That's
1829000	1831000	again, it's going to
1831000	1833000	very quickly for ASTs.
1833000	1835000	And in particular, ASTs are timers
1835000	1837000	which are most what we find.
1837000	1839000	I'm not
1839000	1841000	here going to go into event handling
1841000	1843000	apart from to say
1843000	1845000	that it's extremely difficult.
1845000	1847000	Event handling is one of the most difficult things we had to do.
1847000	1849000	And again, that's a data structure.
1849000	1851000	You have to go into shared memory.
1851000	1853000	And you do need to have this incredibly complex
1853000	1855000	signaling between two processes to make sure
1855000	1857000	that one, your critical regions aren't violated.
1857000	1859000	And number two, if you're in the middle
1859000	1861000	of a critical region, you don't lose the signal.
1861000	1863000	Because then you won't get the event flag happening.
1867000	1869000	On my next slide
1869000	1871000	is actually event flags.
1871000	1873000	I've got a process table down here with 50 things on it
1873000	1875000	so I think I'll ignore that one.
1875000	1877000	Needless to say that some of the things you need, of course,
1877000	1879000	are a bank of event flags inside the
1879000	1881000	shared memory process table.
1881000	1883000	Actually, one thing I do see on here
1883000	1885000	which I will mention at this time
1885000	1887000	is
1887000	1889000	I think really I'm going to say this to give you an idea
1889000	1891000	how difficult it is sometimes
1891000	1893000	to get Unix to do anything for you.
1893000	1895000	For instance, most of you are used to
1895000	1897000	reading a character or saying, do I have a character
1897000	1899000	available in my input buffer?
1899000	1901000	Would it be, do I have a character there, shall I read it?
1901000	1903000	Now, if you're looking at standard Unix
1903000	1905000	you cannot do this.
1905000	1907000	You cannot say, do I have a character?
1907000	1909000	All you can say is, let me do a read
1909000	1911000	on a channel. And if I have a character
1911000	1913000	give it to me. If I don't have a character
1913000	1915000	don't give it to me. Now, if all you want to do is
1915000	1917000	a check, you suddenly find
1917000	1919000	yourself with a character sitting there
1919000	1921000	and you wonder what the hell you're going to do with it.
1921000	1923000	Now, of course, the problem then becomes
1923000	1925000	compounded if you then want to
1925000	1927000	chain off or spawn
1927000	1929000	another job that effectively
1929000	1931000	needs that character if you're typing ahead
1931000	1933000	for instance. So, other things you
1933000	1935000	have to do to get a good emulation of VMS
1935000	1937000	under Unix is, of course, keep a last character
1937000	1939000	buffer in your shared memory process table list
1939000	1941000	and check that before you do any reads.
1941000	1943000	These all sound pretty
1943000	1945000	trivial, but they're the type of things
1945000	1947000	that can take a massive redesign
1947000	1949000	if you don't get it right at the beginning.
1949000	1951000	As we didn't.
1953000	1955000	Now, one of the other things
1955000	1957000	we're going to come to is now the
1957000	1959000	asynchronous I.O.
1959000	1961000	In other words, Q.I.O. without W on the end.
1963000	1965000	It's difficult to do.
1965000	1967000	You've got to remember that Unix has no
1967000	1969000	asynchronous I.O. capabilities.
1969000	1971000	If you want to do it,
1971000	1973000	if you really need to do it, first of all I'd suggest
1973000	1975000	recode it. It's not something that's going to
1975000	1977000	come across easily under Unix.
1977000	1979000	To give an example, the way we implemented
1979000	1981000	for instance a Q.I.O. to get a character
1981000	1983000	is that we duplicate the job in memory,
1983000	1985000	we then organize a sequence of signals
1985000	1987000	via the shared memory
1987000	1989000	process table.
1989000	1991000	The job, which is a direct duplication, is called
1991000	1993000	a fork under Unix. It gives you two jobs
1993000	1995000	exactly the same, both running,
1995000	1997000	same code, same data, everything.
1997000	1999000	The only thing you don't get across are the locks,
1999000	2001000	the shared memory and this type of thing.
2001000	2003000	So you have two processes that both know what they're doing
2003000	2005000	and then one can go off and decide to read
2005000	2007000	the character. It then has to signal back its
2007000	2009000	parent process that it's now got the character.
2009000	2011000	It gets very involved
2011000	2013000	and very nasty.
2013000	2015000	If you can get away with that, it's one area I'd say
2015000	2017000	that's very difficult to do properly.
2017000	2019000	Don't do asynchronous I.O.
2019000	2021000	Unix 5.4 in the future is going to
2021000	2023000	allow you to do asynchronous I.O.
2023000	2025000	If you depend on Unix 5.4, you're going to cut
2025000	2027000	yourself off from BSD, which the Alteryx
2027000	2029000	machines are running on, and you're going to cut yourself off
2029000	2031000	from the SCO boxes as well.
2031000	2033000	They're still running 5.3.
2037000	2039000	Now the last thing which I'll
2039000	2041000	briefly touch on
2041000	2043000	is SMG.
2043000	2045000	A lot of people are using
2045000	2047000	SMG and we had to implement ourselves as well.
2047000	2049000	There is no direct
2049000	2051000	equivalent for SMG
2051000	2053000	under Unix.
2053000	2055000	Again, what we did was
2055000	2057000	these guys up in Canada,
2057000	2059000	Byte Designs,
2059000	2061000	they're amazing. They also have a product called
2061000	2063000	W, which is a Windows package.
2063000	2065000	We bought the source code for that. It was another
2065000	2067000	whole $600. It was really very cheap.
2067000	2069000	It gives you a good base
2069000	2071000	to implement something like SMG on.
2071000	2073000	Again, we
2073000	2075000	put about another 9
2075000	2077000	months effort into the project
2077000	2079000	to get SMG fully implemented.
2079000	2081000	Again,
2081000	2083000	all these things under Unix. Unix gives you
2083000	2085000	this base, but it doesn't
2085000	2087000	give you the periphery around it which you're so used to
2087000	2089000	under VMS.
2089000	2091000	It is possible.
2091000	2093000	FMS as well is something we're looking at.
2093000	2095000	It is possible to do. There's no doubt.
2095000	2097000	There is nothing under Unix currently.
2097000	2099000	Although a lot of people have chosen to go a slightly different route
2099000	2101000	and that's modify their VAX FMS code
2101000	2103000	to run with many of the packages that are available
2103000	2105000	both under the VAX and under VMS.
2105000	2107000	Sorry, VAX and under Unix.
2107000	2109000	That seems to me to be a particularly
2109000	2111000	good idea.
2113000	2115000	I think really now I've come to the end of the
2117000	2119000	top level technical stuff.
2119000	2121000	I'll be happy to take any questions at this point.
2121000	2123000	It went a little bit faster than I thought it would.
2123000	2125000	I do apologize to the erratic
2125000	2127000	jumping around, but it was prepared
2127000	2129000	in the breakfast hall half an hour ago.
2129000	2131000	Vic Lindsay, VLSystems.
2131000	2133000	In your
2133000	2135000	translation efforts and so forth, what
2135000	2137000	headaches have you encountered with
2137000	2139000	networks?
2139000	2141000	Well, luckily, so far
2141000	2143000	none. We haven't had anyone that's
2143000	2145000	actually wanted to do it.
2147000	2149000	I'm sure we will.
2149000	2151000	Unix does give you good networking capabilities.
2151000	2153000	In particular,
2153000	2155000	NFS.
2155000	2157000	I'm sure that
2157000	2159000	you mean something like
2159000	2161000	DECnet interfacing with RMS?
2161000	2163000	Either interfaces like it or even to go
2163000	2165000	one layer further, file
2165000	2167000	serving onto other machines,
2167000	2169000	common file architecture, so
2169000	2171000	that you can share files, file locks
2171000	2173000	between the two. That gets into a very big
2173000	2175000	mess.
2175000	2177000	I realize that.
2177000	2179000	NFS should theoretically give you most of that.
2179000	2181000	NFS now does enable you
2181000	2183000	to do record locking over multiple Unix
2183000	2185000	machines, which is always the first
2185000	2187000	step.
2187000	2189000	I only covered on briefly, of course, the record locking
2189000	2191000	that Unix gives you isn't sufficient
2191000	2193000	for RMS emulation under Unix.
2193000	2195000	So, it's going to get
2195000	2197000	nasty. I think the only way,
2197000	2199000	if we have to do it, we'll probably implement it using
2199000	2201000	streams, and
2201000	2203000	dedicate a stream server to do record locking
2203000	2205000	and a stream server to do the networking.
2205000	2207000	The streams is a nice,
2207000	2209000	effectively device-independent
2209000	2211000	way under Unix of doing
2211000	2213000	network management.
2213000	2215000	You don't need to know where things are, you just send a message down
2215000	2217000	and it gives it to you back. I imagine if we're
2217000	2219000	going to do it, that's the way we'll do it, but at the moment
2219000	2221000	we haven't had to
2221000	2223000	meet that bridge yet.
2223000	2225000	Thank you for the question.
2225000	2227000	Hi, Charles Capps, Temple University.
2227000	2229000	A couple of questions.
2229000	2231000	One is FDL files.
2231000	2233000	Do you deal with them, or?
2233000	2235000	At the moment, no.
2235000	2237000	We haven't really done anything like that.
2237000	2239000	The only real thing we've...
2241000	2243000	Well, kind of slightly. We have
2243000	2245000	something called Create, which can take an FDL,
2245000	2247000	but it only really works for what customers
2247000	2249000	so far have needed. We can't say we've done a generalized
2249000	2251000	FDL.
2251000	2253000	I guess Create is the main one I'm interested in.
2253000	2255000	Yeah, I mean, you can take some...
2255000	2257000	I wouldn't say it's exhaustive.
2257000	2259000	We tend to implement things as they're needed.
2259000	2261000	If they don't work, we get them working
2261000	2263000	and put them in.
2263000	2265000	The other one is the so-called VAX extensions to Fortran,
2265000	2267000	most of which
2267000	2269000	are in all of the other
2269000	2271000	Fortrans, like while doing stuff,
2271000	2273000	but one of which nobody's touched
2273000	2275000	and it's different in
2275000	2277000	Fortran 90 is records.
2277000	2279000	Have you dealt with that at all, or?
2279000	2281000	Not under Fortran.
2281000	2283000	We did under Basic.
2283000	2285000	Again,
2285000	2287000	things like Fortran,
2287000	2289000	we haven't applied too much effort to at the moment
2289000	2291000	because there are good products out there, but
2291000	2293000	I think your best thing would be to
2293000	2295000	recode it out after you've
2295000	2297000	carefully put it in, of course.
2297000	2299000	Yeah, that's
2299000	2301000	where that does a lot of nice stuff.
2301000	2303000	Well, I guess if you recoded it to see...
2303000	2305000	There was a thing called Fortrix
2305000	2307000	on the market, which is
2307000	2309000	a Fortran to see translator
2309000	2311000	by somebody.
2311000	2313000	They're over in the Boston area.
2313000	2315000	They probably
2315000	2317000	would handle that.
2317000	2319000	I know a lot of their stuff is designed for DEC.
2319000	2321000	Thank you.
2321000	2323000	Rama Kuduru
2323000	2325000	from Bara.
2325000	2327000	Is there something comparable to
2327000	2329000	VMS mailboxes in Unix, and if not,
2329000	2331000	how did you implement mailboxes?
2331000	2333000	That's a good question. I missed those totally.
2333000	2335000	Yeah, we did mailboxes.
2335000	2337000	There is nothing comparable.
2337000	2339000	You only have FIFOs.
2339000	2341000	You can create a node
2341000	2343000	under Unix, which is effectively
2343000	2345000	the ability to throw characters in a queue
2345000	2347000	and then another process can take them out.
2347000	2349000	That's all you have
2349000	2351000	for a base level under Unix.
2351000	2353000	If you want to implement
2353000	2355000	the full mailbox IO
2355000	2357000	of VMS around that, you have to put a lot of
2357000	2359000	code into it. And of course, again,
2359000	2361000	you have to go back to the asynchronous
2361000	2363000	side of things, which we had to do a lot of work on.
2363000	2365000	Let me know when a mailbox has got some
2365000	2367000	information in it, which just about everybody
2367000	2369000	uses or seems to use.
2369000	2371000	The answer is, one, no, Unix
2371000	2373000	does not give you anything as powerful as
2373000	2375000	mailboxes, but it gives you a very low level
2375000	2377000	way of throwing things
2377000	2379000	into a device and reading them out again.
2379000	2381000	You've got to remember,
2381000	2383000	Unix is really character based.
2383000	2385000	You throw characters in, you read characters
2385000	2387000	out. What you do around that
2387000	2389000	is up to you.
2389000	2391000	We implemented the full mailbox
2391000	2393000	spectrum of system calls.
2393000	2395000	But again, it took a long time.
2395000	2397000	But it is as certainly as possible.
2401000	2403000	No one else? Okay, well,
2403000	2405000	thank you for your time, ladies and gentlemen.