...is true, then it was created today. If false, then it was created before today. Note there are 3 blank spaces before the "1" in quotes, and you can change that to any number you want (right-justified in a 4 character field). Want to check if the file was created in the last week? Use " 7". Last 3 weeks? " 21" (two spaces). And so on...

"Tomorrow" translates to midnight, tonight. "CDT" is the Creation Date and Time of the file. The delta time will always be a positive value (unless you've got a file created in the future, which Analyze/Disk/Repair should fix for you!) Using the text string delta time returns, you can actually test to see if a file was created within the past 'delta time', by changing the "Tomorrow" to the null string, "" (i.e., the current time), and change the right side of the comparison to a complete delta time spec (e.g., " 0 12:00:00.00" for within the past 12 hours.)

One final caveat: you'll need OpenVMS v8.x for f$delta_time to understand "Today", "Tomorrow", etc. This was not supported in 7.3 -- you needed to use f$cvtime to convert the relative descriptors to a valid time spec. So there is a circumstance where you'd have to jump the f$cvtime hurdle. I'd say "live with it", but you really should upgrade!

Cool, huh? Well, I think so...

It was 1992, and inside Digital, we were ramping up for deployment. Lots of meetings and presentations, demos and documents were making their ways across the country and around the world. This was the time when Alpha was called "Alpha" -- not the product name, but the Internal Use Only project name.

Engineering was in charge, and strongly favored the Alpha moniker for the actual product name. They created a logo and started sticking it on material, from documents, to t-shirts (more about that in a future "My Digital Collection"), and even coffee mugs. Like this one, which I was fortunate enough to get during one of the many training classes I went to.

Then came Digital's infamous Stealth Marketing division. They didn't like the name, nor the logo. Everyone knows about how "Alpha" is too generic a term and not trademark-able, so they came up with "AXP". Which turned into "Alpha AXP". Which turned into "Alpha". But this logo was considered too busy, too complex, and had too many colors. It wasn't "cost effective" to reproduce, because it would take at least 3 colors to print.

So before Alpha, before Alpha Generation, or Alpha Powered, even before Alpha aXP, there was this Alpha logo.

I've always thought it was the coolest of the lot.

Avram Miller was the project manager for the DEC Pro 350 PC back in the early 80's. While the interview was interesting to listen to, I found myself poking around his blog. There, I found a real gem, in an article entitled Digital Equipment Movie about the Professional Computer Series, 1983. This previously unreleased video, Personal Challenge, (43 minutes) documented the birth of the DEC PC family, specifically focusing on the Pro 350.

Avram said he found the video embarassing, but I found it fascinating. While it was done in a typical 80's style, it was still a fascinating look at the inside of the Mill, at a lot of the design facets of the computers, and the prep work done for the unveiling. It was a great flashback for me, seeing the engineers sitting at a Catia workstation, working off hand-drawn circuit diagrams, and wire wrapping prototypes!

It was also cool to see the announcement of All-In-1 as a footnote to the Pro launch. Too bad both are now footnotes in computer history, and that wound up setting the sensation I took away from this movie: a touch of melancholy, for a day gone by, a lot of hard work by a lot of remarkable people, and a lot of squandered talent.

Thanks for posting the video, Avram.

To start off with, I'll go with my favorite item: my stoneware coffee mugs. I've got 4 of these; I use them every single day and they don't have a single nick.

But today, I wanted to be able to print from my home Hobbyist AlphaServer.

This printer is connected to my network via dedicated LinkSys WPSM54G, a wireless print server designed to work with multi-function printers. The latest release of firmware (1017) for the WPSM54G added the ability to print via port 9100, LPD, IPP, and even email (at least in theory). It should be noted that port 23 is open, too, allowing simple monitoring of traffic through the server.

My initial tests using DCPS v2.4 and IP_RawTCP on port 9100 proved futile, as it turns out that the print server does not allow bidirectional communications, which is essential for proper DCPS functionality. No problem, I switched to IP_LPD (the queue name is "raw", for a complete spec of "IP_LPD/host:raw") and things got a little bit better -- the LED on the printer started flashing. But still, no output.

A quick check of the printer settings allowed me to enable the printing of Postscript errors. Resubmitting my print job resulted in a page output with the error "OFFENDING COMMAND: papersize".

The closest thing in the DCPS System Manager's Guide was a reference to the logical DCPS$Sheet_Size -- not PAPERSIZE. The status page from the printer showed the default paper size was set to LETTER, the same as the default contents of the DCPS$Sheet_Size logical -- this wasn't helping. The only other reference in the LPD troubleshooting section 11.2.1 of the manual was for DCPS$queue_Product_Name. Since the HP LaserJet 3050 wasn't in the list of supported printers for v2.4, I defined the logical as "HPGENERIC", restarted the queue, and felt a bit of satisfaction when the printer successfully printed out a test .com file, with all the pretty DCPS formatting!

In summary, I'm able to print from OpenVMS to a USB-connected HP LaserJet 3050 via a 802.11n wireless D-Link router connecting to my 802.11g LinkSys printserver, with most of the regular DCPS functionality. If that's not a convoluted path to go 8 feet, I'm not sure what is! Now to see if I can print from my MacBook...

I found that there's plenty of documentation (well, if you can count as high as 1) for the CDRecord.com procedure (specifically, @CDRecord Help), but not much on actually using Sys$System:CDRecord.exe, and practically none for using that to burn what's commonly called an ISO image file.

But I think I've figured out how.

First, you need to translate the name of the device you're using into numbers. I could go to great lengths to explain how to do this, but it's like Prego -- "it's in there". Just use the .COM file to retrieve it with the INQUIRE command:

 $ @Sys$Manager:CDRecord Inquire DQA0:

If you're indeed using DQA0: for your burner, you'll see a couple lines that looks like this in the morass of output:

 scsidev: '52,0,0'
 scsibus: 52 target: 0 lun: 0

And the first of the two is what you need. There. Presuming you've got your .ISO file ready to go, the hard part is done. Do the following to do a test burn with the laser off:

 $ MCR CDRecord -dev=52,0,0 -dummy PF_CCOUGSYS0429.iso

and leave the '-dummy' off to do a real burn. Hope this helps someone who's trying to figure out why they need a PC to burn an ISO-9660 CD, when they've got a burner on their VMS system!

$ Set Device /Reset=Error_Count  

$ Analyze /Media /Exercise=Full

$ exit 2928

The trick here being that you need to include the 0 (zero)! f$fao("!%D") is nonsensical!