3 ms·

Ahh the memories. At my first proper job, we had a 8 node VAXCluster running Oracle 7, VB3 clients on Windows 3.1 on Compaq and DEC machines, Motif clients on

Ahh the memories. At my first proper job, we had a 8 node VAXCluster running Oracle 7, VB3 clients on Windows 3.1 on Compaq and DEC machines, Motif clients on Solaris 2.4 on SparcStations :) The VAXCluster had 100% uptime for 4 years when they killed it and replaced it with Alpha machines.

excuse-me 14y ago
I remember DEC sending out a fix for the "day 10000 bug". Some system counter would wrap around if it was up for 10000days (27years)! Compare it with the Windows95 49day bug that nobody ever reached.
- Hoff 14y ago
  Some DEC code for OpenVMS had been converting variables containing times using the Unix epoch date to and from the OpenVMS-format dates* using the LIB$ LIBRTL calls, and the LIBRTL calls had a documented format limit of 9,999 days. When 19-May-1997 rolled around, you needed to use a different conversion sequence for your Unix epoch dates, or to have applied the then-available LIBRTL 10K Delta Time patch that extended the permitted day field. More to the OP's point, the longest continuous OpenVMS server uptime I'm aware of was around seventeen years. The downside of that being seventeen years of unapplied patches. *VMS uses 17-Nov-1958 as its base date; that date was chosen to match the date commonly used by the Smithsonian Astrophysical Observatory
  - excuse-me 14y ago
    Actually "1858" - the base for Modified Julian Days. Although ironically MJD was invented in around 1958 to cope with a computer limitation. vms is also famous for having one of the system time settings specified in "micro-fortnights"
- tytr 14y ago
  Yet people criticised the VAX. I guess every computer has its flaws (nothing is perfect!), but was the criticism of the VAX justified? (Assuming uptime and reliability means anything, and compared to what followed it. Windows NT? C'mon.) It is just one more bit of evidence that tells me that many of the supposed "experts" on matters of computing are anything but. There's FUD and then there's just people who just have no idea what they're saying. (Of course the CEO of DEC got caught making the dumbest comment ever. No one is immune.) Maybe we should just focus on results and not what people say?
  - excuse-me 14y ago
    VMS is different from UNIX. VMS is like a mini-mainframe. You aren't supposed to play with it, you get given specific permissions by some operator, you do as you are told, you don't mess around. And you do things the VMS way. If you want to know the VMS way there are 100ft of grey manuals on the shelf telling you. Unix has a play with and enjoy the jokes philosophy. In my experience VMS people hate Unix more than Unix people hate VMS
    - gouranga 14y ago
      I remember having to shift those manuals to a skip when we replaced the VAXCluster with SQL 6.5 (bad bad bad decision othe than for electricity usage!)... I didn't remember much hate between the UNIX/VAX people in my org as they were pooled together. I think everyone agreed that VAX/VMS was superior though when it came to getting stuff done and leaving it done.

excuse-me 14y ago

I remember DEC sending out a fix for the "day 10000 bug". Some system counter would wrap around if it was up for 10000days (27years)! Compare it with the Windows95 49day bug that nobody ever reached.

Hoff 14y ago
Some DEC code for OpenVMS had been converting variables containing times using the Unix epoch date to and from the OpenVMS-format dates* using the LIB$ LIBRTL calls, and the LIBRTL calls had a documented format limit of 9,999 days. When 19-May-1997 rolled around, you needed to use a different conversion sequence for your Unix epoch dates, or to have applied the then-available LIBRTL 10K Delta Time patch that extended the permitted day field. More to the OP's point, the longest continuous OpenVMS server uptime I'm aware of was around seventeen years. The downside of that being seventeen years of unapplied patches. *VMS uses 17-Nov-1958 as its base date; that date was chosen to match the date commonly used by the Smithsonian Astrophysical Observatory
- excuse-me 14y ago
  Actually "1858" - the base for Modified Julian Days. Although ironically MJD was invented in around 1958 to cope with a computer limitation. vms is also famous for having one of the system time settings specified in "micro-fortnights"
tytr 14y ago
Yet people criticised the VAX. I guess every computer has its flaws (nothing is perfect!), but was the criticism of the VAX justified? (Assuming uptime and reliability means anything, and compared to what followed it. Windows NT? C'mon.) It is just one more bit of evidence that tells me that many of the supposed "experts" on matters of computing are anything but. There's FUD and then there's just people who just have no idea what they're saying. (Of course the CEO of DEC got caught making the dumbest comment ever. No one is immune.) Maybe we should just focus on results and not what people say?
- excuse-me 14y ago
  VMS is different from UNIX. VMS is like a mini-mainframe. You aren't supposed to play with it, you get given specific permissions by some operator, you do as you are told, you don't mess around. And you do things the VMS way. If you want to know the VMS way there are 100ft of grey manuals on the shelf telling you. Unix has a play with and enjoy the jokes philosophy. In my experience VMS people hate Unix more than Unix people hate VMS
  - gouranga 14y ago
    I remember having to shift those manuals to a skip when we replaced the VAXCluster with SQL 6.5 (bad bad bad decision othe than for electricity usage!)... I didn't remember much hate between the UNIX/VAX people in my org as they were pooled together. I think everyone agreed that VAX/VMS was superior though when it came to getting stuff done and leaving it done.