checking if NUMERIC
in [Cobol]
|
From: Clark F Morris on 26 Jan 2008 18:56 On Sun, 21 Oct 2007 18:33:22 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message >news:1eASi.226775$vo5.15659(a)fe04.news.easynews.com... >>I certainly don't want to claim your "opinions" are wrong - however, I just >>don't agree with them (exactly). > >No problem. I didn't expect agreement; neither do I expect everyone to >understand why I hold such an opinion... :-) > >COBOL is *designed* so that you can put data >> into "numerically defined" fields and THEN validate them (before using >> them). I am "used to" thinking this way, so there is no problem. > >At this point we diverge a bit. I don't believe it was ORIGINALLY designed >to do that, but I certainly agree that is how everyone sees it. > >I believe it was DESIGNED to validate data in AN fields, much as I have >described, but I can't prove that and I'm certianly not going to argue it >:-) As someone who has used COBOL since May 1963 (RCA 301, after that varying flavors of IBM COBOL), I have always used it such that input field were defined as expected and done the test accordingly. In the case of numerics with sign overpunches, the picture (or SIZE and CLASS in the Codasyl COBOL 61 I started with) determined how the IF NUMERIC would work. I assumed the input from cards could be bad and thus tested it using the descriptions of the fields as I wanted them. Given that an alphanumeric field could not be easily moved to a signed field, I doubt that the intent was to have all input in Alphanumeric fields. > >> >> There is one "technical" issue with your desire to put everything into >> ALPHANUMERIC fields, validate, and then move "valid" numeric data to >> numeric fields. The issue is what to do with NATIONAL (usually - but not >> always - Unicode data). This should NOT be "confused" with ALPHANUMERIC >> data - but can be NUMERIC. >> >> I suppose (making an assumption about your views - that may not be >> correct), you would accept putting "single-byte-ish" data into >> ALPHANUMERIC fields and "Unicode-ish" type data into NATIONAL fields. >> Then validating that data and then moving them to the appropriate numeric >> fields. > >Your assumption is right on the button and you saved me posting the solution >I would have. :-) >> >> As I mentioned before, the COBOL "if numeric" test won't work for this (as >> it explicitly cannot check for valid/invalid signs in ALPHANUMERIC or >> NATIONAL fields). > >That is one reason I believe it to be flawed... > >However, if each programmer (site, whatever) does use its own >> "component" to do the validation, this could be made to work. > >Or... a vendor supplied component could ensure consistency... > >> >> As I say, "thinking in traditional COBOL ways" I am perfectly happy with >> using the IF NUMERIC class test (especially since it has been expanded to >> all appropriate USAGEs). Doesn't mean that you should be "happy" with it, >> but it meets my mind-set. > >Fine. We have no issues. Thanks for a civilized post, Bill. > >Pete.
From: Pete Dashwood on 26 Jan 2008 19:34 "Clark F Morris" <cfmpublic(a)ns.sympatico.ca> wrote in message news:5phnp39cnk3nd7vc4nsi2flb4psm9emmco(a)4ax.com... > On Sun, 21 Oct 2007 18:33:22 +1300, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> wrote: > >> >> >>"William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message >>news:1eASi.226775$vo5.15659(a)fe04.news.easynews.com... >>>I certainly don't want to claim your "opinions" are wrong - however, I >>>just >>>don't agree with them (exactly). >> >>No problem. I didn't expect agreement; neither do I expect everyone to >>understand why I hold such an opinion... :-) >> >>COBOL is *designed* so that you can put data >>> into "numerically defined" fields and THEN validate them (before using >>> them). I am "used to" thinking this way, so there is no problem. >> >>At this point we diverge a bit. I don't believe it was ORIGINALLY designed >>to do that, but I certainly agree that is how everyone sees it. >> >>I believe it was DESIGNED to validate data in AN fields, much as I have >>described, but I can't prove that and I'm certianly not going to argue it >>:-) > > As someone who has used COBOL since May 1963 (RCA 301, after that > varying flavors of IBM COBOL), I have always used it such that input > field were defined as expected and done the test accordingly. In the > case of numerics with sign overpunches, the picture (or SIZE and CLASS > in the Codasyl COBOL 61 I started with) determined how the IF NUMERIC > would work. I started with COBOL 61 as well :-) You forgot to mention that, prior to the introduction of PICTURE, data was defined with SIZE, CLASS, and *USAGE* clauses. >I assumed the input from cards could be bad Yep, me too... and it very often was :-) >and thus > tested it using the descriptions of the fields as I wanted them. Well, I did it similarly, ensuring the input record was defined with what was required, but then testing each supposedly numeric field in an AN field. If they all passed, it was safe to proceed. My programs did this stuff in a VALIDATE-INPUT SECTION. It worked pretty well and I seldom had 0c7 crashes caused by bad input (usually it was bad programming... Ah, happy days, when we were learning...:-)) > Given > that an alphanumeric field could not be easily moved to a signed > field, I doubt that the intent was to have all input in Alphanumeric > fields. Maybe. The problem was that with packed fields as soon as you tried to use them, you'd crash with 0c7. It therefore was better to ensure that what you stored there was valid... >> >>> >>> There is one "technical" issue with your desire to put everything into >>> ALPHANUMERIC fields, validate, and then move "valid" numeric data to >>> numeric fields. The issue is what to do with NATIONAL (usually - but >>> not >>> always - Unicode data). This should NOT be "confused" with ALPHANUMERIC >>> data - but can be NUMERIC. >>> >>> I suppose (making an assumption about your views - that may not be >>> correct), you would accept putting "single-byte-ish" data into >>> ALPHANUMERIC fields and "Unicode-ish" type data into NATIONAL fields. >>> Then validating that data and then moving them to the appropriate >>> numeric >>> fields. >> >>Your assumption is right on the button and you saved me posting the >>solution >>I would have. :-) >>> >>> As I mentioned before, the COBOL "if numeric" test won't work for this >>> (as >>> it explicitly cannot check for valid/invalid signs in ALPHANUMERIC or >>> NATIONAL fields). >> >>That is one reason I believe it to be flawed... >> >>However, if each programmer (site, whatever) does use its own >>> "component" to do the validation, this could be made to work. >> >>Or... a vendor supplied component could ensure consistency... >> >>> >>> As I say, "thinking in traditional COBOL ways" I am perfectly happy with >>> using the IF NUMERIC class test (especially since it has been expanded >>> to >>> all appropriate USAGEs). Doesn't mean that you should be "happy" with >>> it, >>> but it meets my mind-set. >> >>Fine. We have no issues. Thanks for a civilized post, Bill. >> >>Pete. Pete. -- "I used to write COBOL...now I can do anything."
From: Clark F Morris on 27 Jan 2008 20:23 On Sun, 27 Jan 2008 13:34:41 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Clark F Morris" <cfmpublic(a)ns.sympatico.ca> wrote in message >news:5phnp39cnk3nd7vc4nsi2flb4psm9emmco(a)4ax.com... >> On Sun, 21 Oct 2007 18:33:22 +1300, "Pete Dashwood" >> <dashwood(a)removethis.enternet.co.nz> wrote: >> >>> >>> >>>"William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message >>>news:1eASi.226775$vo5.15659(a)fe04.news.easynews.com... >>>>I certainly don't want to claim your "opinions" are wrong - however, I >>>>just >>>>don't agree with them (exactly). >>> >>>No problem. I didn't expect agreement; neither do I expect everyone to >>>understand why I hold such an opinion... :-) >>> >>>COBOL is *designed* so that you can put data >>>> into "numerically defined" fields and THEN validate them (before using >>>> them). I am "used to" thinking this way, so there is no problem. >>> >>>At this point we diverge a bit. I don't believe it was ORIGINALLY designed >>>to do that, but I certainly agree that is how everyone sees it. >>> >>>I believe it was DESIGNED to validate data in AN fields, much as I have >>>described, but I can't prove that and I'm certianly not going to argue it >>>:-) >> >> As someone who has used COBOL since May 1963 (RCA 301, after that >> varying flavors of IBM COBOL), I have always used it such that input >> field were defined as expected and done the test accordingly. In the >> case of numerics with sign overpunches, the picture (or SIZE and CLASS >> in the Codasyl COBOL 61 I started with) determined how the IF NUMERIC >> would work. > >I started with COBOL 61 as well :-) You forgot to mention that, prior to the >introduction of PICTURE, data was defined with SIZE, CLASS, and *USAGE* >clauses. I forgot about USAGE or the RCA 301 compiler didn't have it since everything was 6 bit characters. > >>I assumed the input from cards could be bad > >Yep, me too... and it very often was :-) > >>and thus >> tested it using the descriptions of the fields as I wanted them. > >Well, I did it similarly, ensuring the input record was defined with what >was required, but then testing each supposedly numeric field in an AN field. >If they all passed, it was safe to proceed. My programs did this stuff in a >VALIDATE-INPUT SECTION. It worked pretty well and I seldom had 0c7 crashes >caused by bad input (usually it was bad programming... Ah, happy days, when >we were learning...:-)) I used the numeric descriptions because the results would be different depending on whether the field could be signed. The expectations are different and thus the description of the field as expected is needed. This would be true even with sign is separate. > >> Given >> that an alphanumeric field could not be easily moved to a signed >> field, I doubt that the intent was to have all input in Alphanumeric >> fields. > >Maybe. The problem was that with packed fields as soon as you tried to use >them, you'd crash with 0c7. It therefore was better to ensure that what you >stored there was valid... Actually with the 360 DOS COBOL (or one of its successors) the move could bomb out because they generated a gratuitous Zero Add Packed for at least some signed fields and I seem to recall some moves to unsigned fields generated Zero Add Packed, Or Immediate. > >>> >>>> >>>> There is one "technical" issue with your desire to put everything into >>>> ALPHANUMERIC fields, validate, and then move "valid" numeric data to >>>> numeric fields. The issue is what to do with NATIONAL (usually - but >>>> not >>>> always - Unicode data). This should NOT be "confused" with ALPHANUMERIC >>>> data - but can be NUMERIC. >>>> >>>> I suppose (making an assumption about your views - that may not be >>>> correct), you would accept putting "single-byte-ish" data into >>>> ALPHANUMERIC fields and "Unicode-ish" type data into NATIONAL fields. >>>> Then validating that data and then moving them to the appropriate >>>> numeric >>>> fields. >>> >>>Your assumption is right on the button and you saved me posting the >>>solution >>>I would have. :-) >>>> >>>> As I mentioned before, the COBOL "if numeric" test won't work for this >>>> (as >>>> it explicitly cannot check for valid/invalid signs in ALPHANUMERIC or >>>> NATIONAL fields). >>> >>>That is one reason I believe it to be flawed... >>> >>>However, if each programmer (site, whatever) does use its own >>>> "component" to do the validation, this could be made to work. >>> >>>Or... a vendor supplied component could ensure consistency... >>> >>>> >>>> As I say, "thinking in traditional COBOL ways" I am perfectly happy with >>>> using the IF NUMERIC class test (especially since it has been expanded >>>> to >>>> all appropriate USAGEs). Doesn't mean that you should be "happy" with >>>> it, >>>> but it meets my mind-set. >>> >>>Fine. We have no issues. Thanks for a civilized post, Bill. >>> >>>Pete. > >Pete.
|
Pages: 1 Prev: Ryan-MacFarland COBOL Next: Remember those X-Ray Vision Glasses from the 50's? |