Re: Curiousity: Mono on z/OS?
Porting Java to z/OS *is* difficult. Along with that already mentioned, a bytecode VM needs a JIT to be efficent which is no less than a dynamic optimizing compiler. On Fri, Jun 12, 2009 at 3:40 PM, Frank Swarbrickfrank.swarbr...@efirstbank.com wrote: Why would porting Mono be any more difficult than porting Java? Aren't they both bytecode runtime environments (not sure that's the correct term...)? On 6/12/2009 at 1:50 PM, in message 4a32792b026d0007a...@sinclair.provo.novell.com, Mark Post mp...@novell.com wrote: On 6/12/2009 at 2:53 PM, Kirk Wolf k...@dovetail.com wrote: John, I'm pretty sure its already available on z Linux, or could easily be built. Porting to z/OS would probably be a nice challenge, given the lack of essential GNU tool chain components and the fact that z/OS Unix is by nature EBCIDIC. It's an interesting idea, but what specific applications would it be useful for? Yeah, that could get pretty tricky. The original port to Linux on System z was tough enough, from what I understand. In terms of what you could do with it, the answer is the same as for any other platform. If you have developers (or their managers) that really like using .NET, they could continue using that framework, and then deploy the application to the architecture that makes most sense for it, and not just Windows on Intel/AMD. We have some customers that are very interested in that sort of flexibility. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Language Environment runtime options and system dumps
Clark Morris pisze: [...] Virtually all LE dumps are User 4039 and in the descriptive information in the dump up where they give the registers, they show the original abend code. It's a long time since I had to use the LE dump but I remember that and that I got the COBOL file areas nicely. Just curious: WHY??? Why the real description is so ugly hidden? Just to make things even more complicated? Usually programs tend to use descriptive messages in more and more situations. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E and multiple zones
Mark Zelden pisze: On Fri, 12 Jun 2009 14:51:17 -0500, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Fri, 12 Jun 2009 18:24:28 +0200, R.S. wrote: In fact I started follow-on discussion about how to purge sysmods which accepted everywhere. There are two ideas: a) REJECT in mass mode - suggested by Mark Zelden b) use another OPTion set with PURGE=YES for last ACCEPT. That's REJECT PURGE, not mass mode REJECT. Mass mode is where you reject SYSMODs that have never been installed. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/GIMCOM40/15.0?SHELF=GIM2BK71DT=20080615231616 or tiny: http://preview.tinyurl.com/nyybug Right command, wrong terminology. Thanks for the correction. Radoslaw was just repeating what I wrote in an earlier post. And now it's much more clear for me! g I knew (somewhere in my subconscious) I could lose to much from the PTS. Gentlemen Thank you all for your help! -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Language Environment runtime options and system dumps
On 13 Jun 2009 09:52:54 -0700, in bit.listserv.ibm-main you wrote: Clark Morris pisze: [...] Virtually all LE dumps are User 4039 and in the descriptive information in the dump up where they give the registers, they show the original abend code. It's a long time since I had to use the LE dump but I remember that and that I got the COBOL file areas nicely. Just curious: WHY??? Why the real description is so ugly hidden? Just to make things even more complicated? Usually programs tend to use descriptive messages in more and more situations. While I can't speak for the LE designers, I guess that since LE traps the original abed, there was no good way to turn around and make that the abend code when LE issued the termination. I also suspect that the abend code had to be a user code rather than a system code so the least confusing method was thought to be use a catchall code and show the causing code (system or user) in the dump. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Language Environment runtime options and system dumps
Jim, Has anyone asked (yet) WHY you want this? I know that in IBM-MAIN, historically people (often systems programmers) don't like debugging tools that get in the way of original dump information. However, depending on what is causing the S0C4, it is possible that more - not less - LE assistance might be the answer. For COBOL only applications, for example, using SSRANGE (compile and run-time) often finds the cause of S0C4 ABENDs and does so in a manner that the application programmer can find the cause quickly and easily. Of course, if this is NOT a COBOL application - or you can't recompile (if the program was originally compiled with NOSSR) then this particular aid won't help. My point is simply that sometimes, using the user friendly debugging tools at hand can make the need for a system dump of the original abend unnecessary. Jim McAlpine jim.mcalp...@gmail.com wrote in message news:21d1f8c20906120723s12d0fc19v19493cbc3d786...@mail.gmail.com... Is there any combination of LE runtime options that will give a system dump of the original abend and an LE message. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Language Environment runtime options and system dumps
On Sat, 13 Jun 2009 15:52:16 -0300 Clark Morris cfmpub...@ns.sympatico.ca wrote: :On 13 Jun 2009 09:52:54 -0700, in bit.listserv.ibm-main you wrote: :Clark Morris pisze: :[...] : Virtually all LE dumps are User 4039 and in the descriptive : information in the dump up where they give the registers, they show : the original abend code. It's a long time since I had to use the LE : dump but I remember that and that I got the COBOL file areas nicely. :Just curious: WHY??? :Why the real description is so ugly hidden? Just to make things even :more complicated? :Usually programs tend to use descriptive messages in more and more :situations. :While I can't speak for the LE designers, I guess that since LE traps :the original abed, there was no good way to turn around and make that :the abend code when LE issued the termination. I also suspect that :the abend code had to be a user code rather than a system code so the :least confusing method was thought to be use a catchall code and show :the causing code (system or user) in the dump. Certainly can be done. LE could do all the logic in its ESTAE retry routine and then percolate. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multi-line Srchfor Utility?
On Fri, 12 Jun 2009 10:10:06 -0500 Chase, John jch...@ussco.com wrote: : -Original Message- : From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen : On Fri, 12 Jun 2009 07:58:50 -0500 Mark Zelden :mark.zel...@zurichna.com : wrote: : :On Fri, 12 Jun 2009 08:05:48 -0400, Mike Myers :m...@mentor-services.com wrote: : : : :If you were to take Dave's approach, I wrote a REXX EXEC that will : :execute the same edit macro against all members of a PDS or PDSE, :given : :the name of the PDS and the name of the macro as input. : :See EDMACALL on my web site (URL below) or CBT file 434. : Been a while for me, but wouldn't the QUERY security generate some :literal : data that could be searched for in the load library? Should be easier :than : scanning source. :The need is not just to see whether the program issues a specific :command, but also to see specifically what values or references were :specified on the command. :While it's true that the CICS preprocessor generates a unique literal :for each EXEC CICS command, that literal is a bit string (arg 0 in the :DFHEI1 call) which would then require translation back to the original :source, e.g.: :x'0c02b00027cc00f0f0f0f4f5404040' :From the first two bytes (function) I can tell you that the command is :EXEC CICS GETMAIN, but beyond that I'd need to refer to the CICS Data :Areas manual to decode the rest of it, and there's no way I could fill :in all the blanks. In the first place, how would I find the specific :code that refers to that particular bit string? Here's the machine code :generated for this particular bit string (offsets omitted :intentionally): You can scan the loadlib to limit the number of source members that need to be scanned. Much easier to scan for a string than an EXEC CICS QUERY SECURITY block that may wrap multiple lines. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Enterprise COBOL code generation question
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Clark Morris On 1 May 2009 07:52:30 -0700, in bit.listserv.ibm-main you wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Sidler On Fri, 1 May 2009 08:38:59 -0500, Chase, John wrote: Thanks for pointing out the benefit of TRUNC(OPT) to me. But then there's this in the Notes for TRUNC in the Installation Customization Guide: 2. TRUNC=BIN is the recommended option when interfacing with other products that have S/390-format binary data (such as CICS, DB2, FORTRAN, and PL/I). This is especially true if there is a possibility of having more than 9 digits in a fullword or more than 4 digits in a halfword. So, we're stuck with TRUNC(BIN) in CICS, where arguably we'd want the best performance. :-( I think that if you use the CICS integrated translator then TRUNC() becomes mostly irrelevant in the CICS environment. The integrated translator will use COMP-5 internally. Why IBM didn't choose to use COMP-5 fields during translation before this for COBOL3 I never understood. We also use Rational Developer for System z (RDz) in conjunction with the CICS Service Flow Feature to generate driver or wrapper programs for Service Flows. Those generated programs contain working storage fields defined with PIC S9(8) COMP and S9(4) COMP which are untouched by the CICS translator, integrated or standalone, leaving us stuck with using TRUNC(BIN). I suppose we could manually edit the obvious halfword and fullword fields in the generated source to COMP-5, but why should we have to do that? If you are NOT doing any conversions to and/or from either packed decimal or character, TRUNC(OPT) should work just fine with your current definitions. BINARY/COMP to BINARY/COMP does not get truncated to picture when using TRUNC(OPT). Run a test and verify it for yourself. We have. It truncates at 8 decimal digits. Enterprise COBOL for z/OS 3.4.1. When an IF statement compares a S9(8) COMP variable for equality to a fullword constant whose decimal value is greater than , it writes a message in the compiler listing to the effect that the result of comparison is already known and basically generates only the else branch of the code (it doesn't generate the comparison code). -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
