Data Validation Student Project (0/1)
Author |
Message |
Larr #1 / 10
|
Data Validation Student Project (0/1)
Hi, I've attached the source and input data file for a data validation project for an introductory COBOL course. If anyone wants to look at it and make some suggestions for better code, please do. It works the way it is supposed to now, I just wanted to improve upon it. Thanks. BTW, we use Microfocus Personal COBOL 2.0 for DOS.
|
Sat, 11 May 2002 03:00:00 GMT |
|
|
Simon R Har #2 / 10
|
Data Validation Student Project (0/1)
Quote:
>Hi, >I've attached the source and input data file for a data validation >project for an introductory COBOL course. If anyone wants to look at >it and make some suggestions for better code, please do. It works the >way it is supposed to now, I just wanted to improve upon it. Thanks. >BTW, we use Microfocus Personal COBOL 2.0 for DOS.
One tip, you could refrain from using periods (.) after every line of code, this is unnecessary and very "old" this is why we have END-* statements nowadays. Another tip, code in lowercase - it looks better and easier to read IMHO. As for logic I only browsed your code, keep up the good work. Simon R Hart.
|
Mon, 13 May 2002 03:00:00 GMT |
|
|
Larr #3 / 10
|
Data Validation Student Project (0/1)
On Thu, 25 Nov 1999 17:33:47 -0800, "Simon R Hart"
Thanks for the tips and encouragement. I'll try using lowercase, but I'll have to wait until after the class to try losing the periods - my instructor requires this in our coding guidelines. <snip> Quote: >One tip, you could refrain from using periods (.) after every line of >code, this is unnecessary and very "old" this is why we have END-* >statements nowadays. >Another tip, code in lowercase - it looks better and easier to read IMHO. >As for logic I only browsed your code, keep up the good work. >Simon R Hart.
|
Tue, 14 May 2002 03:00:00 GMT |
|
|
Howard Braze #4 / 10
|
Data Validation Student Project (0/1)
Quote:
> One tip, you could refrain from using periods (.) after every line of > code, this is unnecessary and very "old" this is why we have END-* > statements nowadays. > Another tip, code in lowercase - it looks better and easier to read IMHO.
But if you start working at our shop, put those periods back in. I bet you would have a problem getting lower case to be accepted here as well.
|
Fri, 17 May 2002 03:00:00 GMT |
|
|
Warren Porte #5 / 10
|
Data Validation Student Project (0/1)
Quote:
> > One tip, you could refrain from using periods (.) after every line of > > code, this is unnecessary and very "old" this is why we have END-* > > statements nowadays. > > Another tip, code in lowercase - it looks better and easier to read IMHO. > But if you start working at our shop, put those periods back in. I bet > you would have a problem getting lower case to be accepted here as well.
Amen. A former supervisor in this shop had a small revolt over this issue, especially when the code ended up in mixed upper/lower case. While putting together a script to perform automated changes to programs checked out for Y2K, I was able to add a program to convert all non-commented, non-quoted text to uppercase. That program was named in his honor <g>. -- Warren Porter -- Remove numbers to reply.
|
Fri, 17 May 2002 03:00:00 GMT |
|
|
Thane Hubbe #6 / 10
|
Data Validation Student Project (0/1)
On Mon, 29 Nov 1999 11:05:03 -0700, Howard Brazee Quote:
>> One tip, you could refrain from using periods (.) after every line of >> code, this is unnecessary and very "old" this is why we have END-* >> statements nowadays. >> Another tip, code in lowercase - it looks better and easier to read IMHO. >But if you start working at our shop, put those periods back in. I bet >you would have a problem getting lower case to be accepted here as well.
I recently did some contract work for the guy who taught me to program. He has stuck to his '74 COBOL ways (except I see him using an occasional inline perform and IF/End-If now. When working on his code I follow his style. However in doing this I learned one interesting thing about the periodless style I prefer. When SEARCHING for all occurances of a data name, one can search with a trailing space if not using periods (He uses temp numeric variables of X and Y) but one cannot reliably do this of using the one period per statement method. --- Try a better search engine: http://www.google.com My personal web site: http://www.geocities.com/Eureka/2006/
|
Sun, 19 May 2002 03:00:00 GMT |
|
|
Howard Braze #7 / 10
|
Data Validation Student Project (0/1)
Quote:
> On Mon, 29 Nov 1999 11:05:03 -0700, Howard Brazee
> >> One tip, you could refrain from using periods (.) after every line of > >> code, this is unnecessary and very "old" this is why we have END-* > >> statements nowadays. > >> Another tip, code in lowercase - it looks better and easier to read IMHO. > >But if you start working at our shop, put those periods back in. I bet > >you would have a problem getting lower case to be accepted here as well. > I recently did some contract work for the guy who taught me to > program. He has stuck to his '74 COBOL ways (except I see him using > an occasional inline perform and IF/End-If now. When working on his > code I follow his style. > However in doing this I learned one interesting thing about the > periodless style I prefer. When SEARCHING for all occurances of a > data name, one can search with a trailing space if not using periods > (He uses temp numeric variables of X and Y) but one cannot reliably do > this of using the one period per statement method.
Yes, if your editor has trailing spaces (some have nulls). But since there is no guarantee that a program might not have a period, a parenthesis, a comma or semicolon, or even a column 73 comment following a variable name, the edit needs to be more careful anyway. I like SPF's ability to exclude all, find all occurrences of a string, then review visibly before making my change all. With TSO/SPF I do the following: X ALL;F OLDSTRING WORD ALL Then I visibly inspect the displayed lines, excluding lines I don't wish to be changed, before entering: C * NEWSTRING NX ALL Then I review the changes, making sure I didn't mess up spacing, etc. It helps to design your variable names with this type of editing in mind.
|
Sun, 19 May 2002 03:00:00 GMT |
|
|
Howard Braze #8 / 10
|
Data Validation Student Project (0/1)
Quote:
> > However in doing this I learned one interesting thing about the > > periodless style I prefer. When SEARCHING for all occurances of a > > data name, one can search with a trailing space if not using periods > > (He uses temp numeric variables of X and Y) but one cannot reliably do > > this of using the one period per statement method.
Even if you could trust this to work, it is not sufficient reason if periods provide the solid stop which makes programs more clear. (which certainly is the case with IDMS pre-compilers). I infer then that you have a period on its own line at the end of a paragraph. Otherwise, your search example wouldn't work. For some reason, we're not allowed to do that in our shop.
|
Sun, 19 May 2002 03:00:00 GMT |
|
|
Russell Style #9 / 10
|
Data Validation Student Project (0/1)
If you have the 16 bit Microfocus product, the "DIFF" program can do that sort of uppercase, as well as renumbering cols 1-6.
Quote:
> > > One tip, you could refrain from using periods (.) after every line of > > > code, this is unnecessary and very "old" this is why we have END-* > > > statements nowadays. > > > Another tip, code in lowercase - it looks better and easier to read > IMHO. > > But if you start working at our shop, put those periods back in. I bet > > you would have a problem getting lower case to be accepted here as well. > Amen. A former supervisor in this shop had a small revolt over this issue, > especially when the code ended up in mixed upper/lower case. While putting > together a script to perform automated changes to programs checked out for > Y2K, I was able to add a program to convert all non-commented, non-quoted > text to uppercase. That program was named in his honor <g>. > -- > Warren Porter -- Remove numbers to reply.
|
Sun, 19 May 2002 03:00:00 GMT |
|
|
Thane Hubbe #10 / 10
|
Data Validation Student Project (0/1)
On Wed, 01 Dec 1999 07:26:56 -0700, Howard Brazee Quote:
>I infer then that you have a period on its own line at the end of a >paragraph. Otherwise, your search example wouldn't work. For some >reason, we're not allowed to do that in our shop.
That's how I do it! --- Try a better search engine: http://www.google.com My personal web site: http://www.geocities.com/Eureka/2006/
|
Mon, 20 May 2002 03:00:00 GMT |
|
|
|