Re: EXTERNAL: COBOL V6.2 possible change in behavior with recent patch level
Mr Monk, I agree with you 100%and I wish everyone was on the same pagebut that’s fantasy world talking. The reality is that each data center believes that they are doing things properly...even within the same company. And each site has totally different schedules as to when software upgrades occurs, maintenance occurs or who gets upgraded box. Some sites lease their boxes and equipment, some own it...so when a contract is up comes into play or might even be a site that IBM runs compared to a site that we run...then you have Endeavor at some sites, others PDSMAN or just god old PDS's. Just keeping everyone or trying to insure everyone is using the same compiler options is a chore. But still each box generates different code from compiler...and it stinks when you get the stink eye when your change blows up and you keep claiming that you tested itunfortunately sometimes you get some bosses that aren’t mainframe savvy and things suffer. Thanks, Tom -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Saturday, March 13, 2021 6:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL: COBOL V6.2 possible change in behavior with recent patch level I used to write code for and maintain the code base of a Pension and 401k accounting system written in COBOL ... we ran at the top 6% of the banks in the USA. The way you fix your problem is you have support levels. Yes there are tons of customer with different compiler levels. BUT your company, as an organization, can have a minimum support level... Z13? OK cobol 6.2 patch level such-and-such is required to run our software. Z14? OK cobol 6.2 patch level such-and-such is required to run our software. Joe On Sat, Mar 13, 2021 at 1:52 AM Savor, Thomas < 0330b7631be3-dmarc-requ...@listserv.ua.edu> wrote: > Mr Ross, > > I'm not sure that you guys at IBM have realized that you have created > a nightmare out there in the field for a lot of customers and > especially vendors of COBOL applications. I'm a part of many that > support/write Assembler/Cobol code for a giant Credit Software system. > We have 5+ million lines of code. > > Now as a vendor, we also have "many" processing centers around the > World running our software. Some sites we run, some sites IBM runs. > Do you think that each and every site has the same box, same Z/os > level, same compiler , same maintenance level , same ARCH level or use > same OPT setting ?? All the application folks can do is recommend. > But Management and Systems Programmers tend to do what they want. > > If I'm directed that my Test box is a Z13 (and is), but my Production > box is a Z15 (it's a Z14 at this very moment). Then I'm NEVER testing > code that goes into Production EVER. And this has caused > problemssome in the form of abends, some in the form of added run > times. Its very unrealistic to think that I have to regression test > 5+ million lines of code every time maintenance to the compiler is > applied, let alone go from > 6.2 to the next Cobol release...who the hell is going to pay for this ?? > The application folks NEVER know when maintenance is going in or when > the next compiler release goes in.until after the fact. > > IBM and even System Programmers need to stop hiding behind "fix your > crap code", how about "stop changing the behavior of our programs on a whim". > > Last year we had a little very small program cause much grief after > 30+ years of NO PROBLEMS. Our release goes out to a good customer and > run time goes from 10 minutes to 1.5 hours on a transaction edit > process of 1+ million recordsterrible. We found out from our > customer thru STROBE that 95% of the time was spent in Abend Recovery > because a Leap Year date calculation routine that couldn't care less > about the result of a division compute statement...only the remainder. > But because the result was too small, program blew up, went into Abend > Recovery and continued on. Testing and UAT had no idea. This was > because of the sensitivity of the Vector Packed Decimal instructions > that were on a Z14 box. We were able to reproduce error on a Z13 with > OPT(2)but had no idea of the ramifications. > > Personally, I wish we could just stay on COBOL 4.2...but no such luck. > > Thanks, > > Tom > > > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Ross > Sent: Friday, March 12, 2021 11:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: COBOL V6.2 possible change in behavior with recent > patch level > > CAUTION: This email originated from outside of the company. Do not > click links or open attachments unless you recognize the sender and > know the content is safe. > > > > >We recently applied patches up through September 2020 to our > >Enterprise COB= OL V6.2 compiler. Prior to this we had patches > >through September 2019. Th= is appears to have changed how some code > >is gener
Re: EXTERNAL: COBOL V6.2 possible change in behavior with recent patch level
Yes. The code was buggy. I was just interested to know how the bug had gone undetected. All is good now. The bug has been fixed. From: IBM Mainframe Discussion List on behalf of Joe Monk Sent: Saturday, March 13, 2021 4:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL: COBOL V6.2 possible change in behavior with recent patch level What I find really interesting is that this whole problem could have been resolved by simply adding an "IF" condition... 01 ipt. 05 as-char pic xx. 88 as-char-10value '10'. 05 as-nums redefines as-char pic 99. 88 as-num-10 value 10. IF as-char numeric IF as-num-10 Joe On Sat, Mar 13, 2021 at 1:52 AM Savor, Thomas < 0330b7631be3-dmarc-requ...@listserv.ua.edu> wrote: > Mr Ross, > > I'm not sure that you guys at IBM have realized that you have created a > nightmare out there in the field for a lot of customers and especially > vendors of COBOL applications. I'm a part of many that support/write > Assembler/Cobol code for a giant Credit Software system. We have 5+ > million lines of code. > > Now as a vendor, we also have "many" processing centers around the World > running our software. Some sites we run, some sites IBM runs. Do you > think that each and every site has the same box, same Z/os level, same > compiler , same maintenance level , same ARCH level or use same OPT setting > ?? All the application folks can do is recommend. But Management and > Systems Programmers tend to do what they want. > > If I'm directed that my Test box is a Z13 (and is), but my Production box > is a Z15 (it's a Z14 at this very moment). Then I'm NEVER testing code > that goes into Production EVER. And this has caused problemssome > in the form of abends, some in the form of added run times. Its very > unrealistic to think that I have to regression test 5+ million lines of > code every time maintenance to the compiler is applied, let alone go from > 6.2 to the next Cobol release...who the hell is going to pay for this ?? > The application folks NEVER know when maintenance is going in or when the > next compiler release goes in.until after the fact. > > IBM and even System Programmers need to stop hiding behind "fix your crap > code", how about "stop changing the behavior of our programs on a whim". > > Last year we had a little very small program cause much grief after 30+ > years of NO PROBLEMS. Our release goes out to a good customer and run time > goes from 10 minutes to 1.5 hours on a transaction edit process of 1+ > million recordsterrible. We found out from our customer thru STROBE > that 95% of the time was spent in Abend Recovery because a Leap Year date > calculation routine that couldn't care less about the result of a division > compute statement...only the remainder. But because the result was too > small, program blew up, went into Abend Recovery and continued on. Testing > and UAT had no idea. This was because of the sensitivity of the Vector > Packed Decimal instructions that were on a Z14 box. We were able to > reproduce error on a Z13 with OPT(2)but had no idea of the > ramifications. > > Personally, I wish we could just stay on COBOL 4.2...but no such luck. > > Thanks, > > Tom > > > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Ross > Sent: Friday, March 12, 2021 11:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: COBOL V6.2 possible change in behavior with recent > patch level > > CAUTION: This email originated from outside of the company. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > >We recently applied patches up through September 2020 to our Enterprise > >COB= OL V6.2 compiler. Prior to this we had patches through September > >2019. Th= is appears to have changed how some code is generate, even > >though the compi= ler options have not changed. > > Frank, this is unfortunate, but I have to say, we do not recommend running > COBOL programs with invalid data, and we do not recommend using ZONEDATA > with other than (PFD) as the sub option. We keep finding new ways that > older COBOL behaved differently than new COBOL with invalid data, and in > the case you mention we had a customer complaining that the example you > posted ABENDed with COBOL V4 but not COBOL V6 with ZONEDATA(MIG), so we > changed the code. The intention of ZONEDATA(other than PFD) is to mimic > COBOL V4, and this is a little bit of an ongoing process. We, of course, > NEVER used to test with invalid data (data that does not match the PICTURE > and USAGE) so this is a challenging job! > > The best way to go is to correct your programs and data to follow the > rules. > For example, we had a customer recompile all programs in an application > with COBOL V6.1, but they did NOT folow
Re: WWUNTERSE for distributed platforms (especially SMF)
On 14/03/2021 2:32 am, Robert Prins wrote: Unlike PCTERSE the program and IBMs offering it doesn't do any EBCDIC-ASCII translation... Why hasn't it been released as open source under the same license, after all it's just decompression code, and given the note in the User's Guide, "The decompress function of TERSE was recently ported to Java by IBM and it is available under the Apache 2.0 license and is available here. However, that program doesn’t support VBS format either." so that those with the knowledge can add features like EBCDIC-ASCII translation, or incorporate the code into something with a GUI? After a discussion with Mario at SHARE last year and some assistance since I have been working on updating the open source Java code to support variable length binary records. I have it working, I have just been very slow to update the documentation and contribute it back to the original repository. You can see my changes here: https://github.com/andrew890/tersedecompress What I would like to do is make it available as a class that can be used from other applications, not just a command line application. Some of the changes and refactoring have been done with that goal in mind. A secondary goal is a port to C# so it could run under .NET (Windows and other platforms). But *why* do you want it to translate EBCDIC->ASCII? The current implementation does that, but I haven't figured out why. It makes testing much more complicated. It seems like it would be much better to do the translation outside of an UNTERSE implementation, and have the compression code give you back exactly the same data that was compressed. Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LISTCAT output information in XML or JSON
Thanks. I don't have access to DB2. And I don't really know what a UDTF is (User Defined Table ). But the code would be interesting to look at. I'm a decent HLASM programmer, so hopefully I'll understand it. On Sat, Mar 13, 2021 at 1:38 AM Salva Carrasco wrote: > I wrote an assembler UDTF for Db2 that retrieve list of cataloged datasets > based on mask/type using the CSI. > > Can share it if you are interested. > > -- > 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: lost mainframe info - Resolved - Maintec Technologies
Thank you for your assistance in locating them Charles. On Sat, Mar 13, 2021 at 6:48 AM Charles Mills wrote: > Sonny and Maintec are GREAT to work with! > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sonny Gupta > Sent: Saturday, March 13, 2021 2:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: lost mainframe info - Resolved - Maintec Technologies > > To All, I have contacted Stan privately and provided him with Logon > information. He was able to logon and hopefully he will take over the > client's (who passed away recently) Business & Clients. We are currently > running on z12 Mainframe & soon to migrate to z/OS 2.4. Do let us if anyone > has requirement for testing/development or LPAR/Dedicated environment for > production. > > We are working on a potential opportunity to bring in a Z15-T01 (A02 > Capacity Marker) Mainframe and are considering creating/posting a short > video from the time truck delivers the Mainframe, until we are able to > logon to TSO... > > Thanks > > Sonny Gupta > Maintec Technologies, Inc > Raleigh, NC > www.maintec.com > 919-424-6323 > > -- > 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: lost mainframe info - Resolved - Maintec Technologies
Sonny and Maintec are GREAT to work with! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sonny Gupta Sent: Saturday, March 13, 2021 2:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: lost mainframe info - Resolved - Maintec Technologies To All, I have contacted Stan privately and provided him with Logon information. He was able to logon and hopefully he will take over the client's (who passed away recently) Business & Clients. We are currently running on z12 Mainframe & soon to migrate to z/OS 2.4. Do let us if anyone has requirement for testing/development or LPAR/Dedicated environment for production. We are working on a potential opportunity to bring in a Z15-T01 (A02 Capacity Marker) Mainframe and are considering creating/posting a short video from the time truck delivers the Mainframe, until we are able to logon to TSO... Thanks Sonny Gupta Maintec Technologies, Inc Raleigh, NC www.maintec.com 919-424-6323 -- 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: WWUNTERSE for distributed platforms (especially SMF)
On 2021-03-09 20:43, Cheryl Watson wrote: I hope this isn't considered advertising if it's for a free product, but we'd like to announce our new WWUNTERSE (no-charge) product. To address this need, and because we spent a lot of our own time moving SMF data around, our colleague Mario Bezzi created a program called WWUNTERSE. WWUNTERSE runs on Windows and Linux. It can process tersed files that were created from VBS files. It also supports tersed versions of F, FB, V, VB, and VBS files. And it provides the option to include the Block Descriptor Word (BDW) in the output file (as required by MXG/SAS on distributed systems). And the best news of all is that there is no charge for WWUNTERSE. It is available for download now, from the Free Tools page of the Watson & Walker public website at https://watsonwalker.com/software/free-tools/. Please take it for a test drive and let us know what you think. Unlike PCTERSE the program and IBMs offering it doesn't do any EBCDIC-ASCII translation... Why hasn't it been released as open source under the same license, after all it's just decompression code, and given the note in the User's Guide, "The decompress function of TERSE was recently ported to Java by IBM and it is available under the Apache 2.0 license and is available here. However, that program doesn’t support VBS format either." so that those with the knowledge can add features like EBCDIC-ASCII translation, or incorporate the code into something with a GUI? Robert -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather - https://prino.neocities.org/indez.html Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html -- Robert AH Prins robert.ah.prins(a)gmail.com The hitchhiking grandfather - https://prino.neocities.org/ Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: COBOL V6.2 possible change in behavior with recent patch level
I used to write code for and maintain the code base of a Pension and 401k accounting system written in COBOL ... we ran at the top 6% of the banks in the USA. The way you fix your problem is you have support levels. Yes there are tons of customer with different compiler levels. BUT your company, as an organization, can have a minimum support level... Z13? OK cobol 6.2 patch level such-and-such is required to run our software. Z14? OK cobol 6.2 patch level such-and-such is required to run our software. Joe On Sat, Mar 13, 2021 at 1:52 AM Savor, Thomas < 0330b7631be3-dmarc-requ...@listserv.ua.edu> wrote: > Mr Ross, > > I'm not sure that you guys at IBM have realized that you have created a > nightmare out there in the field for a lot of customers and especially > vendors of COBOL applications. I'm a part of many that support/write > Assembler/Cobol code for a giant Credit Software system. We have 5+ > million lines of code. > > Now as a vendor, we also have "many" processing centers around the World > running our software. Some sites we run, some sites IBM runs. Do you > think that each and every site has the same box, same Z/os level, same > compiler , same maintenance level , same ARCH level or use same OPT setting > ?? All the application folks can do is recommend. But Management and > Systems Programmers tend to do what they want. > > If I'm directed that my Test box is a Z13 (and is), but my Production box > is a Z15 (it's a Z14 at this very moment). Then I'm NEVER testing code > that goes into Production EVER. And this has caused problemssome > in the form of abends, some in the form of added run times. Its very > unrealistic to think that I have to regression test 5+ million lines of > code every time maintenance to the compiler is applied, let alone go from > 6.2 to the next Cobol release...who the hell is going to pay for this ?? > The application folks NEVER know when maintenance is going in or when the > next compiler release goes in.until after the fact. > > IBM and even System Programmers need to stop hiding behind "fix your crap > code", how about "stop changing the behavior of our programs on a whim". > > Last year we had a little very small program cause much grief after 30+ > years of NO PROBLEMS. Our release goes out to a good customer and run time > goes from 10 minutes to 1.5 hours on a transaction edit process of 1+ > million recordsterrible. We found out from our customer thru STROBE > that 95% of the time was spent in Abend Recovery because a Leap Year date > calculation routine that couldn't care less about the result of a division > compute statement...only the remainder. But because the result was too > small, program blew up, went into Abend Recovery and continued on. Testing > and UAT had no idea. This was because of the sensitivity of the Vector > Packed Decimal instructions that were on a Z14 box. We were able to > reproduce error on a Z13 with OPT(2)but had no idea of the > ramifications. > > Personally, I wish we could just stay on COBOL 4.2...but no such luck. > > Thanks, > > Tom > > > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Ross > Sent: Friday, March 12, 2021 11:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: COBOL V6.2 possible change in behavior with recent > patch level > > CAUTION: This email originated from outside of the company. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > >We recently applied patches up through September 2020 to our Enterprise > >COB= OL V6.2 compiler. Prior to this we had patches through September > >2019. Th= is appears to have changed how some code is generate, even > >though the compi= ler options have not changed. > > Frank, this is unfortunate, but I have to say, we do not recommend running > COBOL programs with invalid data, and we do not recommend using ZONEDATA > with other than (PFD) as the sub option. We keep finding new ways that > older COBOL behaved differently than new COBOL with invalid data, and in > the case you mention we had a customer complaining that the example you > posted ABENDed with COBOL V4 but not COBOL V6 with ZONEDATA(MIG), so we > changed the code. The intention of ZONEDATA(other than PFD) is to mimic > COBOL V4, and this is a little bit of an ongoing process. We, of course, > NEVER used to test with invalid data (data that does not match the PICTURE > and USAGE) so this is a challenging job! > > The best way to go is to correct your programs and data to follow the > rules. > For example, we had a customer recompile all programs in an application > with COBOL V6.1, but they did NOT folow our 2-compile 2-test migration > process to find and clean up invalid data. The results o their regression > tests were OK, so they went into production! All was well until they moved > to COBOL V6.2 to compile with ARCH(12) and exploit z14. At that poi
Re: EXTERNAL: COBOL V6.2 possible change in behavior with recent patch level
What I find really interesting is that this whole problem could have been resolved by simply adding an "IF" condition... 01 ipt. 05 as-char pic xx. 88 as-char-10value '10'. 05 as-nums redefines as-char pic 99. 88 as-num-10 value 10. IF as-char numeric IF as-num-10 Joe On Sat, Mar 13, 2021 at 1:52 AM Savor, Thomas < 0330b7631be3-dmarc-requ...@listserv.ua.edu> wrote: > Mr Ross, > > I'm not sure that you guys at IBM have realized that you have created a > nightmare out there in the field for a lot of customers and especially > vendors of COBOL applications. I'm a part of many that support/write > Assembler/Cobol code for a giant Credit Software system. We have 5+ > million lines of code. > > Now as a vendor, we also have "many" processing centers around the World > running our software. Some sites we run, some sites IBM runs. Do you > think that each and every site has the same box, same Z/os level, same > compiler , same maintenance level , same ARCH level or use same OPT setting > ?? All the application folks can do is recommend. But Management and > Systems Programmers tend to do what they want. > > If I'm directed that my Test box is a Z13 (and is), but my Production box > is a Z15 (it's a Z14 at this very moment). Then I'm NEVER testing code > that goes into Production EVER. And this has caused problemssome > in the form of abends, some in the form of added run times. Its very > unrealistic to think that I have to regression test 5+ million lines of > code every time maintenance to the compiler is applied, let alone go from > 6.2 to the next Cobol release...who the hell is going to pay for this ?? > The application folks NEVER know when maintenance is going in or when the > next compiler release goes in.until after the fact. > > IBM and even System Programmers need to stop hiding behind "fix your crap > code", how about "stop changing the behavior of our programs on a whim". > > Last year we had a little very small program cause much grief after 30+ > years of NO PROBLEMS. Our release goes out to a good customer and run time > goes from 10 minutes to 1.5 hours on a transaction edit process of 1+ > million recordsterrible. We found out from our customer thru STROBE > that 95% of the time was spent in Abend Recovery because a Leap Year date > calculation routine that couldn't care less about the result of a division > compute statement...only the remainder. But because the result was too > small, program blew up, went into Abend Recovery and continued on. Testing > and UAT had no idea. This was because of the sensitivity of the Vector > Packed Decimal instructions that were on a Z14 box. We were able to > reproduce error on a Z13 with OPT(2)but had no idea of the > ramifications. > > Personally, I wish we could just stay on COBOL 4.2...but no such luck. > > Thanks, > > Tom > > > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Ross > Sent: Friday, March 12, 2021 11:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: COBOL V6.2 possible change in behavior with recent > patch level > > CAUTION: This email originated from outside of the company. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > >We recently applied patches up through September 2020 to our Enterprise > >COB= OL V6.2 compiler. Prior to this we had patches through September > >2019. Th= is appears to have changed how some code is generate, even > >though the compi= ler options have not changed. > > Frank, this is unfortunate, but I have to say, we do not recommend running > COBOL programs with invalid data, and we do not recommend using ZONEDATA > with other than (PFD) as the sub option. We keep finding new ways that > older COBOL behaved differently than new COBOL with invalid data, and in > the case you mention we had a customer complaining that the example you > posted ABENDed with COBOL V4 but not COBOL V6 with ZONEDATA(MIG), so we > changed the code. The intention of ZONEDATA(other than PFD) is to mimic > COBOL V4, and this is a little bit of an ongoing process. We, of course, > NEVER used to test with invalid data (data that does not match the PICTURE > and USAGE) so this is a challenging job! > > The best way to go is to correct your programs and data to follow the > rules. > For example, we had a customer recompile all programs in an application > with COBOL V6.1, but they did NOT folow our 2-compile 2-test migration > process to find and clean up invalid data. The results o their regression > tests were OK, so they went into production! All was well until they moved > to COBOL V6.2 to compile with ARCH(12) and exploit z14. At that point they > discovered they had some invalid data processing that started causing new > ABENDs with Vector Packed Decimal instructi
Re: lost mainframe info - Resolved - Maintec Technologies
To All, I have contacted Stan privately and provided him with Logon information. He was able to logon and hopefully he will take over the client's (who passed away recently) Business & Clients. We are currently running on z12 Mainframe & soon to migrate to z/OS 2.4. Do let us if anyone has requirement for testing/development or LPAR/Dedicated environment for production. We are working on a potential opportunity to bring in a Z15-T01 (A02 Capacity Marker) Mainframe and are considering creating/posting a short video from the time truck delivers the Mainframe, until we are able to logon to TSO... Thanks Sonny Gupta Maintec Technologies, Inc Raleigh, NC www.maintec.com 919-424-6323 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
