ISPF PanExit question
I'm looking for a good example of using a REXX panel exit. I've tried and get an error. Here is the pertinent code and message: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,EXITDATA,MSG=PEX001) )END Error message: Exit data or message field defined incorrectly for panel exit. I've also tried: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,,MSG=PEX001) )END With the same error message. The code works if I use this without the exitdata and msg: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT) )END Thanks in advance -- Lionel B. Dyck BMC Software Product Development Lead, Common Install and Services 10431 Morado Circle, Building 5, Austin, Texas 78759 Office Phone: 512-340-6031 (extension x26031) E-Mail: lionel_d...@bmc.com Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are. - John Wooden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF PanExit question
I think you must have a '' before 'EXITDATA': PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,EXITDATA,MSG=PEX001) Best Regards, Thomas Berg ___ Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel Sent: Thursday, April 24, 2014 12:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF PanExit question I'm looking for a good example of using a REXX panel exit. I've tried and get an error. Here is the pertinent code and message: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,EXITDATA,MSG=PEX001) )END Error message: Exit data or message field defined incorrectly for panel exit. I've also tried: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,,MSG=PEX001) )END With the same error message. The code works if I use this without the exitdata and msg: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT) )END Thanks in advance -- Lionel B. Dyck BMC Software Product Development Lead, Common Install and Services 10431 Morado Circle, Building 5, Austin, Texas 78759 Office Phone: 512-340-6031 (extension x26031) E-Mail: lionel_d...@bmc.com Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are. - John Wooden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF PanExit question
That solved the issue - thank you (now why didn't I see that) -- Lionel B. Dyck BMC Software Product Development Lead, Common Install and Services 10431 Morado Circle, Building 5, Austin, Texas 78759 Office Phone: 512-340-6031 (extension x26031) E-Mail: lionel_d...@bmc.com Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are. - John Wooden -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Thursday, April 24, 2014 6:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF PanExit question I think you must have a '' before 'EXITDATA': PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,EXITDATA,MSG=PEX001) Best Regards, Thomas Berg ___ Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel Sent: Thursday, April 24, 2014 12:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF PanExit question I'm looking for a good example of using a REXX panel exit. I've tried and get an error. Here is the pertinent code and message: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,EXITDATA,MSG=PEX001) )END Error message: Exit data or message field defined incorrectly for panel exit. I've also tried: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,,MSG=PEX001) )END With the same error message. The code works if I use this without the exitdata and msg: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT) )END Thanks in advance -- Lionel B. Dyck BMC Software Product Development Lead, Common Install and Services 10431 Morado Circle, Building 5, Austin, Texas 78759 Office Phone: 512-340-6031 (extension x26031) E-Mail: lionel_d...@bmc.com Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are. - John Wooden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF PanExit question
Dyck, Lionel wrote: I'm looking for a good example of using a REXX panel exit. On what z/OS and ISPF levels are you? Error message: Exit data or message field defined incorrectly for panel exit. Please post the return code coming with the message. And also the content of MSG before and after the call of the REXX program. What is the length of msg? It seemed to me the system is very picky about length of msg. It must be 8 characters if I get it right. Can you see the content of the msg AFTER using the REXX program? Sorry, could not find a good example. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF PanExit question
Dyck, Lionel wrote: That solved the issue - thank you (now why didn't I see that) Good catch from Thomas who kindly helped you. Your error message as posted distracted me (and perhaps rest of us too) way too much. :-) I have a quick look at my panels and yes, ampersands () are used for variables used by panels. I'm glad your issue is solved! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
Here in this forum and elsewhere the notion that since the binder's support for AMODE(SPLIT) had been little used it would not be necessary or desirable to provide an analogous binder facility for mixing AMODE(31) and AMODE(64) in the same executable was widely reported. (I use the word 'reported' advisedly. Here, for example, the view of someone else, never necessarily that of the poster, was always what was set out.) This notion had two important, albeit non-technical, merits. Both sloth and parsimony recommended it. It was nevertheless a bad, even a very bad one. Among the traditional statement-level languages, i.e., Java excluded, only one IBM C implementation yet supports AMODE(64), and others are apparently going to be slow in coming. Binder support for something like AMODE(MIXED,31,64) is thus urgent. (Binder terminology has traditionally had a short-term bias; ANY, for example, had to mutate into ANY31 abd ANY64.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
PMFJI here, but it is my impression (please correct me if I am wrong) that XPLINK is the z/OS analog of the calling mechanism developed in Germany for z/Linux from the kernel on up to user space. Yes, it's fast, but it provides no call backtrace (i.e., no register saveareas) unless specifically requested at compile time. And the addition of savearea code obviously also impacts the speed of the calling-convention code. IMHO there is no good excuse for not providing interoperability with any and all other calling mechanisms. It violates the standard of interoperability established by OS360 50 years ago, for little or no benefit to the existing program code base. Only future (i.e., unwritten) or ported code benefits from these poor choices. But perhaps that is the point, mainly to support ported code brought in from the cloud. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Tuesday, April 22, 2014 9:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enterprise COBOL v5.1 and RDz v9.x On Mon, 21 Apr 2014 15:31:31 -0500, Paul Gilmartin wrote: z/OS engenders enormous obstacles to migrating to an all 64-bit LE enabled universe. Yes. Not the least of which is that the LE direction is to support 64-bit code only with XPLINK, and that there is no mechanism in LE for a non-XPLINK program to call an XPLINK program The design of XPLINK and XPLINK-64 currently precludes the mixing of the two. That means that the only migration from 31-bit code to 64-bit code in LE is to replace entire executable units, including all called programs, at the same time. IMO, the LE designers did a poor job when they designed XPLINK-64. In contrast, the MVS designers did a good job designing the calling conventions for 64-bit programs. 64-bit programs can easily be written to interoperate with 31-bit programs, and the 31-bit applications do not need to be changed to be able to work with 64-bit applications, provided that the 64-bit applications are designed with interoperability in mind. LE did not consider any such possibility or need. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Development Clueless about COBOL DEV activities
From the description that sounds like IBM Migration Utility - Converts CA Easytrieve to 'COBOL'. None of the doc I could find specified what level of 'COBOL' was produced though... It produces the source, which is then dynamically compiled with whatever COBOL you are running. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
ShowMvs can so I think you can also (source is available for ShowMvs) On 24.04.2014 16:42, Charles Mills wrote: Is there any way for an (authorized) program to determine whether SYS(EXITS(IEFU8n)) has been specified? That is, whether IEFU8n (where 'n' is 3, 4 or 5) is active. Note that z/OS allows a module to be added to an exit even though the exit is not active and the module will never receive a single call. I am looking for whether the EXIT is active and will be called by z/OS, not whether or not module X has been installed on the exit. I am hoping for a conventional z/OS macro type answer, not issue /D SMF,O from Rexx and parse the results. I am looking at bit EXAAEDEFINED in the CSVDYNEX answer area mapping DSECT CSVEXAA. Does this provide the information I am looking for? Does something else? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
Excellent thought. I shall look into that. Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Thursday, April 24, 2014 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())? ShowMvs can so I think you can also (source is available for ShowMvs) On 24.04.2014 16:42, Charles Mills wrote: Is there any way for an (authorized) program to determine whether SYS(EXITS(IEFU8n)) has been specified? That is, whether IEFU8n (where 'n' is 3, 4 or 5) is active. Note that z/OS allows a module to be added to an exit even though the exit is not active and the module will never receive a single call. I am looking for whether the EXIT is active and will be called by z/OS, not whether or not module X has been installed on the exit. I am hoping for a conventional z/OS macro type answer, not issue /D SMF,O from Rexx and parse the results. I am looking at bit EXAAEDEFINED in the CSVDYNEX answer area mapping DSECT CSVEXAA. Does this provide the information I am looking for? Does something else? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
Charles Mills wrote: Is there any way for an (authorized) program to determine whether SYS(EXITS(IEFU8n)) has been specified? That is, whether IEFU8n (where 'n' is 3, 4 or 5) is active. Note that z/OS allows a module to be added to an exit even though the exit is not active and the module will never receive a single call. I am looking for whether the EXIT is active and will be called by z/OS, not whether or not module X has been installed on the exit. True. I am hoping for a conventional z/OS macro type answer, not issue /D SMF,O from Rexx and parse the results. I am looking at bit EXAAEDEFINED in the CSVDYNEX answer area mapping DSECT CSVEXAA. Does this provide the information I am looking for? Does something else? Try CSVDYNEX LIST which can, amongst other info, gives you the status (active/inactive) of the exit. EXAAEDEFINED - simply the system have it or not despite the status, say via SETPROG command. What about EXAAM1ACTIVE, EXAAM2ACTIVE or EXAAMACTIVE in CSVEXAA? That can give you the status of your exit. (STATE in CSV464I) Sample command and result: D PROG,EXIT,EX=SYSSTC.IEFU29,DIAG Only when active: CSV464I 17.00.54 PROG,EXIT DISPLAY EXIT SYSSTC.IEFU29 MODULESTATE EPADDRLOADPTLENGTHJOBNAME PARAM IEFU29 A 85FBDAC8 * When not there, you see this: CSV463I NO EXIT MATCHING SYSSTC.IEFU81 EXISTS I agree, scraping from SYSLOG isn't helpful. Hope above was useful. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
Charles Mills wrote: Excellent thought. I shall look into that. Thanks, You will get it there. From Mark Zelden's nice tool this little line: TMEXAAMFLAGS,EXAAMACTIVE Is it really active? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS RESMIL setting on CPU consumption
Yes RESMIL(5) will reduce cpu consumption, it will also potentially cause performance delays to your jobs, as each system will hold the enq request for a minimum of 5 ms. If you have any applications that generate alot of enqueues, that need to be sent through the ring, they will run longer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
Elardus Engelbrecht wrote: From Mark Zelden's nice tool this little line: Sorry, it is actually in FILE 492 which is from Roland Schiradin. Sorry Mark for troubling you. I was sniffing around your webpages recently and got hold up for other urgent work before posting this. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
It is indeed there: SYS TYPE(0,4-7,14-15,18,21,26,30,36,41-42,50,60-90,94,100-103,109-116,118-20 EXITS(IEFU29,IEFUTL,IEFUJI,IEFUSO,IEFUJP,IEFUSI,IEFUJV,IEFACTRT,IEFU85,I OMVS TYPE(0,4-7,14-15,18,21,26,30,36,41-42,50,60-90,94,100-103,109-116,118-20 EXITS(IEFU85,IEFU84,IEFU83) STC TYPE(0,30,41-42,50,60-83,88-89,100-103,109-110,115-120) etc. Somewhere around line 8250 of SHOWZOS Gilbert pulls it (not surprisingly) out of the SMCA and associated tables. SSTEXTAB. Anyone know where the SMF Selection Control Table is documented? I don't see it in my MVS Data Areas, but I suppose I am looking in the wrong place. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, April 24, 2014 11:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())? Excellent thought. I shall look into that. Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Thursday, April 24, 2014 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())? ShowMvs can so I think you can also (source is available for ShowMvs) On 24.04.2014 16:42, Charles Mills wrote: Is there any way for an (authorized) program to determine whether SYS(EXITS(IEFU8n)) has been specified? That is, whether IEFU8n (where 'n' is 3, 4 or 5) is active. Note that z/OS allows a module to be added to an exit even though the exit is not active and the module will never receive a single call. I am looking for whether the EXIT is active and will be called by z/OS, not whether or not module X has been installed on the exit. I am hoping for a conventional z/OS macro type answer, not issue /D SMF,O from Rexx and parse the results. I am looking at bit EXAAEDEFINED in the CSVDYNEX answer area mapping DSECT CSVEXAA. Does this provide the information I am looking for? Does something else? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Development Clueless about COBOL DEV activities
I talked to the developers today and IMU generates fairly vanilla COBOL code. It should compileable with any supported COBOL release. Is there a problem that we need to be aware of? Ken Hume (720)396-7776 kph...@us.ibm.com IBM APA Product Manager IBM PD Tools Client Advocate -Original Message- From: Dana Mitchell Sent: Thursday, April 24, 2014 6:41 AM Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Development Clueless about COBOL DEV activities On Thu, 24 Apr 2014 12:53:58 +0800, Timothy Sipples sipp...@sg.ibm.com wrote: Still wondering which IBM utility. Even if this forum is an unofficial channel, it's hard to fix an unknown gap. Timothy, DId you see my post yesterday?: On Wed, 23 Apr 2014 08:30:43 -0500, Dana Mitchell mitchd...@gmail.com wrote: From the description that sounds like IBM Migration Utility - Converts CA Easytrieve to 'COBOL'. None of the doc I could find specified what level of 'COBOL' was produced though... Dana On Wed, 23 Apr 2014 14:44:12 +0800, Timothy Sipples sipp...@sg.ibm.com wrote: Which IBM utility? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
On Thu, 24 Apr 2014 10:33:50 -0400, Farley, Peter x23353 wrote: PMFJI here, but it is my impression (please correct me if I am wrong) that XPLINK is the z/OS analog of the calling mechanism developed in Germany for z/Linux from the kernel on up to user space. I don't know about that. XPLINK was introduced with OS/390 2.10 The LE Concepts Guide has this in its glossary: quote Extra Performance Linkage (XPLINK). Extra Performance Linkage (XPLINK) is an enhanced linkage between programs that can significantly improve the performance of your C and C++ programs. The primary goal of XPLINK is to make subroutine calls as fast and efficient as possible by removing all nonessential instructions from the main program path. The XPLINK run-time option controls the initialization of the XPLINK environment. /quote Yes, it's fast, but it provides no call backtrace (i.e., no register saveareas) unless specifically requested at compile time. Yes, it does, but it does it differently. The XPLINK save areas are documented in the LE Vendor Interfaces manual. Not all registers are necessarily saved, but register 7, the return address with XPLINK, is always saved. Fast? Well, you can pass a few parameters in registers. And it doesn't do a GETMAIN for a save area in the code for every program entry. And it doesn't check the stack to see if there is sufficient room in the stack every time. Instead, it relies upon a Program Interruption Code 4 if it tries to store the caller's registers outside of the stack. I don't remember how they ensure that a PIC 4 occurs with XPLINK, rather than overlaying something. With XPLINK-64, the stack is above the bar and a guard area is allocated. This causes its own issues. For example, if an XPLINK-64 program wants to call a program that uses standard linkage, even a standard program like GET or PUT, it needs to allocate a save area below the bar for its save area. Actually, LE uses a stack with standard linkage too, so it doesn't need the GETMAIN either, but it tests the stack to see if there is sufficient space available. If not, more stack is acquired. In XPLINK, the same kind of thing is done, but it is triggered by the PIC 4. If I am a Cobol programmer, I might want to write a program that is called to look up something in a table that resides above the bar. The limitations on interoperability mean that it is more difficult to do that and the small performance improvement that would be available in an environment that is all XPLINK-64 becomes a bigger performance penalty each time the program is called. LE would have me recompile the entire system to run XPLINK-64. And if my system uses subroutines that are also used by other systems, maybe I should recompile all of them as well. The LE people apparently don't share my opinion about this. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sorry state of IT education?
On Wed, 23 Apr 2014 18:21:52 -0500, Roger W. Suhr wrote: It's really simple, I always tell my younger colleagues: If you're willing to stay in the office after work hours, I'll stay with you and show/help you with a few things, and where to find more information. If not, don't expect me to interrupt my work to do yours. My manager considers the work that I do mentoring and training newer people to be part of the job for me and for them. So do I. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
On Thu, 24 Apr 2014 12:32:32 +0800, Timothy Sipples wrote: I remember a school of thought that thunking might not have been a good idea because it encouraged developers to do what they do best: nothing. :-) I never heard of thunking before. It sounds to me like a derogatory term for calling routines that run in different addressing modes. Is that what is intended? That is, developers would use thunking as a means to achieve the bare minimum for a too-timid leap to the next addressing width when what they really should have done (for their customers' and end users' benefit) is brought their whole product/program over to the new width -- or at least continued their efforts in subsequent releases to complete the move to the next width. I don't know if I'd agree with that school of thought, but I remember it, and there's a certain logic to it. I hope that you are not suggesting that z/OS should not have been released until everything ran AMODE 64. We might still be waiting. I wonder if thunking is an area a third party and/or the open source community would find interesting -- a standard set of callable thunking services. And I wonder if it'd be technically possible as such, and how difficult. I don't see what you mean. It is not difficult for any program to call any other, regardless of addressing mode. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Development Clueless about COBOL DEV activities
Mike Schwab wrote: begin extract Easytrieve plus has a case structure and end-???. I assume you would need Cobol 2 or higher to have equivalent structures. /end extract and this is correct in the sense that straightforward mapping of one case figure into another one---SWITCH in C or SELECT in PL/I say---is not possible in versions of COBOL that antedate its EVALUATE statement. Any such Easytrieve figure can, however, be implemented in COBOL without any conceptual or practical difficulty using nested if-then-else statements. Moreover, before COBOL 5.1, which does optimize case-like constructions elegantly, this is anyway what you get in compiled code for EVALUATEs. Even very simple branch tables of the sort used to implement C and C-like SWITCH statements are not [yet] provided. COBOL 5.2 is a very large step forward in performance; and the fact that this has not been much talked about by its potential users has led me to suspect that the managers of many COBOL shops do not really care much about performance. Typically---There are of course some honorable exceptions---they are hardware hawks who would rather throw another or a faster machine at a performance problem than address it directly. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
On 4/24/2014 4:50 PM, Tom Marchant wrote: I never heard of thunking before. It sounds to me like a derogatory term for calling routines that run in different addressing modes. Is that what is intended? I first heard the term in a book on the OS/2 system design and implementation, and I'm sure it was not intended as derogatory. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
Thanks. I can obviously find it in showmvs -- just thought I would ask. Charles Composed on a mobile: please excuse my brevity Rob Scott rsc...@rocketsoftware.com wrote: The SMF SST control block is not a GUPI nor is documented anywhere that I am aware of. The code in SHOWZOS is using either reverse-engineered DSECTs or something left over from the pre-OCO days. On 24 Apr 2014, at 17:40, Charles Mills charl...@mcn.org wrote: It is indeed there: SYS TYPE(0,4-7,14-15,18,21,26,30,36,41-42,50,60-90,94,100-103,109-116,118-20 EXITS(IEFU29,IEFUTL,IEFUJI,IEFUSO,IEFUJP,IEFUSI,IEFUJV,IEFACTRT,IEFU85,I OMVS TYPE(0,4-7,14-15,18,21,26,30,36,41-42,50,60-90,94,100-103,109-116,118-20 EXITS(IEFU85,IEFU84,IEFU83) STC TYPE(0,30,41-42,50,60-83,88-89,100-103,109-110,115-120) etc. Somewhere around line 8250 of SHOWZOS Gilbert pulls it (not surprisingly) out of the SMCA and associated tables. SSTEXTAB. Anyone know where the SMF Selection Control Table is documented? I don't see it in my MVS Data Areas, but I suppose I am looking in the wrong place. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, April 24, 2014 11:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())? Excellent thought. I shall look into that. Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Thursday, April 24, 2014 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())? ShowMvs can so I think you can also (source is available for ShowMvs) On 24.04.2014 16:42, Charles Mills wrote: Is there any way for an (authorized) program to determine whether SYS(EXITS(IEFU8n)) has been specified? That is, whether IEFU8n (where 'n' is 3, 4 or 5) is active. Note that z/OS allows a module to be added to an exit even though the exit is not active and the module will never receive a single call. I am looking for whether the EXIT is active and will be called by z/OS, not whether or not module X has been installed on the exit. I am hoping for a conventional z/OS macro type answer, not issue /D SMF,O from Rexx and parse the results. I am looking at bit EXAAEDEFINED in the CSVDYNEX answer area mapping DSECT CSVEXAA. Does this provide the information I am looking for? Does something else? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sorry state of IT education?
In 5357c6a4.3080...@charter.net, on 04/23/2014 at 09:56 AM, Gerhard Postpischil gerha...@charter.net said: Nowadays companies need to assess applicant skills, but are not willing to pay for (third party?) testing, even though it would save them money. A small ISV I did consulting work for exemplifies this - their flagship package kept bombing - two programmers they hired for upgrades had inserted things like MVC byte,C'A', instead of MVI or =C'A'. ISV? That error was endemic in DIDOCS fixes from EWS. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
If you say so. I seem to recall that FORTRAN was call by name, but I'm remembering compiler theory from the early 1970's. So I could be wrong. - -teD - Original Message From: Bernd Oppolzer Sent: Thursday, April 24, 2014 23:45 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Enterprise COBOL v5.1 and RDz v9.x You're right about the term thunk, and that it was first used in the call-by-name context, but FORTRAN was always call-by-reference, call-by-name was one of the ALGOL call mechanisms (the other one was call-by-value) http://en.wikipedia.org/wiki/Thunk_%28compatibility_mapping%29 Kind regards Bernd Am 24.04.2014 23:36, schrieb Ted MacNEIL: Early compiler writers used the term for languages that used 'call by name' sub-routines (such as FORTRAN) when something like an expression was passed. A 'thunking' routine was built by the compiler to evaluate the expression and pass a variable to the actual called sub-routine. I don't know why it's called 'thunking', but it's not a derogatory term. - -teD - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS RESMIL setting on CPU consumption
On Wed, 23 Apr 2014 04:56:28 -0500, Anthony Fletcher wrote: It is a while since there had been any discussion of appropriate values of RESMIL and its effect on CPU consumptiom. It appears that there was general concensus that RESMIL(OFF) would be a bad idea, and that RESMIL(0) would be best since it should be managed dynamically. In a 3-LPAR plex with GRS linking the 3 (not via VF) then surely whatever happens in one LPAR will happen in the other two, but does that mean that if GRS dynamically sets the RESMIL to 0 it will cause increased CPU consumption in all 3 LPARS? Might it be better to set RESMIL to, say 5 so that it never goes too far down? H. From a long association of messing with GRS ring, I've come to the conclusion that it doesn't pay to screw with GRS ring. Given your employer, you may have better access to any (apparently non-existent) lower level tools to see what is actually happening in a ring, but otherwise, it may be best to leave well enough alone. Changes to ring parameters can be difficult to remediate in need - although 3-system is certainly better than some I've seen. If you are seeing increased CPU consumption in GRS address space(s), treat that as a symptom of some other (major ?) problem, not the base problem. Rings can be very sensitive to things like small partitions - sandpit getting single digit CPU share say due to weights. And maybe even just one CPU to make it worse. Empirical evidence suggests capping events can severely adversely impact all the systems in a ring. I had protracted discussions with GRS support about this, but they were unable/unwilling to provide tools that would allow evidence to be collected. Maybe you will have better luck. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
I wrote: I don't know if I'd agree with that school of thought Tom Marchant replied: I hope that you are not suggesting that z/OS should not have been released until everything ran AMODE 64. We might still be waiting. Setting aside that thunking services are not particularly related to the construction and delivery of the z/OS product itself, did you overlook what I wrote? :-) Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Development Clueless about COBOL DEV activities
I wrote: Still wondering which IBM utility. Dana Mitchell asks: DId you see my post yesterday? I saw your guess, yes. Based on subsequent contributions to this discussion it doesn't appear to be the correct guess, but hey, you threw a dart. ;) If somebody would like to contact me offline, feel free. I can't promise resolution within any particular period of time, but I can promise there's nothing I can do unless I know which IBM utility might have a gap. Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
