Hi, Gary.

So, let me see if I got this straight....your organization has developed some sort of application, which runs on CMS, that allows Windows-based code to be executed? Way cool, dude. Good luck with it, and could you please keep this informed as to your progress on this?

Given your earlier experiences with the BFS, I would strongly recommend that you take a closer look at using the RSK as the basis for your new file system. Creating a 'simple' file system, using the RSK's DASD management APIs should not be all that difficult, and it certainly does scale up to the sizes you mentioned before.....

#  The maximum number of storage groups is 1024.

# The maximum number of data blocks per storage group is X'FFFFFFFF' (16 TB).

# The maximum number of minidisks per storage group is 13,000.

# The total number of dataspace-mapped DASD blocks cannot exceed X'FFFFFFFF' (16 TB).

Plus, it can perform DASD I/O async allowing perhaps one RSK-based file server to support several Windows application's I/O needs.

Hope this helps some.

DJ

Gary M. Dennis wrote:
Emulation would be a non-starter for a production environment. I would
describe this system as a single pass code segment translation system with
conditional block invalidation.

We have been using VM for 20 of our 27 years in business. A development
environment without it has never been considered an option.

Many companies (ours included) consider running a few dozen virtual Windows®
images on a rack-mounted machine good business. We see no reason why
z/System should not support from 250 images on the low end to several
thousand on mid and high end systems.



On 3/25/08 5:45 PM, "Stephen Frazier" <[EMAIL PROTECTED]> wrote:

Are you attempting to write a windows emulator that runs under VM?

Looking at your companies web site it looks like you mostly sell products that
run under z/OS.

If you can do this there will be a lot of interest.

Gary M. Dennis wrote:
Months ago. The development team was so focused on instruction result
fidelity, machine state, and segment translation bypass issues that I/O
subsystem did not receive the necessary attention. At least the tough part
is done.

Gary Dennis
Mantissa

--.  .-  .-.  -.--

Gary M. Dennis
Mantissa Corporation
2 Perimeter Park South
Birmingham, Alabama 35243-3274

p: 205.968-3942
m: 205.218-3937
f: 205.968.3932

[EMAIL PROTECTED]

http://www.mantissa.com
http://www.idovos.com

Reply via email to