Programming Languages on OpenVMS

Looking at OpenVMS administration, and investigating the possible languages to use on OpenVMS, there are many options – some supported by HP and some community open source options.

One of the first options is Perl; apparently Perl was originally designed as a way to write scripts that worked under UNIX and VMS both. Bernd Ulmann wrote an article for OpenVMS Technical Journal 13 about Perl on OpenVMS and gave a presentation on it in the spring of 2009 at an HP Connect OpenVMS Meeting (English translation) in Germany.

The HP version of Perl appears to be tied to the Secure Web Server (SWS) but it can stand alone.

Another language that is growing on OpenVMS is Java. Jean-Yves Bourles and Thierry Uso wrote on Java and OpenVMS in OpenVMS Technical Journal 10. Netbeans is available from HP to facilitate Java development on OpenVMS.

With Java available, that opens up the possibility of perhaps using a language that runs on the Java JVM as well. That brings to mind JRuby, Jython, Groovy, Scala, and Clojure. Information on most of these is rather scarce unfortunately; only Scala and JRuby have ports (both by the aforementioned Thierry Uso). Personally, these two are the most interesting to me; Scala has unmatched integration with Java itself as well.

Python is also available. Python seems to be the new administration tool of choice; at least, Red Hat seems to think that way.

As part of the Secure Web Server (SWS), you also get HP’s version of PHP. However, this does not seem to be a separate product as Perl is, and there is no description of using PHP as a scripting language (which you can do by running PHP against a file from the command line).

Lua is graciously made available for OpenVMS by our friends over at Hoffman Labs. Lua is a fantastic scripting language that doesn’t get the cover that it deserves.

Lastly, Tcl/Tk is available as well.

So which do I recommend? Well, Perl, PHP, and Java are all HP supported products, so one could start there. With Java, I see Scala and JRuby being fantastic languages as well, although they are not supported by HP. Lua is also a favorite of mine; an OpenVMS version is wonderful; however, Lua is not as widely available for other platforms as is Perl and Java.

I should mention that PL/I is still active on OpenVMS; it is commercially sold and supported by Kednos. PL/I was an interesting language, but it doesn’t have modern capabilities.

At the German openvms.org site there is also a big list of OpenVMS ports (including languages).

Are you ready for programming on OpenVMS? I am!

Watch Out! Using SFTP to Transfer Files to OpenVMS…

The HP ITRC Forums has a thread on problems transferring files to OpenVMS using SFTP. The symptoms were that transferring files to OpenVMS would result in a corrupted file.

The problem’s cause was rather insidious: due to the way file versioning works, the new file inherits the old version’s attributes, which could be incompatible with the UNIX file format. When this occurs, the result is a corrupted file.

The fix is to convert the file attributes to StreamLF. Steven Schweda recommended this utility:

$! 12 December 1999. SMS.
$!
$! CONVERT a file to StreamLF record format.
$!
$ convert 'p1' 'p2' /fdl = sys$input:
RECORD
FORMAT stream_lf
$!

Steven also suggests this utility, which finds all files that are non-streamlf – with an optional parameter specifying files to look at:

$! 9 November 2006. SMS.
$!
$! Find non-directory files matching P1 which are not
$! Record format: Stream_LF.
$!
$!
$ if (p1 .eqs. "")
$ then
$ p1 = "[...]*.*;*"
$ endif
$!
$ file_old = ""
$ loop_top:
$!
$ file = f$search( p1)
$ if ((file .eqs. "") .or. (file .eqs. file_old)) then goto loop_end
$!
$ file_old = file
$ if (.not. f$file_attributes( file, "DIRECTORY"))
$ then
$!
$ rfm = f$file_attributes( file, "RFM")
$ if (rfm .nes. "STMLF")
$ then
$ write sys$output "''rfm' ''file'"
$ endif
$!
$ endif
$!
$ goto loop_top
$!
$ loop_end:
$!


The rule is: when working with UNIX files on OpenVMS, create a streamlf file first! This will prevent corrupted files.

New Releases: Fedora 13 and Slackware 13.1

Two brand new Linux distribution releases: the Fedora Project releases Fedora 13, and Patrick Volkerding (et al) releases Slackware 13.1.

Fedora is, of course, the proving ground for new features for Red Hat Enterprise Linux, and contains cutting edge technologies in its releases. Fedora releases are always available at http://fedoraproject.org/get-fedora.html. Fedora 13 (Desktop) CDROMs are available for ix86 32-bit and ix86 64-bit. If you’re looking for a different “spin” – such as a different desktop or specialized for a particular purpose – be sure to check out Fedora Spins. For system and network administrators, the most interesting is probably the Fedora Security Spin.

If you don’t want to try the cutting edge Fedora, try the next generation of Red Hat Enterprise: Red Hat Enterprise Linux 6 Beta 1.

Patrick Volkerding, the driving force behind Slackware from the beginning, announced release 13.1. Slackware is the oldest Linux distribution out there, and perhaps the most “BSD-like” of any of them. One doesn’t hear about Slackware servers nor about commercial support for Slackware servers, but it’s certainly a viable alternative if you’re able to choose anything you like. Downloads for Slackware are available at all the mirrors; the site lists USA mirrors here.

Slackware (as driven by Patrick) doesn’t run on multiple architectures, but folks have ported Slackware to other processors such as ARM, SPARC, IBM S/390, and Macintosh PowerPC. However, the ARM port seems to be the only current one; the others have fallen behind.

If you’re serious about using Slackware (sometimes called “Slack”) check out the SlackBuild repository; they offer scripts that will help you consistently build your software for Slackware.

Red Hat Enterprise Linux 3 Approaches End-of-Life

Red Hat Enterprise Linux 3 will be end-of-life on 31 October 2010 (about six months away). Red Hat gives details about their product lifecycle on their web site.

RHEL 4 will reach end-of-life on 29 February 2012, and RHEL 5 will reach end-of-life on 31 March 2014 – so for them, there is several years left. The CentOS distributionCentOS distribution has CentOS 4 and 5 available for download – CentOS is an open source build of Red Hat Enterprise Linux.

RHEL 6 entered beta a little while ago, and is available for testing. CentOS 6 does not seem to exist yet.

Refining and Perfecting Your To Do Lists

What could be easier than a checklist? Before answering, consider that aircraft manufacturers spend years getting the checklists for their aircraft ready, and have entire divisions dedicated to checklists.

The answer, it turns out, is not so simple. Atul Gawande wrote a complete book about it: The Checklist Manifesto. This book is a very good read, and will change how you look at checklists.

Recently, Sarah Welch and Alicia Rockmore had a post over at the Clutter Control Freak Blog about Effective To Do Lists.

What makes a To Do List – or checklist – effective?

Everything in one place. This way, you know where to find what to do next. Don’t have multiple todo lists.

Update frequently. If things are missing from your todo list, then you won’t refer to it – or if you do, these things to do will be forgotten.

Access daily. Refer to the list every day – preferably first thing in the morning. If you do this, then you’ll be able to keep up to date with what is going on and what needs doing.

Write down actions. Don’t put big projects into your to do list – write down only actions that can be done. For example: “Get tires” is too big (unless all you have to do is go get them). Where will you go? Will you call many stores to compare? What size will you get? How many?

Revise often. Perhaps the things that are on the list are no longer to be done; remove them from the list. Your list should be current at all times.

If you keep your to do lists “alive” and active, then your ability to act on them increases and you can get a lot more done.

BGP Still Contains 20-Year Old Insecurities

According to an article from the AP, BGP (Border Gateway Protocol) still contains weaknesses that could result in widespread loss of Internet connectivity.

The article spends an inordinate amount of time explaining that this has already happened in certain areas for other reasons, and only discusses BGP briefly (relative to the rest of the article).

It is, however, a real problem. Current protocol changes (to improve security) include a wide range of protocols: DNS-SEC, SNMP v4, SMTP (with message submission and encryption), POP3S, IMAPS, and others. Even IPv6 involves changes to increase security.

It is unfortunate that the routing backbone of the Internet is still suffering from reliability problems after all these years – even after the president said that fixing it was top priority.

The problems go beyond just security, but stability and scalability as well. Is it time for a replacement or redesign of BGP?

Is Your Data Center Power and Cooling Truly Safe?

Recently, Amazon has made the news for several unrelated outages at different data centers. The causes of these outages are very interesting, and provide a lesson for the rest of us.

The most recent affected Amazon EC2 users on 13 May. This outage was caused when a cutover from the loss of utility power failed: a switch failed to activate as it should. To make matters worse, the switch failed because of a misconfiguration that was done by the manufacturer.

This outage is compared to a similar one that affected Rackspace in 2007. During a power outage from the utility (because of a car crash), the power went on and off a couple of times, preventing the cooling apparatus from cooling the data center properly. With the rising heat in the data center, they had to shut down equipment or suffer equipment failure.

Another power loss affected an Amazon data center on 4 May (twice). The day was to involve a switchover from one power substation to another (from the electric utility). During this process, one UPS failed to cutover to the backup generators, resulting in an outage to a number of servers. Later that day, after bypassing the failed UPS, human error caused one of the backup generators to shut down, taking down servers once again.

One of the biggest problems in resolving these problems is money. Until something like this happens to a company, many do not want to put forward the money that it would take to avoid such outages.

What would it take to avoid outages like these? The assumption will be that power outages will occur and colling will fail; how do we handle it? How do we increase reliability?

• Don’t rely on the UPS to save the data center. Use multiple UPSes or put each rack on a racked UPS.
• Cluster multiple servers together across data centers in an active/active configuration so that downtime in one data center will be mitigated by another.
• Pair administrators or team members together to reduce human error. Studies show that the worst evaluator of our own capabilities is ourselves (“We have met the enemy and he is us.”)
• Make sure that cooling devices can run on backup power. Also verify that cooling devices will run long enough to shut down servers if necessary.
• Investigate alternative cooling sources, such as external air, or “rack-local” cooling that could run off of UPS power.
• Don’t trust the manufacturer. Nine times out of ten things might be just fine; that leaves a 10% failure rate. Shoot for 100%!
• Remove all singular paths of failure. What if a UPS fails? What if an air conditioning unit fails? What if the power fails?
• Test before things happen! Do you have complete protection from power failures? Test it. Do you have complete protection against cooling loss? Test it.

Even smaller companies with a single on-site data center could take advantage of some of these options without breaking the bank. Clustering many servers with an external data hosting site could be done, or a company could partner with a related company for an external server hosting site.

To save labor costs, one could extend the time needed to complete the tasks without adding any more staff to the project.

One other thing that could be done for reliability’s sake – but is probably cost prohibitive for all but the most voracious and deep-pocketed corporations – add a second power link from a different substation and different links. Power goes “out” from one substation, the other substation will continue to provide power. (Not sure that is even possible…)

Note that monitoring does not take the place of testing. There is a difference between knowing that the data center is without power and preventing the data center from losing power.

System checks do not take the place of testing. The UPS might claim to be working fine – do you trust it? Perhaps it will work just fine – and maybe not. Perhaps it will work, but it is misconfigured.

Test! One of my favorite stories about testing has to do with a technical school that provided mainframe computing services for students and faculty. They tested a complete power cycle of the mainframe each month. One month, they went through their testing, rectifying whatever needed rectifying as they went. Two days later, a power loss to the entire school during a thunderstorm required an active restart of the mainframe – without incident.

Would that have been as smooth without testing? I doubt it.

How to Lose Your Life to the Law

Recently, the blog Gizmodo received a pre-release version of a new iPhone, and examined it and wrote about it. This caused Apple to request it, then a flurry of legal actions (including search and seizure) by the government.

What no one has wrote about is how this must have brought the reporter’s life to a complete standstill, with a loss of practically everything he uses and everything he knows. Consider what was taken from Gizmodo reporter Jason Chen:

• A Samsung digital camera. How many photos were on it? Family photos? Friends, events, etc.?
• Three Apple laptops and an IBM Thinkpad. How many articles were on them? How many emails? How many documents that Jason was working on?
• An HP Mediasmart server. How many songs?
• An external hard drive and several USB thumb drives. How much data was on these drives? Finances? Sources? Records? Insurance records? Health details?
• An Apple iPad. How much was this being used? Did it contain important parts of Jason’s personal life?
• An Apple iPhone. This would have had an address book, phone numbers called and received, and more.

In short, the officers of the law seized Jason’s entire digital life – for a sort of extended search in absentia.

No word on whether online services were served with warrants. Not only is the search warrant executed on Jason Chen sealed by the court, but the request to seal is also sealed. Thus one doesn’t know what they were looking for, nor why it is supposed to be secret.

So what’s the answer? The only answer is a change to the laws of the country or personally hiding and squirreling away your data. About the only thing to do in this day and age is to put your data onto a server which is in a country with excellent privacy laws, like Switzerland – the way Neomailbox has done with email. If this concerns you, you should check out the Surveillance Self-Defense site sponsored by the Electronic Frontier Foundation.

Drunk or Tired? No Difference!

As system administrators, the occasional all-nighter is necessary to fix things that go wrong. We also know that the majority of errors can be traced to human error – including those that affect server stability.

A recent article equates a lack of sleep to being drunk – specifically, a 24-hour wake cycle is equivalent to a blood alcohol level of 0.1. This is not good – not at all.

If we consider this fact, and expect that mistakes are very likely after 24 hours of being awake, then we must act. What can we do as system administrators when we work an all-nighter?

• Take a nap. A small nap – from 15 minutes to an hour – can revitalize you and help you to minimize errors.
• Have a coworker check your work – or work with you. Having someone to check your work will make a finer net whereby each of you can check the other’s work.
• Take an extended nap or sleeptime. For example, take off the day of an extended maintenance schedule – or go to sleep at the end of the day and wake up hours later for maintenance (if it is scheduled for late at night).

In short, it is primarily about getting enough sleep. Finding ways to minimize errors or catch errors is good, but never as good as getting enough sleep in the first place.

Oracle Continues to Withdraw Sun Support Access

A couple of days ago, Techbert noted that Sun firmware downloads were no longer available from Oracle. This is just one more way that Oracle has been withdrawing from Sun’s traditional open stance.

Oracle already has stated it would not be putting all new technologies into OpenSolaris, and that it would provide support for all Sun servers in the (customer’s) data center or none at all.

The entire character of Sun’s offerings has changed, and for the customer, not for the better.