Learning a New OS... and Fast!? 76
Inexile2002 asks: "I've been asked to assist a consultant on a project using VMS and basically have four days to figure out enough that I'm actually of some use. (We're not doing development, just security reviews, so I'm not totally screwed.) Originally I was going to ask for advice on how to start teaching myself VMS from scratch including best books and support websites when I realized that there is a more generic issue here. What are people's thoughts on learning a new OS and learning it fast? Have people found optimal ways to pick things up quickly, get a familiarity with commands and underlying logic? How about learning the basics when you can't actually install and play with the OS in question?"
As with any project... (Score:5, Funny)
Re:As with any project... (Score:1)
*looks at 5,000 page essay due in in 7 hours*
Re:As with any project... (Score:2)
Daniel
Rule #1 (Score:5, Insightful)
Books will only go so far. Real-world experience is the only thing that counts.
Re:Rule #1 (Score:3, Interesting)
But I had been building my own little microcosm of the internet, complete with a few vaxen. All the windows monkeys at work look at me with a strange grimace, and sometimes utter things like "What is the point in all of that? No one *ever* uses it anymore...".
But don't worry, security is a simple thing, and even someone that knows nothing of VMS can fake it in a few days. I'm sure that 99.999% of kiddiots will never be able to exploit a VMS hole that you have no chance of catching....
Re:Rule #1 (Score:1)
Why does this make me believe that you are probably also faking your skills in Security.
I've been working in Network/System professionally for about 5 years now, and the one thing that I learn over and over, is that Security is by far the most demanding discipline in the IT world.
It's far from simple.
From your comments, it sounds like you could be replaced by a small collection of shell scripts [fish.com].
Post your real name/company so nobody here has the misfortune of hiring you.
Re:Rule #1 (Score:4, Insightful)
2) I respect the nuances and small details of security, even if I'm not an expert.
3) I'm not an expert, I'm at the lowest rungs of IT, and it's taken 3 years to get there.
4) I'm not some asshole faker posting to "ask slashdot" begging someone to help him look good.
5) I know VMS, if only as a hobbyist.
As for whether I could be replaced by a collection of shell scripts, I think you are going overkill. On most days, I could be replaced by a slightly trained chimp. Shell scripts could probably replace 10 of me.
If I meant anything at all by my previous post, it was that this jackass would probably laugh at me too, on any day other than the one he needed to use me to fake skills he doesn't have.
And the old VMS farts will tell you... (Score:5, Informative)
...that on any decent VMS system,
will start a surprisingly friendly hierarchical help menu on "topic". Or don't specify a topic and just wander around the help tree.
Just as "man man" is a useful command to give to Unix newbies, "HELP HELP" is a good starting point for VMS. My first networked machine was a VMS. When I finally moved to Unix, I was so diappointed in the man pages. "You have to type the whole name of the topic? It can't figure it out? Sheesh..."
Like the tagline goes: VMS is a text-based adventure game. If you win, you get to use Unix.
Re:And the old VMS farts will tell you... (Score:5, Interesting)
I'd have to second this guy's recommendation. Several years ago one of my co-workers and I went to what was billed (by DEC) as a beginners VMS class. Once we got to class though, the instructor informed us that the class had been restructured at a intermediate/semi-advanced level. She offered to refund our money or schedule us for another class at a later date. I told her to give us about half an hour and we'd tell her if that would be necessary. The first thing I did was type 'help' (which was how the online documentation was referenced on the MPE systems we were both highly proficient in). After browsing through the help system for a while, and testing out a few simple commands we were able to proceed with the course fairly well.
For a long time I used to think of the various operating systems as different languages that had to be learned in order to make the computers work for you. Over time I've come to the conclusion that they are actually more like dialects of the same language. The most important paradigm (did I really use that word???) to me when working with unfamiliar systems is that on most computers it is demonstratively true that "everything is a file". Learning the equivalent of the 'cd' command and how to view, move, copy, and delete files actually goes a long way towards understanding peculiarities of the given dialect being learned.
With Unix(all flavours), DOS, VMS, MPE, RTE, windows, and several others that don't immediately come to mind, there is a way to use the equivalent of the 'copy' command to simulate the 'cat' or 'type' command to display the contents of a file to your monitor. Knowing how an operating system represents and deals with the various special types of files, i.e., directories, files, programs, and devices, can really help you to get a quick handle on how things are done.
One of the really nice things about VMS IMO is the built-in versioning system. This makes for easy recovery in case of stupid mistakes in deleting/changing files in many circumstances. VMS is a cool OS, but I unfortunately haven't been in a position to spend as much time with it as I'd have liked.
Re:And the old VMS farts will tell you... (Score:4, Informative)
I disagree completely. The HELP command on VMS has good docs written in fairly plain english, and it is easier to browse than man. But a lot of VMS info isn't in the help/message system.
I'd focus on the manuals first, since they actually explain the concepts. HELP is mostly just a quick reference. VMS comes with a CD of manuals in HTML and PDF, and there's a web site as well with those. If you read off a screen faster than off paper, then there you go. I think SYS$HELP: also has txt copies of some docs, if they were installed.
You can also get a VAX emulator to experiment with. CHARON used to have a free version. The project that wrote the free PDP-11 emulator has a free VAX emulator too. You'll need the install sets from the tape or CD and a valid liscence PAK for VMS. If you "borrow" the PAK from a real VAX on your LAN, you may want to avoid experimenting with networking (besides being "illegal" -- gasp!).
As far as learning an OS quickly?
- 4 days isn't enough time. I say 7 to 30.
- Learn the shell and make a quick reference sheet of the sytax/commands.
- Learn the editor and do the same thing.
- Then learn how to customize the editor and do automation. EVE on VMS is underrated. You can write your own commands and maps them to keys, edit multiple files, run DCL from EVE and stick the output in a file, edit ASCII tables in block mode. And you can remap the keys. I have an EVE$INIT.EVE that leave all the standard/default keys alone, but maps all the standard commands like GET FILE to things like GOLD-O, etc. There's also EDT, but I'd learn just enough of it to be able to get out of it.
- Learn how to write scripts. On VMS you have @ and
- Learn how to multitask from the shell. On VMS, the commands you want are SPAWN and ATTACH. The trick is to SPAWN the program with a process name that you pick, the use attach to switch to it. From DCL, you can use DEFINE to map the ATTACH command to a function key. From programs like EVE you again map the ATTACH command to a key to switch back to DCL. Once you get the idea, you can do one-touch task switching between DCL, EVE, pine, lynx, NOTES, and you're own programs. Then VMS doesn't seem like such a typing contest to use.
- Learn the boot process of the hardware and OS completely. FE, on VMS the boot scripts set most of the logicals and symbols. People who don't understand this tend to think they can set symbols ad hoc, then reboot the VAX if there's a problem, and the symbol will still be there. Nuh uh. Sorry.
- Also learn how to "break in" by booting up by an alternate means. If you get locked out of a machine by a coworker or assume duties of a neglected box, it nice to know which manual the procedure is in than having to wonder if you can get in at all.
- Then learn how to find, download, and install freeware from off the net. No matter how obscure a computer may be, someone has written software for it, and someone else has a collection of it on the internet for you to download. You can learn a lot by trying to install new software on an OS. You can also fuck up your production system, so use an unpriviledged account on the test systemaa (after updating your backups first) and be careful. VMS was once the MS Windows of mainframes, and it did have viruses, trojans, and other malware.
- Try installing the OS from scratch, if you can. This is where an emulator rules. It dispenses with the need for a "spare" VAX to ruin, and emulators have feature that allow you to cheat. Often you can pause the CPU and scan memory for strings, or save and restore snapshots of the disk or the entire state of the emulated machine. Then you can try all kinds of reckless and stupid things without hosing the OS (just restore a snapshot). If you wanted to learn NT from scratch, having Bochs, VMWare, or VirtualPC would give you the same advantage.
- Last, learn how to use the built-in commands to write, compile, and run your own binaries. VMS usually doesn't come with compilers unless you buy them (I think) but MACRO assembly is standard. Most wouldn't go that far, but if you really want to learn an OS, learning how to write applications for it opens all the doors. Unfortunately, you really should know all the previous stuff first or you get stuck on simple things. Assembly may sound extreme, but it's absurd how much information you can get from a binary by running it through a decompiler. If you know enough asm to be able to look up what you need to know, then that's enough to get by.
I once had a VMS problem where a W32 client would crash when the user used a "Print Preview" function. A lot of spring cleaning had been done on the VAX to remove what the vendor told us were old, useless files that were safe to delete. Ha ha ha. Fortunately I had installed infozip a while back and zip'd up these "junk" files before deleting them. But there were no log or error messages that told us what was wrong with the client (it just Dr. Watson'd). I used cygwin to run 'strings' on the client exe, and listed in there was a pathname to one of the files we'd deleted. For fun I made an empty file with CREATE on the VAX with the same name, and like that the problem was gone. The client only tested for the existance of that file, but didn't actually need its contents.
I've used the same basic steps to learn several platforms: Macs, Solaris, NT, DOS, Linux, etc. People get superstitious around computers. even experienced people. It'd be no different on other wierd architectures, like an AS/400 or a old 8-bit PC from the 80s. It's mostly just process of elimination.
Consultants... (Score:5, Interesting)
I seriously doubt that you will learn enough in 4 days to be of any use. You will probably slow down the others who do know what they're doing. I would just admit that I didn't know anything about the OS, but would like to work along with the others to learn.
I've always thought consultants were overpaid. This proves it. See this week's Dilbert strip for proof.
Monday [dilbert.com]
Tuesday [dilbert.com]
Wednesday [dilbert.com]
Thursday [dilbert.com]
Re:Consultants... (Score:2)
As a consultant, one thing I can tell you is that there are consultants to do *anything*, not just the kind that "come into your organization and give you a bunch of terrible ideas to mess it up" as in the comics you "cite." The point of a consultant is to get an expert to come in and perform a service no one internally is quite equipped to do.
First of all, I agree that this guy has a terrible approach, grabbing a contract and trying to get up to speed in 4 days. But the perception that all consultants do this, and hence "are overpaid," makes consultant/client relationships extremely sticky, and actually makes a lot of contracts harder than they need to be.
I've discovered that many potential clients treat consultants like used car salesmen: consultants have something they want, but will try to screw them in every conceivable way before giving it up. Especially the idea that we present estimates only to run over them once it's too late to do anything about it, like adding options and hidden fees to a car purchase.
In fact, many clients write extremely weak requirements documents. The initial negotiation and definition of work to be done is the most important part of the process, but here's the thing: they're always in a HUGE hurry and are extremely demanding that we start right NOW. The result is often that a contract is started with vague requirements, at best.
And then people are genuinely surprised when there's been a miscommunication, and the work is more involved than anyone thought. But by that time, they have been so indoctrinated that consultants are out to screw them, that they become inflexible, convinced that "I'm only looking out for myself."
An initial context of mutual respect and an iota of patience to draw up specific requirements would go a long way to smoothing out contract work. There will always be poor contractors like our VMS opeator here, but posts like yours help to generalize the problem into relationships where it really doesn't need to be an issue.
Easy (Score:1)
Oh you are a security reviewer? Nevermind then...
What a relief (Score:4, Funny)
Re:Check out his email address (Score:4, Insightful)
You've never worked for a consulting company. The original poster may have never applied for the job himself. He was 'asked to assist'.
I was often bid by my company for contracts in environments in which I had little or no experience. Usually the client knew this, and didn't care because you were (a) on a very low rate and (b) contributing other skills as well. Generally this situation applied to employees who were recent graduates and new to the workforce.
On the whole it worked well enough, except those times the marketing people put you in somewhere having described you as having 'guru' level status for some technology that you saw at a demo once. Bastards.
Focus on the code. (Score:3, Informative)
You can not learn enough about an OS to consult on its security, and if I'd hired you to look at my systems and later found out you hadn't even been on them a week prior, I'd likely turn around and sue you pantless.
If strictly looking at code or similar is your plan, and you're only worried about being able to navigate the system enough to look at source, I'd suggest looking at the little intros that are part of any college coursework involving the OS. Chance are you can find all kinds of class notes and course workbooks with Google.
Actually... (Score:5, Informative)
I do touch the tech often enough that I'm helping out the VMS guy. Mostly, that'll mean doing his documentation for him when he's done his testing. I just want to be conversant enough that I won't be a time suck while I document everything. As for learning, I find I don't know what to ask the sys admins if I don't know anything about the OS. Even when I know the system, I play dumb... it's just going to be much much easier to play dumb for VMS.
Basically, I could go in to this and not know a thing about VMS and it wouldn't really hurt my ability to do my job. However, that's not the way I like to do things... I handle processes and policies but the more I know about the client...
Re:Actually... (Score:2)
Thank Ghod for that!
I do touch the tech often enough that I'm helping out the VMS guy. Mostly, that'll mean doing his documentation for him when he's done his testing. I just want to be conversant enough that I won't be a time suck while I document everything. As for learning, I find I don't know what to ask the sys admins if I don't know anything about the OS. Even when I know the system, I play dumb... it's just going to be much much easier to play dumb for VMS.
Your best bet to learn about VMS is to ask the VMS guy. You will be a time suck, but it is better asking him what he means than trying to learn some random stuff about VMS and getting it wrong when doing his documentation. (Why are you doing his documentation btw? He should do his own documentation, especially if you are not fully conversant with VMS.) Learn what you can from the VMS guy, that should give you enough insight into the general feel of VMS (quite a nice OS) to be able to start asking the right questions.
What do you want to do with VMS? Do you want to know about administrating a VMS system, general user stuff, in depth technical info, security, etc... Maybe you should just look into the history and general overview of VMS in the few days you have, then when you have a specific task in mind try to find out how to do that.
Basically, I could go in to this and not know a thing about VMS and it wouldn't really hurt my ability to do my job. However, that's not the way I like to do things... I handle processes and policies but the more I know about the client...
As I suggested above, just try to learn some history and background about VMS. When you need to do something in VMS, then ask someone who knows VMS to teach you specific tasks.
Translate (Score:3, Insightful)
Still, it is a handy, if imperfect, reference if you mostly use one of [Windows, *nix, Netware, Macintosh, MSDOS] but sometimes need to recall how to do something on other than your primary OS.
Re:Translate (Score:2)
At my new job.. (Score:1)
In little after the first 3 days I was confident enough to take on any problem, and even offer advice to others in my class/the teachers. I was surprised how I caught on so fast, OSX was a breeze since it is Unix based.
Re:At my new job.. (Score:1)
Re:At my new job.. (Score:1)
"Mac Basics"
is what it was called.
History of the mac, common functions, blah blah. TCP/IP networking, twas interesting.
The class was meant to teach the laymen how to troubleshoot the mac and use it.
Find out what VMS uses for grep and... (Score:3, Funny)
grep "Here's where the buffer under-run starts" *.c
Do it The Matrix way ... (Score:4, Funny)
Re:Do it The Matrix way ... (Score:2)
Well, someone around here has certainly been popping a pill, but I'm not sure it was the original poster... :-)
easy. (Score:3, Funny)
mistitled? (Score:3, Funny)
shouldnt that be Learning an Old OS... ?
First (Score:1)
check the Rosetta Stone (Score:5, Interesting)
Re:check the Rosetta Stone (Score:2)
DEC or non-DEC, I don't think expanding one's Unix knowledge is the fastest way to learn VMS.
Re:check the Rosetta Stone (Score:3, Funny)
Some information on VMS (Score:4, Informative)
The site is very insightful.. and I think it can be read through in a couple of hours. =)
DeathRow OpenVMS cluster (Score:3, Interesting)
You can connect with telnet of SSH.
The best way I learn... (Score:2)
I've learned a lot of things that way. I probably haven't learned them correctly or as well as I should but it has helped.
Good luck to you!
On a more related note I do remember a very good resource on VAX/VMS security. I can't find it now but it was along the lines of how to hack a Vax. it outlined a lot of security issues and how it differs from the Unix world.
I recommend.... (Score:1)
If your local bookstore for some reason is out of stock (as the book is one of their top sellers), try SAMS Press' "Teach Yourself VMS in 24 Hours".
You won't be disappointed...
Re:I recommend.... (Score:1)
http://www.openvms.compaq.com/dummies_book.html
And I thought I was being sarcastic... :'-(
Read these. (Score:2)
VMS is easy (Score:4, Informative)
VMS is really quite similar to Unix-y OS's. What really flipped the switch for me was the how to pass parameters to the commands in VMS.
This page has helped me the most. In fact I have a print out taped up in my cube for easy reference.
http://www.physnet.uni-hamburg.de/phy
Dont get discouraged by some of the long commands. As long as you have the unique chars it knows what you mean. The command DIRECTORY is shortened to DIR.
Also the man equivelent in VMS is the HELP command. The help docs are complete and very well done.
The other trick to learning VMS fast is to know the directory syntax. Instead of #cd
On a side note, stay away from the VMS to Linux HOWTO. It has *very* little helpful info, except for the first few pages that show the related Linux commands.
Re:VMS is easy (Score:2)
Re:VMS==COBOL? (Score:2)
Why such long command names? You'd think they could at least truncate the command DIFFERENCES to something like DIFF (or, if that's too unixy, DIFFS), DIRECTORY to DIR, etc.
Re:VMS==COBOL? (Score:2)
Re:VMS!=COBOL? (Score:2, Informative)
backwards (Score:5, Informative)
You've got this backwards. Security requires more indepth knowledge of the OS than development. If they've got you doing security reviews for a system you don't know how to use, I'm sure there are a few hundred script kiddies around who'd love to know who you're doing this for.
Re:backwards (Score:1)
How many scripts are there out there to exploit VMS holes?
Re:backwards (Score:2)
The way I do it (Score:1)
I spose what I am getting at is once the pressure of breaking something that some one else is relying on is removed, I can discover and learn at my best.
As a secondary, these things may help
- someone who knows and can spare the time for questions they think are dumb
- a good book, or good web site or other reference that someone who you trust to know the OS can recomend.
- Mailing lists, and mailing list archives;
Remember: All OS's do the same thing: Make the hardware useful - but then you did say you were using VMS
-Idiot
(PS: thanks again Jules for getting that Solaris box booting multiuser again
Re:The way I do it (Score:2)
While exploring the system I discovered a few commands which I could not execute because of insufficient rights, but they did run at least long enough to tell me that fact.
So I went looking for them to see what else I might find that I wasn't allowed to run and discovered that there was a whole section of the system where these executables were stored that I couldn't see unless I knew the full name of the file.
(You can see where this is headed...
I wrote a little script to iterate every combination of characters for file names up to ten characters long (figured that was long enough to get at least a few things).
The problem was that the script was a recursive loop and the kernel would attempt to optimise loops on execution. And there was a bug in the task-switcher that wouldn't let it service other tasks until the optimisation process was done.
So the system came to a screeching halt as it figured out 260,000,000,000 file names!
Watch someone, then jump in and play with it (Score:3, Insightful)
After that, just make sure you're not on any important machine when you start experimenting with your new knowledge, and play around with it.
I've never used VMS, but then again I've never read any books on DOS and (would think) I'm still pretty damn good at the CLI bashing (esp. under NT/2k), so I reckon second hand knowledge is better than any book.
Are you in New Jersey by any chance? (Score:2)
Heard they were bringing in a couple of "highly skilled VMS security consultants" for a security audit. Hell, with four days worth of reading you'll be better than the idiots we have now (at least you've proven you can read...)!
Looks Weird... (Score:1)
Of course, I learn a new trick with Unix every day, so you're most likely screwed. Joking...
Links (Score:5, Informative)
Anyway VMS security is nothing like Unix security. Oracle or NT security is much closer to the security model. VMS admins don't tend to modify the base systems very much and VMS is very secure by default. So I wouldn't be looking for Linuxy holes like the equivelent of "sendmail" exploits. The real problem you'll have is finding out which users can elevate privledge, and privledges that in combination can give them a great deal of authority.
In my experience the hole that VMS guys tend to miss is this: Unaudited program gives the author the authority of the user running the program. So if Joe submits changes to the "update accounts file" and update accounts runs as a system operator on the production box then Joe has system operator permissions unless someone is checking his code carefully. Unix guys tend to see this as obvious VMS guys tend to miss this since Joe may not officially even have a log in ont he production box.
is this a joke? (Score:3, Funny)
someone that doesn't know squat about vms, and has 4 days to learn says:
i have no idea how to even respond to that. if taking this job was your idea, i'd suggest to get into som other line of work (like sweeping streets). if someone you work for put you on this project, i suggest you explain to them why this is a bad idea. this may require the help of a large hammer.
I hate to burst your bubble. (Score:2)
I know jack about AS/400, I know I could probobly be a proficient user in 4 days, and maybe even a relativly good admin in a few weeks, but to feel like a did a good job securing it would take a lot longer.
This is someplace where it actually is a good idea to pay a consultant a ton of money. Specialized skills (like VMS these days) are hard to come by. A consultant who specializes in vms will have the experience to help.
That is, unless you have a member of your team who knows what they're doing allready. An extra set of eyes with a fresh perspective, and a good understanding of the existing use of the cluster will help the experienced (and maybe slightly complacent) vms guru with his/her job.
Immerse yourself (Score:1)
Of course, realistically speaking no one is going to gain any significant mastery of something like VMS in just a couple of days. Especially if you're working on a security project where the people you're up against (i.e. blackhats and evil-doers) have probably spent enormous amounts of time uncovering obscure holes and configuration problems.
And, as a previous respondent said, tear yourself away from
For Clarity's Sake (Score:5, Informative)
Second, by security reviews... I should have been clearer... not securing the boxes on any kind of code or OS level... if the sys admin isn't doing his job I'll never damn well know. I'll be reviewing security policy. Who has authority to sign off on new user accounts? Has this person signed off on new user accounts? What is the process for notifying the sys admin to remove an account? Has everyone who's departed the company had their account deleted? This is the kind of security review I'm responsible for. I also look at who has the ability to actually walk up to the box. I assess adequacy of the security physically getting into the server room.
I'm not totally stupid. If they wanted me to actually touch a keyboard on a machine who's OS I didn't know - I would tell them to find someone else. (Hell, because of the nature of what I do, I'm reluctant to touch the machines I do know.) I try to learn as much as I can before I go in because that is the way I prefer to work.
There are people in my shop who wouldn't know a shell script from a hollywood script and they can do the same job I do and do it competently. I just like to know as much as I can about the system.
And so far the best suggestions have been to read the online stuff and not sleep... already doing that. (Avoiding
From an old fart who has used VMS over 20 years (Score:3, Informative)
The main point is ensuring that accounts can be tied to users (as that is what gets audited) and that unlike Unix, you may have many system administrators with individual accounts. VMS also supports the concept of Security Administrators as separate from the System Administrator.
What you are looking for is documentation on who can do what and who approves it. For various reasons, it is a good idea to keep users or at least their rights identifiers around for a long time, even after users have left. It is better to disable the user until you are certain that their rights identifier is no longer in the system.
As with many systems, an OpenVMS console can be used for breaking into the system. However, it can be secured in such a way that bypassing security is extremely difficult.
Free account on a VMS machine (Score:4, Informative)
is available here:
http://www.thevax.org/ [thevax.org].
It's a free service run by hobbyists.
HTH,
JP
Errr... (Score:2)
Second of all, *why* are you going along on this one? There have to be *zillions* of old VMS junkies that are out of work that are very competent at this.
Seek good documentation first. (Score:3, Informative)
VMS Documentation:
http://www.openvms.compaq.com/doc/
VMS OS Documentation:
http://www.openvms.compaq.com/doc/os731_index.html
Look in particular at "OpenVMS User's Manual" for starters, then "OpenVMS System Manager's Manual", and "OpenVMS Guide to System Security".
VMS security is fairly fine-grained and the OS is pretty secure by default provided people (and processes, eg backups) are granted privileges on the basis of the minimum needed to perform their work, and passwords for the really dangerous accounts are kept under tight control (place I used to work had the password for the all-powerful "system" account in a sealed envelope in a safe). Oh, and if you have physical access to the system console then there are alternative boot modes which can override all the OS protections. They're well-documented.
System Management:
http://www.openvms.compaq.com/openvms/system_manag ement.html - though at first glance this looks to be more a "here are some fine extra products you can buy to help you" page than detailed technical information.
More VMS Documentation:
http://www.openvms.compaq.com/wizard/openvms_faq.h tml
Yet more VMS Documentation:
Type "HELP" at the command line.
Notwithstanding your clarifications of what you'll be doing, good luck.
Guide to System Security (Score:2)
You're totally screwed (Score:1, Troll)
I've never used VMS, but I'm completely sure it's a system with its own quirks, security features and comon configuration errors that result in security problems.
My own opinion is that when possible I'll never get into this situation. I can and do admit I don't know everything, and if possible would try to get out of a situation when I'm pretty sure I won't be helpful. If you can't do that I think you should try to find a guru who'll give you some basic knowledge. But I still think that in 4 days you can't learn much about security.
VMS? boy are you in for it (Score:2)
However, development-wise, the DECWindows debugger is quite good, as are the compilers (though watch out for symbol name lengths on older DEC C compilers).
When it comes to learning one's way around a new OS in general, I've either muddled through over a period of weeks or volunteered ^_^ a mentor onsite and pestered them with hopefully intelligent questions. (Nothing you can find out from the online HELP, in other words.)
Be honest with the person ... (Score:2)
With that said and you still feel compelled to do this then hopefully you have a major strength in some other OS (say NT-like OSs). If you know a lot about OSs (in terms of theory) you know that they function pretty much the same way. They operate the system. The ways that they do this may be different, but the same functions must be accomplished. A OS expert can pick up new OSs really quickly because they have a deep understanding of what an OS is suppose to do and how they relate to the computer system. If you are that kind of person, it's just a matter of learning new command keywords and command line syntax. If you are not that kind of person, you would never be successful in securing any operation system VMS or otherwise.
Easy (Score:2)
Once you've got them I'd recommend telnetting on over to Manson [vistech.net] which mercifully for those of us who don't have access to our own Vax will let you play around with a guest account.
VMS feels a LOT like DOS though. If you're comfortable with DOS you can pick up the basics of VMS in a few hours.
Emulator (Score:1)