...to let you all know that we're changing the name of the system formerly known as z/Vos. Why would we do that? Simple, really: As it turns out, it's just a little too similar to an existing intellectual property name. So, even though we were fond of the name "z/Vos" and were a little sad to have to shift gears - we're betting nonetheless that a rose smells as sweet no matter what the name...And here's what we're going to call it:

z86VM™

Elegant, no?

You may recall a few weeks back that we posted a body of code from a test program used for DAT structure creation, then issued a challenge offering a new iPod for anyone who could correctly identify the bug within...Now, it's high time we posted the solution. The explanation submitted by contest winner, Jens Remus - from Böblingen, Germany - was elegant, concise and right on the money. So much so that we decided to just post his submission right here on the blog, just as he wrote it. Please read on...

------------------------------------------------------------------------------------------

The error is on line 102:

ag r14,=AD(((stTL/4096))+dt_r3) | show length |

First, to recap: Many have asked about machine requirements for x86 virtualization using z/Vos. On the software side, z/VM 5.4 will be required. On the hardware side of the picture, the machine must be capable of supporting all extended immediate instructions. Some CPU models support these instructions, but at a high price, since hte instructions (some of them) are emulated.

Those requirements in greater detail:

• z/Architecture architectural mode

• Extended-translation facility 2

• Long-displacement facility

• HFP-multiply-and-add/subtract facility (I think)

• General-instructions-extension facility

• Execute-extensions facility

• Floating-point-support-enhancement facilities

• The DFP (decimal-floating-point) facility (future)

/&

Many have asked about machine requirements for x86 virtualization using z/Vos. On the software side z/VM 5.4 will be required. On the hardware side of the picture, the machine must be capable of supporting all extended immediate instructions. Some CPU models support these instructions, but at a high cost since the instructions (some of them) are emulated. We're thinking z10.

Hmmm...I wonder about the floating point requirements...I'll get back to you.

/&

At this stage of the z/Vos effort we did not think that we'd be writing a program loader. Think again. A combination of long name entry points and 64 bit address constants has conspired to put us in that position.

We are six days in, and trying to avoid writing a linker. We'll see if the man in the blue shoes can pull this off...

/&

Each OS process in z/Vos has to have its own address space. We recently created a primary address space DAT map for a z/VM CMS machine, as part of an experiment to test the effects of frequent access mode addres space switching. This works beautifully but we can't help but wonder about TLB cage rattling. We have been told that there are no tools capable of measuring TLB activity.

/&

We've found our winner! Jens Remus, of Böblingen, Germany, was the first to successfully identify the error in the code we posted here a few days ago. For his time and effort, he wins an iPod Classic, along with our sincerest congratulations!

As we're still having a good time with this, we're keeping the competition going by offering an iPod Nano (you choose the color) to the 2nd person who correctly identifies the bug. So if you've got the time and inclination, please feel free to take your best shot. Again, just email us here.

Once again, Jens: WELL DONE!!!

The following code (located in the "Contest.txt" file attached to this post) is from a test program used for DAT structure creation. The program has an error which causes a defect in the structure. Take a look and see if you can identify the error. Once you do, just email us here with your response. If you're the 1st to correctly id the buggy code, we'll send you a new iPod Classic (120GB). If you're the 2nd, we'll send you a new iPod Nano (16GB) in the color of your choice.

The point of all this? Nothing more than just having a little fun - for those of us interested in this sort of thing...So have at it!

We're going to give away 2. Here's how it's going to work:

Monday @12:00 CDT (UTC -5),  we're going to post some code for creating 2 mainframe DAT tables. In this code there will be a single bug which results in a structural error. Whoever correctly identifies this bug, and responds first with the answer (via the contact form on this site), will win a new iPod Classic (120GB). The second person to respond correctly will win a new iPod Nano (16GB), and get to choose the color...

We'll also post the winner here on this blog, along with all due praise and accolades (if, of course, the winner does not object to the publicity).

So - Monday, let's have some fun with it...Until then, have a lovely weekend.

We're looking forward to the time when z/Vos hits the market, so that we can tell the world in full about what it is and what it does. We will be shouting it from the rooftops, to be sure... But what's going to be the most effective way to do this?

Well, we've started by excluding two methods right off the bat: 1.) Promotional bottles of hot sauce, and 2.) promotional bricks.

Let's take a closer look at why...

1.)  Hot Sauce -- We tried this approach several years ago, having mailed thousands of  bottles of 'Mantissa' brand hot sauce, along with a bulletin on our latest innovation at the time. This campaign came to an end, however, when we got a call from an exec at Bank of New York: his very expensive suit had apparently been ruined by a bottle of sauce which had broken in transit. So, as you might've guessed, all further plans for the tabasco campaign were scrapped...