Re: Problems that occur in production
Basic rule of the universe. Right is a very very small subset of all possiblities. Wrong is an almost infinite superset consisting of everything except what is Right. Wherever possible test for right and reject everything else. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On 4 Aug 2008 12:08:38 -0700, [EMAIL PROTECTED] (John Mattson) wrote: Basic rule of the universe. Right is a very very small subset of all possiblities. Wrong is an almost infinite superset consisting of everything except what is Right. Wherever possible test for right and reject everything else. Of course when our work is supposed to be right for users, management, government, customers, the enterprise, and stay right as conditions change - defining this right is problematical. Most all wars these days are fought between people who are Right (and Righteous). Most of the most political hatred is between people who are Right.And every time we have a committee setting up requirements for a new system, we have acrimony as different needs and wants conflict. That said - the big problem with programmer unit testing is that we tend to be to focused on testing what we think is right. The everything else category doesn't get enough testing, as it is much more poorly defined. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
snip I think this whole approach is WRONG! There are a lot of problems that occur in production. Rather, hire trained professionals that: 1. Know how to do their job. 2. Know how to problem solve. 3. Employ best practices. The documentation of everything that could go wrong is a never-ending task. I thought I saw it all over the last 27 years. But, somebody always comes along with somethin new to prove me wrong. unsnip-- One of the permutations of Murphy's Law says that if you design an input editor to reject all bad input, some engenious idiot will manage to get bad input through it anyway. And unfortunately, it's so very true! --- The only time politicians tell the truth is when they're calling each other liars. :-)) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Numeric test in COBOL was Re: Problems that occur in production
On 30 Jul 2008 01:47:07 -0700, in bit.listserv.ibm-main you wrote: On Thu, 26 Jun 2008 07:58:34 -0500, McKown, John [EMAIL PROTECTED] wrote: How about: 1) Check all I/O statements for correct execution (COBOL FILE STATUS). This includes OPEN and CLOSE. If the file is a VSAM file, then be sure to put the VSAM FILE STATUS in any messages in addition to the normal FILE STATUS. This can be a life saver. As an example, we had a normal FILE STATUS say something like record too large. Programmer went crazy looking at the record. The actual problem was that the record being added was updating the keys in an AIX and there were too many base keys for the alternate key. The record too large was the AIX record, not the data record. 2) Check for overflow / underflow in all arithmetic operations with an ON SIZE ERROR clause. Unless, of course, you want to silently loose any high order digits. I think this will also catch division by 0 errors. 3) Verify that PIC 9 USAGE DISPLAY or PACKED-DECIMAL actually contain valid decimal information before using, unless you can be assured that they cannot be incorrect. The only way that I can think of to do this is if the data comes from somethink like DB2 which enforces correctness. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology Hello John, I apologize to answer you so late. Thank you for the information. In point 3, do you mean that each variable defined with these usage clauses must be checked before to be read? I would have thought that it was sufficient to use the IF var IS NUMERIC statement when a PIC X is assigned to a PIC 9 variable. What are you thinking about this? You should always use the IF NUMERIC test against the field description of the numeric as it should be. This means that PIC 99, PIC S99 and PIC S99 SIGN IS SEPARATE will give different results because a negative value is not numeric for PIC 99 and the sign can't be a zone overlay (1J is -11 if the PIC is S99 without SIGN IS SEPARATE). See your manual for how SIGN IS SEPARATE is handled. Do you think that potential bugs can be generated by bad redefines clauses? Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On Sun, 3 Aug 2008 22:43:57 +, Ted MacNEIL wrote: I think this whole approach is WRONG! There are a lot of problems that occur in production. ` Rather, hire trained professionals that: 1. Know how to do their job. 2. Know how to problem solve. 3. Employ best practices. The documentation of everything that could go wrong is a never-ending task. I thought I saw it all over the last 27 years. But, somebody always comes along with somethin new to prove me wrong. I have seen a myopic approach to validating input, consisting of: o Test for all the ways the programmer can envision that the input can be incorrect. o If none match, then assume the input is correct. Versus: o Test for the few constructs the specification permits as correct input. o If none match, the input is incorrect. I've seen extreme cases, such as, validating that a string is alphameric by: o Testing that it contains no spaces; o Testing that it contains no commas; o Testing that it contains no parentheses; ... This can produce very explicit diagnostics, such as ILLEGAL USE OF PERIOD IN PARAMETER, but if the adversary has the source code he can readily break it by supplying incorrect input the coder didn't anticipate. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
I heard the observation long ago that the hardest area of programming is error handling, whether dealing with the deepest levels of the OS or 'simple' end user application input. At some point in development it comes down to - imagining what could go wrong - writing some sort of exception routine - testing the routine under artificially contrived conditions The last one is vastly complicated by the prospect that multiple error conditions might occur in combination. Yikes! We all write code to handle the expected. How far we go--or have the ability to go--in managing the unexpected depends on factors ranging from developer experience to budgetary constraints. Hmm. I hope airliner development gets unlimited budget. ;-) . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Paul Gilmartin [EMAIL PROTECTED] .COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: Problems that occur in production 08/03/2008 04:28 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU On Sun, 3 Aug 2008 22:43:57 +, Ted MacNEIL wrote: I think this whole approach is WRONG! There are a lot of problems that occur in production. ` Rather, hire trained professionals that: 1. Know how to do their job. 2. Know how to problem solve. 3. Employ best practices. The documentation of everything that could go wrong is a never-ending task. I thought I saw it all over the last 27 years. But, somebody always comes along with somethin new to prove me wrong. I have seen a myopic approach to validating input, consisting of: o Test for all the ways the programmer can envision that the input can be incorrect. o If none match, then assume the input is correct. Versus: o Test for the few constructs the specification permits as correct input. o If none match, the input is incorrect. I've seen extreme cases, such as, validating that a string is alphameric by: o Testing that it contains no spaces; o Testing that it contains no commas; o Testing that it contains no parentheses; ... This can produce very explicit diagnostics, such as ILLEGAL USE OF PERIOD IN PARAMETER, but if the adversary has the source code he can readily break it by supplying incorrect input the coder didn't anticipate. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
User guides are full of how to do things correctly. On Wed, 30 Jul 2008 04:07:30 -0500, J. Chiampi [EMAIL PROTECTED] wrote: Do you want someone to give you a list of of silly things not to do like divide by zero, use non-numeric fields in numeric operations, don't use subscripts wisely, and ignore checking file-status/SQLCODE/return code? Hello, I agree with you that it is very interesting to check if return codes are used. I can detect potential severe bugs like this. About your last question, it could be useful if you have a list of silly things not to do. Do you have such a list? Even if it is partial, it would be interesting. Thanks in advance. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On Thu, 26 Jun 2008 07:58:34 -0500, McKown, John [EMAIL PROTECTED] wrote: How about: 1) Check all I/O statements for correct execution (COBOL FILE STATUS). This includes OPEN and CLOSE. If the file is a VSAM file, then be sure to put the VSAM FILE STATUS in any messages in addition to the normal FILE STATUS. This can be a life saver. As an example, we had a normal FILE STATUS say something like record too large. Programmer went crazy looking at the record. The actual problem was that the record being added was updating the keys in an AIX and there were too many base keys for the alternate key. The record too large was the AIX record, not the data record. 2) Check for overflow / underflow in all arithmetic operations with an ON SIZE ERROR clause. Unless, of course, you want to silently loose any high order digits. I think this will also catch division by 0 errors. 3) Verify that PIC 9 USAGE DISPLAY or PACKED-DECIMAL actually contain valid decimal information before using, unless you can be assured that they cannot be incorrect. The only way that I can think of to do this is if the data comes from somethink like DB2 which enforces correctness. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology Hello John, I apologize to answer you so late. Thank you for the information. In point 3, do you mean that each variable defined with these usage clauses must be checked before to be read? I would have thought that it was sufficient to use the IF var IS NUMERIC statement when a PIC X is assigned to a PIC 9 variable. What are you thinking about this? Do you think that potential bugs can be generated by bad redefines clauses? Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On Sat, 28 Jun 2008 10:41:03 -0500, Kenneth E Tomiak [EMAIL PROTECTED] wrote: Any language can have problems if the author lacks basic programming skills for error handling. Make sure data is correct and use every available file- status/SQLCODE/return code instead of assuming an operation worked. It will bloat your code and make it run longer than not taking such precautions. Even check file-status on a WRITE as you may have run out of space. How many programmers ever do that? The best system design principles I learned are that the programs handling data input handle validation, so that the other programs that merely handle data do not have to revalidate what is supposed to be already validated data. That reduces the run-time of the back end programs but raises the risk some future design change will get overlooked as to all of the affected programs and an abend will be in your future. Every program sstill needs to check file- status/SQLCODE/return code for the potential of a problem. Do you want someone to give you a list of of silly things not to do like divide by zero, use non-numeric fields in numeric operations, don't use subscripts wisely, and ignore checking file-status/SQLCODE/return code? Hello, I agree with you that it is very interesting to check if return codes are used. I can detect potential severe bugs like this. About your last question, it could be useful if you have a list of silly things not to do. Do you have such a list? Even if it is partial, it would be interesting. Thanks in advance. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
Any language can have problems if the author lacks basic programming skills for error handling. Make sure data is correct and use every available file- status/SQLCODE/return code instead of assuming an operation worked. It will bloat your code and make it run longer than not taking such precautions. Even check file-status on a WRITE as you may have run out of space. How many programmers ever do that? The best system design principles I learned are that the programs handling data input handle validation, so that the other programs that merely handle data do not have to revalidate what is supposed to be already validated data. That reduces the run-time of the back end programs but raises the risk some future design change will get overlooked as to all of the affected programs and an abend will be in your future. Every program sstill needs to check file- status/SQLCODE/return code for the potential of a problem. Do you want someone to give you a list of of silly things not to do like divide by zero, use non-numeric fields in numeric operations, don't use subscripts wisely, and ignore checking file-status/SQLCODE/return code? On Fri, 20 Jun 2008 08:58:07 -0500, J. Chiampi [EMAIL PROTECTED] wrote: Hello, I'm looking for information about problems that could occur in production with Cobol programs and that could generate abend. I would like to find a description and how to prevent them before they occur. For instance, I think that it could be interesting to avoid moving alphanumeric variables into numeric variable without checking them by using a IF NUMERIC or moving data into another that is shorter or avoid closing file or never check array boundaries... Do you see other important cases related to performance or robustness? Thanks in advance. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
Ok. This should be interesting and not very difficult to check. Other ideas? Thanks. Regards On Wed, 25 Jun 2008 14:47:55 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: This has bit us several times in the past. If I remember correctly it caused various 0C4 and 0C1 type abends. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of J. Chiampi Sent: Wednesday, June 25, 2008 12:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Problems that occur in production On Wed, 25 Jun 2008 08:49:56 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: How about calling a program and passing the wrong number of PARMS in the linkage section? The receiving program expects 3 but you only pass two and vice versa... Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 Hello, Yes and it could interesting to compare the size of parms that are sended with the size of parms that are expected in called subprogram, no? Did you already encounter such a problem? As a result, is there an abend or an unexpected behavior? Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
How about: 1) Check all I/O statements for correct execution (COBOL FILE STATUS). This includes OPEN and CLOSE. If the file is a VSAM file, then be sure to put the VSAM FILE STATUS in any messages in addition to the normal FILE STATUS. This can be a life saver. As an example, we had a normal FILE STATUS say something like record too large. Programmer went crazy looking at the record. The actual problem was that the record being added was updating the keys in an AIX and there were too many base keys for the alternate key. The record too large was the AIX record, not the data record. 2) Check for overflow / underflow in all arithmetic operations with an ON SIZE ERROR clause. Unless, of course, you want to silently loose any high order digits. I think this will also catch division by 0 errors. 3) Verify that PIC 9 USAGE DISPLAY or PACKED-DECIMAL actually contain valid decimal information before using, unless you can be assured that they cannot be incorrect. The only way that I can think of to do this is if the data comes from somethink like DB2 which enforces correctness. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On Tue, 24 Jun 2008 14:20:03 -0600, Howard Brazee [EMAIL PROTECTED] wrote: On 24 Jun 2008 12:55:15 -0700, [EMAIL PROTECTED] (Ed Philbrook) wrote: Comparing a subscript that had just changed to its maximum value before using it in any other operation would prevent the majority of abends and storage violations at my current facility. Of course, in the event that the maximum is exceeded, an orderly termination with the proper notifications must be coded for. What's funny is that shops have old, old, old standards that compile CoBOL without SSRANGE (for efficiency). Many of those shops fell in love with PL/I because boundary checking was automatic. It was just as expensive though. As time goes by, the costs of not having SSRANGE, get bigger and bigger (relative to the cost of implementing it), but the person who set the standard has been replaced a dozen times, and the standard lives on. Ok. I am going to see how to take your suggestion into account. And about data manipulation, I thought to the following checks: - a data is moved into another that has a shorter size (it will be truncated or it could override other data) - a PIC X is moved into a PIC 9 without test IF NUMERIC - a data is redefined and one of its numeric field is redefined in several fields - size of FD is not equal to size defined in JCL (LRECL) - a file is read but it has not been opened - some numeric conversions could lead to lost of accuracy, no ? Same with arithmetic statements, I suppose. What are you thinking about this? Other ideas? Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
How about calling a program and passing the wrong number of PARMS in the linkage section? The receiving program expects 3 but you only pass two and vice versa... Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On Wed, 25 Jun 2008 08:49:56 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: How about calling a program and passing the wrong number of PARMS in the linkage section? The receiving program expects 3 but you only pass two and vice versa... Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 Hello, Yes and it could interesting to compare the size of parms that are sended with the size of parms that are expected in called subprogram, no? Did you already encounter such a problem? As a result, is there an abend or an unexpected behavior? Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
This has bit us several times in the past. If I remember correctly it caused various 0C4 and 0C1 type abends. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of J. Chiampi Sent: Wednesday, June 25, 2008 12:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Problems that occur in production On Wed, 25 Jun 2008 08:49:56 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: How about calling a program and passing the wrong number of PARMS in the linkage section? The receiving program expects 3 but you only pass two and vice versa... Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 Hello, Yes and it could interesting to compare the size of parms that are sended with the size of parms that are expected in called subprogram, no? Did you already encounter such a problem? As a result, is there an abend or an unexpected behavior? Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On Fri, 20 Jun 2008 11:07:44 -0600, Steve Comstock [EMAIL PROTECTED] wrote: J. Chiampi wrote: Hello, I'm looking for information about problems that could occur in production with Cobol programs and that could generate abend. I would like to find a description and how to prevent them before they occur. For instance, I think that it could be interesting to avoid moving alphanumeric variables into numeric variable without checking them by using a IF NUMERIC or moving data into another that is shorter or avoid closing file or never check array boundaries... Do you see other important cases related to performance or robustness? Thanks in advance. Regards You could use LE condition handling to trap errors and handle them in some installation-specified standard way. In our course Enterprise COBOL Update I: Essentials we have a lab that builds and uses a condition handler to intercept most errors; the classroom version just lets the program continue; in real life, of course, you would take more severe actions. But at least we demo how to intercept and analyze conditions that arise. Check out http://www.trainersfriend.com/COBOL_Courses/d704descr.htm Kind regards, -Steve Comstock The Trainer's Friend, Inc. Thanks for your response. I totally agree with you. My objective is to prevent bugs that regularly occur and to deliver reports for developers. What I would like to do is: - identify common problems that occur regularly in production and that lead to abends - detect them with some automated routines running on Cobol source code - provide reports with impacted code location, short explanation of the problem and a solution So I'm interesting if you have information about bugs that are interesting to take into account in order to help developer work and to increase the quality of application. I do not have enough experience on this. I ask this question to all experienced developers. Thanks in advance. Regards Jerome Chiampi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
Hello, Comparing a subscript that had just changed to its maximum value before using it in any other operation would prevent the majority of abends and storage violations at my current facility. Of course, in the event that the maximum is exceeded, an orderly termination with the proper notifications must be coded for. EdP J. Chiampi [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 06/24/2008 02:21 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Problems that occur in production On Fri, 20 Jun 2008 11:07:44 -0600, Steve Comstock [EMAIL PROTECTED] wrote: J. Chiampi wrote: Hello, I'm looking for information about problems that could occur in production with Cobol programs and that could generate abend. I would like to find a description and how to prevent them before they occur. For instance, I think that it could be interesting to avoid moving alphanumeric variables into numeric variable without checking them by using a IF NUMERIC or moving data into another that is shorter or avoid closing file or never check array boundaries... Do you see other important cases related to performance or robustness? Thanks in advance. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On 24 Jun 2008 12:55:15 -0700, [EMAIL PROTECTED] (Ed Philbrook) wrote: Comparing a subscript that had just changed to its maximum value before using it in any other operation would prevent the majority of abends and storage violations at my current facility. Of course, in the event that the maximum is exceeded, an orderly termination with the proper notifications must be coded for. What's funny is that shops have old, old, old standards that compile CoBOL without SSRANGE (for efficiency). Many of those shops fell in love with PL/I because boundary checking was automatic. It was just as expensive though. As time goes by, the costs of not having SSRANGE, get bigger and bigger (relative to the cost of implementing it), but the person who set the standard has been replaced a dozen times, and the standard lives on. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Problems that occur in production
Hello, I'm looking for information about problems that could occur in production with Cobol programs and that could generate abend. I would like to find a description and how to prevent them before they occur. For instance, I think that it could be interesting to avoid moving alphanumeric variables into numeric variable without checking them by using a IF NUMERIC or moving data into another that is shorter or avoid closing file or never check array boundaries... Do you see other important cases related to performance or robustness? Thanks in advance. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
In a message dated 6/20/2008 8:58:40 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: a IF NUMERIC or moving data into another that is shorter or avoid closing file or never check array boundaries... Do you see other important cases related to performance or robustness? Thanks in advance. Regression testing is a long time science. There are tools and methodologies for just about every facet of IT. Google for Regression testing software. One that looked promising and get a triple buzzword bingo pretty rapidly: _http://www.rttsweb.com/services/?_kk=regression%20testing_kt=80adb2a4-6141-4 804-8056-9a508e440316gclid=CNDYh5-qg5QCFRGHQAodEyedVw_ (http://www.rttsweb.com/services/?_kk=regression%20testing_kt=80adb2a4-6141-4804-8056-9a508e440316; gclid=CNDYh5-qg5QCFRGHQAodEyedVw) **Gas prices getting you down? Search AOL Autos for fuel-efficient used cars. (http://autos.aol.com/used?ncid=aolaut000507) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
J. Chiampi wrote: Hello, I'm looking for information about problems that could occur in production with Cobol programs and that could generate abend. I would like to find a description and how to prevent them before they occur. For instance, I think that it could be interesting to avoid moving alphanumeric variables into numeric variable without checking them by using a IF NUMERIC or moving data into another that is shorter or avoid closing file or never check array boundaries... Do you see other important cases related to performance or robustness? Thanks in advance. Regards You could use LE condition handling to trap errors and handle them in some installation-specified standard way. In our course Enterprise COBOL Update I: Essentials we have a lab that builds and uses a condition handler to intercept most errors; the classroom version just lets the program continue; in real life, of course, you would take more severe actions. But at least we demo how to intercept and analyze conditions that arise. Check out http://www.trainersfriend.com/COBOL_Courses/d704descr.htm Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
