(emulation at it's best)
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?
Posts
I guess it was principally my comments that you are responding to here...
ReplyDeleteAs for something running faster under emulation, well that's an easy one. A PC running pretty much only the OS and a single task is doing far less than a mainframe that could have hundreds of tasks going on concurrently. As well, Z/OS machines typically have CPU percentage throttled, especially for "test" jobs. What's more, these days, it is entirely possible that a PC-based machine could be faster than the mainframe.
But here's my idea of "emulated or not emulated." Under Micro Focus, say I compile a COBOL program. Now, can I distribute that executable? Can I give it to someone who does not have Micro Focus installed on their machine, and can they run it?
If the answer is no, then there's an emulation layer (or at least an API layer that must be installed, which one could argue that if an API layer is required, then the code isn't "native").
Here's a question for you... do you see Micro Focus as an execution environment, or as a development environment? IOW, do people get Micro Focus to develop for the mainframe? Or do they get it to, in some ways, replace the mainframe, running production code?
Thanks... keep up the great work. I enjoy your articles.
-Mike
Thanks!
ReplyDeleteI agree with your view on the fact that the mainframe was probably doing a bit more than just that program. However, keep in mind that the measure was CPU time, not clock time. It was specifically how much time it took for that routine to run when it had its share of the CPU.
Nope, you can't run the program without the MF Server component being in place. It provides the libraries which provide the EXEC CICS support or the file access, etc. But not everything hits those libraries / functions, so I'm still not sold on the emulation description. Doesn't your example eliminate both Java and C# as being native code? They both require supporting modules to run don't they? or am I missing something?
Good question on whether Micro Focus delivers an execution environment or a development environment. The answer is both, it just depends on what your goals are. If you wish to develop to target the mainframe, you do your work locally and once finished push the code back to the mainframe. If you wish to target the distributed platform, you do your development work locally and create DLL's, EXE's, etc for the platform.
Well, I'm not 100% sure what "CPU Time" is measuring... is it CPU Clock Cycles that have been dedicated to that process? If it is, then you really can't compare CPU time between platforms with different architectures. Certain CPUs do far more in a single clock cycle than other CPUs might. So you may be seeing that an IBM mainframe does less in a CPU cycle than does a Core 2 (I'm just guessing here... hardware is not my strong suit) and so would require more cycles to less work.
ReplyDeleteBut you're right... I assumed you meant wall clock time.
You are 100% correct about my point for "what is emulated" in Java and C#. To my knowledge, C# isn't cross-platform... is it? So that shouldn't count. But on that front, EVERY Windows program could be said to be running in emulation since they end up doing more Windows API calls than executing anything directly at the machine level.
And Java... well, you're right. It does run in a "virtual machine" (JVM) but I could argue that the ubiquity of JVMs on pretty much every platform, as well as the idea that it's ALWAYS executed in this virtual layer, obscures its place in this definition.
Yeah, I'm picking nits here, but I do think one could make the case that Java is truly cross-platform because it runs in the same manner everywhere.
Z/OS COBOL vs. Micro Focus COBOL, however... that's a different animal because even if the source is the same, they are executed in vastly different manners. Z/OS COBOL uses no APIs; it all runs natively. Well... I guess you could classify CICS as an API layer... and DB2, IMS, and perhaps even VSAM. So I guess my definition is on real shaky ground :-)
On the point of "what is Micro Focus," I was asking what YOU consider it to be. In essence, what was it created for? This is just a curiosity on my part -- just picking your brain. I used Micro Focus many years ago for development in a DOS/VSE shop (ugh!) and found it innovative, but not quite ready for prime time. Of course, that was nearly 20 years ago, so I would wager there've been improvements :-)
-Mike
What is Micro Focus? I never really sat and thought about that before Mike. I'd like to "jump-in" if I may? Micro Focus is a better way of doing the something that's been done the same way for a long time. OK, ok...too 'salesy' I agree. But really, it is. Micro Focus takes advantage of a new platform and the capabilities it presents and offers a whole new way of doing the same thing to someone who has been doing it the same way for a rather long time. I personally don't believe it's an emulation though. Here's why...
ReplyDeleteFollowing your thought process in the previous note,on the mainframe you can't simply edit a COBOL program, compile it and run it. There is a runtime environment installed. It may be built into the operating system or may be an add-on but it is nonetheless present. And it's native to that platform. The same thing is said for the Micro Focus environment. You do the same edit, and compile and when you go to execute the runtime is native on the environment (Windows, Unix or Linux). You are right, you need a runtime but that is to merely enable the functionality you programmed in your module to execute. No different than Java which has a runtime as well. You mention no APIs in z/OS. Well we do have APIs but that's how we've chosen to enable our product, which is the standard on the distributed platform, isn't it?
What is Micro Focus? To me it is a better (faster, cheaper, more accurate) way of doing what mainframe developers have been doing for a long time: Keeping businesses up, running and profitable!