On Mon, Jun 9, 2014 at 3:58 AM, Timothy Sipples <sipp...@sg.ibm.com> wrote:
> John, > > I like your idea. I have a couple (perhaps somewhat naive) comments: > Thanks for the encouragement. Comments always welcome. I need all the thoughts I can get! > > 1. Why not just provide a straightforward, "identical" C/C++ interface to > the work already done in JZOS? C/C++ can call Java via JNI, and there's a > choice of 31-bit or 64-bit calling. (Supporting both would be nice.) Or at > least start with that approach and see where it leads, because that's the > "external" part programmers using this C/C++ interface will see. It'd mean > programmers would only have to learn one interface (JZOS/JZOS-like) whether > they're programming in Java, C, or C++ (or conceivably other languages, > including all the JVM-based ones), stylistically speaking anyway. It also > means the documentation could be extensively and liberally shared, and as > JZOS evolves the C/C++ interface can more easily, too. Problem > determination, debugging, error codes, codepages and Unicode, etc., etc. -- > all that "detail" stuff just comes along for the ride, presumably. > Interesting idea. Of course, many don't like using Java (I'm not in that group) due to its overhead, especially if there are no specialty engines to run it for "free". It is almost amusing in that, according to Kirk Wolf of Dovetailed Technologies (original authors of JZOS), the Java classes are basically just a layer over C/C++ code which does all the real work of interfacing to DFSORT. What might be "nice" would be if the Java (JZOS) people would "donate" the C/C++ code to the DFSORT people so that it could be integrated into the DFSORT product. Of course, given that IBM is, basically, a set of "federated" fiefdoms, that might not be politically acceptable to either the JZOS or even the DFSORT people. > > If you later decide you want your own backend path to DFSORT then that > could even be a second, selectable/parameterized path available through the > same interface. But with "Path 1" (JZOS) you start off delivering something > useful, sooner, then you can decide whether "Path 2" even has merit. > True, but it means learning how to start up a JVM from a C/C++ program (which will actually be a subroutine) and invoke a Java class. I don't know how to do that. More time learning. I already know how to invoke DFSORT from HLASM. So translating that into C/C++, or actually doing the hard work in HLASM with C/C++ wrappers, would likely be faster for me. > > Yes, there's JVM startup, and some people worry about that, but a JVM can > be both persistent and small if you wish. Beyond the scope of my comments > here, really. > > Programmers can also see another (hopefully excellent) example of z/OS C/C+ > + code tapping into Java via JNI, and having another such example published > certainly isn't a bad thing. > True. Makes me wish there was a future here for such. But there isn't. We're scheduled to shut down z/OS on or before Dec 2015. > > 2. If you package your work up in a dataset -- and I don't have an opinion > on that -- given the recent discussion about compiler trends I'd say a PDSE > would be recommended over a PDS. Again, though, I'm not sure you must > choose. You could publish two formats: a PDSE and a pax/tar file (probably > pax.Z). > True. I try to remember to say PDSE, but sometimes I say PDS. I don't use the old style PDS libraries except where required for some reason. PDSEs are better for me, despite their still having some "strange" problems (like latch contention) in z/OS 1.12 (where we are frozen for the remainder of z/OS's life here). > > > -------------------------------------------------------------------------------------------------------- > Timothy Sipples > IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA > > -------------------------------------------------------------------------------------------------------- > > E-Mail: sipp...@sg.ibm.com > > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
