What's Missing in a COBOL Style Guide?
Colin Campbell
You provided lots of great input when I posted a proposed COBOL
Programming Standard a few days ago. One thing that came up repeatedly,
both in this newsgroup and within my company was "show us examples of
how to code, not just the prohibitions about what we cannot code".
So, I'm dusting off a Style Guide that has been laying around, probably
largely ignored. I think I can sneak it into the standard without
alarming the management too badly.
How about looking it over and telling me what else it needs to say, what
it says wrong, etc.? It is unabashedly IBM Mainframe COBOL oriented.
I'd be willing to have suggestions that apply to other platforms,
though.
Here's the document:
1985 ANSI/ISO COBOL -- Style Guide
1
Introduction
From: Colin Campbell
Date: 12 March 2003
This Style Guide for writing 1985 ANSI/ISO COBOL is intended to
suggest ways that programmers can write more readable and more
maintainable programs. Nothing in this guide needs to be taken
as a rule. Programmers are free to follow some suggestions and
ignore others. Programmers are, however, encouraged to think
about the suggestions and how they might help in programming;
also, they should read the entire document, because they may see
programs in the future which use some of these suggestions, and
need to understand the code they're seeing.
Contributions to the Style Guide are welcome from anyone coding
COBOL at CoX-ORG; they may be sent to:
Colin Campbell at xxx
General Suggestions
1.Use of comment lines:
Both the '/' and '*' in Column 7 (the 'Continue Column', in
COBOL terminology) can be used to signify comments. The '/'
causes a page eject on the output listing of any compiler,
according to the 1985 ANSI standard. Many programmers use the
'/' without any other text to start a new page, then put
comment lines starting with '*' after it, to tell what a set
of data items is for or what a procedure does. Since the '/'
is also a comment line, go ahead and start the 'comment text'
on that line, and continue with '*' lines.
Comments are often interspersed within source code, especially
in the Procedure Division, to explain to a reader the intent
of some code. Such comments should be general in their nature
(such as 'This is the case of a keyword coded without its
value'), and the code itself should be clear enough to be
understandable once the 'general idea' is given by the
comment. If the comment has to tell the reader a lot of
detail, this may mean that the code should be changed -
perhaps to improve the names of data items or conditions.
Watch for this situation.
Programmers sometimes put code in a program which they do not
intend to use in the production version of the program, such
as debugging lines, or logic which it is later decided is not
needed (but the programmer thinks might be wanted in the
future). The normal thing to do in this case is to turn
thecode into comments by putting '*' in the continue column.
Two variations on this practice might be useful.
One is to put a distinctive string, perhaps '**' or '*==>' on
such lines. This makes it easy to find all of them when
editing a program. When the saved lines prove to be needed,
you'll save time locating them. You could even use different
'comment strings' for different related groups, since there
are often data items and procedure statements which both
relate to a feature.
If you've used 'debugging lines' (usually DISPLAY verbs, with
perhaps some data items to allow conversion of indexes, etc.)
in testing your program, you may want to keep them for future
testing. COBOL contains a little used feature called the
Debug Module which can help with this. Change these lines to
true 'debug lines' by coding 'D' in the continue column. Such
lines are treated as comments unless the SOURCE-COMPUTER
paragraph contains the phrase 'WITH DEBUGGING MODE '. The
following method of coding the SOURCE-COMPUTER paragraph is
suggested:
*SOURCE-COMPUTER. IBM-390 DEBUGGING MODE.
By changing the '*' to a space, all of the 'D' lines in the
program are activated (that is, compiled and executed); by
changing the space to '*', they are all deactivated (that is,
ignored by the compiler). Since the SOURCE-COMPUTER paragraph
has no other purpose except to set the debugging mode on or
off, it may be commented or omitted.
General Suggestions
2.Use of EJECT and SKIP1/2/3:
These compiler directives are IBM extensions to COBOL, while
comment lines are defined as part of the language by ANSI.
Therefore, it would be better to use the standard method to
control the listing.
If an existing program containing EJECT and/or SKIPn
directives is being converted to ANSI 1985 COBOL, it is
relatively simple to change all of the EJECT lines to the '/'
in the continue column. The process using the ISPF/PDF Editor
would be to exclude all lines and find all occurrences of
EJECT, change all space in column 7 to '/' in the non-excluded
lines, and finally, remove all occurrences of EJECT. The
editor commands would be:
X ALL;
F ALL ' EJECT ';
C ALL NX ' ' '/' 7;
C ALL NX ' EJECT ' ''
A similar sequence could be used for SKIP1, SKIP2, and SKIP3
replacement (these would be changed to '*' in the continue
column).
While this not a document to teach ISPF, command sequences
like the one shown above can be retrieved and modified easily
by setting one of the PF keys to the value 'RETRIEVE' or
'CRETRIEV'. (Type 'KEYS' on any ISPF command line to get
access to the key meanings.)
3.Coding a COBOL Program in Mixed Case:
Beginning with 1985 ANSI COBOL, the 26 lower case alphabetic
characters may be used anywhere the 26 upper case alphabetic
characters can be used, and the lower case and upper case
equivalents are considered equal.
This means that reserved words and user defined names may be
coded in either case - "identification", "Identification",
"IdEnTiFiCaTiOn", and "IDENTIFICATION" are all equivalent and
valid. A procedure name may be defined as "READ-A-RECORD" and
referenced as "read-a-record".
Should you use upper case, as in the past, or start using
lower case, or use a mixture? This is your choice. To the
compiler, it makes no difference, because every reserved word
or name is translated to upper case for the purposes of
matching. To you, however, there is a difference. First, non-
numeric literals are NOT translated, so if you wish them to
appear in upper case on output, for example, you must enter
them in upper case. Second, while the ISPF Editor's FIND
command will find strings in either case, there may be
utilities that will not. Third, there is the question of
readability. You must decide, but the vast majority of COBOL
programs now in existence are written in upper case, so it may
be hard for a programmer to read a lower or mixed case program
as quickly.
All in all, it may be better to continue to code COBOL in
upper case, only using lower case characters in places where
they are needed, such as to compare against input, to create
mixed case messages, or the like.
Procedure Division Ideas
4.Creating Data and Procedure Names:
It is usually a good idea to choose user defined names, such
as data names and procedure names, which contain at least one
hyphen ('-') to reduce the chance that they may conflict with
current or future COBOL reserved words.
Avoid very simple words, and common words, especially if they
are Data Processing terms.
Very short names are desirable for use as subscripts and
indexes, but make them at least two characters long, to
simplify finding them when editing a program. (Think how
difficult it would be to find the occurrences of the words 'I'
or 'X' as opposed to the word 'IX'!)
If you've tried to convert an old program to 1985 ANSI COBOL
and find that the program used what is now a reserved word,
one technique for converting it might be to append '--X' to
the name (assuming it is short enough). There are no COBOL
reserved words with consecutive hyphens, and very few user
defined names.
Procedure Division Ideas
1.Coding of Periods
Code periods very sparingly in the Procedure Division.
Periods are required only at the end of a procedure header
(paragraph name, or section name followed by the word SECTION)
and at the end of a procedure (paragraph or section). The
period at the end of a procedure should be coded on a new line
in column 12 (the start of 'margin B' in COBOL terms). Since
periods are easy to overlook, this helps make it easier to
check visually that they are present.
The practice of coding a period after each statement makes
changing a program harder. For example, a series of MOVE
statements might have started out being unconditional, but
later need to be executed only if a condition is met. If each
MOVE ends with a period, then the periods must be removed to
make the whole group execute only under the condition.
One of the most common errors in COBOL programming is
misplacing periods, either putting one where it shouldn't be,
or leaving one out that is needed. Most often, this is
related to use of the IF statement. Instead of terminating IF
statements with a period, use the END-IF 'scope terminator',
and line it up with the IF to which it corresponds.
When coding nested IF's, it is not always practical to use END-
IF, because it may require two, three, four, or more to 'end'
all of the conditions. In this case, the period is a great
convenience, so it should be used, but code it on a new line
at the start of margin B. Doing this is valid COBOL syntax,
and it makes modification of the IF statement simpler, because
the period doesn't have to be removed from the 'old' last line
and replaced on a 'new' last line.
2.Aligning procedural statements:
For a set of statements in a single procedure, try to align
the word 'TO' and all of the relational operators (think of
them as being two characters long, since there are now '<='
and '=>' as well as '= ', etc.) for improved readability.
For example:
MOVE DATE--NAME TO DATA--NAME-2
IF DATA--NAME-3 = DATA--NAME-4
MOVE DATA--NAME-2 TO DATA--NAME-3
END-IF
In addition, code verbs in 'fixed' columns, leaving room for
the longer verbs (EVALUATE, SUBTRACT, and UNSTRING are each
eight characters). This generally helps the eye see each
statement more easily. Most editors can be set up to provide
tab characters so that entering the statements doesn't require
excessive use of the space bar.
The ISPF Edit and View facilities offer an aid to looking at
COBOL and other types of source code. This is the HILITE
command. In order to use it, the PC 3270 Emulator tool must
support 'Extended Attributes', and the user must choose a
terminal type that includes extended attributes. Then, when
editing a COBOL member, type "HI AUTO" on the commend line.
The result should be that the COBOL source becomes colored.
Immediately after, type "HI", which will bring up a dialog
where there are choices that can be selected using a "/".
Select all of them. Then, while still in this dialog, use the
Action Bar choice "Languages", and type the number for COBOL,
then press Enter. Yet another dialog will be started to allow
you to specify color choices for various COBOL elements. The
important one right now is "Special Characters". Choose a
distinctive color and under hilighting, type "Reverse". Then,
go to the next field, "Special Characters to highlight" and
enter the period and the semicolon. Save the changes by
pressing the End function key. When you return to viewing
your program, you'll see that all of the periods are enclosed
in a character box, and are extremely visible. These settings
will be saved in the user's profile data set for use with
every Edit or View of a COBOL program.
3.Using NOT:
If you've ever coded 'NOT >' or 'NOT <' relational operators,
it is time to stop, because 1985 ANSI COBOL allows coding '<='
(less than or equal to, the equivalent of not greater than)
and '>=' (greater than or equal to, the equivalent of not less
than). Many programmers and theorists believe that humans
have a hard time understanding the use of NOT.
Procedure Division Ideas
4.Improving PERFORM Readability:
Sequences of code which require repetitive (loop controlled)
execution and are used only once in a program used to have to
be coded as a separate procedure (paragraph or section). In
1985 ANSI COBOL, they may be written as part of an 'in line
PERFORM'. Using this option allows the programmer to avoid
creating another procedure name and also puts the code where
it is actually used, like a FORTRAN DO-loop. Here is a 1974
to 1985 ANSI COBOL comparison:
Old:
PERFORM MAKE-ROOM-IN-TABLE
VARYING 'index' FROM 'index' BY -1
UNTIL 'index' < 1
OR 'new-entry-key' > 'entry-key(index)'
MOVE 'new-entry' TO 'entry(index + 1)'
...
MAKE-ROOM-IN-TABLE SECTION.
MOVE 'entry(index)' TO 'entry(index + 1)'
.
New:
PERFORM
VARYING 'index' FROM 'index' BY -1
UNTIL 'index' < 1
OR 'new-entry-key' > 'entry-key(index)'
MOVE 'entry(index)' TO 'entry(index + 1)'
END-PERFORM
MOVE 'new-entry' TO 'entry(index + 1)'
...
5.Using 'switches' or 'flags':
Define the item where such a 'state variable' is stored
without a data name, and change the state with SET
statements. One example of needing such a variable might be
in loading a table in a subprogram when it is called for the
first time. Testing for zero occurrences in the table
wouldn't take into account the possibility of an empty input
file, so some type of first time indicator is needed. Here is
a 1974 to 1985 ANSI COBOL comparison:
Old:
77 LOAD-TABLE-FLAG PIC X(01) VALUE 'N'.
88 TABLE-LOAD-REQD VALUE 'N'.
88 TABLE-LOADED VALUE 'Y'.
...
IF TABLE-LOAD-REQD
PERFORM TABLE-LOAD
MOVE 'Y' TO LOAD-TABLE-FLAG
New:
77 PIC X(01) VALUE 'N'.
88 TABLE-LOAD-REQD VALUE 'N'.
88 TABLE-LOADED VALUE 'Y'.
...
IF TABLE-LOAD-REQD
PERFORM TABLE-LOAD
SET TABLE-LOADED TO TRUE
END-IF
As you can see, there are two advantages to this technique.
First, the need to invent another data name is avoided.
Second, the values associated with the 'state' of the variable
don't have to be known in the Procedure Division; in fact,
they could be changed to '0' and '1' or anything else without
requiring any change to the Procedure Division.
Procedure Division Ideas
6. Writing compound conditional expressions:
Compound conditional expressions (multiple simple conditions
connected by AND or OR) can be the source of problems in
programs, especially when maintenance is done by someone not
familiar with a program.
One reason is that the AND or OR words usually 'hide' at the
end of a line. Consider moving them to the start of the next
line, and limiting the number of conditions per line to one.
This will make the 'AND' and 'OR' more visible, and if they
are aligned under the related 'IF' or 'WHEN', there will be
more room on the line to write the condition. Finally, if one
of the conditions is deleted, or a new condition is added, it
will usually only be necessary to delete or insert one line,
and the danger of leaving a 'hanging' AND or OR or forgetting
to put one in is reduced. Here is an example:
IF TABLE-LOAD-REQD
AND TABLE-STATUS = '00'
PERFORM TABLE-LOAD
SET TABLE-LOADED TO TRUE
END-IF
7.Writing expressions:
Expressions used in COMPUTE, IF, and elsewhere are handled by
COBOL compilers according to a set of rules which control the
order of evaluation, such as those for AND and OR in
conditional expressions and those for '**', '*', '/', '+', and
'-' in arithmetic expressions.
Parentheses are required only to force expressions to be
evaluated in a different order than the rules of COBOL would
normally cause them to be evaluated. Some programmers use
them to 'clarify' a program, so that there will be no doubt
about the order of evaluation. You might consider whether
code which 'needs' such clarification is what you want to
write. Sometimes, however, the parentheses are required. In
such cases, consider coding each parenthesis on a line by
itself, or no more than one set of left and right parentheses
on a line. The first technique makes the parentheses more
visible, and the second makes it easier to be sure that they
are balanced, especially when changing the expression.
Here is an example:
COMPUTE ANSWER = (
C
+ (A + 1)
* (B - 2)
)
Remember that the ISPF Editor now can help with this task.
There is a "HILITE" command available, which can be used to
colorize COBOL code and check for balanced parentheses. You
must have your terminal emulator set up to use "Extended
Attributes".
James J. Gavan
Colin Campbell wrote:
> Folks,
> You provided lots of great input when I posted a proposed COBOL
> Programming Standard a few days ago. One thing that came up repeatedly,
> both in this newsgroup and within my company was "show us examples of
> how to code, not just the prohibitions about what we cannot code".
>
Colin, As it's Mainframe - just a couple of pointers which are fairly
universal :-
My preference, use numerics for 88s. Agreed you can do it with alpha, but :-
01 MYFLAG PIC 9(03) VALUE ZERO..
88 VALIDATION-OK VALUE 0.
88 ERROR-NAME VALUE 1.
88 ERROR-ZIPCODE VALUE 2.
88 ERROR- VALUE 3. ETC....
88 WARNING-ERRORS VALUE 1 THRU 9
88 CRITICAL-ERRORS VALUE 20 THRU 35.
Groupings like VALIDATION-OK, WARNING-ERRORS and CRITICAL-ERRORS allow you
to make specific decisions.
Doesn't always work avoiding that "need to invent another data name". (OK -
so now I'm going back to lowercase - phew !). Here's one I'm currently
testing with sorting collections into different sequences:-
01 SequenceFlag pic 9.
88 NewByName value 1.
88 NewByCountry value 2.
88 NewByType value 3.
88 ValidSequence value 1 thru 3.
01 Old-SequenceFlag pic 9.
88 OldByName value 1.
88 OldByCountry value 2.
88 OldByType value 3.
................
display "Phase 2 - Default Sort using MOVE CORRESPONDING"
move 9 to SequenceFlag
perform CHOICE-PARA until SequenceFlag = zeroes
EXIT METHOD.
CHOICE-PARA.
display " "
display "Select sequence :"
display "(1) By name (2) By Country (3) By Type (0) Quit routine"
accept SequenceFlag
Evaluate true
when Old-SequenceFlag = SequenceFlag
display "*** Already in sequence you requested ***"
when ValidSequence
move zeroes to Kounter
etc..........
Note that when I have finished doing the callback which displays the
re-sorted list I then move SequenceFlag to Old-SequenceFlag.
>
>
> Procedure Division Ideas
>
> 6. Writing compound conditional expressions:
>
> Compound conditional expressions (multiple simple conditions
> connected by AND or OR) can be the source of problems in
> programs, especially when maintenance is done by someone not
> familiar with a program.
>
> One reason is that the AND or OR words usually 'hide' at the
> end of a line. Consider moving them to the start of the next
> line, and limiting the number of conditions per line to one.
> This will make the 'AND' and 'OR' more visible, and if they
> are aligned under the related 'IF' or 'WHEN', there will be
> more room on the line to write the condition. Finally, if one
> of the conditions is deleted, or a new condition is added, it
> will usually only be necessary to delete or insert one line,
> and the danger of leaving a 'hanging' AND or OR or forgetting
> to put one in is reduced. Here is an example:
> IF TABLE-LOAD-REQD
> AND TABLE-STATUS = '00'
> PERFORM TABLE-LOAD
> SET TABLE-LOADED TO TRUE
> END-IF
>
Some have a tendency to 'bracket' the conditions - and I think that's a good
idea for clarity :-
IF ( TABLE-LOAD-REQD) AND
( TABLE-STATUS = '00')
etc.,,,,,,
Just my $0.02
Jimmy, Calgary AB
Thane Hubbell
> Folks,
> You provided lots of great input when I posted a proposed COBOL
> Programming Standard a few days ago. One thing that came up repeatedly,
> both in this newsgroup and within my company was "show us examples of
> how to code, not just the prohibitions about what we cannot code".
>
> So, I'm dusting off a Style Guide that has been laying around, probably
> largely ignored. I think I can sneak it into the standard without
> alarming the management too badly.
>
> How about looking it over and telling me what else it needs to say, what
> it says wrong, etc.? It is unabashedly IBM Mainframe COBOL oriented.
> I'd be willing to have suggestions that apply to other platforms,
> though.
>
> Here's the document:
... Snipped ...
Colin,
I really like the guide. I like the fact that it is a GUIDE - the
TONE is excellent!!! The REASONS for the specified suggestions were
plain, clear and logical. I like the document a lot.
Robert Wagner
I'll restrict these comments to what I see wrong rather than missing.
>2.Aligning procedural statements:
>
> For a set of statements in a single procedure, try to align
> the word 'TO' and all of the relational operators (think of
> them as being two characters long, since there are now '<='
> and '=>' as well as '= ', etc.) for improved readability.
> For example:
>
> MOVE DATE--NAME TO DATA--NAME-2
> IF DATA--NAME-3 = DATA--NAME-4
> MOVE DATA--NAME-2 TO DATA--NAME-3
> END-IF
No, no. Goofy spacing doesn't make a program more readable.
>3.Using NOT:
> If you've ever coded 'NOT >' or 'NOT <' relational operators,
> it is time to stop, because 1985 ANSI COBOL allows coding '<='
> (less than or equal to, the equivalent of not greater than)
> and '>=' (greater than or equal to, the equivalent of not less
> than). Many programmers and theorists believe that humans
> have a hard time understanding the use of NOT.
It's true that humans have a hard time understanding NOT. We programmers who
understand Boolean algebra don't. Constructs such as <= contain an unnecessary
OR whereas not > is a single condition. Please delete this paragraph.
>7.Writing expressions:
>
> Expressions used in COMPUTE, IF, and elsewhere are handled by
> COBOL compilers according to a set of rules which control the
> order of evaluation, such as those for AND and OR in
> conditional expressions and those for '**', '*', '/', '+', and
> '-' in arithmetic expressions.
>
> Parentheses are required only to force expressions to be
> evaluated in a different order than the rules of COBOL would
> normally cause them to be evaluated. Some programmers use
> them to 'clarify' a program, so that there will be no doubt
> about the order of evaluation. You might consider whether
> code which 'needs' such clarification is what you want to
> write. Sometimes, however, the parentheses are required. In
> such cases, consider coding each parenthesis on a line by
> itself, or no more than one set of left and right parentheses
> on a line. The first technique makes the parentheses more
> visible, and the second makes it easier to be sure that they
> are balanced, especially when changing the expression.
> Here is an example:
> COMPUTE ANSWER = (
> C
> + (A + 1)
> * (B - 2)
> )
Forget the 'rules of COBOL'. Parentheses should always be written when a
statement contains a mixture of AND and OR, or +/- and multiply or divide.
Robert
William M. Klein
As usual an excellent document, BUT ... you know me. A few comments and
suggestions below.
--
Bill Klein
wmklein <at> ix.netcom.com
"Colin Campbell" <cmc...@attglobal.net> wrote in message
news:3E6FC7EC...@attglobal.net...
<snip>
WMK - my personally preferred way to code this is:
Source-Computer. IBM-390
* Debugging Mode
.
where ONLY the "debuging mode" line is a comment-line (withe the period on a
separate line following it)
>
<snip>
>
> 3.Coding a COBOL Program in Mixed Case:
>
> Beginning with 1985 ANSI COBOL, the 26 lower case alphabetic
> characters may be used anywhere the 26 upper case alphabetic
> characters can be used, and the lower case and upper case
> equivalents are considered equal.
WMK - except, of course within alphanumeric literals - as you state later
>
> This means that reserved words and user defined names may be
> coded in either case - "identification", "Identification",
> "IdEnTiFiCaTiOn", and "IDENTIFICATION" are all equivalent and
> valid. A procedure name may be defined as "READ-A-RECORD" and
> referenced as "read-a-record".
>
> Should you use upper case, as in the past, or start using
> lower case, or use a mixture? This is your choice. To the
> compiler, it makes no difference, because every reserved word
> or name is translated to upper case for the purposes of
> matching. To you, however, there is a difference. First, non-
> numeric literals are NOT translated, so if you wish them to
> appear in upper case on output, for example, you must enter
> them in upper case. Second, while the ISPF Editor's FIND
> command will find strings in either case, there may be
> utilities that will not. Third, there is the question of
> readability. You must decide, but the vast majority of COBOL
> programs now in existence are written in upper case, so it may
> be hard for a programmer to read a lower or mixed case program
> as quickly.
>
> All in all, it may be better to continue to code COBOL in
> upper case, only using lower case characters in places where
> they are needed, such as to compare against input, to create
> mixed case messages, or the like.
WMK - but this may change over time - and not be true in text books, IBM
manuals, or other samples that you will see. Therefore, it may help to at
least become familar with mixed-case source code.
>
> Procedure Division Ideas
>
> 4.Creating Data and Procedure Names:
>
> It is usually a good idea to choose user defined names, such
> as data names and procedure names, which contain at least one
> hyphen ('-') to reduce the chance that they may conflict with
> current or future COBOL reserved words.
WMK - new reserved words MAY include a single hyphen (and in fact many were
introduced in the 2002 Standard with this. To avoid this, you can create
new user-defined words with double contguous hyphens - or a hyphen after the
first or second letter.
>
<snip>
WMK - special note, you may not (in IBM or any other "strictly '85 Standard)
COBOL use any "AFTER" phrases with inline PERFORMs. This restriction is
removed in the 2002 Standard, but so far - if you are vaying multiple items
with IBM compilers, you must still use out-of-line PERFORMs.
<snip>
>
<snip>
Some other ideas to consider:
- Line up Picture and Usage clauses in Data Division.
- If you have "long" alphanumeric literals in the data division, place the
reserved word VALUE on one line and then the literal on the next line. If
the value is longer than will fit into one line, consider using multiple
filler items - rather than a single "continued" literal.
- NEVER continue a COBOL word across lines (even though the compiler allows
this). ISPF won't find it then (and it is also easy to miss in
maintenance).
- Use "standard) numbering for levels in Data Division. (I sill use the 01,
05, 10 ... method) as this allows room to insert "middle" levels if
absolutely required during maintenance. Remember that *if* you use the
CORRESPONDING phrase, how you set up "levels" can make a difference.
- Avoid 66 levels. With IBM compilers there is no performance difference
between a 77 level and an elementary 01-level. However, some programmers
find 77-levels more "self-documenting" for items that are not grouped.
- Using "THRU" values in 88-levels may be dangerous if you might ever "port"
your program to another environment (such as changing from EBCDIC to ASCII).
Unless the list is really too long, consider listing all "valid" values
individually.
- The INITIALIZE statement is your friend. However, you need to understand
what it does and does not do (such as the fact that it does NOT change items
defined as FILLER).
- When using Reference Modification with "arithmetic expressions) as either
the starting point or the length, make certain that your expression will
always evaluate to an integer. If it doesn't, results may vary from
compiler to compiler (some round while others truncate).
- When using intrinsic functions with "requirements" on their arguments,
make certain that you "test" the data used as an argument first, e.g. date
intrinsic functions must have "valid dates" as input. Similar restrictions
exist for some (but not all) LE callable services. Always check for return
codes after LE callable services.
- If you use "interfaces" such as DB2 or certain CICS functions, make
certain that you "zero-out" the Return-Code special register after such
accesses - otherwise, your program may APPEAR to have a problem in your
SYSLOG output that isn't a real problem. See for example:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg10/3.2.1.4
Thane Hubbell
rob...@wagner.net (Robert Wagner) wrote in message news:<3e7005d6....@news.optonline.net>...
> Colin Campbell <cmc...@attglobal.net> wrote:
>
> I'll restrict these comments to what I see wrong rather than missing.
>
> >2.Aligning procedural statements:
> >
> > For a set of statements in a single procedure, try to align
> > the word 'TO' and all of the relational operators (think of
> > them as being two characters long, since there are now '<='
> > and '=>' as well as '= ', etc.) for improved readability.
> > For example:
> >
> > MOVE DATE--NAME TO DATA--NAME-2
> > IF DATA--NAME-3 = DATA--NAME-4
> > MOVE DATA--NAME-2 TO DATA--NAME-3
> > END-IF
>
> No, no. Goofy spacing doesn't make a program more readable.
>
But it sure makes it more editable, and helps automated conversion
tools extend the life of the program, especially if the alignment
rules are strictly followed. I had the great pleasure of converting a
customers system from Realia to Fujitsu COBOL and since he religiously
followed rules like this a majority of the conversion was automated
via a conversion program. I don't PERSONALLY follow this style, but I
don't see anything at all wrong with it.
> >3.Using NOT:
> > If you've ever coded 'NOT >' or 'NOT <' relational operators,
> > it is time to stop, because 1985 ANSI COBOL allows coding '<='
> > (less than or equal to, the equivalent of not greater than)
> > and '>=' (greater than or equal to, the equivalent of not less
> > than). Many programmers and theorists believe that humans
> > have a hard time understanding the use of NOT.
>
> It's true that humans have a hard time understanding NOT. We programmers who
> understand Boolean algebra don't. Constructs such as <= contain an unnecessary
> OR whereas not > is a single condition. Please delete this paragraph.
>
I'm one of the people who says "don't be afraid of negative logic",
but some otherwise quite capable and talented programmers do seem to
have trouble. Could be because of the symbolic logic course I took a
long time ago, but overall from a maintenance standpoint I think the
original advice is excellent.
<Sarcasm>There's some good advice for a COBOL programmer. </Sarcasm>
Peter E.C. Dashwood
I simply haven't had time to read the whole Guide, however I have quickly
browsed the responses.
I agree with Thane that the TONE is right.
30 years ago I had to formulate exactly such a guide for a COBOL shop in New
Zealand. (I still have a copy of it somewhere in the attic <G>...was so
proud of it I kept it). I remember that then as now, the secret is to
ENCOURAGE programmers (rather than COERCE them) into agreeing a consistent
coding style.
Colin's document, in its introduction, does this.
Programmers are usually intelligent people who don't react well to words
like "MANDATORY" "REQUIRED" or "YOU WILL DO THIS".
In hindsight ,with broader and longer experience, having seen many flame
wars over style, I have a much more relaxed attitude now than I had even
then. But I can afford that indulgence; most corporate shops can't. We do
need standards and gudelines for consistency, but we need to be open minded
and gentle in enforcing them.
I have to say that I also endorse 100% Robert's comments on points 3 and 7
below. (I don't really care about "goofy spacing"...)
I too am from the school where programmers were required to learn Logic, and
Boolean Algebra and Propositional Calculus are both very dear to my heart
(as previous posts here have demonstrated.)
There is nothing difficult about learning the proper Boolean use of
Negation, and a single day is more than enough for any programmer who wants
to learn the basics of AND, OR, NOT, De Morgan's Laws (which many old hands
learn by bitter experience without even knowing they learned it <G>) and the
use of Boolean simplification to take the knots out of complex conditions
and nested IFs. I have run such courses in-house on countless occasions. If
anyone here is interested in a tutorial or would like more on this, simply
indicate your interest and I'll gladly provide it.
I think it would be a pity to see NOT being banned in relational conditions
because it is considered by "humans" <G> to simply be a means of saying
"greater than or equal to" or "less than or equal to" or "unequal to"...
For the same reason, I hate to see flags being set to "Y" or "N" when 1
indicates TRUE and 0 indicates FALSE. (I hate it even more when certain
languages corrupt this pure concept into letting a negative value indicate
FALSE, just because it is easier to implement on certain hardware...). But
that's just me, and those are simply MY preferences. I don't think it is
RIGHT or WRONG to set flags to "Y" or "N" (as Paul Simon says, "...I have no
opinion about that...").
Pete.
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3e7005d6....@news.optonline.net...
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Joe Zitzelberger
> indexes, but make them at least two characters long, to
> simplify finding them when editing a program. (Think how
> difficult it would be to find the occurrences of the words 'I'
> or 'X' as opposed to the word 'IX'!)
In ISPF you can use 'f I word' or 'f X word all'
and find only the single char subscripts.
>3.Using NOT:
> If you've ever coded 'NOT >' or 'NOT <' relational operators,
> it is time to stop, because 1985 ANSI COBOL allows coding '<='
> (less than or equal to, the equivalent of not greater than)
> and '>=' (greater than or equal to, the equivalent of not less
> than). Many programmers and theorists believe that humans
> have a hard time understanding the use of NOT.
> Procedure Division Ideas
In the case of Cobol relation operators there is one screwy
thing that makes me a bit edgy, trying to pronounce the
operators comes out as:
<= -- Less or equal
= -- Equal
>= -- Greater or equal (huh?!?)
In my well ordered, though often misunderstood, mind this
ought to be '=>', as one would speak it, 'equal or greater'.
Now I realize that there are many different dialects and
opinions -- some people might actually say 'greater or
equal'. My personal opinion is that "NOT <" is an easier
read than ">=". Since I automatically, initially, type
it as "=>", using "NOT <" saves me an extra compile.
Also, as Cobol does not allow '<>' a programmer still needs to
write 'NOT ='.
Anyway, I'm not sure how a programmer can understand any
relational operator without also understanding its
compliment. They define each other.
<rant>
Not specifically related to relation operators, but to
the general 'NOT is hard to read' idea...
In its most perverted form this rule can actually reduce
readability by requiring odd-looking constructs like:
IF A=B
CONTINUE
ELSE
STATEMENTS WHEN A NOT = B
END-IF
The boolean condition of an IF statement can only resolve to
two states. It doesn't make much sense to me that a programmer
can understand one state without understanding the other state
completely. If you can grasp the true condition then the
not-true is equally graspable as 'everything else'.
</rant>
Finally, I would suggest another comment -- 'Whitespace
and indentation are your friends'.
Grouping lines that are logically executed together,
such as the body of an IF or PERFORM and visually
setting them off from the surrounding statements
is a great assist to readability.
Richard Plinston
> Now I realize that there are many different dialects and
> opinions -- some people might actually say 'greater or
> equal'.
They do.
If fact if you wanted to use the long form of Cobol it would be:
IF variable-1 IS GREATER THAN OR EQUAL TO variable-2
THEN ...
However, NOT < is OK too.
Colin Campbell
"James J. Gavan" wrote:
>
>
> Colin, As it's Mainframe - just a couple of pointers which are fairly
> universal :-
>
> >
> >
I'm sorry, I cannot see any "clarity" gain by placing parentheses around a
condition-name or a simple condition, just because there is a logical connector
between them. You can't fool the compiler, who won't mind either way of writing
it. But I don't think this would help a human reader, either.
Even if a program coded the IF this way, it would still be my preference to put
the logical connector at the start of the line, to make it more visible.
Colin
Colin Campbell
I'm sure where you say "forget the rules of COBOL", you mean that you are adding
to them. Since we're talking about COBOL code, we cannot "forget the rules".
Colin
>
> Forget the 'rules of COBOL'. Parentheses should always be written when a
> statement contains a mixture of AND and OR, or +/- and multiply or divide.
>
> Robert
I would have to assume you have a reason for saying so, and that it stems directly
from the rules you say to forget.
Colin Campbell
I don't even mind the three line version of SOURCE-COMPUTER). You certainly
pointed out some things I forgot to say, like DATA DIVISION phrase alignment.
Maybe this practice is so nearly universal that I forgot it! Still, it will go
into the revision.
Colin
Colin Campbell
Thanks for your input. With respect to your comment about ISPF Editor
"Find", let me point out the following:
I just added the following two statements to a COBOL program:
77 I BINARY PIC S9(4) VALUE ZERO.
77 I-X BINARY PIC S9(4) VALUE ZERO.
Then, I typed "f i word all".
Result:
Both of the lines I added were highlighted, because the Editor doesn't
treat the hyphen correctly.
(And, by the way, typing "F all 'x' word" results in highlighting the
I-X entry.)
This is precisely the problem that my advice attempts to address.
Colin
Thane Hubbell
>
> >
> > Procedure Division Ideas
> >
> > 4.Creating Data and Procedure Names:
> >
> > It is usually a good idea to choose user defined names, such
> > as data names and procedure names, which contain at least one
> > hyphen ('-') to reduce the chance that they may conflict with
> > current or future COBOL reserved words.
>
> WMK - new reserved words MAY include a single hyphen (and in fact many were
> introduced in the 2002 Standard with this. To avoid this, you can create
> new user-defined words with double contguous hyphens - or a hyphen after the
> first or second letter.
>
Use caution if they are EC- however.
>
> - The INITIALIZE statement is your friend. However, you need to understand
> what it does and does not do (such as the fact that it does NOT change items
> defined as FILLER).
>
Lest anyone thing that the non initialization of filler is "wrong" - it's not.
It's to allow one to do this:
01 SOCIAL-SEC-NUM.
03 FIRST-3 pic 999.
03 FILLER PIC X VALUE "-".
03 SECOND-2 PIC 99.
03 FILLER PIC X VALUE "-".
03 LAST-3 PIC 999.
Then when you INITIALIZE SOCIAL-SEC-NUM you don't lose your "-" characters.
Robert Wagner
>I remember that then as now, the secret is to
>ENCOURAGE programmers (rather than COERCE them) into agreeing a consistent
>coding style.
The shops I managed for 20+ years had no published programming standards. Yet
style was so standardized that you couldn't tell from reading code who wrote it.
I accomplished it through social pressure (pride) and deliberately assigning
maintenance to someone other than the original author. They knew the code they
wrote today would need to be understood and modified by a cohort tomorrow.
>Colin's document, in its introduction, does this.
>
>Programmers are usually intelligent people who don't react well to words
>like "MANDATORY" "REQUIRED" or "YOU WILL DO THIS".
That's ok if the Standards author knows what he's talking about, and
substantiates strictures with examples. If he doesn't, we'll find ways around
the Standard.
>In hindsight ,with broader and longer experience, having seen many flame
>wars over style, I have a much more relaxed attitude now than I had even
>then. But I can afford that indulgence; most corporate shops can't. We do
>need standards and gudelines for consistency, but we need to be open minded
>and gentle in enforcing them.
Mainframe shops are seldom 'gentle in enforcing them'.
>There is nothing difficult about learning the proper Boolean use of
>Negation, and a single day is more than enough for any programmer who wants
>to learn the basics of AND, OR, NOT, De Morgan's Laws (which many old hands
>learn by bitter experience without even knowing they learned it <G>) and the
>use of Boolean simplification to take the knots out of complex conditions
>and nested IFs. I have run such courses in-house on countless occasions. If
>anyone here is interested in a tutorial or would like more on this, simply
>indicate your interest and I'll gladly provide it.
I wrote one in Best Practices. Nobody commented on it.
>I think it would be a pity to see NOT being banned in relational conditions
>because it is considered by "humans" <G> to simply be a means of saying
>"greater than or equal to" or "less than or equal to" or "unequal to"...
Computer: a machine not as intelligent as a human being but more intelligent
than a programmer. :)
>For the same reason, I hate to see flags being set to "Y" or "N" when 1
>indicates TRUE and 0 indicates FALSE. (I hate it even more when certain
>languages corrupt this pure concept into letting a negative value indicate
>FALSE, just because it is easier to implement on certain hardware...). But
>that's just me, and those are simply MY preferences. I don't think it is
>RIGHT or WRONG to set flags to "Y" or "N" (as Paul Simon says, "...I have no
>opinion about that...").
I use flags extensively. I always use low-value as false. True value may be 'y'
or may be a letter representing the proposition. It is never 1. I don't see
what difference it makes.
Robert Wagner
>> No, no. Goofy spacing doesn't make a program more readable.
>
>But it sure makes it more editable, and helps automated conversion
>tools extend the life of the program, especially if the alignment
>rules are strictly followed. I had the great pleasure of converting a
>customers system from Realia to Fujitsu COBOL and since he religiously
>followed rules like this a majority of the conversion was automated
>via a conversion program. I don't PERSONALLY follow this style, but I
>don't see anything at all wrong with it.
We don't program to make conversion easier; we program to make maintenance
easier .
>> Forget the 'rules of COBOL'. Parentheses should always be written when a
>> statement contains a mixture of AND and OR, or +/- and multiply or divide.
>
><Sarcasm>There's some good advice for a COBOL programmer. </Sarcasm>
I deliberately inserted a logic error to see whether anyone would catch it.
Nobody did. If they don't catch it here, they won't in source programs either.
The statement should have read:
when a statement contains a mixture of (AND and OR) or (+/- and (multiply or
divide))
Robert Wagner
>Robert,
>I'm sure where you say "forget the rules of COBOL", you mean that you are
adding
>to them. Since we're talking about COBOL code, we cannot "forget the rules".
>Colin
I'm saying your programmers will 'forget the rules of COBOL', so don't make
remembrance a precept of the Standard.
>> Forget the 'rules of COBOL'. Parentheses should always be written when a
>> statement contains a mixture of AND and OR, or +/- and multiply or divide.
You didn't point out the logcal error in the above sentence. If you can't see
it, neither can your programmers.
Robert Wagner
>I would have to assume you have a reason for saying so, and that it stems
directly
>from the rules you say to forget.
This is one of the most error-prone, bug-prone avenues of COBOL. Writing
explicit parentheses solves the problem completely.
Robert Wagner
>> - The INITIALIZE statement is your friend. However, you need to understand
>> what it does and does not do (such as the fact that it does NOT change items
>> defined as FILLER).
>>
>
>Lest anyone thing that the non initialization of filler is "wrong" - it's not.
Yes, it is wrong. It doesn't initialize FILLERs nor pointers.
>It's to allow one to do this:
>
>01 SOCIAL-SEC-NUM.
> 03 FIRST-3 pic 999.
> 03 FILLER PIC X VALUE "-".
> 03 SECOND-2 PIC 99.
> 03 FILLER PIC X VALUE "-".
> 03 LAST-3 PIC 999.
>
>Then when you INITIALIZE SOCIAL-SEC-NUM you don't lose your "-" characters.
WMK thinks INITIALIZE should restore initial values. That's plausible. It would
address your objection. But lacking an initial value, it should restore pointers
to null and fillers to spaces (pic x) or zeros (pic 9 display) or low-values
(any other pic). I'll write 'move low-values to ...' until they get it right.
Peter E.C. Dashwood
represents the additive identity in ANY algebra. In a Boolean Algebra, the
multiplicative identity represents universal truth; and the additive
identity represents the negation of this.
Like I said, these are preferences... it really doesn't matter.
Pete.
Thane Hubbell
I hate to jump on the Robert you are wrong bandwagon, but Robert - you
are wrong.
The non initialization of filler is Correct in '85 COBOL and not
broken. (We were not talking abotu COBOL 2002 features which I will
get into). I have no clue where your comment on pointers came from,
since there is no usage Pointer in 85 COBOL - whatever an implementor
does with his special values is up to him.
Now with COBOL 2002 you CAN INITIALIZE filler and you can INITIALIZE
to the initial value, so I have no clue where your WMK comments came
from either. COBOL 85 doesn't - it's not broken.
SkippyPB
<dash...@enternet.co.nz> enlightened us:
>
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e71366b....@news.optonline.net...
>> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>>
>> I use flags extensively. I always use low-value as false. True value may
>be 'y'
>> or may be a letter representing the proposition. It is never 1. I don't
>see
>> what difference it makes.
>>
>The difference is that 1 represents the multiplicative identity and 0
>represents the additive identity in ANY algebra. In a Boolean Algebra, the
>multiplicative identity represents universal truth; and the additive
>identity represents the negation of this.
>
>Like I said, these are preferences... it really doesn't matter.
>
>Pete.
>
Also the actual value of the literal low-value is not the same on
every system. Therefore its use may not be portable or make sense.
Much better to use 0 (zero) = off; 1 = on; or y = yes or on; n = no or
off; all of which are portable and readable.
Regards,
////
(o o)
-oOO--(_)--OOo-
Micro$oft Haiku Error Message #109
Program aborting:
Close all that you have worked on.
You ask far too much.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
William M. Klein
Standard compiler) INITIALIZE *should* change FILLER values. Apparently Mr.
Wagner (whose notes I am now not even seeing) decided it was safe to ignore
what I wrote and put (incorrect) words in my mouth.
I did, however, point out that users of the INITIALIZE statement need to
know exactly what it does and does not do and I gave the fact that it does
not initialize FILLER items as an example.
As Thane and I are both well aware, there are BUNCHES of enhancements to the
INITIALIZE statement in the 2002 Standard including the option (not default)
to initialize filler items as well as the ability to initialize items to the
original VALUE clause.
--
Bill Klein
wmklein <at> ix.netcom.com
"Thane Hubbell" <tha...@softwaresimple.com> wrote in message
news:bfdfc3e8.03031...@posting.google.com...
Richard
> >> - The INITIALIZE statement is your friend. However, you need to understand
> >> what it does and does not do (such as the fact that it does NOT change items
> >> defined as FILLER).
> Yes, it is wrong. It doesn't initialize FILLERs nor pointers.
The qualification above indicates that you need to _understand_
INITIALISE. As you have demonstrated many times before your
understanding is not of Cobol but of some stuff that you invented
decades ago without reading the manual.
INITIALISE is _not_ wrong. It may not match what your opinion of what
it might do, but that simply indicates that it is your understanding
that is wrong.
> >01 SOCIAL-SEC-NUM.
> > 03 FIRST-3 pic 999.
> > 03 FILLER PIC X VALUE "-".
> > 03 SECOND-2 PIC 99.
> > 03 FILLER PIC X VALUE "-".
> > 03 LAST-3 PIC 999.
> WMK thinks INITIALIZE should restore initial values. That's plausible.
WMK is aware of every nuance of INITIALISE. It will be able to
restore initial values in the '2002 standard.
> It would address your objection.
It wasn't an 'objection' it was an 'explanation', a 'clarification'.
You obviously didn't understand that, but then _anything_ that doesn't
agree with you is 'quibbling' even when it is intended to educate you
to as to how and why it actually works.
> But lacking an initial value, it should restore pointers
> to null and fillers to spaces (pic x) or zeros (pic 9 display) or low-values
> (any other pic).
No it _shouldn't_, not in the current standard, it should work exactly
as it is _defined_ to work. It may well be able to work differently
when told to in some future compilers.
If you want 'filler' to be set to spaces or zero all that is required
is that you give them a name, that is how the INITIALISE knows whether
you want the field set to some initial value or not.
Learn how the language can be instructed to bahave as you want it to
and stop complaining that it doesn't work some other way.
> I'll write 'move low-values to ...'
It might be very poor practice to move low-values to display numeric
fields, they should be set to all zero, other values _may_ give
incorrect results or may not pass a NUMERIC test.
It is very poor practice to set fields to low-values if they will be
written to a terminal or printer as the behaviour of these is
different from spaces - they will be ignored while a space will move
the output one character to the right.
> until they get it right.
Why don't you get your understanding of Cobol 'right' and then you
will stop making these stupid assertions about how ignorant you are.
Robert Wagner
>Just to be clear, WMK never claimed that he thought that (with an '85
>Standard compiler) INITIALIZE *should* change FILLER values. Apparently Mr.
>Wagner (whose notes I am now not even seeing) decided it was safe to ignore
>what I wrote and put (incorrect) words in my mouth.
I was referring to discussions about how the 2002 standard should work, not what
the 85 standard specified.
Robert Wagner
>
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e71366b....@news.optonline.net...
>> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>>
>> I use flags extensively. I always use low-value as false. True value may
>be 'y'
>> or may be a letter representing the proposition. It is never 1. I don't
>see
>> what difference it makes.
>>
>The difference is that 1 represents the multiplicative identity and 0
>represents the additive identity in ANY algebra. In a Boolean Algebra, the
>multiplicative identity represents universal truth; and the additive
>identity represents the negation of this.
Any non-zero value represents 'multiplicative identity' and 'universal truth'..
The value 1 has no special significance.
I use meaningful values so I can understand them on diagnostic DISPLAYs.
COBOL doesn't offer bit-sized variables. The smallest we get is a byte. We might
as well use the eight bits to convey human-readable information.
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote in message
news:<3e714988....@news.optonline.net>...
>> tha...@softwaresimple.com (Thane Hubbell) wrote:
>>
>> >> - The INITIALIZE statement is your friend. However, you need to
understand
>> >> what it does and does not do (such as the fact that it does NOT change
items
>> >> defined as FILLER).
>> >>
>> >
>> >Lest anyone thing that the non initialization of filler is "wrong" - it's
not.
>>
>> Yes, it is wrong. It doesn't initialize FILLERs nor pointers.
>> >It's to allow one to do this:
>> >
>> >01 SOCIAL-SEC-NUM.
>> > 03 FIRST-3 pic 999.
>> > 03 FILLER PIC X VALUE "-".
>> > 03 SECOND-2 PIC 99.
>> > 03 FILLER PIC X VALUE "-".
>> > 03 LAST-3 PIC 999.
>> >
>> >Then when you INITIALIZE SOCIAL-SEC-NUM you don't lose your "-" characters.
>>
>I hate to jump on the Robert you are wrong bandwagon, but Robert - you
>are wrong.
>
>The non initialization of filler is Correct in '85 COBOL and not
>broken. (We were not talking about COBOL 2002 features which I will
>get into). I have no clue where your comment on pointers came from,
>since there is no usage Pointer in 85 COBOL - whatever an implementor
>does with his special values is up to him.
I don't dispute that compilers follow the 85 standard. I'm talking about about
how INITITIALIZE 'should' work.
>Now with COBOL 2002 you CAN INITIALIZE filler and you can INITIALIZE
>to the initial value, so I have no clue where your WMK comments came
>from either. COBOL 85 doesn't - it's not broken.
The 2002 solution is a political compromise. INITIALIZE should clear everything
without needing to add special syntax for FILLERs and initial values
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote
>
>> >> - The INITIALIZE statement is your friend. However, you need to
understand
>> >> what it does and does not do (such as the fact that it does NOT change
items
>> >> defined as FILLER).
>
>> Yes, it is wrong. It doesn't initialize FILLERs nor pointers.
>
>The qualification above indicates that you need to _understand_
>INITIALISE. As you have demonstrated many times before your
>understanding is not of Cobol but of some stuff that you invented
>decades ago without reading the manual.
Forgive my ignorance, m'lord, I'm just a COBOL programmer. You said yourself I'm
stupid. Don't now chastise me for failing to underatand INITIALIZE. You can't
have it both ways.
>If you want 'filler' to be set to spaces or zero all that is required
>is that you give them a name, that is how the INITIALISE knows whether
>you want the field set to some initial value or not.
Bull. I want the structure initialized, whether fields are FILLER or not.
>It might be very poor practice to move low-values to display numeric
>fields, they should be set to all zero, other values _may_ give
>incorrect results or may not pass a NUMERIC test.
Agreed. I'll initialize them separately if necessary.
Robert Wagner
>On Fri, 14 Mar 2003 12:38:32 -0000, "Peter E.C. Dashwood"
><dash...@enternet.co.nz> enlightened us:
>
>>
>>"Robert Wagner" <rob...@wagner.net> wrote in message
>>news:3e71366b....@news.optonline.net...
>>> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>>>
>>> I use flags extensively. I always use low-value as false. True value may
>>be 'y'
>>> or may be a letter representing the proposition. It is never 1. I don't
>>see
>>> what difference it makes.
>>>
>>The difference is that 1 represents the multiplicative identity and 0
>>represents the additive identity in ANY algebra. In a Boolean Algebra, the
>>multiplicative identity represents universal truth; and the additive
>>identity represents the negation of this.
>>
>>Like I said, these are preferences... it really doesn't matter.
>>
>>Pete.
>>
>
>Also the actual value of the literal low-value is not the same on
>every system. Therefore its use may not be portable or make sense.
>Much better to use 0 (zero) = off; 1 = on; or y = yes or on; n = no or
>off; all of which are portable and readable.
Name one system where low-values is other than binary zeros.
Donald Tees
DISPLAY-7, with odd parity, on an 8 bit machine.
Donald
Richard Plinston
>>The qualification above indicates that you need to _understand_
>>INITIALISE. As you have demonstrated many times before your
>>understanding is not of Cobol but of some stuff that you invented
>>decades ago without reading the manual.
>
> Forgive my ignorance, m'lord, I'm just a COBOL programmer. You said
> yourself I'm stupid. Don't now chastise me for failing to underatand
> INITIALIZE. You can't have it both ways.
I was not chastising you for not understanding initialise, that is
something that might be cured over time, I was chastising you for arguing
with people who _do_ understand how it works.
>>If you want 'filler' to be set to spaces or zero all that is required
>>is that you give them a name, that is how the INITIALISE knows whether
>>you want the field set to some initial value or not.
> Bull. I want the structure initialized, whether fields are FILLER or not.
Then you don't understand why the word FILLER is used. It is so that the
field cannot be directly referenced and _doesn't_ take part in certain
operations, such as initialise (and also DISPLAY UPON CRT).
Perhaps you should write your own language rather than claiming that Cobol
is 'wrong' when it follows its definition correctly.
Richard Plinston
> INITIALIZE should clear
> everything without needing to add special syntax for FILLERs and initial
> values
You _can_ make it do that, just put names on the fields instead of FILLER.
The use of 'FILLER' is like saying (in '59 thru '85) 'Don't change this
field when doing an INITIALIZE'.
William M. Klein
see that he has decided how COBOL statements should work - even though what
he "wants" is simply NOT the way it was designed or is currently implemented
by any conforming compiler.
Let's see what I can say similar to what he said about what INITIALIZE
should do:
A) Move CORRESPONDING should move FILLER items - when I want them copied to
the receiving field
B) CALL should look thru the entire computer for subprograms - even if they
aren't in the "PATH" (PC), STEPLIB/JOBLIB (IBM mainframe) etc
C) Reference modification should allow you to find a specified string of
characters
D) Logic errors in my programs should get compiler errors
***
Anyone else have ideas of how the COBOL language "should" work - that would
simply break all the existing code that relies on compilers that actually
DO follow the Standard language definitions?
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard Plinston" <rip...@Azonic.co.nz> wrote in message
news:b4u9g6$i9t$2...@aklobs.kc.net.nz...
Richard Plinston
> Name one system where low-values is other than binary zeros.
The Cogar/Singer/ICL 1500 series.
This originated by Cogar in late 60s was a desktop networked system using
coax cabling. Singer acquired Cogar systems in the early 70s and ICL
bought Singer Computer division around 1976.
This used a mechanism called 'excess-3' to make the mini-computer CPU
easier to design and manufacture.
To keep on topic: the founders of MicroFocus Cobol had previously worked
for ICL Dataskill in Reading, England and had written a Cobol system for
the ICL 1500. The MF CIS Cobol had much in common, surprisingly.
Richard Plinston
> Anyone else have ideas of how the COBOL language "should" work - that
> would
> simply break all the existing code that relies on compilers that actually
> DO follow the Standard language definitions?
The compiler should follow indentation instead of stepping in or out of
levels using IFs and ELSEs. Oh no, that was one of Robert Wagner's too.
Rick Smith
[snip]
> Name one system where low-values is other than binary zeros.
LOW-VALUE depends upon the native character set
only by default. LOW-VALUE is defined as the lowest
value in the PROGRAM COLLATING SEQUENCE.
Different programs running together on the same
machine may have different characters for LOW-VALUE.
If you understood the "Rules of COBOL" you might have
known that.
The program below displays '048' as the LOW-VALUE
character from the subprogram. Note the directives
for checking conformance to ANS 85 COBOL.
$set ans85 flag"ans85" flagas"S"
identification division.
program-id. hex-test.
data division.
working-storage section.
77 hex-low-value pic x.
77 value-of-hex-low-value pic 9(3).
procedure division.
begin.
call "hex-low"
using hex-low-value
compute value-of-hex-low-value =
function ord (hex-low-value) - 1
display value-of-hex-low-value
stop run.
end program hex-test.
identification division.
program-id. hex-low.
environment division.
configuration section.
source-computer. PC-DOS.
object-computer. PC-DOS
program collating sequence is hex.
special-names.
alphabet hex is
"0" "1" "2" "3" "4"
"5" "6" "7" "8" "9"
"a" also "A" "b" also "B"
"c" also "C" "d" also "D"
"e" also "E" "f" also "F".
data division.
working-storage section.
linkage section.
77 hex-low-value pic x.
procedure division
using hex-low-value.
begin.
move low-value to hex-low-value
exit program.
end program hex-low.
Rick Smith
[snip]
> COBOL doesn't offer bit-sized variables. The smallest we get is a byte. We
might
> as well use the eight bits to convey human-readable information.
The COBOL 2002 standard does offer BIT variables.
Richard
> >> True value may be 'y'
> COBOL doesn't offer bit-sized variables.
I used bit fields in ICL 1900 Cobol in the 70s and 80s. The 24 bit
word of these machines could be PIC S1(23) SYNC RIGHT or PIC 1 OCCURS
24 (or PIC S9(6) COMP SYNC RIGHT).
Fujitsu also has BOOLEAN and BIT usage, as will '2002 standard.
These can only have values 0 or 1.
> The smallest we get is a byte. We might
> as well use the eight bits
A 'byte' is not necessarily 8 bits, it may be any number of bits as
determined by the machine's architecture. Common sizes are 6, 8, 9.
> to convey human-readable information.
A 'y' may indicate 'yes' to you, but other languages may interpret
this in different ways.
Robert Wagner
>
>Robert Wagner <rob...@wagner.net> wrote in message
>news:3e728355....@news.optonline.net...
>[snip]
>> Name one system where low-values is other than binary zeros.
I wonder why people go to such extraordinary lengths. Because they feel
threatened?
I earlier cited Burroughs Medium Systems, where the default was the lowest
character in the 'program collating sequence', to wit: a space. Thankfully,
Burroughs expired into Unisys. Chuck Stevens confirms that current Unisys
compilers produce x'00' for low-values and x'FF' for high-values, as do all
other compilers excepting the code below.
Robert Wagner
>I do miss so much <G> when I don't see Robert's original messages.
If you're not listening, there is little point in responding. Someone please
quote this so WMK will see it.
>A) Move CORRESPONDING should move FILLER items - when I want them copied to
>the receiving field
Nonsense. There is no way to establish correspondence between FILLERs.
>B) CALL should look thru the entire computer for subprograms - even if they
>aren't in the "PATH" (PC), STEPLIB/JOBLIB (IBM mainframe) etc
Just plain silly. I never said that.
>C) Reference modification should allow you to find a specified string of
>characters
I never wrote about reference modifiers. I don't like them and never use them.
>D) Logic errors in my programs should get compiler errors
For the fourth time, you're putting words in my mouth that I never said.
Robert Wagner
What value does the Cogar/Singer/ICL 1500 series use for low-values?
Does this have any relevance today?
SkippyPB
enlightened us:
>"Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>
>>
>>"Robert Wagner" <rob...@wagner.net> wrote in message
>>news:3e71366b....@news.optonline.net...
>>> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>>>
>>> I use flags extensively. I always use low-value as false. True value may
>>be 'y'
>>> or may be a letter representing the proposition. It is never 1. I don't
>>see
>>> what difference it makes.
>>>
>>The difference is that 1 represents the multiplicative identity and 0
>>represents the additive identity in ANY algebra. In a Boolean Algebra, the
>>multiplicative identity represents universal truth; and the additive
>>identity represents the negation of this.
>
>Any non-zero value represents 'multiplicative identity' and 'universal truth'..
>The value 1 has no special significance.
>
It does in Binary which is the very heart and soul of any computer.
How long you been programming?
>I use meaningful values so I can understand them on diagnostic DISPLAYs.
>
So displaying 0 (zero) and 1 are not meaningful values if you're just
looking for a switch or flag value? Easy to say IF 1 display ON.
>COBOL doesn't offer bit-sized variables. The smallest we get is a byte. We might
>as well use the eight bits to convey human-readable information.
The 2002 Standard offers bit values.
SkippyPB
<wmk...@ix.netcom.com> enlightened us:
>I do miss so much <G> when I don't see Robert's original messages. Now, I
>see that he has decided how COBOL statements should work - even though what
>he "wants" is simply NOT the way it was designed or is currently implemented
>by any conforming compiler.
>
>Let's see what I can say similar to what he said about what INITIALIZE
>should do:
>
>A) Move CORRESPONDING should move FILLER items - when I want them copied to
>the receiving field
>
>B) CALL should look thru the entire computer for subprograms - even if they
>aren't in the "PATH" (PC), STEPLIB/JOBLIB (IBM mainframe) etc
>
>C) Reference modification should allow you to find a specified string of
>characters
>
>D) Logic errors in my programs should get compiler errors
>
> ***
>
>Anyone else have ideas of how the COBOL language "should" work - that would
>simply break all the existing code that relies on compilers that actually
>DO follow the Standard language definitions?
Yes, I'd like it to take my poorly written problem statement because I
refuse to follow a "best practise" and write a self linking,
self-running program that will reside in whatever source management
system I have, generate its own JCL (because I'm a mainframe kind of
guy), and do this while I'm out to lunch and not whine when I get the
credit for a brilliant solution. You think we can get that in the
2004 Standard?
Donald Tees
"SkippyPB" <swie...@neo.NOSPAM.rr.com> wrote in message
>
> Yes, I'd like it to take my poorly written problem statement because I
> refuse to follow a "best practise" and write a self linking,
> self-running program that will reside in whatever source management
> system I have, generate its own JCL (because I'm a mainframe kind of
> guy), and do this while I'm out to lunch and not whine when I get the
> credit for a brilliant solution. You think we can get that in the
> 2004 Standard?
>
a search replacing on paragrapgh names. Next you invoke the compiler,
recompile "self", invoke the os-object "copy", and do a chain back into
yourself iteratively. This entirely eliminates the need for the old
fashioned ALTER statement.
Donald
Richard Plinston
> "William M. Klein" <wmk...@ix.netcom.com> wrote:
>
>>I do miss so much <G> when I don't see Robert's original messages.
>
> If you're not listening, there is little point in responding. Someone
> please quote this so WMK will see it.
He'w not responding to you, he is writing to us. Let me explain: the <G>
stands for <grin>, that indicates that he is enjoying missing out.
>>A) Move CORRESPONDING should move FILLER items - when I want them copied
>>to the receiving field
>
> Nonsense. There is no way to establish correspondence between FILLERs.
Exactly, specifying a field as FILLER means: don't do this one, just as it
is in INITIALIZE.
>>B) CALL should look thru the entire computer for subprograms - even if
>>they aren't in the "PATH" (PC), STEPLIB/JOBLIB (IBM mainframe) etc
>
> Just plain silly. I never said that.
>
>>C) Reference modification should allow you to find a specified string of
>>characters
>
> I never wrote about reference modifiers. I don't like them and never use
> them.
Are they another thing that you tried without reading the manual and didn't
work the way they _should_ ?
>>D) Logic errors in my programs should get compiler errors
>
> For the fourth time, you're putting words in my mouth that I never said.
Of course you never said them, but they are quite similar to things that
you _have_ said.
Richard Plinston
> Richard Plinston <rip...@Azonic.co.nz> wrote:
>
>>Robert Wagner wrote:
>>
>>> Name one system where low-values is other than binary zeros.
>>
>>The Cogar/Singer/ICL 1500 series.
>
> What value does the Cogar/Singer/ICL 1500 series use for low-values?
Excess-3 has zero as x"03", which is why it is called excess-3.
> Does this have any relevance today?
You didn't ask for a _relevant_ system, you just asked for a system. As it
happens it did have a form of Cobol on it, and I do have some around here
still in my pile of obsolete machines, though they haven't been switch on
for 15 years or so.
Richard Plinston
> I wonder why people go to such extraordinary lengths. Because they feel
> threatened?
It is not _us_ that is threatened, it is truth and significance.
Most of the statements you make are in the _form_ of statements of fact,
but are either merely opinions or are wrong. Often they are but one aspect
of a range of options, but stated as if it were the only option.
No one really cares what it is that you believe, but when you make what you
intend to be definitive statements then some others may not have the
experience or perspective to know that your pronouncements are rather
shallow and that other options exist.
I have no particular interest in making systems that do not have low-values
as all bits zero, or even of using them. But I do know that they exist.
Over many years you seem to have developed mechanisms to protect your ego.
Instead of learning, from what others say to and about you, to make less
stupid and uninformed statements, you have learnt to blame others for the
corrections and 'insults' that you get.
In this particular case you are shown to be wrong in form and content and
yet your reaction is not one of learning that there is more to systems than
you thought.
Your reaction is that we contrived these because we feel 'threatened'.
'Threatened' by what ? your 'superior intellect' ? your 'ability to change
the world' ?
No. we are only threatened by ignorence and stupidity.
Rick Smith
> "Rick Smith" <rick...@mfi.net> wrote:
>
> >
> >Robert Wagner <rob...@wagner.net> wrote in message
> >news:3e728355....@news.optonline.net...
> >[snip]
> >> Name one system where low-values is other than binary zeros.
>
> I wonder why people go to such extraordinary lengths. Because they feel
> threatened?
I don't know who 'they' are; but I don't feel theatened. I am
interested in correcting your misunderstanding and
misrepresentation of the rules of COBOL.
Your statement was flawed because there is no direct
relationship between the use of LOW-VALUES and the
storage of a particular value in the memory of the computer.
Furthermore, your suggestion to use LOW-VALUES in a
situation (representation of logic state) where a unique value
is required is flawed because LOW-VALUES, by definition,
is not unique. At the very least, LOW-VALUES will match one
other character, a character that is unique within the character
set. Then, because LOW-VALUES is not unique, it is
guaranteed to introduce logic errors when, for some program
collating sequence, LOW-VALUES, representing one logic
state, and a unique character, representing another logic state,
have the same value. Therefore, your recommendation is not
portable and is not "best practice."
> I earlier cited Burroughs Medium Systems, where the default was the lowest
> character in the 'program collating sequence', to wit: a space.
Thankfully,
> Burroughs expired into Unisys. Chuck Stevens confirms that current Unisys
> compilers produce x'00' for low-values and x'FF' for high-values, as do
all
> other compilers excepting the code below.
[code snipped]
Are you saying that you knew you were wrong but made
your flawed statement anyway?
William M. Klein
indicating it, the sentence that came before my list, i.e.
"Let's see what I can say similar to what he said about what INITIALIZE
should do:"
He never even noticed that I made NO claims that what I listed was what he
said. I simply said that these "should work like" were SIMILAR to his
absurd statement about how INITIALIZE "should work".
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard Plinston" <rip...@Azonic.co.nz> wrote in message
news:b4vsq5$cla$1...@aklobs.kc.net.nz...
Thane Hubbell
> ha...@softwaresimple.com (Thane Hubbell) wrote:
>
> >> No, no. Goofy spacing doesn't make a program more readable.
> >
> >But it sure makes it more editable, and helps automated conversion
> >tools extend the life of the program, especially if the alignment
> >rules are strictly followed. I had the great pleasure of converting a
> >customers system from Realia to Fujitsu COBOL and since he religiously
> >followed rules like this a majority of the conversion was automated
> >via a conversion program. I don't PERSONALLY follow this style, but I
> >don't see anything at all wrong with it.
>
> We don't program to make conversion easier; we program to make maintenance
> easier .
>
>
Conversion is maintenance.
Thane Hubbell
>
> I don't dispute that compilers follow the 85 standard. I'm talking about about
> how INITITIALIZE 'should' work.
>
> >Now with COBOL 2002 you CAN INITIALIZE filler and you can INITIALIZE
> >to the initial value, so I have no clue where your WMK comments came
> >from either. COBOL 85 doesn't - it's not broken.
>
> The 2002 solution is a political compromise. INITIALIZE should clear everything
> without needing to add special syntax for FILLERs and initial values
What? You don't want it backward compatible?
Maybe this example won't get lost this time.
01 SSN.
03 First-3 pic 999.
03 filler pic x value "-".
03 second-2 pic 99.
03 filler pic x value "-".
03 third-part pic 9999.
Initialize SSN
Gives you the DESIRED result of 000-00-0000
This is a FEATURE not a bug. This is something that has been widely
used - because it is a FEATURE - intentional. The news standard keeps
this compatibility so as not to break programs - and allows those who
WANT filler initialized to have it so.
Thane Hubbell
> COBOL doesn't offer bit-sized variables. The smallest we get is a byte. We might
> as well use the eight bits to convey human-readable information.
PIC 1 Usage BIT.
Bit-sized variable from COBOL 2002 - already supported by numerous compilers.
Robert Wagner
>Robert Wagner wrote:
>
>> I wonder why people go to such extraordinary lengths. Because they feel
>> threatened?
>Over many years you seem to have developed mechanisms to protect your ego.
>Instead of learning, from what others say to and about you, to make less
>stupid and uninformed statements, you have learnt to blame others for the
>corrections and 'insults' that you get.
Over the years I've learned to expect hostility from stupid people; friendship
from smart people. And I've learned the most effective way to motivate stupid
people is to threaten them .. not so much from personal practice, but from
watching their managers (and news media) do it.
>'Threatened' by what ? your 'superior intellect' ? your 'ability to change
>the world' ?
>
>No. we are only threatened by ignorence and stupidity.
Given the surplus of ignorance and stupidity in the world, you must feel _very_
threatened.
Robert Wagner
>>>C) Reference modification should allow you to find a specified string of
>>>characters
>>
>> I never wrote about reference modifiers. I don't like them and never use
>> them.
>
>Are they another thing that you tried without reading the manual and didn't
>work the way they _should_ ?
They are for lazy programmers. They obscure meaning. If you want to subdivide a
string, write a structure and give the substrings meaningful names.
Robert Wagner
>On Sat, 15 Mar 2003 01:56:17 GMT, rob...@wagner.net (Robert Wagner)
>enlightened us:
>
>>"Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>>
>>>
>>>"Robert Wagner" <rob...@wagner.net> wrote in message
>>>news:3e71366b....@news.optonline.net...
>>>> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>>>>
>>>> I use flags extensively. I always use low-value as false. True value may
>>>be 'y'
>>>> or may be a letter representing the proposition. It is never 1. I don't
>>>see
>>>> what difference it makes.
>>>>
>>>The difference is that 1 represents the multiplicative identity and 0
>>>represents the additive identity in ANY algebra. In a Boolean Algebra, the
>>>multiplicative identity represents universal truth; and the additive
>>>identity represents the negation of this.
>>
>>Any non-zero value represents 'multiplicative identity' and 'universal
truth'..
>>The value 1 has no special significance.
>>I use meaningful values so I can understand them on diagnostic DISPLAYs.
>>
>
>So displaying 0 (zero) and 1 are not meaningful values if you're just
>looking for a switch or flag value? Easy to say IF 1 display ON.
I often display multiple indicators on a line. If it reads '1 0 1 1 0', I must
look at code to determine which indicators they are. If it reads 'a d u ', I
know at a glance it's an alphabetic word found in the dictionary and written in
upper case.
Robert Wagner
>Yes, I'd like it to take my poorly written problem statement because I
>refuse to follow a "best practise" and write a self linking,
>self-running program that will reside in whatever source management
>system I have, generate its own JCL (because I'm a mainframe kind of
>guy), and do this while I'm out to lunch and not whine when I get the
>credit for a brilliant solution. You think we can get that in the
>2004 Standard?
Synergy promises all that and more. What's your boss's email? :)
Robert Wagner
Editing source is too crude. The modern way to write self-modifying code is
called 'introspection', which enables a program to look at itself (and others),
then modify its behavior 'in situ'. For compilers that doesn't support
introspection (or reflection), there's always operator overloading. Be sure to
destroy the method after you use it so someone else doesn't inadvertently
stumble into it.
Richard Plinston
> They are for lazy programmers. They obscure meaning. If you want to
> subdivide a string, write a structure and give the substrings meaningful
> names.
No. They are useful for the purpose they were designed to fulfill. I do a
fair amount of templating where a text file is the template of an HTML,
XML, print form, postscript or EDIFAC output with tags marking the
positions where substitutions are made.
These may start at any point in the line and be any length. What would you
suggest as a mechanism for using variable names: a million redefines and
two levels of GO TO DEPENDING ON to select the correct name for start point
and length ?
Robert Wagner
I'll concede backward compatibility is a plausible reason to keep the old rules.
Rather than burdening us with extra syntax, a better solution would be a
compiler option to make it work 'the right way' or 'the old way'. Initial
values, as in the example, should always be set. They were there INITIALly, when
the program was loaded.
I see a dichotomy in the word INITIALIZE. It seems reasonable that INITIALIZE
set everything to its initial state. On most operating systems, that's binary
zeros unless you say VALUE. When a program starts, pic x fields don't have
spaces; they have binary zeros. First-3 doesn't have zeros; it has low-values.
The word "initialize" looks like a misnomer. If I was on the committee, I would
have argued for a new verb: "clear".
Robert
Robert Wagner
>
>Furthermore, your suggestion to use LOW-VALUES in a
>situation (representation of logic state) where a unique value
>is required is flawed because LOW-VALUES, by definition,
>is not unique. At the very least, LOW-VALUES will match one
>other character, a character that is unique within the character
>set. Then, because LOW-VALUES is not unique, it is
>guaranteed to introduce logic errors when, for some program
>collating sequence, LOW-VALUES, representing one logic
>state, and a unique character, representing another logic state,
>have the same value. Therefore, your recommendation is not
>portable and is not "best practice."
Kindly point out the logical flaw in this code.
05 filler pic x value low-value.
88 end-of-file value 'e' false low-value.
Do you seriously think some compiler will use 'e' as low-value?
JerryMouse
Reference modification is like an indoor toilet: once you use one, you'll
wonder how you ever lived without it. Trust me on this.
JerryMouse
"Robert Wagner" <rob...@wagner.net>
>
> The 2002 solution is a political compromise. INITIALIZE should clear
everything
> without needing to add special syntax for FILLERs and initial values
>
Uh, what does 'clear' mean?
01 XXX COMP-3.
02 XXX-A PIC 9(3).
02 FILLER PIC X(650).
02 XXX-B PIC 9(7).
So what should INITIALIZE put in the above FILLER to "clear" it?
How about:
01 MASTER.
02 MASTER-MONTHS.
05 MASTER-MONTH OCCURS 12 PIC 9(5).
02 MASTER-DAYS.
05 MASTER-DAY OCCURS 365 PIC 9(5).
01 MASTER-MONTH-ONLY REDEFINES MASTER.
02 MASTER-MONTH-CLEAR OCCURS 12 PIC 9(5).
02 FILLER PIC X(4380).
01 MASTER-DAYS-ONLY REDEFINES MASTER.
02 FILLER OCCURS 12 PIC 9(5).
02 MASTER-DAY-CLEAR OCCURS 365 PIC 9(5).
Compare the actions of:
INITIALIZE MASTER
INITIALIZE MASTER-MONTH-ONLY
and
INITIALIZE MASTER-DAYS-ONLY
Richard Plinston
> Rather than burdening us with extra syntax, a better solution would be a
> compiler option to make it work 'the right way' or 'the old way'.
It is only your opinion that 'the right way' is not the same as 'the old
way'.
But using compiler options doesn't avoid any 'burden', it only hides it in
the compiler configuration file.
> Initial
> values, as in the example, should always be set. They were there
> INITIALly, when the program was loaded.
> I see a dichotomy in the word INITIALIZE.
You seem to see a lot of things which don't exist.
Working-Storage may be set with initial values on loading with a VALUE
clause or some initial values may be set with the INITIALIZE statement.
They should be considered as alternatives for W-S. Local storage and file
section only have initialize.
> It seems reasonable that
> INITIALIZE set everything to its initial state. On most operating systems,
> that's binary zeros unless you say VALUE.
Yet another of your fundemental lack of understanding of Cobol.
If there are no VALUE clauses, or it is Local-Storage or file section, then
then there is _NO_ defined default setting. It is entirely at the whim of
the vendor what these are set to and no particular value can be relied on.
With MF the compiler options allow the undefined bytes to any specific
character. Relying on this is seriously flawed.
> When a program starts, pic x
> fields don't have spaces; they have binary zeros. First-3 doesn't have
> zeros; it has low-values.
No they don't, they have no specific value. They may be null or spaces or
whatever was previously in those bytes or some value chosen by the vendor.
This is especially true of local storage and file section.
Your arguments are remarkably shallow.
> The word "initialize" looks like a misnomer. If I was on the committee, I
> would have argued for a new verb: "clear".
If you were on the committee there never would have been any release of the
standards. You would still be arguing instead of understanding _why_
particular choices were made.
Robert Wagner
Based on incomplete knowledge of the problem (read: I might be wrong), I'd
suggest parsing the input record into words rather than operating on them 'in
situ'. By doing so you've elevated the system from trying to do everything at
one layer to a two-layer approach -- a parser and a syntax analyzer.
Robert Wagner
>Reference modification is like an indoor toilet: once you use one, you'll
>wonder how you ever lived without it. Trust me on this.
The real reason I shun reference modification is because it reminds me of Basic.
What a horrid language.
Peter E.C. Dashwood
> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>
> >
> > I don't
> >see
> >> what difference it makes.
> >>
> >The difference is that 1 represents the multiplicative identity and 0
> >represents the additive identity in ANY algebra. In a Boolean Algebra,
the
> >multiplicative identity represents universal truth; and the additive
> >identity represents the negation of this.
>
> Any non-zero value represents 'multiplicative identity' and 'universal
truth'..
> The value 1 has no special significance.
>
1) could there be? As the particular set of Boolean Algebras we deal with
in computing are all based on this particular two valued system, I rest my
case.
In Algebras that have more than two values your statement is axiomatically
false. ("any non-zero value" CAN NOT be used as multiplicative identity.)
And no, I am not threatened by your intellect <G>, neither do I care how you
represent universal truth.
My post is out of respect for George Boole...
Pete.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Peter E.C. Dashwood
Definitely. When it's released in 2050...<G>
Rick Smith
It is the *program*, not the compiler, that determines the
*program* collating sequence. If the *programmer* sets the
alphabet for the *program* collating sequence, such that
'e' is the first character in the collating sequence, then every
conforming compiler will use 'e' as low-value. Whenever 'e'
is the first character in the *program* collating sequence,
the code, above, will treat 'end-of-file' as always true.
Note that flagging is OFF due to use of the non-standard
'SET condition TO FALSE'.
*set ans85 flag"ans85" flagas"S"
identification division.
program-id. lv-test.
environment division.
configuration section.
source-computer. PC-DOS.
object-computer. PC-DOS
program collating sequence is e-start.
special-names.
alphabet e-start is
"efgop930".
data division.
working-storage section.
77 filler pic x value low-value.
88 end-of-file value "e" false low-value.
procedure division.
begin.
perform display-state
set end-of-file to true
perform display-state
set end-of-file to false
perform display-state
stop run.
display-state.
if end-of-file
display "True"
else
display "False"
end-if.
end program lv-test.
The program displays "True" three times.
The general rule you suggest is to use LOW-VALUE as
'False' and as the default value for the field and some other
character for the 'True' value. It is not just that 'e' could result
in failure; but that any character value could result in failure
for a particular collating sequence.
It is not the use of 'e' in particular, that is the problem. It is
the reliance upon LOW-VALUE as never being equivalent
to any other character that is the problem.
Richard Plinston
> Based on incomplete knowledge of the problem (read: I might be wrong), I'd
Yes, you might be.
> suggest parsing the input record into words rather than operating on them
> 'in situ'. By doing so you've elevated the system from trying to do
> everything at one layer to a two-layer approach -- a parser and a syntax
> analyzer.
Yes, you are.
Given that you have no idea how the code is developed or how many 'layers'
that I have in the actual code, then it presumptuous of you to assert that
it could be 'elevated' by writing it in some other way.
I don't 'operate in situ', the lines may require repitition and/or packing.
The template file _is_ parsed, but not into 'words', that woould be quite
inappropriate, but creates a table of field positions, including start
point and lengths, which the output 'layer' uses as substitution points.
Also when processing print format templates that will be output as text it
is important to maintain the columnar relationships. That is the positions
in the line are significant, parsing to words will lose that. HTML, XML,
and EDIFACT gats packed tightly so 'in situ' doesn't work. Not that the
template processor knows what it is working on, there are control lines in
the template that can charge how it operates.
In most case the tags aren't 'words', the templates aren't like, for
example, source code.
Reference notation makes it work well and fast. The alternate that you
suggested of millions of redefines to cover all possible fields is just a
non-starter. UNSTRING/STRING requires control over positions and lengths
that is just too complicated. Using PERFORM loops to move character by
character would work but would be really tedious.
As a solution reference notation is a good fit to the the problem. So far
you have suggested two really bad fits.
Robert Wagner
>
>"Robert Wagner" <rob...@wagner.net>
>>
>> The 2002 solution is a political compromise. INITIALIZE should clear
>everything
>> without needing to add special syntax for FILLERs and initial values
>>
>
>Uh, what does 'clear' mean?
>
>01 XXX COMP-3.
> 02 XXX-A PIC 9(3).
> 02 FILLER PIC X(650).
> 02 XXX-B PIC 9(7).
>
>So what should INITIALIZE put in the above FILLER to "clear" it?
It puts spaces.
>How about:
>01 MASTER.
> 02 MASTER-MONTHS.
> 05 MASTER-MONTH OCCURS 12 PIC 9(5).
> 02 MASTER-DAYS.
> 05 MASTER-DAY OCCURS 365 PIC 9(5).
>
>01 MASTER-MONTH-ONLY REDEFINES MASTER.
> 02 MASTER-MONTH-CLEAR OCCURS 12 PIC 9(5).
> 02 FILLER PIC X(4380).
>
>01 MASTER-DAYS-ONLY REDEFINES MASTER.
> 02 FILLER OCCURS 12 PIC 9(5).
> 02 MASTER-DAY-CLEAR OCCURS 365 PIC 9(5).
>
>
>Compare the actions of:
>INITIALIZE MASTER
>INITIALIZE MASTER-MONTH-ONLY
>and
>INITIALIZE MASTER-DAYS-ONLY
It puts zeros into cases 1 and 3, spaces into the filler in case 2.
Robert Wagner
>Robert Wagner wrote:
>
>> Rather than burdening us with extra syntax, a better solution would be a
>> compiler option to make it work 'the right way' or 'the old way'.
>
>It is only your opinion that 'the right way' is not the same as 'the old
>way'.
All rules in the standard are someone's opinion. There is no 'universal truth'.
>> Initial
>> values, as in the example, should always be set. They were there
>> INITIALly, when the program was loaded.
>
>> I see a dichotomy in the word INITIALIZE.
>
>You seem to see a lot of things which don't exist.
Life would be simpler if I had your certitude. I'm burdened with thinking about
the meanings of words.
>> It seems reasonable that
>> INITIALIZE set everything to its initial state. On most operating systems,
>> that's binary zeros unless you say VALUE.
>
>Yet another of your fundemental lack of understanding of Cobol.
You'd think I'd know COBOL after 40 years and millions of lines of code. But
no, I need to be told I know nothing. Thank you for the valuable revalation.
>If there are no VALUE clauses, or it is Local-Storage or file section, then
>then there is _NO_ defined default setting. It is entirely at the whim of
>the vendor what these are set to and no particular value can be relied on.
You use the word 'vendor' as governmental agencies do, as a term of
disparagement. The vendors in question are Microsoft and IBM, two of the
largest companies in the world. They are not starving waifs scratching at the
door.
>> When a program starts, pic x
>> fields don't have spaces; they have binary zeros. First-3 doesn't have
>> zeros; it has low-values.
>
>No they don't, they have no specific value. They may be null or spaces or
>whatever was previously in those bytes or some value chosen by the vendor.
>
>This is especially true of local storage and file section.
I start with the same assumption. But I know they contain binary zeros. I don't
want to depend on it least Mr. Peabody sends me through the time machine to the
Bad Old Days, when one couldn't depend on initial values.
>> The word "initialize" looks like a misnomer. If I was on the committee, I
>> would have argued for a new verb: "clear".
>
>If you were on the committee there never would have been any release of the
>standards. You would still be arguing instead of understanding _why_
>particular choices were made.
Your mama wears combat boots.
Robert Wagner
In all my years of programming, I've never seen anyone use 'collating sequence
is'. You just pulled that up for the sake of debate.
I'm concerned with Practice in the real world. Diluting Practice with such
hypotheticals does a disservice to struggling programmers.
Robert Wagner
>
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e7274a3....@news.optonline.net...
>> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>>
>> >
>> > I don't
>> >see
>> >> what difference it makes.
>> >>
>> >The difference is that 1 represents the multiplicative identity and 0
>> >represents the additive identity in ANY algebra. In a Boolean Algebra,
>the
>> >multiplicative identity represents universal truth; and the additive
>> >identity represents the negation of this.
>>
>> Any non-zero value represents 'multiplicative identity' and 'universal
>truth'..
>> The value 1 has no special significance.
>>
>In a two valued logic system, using 0 and 1, what non-zero value (other than
>1) could there be? As the particular set of Boolean Algebras we deal with
>in computing are all based on this particular two valued system, I rest my
>case.
Today's COBOL obliges us to use a 256-valued system, not a two valued system.
>In Algebras that have more than two values your statement is axiomatically
>false. ("any non-zero value" CAN NOT be used as multiplicative identity.)
Why is that? Educate me.
Peter E.C. Dashwood
this response is completely unworthy of you.
"In all my years ...I've never seen..." is no form of real argument.
I wouldn't mind betting I've had more years than you (36 in COBOL;38 in
programming) and I've never seen Collating Sequence used either.
But the point is that it COULD be.
People are not presenting these arguments just to make you wrong.
It's because they are valid arguments.
I shouldn't think anyone really cares whether you use low values to
represent FALSE or not (I certainly don't), but if you're going to have
debate, then expect people to present cases.
You are smart enough to recognise a good case when you see it, and to adopt
the approach that it is an obscure oddity, being presented to make you
wrong, is simply selling yourself short.
You can do much better than this. Would it be so painful to accept that this
is a valid point and acknowledge it?
Or is your whole time here to be about making yourself right?
Think on't...
Pete.
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3e742223....@news.optonline.net...
Peter E.C. Dashwood
> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
>
> >
> >"Robert Wagner" <rob...@wagner.net> wrote in message
> >news:3e7274a3....@news.optonline.net...
> >> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
> >>
> >> >
> >> > I don't
> >> >see
> >> >> what difference it makes.
> >> >>
> >> >The difference is that 1 represents the multiplicative identity and 0
> >> >represents the additive identity in ANY algebra. In a Boolean Algebra,
> >the
> >> >multiplicative identity represents universal truth; and the additive
> >> >identity represents the negation of this.
> >>
> >> Any non-zero value represents 'multiplicative identity' and 'universal
> >truth'..
> >> The value 1 has no special significance.
> >>
> >In a two valued logic system, using 0 and 1, what non-zero value (other
than
> >1) could there be? As the particular set of Boolean Algebras we deal
with
> >in computing are all based on this particular two valued system, I rest
my
> >case.
>
> Today's COBOL obliges us to use a 256-valued system, not a two valued
system.
>
Robert, I can't believe you wrote that. It is a two valued LOGIC system.
What it manipulates is a CHARACTER SET, that may indeed be 256 characters.
(Or not...what about Cyrillic, and Asian Character sets that use Double Byte
mode?)
We cannot have 256 outcomes from an IF; it is either TRUE or FALSE. Two
states.
But then you knew that... You were just scratching to refute a case that
can't be refuted. ANYTHING except agree that the case was made <G>...
> >In Algebras that have more than two values your statement is
axiomatically
> >false. ("any non-zero value" CAN NOT be used as multiplicative identity.)
>
> Why is that? Educate me.
>
OK, but don't encourage me to waste my time...If I do this, I'll expect you
to acknowledge you have received and understood <G>.
In any Algebra, there are certain values that can be applied using the
operations defined in the Algebra, without actually changing whatever they
were used to operate on. (In fact, the system cannnot BE an "Algebra" unless
these values exist...).
Because they don't cause change, they are referred to as "identities" (the
result after using them is identical to the result BEFORE using them...)
For example, if we define the operation of "Multiplication", there exists a
value (1) such that any number "multiplied" by this value remains unchanged.
This is referred to as the "Multiplicative identity".
If we define the operation of "Addition", there exists a value (0) such that
any number "added" to this value remains unchanged. This is referred to as
the "Additive identity".
And so on, for other operations in other Algebras.
A good question might be "Why are these identities important? If they don't
change anything, why do we need them?"
The answer to this is way beyond the scope of what I'm writing here, but as
a general analogy, compare the Roman system of counting and arithmetic
(which had no zero) with the Arabic system that gave us Algebra. Systems
without identities are stunted in what they can do.
Given the definition of Multiplicative Identity explained above, you should
now see that ANY value simply won't cut it as a Multiplicative Identity (it
has to be 1).
In a Boolean Algebra, the Operation of "AND" (which corresponds loosely to
the operation of "Multiplication" in other systems) uses the Identity 1.
Anything ANDed with 1 remains unchanged. 1 is therefore referred to as the
Multiplicative Identity for any Boolean Algebra, and by extension,
represents a value of TRUE. (If you AND something with TRUE it remains
TRUE). Similarly, if you OR something with Zero, it remains unchanged. So
zero represents the Additive Identity in a Boolean Algebra (as it does in
most other Algebras).
That, in a nutshell, is why I use 1 and zero to represent TRUE and FALSE in
my programs (not just COBOL, but wherever I'm allowed to...)
However, I am not suggesting this is RIGHT or WRONG; only that it is MY
preference.
Donald Tees
> Richard Plinston <rip...@Azonic.co.nz> wrote:
>
> >Robert Wagner wrote:
> >
> >> Rather than burdening us with extra syntax, a better solution would be
a
> >> compiler option to make it work 'the right way' or 'the old way'.
> >
> >It is only your opinion that 'the right way' is not the same as 'the old
> >way'.
>
> All rules in the standard are someone's opinion. There is no 'universal
truth'.
>
No. All words in the standard define the language.
Deviations from the standard are opinion. If you want to understand basic
language theory at all, you have to start realizing that it takes two people
agreeing on a common meaning to define a "language". All people in the
world deciding that a word has a private meaning is the antithesis of
language.
I'd suggest that you read about the tower of babel in the bible, and start
upgrading your theories from there. We have come a long way in the last
3000 years or so.
Donald
Michael Mattias
news:3e742...@text-west.newsgroups.com...
> Robert,
>
> this response is completely unworthy of you.
>
> "In all my years ...I've never seen..." is no form of real argument.
>
> I wouldn't mind betting I've had more years than you (36 in COBOL;38 in
> programming) and I've never seen Collating Sequence used either.
>
> But the point is that it COULD be.
Pete, I shocked. Of course it could be, but it's immaterial.. because once
the program has been compiled, the value of LOW-VALUE is locked into the
program... you cannot change the COLLATING SEQUENCE of a compiled program.
(This may not be true of a p-code compiler; but let's forget they exist for
a moment).
OTOH, if the programmer used LOW-VALUE here then tested ZEROES there, then
the program is not source-code compatible; not that ANYONE would EVER
recompile a program on a new machine/with a new compiler/new version of a
compiler/adding a COLLATING SEQUENCE clause to an FD without thoroughly
testing every piece of logic in the code.
Would they?
MCM
Frederico Fonseca
wrote:
>"Rick Smith" <rick...@mfi.net> wrote:
>
>>
>>Robert Wagner <rob...@wagner.net> wrote in message
>>news:3e73a68f....@news.optonline.net...
>>> "Rick Smith" <rick...@mfi.net> wrote:
>>>
>>> >
>>
>>It is the *program*, not the compiler, that determines the
>>*program* collating sequence. If the *programmer* sets the
>>alphabet for the *program* collating sequence, such that
>>'e' is the first character in the collating sequence, then every
>>conforming compiler will use 'e' as low-value. Whenever 'e'
>>
>> identification division.
>> program-id. lv-test.
>> program collating sequence is e-start.
>> special-names.
>> alphabet e-start is
>> "efgop930".
>> data division.
>> working-storage section.
>> 77 filler pic x value low-value.
>> 88 end-of-file value "e" false low-value.
anip
>>It is not the use of 'e' in particular, that is the problem. It is
>>the reliance upon LOW-VALUE as never being equivalent
>>to any other character that is the problem.
>
>In all my years of programming, I've never seen anyone use 'collating sequence
>is'. You just pulled that up for the sake of debate.
Then YOU have not seen enough of others shops programs.
I have been using this construce for at least 12 years now in
production programs, and in several of the shops I have worked with.
And in all the COBOL courses I have given I have always mentioned that
the LOW-VALUES figurative constant is dependent in the usage of clause
"alphabet is" so that the students were aware of the dangers of using
"low-values" or "high-values".
>
>I'm concerned with Practice in the real world. Diluting Practice with such
>hypotheticals does a disservice to struggling programmers.
Assuming that real world is your company, then yes you are correct.
Fortunately there are a few thousands others companies that have never
heard of you (and never will).
FF
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
Thane Hubbell
> Rather than burdening us with extra syntax, a better solution would be a
> compiler option to make it work 'the right way' or 'the old way'. Initial
> values, as in the example, should always be set. They were there INITIALly, when
> the program was loaded.
The problem with this solution is that it means that you have to have
the same behavior for the entire program. That's not desireable -
sometimes I might want the filler initialized, other times I might
not.
>
> I see a dichotomy in the word INITIALIZE. It seems reasonable that INITIALIZE
> set everything to its initial state. On most operating systems, that's binary
> zeros unless you say VALUE. When a program starts, pic x fields don't have
> spaces; they have binary zeros. First-3 doesn't have zeros; it has low-values.
>
> The word "initialize" looks like a misnomer. If I was on the committee, I would
> have argued for a new verb: "clear".
>
Intersting, and I can see why you might think that.... however, don't
consider the "INITIAL" value to be that value that the operating
environment assigns at startup, consider it from the point of view of
the programmer --- it's the Initial value *I* want - and that could be
any number of things considering the need at the time.
SkippyPB
You stated your argument as an absolute truth. Mr. Smith has just
illustrated that truth was false. Whether you've never seen it or not
is irrelevant as the possibility exists and must be accounted for in
any intelligent encompassing "best practice". Any practice that
ignores a possibility that is known through the understanding of Cobol
and its standards isn't worth snot.
>I'm concerned with Practice in the real world. Diluting Practice with such
>hypotheticals does a disservice to struggling programmers.
Any good programmer when coding a solution to a problem takes all
hypotheticals into consideration so that a thorough solution can be
coded. Failure to do so is bad programming even if you don't use
periods.
Regards,
////
(o o)
-oOO--(_)--OOo-
Micro$oft Haiku Error Message #109
Program aborting:
Close all that you have worked on.
You ask far too much.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
SkippyPB
enlightened us:
>"JerryMouse" <nos...@bisusa.com> wrote:
No RPG is a horrid language. Basic is a very nice language which I've
done a lot with over the years. But then beauty is in the eye of
beholder.
Robert Wagner
>I wouldn't mind betting I've had more years than you (36 in COBOL;38 in
>programming) and I've never seen Collating Sequence used either.
You'd lose the bet.
>this response is completely unworthy of you.
>
>"In all my years ...I've never seen..." is no form of real argument.
>
>But the point is that it COULD be.
>
>People are not presenting these arguments just to make you wrong.
I think they are. They are constructing improbable cases to rebut my points
about realistic use of COBOL. For instance, an alphabet beginning with 'e'.
>It's because they are valid arguments.
>
>I shouldn't think anyone really cares whether you use low values to
>represent FALSE or not (I certainly don't), but if you're going to have
>debate, then expect people to present cases.
This isn't an ivory tower debate forum. It's a place where people come for
practical advice. They will leave if they see crotchety old men quibbling over
minutiae.
>You are smart enough to recognise a good case when you see it, and to adopt
>the approach that it is an obscure oddity, being presented to make you
>wrong, is simply selling yourself short.
I get it -- you're the 'good cop' playing against Richard's 'bad cop'.
>You can do much better than this. Would it be so painful to accept that this
>is a valid point and acknowledge it?
Fine. It's a valid hypothetical point.
>Or is your whole time here to be about making yourself right?
I've admitted to being wrong several times here.
Robert Wagner
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e7413e2....@news.optonline.net...
>> Richard Plinston <rip...@Azonic.co.nz> wrote:
>>
>> >Robert Wagner wrote:
>> >
>> >> Rather than burdening us with extra syntax, a better solution would be
>a
>> >> compiler option to make it work 'the right way' or 'the old way'.
>> >
>> >It is only your opinion that 'the right way' is not the same as 'the old
>> >way'.
>>
>> All rules in the standard are someone's opinion. There is no 'universal
>truth'.
>>
>
>No. All words in the standard define the language.
>
>Deviations from the standard are opinion. If you want to understand basic
>language theory at all, you have to start realizing that it takes two people
>agreeing on a common meaning to define a "language". All people in the
>world deciding that a word has a private meaning is the antithesis of
>language.
You make an excellent point. But languages evolve as people agree on 'common
usage' meaning of new words. For instance, we all agree that comp-3 means packed
decimal, even though it doesn't say so in the '85 standard. Commonly used words
are usually adopted in the next standard, just as commonly used English words
find their way into the dictionary.
Because COBOL uses English words, it has some obligation to define meanings
close to the English meanings. In my opinion, INITIALIZE isn't close enough. It
should set _every_ field in the referenced structure to an initial value.
Robert
"Hit Enter to exit"
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote in message
>
>> Rather than burdening us with extra syntax, a better solution would be a
>> compiler option to make it work 'the right way' or 'the old way'. Initial
>> values, as in the example, should always be set. They were there INITIALly,
when
>> the program was loaded.
>
>The problem with this solution is that it means that you have to have
>the same behavior for the entire program. That's not desireable -
>sometimes I might want the filler initialized, other times I might
>not.
When a language feature is unpredictable, I avoid using it, preferring to do it
myself. I used to think 'move low-values ..' was predictable. Now I'll have to
write 'move all x'00' ..'
>> I see a dichotomy in the word INITIALIZE. It seems reasonable that INITIALIZE
>> set everything to its initial state. On most operating systems, that's binary
>> zeros unless you say VALUE. When a program starts, pic x fields don't have
>> spaces; they have binary zeros. First-3 doesn't have zeros; it has
low-values.
>>
>> The word "initialize" looks like a misnomer. If I was on the committee, I
would
>> have argued for a new verb: "clear".
>>
>
>Intersting, and I can see why you might think that.... however, don't
>consider the "INITIAL" value to be that value that the operating
>environment assigns at startup, consider it from the point of view of
>the programmer --- it's the Initial value *I* want - and that could be
>any number of things considering the need at the time.
I can live with that. I think of it in OO terms, as the value set by a
constructor. Whatever NEW does, INITIALIZE should do the same.
Robert Wagner
>I have been using this construct for at least 12 years now in
>production programs, and in several of the shops I have worked with.
Two translations for every comparison will make your program run slowly. When I
want to do that, I do a single translation into the machine's collating
sequence.
Robert Wagner
>"Robert Wagner" <rob...@wagner.net> wrote in message
>> Today's COBOL obliges us to use a 256-valued system, not a two valued
>system.
>>
>
>Robert, I can't believe you wrote that. It is a two valued LOGIC system.
>
>What it manipulates is a CHARACTER SET, that may indeed be 256 characters.
>(Or not...what about Cyrillic, and Asian Character sets that use Double Byte
>mode?)
>
>We cannot have 256 outcomes from an IF; it is either TRUE or FALSE. Two
>states.
It is true that IF may have only two outcomes, but the indicator may have 255
different states of 'truth'. For example, in the code snippet I posted, a word
may be numeric-word, percent-word, punctuation-word, alphabetic-word, etc.
I did learn something -- the concept of _preserving_ identity rather than
changing it.
Robert Wagner
I disagree. My Best Practices says:
"Over its history, the COBOL language has accumulated many features that are Bad
Practices and/or obsolete. Encyclopedic reference books describe them all in
alphabetical order without giving the reader a clue as to which are good, bad
and superfluous. Rather than compiling a list of negatives.. don't do this and
that .. I simply omitted the bad features. The syntax in the first three
chapters is all you need to write the most complex programs under COBOL '85."
The three chapters do not mention 'collating sequence is', nor GO TO, nor ALTER.
Robert
Rick Smith
> In all my years of programming, I've never seen anyone use 'collating
sequence
> is'. You just pulled that up for the sake of debate.
It is because I have used it that I understood your assumption,
that LOW-VALUES is always X"00", was wrong; but you never
saw me use it or saw my post to the group in October 2000.
<
http://groups.google.com/groups?q=collating+sequence+group:comp.lang.cobol&h
l=en&lr=&ie=UTF-8&selm=8stgh6%246de%241%40news.hitter.net&rnum=7 >
> I'm concerned with Practice in the real world. Diluting Practice with such
> hypotheticals does a disservice to struggling programmers.
In the referenced post, I demonstrated the practical use of
PROGRAM COLLATING SEQUENCE and a programmer-
defined ALPHABET to handle hexi-decimal conversions
in a portable manner.
Richard Plinston
> For instance, we all agree that comp-3 means packed decimal,
No we certainly do not. We can all agree that PACKED DECIMAL means Binary
Coded Decinal, but the _reason_ that PACKED was introduced into the the
standard was for the very reason that COMP-3 meant different things in
different vendors compilers, and especially BCD may have been some other
COMP-~, or not available at all.
> In my opinion, INITIALIZE isn't
> close enough. It should set _every_ field in the referenced structure to
> an initial value.
Yes, we do know what your opinion is. However, it seems that no one agrees
with you at all.
> languages evolve as people agree on 'common usage'
Either you are going to agree with the standard and everyone else, or you
are going to 'evolve' your own private language that is not Cobol.
Donald Tees
You have stated your opinion ... to late to do any good, as the time to have
done it was when the new standard was being developed. You have not had a
single person agree with your opinion, and had about a dozen disagree, with
lots of good reasons stated.
Your absolute refusal to acknowlege that, combined with your last hundred
posts or so, leads me to believe that you either do not understand the basic
nature of language, or that you are not really interested in communicating
at all. That is, you are not interested in what the words spoken, written,
or compiled actually DO mean, by common assent. Instead, you wish to spew
out strings of letters in some private language, that you and you only
understand, then claim the rest of us are rather dumb because we obviously
do not see your point.
When you wish to adopt a common language, for the sake of communication, if
nothing else, then maybe you will be qualified to write a book. Until then,
the rest of us are going to assume you are making a noise because you like
to hear the sound of your own voice.
Donald
Rick Smith
> >People are not presenting these arguments just to make you wrong.
>
> I think they are. They are constructing improbable cases to rebut my
points
> about realistic use of COBOL. For instance, an alphabet beginning with
'e'.
A portable subprogram translating character commands
to numeric values might need to translate 'e' also 'E' to the
value 1. In this case, an alphabet beginning with 'e' would
mean that the expression 'FUNCTION ORD (command-char)'
would return 1 whenever command-char is 'e' or 'E'.
LOW-VALUE would be 'e'.
Such a program may not have a state variable unless
a command sequence needs special translation.
01 filler value low-value.
88 end-command-received value 'e' false low-value.
In which case, the program has a logic error.
And yes, I made this up just to demonstrate that there are
practical, realistic cases, even if unlikely, that will result in
failure if your methods are used. I can do this easily because
I understand the flaw.
William M. Klein
types of programs:
1) Programs intended to run in both ASCII and EBCDIC environments - where
the use of the COLLATING SEQUENCE makes the program "portable" across
environments.
2) In environments intended for "international use" - where additional
"alphabetic" characters (accented, umlauted vowels - diagraphs, etc) exist
and need to be "put" in their correct collating order.
For those of us who HAVE worked in either of these environments, this phrase
is "relatively" common. For those used to coding in a "single" environment,
I agree that it is probably unusual.
--
Bill Klein
wmklein <at> ix.netcom.com
"Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote in message
news:3e742...@text-west.newsgroups.com...
Thane Hubbell
> >
> >The problem with this solution is that it means that you have to have
> >the same behavior for the entire program. That's not desireable -
> >sometimes I might want the filler initialized, other times I might
> >not.
>
> When a language feature is unpredictable, I avoid using it, preferring to do it
> myself. I used to think 'move low-values ..' was predictable. Now I'll have to
> write 'move all x'00' ..'
>
Huh? Which part of INITIALIZE is unpredictable?
> >
> >Intersting, and I can see why you might think that.... however, don't
> >consider the "INITIAL" value to be that value that the operating
> >environment assigns at startup, consider it from the point of view of
> >the programmer --- it's the Initial value *I* want - and that could be
> >any number of things considering the need at the time.
>
> I can live with that. I think of it in OO terms, as the value set by a
> constructor. Whatever NEW does, INITIALIZE should do the same.
That's why I sometimes override "NEW" with my own method - to do
something different. I suppose that makes "NEW" unpredictable as well
and maybe you shouldn't use it.
William M. Klein
Don't you understand? According to Mr. Wagner, that which doesn't work
the way that he thinks it SHOULD work is "unpredictable" - that which
differs from what he thinks is "best" is WRONG - that which didn't work the
way he wanted it to at least once in the past 40 years must be dangerous.
If nothing else, he really is quite consistent <G>
--
Bill Klein
wmklein <at> ix.netcom.com
"Thane Hubbell" <tha...@softwaresimple.com> wrote in message
news:bfdfc3e8.0303...@posting.google.com...
Peter E.C. Dashwood
I'm not taking issue with your post...
All I will say is that when working on Mainframes (IBM and NCR as it
happens), when we needed to translate a character set from one system to
another we used the TRANSFORM verb, NOT the COLLATING SEQUENCE.
I know it is non-standard COBOL, but it certainly did the job. I have
personally never used COLLATING SEQUENCE or seen it used, in 36 years,
DESPITE having done conversions across different platforms and had programs
that must deal with the relative formats.
Having said that, I accept totally that there are legitimate uses for it as
Rick in particular has demonstrated.
Pete.
"William M. Klein" <wmk...@ix.netcom.com> wrote in message
news:b52rqv$u8j$1...@slb2.atl.mindspring.net...
Peter E.C. Dashwood
"Donald Tees" <Donal...@sympatico.ca> wrote in message
news:8R4da.364$lQ4....@news20.bellglobal.com...
>
> Instead, you wish to spew
> out strings of letters in some private language, that you and you only
> understand, then claim the rest of us are rather dumb because we obviously
> do not see your point.
>
Has anyone ever seen Robert Wagner and Tony Dilworth at the same time <G>?
Pete.
Donald Tees
>
> "Donald Tees" <Donal...@sympatico.ca> wrote in message
> news:8R4da.364$lQ4....@news20.bellglobal.com...
> >
> > Instead, you wish to spew
> > out strings of letters in some private language, that you and you only
> > understand, then claim the rest of us are rather dumb because we
obviously
> > do not see your point.
> >
> Ah, now it has dawned on me...
>
> Has anyone ever seen Robert Wagner and Tony Dilworth at the same time <G>?
>
> Pete.
I am finding some of the "new age" language theory rather fascinating. I
wish I had had some of those insights thirty years ago, when I was
developing my "thinking modes".
Donald
Richard Plinston
> Ah, now it has dawned on me...
>
> Has anyone ever seen Robert Wagner and Tony Dilworth at the same time <G>?
Much the same in style, but opposite in content. Put the two in one room
and sell tickets.
Robert Wagner
In the domain of science, you'd be a theoritician and I'd be an experimenter.
Experimenters are not necessarily stupid (cf. Madame Wu), we're just more
practical-minded.
This a role reversal. In real life, I'm usually the abstract thinker resented by
operations people and mediocre programmers.
I don't harbor any anger. You blind-sided me with 'collating sequence', which is
fine in this little debating society. In the real world, low-values still means
x'00' 99.999% of the time.
WMK thinks english-speakers are parochial. How many languages does he speak
fluently?
Robert
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote in message
news:<3e74b6f5...@news.optonline.net>...
>> >
>> >The problem with this solution is that it means that you have to have
>> >the same behavior for the entire program. That's not desireable -
>> >sometimes I might want the filler initialized, other times I might
>> >not.
>>
>> When a language feature is unpredictable, I avoid using it, preferring to do
it
>> myself. I used to think 'move low-values ..' was predictable. Now I'll have
to
>> write 'move all x'00' ..'
>>
>
>Huh? Which part of INITIALIZE is unpredictable?
The unpredictability comes in maintenance. Consider:
*> copybook payroll-master
01 payroll-master.
....
*> 05 ytd-earnings pic x9(05)v9(02).
*> ytd-earnings has been replaced by new-ytd-earnings
*> changed 12/31/1989 by Robert Wagner per change notice 1234
05 filler pic s9(05)v9(02).
The field now contains random values aka 'garbage'.
>> I can live with that. I think of it in OO terms, as the value set by a
>> constructor. Whatever NEW does, INITIALIZE should do the same.
>
>That's why I sometimes override "NEW" with my own method - to do
>something different. I suppose that makes "NEW" unpredictable as well
>and maybe you shouldn't use it.
The beauty of OO is putting _you_ in charge of your own destiny, rather than a
standards committee. If you don't like the way NEW works, overload it with your
own method.
Too bad we cannot overload INITIALIZE as conveniently.