To Emulate or Not to Emulate - That is the Question

Some great comments on the last posting.  Thanks everyone for your input!

(emulation at it's best)

As you may have guessed from the title, I'm going to see if I can tackle the emulation comment.  I've never really thought of the Micro Focus Mainframe Subsystem (MSS) as an emulation environment.  But then I went out to Dictionary.com.  Hmmm...seems like maybe I'm wrong to some degree if you follow that definition.  One part of the definition fits nicely "When one system performs in exactly the same way as another..", but the rest pointed out an opinion which I've always assocated with emulation, "...though perhaps not at the same speed."

My thinking has been that an emulation environment involves a "wrapper" around the application, filtering the API calls and executing lower level calls to OS specific functions to perform comparable tasks.  This means extra steps which equates to slower performance.

After additional pondering (no Rick, I didn't fall asleep!), the key component which slows things down is the wrapper layer.  However, from my use of the Micro Focus tools, I don't see the wrapper or the penalty such a wrapper would include existing.  What I see are direct calls to platform specific API's which provide the same the same functionality as on the mainframe.  The difference is that those routines are executing OS specific versions of those routines.

Maybe I'm nuts, but to me this seems a bit different.  What you end up with is something which doesn't necessarily pay the same performance price as you would see with that "wrapper layer" or shell. A still calls B, not A calls B which calls C. 

The MSS is emulating the functionality found on the z/OS environment, but I don't believe it is acting as a shell environment within which the application runs.  The statements such as EXEC CICS and READ / WRITE are calling API's which are compiled to run natively on the platform, whether UNIX, Linux or Windows.  For instance, the read statement is passed to the Micro Focus file handler which executes the appropriate lower level funtion to access the indexed file on that platform.  And if you have the need, you can even replace the file handler with your own.  The MSS is Micro Focus' own engine providing the same functionality found on z/OS for things like JES or CICS or IMS but on different operating systems.

To give you some perspective, I recently had the opportunity (during the snow storm in New York City in December - Thanks Rob! *grin*)  to do a performance test for a prospective customer.  The prospect gave us a z/OS batch routine (JCL, COBOL, VSAM)  which proccessed just under eleven GB of EBCDIC data (one input file).  On the z10 z/OS mainframe this job with this data ran in two minutes and thirty seconds of CPU time and created fifty-six separate GDG output files.  

After setting up the tools in a Windows Server 2008 R2 virtual machine managed by Hyper-V on a dual CPU quad-core HP Blade with a high speed SAN, we were able to recompile the program and run the job with no changes to either the program or the data file (we kept it EBCDIC).  In five runs, we averaged 1 minute and 20 seconds.  Is this typical?  Nah.  But is it unusual?  Nah.

If this application execution enviroinment were wrapped in an emulation layer, I just can't see how it could be faster.  It would have more to do to perform the same work and would therefore be slower.

So, yes, it emulates the functionality of the environment, but it doesn't do it by running in an emulation environment.  Almost a Yogi statement there huh?

There are a few folks who follow this blog who might be able to add their two cents to this.  Maybe they will post some thoughts.

Anyone?