Nested IFs, is there an alternative?
Mike Frederickson
the fields that is input it 05 GRADE PIC A. The only acceptable values belong to this set {A, B, C, D, F, W, I}. To ensure that only correct data is written to the records, I have defined the PIC as alphabetic to preclude numbers. Now I want to validate the user entered data. So I was planning on something like the code below, but I was wondering if I could pick the minds of some of the more expeirenced programmers out there. Is there a better way to validate this? This structure will determine if the data is correct, but it seemsto me there ought to be an easier way to do this. I am using Fujitsu V3 on a WIN95 platform. I am also taking a COBOL class and this is homework.
IF GRADE IS EQUAL TO 'A'
MOVE 'Y' TO GRADE-CORRECT
ELSE
IF GRADE IS EQUAL TO 'B'
MOVE 'Y' TO GRADE-CORRECT
ELSE
IF GRADE IS EQUAL TO 'C'
MOVE 'Y' TO GRADE-CORRECT
ELSE
IF GRADE IS EQUAL
TO 'D'
MOVE 'Y' TO GRADE-CORRECT
ELSE
IF GRADE IS EQUAL TO 'F'
MOVE 'Y' TO GRADE-CORRECT
ELSE
IF GRADE IS EQUAL TO 'W'
MOVE 'Y' TO GRADE-CORRECT
ELSE
IF GRADE IS EQUAL TO 'I'
MOVE 'Y' TO GRADE-CORRECT
ELSE
MOVE 'N' TO GRADE-CORRECT
END-IF
END-IF
END-IF
END-IF
END-IF
END-IF
END-IF
Terry Winchester
Look up the word EVALUATE.
Good Luck
Terry
Dirk Munk
Have a look at OR, you could use that too.
But a really elegant method (in my view) is using 88 entries. They
provide you with a very powerful way of avoiding difficult IF statements
with all the chance of a mistake, and are very easy to adapt to your
needs when you need to modify the program.
it could look like this:
05 grade pic (a).
88 grade-ok values are "A","B","C","D","F","W","I".
88 grade-sometimes-ok values are "A","W".
88 grade-not-so-ok values are "M","Q".
In your case you can now simply use
if grade-ok move "Y" to grade-correct.
The other two 88 entries are just to show you that you can add any
number of 88 entries for use on other places in your program.
Regards,
Dirk
Mike Frederickson wrote:
>
> Part 1.1 Type: Plain Text (text/plain)
> Encoding: 7bit
Michael Mattias
...
--
Michael Mattias
Racine WI USA
C:\DOS
C:\DOS\RUN
RUN\DOS\RUN
Mike Frederickson wrote in message <385236D5...@shinbiro.com>...
JohnTrifon
Try this:
MOVE 'N' TO GRADE-CORRECT
EVALUATE grade
WHEN 'A'
WHEN 'B'
WHEN 'C'
WHEN 'D'
WHEN 'F'
WHEN 'I'
WHEN 'W'
MOVE 'Y' TO GRADE-CORRECT
END-EVALUATE
I tend to avoid 88's since it requires one to look back into the data
division to find out what field is being referenced and then what the
valid values are. That said:
05 GRADE PIC A.
88 valid-grade value 'A' THRU 'D' 'F' 'I' 'W'.
...
MOVE 'N' TO GRADE-CORRECT
IF valid-grade
MOVE 'Y' TO GRADE-CORRECT.
Also, defining the picture clause as a PIC A does not guarantee it will
only contain alphabetic values. Generally, in the real world, PIC A is
rarely used, PIC X being preferred.
James J. Gavan
Mike Frederickson wrote:
>
As you've found with the responses, several alternatives - and as you've
realized your nested "IFs" are horrible. For my money, and the technique
I use, I go with Dirk's Level 88's - no IFs, no EVALUATES. I'm not
excluding EVALUATE for other circumstances, but the Level 88 is the best
way for your current example.
Jimmy, Calgary AB
Richard Plinston
: Try this:
: MOVE 'N' TO GRADE-CORRECT
: EVALUATE grade
: WHEN 'A'
: WHEN 'B'
: WHEN 'C'
: WHEN 'D'
: WHEN 'F'
: WHEN 'I'
: WHEN 'W'
: MOVE 'Y' TO GRADE-CORRECT
: END-EVALUATE
Or even:
IF ( Grade = "A" OR "B" OR "C" OR "D" OR "F" .... )
MOVE "Y" TO Grade-Correct
ELSE
MOVE "N" TO Grade-Correct
END-IF
: I tend to avoid 88's since it requires one to look back into the data
: division to find out what field is being referenced and then what the
: valid values are. That said:
I agree. It is particularly difficult when greping.
--
Dirk Munk
JohnTrifon wrote:
>
> Mike,
>
> Try this:
> MOVE 'N' TO GRADE-CORRECT
> EVALUATE grade
> WHEN 'A'
> WHEN 'B'
> WHEN 'C'
> WHEN 'D'
> WHEN 'F'
> WHEN 'I'
> WHEN 'W'
> MOVE 'Y' TO GRADE-CORRECT
> END-EVALUATE
>
> I tend to avoid 88's since it requires one to look back into the data
> division to find out what field is being referenced and then what the
> valid values are.
Maybe, but the big advantage is that there is one definition of a
certain situation, so if you have more then one IF or Evaluate statement
using these values, changing the 88 statement will change the beheaviour
of all IF and Evaluate statements without changing their coding.
And I always like to have a listing of the program on my desk :-)).
Regards,
Dirk
Clark Morris
Since this is a 1 byte field you can set up a class in the
SPECIAL-NAMES by coding CLASS VALID-GRADES IS "A" THRU "D", "F", "I",
"W". Then test
IF grades VALID-GRADES
MOVE 'Y' TO grade-correct
ELSE
MOVE 'N' TO grade-correct
END-IF
I now tend to use 88 levels and set them to true for flags and certain
other things. This documents the valid values for the field in one
place and allows for one place of change on the valid values. It also
has the disadvantage of making it difficult to find the places the
field is referred to. On flags, I now define them as filler so that
all of the references are by the 88 name.
Clark Morris, CFM Technical Programming Services, cfm...@istar.ca
Richard Plinston wrote:
>
> JohnTrifon <jtr...@ix.netcom.com> wrote:
>
> : Try this:
> : MOVE 'N' TO GRADE-CORRECT
> : EVALUATE grade
> : WHEN 'A'
> : WHEN 'B'
> : WHEN 'C'
> : WHEN 'D'
> : WHEN 'F'
> : WHEN 'I'
> : WHEN 'W'
> : MOVE 'Y' TO GRADE-CORRECT
> : END-EVALUATE
>
> Or even:
>
> IF ( Grade = "A" OR "B" OR "C" OR "D" OR "F" .... )
> MOVE "Y" TO Grade-Correct
> ELSE
> MOVE "N" TO Grade-Correct
> END-IF
>
> : I tend to avoid 88's since it requires one to look back into the data
> : division to find out what field is being referenced and then what the
William M. Klein
88-levels (or even EVALUATE). Make ABSOLUTELY certain that you know what
collating sequence is going to be in use (compile-time AND run-time) whenever
you use a "THRU" phrase. Similarly, beware of porting such programs to other
environments.
"A" thru "z" (or "a" thru "Z") can give VERY different results in ASCII vs
EBCDIC and if you change it to
"1" thru "Z" the world can REALLY change even more dramatically.
--
Bill Klein
wmklein <at> ix dot netcom dot com
Clark Morris <cfm...@istar.ca> wrote in message
news:3852C411...@istar.ca...
> > : WHEN 'W'
> > : MOVE 'Y' TO GRADE-CORRECT
William Lynch
My recommendation, also. Go with an 88-level. If you want to be very
careful (a la Bill K's post), don't use the "thru" option, code:
88 VALID-GRADE VALUES 'A' 'B' 'C' ...
i.e., list all valid values & only valid values.
I can think of another way which is also self-documenting and obvious
when you're looking at the code:
EVALUATE GRADE
WHEN 'A'
WHEN 'B'
WHEN 'C'
WHEN 'D'
WHEN 'F'
WHEN 'W'
(include the rest of the valid options here)
MOVE 'Y' TO GRADE-CORRECT
WHEN OTHER
MOVE 'N' TO GRADE-CORRECT
END-EVALUATE
Bill Lynch
James J. Gavan
Mike,
As usual, when somebody asks a question, you finish up with a variation
on a theme, leaving you guessing which way is up <G> Let's try and put
all the answers together, including the caveat from our legal-beagle,
Mr. Klein :-
01 grade pic x.
88 grade-ok values are "A","B","C","D","F","W","I".
88 grade-sometimes-ok values are "A","W".
88 grade-not-so-ok values are "M","Q".
Depending upon how specific you want to be, you could use
compute my-char = function uppercase/lowercase (grade) ( or
integer function)
Then you could test is (not) alphabetic or is (not) numeric
You can follow this by the several Evaluate styles recommended
And a point Ken Foskey would make, XP(Extreme Programming) -
if the critieria doesn't fit your tests have an "other"
Evaluate grade
when grade-ok do this......
when grade-sometimes-ok do this ........
when grade-not-so-ok do this........
when other do I've got a problem
End-Evaluate
Info for those that don't like 88's, because it means looking up in
Global Working-Storage; this is where OO gives a slight edge, by
localizing the test :-
*>-------------------------
Method-id. "test-grade".
*>------------------------
Working-storage section.
01 grade pic a.
88 grade-ok values are "A","B","C","D","F","W","I".
88 .....
Linkage section.
01 lnk-grade pic x.
88 lnk-ok value "Y".
88 lnk-lousy value "N".
Procedure Division returning lnk-grade.
*> do functions for upper/lowercase/or integers if you want
if grade-ok set lnk-OK to true
else set lnk-lousy to true
End-if
*> or you code it, (and ignoring the Linkage above) :-
Evaluate grade
when grade-ok
invoke self "grade-ok"
when grade-sometimes-ok
invoke self "sometimes-ok"
when grade-not-so-ok
invoke self "not-so-ok"
when other
invoke self "ive-got-a-problem"
End-Evaluate
Exit Method
End Method "test-grade".
*>------------------------
End of message Mike.
Bill Klein,
I swear, if you and I meet at Newbury in May, I'm gonna waltz you down
to Gieves in the 'Dilly and get you outfitted with an Horace Rumpole
outfit, complete with wig !
Jimmy, Calgary AB
Mike Frederickson
"James J. Gavan" wrote:
Mike,
As usual, when somebody asks a question, you finish up with a variation
on a theme, leaving you guessing which way is up <G> Let's try and put
all the answers together, including the caveat from our legal-beagle,
Mr. Klein :-
<SNIP>
Arnold Trembley
>
> 1 more Alternative and 1 comment.
>
> Since this is a 1 byte field you can set up a class in the
> SPECIAL-NAMES by coding CLASS VALID-GRADES IS "A" THRU "D", "F", "I",
> "W". Then test
> IF grades VALID-GRADES
> MOVE 'Y' TO grade-correct
> ELSE
> MOVE 'N' TO grade-correct
> END-IF
I like the CLASS approach, althought I would define it as
CLASS VALID-GRADES IS "ABCDFIW".
There are two advantages, in my opinion. A class test can be performed
against any variable (you don't have to MOVE it to the field with the
defined condition-names), and on an IBM mainframe the generated code
will be very efficient, one six-byte TRT (Translate and Test)
instruction. A small data table will be generated to support the TRT.
One possible disadvantage is that you could perform the class test
against a string variable and get a TRUE result if every character in
the string is found in the set of valid characters in the class.
--
Arnold Trembley
http://home.att.net/~arnold.trembley/
Ib Tanding
fail, I can arrange something in The Lion in West Street. Many good men have
earned an 'under-cover-attitude' there.
Regards
Ib
James J. Gavan skrev i meddelelsen <3853162D...@home.com>...
>
Snip
Clark Morris
WHEN GRADE-OK
etc.
The 88 is always related to the field, in this case grade. Also in
the case below the "do this" for condition GRADE-SOMETIMES-OK will
never be acted upon because it is a subset of GRADE-OK and the WHEN
for GRADE-OK came first.
Clark Morris, CFM Technical Programming Services Inc.,
cfm...@istar.ca
"James J. Gavan" wrote:
>
> Mike,
>
> As usual, when somebody asks a question, you finish up with a variation
> on a theme, leaving you guessing which way is up <G> Let's try and put
> all the answers together, including the caveat from our legal-beagle,
> Mr. Klein :-
>
> Bill Klein,
>
> I swear, if you and I meet at Newbury in May, I'm gonna waltz you down
> to Gieves in the 'Dilly and get you outfitted with an Horace Rumpole
> outfit, complete with wig !
>
> Jimmy, Calgary AB
James J. Gavan
Mike Frederickson wrote:
>
> Thanks for all the help. I looked up EVALUATE in the programing text
> we are using (Stern and Stern's Structured COBOL Programming )and
> there were only examples with numeric values. Any sugestions on how to
> learn what is not in the books? I have downloaded the Fujitsu
> manuals, but they are duanting in disk format.
>
> "James J. Gavan" wrote:
>
> > Mike,
> >
> > As usual, when somebody asks a question, you finish up with a
> > variation
> > on a theme, leaving you guessing which way is up <G> Let's try and
> > put
> > all the answers together, including the caveat from our
> > legal-beagle,
> > Mr. Klein :-
> >
> > <SNIP>
Mike,
Some possibles, "Teach Yourself COBOL in 24 Hours", "COBOL Unleashed"
and a neat one if still in print Jerome Garfunkel's "The COBOL 85
Example Book". But I doubt they cover all the possibilities we've been
chewing around here.
Jimmy, Calgary AB
Michael Mattias
Mike Frederickson wrote in message <38533811...@shinbiro.com>...
> Any sugestions on how to learn what is not in the books?
The library, trade press, people in the trade, and newsgroups come to mind.
MCM
Joe Grenier
Mike Frederickson wrote in message <385236D5...@shinbiro.com>...
Howard Brazee
I never use PIC A. I would rather check myself to see if it is
alphabetic than have my program blow.
Your code above would be better off with an EVALUATE.
But don't bother, just use an 88 level with your VALID-GRADES VALUE
containing the values you want. Then say IF VALID-GRADES CONTINUE ELSE
PERFORM 1000-BAD-GRADE.
(If you hadn't showed us what you have tried, I would have ignored this
homework assignment).
Howard Brazee
>
> Thanks for all the help. I looked up EVALUATE in the programing text
> we are using (Stern and Stern's Structured COBOL Programming )and
> there were only examples with numeric values. Any sugestions on how to
> learn what is not in the books? I have downloaded the Fujitsu
> manuals, but they are duanting in disk format.
>
> "James J. Gavan" wrote:
Play around with WHEN TRUE That expands the value of EVALUATE more
than what you probably see now.
docd...@clark.net
Howard Brazee <Please, do, not, e-mail, replies, post, them!!> wrote:
[snippicito]
>(If you hadn't showed us what you have tried, I would have ignored this
>homework assignment).
You'll notice that it didn't get my Usual Response, either.
DD
William Lynch
Oh, we'd heard you'd been kidnapped by terrorists:-)
Bill Lynch
michael vasmatics
Howard Brazee <bra...@NOSPAMwebaccess.net> wrote in message
news:385510B4...@NOSPAMwebaccess.net...
> alphabetic than have my program blow.
>
> Your code above would be better off with an EVALUATE.
> But don't bother, just use an 88 level with your VALID-GRADES VALUE
> containing the values you want. Then say IF VALID-GRADES CONTINUE ELSE
> PERFORM 1000-BAD-GRADE.
>
> homework assignment).
Ok so much for the pros they had there say, can't figure the BLOW thing if
your checking the value.
So as one student to another consider this, lets keep it simple and answer
the quistion .
"IF" works fine, you just need the right IF so it doesn't look like
spaghetti code. LOOK AT YOURS THEN LOOK BELOW.
Why couldn't you just code, a simple compounded if statement?
IF this can't be done then the pros can tell us why.
IF GRADE = 'A' OR ' B' OR 'C' OR 'D' OR 'F' OR 'W' OR ' I'
MOVE 'Y' TO GRADE- CORRECT
ELSE
MOVE 'N' TO GRADE- CORRECT
END-IF.
this seems straight forward and readable, and you can use PIC X,
your testing for the value of grade so if the condition isn't met it wont
pass.
If your testing for it, how could it BLOW, a simple class test for
alphabetic wont do at all,
I just got finished with a COBOL class so I'm no expert but I don't see
anything wrong whit a compounded IF statement.
You need to reread the section on a compounded IF condition.
Here is something along this compounded idea I just used in a program I
handed in
for a presort condition to weed out bad records before sorting
600-VALIDATE.
IF EMPL-NUM NUMERIC
AND
TER-NUM NUMERIC
AND
OFFICE-NUM NUMERIC
AND
YR-SALARY NUMERIC
AND
SS-NUM NUMERIC
NEXT SENTENCE
ELSE
MOVE PAYROLL-REC-IN TO WS-FAILED-REC
MOVE 'YES' TO BAD-REC
END-IF.
610-EX-VALIDATE.
EXIT.
See its all compounded, IF all these fields are numeric its a good record
release it to sort otherwise its a bad record
so don't release it , write to a bad records report.
These are different fields. BUT, its single dependent, although on more then
one variable but its still yes or no or 1 of 2 things can happen ,bad input
or good input.
Nested IF as I understand it is for multiple branching.
LIKE this:
IF person is a salary employee, just move pay in to pay out, ELSE he is
hourly go to hourly calculation, IF hourly with more then forty hours
of work calculate regular pay and OT pay ELSE he dint work OT, so just
calculate regular pay.
See how this thing branches depending IF person is hourly or salary and IF
he is hourly did he work OT or not, a simple yes or no wont do.
Depending on the condition, 1 of 3 calculations is used, see the "branch
once and branch again" this has to be nested.
Your stuff doesn't need to be nested its a yes or no, it just needs to be
compounded. One line will do it, and its easy to read.
For data validation you should reread the following statements IF, INSPECT
and EVALUATE.
Howard Brazee
> > I never use PIC A. I would rather check myself to see if it is
> > alphabetic than have my program blow.
> >
> > Your code above would be better off with an EVALUATE.
> > But don't bother, just use an 88 level with your VALID-GRADES VALUE
> > containing the values you want. Then say IF VALID-GRADES CONTINUE ELSE
> > PERFORM 1000-BAD-GRADE.
> >
> > (If you hadn't showed us what you have tried, I would have ignored this
> > homework assignment).
>
> Ok so much for the pros they had there say, can't figure the BLOW thing if
> your checking the value.
The word is "you're", not "your" - sorry for being off-topic but I have
a personal problem being too easily irritated with that misspelling.
Back on topic:
You can blow when you reference a PIC 9(5) alphabetic value. I believe
you can blow when you reference a PIC A(5) numeric value. And checking
for it being numeric or alphabetic is referencing it.
I don't know of any upside to using PIC A instead of PIC X.
Howard Brazee
> > I never use PIC A. I would rather check myself to see if it is
> > alphabetic than have my program blow.
> >
> > Your code above would be better off with an EVALUATE.
> > But don't bother, just use an 88 level with your VALID-GRADES VALUE
> > containing the values you want. Then say IF VALID-GRADES CONTINUE ELSE
> > PERFORM 1000-BAD-GRADE.
> >
> > (If you hadn't showed us what you have tried, I would have ignored this
> > homework assignment).
>
> Ok so much for the pros they had there say, can't figure the BLOW thing if
> your checking the value.
The word is "you're", not "your" - sorry for being off-topic but I have
Michael Mattias
>
>600-VALIDATE.
> IF EMPL-NUM NUMERIC
> AND
> TER-NUM NUMERIC
> AND
> OFFICE-NUM NUMERIC
> AND
> YR-SALARY NUMERIC
> AND
> SS-NUM NUMERIC
> NEXT SENTENCE
> ELSE
> MOVE PAYROLL-REC-IN TO WS-FAILED-REC
> MOVE 'YES' TO BAD-REC
> END-IF.
>
> 610-EX-VALIDATE.
> EXIT.
Just for style points, I would prefer:
IF (all that stuff)
MOVE "YES" TO GOOD-RECORD
ELSE
MOVE "NOPE" TO GOOD-RECORD.
I just find it confusing when "YES" is "BAD" and "NOPE" is "GOOD"
But if you insist, you should consider CONTINUE in lieu of NEXT SENTENCE;
it will make maintenance a tad easier for the next poor schlmiel. (And if
that's me, I will no doubt mutter aspersions upon the validity of your
birth).
MCM
Howard Brazee
>
> But if you insist, you should consider CONTINUE in lieu of NEXT SENTENCE;
> it will make maintenance a tad easier for the next poor schlmiel. (And if
> that's me, I will no doubt mutter aspersions upon the validity of your
> birth).
>
> MCM
The only time where I still use NEXT SENTENCE is in statements which
will be expanded by my pre-compiler (I always terminate those by full
stop periods). Otherwise, if CONTINUE isn't appropriate, the command
should be restructured. Anybody disagree?
Jeff Baynard
names are great but I would say most programmers (read: maintenance) are
more comfortable with a straightforward IF statement.
Jeff
---------
michael vasmatics
Howard Brazee <bra...@NOSPAMwebaccess.net> wrote in message
>
> You can blow when you reference a PIC 9(5) alphabetic value. I believe
> you can blow when you reference a PIC A(5) numeric value. And checking
> for it being numeric or alphabetic is referencing it.
>
> I don't know of any upside to using PIC A instead of PIC X.
I agree with what you stated, and I'm sorry about the spelling mistake, I
am, I admit, terrible at spelling, even simple words.
It leads to people thinking that I must be a simpleton for that I'm sorry.
Since I'm only a student although a very old one, I tried to explain that my
answer may not be the best. I saw nothing wrong with his code except that
the nested IF should have been a compounded IF. I tried to tell him why, I
also tried to tell him what he needed to revisit.
I guess the lesson learned here is for students to read and listen. I just
felt that, If he couldn't figure out the nested IF, how is he going to
figure out LEVEL 88 special names. As for the PIC A, I have yet to use it, I
use PIC X myself but that doesn't make it wrong.
He was expecting an ALPHA field and choking if the value coming in was
correct. I used packed decimal in a program and if a non numeric shows up
the program chokes.
I didn't realize that the answer was to use it as PICK X first, then check
to make sure its numeric, then turn it into a packed decimal
to make it more efficient.
In either case I didn't mean to offend anyone, if I have, for that I
apologies. My intent was to show why a compounded if would be better,
and what other things he needed to read to get a better understanding of how
to set it up his validation.
Aaron Cardon
writing correctly yourself. If you don't know what I'm talking about, I'll
give you a hint; Sentences do not usually begin with the word "and."
>>>And checking for it being numeric or alphabetic is referencing it.
That isn't even a complete sentence!
Howard Brazee wrote in message <3858FCB3...@NOSPAMwebaccess.net>...
>michael vasmatics wrote:
>
>> > I never use PIC A. I would rather check myself to see if it is
>> > alphabetic than have my program blow.
>> >
>> > Your code above would be better off with an EVALUATE.
>> > But don't bother, just use an 88 level with your VALID-GRADES VALUE
>> > containing the values you want. Then say IF VALID-GRADES CONTINUE ELSE
>> > PERFORM 1000-BAD-GRADE.
>> >
>> > (If you hadn't showed us what you have tried, I would have ignored this
>> > homework assignment).
>>
>> Ok so much for the pros they had there say, can't figure the BLOW thing
if
>> your checking the value.
>
>The word is "you're", not "your" - sorry for being off-topic but I have
>a personal problem being too easily irritated with that misspelling.
>Back on topic:
>
Bill Lynch
>
> I agree, let's keep it simple whenever possible. Class, 88s,
Huh? No 88-levels? I'm going to disagree, especially since we can both
test and set the 88 from COBOL II onward (revealing my IBM mainframe
orientation). Using the 88's is far more symbolic & self-documenting
than coding:
IF some_field = 1...
or
IF some_other_field = 'Q' ...
IMHO, anyway.
Bill Lynch
Aaron Cardon
writing correctly yourself. If you don't know what I'm talking about, I'll
give you a hint; Sentences do not usually begin with the word "and."
>>>And checking for it being numeric or alphabetic is referencing it.
That isn't even a complete sentence!
Howard Brazee wrote in message <3858FCB3...@NOSPAMwebaccess.net>...
>michael vasmatics wrote:
>
>> > I never use PIC A. I would rather check myself to see if it is
>> > alphabetic than have my program blow.
>> >
>> > Your code above would be better off with an EVALUATE.
>> > But don't bother, just use an 88 level with your VALID-GRADES VALUE
>> > containing the values you want. Then say IF VALID-GRADES CONTINUE ELSE
>> > PERFORM 1000-BAD-GRADE.
>> >
>> > (If you hadn't showed us what you have tried, I would have ignored this
>> > homework assignment).
>>
>> Ok so much for the pros they had there say, can't figure the BLOW thing
if
>> your checking the value.
>
Bill Lynch
>
(snip)
>
> 1. Can we please stop using "YES" and "NO" or "Y" and "N" in code?
>
> My objections are based on having worked in different countries where the
> native language uses "Ja" or "Si" or something else instead of "YES". Lets
> make COBOL international and assign a value of "1" for "TRUE" and "0" for
> FALSE ("1" = "GOOD", "0"=BAD, " "= UGLY (indeterminate) for Michael...)
Interesting you should mention this:-) For the last several years ('92
or so, when we moved up to COBOL II), I've been defining switches as PIC
9 and placing them in their own 01-level (no VALUE clauses). In my
initialization logic I say:
INITIALIZE SWITCHES
So the default value for all switches is ZERO, which usually means no
error. Other values are from 1 thru 9 and mean whatever I need for the
task at hand. If I have many potential values, the field is PIC 99. When
you're writing display or print programs, any switch = ZERO means no
errors. Any non-ZERO value is a subscript to a table of error messages.
For YES/NO or BON/MAL or JA/NEIN, etc., ZERO is the default and anything
non-ZERO is the opposite.
Bill Lynch
Jeff Baynard
I also admit having to reference Mike Murach's Cobol Part 1 book to properly
code a SEARCH ALL the other day. duh.
Jeff
----------
In article <385B5592...@worldnet.att.net>, Bill Lynch
Peter E. C. Dashwood
Bill Lynch wrote in message <385B5592...@worldnet.att.net>...
>Jeff Baynard wrote:
>>
>> I agree, let's keep it simple whenever possible. Class, 88s,
>
>Huh? No 88-levels? I'm going to disagree, especially since we can both
>test and set the 88 from COBOL II onward (revealing my IBM mainframe
>orientation). Using the 88's is far more symbolic & self-documenting
>than coding:
>
dissertation on the use of English (spelling and grammar), Michael (whose
contributions I ALWAYS read...informative and usually amusing) asked for
"YES" to represent the GOOD and "NOPE" to represent the BAD...What
represents the UGLY, Mike? Oops, sorry, most of the code examples posted do
that just fine...
So here's my contribution (in flawless English and perfect grammar,
correctly spelled, using no joined-up writing and a large crayon...)
1. Can we please stop using "YES" and "NO" or "Y" and "N" in code?
My objections are based on having worked in different countries where the
native language uses "Ja" or "Si" or something else instead of "YES". Lets
make COBOL international and assign a value of "1" for "TRUE" and "0" for
FALSE ("1" = "GOOD", "0"=BAD, " "= UGLY (indeterminate) for Michael...)
so...
(01 RECORD-FLAG pic x value space.
88 GOOD-RECORD value "1".
88 BAD-RECORD value "0".)
IF (all that stuff)
SET GOOD-RECORD TO TRUE
ELSE
SET BAD-RECORD TO TRUE
END-IF
Obviously, I can't force anybody to apply this as a standard, but you would
make an old man very happy if you did so...(and maintenance programmmers
from all ethnic backgrounds will call down blessings upon your house...)
2. The original contributor wanted to know about alternatives to nested IFs
(remember that...?)
Well, I don't propose to discuss alternatives here, (don't see why I should
be the ONLY one on topic, and besides, it would involve too many specific
examples and it's Sunday here in NZ and it's clear blue sky and I'm going
fishing and having a few beers this afternoon with some friends, so I
haven't got all day for this...) but I'm happy to post a few simple rules
which may help some of you to know when to use a nested IF.
Pete's rules for nested IFs:
1. If you can avoid using them, do so.
2. There is ONE valid case where you SHOULD use a nested IF... (actually
there are probably others, but this is the only time when I will DEFINITELY
write a nested IF)
If there is a "decision tree", use a nested IF. Here's a simple decision
tree, nested to 3 levels...
IF c1
IF c2
IF c3
a1
ELSE
a2
ELSE
a3
ELSE
CONTINUE
Before you get incensed at the "bad code" let me explain. I have
deliberately omitted the END-IFs for clarity. You should read the above as:
(The "c"s are conditions; the "a"s are actions, so c1=Condition 1, a1=
Action 1)
If c1 is TRUE, AND c2 is TRUE, AND c3 is TRUE, do a1.
If c1 is TRUE, AND c2 is TRUE, AND c3 is NOT TRUE, do a2.
If c1 is TRUE, AND c2 is NOT TRUE, do a3
If c1 is NOT TRUE, just carry on
So we have a branching tree-like structure of conditions and actions.
Remember that all the conditions above may be "any conditional expression"
so you could include compound conditions in your decision tree. Also, the
"action" can be any valid COBOL construct, including "IF". This brings us to
the next important rule...
3. ONLY nest your IFs into the TRUE branches of your decision tree. This
keeps it simple. While COBOL will support having ELSE...IF, in my opinion,
this is inelegant and best avoided. (I confess there are occasions when I
have done it, but I was young and foolish at the time...). So here's the
code for the tree above...
IF c1
IF c2
IF c3
a1
ELSE
a2 (Note: we avoid putting further IFs here...
If you REALLY need to have some tricky stuff at
this point, move it
into its own section and PERFORM it...)
END-IF
ELSE
a3
END-IF
END-IF
OK, that's really all I wanted to say on the subject. Students please note,
and if your lecturer disagrees tell him to mail me...(You just can't get the
help these days...)
Now, wheres that bait box....
Pete.
Michael Mattias
<83h5ei$8c5$1...@hermes.enternet.co.nz>...
>
> Michael ... asked for
>"YES" to represent the GOOD and "NOPE" to represent the BAD...What
>represents the UGLY, Mike?
Mirror, mirror, on the wall...... (1)
>Pete's rules for nested IFs:
>
>3. ONLY nest your IFs into the TRUE branches of your decision tree.
Now that is an *excellent* rule: nest the code only if the decision is
nested rather than evaluative (is 'evaluative' a real word?); and if the
decision seems nested, see if a compound IF can convert it to an evaluative
test.
One thing about that though: pre-ANSI '85 (well,
pre-explicit-scope-terminator) COBOL has left us an astonishing quantity of
"nested evaluation" (I don't like to mix metaphors like that, but if the
shoe fits, you should not throw stones) code to maintain.
However, with COBOL code's unexpected longevity, methinks we should all be
prepared to see this kind of code for a long, long, time.
MCM
1. Or is it OFF the wall?
Chris A. Goodey
<may...@shinbiro.com> wrote:
>I am writing a program that will accept class information and write the
>data to a disk. One of
>the fields that is input it 05 GRADE PIC A. The only acceptable
>values belong to this set {A, B, C, D, F, W, I}.
<snip>
For something this simple, an 88 level is nice (as is mentioned by
many replies.) Saying IF VALID-GRADE MOVE "T" TO OUTPUT-FLAG ELSE
MOVE "F" TO OUTPUT-FLAG is pretty clear code to me.
A single if can also work for some simple cases like this,
as in IF GRADE = "A" OR "B" OR "C"
(when you want to do the same thing for all the characters.)
The EVALUATE statement is my favorite addition for Cobol 85, and makes
programming fun again, not to mention producing more readable code. It
can be used to replace complicated messes of IF statements with a
single clear statement. It is especially useful when processing a
variable (or two or more) that map to specific functions. In the case
you mentioned, where any valid grade results in the same action, the
evaluate can go like this
EVALUATE GRADE
WHEN 'A'
WHEN 'B'
WHEN 'C'
WHEN 'D'
WHEN 'F'
WHEN 'W'
WHEN 'I' MOVE 'T' TO OUTPUT-FLAG
WHEN OTHER MOVE 'F' TO OUTPUT-FLAG.
END-EVALUATE.
Note that you can 'stack' up a number of conditions without any action
verb, and all the stacked up values go against the first verb (in
this case, the MOVE 'T' part.)
Evaluate has other nice feature, like THRU. This works for things that
are a continuous range of values, and would have been coded in an
if statement as IF GRADE >= "A" AND GRADE <= "D" (and probably
generates much the same code.) However, it if often much clearer.
EVALUATE GRADE
WHEN 'A' THRU 'D'
WHEN 'F'
WHEN 'W'
WHEN 'I' MOVE 'T' TO OUTPUT-FLAG
WHEN OTHER MOVE 'F' TO OUTPUT-FLAG.
END-EVALUATE..
The THRU part is very nice for easily specifying ranges. But what if
you want an entire range except for something?
EVALUATE INPUT-VALUE
WHEN 2 MOVE "A" TO RESULT
WHEN 1 THRU 10 MOVE "B" TO RESULT
WHEN 15 CONTINUE
WHEN 11 THRU 20 MOVE "C" TO RESULT
WHEN OTHER DISPLAY 'INVALID VALUE"
END-EVALUATE.
Since an evalute statement select no more than one clause to execute,
and does so in order, a value of 2 will result into the MOVE "A" part
executing, and nothing else, so the 1 THRU 10 part will not be
encountered for input of 2.
Now this could easily be coded with lots of IF THEN ELSES, but it is
often MUCH clearer to use the evaluate statement.
Note that the EVALUATE can process more than one value, and can use
constants such as TRUE and FALSE. I don't have time to give some
good examples right now but may borrow some from working programs
and post them sometime.
Speaking about the HP3000 MPE\iX compiler, this produces code just
like a bunch of IF statements do. Thus, putting the most likely
condition first can result in faster code. However, for most
real-world applications, clear code is better than strange code that
is marginally faster.
If you are not using evaluate statements then you are missing the best
feature of Cobol 85!
Your milage may vary.
Thane Hubbell
<dash...@enternet.co.nz> wrote:
Everything else in your post I agree with.
>1. Can we please stop using "YES" and "NO" or "Y" and "N" in code?
>
>My objections are based on having worked in different countries where the
>native language uses "Ja" or "Si" or something else instead of "YES". Lets
>make COBOL international and assign a value of "1" for "TRUE" and "0" for
>FALSE ("1" = "GOOD", "0"=BAD, " "= UGLY (indeterminate) for Michael...)
>so...
>
>(01 RECORD-FLAG pic x value space.
> 88 GOOD-RECORD value "1".
> 88 BAD-RECORD value "0".)
>
>IF (all that stuff)
> SET GOOD-RECORD TO TRUE
>ELSE
> SET BAD-RECORD TO TRUE
>END-IF
>
This one really does not matter. The values in the 88 are
inconsequential if one uses SET to make them true, and (presently,
until the next standard) - Initialize to make them false.
---
Try a better search engine: http://www.google.com
My personal web site: http://www.geocities.com/Eureka/2006/
Bill Lynch
>
(snippage)
> Hmmmm....I take no issue with what you've written, Bill, (whatever works for
> you is OK) but I would make the following observations:
>
> 1. Pic x switches are more efficient on IBM Mainframes. (It generates a
> single CLI (Compare Logical Immediate, where the literal being compared is
> a single byte contained in the instruction) instruction to check for 1 or 0.
> If you define the switch as numeric, you may end up having a CVB (convert to
> binary) followed by a PACK, followed by a CP (compare packed). All in all, a
> bit of an overkill for a switch test...)
A CVB in this case makes no sense. It converts packed data (in memory -
a doubleword) to binary (in a register). Worst case would be a PACK
followed by a CP.
> 2. I'm not sure about your practise of using the values of a switch to be a
> subscript into a table of errors....I guess as long as the switch is not a
> simple ON/OFF (Boolean) then it's OK. It raises the question: "When is a
> switch, not a switch...?"
When it may have more than two states. I agree it's not really a switch
in that case, but an error flag (for want of a better term). Maybe I
should have made that clearer.
> I definitely don't like the idea of zero being the "default"...for me, zero
> represents logically FALSE, so it would always be NO. (You can imagine the
> trouble I had when I first learned C and found that NEGATIVE returns
> represent this...)
Maybe it's my IBM mainframe background, i.e., RC=0 means no errors.
Bill Lynch
Bill Lynch
>
>
> I agree that the actual values used are irrelevant when SET is employed, but
> I would argue the validity of using INITIALIZE to set Falsity. The initial
> value of a flag should be indeterminate. If you want it to be false, SET it
> so and do it explicity so there is no doubt about it. TRUE and FALSE have
> equal logical weight. It should be easily apparent from code what state is
> being set and where.
Falsity - I like that! I don't see the difference between having ZERO =
False and saying:
SET SWITCH-IS-OFF TO TRUE
or
INITIALIZE SWITCHES (where the byte for SWITCH-OFF in a field in
SWITCHES)
Same difference to me, except you have to code the SET for every switch.
> Assuming the initial state of a flag to be FALSE is a recipe for disaster,
> especially in on-line programs where code may be re-used. (Even COBOL code
> can be "serially re-usable" (pseudo re-entrant) and the initial state of a
> flag could have been long lost. Think about the case where flags are defined
> as EXTERNAL...a number of modules could be inheriting the flag; it's initial
> state is meaningless.
I really don't see your point here. The switches aren't set to anything
until I code the INITIALIZE in the initialization routine. It makes no
matter if the program is being used concurrently or not, every
invocation of the program gets its own WORKING-STORAGE, so no one in
task B can ever trip over any value in task A. I do trust myself (and
you guys, too (includes women)) to get the usage straight within the
task, even if some are EXTERNAL, which I do use in a couple of places.
Bill Lynch
William M. Klein
Bill Lynch <wbl...@worldnet.att.net> wrote in message
news:385D0331...@worldnet.att.net...
Bill,
I was following you OK until you said that you do use EXTERNAL in some
programs. In such cases, you are NOT getting your own "copy" of the switches
in each program - but a shared copy. Now, it is still true that you can
reset it in the "housekeeping" routine of each program, but if this is the
case, it doesn't make any sense to use EXTERNAL. On the other hand, if you
do truly share it across programs (where EXTERNAL is useful), then it is true
that you can never tell what the initial (to the run-unit) setting will be.
This can be avoided by having a "housekeeping" routine for the whole
run-unit - but that only works if there is some program you can be certain
gets executed before all the others in your run-unit. That is one possible
system design, but I have also seen systems where it really isn't possible to
predict "where you start from".
--
Bill Klein
wmklein <at> ix dot netcom dot com
James J. Gavan
Bill Lynch wrote:
>
> "Peter E. C. Dashwood" wrote:
> >
> (snip)
> >
> > 1. Can we please stop using "YES" and "NO" or "Y" and "N" in code?
> >
> > My objections are based on having worked in different countries where the
> > native language uses "Ja" or "Si" or something else instead of "YES". Lets
> > make COBOL international and assign a value of "1" for "TRUE" and "0" for
> > FALSE ("1" = "GOOD", "0"=BAD, " "= UGLY (indeterminate) for Michael...)
>
> Interesting you should mention this:-) For the last several years ('92
> or so, when we moved up to COBOL II), I've been defining switches as PIC
> 9 and placing them in their own 01-level (no VALUE clauses). In my
> initialization logic I say:
My approach is similar. In the case of M/F OO there are classes which
will return boolean isTrue isFalse - so Merant recommend you use a Pic
x(4) comp-5. My 'tests' tend to be 95% numeric, exceptions being as
follows, where user is entering only one character :-
evaluate inputField
when "d" or "D" display "Dual"
when "m" or"M" display "Mixed"
when other display "Screen Mode"
End-evaluate
Tied in with that comp-5 approach, (and not knowing implications on
mainframes - as you and Pete have discussed), the comp-5 means that you
don't have to remember how many digits you allocated for a routine - in
your case you said sometimes pic 9, others pic 99. This tied in with
'flagging' errors allows you to go to your error table knowing that you
can always rely on the comp-5 being of sufficient size.
We've been discussing the merits of IFs and EVALUATEs but we didn't
advise the original questioner on 'hit frequencies'
evaluate true
when Red do this
when White do this
when Blue do this
when other do this
End-evaluate
Yep. I've written the colours as most of us in the Western democracies
think of them - and as an example it is probably difficult to suggest
which should come first. But that isn't the case with the following, for
a department store group, and the same concept applies to the particular
branch of commerce you are dealing with :-
evaluate true
when Fashions do this
when ShopinShop do this
when Food do this
when other do this
End-evaluate
It's a fair bet 'Fashions' will give you the 80/20 Pareto rule. Don't
know American terminology for 'Shop-within-Shop' but UK version means
trade-names like Aquascutum, London Fog or in perfumeries, Chanel,
Charlie etc. operating as separate 'shops' within the store. They
probably come out second. Food used to be a factor in department stores,
but with the onslaught of supermarkets, tends to be a minority
speciality department. So based on that knowledge it is possible to make
this type of Evaluate( or IF ) meaningful in terms of hit-rate.
Above doesn't fit the bill ? You can divide it down further :-
evaluate true
when Fashions
evaluate true
when LadiesFashions do this
when ChildrensFashions do this
when MensFashions do this
when other do this
End-evaluate
when ShopinShop do this
when Food do this
when other do this
End-evaluate
Now take those tables above for a large supermarket chain, which also
dabbles in 'Dry Goods' and you reverse the order, splitting the Food
down into its own departmental categories. It's 25 years since I was
involved with Food, so we would need one of our supermarket specialists
to give us the Pareto breakdown.
Jimmy, Calgary AB
Thane Hubbell
<dash...@enternet.co.nz> wrote:
>I would argue the validity of using INITIALIZE to set Falsity. The initial
>value of a flag should be indeterminate. If you want it to be false, SET it
>so and do it explicity so there is no doubt about it. TRUE and FALSE have
>equal logical weight. It should be easily apparent from code what state is
>being set and where.
Agreed - but Set ... False is not part of the current standard - So I
use initialize or I have a false conditional that I use.
Peter E. C. Dashwood
Bill Lynch wrote in message <385C5DC3...@worldnet.att.net>...
>Interesting you should mention this:-) For the last several years ('92
>or so, when we moved up to COBOL II), I've been defining switches as PIC
>9 and placing them in their own 01-level (no VALUE clauses). In my
>initialization logic I say:
>
> INITIALIZE SWITCHES
>
>So the default value for all switches is ZERO, which usually means no
>error. Other values are from 1 thru 9 and mean whatever I need for the
>task at hand. If I have many potential values, the field is PIC 99. When
>you're writing display or print programs, any switch = ZERO means no
>errors. Any non-ZERO value is a subscript to a table of error messages.
>For YES/NO or BON/MAL or JA/NEIN, etc., ZERO is the default and anything
>non-ZERO is the opposite.
>
>Bill Lynch
Hmmmm....I take no issue with what you've written, Bill, (whatever works for
you is OK) but I would make the following observations:
1. Pic x switches are more efficient on IBM Mainframes. (It generates a
single CLI (Compare Logical Immediate, where the literal being compared is
a single byte contained in the instruction) instruction to check for 1 or 0.
If you define the switch as numeric, you may end up having a CVB (convert to
binary) followed by a PACK, followed by a CP (compare packed). All in all, a
bit of an overkill for a switch test...)
2. I'm not sure about your practise of using the values of a switch to be a
subscript into a table of errors....I guess as long as the switch is not a
simple ON/OFF (Boolean) then it's OK. It raises the question: "When is a
switch, not a switch...?"
I definitely don't like the idea of zero being the "default"...for me, zero
represents logically FALSE, so it would always be NO. (You can imagine the
trouble I had when I first learned C and found that NEGATIVE returns
represent this...)
Pete.
Peter E. C. Dashwood
Thane Hubbell wrote in message <385ce37b....@news1.attglobal.net>...
>On Sun, 19 Dec 1999 11:28:41 +1300, "Peter E. C. Dashwood"
><dash...@enternet.co.nz> wrote:
>
>This one really does not matter. The values in the 88 are
>inconsequential if one uses SET to make them true, and (presently,
>until the next standard) - Initialize to make them false.
It may not matter to you Thane, but there are many programmers around the
World to whom it DOES matter. Some non-English-first-language speakers are
actually offended when they see YES and NO being used in listings that they
have been passed from parent companies and are required to maintain. (Mind
you, that could just be peevishness at having to maintain code that was "not
invented here"...Nevertheless, I have seen this manifested on different
occasions.)
I agree that the actual values used are irrelevant when SET is employed, but
I would argue the validity of using INITIALIZE to set Falsity. The initial
value of a flag should be indeterminate. If you want it to be false, SET it
so and do it explicity so there is no doubt about it. TRUE and FALSE have
equal logical weight. It should be easily apparent from code what state is
being set and where.
Assuming the initial state of a flag to be FALSE is a recipe for disaster,
especially in on-line programs where code may be re-used. (Even COBOL code
can be "serially re-usable" (pseudo re-entrant) and the initial state of a
flag could have been long lost. Think about the case where flags are defined
as EXTERNAL...a number of modules could be inheriting the flag; it's initial
state is meaningless.
Pete.
Peter E. C. Dashwood
Bill Lynch wrote in message <385D00F1...@worldnet.att.net>...
>"Peter E. C. Dashwood" wrote:
>>
>> Hmmmm....I take no issue with what you've written, Bill, (whatever works
for
>> you is OK) but I would make the following observations:
>>
>> 1. Pic x switches are more efficient on IBM Mainframes. (It generates a
>> single CLI (Compare Logical Immediate, where the literal being compared
is
>> a single byte contained in the instruction) instruction to check for 1 or
0.
>> If you define the switch as numeric, you may end up having a CVB (convert
to
>> binary) followed by a PACK, followed by a CP (compare packed). All in
all, a
>> bit of an overkill for a switch test...)
>
>a doubleword) to binary (in a register). Worst case would be a PACK
>followed by a CP.
>
years since I wrote mainframe assembler and I mistakenly thought that it was
necessary to issue a CVB before issuing PACK. Now you've documented what it
does, those dormant brain cells have revived and I recall how it works (You
issue the CVB AFTER you've PACKED the data, or not...)
The real point is that a PACK (which is a fairly hefty instruction; it was
originally implemented as a macro...) and a CP is more overhead than a CLI.
That's why we always made our flags PIC X. I realise that these days it
really doesn't matter too much.
Now I'll just go and find Nursie and get my poultice changed....
Pete.
Peter E. C. Dashwood
James J. Gavan wrote in message <385D392D...@home.com>...
>
>....It's 25 years since I was involved with Food....
For God's sake, Jimmy, switch off the Bloody computer and go eat
something...<G>
(BTW, I liked your "split" EVALUATEs...)
Pete.
Ken Foskey
>
> Falsity - I like that! I don't see the difference between having ZERO
> = False and saying:
>
> SET SWITCH-IS-OFF TO TRUE
>
> or
>
> INITIALIZE SWITCHES (where the byte for SWITCH-OFF in a field in
> SWITCHES)
>
> Same difference to me, except you have to code the SET for every
> switch.
I personally don't like initialize to false. YEs it is good to have
defined behaviour. In this case I would prefer:
SET SWITCH TO FALSE.
I understand that the next standard caters for this. Perfectly clear
and no need to define two 88 levels.
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
donald tees
door. How the hell to you expect code to work without pizza and jolt to
bootstrap it?
Peter E. C. Dashwood wrote in message
<83k1lk$d1h$1...@hermes.enternet.co.nz>...
Michael Mattias
are careful about your WS:
01 SWITCH-BANK-1
05 SB-1 PIC 9 OCCURS 10.
88 SB-1-FALSE VALUE 0.
88 SB-1-TRUE VALUE 1.
INITIALIZE SWITCH-BANK-1
REPLACING NUMERIC DATA BY 0 << Pick one
REPLACING NUMERIC DATA BY 1 <<
--
Michael Mattias
Racine WI USA
Ken Foskey wrote in message <385E1E3A...@zip.com.au>...
Howard Brazee
>
> If you are going to pick on the way people write email, you should first try
> writing correctly yourself. If you don't know what I'm talking about, I'll
> give you a hint; Sentences do not usually begin with the word "and."
>
> >>>And checking for it being numeric or alphabetic is referencing it.
>
> That isn't even a complete sentence!
I appreciate the feedback - truly, as I do want to communicate better.
But this particular piece of language is one that I had debated with
myself over the years before I decided that I like it that way. Maybe I
am not good enough to use sentence fragments effectively, but I do like
the way they communicate when I read others use them well.
I do try writing correctly myself and I can't wait for this unending
task to end. I doubt if anybody helping me is perfect, and I don't
expect him to be perfect.
I doubt if anybody purposely says "your" when he means "you're" -
thinking this is more effective communication.