Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
On 9/7/2013 10:22 AM, Tom Ross wrote: If I am reading this correctly, the BINDER would need to use a PDSE output file if there is JAVA, C/C++ type of programs. If you have native cobol, then you might be able to continue the LKED with BINDER to a non PDSE. No, the COBOL Migration Guide is correct, all COBOL programs produce GOFF output with COBOL V5, so after Binding you will have a program object and it must reside in a PDSE. I thought it was pretty clear myself, any suggestions for how we could have made it clearer? Cheers, TomR COBOL is the Language of the Future! Program objects can also be stored as z/OS UNIX files; I presume you wouldn't need PDSEs for those files then, eh? Will that work? -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Tom, Very late to this, so sorry if my concerns have been answered earlier. What about shops with a ring of monoplexes ?. The sysplex scope is each ind= ividual monoplex - but the sharing boundary is the larger GRSplex. Latch co= ntention - particularly PDSE latches - are a PITA. It also says not to share PDSEs outside of GRSplex, but this seems like it woudl work for you, since the GRSplex is your sharing boundary. It sounds like you can do the kind of sharing you need to with PDSEslet me know! Shane is talking about a ring of monoplexes that are working together in a GRSPlex. As he said, the sharing boundary is each individual monoplex. Which means that NONE of the PDSEs can be shared safely outside of the individual monoplex, no matter how big the GRSplex is. IGDSMS applies to the monoplex boundary, too, not to GRSplex boundaries. PDSE just *assumes* that systems are always in a construct where GRSplex = SYSplex, and in a ring of monoplexes that just isn't the case! This assumption has something to do with the nature of PDSE communication inside a sysplex: PDSE uses XCF communication, and that by design only works inside the sysplex, aka monoplex. Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
On Mon, 9 Sep 2013 14:28:26 -0700, Tom Ross wrote: Never too late! I need to know these answers too. Some of my customers say PDSE is not a problem, others are quite concerned, like you. Hey Tom, Barbara explained the particular issues a ring of monoplexes present. Seems IBM have disavowed the possibility that anyone would be this far behind the curve - but such sites still exist, and they have real problems. And whilst they may be considered irrelevant in the grand scheme of things to some, they help pay for my imbibing requirements;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Tom, Why convert to PDSE? I am curious? A stated IBM direction? Converting to PDSE just makes it easier to use or move to COBOL V5.1. PDSE is far better than PDS, lots of advantages, so you could view it as IBM direction, but for COBOL, that is the only thing we can do. In COBOL V5.1, we always generate parts of the object program with loadable user classes, which are only supported by Program Objects. Load Modules only support class B_TEXT or B_PRV in object programs. As Frank Swarbick suggested, it might be an option to use new PDSE Load Libraries for newer code and add the new libraries to concatenations. That would provide a one module at a time migration path, but it also might add too much complexity to application build and maintenance. The good people here on IBMMAIN would know much better than I would. Is that a reasonable option, to just start using PDSEs from one day in the future for any programs recompiled with COBOL V5.1? Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Tom, Could you share the SHARE presentations you have given on COBOL V5? Yes, thanks for the reminder! One of my TODOs has been to get our Web people to add my 2 COBOL V5 presentaitons to our resources page. I just sent them over, they should be live soon at: http://www-01.ibm.com/support/docview.wss?uid=swg21634215 Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Tom, Thank you. I like Frank's idea also Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Sep 10, 2013, at 5:44 PM, Tom Ross tmr...@stlvm20.vnet.ibm.com wrote: Tom, Why convert to PDSE? I am curious? A stated IBM direction? Converting to PDSE just makes it easier to use or move to COBOL V5.1. PDSE is far better than PDS, lots of advantages, so you could view it as IBM direction, but for COBOL, that is the only thing we can do. In COBOL V5.1, we always generate parts of the object program with loadable user classes, which are only supported by Program Objects. Load Modules only support class B_TEXT or B_PRV in object programs. As Frank Swarbick suggested, it might be an option to use new PDSE Load Libraries for newer code and add the new libraries to concatenations. That would provide a one module at a time migration path, but it also might add too much complexity to application build and maintenance. The good people here on IBMMAIN would know much better than I would. Is that a reasonable option, to just start using PDSEs from one day in the future for any programs recompiled with COBOL V5.1? Cheers, TomR COBOL is the Language of the Future! -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
I'm not saying it is a bad thing, that this requirement is now upon us. It just took me by surprise. I am glad that someone here brought it up. Other than the terrible conversion to VS COBOL II all those years ago, upgrades to the cobol compiler over the years have been pretty pain-free in the shops I have worked in. In fact, it was usually a non-event. We will get there, but the scope of the project to get there just got larger. We will have to convert more than 500 application load libraries to PDSE beforehand. I'm pretty sure that most of them will be converted with a simple DFDSS job assuming there are no invalid load modules that cannot be converted to an program object. //STEP1 EXEC PGM=ADRDSSU,REGION=8M //SYSPRINT DDSYSOUT=* //SYSIN DD* COPY DS(INC(old.PDS)) - CONVERT(PDSE(old.PDS)) - DELETE - ALLX - CATALOG - PURGE /* But there are always the few application load libraries that are always allocated it seems. There are many improvements I see too, but the resource requirements to compile have gone up too. Consider the following statement(s) in the migration guide: Compile-time storage requirements are substantially increased compared to prior versions of Enterprise COBOL. The compiler requires a minimum of 200M REGION size to run. And Compile-time CPU time requirements are substantially increased, compared to prior versions of Enterprise COBOL. The compiler may take more than four times as long to compile as the older compilers. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Sunday, September 08, 2013 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc Shane's surmise that the PDSE requirement for COBOL 5.1 executables will slow its adoption in many shops is certainly correct. All such requirements do so. Where Shane and I differ, and I suspect that this difference is visceral, is that I am radically impatient with the conservatism of these shops, which is making them irrelevant, and he is [legitimately] preoccupied with their current, detailed, operational problems. I do not, of course, deny that there are such problems. They are always with us. Nirvana will not obtain when the current batch have been resolved. They will be succeeded by others of much the same sort. The existence of a set of these problems, whatever its current makeup may be, is not, however, an argument for stasis. 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
It is true that 5.1 resource requirements for compilation [AND for binding] are greater, but the resulting program objects are measurably more efficient. Both residence time and resource usage are reduced. In an engineering shop, in which compilations are often executed only a few times, this would be unfortunate. In a COBOL shop, in which execution is very much more frequent than compilation, it strikes the right balance. 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
It is true that 5.1 resource requirements for compilation [AND for binding] are greater, but the resulting program objects are measurably more efficient. Can you point me to the data that supports that claim? Thanks. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
I see that in January the price for COBOL V3 and V4 will be raised to equal V5. So there's one reason not to upgrade that no longer exists. -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
In vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013 at 09:22 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com said: No, the COBOL Migration Guide is correct, all COBOL programs=20 produce GOFF output with COBOL V5, so after Binding you will have=20 a program object and it must reside in a PDSE. It's not the use of GOFF per se that requires program objects, it's the use of GOFF features that aren't supported in load modules. Sorry about that, you are correct. Though GOFF is new for COBOL V5.1, it is not the reason why the executables must be program objects and must be in PDSEs. I must admit I was more focused on getting people ready for COBOL V5.1, and there are really 2 things that shops can do to prepare for COBOL V5.1 without getting the product, and I have been SHAREing this information for years now: 1) Convert load libraries to PDSE if not already there 2) Expand the max region size for users who will be doing compiles with COBOL V5.1 (they will need 200M). Shops with PL/I or Fault Analyzer may have done this already, but other shops may not allow enough region size to do compiles with COBOL V5.1 Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Tom, Could you share the SHARE presentations you have given on COBOL V5? Thanks Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Monday, September 09, 2013 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc In vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013 at 09:22 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com said: No, the COBOL Migration Guide is correct, all COBOL programs=20 produce GOFF output with COBOL V5, so after Binding you will have=20 a program object and it must reside in a PDSE. It's not the use of GOFF per se that requires program objects, it's the use of GOFF features that aren't supported in load modules. Sorry about that, you are correct. Though GOFF is new for COBOL V5.1, it is not the reason why the executables must be program objects and must be in PDSEs. I must admit I was more focused on getting people ready for COBOL V5.1, and there are really 2 things that shops can do to prepare for COBOL V5.1 without getting the product, and I have been SHAREing this information for years now: 1) Convert load libraries to PDSE if not already there 2) Expand the max region size for users who will be doing compiles with COBOL V5.1 (they will need 200M). Shops with PL/I or Fault Analyzer may have done this already, but other shops may not allow enough region size to do compiles with COBOL V5.1 Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
It isn't just the raw library conversion that is an issue for large shops. It is also the plumbing, the everyday compile and debugging procedures and tools. Consider the SDLC tool to start with, which may be commercial (requiring the shop to wait on the vendor for appropriate changes and then the normal rash of testing and QA requirements before the new product version can be implemented) or which may be home-grown, requiring active changes by often scarce (and due to experienced retirements and/or layoffs, far less knowledgeable of the design and execution of the plumbing tools) internal personnel, requiring prioritization of time and talents that may or may not be available due to more pressing business requirements, or even if available, able to accomplish the needed changes in a timely manner. As usual, the devil is in the details, regardless of the desirability of the end result. Implementation bureaucracy has real value when changes can introduce instability costing clients and companies real money, but also extends the time it takes to implement even desirable results. Conservative shops, in the pejorative sense that you use, have real cost concerns that drive their conservative approach to change. Whether the ROI of a change is positive is not the issue; plumbing changes like those being introduced by COBOL 5.1 take time and talent away from legitimate, immediate business needs too. All that said, I tend to agree with you that the changes are a positive for the future. I just won't hold my breath while I wait to see them for myself. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Sunday, September 08, 2013 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc Shane's surmise that the PDSE requirement for COBOL 5.1 executables will slow its adoption in many shops is certainly correct. All such requirements do so. Where Shane and I differ, and I suspect that this difference is visceral, is that I am radically impatient with the conservatism of these shops, which is making them irrelevant, and he is [legitimately] preoccupied with their current, detailed, operational problems. I do not, of course, deny that there are such problems. They are always with us. Nirvana will not obtain when the current batch have been resolved. They will be succeeded by others of much the same sort. The existence of a set of these problems, whatever its current makeup may be, is not, however, an argument for stasis. -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
In 4ee2851a2279b94cb70cd69b17410609ae9bb...@s1flokydce2kx01.dm0001.info53.com, on 09/09/2013 at 11:53 AM, Jousma, David david.jou...@53.com said: I'm pretty sure that most of them will be converted with a simple DFDSS job If there is no PDS sharing across sysplex boundaries. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Could you share the SHARE presentations you have given on COBOL V5? You can download them from the SHARE website (www.share.org). Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
On 09/09/2013 10:08 AM, David Andrews wrote: I see that in January the price for COBOL V3 and V4 will be raised to equal V5. So there's one reason not to upgrade that no longer exists. Just a radical thought... From users' standpoint IBM could have achieved an even better impetus for migration by making V5 cheaper than V3 and V4, to compensate for installation migration costs and the likelihood that in some shops higher compile costs during program development will exceed execution-time savings from better object code optimization. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
I agree, This essentially makes in mandatory to be SMS on any volume and that means a lot of rule changes in the SMS constructs and in addition forcing SMS on just about any type of load module PDSE's. IN addition it seems to make in necessary for the whole SMS infrastructure to be in place day 1 of the new new COBOL. I am all for SMS but in a graduated fashion. Load modules PDSe's are a PITA in a lot of ways. My thinking is that there will be a lot of people NOT upgrading to the new COBOL just because of this. Ed On Sep 9, 2013, at 9:52 AM, Farley, Peter x23353 wrote: It isn't just the raw library conversion that is an issue for large shops. It is also the plumbing, the everyday compile and debugging procedures and tools. Consider the SDLC tool to start with, which may be commercial (requiring the shop to wait on the vendor for appropriate changes and then the normal rash of testing and QA requirements before the new product version can be implemented) or which may be home-grown, requiring active changes by often scarce (and due to experienced retirements and/or layoffs, far less knowledgeable of the design and execution of the plumbing tools) internal personnel, requiring prioritization of time and talents that may or may not be available due to more pressing business requirements, or even if available, able to accomplish the needed changes in a timely manner. As usual, the devil is in the details, regardless of the desirability of the end result. Implementation bureaucracy has real value when changes can introduce instability costing clients and companies real money, but also extends the time it takes to implement even desirable results. Conservative shops, in the pejorative sense that you use, have real cost concerns that drive their conservative approach to change. Whether the ROI of a change is positive is not the issue; plumbing changes like those being introduced by COBOL 5.1 take time and talent away from legitimate, immediate business needs too. All that said, I tend to agree with you that the changes are a positive for the future. I just won't hold my breath while I wait to see them for myself. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
This essentially makes in mandatory to be SMS on any volume and that means a lot of rule changes in the SMS constructs and in addition forcing SMS on just about any type of load module PDSE's. IN addition it seems to make in necessary for the whole SMS infrastructure to be in place day 1 of the new new COBOL. I am all for SMS but in a graduated fashion. Load modules PDSe's are a PITA in a lot of ways. My thinking is that there will be a lot of people NOT upgrading to the new COBOL just because of this. I am not a fan of PDSEs, but have seen no more problems with PDSE load libraries than with non-load libraries. Although I find it a bit hard to believe that after 20 years people still resist using SMS, PDSEs can be allocated on non-SMS managed volumes. It's not something I recommend, but it can be done. z/OS is intended for customers willing to spend money; that's the only way IBM can stay in business. If paying more for a compiler is a budget-buster, frankly the only solution is to start using Linux and move to entirely open source products. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
On 9/9/2013 9:58 AM, Ed Gould wrote: This essentially makes in mandatory to be SMS on any volume and that means a lot of rule changes in the SMS constructs and in addition forcing SMS on just about any type of load module PDSE's. IN addition it seems to make in necessary for the whole SMS infrastructure to be in place day 1 of the new new COBOL. I am all for SMS but in a graduated fashion. Load modules PDSe's are a PITA in a lot of ways. My thinking is that there will be a lot of people NOT upgrading to the new COBOL just because of this. SMS is not relevant to this discussion. PDSEs have not required SMS management since some ancient OS/390 release... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
On Mon, Sep 9, 2013 at 12:19 PM, Bob Shannon bshan...@rocketsoftware.comwrote: This essentially makes in mandatory to be SMS on any volume and that means a lot of rule changes in the SMS constructs and in addition forcing SMS on just about any type of load module PDSE's. IN addition it seems to make in necessary for the whole SMS infrastructure to be in place day 1 of the new new COBOL. I am all for SMS but in a graduated fashion. Load modules PDSe's are a PITA in a lot of ways. My thinking is that there will be a lot of people NOT upgrading to the new COBOL just because of this. I am not a fan of PDSEs, but have seen no more problems with PDSE load libraries than with non-load libraries. Although I find it a bit hard to believe that after 20 years people still resist using SMS, PDSEs can be allocated on non-SMS managed volumes. It's not something I recommend, but it can be done. z/OS is intended for customers willing to spend money; that's the only way IBM can stay in business. If paying more for a compiler is a budget-buster, frankly the only solution is to start using Linux and move to entirely open source products. Which is what many are doing. This company would have already gone to Windows. Except that management directly above IT has noticed the the z just keeps running and Windows applications tend to screw up on a more regular basis. And we won't go to Linux because IT management here is dedicated to a Windows monoculture. I really don't know why. Oh, yes, I've been told that Linux costs more, per server, to run than Windows. Because we run RHEL on Power boxes versus older Windows server on smaller Windows boxes. I have no idea why they don't run CentOS on Power (assuming there is a CentOS for Power). Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Around here, this is another nail in the z/OS coffin. My manager is trying to get price reductions from our current software vendors. His plea is give us an execute-only, no-support contract at a reduced price. Basically we are being stabilized at our current levels. IT management has been told, unconditionally, to reduce the budget. _Whatever it takes_! If we can't do it any other way, more layoffs _will_ be the answer. We have a bare minimum staff already. On Mon, Sep 9, 2013 at 11:20 AM, Joel C. Ewing jcew...@acm.org wrote: On 09/09/2013 10:08 AM, David Andrews wrote: I see that in January the price for COBOL V3 and V4 will be raised to equal V5. So there's one reason not to upgrade that no longer exists. Just a radical thought... From users' standpoint IBM could have achieved an even better impetus for migration by making V5 cheaper than V3 and V4, to compensate for installation migration costs and the likelihood that in some shops higher compile costs during program development will exceed execution-time savings from better object code optimization. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Right.In our case, there is not. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, September 09, 2013 12:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc In 4ee2851a2279b94cb70cd69b17410609ae9bb...@s1flokydce2kx01.dm0001.info53.com, on 09/09/2013 at 11:53 AM, Jousma, David david.jou...@53.com said: I'm pretty sure that most of them will be converted with a simple DFDSS job If there is no PDS sharing across sysplex boundaries. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
On Sat, 7 Sep 2013 21:52:07 -0400, John Gilmore wrote: Qua sysprog, I am sure thjat you are aware that PDSEs are problematic early in an IPL process; but none of these problems obtains for COBOL APs. Very late to this, so sorry if my concerns have been answered earlier. What about shops with a ring of monoplexes ?. The sysplex scope is each ind= ividual monoplex - but the sharing boundary is the larger GRSplex. Latch co= ntention - particularly PDSE latches - are a PITA. Never too late! I need to know these answers too. Some of my customers say PDSE is not a problem, others are quite concerned, like you. I did a quick search and found this: www-01.ibm.com/support/docview.wss?uid=tss1prs4280aid=1? Where it says: PDSE sharing parameters are defined in the IGDSMSxx member of SYS1.PARMLIB. You can choose a NORMAL or EXTENDED sharing option. EXTENDED provides for sharing at the member level across a sysplex, where NORMAL provides for sharing at the PDSE data set level across a sysplex. The DSNTYPE(LIBRARY) parameter will default to a PDSE definition when a library is allocated with DSORG=PO or directory block allocation request is made in the SPACE parameter. It also says not to share PDSEs outside of GRSplex, but this seems like it woudl work for you, since the GRSplex is your sharing boundary. It sounds like you can do the kind of sharing you need to with PDSEslet me know! Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Bob, I know of at least one shop that is fairly large ( 3+ 6 way sysplexes) and has a minimal SMS configuration (and some must have OS allowances for PDSe's and HFS's(ZFS) etc) but there are staunchly anti SMS (they have purchased another SMS look alike product). I honestly don't think their Backup up product doesn't really support these other SMS products either. They are mostly reliant on DASD mirroring for most of their volumes. Ed On Sep 9, 2013, at 12:19 PM, Bob Shannon wrote: This essentially makes in mandatory to be SMS on any volume and that means a lot of rule changes in the SMS constructs and in addition forcing SMS on just about any type of load module PDSE's. IN addition it seems to make in necessary for the whole SMS infrastructure to be in place day 1 of the new new COBOL. I am all for SMS but in a graduated fashion. Load modules PDSe's are a PITA in a lot of ways. My thinking is that there will be a lot of people NOT upgrading to the new COBOL just because of this. I am not a fan of PDSEs, but have seen no more problems with PDSE load libraries than with non-load libraries. Although I find it a bit hard to believe that after 20 years people still resist using SMS, PDSEs can be allocated on non-SMS managed volumes. It's not something I recommend, but it can be done. z/OS is intended for customers willing to spend money; that's the only way IBM can stay in business. If paying more for a compiler is a budget-buster, frankly the only solution is to start using Linux and move to entirely open source products. Bob Shannon Rocket Software -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
I don't know if the below would be better or worse for the shops that are concerned about converting PDSs with load modules to PDSEs with program objects, but would it not be true to say that one could, if one wished, leave all pre-COBOL5 executables in their current PDS and compile only COBOL 5 executables into a new PDSE? Of course one would need to concatenate the two in any JOBLIB/STEPLIB, but I would hope (?!?!) that these definitions would be brought in via JCL INCLUDE statements or something similar. Perhaps the latter is naive... Frank From: Tom Ross tmr...@stlvm20.vnet.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, September 9, 2013 9:18 AM Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc In vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013 at 09:22 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com said: No, the COBOL Migration Guide is correct, all COBOL programs=20 produce GOFF output with COBOL V5, so after Binding you will have=20 a program object and it must reside in a PDSE. It's not the use of GOFF per se that requires program objects, it's the use of GOFF features that aren't supported in load modules. Sorry about that, you are correct. Though GOFF is new for COBOL V5.1, it is not the reason why the executables must be program objects and must be in PDSEs. I must admit I was more focused on getting people ready for COBOL V5.1, and there are really 2 things that shops can do to prepare for COBOL V5.1 without getting the product, and I have been SHAREing this information for years now: 1) Convert load libraries to PDSE if not already there 2) Expand the max region size for users who will be doing compiles with COBOL V5.1 (they will need 200M). Shops with PL/I or Fault Analyzer may have done this already, but other shops may not allow enough region size to do compiles with COBOL V5.1 Cheers, TomR COBOL is the Language of the Future! -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Tom, Why convert to PDSE? I am curious? A stated IBM direction? Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Sep 9, 2013, at 11:18 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com wrote: In vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013 at 09:22 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com said: No, the COBOL Migration Guide is correct, all COBOL programs=20 produce GOFF output with COBOL V5, so after Binding you will have=20 a program object and it must reside in a PDSE. It's not the use of GOFF per se that requires program objects, it's the use of GOFF features that aren't supported in load modules. Sorry about that, you are correct. Though GOFF is new for COBOL V5.1, it is not the reason why the executables must be program objects and must be in PDSEs. I must admit I was more focused on getting people ready for COBOL V5.1, and there are really 2 things that shops can do to prepare for COBOL V5.1 without getting the product, and I have been SHAREing this information for years now: 1) Convert load libraries to PDSE if not already there 2) Expand the max region size for users who will be doing compiles with COBOL V5.1 (they will need 200M). Shops with PL/I or Fault Analyzer may have done this already, but other shops may not allow enough region size to do compiles with COBOL V5.1 Cheers, TomR COBOL is the Language of the Future! -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
On Sat, 7 Sep 2013 21:52:07 -0400, John Gilmore wrote: Qua sysprog, I am sure thjat you are aware that PDSEs are problematic early in an IPL process; but none of these problems obtains for COBOL APs. Very late to this, so sorry if my concerns have been answered earlier. What about shops with a ring of monoplexes ?. The sysplex scope is each individual monoplex - but the sharing boundary is the larger GRSplex. Latch contention - particularly PDSE latches - are a PITA. Tom Ross and his colleagues are to be applauded for having taken this step. It was long, long overdue; and COBOL shops are now being dragged, kicking and screaming as usual, into the last lustrum of the 20th century H - wishful thinking I suspect. There are other issues to be addressed first - I would counter that this may well slow the adoption of 5.1 in more than a few shops. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
In 0810432924290538.wa.dbohnaegonusa@listserv.ua.edu, on 09/06/2013 at 08:16 AM, Bohn, Dale db...@aegonusa.com said: The non-loaded class are only supported in the PM3(?) load modules which the binder will only put into a PDSE. Don't confuse load modules with program objects. The BINDER will only create a load module in a PDS and will only create a program object in a PDSE. The formats are pretty much unrelated. I'm not aware of any new load module features added by the BINDER; in particular, there are no long names and no classes, hence the need for the output of newer compilers to go into program objects. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
In 4ee2851a2279b94cb70cd69b17410609ae51c...@s1flokydce2kx01.dm0001.info53.com, on 09/06/2013 at 12:01 PM, Jousma, David david.jou...@53.com said: A program object is a new style GOOF executable that is the output from the binder when binding an object module from Enterprise COBOL V5.1. No. A program object is an old[1] style executable module[2] that is the output from the binder when creating an executable module in a PDSE. What is new with V5.1 is that the creation of load modules in a PDS is no longer supported. [1] But not as old as a load module. [2] Unrelated to GOFF, which is the format for object modules -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
In vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013 at 09:22 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com said: No, the COBOL Migration Guide is correct, all COBOL programs produce GOFF output with COBOL V5, so after Binding you will have a program object and it must reside in a PDSE. It's not the use of GOFF per se that requires program objects, it's the use of GOFF features that aren't supported in load modules. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Shane's surmise that the PDSE requirement for COBOL 5.1 executables will slow its adoption in many shops is certainly correct. All such requirements do so. Where Shane and I differ, and I suspect that this difference is visceral, is that I am radically impatient with the conservatism of these shops, which is making them irrelevant, and he is [legitimately] preoccupied with their current, detailed, operational problems. I do not, of course, deny that there are such problems. They are always with us. Nirvana will not obtain when the current batch have been resolved. They will be succeeded by others of much the same sort. The existence of a set of these problems, whatever its current makeup may be, is not, however, an argument for stasis. 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
If I am reading this correctly, the BINDER would need to use a PDSE output file if there is JAVA, C/C++ type of programs. If you have native cobol, then you might be able to continue the LKED with BINDER to a non PDSE. No, the COBOL Migration Guide is correct, all COBOL programs produce GOFF output with COBOL V5, so after Binding you will have a program object and it must reside in a PDSE. I thought it was pretty clear myself, any suggestions for how we could have made it clearer? Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
That would mean that all functions must be updated to use PDSE datasets rather than PDS for Cobol Compile and Load libraries. If that is correct, that will be a large change to a lot of processes in a lot of shops. I know I can use IEBCOPY to copy my current PDS loadlib to a PDSE library and then I would be good to go. However the changes to my JCL is another matter. I will most likely need to change out all of my current Load libraries in CICS, IMS, MQ, DB2, Prod batch to the new PDSE library in order to move into position for Cobol V5. Please let me know if I am mis-understanding. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Saturday, September 07, 2013 9:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc If I am reading this correctly, the BINDER would need to use a PDSE output file if there is JAVA, C/C++ type of programs. If you have native cobol, then you might be able to continue the LKED with BINDER to a non PDSE. No, the COBOL Migration Guide is correct, all COBOL programs produce GOFF output with COBOL V5, so after Binding you will have a program object and it must reside in a PDSE. I thought it was pretty clear myself, any suggestions for how we could have made it clearer? Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc
Lizette, You are not misunderstanding the situation. The documentation is clear, and Tom Ross has removed the last vestige of ambiguity (if in fact there was any). Qua sysprog, I am sure thjat you are aware that PDSEs are problematic early in an IPL process; but none of these problems obtains for COBOL APs. Tom Ross and his colleagues are to be applauded for having taken this step. It was long, long overdue; and COBOL shops are now being dragged, kicking and screaming as usual, into the last lustrum of the 20th century 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
What version of Cobol are you running now? I would also look at the migration guides for z/OS V2.1 and COBOL For cobol:http://publibfp.boulder.ibm.com/epubs/pdf/c1473830.pdf For z/OS V2.1: http://www-03.ibm.com/systems/z/os/zos/bkserv/zos_migration_manuals.html Also, see if and when Marna Walle provides a migration presentation for v2.1. And there are many system libraries that are PDS/E datasets. JES2 has some, as well as other products. So you are running PDS/Es at this time. So long as you keep your PDS/E maint up to date, you should not have issues. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 2:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
With COBOL 5.1, AFAIK, comes also the requirement of the load libraries to be PDSE. Which we DON'T have today, neither in production or test systems. You have PDSEs on your Sysres. If you run DB2 you have PDSEs. PDSEs don't have to be SMS-managed. The only problem you may have is that PDSEs cannot be shared outside of a Sysplex. They cannot be shared across Sysplexes. Otherwise once you install COBOL the library should remain untouched and should be very stable. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
A quick look in the ENT COB 5.1 migration guide does turn up this jewel... Binding (link-editing) Enterprise COBOL programs What is the difference between an object module, a load module, and a program object? An object module is the output of the compiler and input to the binder. A load module is a non-GOFF executable that is output from the binder with an Enterprise COBOL V4.2 object module. A program object is a new style GOOF executable that is the output from the binder when binding an object module from Enterprise COBOL V5.1. Are PDS and PDSE data sets allowed for object and load modules with Enterprise COBOL V5? Compiler output data sets can be PDS or PDSE, including the object module. The output of the bind step must be a PDSE. When COBOL object modules are linked (bound) they become program objects and must be stored in PDSE data sets. This is going to be a big undertaking for us. We have hundreds of application load libraries that are PDS, NOT PDSE. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.commailto:david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Don't know for COBOL, but we have some experience with PL/1 here, and as long as you don't use some of the fancier new options like RENT, DLL etc., you don't need your output libraries to be PDSEs, because the resulting load objects don't have the properties that need them to be GOFFs or program objects type 3 (PO3) - I guess, that's the difference. The Binder, AFAIK, does output into normal PDS libraries as well. But it will refuse to do so if the load objects need to be PO3 or GOFF. So I guess you have to check if you need the new options or if you can live without them. At our site, for example, we decided to stay with NORENT - our modules are all naturally reentrant - and we build classical load modules (which are limited to 16 MB in size, BTW), and so we still use normal PDS libraries. But there is a neighbor site in the same company, where all is PDSE - because of compiler options DLL and RENT. Kind regards Bernd Am 06.09.2013 14:01, schrieb Jousma, David: A quick look in the ENT COB 5.1 migration guide does turn up this jewel... Binding (link-editing) Enterprise COBOL programs What is the difference between an object module, a load module, and a program object? An object module is the output of the compiler and input to the binder. A load module is a non-GOFF executable that is output from the binder with an Enterprise COBOL V4.2 object module. A program object is a new style GOOF executable that is the output from the binder when binding an object module from Enterprise COBOL V5.1. Are PDS and PDSE data sets allowed for object and load modules with Enterprise COBOL V5? Compiler output data sets can be PDS or PDSE, including the object module. The output of the bind step must be a PDSE. When COBOL object modules are linked (bound) they become program objects and must be stored in PDSE data sets. This is going to be a big undertaking for us. We have hundreds of application load libraries that are PDS, NOT PDSE. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Dave, I think this redbook may help http://www.redbooks.ibm.com/redbooks/pdfs/sg246106.pdf The binder supports a modified extended object module, produced by the C and C++ compilers, and an entirely new object module format, called GOFF. This new object module type is described in 7.2.5, GOFF If I am reading this correctly, the BINDER would need to use a PDSE output file if there is JAVA, C/C++ type of programs. If you have native cobol, then you might be able to continue the LKED with BINDER to a non PDSE. So any process currently using BINDER for JAVA or C/C++ would most likely already be using a PDSE for the program object output. It might be possible that IBM did not document that section clearly enough (big surprise ) That is just a guess. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 5:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. A quick look in the ENT COB 5.1 migration guide does turn up this jewel... Binding (link-editing) Enterprise COBOL programs What is the difference between an object module, a load module, and a program object? An object module is the output of the compiler and input to the binder. A load module is a non-GOFF executable that is output from the binder with an Enterprise COBOL V4.2 object module. A program object is a new style GOOF executable that is the output from the binder when binding an object module from Enterprise COBOL V5.1. Are PDS and PDSE data sets allowed for object and load modules with Enterprise COBOL V5? Compiler output data sets can be PDS or PDSE, including the object module. The output of the bind step must be a PDSE. When COBOL object modules are linked (bound) they become program objects and must be stored in PDSE data sets. This is going to be a big undertaking for us. We have hundreds of application load libraries that are PDS, NOT PDSE. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.commailto:david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
I should have also included this section GOFF stands for Generalized Object File Format . It is an enhanced type of object module introduced by the binder in DFSMS/MVS 1.3 and produced by the High Level Assembler, COBOL, and C++. GOFF supports long names and multipart modules, and provides some other new features. These object modules can be stored as sequential files, as members of PDS or PDSE libraries, or as z/OS UNIX file system files. So unless the new stuff is used, you may be okay Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, September 06, 2013 5:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Dave, I think this redbook may help http://www.redbooks.ibm.com/redbooks/pdfs/sg246106.pdf The binder supports a modified extended object module, produced by the C and C++ compilers, and an entirely new object module format, called GOFF. This new object module type is described in 7.2.5, GOFF If I am reading this correctly, the BINDER would need to use a PDSE output file if there is JAVA, C/C++ type of programs. If you have native cobol, then you might be able to continue the LKED with BINDER to a non PDSE. So any process currently using BINDER for JAVA or C/C++ would most likely already be using a PDSE for the program object output. It might be possible that IBM did not document that section clearly enough (big surprise ) That is just a guess. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 5:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. A quick look in the ENT COB 5.1 migration guide does turn up this jewel... Binding (link-editing) Enterprise COBOL programs What is the difference between an object module, a load module, and a program object? An object module is the output of the compiler and input to the binder. A load module is a non-GOFF executable that is output from the binder with an Enterprise COBOL V4.2 object module. A program object is a new style GOOF executable that is the output from the binder when binding an object module from Enterprise COBOL V5.1. Are PDS and PDSE data sets allowed for object and load modules with Enterprise COBOL V5? Compiler output data sets can be PDS or PDSE, including the object module. The output of the bind step must be a PDSE. When COBOL object modules are linked (bound) they become program objects and must be stored in PDSE data sets. This is going to be a big undertaking for us. We have hundreds of application load libraries that are PDS, NOT PDSE. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.commailto:david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
I'm talking about application datasets like those in IMS etc. Historically we have bad experience from PDSE... 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 Bob Shannon Sent: Friday, September 06, 2013 1:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. With COBOL 5.1, AFAIK, comes also the requirement of the load libraries to be PDSE. Which we DON'T have today, neither in production or test systems. You have PDSEs on your Sysres. If you run DB2 you have PDSEs. PDSEs don't have to be SMS-managed. The only problem you may have is that PDSEs cannot be shared outside of a Sysplex. They cannot be shared across Sysplexes. Otherwise once you install COBOL the library should remain untouched and should be very stable. Bob Shannon Rocket Software -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Thanks, but we have gone through the documentation. What I'm out for is the *experiences* that people have. There are nearly always surprises in cases like this - at least from our hurtful experience... 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 Lizette Koehler Sent: Friday, September 06, 2013 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. What version of Cobol are you running now? I would also look at the migration guides for z/OS V2.1 and COBOL For cobol:http://publibfp.boulder.ibm.com/epubs/pdf/c1473830.pdf For z/OS V2.1: http://www-03.ibm.com/systems/z/os/zos/bkserv/zos_migration_manuals.html Also, see if and when Marna Walle provides a migration presentation for v2.1. And there are many system libraries that are PDS/E datasets. JES2 has some, as well as other products. So you are running PDS/Es at this time. So long as you keep your PDS/E maint up to date, you should not have issues. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 2:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
As always, AFAIK, but it seems that COBOL 5.1 *requires* PDSE due to it using some functionality of PDSE objects. 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 Jousma, David Sent: Friday, September 06, 2013 1:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Regarding PDSE, from migration guide: Link edit/bind changes with Enterprise COBOL Version 5.1 There have been a number of changes to link editing or binding Enterprise COBOL 5.1 programs. * The DFSMS Program Management Binder must be used to bind (link edit) Enterprise COBOL V5 applications. The Language Environment Prelinker is no longer supported. * Executables are Program Objects, not LOAD MODULES. The Program Management Loader (IEWBLDGO) is no longer supported. * Executables can not reside in PDS (only in PDSE ) * NOLOAD segments will not take storage at run time, unless Debug Tool, CEEDUMP, Fault Analyzer, Application Performance Analyzer or a 3rd-party vendor tool that uses DWARF debugging data is used Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Enterprise COBOL V5 uses DRAWF records in an non-loaded class instead of a side file as was used previously. COBOL V5 is the first of the compilers to convert to DRAWF (C already supported it), this is part of IBM's change to have all the compilers share the backend code generator ( same one used by Java JIT). The PD Tools V12 or above ( FA, DB) are required for DRAWF support. The non-loaded class are only supported in the PM3(?) load modules which the binder will only put into a PDSE. So IBM is not saying you have to convert your load libraries to PDSE, you just would be able to use any of the new compilers in the future. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Do you know if you could use PD v12 in a z/OS 1.13 system ? (If so we could implement PD v12 before taking on z/OS v2.1 and/or COBOL 5.1.) 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 Bohn, Dale Sent: Friday, September 06, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Enterprise COBOL V5 uses DRAWF records in an non-loaded class instead of a side file as was used previously. COBOL V5 is the first of the compilers to convert to DRAWF (C already supported it), this is part of IBM's change to have all the compilers share the backend code generator ( same one used by Java JIT). The PD Tools V12 or above ( FA, DB) are required for DRAWF support. The non-loaded class are only supported in the PM3(?) load modules which the binder will only put into a PDSE. So IBM is not saying you have to convert your load libraries to PDSE, you just would be able to use any of the new compilers in the future. -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Does anyone have an experience (= have used) with COBOL 5.1 and/or PD Tools under z/OS 2.1 ? Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
On Fri, 6 Sep 2013 05:34:19 -0700, Lizette Koehler wrote: The binder supports ... an entirely new object module format, called GOFF. GOFF is an enhanced form of an object module that HLASM has produced since at least HLASM 1.3 in 1998. AFAIK, GOFF is necessary for the object module (the output from the compiler) to contain things that would require that the resulting executable be a program object, but the use of GOFF does not necessarily mean that the binder can only produce a program object from it. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
We have all the PD tools at V12 on our z/os 1.12 system now. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Do you know if you could use PD v12 in a z/OS 1.13 system ? (If so we could implement PD v12 before taking on z/OS v2.1 and/or COBOL 5.1.) 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 Bohn, Dale Sent: Friday, September 06, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Enterprise COBOL V5 uses DRAWF records in an non-loaded class instead of a side file as was used previously. COBOL V5 is the first of the compilers to convert to DRAWF (C already supported it), this is part of IBM's change to have all the compilers share the backend code generator ( same one used by Java JIT). The PD Tools V12 or above ( FA, DB) are required for DRAWF support. The non-loaded class are only supported in the PM3(?) load modules which the binder will only put into a PDSE. So IBM is not saying you have to convert your load libraries to PDSE, you just would be able to use any of the new compilers in the future. -- 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
While the V12 FA, FM, DB support Enterprise COBOL V5, it will be supported in the NEXT Version of APA (4Q13). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Thanks. No problems when using them I suppose ? 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 Jousma, David Sent: Friday, September 06, 2013 3:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We have all the PD tools at V12 on our z/os 1.12 system now. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Do you know if you could use PD v12 in a z/OS 1.13 system ? (If so we could implement PD v12 before taking on z/OS v2.1 and/or COBOL 5.1.) 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 Bohn, Dale Sent: Friday, September 06, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Enterprise COBOL V5 uses DRAWF records in an non-loaded class instead of a side file as was used previously. COBOL V5 is the first of the compilers to convert to DRAWF (C already supported it), this is part of IBM's change to have all the compilers share the backend code generator ( same one used by Java JIT). The PD Tools V12 or above ( FA, DB) are required for DRAWF support. The non-loaded class are only supported in the PM3(?) load modules which the binder will only put into a PDSE. So IBM is not saying you have to convert your load libraries to PDSE, you just would be able to use any of the new compilers in the future. -- 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Thanks! 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 Bohn, Dale Sent: Friday, September 06, 2013 3:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. While the V12 FA, FM, DB support Enterprise COBOL V5, it will be supported in the NEXT Version of APA (4Q13). -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Nope. All working fine. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Thanks. No problems when using them I suppose ? Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
What perhaps needs a little more emphasis is that, while COBOL is the first, the requirements that binder output be a PDSE-resident program object will obtain for C/C++, PL/I, and LE-compatible HLASM source in the proximate future , Tom Marchant's statement begin extract . . . GOFF does not necessarily mean that the binder can only produce a program object from it. /end extract is entirely correct. It is really only relevant, however, for assembly-language programs. The V1R6 HLASM LR contains the text . . . The program object model can be created only when the GOFF option is specified. The load module option can be created when either the NOGOFF or the GOFF opotion is specified, . . . There is nothing analogous to the HLASM option alternatives NOGOFF|GOFF available for COBOL 5.1. COBOL source libraries can continue to be PDSs, but CPOBOL executables must be stored in PDSEs. This should hold no terrors for anyone. PDSEs can be highly problematic at IPL time: suppoprt for their use is not always available early enough. For COBOL APs they are technically unproblematic. They req On 9/6/13, Jousma, David david.jou...@53.com wrote: Nope. All working fine. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Thanks. No problems when using them I suppose ? Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Sorry about that. The last two paragraphs of my previous post should be There is nothing analogous to the HLASM option alternatives NOGOFF|GOFF available for COBOL 5.1. COBOL source libraries can continue to be PDSs, but COBOL executables must be stored in PDSEs. This should hold no terrors for anyone. PDSEs can be highly problematic at IPL time: suppoprt for their use is not always available early enough. For COBOL APs they are technically unproblematic. The requirement that PDSEs be used for executables may, of course, pose bureaucratic problems for some large shops, but these problems can be surmounted, and they should anyway have been addressed long ago. 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
