A number of changes today. An accumulation from a couple of days.

1. Updated the Operations Manual. It now includes change bars from the prior update. https://www.mantissa.com/dotcom2020/wp-content/uploads/2014/06/z86VM-Concepts.Beta3_.v061814.pdf

2. New problem found – not yet fixed – Under DEMODSL, when you have the desktop running and open a window, if you resize the window, there is a good chance that your system will appear to freeze. It actually goes in a loop. The problem is known, but it will take a bit to get the fix out.

3. A new hardware restriction was identified. The z86MNT 191 cms disk must be large enough to contain the downloaded VMARC file and some workspace. We’ve learned that a 3390-3 is too small to meet that need. The storage device can be reconfigured to grow the space. Some technical solutions may be possible, but may not be ready until General Availability or later. This is a good reason for running the Beta…to find this kind of problems.

4. If you want to use multiple 3390-3 devices to meet the IO server needs, the documentation describing the set up is now included in the Ops Manual.

5. Several new troubleshooting guides were provided, including VNC usage and z/VM paging set up recommendations.

6. We do not have a Software License agreement or NDA in place for Beta participants. We have found all to be mainframe enthusiasts, much like ourselves. There is a trust inherent in this beta. To that end, the Beta description now includes a comment about the spirit of this beta. We hope that each of our participants will maintain that spirit. The text added is as follows:

We’ve released the beta because we wanted to learn from you, the customer, what is good and bad and also to check our documentation, identify any restrictions in the code and capture new product requirements. We have found it is capable of doing some very interesting demos as to possibilities for how it can be used in the future.  We are concerned about expectations for our product. We know we have performance and quality work to do before it becomes generally available. We ask that you understand that.

We would like to make the beta a good experience for you. We may ship additional beta’s with new functions, fixes and performance enhancements. If you want to show someone a demo because you think it is “cool”, “exciting”, “the future”, or any other kind words, that would be wonderful.   We ask that you not show nor publish any performance data associated with your experience in the beta, without permission from Mantissa. We are not done developing the product yet and we hope to further improve the experience. That’s also why we have no published nor target general availability date yet. We will not release the code until it meets our own expectations.

All of us at Mantissa appreciate the time being spent by each of you participating in the beta. We have one customer that has completed all the pre-defined exercises and is looking for more. We have several other customers in a variety of spots within the operations manual testing their install. Thank you all for your interest.

And we continue to be interested in your feedback. Don’t hesitate to comment here or send an email to z86vm@mantissa.com

New Hardware Restrictions Identified: We are trying to reduce or avoid hardware restrictions for z86VM. We’ve documented our server restriction that z86VM will only run on z114 or z196 processors and above. That is because z86VM takes advantage of dozens of z hardware instructions that were originally released in the z196 server. IBM chose not to make them available in earlier hardware releases.

Today, we must inform you of storage restrictions. While FBA and FCP attached storage devices are supported by z/VM, these are not presently supported by z86VM. There are also minimum storage capacity needs for z86VM to be successful.  There are two parts of storage needs: 1. The z86VM IO server file system and 2. The z86MNT 191 CMS Disk that is used to stage the product and copy it into the IO server.

With the z86VM IO server, we can support any ECKD storage device sizes. Multiple disks can be strung together to create a single larger file system. x86 operating systems that are larger than a single ECKD device can logically span multiple devices in the IO file server. If someone would like to use 3390-3 devices for the IO Server, we can provide documentation as to how to do that.

The issue or restriction is a small z86MNT 191 disk cannot host the original files shipped from Mantissa to customers. We have looked at several technical solutions from Mantissa, but none are currently in our Beta release plans. The alternative for a customer is to acquire a larger storage device or reconfigure an existing storage subsystem to meet the capacity requirements for the z86MNT 191 disk needs.

If there are existing beta customers that are experiencing this constraint, please send a note to z86vm@mantissa.com with z86VM Beta in the subject line so we can better understand your requirements.

As mentioned yesterday, the network conflict problem was solved. Beta customers that joined today, have no changes to make. Unfortunately, everyone else should make a change if you want multiple systems to run simultaneously.

Changes for sites that have previously downloaded

1. Download z86.exec from mantissa ftp site (binary fixed lrecl 80) to replace previous Z86 EXEC A.

2. Update the z/VM Directory to add the Additional Record  (in bold) and perform a DIRECTXA USER DIRECT

USER Z86IO   Z86IO   9G  20G  G
 INCLUDE Z86PROF
 OPTION MAXCONN 2000
 NICDEF 0100 TYPE QDIO LAN SYSTEM VSW86 MACID FFFF02
 NICDEF 0110 TYPE QDIO LAN SYSTEM VSW86 MACID FFF202
 MDISK  0195 3390 <start_cyl> 00010 <volid> MR Z86IO Z86IO Z86IO
 MDISK  0200 3390 <start_cyl> 05000 <volid> MR Z86IO Z86IO Z86IO

3. Update PROFILE Z86 on Z86MNT ID with the 2 Additional Records  (in bold)

/* */
 zio_start = Z86IO
 vnicadr =  0100
 vswitch =  VSW86
 x86hd =    0200
 zio_end =   Z86IO

z86_start =  DEMODSL
 io_server=  Z86IO
 module =  V0R3C4M  MODULE   A
 vncport =  2001
 vnicadr =  0110     /* Add this record */
 pcimage =  dsl.img
 VMIMAGE = DSL0602  IMG      A
 z86_end =  DEMODSL

z86_start =  SME8
 io_server=  Z86IO
 module =  V0R3C4M  MODULE   A
 vncport =  1999
 vnicadr =  0100     /* Add this record */
 pcimage =  sme.img
 vmimage =  SME8    IMG   A
z86_end =  SME8

4. In the original post, we neglected to inform you that you must issue z86 (DEFINE=ALL in order for these changes to take effect. You could also issue z86 (INSTALL, but that command will take more time to execute.

5. Now you can issue z86 (START=ALL and the network conflict should be resolved.

First, I want to congratulate Ed S. for being the first customer to send us a picture of the VNC console. Unfortunately, it was for diagnostic purposes, but he got the DSL system booting up. Thanks Ed for the valuable feedback that you’ve given us. We appreciate it. We’d love to see status and updates from anyone else too.

On June 4, we told you about a problem in item #3 about the mutually exclusive nature of SME and DSL. We’ve solved the problem, but haven’t finished documenting it yet. There are two set up changes to make. There were no code errors and the net effect is the system is easier to manage with the changes. We hope to have them documented by tomorrow.

However, in the mean time, there is a simple work around. Instead of issuing z86 (start=all  – which creates the problem, change it to z86 (start=demodsl  and just boot up the dsl image.

You could also do z86 (start=1  and it will boot up which ever image is first in your PROFILE Z86. BTW, if you were ever wondering why we’d have a command like that – start the first xxx number in the profile, it is for benchmark purposes. We have several hundred users defined in our PROFILE, all clones of each other. Given the hardware that we are running on at the time, we can start a given number to do the benchmark. The alternative would be to issue the command naming every user….it wasn’t worth doing 🙂

There’s a few other things that will be forthcoming. We presented at the Marist College hosted Enterprise Computing Conference yesterday. We did a 15 minute presentation followed by a 15 minute demo. It was a terrific audience response. But more importantly, we got asked a lot of tactical and strategic questions. We’re going to add those to the FAQ section over the next couple of days. When we’re done, we’ll post the update here. But who knows, we may add a few now, some later, etc. Check back if you’d like.

Personally, I’m going to this blog a lot to update it, but we didn’t include a link to the blog on the home page, so it’s either a bookmark or a double click. That’s on my list to fix.

Finally, we got some comments about the Operations Manual. Some questions about examples that describe z860001 userid, when you readers were looking for DEMODSL or SME8. Sorry about that. That’s a little bit of internal Mantissa stuff getting through. We have a collection of operating systems at various software levels that we boot. Changing your zVM userid is a pain. So we’ve been using a naming convention of z86001, z86002…..Someone else has z86D01, D02, etc. I have four z/VM userid’s but about 15 OS’s defined in my PROFILE Z86. Rather than delete a profile entry, I comment it out. So today, D01 could be SME and tomorrow, it’s DSL and the next day, it’s SME with WordPress. It all depends on what we are testing that day.

So anyway, we’ll correct the manual toward what we shipped in the Beta code. However, like any z/VM userid, you can name them anything you want. But if you do change them in z/VM, don’t forget to update your PROFILE Z86 file.

z86VM Beta 3 Update for June 5, 2014.

1. Yesterday, we spoke of a problem with the mutually exclusive nature between SME and DSL. Our crackerjack staff solved that, but there are some installation changes to be made. In particular, the USER DIRECT definition of the IO server z/VM guest needs some modification and a new variable needs to be added or used for a z86VM user definition in PROFILE Z86. The Operations Manual has been updated in both sections 3. Define z86VM userids on page 29 of the current manual and in Appendix C in the Troubleshooting Guide.

2. Two other areas of potential concern were added to Appendix C – Troubleshooting Guide. If you see a lot of NIC related messages on any z/VM guest, they were put there to assist the z86VM developers. While they may appear to be ominous, have no fear, they are just making your screen beep when it scrolls to the next page. In the other area, the first time you operate SME Server-Manager from a web browser, you may be presented with an even scarier message that this system may not be trusted. Again, that’s because the beta code was built on a Mantissa machine and a digital certificate was grabbed from there. Now that it’s on your system, the digital certificate doesn’t match. Add the exception for now, as this is only Beta. For a real production environment, you’d want to make sure this was your digital certificate mapped to this particular system image. We’ll update how to to that as we approach General Availability.

3. Thanks to those that provided some nice feedback on the Beta so far. For those others attempting to install, again, any problems, don’t hesitate to ask via comment here or email us at support@mantissa.com.

Beta 3 update – June 4, 2014. We’ve got a couple of changes to tell you about that occurred after Beta 3 shipped.

1. Original email message suggested that you download via FTP the following file: z86VM.direct.txt   That was incorrect. It should be z86vmb3.direct.txt.

2. During the FTP process, the simplest means would be to run the FTP client directly from a z/VM session. However, we’ve found that doesn’t work. We aren’t sure if it is the FTP client on z/VM (which is our suspicion) or our FTP server. However, our FTP server does work from Windows and MacOS based systems. So what you’ll need to do is FTP from your desktop and then once downloaded there, upload them via FTP PUT commands to your z/VM system.

Each of the above have been updated in our opening email, the web site and the Operations manual available on the web site.

3. There seems to be a problem when attempting to run both the DSL and SME images on different virtual machines with the same IO server. SME requires a “hardened” mac address and the trouble shooting guide in the Appendix  C describes how to modify the system to do that. However, we didn’t realize the mutually exclusive nature of the two different Linux OS’s. This is not a proper behavior. We are looking into the solution for that now.

4. In the known problems area, we told you that Firefox that ships with DSL hasn’t been working for us. What we neglected to tell you is that Opera does work. On the DSL Desktop, you’ll see an O icon on the lower left side of the collection of desktop icons. Click on that to enjoy the Opera Browser.

5. Some customers have asked for some capacity planning and set up guidance for the different z/VM images used. Here’s how we’ve set up our images at Mantissa:

Page 29 of the Operations doc recommends 20,000 3390 cyls.

We have the following VM definitions for Beta 3:

Each x86 ID is defined with 6 Gig memory and a 10 cyl boot drive. (The 194 drive)

The I/O ID is defined with 9 Gig memory and a 10 cyl boot drive. (The 195 drive)  The x86 hard drive space (UDM) is defined on the I/O ID.  Beta 3 defines it as 10k Cyls.

The maint ID is defined with 1 Gig memory and a 10k Cyl A-disk.

We’ll update our online doc with this information within 24 hours.