Quayle Consulting now sells CRISP!

CRISP product, with full names of CRISP/32 and CRISP/64, is factory-automation software running under the OpenVMS (“VMS”) operating system.  The “/32” version runs on VAX systems running VAX/VMS or OpenVMS.  The “/64” runs in 64-bit mode on AlphaServer and Integrity Server systems.  Quayle Consulting has been supporting the CRISP source code for several years, and migrated it from the 32-bit VAX to the 64-bit AlphaServer and Integrity servers.

Quayle Consulting Inc. has just reached an agreement with CRISP Automation to sell CRISP licenses and CRISP support contracts.  For more information, please contact Quayle Consulting at www.stanq.com or post a comment on this page.

Ticketmaster and its “old” system

In Wired magazine, issue 18.11, there are a few mentions of Ticketmaster’s “old” system.  Some looks at job sites like monster.com over the years shows that Ticketmaster is always looking for people with VAX and VMS talent.  Could that be the “old” system that Wired refers to?

Funny, that “old” system withstands the assault of millions of people trying to buy tickets all at the same time.  No other system has emerged that can handle that load — many have tried, all have failed.

As I’ve said before, “legacy” means “stuff that just works”.  That’s VMS!

Hello from New Hampshire — Birthplace of VMS

Hello from Nashua NH. This week is the OpenVMS Advanced Technical Bootcamp. We started at 7:45 AM this morning, and went until 9:15 this evening.

The Bootcamp is held in Nashua because that was where VMS was originally developed. Unfortunately, Hewlett Packard canned the entire VMS development team a couple of years ago and moved development to India. *sigh*

I directed a session titled “Risk vs. Benefits of VAX/Alpha Emulation”. I’ll be doing it again Thursday afternoon. Here’s a link in case you can’t drop by and see it in person…

CHARON-VAX and CHARON-AXP supported on VMware

The CHARON product line is now supported in VMware on top of a Windows instance. Versions supported are:

  • CHARON-VAX version 3.4 build 110 and later
  • CHARON-AXP/4100/DS/ES/GS version 2.3 Build 108 and later
  • CHARON-AXP/SMA and CHARON-AXP/SMA Plus version 2.1.26 and later

There are some requirements:

  • The CHARON virtual machine should have exclusive access to the CHARON USB license dongle. It could be achieved with a third party product, for example: http://www.digi.com/products/usb/anywhereusb.jsp#overview.
  • The CHARON virtual machine should meet standard CHARON hardware requirements in terms of Windows OS version and patch level, CPU, RAM, storage, etc.
  • On any physical server hosting a CHARON virtual machine, the total number of VMware vCPUs allocated to all active Virtual Machines should not exceed the number of host physical CPU cores. The same requirement is applicable to RAM: total vRAM allocated to active VMs must not exceed total host RAM.

Some product features are not supported:

  • The Pass Through mode in CHARON-AXP/SMA and CHARON-AXP/SMA Plus
  • Direct device access

Please note that the supported CHARON-VAX version requires a HASP dongle. The older Hardlock dongle can be swapped at no charge for customers under support.

Another successful CHARON-VAX migration

I can’t show you the name, but here’s an email I received on March 22nd from a customer. For information on CHARON-VAX, check out http://www.stanq.com/charon-vax.html.

Subject: BEANIE MOVE COMPLETE in ERIE PA
Date: Mon, 22 Mar 2010 11:04:46 -0400

BEANIE$ sho mem
System Memory Resources on 22-MAR-2010 11:01:59.03

Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (128.00Mb) 262144 26089 216652 19403

Virtual I/O Cache Usage (pages): Total Free In Use Maximum
Cache Memory 15997 871 15126 167677

Slot Usage (slots): Total Free Resident Swapped
Process Entry Slots 284 178 96 10
Balance Set Slots 280 184 94 2

Dynamic Memory Usage (bytes): Total Free In Use Largest
Nonpaged Dynamic Memory 16000000 10547584 5452416 10421888
Paged Dynamic Memory 8000000 6670048 1329952 6666368

Paging File Usage (pages): Free Reservable Total
PSWAP:[BEANIE]SWAPFILE.SYS;1 994472 994472 999992
DISK$VAXVMSRL5:[SYS0.SYSEXE]PAGEFILE.SYS 4819 -480 5000
PSWAP:[BEANIE]PAGEFILE.SYS;1 907387 610340 999992

Of the physical pages in use, 62343 pages are permanently allocated to OpenVMS.

and a total success…. Here it is with most people logged in and only a bit of swapping and all is well. Remember, the original system had 384MB but this system is fitting fine in 128 using the VMS OS to do what it knows what to do best, handling virtual address space.

But, since I know you would want to know, I did have a problem yesterday that I think I resolved. It was that sometimes you couldn’t log in while it got hung up in a RWMBXW but then cleared itself.
Here is my buddy, Steve Hoffman’s take on this:
http://h71000.www7.hp.com/wizard/group3/384.html

However, I resolved it by doing something else that I think was causing the MBX waits… setting PFRATL page trimmer back to ZERO, where I think I will leave it.
http://www3.sympatico.ca/n.rieck/docs/openvms_notes_system_tuning.html
3rd paragraph under AWSA, I realized I should NOT have this trimming as the processes on this box never grow to be very large anyway, as we now can see how little is swapped.
It was trimming and then things grew and it a kind of thrashing situation on a bored system (not-loaded at all). Now that PFRATL=0 all is well, I get no RWMBX delays anymore.

I had to leave the system as a VAX-CLUSTER even though it is now only one member as thet CLUSTER alias is used in PROXY (no password) access to PDP-11s. Don’t even ask. I could use Charon-PDPs!!!

Just thought you might want to know that it is virtually complete. 🙂

OH by the way, remember, I had to place the VAX NIC on windows to 10/half and left it there. I now get no COLLISION DETECT CHECK FAILURES in LANCP, which I got alot of when I had it set to 100full.
BEANIE$ mcr lancp show dev eza/count
0 Collision detect check failure
0 Unrecognized frame destination
0 System buffer unavailable
0 User buffer unavailable

VAX in a room with no walls

There’s a legend about a company accidentally walling-off a VAX server, and it continued to hum along.

It’s no longer a legend — I have found an eyewitness!

Keating Floyd (Keating_floyd-at-onebox-dot-com) is a consultant. He was visiting B&W Tobacco in Macon, Georgia in 1998 or so. The client was ripping out drywall, and discovered a VAX that no one knew about. It was still running and serving clients.

Sorry — no pictures available.  And he didn’t know what application was running.  But, hey, it was running VMS, for sure!