Code Comments
Programming Forum and web based access to our favorite programming groups."Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message news:5dm9m3F34unkmU1@mid.individual.net... > > "Rick Smith" <ricksmith@mfi.net> wrote in message > news:137bqa93d3t9kb4@corp.supernews.com... > > And you certainly realize, Rick, that a lot more than COBOL gets covered > here... :-) > > People who are making the transition from COBOL to "something else" (and > there is an increasing number of them) are certainly interested in other > solutions. That doesn't mean they are not interested in COBOL; solutions are > not necessarily mutually exclusive...(I have a number of C# solutions that > still utilise COBOL, for example...) Or, perhaps there is one who is interested in getting people to make "the transition from COBOL to 'something else'" and regularly mentions C#. <g> in > > Pretty trivial, huh? I never said it was trivial, only "hardly overwhelming". > Perhaps you'd like to post it? :-) Shown below, 193 lines. Note that I do more than the regular expression given above. [I really had no interest in writing the code; but, I couldn't sleep (a predator, who wanted to mow my yard, showed up at my doorstep triggering one of my OCD reactions) and I could not recall any recent discussion of class conditions.] > > So POSIX has RegExs available to COBOL? That's interesting. As mentioned > earlier, I was considering getting the VB regEx engine (which is actually a > COM component) working with Fujitsu COBOL, but moving to C# meant I didn't > have to. In fact, moving to Perl, PHP, Ruby, Java, or just about ANYTHING > would have provided support for RegExs... > > > > No, my point was about RegExs, not about C# (although I really like using C# > :-)) I reviewed the thread and found that your comments about regular expressions were hardly separable from C#, including your using Microsoft's perversion of the ISO standard for regular expressions. But, maybe I have some bias. <G> ----- $set ans85 flag"ans85" flagas"s" identification division. program-id. emailadr. * * Demonstration program to validate email addresses; * but does not necessarily recognize all valid * email addresses. * * In particular, it demonstrates the use of class * conditions to validate the character content of fields. * environment division. configuration section. special-names. alphabet email is standard-1 class local-chars is "A" thru "Z" "a" thru "z" "0" thru "9" "_" "%" "-" * domain-chars also used for server class domain-chars is "A" thru "Z" "a" thru "z" "0" thru "9" "-" * domain-type-chars also used for country class domain-type-chars is "A" thru "Z" "a" thru "z"
Post Follow-up to this message"Rick Smith" <ricksmith@mfi.net> wrote in message news:137cjk4fgjh1hef@corp.supernews.com... > > "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message > news:5dm9m3F34unkmU1@mid.individual.net... > are > > Or, perhaps there is one who is interested in getting people > to make "the transition from COBOL to 'something else'" and > regularly mentions C#. <g> > (OK, the following is serious and I promise I am not being mischievous...) If you mean me, I plead "not guilty". (I'm "guilty" of mentioning C#, certainly, but only in the context of alternatives to COBOL. Why should we consider alternatives to COBOL? See below...) I have no vested interest in this and am not on commission to anyone. What possible gain is there for me in persuading people away from COBOL? None, whatsoever. But then, I don't have to; they are voting with their feet... I see a trend. I try to understand why it is a trend, and I find a paradigm shift is occurring that will leave COBOL out in the cold, within a few years. As always, I call them like I see them. What can be done about it? Many people here (like myself) have a huge investment in COBOL, accrued over many years. So any alternative needs to consider that investment. That's how I arrived at C#. It offers great Interoperability and that was what first attracted me to it. I needed a DotNET solution and I couldn't get a COBOL one. C# offered easy entry into DotNET with no loss of COBOL assets, and a MUCH more productive IDE than I had ever had (on PC or mainframe) previously. End of story. I know COBOL will be around for some time yet and I'm glad about that. But I also know it won't be indefinite or even for the foreseeable future. I have had a history here of promoting unpopular viewpoints. 1. I recommended RDBs when everyone said there was nothing wrong with ISAM. 2. I tried very hard (and, generally, failed dismally :-)) to encourage people to look at OO and maybe learn Java or extend their COBOL skillsets. 3. I brought the message about components here. (24000 people read an article I wrote on it, the link to which was ONLY published here.) 4. Now I'm saying COBOL has a limited life and it's time to look at alternatives. Does any of that sound irresponsible or wrong? (It may be debatable, certainly, but these are viewpoints I hold.) So many times I've debated these issues here and been beat up and abused. But sometimes, something I say strikes a chord with someone and they go and do it. And at least I know I tried... :-) Outside of this forum what is the world doing? Using OO, accessing RDBs, gluing components together, implementing component based designs, and considering new ways of doing things. Ways that are unknown to COBOL people generally. Genetic algorithms, Regular expressions, Lambda functions, heuristic programming... Should these subjects be taboo because COBOL does not support them? I don't think so, and there's no way you can shut me up :-) (Thank God for free speech and unmoderated Usenet forums...:-)) If you don't like what I say here, put me on your kill list (Usenet please, not in the real world :-)), simply don't read or respond to my mail, or make your case against it, but don't ascribe ulterior motives to me or accuse me of doing things I'm not. I am nothing if not up front and honest in my positions. Yes, I like C# (it has grown on me since I started using it), but I also like COBOL and Java. Yes, I think the lifetime for COBOL is limited, but I am certainly not alone in that. I'd like to see people here preparing for the end of it and, to that extent, I may suggest other alternatives, and document my experience in moving away from it. Some people find that helpful. Others, take it as a personal attack on COBOL; it isn't. Finally, I DIDN'T post the C# code until someone asked me to </end of very strong serious statement> Now, back to Regular expressions... :-) > in > > I never said it was trivial, only "hardly overwhelming". > > > Shown below, 193 lines. Note that I do more than the > regular expression given above. > > [I really had no interest in writing the code; but, I couldn't > sleep (a predator, who wanted to mow my yard, showed > up at my doorstep triggering one of my OCD reactions) and > I could not recall any recent discussion of class conditions.] Well, full credit for coding it anyway, Rick. > > a > C# > > I reviewed the thread and found that your comments about > regular expressions were hardly separable from C#, including > your using Microsoft's perversion of the ISO standard for > regular expressions. But, maybe I have some bias. <G> I think we both have :-) Nevertheless, I respect your posts here and have always done so. My background for RegExs is certainly a MicroSoft one so I have been exposed to their examples. I'm not as sensitive about standards as you are. But we won't go there...:-) suffice to say, if something works (and saves me time), but violates a "standard" (which may be non-existent outside the paper it is written on), I'll bend the standard every time. I don't consider this perverted, or even perverse; I consider it pragmatic. > > ----- > $set ans85 flag"ans85" flagas"s" > identification division. > program-id. emailadr. > * > * Demonstration program to validate email addresses; > * but does not necessarily recognize all valid > * email addresses. > * > * In particular, it demonstrates the use of class > * conditions to validate the character content of fields. > * > environment division. > configuration section. > special-names. > alphabet email is standard-1 > class local-chars is "A" thru "Z" "a" thru "z" > "0" thru "9" "_" "%" "-" > * domain-chars also used for server > class domain-chars is "A" thru "Z" "a" thru "z" > "0" thru "9" "-" > * domain-type-chars also used for country > class domain-type-chars is "A" thru "Z" "a" thru "z" > . > data division. > working-storage section. > 77 current-position binary pic 9(4) value 1. > 01 work-area. > 02 work-status binary pic s9(4) value +0. > 02 local-count binary pic 9(4) value 0. > 02 local-delimiter pic x value space. > 02 local-part pic x(31) value space. > 02 domain-part-count binary pic 9(4) value 0. > 02 domain-count-1 binary pic 9(4) value 0. > 02 domain-delimiter-1 pic x value space. > 02 domain-part-1 pic x(31) value space. > 02 domain-count-2 binary pic 9(4) value 0. > 02 domain-delimiter-2 pic x value space. > 02 domain-part-2 pic x(31) value space. > 02 domain-count-3 binary pic 9(4) value 0. > 02 domain-delimiter-3 pic x value space. > 02 domain-part-3 pic x(31) value space. > 02 domain-count-4 binary pic 9(4) value 0. > 02 domain-delimiter-4 pic x value space. > 02 domain-part-4 pic x(31) value space. > linkage section. > 01 email-address pic x(256). > 01 validation-status binary pic s9(4). > procedure division > using email-address validation-status. > begin. > initialize work-area > move 1 to current-position > unstring email-address > delimited by "@" or all space > into local-part > delimiter in local-delimiter > count in local-count > with pointer current-position > on overflow > if local-delimiter = "@" > if local-part (1:local-count) is local-chars > perform get-domain-part > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > not on overflow > move -1 to work-status > end-unstring > move work-status to validation-status > exit program > . > end-of-program. > stop run > . > > get-domain-part. > unstring email-address > delimited by "." or all space > into domain-part-1 > delimiter in domain-delimiter-1 > count in domain-count-1 > domain-part-2 > delimiter in domain-delimiter-2 > count in domain-count-2 > domain-part-3 > delimiter in domain-delimiter-3 > count in domain-count-3 > domain-part-4 > delimiter in domain-delimiter-4 > count in domain-count-4 > with pointer current-position > tallying domain-part-count > end-unstring > evaluate domain-part-count > when 2 > * domain.type > if domain-count-1 > 0 > and domain-part-1 (1:domain-count-1) > is domain-chars > if domain-count-2 >= 2 and <= 4 > and domain-part-2 (1:domain-count-2) > is domain-type-chars > continue > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > when 3 > * domain.type.country or > * server.domain.type > perform try-domain-type-country > if work-status not = 0 > move 0 to work-status > perform try-server-domain-type > end-if > when 4 > * server.domain.type.country > if domain-count-1 > 0 > and domain-part-1 (1:domain-count-1) > is domain-chars > if domain-count-2 > 0 > and domain-part-2 (1:domain-count-2) > is domain-chars > if domain-count-3 >= 2 and <= 4 > and domain-part-3 (1:domain-count-3) > is domain-type-chars > if domain-count-4 = 2 > and domain-part-4 (1:domain-count-4) > is domain-type-chars > continue > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > when other > move -1 to work-status > end-evaluate > . > try-domain-type-country. > if domain-count-1 > 0 > and domain-part-1 (1:domain-count-1) > is domain-chars > if domain-count-2 >=2 and <=4 > and domain-part-2 (1:domain-count-2) > is domain-chars > if domain-count-3 = 2 > and domain-part-3 (1:domain-count-3) > is domain-type-chars > continue > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > . > try-server-domain-type. > if domain-count-1 > 0 > and domain-part-1 (1:domain-count-1) > is domain-chars > if domain-count-2 > 0 > and domain-part-2 (1:domain-count-2) > is domain-chars > if domain-count-3 >= 2 and <= 4 > and domain-part-3 (1:domain-count-3) > is domain-type-chars > continue > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > . > end program emailadr. > ----- > Well, I think that's a work of art :-). Good job. I s'pose it isn't fair to mention at this point that the C# solution did it with one line of code? :-) OK, I won't mention that...besides, it used a perverted MS implementation.... :-) This is a perfect example of why procedural coding cannot continue. It simply costs too much to write code line by line and have thousands of lines of it. Fortunately, in the 21st century, we don't have to (unlike the latter half of the 20th century where there really wasn't much choice...) Do you think it might be useful to have Regular Expressions in COBOL? (Or might it have been...?) Pete.
Post Follow-up to this messageRick Smith wrote: [snip] > I reviewed the thread and found that your comments about > regular expressions were hardly separable from C#, including > your using Microsoft's perversion of the ISO standard for > regular expressions. But, maybe I have some bias. <G> > > ----- > $set ans85 flag"ans85" flagas"s" > identification division. > program-id. emailadr. > * > * Demonstration program to validate email addresses; > * but does not necessarily recognize all valid > * email addresses. > * > * In particular, it demonstrates the use of class > * conditions to validate the character content of fields. > * > environment division. > configuration section. > special-names. > alphabet email is standard-1 > class local-chars is "A" thru "Z" "a" thru "z" > "0" thru "9" "_" "%" "-" > * domain-chars also used for server > class domain-chars is "A" thru "Z" "a" thru "z" > "0" thru "9" "-" > * domain-type-chars also used for country > class domain-type-chars is "A" thru "Z" "a" thru "z" > . > data division. > working-storage section. > 77 current-position binary pic 9(4) value 1. > 01 work-area. > 02 work-status binary pic s9(4) value +0. > 02 local-count binary pic 9(4) value 0. > 02 local-delimiter pic x value space. > 02 local-part pic x(31) value space. > 02 domain-part-count binary pic 9(4) value 0. > 02 domain-count-1 binary pic 9(4) value 0. > 02 domain-delimiter-1 pic x value space. > 02 domain-part-1 pic x(31) value space. > 02 domain-count-2 binary pic 9(4) value 0. > 02 domain-delimiter-2 pic x value space. > 02 domain-part-2 pic x(31) value space. > 02 domain-count-3 binary pic 9(4) value 0. > 02 domain-delimiter-3 pic x value space. > 02 domain-part-3 pic x(31) value space. > 02 domain-count-4 binary pic 9(4) value 0. > 02 domain-delimiter-4 pic x value space. > 02 domain-part-4 pic x(31) value space. > linkage section. > 01 email-address pic x(256). > 01 validation-status binary pic s9(4). > procedure division > using email-address validation-status. > begin. > initialize work-area > move 1 to current-position > unstring email-address > delimited by "@" or all space > into local-part > delimiter in local-delimiter > count in local-count > with pointer current-position > on overflow > if local-delimiter = "@" > if local-part (1:local-count) is local-chars > perform get-domain-part > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > not on overflow > move -1 to work-status > end-unstring > move work-status to validation-status > exit program > . > end-of-program. > stop run > . > > get-domain-part. > unstring email-address > delimited by "." or all space > into domain-part-1 > delimiter in domain-delimiter-1 > count in domain-count-1 > domain-part-2 > delimiter in domain-delimiter-2 > count in domain-count-2 > domain-part-3 > delimiter in domain-delimiter-3 > count in domain-count-3 > domain-part-4 > delimiter in domain-delimiter-4 > count in domain-count-4 > with pointer current-position > tallying domain-part-count > end-unstring > evaluate domain-part-count > when 2 > * domain.type > if domain-count-1 > 0 > and domain-part-1 (1:domain-count-1) > is domain-chars > if domain-count-2 >= 2 and <= 4 > and domain-part-2 (1:domain-count-2) > is domain-type-chars > continue > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > when 3 > * domain.type.country or > * server.domain.type > perform try-domain-type-country > if work-status not = 0 > move 0 to work-status > perform try-server-domain-type > end-if > when 4 > * server.domain.type.country > if domain-count-1 > 0 > and domain-part-1 (1:domain-count-1) > is domain-chars > if domain-count-2 > 0 > and domain-part-2 (1:domain-count-2) > is domain-chars > if domain-count-3 >= 2 and <= 4 > and domain-part-3 (1:domain-count-3) > is domain-type-chars > if domain-count-4 = 2 > and domain-part-4 (1:domain-count-4) > is domain-type-chars > continue > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > when other > move -1 to work-status > end-evaluate > . > try-domain-type-country. > if domain-count-1 > 0 > and domain-part-1 (1:domain-count-1) > is domain-chars > if domain-count-2 >=2 and <=4 > and domain-part-2 (1:domain-count-2) > is domain-chars > if domain-count-3 = 2 > and domain-part-3 (1:domain-count-3) > is domain-type-chars > continue > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > . > try-server-domain-type. > if domain-count-1 > 0 > and domain-part-1 (1:domain-count-1) > is domain-chars > if domain-count-2 > 0 > and domain-part-2 (1:domain-count-2) > is domain-chars > if domain-count-3 >= 2 and <= 4 > and domain-part-3 (1:domain-count-3) > is domain-type-chars > continue > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > else > move -1 to work-status > end-if > . > end program emailadr. > ----- Thank you Rick. Did you get any sleep afterwards? Yet another Richard
Post Follow-up to this message"Rick Smith" <ricksmith@mfi.net> wrote in message news:137cjk4fgjh1hef@corp.supernews.com... [snip] [snip] > ----- [snip] > if local-part (1:local-count) is local-chars should be: if local-count > 0 and local-part (1:local-count) is local-chars [snip] > unstring email-address ... [snip] > end-unstring > evaluate domain-part-count [snip] should be: not on overflow perform evaluate-domain-parts on overflow move -1 to work-status end-unstring
Post Follow-up to this message"Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message news:sYwdi.183576$p47.7075@bgtnsc04-news.ops.worldnet.att.net... [snip] > > Thank you Rick. Did you get any sleep afterwards? Yes, after a mental review of the code revealed a couple errors, I slept for a few hours.
Post Follow-up to this message"Rick Smith" <ricksmith@mfi.net> wrote in message news:137dlqqnasl8m3e@corp.supernews.com... [snip] > should be: > not on overflow > perform evaluate-domain-parts > on overflow > move -1 to work-status > end-unstring There seems to be a peculiarity in COBOL 85 that was removed in COBOL 2002. For COBOL 85, the 'on overflow' condition must occur before the 'not on overflow' condition. The above should actually be: on overflow move -1 to work-status not on overflow perform evaluate-domain-parts My apologies.
Post Follow-up to this message"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message news:5dna71F35l0l3U1@mid.individual.net... > > "Rick Smith" <ricksmith@mfi.net> wrote in message > news:137cjk4fgjh1hef@corp.supernews.com... > (OK, the following is serious and I promise I am not being mischievous...) > > If you mean me, I plead "not guilty". > > (I'm "guilty" of mentioning C#, certainly, but only in the context of > alternatives to COBOL. Why should we consider alternatives to COBOL? See > below...) > > I have no vested interest in this and am not on commission to anyone. > > What possible gain is there for me in persuading people away from COBOL? > None, whatsoever. But then, I don't have to; they are voting with their > feet... > > I see a trend. I try to understand why it is a trend, and I find a > paradigm shift is occurring that will leave COBOL out in the cold, within > a few years. As always, I call them like I see them. > > What can be done about it? Many people here (like myself) have a huge > investment in COBOL, accrued over many years. So any alternative needs to > consider that investment. That's how I arrived at C#. It offers great > Interoperability and that was what first attracted me to it. I needed a > DotNET solution and I couldn't get a COBOL one. C# offered easy entry into > DotNET with no loss of COBOL assets, and a MUCH more productive IDE than I > had ever had (on PC or mainframe) previously. > > End of story. > > I know COBOL will be around for some time yet and I'm glad about that. But > I also know it won't be indefinite or even for the foreseeable future. > > I have had a history here of promoting unpopular viewpoints. > > 1. I recommended RDBs when everyone said there was nothing wrong with > ISAM. > > 2. I tried very hard (and, generally, failed dismally :-)) to encourage > people to look at OO and maybe learn Java or extend their COBOL skillsets. > > 3. I brought the message about components here. (24000 people read an > article I wrote on it, the link to which was ONLY published here.) > > 4. Now I'm saying COBOL has a limited life and it's time to look at > alternatives. > > Does any of that sound irresponsible or wrong? (It may be debatable, > certainly, but these are viewpoints I hold.) > > So many times I've debated these issues here and been beat up and abused. > But sometimes, something I say strikes a chord with someone and they go > and do it. And at least I know I tried... :-) > > Outside of this forum what is the world doing? > > Using OO, accessing RDBs, gluing components together, implementing > component based designs, and considering new ways of doing things. Ways > that are unknown to COBOL people generally. Genetic algorithms, Regular > expressions, Lambda functions, heuristic programming... Should these > subjects be taboo because COBOL does not support them? > > I don't think so, and there's no way you can shut me up :-) (Thank God for > free speech and unmoderated Usenet forums...:-)) > > If you don't like what I say here, put me on your kill list (Usenet > please, not in the real world :-)), simply don't read or respond to my > mail, or make your case against it, but don't ascribe ulterior motives to > me or accuse me of doing things I'm not. > > I am nothing if not up front and honest in my positions. Yes, I like C# > (it has grown on me since I started using it), but I also like COBOL and > Java. Yes, I think the lifetime for COBOL is limited, but I am certainly > not alone in that. I'd like to see people here preparing for the end of it > and, to that extent, I may suggest other alternatives, and document my > experience in moving away from it. Some people find that helpful. Others, > take it as a personal attack on COBOL; it isn't. > > Finally, I DIDN'T post the C# code until someone asked me to > > </end of very strong serious statement> > > Now, back to Regular expressions... :-) > > > Well, full credit for coding it anyway, Rick. > > I think we both have :-) Nevertheless, I respect your posts here and have > always done so. > > My background for RegExs is certainly a MicroSoft one so I have been > exposed to their examples. I'm not as sensitive about standards as you > are. But we won't go there...:-) suffice to say, if something works (and > saves me time), but violates a "standard" (which may be non-existent > outside the paper it is written on), I'll bend the standard every time. I > don't consider this perverted, or even perverse; I consider it pragmatic. > > Well, I think that's a work of art :-). > > Good job. > > I s'pose it isn't fair to mention at this point that the C# solution did > it with one line of code? :-) OK, I won't mention that...besides, it > used a perverted MS implementation.... :-) > > This is a perfect example of why procedural coding cannot continue. It > simply costs too much to write code line by line and have thousands of > lines of it. Fortunately, in the 21st century, we don't have to (unlike > the latter half of the 20th century where there really wasn't much > choice...) > > Do you think it might be useful to have Regular Expressions in COBOL? (Or > might it have been...?) > > Pete. > We don't need no stink'in API library in COBOL :-)
Post Follow-up to this message"Charles Hottel" <chottel@earthlink.net> wrote in message news:u_Edi.5707$tb6.36@newsread3.news.pas.earthlink.net... > > "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message > news:5dna71F35l0l3U1@mid.individual.net... > > We don't need no stink'in API library in COBOL :-) Thanks Charlie. I take it you're speaking on behalf of the badgers... as in ..."We don't need no stinkin' badgers..." right :-) Pete.
Post Follow-up to this message"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message news:5dpqhhF2vbvj2U1@mid.individual.net... > > "Charles Hottel" <chottel@earthlink.net> wrote in message > news:u_Edi.5707$tb6.36@newsread3.news.pas.earthlink.net... > > Thanks Charlie. I take it you're speaking on behalf of the badgers... as > in ..."We don't need no stinkin' badgers..." right :-) > > Pete. > > Yep. I once suggest here that COBOL could use and API library but most "old hands" were not receptive. It does take time to learn an API but if it is a good one that you will use often it is time well spent. Saves always reinventing the wheel and reduces the chance of getting it wrong. Good documentation such as can be produced by JavaDoc is essential.
Post Follow-up to this message"Charles Hottel" <chottel@earthlink.net> wrote in message news:GQZdi.6035$tb6.5260@newsread3.news.pas.earthlink.net... > > "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message > news:5dpqhhF2vbvj2U1@mid.individual.net... > > Yep. > > I once suggest here that COBOL could use and API library but most "old > hands" were not receptive. It does take time to learn an API but if it is > a good one that you will use often it is time well spent. Saves always > reinventing the wheel and reduces the chance of getting it wrong. Good > documentation such as can be produced by JavaDoc is essential. > You're gonna LOVE DotNET /Mono ... :-) Pete.
Post Follow-up to this messagePowered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.