my two cents: (a) is the SDSF API available in Java or is it just JNI around some C or even REXX functions? - no words, eh -
(b) what has to be done? # computing like numerical maths (in addition one could differ, e.g. between integer and floating point) --> Java has neat facilities dealing efficiently according to type of data. For REXX, everything appears as string (yes, REXX knows about different data types like string of characters, integer and float. But all data is given in the form of typeless character strings. Therefore I imply that REXX needs to find out how to deal with the data depending on operation and appearance.). # I/O business (in addition one could differ between, e.g. small chunks of DASD and big PS data sets on tape) --> Java on z/OS deals with CCSID conversion between EBCDIC and Unicode (in general, may be you have the data set contents in Unicode already?) which REXX typically does not need. (c) Do you have REXX compiler or interpreter? When you have compiled REXX, I would assume this is running faster than Java as a rule of thumb. When you have REXX interpreter only, I would assume the Java program is running faster due to the just in time compiler. (d) How much work is the program doing? When there are only small units of work, you should keep in mind that for running Java, there must be set up a JVM first. This is expensive compared to just loading a module. But the more the Java program is doing the less this preparation time is counting. From what you wrote, I assume the program is a little service for a web server. Therefore, I would expect the overhead of starting the JVM as the main factor. Once I was reading very little on "reusable JVMs". May be there is something like Java-initiators available. I think the common suspects like Kirk can tell about this. I have learned that fork()'ing in Unix is not so much overhead as expected. Unused BPXAS address spaces are held in idle state for 30 minutes. These will be used by fork() which also is a concept I compare to JES initiators, may be Java has something similar, see above. Therefore I will not share your bet on TSO from this point of view. However, online workload like TSO typically is allowed for a better WLM service class than batch. Cheers Michael John McKown <[email protected]> Gesendet von: IBM Mainframe Discussion List <[email protected]> 2011-05-18 02:25 Bitte antworten an IBM Mainframe Discussion List <[email protected]> An [email protected] Kopie Thema SDSF API - REXX or Java? Does anybody know which is more CPU efficient? Functionally equivalent SDSF API code in REXX or in Java? Assume there is no zAAP or zIIP to offload the Java workload. Assume fairly equal programming ability in the person doing the coding (equally medium). Compiling of Java would occur on my desktop using Netbeans as the IDE. REXX would be edited on z/OS using ISPF edit. The code would either run in the HTTP server or in batch (using JZOS for Java; and IKJEFT01 for REXX or maybe even Co:Z to run REXX in a UNIX environment instead of a TSO environment). Secondary question. In general, would using Co:Z's UNIX setup be more efficient, less efficient, or generally equal to IKJEFT01 for running REXX? I guess that might be comparing TSO in batch vs. UNIX in batch. I'd almost bet on TSO due to the overhead of fork()'ing in UNIX. -- John McKown Maranatha! <>< ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
