f



If you were inventing CoBOL...

If you were inventing CoBOL back when, what would you do differently?

I wonder how foresight would have effected OO enhancements.

I would like a USAGE LARGE for numbers that don't fit computer architecture
(have a hundred digits, but inefficient).

Could we get away with enforced structure with the efficiencies back then?

Would you do calls differently?

I see no reason for margins on the left and in the right.

I'd standardize GOBACK type exits.

I'd really like to improve on error checking for calls and functions.
0
howard (6283)
9/2/2004 1:43:54 PM
comp.lang.cobol 4278 articles. 1 followers. Post Follow

320 Replies
2901 Views

Similar Articles

[PageSpeed] 22

Buuuuttttt  If you were inventing COBOL would you be limited to the 
hardware and memory constraints of yester year?  Makes a huge difference.

PatH...doesn't want to hurt his brain too much this morning

Howard Brazee wrote:

> If you were inventing CoBOL back when, what would you do differently?
> 
> I wonder how foresight would have effected OO enhancements.
> 
> I would like a USAGE LARGE for numbers that don't fit computer architecture
> (have a hundred digits, but inefficient).
> 
> Could we get away with enforced structure with the efficiencies back then?
> 
> Would you do calls differently?
> 
> I see no reason for margins on the left and in the right.
> 
> I'd standardize GOBACK type exits.
> 
> I'd really like to improve on error checking for calls and functions.

0
phall1 (22)
9/2/2004 2:17:31 PM
On  2-Sep-2004, Pat Hall <phall@notsospam.certcoinc.com> wrote:

> Buuuuttttt  If you were inventing COBOL would you be limited to the
> hardware and memory constraints of yester year?  Makes a huge difference.

Maybe it would be interesting to split the answer into what I asked - you were
inventing it back then - and a separate answer if we had today's resources but
no need to have backward compatibility.
0
howard (6283)
9/2/2004 2:47:22 PM
On Thu, 2 Sep 2004 13:43:54 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>If you were inventing CoBOL back when, what would you do differently?

Omit PERFORM THRU. 
People wouldn't have acquired bad habits that had to be unlearned
later. The concept is flawed, and caused compilers grief in re
returns.

Make PERFORM pass parameters.

Define a DATE type.

Forget SECTIONs. They've always been unnecessary.

>I wonder how foresight would have effected OO enhancements.

??

>I would like a USAGE LARGE for numbers that don't fit computer architecture
>(have a hundred digits, but inefficient).

Don't need USAGE; pic 9(1000) says what you want.

>Could we get away with enforced structure with the efficiencies back then?

Yes. Structured has always been faster than spaghetti. Better overall
flow compensates for micro-inefficiencies. 

>Would you do calls differently?

No.

But I would add better dynamic memory. You call with a structure, it
allocates memory, sets a pointer to the structure but hides it from
you.  It's like an OO constructor. Then people wouldn't be afraid of
pointers because they couldn't accidentally step on them.

>I see no reason for margins on the left and in the right.

I've been using free-form for >20 years, on >3 compilers. The
foot-dragger is IBM.

>I'd standardize GOBACK type exits.

 I didn't know it was a problem, even before 2002.

>I'd really like to improve on error checking for calls and functions.

You already have that. It's called Prototypes. 

0
robert6624 (636)
9/2/2004 2:52:24 PM
Howard Brazee wrote:
> 
> On  2-Sep-2004, Pat Hall <phall@notsospam.certcoinc.com> wrote:
> 
> > Buuuuttttt  If you were inventing COBOL would you be limited to the
> > hardware and memory constraints of yester year?  Makes a huge difference.
> 
> Maybe it would be interesting to split the answer into what I asked - you were
> inventing it back then - and a separate answer if we had today's resources but
> no need to have backward compatibility.

Inventing it back then: most certainly include the in-line performs
(perform ...end-perform) and end-if; but I'd have to leave space
somewhere on the form for sequence numbers because we were using card
decks!  I would have a different method for indicating overlayable
sections due to memory limitations.

If I were inventing it now: I'd require AT END and INVALID KEY with READ
statements (as appropriate); I would not have some verbs, especially
EVALUATE (hey! you did say "if YOU were inventing Cobol"!  And despite
study, explanations and examples, I've yet to come across a case where
an evaluate couldn't be done more clearly and usually simpler with IF's
and/or CASE statments).  We wouldn't need most of the various numeric
formats: "usage display" with (say) 24V8 maximum  digits would suffice
for nearly everything, along with special formats for extreme precision
requirements and really big numbers.  Apart from that, I would stick to
the original goal of clarity and English-like statements.  Cobol has
stood the test of time due to its inherent strengths: smart to retain
those.

PL
0
lacey (134)
9/2/2004 4:05:22 PM
On 2004-09-02, Howard Brazee <howard@brazee.net> wrote:
> If you were inventing CoBOL back when, what would you do differently?

eliminate "PEFORM THRU"
eliminate SECTIONS
eliminate "GO TO" unless there was a "CAME FROM"  verb also

allow parameters to be passed to PERFORM -- PERFORM 1000-XYZ USING A, B
and then having something like
1000-XYZ USING A PIC X(20), B PIC 9(05).

either force the use of periods after each statement, or only allow them at
the end of a paragraph

Create some type of qualification better than "X OF Y". Y.X or Y_X is much
nicer.




Create a distinct data type of BOOLEAN, with allowed values of TRUE and FALSE
so we can have something like 
01  ws-logical-switches.
    05  ws-switch-a      usage boolean value true.
    05  ws-switch-b      usage boolean value false.
    
    
and procedural statements like 
      set ws-switch-a to true       -- (I know we can do this now)
 and  set ws-switch-a to false      -- (but we can't do this yet)
  
 
 

-- 
Alex / AB2RC 
0
avflinsch (2)
9/2/2004 4:10:52 PM
On  2-Sep-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:

> Inventing it back then: most certainly include the in-line performs
> (perform ...end-perform) and end-if; but I'd have to leave space
> somewhere on the form for sequence numbers because we were using card
> decks!

But why do we need space for sequence numbers in 73-80 as well as 1-6?   I've
sorted cards both ways.
0
howard (6283)
9/2/2004 4:32:15 PM
The biggest omission, as far as I'm concerned - Date, DateTime & Time types,
plus the arithmetic functions for them.

Michael


0
9/2/2004 5:05:09 PM
See http://www.cobolportal.com/j4/files/04-0120.doc for the current state of
this capability as proposed by J4 for the 2008 COBOL standard.    WG4 will
be discussing it next month.  It doesn't require new "types" or PICTURE
character-strings -- all of its mechanisms coexist nicely with existing
COBOL USAGEs.

    -Chuck Stevens

"Michael Russell" <michael.russell@spamex.dsl.pipex.com> wrote in message
news:413752b1$0$20257$cc9e4d1f@news-text.dial.pipex.com...
> The biggest omission, as far as I'm concerned - Date, DateTime & Time
types,
> plus the arithmetic functions for them.
>
> Michael
>
>


0
9/2/2004 5:20:28 PM
Robert Wagner wrote:

>Forget SECTIONs. They've always been unnecessary.
>
>  
>
In your purview yes. But back using a Radio Shack with only 64K - 
absolute necessity to prioritize by allocating Section Numbers, to 
'swap' in and out, in order to achieve some objectives. To-day - I gave 
up on Sections  nigh on 20 years ago when I first switched the 
application to a PC - a Compaq portable.

Jimmy
0
jjgavan (507)
9/2/2004 5:25:38 PM
"avflinsch" <avflinsch@att.net> wrote in message
news:slrncjehhn.bj7.AB2RC@homer.linux1.lan...

> and procedural statements like
>       set ws-switch-a to true       -- (I know we can do this now)
>  and  set ws-switch-a to false      -- (but we can't do this yet)

If you're talking about 88's, yes, you can, presuming a COBOL compiler
compliant with (or containing this particular feature of) the current
standard ISO/IEC 1989:2002, and presuming  that the 88 has a "WHEN SET TO
FALSE" phrase in its VALUE clause.

    -Chuck Stevens


0
9/2/2004 5:37:31 PM
there may be others still around that can be more precise about the 
answers I'm giving below, and I'm not qualified to discuss some of the
features you are interested in, BUT.... I'll try anyway.

First, each time some feature would show up, it had a name that was new,
but usually Grace would say something like this. "Oh, that's not new,
we've been doing that all along, but we called ti ...."

Second, I believe given the current state of computers and programming,
she might say, "Oh, that's a good idea, etc.." Or not of course. <G>

My answers are inserted after each question.


Howard Brazee wrote:

> If you were inventing CoBOL back when, what would you do differently?

	Arrange to make some file formats and hardware features standard
	across all computers.
> 
> I wonder how foresight would have effected OO enhancements.

	In 1959, what was OO?
> 
> I would like a USAGE LARGE for numbers that don't fit computer architecture
> (have a hundred digits, but inefficient).

	You need them, write a proposal and we will consider it.
> 
> Could we get away with enforced structure with the efficiencies back then?
> 
	I'm not sure I know what you mean. Are we talking about End this and 
that, top down, ...what?

> Would you do calls differently?

	If the hardware had enough memory and storage to consider such
features, probably...
> 
> I see no reason for margins on the left and in the right.

We did, because we had ONE input medium in common. Punched cards,
and the things they caused to be habits. These reasons do not seem
so important today, unless we are talking tape, disk, other storage
recording methods and organizations.  This was the time of the Model
T. Not the Thunder bird.
> 
> I'd standardize GOBACK type exits.

There are a lot of things like that which I hope people will take
the time to study, an propose changes to the language.
> 
> I'd really like to improve on error checking for calls and functions.
Same as answer immediately above.


P.S. Back then, competition was based on unique hardware, and costs.
Think of the money spent since 1960 to support that method. Compare
that with the INTEL method today.  Had everyone agreed to make IBM
hardware back then, things would probably not seemed so important
as they did then. And BTW, as I view todays situation, the problem
is even worse.

Warren Simmons
wsimmons5@optonline.net
0
wsimmons5 (172)
9/2/2004 5:43:23 PM
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:413744C2.1041D866@mb.sympatico.ca...
> I would have a different method for indicating overlayable
> sections due to memory limitations.

Although memory limitations are far less an issue than they once were, it is
not clear that all architectures provide the capability of having arbitrary
large object code "blocks".  SECTIONs allow the user to have some control
over the size of such "blocks" and to avoid having "block transitions" occur
in critical-path code.   Even though I agree that the "Segmentation Module"
was way too specific and was appropriately marked as obsolete in '85, I
think retaining "SECTION" (as it still exists in 2002 COBOL) serves a useful
purpose -- whether or not the SECTIONs are ever referenced via GO TO or
PERFORM, and whether or not the implementor does "code block breaks" at
SECTION boundaries.  If nothing else, they can be used to establish a
hierarchy of procedural code between the program and the paragraph levels,
which can be helpful to the programmer (or the *next* programmer to work on
the program).

    -Chuck Stevens


0
9/2/2004 5:52:45 PM
On  2-Sep-2004, Warren Simmons <wsimmons5@optonline.net> wrote:

> > Could we get away with enforced structure with the efficiencies back then?
> >
> 	I'm not sure I know what you mean. Are we talking about End this and
> that, top down, ...what?

There are languages that are much harder to write unstructured code with.  
Eliminating drop thru paragraphs & sections is one way to do this.
0
howard (6283)
9/2/2004 6:06:54 PM
On  2-Sep-2004, Warren Simmons <wsimmons5@optonline.net> wrote:

> > I see no reason for margins on the left and in the right.
>
> We did, because we had ONE input medium in common. Punched cards,
> and the things they caused to be habits. These reasons do not seem
> so important today, unless we are talking tape, disk, other storage
> recording methods and organizations.  This was the time of the Model
> T. Not the Thunder bird.

OK.   In 1969 I saw no reason for margins on both the left and in the right. 
Admittedly CoBOL was a mature language then, but we still used punched cards.  
1969 was Model T time as far as computing goes.
0
howard (6283)
9/2/2004 6:09:44 PM
On the subject of "margins on the left and right".

The '68 thru '85 (and '02 when in fixed form reference format) *only* specify 
"sequence area" for columns 1-6. (Since the '85 Standard, this area doesn't need 
to be numbers, much less in ascending order)

There is NO requirement for the "R-margin" (end of source code) to be after 
column 72, 80, or any other specific place.  This is left up to the implementor.

As far as what appears (if anything) between the R-margin and "end-of-line" 
there is NOTHING in any previous or current standard suggesting that there 
should (or must) be a "right margin".  In an interpretation of the '85 Standard 
(if I recall correctly - or it might just have been when developing the '02 
Standard), it was determined that the "implementor definition of end of line" 
*allowed* for the implementor to "support" columns 73-80 (for example) to 
"include data".  But this is certainly not something that the Standard ever 
talks about, much less requires.

   ***

In the '02 Standard when using free form reference format, the "sequence area" 
(columns 1-6) is gone.  A programmer may (but is not required to) use inline 
comments, at the end of any, many, or all lines to "identify" the line.

-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
wmklein (2605)
9/2/2004 7:14:36 PM
Even in fixed-form reference format, the distinction between Margin A and
Margin B is gone in ISO/IEC 1989:2002.

    -Chuck Stevens

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:cJmdnUo_d4697KrcRVn-rw@comcast.com...
> On the subject of "margins on the left and right".
>
> The '68 thru '85 (and '02 when in fixed form reference format) *only*
specify
> "sequence area" for columns 1-6. (Since the '85 Standard, this area
doesn't need
> to be numbers, much less in ascending order)
>
> There is NO requirement for the "R-margin" (end of source code) to be
after
> column 72, 80, or any other specific place.  This is left up to the
implementor.
>
> As far as what appears (if anything) between the R-margin and
"end-of-line"
> there is NOTHING in any previous or current standard suggesting that there
> should (or must) be a "right margin".  In an interpretation of the '85
Standard
> (if I recall correctly - or it might just have been when developing the
'02
> Standard), it was determined that the "implementor definition of end of
line"
> *allowed* for the implementor to "support" columns 73-80 (for example) to
> "include data".  But this is certainly not something that the Standard
ever
> talks about, much less requires.
>
>    ***
>
> In the '02 Standard when using free form reference format, the "sequence
area"
> (columns 1-6) is gone.  A programmer may (but is not required to) use
inline
> comments, at the end of any, many, or all lines to "identify" the line.
>
> -- 
> Bill Klein
>  wmklein <at> ix.netcom.com
>
>


0
9/2/2004 7:19:41 PM
..    Am  02.09.04
schrieb  howard@brazee.net (Howard Brazee)
    auf  /COMP/LANG/COBOL
     in  ch7nl8$t7s$1@peabody.colorado.edu
  ueber  Re: If you were inventing CoBOL...

>>> I see no reason for margins on the left and in the right.
>>
>> We did, because we had ONE input medium in common. Punched cards,
>> and the things they caused to be habits. These reasons do not seem
>> so important today, unless we are talking tape, disk, other storage
>> recording methods and organizations.  This was the time of the Model
>> T. Not the Thunder bird.

HB> OK.   In 1969 I saw no reason for margins on both the left and in the
HB> right. Admittedly CoBOL was a mature language then, but we still used
HB> punched cards. 1969 was Model T time as far as computing goes.

   So what was the punched tape back then? A phaeton? A race-car?

   Algol, it seems, was for the people using punched tape, and  
FORTRAN, I read, was an effort to sell punched cards to engineers.


Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Die Interessen der Nation lassen sich nicht anders formulieren als unter
dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
Herrschaft anstrebt."            - Leo Trotzki         (27. Januar 1932)
0
l.willms1 (637)
9/2/2004 7:41:00 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com...

> >Could we get away with enforced structure with the efficiencies back
then?
>
> Yes. Structured has always been faster than spaghetti. Better overall
> flow compensates for micro-inefficiencies.

*Always*?

The seeds of "structured programming" appear to have been first sown with
Edsger Dijkstra's paper disparaging the use of GO TO, some eight years after
the specification of COBOL-60 and some two years before the content of what
became the '68 standard was finished!   The only *language* I've ever run
into that seemed to take Dijkstra's opinions to heart was SDL/UPL on the
B1000 -- and this, I believe, was written during the period when Dijkstra
was a Burroughs fellow, and even that had an "UNDO" statement whose effect
was to take flow out of the current block -- and in a violation of
Dijkstra's philosophy, out of a *parent* block.   The concept of the "block"
was adopted from Algol, a language which Dijkstra (and later Wirth) greatly
admired.

There are some things that have been done through the history of COBOL that
I'd personally rather have been done differently, and at some point I may
articulate them, but I want to avoid speculations like "If pigs had wings,
maybe they could fly" in the process.

    -Chuck Stevens


0
9/2/2004 7:41:04 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> >If you were inventing CoBOL back when, what would you do differently?
> 
> Omit PERFORM THRU. 
> People wouldn't have acquired bad habits that had to be unlearned
> later. The concept is flawed, and caused compilers grief in re
> returns.

In the late 50s the programmers wrote constructs in particular ways
using languages with certain features.  Cobol took features from
several existing languages and merged them to provide the easiest
upgrade path for programmers.

If they had crippled it (in the opinion of the programmers) such that
existing techniques could not be used then the language would have
failed because few would have used it.
 
> Forget SECTIONs. They've always been unnecessary.

You may not know what they were for, but they were essential on
machines that I used, and on most of the machines at the time.

> Yes. Structured has always been faster than spaghetti. Better overall
> flow compensates for micro-inefficiencies. 

You are wrong, but I can't be bothered arguing it.

> But I would add better dynamic memory. You call with a structure, it
> allocates memory, sets a pointer to the structure but hides it from
> you.  It's like an OO constructor. Then people wouldn't be afraid of
> pointers because they couldn't accidentally step on them.

You mean: just like Java does.
0
riplin (4127)
9/2/2004 7:48:34 PM
..    Am  02.09.04
schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
    auf  /COMP/LANG/COBOL
     in  eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com
  ueber  Re: If you were inventing CoBOL...

RW> Forget SECTIONs. They've always been unnecessary.

   Besides that in my style, I always divided up my programs in  
SECTIONs (having one single paragraph called ANFANG, i.e. German for  
"BEGIN"), you can't do without SECTIONs when you are using  
DECLARATIVEs, COBOLs equivalent to ON ERROR GOTO.



yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Es sind nicht die Gener�le und K�nige, die die Geschichte machen,
sondern die breiten Massen des Volkes"                - Nelson Mandela
0
l.willms1 (637)
9/2/2004 7:52:00 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:ch7nl8$t7s$1@peabody.colorado.edu...

> OK.   In 1969 I saw no reason for margins on both the left and in the
right.
> Admittedly CoBOL was a mature language then, but we still used punched
cards.
> 1969 was Model T time as far as computing goes.

In 1969 -- and well into the 1980's, at least -- people were *still* using
punch cards as input not only to application programs but to compilers -- 
either as source patches or as entire source files.  The programmer who
didn't put sequence numbers in his source card decks was risking
catastrophe!   It was a Big Deal for a user site I worked for when we were
able to nstall our very first data communications network, went to
line-at-a-time source editing using (gasp!) terminals and got rid of our
keypunches in 1977!   Certainly the distinction between Margin L and Margin
C was important to *that* site!

    -Chuck Stevens


0
9/2/2004 7:57:28 PM
"Howard Brazee" <howard@brazee.net> wrote:

>
>On  2-Sep-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:
>
>> Inventing it back then: most certainly include the in-line performs
>> (perform ...end-perform) and end-if; but I'd have to leave space
>> somewhere on the form for sequence numbers because we were using card
>> decks!
>
>But why do we need space for sequence numbers in 73-80 as well as 1-6?   I've
>sorted cards both ways.

<Zummmerzet accent>

When I were just a young laad..  We used to put the program ID in
73-80 as well as the sequence in 1-6.  That way, if/when one of the
ops dropped a tray of cards it was possible to sort them back into
correctly-sequenced individual programs..  :-)

</Zummerzet accent>

-- 
Jeff.         Ironbridge,  Shrops,  U.K.
jjy@jakfield.xu-netx.com  (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)

.... "There are few hours in life more agreeable
      than the hour dedicated to the ceremony
      known as afternoon tea.."

         Henry James,  (1843 - 1916).

 
0
ralf4 (132)
9/2/2004 8:34:04 PM
On  2-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> In 1969 -- and well into the 1980's, at least -- people were *still* using
> punch cards as input not only to application programs but to compilers -- 
> either as source patches or as entire source files.  The programmer who
> didn't put sequence numbers in his source card decks was risking
> catastrophe!   It was a Big Deal for a user site I worked for when we were
> able to nstall our very first data communications network, went to
> line-at-a-time source editing using (gasp!) terminals and got rid of our
> keypunches in 1977!   Certainly the distinction between Margin L and Margin
> C was important to *that* site!

Sure.   I remember using the card sorter to put my deck back in order.   But I
never needed both sets of sequence numbers to do so.  One was sufficient.     
0
howard (6283)
9/2/2004 8:41:30 PM
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:cJmdnUo_d4697KrcRVn-rw@comcast.com...
> On the subject of "margins on the left and right".
>
> The '68 thru '85 (and '02 when in fixed form reference format) *only*
specify
> "sequence area" for columns 1-6. (Since the '85 Standard, this area
doesn't need
> to be numbers, much less in ascending order)
>
> There is NO requirement for the "R-margin" (end of source code) to be
after
> column 72, 80, or any other specific place.  This is left up to the
implementor.

True for '74 and later; I see some evidence that that's not the case for
ANSI X3.23-1968.

Note that I don't have a copy of that standard (I wish I did and I've been
looking for one for a very long time), but the I do have at hand indicates
that Margin R was specified as Column 72, columns 73-80 being reserved for
"identification".

I have an IBM DOS reference manual from '73 that so specifies and doesn't
mark it as an extension and a later Unisys A Series COBOL(68) reference
manual that does likewise.  When both agree on a specification, and both
fail to specify it as an extension, it is a usually-reliable indicator of
the presence of that specification in the '68 standard.  COBOL coding forms
from both IBM and Burroughs (the latter dating back as far as 1963!)
indicate that this was at the very least conventional by then.

> As far as what appears (if anything) between the R-margin and
"end-of-line"
> there is NOTHING in any previous or current standard suggesting that there
> should (or must) be a "right margin".

Not clear to me; I'd argue otherwise for '68 and, if my B6500 COBOL
reference manual is to be believed, COBOL-60 as well.

I'd *expect* any compliant compiler before '74 to stop looking for COBOL
source after Column 72.   Anybody got a copy of ANSI X3.23-1968 to check?

    -Chuck Stevens


0
9/2/2004 8:43:33 PM
On  2-Sep-2004, Jeff York <ralf4@btinternet.com> wrote:

> When I were just a young laad..  We used to put the program ID in
> 73-80 as well as the sequence in 1-6.  That way, if/when one of the
> ops dropped a tray of cards it was possible to sort them back into
> correctly-sequenced individual programs..  :-)

That's right.   I forgot about that.   Some shops had that, and others used the
same sequence number standards they used for JCL, namely numbers in the right.
0
howard (6283)
9/2/2004 8:53:56 PM
On Thu, 2 Sep 2004 10:37:31 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"avflinsch" <avflinsch@att.net> wrote in message
>news:slrncjehhn.bj7.AB2RC@homer.linux1.lan...
>
>> and procedural statements like
>>       set ws-switch-a to true       -- (I know we can do this now)
>>  and  set ws-switch-a to false      -- (but we can't do this yet)
>
>If you're talking about 88's, yes, you can, presuming a COBOL compiler
>compliant with (or containing this particular feature of) the current
>standard ISO/IEC 1989:2002, and presuming  that the 88 has a "WHEN SET TO
>FALSE" phrase in its VALUE clause.

We can say:

05  pic 9 value 0.
     88 end-of-file value 1 false 0.

And we can say: 

    set end-of-file to false

But we cannot say:

05  pic 9 value not end-of-file.
     88  end-of-file value 1 false 0.

We have to code the value 0 in two places. Someone might change one
and overlook the other.

If it's indirect in the procedure division, why isn't it indirect in
the data division as well?
    
0
robert6624 (636)
9/2/2004 9:06:06 PM
On Thu, 2 Sep 2004 13:43:54 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>If you were inventing CoBOL back when, what would you do differently?

Get rid of precedence rules. Require that logical and arithmetic
statements  use parentheses on statements containing more than one
level. 

Do not allow logical elision between AND/OR nor into or out of
parentheses.

For example, this would be invalid:

if a not = b and c or d

Would be written as:

if (a not = b and c) or (a not = d)

Require a warning on logical statements always true or false. For
example:

if a not = 1 or 2
if a = b or c or a

Reason for both: after newbies get bitten a few times, shops pass
rules prohibiting all elision. I think it's one of Cobol's nicest
features. Other languages drive me crazy when they make me repeat the
subject over and over. 


0
robert6624 (636)
9/2/2004 9:08:06 PM
On Thu, 2 Sep 2004 16:32:15 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>On  2-Sep-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:
>
>> Inventing it back then: most certainly include the in-line performs
>> (perform ...end-perform) and end-if; but I'd have to leave space
>> somewhere on the form for sequence numbers because we were using card
>> decks!
>
>But why do we need space for sequence numbers in 73-80 as well as 1-6?   I've
>sorted cards both ways.

The other one was for version control .. still is in many places. 
0
robert6624 (636)
9/2/2004 9:08:08 PM
On Thu, 02 Sep 2004 17:25:38 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:

>Robert Wagner wrote:
>
>>Forget SECTIONs. They've always been unnecessary.

>In your purview yes. But back using a Radio Shack with only 64K - 
>absolute necessity to prioritize by allocating Section Numbers, to 
>'swap' in and out, in order to achieve some objectives. To-day - I gave 
>up on Sections  nigh on 20 years ago when I first switched the 
>application to a PC - a Compaq portable.

If you MUST do memory management, dynamic CALL/CANCEL is better.

It has the additional benefit of organizing an oversize program into
more manageable pieces.

0
robert6624 (636)
9/2/2004 9:08:09 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:4s2fj0dubd28r06p92bcvnrmg9jsurin6b@4ax.com...

> Get rid of precedence rules. Require that logical and arithmetic
> statements  use parentheses on statements containing more than one
> level.

I actually agree with Robert here in at least part of this:  I think
abbreviated combined relation conditions in particular are a delusion and a
snare.    The big problem with them is that it is at first glance
*reasonable* but ultimately *erroneous* that abbreviation implies some sort
of association not otherwise implied by the precedence rules (or the
parentheses).

The 2002 standard points out some of the problems with Abbreviated Combined
Relation Conditions  in an ISO NOTE on page 137 relating to the use of NOT
in abbreviations; this has been expanded further a part of the
clarifications in an approved proposal to add the relational operator "<>"
for "not equal" in the draft for the next standard, which proposal may be
found at http://www.cobolportal.com/j4/files/03-0224.doc .

 COBOL's arithmetic precedence rules don't bother me that much; they seem to
match Fortran, ALGOL, Pascal and PL/I at least, so someone coming from those
languages shouldn't be terribly confused.

But as a matter of style too many parentheses in either case is better than
too few.

> Require a warning on logical statements always true or false. For
> example:

> if a not = 1 or 2
> if a = b or c or a

Many implementors do this; it's not clear to me that it's the *standard's*
job to tell the *implementor* how to keep the *programmer* from shooting
himself in the foot in every case.  I believe the standard specifies a
mechanism for flagging *standards violations*, but not one for *advisories*
along the lines of "Are you sure that's what you meant?" (or even for the
method of presentation of syntax *errors*, except that object code shouldn't
be produced when they occur).   It may actually be a useful technique for
*incorporating* prototype code into *production* programs before testing is
complete; I've found it useful to "stub" large blocks of code that way -- or
even with "IF <enabling-condition> AND FALSE THEN ..." , where all I have to
do is delete the "AND FALSE" to open up the new logic, in my time.

    -Chuck Stevens


0
9/2/2004 9:43:29 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:042fj0ls9pu3je725nbdmkm45pths5csfr@4ax.com...

> We can say:
>
> 05  pic 9 value 0.
>      88 end-of-file value 1 false 0.
>
> And we can say:
>
>     set end-of-file to false
>
> But we cannot say:
>
> 05  pic 9 value not end-of-file.
>      88  end-of-file value 1 false 0.
>
> We have to code the value 0 in two places. Someone might change one
> and overlook the other.
>
> If it's indirect in the procedure division, why isn't it indirect in
> the data division as well?

I think that compromises the utility and clarity of the multivalued case for
TRUE.  You could equally well have coded
    05  pic 9 value not end-of-file.
        88  end-of-file values 1 thru 9 false 0.

This is unambiguous as written, but what if it read "05 pic 9 value
end-of-file."?

I'm also not convinced that it adds significant utility.  I'm also not sure
what "it" is that you are claiming needs to be "indirect".

    -Chuck Stevens


0
9/2/2004 10:10:26 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:3u2fj01k5p28pca6imktrckrd1ulp1mbml@4ax.com...

> If you MUST do memory management, dynamic CALL/CANCEL is better.

What, in *standards terms*, is "dynamic CALL/CANCEL"?  The way I would
presume "dynamic" applied to CALL/CANCEL is CALL <dataname> as distinct from
CALL <literal>, and there are implementations where "dynamic CALL/CANCEL" is
maybe better than developing the information using an abacus and a pointed
stick on wet clay, but not by much!

I don't disagree that "modularity" is a virtue, and I happen to agree that
IPC (even as implemented according to '74 standards) is a really good way to
accomplish modularity, but I'm not convinced that the problems of memory
management are best solved by *procedural* modularity, particularly when the
system already does a pretty good job of handling object code, without any
involvement by the user at all, the overwhelming majority of the time.

> It has the additional benefit of organizing an oversize program into
> more manageable pieces.

One man's "oversize" is another man's "trivial".

Two personal hot buttons on related subjects:

Personally, I think "nested programs" is a Good Thing.  I just don't like
where the '85 standard put them.  I would personally have preferred that
the nested programs be located before any executable code in the PROCEDURE
DIVISION of the parent rather than after it.

While I'm on the subject of '85 CALL enhancements, I would have preferred
the BY VALUE/BY REFERENCE distinction be part of the "signature" of the
"callee" rather than the sole responsibility of the "caller".

    -Chuck Stevens


0
9/2/2004 10:28:48 PM
Jeff York wrote:

>"Howard Brazee" <howard@brazee.net> wrote:
>
>  
>
>>On  2-Sep-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:
>>
>>    
>>
>>>Inventing it back then: most certainly include the in-line performs
>>>(perform ...end-perform) and end-if; but I'd have to leave space
>>>somewhere on the form for sequence numbers because we were using card
>>>decks!
>>>      
>>>
>>But why do we need space for sequence numbers in 73-80 as well as 1-6?   I've
>>sorted cards both ways.
>>    
>>
>
><Zummmerzet accent>
>
>When I were just a young laad..  We used to put the program ID in
>73-80 as well as the sequence in 1-6.  That way, if/when one of the
>ops dropped a tray of cards it was possible to sort them back into
>correctly-sequenced individual programs..  :-)
>
></Zummerzet accent>
>
>  
>
Your Somerset shire bit hits the nail on the head. Started in systems on 
an ICT 1500 at Trowbridge, (we were using Machine Code and mainly FAS 
(1500 Assembler)).  All paper tape. Moved to Debenhams  in Taunton, ICL 
1900 series where we initially still used paper tape. But already geared 
to going to COBOL as the standard we did exactly as you did with the 
paper tape, reference 1-6 and 73-80; (The identification helped when 
splitting paper-tape and splicing in a correction).I think that may have 
even been the case when we moved to key-to-tape and then key-to-disk. No 
luxuries back in the '70s as Chuck pointed out. I think we got three 
EXPENSIVE VDUs about '74 - a constant line-up (queue) of the programmers 
trying to submit their jobs to the magic box on the floor below.

Currently, as a more practical use, if I do print a program to check 
(sometimes more complete than viewing on screen) or if I wish to retain 
a hard copy, then it's better for appearance to have margins for filing 
in a binder - using  'portrait'.. I could go 'free format' but I still 
stick to columns 8 - 72 inclusive.

That was a bloody feeble attempt at Zummerzet from a Shrop-SHAIRE lad ! 
Went back in 2000 and visited Yeovil and Taunton - sadly just 'townie' 
accents, somewhat 'Estuary English' (London). Noww iff oid garn upt ter 
Dunkery Beacon to voo the Welsh Coast on a dursant day, quate liklee I 
wouldda 'ad sum werds wiv folks wat zounded loike the charaketers from 
Blackmore's "Larna Duuune" (Lorna Doone).  :-)

Jimmy, Calgary AB
0
jjgavan (507)
9/2/2004 10:31:06 PM
Do add to Chuck's comment, there is a common "misconception" that the CANCEL 
statement *must* free storage.  Not only does the Standard not require this, 
there are a number of implementations that don't do it.  The only thing that the 
CANCEL statement is required to do is to insure that the next time the CANCELed 
program is called, it is in initial - not last-used - state.

P.S.  The IBM mainframe documentation states that the reason that using the 
NODYNAM compiler option is "not conforming to the ANSI/ISO Standard" is that it 
does NOT insure that a CANCEL places subprograms in initial state. I don't know 
how many/which other implementations may have this same "non-Standard" behavior. 
If they do, then they must include an option (similar to IBM's DYNAM option) for 
standard conformance.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message 
news:ch86r0$t6i$1@si05.rsvl.unisys.com...
>
> "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:3u2fj01k5p28pca6imktrckrd1ulp1mbml@4ax.com...
>
>> If you MUST do memory management, dynamic CALL/CANCEL is better.
>
> What, in *standards terms*, is "dynamic CALL/CANCEL"?  The way I would
> presume "dynamic" applied to CALL/CANCEL is CALL <dataname> as distinct from
> CALL <literal>, and there are implementations where "dynamic CALL/CANCEL" is
> maybe better than developing the information using an abacus and a pointed
> stick on wet clay, but not by much!
>
> I don't disagree that "modularity" is a virtue, and I happen to agree that
> IPC (even as implemented according to '74 standards) is a really good way to
> accomplish modularity, but I'm not convinced that the problems of memory
> management are best solved by *procedural* modularity, particularly when the
> system already does a pretty good job of handling object code, without any
> involvement by the user at all, the overwhelming majority of the time.
>
>> It has the additional benefit of organizing an oversize program into
>> more manageable pieces.
>
> One man's "oversize" is another man's "trivial".
>
> Two personal hot buttons on related subjects:
>
> Personally, I think "nested programs" is a Good Thing.  I just don't like
> where the '85 standard put them.  I would personally have preferred that
> the nested programs be located before any executable code in the PROCEDURE
> DIVISION of the parent rather than after it.
>
> While I'm on the subject of '85 CALL enhancements, I would have preferred
> the BY VALUE/BY REFERENCE distinction be part of the "signature" of the
> "callee" rather than the sole responsibility of the "caller".
>
>    -Chuck Stevens
>
> 


0
wmklein (2605)
9/2/2004 10:46:49 PM
On Thu, 2 Sep 2004 13:43:33 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:


>I'd *expect* any compliant compiler before '74 to stop looking for COBOL
>source after Column 72.  

The current Oracle pre-compiler (Pro*Cobol) ABENDS if there's anything
beyond 72. 
0
robert6624 (636)
9/2/2004 11:01:06 PM
On Thu, 2 Sep 2004 12:41:04 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com...
>
>> >Could we get away with enforced structure with the efficiencies back
>then?
>>
>> Yes. Structured has always been faster than spaghetti. Better overall
>> flow compensates for micro-inefficiencies.
>
>*Always*?

I meant at all times during the evolution of hardware, even on anemic
machines of the '60s.

Many people independently discovered structured programming in the
late '60s. I recall when I did in '68 after this conversation:

EM: Did you know it's possible to write a program without a single
GOTO?
RW: Nah, can't be done. How would you handle ...
EM: Here, look at this proof of concept. 
RW: Hey, this is interesting. You know that program we were about to
rewrite? Let's try it this way. It'll be a challenge to write in this
wierd style.

We did, and it came out half the size (in source lines) as the
original. It ran faster too, on a Spectra 70 comparable to a 360-40.
So we rewrote a dozen more programs, developing style in the process.
We learned early on the value of many callable programs. 
In he end, our rewrites were running 25-50% faster than the originals.
Why? Because they were more cleanly designed. We made decisions once
rather than several times. We passed data between programs in memory
rather than through files. We replaced three load modules and data
passes with one.

Structured programming per se didn't run faster. It was the catalyst
to learning top-down design.  We'd write the framework first, stub out
or dummy the low-level code, and test flow of control FIRST. As we
added layers of lower code, it came into focus. 

The old programs had been designed bottom-up .. by 'coders' who wrote
file handling first rather than last. They had inordinate trouble
mastering flow of control, which led to redundant code.

That's why structured programming is faster.


0
robert6624 (636)
9/2/2004 11:01:07 PM
On 2 Sep 2004 12:48:34 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
>

>> Forget SECTIONs. They've always been unnecessary.
>
>You may not know what they were for, but they were essential on
>machines that I used, and on most of the machines at the time.

They were for memory management. I used overlays on one machine, a
Honeywell 2200. Then I discovered dynamic call and didn't go back to
sections.

>> But I would add better dynamic memory. You call with a structure, it
>> allocates memory, sets a pointer to the structure but hides it from
>> you.  It's like an OO constructor. Then people wouldn't be afraid of
>> pointers because they couldn't accidentally step on them.
>
>You mean: just like Java does.

Realia had that in 1984. I wish others had copied it. 
0
robert6624 (636)
9/2/2004 11:01:08 PM
On 02 Sep 2004 19:52:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>.    Am  02.09.04
>schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
>    auf  /COMP/LANG/COBOL
>     in  eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com
>  ueber  Re: If you were inventing CoBOL...
>
>RW> Forget SECTIONs. They've always been unnecessary.
>
>you can't do without SECTIONs when you are using  
>DECLARATIVEs, COBOLs equivalent to ON ERROR GOTO.

Declaratives are Cobol's equivalent of COME FROM. Problem is, they
don't know where they came from, so they can't describe the error in
detail. 


0
robert6624 (636)
9/2/2004 11:01:08 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:dq5fj092r4fdu26cuhun2j7v284pqtco0s@4ax.com...
> On Thu, 2 Sep 2004 12:41:04 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
> >"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> >news:eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com...
> >
> >> >Could we get away with enforced structure with the efficiencies back
> >then?
> >>
> >> Yes. Structured has always been faster than spaghetti. Better overall
> >> flow compensates for micro-inefficiencies.
> >
> >*Always*?
>
> I meant at all times during the evolution of hardware, even on anemic
> machines of the '60s.

What about the anemic machines of the '50's?  I did a little programming on
1401's, and also on machines that didn't have COBOL compilers or do "block
structure" very well to begin with.

>
> Many people independently discovered structured programming in the
> late '60s. I recall when I did in '68 after this conversation:

The deprecation of "go to" seems indeed to have been stimulated by an
article by Dijkstra published in March 1968.   It's not clear *to me* that
there was widespread advocacy of such an approach before then.

> EM: Did you know it's possible to write a program without a single
> GOTO? ...

All very well and good, but it relied on ideas that nobody seems to have
espoused *before* March of 1968.

> We did, and it came out half the size (in source lines) as the
> original. It ran faster too, on a Spectra 70 comparable to a 360-40.

That doesn't mean the techniques could reasonably be applied before they
were invented.  I don't think GO TO in  COBOL is inherently evil any more
than the branch instructions on the 1401 were.

I don't think "if we had some ham, we could have some ham and eggs -- if we
had some eggs" speculations are useful; I'm personally limiting myself to
things that I believe were, in my view,  architectural *errors*.  The
presence or absence of GO TO is a religious war, and I personally know of
*no* hardware architecture that omits it altogether.   Even BALR on the
System/360 did a *branch*.   Speculation as to what the world would have
been like if Dijkstra had been Grace Hopper's boss back in the 1950's aren't
very useful in my view.   I think there's a case to be made for some
mistakes in direction *at the time they were taken*, but I don't think
eliminating GO TO from COBOL would have been appropriate in 1968 or even
today.

> Structured programming per se didn't run faster. It was the catalyst
> to learning top-down design.  We'd write the framework first, stub out
> or dummy the low-level code, and test flow of control FIRST. As we
> added layers of lower code, it came into focus.
>
> The old programs had been designed bottom-up .. by 'coders' who wrote
> file handling first rather than last. They had inordinate trouble
> mastering flow of control, which led to redundant code.
>
> That's why structured programming is faster.

And structured programming was a concept that wasn't "always" around.



    -Chuck Stevens


0
9/3/2004 12:03:22 AM
Chuck Stevens wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:ch7nl8$t7s$1@peabody.colorado.edu...
>
>> OK.   In 1969 I saw no reason for margins on both the left and in
>> the right. Admittedly CoBOL was a mature language then, but we still
>> used punched cards. 1969 was Model T time as far as computing goes.
>
> In 1969 -- and well into the 1980's, at least -- people were *still*
> using punch cards as input not only to application programs ....

How about the 2000 election (and 2004 in some places)?


0
nospam312 (645)
9/3/2004 12:15:41 AM
Howard Brazee wrote:
> If you were inventing CoBOL back when, what would you do differently?
>
> I wonder how foresight would have effected OO enhancements.
>
> I would like a USAGE LARGE for numbers that don't fit computer
> architecture (have a hundred digits, but inefficient).
>
> Could we get away with enforced structure with the efficiencies back
> then?
>
> Would you do calls differently?
>
> I see no reason for margins on the left and in the right.
>
> I'd standardize GOBACK type exits.
>
> I'd really like to improve on error checking for calls and functions.

Frankly, I can't think of a thing I'd do differently.....


0
nospam312 (645)
9/3/2004 12:17:31 AM
Robert Wagner wrote:
> 
> 
> 
> Declaratives are Cobol's equivalent of COME FROM. Problem is, they
> don't know where they came from, so they can't describe the error in
> detail.

Sure they can: it takes some coding effort, though.  Just set up WS
variables  FILE-NAME, WHERE-IN-PROGRAM, and FUNCTION, and fill them
properly before performing any I-O.  Then the Declarative can display
messages or make decisions based on what it's given.  I've been doing it
for years.

PL
0
lacey (134)
9/3/2004 12:19:41 AM
In article <dq5fj092r4fdu26cuhun2j7v284pqtco0s@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On Thu, 2 Sep 2004 12:41:04 -0700, "Chuck Stevens"
><charles.stevens@unisys.com> wrote:
>
>>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>>news:eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com...
>>
>>> >Could we get away with enforced structure with the efficiencies back
>>then?
>>>
>>> Yes. Structured has always been faster than spaghetti. Better overall
>>> flow compensates for micro-inefficiencies.
>>
>>*Always*?
>
>I meant at all times during the evolution of hardware, even on anemic
>machines of the '60s.
>
>Many people independently discovered structured programming in the
>late '60s. I recall when I did in '68 after this conversation:
>
>EM: Did you know it's possible to write a program without a single
>GOTO?
>RW: Nah, can't be done. How would you handle ...
>EM: Here, look at this proof of concept. 
>RW: Hey, this is interesting. You know that program we were about to
>rewrite? Let's try it this way. It'll be a challenge to write in this
>wierd style.

[snip]

>In he end, our rewrites were running 25-50% faster than the originals.
>Why? Because they were more cleanly designed. We made decisions once
>rather than several times. We passed data between programs in memory
>rather than through files. We replaced three load modules and data
>passes with one.
>
>Structured programming per se didn't run faster. It was the catalyst
>to learning top-down design.

Good of you to come to this realisation, Mr Wagner... a less-biased test 
between structured and non-structured would have been to have two teams 
putting the same amount of analysis and design time into the code; what 
you appear to have demonstrated above is that well-thought-out and 
-designed structured code rewrites are faster than the original code was.

DD

0
docdwarf (6044)
9/3/2004 12:24:29 AM
Robert Wagner wrote:
> On 02 Sep 2004 19:52:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
> 
> 
>>.    Am  02.09.04
>>schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
>>   auf  /COMP/LANG/COBOL
>>    in  eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com
>> ueber  Re: If you were inventing CoBOL...
>>
>>RW> Forget SECTIONs. They've always been unnecessary.
>>
>>you can't do without SECTIONs when you are using  
>>DECLARATIVEs, COBOLs equivalent to ON ERROR GOTO.
> 
> 
> Declaratives are Cobol's equivalent of COME FROM. Problem is, they
> don't know where they came from, so they can't describe the error in
> detail. 
> 
> 
Come from.....

Perform did a branch and return. Doesn't that count?

Warren
0
wsimmons5 (172)
9/3/2004 1:55:28 AM
Robert Wagner wrote:

> On Thu, 2 Sep 2004 13:43:54 GMT, "Howard Brazee" <howard@brazee.net>
> wrote:
> 
> 
>>If you were inventing CoBOL back when, what would you do differently?
> 
> 
> Get rid of precedence rules. Require that logical and arithmetic
> statements  use parentheses on statements containing more than one
> level. 
> 
> Do not allow logical elision between AND/OR nor into or out of
> parentheses.
> 
> For example, this would be invalid:
> 
> if a not = b and c or d
> 
> Would be written as:
> 
> if (a not = b and c) or (a not = d)
> 
> Require a warning on logical statements always true or false. For
> example:
> 
> if a not = 1 or 2
> if a = b or c or a
> 
> Reason for both: after newbies get bitten a few times, shops pass
> rules prohibiting all elision. I think it's one of Cobol's nicest
> features. Other languages drive me crazy when they make me repeat the
> subject over and over. 
> 
> 
then you would be delighted to know, that many years into the COBOL
effort, the CC had a task group trying to clarify this kind of
"logic".  Seems most had never had that  much exposure to this.

Warren
0
wsimmons5 (172)
9/3/2004 2:06:34 AM
If anyone doesn't know how to tell "where they came from" in a DEBUGGING 
DECLARATIVE, check out the "Debug-item" special register.  See (for example):

 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr20/1.3.8.2

When/if you ever have a 2002 conforming compiler (and use "exception" 
declaratives) check out the following (new) intrinsic functions:

EXCEPTION-FILE                 Information about the file exception that raised 
an exception

EXCEPTION-FILE-N             (National) Information about the file exception 
that raised an exception

EXCEPTION-LOCATION      Implementor-defined location of statement causing an 
exception

EXCEPTION-LOCATION-N  (National) Implementor-defined location of statement 
causing an exception

EXCEPTION-STATEMENT Name of statement causing an exception

EXCEPTION-STATUS         Exception-name identifying last exception

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message 
news:4137B89D.39484918@mb.sympatico.ca...
> Robert Wagner wrote:
>>
>>
>>
>> Declaratives are Cobol's equivalent of COME FROM. Problem is, they
>> don't know where they came from, so they can't describe the error in
>> detail.
>
> Sure they can: it takes some coding effort, though.  Just set up WS
> variables  FILE-NAME, WHERE-IN-PROGRAM, and FUNCTION, and fill them
> properly before performing any I-O.  Then the Declarative can display
> messages or make decisions based on what it's given.  I've been doing it
> for years.
>
> PL 


0
wmklein (2605)
9/3/2004 2:09:34 AM
"William M. Klein" wrote:
> 
> If anyone doesn't know how to tell "where they came from" in a DEBUGGING
> DECLARATIVE, check out the "Debug-item" special register.  See (for example):
> 
>  http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr20/1.3.8.2
> 
> When/if you ever have a 2002 conforming compiler (and use "exception"
> declaratives) check out the following (new) intrinsic functions:
> 
> EXCEPTION-FILE                 Information about the file exception that raised
> an exception
> 
> EXCEPTION-FILE-N             (National) Information about the file exception
> that raised an exception
> 
> EXCEPTION-LOCATION      Implementor-defined location of statement causing an
> exception
> 
> EXCEPTION-LOCATION-N  (National) Implementor-defined location of statement
> causing an exception
> 
> EXCEPTION-STATEMENT Name of statement causing an exception
> 
> EXCEPTION-STATUS         Exception-name identifying last exception
> 
> --
> Bill Klein
> 

As Arte Johnson would say: "Verrry interesting".  I'd be interested to
see the implementation of EXCEPTION-LOCATION.

PL
0
lacey (134)
9/3/2004 2:46:17 AM
"Howard Brazee" <howard@brazee.net> wrote in message
news:ch80hq$t3i$1@peabody.colorado.edu...
>
> On  2-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> > In 1969 -- and well into the 1980's, at least -- people were *still*
using
> > punch cards as input not only to application programs but to
compilers -- 
> > either as source patches or as entire source files.  The programmer who
> > didn't put sequence numbers in his source card decks was risking
> > catastrophe!   It was a Big Deal for a user site I worked for when we
were
> > able to nstall our very first data communications network, went to
> > line-at-a-time source editing using (gasp!) terminals and got rid of our
> > keypunches in 1977!   Certainly the distinction between Margin L and
Margin
> > C was important to *that* site!
>
> Sure.   I remember using the card sorter to put my deck back in order.
But I
> never needed both sets of sequence numbers to do so.  One was sufficient.

    I never used copy statements back when I worked with punch cards
(college class),
but I can easily imagine having a library of copy members punched on cards.
As such,
their sequence numbers would not fit into the main program.  If you put the
name of the
copy in cols 73-80, you could filter the sack full of cards into individual
decks before
sorting them.

    Those card sorters were amazingly fast, considering they worked with
physical
cards.


0
rws0203 (21)
9/3/2004 4:20:44 AM
Peter Lacey wrote:

>"William M. Klein" wrote:
>  
>
>>If anyone doesn't know how to tell "where they came from" in a DEBUGGING
>>DECLARATIVE, check out the "Debug-item" special register.  See (for example):
>>
>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr20/1.3.8.2
>>
>>When/if you ever have a 2002 conforming compiler (and use "exception"
>>declaratives) check out the following (new) intrinsic functions:
>>
>>EXCEPTION-FILE                 Information about the file exception that raised
>>an exception
>>
>>EXCEPTION-FILE-N             (National) Information about the file exception
>>that raised an exception
>>
>>EXCEPTION-LOCATION      Implementor-defined location of statement causing an
>>exception
>>
>>EXCEPTION-LOCATION-N  (National) Implementor-defined location of statement
>>causing an exception
>>
>>EXCEPTION-STATEMENT Name of statement causing an exception
>>
>>EXCEPTION-STATUS         Exception-name identifying last exception
>>
>>--
>>Bill Klein
>>
>>    
>>
>
>As Arte Johnson would say: "Verrry interesting".  I'd be interested to
>see the implementation of EXCEPTION-LOCATION.
>
>PL
>  
>
Peter,

So would I - but more specifically EC-conditions in general. I assume 
you are still using Visual Age. The OCTG defined the general outline of 
the COBOL OO structure about '93. As one of the first three, (Hitachi,  
IBM and  Micro Focus),  IBM Visual Age syntax must be pretty close to 
final 2002 format. Did IBM have an Exception Handler class ?

I note from your other message you said "the get back info" can be coded 
*with effort* - but the 'get back info' you are referring to is not my 
point. Three ways currently to write a COBOL program :-

1 - Procedural
2 - Procedural invoking OO support where necessary (Robert did this 
using Collection classes, and you see it in examples illustrating 
features like getting at OLEs - demo-wise it makes it clear).
3 - a Procedural Trigger program - the remainder *completely* OO classes 
- which is what I use

#1 and #2 - if you *like* the Declaratives approach - onerous, but 
that's a way to pick up on errors.

# 3 - an ABSOLUTE SOD ! Because my error may occur in a Class 5, 6 or 7 
steps removed from Class 1 which started the action (Business Class).  
I've raised this one before - and it was 'Grinder' with a Pascal 
background who mentioned :-

{try...

catch}

a feature now available to Fujitsu users in dot Net ( via Version 7) and 
Micro Focus users via N/E Version 4.0.. Not sure of the implications of 
the above syntax - but stated simply, if I hit an error condition in 
Class 7 which means I should terminate the module, (e.g. Payroll 
calculations), but NOT abort the application - but go back to the menu 
and use other modules which still work - how the hell can I get Class 7 
to signal back to Class 1..

Not here, but if you have any code that illustrates anything similar - 
I'd appreciate if you could send me some -  and drop the second "J" in 
the e-mail address.

Jimmy, Calgary AB
0
jjgavan (507)
9/3/2004 6:19:36 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> Declaratives are Cobol's equivalent of COME FROM. 

There is actually no such thing as a 'come from', that is prely a joke.
They are, as someone else said, the exact equivalent of an 'ON ERROR'.

> Problem is, they don't know where they came from,

Of course they do, they can go back to where that was just like a PERFORM can.

> so they can't describe the error in detail.

No more nor no less than, say, a PERFORMed procedure can.
0
riplin (4127)
9/3/2004 6:34:06 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> >>Forget SECTIONs. They've always been unnecessary.
> 
> If you MUST do memory management, dynamic CALL/CANCEL is better.

Your original stated 'always'.  Dynamic CALL/CANCEL has not _always_ been available.
0
riplin (4127)
9/3/2004 6:40:59 AM
"James J. Gavan" <jjgavan@shaw.ca> wrote:

>Jeff York wrote:
>
>>"Howard Brazee" <howard@brazee.net> wrote:
>>
>>  
>>
>>>On  2-Sep-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:
>>>
>>>    
>>>
>>>>Inventing it back then: most certainly include the in-line performs
>>>>(perform ...end-perform) and end-if; but I'd have to leave space
>>>>somewhere on the form for sequence numbers because we were using card
>>>>decks!
>>>>      
>>>>
>>>But why do we need space for sequence numbers in 73-80 as well as 1-6?   I've
>>>sorted cards both ways.
>>>    
>>>
>>
>><Zummmerzet accent>
>>
>>When I were just a young laad..  We used to put the program ID in
>>73-80 as well as the sequence in 1-6.  That way, if/when one of the
>>ops dropped a tray of cards it was possible to sort them back into
>>correctly-sequenced individual programs..  :-)
>>
>></Zummerzet accent>
>>
>>  
>>
>Your Somerset shire bit hits the nail on the head. Started in systems on 
>an ICT 1500 at Trowbridge, (we were using Machine Code and mainly FAS 
>(1500 Assembler)).  All paper tape. Moved to Debenhams  in Taunton, ICL 
>1900 series where we initially still used paper tape. But already geared 
>to going to COBOL as the standard we did exactly as you did with the 
>paper tape, reference 1-6 and 73-80; (The identification helped when 
>splitting paper-tape and splicing in a correction).

Blimey!  You must be even older than me!  I first programmed in
machine code and Fortran at uni, then my first "proper job" was at
Evode in Stafford, initially on a Univac 1004 (A plugged-program
machine!) followed by a "real computer" - an ICL 1901A which used
COBOL.  The Univac was card input, card and print output. The program
board was about 2 feet square and fully-wired weighed about 40 pounds
so it took a degree of physical strength as it loaded at chest-height
and you had to be delicate otherwise it would knock some of the plugs
loose. It was a hanging-offence should anyone actually drop one!

<>

>That was a bloody feeble attempt at Zummerzet from a Shrop-SHAIRE lad ! 

T-t-terribly sorry old chap!  :-)   Oy  thort loyke iffn oy daint ger
backter summat loyke ingliish, no bugger ud understaand me.   :-)

>Went back in 2000 and visited Yeovil and Taunton - sadly just 'townie' 
>accents, somewhat 'Estuary English' (London). Noww iff oid garn upt ter 
>Dunkery Beacon to voo the Welsh Coast on a dursant day, quate liklee I 
>wouldda 'ad sum werds wiv folks wat zounded loike the charaketers from 
>Blackmore's "Larna Duuune" (Lorna Doone).  :-)

It's all television's fault..  :-)  Accents are becoming flattened -
it's so bad that one can return to the town of one's birth (Wednesbury
in the heart of the "black country") and actually hear persons whom
one can understand..  :-)

-- 
Jeff.         Ironbridge,  Shrops,  U.K.
jjy@jakfield.xu-netx.com  (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)

.... "There are few hours in life more agreeable
      than the hour dedicated to the ceremony
      known as afternoon tea.."

         Henry James,  (1843 - 1916).

 
0
ralf4 (132)
9/3/2004 9:01:36 AM
On Thu, 2 Sep 2004 15:28:48 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:3u2fj01k5p28pca6imktrckrd1ulp1mbml@4ax.com...
>
>> If you MUST do memory management, dynamic CALL/CANCEL is better.

>I don't disagree that "modularity" is a virtue, and I happen to agree that
>IPC (even as implemented according to '74 standards) is a really good way to
>accomplish modularity, but I'm not convinced that the problems of memory
>management are best solved by *procedural* modularity, particularly when the
>system already does a pretty good job of handling object code, without any
>involvement by the user at all, the overwhelming majority of the time.

Segments are a case of procedural modularity. Only procedural code is
pageable. With dynamic calls, working-storage belonging to the
'segment'  is pageable as well. 

>Personally, I think "nested programs" is a Good Thing.  I just don't like
>where the '85 standard put them.  I would personally have preferred that
>the nested programs be located before any executable code in the PROCEDURE
>DIVISION of the parent rather than after it.

That separates the main procedure division from its data division. If
programs were nested say 2 layers deep, program 3 would similarly
separate program 2 into two pieces.

People would be editing the main program's procedure division, hit
Page Up to see its data division, and be looking at an unrelated
program's data division. They would say nested programs are too
confusing.

I like small programs having  'locality of reference' for ease of text
editing. If one is accustomed to working on very large programs,
that's not a concern .. there are always two editor windows open.

>While I'm on the subject of '85 CALL enhancements, I would have preferred
>the BY VALUE/BY REFERENCE distinction be part of the "signature" of the
>"callee" rather than the sole responsibility of the "caller".

If you use prototypes, it is controlled by the callee.

0
robert6624 (636)
9/3/2004 11:43:49 AM
On Thu, 2 Sep 2004 15:10:26 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:042fj0ls9pu3je725nbdmkm45pths5csfr@4ax.com...
>
>> We can say:
>>
>> 05  pic 9 value 0.
>>      88 end-of-file value 1 false 0.
>>
>> And we can say:
>>
>>     set end-of-file to false
>>
>> But we cannot say:
>>
>> 05  pic 9 value not end-of-file.
>>      88  end-of-file value 1 false 0.
>>
>> We have to code the value 0 in two places. Someone might change one
>> and overlook the other.
>>
>> If it's indirect in the procedure division, why isn't it indirect in
>> the data division as well?
>
>I think that compromises the utility and clarity of the multivalued case for
>TRUE.  You could equally well have coded
>    05  pic 9 value not end-of-file.
>        88  end-of-file values 1 thru 9 false 0.
>
>This is unambiguous as written, but what if it read "05 pic 9 value
>end-of-file."?

It should do the same thing 'set end-of-file to true' does.  It uses
the first value. Why is ambiguity objectionable in the data division,
but the exact same ambiguity is not a concern in the procedure
division?

>I'm also not convinced that it adds significant utility.  I'm also not sure
>what "it" is that you are claiming needs to be "indirect".

"It" is the value representing a condition. Indirection means
'referred to by name rather than literal value'.

Another idea. Suppose the initial value will be set with INITIALIZE
(with option to initialize fillers). It would be nice if we could
write:

05 pic 9 value INITIAL.
   88 end-of-file value 1 false INITIAL. 

With that, if someone changes the pic to X, the false value will
automatically change from zero to space. 
0
robert6624 (636)
9/3/2004 11:43:50 AM
On Thu, 2 Sep 2004 17:46:49 -0500, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Do add to Chuck's comment, there is a common "misconception" that the CANCEL 
>statement *must* free storage.  Not only does the Standard not require this, 
>there are a number of implementations that don't do it.  The only thing that the 
>CANCEL statement is required to do is to insure that the next time the CANCELed 
>program is called, it is in initial - not last-used - state.

In the days of memory-starved machines, every system I worked on did
free memory.

They don't free memory today because of the way multi-tasking
operating systems manage shared resources (dll and so). Suppose there
are three tasks -- A, B and C -- calling program P. The operating
system has but one copy of P's procedure division in memory, and three
instances of its data division. When A says it's finished with P, the
operating system could reasonably free one data division but not the
procedure division. It still has two users. The procedure division
shouldn't be freed until its User Count goes to zero. 
0
robert6624 (636)
9/3/2004 11:43:50 AM
On Thu, 2 Sep 2004 14:43:29 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:4s2fj0dubd28r06p92bcvnrmg9jsurin6b@4ax.com...
>
>> Get rid of precedence rules. Require that logical and arithmetic
>> statements  use parentheses on statements containing more than one
>> level.
>
>I actually agree with Robert here in at least part of this:  I think
>abbreviated combined relation conditions in particular are a delusion and a
>snare.    The big problem with them is that it is at first glance
>*reasonable* but ultimately *erroneous* that abbreviation implies some sort
>of association not otherwise implied by the precedence rules (or the
>parentheses).

That's why I suggested not allowing ACRC to travel through parentheses
-- so people wouldn't make that mistake, become frustrated and ban
ACRC.

> COBOL's arithmetic precedence rules don't bother me that much; they seem to
>match Fortran, ALGOL, Pascal and PL/I at least, so someone coming from those
>languages shouldn't be terribly confused.

The reason for AND/OR precedence is not obvious to people who don't
think in logical algebra. They have enough trouble with logic;
precedence just adds to the confusion. 

The reason is that AND is logical multiplication, OR is logical
addition.

>> Require a warning on logical statements always true or false. For
>> example:
>
>> if a not = 1 or 2
>> if a = b or c or a
>
>Many implementors do this; it's not clear to me that it's the *standard's*
>job to tell the *implementor* how to keep the *programmer* from shooting
>himself in the foot in every case.  I believe the standard specifies a
>mechanism for flagging *standards violations*, but not one for *advisories*
>along the lines of "Are you sure that's what you meant?" (or even for the
>method of presentation of syntax *errors*, except that object code shouldn't
>be produced when they occur).  

If the objective is a language that's robust, portable and
predictable, seems to me that Standard Warnings would help Cobol
toward that ideal.

Ok, make it a fatal error. They're telling the compiler to do
something illogical -- generate code that will never be executed. 

While we're on the topic, this should be an error also:

05  foo pic 9(4).
perform varying foo from 1 by 1 until foo > 10000

The condition will always be false.

> It may actually be a useful technique for
>*incorporating* prototype code into *production* programs before testing is
>complete; I've found it useful to "stub" large blocks of code that way -- or
>even with "IF <enabling-condition> AND FALSE THEN ..." , where all I have to
>do is delete the "AND FALSE" to open up the new logic, in my time.

I do that too. Make an exception for TRUE and FALSE.
0
robert6624 (636)
9/3/2004 11:43:51 AM
..    Am  03.09.04
schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
    auf  /COMP/LANG/COBOL
     in  kajgj0lk8r0hgcs9eqj8u2lea41r0nit5k@4ax.com
  ueber  Re: If you were inventing CoBOL...

RW> While we're on the topic, this should be an error also:
RW>
RW> 05  foo pic 9(4).
RW> perform varying foo from 1 by 1 until foo > 10000
RW>
RW> The condition will always be false.

   A similar thing happened on the first flight of Ariane 5.


   That was a very costly programming error, although in all  
probability not using COBOL.


Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Das Volk, das ein anderes Volk unterjocht, schmiedet seine eigenen
Ketten."                         - Karl Marx           (1. Januar 1870)
0
l.willms1 (637)
9/3/2004 1:08:00 PM
On Fri, 03 Sep 2004 01:55:28 GMT, Warren Simmons
<wsimmons5@optonline.net> wrote:

>Robert Wagner wrote:
>> On 02 Sep 2004 19:52:00 GMT, l.willms@jpberlin.de (Lueko Willms)
>> wrote:
>> 
>> 
>>>.    Am  02.09.04
>>>schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
>>>   auf  /COMP/LANG/COBOL
>>>    in  eebej0hjvt5qt0ld6mjl3anl369st8o1ip@4ax.com
>>> ueber  Re: If you were inventing CoBOL...
>>>
>>>RW> Forget SECTIONs. They've always been unnecessary.
>>>
>>>you can't do without SECTIONs when you are using  
>>>DECLARATIVEs, COBOLs equivalent to ON ERROR GOTO.
>> 
>> 
>> Declaratives are Cobol's equivalent of COME FROM. Problem is, they
>> don't know where they came from, so they can't describe the error in
>> detail. 
>> 
>> 
>Come from.....
>
>Perform did a branch and return. Doesn't that count?

It's true that the return address could be fished out of the stack,
but it only counts IN COBOL if the compiler-generated code (or
runtime) does it for you. The return address would then have to be
related to a line number and/or paragraph name, and other means used
to figure out which file threw the error.

The new EC- values Bill Klein posted appear to be doing just that.
When we get the new  feature(s), declaratives will have reasonable
support FROM COBOL. Note, however, they require debugging information.
That could be a problem in older shops, where rules prohibit debugging
information in production.  
0
robert6624 (636)
9/3/2004 1:21:36 PM
On  2-Sep-2004, "JerryMouse" <nospam@bisusa.com> wrote:

> > In 1969 -- and well into the 1980's, at least -- people were *still*
> > using punch cards as input not only to application programs ....
>
> How about the 2000 election (and 2004 in some places)?

Punched cards offer a sold, auditable trace that is very hard to hack.    I'm
against changing it to touch-screen and the like.
0
howard (6283)
9/3/2004 3:03:42 PM
On  2-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> That doesn't mean the techniques could reasonably be applied before they
> were invented.  I don't think GO TO in  COBOL is inherently evil any more
> than the branch instructions on the 1401 were.

Still, if CoBOL was invented that the only way to get to a paragraph was to
perform it, coders back then wouldn't have had any problem writing code.


> And structured programming was a concept that wasn't "always" around.

They wouldn't have needed such a concept so much with that change.
0
howard (6283)
9/3/2004 3:06:49 PM
On  2-Sep-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

>    Besides that in my style, I always divided up my programs in
> SECTIONs (having one single paragraph called ANFANG, i.e. German for
> "BEGIN"), you can't do without SECTIONs when you are using
> DECLARATIVEs, COBOLs equivalent to ON ERROR GOTO.

Declaratives are something that could have been designed differently.

And certainly, if SORT can remove the requirement that it runs sections, so
could declaratives.
0
howard (6283)
9/3/2004 3:08:43 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:d2lgj0tsrs9tu0tqkkk3dp9n3u5fr4fsn6@4ax.com...
> Segments are a case of procedural modularity.

OK, but so are called programs.

> Only procedural code is pageable.

*WHAT?*   Please support the universality of this statement!

> With dynamic calls, working-storage belonging to the
> 'segment'  is pageable as well.

Working-storage belonging to the called program is "pageable" in exactly the
same way as any other storage in COBOL or any other language.  The Burroughs
B5000 was "paging" working-storage over 40 years ago, and its descendants do
so today.


> That separates the main procedure division from its data division. If
> programs were nested say 2 layers deep, program 3 would similarly
> separate program 2 into two pieces.

Just as has been done in ALGOL and Pascal and related languages, and as was
done a very long time before COBOL decided it had a better idea!

> People would be editing the main program's procedure division, hit
> Page Up to see its data division, and be looking at an unrelated
> program's data division.

That sounds like a problem for the editor, not a problem for the compiler.

> They would say nested programs are too confusing.

Yeah, that's why nobody ever wrote anything in ALGOL or Pascal.

> I like small programs having  'locality of reference' for ease of text
> editing. If one is accustomed to working on very large programs,
> that's not a concern .. there are always two editor windows open.

I understand that; in fact, I think "nested programs" in COBOL are stolen
philosophically from "procedures" in ALGOL and Pascal; the big difference I
see is that "procedures" in those languages are always "INITIAL" in COBOL
terms.  But aside from that I think there are more similarities than
differences.

> If you use prototypes, it is controlled by the callee.

OK; I was actually thinking in terms of '85 COBOL semantics and code
compatible with it.  I've never understood the particular utility of calling
a program one time with a parameter BY REFERENCE and the next time BY VALUE,
particularly because in our environment what other languages term "by value"
(only allowed for single- or double-word values) is significantly more
efficient than "by reference" or "by name"; the reverse is usually true in
our COBOL85, so the behavior in that language is counterintuitive for the
seasoned MCP user.

    -Chuck Stevens


0
9/3/2004 3:41:43 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:kajgj0lk8r0hgcs9eqj8u2lea41r0nit5k@4ax.com...


> If the objective is a language that's robust, portable and
> predictable, seems to me that Standard Warnings would help Cobol
> toward that ideal.

Then the presence of Standard Warnings, and a list of things every
implementor should be required to warn about, is the underlying idea.  I'd
suggest you write a proposal that it be added to the candidates list,
together with a *list* of warnings you think ought to be included.

> Ok, make it a fatal error. They're telling the compiler to do
> something illogical -- generate code that will never be executed.

As I mentioned before, I oppose the idea of having the standard *prevent*
the "stubbing" of code.

> While we're on the topic, this should be an error also:
>
> 05  foo pic 9(4).
> perform varying foo from 1 by 1 until foo > 10000
>

I don't think *standard* COBOL should differentiate between the above and
    05  foo pic 9(4)
    05  blivet pic 9.
    05  whoosis pic 9.
    05  whatsis pic 9(5).
    move 1 to blivet whoosis move 10000 to whatsis.
    perform varying foo from blivet by whoosis until foo > whatsis.
Nor do I believe the *standard* should encourage such a differentiation.

> The condition will always be false.

Only because all the arguments are literals.  The condition might always be
false anyway, even if the PERFORM control items are variables.

> I do that too. Make an exception for TRUE and FALSE.

They don't currently exist in the conditional-expression syntax to begin
with.  Proposing such -- e.g. that the keywords TRUE or FALSE may be used
anywhere a <boolean-expression> may be used -- would certainly be another
reasonable addition to the "candidates list".  .

    -Chuck Stevens


0
9/3/2004 3:54:15 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:cha1dr$q67$1@peabody.colorado.edu...

> And certainly, if SORT can remove the requirement that it runs sections,
so
> could declaratives.

Take it from me, the removal of that requirement caused some implementors
quite a few headaches!  Things were much simpler when you could determine at
*compile time* whether a RELEASE or RETURN statement was within the confines
of a SORT input or output procedure!

    -Chuck Stevens


0
9/3/2004 3:57:23 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:btjgj09sa8iedc4m2gnjns4st9rfe8m4do@4ax.com...

> "It" is the value representing a condition. Indirection means
> 'referred to by name rather than literal value'.

And you can't do this with "CONSTANT" today?

If there are already fourteen approved ways to skin a cat, it's not clear
that we need to standardize a fifteenth!

> Another idea. Suppose the initial value will be set with INITIALIZE
> (with option to initialize fillers). It would be nice if we could
> write:
>
> 05 pic 9 value INITIAL.
>    88 end-of-file value 1 false INITIAL.
>
> With that, if someone changes the pic to X, the false value will
> automatically change from zero to space.

Or a sixteenth!

If the user changes an item from PIC 9 to PIC X, I'd think the user would
want to, and should, examine every reference to it to make sure that the
change didn't break anything.  I believe standardizing "The value is ...
well ... whatever" would not be met with much enthusiasm.

And it took the author of the (now-approved) proposal for Structured
Constants in the 2008 draft (see
http://www.cobolportal.com/j4/files/04-0056.doc ) a fair amount of effort to
convince J4 that the content of a Structured Constant should be, at the
beginning of execution, as if a statement of the form "INITIALIZE ... WITH
FILLER ALL TO VALUE" had been executed against it before execution begins.
The idea of having the effects of INITIALIZE "bleed over" into compile-time
was of some concern, and I think doing that in this case would be a hard
sell.

    -Chuck Stevens


0
9/3/2004 4:26:25 PM
On Fri, 3 Sep 2004 08:41:43 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:d2lgj0tsrs9tu0tqkkk3dp9n3u5fr4fsn6@4ax.com...
>> Segments are a case of procedural modularity.
>
>OK, but so are called programs.
>
>> Only procedural code is pageable.
>
>*WHAT?*   Please support the universality of this statement!

I didn't express the point clearly enough. Second try:

If the program manages memory with priority numbers on segments, the
size of shared memory is the size of procedural code.

If the program  manages memory with CALL/CANCEL, the size of shared
memory is larger because the size of some working-storage can be freed
as well.


>> With dynamic calls, working-storage belonging to the
>> 'segment'  is pageable as well.
>
>Working-storage belonging to the called program is "pageable" in exactly the
>same way as any other storage in COBOL or any other language.  The Burroughs
>B5000 was "paging" working-storage over 40 years ago, and its descendants do
>so today.

I should have said freeable rather than pageable. The machines we're
discussing didn't have virtual memory. If they had, there would have
been no need for the programmer to manage memory.

>> That separates the main procedure division from its data division. If
>> programs were nested say 2 layers deep, program 3 would similarly
>> separate program 2 into two pieces.
>
>Just as has been done in ALGOL and Pascal and related languages, and as was
>done a very long time before COBOL decided it had a better idea!

C is the same. The reason has nothing to do with structure or
philosophy, it's more mundane. The compiler needs to type-check
parameters on the call. There are three ways that could be done:

a. Two passes in the compiler front-end. 
      Too slow.
b. Prototypes at the top.
      Too verbose.
c. Require the callee to be seen before the caller.
      The solution they used.

Because Cobol doesn't require type-checking, the better idea was to
put the called program where it logically belongs.

>> I like small programs having  'locality of reference' for ease of text
>> editing. If one is accustomed to working on very large programs,
>> that's not a concern .. there are always two editor windows open.
>
>I understand that; in fact, I think "nested programs" in COBOL are stolen
>philosophically from "procedures" in ALGOL and Pascal; the big difference I
>see is that "procedures" in those languages are always "INITIAL" in COBOL
>terms.  But aside from that I think there are more similarities than
>differences.

A major difference is data visability. Pascal makes everything in the
equivalent of working-storage global. Parameters? We don't got to pass
no stiinking parameters! Just reach into the pot and help yourself. 

Cobol has been criticized for having 'an ocean of global data' since
the beginning. That's WHY nested programs were created. 

As for inheritance, I'd say ALGOL got the idea from Fortran's 'blank
common'.

> I've never understood the particular utility of calling
>a program one time with a parameter BY REFERENCE and the next time BY VALUE,

That's not utility, that's an error.

Some day, the solution will be typecasting via  introspection. The
compiler will peek into the callee to see what it wants, then cast the
call to match. 

>particularly because in our environment what other languages term "by value"
>(only allowed for single- or double-word values) is significantly more
>efficient than "by reference" or "by name"; the reverse is usually true in
>our COBOL85, so the behavior in that language is counterintuitive for the
>seasoned MCP user.

To a seasoned Intel assembly programmer, it seems intuitive that a
single instruction, memory-to-memory move is the fastest way to copy a
string. It used to be. Now it's faster to tediously load and store a
word at a time.

We have compilers between us and the machine to automate optimizations
like this. In case you cited, if all targets were nested, a smart
compiler could disregard what the programmer wrote and optimize the
parameter type automatically. If targets were external, a 'full make'
would be required to optimize. 

I don't think programmers should have to hold the machine's hand like
we used to. Stuff like this should be automated.

0
robert6624 (636)
9/3/2004 6:06:32 PM
On Fri, 3 Sep 2004 15:03:42 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>On  2-Sep-2004, "JerryMouse" <nospam@bisusa.com> wrote:
>
>> > In 1969 -- and well into the 1980's, at least -- people were *still*
>> > using punch cards as input not only to application programs ....
>>
>> How about the 2000 election (and 2004 in some places)?
>
>Punched cards offer a sold, auditable trace that is very hard to hack.    I'm
>against changing it to touch-screen and the like.

First 'Hanging Chad' Case Heads to Trial
Federal suit seeks to decertify punch-card ballots, upgrade system

Dee McAree
The National Law Journal
07-26-2004


Four years ago, the "hanging chad" became part of the country's
lexicon during the Florida recount in the Bush versus Gore
presidential election. 

This week, the first case to litigate the constitutionality of
punch-card voting is scheduled to commence in federal court in Ohio. 

[snip]
The lawsuit contends that Ohio voting system inconsistencies violate
the equal protection clause of the 14th Amendment and the Voting
Rights Act of 1965. The suit seeks a court order requiring the Ohio
secretary of state to decertify the punch-card ballot. They want to
invalidate the system to put pressure on state officials to come up
with a voting method with an equal statistical error rate for all
voters. 

[snip]
Of the 88 counties in Ohio, about 69 use punch-card voting, Saphire
said. Some of the more affluent counties have upgraded to newer
touch-screen technology that has a lower error rate. Therefore,
minorities who live in the less affluent neighborhoods are more likely
to have their votes rejected, allege the plaintiffs' lawyers. 

The ACLU's research of the last presidential election found that the
rejected ballots in an Ohio county that used punch cards amounted to
six times higher than a county that used touch-screen technology. A
total of 93,000 Ohio voters had their votes rejected. In some minority
neighborhoods near Akron, the rejected rate reached 10 percent to 15
percent. 

[snip]
The plaintiffs' lawyers say the critical problem with punch-card
voting is that it does not allow a user to check his vote. There are
no safeguards to alert a voter who elects too few candidates or elects
too many.

http://www.law.com/jsp/article.jsp?id=1090180166667
0
robert6624 (636)
9/3/2004 6:06:33 PM
Jeff York wrote:

>Blimey!  You must be even older than me! 
>
That's for sure. Some here already know - but now I'm going to give it 
to you, but you have to  go googling if interested..
The song :-

You must remember this,
A kiss is just a kiss,
A sigh is just a sigh........

Was the rage and popularized in the movie, (film to you),  'Casablanca' 
starring Bogey and the then young and pretty Ingrid Bergman. However 
that song was written the year I was born  - go for it :-)

Jimmy


> I first programmed in
>machine code and Fortran at uni, then my first "proper job" was at
>Evode in Stafford, initially on a Univac 1004 (A plugged-program
>machine!) followed by a "real computer" - an ICL 1901A which used
>COBOL.  The Univac was card input, card and print output. The program
>board was about 2 feet square and fully-wired weighed about 40 pounds
>so it took a degree of physical strength as it loaded at chest-height
>and you had to be delicate otherwise it would knock some of the plugs
>loose. It was a hanging-offence should anyone actually drop one!
>
><>
>
>  
>
>>That was a bloody feeble attempt at Zummerzet from a Shrop-SHAIRE lad ! 
>>    
>>
>
>T-t-terribly sorry old chap!  :-)   Oy  thort loyke iffn oy daint ger
>backter summat loyke ingliish, no bugger ud understaand me.   :-)
>
>  
>
>>Went back in 2000 and visited Yeovil and Taunton - sadly just 'townie' 
>>accents, somewhat 'Estuary English' (London). Noww iff oid garn upt ter 
>>Dunkery Beacon to voo the Welsh Coast on a dursant day, quate liklee I 
>>wouldda 'ad sum werds wiv folks wat zounded loike the charaketers from 
>>Blackmore's "Larna Duuune" (Lorna Doone).  :-)
>>    
>>
>
>It's all television's fault..  :-)  Accents are becoming flattened -
>it's so bad that one can return to the town of one's birth (Wednesbury
>in the heart of the "black country") and actually hear persons whom
>one can understand..  :-)
>
>  
>
0
jjgavan (507)
9/3/2004 6:12:54 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:p68hj0p9f52si1kpsbs870up126ek6lfhh@4ax.com...
> On Fri, 3 Sep 2004 08:41:43 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
> >"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> >news:d2lgj0tsrs9tu0tqkkk3dp9n3u5fr4fsn6@4ax.com...
> >> Segments are a case of procedural modularity.
> >
> >OK, but so are called programs.
> >
> >> Only procedural code is pageable.
> >
> >*WHAT?*   Please support the universality of this statement!
>
> I didn't express the point clearly enough. Second try:
>
> If the program manages memory with priority numbers on segments, the
> size of shared memory is the size of procedural code.

Ummm ... no .... that is not a Universal Truth ...

Going by ANSI X3.23-1974 syntax, where the "Segmentation Module" is not yet
marked as obsolete:

I've heard of *segment numbers*, and I've heard of the segment-limit clause
which may impact the way SECTIONs with various segment-numbers are handled,
with respect to how they're treated.  For example, "The fixed portion [of
the procedural code for the program] is that part of the program which is
*logically treated as if it were always in memory*" [emphasis added].

The implementor is *not* obligated to ensure that all portions of the "fixed
portion" is indeed unconditionally and always in memory during the execution
of the program, only that the actions *of the program* are indistinguishable
from that behavior.

The implementor is *not* obligated to ensure that two SECTIONs with the same
"segment number" are phyically or logically associated with one another in
memory, only that the actions of the program are indistinguishable from that
which would obtain with such a physical or logical association.

Moreover, there is no requirement on the part of an implementor to ensure
that two copies of the same program share *any* part of their memory, much
less a specific portion of it.  Some implementors choose to do so -- on
Unisys MCP systems a single instance of the object code file on disk is
"managed" by the operating system for all executors of it, and "manages" the
determination of which code segments are in memory based on how they are
used -- the ALTER behavior impacted by section-numbers is managed in the
individual "data spaces".

The *program* is not managing the memory, as I see it; the *operating
environment* is managing the memory using the segment-number of the various
SECTIONs and the SEGMENT-LIMIT clause as *guidelines* in that process.

It is precisely because *all* of this is really an implementation detail,
and because the *specifics* of fixed-versus-overlayable in various
implementations are really none of the standard committee's business, that
led to the Segmentation Module being marked as obsolete in 1985 and to its
elimination from the standard in 2002.  The SECTION header remains, but
ALTER, segment-numbers and the SEGMENT-LIMIT clause are gone.

> If the program  manages memory with CALL/CANCEL, the size of shared
> memory is larger because the size of some working-storage can be freed
> as well.

It is not the program that is managing the memory in the first place, it is
the operating environment.  IN an environment in which program initiation
and termination are costly and in which the operating environment does a
really good job of memory management in the first place, CALL/CANCEL may be
a *much* less efficient approach than what you propose   Who says all of
WORKING-STORAGE *has to be* in a monolithic block that is unconditionally
resident for the life of the program?

> I should have said freeable rather than pageable. The machines we're
> discussing didn't have virtual memory. If they had, there would have
> been no need for the programmer to manage memory.

What machines were *we* discussing?  As far as I'm concerned, *we* were
discussing what COBOL *ought to do* and what features COBOL *ought to
provide* and why.

> C is the same. The reason has nothing to do with structure or
> philosophy, it's more mundane. The compiler needs to type-check
> parameters on the call. There are three ways that could be done:
>
> a. Two passes in the compiler front-end.
>       Too slow.

I know of a two-pass COBOL compiler that is *triple* the speed of its
one-pass counterpart.  Show me how slow a two-pass compiler always is
compared to a one-pass compiler.  I've also known *six-pass* COBOL compilers
that weren't speed demons *during compilation*, but that generated
blindingly-fast object code.  And what's *the* compiler front-end?

> b. Prototypes at the top.
>       Too verbose.

also requires prototypes.  This is similar to ALGOL's FORWARD I think.

> c. Require the callee to be seen before the caller.
>       The solution they used.

The solution ALGOL, Pascal, PL/I, etc., used, which I personally prefer.

> Because Cobol doesn't require type-checking, the better idea was to
> put the called program where it logically belongs.

It's not clear to me that the "because" is true, nor is it clear to me that
"logically belongs" has been established.

> A major difference is data visability. Pascal makes everything in the
> equivalent of working-storage global.

Sort of, and Pascal is very much like its ancestor in this respect.  The
philosophy there is that data *at a given level* isn't visible at a higher
level in the program, but you can see the data for all higher levels of the
program from wherever you are.  I agree that COBOL's explicit declaration of
what data in the parent level you can and can't see at the child level can
be seen as an improvement.

> Parameters? We don't got to pass
> no stiinking parameters! Just reach into the pot and help yourself.

You don't have to pass "shared data" in COBOL as parameters, you can always
make it global and thus access by anyone beneath is welcome if that's what
you want.

> Cobol has been criticized for having 'an ocean of global data' since
> the beginning. That's WHY nested programs were created.

Yes, but I'd say the "global" issue is a refinement on that.  Nested
programs allows the data that is accessed or used only by a given set of
logic to be associated with that logic and thus removed from the "outer
block".   And if you're *really* modularizing, how much "local" data does
the "outer block" of a COBOL program in which all its real work is done in
"nested" programs really need?

> As for inheritance, I'd say ALGOL got the idea from Fortran's 'blank
> common'.

Could be, but I think the ALGOL approach is rather more powerful and
sophisticated.

> > I've never understood the particular utility of calling
> >a program one time with a parameter BY REFERENCE and the next time BY
VALUE,
>
> That's not utility, that's an error.

No, it's *explicitly* allowed by COBOL, and I believe the justification is
that one time you might *not* want to allow the callee to modify the data,
but the next time you *might*, and the standards folks didn't want to
preclude people from writing programs that did that.  I wasn't there when
this decision was made, and had I been I'd almost certainly have argued
*strenuously* against it, but I have heard hints that at least one
implementor thought *copying* the data should be obligatory for BY VALUE,
and that's the way it is.

> Some day, the solution will be typecasting via  introspection. The
> compiler will peek into the callee to see what it wants, then cast the
> call to match.

Not sure what you mean by this, but I think having the compiler do "Well, I
know what you *wrote*, but I've decided what you really *meant* was ..." is
a REALLY bad idea.

> To a seasoned Intel assembly programmer, it seems intuitive that a
> single instruction, memory-to-memory move is the fastest way to copy a
> string. It used to be. Now it's faster to tediously load and store a
> word at a time.

That's actually one of the big differences:  COBOL allows just about
anything to be passed BY VALUE; the procedural languages didn't.

> We have compilers between us and the machine to automate optimizations
> like this. In case you cited, if all targets were nested, a smart
> compiler could disregard what the programmer wrote

NO.  Can't do that unless it can be guaran-dam-teed that the results are
*unconditionally identical*.

> and optimize the
> parameter type automatically. If targets were external, a 'full make'
> would be required to optimize.

> I don't think programmers should have to hold the machine's hand like
> we used to. Stuff like this should be automated.

Some of it can, some of it is.  The *standard* specifies how it should
*behave*; it isn't the *standard*'s job to make sure the implementor does it
efficiently, it's the *implementation's*.

    -Chuck Stevens


0
9/3/2004 8:10:35 PM
On Fri, 3 Sep 2004 08:54:15 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:kajgj0lk8r0hgcs9eqj8u2lea41r0nit5k@4ax.com...
>
>
>> If the objective is a language that's robust, portable and
>> predictable, seems to me that Standard Warnings would help Cobol
>> toward that ideal.
>
>Then the presence of Standard Warnings, and a list of things every
>implementor should be required to warn about, is the underlying idea.  I'd
>suggest you write a proposal that it be added to the candidates list,
>together with a *list* of warnings you think ought to be included.

How to compile such a list:
... Start with messages issued by a 2002 compiler 
      Do-able
... Delete messages related to non-standard extensions
      Requires expert knowledge of 2002 & 2008 standards
      I'm not that expert
... Delete messages not important enough to make the cut
      Do-able
... Add the one about condition always true/false
... Write rules about how to determine same
     All literals is easy. How about a variable that never changes?
     Never change must distinguish between call by reference/value.
     If the only call is to a nested program that doesn't change it
     and doesn't call outside by reference, it didn't change.
    Watch  out for pass via GLOBAL.
    Watch out for EXTERNAL.
    Watch out for changes via REDEFINES and group names.
    Deal with ESQL references. How?

Finally, realize the warning will be issued only when the compiler is
in standard-compliant mode. Has anyone ever used that, outside the
lab?  Maybe some government project .. once .. a long time ago. 

On second thought, it's not worth the effort.

>> The condition will always be false.
>
>Only because all the arguments are literals.  The condition might always be
>false anyway, even if the PERFORM control items are variables.

See above.

>> I do that too. Make an exception for TRUE and FALSE.
>
>They don't currently exist in the conditional-expression syntax to begin
>with.  Proposing such -- e.g. that the keywords TRUE or FALSE may be used
>anywhere a <boolean-expression> may be used -- would certainly be another
>reasonable addition to the "candidates list".  .

I ASSumed it was supported for two reasons:
... I use them routinely in Micro Focus.
... Logic. Why would the standard create logical literals and then not
permit them in conditional expressions? That's illogical.

I refuse to write PERFORM UNTIL FALSE. It is common usage in other
languages as DO FOREVER and WHILE TRUE. It implies on an explicit exit
will be issued. Premature exits are for exceptions. The normal exit
condition should be expressible in loop control. 

0
robert6624 (636)
9/3/2004 11:11:31 PM
Just to "add" to this thread,  I think it would be nice if some future Standard 
actually *required* the compiler to produce a listing (which it doesn't and 
never has).  It would also be nice if it gave some clue how such a listing 
should handle COPY REPLACING/REPLACE statements - which are currently handled 
very differently by various compilers. (Some show before the replacement, some 
after)

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:h2rhj0laki7m79s47rtatijjm0prgcal3f@4ax.com...
>
> On Fri, 3 Sep 2004 08:54:15 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>>news:kajgj0lk8r0hgcs9eqj8u2lea41r0nit5k@4ax.com...
>>
>>
>>> If the objective is a language that's robust, portable and
>>> predictable, seems to me that Standard Warnings would help Cobol
>>> toward that ideal.
>>
>>Then the presence of Standard Warnings, and a list of things every
>>implementor should be required to warn about, is the underlying idea.  I'd
>>suggest you write a proposal that it be added to the candidates list,
>>together with a *list* of warnings you think ought to be included.
>
> How to compile such a list:
> .. Start with messages issued by a 2002 compiler
>      Do-able
> .. Delete messages related to non-standard extensions
>      Requires expert knowledge of 2002 & 2008 standards
>      I'm not that expert
> .. Delete messages not important enough to make the cut
>      Do-able
> .. Add the one about condition always true/false
> .. Write rules about how to determine same
>     All literals is easy. How about a variable that never changes?
>     Never change must distinguish between call by reference/value.
>     If the only call is to a nested program that doesn't change it
>     and doesn't call outside by reference, it didn't change.
>    Watch  out for pass via GLOBAL.
>    Watch out for EXTERNAL.
>    Watch out for changes via REDEFINES and group names.
>    Deal with ESQL references. How?
>
> Finally, realize the warning will be issued only when the compiler is
> in standard-compliant mode. Has anyone ever used that, outside the
> lab?  Maybe some government project .. once .. a long time ago.
>
> On second thought, it's not worth the effort.
>
>>> The condition will always be false.
>>
>>Only because all the arguments are literals.  The condition might always be
>>false anyway, even if the PERFORM control items are variables.
>
> See above.
>
>>> I do that too. Make an exception for TRUE and FALSE.
>>
>>They don't currently exist in the conditional-expression syntax to begin
>>with.  Proposing such -- e.g. that the keywords TRUE or FALSE may be used
>>anywhere a <boolean-expression> may be used -- would certainly be another
>>reasonable addition to the "candidates list".  .
>
> I ASSumed it was supported for two reasons:
> .. I use them routinely in Micro Focus.
> .. Logic. Why would the standard create logical literals and then not
> permit them in conditional expressions? That's illogical.
>
> I refuse to write PERFORM UNTIL FALSE. It is common usage in other
> languages as DO FOREVER and WHILE TRUE. It implies on an explicit exit
> will be issued. Premature exits are for exceptions. The normal exit
> condition should be expressible in loop control.
> 


0
wmklein (2605)
9/3/2004 11:56:24 PM
"Howard Brazee" <howard@brazee.net> wrote 

> > That doesn't mean the techniques could reasonably be applied before they
> > were invented.  I don't think GO TO in  COBOL is inherently evil any more
> > than the branch instructions on the 1401 were.
> 
> Still, if CoBOL was invented that the only way to get to a paragraph was to
> perform it, coders back then wouldn't have had any problem writing code.

They simply would have ignored the language as being 'broken'.  One
reason why Cobol succeeded was that programmers could move most of
their existing code from commercial languages to it. And all their
existing techniques.

There is no doubt that ALTER is a vastly faster mechanism than any 'IF
first-flag' technique, and this is why ALTER was used and required to
be in the language.

It was just earlier in the same decade that mercury tube was a common
memory. You should read 'Early British Computers' to get an
appreciation of the programming techniques used at that time just to
get the program running fast enough.
 
> > And structured programming was a concept that wasn't "always" around.
> 
> They wouldn't have needed such a concept so much with that change.

Geez, Robert, you have such perfect hindsight.
0
riplin (4127)
9/3/2004 11:57:15 PM
Again, Sections represented OVERLAYS needed because ONE PROGRAM could 
NOT all fit into memory. Univac 1 1960. All advances since thing have
appliced SECTIONS to the hardware in question. Memory may fail me, but
as I recall, Burroughs was the only participant who did not care if
SECTIONS were added or not. They had solved the problem for themselves.

FIRST, put yourself in the 1960 mode, and then suggest something that
could not or was not dreamed of at that time. Then allow for the fact
that a lot has happened, and pick something that COBOL does NOT do, or
could do a LOT better today.

At the time COBOL was "designed", plugboards were the main method of
programming. And each step had it's own hardware. Except for perhaps
military development.

Twenty years later, it was possible to have
a computer manufaturer quote bulk prices for computers installed in
Jet planes, and process control. I was once told by such a company
that they could build and sell in bulk, something like the B3500
in a package that would fit in a plane, and have replaceable drawers
to speed field repair. Of course the interface to the user was not the
same as one used for corporate bookkeeping. By todays prices they would
have been expensive, but compared to normal data processing hardware
one could own one for a month's rent of a big dp system. When he PC
came along, it was not a surprise. First, the government has to pay for
the design and development, then, when obsolete, make it available for
consumer use. Consider this a pontification.

Warren Simmons




Robert Wagner wrote:

> On Thu, 2 Sep 2004 15:28:48 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
> 
> 
>>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>>news:3u2fj01k5p28pca6imktrckrd1ulp1mbml@4ax.com...
>>
>>
>>>If you MUST do memory management, dynamic CALL/CANCEL is better.
> 
> 
>>I don't disagree that "modularity" is a virtue, and I happen to agree that
>>IPC (even as implemented according to '74 standards) is a really good way to
>>accomplish modularity, but I'm not convinced that the problems of memory
>>management are best solved by *procedural* modularity, particularly when the
>>system already does a pretty good job of handling object code, without any
>>involvement by the user at all, the overwhelming majority of the time.
> 
> 
> Segments are a case of procedural modularity. Only procedural code is
> pageable. With dynamic calls, working-storage belonging to the
> 'segment'  is pageable as well. 
> 
> 
>>Personally, I think "nested programs" is a Good Thing.  I just don't like
>>where the '85 standard put them.  I would personally have preferred that
>>the nested programs be located before any executable code in the PROCEDURE
>>DIVISION of the parent rather than after it.
> 
> 
> That separates the main procedure division from its data division. If
> programs were nested say 2 layers deep, program 3 would similarly
> separate program 2 into two pieces.
> 
> People would be editing the main program's procedure division, hit
> Page Up to see its data division, and be looking at an unrelated
> program's data division. They would say nested programs are too
> confusing.
> 
> I like small programs having  'locality of reference' for ease of text
> editing. If one is accustomed to working on very large programs,
> that's not a concern .. there are always two editor windows open.
> 
> 
>>While I'm on the subject of '85 CALL enhancements, I would have preferred
>>the BY VALUE/BY REFERENCE distinction be part of the "signature" of the
>>"callee" rather than the sole responsibility of the "caller".
> 
> 
> If you use prototypes, it is controlled by the callee.
> 
0
wsimmons5 (172)
9/4/2004 12:49:21 AM
On Fri, 3 Sep 2004 13:10:35 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:p68hj0p9f52si1kpsbs870up126ek6lfhh@4ax.com...

>   Who says all of
>WORKING-STORAGE *has to be* in a monolithic block that is unconditionally
>resident for the life of the program?

The culture says so. 

It sounds like you're referring to dynamic memory allocation in lieu
of working-storage. If that's done, there would be at least one
POINTER in the program. Neither allocate nor pointer was available in
the 85 standard, but they were in IBM mainframe Cobol. When I worked
at the largest US brokerage house, I had access to much of their Cobol
source -- many thousands of programs. Out of curiosity, I did a search
for POINTER. There were  none.

The vast majority of mainstream Cobol programmers think
working-storage has to be a monolithic block. It doesn't matter what's
offered by the standard or compiler. They'll keep doing it 'the way
they were taught' (mostly autodactation) until the day the die. 

>> a. Two passes in the compiler front-end.
>>       Too slow.

> ...  what's *the* compiler front-end?

The front-end translates Cobol to intermediate code, as opposed to the
back-end, which translates intermediate to machine code.

>> Parameters? We don't got to pass
>> no stiinking parameters! Just reach into the pot and help yourself.
>
>You don't have to pass "shared data" in COBOL as parameters, you can always
>make it global and thus access by anyone beneath is welcome if that's what
>you want.

I'm assume that was a sop to other cultures. I picture heated debates
between 'purists' vs. ALGOL/Pascal/C types. They compromized with
GLOBAL.

>> Cobol has been criticized for having 'an ocean of global data' since
>> the beginning. That's WHY nested programs were created.
>
>Yes, but I'd say the "global" issue is a refinement on that.  Nested
>programs allows the data that is accessed or used only by a given set of
>logic to be associated with that logic and thus removed from the "outer
>block".   And if you're *really* modularizing, how much "local" data does
>the "outer block" of a COBOL program in which all its real work is done in
>"nested" programs really need?

Only the stuff passed to and from them. But that could be a lot.
Record structures, for instance. 

>> > I've never understood the particular utility of calling
>> >a program one time with a parameter BY REFERENCE and the next time BY
>VALUE,
>>
>> That's not utility, that's an error.
>
>No, it's *explicitly* allowed by COBOL

There is some miscommunication here due to an error.

BY CONTENT copies the thing and passes a pointer to the copy
BY VALUE      puts word-sized things directly into the parameter list 

You got them backwards. I didn't, so calling with a pointer one time
and a value another time is always an error. Yes, Cobol does allow you
to do that .. I think.

>> Some day, the solution will be typecasting via  introspection. The
>> compiler will peek into the callee to see what it wants, then cast the
>> call to match.
>
>Not sure what you mean by this, but I think having the compiler do "Well, I
>know what you *wrote*, but I've decided what you really *meant* was ..." is
>a REALLY bad idea.

We won't be asked to say what we want. We'll leave it blank and let
the compiler fill it in.

>That's actually one of the big differences:  COBOL allows just about
>anything to be passed BY [CONTENT]; the procedural languages didn't.

Yes, that's not an option in other languages. They offer BY REFERENCE
and BY VALUE.

Why are we so paranoic that we feel the need to protect data from
'malicious' or irresponsible called programs?  The problem is not
irresponsibility, it's fallibility. We're wasting valuable resources
defending against a fantasm rather than addressing the problem with a
better language.

0
robert6624 (636)
9/4/2004 3:45:32 AM
On Fri, 3 Sep 2004 09:26:25 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:btjgj09sa8iedc4m2gnjns4st9rfe8m4do@4ax.com...
>
>> "It" is the value representing a condition. Indirection means
>> 'referred to by name rather than literal value'.
>
>And you can't do this with "CONSTANT" today?

Hmmm. CONSTANT was new in 2002, but Micro Focus had nearly the same as
level 78. The HUGECALC demo I posted here had 50-100 inline references
to 'length of huge / 2'. The code would read much more cleanly if I'd
used a 78 to equate 'midpoint' to that expression. I apologized for
the verbosity, saying I didn't know a way around it.

Why didn't anyone point out 78/CONSTANT?

>And it took the author of the (now-approved) proposal for Structured
>Constants in the 2008 draft (see
>http://www.cobolportal.com/j4/files/04-0056.doc ) a fair amount of effort to
>convince J4 that the content of a Structured Constant should be, at the
>beginning of execution, as if a statement of the form "INITIALIZE ... WITH
>FILLER ALL TO VALUE" had been executed against it before execution begins.
>The idea of having the effects of INITIALIZE "bleed over" into compile-time
>was of some concern, and I think doing that in this case would be a hard
>sell.

You know what they say about people who refer to themselves in the
third person. :)

To me, a structured constant is a typedef with values. It also looks
like an OO constructor. It says (to the compiler) construct one of
these things and initialize it like this.

A simpler solution would have been TYPEDEF INITIALIZED. 
0
robert6624 (636)
9/4/2004 3:45:35 AM
On Fri, 03 Sep 2004 23:56:24 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Just to "add" to this thread,  I think it would be nice if some future Standard 
>actually *required* the compiler to produce a listing (which it doesn't and 
>never has).  It would also be nice if it gave some clue how such a listing 
>should handle COPY REPLACING/REPLACE statements - which are currently handled 
>very differently by various compilers. (Some show before the replacement, some 
>after)

As an alternative, the standard might specify that error messages
refer to _original_ line numbers, before COPY. Most compilers already
do this.

I haven't looked at a listing in 20 years. I edit the source and go to
the line number indicated. If there is a pre-processor involved, I
edit its output, which is input to the compiler.
0
robert6624 (636)
9/4/2004 3:45:37 AM
On Fri, 3 Sep 2004 15:06:49 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>On  2-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>> That doesn't mean the techniques could reasonably be applied before they
>> were invented.  I don't think GO TO in  COBOL is inherently evil any more
>> than the branch instructions on the 1401 were.

>Still, if CoBOL was invented that the only way to get to a paragraph was to
>perform it, coders back then wouldn't have had any problem writing code.
>
>> And structured programming was a concept that wasn't "always" around.
>
>They wouldn't have needed such a concept so much with that change.

I agree with Chuck on this. In the early '60s, with a background of
1401 assembly language programming, I thought it would be impossible
to write a Cobol program without GO TO.  Had I been on a standards
committee, I would have defended GO TO. 

In retrospect, it is obvious I was wrong. All the founders were.  In
their defense, they were 'creatures of their time'.  They did the best
they could with assembly language antecedents and very little
experience with high-level languages. 

Structured programming was discovered in the late '60s and promoted in
the early '70s  by people such as Yourdon and Michael Jackson (the
other one). I wish we'd grocked it earlier, but we didn't.
0
robert6624 (636)
9/4/2004 5:03:56 AM
Robert Wagner wrote:

>On Fri, 3 Sep 2004 09:26:25 -0700, "Chuck Stevens"
><charles.stevens@unisys.com> wrote:
>
>  
>
>>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>>news:btjgj09sa8iedc4m2gnjns4st9rfe8m4do@4ax.com...
>>
>>    
>>
>>>"It" is the value representing a condition. Indirection means
>>>'referred to by name rather than literal value'.
>>>      
>>>
>>And you can't do this with "CONSTANT" today?
>>    
>>
>
>Hmmm. CONSTANT was new in 2002, but Micro Focus had nearly the same as
>level 78. The HUGECALC demo I posted here had 50-100 inline references
>to 'length of huge / 2'. The code would read much more cleanly if I'd
>used a 78 to equate 'midpoint' to that expression. I apologized for
>the verbosity, saying I didn't know a way around it.
>
>Why didn't anyone point out 78/CONSTANT?
>
>  
>
>>And it took the author of the (now-approved) proposal for Structured
>>Constants in the 2008 draft (see
>>http://www.cobolportal.com/j4/files/04-0056.doc ) a fair amount of effort to
>>convince J4 that the content of a Structured Constant should be, at the
>>beginning of execution, as if a statement of the form "INITIALIZE ... WITH
>>FILLER ALL TO VALUE" had been executed against it before execution begins.
>>The idea of having the effects of INITIALIZE "bleed over" into compile-time
>>was of some concern, and I think doing that in this case would be a hard
>>sell.
>>    
>>
>
>You know what they say about people who refer to themselves in the
>third person. :)
>
>To me, a structured constant is a typedef with values. It also looks
>like an OO constructor. It says (to the compiler) construct one of
>these things and initialize it like this.
>
>A simpler solution would have been TYPEDEF INITIALIZED. 
>  
>
Well let me give you a little background on this one because I was *very 
interested*. I'm not sure Chuck knows the full history, (I might have 
told him), but he was the one who did cartwheels trying to resolve this.

We had a discussion group going at Thane's (Hubbell) group 
softwaresimple.com discussing COBOL and OO COBOL - tended to majorly be 
the latter. Artur Reimann the then representative for Fujitsu  at J4 was 
taken seriously ill just before emplaning for the meeting at Newbury in 
May/June 2000. I don't know specifics but he had to opt out on health 
grounds. Thane being a Fujitsu user was probably asked to represent 
them. Fresh face, some bright new ideas he picked up on the OO method 
syntax. At that time, say around mid to late 2000, a method looked very 
much like a 'mini' program and certainly in Micro Focus had 
Working-Storage.

So Thane initially picked up on this aspect that a 'min-program' would 
take a reference to a COBOL file. It completely blew the concept of 
"new" creating a separate instance, if you had files defined in methods. 
I can't actually recall but a method "mini program" may have also have 
allowed Declaratives. So he proposed take away that file feature in a 
method - quite right ! In the process he also said take away 
Working-Storage - after all , we had Local-Storage.

Well J4 sure likes to deliberate - but WOOSH ! - this one passed through 
their portals before you had a chance to count up to ten. Even if not 
actually into OO they could understand the logic behind what Thane was 
proposing.

Too late, and I for one am saying to myself, "Hey what have you done 
with my method Working-Storage- I use it to store literals". Now the 
name of the game in Micro Focus is that you CAN have method working 
storage - but if you have in global W/S  and the method W/S a field 
called "ws-count", then the method reference takes PRECEDENCE when you 
are in the method - so you don't screw up between the two. Makes sense 
to name the two differently anyway by calling the latter ls-count.

So yours truly IS using Level 78's in the Local-storage, but to retain 
my literals in the method I'm still coding Working Storage. (You may 
recall you picked up on this saying for language translation that they 
should be in a file - Uggh - I did that in DOS for the text to build all 
my menus using M/F's Screen Section enhancements - until I lost the 
f..... file ! Oh yes, I had backups, but still lost it. The other 
problem with your file concept, it does need administering; you are 
bound to get duplications or obsolete messages where somebody adds a new 
message and forgets to tell the administrator to delete the old one. I 
know, I know - it can be done - but it is an unnecessary hassle).

Now I asked M/F about storing literals in Method W/S - they weren't too 
thrilled, because you have to load them in their *initial state* each 
time you load the method. But bearing in mind JerryMouse's oft repeated 
message, 'don't micromanage' - what the hell. I don't see a performance 
slowdown, and when coding I'm concentrating on what is happening within 
one method. Yes, I could hold those literals up in global W/S - but I 
really don't wont to go flipping around the source.

I must have sent something on this to J4 because I eventually got a 
query from somebody at HP - when I clarified what I was after, i.e. 
"literals in a method' - he replied, "That makes sense'. Certainly well 
prior to this J4 had decided on the word CONSTANT,  ('bye, 'bye M/F's 
Level 78). Well CONSTANT sure fits in with the criticism that COBOL is 
verbose. (Why don't we get rid of Level 77's and call then 
SEPARATELY-DISTINGUISHABLE-VARIABLE).
I don't  know and to be truthful don't really care, but there were 
apparently some deficiencies in using CONSTANT. So Chuck steps in to 
take a crack at this one. He must have seen my paper, and he too saw 
merit in what I wanted to do, so he asked me, "Would this fit, would 
that fit", but he had to put the whole thing together to fit within the 
framework of how they already had CONSTANTS specified - I'm more than 
certain that he agonized over this one for quite a while.

Sometimes the background history can be fascinating. Get on the right 
side of Bill K. and he can sure tell you some fascinating tales about J4 
and why things turned out in a particular way.

Jimmy, Calgary AB

0
jjgavan (507)
9/4/2004 5:34:56 AM
"James J. Gavan" <jjgavan@shaw.ca> wrote:

>Jeff York wrote:
>
>>Blimey!  You must be even older than me! 
>>
>That's for sure. Some here already know - but now I'm going to give it 
>to you, but you have to  go googling if interested..
>The song :-
>
>You must remember this,
>A kiss is just a kiss,
>A sigh is just a sigh........
>
>Was the rage and popularized in the movie, (film to you),  'Casablanca' 
>starring Bogey and the then young and pretty Ingrid Bergman. However 
>that song was written the year I was born  - go for it :-)

Hubert Hupfield in 1931?  And I thought that *I* was a dinosaur..  :-)

-- 
Jeff.         Ironbridge,  Shrops,  U.K.
jjy@jakfield.xu-netx.com  (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)

.... "There are few hours in life more agreeable
      than the hour dedicated to the ceremony
      known as afternoon tea.."

         Henry James,  (1843 - 1916).

 
0
ralf4 (132)
9/4/2004 7:16:52 AM
Robert Wagner wrote:
>>   Who says all of
>> WORKING-STORAGE *has to be* in a monolithic block that is
>> unconditionally resident for the life of the program?
>
>
> The vast majority of mainstream Cobol programmers think
> working-storage has to be a monolithic block. It doesn't matter what's
> offered by the standard or compiler. They'll keep doing it 'the way
> they were taught' (mostly autodactation) until the day the die.

Not that there's anything wrong with that.



0
nospam312 (645)
9/4/2004 1:11:31 PM
In article <vc6ij0h5pe6ob9cahhbcknhq93tneleamr@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:

[snip]

>I haven't looked at a listing in 20 years. I edit the source and go to
>the line number indicated.

Our experiences are different, Mr Wagner... as recently as 1996 I 
consulted with an organisation that used an IBM mainframe MVS-oid 
environment but did not have ABEND-Aid or FileAid; when things blew up the 
speediest course of action was to find the PSW, recompile with PMAP and 
NOOBJ, locate the offending statement and take things from there.

(For correcting data errors in VSAM files each programmer had a couple of 
programs that they'd use... skeleton utilities where they'd determine the 
data in error from the dump and then modify the skeleton to correct it 
just this one time - IF RECORD-KEY = '1A275BFZ009' MOVE +0 TO 
WS-QUANT-NEEDED, recompile and run it against the offending file, reading 
the old and writing a new.  They were... stunned when they found I was 
using a different system (because nobody would show A Consultant how 
things were done there, Heaven Forbid that an Outsider learn the 
jealously-guarded secrets... 'Oh, the A1725D08 file?  Louie's the one who 
knows most about that and he's out today... but hey, it's just a data 
error and you're a Consultant, you should have no trouble fixing it, 
that's why you get paid the big bucks, right?'... Job Security by 
Idiosyncratic Knowledge, aye) of finding the offending record in a dump, 
pulling it out via IDCAMS to a single-record dataset, using a combination 
of the TSO Editor, a file-layout and a... sense of smell to change the 
data... and then, by a series of IDCAMS, putting the file back together 
again with the modified rec replacing the original.)

DD

0
docdwarf (6044)
9/4/2004 1:53:14 PM
In article <iscij015s0h8to660uehaog7lbnkjqvbdo@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:

[snip]

>They'll keep doing it 'the way
>they were taught' (mostly autodactation) until the day the die. 

Might the same OED that lists 'consanguinaceous' along with 
'consanguineous' be the one were one finds 'autodactation' listed with 
'autodidaction'?

DD

0
docdwarf (6044)
9/4/2004 2:04:36 PM
On Sat, 04 Sep 2004 05:34:56 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:

>So yours truly IS using Level 78's in the Local-storage, but to retain 
>my literals in the method I'm still coding Working Storage. (You may 
>recall you picked up on this saying for language translation that they 
>should be in a file - Uggh - I did that in DOS for the text to build all 
>my menus using M/F's Screen Section enhancements - until I lost the 
>f..... file ! Oh yes, I had backups, but still lost it. The other 
>problem with your file concept, it does need administering; you are 
>bound to get duplications or obsolete messages where somebody adds a new 
>message and forgets to tell the administrator to delete the old one. I 
>know, I know - it can be done - but it is an unnecessary hassle).

In the old days, administering control files may have been the most
onerous hassle. Today, that pales in comparison to Development
Methodologies such as ISO 9000, CMM, SDLC, Sigma 7, etc. They work
pretty much the same.  Picture the letter V. The point at the bottom
is where program changes are made. Down the left side are stages of
planning and design, where each step must be approved by a committee
and signed off. Up the right side are stages of testing that
correspond to the planning stages. The effect of the change is
compared to the planning document to insure they agree and nothing was
overlooked. 

Because this is a slow and expensive process, typically taking 6-12
months to complete a cycle, changes are batched. The input to a cycle
typically contains dozens to hundreds of change requests. As a result,
a one-line change to a literal will take at least six months to be
implemented.

The process is wary of program changes causing unintended
side-effects. Every program change, even just changing a literal, is
seen as a potential logic change. Thus, all the program's
functionality is required to be  re-tested.

Think you can slip it in on the back of another change? Think again.
While working on a program, I corrected a misspelling in an error
message. The change appeared during code review, which uses mechanical
comparison of old to new source. "Out Of Scope", they cried. In the
world of bureaucracy, nothing raises red flags faster. I was told to
but back like it was and don't ever do that again.

Imagine what it would be like if changes to data went through the same
process. A change to a customer's address would be reviewed by
committees, who verified that the new address is valid and the
customer's signature is original not a photocopy (I'm not making this
up). A clerk would execute the change .. in a test environment, of
course. He would capture the action in a script so it could be
promoted up the right side of the V unaltered.  Testers would bring
the new address up on a screen to verify that it matched the request.
Regression testing would make sure the change didn't accidentally
alter anything else. Finally, customers would have to sign off on
their new address (User Acceptance Testing) before it went live.
Because the process was slow, they'd slow it down more by waiting
until they had a batch of1,000 address changes. 

This absurd example demonstrates why literals such as screen headings
and error messages are more easily administered in data files vs.
hard-coded in programs. Program changes were quick an easy in the old
days, still are in very small shops. In big shops, we've been
handcuffed and hog-tied by bureaucrats. 

Peter Dashwood proposes a better way to manage development. Until it's
in use, I'm inclined to put data in files, logic in programs.

FWIW, Micro Focus error messages are in a file. If you don't like the
wording, change it.


0
robert6624 (636)
9/4/2004 3:00:23 PM
On 4 Sep 2004 10:04:36 -0400, docdwarf@panix.com wrote:

>In article <iscij015s0h8to660uehaog7lbnkjqvbdo@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>
>[snip]
>
>>They'll keep doing it 'the way
>>they were taught' (mostly autodactation) until the day the die. 
>
>Might the same OED that lists 'consanguinaceous' along with 
>'consanguineous' be the one were one finds 'autodactation' listed with 
>'autodidaction'?

Touche. We're even.

0
robert6624 (636)
9/4/2004 3:12:56 PM
On 4 Sep 2004 09:53:14 -0400, docdwarf@panix.com wrote:

>In article <vc6ij0h5pe6ob9cahhbcknhq93tneleamr@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>
>[snip]
>
>>I haven't looked at a listing in 20 years. I edit the source and go to
>>the line number indicated.
>
>Our experiences are different, Mr Wagner... as recently as 1996 I 
>consulted with an organisation that used an IBM mainframe MVS-oid 
>environment but did not have ABEND-Aid or FileAid; when things blew up the 
>speediest course of action was to find the PSW, recompile with PMAP and 
>NOOBJ, locate the offending statement and take things from there.

If you compile with the right debug option, the line number is
displayed. 

>(For correcting data errors in VSAM files each programmer had a couple of 
>programs that they'd use... skeleton utilities where they'd determine the 
>data in error from the dump and then modify the skeleton to correct it 
>just this one time - IF RECORD-KEY = '1A275BFZ009' MOVE +0 TO 
>WS-QUANT-NEEDED, recompile and run it against the offending file, reading 
>the old and writing a new. 

I usually copied to a flat file, edited it with ISPF/ICCF (which has
hex mode) and reloaded. 

It bugs me that indexed file systems don't come with a tool to correct
data errors. VSAM's not the only one; all Cobol compilers do it.
Management doesn't understand the deficiency. They think IBM is a big
company, surely it supplied minimal tools. We end up with no more
software than came with the operating system & compiler.

It's worse in the Unix world because the standard text editor -- vi --
sucks big time. It's so bad that it's unusable, IMO. I wind up copying
files to my desktop, editing there and copying back.

Databases are better than VSAM because the come with a data repair
'tool' -- the SQL language itself. Also, they have control tables that
take the mystery out of record layouts. One can approach a database
without prior knowledge, without outside documentation, and quickly
see what's in it. If he has a $500 tool like Toad running on his
desktop, he can be productive immediately. 

> They were... stunned when they found I was 
>using a different system (because nobody would show A Consultant how 
>things were done there, Heaven Forbid that an Outsider learn the 
>jealously-guarded secrets... 'Oh, the A1725D08 file?  Louie's the one who 
>knows most about that and he's out today... but hey, it's just a data 
>error and you're a Consultant, you should have no trouble fixing it, 
>that's why you get paid the big bucks, right?'... Job Security by 
>Idiosyncratic Knowledge, aye) of finding the offending record in a dump, 
>pulling it out via IDCAMS to a single-record dataset, using a combination 
>of the TSO Editor, a file-layout and a... sense of smell to change the 
>data... and then, by a series of IDCAMS, putting the file back together 
>again with the modified rec replacing the original.)

I once built an overwritten VSAM Master Catalog from scratch using
DITTO .. bit by bit .. at 2am  .. half drunk. It had to be right the
first time else CICS wouldn't have come up (its log files were VSAM).
CICS was the only User Interface  on VSE,  other than punched cards
and printed reports. You can't run ICCF or anything interactive if
CICS is down. There's no margin of error, no second attempt. If CICS
won't come up, you reinstall the operating system, reapply APARs,
start from scratch. 

Did you ever use the VSAM backup utility CA-FAVER? Use it once and you
can't live without it. Why doesn't IBM sell tools like that?
0
robert6624 (636)
9/4/2004 5:20:48 PM
Peter Lacey wrote:
> 
> If I were inventing it now: I'd require AT END and INVALID KEY with READ
> statements (as appropriate); I would not have some verbs, especially
> EVALUATE (hey! you did say "if YOU were inventing Cobol"!  And despite
> study, explanations and examples, I've yet to come across a case where
> an evaluate couldn't be done more clearly and usually simpler with IF's
> and/or CASE statments). 

And EVALUATE differs from a CASE statement *how*, exactly?  That's 
COBOL's version of a case statement.  :)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/4/2004 5:39:49 PM
Howard Brazee wrote:
> If you were inventing CoBOL back when, what would you do differently?

Probably just a few minor changes...

   - Fall-through pararaphs - only the first paragraph after "PROCEDURE 
DIVISION" would be fallen through.  Of course, this mandates scope 
delimiters for PERFORM, IF, etc. (which we currently have).

   - Global vs. locally declared variables - We have this too, now, with 
nested subprograms.

   - User-defined functions that can return values - this goes along 
with the point above.  You could say something like "MOVE FUNCTION 
DATE-FORMAT (ws-some-var) TO FORMATTED-DATE", and have that function 
return the character string.

We've got everything except the top one right now, and some would tell 
me that if I wanted those others, I should go use VB instead.  :)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/4/2004 5:50:25 PM
Robert Wagner wrote:
> 
> Get rid of precedence rules. Require that logical and arithmetic
> statements  use parentheses on statements containing more than one
> level. 
> 
> Do not allow logical elision between AND/OR nor into or out of
> parentheses.
> 
> For example, this would be invalid:
> 
> if a not = b and c or d
> 
> Would be written as:
> 
> if (a not = b and c) or (a not = d)
> 
> Require a warning on logical statements always true or false. For
> example:
> 
> if a not = 1 or 2
> if a = b or c or a
> 
> Reason for both: after newbies get bitten a few times, shops pass
> rules prohibiting all elision. I think it's one of Cobol's nicest
> features. Other languages drive me crazy when they make me repeat the
> subject over and over. 

This is where I've taken to using an "if-formatted evaluate" (my own 
term)...

evaluate variable  when thisValue  when thatValue
     perform thisOrThat
when other
     perform theOtherThing
end-evaluate

Then, sometimes I'll put each "when" on another line, so as to make it 
easy to add or remove conditions.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/4/2004 6:02:47 PM
On Sat, 04 Sep 2004 12:50:25 -0500, LX-i <lxi0007@netscape.net> wrote:

>Howard Brazee wrote:
>> If you were inventing CoBOL back when, what would you do differently?
>
>Probably just a few minor changes...
>
>   - Fall-through pararaphs - only the first paragraph after "PROCEDURE 
>DIVISION" would be fallen through.  

Cobol doesn't require a paragraph name after the  PROCEDURE DIVISION
header. You don't PERFORM or GO TO it; it serves no function. Just
leave it out.
0
robert6624 (636)
9/4/2004 6:38:37 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> Hmmm. CONSTANT was new in 2002, 

I recall the ICL 1900 compiler in the late 60s had a CONSTANT SECTION,
as does Fujitsu today.

> To me, a structured constant is a typedef with values. It also looks
> like an OO constructor. It says (to the compiler) construct one of
> these things and initialize it like this.
> 
> A simpler solution would have been TYPEDEF INITIALIZED.

But a TYPEDEF is merely the definition of a type, not a declaration of
one.
0
riplin (4127)
9/4/2004 7:04:13 PM
On Sat, 04 Sep 2004 13:02:47 -0500, LX-i <lxi0007@netscape.net> wrote:


>This is where I've taken to using an "if-formatted evaluate" (my own 
>term)...
>
>evaluate variable  when thisValue  when thatValue
>     perform thisOrThat
>when other
>     perform theOtherThing
>end-evaluate
>
>Then, sometimes I'll put each "when" on another line, so as to make it 
>easy to add or remove conditions.

You can put a condition after WHEN, rather than a value. The
difference is the equal sign. variable is an implied subject.
Condition lets you test variables not named in evaluate.

evaluate variable
     when = thisValue or thatValue      or (black = white)
           perform thisOrThat

If there are multiple values that are likely to change, I prefer 88
level.

05 variable pic x.
   88 thisOrThat values 'a' 'b' 'q' thru 'z'.

evaluate true
    when thisOrThat ...
0
robert6624 (636)
9/4/2004 7:06:17 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> As an alternative, the standard might specify that error messages
> refer to _original_ line numbers, before COPY. Most compilers already
> do this.

As long as an error _in_ a COPY book gives the filename and line
number within that as well.  If nested COPYs are allowed then it would
have to to give the whole nesting of file names and the line number.

And if the COPY is used more than once we should have the line number
of the COPY statement in the file it was in.

REPLACING may change the line numbering after COPYing, so it should be
the pre-REPLACING line number.

I can see why they don't do that.
0
riplin (4127)
9/4/2004 7:13:49 PM
On 4 Sep 2004 12:04:13 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>> Hmmm. CONSTANT was new in 2002, 
>
>I recall the ICL 1900 compiler in the late 60s had a CONSTANT SECTION,
>as does Fujitsu today.

CONSTANT SECTION was in the early standards. It was later dropped ..
in 85, I'm fairly sure.

>> To me, a structured constant is a typedef with values. It also looks
>> like an OO constructor. It says (to the compiler) construct one of
>> these things and initialize it like this.
>> 
>> A simpler solution would have been TYPEDEF INITIALIZED.
>
>But a TYPEDEF is merely the definition of a type, not a declaration of
>one.

Right. I saw it working like this:

01  myDate typedef initialized.
    05  month   pic 99.
    05      value '-'   pic x.
    05  year     pic 9999.

01 sales-journal.
.....
     05  deliveryDate  myDate.
     05  receiptDate   myDate.

The two dates would be initialized to '00-0000'. The zeros were
supplied at compile time as if INITIALIZE had been executed.




0
robert6624 (636)
9/4/2004 7:35:37 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> In the old days, administering control files may have been the most
> onerous hassle. Today, that pales in comparison to Development
> Methodologies such as ISO 9000, CMM, SDLC, Sigma 7, etc. ...

> This absurd example demonstrates why literals such as screen headings
> and error messages are more easily administered in data files vs.
> hard-coded in programs. 

Of course when the 'Development methodology' notices that parts of the
system are being exported to files outside of its control then they
merely appropriate control over that.     ;-)

I find that table driven systems are much easier to develop and
maintain than hard coded ones.  The tables can then be held in data
files and adjusted to suit exactly the user needs.  And, for example,
most of my output is templated in some way using a template file that
may be text or postscript, the data is merged in to give the output. 
Then it doesn't matter to the program (or at least not much) whether
the output is a printed report, a CSV file, HTML, or EDIFAC.
0
riplin (4127)
9/4/2004 7:55:09 PM
Jeff York wrote:

>"James J. Gavan" <jjgavan@shaw.ca> wrote:
>
>  
>
>>Jeff York wrote:
>>
>>    
>>
>>>Blimey!  You must be even older than me! 
>>>
>>>      
>>>
>>That's for sure. Some here already know - but now I'm going to give it 
>>to you, but you have to  go googling if interested..
>>The song :-
>>
>>You must remember this,
>>A kiss is just a kiss,
>>A sigh is just a sigh........
>>
>>Was the rage and popularized in the movie, (film to you),  'Casablanca' 
>>starring Bogey and the then young and pretty Ingrid Bergman. However 
>>that song was written the year I was born  - go for it :-)
>>    
>>
>
>Hubert Hupfield in 1931?  And I thought that *I* was a dinosaur..  :-)
>
>  
>
No you are only a dinosaur if you insist on using  COBOL '74 and READ 
INTO..........
0
jjgavan (507)
9/4/2004 8:27:07 PM
Robert Wagner wrote:

>FWIW, Micro Focus error messages are in a file. If you don't like the
>wording, change it.
>
>
>  
>
Yep - particularly associated with their Exception Handler - which is 
primarily a Validity check messenger. I know of two using it. One, "Well 
it's OK, sort of",  the other, "Nah. Don't like the messagefile".

As I view it - my methods are self-contained mini-programs, so in the 
course of doing various checks I'll set a Level 88,  say "InvalidClient" 
- I've just invented it on the fly. Now jump up to W/S and under 01 
ErrorCode  pic x(4) comp-5 value 0., 'll add the new 88 with the next 
value. Randomly I have all my errors defined. NOW I do the 
ErrorMessageBox method - bring down that W/S Table with a copy/paste - 
it's now in the error method that I dream up concise wording for 
messages specific to this class. OK one could argue that 'InvalidClient" 
could pop-up through several classes - but I  kinda feel, I've put a 
lead weight around my ankle if I stop to research that, and say, put it 
in a messagefile.

Jimmy
0
jjgavan (507)
9/4/2004 8:56:33 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:bu4kj0pqtrfr1mgbj2ncj0cbd4jjr8rjuk@4ax.com...
> On 4 Sep 2004 12:04:13 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
> >Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
> >
> >> Hmmm. CONSTANT was new in 2002,
> >
> >I recall the ICL 1900 compiler in the late 60s had a CONSTANT SECTION,
> >as does Fujitsu today.
>
> CONSTANT SECTION was in the early standards. It was later dropped ..
> in 85, I'm fairly sure.

I see no evidence that CONSTANT SECTION was part
of COBOL 68, the first ANSI COBOL standard. I have
an article of some CODASYL COBOL JOD activity
that shows the CONSTANT SECTION was deleted from
the CODASYL COBOL standard in 1969.



0
ricksmith (875)
9/4/2004 9:13:53 PM
Robert Wagner wrote:
> On Sat, 04 Sep 2004 12:50:25 -0500, LX-i <lxi0007@netscape.net> wrote:
> 
> 
>>Howard Brazee wrote:
>>
>>>If you were inventing CoBOL back when, what would you do differently?
>>
>>Probably just a few minor changes...
>>
>>  - Fall-through pararaphs - only the first paragraph after "PROCEDURE 
>>DIVISION" would be fallen through.  
> 
> 
> Cobol doesn't require a paragraph name after the  PROCEDURE DIVISION
> header. You don't PERFORM or GO TO it; it serves no function. Just
> leave it out.

heh - I'll have to try that, to see if our compiler supports it.  Just 
another thing to throw off my coworkers...  ;)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/4/2004 10:20:58 PM
Richard wrote:
> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
> 
> 
>>As an alternative, the standard might specify that error messages
>>refer to _original_ line numbers, before COPY. Most compilers already
>>do this.
> 
> 
> As long as an error _in_ a COPY book gives the filename and line
> number within that as well.  If nested COPYs are allowed then it would
> have to to give the whole nesting of file names and the line number.
> 
> And if the COPY is used more than once we should have the line number
> of the COPY statement in the file it was in.
> 
> REPLACING may change the line numbering after COPYing, so it should be
> the pre-REPLACING line number.
> 
> I can see why they don't do that.

The Unisys 2200 UCS COBOL compiler does (although nested COPYs are not 
allowed).  The lines are numbered within the regular COBOL source, then 
the copy looks like

2004          copy whatever
2004.C1.1  whatever proc.
2004.C1.2     etc.

If a line is expanded due to a replace, it'll look something like

2004.C1.15         when this-used-to-be-one-character also
2004.C1.15.R1  this-makes-the-line-too-long-to-fit

And, when running full-program monitors, those are the numbers that show 
up with the debugging statements.  :)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/4/2004 10:25:56 PM
In article <tlmjj09h1bjhdv9nbcruhl39h04t56tkfo@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 4 Sep 2004 10:04:36 -0400, docdwarf@panix.com wrote:
>
>>In article <iscij015s0h8to660uehaog7lbnkjqvbdo@4ax.com>,
>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>
>>[snip]
>>
>>>They'll keep doing it 'the way
>>>they were taught' (mostly autodactation) until the day the die. 
>>
>>Might the same OED that lists 'consanguinaceous' along with 
>>'consanguineous' be the one were one finds 'autodactation' listed with 
>>'autodidaction'?
>
>Touche. We're even.

Oh, I *cannot* resist... 'even', Mr Wagner?  What a change... but I guess 
I'll just have to do my best to adjust to my decrease in circumstances.

DD

0
docdwarf (6044)
9/4/2004 10:48:55 PM
In article <9rrjj0tvgu0rg9l711gt58bo3856be40fk@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 4 Sep 2004 09:53:14 -0400, docdwarf@panix.com wrote:
>
>>In article <vc6ij0h5pe6ob9cahhbcknhq93tneleamr@4ax.com>,
>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>
>>[snip]
>>
>>>I haven't looked at a listing in 20 years. I edit the source and go to
>>>the line number indicated.
>>
>>Our experiences are different, Mr Wagner... as recently as 1996 I 
>>consulted with an organisation that used an IBM mainframe MVS-oid 
>>environment but did not have ABEND-Aid or FileAid; when things blew up the 
>>speediest course of action was to find the PSW, recompile with PMAP and 
>>NOOBJ, locate the offending statement and take things from there.
>
>If you compile with the right debug option, the line number is
>displayed. 

I'd ask what the 'right debug option' for IKFCBL00 might have been, Mr 
Wagner... but I don't have much call to use that compiler any more.

>
>>(For correcting data errors in VSAM files each programmer had a couple of 
>>programs that they'd use... skeleton utilities where they'd determine the 
>>data in error from the dump and then modify the skeleton to correct it 
>>just this one time - IF RECORD-KEY = '1A275BFZ009' MOVE +0 TO 
>>WS-QUANT-NEEDED, recompile and run it against the offending file, reading 
>>the old and writing a new. 
>
>I usually copied to a flat file, edited it with ISPF/ICCF (which has
>hex mode) and reloaded. 

Sounds moderately familiar, aye.

>
>It bugs me that indexed file systems don't come with a tool to correct
>data errors. VSAM's not the only one; all Cobol compilers do it.
>Management doesn't understand the deficiency. They think IBM is a big
>company, surely it supplied minimal tools. We end up with no more
>software than came with the operating system & compiler.

Sometimes a site does, sometimes a site doesn't... if your assertion above 
were true then there'd be no surprise demonstrated when I say that I 
worked on a site in 1996 that didn't have FileAid or ABEND-Aid... and I 
have seen surprise demonstrated at this.

>
>It's worse in the Unix world because the standard text editor -- vi --
>sucks big time. It's so bad that it's unusable, IMO. I wind up copying
>files to my desktop, editing there and copying back.

'Pico?  Too delicate for vi, are we... why not go all out, then, and just 
use a Mac?'

>
>Databases are better than VSAM because the come with a data repair
>'tool' -- the SQL language itself.

I would say, Mr Wagner, that this is good only when the structure 
underlying the database is still more-or-less intact.  For DB2 there 
are a myriad of underlying VSAM structures, any one of which can get 
corrupted and render the database unfit for SQL manipulation, in Oracle... 
well, it varies from one implementation to the next but the same principle 
holde, you throw a bad block into the wrong segment of the wrong file and 
SQL just won't 'take'.

>Also, they have control tables that
>take the mystery out of record layouts. One can approach a database
>without prior knowledge, without outside documentation, and quickly
>see what's in it. If he has a $500 tool like Toad running on his
>desktop, he can be productive immediately. 

Toad is for Oracle, Mr Wagner... DB2 can be, like a few other IBM 
products, a bit more mysterious.

[snip]

>Did you ever use the VSAM backup utility CA-FAVER?

Can't say as I have, Mr Wagner... whatever my client has installed, I use.

DD
0
docdwarf (6044)
9/4/2004 11:03:48 PM
LX-i wrote:
> 
> Peter Lacey wrote:
> >
> > If I were inventing it now: I'd require AT END and INVALID KEY with READ
> > statements (as appropriate); I would not have some verbs, especially
> > EVALUATE (hey! you did say "if YOU were inventing Cobol"!  And despite
> > study, explanations and examples, I've yet to come across a case where
> > an evaluate couldn't be done more clearly and usually simpler with IF's
> > and/or CASE statments).
> 
> And EVALUATE differs from a CASE statement *how*, exactly?  That's
> COBOL's version of a case statement.  :)
> 


The mind boggles!

Let me ask you first:  how many languages are you fluent in?  That will
determine how I reply.

PL
0
lacey (134)
9/5/2004 2:46:15 AM
Peter Lacey wrote:
> LX-i wrote:
> 
>>Peter Lacey wrote:
>>
>>>If I were inventing it now: I'd require AT END and INVALID KEY with READ
>>>statements (as appropriate); I would not have some verbs, especially
>>>EVALUATE (hey! you did say "if YOU were inventing Cobol"!  And despite
>>>study, explanations and examples, I've yet to come across a case where
>>>an evaluate couldn't be done more clearly and usually simpler with IF's
>>>and/or CASE statments).
>>
>>And EVALUATE differs from a CASE statement *how*, exactly?  That's
>>COBOL's version of a case statement.  :)
>>
> 
> The mind boggles!
> 
> Let me ask you first:  how many languages are you fluent in?  That will
> determine how I reply.

Mostly English - a little bit of Spanish...  ;)

I've worked in COBOL, VB, Ada, Java, PHP, and a wee bit of C++ and FORTRAN.

(I'm not the only one who had a like response to your postulate above - 
what are we all missing?  :>  )


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/5/2004 3:41:40 AM
On 4 Sep 2004 19:03:48 -0400, docdwarf@panix.com wrote:

>In article <9rrjj0tvgu0rg9l711gt58bo3856be40fk@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:

>>It bugs me that indexed file systems don't come with a tool to correct
>>data errors. VSAM's not the only one; all Cobol compilers do it.
>>Management doesn't understand the deficiency. They think IBM is a big
>>company, surely it supplied minimal tools. We end up with no more
>>software than came with the operating system & compiler.
>
>Sometimes a site does, sometimes a site doesn't... if your assertion above 
>were true then there'd be no surprise demonstrated when I say that I 
>worked on a site in 1996 that didn't have FileAid or ABEND-Aid... and I 
>have seen surprise demonstrated at this.

I suppose most MVS shops had FileAid and SynchSort. I won't proffer an
estimate 'cause I haven't worked in that many. It's safe to say the
initiative came from programmers, who had to cajole and justify the
expense. It didn't come from management. 

>>It's worse in the Unix world because the standard text editor -- vi --
>>sucks big time. It's so bad that it's unusable, IMO. I wind up copying
>>files to my desktop, editing there and copying back.
>
>'Pico?  Too delicate for vi, are we... why not go all out, then, and just 
>use a Mac?'

Macs are for aging hippies.

>Databases are better than VSAM because the come with a data repair
>>'tool' -- the SQL language itself.
>
>I would say, Mr Wagner, that this is good only when the structure 
>underlying the database is still more-or-less intact.  For DB2 there 
>are a myriad of underlying VSAM structures, any one of which can get 
>corrupted and render the database unfit for SQL manipulation, 

So much for the assertion that IBM mainframes are ultra-reliable.

>in Oracle... 
>well, it varies from one implementation to the next but the same principle 
>holds, you throw a bad block into the wrong segment of the wrong file and 
>SQL just won't 'take'.

Oracle dies slowly and gracefully. I've never seen an Informix
database corrupted.

>>Also, they have control tables that
>>take the mystery out of record layouts. One can approach a database
>>without prior knowledge, without outside documentation, and quickly
>>see what's in it. If he has a $500 tool like Toad running on his
>>desktop, he can be productive immediately. 
>
>Toad is for Oracle, Mr Wagner... DB2 can be, like a few other IBM 
>products, a bit more mysterious.

Aren't there tools like Toad for DB2? No? Economy of scale. Yes? You
must be talking about FileAid for DB2. It's good for queries but not
an administrative tool.

DB2 has good performance, but administration frustrates even seasoned
DBAs. Changes seldom work right the first time. For ease of
maintenance, I'd rank databases from best to worst:

Informix
SQLServer/Sybase
Oracle
DB2/UDB

For performance:

Informix
DB2/UDB
Oracle
SQLServer/Sybase

0
robert6624 (636)
9/5/2004 4:28:23 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> CONSTANT SECTION was in the early standards. It was later dropped ..
> in 85, I'm fairly sure.

I see no evidence of that at all.

It was not in 74 or 68.  Nor is it a change in 68 so I doubt that it was in 61.
0
riplin (4127)
9/5/2004 4:54:36 AM
Standard COBOL (thru the '85 Standard at least) definitely DOES require a 
paragraph (or section and paragraph) at the beginning of the Procedure Division. 
Some, not all, compilers didn't require this - but flagged it as an extension 
when non-standard flagging was turned on.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:pn2kj09tp9j4eketmhjq8rbhbicl68kcd7@4ax.com...
> On Sat, 04 Sep 2004 12:50:25 -0500, LX-i <lxi0007@netscape.net> wrote:
>
>>Howard Brazee wrote:
>>> If you were inventing CoBOL back when, what would you do differently?
>>
>>Probably just a few minor changes...
>>
>>   - Fall-through pararaphs - only the first paragraph after "PROCEDURE
>>DIVISION" would be fallen through.
>
> Cobol doesn't require a paragraph name after the  PROCEDURE DIVISION
> header. You don't PERFORM or GO TO it; it serves no function. Just
> leave it out. 


0
wmklein (2605)
9/5/2004 5:17:12 AM
In article <qs2lj0drh9aqc2rm2uh07tbad5fch3ahvh@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 4 Sep 2004 19:03:48 -0400, docdwarf@panix.com wrote:
>
>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>In article <9rrjj0tvgu0rg9l711gt58bo3856be40fk@4ax.com>,
>>>It bugs me that indexed file systems don't come with a tool to correct
>>>data errors. VSAM's not the only one; all Cobol compilers do it.
>>>Management doesn't understand the deficiency. They think IBM is a big
>>>company, surely it supplied minimal tools. We end up with no more
>>>software than came with the operating system & compiler.
>>
>>Sometimes a site does, sometimes a site doesn't... if your assertion above 
>>were true then there'd be no surprise demonstrated when I say that I 
>>worked on a site in 1996 that didn't have FileAid or ABEND-Aid... and I 
>>have seen surprise demonstrated at this.
>
>I suppose most MVS shops had FileAid and SynchSort. I won't proffer an
>estimate 'cause I haven't worked in that many. It's safe to say the
>initiative came from programmers, who had to cajole and justify the
>expense. It didn't come from management. 

I am uncertain of the origin as well, Mr Wagner, but remember that such 
tools cost money and that (among other things) the allocation of budget is 
a responsibility of management.  Consider... a shop doesn't have these 
tools until a given programmer is promoted to management and thus has say 
over budget.  Whence comes the 'initiative', then?

>
>>>It's worse in the Unix world because the standard text editor -- vi --
>>>sucks big time. It's so bad that it's unusable, IMO. I wind up copying
>>>files to my desktop, editing there and copying back.
>>
>>'Pico?  Too delicate for vi, are we... why not go all out, then, and just 
>>use a Mac?'
>
>Macs are for aging hippies.

Generalisations are for those too unsubtle to deal with specifics... see 
how easy it is?

>
>>Databases are better than VSAM because the come with a data repair
>>>'tool' -- the SQL language itself.
>>
>>I would say, Mr Wagner, that this is good only when the structure 
>>underlying the database is still more-or-less intact.  For DB2 there 
>>are a myriad of underlying VSAM structures, any one of which can get 
>>corrupted and render the database unfit for SQL manipulation, 
>
>So much for the assertion that IBM mainframes are ultra-reliable.

Mr Wagner, who here has made that assertion?  I do not know where the 
strategy originated but the backup regimen at every IBM mainframe shop in 
which I have worked has been 'incremental daily, system weekly'... a 
curious precaution to take when one is dealing with 'ultra-reliable' 
equipment.

>
>>in Oracle... 
>>well, it varies from one implementation to the next but the same principle 
>>holds, you throw a bad block into the wrong segment of the wrong file and 
>>SQL just won't 'take'.
>
>Oracle dies slowly and gracefully. I've never seen an Informix
>database corrupted.

Perhaps you need to get out more... remember, the question is not 'what 
will you do *if* the disk dies', it is 'what will you do *when* the disk 
dies'.

>
>>>Also, they have control tables that
>>>take the mystery out of record layouts. One can approach a database
>>>without prior knowledge, without outside documentation, and quickly
>>>see what's in it. If he has a $500 tool like Toad running on his
>>>desktop, he can be productive immediately. 
>>
>>Toad is for Oracle, Mr Wagner... DB2 can be, like a few other IBM 
>>products, a bit more mysterious.
>
>Aren't there tools like Toad for DB2? No?

I've never heard of one, Mr Wagner... and a Google search for "toad for 
db2" (quotes included) brings up none-too-many hits.  The most instructive 
seems to be:

http://www.db2mag.com/story/showArticle.jhtml?articleID=25600500#3

--begin quoted text:

Product News for Quarter 3, 2004

[snip]

Toad for DB2

Quest Software is working on bringing the Toad application development 
tool to DB2 customers.

--end quoted text

>Economy of scale. Yes? You
>must be talking about FileAid for DB2. It's good for queries but not
>an administrative tool.

I am an apps jockey, Mr Wagner; I leave administrating to the 
administrators.

>
>DB2 has good performance, but administration frustrates even seasoned
>DBAs.

See above about 'mysterious'.

DD
0
docdwarf (6044)
9/5/2004 9:41:31 AM
"James J. Gavan" <jjgavan@shaw.ca> wrote:

>Jeff York wrote:
>
>>"James J. Gavan" <jjgavan@shaw.ca> wrote:
>>
>>  
>>
>>>Jeff York wrote:
>>>
>>>    
>>>
>>>>Blimey!  You must be even older than me! 
>>>>
>>>>      
>>>>
>>>That's for sure. Some here already know - but now I'm going to give it 
>>>to you, but you have to  go googling if interested..
>>>The song :-
>>>
>>>You must remember this,
>>>A kiss is just a kiss,
>>>A sigh is just a sigh........
>>>
>>>Was the rage and popularized in the movie, (film to you),  'Casablanca' 
>>>starring Bogey and the then young and pretty Ingrid Bergman. However 
>>>that song was written the year I was born  - go for it :-)
>>>    
>>>
>>
>>Hubert Hupfield in 1931?  And I thought that *I* was a dinosaur..  :-)
>>
>>  
>>
>No you are only a dinosaur if you insist on using  COBOL '74 and READ 
>INTO..........

I've never used READ INTO...  And I'm getting my GO TOs down to less
than 20 a day.

-- 
Jeff.         Ironbridge,  Shrops,  U.K.
jjy@jakfield.xu-netx.com  (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)

.... "There are few hours in life more agreeable
      than the hour dedicated to the ceremony
      known as afternoon tea.."

         Henry James,  (1843 - 1916).

 
0
ralf4 (132)
9/5/2004 10:20:37 AM
On Sun, 05 Sep 2004 05:17:12 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Standard COBOL (thru the '85 Standard at least) definitely DOES require a 
>paragraph (or section and paragraph) at the beginning of the Procedure Division. 
>Some, not all, compilers didn't require this - but flagged it as an extension 
>when non-standard flagging was turned on.

The 2002 Standard does not require a paragraph at the beginning. 

An old, mostly '74, Realia compiler issues a warning when there are no
paragraph names at all, but doesn't require one at the beginning. This
suggests the '74 standard required at least one paragraph name. I
don't have a copy to check.

>-- 
>Bill Klein
> wmklein <at> ix.netcom.com
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
>news:pn2kj09tp9j4eketmhjq8rbhbicl68kcd7@4ax.com...
>> On Sat, 04 Sep 2004 12:50:25 -0500, LX-i <lxi0007@netscape.net> wrote:
>>
>>>Howard Brazee wrote:
>>>> If you were inventing CoBOL back when, what would you do differently?
>>>
>>>Probably just a few minor changes...
>>>
>>>   - Fall-through pararaphs - only the first paragraph after "PROCEDURE
>>>DIVISION" would be fallen through.
>>
>> Cobol doesn't require a paragraph name after the  PROCEDURE DIVISION
>> header. You don't PERFORM or GO TO it; it serves no function. Just
>> leave it out. 
>

0
robert6624 (636)
9/5/2004 2:17:18 PM
On 4 Sep 2004 21:54:36 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
>
>> CONSTANT SECTION was in the early standards. It was later dropped ..
>> in 85, I'm fairly sure.
>
>I see no evidence of that at all.
>
>It was not in 74 or 68.  Nor is it a change in 68 so I doubt that it was in 61.

A Google news search found this in CLC, 1995:

In article <3rqmks$vdm@darwin.nbnet.nb.ca> , morrisc@nbnet.nb.ca
writes:
>While I want to review your posting on the X3J4 meeting before 
>commenting, I would be interested in the reason for not bringing 
>back the CONSTANT SECTION (it was a part of COBOL 61 or 63).  

Reply by Don Nelson (nelson_don@tandem.com)
I think the reason that the Constant Section was dropped from the 
first standard (COBOL '68) was that there were no rules about what 
could be done with such items.  For example, they could easily be 
receiving items (there was no rule that prohibited this).  Rather than
putting in such a rule (and invalidating some existing programs), the 
ANSI committee decided to drop it. 
0
robert6624 (636)
9/5/2004 2:42:34 PM
On 5 Sep 2004 05:41:31 -0400, docdwarf@panix.com wrote:

>In article <qs2lj0drh9aqc2rm2uh07tbad5fch3ahvh@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>On 4 Sep 2004 19:03:48 -0400, docdwarf@panix.com wrote:

>>I suppose most MVS shops had FileAid and SynchSort. I won't proffer an
>>estimate 'cause I haven't worked in that many. It's safe to say the
>>initiative came from programmers, who had to cajole and justify the
>>expense. It didn't come from management. 
>
>I am uncertain of the origin as well, Mr Wagner, but remember that such 
>tools cost money and that (among other things) the allocation of budget is 
>a responsibility of management.  Consider... a shop doesn't have these 
>tools until a given programmer is promoted to management and thus has say 
>over budget.  Whence comes the 'initiative', then?

Consider BMC. IBM's VSE operating system is nearly impossible to
administer 'out of the box'. BMC sold most-have tools that made it
usable. I managed a VSE shop in the early '80s, did not have budget
authority, but INSISTED we buy BMC. I got it. Many others must have
done the same because  BMC's founder, John Jay Moores, became the
first software billionaire when Microsoft was just getting started.

>>>>It's worse in the Unix world because the standard text editor -- vi --
>>>>sucks big time. It's so bad that it's unusable, IMO. I wind up copying
>>>>files to my desktop, editing there and copying back.
>>>
>>>'Pico?  Too delicate for vi, are we... why not go all out, then, and just 
>>>use a Mac?'

I've heard of but not used Pico. It's old. The number two Unix editor,
emacs, is pretty good. It's distributed with the operating system by
Sun and HP, at least. Problem is, many shops don't install it.

>>>>Also, they have control tables that
>>>>take the mystery out of record layouts. One can approach a database
>>>>without prior knowledge, without outside documentation, and quickly
>>>>see what's in it. If he has a $500 tool like Toad running on his
>>>>desktop, he can be productive immediately. 
>>>
>>>Toad is for Oracle, Mr Wagner... DB2 can be, like a few other IBM 
>>>products, a bit more mysterious.
>>
>>Aren't there tools like Toad for DB2? No?
>
>I've never heard of one, Mr Wagner... and a Google search for "toad for 
>db2" (quotes included) brings up none-too-many hits.  The most instructive 
>seems to be:
>
>http://www.db2mag.com/story/showArticle.jhtml?articleID=25600500#3
>
>--begin quoted text:
>
>Product News for Quarter 3, 2004
>
>[snip]
>
>Toad for DB2
>
>Quest Software is working on bringing the Toad application development 
>tool to DB2 customers.
>
>--end quoted text

BMC and Platinum already own that market. Quest (Toad) must be brave
to go head-to-head against BMC. 

>>Economy of scale. Yes? You
>>must be talking about FileAid for DB2. It's good for queries but not
>>an administrative tool.
>
>I am an apps jockey, Mr Wagner; I leave administrating to the 
>administrators.

If you have an ODBC connection to DB2, you already have a very good
application tool in msquery. It comes with Excel, but can run
standalone as well. It's  as good as FileAid and it's 'free'.

0
robert6624 (636)
9/5/2004 3:36:09 PM
Constant Section preceeded 77,  88

Warren

Richard wrote:
> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
> 
> 
>>CONSTANT SECTION was in the early standards. It was later dropped ..
>>in 85, I'm fairly sure.
> 
> 
> I see no evidence of that at all.
> 
> It was not in 74 or 68.  Nor is it a change in 68 so I doubt that it was in 61.
0
wsimmons5 (172)
9/5/2004 5:55:51 PM
In article <44CdneTmj_GfIqTcRVn-tA@giganews.com>,
 "JerryMouse" <nospam@bisusa.com> wrote:

> Robert Wagner wrote:
> >>   Who says all of
> >> WORKING-STORAGE *has to be* in a monolithic block that is
> >> unconditionally resident for the life of the program?
> >
> >
> > The vast majority of mainstream Cobol programmers think
> > working-storage has to be a monolithic block. It doesn't matter what's
> > offered by the standard or compiler. They'll keep doing it 'the way
> > they were taught' (mostly autodactation) until the day the die.
> 
> Not that there's anything wrong with that.
> 

Anything wrong with what?

That they treat all storage as a universally available monolithic block?

That they will continue to do so?

Or that they will die?

0
9/5/2004 8:29:42 PM
Richard wrote:

> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
> 
> 
>>CONSTANT SECTION was in the early standards. It was later dropped ..
>>in 85, I'm fairly sure.
> 
> 
> I see no evidence of that at all.
> 
> It was not in 74 or 68.  Nor is it a change in 68 so I doubt that it was in 61.
I know that it was in the RCA 301 COBOL that I used in 1963 - 1966.  I 
think it was in the '61 or '63 version of the standard.  Actually I 
thought the standards were 1961, then 1963, 1968, etc.

0
cfmtech (125)
9/5/2004 8:35:40 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> >'Pico?  Too delicate for vi, are we... why not go all out, then, and just 
> >use a Mac?'
> 
> Macs are for aging hippies.

These days Macs run Unix - a BSD variety.
 
> DB2 has good performance, but administration frustrates even seasoned
> DBAs. Changes seldom work right the first time. For ease of
> maintenance, I'd rank databases from best to worst:
> 
> Informix
> SQLServer/Sybase
> Oracle
> DB2/UDB

You had made a comment that you had not seen db admin done from
programs. I couldn't see why this was not so.  Then I found one
reason:

In PostgreSQL admin functions are transactional.  For example a
program can add a field to a table and then populate that field as one
transaction and then commit.  Other accesses to that table will only
see the added fields after the commit and so can continue to access,
but may notice that the rows are locked.

There is no need, as there seems to be in Oracle, of taking down the
db for this admin, so it can safely be put in a db check funtion in
the program.

> For performance:
> 
> Informix
> DB2/UDB
> Oracle
> SQLServer/Sybase

For read only performance, such as driving web sites, nothing beats
MySQL.

OTOH, it's not much chop at update performance.
0
riplin (4127)
9/6/2004 2:13:38 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> It's worse in the Unix world because the standard text editor -- vi --
> sucks big time. It's so bad that it's unusable, IMO. I wind up copying
> files to my desktop, editing there and copying back.

The Unix world comes with _several_ text editors, it is only necessary
to change your preferences to another from those already installed or
by installing some other.

But then vi is only 'unusable' to those who haven't learned to use it,
just like any other tool.

Personally, I find Midnight Commander and SetEdit suit my needs, but I
can use vi if I have to.
0
riplin (4127)
9/6/2004 2:44:27 AM
LX-i wrote:
> 
> Peter Lacey wrote:
> > LX-i wrote:
> >
> >>Peter Lacey wrote:
> >>
> >>>If I were inventing it now: I'd require AT END and INVALID KEY with READ
> >>>statements (as appropriate); I would not have some verbs, especially
> >>>EVALUATE (hey! you did say "if YOU were inventing Cobol"!  And despite
> >>>study, explanations and examples, I've yet to come across a case where
> >>>an evaluate couldn't be done more clearly and usually simpler with IF's
> >>>and/or CASE statments).
> >>
> >>And EVALUATE differs from a CASE statement *how*, exactly?  That's
> >>COBOL's version of a case statement.  :)
> >>
> >
> > The mind boggles!
> >
> > Let me ask you first:  how many languages are you fluent in?  That will
> > determine how I reply.
> 
> Mostly English - a little bit of Spanish...  ;)

mas agua caliente, por favor ...

> 
> I've worked in COBOL, VB, Ada, Java, PHP, and a wee bit of C++ and FORTRAN.
> 


Me: COBOL, RPG, 360-style assembler, FORTRAN (a long time ago), PRIME
Infobasic, and PROGRESS: plus a bit of VB and a tiny bit of C.  I have
seen two styles of CASE implementation:

BEGIN CASE
 CASE x = y
....
 CASE b = a
....
 CASE TRUE  (i.e., the default)
....
END CASE

or

CASE variable
 WHEN value
....
 WHEN another value
....
 ELSE (default)
END CASE.

The second is much more precise and far more focused.

I see from somebody else's post that EVALUATE was implemented to encode
decision tables (which I didn't know);  that gives it a rationale; but
it's still an abomination.  You can equate various aspects of EVALUATE
to either style, as you please.


(Please note that I don't have an up-to-date COBOL reference).
PL
0
lacey (134)
9/6/2004 5:10:50 PM
In article <413752b1$0$20257$cc9e4d1f@news-text.dial.pipex.com>,
 "Michael Russell" <michael.russell@spamex.dsl.pipex.com> wrote:

> The biggest omission, as far as I'm concerned - Date, DateTime & Time types,
> plus the arithmetic functions for them.
> 
> Michael
> 
> 

Amen!

0
9/6/2004 11:03:52 PM
In article <413C9A1A.A5F7E136@mb.sympatico.ca>,
 Peter Lacey <lacey@mb.sympatico.ca> wrote:

> LX-i wrote:
> > 
> > Peter Lacey wrote:
> > > LX-i wrote:
> > >
> > >>Peter Lacey wrote:
> > >>
> > >>>If I were inventing it now: I'd require AT END and INVALID KEY with READ
> > >>>statements (as appropriate); I would not have some verbs, especially
> > >>>EVALUATE (hey! you did say "if YOU were inventing Cobol"!  And despite
> > >>>study, explanations and examples, I've yet to come across a case where
> > >>>an evaluate couldn't be done more clearly and usually simpler with IF's
> > >>>and/or CASE statments).
> > >>
> > >>And EVALUATE differs from a CASE statement *how*, exactly?  That's
> > >>COBOL's version of a case statement.  :)
> > >>
> > >
> > > The mind boggles!
> > >
> > > Let me ask you first:  how many languages are you fluent in?  That will
> > > determine how I reply.
> > 
> > Mostly English - a little bit of Spanish...  ;)
> 
> mas agua caliente, por favor ...
> 
> > 
> > I've worked in COBOL, VB, Ada, Java, PHP, and a wee bit of C++ and FORTRAN.
> > 
> 
> 
> Me: COBOL, RPG, 360-style assembler, FORTRAN (a long time ago), PRIME
> Infobasic, and PROGRESS: plus a bit of VB and a tiny bit of C.  I have
> seen two styles of CASE implementation:
> 
> BEGIN CASE
>  CASE x = y
> ...
>  CASE b = a
> ...
>  CASE TRUE  (i.e., the default)
> ...
> END CASE
> 
> or
> 
> CASE variable
>  WHEN value
> ...
>  WHEN another value
> ...
>  ELSE (default)
> END CASE.
> 
> The second is much more precise and far more focused.
> 
> I see from somebody else's post that EVALUATE was implemented to encode
> decision tables (which I didn't know);  that gives it a rationale; but
> it's still an abomination.  You can equate various aspects of EVALUATE
> to either style, as you please.
> 
> 
> (Please note that I don't have an up-to-date COBOL reference).
> PL

The second style is a subset of EVALUATE.  You can code, and have it be 
completely legal and reasonable:

   EVALUATE some-number
      WHEN 1
         ...do something...
      WHEN 2
         ...do something else...
      WHEN 3
         ...do something else...
      WHEN 4
         ...do something else...
      WHEN OTHER
         ...do something else...
   END-EVALUATE

This is exactly your second style from above.

Some of the problems with that type of CASE structures, in some 
languages, is that it is sometimes the case (-;) that the value of 
"some-number" must be known at compile time.

But Cobol Evaluate offers a much richer type of case, which you are 
never forced to use if you prefer the simple case above.  Cobol Evaluate 
allows you to define the condition as an expression or a variable.  It 
allows multiple conditions to be evaluated at once.  Finally, it allows 
you to use literals, variables or expressions in the when clauses.

It is totally flexible.

0
9/6/2004 11:32:31 PM
In article <ei9mj0lh7jp8vlvf162a7d7kg9s8d719ae@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 5 Sep 2004 05:41:31 -0400, docdwarf@panix.com wrote:
>
>>In article <qs2lj0drh9aqc2rm2uh07tbad5fch3ahvh@4ax.com>,
>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>On 4 Sep 2004 19:03:48 -0400, docdwarf@panix.com wrote:
>
>>>I suppose most MVS shops had FileAid and SynchSort. I won't proffer an
>>>estimate 'cause I haven't worked in that many. It's safe to say the
>>>initiative came from programmers, who had to cajole and justify the
>>>expense. It didn't come from management. 
>>
>>I am uncertain of the origin as well, Mr Wagner, but remember that such 
>>tools cost money and that (among other things) the allocation of budget is 
>>a responsibility of management.  Consider... a shop doesn't have these 
>>tools until a given programmer is promoted to management and thus has say 
>>over budget.  Whence comes the 'initiative', then?
>
>Consider BMC. IBM's VSE operating system is nearly impossible to
>administer 'out of the box'. BMC sold most-have tools that made it
>usable. I managed a VSE shop in the early '80s, did not have budget
>authority, but INSISTED we buy BMC.

All right, let me see if I have this straight... someone who manages a 
shop is, by definition, management; if you were managing a shop and the 
initiative came from you then, by definition, the initiative came from 
management.

[snip]

>>>Aren't there tools like Toad for DB2? No?
>>
>>I've never heard of one, Mr Wagner... and a Google search for "toad for 
>>db2" (quotes included) brings up none-too-many hits.  The most instructive 
>>seems to be:
>>
>>http://www.db2mag.com/story/showArticle.jhtml?articleID=25600500#3
>>
>>--begin quoted text:
>>
>>Product News for Quarter 3, 2004
>>
>>[snip]
>>
>>Toad for DB2
>>
>>Quest Software is working on bringing the Toad application development 
>>tool to DB2 customers.
>>
>>--end quoted text
>
>BMC and Platinum already own that market.

Mr Wagner, this is odd... you ask 'Aren't there tools like Toad for DB2? 
No?', I respond with a link showing that Toad is not yet ready for DB2 and 
you reply with 'BMC and Platinum already own that market.'

If you knew who 'owned the market' what might have been your reason for 
asking if tools like another, similar tool existed for it?

 Quest (Toad) must be brave
>to go head-to-head against BMC. 

>
>>>Economy of scale. Yes? You
>>>must be talking about FileAid for DB2. It's good for queries but not
>>>an administrative tool.
>>
>>I am an apps jockey, Mr Wagner; I leave administrating to the 
>>administrators.
>
>If you have an ODBC connection to DB2, you already have a very good
>application tool in msquery. It comes with Excel, but can run
>standalone as well. It's  as good as FileAid and it's 'free'.

Thanks for the advice, Mr Wagner; I'll try to keep it in mind for when 
next I find myself in a DB2 shop.

DD

0
docdwarf (6044)
9/7/2004 12:41:22 AM
On 5 Sep 2004 19:13:38 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

>You had made a comment that you had not seen db admin done from
>programs. I couldn't see why this was not so.  Then I found one
>reason:
>
>In PostgreSQL admin functions are transactional.  For example a
>program can add a field to a table and then populate that field as one
>transaction and then commit.  Other accesses to that table will only
>see the added fields after the commit and so can continue to access,
>but may notice that the rows are locked.
>
>There is no need, as there seems to be in Oracle, of taking down the
>db for this admin, so it can safely be put in a db check funtion in
>the program.

The big difference between SQL-92 and SQL-99 was moving administration
into *standardized* transactional SQL, called DCL (as opposed to data
manipulation, called DML). Under 92, administration was an
implementor-defined 'extension'. It could be 100% offline; it could be
kinda-sorta like the 99 standard, as is the case with PostgreSQL;  it
could do the easy stuff in non-standard SQL and the hard stuff
offline, as was the case with Oracle prior to version 8i. 

By 2000, all commercial databases had gone to the 99 standard with the
notable exception of Oracle, which held out until version 8i (2002?).
Open source and inexpensive databases, specifically MySQL and
PostgreSQL, are not yet on the 99 standard to the best of my
knowledge. Thus, they are not better than their 99 standard-conformant
competition. At best, they're almost as good.

Standardized DCL means more than 'administration from within a
program', it also means Remote Administration, which is much more
important in terms of cost-saving. Remote doesn't mean logging on via
telnet, it means doing administration through an ODBC connection. It
means $600 programs like Toad, running on a PC, can administer any
database.

I don't recall the specific comment I made, but it was referring to
the SQL-92 environment. 

>For read only performance, such as driving web sites, nothing beats
>MySQL.

I don't dispute that. Users pay a price because they have to program
features provided  by other databases.

>OTOH, it's not much chop at update performance.

I take it 'much chop' means 'very good'. :)

0
robert6624 (636)
9/7/2004 1:58:09 AM
On 5 Sep 2004 19:44:27 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
>
>> It's worse in the Unix world because the standard text editor -- vi --
>> sucks big time. It's so bad that it's unusable, IMO. I wind up copying
>> files to my desktop, editing there and copying back.
>
>The Unix world comes with _several_ text editors, it is only necessary
>to change your preferences to another from those already installed or
>by installing some other.

On a 'certified' system, only certified software can be installed.
Remember the infamous emacs flaw used in The Coocoo's Egg?
If it comes with the operating system and is supported by the OS
company, that's usually good enough, but not always. It depends on the
security tyrant's mood at the moment. Some of them have a negative
attitude about open source, shareware and freeware. I had one
uninstall SAMBA, even though it's distributed and supported by Sun.

The solution: edit on another platform. UltraEdit is good for this. It
automatically FTPs the file to a PC when loading, FTPs back when
saving.

>But then vi is only 'unusable' to those who haven't learned to use it,
>just like any other tool.
>
>Personally, I find Midnight Commander and SetEdit suit my needs, but I
>can use vi if I have to.

I too can use vi if I have to.

0
robert6624 (636)
9/7/2004 1:58:12 AM
On 6 Sep 2004 20:41:22 -0400, docdwarf@panix.com wrote:

>In article <ei9mj0lh7jp8vlvf162a7d7kg9s8d719ae@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:

>All right, let me see if I have this straight... someone who manages a 
>shop is, by definition, management; if you were managing a shop and the 
>initiative came from you then, by definition, the initiative came from 
>management.

Yes, but I didn't have authority to Spend More Money. I had to justify
the expense to executives.

>>>>Aren't there tools like Toad for DB2? No?
>>>
>>>I've never heard of one, Mr Wagner... and a Google search for "toad for 
>>>db2" (quotes included) brings up none-too-many hits.  
>>
>>BMC and Platinum already own that market.
>
>Mr Wagner, this is odd... you ask 'Aren't there tools like Toad for DB2? 
>No?', I respond with a link showing that Toad is not yet ready for DB2 and 
>you reply with 'BMC and Platinum already own that market.'
>
>If you knew who 'owned the market' what might have been your reason for 
>asking if tools like another, similar tool existed for it?

It was an rhetorical question, an opportunity for you to deride my
deficient knowledge and an opportunity for more incisive commentary.

Although these companies own the market, they are not like Toad. They
don't run on a PC and they don't sell for $600. Could an inexpensive
tool defeat them purely on cost? Or would mainframers' disdain for
'toy computers' defend their turf? In the end, the issue is social
rather than technical. 


0
robert6624 (636)
9/7/2004 2:57:12 AM
In article <r97qj0tphnr9ab5t3iku5l9e6arfvvujeb@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 6 Sep 2004 20:41:22 -0400, docdwarf@panix.com wrote:
>
>>In article <ei9mj0lh7jp8vlvf162a7d7kg9s8d719ae@4ax.com>,
>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>
>>All right, let me see if I have this straight... someone who manages a 
>>shop is, by definition, management; if you were managing a shop and the 
>>initiative came from you then, by definition, the initiative came from 
>>management.
>
>Yes, but I didn't have authority to Spend More Money. I had to justify
>the expense to executives.

Yes, but your original assertion was that such initiatives came from 
programmers, not management.  Curious that you would support this 
assertion with an example of the opposite.

>
>>>>>Aren't there tools like Toad for DB2? No?
>>>>
>>>>I've never heard of one, Mr Wagner... and a Google search for "toad for 
>>>>db2" (quotes included) brings up none-too-many hits.  
>>>
>>>BMC and Platinum already own that market.
>>
>>Mr Wagner, this is odd... you ask 'Aren't there tools like Toad for DB2? 
>>No?', I respond with a link showing that Toad is not yet ready for DB2 and 
>>you reply with 'BMC and Platinum already own that market.'
>>
>>If you knew who 'owned the market' what might have been your reason for 
>>asking if tools like another, similar tool existed for it?
>
>It was an rhetorical question, an opportunity for you to deride my
>deficient knowledge and an opportunity for more incisive commentary.

Your knowledge seems obvious enough, Mr Wagner, and some opportunities can 
slip past, ungrasped... Such is Life.

>
>Although these companies own the market, they are not like Toad. They
>don't run on a PC and they don't sell for $600. Could an inexpensive
>tool defeat them purely on cost? Or would mainframers' disdain for
>'toy computers' defend their turf? In the end, the issue is social
>rather than technical. 

In the end - at least 'the end' as it appears to exist not - I do not have 
sufficient data to agree or disagree with this.

DD

0
docdwarf (6044)
9/7/2004 9:17:57 AM
On 7 Sep 2004 05:17:57 -0400, docdwarf@panix.com wrote:

>In article <r97qj0tphnr9ab5t3iku5l9e6arfvvujeb@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>On 6 Sep 2004 20:41:22 -0400, docdwarf@panix.com wrote:
>>
>>>In article <ei9mj0lh7jp8vlvf162a7d7kg9s8d719ae@4ax.com>,
>>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>
>>>All right, let me see if I have this straight... someone who manages a 
>>>shop is, by definition, management; if you were managing a shop and the 
>>>initiative came from you then, by definition, the initiative came from 
>>>management.
>>
>>Yes, but I didn't have authority to Spend More Money. I had to justify
>>the expense to executives.
>
>Yes, but your original assertion was that such initiatives came from 
>programmers, not management.  Curious that you would support this 
>assertion with an example of the opposite.

I was wearing two hats. The request came from the programmer side, was
approved by the manager side and passed up the ladder.

I said the need for BMC on VSE came from programmers because
non-technical managers would not perceive it. It wouldn't have been
mentioned by  the IBM salesman nor aforementioned magazines.
0
robert6624 (636)
9/7/2004 11:03:44 AM
In article <ip4rj0dogs04bdrile3fugk9lsf44m4347@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 7 Sep 2004 05:17:57 -0400, docdwarf@panix.com wrote:
>
>>In article <r97qj0tphnr9ab5t3iku5l9e6arfvvujeb@4ax.com>,
>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>On 6 Sep 2004 20:41:22 -0400, docdwarf@panix.com wrote:
>>>
>>>>In article <ei9mj0lh7jp8vlvf162a7d7kg9s8d719ae@4ax.com>,
>>>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>
>>>>All right, let me see if I have this straight... someone who manages a 
>>>>shop is, by definition, management; if you were managing a shop and the 
>>>>initiative came from you then, by definition, the initiative came from 
>>>>management.
>>>
>>>Yes, but I didn't have authority to Spend More Money. I had to justify
>>>the expense to executives.
>>
>>Yes, but your original assertion was that such initiatives came from 
>>programmers, not management.  Curious that you would support this 
>>assertion with an example of the opposite.
>
>I was wearing two hats.

Ahhhhh, of course... it should have been obvious that you were 
demonstrating the existence of bicephalic anomalies.

DD

0
docdwarf (6044)
9/7/2004 11:29:16 AM
On 7 Sep 2004 07:29:16 -0400, docdwarf@panix.com wrote:

>In article <ip4rj0dogs04bdrile3fugk9lsf44m4347@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>On 7 Sep 2004 05:17:57 -0400, docdwarf@panix.com wrote:
>>
>>>In article <r97qj0tphnr9ab5t3iku5l9e6arfvvujeb@4ax.com>,
>>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>>On 6 Sep 2004 20:41:22 -0400, docdwarf@panix.com wrote:
>>>>
>>>>>In article <ei9mj0lh7jp8vlvf162a7d7kg9s8d719ae@4ax.com>,
>>>>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>>
>>>>>All right, let me see if I have this straight... someone who manages a 
>>>>>shop is, by definition, management; if you were managing a shop and the 
>>>>>initiative came from you then, by definition, the initiative came from 
>>>>>management.
>>>>
>>>>Yes, but I didn't have authority to Spend More Money. I had to justify
>>>>the expense to executives.
>>>
>>>Yes, but your original assertion was that such initiatives came from 
>>>programmers, not management.  Curious that you would support this 
>>>assertion with an example of the opposite.
>>
>>I was wearing two hats.
>
>Ahhhhh, of course... it should have been obvious that you were 
>demonstrating the existence of bicephalic anomalies.

I didn't write that, the other guy did. 

I'm off now to an Orientation at the unemployment office. Good thing
... I'm so disoriented. 

0
robert6624 (636)
9/7/2004 11:52:40 AM
In article <i68rj0ti1gkg8l7tn9bn9pcp6gnoev0pdp@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 7 Sep 2004 07:29:16 -0400, docdwarf@panix.com wrote:
>
>>In article <ip4rj0dogs04bdrile3fugk9lsf44m4347@4ax.com>,
>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>On 7 Sep 2004 05:17:57 -0400, docdwarf@panix.com wrote:
>>>
>>>>In article <r97qj0tphnr9ab5t3iku5l9e6arfvvujeb@4ax.com>,
>>>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>>>On 6 Sep 2004 20:41:22 -0400, docdwarf@panix.com wrote:
>>>>>
>>>>>>In article <ei9mj0lh7jp8vlvf162a7d7kg9s8d719ae@4ax.com>,
>>>>>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>>>
>>>>>>All right, let me see if I have this straight... someone who manages a 
>>>>>>shop is, by definition, management; if you were managing a shop and the 
>>>>>>initiative came from you then, by definition, the initiative came from 
>>>>>>management.
>>>>>
>>>>>Yes, but I didn't have authority to Spend More Money. I had to justify
>>>>>the expense to executives.
>>>>
>>>>Yes, but your original assertion was that such initiatives came from 
>>>>programmers, not management.  Curious that you would support this 
>>>>assertion with an example of the opposite.
>>>
>>>I was wearing two hats.
>>
>>Ahhhhh, of course... it should have been obvious that you were 
>>demonstrating the existence of bicephalic anomalies.
>
>I didn't write that, the other guy did. 

Sure, that's what they *all* say... or at least half of them.

>
>I'm off now to an Orientation at the unemployment office. Good thing
>.. I'm so disoriented. 

I got re-oriented by finding China on a map... interesting that the state 
you're dealing with has such things; here in Maryland one can go for 
months and months without seeing the inside of an unemployment office, it 
can all be taken care of by telephone and/or web.  Makes sense, in a 
way... there would have to be a tremendous amount of fraud to make offices 
more cost-effective than this new remote setup... on the other hand, when 
did civil service decisions ever have a base in economic 'sense'?

DD

0
docdwarf (6044)
9/7/2004 12:34:12 PM
On  3-Sep-2004, Warren Simmons <wsimmons5@optonline.net> wrote:

> Memory may fail me, but
> as I recall, Burroughs was the only participant who did not care if
> SECTIONS were added or not.

This was way before IBM "invented" virtual memory.
0
howard (6283)
9/7/2004 1:38:31 PM
On  3-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:

> > Still, if CoBOL was invented that the only way to get to a paragraph was to
> > perform it, coders back then wouldn't have had any problem writing code.
>
> They simply would have ignored the language as being 'broken'.  One
> reason why Cobol succeeded was that programmers could move most of
> their existing code from commercial languages to it. And all their
> existing techniques.

Which languages were ported to CoBOL?   Autocoder?   Fortran?    Assembler?  
Those didn't port well.   I worked at a shop that moved from RPG to CoBOL.   It
didn't port at all.

I don't think that was why CoBOL succeeded.   
0
howard (6283)
9/7/2004 1:42:20 PM
On  4-Sep-2004, LX-i <lxi0007@netscape.net> wrote:

>    - Fall-through pararaphs - only the first paragraph after "PROCEDURE
> DIVISION" would be fallen through.  Of course, this mandates scope
> delimiters for PERFORM, IF, etc. (which we currently have).

Why have any fall through paragraphs at all?   Without any being allowed, we
don't need scope delimiters.   I don't see the advantage of having one fall
through paragraph.

>    - User-defined functions that can return values - this goes along
> with the point above.  You could say something like "MOVE FUNCTION
> DATE-FORMAT (ws-some-var) TO FORMATTED-DATE", and have that function
> return the character string.

Also have the function return an error code that can be checked without aborting
when the function fails.
0
howard (6283)
9/7/2004 1:49:48 PM
In article <v92qj0la20o04upld2p1aekgerlv2d825e@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
> On 5 Sep 2004 19:44:27 -0700, riplin@Azonic.co.nz (Richard) wrote:
> 
> >Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
> >
> >> It's worse in the Unix world because the standard text editor -- vi --
> >> sucks big time. It's so bad that it's unusable, IMO. I wind up copying
> >> files to my desktop, editing there and copying back.

Yet many, many people are very productive with vi.  I generally use
vim, these days, as I like some of the additional features, but most
of what I do in it is supported by vi as well.

I've used many programming editors, on many platforms, and some of them
(OS/400's SEU comes to mind) did indeed suck.  vi, on the other hand,
is tremendously efficient and powerful.  Maybe the problem is you.

> Remember the infamous emacs flaw used in The Coocoo's Egg?

That wasn't a bug in emacs; Cliff Stoll's analysis was wrong.  The
emacs process shouldn't have had permission to overwrite atrun; since
it did, no amount of "checking" by it would have sufficed to plug the
security hole.  It was either an OS implementation flaw or adminis-
trative error; which one is not clear from Stoll's account.

Cliff Stoll, though an entertaining writer, a swell guy, and a noted
manufacturer of three-dimensional injections of Klein bottles, is not
a security expert, and _The Coocoo's Egg_ should not be treated as a
security textbook.

Not that any of this is relevant to the question of whether a user
is allowed to have emacs on a given Unix system.

> The solution: edit on another platform.

Or learn to use vi.  Thousands have.  (Or, of course, you could learn
one of the other editors that are included in any standard Unix system,
per the Single Unix Specification, though I don't imagine they'd be
any more to your taste.  Or you could write your own editor; since it
wouldn't have any capabilities you don't already have from the command
line, it's not any more of a security risk than you are.)

-- 
Michael Wojcik                  michael.wojcik@microfocus.com

You have Sun saying, "Who needs Linux? We have Solaris."  You have
Microsoft saying, "Who needs Linux? We have Windows 2000."  Then you
have IBM saying, "I think we all need Linux."  Only the greatest
sinners know how to really repent.  -- John Patrick, IBM VP
0
mwojcik (1879)
9/7/2004 2:58:51 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:chkdrs$l2e$1@peabody.colorado.edu...

> I worked at a shop that moved from RPG to CoBOL.   It
> didn't port at all.

If you had the right tools, it might.  As I remember the history, Burroughs'
first effort at RPG (on the B2500/B3500?) was the COFIRS translator which
transformed RPG source files into COBOL.  Burroughs' next big effort in this
language was RPG for the B1000, which produced the same object code as the
original COBOL compiler on that system (remember, each language had its own
instruction set on that system), and was pretty much based on a combination
of COFIRS and COBOL.  An instruction set specifically for RPG came quite a
bit later; I don't know how much they had to change the compiler, though.

    -Chuck Stevens


0
9/7/2004 3:31:29 PM
 On  3-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:
> 
> > > Still, if CoBOL was invented that the only way to get to a paragraph was to
> > > perform it, coders back then wouldn't have had any problem writing code.
> >

I've got news for you.  Programmers back then didn't have any problems
writing code.  

In any language, at any time, programmers become familiar with the
language as it is and write within its limits.  Problems that they may
have, then or now, are caused by faulty planning or misuse of language
features (such as a subscript  with a value of zero).  

Richard surely didn't mean they would have had NO problems - just one
particular kind.  In any case, he's wrong.



PL
0
lacey (134)
9/7/2004 3:34:46 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:chkdkn$jvu$1@peabody.colorado.edu...
>
> On  3-Sep-2004, Warren Simmons <wsimmons5@optonline.net> wrote:
>
> > Memory may fail me, but
> > as I recall, Burroughs was the only participant who did not care if
> > SECTIONS were added or not.
>
> This was way before IBM "invented" virtual memory.

I once thought it was a legend that on the very day IBM announced that
"invention", Burroughs executives were holding a coctail party celebrating
the anniversary of its introduction on the B5000 some ten years earlier, but
I have since then seen evidence that this actually took place.

    -Chuck Stevens



0
9/7/2004 3:35:25 PM
On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> > I worked at a shop that moved from RPG to CoBOL.   It
> > didn't port at all.
>
> If you had the right tools, it might.  As I remember the history, Burroughs'
> first effort at RPG (on the B2500/B3500?) was the COFIRS translator which
> transformed RPG source files into COBOL.  Burroughs' next big effort in this
> language was RPG for the B1000, which produced the same object code as the
> original COBOL compiler on that system (remember, each language had its own
> instruction set on that system), and was pretty much based on a combination
> of COFIRS and COBOL.  An instruction set specifically for RPG came quite a
> bit later; I don't know how much they had to change the compiler, though.

If you have the right tools, I suppose you're right.   I'm awfully glad we
didn't have the right tools.

(I am *not* a fan of such conversions).
0
howard (6283)
9/7/2004 4:09:11 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:n1dij05d8lhrr45sb8ml17obajjggmqf1r@4ax.com...

> You know what they say about people who refer to themselves in the
> third person. :)
>
> To me, a structured constant is a typedef with values.

To me, a structured constant looks, at least underneath the covers, a whole
lot more like an ALGOL value array with COBOL record capabilities (which
ALGOL lacks).

> It also looks
> like an OO constructor.

Yes, it could be viewed that way, but it specifically avoids any OO
philosophies or prerequisites.  It looks a WHOLE LOT MORE like a COBOL
record in WORKING-STORAGE, except that the implementation is prohibited from
allowing any reference to it as a destination.

> It says (to the compiler) construct one of
> these things and initialize it like this.

Sort of; it also says to the compiler "If you have a way at execution time
in which this record can be rendered immutable, you are free to make use of
it, but in any event access to it or to any part of it as a destination is
to be prohibited."

> A simpler solution would have been TYPEDEF INITIALIZED.

Would it, now?  And what of those on the WG4 committee who absolutely
forbade that this mechanism either require any OO feature or syntax for its
implementation or use?   The objective here is to take a good old COBOL-85
(or -74 or -68 or -60) record and somehow "protect" it from execution-time
modification.

CONSTANT SECTION was a feature of "standard" COBOL until it was deleted in
the 1969 edition of the JOD and apparently it was eliminated from X3.23-1968
by a similar process.  Structured constants are a whole lot more like
records declared in the CONSTANT SECTION -- with the additional proviso of
defined values for FILLERs  and un-VALUEd items, and the ability to declare
them in places other than the CONSTANT SECTION -- than they are to any OO
solution.   The project came, in fact, as a response to the request that the
committee consider *reinstating* the CONSTANT SECTION to standard COBOL.
For a variety of reasons, J4 thinks structured constants are a better idea
overall than either reinstating the CONSTANT SECTION or requiring the user
to learn OO techniques, and it's my understanding from what I heard at the
WG4 meeting last year that they do too.

    -Chuck Stevens


0
9/7/2004 4:12:05 PM
The first immediate stimuli for the Structured Constant paper were Don
Nelson's paper J4/02-0005 and your paper J4/02-0008, both with the same
title "Constant section enhancement".

Don's paper is precipitated by his experience as a CICS developer and
essentially argues for the (re)instatement of the Constant Section (deleted
from "pre-first-standard COBOL in the 1969 JOD).

Yours, which explicitly supports his, appears to be based on the "78-level
model" in the Micro Focus implementation (and perhaps others).  Although you
have used 78's in your defense of the concept, I don't see a suggestion in
your paper that 78-level items are anything but a feature that can be used
in any program, not one limited to use in methods.  I agreed with the
sentiment -- that allowing constant records anywhere rather than restricting
them to a single section was a good idea -- but disagreed with the syntax,
finding it too restrictive and perhaps misleading.

Subsequent to these, John Piggott submitted J4/03-0092, Access modes for
records in memory, which allowed definition-only, read-only, read-write, and
write-only modes.

I attempted to defend John's concepts at the COBOL workshop that immediately
preceded the June 2003 WG4 meeting as well as at the WG4 meeting itself.
The various approaches were discussed at length -- CONSTANT section,
78-level items, and John's ACCESS MODE proposal.  While the functionality of
"access mode is read-only" received enthusiastic support, the other "access
modes" nor the syntax did not; something involving "constant" was
overwhelmingly preferred.

Note also that the attendees at the workshop (as well as the delegates to
the WG4 meeting), were *decidedly* against making this an "OO-oriented"
feature, or in fact anything that couldn't be characterized as inherently an
OO feature that would be meaningless in "native COBOL".    That's why the
only proposal "on the boards" for XML handling is *native* COBOL syntax, not
OO methodology.

 > Sometimes the background history can be fascinating. Get on the right
> side of Bill K. and he can sure tell you some fascinating tales about J4
> and why things turned out in a particular way.

I became the primary Unisys representative to INCITS/J4 effective with
meeting #228 in Carmel, California and have missed one meeting since then.
Although I'm sure Mr. Klein Bill Klein keeps up with the flow of documents
on the J4 website, the only meetings Mr. Klein seems to have attended since
I became a member were the next two meetings, namely, #229 in February 2001
and #230 in April 2001.  By Meeting #232 in the fall of 2001 he had changed
his membership from "voting" to "advisory".  I believe Bill attended the WG4
meeting in May 2000, but none since.

Thus, Bill may have intimate knowledge of what went on up to the middle of
2001, but he wasn't around for most of the discussion that led to the
current form of Structured Constants.

My first draft of the Structured Constants paper, J4/03-0188 dated July 23,
2003 was the result of those directions from the workshop and from the WG4
meeting in response to John Piggott's paper as well as Don's and yours.

After three further drafts, J4/04-0056 was approved by J4 for incorporation
into the draft for the next standard at J4 meeting #246 in April 2004.  I
took some care to record the discussions and the decisions in the "history"
section of the approved document, q.v.

    -Chuck Stevens


0
9/7/2004 6:24:54 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:bu4kj0pqtrfr1mgbj2ncj0cbd4jjr8rjuk@4ax.com...

> CONSTANT SECTION was in the early standards. It was later dropped ..
> in 85, I'm fairly sure.

Whether it was "standard" or not is a matter of terminology and opinion.
"First standard COBOL" was ANSI X3.23-1968, and it doesn't seem to be there,
although some implementations (including Burroughs Large System COBOL(68),
for compatibility reasons) provided it.  It is definitely not in '74 or '85.

The "History of COBOL" section of the '74 standard explicitly states that
CONSTANT SECTION was dropped by the CODASYL Programming Language Committee
in the 1969 Journal of Development.  My guess is that this got dropped from
the ANSI standards effort by consensus between CODASYL and X3J4 sometime
before the publication of CIB #9, though I have no means of verifying that.
The IBM DOS COBOL(68) reference manual makes no mention of it; the Unisys A
Series COBOL(68) documentation does, but it didn't do a good job of
indicating extensions to ANSI-68 COBOL, and its presence in that dialect is
justifiable for reasons of compatibility by its presence in the COBOL-60
implementation on the Burroughs B6500.

    -Chuck Stevens


0
9/7/2004 6:45:26 PM
For those wanting to read the approved paper, it is available at:

 http://www.cobolportal.com/j4/files/04-0056.doc

It may or may not be exactly how I would have defined it, but I (personally) 
don't (quickly) see any problems with it. (I am a little amused that it looks to 
me as if you CAN use both 66-level Renames and Reference modification with it, 
but even that isn't a real problem (just slightly odd).

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message 
news:chkudn$cq7$1@si05.rsvl.unisys.com...
> The first immediate stimuli for the Structured Constant paper were Don
> Nelson's paper J4/02-0005 and your paper J4/02-0008, both with the same
> title "Constant section enhancement".
>
> Don's paper is precipitated by his experience as a CICS developer and
> essentially argues for the (re)instatement of the Constant Section (deleted
> from "pre-first-standard COBOL in the 1969 JOD).
>
> Yours, which explicitly supports his, appears to be based on the "78-level
> model" in the Micro Focus implementation (and perhaps others).  Although you
> have used 78's in your defense of the concept, I don't see a suggestion in
> your paper that 78-level items are anything but a feature that can be used
> in any program, not one limited to use in methods.  I agreed with the
> sentiment -- that allowing constant records anywhere rather than restricting
> them to a single section was a good idea -- but disagreed with the syntax,
> finding it too restrictive and perhaps misleading.
>
> Subsequent to these, John Piggott submitted J4/03-0092, Access modes for
> records in memory, which allowed definition-only, read-only, read-write, and
> write-only modes.
>
> I attempted to defend John's concepts at the COBOL workshop that immediately
> preceded the June 2003 WG4 meeting as well as at the WG4 meeting itself.
> The various approaches were discussed at length -- CONSTANT section,
> 78-level items, and John's ACCESS MODE proposal.  While the functionality of
> "access mode is read-only" received enthusiastic support, the other "access
> modes" nor the syntax did not; something involving "constant" was
> overwhelmingly preferred.
>
> Note also that the attendees at the workshop (as well as the delegates to
> the WG4 meeting), were *decidedly* against making this an "OO-oriented"
> feature, or in fact anything that couldn't be characterized as inherently an
> OO feature that would be meaningless in "native COBOL".    That's why the
> only proposal "on the boards" for XML handling is *native* COBOL syntax, not
> OO methodology.
>
> > Sometimes the background history can be fascinating. Get on the right
>> side of Bill K. and he can sure tell you some fascinating tales about J4
>> and why things turned out in a particular way.
>
> I became the primary Unisys representative to INCITS/J4 effective with
> meeting #228 in Carmel, California and have missed one meeting since then.
> Although I'm sure Mr. Klein Bill Klein keeps up with the flow of documents
> on the J4 website, the only meetings Mr. Klein seems to have attended since
> I became a member were the next two meetings, namely, #229 in February 2001
> and #230 in April 2001.  By Meeting #232 in the fall of 2001 he had changed
> his membership from "voting" to "advisory".  I believe Bill attended the WG4
> meeting in May 2000, but none since.
>
> Thus, Bill may have intimate knowledge of what went on up to the middle of
> 2001, but he wasn't around for most of the discussion that led to the
> current form of Structured Constants.
>
> My first draft of the Structured Constants paper, J4/03-0188 dated July 23,
> 2003 was the result of those directions from the workshop and from the WG4
> meeting in response to John Piggott's paper as well as Don's and yours.
>
> After three further drafts, J4/04-0056 was approved by J4 for incorporation
> into the draft for the next standard at J4 meeting #246 in April 2004.  I
> took some care to record the discussions and the decisions in the "history"
> section of the approved document, q.v.
>
>    -Chuck Stevens
>
> 


0
wmklein (2605)
9/7/2004 6:50:06 PM
"Howard Brazee" <howard@brazee.net> wrote 

> Which languages were ported to CoBOL?   

Flow-Matic, Commercial Translator, and FACT for a start.

> Autocoder?   Fortran?    Assembler?  
> Those didn't port well.   

Assembler techniques were available (such as ALTER) otherwise
assembler programmers would have complained that Cobol was not
suitable.

> I worked at a shop that moved from RPG to CoBOL.   It
> didn't port at all.

No it wouldn't.  But then RPG (IMHO) doesn't do anything well.
 
> I don't think that was why CoBOL succeeded.

It was a reason why it didn't fail completely.
0
riplin (4127)
9/7/2004 7:12:12 PM
"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
news:2q1bobFqejkcU1@uni-berlin.de...

> I know that it was in the RCA 301 COBOL that I used in 1963 - 1966.  I
> think it was in the '61 or '63 version of the standard.  Actually I
> thought the standards were 1961, then 1963, 1968, etc.

Early on, while CODASYL was responsible for the *development* of the COBOL
language, what later became J4 was responsible for its *standardization*.

There were a number of official CODASYL versions of COBOL:  COBOL-60 (the
original specification for the language); COBOL-61;  COBOL-61 Extended; and
COBOL, Edition 1965 were apparently published "as such".  Subsequent stages
reflect published versions of CODASYL's Journal of Development in 1968,
1969, 1970, 1973,m 1976, 1978, 1981 and 1984.  As I understand it, the
CODASYL COBOL committee and ANSI X3J4 merged around this time.

CODASYL eliminated the CONSTANT SECTION in 1969 as reflected in the JoD of
that year.

 ANSI X3.23-1968, the first USA Standard COBOL, does not appear to have
contained the CONSTANT SECTION, although many implementations of that
dialect (including our own) included that feature for compatibility with
earlier COBOL implementations.

    -Chuck Stevens


0
9/7/2004 7:15:49 PM
"LX-i" <lxi0007@netscape.net> wrote in message
news:Cfn_c.43711$5s3.25919@fe40.usenetserver.com...

>    - Fall-through pararaphs - only the first paragraph after "PROCEDURE
> DIVISION" would be fallen through.  Of course, this mandates scope
> delimiters for PERFORM, IF, etc. (which we currently have).

Ooog  ... Add a paragraph label in the middle of code in an existing program
and suddenly it doesn't fall through to what used to be the second
paragraph?    I'd be mighty uncomfortable with such a rule ...

    -Chuck Stevens


0
9/7/2004 7:20:51 PM
On  7-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:

> > I don't think that was why CoBOL succeeded.
>
> It was a reason why it didn't fail completely.

I guess we'll agree to disagree.
0
howard (6283)
9/7/2004 7:30:50 PM
On 7 Sep 2004 08:34:12 -0400, docdwarf@panix.com wrote:

>... interesting that the state 
>you're dealing with has such things; here in Maryland one can go for 
>months and months without seeing the inside of an unemployment office, it 
>can all be taken care of by telephone and/or web. 

For $180/wk more (490-310), I can tolerate a one time orientation. It
wasn't checking for fraud, it was about training available and
placement help -- free computer, telephone, Web listing, etc. Some of
them will benefit. 

0
robert6624 (636)
9/7/2004 7:46:07 PM
On Tue, 7 Sep 2004 13:42:20 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>On  3-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:
>
>> > Still, if CoBOL was invented that the only way to get to a paragraph was to
>> > perform it, coders back then wouldn't have had any problem writing code.
>>
>> They simply would have ignored the language as being 'broken'.  One
>> reason why Cobol succeeded was that programmers could move most of
>> their existing code from commercial languages to it. And all their
>> existing techniques.
>
>Which languages were ported to CoBOL?   Autocoder?   Fortran?    Assembler?  
>Those didn't port well.   I worked at a shop that moved from RPG to CoBOL.   It
>didn't port at all.
>
>I don't think that was why CoBOL succeeded.   

When Cobol first appeared in 1959-61, most Cobol programmers came from
an assembly language background -- Autocoder and/or 7090 -- with a
minority, from Fortran. Their bread-and-butter control mechanism was
Branch. If Cobol hadn't had GO TO, I probably wouldn't have used it.
0
robert6624 (636)
9/7/2004 7:46:08 PM
On 7 Sep 2004 14:58:51 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>In article <v92qj0la20o04upld2p1aekgerlv2d825e@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
>> On 5 Sep 2004 19:44:27 -0700, riplin@Azonic.co.nz (Richard) wrote:
>> 
>> >Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
>> >
>> >> It's worse in the Unix world because the standard text editor -- vi --
>> >> sucks big time. It's so bad that it's unusable, IMO. I wind up copying
>> >> files to my desktop, editing there and copying back.
>
>Yet many, many people are very productive with vi.  

I've seen one or two who were good at vi. The vast majority stumble
and project inefficiency.

>I've used many programming editors, on many platforms, and some of them
>(OS/400's SEU comes to mind) did indeed suck.  vi, on the other hand,
>is tremendously efficient and powerful.  Maybe the problem is you.

The problem is an editor that doesn't let you overtype changes, how
basic is that?, doesn''t have Find All, doesn't let you navigate
between files except by sequential cycling, doesn't support
hyperlinks, doesn't let you open multiple windows, etc. etc.

>> Remember the infamous emacs flaw used in The Coocoo's Egg?

>Cliff Stoll, though an entertaining writer, a swell guy, and a noted
>manufacturer of three-dimensional injections of Klein bottles, is not
>a security expert, and _The Coocoo's Egg_ should not be treated as a
>security textbook.

You're right, of course, but he's often invited to speak and consult
on computer security. He built a career off that book. If I'd been so
lucky, I would have taken the trouble to learn more about the topic.

> Or you could write your own editor; since it
>wouldn't have any capabilities you don't already have from the command
>line, it's not any more of a security risk than you are.)

Bingo. I did. 

0
robert6624 (636)
9/7/2004 7:46:08 PM
On Tue, 7 Sep 2004 13:49:48 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>On  4-Sep-2004, LX-i <lxi0007@netscape.net> wrote:

>>    - User-defined functions that can return values - this goes along
>> with the point above.  You could say something like "MOVE FUNCTION
>> DATE-FORMAT (ws-some-var) TO FORMATTED-DATE", and have that function
>> return the character string.
>
>Also have the function return an error code that can be checked without aborting
>when the function fails.

How? There is only one RETURN-CODE. If there are two functions in a
statement, you don't know which returned an error.

0
robert6624 (636)
9/7/2004 7:46:09 PM
On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> >    - Fall-through pararaphs - only the first paragraph after "PROCEDURE
> > DIVISION" would be fallen through.  Of course, this mandates scope
> > delimiters for PERFORM, IF, etc. (which we currently have).
>
> Ooog  ... Add a paragraph label in the middle of code in an existing program
> and suddenly it doesn't fall through to what used to be the second
> paragraph?    I'd be mighty uncomfortable with such a rule ...

Not if that was the way the language had been from the beginning.
0
howard (6283)
9/7/2004 7:56:59 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:iscij015s0h8to660uehaog7lbnkjqvbdo@4ax.com...
> >   Who says all of
> >WORKING-STORAGE *has to be* in a monolithic block that is unconditionally
> >resident for the life of the program?
>
> The culture says so.

Whose culture?  Certainly not mine!

What, pray tell, is the advantage of a monolithic WORKING-STORAGE except for
the possibility that the implementation might allow the user to corrupt his
own data by indexing outside of a record?

> It sounds like you're referring to dynamic memory allocation in lieu
> of working-storage.

No, I'm referring to an implementation that doesn't have anything but
dynamic memory allocation.  You seem to feel there's some obligation that
any two adjacent 01-level records in working-storage are allocated next to
each other in memory.  What's the point of that?

> If that's done, there would be at least one
> POINTER in the program.

No, not unless you think That Which Allows Access to a Memory Space in
hardware is identical to a USAGE POINTER data item in COBOL ...

> Neither allocate nor pointer was available in
> the 85 standard, but they were in IBM mainframe Cobol.

Well, goody for them!

> When I worked
> at the largest US brokerage house, I had access to much of their Cobol
> source -- many thousands of programs. Out of curiosity, I did a search
> for POINTER. There were  none.

Don't doubt that.

> The vast majority of mainstream Cobol programmers think
> working-storage has to be a monolithic block.

And, again, why should it be?   What possible reason does the end user have
to care one way or another?

> It doesn't matter what's
> offered by the standard or compiler. They'll keep doing it 'the way
> they were taught' (mostly autodactation) until the day the die.

And what exactly might the programmer do differently, aside from force the
compiler to override range checking and go indexing into the wrong record?

>  what's *the* compiler front-end?
>
> The front-end translates Cobol to intermediate code, as opposed to the
> back-end, which translates intermediate to machine code.

What's intermediate code?   Are there compilers that don't produce object
code directly?

> >> > I've never understood the particular utility of calling
> >> >a program one time with a parameter BY REFERENCE and the next time BY
> >VALUE,
> >>
> >> That's not utility, that's an error.
> >
> >No, it's *explicitly* allowed by COBOL
>
> There is some miscommunication here due to an error.

> BY CONTENT copies the thing and passes a pointer to the copy
> BY VALUE      puts word-sized things directly into the parameter list

There's no requirement in the standard that a CALL statement with a BY
CONTENT paarameter make a copy or pass a pointer to the copy in either the
'85 or '02 standard, only that the called program not be able to change the
calling program's version of the data.

> You got them backwards.

Got *what* backwards?  I used the terms "by content" and "by reference", not
"by content" and "by value".

> I didn't, so calling with a pointer one time
> and a value another time is always an error. Yes, Cobol does allow you
> to do that .. I think.

Orthogonal to COBOL's requirements.  COBOL is *not* obligated to pass a
"pointer" unless the programmer has specified that you pass a pointer.  All
BY REFERENCE is obligated to do is to *act as if* the caller and the callee
share the same memory space, not that they actually do so, and all BY
CONTENT is required to do is to prevent the callee from accessing the
caller's memory space.  There's nothing to prevent an implementor from
making copies of the actual data in *both* cases.

> >That's actually one of the big differences:  COBOL allows just about
> >anything to be passed BY [CONTENT]; the procedural languages didn't.
>
> Yes, that's not an option in other languages. They offer BY REFERENCE
> and BY VALUE.

.... and BY NAME and READ-ONLY and PROCEDURAL and FUNCTIONAL ...

       -Chuck Stevens


0
9/7/2004 8:23:39 PM
In article <peorj0pu6pvq0g3oi34f0soclar7orl701@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 7 Sep 2004 08:34:12 -0400, docdwarf@panix.com wrote:
>
>>... interesting that the state 
>>you're dealing with has such things; here in Maryland one can go for 
>>months and months without seeing the inside of an unemployment office, it 
>>can all be taken care of by telephone and/or web. 
>
>For $180/wk more (490-310), I can tolerate a one time orientation. It
>wasn't checking for fraud, it was about training available and
>placement help -- free computer, telephone, Web listing, etc. Some of
>them will benefit. 

How curious... I've never heard of such a thing but it'd seem to make 
sense.  Ah well... next time I come down I won't have to worry about such 
things, I'm 1099 on this gig.

DD

0
docdwarf (6044)
9/7/2004 8:39:50 PM
On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> What, pray tell, is the advantage of a monolithic WORKING-STORAGE except for
> the possibility that the implementation might allow the user to corrupt his
> own data by indexing outside of a record?

Unfortunately, that need existed for a long time when people had bigger tables
than their version of CoBOL would support.
0
howard (6283)
9/7/2004 8:50:10 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:h2rhj0laki7m79s47rtatijjm0prgcal3f@4ax.com...
>
> On Fri, 3 Sep 2004 08:54:15 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
> >"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> >news:kajgj0lk8r0hgcs9eqj8u2lea41r0nit5k@4ax.com...
> >
> >
> >> If the objective is a language that's robust, portable and
> >> predictable, seems to me that Standard Warnings would help Cobol
> >> toward that ideal.
> >
> >Then the presence of Standard Warnings, and a list of things every
> >implementor should be required to warn about, is the underlying idea.
I'd
> >suggest you write a proposal that it be added to the candidates list,
> >together with a *list* of warnings you think ought to be included.
>
> How to compile such a list:
> .. Start with messages issued by a 2002 compiler
>       Do-able
> .. Delete messages related to non-standard extensions
>       Requires expert knowledge of 2002 & 2008 standards
>       I'm not that expert
> .. Delete messages not important enough to make the cut
>       Do-able

I think this is short-sighted so long as it's *not* enclosed by a PERFORM
UNTIL all 2002-compliant, and preferably all supported, implementations of
COBOL have been examined!

> .. Add the one about condition always true/false
> .. Write rules about how to determine same
>      All literals is easy. How about a variable that never changes?
>      Never change must distinguish between call by reference/value.
>      If the only call is to a nested program that doesn't change it
>      and doesn't call outside by reference, it didn't change.

A whole lot of this is imposing a lot of COMPILE-TIME analysis involving
inter-statement relationships that the standard does not impose.  Is a
significant increase in compile-time resource requirements worth it to you?
Can you guarantee that enough users would regard such an increase as a
worthy sacrifice to obtain the functionality to "shout down" those who would
scream bloody murder?

>     Watch  out for pass via GLOBAL.
>     Watch out for EXTERNAL.
>     Watch out for changes via REDEFINES and group names.

Yeah ...

>     Deal with ESQL references. How?

Well, first you have to define what an ESQL reference is in *standard* COBOL
....

> Finally, realize the warning will be issued only when the compiler is
> in standard-compliant mode. Has anyone ever used that, outside the
> lab?  Maybe some government project .. once .. a long time ago.
>
> On second thought, it's not worth the effort.

Well, that's kind of what I thought.  And it's not just the effort, it's the
compile-time overhead imposed on *all* users of the language.

> >Only because all the arguments are literals.  The condition might always
be
> >false anyway, even if the PERFORM control items are variables.
>
> See above.

And see above for my concerns about compile-time analysis of inter-statement
flow regardless of the complexity and size of the PROCEDURE DIVISION!


> I ASSumed it was supported for two reasons:
> .. I use them routinely in Micro Focus.
> .. Logic. Why would the standard create logical literals and then not
> permit them in conditional expressions? That's illogical.

When did the standard create "logical literals?"  They did add a pair of
keywords *keyword* that have meaning in three contexts -- the SET statement
(only for use with 88's), the EVALUATE directive (only with TRUE, only in a
format *distinct from* the use of a literal and only in the context of a
constant-conditional-expression) and the EVALUATE statement (only as a
selection-object which *isn't* a literal), but they didn't add the concept
of a "logical literal" so far as I can see.

> I refuse to write PERFORM UNTIL FALSE. It is common usage in other
> languages as DO FOREVER and WHILE TRUE. It implies on an explicit exit
> will be issued.

Well, it does if you ASSume every program *must* terminate in an orderly
fashion if they terminate!   Not every program *must* conform to that
requirement ...

> Premature exits are for exceptions. The normal exit
> condition should be expressible in loop control.

Why?    I agree that this could be a *stylistic* issue, but I'm not clear
that the cleanest implementation I've seen (or heard of) of Dijkstra's
philosophies *really needed* anything other than DO [FOREVER] and UNDO.

I have heard suggestions that the DO <blockname> [FOREVER] and UNDO
<blockname> also available in the language were "cheating", but then again,
these elements seem to have been implemented in the language that was
specifically inspired by Dijkstra's published articles, during (as I
understand it) the very time that Dijkstra was at Burroughs. and I haven't
heard that he objected  ...

    -Chuck Stevens


0
9/7/2004 9:15:22 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:chl6u2$m95$1@peabody.colorado.edu...
>
> On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> > What, pray tell, is the advantage of a monolithic WORKING-STORAGE except
for
> > the possibility that the implementation might allow the user to corrupt
his
> > own data by indexing outside of a record?
>
> Unfortunately, that need existed for a long time when people had bigger
tables
> than their version of CoBOL would support.

And I'd characterize that as *hardly* the sort of behavior the COBOL
standards committee should be called upon to support!

    -Chuck Stevens


0
9/7/2004 9:16:48 PM
On Thu, 2 Sep 2004 18:05:09 +0100, "Michael Russell"
<michael.russell@spamex.dsl.pipex.com> wrote:

>The biggest omission, as far as I'm concerned - Date, DateTime & Time types,
>plus the arithmetic functions for them.

TYPEDEF lets you  create Date and DateTime types. Functions
date-of-integer and integer-of-date let you do arithmetic .. in one
statement without storing the intermediate. For example, 

01  yyyymmdd typedef.
     05  yyyy      pic  9(4).
     05  mm        pic  9(2).
     05  dd         pic  9(2).

01  a-record.
  05  some-date     yyyymmdd.

compute thirty-days-later  = 
    date-of-integer (integer-of-date(some-date) + 30)
0
robert6624 (636)
9/7/2004 9:22:15 PM
On Tue, 7 Sep 2004 12:20:51 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"LX-i" <lxi0007@netscape.net> wrote in message
>news:Cfn_c.43711$5s3.25919@fe40.usenetserver.com...
>
>>    - Fall-through pararaphs - only the first paragraph after "PROCEDURE
>> DIVISION" would be fallen through.  Of course, this mandates scope
>> delimiters for PERFORM, IF, etc. (which we currently have).
>
>Ooog  ... Add a paragraph label in the middle of code in an existing program
>and suddenly it doesn't fall through to what used to be the second
>paragraph?    I'd be mighty uncomfortable with such a rule ...

Those who use structured programming are not uncomfortable. 

What's the new paragraph name to be used for? Target of a GO TO?

0
robert6624 (636)
9/7/2004 9:22:15 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:ov8sj09og72tif22rsmisl7mtrfc7k1l6j@4ax.com...
> On Tue, 7 Sep 2004 12:20:51 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
> >"LX-i" <lxi0007@netscape.net> wrote in message
> >news:Cfn_c.43711$5s3.25919@fe40.usenetserver.com...
> >
> >>    - Fall-through pararaphs - only the first paragraph after "PROCEDURE
> >> DIVISION" would be fallen through.  Of course, this mandates scope
> >> delimiters for PERFORM, IF, etc. (which we currently have).
> >
> >Ooog  ... Add a paragraph label in the middle of code in an existing
program
> >and suddenly it doesn't fall through to what used to be the second
> >paragraph?    I'd be mighty uncomfortable with such a rule ...
>
> Those who use structured programming are not uncomfortable.
>
> What's the new paragraph name to be used for? Target of a GO TO?
>

Can a paragraph-name be used simply to subdivide logic into more visible or
more meaningful (or even smaller) blocks of source statements?  There's
nothing now, nor has there ever been, any *requirement* that paragraph-names
have any *object-time* function, so far as I know ...

    -Chuck Stevens


0
9/7/2004 9:26:08 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:gr7sj0dojf1b1s1qlocvigaevfubik81q9@4ax.com...
> On Thu, 2 Sep 2004 18:05:09 +0100, "Michael Russell"
> <michael.russell@spamex.dsl.pipex.com> wrote:
>
> >The biggest omission, as far as I'm concerned - Date, DateTime & Time
types,
> >plus the arithmetic functions for them.
>
> TYPEDEF lets you  create Date and DateTime types. Functions
> date-of-integer and integer-of-date let you do arithmetic .. in one
> statement without storing the intermediate. For example,
>
> 01  yyyymmdd typedef.
>      05  yyyy      pic  9(4).
>      05  mm        pic  9(2).
>      05  dd         pic  9(2).
>
> 01  a-record.
>   05  some-date     yyyymmdd.
>
> compute thirty-days-later  =
>     date-of-integer (integer-of-date(some-date) + 30)

This provides for Date values, but how does it provide for DateTime, or for
that matter, Time, manipulation, using standard representations?

    -Chuck Stevens


0
9/7/2004 9:46:39 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:chl3qb$kfp$1@peabody.colorado.edu...
>
> On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> > >    - Fall-through pararaphs - only the first paragraph after
"PROCEDURE
> > > DIVISION" would be fallen through.  Of course, this mandates scope
> > > delimiters for PERFORM, IF, etc. (which we currently have).
> >
> > Ooog  ... Add a paragraph label in the middle of code in an existing
program
> > and suddenly it doesn't fall through to what used to be the second
> > paragraph?    I'd be mighty uncomfortable with such a rule ...
>
> Not if that was the way the language had been from the beginning.

I'd still be uncomfortable with a language specification in which control
would fall through the second, and *only* the second, paragraph in a
program.

I don't see that the standard for COBOL should *enforce* structure to a
program, only that it should *allow* and *support* it.

    -Chuck Stevens


0
9/7/2004 9:50:24 PM
Chuck,
  I think the point (as I read it) is that "if we knew then - what we know now" 
*and* we were inventing (from scratch) what became COBOL, would it (or would it 
not) have been "better" to not allow/define "fall-thru".

IMHO,
  It would have been better if (and this canNOT be changed now)

A) there was *no* "thru procedure-name-2" syntax (Perform, Input/Output 
procedure, etc)
B) no Go To (but there was an "EXIT PERFORMED-PROCEDURE" statement
C) and of course, no ALTER
D) and (I am a little wishy-washy on this one) there were ONLY paragraphs or 
ONLY sections, not both
E) I would have wanted CONTINUE, scope-terminators, and probably (not certain on 
this one either) no NEXT SENTENCE
F) I probably wouldn't want DECLARATIVES either - as they are (sort-of by 
definition) "non-structured"

I think that every current type of program could have been created with these 
restrictions *and* I think (but can't prove it) that such a language would have 
insured "easier to maintain" programs.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message 
news:chlaf0$kuh$1@si05.rsvl.unisys.com...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:chl3qb$kfp$1@peabody.colorado.edu...
>>
>> On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>>
>> > >    - Fall-through pararaphs - only the first paragraph after
> "PROCEDURE
>> > > DIVISION" would be fallen through.  Of course, this mandates scope
>> > > delimiters for PERFORM, IF, etc. (which we currently have).
>> >
>> > Ooog  ... Add a paragraph label in the middle of code in an existing
> program
>> > and suddenly it doesn't fall through to what used to be the second
>> > paragraph?    I'd be mighty uncomfortable with such a rule ...
>>
>> Not if that was the way the language had been from the beginning.
>
> I'd still be uncomfortable with a language specification in which control
> would fall through the second, and *only* the second, paragraph in a
> program.
>
> I don't see that the standard for COBOL should *enforce* structure to a
> program, only that it should *allow* and *support* it.
>
>    -Chuck Stevens
>
> 


0
wmklein (2605)
9/7/2004 10:33:10 PM
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:FGq%c.943557$6p.164444@news.easynews.com...
> Chuck,
>   I think the point (as I read it) is that "if we knew then - what we know
now"
> *and* we were inventing (from scratch) what became COBOL, would it (or
would it
> not) have been "better" to not allow/define "fall-thru".

I understand the premise, but I'm also not fond of "if pigs had wings ..."
speculations.  What I've personally been focusing on is given what we know
now what would we now regard as *wrong* in COBOL.    I think "abbreviated
combined relation conditions" is one, and I think deciding how a parameter
is processed *in a called program* at the level of the *call* is another.
Both have intrinsic problems in specification, I believe.

In fact, I just thought of another:  Even in its current form COBOL's
support for currency signs is decidedly provincial.  As I read the standard,
I can't get COBOL to produce a *floating* version of the most common
designator for the Venezuelan unit of currency.  Why should England and the
US have preferential support from PICTURE?  I think the floating
currency-sign was implemented for the US currency unit, and lo and behold it
works for the British pound, but beyond that it starts falling apart!  I
haven't found a way to float the four-character sequence "Bs. " using the
syntax in 2002 COBOL and the PICTURE clause with all its appendages yet!

Speculation as to what would have happened if Dijkstra had written his
papers twenty years earlier than he did doesn't strike me as helpful -- any
more than "What would COBOL look like if somebody had invented Java in its
present form in 1957?" or "If a machine with a 512-megabyte main memory, a
2.8GHz processor, a 160-gigabyte hard drive, and built-in 100MHz data
communications capability could have been bought over-the-counter at your
local office supply store for $799 in 1968, what would a 'large machine'
have looked like at the time, and who would have actually needed one?"
I think the issues of "structured programming" are *style choice* issues,
and I don't think the *standards* should enforce a particular *style* any
more than I think

That being said,

> IMHO,
>   It would have been better if (and this canNOT be changed now)
>
> A) there was *no* "thru procedure-name-2" syntax (Perform, Input/Output
> procedure, etc)

Not sure.  I'm of the school that doesn't have a problem with GO TO -- so
long as its use is limited to the <paragraph-name-EXIT> of the paragraph I'm
in.  EXIT PARAGRAPH and EXIT SECTION provide good support for structure
here.

> B) no Go To (but there was an "EXIT PERFORMED-PROCEDURE" statement

And the latter I agree with -- when I saw EXIT PERFORM one of the first
things I did was implement it as an extension to our COBOL74 implementation
(there were also compatibility issues based on our lack of the equivalent
EXIT HERE available as an extension to our '68 implementation).  COBOL74
doesn't even allow inline PERFORM, but I haven't yet figured out why it was
disallowed in other contexts in the '02 standard.  Is there a solid argument
against it, aside from the idea of gradual introduction of the feature?

EXIT PARAGRAPH and EXIT SECTION are big helps here.   I'd vote for allowing
all three in all procedural contexts!

> C) and of course, no ALTER

And that I agree with as well ... though I can still see *some* very limited
utility to segment-numbers in an old-fashioned sort of way ...

> D) and (I am a little wishy-washy on this one) there were ONLY paragraphs
or
> ONLY sections, not both

Well, I think if nothing else there are *cosmetic* reasons for both, and
I've already said having both could be useful in "modularizing" programs at
a more atomic level than nested programs, at both the source and object code
levels.

> E) I would have wanted CONTINUE, scope-terminators, and probably (not
certain on
> this one either) no NEXT SENTENCE

I agree with you, and in the case of NEXT SENTENCE, with the 2002 standard
which deprecates its use.  If you presume the presence of scope-terminators
in the language NEXT SENTENCE is not of much use at best.  The standard
deprecates its use in IF and SEARCH, and those are the only cases in which
it's defined in the standard, so far as I know.   The biggest problem with
NEXT SENTENCE is that some users came to think it really meant NEXT
STATEMENT, and to make matters worse some implementors actually did it that
way!

> F) I probably wouldn't want DECLARATIVES either - as they are (sort-of by
> definition) "non-structured"

Well, hm.  They're also the closest thing COBOL has to asynchronous
processing, which is on the "desirable" list for the '08 draft  ...

> I think that every current type of program could have been created with
these
> restrictions *and* I think (but can't prove it) that such a language would
have
> insured "easier to maintain" programs.

True, they could (well, maybe not the last ...); not clear whether it would
be "easier to maintain" if you were used to a language that had, for
example, GO TO.   What would English be like if William the Conqueror had
read the OED from cover to cover or had a laptop to look words up in the
online Webster's?

    -Chuck Stevens


0
9/7/2004 11:26:34 PM
"Howard Brazee" <howard@brazee.net> wrote

> If you have the right tools, I suppose you're right.   I'm awfully glad we
> didn't have the right tools.
> 
> (I am *not* a fan of such conversions).

As with any conversion between languages, one may not wind up with 'a
Cobol program' but with an 'RPG program in the syntax of the Cobol
language'.

There was once a Datamation report (in the late 70s I think) that
compared 'maintenance' effort versus 'new development' effort.  This
found that at Cobol shops some high percentage of programmer time was
'maintenance' while at C shops it was low.

They concluded that if the Cobol programs were converted to C then the
maintenance requirement would be much lower and thus more new
development could be done.

I suspect that some management may have believed this clueless hack.
0
riplin (4127)
9/7/2004 11:41:50 PM
William M. Klein wrote:

>Chuck,
>  I think the point (as I read it) is that "if we knew then - what we know now" 
>*and* we were inventing (from scratch) what became COBOL, would it (or would it 
>not) have been "better" to not allow/define "fall-thru".
>
>IMHO,
>  It would have been better if (and this canNOT be changed now)
>
>A) there was *no* "thru procedure-name-2" syntax (Perform, Input/Output 
>procedure, etc)
>B) no Go To (but there was an "EXIT PERFORMED-PROCEDURE" statement
>C) and of course, no ALTER
>D) and (I am a little wishy-washy on this one) there were ONLY paragraphs or 
>ONLY sections, not both
>E) I would have wanted CONTINUE, scope-terminators, and probably (not certain on 
>this one either) no NEXT SENTENCE
>F) I probably wouldn't want DECLARATIVES either - as they are (sort-of by 
>definition) "non-structured"
>
>I think that every current type of program could have been created with these 
>restrictions *and* I think (but can't prove it) that such a language would have 
>insured "easier to maintain" programs.
>
>  
>
Boy oh boy oh boy - and here's me claiming you are one of the standard 
bearers for (F) Declaratives. Too late - I've already sent it !

But taking your point , "If we were starting from scratch", I'll return 
to an old theme - OO SEPARATE from PROCEDURAL -particularly at PC Level. 
And 'Yes' bring in those bloody GUI features to PC-OO.

Of the course the anti-GUI brigade , "You can NEVER have GUIs as part of 
COBOL". Anybody ever stop to think - apart from their own GUIs provided 
by Fujitsu, Micro Focus, Liant's Wow, CA-Realia using CA tools, 
Accu-COBOL, the most popular GUI tools are those from Flexus - SP2 and 
Norcomm's Screen-IO. Funny thing is they are both written in C - so 
where does C, C++ or C# have the edge - where's the problem for OO COBOL 
- I would suggest largely a constraint by trying to push mainframes and 
PCs through the same door, making both fit, and ignoring what isn't 
common - i.e., COBOL does not acknowledge different O/S.

And our rather 'stodgy' approach to the Standards - if Bill Gates whips 
in a fresh one like 'transparent dialog",  Flexus, Norcomm and the C 
and  Java families probably react immediately. (I've seen a screen shot 
posted in M/F's Answer Exchange; you are looking through the dialog at 
the underlying screen.. One reaction was 'cool', mine was 'why ?'). To 
keep abreast of Bill G., the above reluctantly have to introduce it.,

Jimmy, Calgary AB
0
jjgavan (507)
9/7/2004 11:46:24 PM
"Howard Brazee" <howard@brazee.net> wrote 

> Also have the function return an error code that can be checked without aborting
> when the function fails.

That is difficult to do when a function can only return a single
value.

For example NUMVAL() can return any value validly.  It cannot return
an 'error code' that is not a valid return value.

Also functions may be buried in expressions that will use the return
as part of the calculation.  What would happen if a function returned
an 'error code' and this was used by the calculation ?

Exceptions are one way of dealing with this issue.  The function
raises an exception which must be caught or passed on.
0
riplin (4127)
9/8/2004 12:03:43 AM
On Tue, 7 Sep 2004 13:23:39 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:iscij015s0h8to660uehaog7lbnkjqvbdo@4ax.com...
>> >   Who says all of
>> >WORKING-STORAGE *has to be* in a monolithic block that is unconditionally
>> >resident for the life of the program?
>>
>> The culture says so.
>
>Whose culture?  Certainly not mine!

IBM mainframe culture, and compilers that mimic IBM's memory model.

>What, pray tell, is the advantage of a monolithic WORKING-STORAGE except for
>the possibility that the implementation might allow the user to corrupt his
>own data by indexing outside of a record?

The topic is memory management, not bug detection. If you want to
catch such bugs, turn on bounds checking. Don't depend on memory
management to catch them. 

>> It sounds like you're referring to dynamic memory allocation in lieu
>> of working-storage.
>
>No, I'm referring to an implementation that doesn't have anything but
>dynamic memory allocation.  

Modern IBM dynamically allocates working-storage, but still as one
monolithic chunk.

>You seem to feel there's some obligation that
>any two adjacent 01-level records in working-storage are allocated next to
>each other in memory.  What's the point of that?

I didn't support that idea; IBM did. 

>> The vast majority of mainstream Cobol programmers think
>> working-storage has to be a monolithic block.
>
>And, again, why should it be?   What possible reason does the end user have
>to care one way or another?

Because the programmer (end user) often has to read memory dumps, so
must be aware of the memory model in order to find things.

>> It doesn't matter what's
>> offered by the standard or compiler. They'll keep doing it 'the way
>> they were taught' (mostly autodactation) until the day the die.
>
>And what exactly might the programmer do differently, aside from force the
>compiler to override range checking and go indexing into the wrong record?

Move structures from working-storage to linkage section and
dynamically allocate/free them. I do it routinely. The reason has
nothing to do with range checking.

>>  what's *the* compiler front-end?
>>
>> The front-end translates Cobol to intermediate code, as opposed to the
>> back-end, which translates intermediate to machine code.
>
>What's intermediate code?   Are there compilers that don't produce object
>code directly?

Acu and R/M don't. When viewed from the outside, most compilers appear
to produce object code 'directly'. Internally, they are  going through
intermediate code, which makes it possible to use the same front-end
on multiple platforms. Do you think Micro Focus, Fujitsu and IBM start
from scratch every time a platform is added? They just write another
back-end.

>> >> > I've never understood the particular utility of calling
>> >> >a program one time with a parameter BY REFERENCE and the next time BY
>> >VALUE,
>> >>
>> >> That's not utility, that's an error.
>> >
>> >No, it's *explicitly* allowed by COBOL
>>
>> There is some miscommunication here due to an error.
>
>> BY CONTENT copies the thing and passes a pointer to the copy
>> BY VALUE      puts word-sized things directly into the parameter list
>
>There's no requirement in the standard that a CALL statement with a BY
>CONTENT paarameter make a copy or pass a pointer to the copy in either the
>'85 or '02 standard, only that the called program not be able to change the
>calling program's version of the data.
>
>> You got them backwards.
>
>Got *what* backwards?  I used the terms "by content" and "by reference", not
>"by content" and "by value".

You MEANT reference and content, but you SAID reference and value.

>> I didn't, so calling with a pointer one time
>> and a value another time is always an error. Yes, Cobol does allow you
>> to do that .. I think.
>
>Orthogonal to COBOL's requirements.  COBOL is *not* obligated to pass a
>"pointer" unless the programmer has specified that you pass a pointer.  All
>BY REFERENCE is obligated to do is to *act as if* the caller and the callee
>share the same memory space, not that they actually do so, and all BY
>CONTENT is required to do is to prevent the callee from accessing the
>caller's memory space.  There's nothing to prevent an implementor from
>making copies of the actual data in *both* cases.

Further, the Standard doesn't say BY VALUE is passed in the parameter
list for compatibility with other languages. The description sounds
similar to BY CONTENT. 

As a practical matter, the callee need not distinguish between
REFERENCE and CONTENT, except modifying CONTENT will not produce
expected results.

On the differentiation between REFERENCE and VALUE, you're right in
that section 14 doesn't say they must match between caller and callee
(unless a  prototype are used). However, 9.1.6.3.2 (my version) says:

1) For every method in interface-2 there is a method in interface-1
with the same name taking the same number of parameters, with
consistent BY REFERENCE and BY VALUE specifications.


0
robert6624 (636)
9/8/2004 1:20:25 AM
On Tue, 7 Sep 2004 20:50:10 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>> What, pray tell, is the advantage of a monolithic WORKING-STORAGE except for
>> the possibility that the implementation might allow the user to corrupt his
>> own data by indexing outside of a record?
>
>Unfortunately, that need existed for a long time when people had bigger tables
>than their version of CoBOL would support.

If they'd used lists rather than unsupported tables, rewrite would
have been unnecessary when better hardware/software removed the
restriction. 

0
robert6624 (636)
9/8/2004 1:20:26 AM
On 7 Sep 2004 16:39:50 -0400, docdwarf@panix.com wrote:

>How curious... I've never heard of such a thing but it'd seem to make 
>sense.  Ah well... next time I come down I won't have to worry about such 
>things, I'm 1099 on this gig.

You can't receive per diem as 1099, only actual expenses. The
difference is $10K in tax savings.

0
robert6624 (636)
9/8/2004 1:20:26 AM
On Tue, 7 Sep 2004 14:15:22 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:h2rhj0laki7m79s47rtatijjm0prgcal3f@4ax.com...

>A whole lot of this is imposing a lot of COMPILE-TIME analysis involving
>inter-statement relationships that the standard does not impose.  Is a
>significant increase in compile-time resource requirements worth it to you?
>Can you guarantee that enough users would regard such an increase as a
>worthy sacrifice to obtain the functionality to "shout down" those who would
>scream bloody murder?

They could bypass analysis with a compiler option. More troublesome is
the structure it imposes on the compiler,  would need to have all
source in memory, available for analysis. Existing compilers that
didn't work that way would face complete rewrite. 

>>     Deal with ESQL references. How?
>
>Well, first you have to define what an ESQL reference is in *standard* COBOL

It looks like a series of CALLs with all arguments BY REFERENCE. How
would the compiler know which might be modified?

>> I ASSumed it was supported for two reasons:
>> .. I use them routinely in Micro Focus.
>> .. Logic. Why would the standard create logical literals and then not
>> permit them in conditional expressions? That's illogical.
>
>When did the standard create "logical literals?"  

The Standard made me think so because it contains many statements like
'if so-and-so evaluates to TRUE, ...'. Why is TRUE in uppercase if
it's not a logical literal?

Moreover, it is in most other languages and in Micro Focus.


0
robert6624 (636)
9/8/2004 1:20:27 AM
In article <chlaf0$kuh$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:

[snip]

>I don't see that the standard for COBOL should *enforce* structure to a
>program, only that it should *allow* and *support* it.

If someone wants a standard that enforces a structure then it might be 
instructive to look into Modula-2 (and its many successful 
implementations).

DD

0
docdwarf (6044)
9/8/2004 1:22:15 AM
In article <3misj0lu8ichlf3ueu9lc5he03m0mm44u6@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 7 Sep 2004 16:39:50 -0400, docdwarf@panix.com wrote:
>
>>How curious... I've never heard of such a thing but it'd seem to make 
>>sense.  Ah well... next time I come down I won't have to worry about such 
>>things, I'm 1099 on this gig.
>
>You can't receive per diem as 1099, only actual expenses. The
>difference is $10K in tax savings.

As I understand it one can receive per diem only when one is working more 
than seventy miles away from one's declared residence... or something like 
that.  Have things changed?

DD
0
docdwarf (6044)
9/8/2004 1:29:09 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> I've seen one or two who were good at vi. The vast majority stumble
> and project inefficiency.

Was that 'the vast majority' of those that you have seen using vi
(possibly a small number) or were you asserting 'the vast majority' of
all vi users, even though you have no idea who they are ?
 
> The problem is an editor that doesn't let you overtype changes, how
> basic is that?, 

In what way does vi 'not let you overtype changes' ?  It may be that
you simply don't know how to do this.

> doesn''t have Find All, doesn't let you navigate
> between files except by sequential cycling, doesn't support
> hyperlinks, doesn't let you open multiple windows, etc. etc.

Wow, I find that NotePad doesn't do any of that either, so Windows
editors are all crap.

In fact when I do a 'vi' I get to have multiple windows, jump via tags
to another file and all manner of things.
0
riplin (4127)
9/8/2004 3:05:34 AM
On Tue, 7 Sep 2004 14:46:39 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:gr7sj0dojf1b1s1qlocvigaevfubik81q9@4ax.com...
>> On Thu, 2 Sep 2004 18:05:09 +0100, "Michael Russell"
>> <michael.russell@spamex.dsl.pipex.com> wrote:
>>
>> >The biggest omission, as far as I'm concerned - Date, DateTime & Time
>types,
>> >plus the arithmetic functions for them.
>>
>> TYPEDEF lets you  create Date and DateTime types. Functions
>> date-of-integer and integer-of-date let you do arithmetic .. in one
>> statement without storing the intermediate. For example,
>>
>> 01  yyyymmdd typedef.
>>      05  yyyy      pic  9(4).
>>      05  mm        pic  9(2).
>>      05  dd         pic  9(2).
>>
>> 01  a-record.
>>   05  some-date     yyyymmdd.
>>
>> compute thirty-days-later  =
>>     date-of-integer (integer-of-date(some-date) + 30)
>
>This provides for Date values, but how does it provide for DateTime, or for
>that matter, Time, manipulation, using standard representations?

For those, one uses ESQL, which can do both. :)

SELECT (TIMESTAMP(:finish-time) - TIMESTAMP(:start-time)) INTO
:duration FROM DUAL;

Foul? OK, create DateTime and Time classes in OO Cobol and provide
them with appropriate methods to import and export standard
representations from a non-OO program.  OO doesn't require a change to
OO thinking. One can continue writing non-OO programs and use OO to
simply create new types and extend the language without waiting for a
committee. I did exactly that in OODEMO. This code snippet could
easily have been generalized to 'invoke a-Time 'subtract' using 
start-time stop-time returning duration'. 


 invoke a-Timer 'stop' returning elapsed-time

.. method-id. 'stop'
.. local-storage section
.. 01 temp-time                pic  x(08)
.. 01 end-time        comp     pic s9(09)
.. linkage section
.. 01  elapsed-time   comp     pic s9(09)

.. procedure division returning elapsed-time.
    if running
        accept temp-time from time
        invoke self 'time-to-integer'
            using temp-time returning end-time
        compute elapsed-time rounded = end-time - start-time
        set running to false
    end-if
    exit method
.. end method 'stop'

.. method-id. 'time-to-integer'
.. linkage section
.. 01 input-time
..    05 hours                 pic 99
..    05 minutes               pic 99
..    05 seconds               pic 99
..    05 hundredths            pic 99
.. 01 output-time      comp    pic s9(9)

.. procedure division using input-time returning output-time.
    compute output-time =
       ((((((hours * 60) +
          minutes) * 60) +
          seconds) * 100) +
          hundredths)
    exit method
.. end method 'time-to-integer'

.. end object
.. end class timer
..

0
robert6624 (636)
9/8/2004 3:19:37 AM
On 7 Sep 2004 16:41:50 -0700, riplin@Azonic.co.nz (Richard) wrote:

>"Howard Brazee" <howard@brazee.net> wrote
>
>> If you have the right tools, I suppose you're right.   I'm awfully glad we
>> didn't have the right tools.
>> 
>> (I am *not* a fan of such conversions).
>
>As with any conversion between languages, one may not wind up with 'a
>Cobol program' but with an 'RPG program in the syntax of the Cobol
>language'.

I wrote a DIBOL-to-Cobol conversion program whose design objective was
'maintainable, pretty Cobol'.

DIBOL is a Basic-like language that has out-of-line exception handlers
for everything, including ON SIZE ERROR faults. The exception handlers
are turned on and off by inline procedural code. Typically, they're
turned off most of time and turned on only for statements that need
it. 

So the assignment statement 'b=a' could be converted to 'move a to b',
if the handler was off, or to 'compute b = a on size error perform
numeric-error', if it was on or unknown. The latter is not 'pretty'
maintainable  Cobol, especially when there are thousands of them. 

How to tell whether the handler is or might be on required simulating
all execution paths that might lead to 'b=a'. On large monolithic
spaghetti programs that were typical, I found the number of possible
paths was tens of thousands. I spent weeks trying to reduce the number
of paths, without success. Finally, I gave up. If 'set handler on' was
in the same 'paragraph', I generated compute else I generated move. 

As a practical matter, that solution seemed to work. To a purist, it
was Wrong. 

Some languages are so poorly designed that they cannot be translated
to 'pretty' Cobol. 
0
robert6624 (636)
9/8/2004 3:19:38 AM
"William M. Klein" <wmklein@nospam.netcom.com> wrote 

> I think that every current type of program could have been created with these 
> restrictions *and* I think (but can't prove it) that such a language would have 
> insured "easier to maintain" programs.

That may well be true, however, without, say, ALTER it may have been
difficult to get programs to fit into the machines that were available
at the time.  Having to do first-time and last-time testing using a
flag and test would have used more memory. The difference between
assembler program size and that of an equivalent Cobol would have been
much more marked.  The cost of using Cobol would thus have been much
more because the cost of memory was huge compared to that of
programmers time.

Today the costs have reversed. A Gigabyte is less than the cost of one
programmer for a day, while in 1959 one K of core was more than the
cost of a programmer for a year.

Thus, in 1959, the language had features to save memory.  It also had
features to save programmer time (when compared to assembler) but only
where this did not conflict with fitting it into the computer they
could afford.

Sure, take back 'what you know now' to 1959, but also take back a
machine that you can buy now for 'pocket change' that would allow them
to use those ideas.
0
riplin (4127)
9/8/2004 3:33:14 AM
Robert Wagner wrote:

>Foul? OK, create DateTime and Time classes in OO Cobol and provide
>them with appropriate methods to import and export standard
>representations from a non-OO program.  OO doesn't require a change to
>OO thinking. One can continue writing non-OO programs and use OO to
>simply create new types and extend the language without waiting for a
>committee. I did exactly that in OODEMO. This code snippet could
>easily have been generalized to 'invoke a-Time 'subtract' using 
>start-time stop-time returning duration'. 
>
>
>  
>
Right on. It hasn't happened yet - but that's the way to go. Not a trick 
question. Your example below, are both your methods in FACTORY or did 
you invoke "new" to create an instance and do they appear in OBJECT 
SECTION ?

Jimmy

> invoke a-Timer 'stop' returning elapsed-time
>
>. method-id. 'stop'
>. local-storage section
>. 01 temp-time                pic  x(08)
>. 01 end-time        comp     pic s9(09)
>. linkage section
>. 01  elapsed-time   comp     pic s9(09)
>
>. procedure division returning elapsed-time.
>    if running
>        accept temp-time from time
>        invoke self 'time-to-integer'
>            using temp-time returning end-time
>        compute elapsed-time rounded = end-time - start-time
>        set running to false
>    end-if
>    exit method
>. end method 'stop'
>
>. method-id. 'time-to-integer'
>. linkage section
>. 01 input-time
>.    05 hours                 pic 99
>.    05 minutes               pic 99
>.    05 seconds               pic 99
>.    05 hundredths            pic 99
>. 01 output-time      comp    pic s9(9)
>
>. procedure division using input-time returning output-time.
>    compute output-time =
>       ((((((hours * 60) +
>          minutes) * 60) +
>          seconds) * 100) +
>          hundredths)
>    exit method
>. end method 'time-to-integer'
>
>. end object
>. end class timer
>.
>
>  
>
0
jjgavan (507)
9/8/2004 3:44:21 AM
Reading this message reminded me of something I saw that I think would 
be a great extension to COBOL. Perhaps, even, just with calls.
If you acquire Open Office and review the setting options one has
while typing, you will see among other things, a way to set most
of the variables used in word processing now days.

Presuming that more and more input and output will come from and go to
something like a PC, all or most of the abilities of creating
documents of all kinds would be available to the COBOL programmer, as
well as to other languages via the open licenses. Merges well with
the nature of COBOL until someone finds a really good reason for NOT
doing this.

Warren Simmons




Richard wrote:
> "William M. Klein" <wmklein@nospam.netcom.com> wrote 
> 
> 
>>I think that every current type of program could have been created with these 
>>restrictions *and* I think (but can't prove it) that such a language would have 
>>insured "easier to maintain" programs.
> 
> 
> That may well be true, however, without, say, ALTER it may have been
> difficult to get programs to fit into the machines that were available
> at the time.  Having to do first-time and last-time testing using a
> flag and test would have used more memory. The difference between
> assembler program size and that of an equivalent Cobol would have been
> much more marked.  The cost of using Cobol would thus have been much
> more because the cost of memory was huge compared to that of
> programmers time.
> 
> Today the costs have reversed. A Gigabyte is less than the cost of one
> programmer for a day, while in 1959 one K of core was more than the
> cost of a programmer for a year.
> 
> Thus, in 1959, the language had features to save memory.  It also had
> features to save programmer time (when compared to assembler) but only
> where this did not conflict with fitting it into the computer they
> could afford.
> 
> Sure, take back 'what you know now' to 1959, but also take back a
> machine that you can buy now for 'pocket change' that would allow them
> to use those ideas.
0
wsimmons5 (172)
9/8/2004 5:38:12 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> >Unfortunately, that need existed for a long time when people had bigger tables
> >than their version of CoBOL would support.
> 
> If they'd used lists rather than unsupported tables, rewrite would
> have been unnecessary when better hardware/software removed the
> restriction.

Your argument is a religeous one:

Tables weren't 'unsupported'.  The size wasn't directly supported.

Rewrite was unnecessary anyway.  All that was necessary when the
restriction was removed was to up the OCCURS value.  How hard is that
?

Lists are not directly interchangable with tables.  Lists are either
serial only or require more complex linking and traversal code. 
Tables can be directly accessed by a calculated index number.
Simplistic lists, as implemented in the way you have shown, are
generally slower than tables, and may be _much_ slower.

Double linked lists, trees, and other exotic structures are far more
complex and error prone and may be considerably slower.
0
riplin (4127)
9/8/2004 7:38:53 AM
On Wed, 08 Sep 2004 03:44:21 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:

>Right on. It hasn't happened yet - but that's the way to go. Not a trick 
>question. Your example below, are both your methods in FACTORY or did 
>you invoke "new" to create an instance and do they appear in OBJECT 
>SECTION ?

I did "new" to construct an instance. I didn't like the idea of
putting the timer at the class level (factory) because then there
could only be one timer per program. Here's the top part. Do you have
suggestions for improvement?

 . Class-id. timer inherits from base

 . object section
 . class-control.
       base is class 'base'
       Timer is class 'timer'

*   the following are class methods and data
 . factory
 . end factory

*   the following are instance methods and data
 . object
 . working-storage section
 . 01   value 0       comp-x   pic x.
 .  88 running value 1 false 0
 . 01  start-time     comp     pic s9(09)

 . method-id. 'start'
 . local-storage section
 . 01 temp-time                pic  x(08)

 . procedure division.
     if not running
         accept temp-time from time
         invoke self 'time-to-integer'
             using temp-time returning start-time
         set running to true
0
robert6624 (636)
9/8/2004 8:47:56 AM
On 7 Sep 2004 21:29:09 -0400, docdwarf@panix.com wrote:

>In article <3misj0lu8ichlf3ueu9lc5he03m0mm44u6@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>On 7 Sep 2004 16:39:50 -0400, docdwarf@panix.com wrote:
>>
>>>How curious... I've never heard of such a thing but it'd seem to make 
>>>sense.  Ah well... next time I come down I won't have to worry about such 
>>>things, I'm 1099 on this gig.
>>
>>You can't receive per diem as 1099, only actual expenses. The
>>difference is $10K in tax savings.
>
>As I understand it one can receive per diem only when one is working more 
>than seventy miles away from one's declared residence... or something like 
>that.  Have things changed?

It's changed slightly,  for the worse in most cases. The 70 mile test
was replaced by "in another metropolitan area", which  has never been
defined. Working definition is 'another SMSA'. The DC SMSA includes
suburbs in MD and VA. NY/NJ has seven SMSAs. Jersey City is one,
Newark is another, Passaic is yet another,  although they're only 10
miles apart.  You could have a tax home in Livingston (Newark SMSA),
work in Patterson for a year (Passaic SMSA), Manhattan or Jersey City
for a year,  then back to Patterson,  etc. 

If you work in a SMSA longer than 12 months, not only are you no
longer eligible to receive per diem there, but also you've lost your
tax home. You've constructively moved. On the next project, you'll
have to maintain a household there rather than your original tax home.
If it's a high-cost city, that will be impractical. You've become an
'itinerant' (IRS terminology) who is ineligible to receive per diem
anywhere. On one gig, they couldn't understand  what I was talking
about, so I cleaned out my desk and left on day number 364. 

One would think a 1099 corporation could give its solitary employee
per diem. Nope. It has to be a "Qualified Plan" i.e. reviewed and
approved by the IRS. They won't approve a one person corporation plan.
The corporation can pay only actual housing and food expenses, subject
to the 'another SMSA' test.
0
robert6624 (636)
9/8/2004 8:47:56 AM
On 7 Sep 2004 20:05:34 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
>
>> I've seen one or two who were good at vi. The vast majority stumble
>> and project inefficiency.
>
>Was that 'the vast majority' of those that you have seen using vi
>(possibly a small number) or were you asserting 'the vast majority' of
>all vi users, even though you have no idea who they are ?

My sample is people I've watched, well over 100.
 
>> The problem is an editor that doesn't let you overtype changes, how
>> basic is that?, 
>
>In what way does vi 'not let you overtype changes' ?  It may be that
>you simply don't know how to do this.

I hit R, replacement character, cursor right, R, replacement
character, etc. Is there another way?


0
robert6624 (636)
9/8/2004 8:47:56 AM
In article <nedtj05u837mv4q8vl8hr9r7v6cqsggo2e@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 7 Sep 2004 21:29:09 -0400, docdwarf@panix.com wrote:
>
>>In article <3misj0lu8ichlf3ueu9lc5he03m0mm44u6@4ax.com>,
>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>On 7 Sep 2004 16:39:50 -0400, docdwarf@panix.com wrote:
>>>
>>>>How curious... I've never heard of such a thing but it'd seem to make 
>>>>sense.  Ah well... next time I come down I won't have to worry about such 
>>>>things, I'm 1099 on this gig.
>>>
>>>You can't receive per diem as 1099, only actual expenses. The
>>>difference is $10K in tax savings.
>>
>>As I understand it one can receive per diem only when one is working more 
>>than seventy miles away from one's declared residence... or something like 
>>that.  Have things changed?
>
>It's changed slightly,  for the worse in most cases. The 70 mile test
>was replaced by "in another metropolitan area", which  has never been
>defined. Working definition is 'another SMSA'. The DC SMSA includes
>suburbs in MD and VA.

So much for that, then... I'd fail the test of both mileage and SMSA.

[snip]

>If you work in a SMSA longer than 12 months, not only are you no
>longer eligible to receive per diem there, but also you've lost your
>tax home.

Ahhhhh, it comes back to me now... I recall, years on back, am agency that 
screwed up on my contract somehow and was cutting me oversized checks for 
a few months until they found out.  The pimp called me and asked that I 
sit down and write them a check for the amount in error to which I 
responded 'Why not just take it out of my next paycheck?'... and he said 
something like 'Murfle blurfle too much work.'

My response was 'Hey, you made the error, you have the tools to make it 
right... you do the work, get back to me when you've cleaned up your 
mess' and he got rather annoyed; one of the things he proposed doing was 
getting in contact with the IRS and telling them that the client had told 
him it was projected I'd be there longer than a year so I was no longer 
eligible for per diem.

I asked 'You'd do that?', he responded 'In a heartbeat!'... and I followed 
with 'You know, I'd have difficulty continuing my working relationship 
with an organisation whose representative considers this to be a 
conscionable way to do business... so I think tomorrow I'll call Bill down 
at BlamfCo and tell him that things just aren't working out for me and he 
should find someone to fill out the term of my contract...'

The corrected their error.

[snip]

>One would think a 1099 corporation could give its solitary employee
>per diem. Nope. It has to be a "Qualified Plan" i.e. reviewed and
>approved by the IRS. They won't approve a one person corporation plan.

Not all corporations are created equal, of course... 'twas e'er thus.

DD
0
docdwarf (6044)
9/8/2004 9:27:19 AM
Also, the compiler that had 32K size limits didn't support USAGE POINTER so 
"lists" would have been a problem to implement.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message 
news:217e491a.0409072338.3ded2d39@posting.google.com...
> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>> >Unfortunately, that need existed for a long time when people had bigger 
>> >tables
>> >than their version of CoBOL would support.
>>
>> If they'd used lists rather than unsupported tables, rewrite would
>> have been unnecessary when better hardware/software removed the
>> restriction.
>
> Your argument is a religeous one:
>
> Tables weren't 'unsupported'.  The size wasn't directly supported.
>
> Rewrite was unnecessary anyway.  All that was necessary when the
> restriction was removed was to up the OCCURS value.  How hard is that
> ?
>
> Lists are not directly interchangable with tables.  Lists are either
> serial only or require more complex linking and traversal code.
> Tables can be directly accessed by a calculated index number.
> Simplistic lists, as implemented in the way you have shown, are
> generally slower than tables, and may be _much_ slower.
>
> Double linked lists, trees, and other exotic structures are far more
> complex and error prone and may be considerably slower. 


0
wmklein (2605)
9/8/2004 2:08:49 PM
On  7-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:

> There was once a Datamation report (in the late 70s I think) that
> compared 'maintenance' effort versus 'new development' effort.  This
> found that at Cobol shops some high percentage of programmer time was
> 'maintenance' while at C shops it was low.
>
> They concluded that if the Cobol programs were converted to C then the
> maintenance requirement would be much lower and thus more new
> development could be done.

I always get a good chuckle when reminded of this conclusion.


> I suspect that some management may have believed this clueless hack.

I know that LOTS of management have come to the same conclusion - although
mostly not thought out.    New code is sexy, maintenance is someone else's
problem.
0
howard (6283)
9/8/2004 2:22:23 PM
On  7-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:

> > Also have the function return an error code that can be checked without
> > aborting
> > when the function fails.
>
> That is difficult to do when a function can only return a single
> value.

One can consider READ to be an equivalent of a function.   We can look at return
codes in a couple of different ways with a READ statement, without leaving the
paragraph.


> Also functions may be buried in expressions that will use the return
> as part of the calculation.  What would happen if a function returned
> an 'error code' and this was used by the calculation ?

The return error code cannot be the returned value, it has to be separate.   
But you do bring up a point - some priority needs to be established for nested
functions.
0
howard (6283)
9/8/2004 2:30:08 PM
On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> > Not if that was the way the language had been from the beginning.
>
> I'd still be uncomfortable with a language specification in which control
> would fall through the second, and *only* the second, paragraph in a
> program.

I didn't understand that bit and replied with a question why there should be one
drop through.   Zero seems better to me.

> I don't see that the standard for COBOL should *enforce* structure to a
> program, only that it should *allow* and *support* it.

We can't change this now.   But it DOES enforce structures.   Working Storage is
before Procedure.    Nobody would have considered it enforcing structure if,
from the beginning, the only way to get to a paragraph was to perform it.    The
only way to do subroutines was to call them.   Nobody felt constrained that we
can't drop through to subroutines.

If a program has in its procedure paragraph (call it MAIN, or don't give it a
name at all), 50 PERFORMS and none elsewhere, that program isn't structured the
way we think of it.   There would still be style wars.
0
howard (6283)
9/8/2004 2:36:19 PM
On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> In fact, I just thought of another:  Even in its current form COBOL's
> support for currency signs is decidedly provincial.  As I read the standard,
> I can't get COBOL to produce a *floating* version of the most common
> designator for the Venezuelan unit of currency.  Why should England and the
> US have preferential support from PICTURE?

That's interesting.   And changeable.    What would you propose, a special names
currency sign?

We would want to be able to define more than one currency sign in a given
program.
0
howard (6283)
9/8/2004 2:39:20 PM
Robert Wagner wrote:

>On Wed, 08 Sep 2004 03:44:21 GMT, "James J. Gavan" <jjgavan@shaw.ca>
>wrote:
>
>  
>
>>Right on. It hasn't happened yet - but that's the way to go. Not a trick 
>>question. Your example below, are both your methods in FACTORY or did 
>>you invoke "new" to create an instance and do they appear in OBJECT 
>>SECTION ?
>>    
>>
>
>I did "new" to construct an instance. I didn't like the idea of
>putting the timer at the class level (factory) because then there
>could only be one timer per program. Here's the top part. Do you have
>suggestions for improvement?
>
>  
>
No that's fine as you have done it - your point about wanting more than 
one timer per program - identifying  each 'timer' by an instance. Of 
course if you were only using one per program, then the functions could 
have just been in FACTORY.

Jimmy
0
jjgavan (507)
9/8/2004 2:50:11 PM
Right now, it might be nice for COBOL to have an option to have run-time data
formats.   It checks a data dictionary at run-time.   Not very efficient, but
occasionally useful.
0
howard (6283)
9/8/2004 2:50:30 PM
On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> Can a paragraph-name be used simply to subdivide logic into more visible or
> more meaningful (or even smaller) blocks of source statements?  There's
> nothing now, nor has there ever been, any *requirement* that paragraph-names
> have any *object-time* function, so far as I know ...

Why not use a comment?


The advantage of a comment is that you *know* that's all it is.   
0
howard (6283)
9/8/2004 2:51:40 PM
Yes, you are correct:  you can implement this using the OO features of
2002-compliant COBOL.

You could also implement a similar feature using user-defined functions (not
technically part of OO).


"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:mqqsj01m84qqk1ca550tsas744o8du3ruv@4ax.com...
> >This provides for Date values, but how does it provide for DateTime, or
for
> >that matter, Time, manipulation, using standard representations?
>
> For those, one uses ESQL, which can do both. :)
>
> SELECT (TIMESTAMP(:finish-time) - TIMESTAMP(:start-time)) INTO
> :duration FROM DUAL;
>
> Foul?

Not exactly -- about as relevant, though, as to whether I can do it with a
custom-made device that  receives time signals from WWV for retrieval
through the magnetic tape controllers on a 1401.

> OK, create DateTime and Time classes in OO Cobol and provide
> them with appropriate methods to import and export standard
> representations from a non-OO program.

Sounds a lot more complicated than providing user-defined functions to do
the same thing.

> OO doesn't require a change to
> OO thinking. One can continue writing non-OO programs and use OO to
> simply create new types and extend the language without waiting for a
> committee.

You can continue writing non-OO programs and not use OO features at all
without waiting for a committee to accomplish the same thing, in this case.
The user-written features may or may not be portable, and they may or may
not be compatible with existing or future standard features, but that's true
regardless of whether they are OO features.

> I did exactly that in OODEMO. This code snippet could
> easily have been generalized to 'invoke a-Time 'subtract' using
> start-time stop-time returning duration'.
....

Yeah, it could, and you could do the same thing using user-defined functions
with a whole lot less stuff that non-OO folks might object to!

    -Chuck Stevens


0
9/8/2004 3:31:02 PM
It would be nice if the COPY REPLACING statement was designed from the scratch
for prefixes and suffixes.

I wanted to use it to change the prefix on a file and also replace ==comp-3== by
==display==.
0
howard (6283)
9/8/2004 3:40:58 PM
The 2002 standard is already there for most contexts, but not for this one.

This is the syntax diagram fragment from page 194, 12.2.6.1, SPECIAL-NAMES
paragraph, General format:

    CURRENCY SIGN IS literal-7 WITH PICTURE SYMBOL literal-8.

and what I would like to see available to Venezuelans is something like

    CURRENCY SIGN IS "$" WITH PICTURE SYMBOL "Bs. ".

but page 98, 12.2.6.2, SPECIAL-NAMES paragraph Syntax Rule 20 precludes the
presence of a period (among other characters) within literal-8.

Having worked with de-editing MOVE, I'm almost certain that the presence of
a period in the PICTURE SYMBOL literal would cause serious problems with
that feature, and I strongly suspect that's the reason it (along with comma,
plus sign, hyphen, asterisk and the digits) are prohibited.

But I'd still have to question which feature would a Venezuelan programmer
be more likely to need:  de-editing MOVE, or the ability to represent his
national currency in a customary representation using standard COBOL
conventions?

    -Chuck Stevens

"Howard Brazee" <howard@brazee.net> wrote in message
news:chn5in$fta$1@peabody.colorado.edu...
>
> On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> > In fact, I just thought of another:  Even in its current form COBOL's
> > support for currency signs is decidedly provincial.  As I read the
standard,
> > I can't get COBOL to produce a *floating* version of the most common
> > designator for the Venezuelan unit of currency.  Why should England and
the
> > US have preferential support from PICTURE?
>
> That's interesting.   And changeable.    What would you propose, a special
names
> currency sign?
>
> We would want to be able to define more than one currency sign in a given
> program.


0
9/8/2004 3:46:40 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:chn96a$35j$1@peabody.colorado.edu...
> It would be nice if the COPY REPLACING statement was designed from the
scratch
> for prefixes and suffixes.
>
> I wanted to use it to change the prefix on a file and also replace
==comp-3== by
> ==display==.

I don't much like the "partial-token replace" that is, as far as I'm
concerned, the consequence of an insufficiently-well-thought-out definition
for "COBOL word" in the standard.

But are you aware of "REPLACING LEADING" and "REPLACING TRAILING" in the
2002 standard?  This is syntactically fairly clean, I think.

    -Chuck Stevens


0
9/8/2004 4:06:17 PM
On  8-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> > I wanted to use it to change the prefix on a file and also replace
> ==comp-3== by
> > ==display==.
>
> I don't much like the "partial-token replace" that is, as far as I'm
> concerned, the consequence of an insufficiently-well-thought-out definition
> for "COBOL word" in the standard.
>
> But are you aware of "REPLACING LEADING" and "REPLACING TRAILING" in the
> 2002 standard?  This is syntactically fairly clean, I think.

Aware, but I haven't had an opportunity to try it out.

Can we use multiple REPLACINGs within the same COPY statement with that
standard, as in that example above?
0
howard (6283)
9/8/2004 4:28:56 PM
On Wed, 8 Sep 2004 15:40:58 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>It would be nice if the COPY REPLACING statement was designed from the scratch
>for prefixes and suffixes.
>
>I wanted to use it to change the prefix on a file and also replace ==comp-3== by
>==display==.

You're using prefix as a non-standard form of qualification. If you
used qualification as defined in the standard, there wouldn't be a
problem.
0
robert6624 (636)
9/8/2004 4:36:30 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:chnc08$f46$1@peabody.colorado.edu...
>
> On  8-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> > > I wanted to use it to change the prefix on a file and also replace
> > ==comp-3== by
> > > ==display==.
> >
> > I don't much like the "partial-token replace" that is, as far as I'm
> > concerned, the consequence of an insufficiently-well-thought-out
definition
> > for "COBOL word" in the standard.
> >
> > But are you aware of "REPLACING LEADING" and "REPLACING TRAILING" in the
> > 2002 standard?  This is syntactically fairly clean, I think.
>
> Aware, but I haven't had an opportunity to try it out.
>
> Can we use multiple REPLACINGs within the same COPY statement with that
> standard, as in that example above?

Yes, of course; that appears to have been true from its introduction (in '68
COBOL?), though "pseudo-text" didn't show up until '74.

    -Chuck Stevens


0
9/8/2004 4:40:36 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:r9duj0tmesi1ks6qal3k3qcu18tken3vu9@4ax.com...
> On Wed, 8 Sep 2004 15:40:58 GMT, "Howard Brazee" <howard@brazee.net>
> wrote:
>
> >It would be nice if the COPY REPLACING statement was designed from the
scratch
> >for prefixes and suffixes.
> >
> >I wanted to use it to change the prefix on a file and also replace
==comp-3== by
> >==display==.
>
> You're using prefix as a non-standard form of qualification.

Strikes me more likely he's using the prefix to provide a "form of
qualification" that COBOL doesn't otherwise provide save through unique
identifiers.

> If you used qualification as defined in the standard, there wouldn't be a
> problem.

I'm sure he would if he could figure out the syntax by which one qualifies a
*file name*.

    -Chuck Stevens


0
9/8/2004 5:27:26 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> I hit R, replacement character, cursor right, R, replacement
> character, etc. Is there another way?

You may be doing that with r (lower case) which is 'replace one'.
Using R (upper case) puts you into replace mode where you just type
the replacement until esc to end the mode.

It seems the problem _is_ your knowledge of it.
0
riplin (4127)
9/8/2004 6:56:51 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> Some languages are so poorly designed that they cannot be translated
> to 'pretty' Cobol.

That would only be a reasonable conclusion if the primary design aim
of the language was "how well RW could convert it to something else
and think that the result is pretty".

I can't think of anyone, other than yourself, that would care about
that.
0
riplin (4127)
9/8/2004 7:07:40 PM
Howard Brazee wrote:

>It would be nice if the COPY REPLACING statement was designed from the scratch
>for prefixes and suffixes.
>
>I wanted to use it to change the prefix on a file and also replace ==comp-3== by
>==display==.
>  
>
Can I state the obvious on this thread, "It would be nice....",  and 
Joe's comment "Amen" about arithmetic/date(?)  handling.

I'm still waiting to see Joe's submission to J4 on XML seeing as he uses 
it. Nothing will be *nice* unless it is formally presented to J4. As it 
stands at the moment, I think they have their plate filled to make if 
for COBOL 2006/8 - Chuck please confirm as necessary.

(Mind you noting Chucks *enthusiasm* for OO when replying to Robert - 
Zowee !- What''s he gong to think when he gets my latest ? I was going 
to use 'Wow' instead of 'Zowee' - but playing it safe - Tom might have 
already copyrighted it for Liant  :-)  )

Even at this stage if you submit *nicieees* - you are looking at 201? 
before they would be introduced, if 'blessed' by J4. But it aint gonna 
happen, *wishing*.

Jimmy
0
jjgavan (507)
9/8/2004 7:16:29 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:oiasj05hgcd6pd6hvhjo4kvruafi76tp81@4ax.com...

> >> The culture says so.
> >
> >Whose culture?  Certainly not mine!
>
> IBM mainframe culture, and compilers that mimic IBM's memory model.

Well, there ya go.  Everybody knows "the culture" is synonymous with "IBM
mainfraim culture".

> >What, pray tell, is the advantage of a monolithic WORKING-STORAGE except
for
> >the possibility that the implementation might allow the user to corrupt
his
> >own data by indexing outside of a record?

> The topic is memory management, not bug detection.

I wasn't talking about bug detection; I did, however, suggest bug
*exploitation* as a motive for preferring a monolithic working-storage!

> If you want to catch such bugs, turn on bounds checking.

Well, we can do that, too.  Bounds checking keeps you from
indexing/subscript outside of the *table*.  The hardware keeps you from
indexing/subscripting beyond the limits of the record that contains the
table.

> Don't depend on memory management to catch them.

Oh, I agree.  That's not what memory management is for.  It may, however,
some salubrious side-effects in preventing users from corrupting their data
with no associated costs.  Done properly, that is.

> Modern IBM dynamically allocates working-storage, but still as one
> monolithic chunk.

Some implementations do that.  Others don't.

> >You seem to feel there's some obligation that
> >any two adjacent 01-level records in working-storage are allocated next
to
> >each other in memory.  What's the point of that?
>
> I didn't support that idea; IBM did.

IBM did it that way; I don't see evidence that IBM insisted that everybody
else needed to as well, or that they took a particular position on its
appropriateness in any environment save their own.   Only those with Big
Block Letters Tattooed in Blue on their foreheads would jump from the
premise IBM Did It That Way to the conclusion That's The Way Everybody
Agrees It Needs To Be Done.

> Because the programmer (end user) often has to read memory dumps, so
> must be aware of the memory model in order to find things.

Why and how is the reading of memory dumps made *easier* by a monolithic
working-storage if the contents of every 01-level item are presented
separately, identified by the 01-level item's name as well as the stack
location of the descriptor pointing to it (corresponding to the map provided
on the compilation listing)?   The program dumps available to you *do* have
that capability, right?

> Move structures from working-storage to linkage section and
> dynamically allocate/free them. I do it routinely. The reason has
> nothing to do with range checking.

I can see this having *some* utility in our environment, but if 01-level
records aren't ALLOCATEd until they're accessed, I'm not sure why you'd
*have* to go through all that trouble!   The standard *does* provide a
memory management scheme, true enough -- but it looks a whole lot like what
was provided in COBOL-60 by default on the Burroughs B5000 forty-some years
ago ...

> Acu and R/M don't. When viewed from the outside, most compilers appear
> to produce object code 'directly'. Internally, they are  going through
> intermediate code, which makes it possible to use the same front-end
> on multiple platforms.

Some may, some may not; some may do so for the reasons you suggest and some
may do so for other reasons.

> Do you think Micro Focus, Fujitsu and IBM start
> from scratch every time a platform is added?

That depends on whether they've designed the particular compiler for a
particular platform or not.  I agree that many vendors have been trying to
"generalize" their compilers, but I would hesitate to describe the
communications mechanism from the parsing logic of the compiler and the
code-generation logic as being "intermediate code" in general, particularly
if that "code" is invisible to the user (as, for example, a table in
memory).

> They just write another back-end.

Yes, sometimes that works.

> >> There is some miscommunication here due to an error.

Yes, I've figured out my error.  I was thinking in '85 COBOL and had failed
to note the presence of BY VALUE on parameters in both the PROCEDURE
DIVISION header and the Format 3 CALL statement.  The more I study this, the
more satisfied I am with the 2002 specification in this area.

A CALL statement that passes a BY CONTENT parameter explicitly matches a
Procedure Division header in which the corresponding parameter is BY
REFERENCE.

I was also thinking in more generic (and more pan-language) terms.

> >> BY CONTENT copies the thing and passes a pointer to the copy

Yes, and it is received BY REFERENCE by the callee.  That is now clear.

> >> BY VALUE      puts word-sized things directly into the parameter list

Well, no, not necessarily.  That's the most likely approach, but it is by no
means required.  An implementation could pass rutabagas and ghee for all the
standard cares, so long as the end result meets the requirements.   Doesn't
have to be "word-sized".

> You MEANT reference and content, but you SAID reference and value.

I meant what I wrote, but I now see where I made my mistakes.

> Further, the Standard doesn't say BY VALUE is passed in the parameter
> list for compatibility with other languages.

The standard says very little indeed about compatibility with other
languages.

> The description sounds similar to BY CONTENT.

It does, save that both the called program and the calling program must
declare the parameter BY VALUE.

> As a practical matter, the callee need not distinguish between
> REFERENCE and CONTENT, except modifying CONTENT will not produce
> expected results.

Yes, that's correct according to the 2002 standard.

> On the differentiation between REFERENCE and VALUE, you're right in
> that section 14 doesn't say they must match between caller and callee
> (unless a  prototype are used).

No, that's not right.  Page 422, 14.8.4.3, CALL statement Syntax Rule 8
mandates that if BY VALUE appears on a parameter in the caller it must also
appear on the corresponding parameter in the called program, and that
applies whether a prototype is used or not.

> However, 9.1.6.3.2 (my version) says:

> 1) For every method in interface-2 there is a method in interface-1
> with the same name taking the same number of parameters, with
> consistent BY REFERENCE and BY VALUE specifications.

That's Page 162, 9.3.7.1.2, Conformance between interfaces, in 9.3.7.1,
Conformance for object orientation, in the published standard.

And yes, it's clear from the rules for CALL and for the PROCEDURE DIVISION
header that the parameters have to be consistent whether or not object
orientation is involved.   Both REFERENCE and CONTENT in the CALL match
REFERENCE in the callee; VALUE matches only VALUE.

Now that I understand that it is indeed possible to pass, and receive,
parameters to programs BY VALUE according to the 2002 standard without
imposing prototypes, I'm a whole lot more comfortable with the CALL
statement than I was when the only control was from the CALL statement and
the receiving program had to treat everything BY REFERENCE.

    -Chuck Stevens


0
9/8/2004 7:54:53 PM
On 8 Sep 2004 05:27:19 -0400, docdwarf@panix.com wrote:

>In article <nedtj05u837mv4q8vl8hr9r7v6cqsggo2e@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>On 7 Sep 2004 21:29:09 -0400, docdwarf@panix.com wrote:
>>
>>>In article <3misj0lu8ichlf3ueu9lc5he03m0mm44u6@4ax.com>,
>>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>>On 7 Sep 2004 16:39:50 -0400, docdwarf@panix.com wrote:
>>>>
>>>>>How curious... I've never heard of such a thing but it'd seem to make 
>>>>>sense.  Ah well... next time I come down I won't have to worry about such 
>>>>>things, I'm 1099 on this gig.
>>>>
>>>>You can't receive per diem as 1099, only actual expenses. The
>>>>difference is $10K in tax savings.
>>>
>>>As I understand it one can receive per diem only when one is working more 
>>>than seventy miles away from one's declared residence... or something like 
>>>that.  Have things changed?
>>
>>It's changed slightly,  for the worse in most cases. The 70 mile test
>>was replaced by "in another metropolitan area", which  has never been
>>defined. Working definition is 'another SMSA'. The DC SMSA includes
>>suburbs in MD and VA.
>
>So much for that, then... I'd fail the test of both mileage and SMSA.
>
>[snip]
>
>>If you work in a SMSA longer than 12 months, not only are you no
>>longer eligible to receive per diem there, but also you've lost your
>>tax home.
>
>Ahhhhh, it comes back to me now... I recall, years on back, am agency that 
>screwed up on my contract somehow and was cutting me oversized checks for 
>a few months until they found out.  The pimp called me and asked that I 
>sit down and write them a check for the amount in error to which I 
>responded 'Why not just take it out of my next paycheck?'... and he said 
>something like 'Murfle blurfle too much work.'
>
>My response was 'Hey, you made the error, you have the tools to make it 
>right... you do the work, get back to me when you've cleaned up your 
>mess' and he got rather annoyed; one of the things he proposed doing was 
>getting in contact with the IRS and telling them that the client had told 
>him it was projected I'd be there longer than a year so I was no longer 
>eligible for per diem.
>
>I asked 'You'd do that?', he responded 'In a heartbeat!'... and I followed 
>with 'You know, I'd have difficulty continuing my working relationship 
>with an organisation whose representative considers this to be a 
>conscionable way to do business... so I think tomorrow I'll call Bill down 
>at BlamfCo and tell him that things just aren't working out for me and he 
>should find someone to fill out the term of my contract...'
>
>The corrected their error.
>
>[snip]
>
>>One would think a 1099 corporation could give its solitary employee
>>per diem. Nope. It has to be a "Qualified Plan" i.e. reviewed and
>>approved by the IRS. They won't approve a one person corporation plan.
>
>Not all corporations are created equal, of course... 'twas e'er thus.
>
>DD

0
robert6624 (636)
9/8/2004 7:58:13 PM
On 8 Sep 2004 05:27:19 -0400, docdwarf@panix.com wrote:

>Ahhhhh, it comes back to me now... I recall, years on back, am agency that 
>screwed up on my contract somehow and was cutting me oversized checks for 
>a few months until they found out.  The pimp called me and asked that I 
>sit down and write them a check for the amount in error to which I 
>responded 'Why not just take it out of my next paycheck?'... and he said 
>something like 'Murfle blurfle too much work.'

I had the same situation. The company reached into my checking account
via 'direct deposit' and took it back BEFORE talking to me. Most
people don't realize that direct deposit is bi-directional.  The
capability exists to currect errors like this. 

Months after the project ends, an unprincipled pimp might reach into
your account with such a 'correction'. Then the burden is on you to
get it back. Be sure to withdraw direct deposit authorization the day
after the last paycheck hits. 
0
robert6624 (636)
9/8/2004 8:10:36 PM
On Wed, 8 Sep 2004 10:27:26 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:r9duj0tmesi1ks6qal3k3qcu18tken3vu9@4ax.com...
>> On Wed, 8 Sep 2004 15:40:58 GMT, "Howard Brazee" <howard@brazee.net>
>> wrote:
>>
>> >It would be nice if the COPY REPLACING statement was designed from the
>scratch
>> >for prefixes and suffixes.
>> >
>> >I wanted to use it to change the prefix on a file and also replace
>==comp-3== by
>> >==display==.
>>
>> You're using prefix as a non-standard form of qualification.
>
>Strikes me more likely he's using the prefix to provide a "form of
>qualification" that COBOL doesn't otherwise provide save through unique
>identifiers.
>
>> If you used qualification as defined in the standard, there wouldn't be a
>> problem.
>
>I'm sure he would if he could figure out the syntax by which one qualifies a
>*file name*.

When Howard said "on a file", he didn't mean the file name per se, he
meant datanames in a 'file copybook'. If the file name is 'INV', all
datanames are prefixed with 'INV-'. 

The solution, per the standard, is to qualify names with 'IN INV'. 

0
robert6624 (636)
9/8/2004 9:35:58 PM
In article <c4puj0tqk37476s5fuka54i2s8ci6mcpcl@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 8 Sep 2004 05:27:19 -0400, docdwarf@panix.com wrote:
>
>>Ahhhhh, it comes back to me now... I recall, years on back, am agency that 
>>screwed up on my contract somehow and was cutting me oversized checks for 
>>a few months until they found out.  The pimp called me and asked that I 
>>sit down and write them a check for the amount in error to which I 
>>responded 'Why not just take it out of my next paycheck?'... and he said 
>>something like 'Murfle blurfle too much work.'
>
>I had the same situation. The company reached into my checking account
>via 'direct deposit' and took it back BEFORE talking to me. Most
>people don't realize that direct deposit is bi-directional.

I guess I ain't 'most people'... but I know that when I work on banking 
systems all transactions seem to have the need to be able to run in all 
directions nigh simultaneously.  This is a reason that I avoid direct 
deposit like the plague.

>The
>capability exists to currect errors like this. 
>
>Months after the project ends, an unprincipled pimp might reach into
>your account with such a 'correction'. Then the burden is on you to
>get it back. Be sure to withdraw direct deposit authorization the day
>after the last paycheck hits. 

There's never been a necessity for other folks to have access to my bank 
account that I've found pressing enough to allow them direct deposit (and 
withdrawal) priveleges; were I to find myself in such circumstances I'd 
most likely open up a new account just for paycheck deposit containing 
just enough of a balance to avoid fees, write a check from that account to 
my 'real' account for each paycheck and close the sucker out when I hit 
the beach.

DD

0
docdwarf (6044)
9/8/2004 9:45:21 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:bhuuj0d73a14v8tggg3f6lcr76fuu3end3@4ax.com...
> On Wed, 8 Sep 2004 10:27:26 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
> >"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> >news:r9duj0tmesi1ks6qal3k3qcu18tken3vu9@4ax.com...
> >> On Wed, 8 Sep 2004 15:40:58 GMT, "Howard Brazee" <howard@brazee.net>
> >> wrote:
> >>
> >> >It would be nice if the COPY REPLACING statement was designed from the
> >scratch
> >> >for prefixes and suffixes.
> >> >
> >> >I wanted to use it to change the prefix on a file and also replace
> >==comp-3== by
> >> >==display==.
> >>
> >> You're using prefix as a non-standard form of qualification.
> >
> >Strikes me more likely he's using the prefix to provide a "form of
> >qualification" that COBOL doesn't otherwise provide save through unique
> >identifiers.
> >
> >> If you used qualification as defined in the standard, there wouldn't be
a
> >> problem.
> >
> >I'm sure he would if he could figure out the syntax by which one
qualifies a
> >*file name*.
>
> When Howard said "on a file", he didn't mean the file name per se, he
> meant datanames in a 'file copybook'. If the file name is 'INV', all
> datanames are prefixed with 'INV-'.

I don't know that for a fact.   I'm curious as to how you came by that
information; I don't see it in the thread.

Moreover, in a case in which a symbol file containing both the file
description and its associated record description is invoked into a program
multiple times, I can certainly see some benefit to using REPLACING to
provide unique file names (as well as, or even separately from, providing
unique 01-level record names) while simultaneously changing the USAGE of
some data items.

> The solution, per the standard, is to qualify names with 'IN INV'.

True, for datanames ... 'splain for me, please, how you'd incorporate the
following library named LIB  multiple times in the same program *without*
using REPLACING  ...

    FD  SOMEFILE.
    01  GENERIC-RECORD.
        03  A-FIELD PIC 9(4) USAGE INVALID.

I could see, for example, some benefit to a sequence like:
    COPY LIB REPLACING LEADING ==SOME== BY ==FIRST-==,
                REPLACING LEADING ==GENERIC-== BY ==FIRST-==,
            REPLACING INVALID BY DISPLAY.
    COPY LIB REPLACING LEADING ==SOME== BY ==SECOND-==,
            REPLACING LEADING ==GENERIC-== BY ==SECOND-==,
            REPLACING INVALID BY COMPUTATIONAL.

You could even add REPLACING ==A-== BY ==SECOND-FILE-== to *both* COPY
statements if you wished, but it's not clear to me that that's what Howard
intended as his FIRST goal.

And to the hypothetical response "But nobody in his right mind would ever
consider doing anything remotely like that!", I have to say twenty years of
supporting compilers leads me to the conclusion that that is *never* a
useful, or even meaningful, rejoinder!

    -Chuck Stevens


0
9/8/2004 10:18:55 PM
"Howard Brazee" <howard@brazee.net> wrote 

> > > Also have the function return an error code that can be checked without
> > > aborting
> > > when the function fails.
> >
> > That is difficult to do when a function can only return a single
> > value.
> 
> One can consider READ to be an equivalent of a function.   We can look at return
> codes in a couple of different ways with a READ statement, without leaving the
> paragraph.

What you are suggesting is a 'side effect' not the original
requirement to 'return an error'. 'return' has a specific meaning
especially when used with 'function'.

But no, I wouldn't consider READ to be a _function_ at all.  It is a
statement.  It happens to have a side effect of setting a file status
result.  It may also have other side effects.

> > Also functions may be buried in expressions that will use the return
> > as part of the calculation.  What would happen if a function returned
> > an 'error code' and this was used by the calculation ?
> 
> The return error code cannot be the returned value, it has to be separate.   

That's what I said. But side effects are not easily done either. 
There needs to be a mechanism for raising exceptions.

> But you do bring up a point - some priority needs to be established for nested
> functions.

'nested' is the natural habitat for functions.  If you aren't going to
nest them then there is not much point in them being functions, they
may as well be called procedures.
0
riplin (4127)
9/8/2004 10:51:54 PM
Richard wrote:
> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
> 
>>It's worse in the Unix world because the standard text editor -- vi --
>>sucks big time. It's so bad that it's unusable, IMO. I wind up copying
>>files to my desktop, editing there and copying back.
> 
> The Unix world comes with _several_ text editors, it is only necessary
> to change your preferences to another from those already installed or
> by installing some other.
> 
> But then vi is only 'unusable' to those who haven't learned to use it,
> just like any other tool.
> 
> Personally, I find Midnight Commander and SetEdit suit my needs, but I
> can use vi if I have to.

I've been using vi since I started messing around with Linux.  Our 
office uses the program Visual SlickEdit (http://www.slickedit.com) for 
our desktop editing.  It's a Windows-based program, of course, but using 
the latest version of wine, and copying one DLL from a "real" Windows 
installation, it's up and working great.

It's not cheap, but it's now what I use for all my source code editing. 
  (Still have to boot back to Windows to compile the PC-based COBOL 
stuff - I haven't gotten Fujitsu COBOL to install under wine yet.)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/9/2004 2:42:06 AM
Peter Lacey wrote:
> LX-i wrote:
> 
>>Peter Lacey wrote:
>>
>>>LX-i wrote:
>>>
>>>>And EVALUATE differs from a CASE statement *how*, exactly?  That's
>>>>COBOL's version of a case statement.  :)
>>>
>>>The mind boggles!
>>>
>>>Let me ask you first:  how many languages are you fluent in?  That will
>>>determine how I reply.
>>
>>Mostly English - a little bit of Spanish...  ;)
> 
> mas agua caliente, por favor ...

more hot water, please?  :)

> BEGIN CASE
>  CASE x = y
> ...
>  CASE b = a
> ...
>  CASE TRUE  (i.e., the default)
> ...
> END CASE

Where was that?

> CASE variable
>  WHEN value
> ...
>  WHEN another value
> ...
>  ELSE (default)
> END CASE.

EVALUATE myVar
   WHEN value1   perform heyIts1
   WHEN value2   perform heyIts2
   WHEN OTHER    perform itAint1or2
END-EVALUATE.

> I see from somebody else's post that EVALUATE was implemented to encode
> decision tables (which I didn't know);  that gives it a rationale; but
> it's still an abomination.  You can equate various aspects of EVALUATE
> to either style, as you please.

I guess I don't understand your "abomination" label - doesn't it 
directly support CASE statement format #2?

> (Please note that I don't have an up-to-date COBOL reference).

:)  I'm in a pretty much standard COBOL 85 (with intrinsic functions) 
shop - is that "up-to-date"?


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/9/2004 2:49:44 AM
..    Am  08.09.04
schrieb  lxi0007@netscape.net (LX-i)
    auf  /COMP/LANG/COBOL
     in  5qP%c.45639$5s3.36066@fe40.usenetserver.com
  ueber  *nix text editors (Was: If you were inventing CoBOL...)

l> It's not cheap, but it's now what I use for all my source code
l> editing.   (Still have to boot back to Windows to compile the PC-based
l> COBOL stuff - I haven't gotten Fujitsu COBOL to install under wine
l> yet.)

   Why don't you get KOBOL for Linux? It costs only 60 USD. And I  
would think that Eclipse is a good source text editor for that.

   http://www.thekompany.com

Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Kein Land kann seine Probleme in dieser globalisierten Welt allein
auf sich gestellt l�sen. Entweder wir retten uns alle zusammen oder
wir gehen zusammen unter. Heute mehr denn je gilt das Wort von Jos�
Mart�: Das Vaterland ist die ganze Menschheit."
               - Fidel Castro, Caracas (Veneuzuela), 3. Februar 1999
0
l.willms1 (637)
9/9/2004 6:23:00 AM
..    Am  08.09.04
schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
    auf  /COMP/LANG/COBOL
     in  c4puj0tqk37476s5fuka54i2s8ci6mcpcl@4ax.com
  ueber  Re: If you were inventing CoBOL...

RW> I had the same situation. The company reached into my checking
RW> account via 'direct deposit' and took it back BEFORE talking to me.
RW> Most people don't realize that direct deposit is bi-directional.  The
RW> capability exists to currect errors like this.
RW>
RW> Months after the project ends, an unprincipled pimp might reach into
RW> your account with such a 'correction'. Then the burden is on you to
RW> get it back. Be sure to withdraw direct deposit authorization the day
RW> after the last paycheck hits.

  Can't you instruct your bank to cancel that transaction?

  Under German law, such a direct debit can be cancelled up to 6 weeks  
after the debit date.


Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Die Interessen der Nation lassen sich nicht anders formulieren als unter
dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
Herrschaft anstrebt."            - Leo Trotzki         (27. Januar 1932)
0
l.willms1 (637)
9/9/2004 6:50:00 AM
In article <9GW2O0r9flB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
>.    Am  08.09.04
>schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
>    auf  /COMP/LANG/COBOL
>     in  c4puj0tqk37476s5fuka54i2s8ci6mcpcl@4ax.com
>  ueber  Re: If you were inventing CoBOL...
>
>RW> I had the same situation. The company reached into my checking
>RW> account via 'direct deposit' and took it back BEFORE talking to me.
>RW> Most people don't realize that direct deposit is bi-directional.  The
>RW> capability exists to currect errors like this.
>RW>
>RW> Months after the project ends, an unprincipled pimp might reach into
>RW> your account with such a 'correction'. Then the burden is on you to
>RW> get it back. Be sure to withdraw direct deposit authorization the day
>RW> after the last paycheck hits.
>
>  Can't you instruct your bank to cancel that transaction?

I will qualify this by saying that my knowledge about such things is 
close to a decade out-of-date, Mr Willms, but... to the best of my 
knowledge, no.

>
>  Under German law, such a direct debit can be cancelled up to 6 weeks  
>after the debit date.

One of the reasons that I stopped using direct-deposit mechanisms was 
being told by... someone whom the bank had answering the question-line 
about such matters that once a company had been given authorisation to 
make direct deposits (and the irremovable, associated authority to make 
direct withdrawals by merely changing the sign on the transaction) this 
authority could not be revoked except by changing accounts.

I do not know if this was true at the time - those who answer the 
telephone at various institutions might, possibly, not have the fullest 
and most subtle knowledge of said institution's policies and capabilities 
- and I do not know if it is true now... but having this revealed to me 
has caused me, as noted in another posting, to shun direct deposit 
entirely.

DD

0
docdwarf (6044)
9/9/2004 11:28:39 AM
On 8 Sep 2004 17:45:21 -0400, docdwarf@panix.com wrote:


>There's never been a necessity for other folks to have access to my bank 
>account that I've found pressing enough to allow them direct deposit (and 
>withdrawal) priveleges; were I to find myself in such circumstances I'd 
>most likely open up a new account just for paycheck deposit containing 
>just enough of a balance to avoid fees, write a check from that account to 
>my 'real' account for each paycheck and close the sucker out when I hit 
>the beach.

Better to open a second account at the same bank, use scheduled
electronic transfer to move funds to your main account. That way you
avoid float rules that violate the spirit, if not the letter, of
regulation CC. "It takes seven to ten days for an out of state check
to clear." Someone should create a twelve-step program for bankers'
addiction to float.
0
robert6624 (636)
9/9/2004 1:48:01 PM
resent, since the original post apparently didn't make it thru
--------- schnipp -----------------------------------------

..    Am  02.09.04
schrieb  howard@brazee.net (Howard Brazee)
    auf  /COMP/LANG/COBOL
     in  ch782q$16s$1@peabody.colorado.edu
  ueber  If you were inventing CoBOL...

HB> If you were inventing CoBOL back when, what would you do differently?

   My dear, what a question.

   I guess I would not have invented COBOL at all, but Oberon, or  
Component Pascal, as they call its latest incarnation. Or Ada ...

   ... and a Report Writer module


   Anyway, COBOL should have had "Inline PERFORM" from the beginning,  
and all those improvements from COBOL-85 which made a real programming  
language out of it.  No GOTO and no ALTER.



Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Es sind nicht die Gener�le und K�nige, die die Geschichte machen,
sondern die breiten Massen des Volkes"                - Nelson Mandela
0
l.willms1 (637)
9/9/2004 1:52:00 PM
When I was commissioned, a bank in Maryland offered me a direct deposit checking
account - with the guarantee that if the USAF screwed up and didn't get the
money to the bank - I could spend it anyway.

I took them up on that offer, and in subsequent jobs where direct deposit was
offered, took them up too.   Nowadays, my wife checks on the internet to see
when the deposit has been made, but I never have worried about it - it always
works as advertised.
0
howard (6283)
9/9/2004 1:57:44 PM
On  8-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> I could see, for example, some benefit to a sequence like:
>     COPY LIB REPLACING LEADING ==SOME== BY ==FIRST-==,
>                 REPLACING LEADING ==GENERIC-== BY ==FIRST-==,
>             REPLACING INVALID BY DISPLAY.
>     COPY LIB REPLACING LEADING ==SOME== BY ==SECOND-==,
>             REPLACING LEADING ==GENERIC-== BY ==SECOND-==,
>             REPLACING INVALID BY COMPUTATIONAL.

My current compiler doesn't handle multiple REPLACING clauses.   It will do
nested COPY statements, but not with REPLACING.   It also doesn't handle
LEADING.

If I were designing CoBOL back when, I think I would have done the COPY
statement differently.   IDD copies work well, but they weren't available back
then.
0
howard (6283)
9/9/2004 2:04:03 PM
In article <m9l0k0pd9nt5oriajrc92417rdt4k47952@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 8 Sep 2004 17:45:21 -0400, docdwarf@panix.com wrote:
>
>
>>There's never been a necessity for other folks to have access to my bank 
>>account that I've found pressing enough to allow them direct deposit (and 
>>withdrawal) priveleges; were I to find myself in such circumstances I'd 
>>most likely open up a new account just for paycheck deposit containing 
>>just enough of a balance to avoid fees, write a check from that account to 
>>my 'real' account for each paycheck and close the sucker out when I hit 
>>the beach.
>
>Better to open a second account at the same bank, use scheduled
>electronic transfer to move funds to your main account.

Hmmmmm... I don't know how scheduled EFT works but any time I've done the 
manual version there's been an associated charge for it.  There'd also 
have to be some jiggery-pokery for 'substandard' weeks, holidays, vacation 
time and the like... perhaps some research would be in order should the 
need arise.

>That way you
>avoid float rules that violate the spirit, if not the letter, of
>regulation CC. "It takes seven to ten days for an out of state check
>to clear." Someone should create a twelve-step program for bankers'
>addiction to float.

Float is time, time is money, money is what bankers are in business to 
make... what comes next, reinstatement of usury laws?

Tangentially related... I'm in the habit of paying off my credit-cards in 
full every month.  The other day I got a statement saying that my interest 
rate on a card had been increased; I called Customer Service and asked 
why... the lass told me that they weren't earning enough on my account.  I 
asked two questions:

1) How much money would they have to earn in order to reinstate my lower 
rate? ('I can't answer that but the accounts are reviewed semi-annually 
for such considerations.'  'Oh... so you can tell me that what you earn 
now is 'not enough' but you cannot tell me what 'enough' is?'  'Well, if 
you want to put it *that* way, sir... but the accounts are reviewed 
semi-annually...')

2) My rate was increased because I did not use my card a certain way.  If 
I now use my card that way it is going to cost me more money.  Usually if 
someone wants to encourage a kind of behavior they charge less for it; if 
you want to encourage sales of an item you decrease the price.  What sense 
does it make to charge me more money for something that you want me to do?

(silence... 'Sir, it is our policy to...')

DD

0
docdwarf (6044)
9/9/2004 2:19:04 PM
On  9-Sep-2004, docdwarf@panix.com wrote:

> 2) My rate was increased because I did not use my card a certain way.  If
> I now use my card that way it is going to cost me more money.  Usually if
> someone wants to encourage a kind of behavior they charge less for it; if
> you want to encourage sales of an item you decrease the price.  What sense
> does it make to charge me more money for something that you want me to do?

Fortunately, there are scads of companies who will be glad to own your money for
a month at a time.   If that company doesn't want your business at a rate you're
comfortable with, it isn't too hard to find others which do.
0
howard (6283)
9/9/2004 2:50:41 PM
On 09 Sep 2004 06:50:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>.    Am  08.09.04
>schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
>    auf  /COMP/LANG/COBOL
>     in  c4puj0tqk37476s5fuka54i2s8ci6mcpcl@4ax.com
>  ueber  Re: If you were inventing CoBOL...
>
>RW> I had the same situation. The company reached into my checking
>RW> account via 'direct deposit' and took it back BEFORE talking to me.
>RW> Most people don't realize that direct deposit is bi-directional.  The
>RW> capability exists to currect errors like this.
>RW>
>RW> Months after the project ends, an unprincipled pimp might reach into
>RW> your account with such a 'correction'. Then the burden is on you to
>RW> get it back. Be sure to withdraw direct deposit authorization the day
>RW> after the last paycheck hits.
>
>  Can't you instruct your bank to cancel that transaction?

No. Fed Regulation E provides remedies for unauthorized transactions.
If the (former) employer is properly authorized to access your
account, you cannot rescind a transaction through the banking system.
Your only remedy is a civil lawsuit.


0
robert6624 (636)
9/9/2004 2:51:58 PM
On 9 Sep 2004 07:28:39 -0400, docdwarf@panix.com wrote:

>One of the reasons that I stopped using direct-deposit mechanisms was 
>being told by... someone whom the bank had answering the question-line 
>about such matters that once a company had been given authorisation to 
>make direct deposits (and the irremovable, associated authority to make 
>direct withdrawals by merely changing the sign on the transaction) this 
>authority could not be revoked except by changing accounts.

That's not true. You can withdraw the authorization. My bank does it
over the phone, others may insist it be in writing.
0
robert6624 (636)
9/9/2004 3:03:32 PM
On  9-Sep-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

>    I guess I would not have invented COBOL at all, but Oberon, or
> Component Pascal, as they call its latest incarnation. Or Ada ...

Which of those would have been possible and practical when CoBOL was being
designed?


>    Anyway, COBOL should have had "Inline PERFORM" from the beginning,
> and all those improvements from COBOL-85 which made a real programming
> language out of it.  No GOTO and no ALTER.

While I don't disagree with your recommendations - I have to ask what are the
qualities of "a real programming language" that you are referring to?
0
howard (6283)
9/9/2004 3:26:21 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:chpnsj$bc1$1@peabody.colorado.edu...
>
> On  8-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> > I could see, for example, some benefit to a sequence like:
> >     COPY LIB REPLACING LEADING ==SOME== BY ==FIRST-==,
> >                 REPLACING LEADING ==GENERIC-== BY ==FIRST-==,
> >             REPLACING INVALID BY DISPLAY.
> >     COPY LIB REPLACING LEADING ==SOME== BY ==SECOND-==,
> >             REPLACING LEADING ==GENERIC-== BY ==SECOND-==,
> >             REPLACING INVALID BY COMPUTATIONAL.
>
> My current compiler doesn't handle multiple REPLACING clauses.   It will
do
> nested COPY statements, but not with REPLACING.   It also doesn't handle
> LEADING.

REPLACING is Library Module Level 2 in both the '74 and '85 standards.
Sounds like your compiler implemented Level 1.  That's a really good example
of one of the reasons the '02 standard has no modules and no levels within
modules ...

LEADING and TRAILING are new in '02.

    -Chuck Stevens


0
9/9/2004 3:36:30 PM
In article <jsr0k0hi00bdmcrlbmipfm09b1h6m3765u@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 9 Sep 2004 07:28:39 -0400, docdwarf@panix.com wrote:
>
>>One of the reasons that I stopped using direct-deposit mechanisms was 
>>being told by... someone whom the bank had answering the question-line 
>>about such matters that once a company had been given authorisation to 
>>make direct deposits (and the irremovable, associated authority to make 
>>direct withdrawals by merely changing the sign on the transaction) this 
>>authority could not be revoked except by changing accounts.
>
>That's not true. You can withdraw the authorization. My bank does it
>over the phone, others may insist it be in writing.

As a Wise Person once said, Mr Wagner, 'Never believe anything you see 
posted on the UseNet, including this statement.'  Should I find myself in 
a position which requires direct deposit I'll do my best to keep this, and 
other advice, in mind.

DD

0
docdwarf (6044)
9/9/2004 3:36:50 PM
In article <cjprj0prq523koe9plmd31hr6v8m6jbs5t@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
> On 7 Sep 2004 14:58:51 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
> 
> >In article <v92qj0la20o04upld2p1aekgerlv2d825e@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
> >> >> It's worse in the Unix world because the standard text editor -- vi --
> >> >> sucks big time. It's so bad that it's unusable, IMO. I wind up copying
> >> >> files to my desktop, editing there and copying back.
> >
> >Yet many, many people are very productive with vi.  
> 
> I've seen one or two who were good at vi. The vast majority stumble
> and project inefficiency.

This may come as a shock, Robert, but your anecdotal experience does
not constitute a meaningful study.  Actual studies performed by actual
researchers have shown that vi is as productive for experienced users,
in general, as other editors.  (See eg [1] for abstracts.)

In any event, the thousands of happy vi users worldwide amply demonstrate
that your claim is bogus.

> >I've used many programming editors, on many platforms, and some of them
> >(OS/400's SEU comes to mind) did indeed suck.  vi, on the other hand,
> >is tremendously efficient and powerful.  Maybe the problem is you.
> 
> The problem is an editor that doesn't let you overtype changes, how
> basic is that?,

vi has an overtype mode - command R.

> doesn''t have Find All,

vi has find all - command :p.  Moreover, it has the very powerful
"global" command, :g, which lets you perform any ex command on all
matching lines.  And it has global find-and-replace (with regular
expressions and parameterized replacement), with or without
confirmation.

> doesn't let you navigate between files except by sequential cycling,

Nearly every "improved" vi clone, such as vim, supports multiple file
buffers.  vim ships as the default implementation of vi on a number
of Unix platforms.  The original vi didn't support multiple file
buffers because it was designed to be compact, and traditional vi
still doesn't because there's no demand to change it - everyone who
wants these features uses an improved vi.

> doesn't support hyperlinks,

A clear advantage.  "Supporting" hyperlinks is an idiotic feature.
An editor should not be an HTTP user agent or an FTP client.  (It's
likely that some vi clones do "support" hyperlinks, anyway.  And, of
course, even original vi supports replace-with-shell-command, which
combined with wget or the like will trivially "support" hyperlinks.
Wrap it in a macro if you like.)

> doesn't let you open multiple windows

"Graphical" vi clones do, but I don't count that an advantage (which
is why I don't use them).  vi is a terminal-window editor.  It doesn't
open any windows at all.  That's how I like my programs to work.

Here are reasonable reasons to avoid vi:

- "I don't like vi".
- "I find vi hard to use."
- "I find modal editing does not fit well with my work habits."
- "I prefer GUI interfaces, and a graphical vi is not available on my
  platform."
- "I have a different editor that I already like."

Here are unreasonable ones:

- "vi sucks."
- "No one [or "most people", or whatever unsubstantiated quantity you
  prefer] can use vi well."

In other words, while it's perfectly reasonable to dislike vi, it's
not reasonable to claim that's a deficiency in the editor.  vi wasn't
written for you.  There wouldn't have been any point of contention if
you'd simply written "I hate vi"; as usual, it's your claim that your
experience is universally applicable that's caused the difficulty.

Now, if you'd care to identify some important feature that you can
reasonably claim is desired by most programmers and lacking in vi,
then you might have an argument.  But consider first that two of the
five in your list above were outright wrong, another is widely
available in vi implementations, and the other two are of dubious
value.

-- 
Michael Wojcik                  michael.wojcik@microfocus.com

Advertising Copy in a Second Language Dept.:
   The precious ovum itself is proof of the oath sworn to those who set
   eyes upon Mokona: Your wishes will be granted if you are able to invest
   it with eternal radiance...   -- Noriyuki Zinguzi
0
mwojcik (1879)
9/9/2004 4:19:45 PM
I have a program with the following code in it:

01  TAPEOUT-RECORD.
    COPY LAMMASTP REPLACING == 01 == BY == 02 ==.
....

    COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.


It reads in a file I got via FTP, does a move corresponding, and then writes the
file out looking just like the tapes we used to get.

Ugly copies.   I had to use WORKING-STORAGE because I couldn't do two REPLACINGs
with the same copy.    Glad that the original COPY didn't have 02 levels.
0
howard (6283)
9/9/2004 4:32:12 PM
On 9 Sep 2004 10:19:04 -0400, docdwarf@panix.com wrote:

>In article <m9l0k0pd9nt5oriajrc92417rdt4k47952@4ax.com>,
>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>On 8 Sep 2004 17:45:21 -0400, docdwarf@panix.com wrote:

>Hmmmmm... I don't know how scheduled EFT works but any time I've done the 
>manual version there's been an associated charge for it. 

Transfers within the same bank do not generate an EFT/ACH transaction.
They are handled within the bank's computer and they are almost always
free.

>>That way you
>>avoid float rules that violate the spirit, if not the letter, of
>>regulation CC. "It takes seven to ten days for an out of state check
>>to clear." Someone should create a twelve-step program for bankers'
>>addiction to float.
>
>Float is time, time is money, money is what bankers are in business to 
>make...

How about customer service? What a novel idea. 

CitiBank used to have a service called c2it that effectively allowed
individuals to originate an ACH transaction. I transfer money to your
account .. shazam, it's there in milliseconds. The sending and
receiving accounts didn't have to be CitiBank, they could be in any
bank. They set it up to compete with PayPal. Then they realized I
could pay all my bills that way, as used to be the case with Checkfree
before banks put a stop to it. To protect float, and thereby deny
customer service, money coming from a personal checking account (but
not a credit card) went shazam into a CitiBank account, where it sat
four days, then shazam into your account. The service was 'free'. They
could have charged a fee, but bankers are so addicted to float they'd
rather inconvenience customers .. and then insult our intelligence by
calling it 'free'.

> what comes next, reinstatement of usury laws?

When the Feds passed usury laws in 1980, South Dakota was
grandfathered out. The governer (Janklow) changed State law to allow
big banks to charge whatever they wanted. CitiBank moved its credit
card operation to SD and became the State's largest employer.

0
robert6624 (636)
9/9/2004 4:32:59 PM
In article <khgtj0hcfgie0h32rhl1dbgghd0lf7fle2@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
> On 7 Sep 2004 20:05:34 -0700, riplin@Azonic.co.nz (Richard) wrote:
> 
> >Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
> >
> >> I've seen one or two who were good at vi. The vast majority stumble
> >> and project inefficiency.
> >
> >Was that 'the vast majority' of those that you have seen using vi
> >(possibly a small number) or were you asserting 'the vast majority' of
> >all vi users, even though you have no idea who they are ?
> 
> My sample is people I've watched, well over 100.

Well, considering sample size and methodology, I think it's safe to
disregard this data point entirely.

I've watched quite a few people learn to drive cars.  One or two were
good at it; the vast majority weren't.

> >> The problem is an editor that doesn't let you overtype changes, how
> >> basic is that?, 
> >
> >In what way does vi 'not let you overtype changes' ?  It may be that
> >you simply don't know how to do this.
> 
> I hit R, replacement character, cursor right, R, replacement
> character, etc. Is there another way?

Hit R, type replacement characters until you're done, hit Esc.  The
R command is "replace multiple characters"; it puts you in Replace
mode.

The vi command to replace a single character is "r".

I happily admit that vi is not easy for people who don't know it, and
the only real way to learn it is through experience.  That's true of
the vast majority of the tools I own, including the very simple ones
with no moving parts.  Ever seen someone try to hammer in a nail the
first time?

In any case, the original claim - that Unix software production is
somehow hampered by vi - is clearly nonsense, since Unix software
production races ever forward.  Indeed, it'd be good if something
*did* hamper Unix software production, since so much half-baked stuff
is thrown out there.

-- 
Michael Wojcik                  michael.wojcik@microfocus.com

I said, 'I need to put my soul into my work and it is well known that
computers haven't got a soul.'  My father said, 'The Americans are working
on it.'  -- Sue Townsend, _The Secret Diary of Adrian Mole, Aged 13 3/4_
0
mwojcik (1879)
9/9/2004 4:33:45 PM
01  TAPEOUT-RECORD.
    COPY LAMMASTP REPLACING == 01 == BY == 02 ==.
  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -   15 Line(

    COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.


The above code doesn't work.

It replaced PIC X(01) with PIC X(02)

What a pain.   I may have to have both copies in Working Storage, with a
replacing to change the name of the 01 level in one of them.
0
howard (6283)
9/9/2004 4:39:51 PM
In article <chv0k0hmd6c4nordam61o2lq5jchaf4rg5@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On 9 Sep 2004 10:19:04 -0400, docdwarf@panix.com wrote:
>
>>In article <m9l0k0pd9nt5oriajrc92417rdt4k47952@4ax.com>,
>>Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>>>On 8 Sep 2004 17:45:21 -0400, docdwarf@panix.com wrote:
>
>>Hmmmmm... I don't know how scheduled EFT works but any time I've done the 
>>manual version there's been an associated charge for it. 
>
>Transfers within the same bank do not generate an EFT/ACH transaction.
>They are handled within the bank's computer and they are almost always
>free.

Future conversation with bank Customer Service Rep:

'Of course we can set up a constant-sum, regularly scheduled internal EFT 
between accounts... but there's a $25 Service Initiation fee, a $10 
per-use fee, a $7.86 charge for Miscellaneous Graft and Corruption... oh 
yes, and this falls under Sub-Section L, that means a monthly charge of 
$15.27 for pastries.'

'Saaaayyyyy, what's the big idea?  I read on the UseNet where some guy 
posted that transfers like this are 'almost always free'!'

'Oh, you read that on the UseNet?  Well, that's a horse of a different 
color; not only are all the fees waived but *we* pay *you* for each 
transaction!'

>
>>>That way you
>>>avoid float rules that violate the spirit, if not the letter, of
>>>regulation CC. "It takes seven to ten days for an out of state check
>>>to clear." Someone should create a twelve-step program for bankers'
>>>addiction to float.
>>
>>Float is time, time is money, money is what bankers are in business to 
>>make...
>
>How about customer service? What a novel idea. 

Customer service is one thing... forgoing a chance to make a buck seems to 
be quite another.

[snip]

>> what comes next, reinstatement of usury laws?
>
>When the Feds passed usury laws in 1980, South Dakota was
>grandfathered out. The governer (Janklow) changed State law to allow
>big banks to charge whatever they wanted. CitiBank moved its credit
>card operation to SD and became the State's largest employer.

Charlie Wilson said 'What's good for General Motors is good for the 
USA'... in this case what's good for Citibank is good for South Dakota; 
better a call-center in Pierre than one in Hyderabad, neh?

DD

0
docdwarf (6044)
9/9/2004 5:37:19 PM
In article <chpvr102j6d@news1.newsguy.com>,
Michael Wojcik <mwojcik@newsguy.com> wrote:

[snip]

>In other words, while it's perfectly reasonable to dislike vi, it's
>not reasonable to claim that's a deficiency in the editor.

'Only a fool blames his tools, but... (skritch scratch skritch)... 
damnation, stupid pen's out of ink.'

DD

0
docdwarf (6044)
9/9/2004 5:40:33 PM
..    Am  09.09.04
schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
    auf  /COMP/LANG/COBOL
     in  93r0k0lfh7cl8enneeums84l0nejn7ujc1@4ax.com
  ueber  Re: If you were inventing CoBOL...

RW> No. Fed Regulation E provides remedies for unauthorized transactions.
RW> Your only remedy is a civil lawsuit.

   Withdrawing from my account _is_ unauthorized. And "Fed Regulation  
E" provides as only remedy a civil lawsuit?

   This is really weird.

RW> If the (former) employer is properly authorized to access your
RW> account, you cannot rescind a transaction through the banking system.

   Authorized to transfer my salary to it, but not authorized to make  
withdrawals.

   I may authorize the utility or phone companies to withdraw their  
invoices, but I can also cancel such a withdrawal when I think it is  
unjustified. It is then _their_ problem to get the money from me,  
maybe in the end thru a civil lawsuit. The bank has not the slightest  
interest in being part of that contention. Seems that consumers are  
(still) better protected in Germany than in the USA.

   Not long time ago, some jerk who had seen my account number on my  
website, which is published there, so that people can make donations  
for the costs of the website, and placed an order with Fleurop (a  
flower delivery service), charging this bank account. As soon as I saw  
that, I got my bank to cancel that debit, and also informed Fleurop  
about it, who then apologized. The jerk only wanted to hurt me, since  
he got the flowers to be sent to an invalid address.

   Well, seems hard to understand in the USA, where (in 1987) 83% of  
all non-cash-transactions were done by cheque, while in Germany 55% by  
transfer (direct credit) and 36% by withdrawal (which includes also  
most credit card payments, which are withdrawn monthly from the bank  
account). I see payment by cheque as quite archaic and very expensive.


Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Die Interessen der Nation lassen sich nicht anders formulieren als unter
dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
Herrschaft anstrebt."            - Leo Trotzki         (27. Januar 1932)
0
l.willms1 (637)
9/9/2004 5:54:00 PM
..    Am  09.09.04
schrieb  howard@brazee.net (Howard Brazee)
    auf  /COMP/LANG/COBOL
     in  chpsmt$2je$1@peabody.colorado.edu
  ueber  Re: If you were inventing CoBOL...

>>    I guess I would not have invented COBOL at all, but Oberon, or
>> Component Pascal, as they call its latest incarnation. Or Ada ...

HB> Which of those would have been possible and practical when CoBOL was
HB> being designed?

   Oberon, being a lean one, might have been practical, I guess.

   But the main problem was, that the general thinking in the computer  
industry was not up to that point. At least Algol-60 had a simple  
repetition statement, a FOR with a UNTIL and a WHILE clause, but the  
language specification explained that in form of a GOTO loop.


>>    Anyway, COBOL should have had "Inline PERFORM" from the beginning,
>> and all those improvements from COBOL-85 which made a real programming
>> language out of it.  No GOTO and no ALTER.

HB> While I don't disagree with your recommendations - I have to ask what
HB> are the qualities of "a real programming language" that you are
HB> referring to?

  The introduction of the so-called "inline PERFORM" by the 1985  
standard.


Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung m�glich"        - Friedrich Engels      (Februar 1865)
0
l.willms1 (637)
9/9/2004 6:16:00 PM
Howard,
  I thought that you were using an IBM mainframe compiler?  They *all* support 
multiple REPLACING phrases.

For (oldest that is online) VS COBOL II, see:
  http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYL1101/4.4

For (current online) Enterprise COBOL, see:
 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR20/8.1.7

Possibly your mistake was that you (like Chuck below <G>) erroneously repeated 
the keyword "REPLACING"?

You may NOT (in a Standard - '85 or '02) compiler repeat the replacing keyword, 
but you may have as many

   ==operand-1== by ==operand-2==

phrases as you want.

P.S.  Or is this one of your IDMS pre-compiler problems?

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message 
news:chpnsj$bc1$1@peabody.colorado.edu...
>
> On  8-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>> I could see, for example, some benefit to a sequence like:
>>     COPY LIB REPLACING LEADING ==SOME== BY ==FIRST-==,
>>                 REPLACING LEADING ==GENERIC-== BY ==FIRST-==,
>>             REPLACING INVALID BY DISPLAY.
>>     COPY LIB REPLACING LEADING ==SOME== BY ==SECOND-==,
>>             REPLACING LEADING ==GENERIC-== BY ==SECOND-==,
>>             REPLACING INVALID BY COMPUTATIONAL.
>
> My current compiler doesn't handle multiple REPLACING clauses.   It will do
> nested COPY statements, but not with REPLACING.   It also doesn't handle
> LEADING.
>
> If I were designing CoBOL back when, I think I would have done the COPY
> statement differently.   IDD copies work well, but they weren't available back
> then. 


0
wmklein (2605)
9/9/2004 6:38:52 PM
On  9-Sep-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> Possibly your mistake was that you (like Chuck below <G>) erroneously repeated
>
> the keyword "REPLACING"?
>
> You may NOT (in a Standard - '85 or '02) compiler repeat the replacing
> keyword,
> but you may have as many
>
>    ==operand-1== by ==operand-2==
>
> phrases as you want.

I had that error, but just tried
 COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==
                         ==EDUSERV-RECORD= BY ==XXXX==.

without luck.

For documentation I look at
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igylr205/8.1.4?ACTION=MATCHES&REQUEST=copy+replacing&TYPE=FUZZY&SHELF=&DT=20000927030801&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

or
 http://makeashorterlink.com/?S5F726149


> P.S.  Or is this one of your IDMS pre-compiler problems?

I don't see how.
0
howard (6283)
9/9/2004 7:08:18 PM
On 9 Sep 2004 16:19:45 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>In article <cjprj0prq523koe9plmd31hr6v8m6jbs5t@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:

>> doesn''t have Find All,
>
>vi has find all - command :p.  Moreover, it has the very powerful
>"global" command, :g, which lets you perform any ex command on all
>matching lines.  And it has global find-and-replace (with regular
>expressions and parameterized replacement), with or without
>confirmation.

What I had in mind is what I call 'live grep'. It searches all the
programs being edited and creates a 'grep document' containing
matching lines. You can put the cursor on a line and hit a key to see
it 'in context' in the original file; another keystroke returns you to
the grep. Overtyping and global changes in the grep document are
changing the original. The grep document doesn't contain copies of
lines, it contains pointers to them.

Ultra Edit has a similar feature.

>> doesn't let you navigate between files except by sequential cycling,
>
>Nearly every "improved" vi clone, such as vim, supports multiple file
>buffers.  vim ships as the default implementation of vi on a number
>of Unix platforms.  The original vi didn't support multiple file
>buffers because it was designed to be compact, and traditional vi
>still doesn't because there's no demand to change it - everyone who
>wants these features uses an improved vi.

How about a picklist of buffers rather than next, next, next?

>> doesn't support hyperlinks,
>
>A clear advantage.  "Supporting" hyperlinks is an idiotic feature.
>An editor should not be an HTTP user agent or an FTP client.  (It's
>likely that some vi clones do "support" hyperlinks, anyway.  And, of
>course, even original vi supports replace-with-shell-command, which
>combined with wget or the like will trivially "support" hyperlinks.
>Wrap it in a macro if you like.)

I was thinking of Cobol copybooks. You put the cursor on a line
containing copy or include (or just a file name), hit one key, it
takes every word on the line and searches the path for a file of that
name. It makes two passes, the first pass tries words containing a dot
or in uppercase or in quotes. When it finds the copybook or referenced
file, it adds it to the ring and opens it. One keystroke takes you to
the copybook.

>> doesn't let you open multiple windows
>
>"Graphical" vi clones do, but I don't count that an advantage (which
>is why I don't use them).  vi is a terminal-window editor.  It doesn't
>open any windows at all.  That's how I like my programs to work.

In text-mode editors it is reasonable to split the screen
(horizontally or vertically) into two windows. When editing Cobol, one
often wants to see the data division in one window and the procedure
division in another. When comparing two files, it is convenient to see
them side-by-side.

>Here are reasonable reasons to avoid vi:
>
>- "I don't like vi".
>- "I find vi hard to use."
>- "I have a different editor that I already like."

Those are my reasons.

>There wouldn't have been any point of contention if
>you'd simply written "I hate vi"; as usual, it's your claim that your
>experience is universally applicable that's caused the difficulty.

Yet another lesson in Usenet etiquette.
0
robert6624 (636)
9/9/2004 7:09:39 PM
On  9-Sep-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

> HB> While I don't disagree with your recommendations - I have to ask what
> HB> are the qualities of "a real programming language" that you are
> HB> referring to?
>
>   The introduction of the so-called "inline PERFORM" by the 1985
> standard.

Interesting.   I wonder what we were doing before we had that standard
available.
0
howard (6283)
9/9/2004 7:23:38 PM
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:0r10d.469576$ic1.45680@news.easynews.com...

> Possibly your mistake was that [Chuck] erroneously repeated
> the keyword "REPLACING"?

Right; misread the syntax diagram.

    -Chuck Stevens


0
9/9/2004 7:29:06 PM
docdwarf@panix.com wrote 

> Tangentially related... I'm in the habit of paying off my credit-cards in 
> full every month.  The other day I got a statement saying that my interest 
> rate on a card had been increased; 

I pay off my card in full (well actually I ensure that the wife pays
off her card, I just don't use credit cards), and here that means that
there never is any interest to pay, it only starts after the due date
a week or two after the statement arrives.

In this case the interest rate is irrelevant as it is never invoked.
0
riplin (4127)
9/9/2004 7:39:04 PM
Howard,
   The link you point to DOES show a "loop" for the replacing phrases. (See the 
"<" above operand-1).

Exactly what error are you getting when you try this copy statement?

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message 
news:chq9n1$r1o$1@peabody.colorado.edu...
>
> On  9-Sep-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
>> Possibly your mistake was that you (like Chuck below <G>) erroneously 
>> repeated
>>
>> the keyword "REPLACING"?
>>
>> You may NOT (in a Standard - '85 or '02) compiler repeat the replacing
>> keyword,
>> but you may have as many
>>
>>    ==operand-1== by ==operand-2==
>>
>> phrases as you want.
>
> I had that error, but just tried
> COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==
>                         ==EDUSERV-RECORD= BY ==XXXX==.
>
> without luck.
>
> For documentation I look at
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igylr205/8.1.4?ACTION=MATCHES&REQUEST=copy+replacing&TYPE=FUZZY&SHELF=&DT=20000927030801&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
>
> or
> http://makeashorterlink.com/?S5F726149
>
>
>> P.S.  Or is this one of your IDMS pre-compiler problems?
>
> I don't see how. 


0
wmklein (2605)
9/9/2004 7:41:16 PM
OOPS,
  Howard did you  cut and paste your source code - or re-type it?  You have

> COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==
>                         ==EDUSERV-RECORD= BY ==XXXX==.

which is missing the 2nd "=" after "EDUSERV-RECORD"

which will cause a compiler error.  If this was just a re-typing error, then I 
still want to see what the compiler is saying.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message 
news:chq9n1$r1o$1@peabody.colorado.edu...
>
> On  9-Sep-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
>> Possibly your mistake was that you (like Chuck below <G>) erroneously 
>> repeated
>>
>> the keyword "REPLACING"?
>>
>> You may NOT (in a Standard - '85 or '02) compiler repeat the replacing
>> keyword,
>> but you may have as many
>>
>>    ==operand-1== by ==operand-2==
>>
>> phrases as you want.
>
> I had that error, but just tried
> COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==
>                         ==EDUSERV-RECORD= BY ==XXXX==.
>
> without luck.
>
> For documentation I look at
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igylr205/8.1.4?ACTION=MATCHES&REQUEST=copy+replacing&TYPE=FUZZY&SHELF=&DT=20000927030801&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
>
> or
> http://makeashorterlink.com/?S5F726149
>
>
>> P.S.  Or is this one of your IDMS pre-compiler problems?
>
> I don't see how. 


0
wmklein (2605)
9/9/2004 7:44:46 PM
LX-i <lxi0007@netscape.net> wrote

> I've been using vi since I started messing around with Linux.  Our 
> office uses the program Visual SlickEdit (http://www.slickedit.com) for 
> our desktop editing.  It's a Windows-based program, of course, but using 
> the latest version of wine, and copying one DLL from a "real" Windows 
> installation, it's up and working great.
> 
> It's not cheap, but it's now what I use for all my source code editing. 
>   (Still have to boot back to Windows to compile the PC-based COBOL 
> stuff - I haven't gotten Fujitsu COBOL to install under wine yet.)

You might try using Win4Lin from Netraverse.com.  This provides an
environment in which Windows 98se or ME can be installed into the
Linux file system and then can be run as a window on one of your
desktops.  It actually can run a bit faster than when booted on the
same machine because the ext2/3 filesystem is faster than FAT32.

However, if your compiler uses a dongle and grubby hardware access
that may be an issue.  You should be able to get an
'try-before-you-buy' version, and as long as you have an existing
Win98 install CD ... with valid licence of course.
0
riplin (4127)
9/9/2004 8:02:50 PM
On  9-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:

> I pay off my card in full (well actually I ensure that the wife pays
> off her card, I just don't use credit cards), and here that means that
> there never is any interest to pay, it only starts after the due date
> a week or two after the statement arrives.

There are different psychologies that require different approaches to credit
cards.

Some people can't handle debit cards - they get overdrawn because they don't put
it down in their check-book as checks.

Some people can handle debit cards, but can't handle credit cards, again,
because they don't put down their charges in their check book as checks.    (Not
counting emergency use in the little-used credit card to buy a replacement
refrigerator, or airplane ticket to a funeral).

Some people use charge cards for all their expenditures, put the money in their
check books, and always have enough money to pay for them when due.
0
howard (6283)
9/9/2004 8:13:43 PM
On  9-Sep-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> Howard,
>    The link you point to DOES show a "loop" for the replacing phrases. (See
>    the
> "<" above operand-1).
>
> Exactly what error are you getting when you try this copy statement?


At the start of the listing (other errors are at the end)



   328  IGYLI0088-S   The "COPY" statement was invalid.  Expected "BY", but
   found "XXXX".  The statement was discarded.


   329  IGYLI0001-W   A blank was missing before character "X" in column 59.  A
   blank was assumed.


   329  IGYLI0001-W   A blank was missing before character "=" in column 63.  A
   blank was assumed.


000328         006400     COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==

000329         006410                             ==EDUSERV-RECORD= BY ==XXXX==.

000330         006500/

000331         006600 PROCEDURE DIVISION.

000332         006700


Alternatively, I can do:

000328         006400     COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.

000329C*      
************************************************************************
000330C*       *******   EDUSERV LOAN MASTER FILE COPYBOOK

000331C*      
************************************************************************
000332C*       *******   CHANGE LOG:

000333C*       *******   DLOWENS 11/14/95 MR12505  - EXPAND FILE LAYOUT/EDUSERVE
CHG   MR1250
000334C*       *******   RPAYNE 11/14/95  MR11421  - ADD FLDS TO LAYOUT FOR
NSLDS      MR1142
000335C*       *******   RPAYNE 11/14/95  MR10661  - ADD FLDS TO LAYOUT
      MR1066
000336C*       *******   WC 4/93   NEW COPYBOOK CREATED  SR#6893

000337C*      
************************************************************************
000338C               01  EDUSERV-RECORD.

000339C                   05  LN-DETAIL-RECORD.

000340C                       10  LN-BORROWER-NAME              PIC X(30).

000341C                       10  LN-SOC-SEC-NUMBER             PIC S9(09)     
DISPLAY
....
0
howard (6283)
9/9/2004 8:20:26 PM
On  9-Sep-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> > COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==
> >                         ==EDUSERV-RECORD= BY ==XXXX==.
>
> which is missing the 2nd "=" after "EDUSERV-RECORD"

That was the problem.


> which will cause a compiler error.  If this was just a re-typing error, then I
>
> still want to see what the compiler is saying.

Posted in an earlier message.
0
howard (6283)
9/9/2004 8:23:39 PM
In article <217e491a.0409091139.5539780a@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>docdwarf@panix.com wrote 
>
>> Tangentially related... I'm in the habit of paying off my credit-cards in 
>> full every month.  The other day I got a statement saying that my interest 
>> rate on a card had been increased; 
>
>I pay off my card in full (well actually I ensure that the wife pays
>off her card, I just don't use credit cards), and here that means that
>there never is any interest to pay, it only starts after the due date
>a week or two after the statement arrives.
>
>In this case the interest rate is irrelevant as it is never invoked.

Oh, I *cannot* resist...

.... even though the rate is irrelevant... they raised it!  They raised my 
rate!  It's not a matter of the money, it is a matter of the interest's 
principal!

DD

0
docdwarf (6044)
9/9/2004 8:43:47 PM
On  9-Sep-2004, docdwarf@panix.com wrote:

> >In this case the interest rate is irrelevant as it is never invoked.
>
> Oh, I *cannot* resist...
>
> ... even though the rate is irrelevant... they raised it!  They raised my
> rate!  It's not a matter of the money, it is a matter of the interest's
> principal!

But are the principals interested?
0
howard (6283)
9/9/2004 8:56:55 PM
On Wed, 8 Sep 2004 15:18:55 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:bhuuj0d73a14v8tggg3f6lcr76fuu3end3@4ax.com...

>> When Howard said "on a file", he didn't mean the file name per se, he
>> meant datanames in a 'file copybook'. If the file name is 'INV', all
>> datanames are prefixed with 'INV-'.
>
>I don't know that for a fact.   I'm curious as to how you came by that
>information; I don't see it in the thread.

Howard later posted code showing that was true.

>Moreover, in a case in which a symbol file containing both the file
>description and its associated record description is invoked into a program
>multiple times, I can certainly see some benefit to using REPLACING to
>provide unique file names (as well as, or even separately from, providing
>unique 01-level record names) while simultaneously changing the USAGE of
>some data items.

I agree, except the record name need not be unique. Anyway, that
wasn't the case here.

>> The solution, per the standard, is to qualify names with 'IN INV'.
>
>True, for datanames ... 'splain for me, please, how you'd incorporate the
>following library named LIB  multiple times in the same program *without*
>using REPLACING  ...
>
>    FD  SOMEFILE.
>    01  GENERIC-RECORD.
>        03  A-FIELD PIC 9(4) USAGE INVALID.

You couldn't do it without REPLACING. That's why it's not customary to
put FD names in copybooks.

Some implementations extend the standard by replacing the record name
without the need for REPLACING. For example:

01  OUTPUT-RECORD COPY foo. 

Where foo reads:

01  INVENTORY-RECORD.
     02 ....

However, 'COPY foo' in a sentence by itself would use
INVENTORY-RECORD.

0
robert6624 (636)
9/9/2004 10:22:10 PM
Howard Brazee wrote:
> On  4-Sep-2004, LX-i <lxi0007@netscape.net> wrote:
> 
>>   - Fall-through pararaphs - only the first paragraph after "PROCEDURE
>>DIVISION" would be fallen through.  Of course, this mandates scope
>>delimiters for PERFORM, IF, etc. (which we currently have).
> 
> Why have any fall through paragraphs at all?   Without any being allowed, we
> don't need scope delimiters.   I don't see the advantage of having one fall
> through paragraph.

Well, program flow has to start _somewhere_ - are you saying don't have 
an initial paragraph?

>>   - User-defined functions that can return values - this goes along
>>with the point above.  You could say something like "MOVE FUNCTION
>>DATE-FORMAT (ws-some-var) TO FORMATTED-DATE", and have that function
>>return the character string.
> 
> Also have the function return an error code that can be checked without aborting
> when the function fails.

I think they've tried to make inroads on that with the 2002 standard.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/9/2004 10:22:36 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:qhf1k010k1f3o9o1o2v36o1botloa6eqol@4ax.com...
> On Wed, 8 Sep 2004 15:18:55 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
<snip>
> Some implementations extend the standard by replacing the record name
> without the need for REPLACING. For example:
>
> 01  OUTPUT-RECORD COPY foo.
>
> Where foo reads:
>
> 01  INVENTORY-RECORD.
>     02 ....
>
> However, 'COPY foo' in a sentence by itself would use
> INVENTORY-RECORD.
>

The behavior you describe above was available with IBM's OS/VS COBOL compiler - 
but only when it was running in '68 Standard mode (specified as LANGLVL(1)). 
When LANGLVL(2) (their '74 Standard mode) was in effect this did not work.

I won't swear to it (as I don't have the '68 and '74 Standards) but this may 
well be a difference between the two ANSI Standards.

-- 
Bill Klein
 wmklein <at> ix.netcom.com


-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
wmklein (2605)
9/9/2004 10:28:02 PM
Chuck Stevens wrote:
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:Cfn_c.43711$5s3.25919@fe40.usenetserver.com...
> 
>>   - Fall-through pararaphs - only the first paragraph after "PROCEDURE
>>DIVISION" would be fallen through.  Of course, this mandates scope
>>delimiters for PERFORM, IF, etc. (which we currently have).
> 
> Ooog  ... Add a paragraph label in the middle of code in an existing program
> and suddenly it doesn't fall through to what used to be the second
> paragraph?    I'd be mighty uncomfortable with such a rule ...

This was "if you were inventing it" - if it didn't exist, you wouldn't 
even think of adding a label in the middle of perfectly good executable 
statements.  :)

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/9/2004 10:36:50 PM
Chuck Stevens wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:chl3qb$kfp$1@peabody.colorado.edu...
> 
>>On  7-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>>
>>
>>>>   - Fall-through pararaphs - only the first paragraph after
> 
> "PROCEDURE
> 
>>>>DIVISION" would be fallen through.  Of course, this mandates scope
>>>>delimiters for PERFORM, IF, etc. (which we currently have).
[snip]
> I'd still be uncomfortable with a language specification in which control
> would fall through the second, and *only* the second, paragraph in a
> program.
> 
> I don't see that the standard for COBOL should *enforce* structure to a
> program, only that it should *allow* and *support* it.

PROCEDURE DIVISION.

Paragraph-1.
      perform me.
Paragraph-2.
      perform that.
      stop run.

What is the first paragraph after "PROCEDURE DIVISION"?  :)  I'm not 
advocating that Paragraph-2 be allowed to perform - execution would stop 
with the beginning of Paragraph-2.  Now, if you use the style that omits 
paragraph names completely, then only your "implied" paragraph would be 
fallen into.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/9/2004 10:47:39 PM
In article <chqg2m$oj9$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On  9-Sep-2004, docdwarf@panix.com wrote:
>
>> >In this case the interest rate is irrelevant as it is never invoked.
>>
>> Oh, I *cannot* resist...
>>
>> ... even though the rate is irrelevant... they raised it!  They raised my
>> rate!  It's not a matter of the money, it is a matter of the interest's
>> principal!
>
>But are the principals interested?

Some are, some aren't... I guess it depends on how principled they are.

DD

0
docdwarf (6044)
9/9/2004 10:53:51 PM
"Howard Brazee" <howard@brazee.net> wrote in message 
news:ch782q$16s$1@peabody.colorado.edu...
> If you were inventing CoBOL back when, what would you do differently?
>
> I wonder how foresight would have effected OO enhancements.
>
> I would like a USAGE LARGE for numbers that don't fit computer 
> architecture
> (have a hundred digits, but inefficient).
>
> Could we get away with enforced structure with the efficiencies back then?
>
> Would you do calls differently?
>
> I see no reason for margins on the left and in the right.
>
> I'd standardize GOBACK type exits.
>
> I'd really like to improve on error checking for calls and functions.

My wish list is modest: Scope Terminators.

IMO, the introduction of END-IF is by far the most important change to the 
language since I first started using it in 1980, and I wish it had been 
around from the beginning.   The lack of END-IF spawned a lot of ugly 
repetitious code which did much to detract from Cobol's reputation as a 
programming language.



0
leahydon (34)
9/9/2004 10:54:53 PM
Lueko Willms wrote:
> .    Am  08.09.04
> schrieb  lxi0007@netscape.net (LX-i)
>     auf  /COMP/LANG/COBOL
>      in  5qP%c.45639$5s3.36066@fe40.usenetserver.com
>   ueber  *nix text editors (Was: If you were inventing CoBOL...)
> 
> l> It's not cheap, but it's now what I use for all my source code
> l> editing.   (Still have to boot back to Windows to compile the PC-based
> l> COBOL stuff - I haven't gotten Fujitsu COBOL to install under wine
> l> yet.)
> 
>    Why don't you get KOBOL for Linux? It costs only 60 USD. And I  
> would think that Eclipse is a good source text editor for that.
> 
>    http://www.thekompany.com

I'll check it out.  Most of my cash is pre-allocated at this point, but 
maybe I'll be able to try it out.  First, I'd have to sell the Mrs. on 
it.  If I have a job where I could make money on it, it would be an easy 
sell.  But, if I outlaid the cash now, it would probably be easier to 
get a job making money with it.  :)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/10/2004 12:03:25 AM
Howard Brazee wrote:
> 01  TAPEOUT-RECORD.
>     COPY LAMMASTP REPLACING == 01 == BY == 02 ==.
>   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -   15 Line(
> 
>     COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.
> 
> 
> The above code doesn't work.
> 
> It replaced PIC X(01) with PIC X(02)
> 
> What a pain.   I may have to have both copies in Working Storage, with a
> replacing to change the name of the 01 level in one of them.

Why not

COPY LAMMASTP REPLACING TAPEIN-RECORD BY TAPEOUT-RECORD
....

MOVE CORR TAPEIN-RECORD TO TAPEOUT-RECORD

?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/10/2004 12:16:29 AM
Richard wrote:
> LX-i <lxi0007@netscape.net> wrote
> 
>>It's not cheap, but it's now what I use for all my source code editing. 
>>  (Still have to boot back to Windows to compile the PC-based COBOL 
>>stuff - I haven't gotten Fujitsu COBOL to install under wine yet.)
> 
> You might try using Win4Lin from Netraverse.com.  This provides an
> environment in which Windows 98se or ME can be installed into the
> Linux file system and then can be run as a window on one of your
> desktops.  It actually can run a bit faster than when booted on the
> same machine because the ext2/3 filesystem is faster than FAT32.
> 
> However, if your compiler uses a dongle and grubby hardware access
> that may be an issue.  You should be able to get an
> 'try-before-you-buy' version, and as long as you have an existing
> Win98 install CD ... with valid licence of course.

Hmm - all I've got is W2K Pro and XP Pro.  I'll still check it out, 
though - maybe I can dig around and see.  Seems an old computer I bought 
came with Win98...  Thanks for the tip.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/10/2004 12:30:23 AM
LX-i wrote:

> Howard Brazee wrote:
>
>> On  4-Sep-2004, LX-i <lxi0007@netscape.net> wrote:
>>
>>>   - Fall-through pararaphs - only the first paragraph after "PROCEDURE
>>> DIVISION" would be fallen through.  Of course, this mandates scope
>>> delimiters for PERFORM, IF, etc. (which we currently have).
>>
>>
>> Why have any fall through paragraphs at all?   Without any being 
>> allowed, we
>> don't need scope delimiters.   I don't see the advantage of having 
>> one fall
>> through paragraph.
>
>
> Well, program flow has to start _somewhere_ - are you saying don't 
> have an initial paragraph?

Well there's a truism. Somebody really *bright* reference OO, once 
wrote, "But you are thinking procedural", i.e. a "main", "begin", or 
whatever. Years ago went around a cookie factory in Wales. The damn 
things don't just create themselves ! Somebody has to chuck a whole lot 
of fat, flour, liquid  etc. into a vat - call it housekeeping if you 
like - but that starts the process. Oh yes - more 'housekeeping' - 
somebody has to clean up the bloody mess when the production is finished.

Jimmy
0
jjgavan (507)
9/10/2004 1:46:39 AM
"Howard Brazee" <howard@brazee.net> wrote 

> Some people can't handle debit cards - they get overdrawn because they don't put
> it down in their check-book as checks.

No, there's enough money there, it is just too complicated - you have
to find the card then there are buttons to press.  I just give them
money    ;-)
0
riplin (4127)
9/10/2004 1:57:37 AM
On 09 Sep 2004 17:54:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>.    Am  09.09.04
>schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
>    auf  /COMP/LANG/COBOL
>     in  93r0k0lfh7cl8enneeums84l0nejn7ujc1@4ax.com
>  ueber  Re: If you were inventing CoBOL...
>
>RW> No. Fed Regulation E provides remedies for unauthorized transactions.
>RW> Your only remedy is a civil lawsuit.
>
>   Withdrawing from my account _is_ unauthorized. 

You signed a paper saying they were authorized to access your account.
It didn't say for deposits only.

>And "Fed Regulation  E" provides as only remedy a civil lawsuit?

Regulation E doesn't apply. On second thought, a better cause of
action would be violation of Labor Laws (except in the five States
that don't have a Department of Labor). When they withdrew money, they
underpaid for work performed. That's a serious offense in the US, more
serious than stealing from consumers. In extreme cases, people go to
jail for violations.

>RW> If the (former) employer is properly authorized to access your
>RW> account, you cannot rescind a transaction through the banking system.
>
>   Authorized to transfer my salary to it, but not authorized to make  
>withdrawals.

If they make a mistake, they want to correct it through the same
mechanism.

>   I may authorize the utility or phone companies to withdraw their  
>invoices, but I can also cancel such a withdrawal when I think it is  
>unjustified. It is then _their_ problem to get the money from me,  
>maybe in the end thru a civil lawsuit. The bank has not the slightest  
>interest in being part of that contention. Seems that consumers are  
>(still) better protected in Germany than in the USA.

This is true. In the US, credit card charges can be reversed faily
easily. Utility companies seldom offer credit card billing; they want
access to your bank account.

>   Well, seems hard to understand in the USA, where (in 1987) 83% of  
>all non-cash-transactions were done by cheque, while in Germany 55% by  
>transfer (direct credit) and 36% by withdrawal (which includes also  
>most credit card payments, which are withdrawn monthly from the bank  
>account). I see payment by cheque as quite archaic and very expensive.

In 2004, the check percentage is down to 60%.

The US system is preserved by banks because of their addiction to
float. Twenty years ago, when the Federal Reserve cleared nearly all
checks, 95% of checks cleared overnight. Banks hated that. They set up
private clearing systems whose purpose was to slow things down. More
than half of US checks now clear through bank-run systems and take
longer to clear than 20 years ago. 

We have a good electronic transfer system (ACH) that's used for
businesses,  ATMs and debit cards. Individuals aren't allowed to use
it to pay bills. If they were, the check system would shrink to a
small fraction of its present size. Banks haven't let that happen.
Instead, they offer Online Banking, which gives the illusion of
electronic transfer while still preserving their float.

All this may change after Oct. 28, 2004, when a new law makes shipping
paper checks obsolete. A picture of the check will be taken when it
first hits the banking system. Beyond that point,  clearing will be
electronic. Consumers will no longer have the option to get an
original check with their statement; they will get a picture of it,
which the new law says is legal as an original. In principle, every
check should clear overnight. If that happens, banks might reluctantly
allow individuals to use ACH .. with a usage fee bigger than the float
they were getting before. With the Fed Funds rate at 1.5%, float isn't
as valuable as it used to be. Still, the value of one day's float on
42B checks with average face amount of just under $1K (businesses use
checks too) comes to $1.7B per year or .04 per check. To compensate
for almost 2 days float, they'd have to charge .08 to break even. My
guess is they'll go for 1.00, same as ATM, which costs much less than
..08 to process. 

Consider money orders, which are simply purchased checks. Money order
companies make ALL their profit off float and abandoned property. The
fee charged by stores, typically $1-2, stays at the store or pays
expenses such as forms and machines.  The average face amount of a
money order is $120 and the average float is 10 days. Using the
current Treasury Bond rate of 4.19, float income is .14 per. One
percent are abandoned, which adds interest of .35 and administrative
fees of .10 (this year's sale plus the previous 6 in inventory; after
7 years, gov't takes the money) bringing the total to .59.  Multiplied
by 1B sold per year in the US gives $590M profit. (I know averages
because I set up a money order company.)
0
robert6624 (636)
9/10/2004 2:52:12 AM
James J. Gavan wrote:
> LX-i wrote:
> 
>> Howard Brazee wrote:
>>
>>> Why have any fall through paragraphs at all?   Without any being 
>>> allowed, we
>>> don't need scope delimiters.   I don't see the advantage of having 
>>> one fall
>>> through paragraph.
>>
>> Well, program flow has to start _somewhere_ - are you saying don't 
>> have an initial paragraph?
> 
> Well there's a truism. Somebody really *bright* reference OO, once 
> wrote, "But you are thinking procedural", i.e. a "main", "begin", or 
> whatever. Years ago went around a cookie factory in Wales. The damn 
> things don't just create themselves ! Somebody has to chuck a whole lot 
> of fat, flour, liquid  etc. into a vat - call it housekeeping if you 
> like - but that starts the process. Oh yes - more 'housekeeping' - 
> somebody has to clean up the bloody mess when the production is finished.

:)

(I guess I wasn't clear enough with my first point about only one 
paragraph...  At least two really bright folks read something I didn't 
intend to write.  Funny thing, this "language" stuff...  :> )


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/10/2004 3:10:45 AM
On Thu, 9 Sep 2004 20:13:43 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>Some people can't handle debit cards - they get overdrawn because they don't put
>it down in their check-book as checks.

Some people can't handle checking accounts. My daughter would get  her
balance from an ATM, then spend that much. She couldn't understand why
checks kept bouncing. I tried explaining she had to deduct checks
written in the last 2-4 days because they were in-transit. Of course,
I didn't know what I was talking about. (Which explains why CLC makes
me feel 'at home').

Even sadder, she went to ghetto  high-school where she had taken a
course called Personal Finance. They spent a year teaching teens from
low-income families how create a household budget and how manage a
checking account. A whole year! How long does it take to learn to add
deposits and subtract checks? 
0
robert6624 (636)
9/10/2004 3:13:55 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> In text-mode editors it is reasonable to split the screen
> (horizontally or vertically) into two windows. When editing Cobol, one
> often wants to see the data division in one window and the procedure
> division in another. 

When I use vi I get that.

> When comparing two files, it is convenient to see
> them side-by-side.

I find it _much_ more convenient to use a file comparitor that put the
two files side by side with the difference highlighted.

Alternately I will use konsole or similar with two console sessions
one with each file and then rapidly flick between them so they overlay
each other and the differences stand out.
 
> >Here are reasonable reasons to avoid vi:
> >
> >- "I don't like vi".
> >- "I find vi hard to use."
> >- "I have a different editor that I already like."
> 
> Those are my reasons.

But your original comment was quite unlike those.
0
riplin (4127)
9/10/2004 3:14:39 AM
LX-i <lxi0007@netscape.net> wrote

> Paragraph-1.
>       perform me.
> Paragraph-2.
>       perform that.
>       stop run.
> 
> What is the first paragraph after "PROCEDURE DIVISION"?  :)  

Perhaps it is a terminolgy problem.  The first paragraph is 'perform
me'.  The first pargraph _label_ is 'paragraph-1'.
0
riplin (4127)
9/10/2004 3:18:41 AM
In article <NI40d.47509$5s3.32560@fe40.usenetserver.com>,
 LX-i <lxi0007@netscape.net> wrote:

> Howard Brazee wrote:
> > On  4-Sep-2004, LX-i <lxi0007@netscape.net> wrote:
> > 
> >>   - Fall-through pararaphs - only the first paragraph after "PROCEDURE
> >>DIVISION" would be fallen through.  Of course, this mandates scope
> >>delimiters for PERFORM, IF, etc. (which we currently have).
> > 
> > Why have any fall through paragraphs at all?   Without any being allowed, 
> > we
> > don't need scope delimiters.   I don't see the advantage of having one fall
> > through paragraph.
> 
> Well, program flow has to start _somewhere_ - are you saying don't have 
> an initial paragraph?

Why not allow program flow to begin with the first statement after the 
procedure division....

0
9/10/2004 3:56:22 AM
In article <chqfa3$rgt$1@panix5.panix.com>, docdwarf@panix.com wrote:

> Oh, I *cannot* resist...
> 
> ... even though the rate is irrelevant... they raised it!  They raised my 
> rate!  It's not a matter of the money, it is a matter of the interest's 
> principal!
> 
> DD

* Groan *

That hurt...

0
9/10/2004 4:00:15 AM
Joe Zitzelberger wrote:
> In article <NI40d.47509$5s3.32560@fe40.usenetserver.com>,
>  LX-i <lxi0007@netscape.net> wrote:
> 
> 
>>Howard Brazee wrote:
>>
>>>On  4-Sep-2004, LX-i <lxi0007@netscape.net> wrote:
>>>
>>>
>>>>  - Fall-through pararaphs - only the first paragraph after "PROCEDURE
>>>>DIVISION" would be fallen through.  Of course, this mandates scope
>>>>delimiters for PERFORM, IF, etc. (which we currently have).
>>>
>>>Why have any fall through paragraphs at all?   Without any being allowed, 
>>>we
>>>don't need scope delimiters.   I don't see the advantage of having one fall
>>>through paragraph.
>>
>>Well, program flow has to start _somewhere_ - are you saying don't have 
>>an initial paragraph?
> 
> Why not allow program flow to begin with the first statement after the 
> procedure division....

That would be fine - then you'd have no "fall-through" paragraphs.  :)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/10/2004 11:48:02 AM
On  9-Sep-2004, LX-i <lxi0007@netscape.net> wrote:

> > 01  TAPEOUT-RECORD.
> >     COPY LAMMASTP REPLACING == 01 == BY == 02 ==.
> >   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -   15 Line(
> >
> >     COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.
> >
> >
> > The above code doesn't work.
> >
> > It replaced PIC X(01) with PIC X(02)
> >
> > What a pain.   I may have to have both copies in Working Storage, with a
> > replacing to change the name of the 01 level in one of them.
>
> Why not
>
> COPY LAMMASTP REPLACING TAPEIN-RECORD BY TAPEOUT-RECORD
> ...
>
> MOVE CORR TAPEIN-RECORD TO TAPEOUT-RECORD

I did that.   Still, I would like to have that COPY REPLACING know the
difference between "   01  " and "(01)".
0
howard (6283)
9/10/2004 2:20:38 PM
On  9-Sep-2004, LX-i <lxi0007@netscape.net> wrote:

> > Why have any fall through paragraphs at all?   Without any being allowed, we
> > don't need scope delimiters.   I don't see the advantage of having one fall
> > through paragraph.
>
> Well, program flow has to start _somewhere_ - are you saying don't have
> an initial paragraph?

You don't "fall through" to the initial paragraph.   You start there.
0
howard (6283)
9/10/2004 2:21:43 PM
On 10-Sep-2004, LX-i <lxi0007@netscape.net> wrote:

> > Why not allow program flow to begin with the first statement after the
> > procedure division....
>
> That would be fine - then you'd have no "fall-through" paragraphs.  :)

If CoBOL had been designed without fall-through paragraphs, there would have
been no reason for a MAIN() label on the initial code.   Why bother putting a
label on the first "paragraph" that doesn't get explicitly performed?
0
howard (6283)
9/10/2004 2:24:09 PM
On 9 Sep 2004 18:53:51 -0400, docdwarf@panix.com wrote:

>In article <chqg2m$oj9$1@peabody.colorado.edu>,
>Howard Brazee <howard@brazee.net> wrote:
>>
>>On  9-Sep-2004, docdwarf@panix.com wrote:
>>
>>> >In this case the interest rate is irrelevant as it is never invoked.
>>>
>>> Oh, I *cannot* resist...
>>>
>>> ... even though the rate is irrelevant... they raised it!  They raised my
>>> rate!  It's not a matter of the money, it is a matter of the interest's
>>> principal!
>>
>>But are the principals interested?
>
>Some are, some aren't... I guess it depends on how principled they are.

..
Noting the success of Pibors and zero-strips, the US Treasury has
announced a new series of bonds with missing components. The new
series will be named after former Presidents and Vice-Presidents.

There will be the Dan Quayle Bond, which has no maturity. There will
be a Gerald Ford Bond, which has no interest. Finally, there will be a
Bill Clinton Bond, which has no principal.

0
robert6624 (636)
9/10/2004 2:46:56 PM
Robert Wagner wrote:
> On 9 Sep 2004 18:53:51 -0400, docdwarf@panix.com wrote:
> 
> 
>>In article <chqg2m$oj9$1@peabody.colorado.edu>,
>>Howard Brazee <howard@brazee.net> wrote:
>>
>>>On  9-Sep-2004, docdwarf@panix.com wrote:
>>>
>>>
>>>>>In this case the interest rate is irrelevant as it is never invoked.
>>>>
>>>>Oh, I *cannot* resist...
>>>>
>>>>... even though the rate is irrelevant... they raised it!  They raised my
>>>>rate!  It's not a matter of the money, it is a matter of the interest's
>>>>principal!
>>>
>>>But are the principals interested?
>>
>>Some are, some aren't... I guess it depends on how principled they are.
> 
> 
> .
> Noting the success of Pibors and zero-strips, the US Treasury has
> announced a new series of bonds with missing components. The new
> series will be named after former Presidents and Vice-Presidents.
> 
> There will be the Dan Quayle Bond, which has no maturity. There will
> be a Gerald Ford Bond, which has no interest. Finally, there will be a
> Bill Clinton Bond, which has no principal.
> 

You forgot the Bush Bond, that only friends of the president can redeem, 
but everyone else has to pay for.

Donald

0
donald_tees (563)
9/10/2004 3:41:15 PM
Howard Brazee wrote:
> On  9-Sep-2004, LX-i <lxi0007@netscape.net> wrote:
> 
> 
>>>01  TAPEOUT-RECORD.
>>>    COPY LAMMASTP REPLACING == 01 == BY == 02 ==.
>>>  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -   15 Line(
>>>
>>>    COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.
>>>
>>>
>>>The above code doesn't work.
>>>
>>>It replaced PIC X(01) with PIC X(02)
>>>
>>>What a pain.   I may have to have both copies in Working Storage, with a
>>>replacing to change the name of the 01 level in one of them.
>>
>>Why not
>>
>>COPY LAMMASTP REPLACING TAPEIN-RECORD BY TAPEOUT-RECORD
>>...
>>
>>MOVE CORR TAPEIN-RECORD TO TAPEOUT-RECORD
> 
> 
> I did that.   Still, I would like to have that COPY REPLACING know the
> difference between "   01  " and "(01)".

Ah - I missed that extra space you've got in there.  I understand now.  :)

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/10/2004 5:09:30 PM
In article <chq4ih$rss$1@panix5.panix.com>, docdwarf@panix.com writes:
> In article <chpvr102j6d@news1.newsguy.com>,
> Michael Wojcik <mwojcik@newsguy.com> wrote:
> 
> >In other words, while it's perfectly reasonable to dislike vi, it's
> >not reasonable to claim that's a deficiency in the editor.
> 
> 'Only a fool blames his tools, but... (skritch scratch skritch)... 
> damnation, stupid pen's out of ink.'

Heh.  Actually, I think it's quite reasonable to blame tools at
times, because tools can be poor.  If you're trying to turn a screw
and the handle of your screwdriver shatters, that's a defective tool
(assuming the screwdriver's only been used in the intended manner).

And, as I suggested above, I do think it's reasonable to claim that
you might be able to do a better job with tools more suited to you
personally, even if the tools available are not in themselves
defective.  I find it much easier to write on a whiteboard than on a
chalkboard, for example; that doesn't say anything negative about
the latter.  (I suppose whether that's "blaming the tool" or simply
admitting my own deficiency in using it is a matter of semantics.)

In fairness to Robert, I should admit that vi has a large number of
commands; that it is terse and not overly informative (here again
many of the clones improve on classic vi); and that it is almost
certainly unfamiliar (which is what people mean when they say
"unintuitive") to new users.  (I don't know of any editors other than
vi and its clones which have a similar interface, so newcomers are
likely to find it strange.)  These are barriers to quickly becoming
an expert, and a non-expert is likely to find vi difficult.


-- 
Michael Wojcik                  michael.wojcik@microfocus.com

A coding theorist is someone who doesn't think Alice is crazy.  -- John Gordon
0
mwojcik (1879)
9/10/2004 8:39:59 PM
In article <cht3ev04sb@news3.newsguy.com>,
Michael Wojcik <mwojcik@newsguy.com> wrote:
>
>In article <chq4ih$rss$1@panix5.panix.com>, docdwarf@panix.com writes:
>> In article <chpvr102j6d@news1.newsguy.com>,
>> Michael Wojcik <mwojcik@newsguy.com> wrote:
>> 
>> >In other words, while it's perfectly reasonable to dislike vi, it's
>> >not reasonable to claim that's a deficiency in the editor.
>> 
>> 'Only a fool blames his tools, but... (skritch scratch skritch)... 
>> damnation, stupid pen's out of ink.'
>
>Heh.  Actually, I think it's quite reasonable to blame tools at
>times, because tools can be poor.  If you're trying to turn a screw
>and the handle of your screwdriver shatters, that's a defective tool
>(assuming the screwdriver's only been used in the intended manner).

Both the tools and the craftsman have their limits, sure... and the 
possibility of shattering handles might just be one of the reasons that 
some folks insist on wooden-handled screwdrivers like the ones 
great-gran'ther used.

>
>And, as I suggested above, I do think it's reasonable to claim that
>you might be able to do a better job with tools more suited to you
>personally, even if the tools available are not in themselves
>defective.  I find it much easier to write on a whiteboard than on a
>chalkboard, for example; that doesn't say anything negative about
>the latter.  (I suppose whether that's "blaming the tool" or simply
>admitting my own deficiency in using it is a matter of semantics.)

Not a matter of semantics at all.  Consider:

'A chalkboard is more difficult to write on than a whiteboard.'

'I find it easier to write on a whiteboard than a chalkboard.'

Which states a preference, which assigns a condition to the circumstance?

>
>In fairness to Robert, I should admit that vi has a large number of
>commands; that it is terse and not overly informative (here again
>many of the clones improve on classic vi); and that it is almost
>certainly unfamiliar (which is what people mean when they say
>"unintuitive") to new users.

A description I heard was 'user-hostile'... but I will admit to preferring 
pico.

DD

0
docdwarf (6044)
9/10/2004 10:43:58 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote in message news:<hqr1k0pf6bkc893s69a9o4q2c9ebjbekfl@4ax.com>...
> >   I may authorize the utility or phone companies to withdraw their  
> >invoices, but I can also cancel such a withdrawal when I think it is  
> >unjustified. It is then _their_ problem to get the money from me,  
> >maybe in the end thru a civil lawsuit. The bank has not the slightest  
> >interest in being part of that contention. Seems that consumers are  
> >(still) better protected in Germany than in the USA.
> 
> This is true. In the US, credit card charges can be reversed faily
> easily. Utility companies seldom offer credit card billing; they want
> access to your bank account.


Here in Chicago, most (all?) of the utility companies will take credit
or debit cards.  They *will* hit you with a service charge for doing
so.  I suspect they don't really care, they just don't want the CC
company to take their cut.

In any event successfully disputing a utility bill via your credit
card company is likely going to be tough.  What would be the grounds? 
Fraud?  Non-delivery?  Faulty goods?  Lack of a purchase agreement?
0
robertwessel2 (1674)
9/11/2004 1:12:30 AM
In article <cht3ev04sb@news3.newsguy.com>,
 mwojcik@newsguy.com (Michael Wojcik) wrote:

> In fairness to Robert, I should admit that vi has a large number of
> commands; that it is terse and not overly informative (here again
> many of the clones improve on classic vi); and that it is almost
> certainly unfamiliar (which is what people mean when they say
> "unintuitive") to new users.  (I don't know of any editors other than
> vi and its clones which have a similar interface, so newcomers are
> likely to find it strange.)  These are barriers to quickly becoming
> an expert, and a non-expert is likely to find vi difficult.

Don't sugar coat it.  

I'm conversant with vi.  I've used vi.  I can and often find myself 
using vi.  It works, it will edit quickly and easily in a terminal 
window.  I am not scared of vi.

But let us face reality.

vi sucks.

It doesn't just suck in a normal, everyday lame tool way.  It really 
sucks.

vi sucks so badly that the entire viewership of alt.flame could not put 
voice to the expansive sucky-ness of vi.  The length and breath of the 
sucky-ness that is vi is beyond the bounds of human understanding.

Just in case I haven't made my point.  I think vi really sucks.

Sometime, the tool just sucks.

If, for example, you had a screwdriver that required you to key 
"<escape><cntl><shift>+" and hold the screwdriver with your left big toe 
in order to turn a screw clockwise.  (Although a philips head would 
require the '+' on the keypad, while a prince-reed would require 
"<escape><cntl><meta><F3>".)  And if this screwdriver required you to 
key "<escape><cntl>\+a", while holding the screwdriver in your elbow, in 
order to turn the screw anti-clockwise.  Well, you could assume that 
that tool would suck as well.

But even if such a screwdriver existed.  Even though such a screwdriver 
would indeed suck.  The sucky-ness of that screwdriver would be dwarfed 
by the imense sucky-ness of the editor that is vi.

0
9/11/2004 1:14:43 AM
Robert Wessel wrote:
> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote in message news:<hqr1k0pf6bkc893s69a9o4q2c9ebjbekfl@4ax.com>...
> 
>>>  I may authorize the utility or phone companies to withdraw their  
>>>invoices, but I can also cancel such a withdrawal when I think it is  
>>>unjustified. It is then _their_ problem to get the money from me,  
>>>maybe in the end thru a civil lawsuit. The bank has not the slightest  
>>>interest in being part of that contention. Seems that consumers are  
>>>(still) better protected in Germany than in the USA.
>>
>>This is true. In the US, credit card charges can be reversed faily
>>easily. Utility companies seldom offer credit card billing; they want
>>access to your bank account.
> 
> 
> 
> Here in Chicago, most (all?) of the utility companies will take credit
> or debit cards.  They *will* hit you with a service charge for doing
> so.  I suspect they don't really care, they just don't want the CC
> company to take their cut.
> 
> In any event successfully disputing a utility bill via your credit
> card company is likely going to be tough.  What would be the grounds? 
> Fraud?  Non-delivery?  Faulty goods?  Lack of a purchase agreement?

Here in Canada, I pay my utility bills at my bank's automated teller. 
There is no charge for it if I do it at my home branch.  Since I 
generally have to go to the bank once a week to deposit checks, it has 
never been a consideration.

Donald

0
donald_tees (563)
9/11/2004 2:01:34 AM
Joe Zitzelberger wrote:
>  mwojcik@newsguy.com (Michael Wojcik) wrote:
> 
> 
>>In fairness to Robert, I should admit that vi has a large number of
>>commands; that it is terse and not overly informative (here again
>>many of the clones improve on classic vi); and that it is almost
>>certainly unfamiliar (which is what people mean when they say
>>"unintuitive") to new users.  (I don't know of any editors other than
>>vi and its clones which have a similar interface, so newcomers are
>>likely to find it strange.)  These are barriers to quickly becoming
>>an expert, and a non-expert is likely to find vi difficult.
> 
> 
> Don't sugar coat it.  
> 
> I'm conversant with vi.  I've used vi.  I can and often find myself 
> using vi.  It works, it will edit quickly and easily in a terminal 
> window.  I am not scared of vi.
> 
> But let us face reality.
> 
> vi sucks.
> 
> It doesn't just suck in a normal, everyday lame tool way.  It really 
> sucks.
> 
> vi sucks so badly that the entire viewership of alt.flame could not put 
> voice to the expansive sucky-ness of vi.  The length and breath of the 
> sucky-ness that is vi is beyond the bounds of human understanding.
> 
> Just in case I haven't made my point.  I think vi really sucks.
> 
> Sometime, the tool just sucks.
> 
> If, for example, you had a screwdriver that required you to key 
> "<escape><cntl><shift>+" and hold the screwdriver with your left big toe 
> in order to turn a screw clockwise.  (Although a philips head would 
> require the '+' on the keypad, while a prince-reed would require 
> "<escape><cntl><meta><F3>".)  And if this screwdriver required you to 
> key "<escape><cntl>\+a", while holding the screwdriver in your elbow, in 
> order to turn the screw anti-clockwise.  Well, you could assume that 
> that tool would suck as well.
> 
> But even if such a screwdriver existed.  Even though such a screwdriver 
> would indeed suck.  The sucky-ness of that screwdriver would be dwarfed 
> by the imense sucky-ness of the editor that is vi.
> 


Tell us how you *really* feel.

Donald
;<)

0
donald_tees (563)
9/11/2004 2:13:15 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> >   Withdrawing from my account _is_ unauthorized. 
> 
> You signed a paper saying they were authorized to access your account.
> It didn't say for deposits only.

Robert, you have no idea at all what the wording on that paper
actually said. It may be that authorizations that you have seen are
such as this, but it is pure speculation on your part as to what it
said.

In the bank that I use there are autorizations for direct dosposits
and _separate_ authorizations for withdrawals which may indicate
specific amounts.

> >   Authorized to transfer my salary to it, but not authorized to make  
> >withdrawals.
> 
> If they make a mistake, they want to correct it through the same
> mechanism.

They may 'want' to do many things but their 'want' is not
autorization.
0
riplin (4127)
9/11/2004 7:26:20 PM
Joe Zitzelberger wrote:
> 
> Don't sugar coat it.  
> 
> I'm conversant with vi.  I've used vi.  I can and often find myself 
> using vi.  It works, it will edit quickly and easily in a terminal 
> window.  I am not scared of vi.
> 
> But let us face reality.
> 
> vi sucks.
> 
> It doesn't just suck in a normal, everyday lame tool way.  It really 
> sucks.
> 
> vi sucks so badly that the entire viewership of alt.flame could not put 
> voice to the expansive sucky-ness of vi.  The length and breath of the 
> sucky-ness that is vi is beyond the bounds of human understanding.
> 
> Just in case I haven't made my point.  I think vi really sucks.
> 
> Sometime, the tool just sucks.
> 
> If, for example, you had a screwdriver that required you to key 
> "<escape><cntl><shift>+" and hold the screwdriver with your left big toe 
> in order to turn a screw clockwise.  (Although a philips head would 
> require the '+' on the keypad, while a prince-reed would require 
> "<escape><cntl><meta><F3>".)  And if this screwdriver required you to 
> key "<escape><cntl>\+a", while holding the screwdriver in your elbow, in 
> order to turn the screw anti-clockwise.  Well, you could assume that 
> that tool would suck as well.
> 
> But even if such a screwdriver existed.  Even though such a screwdriver 
> would indeed suck.  The sucky-ness of that screwdriver would be dwarfed 
> by the imense sucky-ness of the editor that is vi.

This one is in my saved mail file now...  :)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
9/11/2004 8:24:26 PM
LX-i wrote:

> Joe Zitzelberger wrote:
>
>> But even if such a screwdriver existed.  Even though such a 
>> screwdriver would indeed suck.  The sucky-ness of that screwdriver 
>> would be dwarfed by the imense sucky-ness of the editor that is vi.
>
>
> This one is in my saved mail file now...  :)
>
Make sure you include Donald's question as well  :-)

0
jjgavan (507)
9/11/2004 9:37:35 PM
On 11 Sep 2004 12:26:20 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
>
>> >   Withdrawing from my account _is_ unauthorized. 
>> 
>> You signed a paper saying they were authorized to access your account.
>> It didn't say for deposits only.
>
>Robert, you have no idea at all what the wording on that paper
>actually said. It may be that authorizations that you have seen are
>such as this, but it is pure speculation on your part as to what it
>said.

A typical agreement can be found here:

www.accuchex.com/support/ forms/ACX.DirectDepositAgreement.pdf

I signed a similar document and a month after the gig ended, they
withdrew $1K from my account. 


0
robert6624 (636)
9/12/2004 3:14:57 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> >> You signed a paper saying they were authorized to access your account.
> >> It didn't say for deposits only.

> A typical agreement can be found here:

It is irrelevant what a _typical_ agreement is.  It is only important
what that exact agreement was that he signed, the bank can only
operate on that contract, not on what 'usually happens' or 'what I
thought it was'.

Your advise was exceedingly poor because it may have disuaded him from
actually finding out what his actual agreement was.

> I signed a similar document and a month after the gig ended, they
> withdrew $1K from my account.

Then you were a fool.  From any agreement if you dislike any clause or
condition just cross it out and initial it before you sign.  Of course
they may then decide that they won't accept that.
0
riplin (4127)
9/12/2004 7:31:38 PM
On 10-Sep-2004, robertwessel2@yahoo.com (Robert Wessel) wrote:

> Here in Chicago, most (all?) of the utility companies will take credit
> or debit cards.  They *will* hit you with a service charge for doing
> so.  I suspect they don't really care, they just don't want the CC
> company to take their cut.

I keep forgetting.   When I go to the SuperMarket and it gives a choice between
Debit and Credit cards, it doesn't mean the type of Debit cards that I am
familiar with.    I never have found out exactly what the new debit cards are,
but the old ones work just like credit cards at the store, but work like checks
for the consumer.    I think the new ones might be like phone cards, with a set
$ amount in them.    At any rate, if you have one of the old style debit cards,
you press CREDIT on the button to tell it how you're paying.
0
howard (6283)
9/13/2004 5:41:52 PM
In article <joe_zitzelberger-109528.21144310092004@knology.usenetserver.com>, Joe Zitzelberger <joe_zitzelberger@nospam.com> writes:
> 
> But let us face reality.
> 
> vi sucks.

Your opinion on the quality of vi is just as relevant as Robert's:
not particularly, to anyone other than yourself.  It is, in short,
subjective.  And so I would equally "facing reality" if I were to
declare, say, that vi is wonderful.

(Your screwdriver example isn't particularly apposite, either, since
it utterly fails to correspond to vi's operation, but that's neither
here nor there; it could be spot-on and still be irrelevant.)

There are some tools which are clearly, objectively, inferior to
others of their kind; and some of them are even relevant to
comp.lang.cobol.  Neither you nor Robert have yet presented an
argument to show that vi is one such, however.  Thus generalities
like "vi sucks" remain vapid and uninformative.

-- 
Michael Wojcik                  michael.wojcik@microfocus.com

We are subdued to what we work in.  (E M Forster)
0
mwojcik (1879)
9/13/2004 8:04:26 PM
On Mon, 13 Sep 2004 17:41:52 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>On 10-Sep-2004, robertwessel2@yahoo.com (Robert Wessel) wrote:
>
>> Here in Chicago, most (all?) of the utility companies will take credit
>> or debit cards.  They *will* hit you with a service charge for doing
>> so.  I suspect they don't really care, they just don't want the CC
>> company to take their cut.
>
>I keep forgetting.   When I go to the SuperMarket and it gives a choice between
>Debit and Credit cards, it doesn't mean the type of Debit cards that I am
>familiar with.    I never have found out exactly what the new debit cards are,
>but the old ones work just like credit cards at the store, but work like checks
>for the consumer.    I think the new ones might be like phone cards, with a set
>$ amount in them.    At any rate, if you have one of the old style debit cards,
>you press CREDIT on the button to tell it how you're paying.

The card that came with your checking account is *supposed* to work
both ways. You're telling the machine which network to send the charge
through, and whether to ask for a PIN or a signature.

I use such a card to buy all my groceries. Because I know debit cards
cost the store much less in service charges, I try debit first. If
that doesn't work, I run the same card through the credit card
network, which always works. My bank is in Texas. Moving around the
US, I've noticed regional differences in where the debit network
fails. In Texas, it always works. In the Midwest and South, it usually
works. In the NorthEast "Financial Services Capitol of the US", the
debit network fails more than half the time. The problem appears to be
in validating the bank's transit number. Somewhere in the network
there is a table of valid bank IDs and their network ids. NorthEastern
stores/networks, thinking the rest of the US doesn't matter, don't
have a complete table; they have only NorthEastern banks.

If you don't believe me, take your card to WalMart and select Debit.
It will work there.

ATM machines must use different networks. My card works in them
everywhere.


0
robert6624 (636)
9/13/2004 8:16:09 PM
"Howard Brazee" <howard@brazee.net> wrote 

> I keep forgetting.   When I go to the SuperMarket and it gives a choice between
> Debit and Credit cards, it doesn't mean the type of Debit cards that I am
> familiar with.    I never have found out exactly what the new debit cards are,
> but the old ones work just like credit cards at the store, but work like checks
> for the consumer.    I think the new ones might be like phone cards, with a set
> $ amount in them.    At any rate, if you have one of the old style debit cards,
> you press CREDIT on the button to tell it how you're paying.

In New Zealand, Debit Cards (EFTPOS) directly interact with the bank
and execute a direct transfer of funds from one account to another
from any EFTPOS terminal in the country at any shop, or even from
mobile terminals, at the time of the transaction.

Some other countries seem to have much less effective systems.
0
riplin (4127)
9/13/2004 11:04:13 PM
In article <f191k0t1vd53d4c9j857q8p918eomcdkd1@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
> On 9 Sep 2004 16:19:45 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
> >In article <cjprj0prq523koe9plmd31hr6v8m6jbs5t@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
> 
> >vi has find all - command :p.
> 
> What I had in mind is what I call 'live grep'. It searches all the
> programs being edited and creates a 'grep document' containing
> matching lines. You can put the cursor on a line and hit a key to see
> it 'in context' in the original file; another keystroke returns you to
> the grep. Overtyping and global changes in the grep document are
> changing the original. The grep document doesn't contain copies of
> lines, it contains pointers to them.

Ah, I see what you were referring to.  I don't know of a vi clone that
has that feature; vim or another might, but I haven't gone looking for
it.  I can see that it would be useful; it's just not the way I typically
work.  (I'm the sort who'd rather spend as much time automating a
repetitive task than do it manually.)

> >Nearly every "improved" vi clone, such as vim, supports multiple file
> >buffers.
> 
> How about a picklist of buffers rather than next, next, next?

vim has that.

> I was thinking of Cobol copybooks. You put the cursor on a line
> containing copy or include (or just a file name), hit one key, it
> takes every word on the line and searches the path for a file of that
> name. It makes two passes, the first pass tries words containing a dot
> or in uppercase or in quotes. When it finds the copybook or referenced
> file, it adds it to the ring and opens it. One keystroke takes you to
> the copybook.

That may be a bit too COBOL-specific for any of the vi clones, but vim
does have a general "open the filename under the cursor" command, and
it's possible to build fancier ones with macros.

> >> doesn't let you open multiple windows
> >
> >"Graphical" vi clones do, but I don't count that an advantage (which
> >is why I don't use them).  vi is a terminal-window editor.  It doesn't
> >open any windows at all.  That's how I like my programs to work.
> 
> In text-mode editors it is reasonable to split the screen
> (horizontally or vertically) into two windows.

vim provides split-screen editing (with as many splits as you can fit
in the terminal window) in character mode.  That's not the same as
opening new windows.  Split-screen I like and use all the time; new
windows I dislike and avoid where possible.

> >Here are reasonable reasons to avoid vi:
> >
> >- "I don't like vi".
> >- "I find vi hard to use."
> >- "I have a different editor that I already like."
> 
> Those are my reasons.

That's fine, but surely you see the difference between these
subjective evaluations and "vi sucks", which claims to be objective?

Anyway, enough about vi.  I like it, you don't; it does some of the
things you want an editor to do, but not all of them, and it is
certainly not all things to all people.

-- 
Michael Wojcik                  michael.wojcik@microfocus.com

Most people believe that anything that is true is true for a reason.
These theorems show that some things are true for no reason at all,
i.e., accidentally, or at random.  -- G J Chaitin
0
mwojcik (1879)
9/14/2004 5:47:31 PM
After my News-ISP has apparently fixed their problems with sending  
messages to COMP-Newsgroups, I dare to resubmit this 20 days old  
contribution of mine again.

--------- schnipp -----------------------------------------

..    Am  02.09.04
schrieb  charles.stevens@unisys.com (Chuck Stevens)
    auf  /COMP/LANG/COBOL
     in  ch8ccb$110j$1@si05.rsvl.unisys.com
  ueber  Re: If you were inventing CoBOL...

CS> That doesn't mean the techniques could reasonably be applied before
CS> they were invented.  I don't think GO TO in  COBOL is inherently evil
CS> any more than the branch instructions on the 1401 were.

   What is evil is not the existens of GOTO in COBOL, but that the  
lack of proper repetition statements did push programmers to program  
COBOL as if it were assembler. And many of those never learned to  
think in program structure, but only step-by-step walk throughs.

   GOTO is superfluous for a "High Level Language".

   I do most of my programming work in the language of a database  
development system, which doesn't have a GOTO. You might also check  
with your colleagues of the OS/1100 side for @SSG or Skeleton, which  
can do wonderful things like WFL and which doesn't know a GOTO.

CS> I don't think "if we had some ham, we could have some ham and eggs --
CS> if we had some eggs" speculations are useful; I'm personally limiting
CS> myself to things that I believe were, in my view,  architectural
CS> *errors*.  The presence or absence of GO TO is a religious war, and I
CS> personally know of *no* hardware architecture that omits it
CS> altogether.

   Sure, the hardware will know nothing else but jumps, but a 'High  
Level Language' should provide some abstraction from that hardware  
level and provide proper statements for repetition. These came to  
COBOL only with the 1985 standard.

CS> Even BALR on the System/360 did a *branch*.
CS> Speculation as to what the world would have been like if Dijkstra had
CS> been Grace Hopper's boss back in the 1950's aren't very useful in my
CS> view.   I think there's a case to be made for some mistakes in
CS> direction *at the time they were taken*, but I don't think
CS> eliminating GO TO from COBOL would have been appropriate in 1968 or
CS> even today.

   When COBOL could organize repetition of PERFORMed _procedures_ with  
VARYING a control variable, UNTIL a loop exit condition, n TIMES, I  
don't see any reason why the same should not have been possible with a  
local sequence of statements.


Yours,
L�ko Willms
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --



0
l.willms1 (637)
9/23/2004 9:11:00 AM
Since my Netnews-ISP has apparently solved their problems of  
forwarding messages when these are aimed at COMP.*-groups, I dare to  
resubmit this contribution, since I did not want to leave Howard  
Brazee without an answer to his question.


--------- schnipp -----------------------------------------

..     Am  09.09.04
 schrieb  howard@brazee.net (Howard Brazee)
     bei  /COMP/LANG/COBOL
      in  chqajq$1oa$1@peabody.colorado.edu
   ueber  Re: If you were inventing CoBOL...

HB>>> While I don't disagree with your recommendations - I have to ask
HB>>> what are the qualities of "a real programming language" that you
HB>>> are referring to?

LW>>   The introduction of the so-called "inline PERFORM" by the 1985
LW>> standard.

HB> Interesting.   I wonder what we were doing before we had that
HB> standard available.

   Either one of two workarounds:

1) Perform in loops other sections, from where one would again perform  
a third section, and so on; a solution which does not help very well  
to grasp the main dynamic structure of a process;

2) programming loops (repetitions) by hand using GOTO which is, in my  
opinion, even worse.



Yours,
L�ko Willms
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --


0
l.willms1 (637)
9/23/2004 9:16:00 AM
Response interleaved:

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9HPwxJ1uflB@jpberlin-l.willms.jpberlin.de...
> CS> That doesn't mean the techniques could reasonably be applied before
> CS> they were invented.  I don't think GO TO in  COBOL is inherently evil
> CS> any more than the branch instructions on the 1401 were.
>
>    What is evil is not the existens of GOTO in COBOL, but that the
> lack of proper repetition statements did push programmers to program
> COBOL as if it were assembler. And many of those never learned to
> think in program structure, but only step-by-step walk throughs.
>
>    GOTO is superfluous for a "High Level Language".

I guess my take on the earlier topic is more like "What in COBOL can now be
seen as a mistake *at the time it was developed*?".

At the time COBOL was developed, GO wasn't superfluous enough in Fortran or
Basic or ALGOL or any of the other higher-level languages around at the time
to warrant its omission from the language.   The "go-to-less" language with
which I am most familiar (and the one I'd argue is probably most in
compliance with Dijkstra's philosophy) had only one loop-control construct:
DO FOREVER, with a corresponding "IF <condition> UNDO", and it dates from
the early 1970's.

>    I do most of my programming work in the language of a database
> development system, which doesn't have a GOTO. You might also check
> with your colleagues of the OS/1100 side for @SSG or Skeleton, which
> can do wonderful things like WFL and which doesn't know a GOTO.

I have no doubt whatever that it's possible to write programs without GO TO
whether the language has the construct or not.  I've done so in both cases,
in fact.  But I think the *absence* of GO TO in the COBOL of 1960 would have
interfered with its acceptance.

>    Sure, the hardware will know nothing else but jumps, but a 'High
> Level Language' should provide some abstraction from that hardware
> level and provide proper statements for repetition. These came to
> COBOL only with the 1985 standard.

I agree, and I also think their proliferation is a Good Thing.  I would
encourage people to use them as a matter of style; I don't agree that COBOL
in 1960 should have followed the precepts Dijkstra published in 1968 or that
it was a mistake for Grace Hopper to have failed to do so.

> When COBOL could organize repetition of PERFORMed _procedures_ with
> VARYING a control variable, UNTIL a loop exit condition, n TIMES, I
> don't see any reason why the same should not have been possible with a
> local sequence of statements.

So the bottom line is "in-line PERFORM" should have been available earlier
than '85.  I don't have a problem with that.  ALGOL had its equivalent a
quarter-century before that.  But ALGOL had, and still has, GO as well.

Many, many times I have rewritten procedures in the ALGOL-dialect products I
work on for the sole purpose of getting rid of GO statements.  That does not
necessarily mean that the logic associated with the avoidance of GO is more
efficient at execution time.  It does mean (at least to me) that if there's
any extra (in this case compile-time) cost to our users associated with
logic alternative to GO and intra-procedure labels, that cost is worth
incurring in the interests of improved maintainability.  There are a few
cases in which it is really impractical to avoid it.  All this doesn't mean
I think ALGOL should have been designed without a GO statement from the
beginning; as for COBOL, I believe the absence of such a construct would
have interfered with the language's acceptance.

    -Chuck Stevens


0
9/23/2004 4:48:02 PM
On 23-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> I have no doubt whatever that it's possible to write programs without GO TO
> whether the language has the construct or not.  I've done so in both cases,
> in fact.  But I think the *absence* of GO TO in the COBOL of 1960 would have
> interfered with its acceptance.

I don't think it would.   It already was significantly different from other
languages of the time.   We would have used the tool as given to us.

I also don't think that removing ADD, SUBTRACT, MULTIPLY, and DIVIDE would have
hurt it.   We learned to use those verbs because they were part of the tool.
0
howard (6283)
9/23/2004 6:13:29 PM
..     Am  23.09.04
 schrieb  howard@brazee.net (Howard Brazee)
     bei  /COMP/LANG/COBOL
      in  civ3o9$m87$1@peabody.colorado.edu
   ueber  Re: "Goto statement considered superfluous" (was: If you were inventin

HB> On 23-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

>> I have no doubt whatever that it's possible to write programs without
>> GO TO whether the language has the construct or not.  I've done so in
>> both cases, in fact.  But I think the *absence* of GO TO in the COBOL
>> of 1960 would have interfered with its acceptance.

HB> I don't think it would.   It already was significantly different from
HB> other languages of the time.   We would have used the tool as given
HB> to us.

  It is of course quite speculative to make statements about what  
would have happend 45 years earlier.

  A fact is that the ideas about programming as a social and creative  
activity were not yet so evolved and widespread as we have absorbed  
them today. That E. Dijkstra's article about the GOTO-Statement had a  
reason to be writen and published, and sparked that discussion as it  
did, is a living proof of that.

  But it would have been possible, als in Algol-60 and maybe other  
programming languages of that time (not to speak of Konrad Zuse's  
'Plankalk�l', a very formalistic language, but with a looping  
construct) did have an iteration instruction, is also proof that it  
would have been thinkable to include that in COBOL as well. Algol-60  
had a "for" statement with a "while" and a "until" clause.

  COBOL should have had it at least with the first standard, COBOL-68,  
or then at least with COBOL-74.

HB> I also don't think that removing ADD, SUBTRACT, MULTIPLY, and DIVIDE
HB> would have hurt it.   We learned to use those verbs because they were
HB> part of the tool.

   Well, but those form an important part of the spirit and basic  
style of COBOL. I think, nobody has ever had any particular problem  
with that (except maybe to realize that in the basic form of MULTIPLY  
and DIVIDE the result is in the second operand).


Yours,
L�ko Willms
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --


0
l.willms1 (637)
9/23/2004 8:57:00 PM
On Thu, 23 Sep 2004 09:48:02 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>I have no doubt whatever that it's possible to write programs without GO TO
>whether the language has the construct or not.  I've done so in both cases,
>in fact.  But I think the *absence* of GO TO in the COBOL of 1960 would have
>interfered with its acceptance.

I agree. In 1968, when someone told me programs could be written
without GO TO, my reaction was "No, that's impossible." At the time I
was an IT manager making decisions about which languages we used. If
Cobol had lacked GO TO, we wouldn't have been using it there.

It's easy to say GO TO was a mistake, in retrospect. Consider that in
1960, most programmers knew only assembly language .. and maybe
Fortran. In their minds, a Branch/Jump function was essential. 
0
robert6624 (636)
9/23/2004 9:43:29 PM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9HQ2SRcPflB@jpberlin-l.willms.jpberlin.de...
> HB> I also don't think that removing ADD, SUBTRACT, MULTIPLY, and DIVIDE
> HB> would have hurt it.   We learned to use those verbs because they were
> HB> part of the tool.
>
>    Well, but those form an important part of the spirit and basic
> style of COBOL. I think, nobody has ever had any particular problem
> with that (except maybe to realize that in the basic form of MULTIPLY
> and DIVIDE the result is in the second operand).

I was thinking about that, and also thinking about responding to Howard
Brazee to similar effect.

It seems to me that four explicit arithmetic statements -- ADD, SUBTRACT,
MULTIPLY, DIVIDE -- are the "really native COBOL" constructs, and it's
COMPUTE and its acceptance of "arithmetic expressions" that represent the
exception to a basic precept envisioned by the original authors of COBOL.

ANSI X3.23-1985 reports that one of the criteria to be applied in the
initial design of COBOL was that it "avoid symbolism as far as possible."
I think COMPUTE can be considered a violation of that precept:  a formula is
a *symbolic* representation of the steps required to perform a calculation.
But because formulae were already well-engrained in other higher-level
languages, their omission from COBOL would have almost certainly been
regarded as a shortcoming.

And that desire to "avoid symbolism" persists to this day.  Although WG4
ultimately decided to request that J4 add the relational operator "<>" as a
synonym for "not equal", there was considerable resistance to the idea as
suggested (right here in this forum) for the 2008 draft precisely because of
the foreignness of symbolic representations to COBOL.  I think the primary
reason it was finally agreed to is that its absence represented a breach of
symmetry given the *previous* introduction of  <= and >= in ANSI X3.23-1985,
which some commentors would have preferred had never been done in the first
place!  All three are violations of that day-one expectation for
"appropriate syntax" in COBOL.

    -Chuck Stevens


0
9/23/2004 10:25:00 PM
I would like to remind people that not only did 60' COBOL have GO TO, it
had ALTER.  They were a pair in many cases.

Warren


Chuck Stevens wrote:
> Response interleaved:
> 
> "Lueko Willms" <l.willms@jpberlin.de> wrote in message
> news:9HPwxJ1uflB@jpberlin-l.willms.jpberlin.de...
> 
>>CS> That doesn't mean the techniques could reasonably be applied before
>>CS> they were invented.  I don't think GO TO in  COBOL is inherently evil
>>CS> any more than the branch instructions on the 1401 were.
>>
>>   What is evil is not the existens of GOTO in COBOL, but that the
>>lack of proper repetition statements did push programmers to program
>>COBOL as if it were assembler. And many of those never learned to
>>think in program structure, but only step-by-step walk throughs.
>>
>>   GOTO is superfluous for a "High Level Language".
> 
> 
> I guess my take on the earlier topic is more like "What in COBOL can now be
> seen as a mistake *at the time it was developed*?".
> 
> At the time COBOL was developed, GO wasn't superfluous enough in Fortran or
> Basic or ALGOL or any of the other higher-level languages around at the time
> to warrant its omission from the language.   The "go-to-less" language with
> which I am most familiar (and the one I'd argue is probably most in
> compliance with Dijkstra's philosophy) had only one loop-control construct:
> DO FOREVER, with a corresponding "IF <condition> UNDO", and it dates from
> the early 1970's.
> 
> 
>>   I do most of my programming work in the language of a database
>>development system, which doesn't have a GOTO. You might also check
>>with your colleagues of the OS/1100 side for @SSG or Skeleton, which
>>can do wonderful things like WFL and which doesn't know a GOTO.
> 
> 
> I have no doubt whatever that it's possible to write programs without GO TO
> whether the language has the construct or not.  I've done so in both cases,
> in fact.  But I think the *absence* of GO TO in the COBOL of 1960 would have
> interfered with its acceptance.
> 
> 
>>   Sure, the hardware will know nothing else but jumps, but a 'High
>>Level Language' should provide some abstraction from that hardware
>>level and provide proper statements for repetition. These came to
>>COBOL only with the 1985 standard.
> 
> 
> I agree, and I also think their proliferation is a Good Thing.  I would
> encourage people to use them as a matter of style; I don't agree that COBOL
> in 1960 should have followed the precepts Dijkstra published in 1968 or that
> it was a mistake for Grace Hopper to have failed to do so.
> 
> 
>>When COBOL could organize repetition of PERFORMed _procedures_ with
>>VARYING a control variable, UNTIL a loop exit condition, n TIMES, I
>>don't see any reason why the same should not have been possible with a
>>local sequence of statements.
> 
> 
> So the bottom line is "in-line PERFORM" should have been available earlier
> than '85.  I don't have a problem with that.  ALGOL had its equivalent a
> quarter-century before that.  But ALGOL had, and still has, GO as well.
> 
> Many, many times I have rewritten procedures in the ALGOL-dialect products I
> work on for the sole purpose of getting rid of GO statements.  That does not
> necessarily mean that the logic associated with the avoidance of GO is more
> efficient at execution time.  It does mean (at least to me) that if there's
> any extra (in this case compile-time) cost to our users associated with
> logic alternative to GO and intra-procedure labels, that cost is worth
> incurring in the interests of improved maintainability.  There are a few
> cases in which it is really impractical to avoid it.  All this doesn't mean
> I think ALGOL should have been designed without a GO statement from the
> beginning; as for COBOL, I believe the absence of such a construct would
> have interfered with the language's acceptance.
> 
>     -Chuck Stevens
> 
> 
0
wsimmons5 (172)
9/24/2004 2:12:25 AM
Again, I would like to point out that the effort to stay away from
smbolic features was deliberate. There were many tools that did tht
kind of think, and the members of CODASYL were bent on disassociate
themeelves from any view of competition. Thus "Business Oriented",
thus Add, Subtract...

It was a move to get something done as fast as possible, the original
schedule for the first spec was 3 months. It took 12. By most measures,
COBOL 60 was enhanced Flow=Matic.  Considered to be a good bet for it's
objectives.

Warren



Chuck Stevens wrote:

> "Lueko Willms" <l.willms@jpberlin.de> wrote in message
> news:9HQ2SRcPflB@jpberlin-l.willms.jpberlin.de...
> 
>>HB> I also don't think that removing ADD, SUBTRACT, MULTIPLY, and DIVIDE
>>HB> would have hurt it.   We learned to use those verbs because they were
>>HB> part of the tool.
>>
>>   Well, but those form an important part of the spirit and basic
>>style of COBOL. I think, nobody has ever had any particular problem
>>with that (except maybe to realize that in the basic form of MULTIPLY
>>and DIVIDE the result is in the second operand).
> 
> 
> I was thinking about that, and also thinking about responding to Howard
> Brazee to similar effect.
> 
> It seems to me that four explicit arithmetic statements -- ADD, SUBTRACT,
> MULTIPLY, DIVIDE -- are the "really native COBOL" constructs, and it's
> COMPUTE and its acceptance of "arithmetic expressions" that represent the
> exception to a basic precept envisioned by the original authors of COBOL.
> 
> ANSI X3.23-1985 reports that one of the criteria to be applied in the
> initial design of COBOL was that it "avoid symbolism as far as possible."
> I think COMPUTE can be considered a violation of that precept:  a formula is
> a *symbolic* representation of the steps required to perform a calculation.
> But because formulae were already well-engrained in other higher-level
> languages, their omission from COBOL would have almost certainly been
> regarded as a shortcoming.
> 
> And that desire to "avoid symbolism" persists to this day.  Although WG4
> ultimately decided to request that J4 add the relational operator "<>" as a
> synonym for "not equal", there was considerable resistance to the idea as
> suggested (right here in this forum) for the 2008 draft precisely because of
> the foreignness of symbolic representations to COBOL.  I think the primary
> reason it was finally agreed to is that its absence represented a breach of
> symmetry given the *previous* introduction of  <= and >= in ANSI X3.23-1985,
> which some commentors would have preferred had never been done in the first
> place!  All three are violations of that day-one expectation for
> "appropriate syntax" in COBOL.
> 
>     -Chuck Stevens
> 
> 
0
wsimmons5 (172)
9/24/2004 2:24:16 AM
On Thu, 23 Sep 2004 15:25:00 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>ANSI X3.23-1985 reports that one of the criteria to be applied in the
>initial design of COBOL was that it "avoid symbolism as far as possible."
>I think COMPUTE can be considered a violation of that precept:  a formula is
>a *symbolic* representation of the steps required to perform a calculation.
>But because formulae were already well-engrained in other higher-level
>languages, their omission from COBOL would have almost certainly been
>regarded as a shortcoming.

When I argued for the superiority of EQUAL TO over =, last year, no
one agreed. Now it seems I was, if not right, at least in concord with
Cobol's design precept.

>And that desire to "avoid symbolism" persists to this day.  Although WG4
>ultimately decided to request that J4 add the relational operator "<>" as a
>synonym for "not equal", there was considerable resistance to the idea as
>suggested (right here in this forum) for the 2008 draft precisely because of
>the foreignness of symbolic representations to COBOL.  I think the primary
>reason it was finally agreed to is that its absence represented a breach of
>symmetry given the *previous* introduction of  <= and >= in ANSI X3.23-1985,
>which some commentors would have preferred had never been done in the first
>place!  All three are violations of that day-one expectation for
>"appropriate syntax" in COBOL.

In the interest of symmetry, remember to disallow 'NOT <>' .. or
permit 'NOT <='.
0
robert6624 (636)
9/24/2004 2:55:17 AM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:2v27l0tlbnkbbjsannafsbg8jiao4fcmap@4ax.com...

> In the interest of symmetry, remember to disallow 'NOT <>' .. or
> permit 'NOT <='.

It's my belief that the proposal J4/03-0224 (q.v. on the J4 website),
approved over a year ago, adequately addresses your timely reminder.

    -Chuck Stevens


0
9/24/2004 3:45:43 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> When I argued for the superiority of EQUAL TO over =, last year, no
> one agreed. 

No one (or at least few) agreed that it was _superior_.  It generates
the identical code and has no functional superiority.  Its textural
quality is dependent entirely on recognition and that is a function of
'what one is used to'.

Personally, having never used the word, and having used symbols as
comparison in several other languages, I find that this is more easily
recognised.  Thus _to_me_ '=' is 'superior', though your prefernce may
be different.

> Now it seems I was, if not right, 

You may be 100% right for _you_ and 100% wrong for _me_.  This is way
your pan_generalizations fail.
0
riplin (4127)
9/25/2004 6:38:20 PM
On 25 Sep 2004 11:38:20 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>> When I argued for the superiority of EQUAL TO over =, last year, no
>> one agreed. 
>
>No one (or at least few) agreed that it was _superior_.  It generates
>the identical code and has no functional superiority.  Its textural
>quality is dependent entirely on recognition and that is a function of
>'what one is used to'.
>
>Personally, having never used the word, and having used symbols as
>comparison in several other languages, I find that this is more easily
>recognised.  Thus _to_me_ '=' is 'superior', though your prefernce may
>be different.
>
>> Now it seems I was, if not right, 
>
>You may be 100% right for _you_ and 100% wrong for _me_.  This is way
>your pan_generalizations fail.

Point taken, but programs perform two communication functions:

1. Between the programmer and the machine.
2. Between the programmer and a human reader -- a maintenance
programmer.

As you say, EQUAL TO and = are synonymous with respect to 1. But your
preference is irrelevant with respect to 2 unless you're the
maintenance programmer. 

It would be nice to have a translating text editor that cast such
things into the reader's preference. It would be easy to write. I
don't know why it hasn't been. The closest I've seen was my Cobol
Beautifier, which I no longer use. It translated = into EQUAL TO
*unless* the brevity of = made the difference between one line and
two. In that case, it translated the opposite way. 

My objective is clarity, not dogmatic attachment to purism. In this
case, the clarity of one line vs. two outweighs the clarity of words
over symbols. What is a Line in free form? It's whatever you can see
without scrolling right.
0
robert6624 (636)
9/25/2004 10:43:01 PM
In article <1prbl0pvmn61vaqgei8jpgp5khtmuspu6c@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:

[snip]

>My objective is clarity, not dogmatic attachment to purism.

Mr Wagner, clarity is in the mind of the beholder... or else all eyeglass 
prescriptions would be identical.

DD

0
docdwarf (6044)
9/26/2004 12:18:06 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> As you say, EQUAL TO and = are synonymous with respect to 1. But your
> preference is irrelevant with respect to 2 unless you're the
> maintenance programmer. 

My preference is entirely relevant at all times for the programs that
I am working on.

> It would be nice to have a translating text editor that cast such
> things into the reader's preference. It would be easy to write. I
> don't know why it hasn't been. The closest I've seen was my Cobol
> Beautifier, which I no longer use. It translated = into EQUAL TO
> *unless* the brevity of = made the difference between one line and
> two. In that case, it translated the opposite way. 
 
> My objective is clarity, not dogmatic attachment to purism. 

It seems that making a claim as to its superiority is entirely a call
to dogma and purism.

> In this
> case, the clarity of one line vs. two outweighs the clarity of words
> over symbols. 

The _clarity_ is exactly whar the reader finds to be clearer. You are
again making the dogmatic claim that words are clearer.  They may be
to someone who is more used to the words but they may not be to
someone who is more used to the symbols.  You are making an entirely
subjective issue into a vast generalisation, that is exactly what
dogma is.

It would be especially poor (for me) to have an inconsistent usage as
your program did.
0
riplin (4127)
9/26/2004 5:08:01 AM
Jeff York wrote:
> "Howard Brazee" <howard@brazee.net> wrote:
> 
> 
>>On  2-Sep-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:
>>
>>
>>>Inventing it back then: most certainly include the in-line performs
>>>(perform ...end-perform) and end-if; but I'd have to leave space
>>>somewhere on the form for sequence numbers because we were using card
>>>decks!
>>
>>But why do we need space for sequence numbers in 73-80 as well as 1-6?   I've
>>sorted cards both ways.
> 
> 
> <Zummmerzet accent>
> 
> When I were just a young laad..  We used to put the program ID in
> 73-80 as well as the sequence in 1-6.  That way, if/when one of the
> ops dropped a tray of cards it was possible to sort them back into
> correctly-sequenced individual programs..  :-)
> 
> </Zummerzet accent>

Exactly.  Cobol was originally designed at a time when the bleeding-edge 
of high tech form of computer input was not a touch screen but a punch 
card.  Thus you needed the option for both numbers.  The use of card 
numbers in 73-89 was a long-time standard for a lot of languages for 
just this reason.  But the numbering for Cobol as sequence numbering is 
separate from this because the compiler can ignore columns 73-80 and you 
could put anything you want there.  You could use the space to do some 
sort of line-printer art if you wanted to do so.
0
paul19 (14)
1/28/2005 12:32:23 PM
Howard Brazee wrote:
> If you were inventing CoBOL back when, what would you do differently?
>

Pardon if this has already been suggested.  I did search, but Google's
new "groups" software leaves a lot to be desired.  Anyway, my response
is:

Regular Expressions!

No, not as related to an editor, as I see already much discussed in
this thread, but in the language itself!

Imagine a typical scenario:  You need to validate user input.  Say,
some sort of a license number (medical, whatever, just an example).
Say it has to have a prefix of "A", "D", or "M" followed by seven
numeric digits.

Via traditional Cobol, in additional to the usual "If NUMERIC" tests,
you would probably set up a buffer with a series of 88-level items or
some such to validate specific bytes for allowed ranges of values.  Or
worse, hard-code "if" statements to look at specific bytes, i.e. 'IF
input-field(1:1) = "A") or ... '

Carrying one step further, you'd move the input to a different input
validation field depending on the type of input entered, which would
require a series of conditional (if / evaluate) tests.  Quite often,
this requires tests in order to determine the type, just so you can
then validate.  Ugh!

With regular expressions you wouldn't even need to move the input to a
new location for validation.  You could just say something like (using
perl-esque syntax):

IF (INPUT-FIELD =~ "[AaDdMm][0-9][0-9][0-9][0-9][0-9][0-9][0-9]")
<do something>
ELSE
<complain>
END-IF.

-or-

EVALUATE INPUT-FIELD
WHEN "[AaDdMm][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"
<do something>
WHEN "[Pp][0-9][0-9][0-9]70"
<do something>
.. . .

I can't count the number of times I wish I'd been able to do something
like this.

0
1/28/2005 9:40:55 PM
<j6vflbl6vy6g8o001@sneakemail.com> wrote in message
news:1106948454.988632.292800@z14g2000cwz.googlegroups.com...
> Howard Brazee wrote:
> > If you were inventing CoBOL back when, what would you do differently?
> >
>
> Pardon if this has already been suggested.  I did search, but Google's
> new "groups" software leaves a lot to be desired.  Anyway, my response
> is:
>
> Regular Expressions!
>
> No, not as related to an editor, as I see already much discussed in
> this thread, but in the language itself!
>
> Imagine a typical scenario:  You need to validate user input.  Say,
> some sort of a license number (medical, whatever, just an example).
> Say it has to have a prefix of "A", "D", or "M" followed by seven
> numeric digits.
>
> Via traditional Cobol, in additional to the usual "If NUMERIC" tests,
> you would probably set up a buffer with a series of 88-level items or
> some such to validate specific bytes for allowed ranges of values.  Or
> worse, hard-code "if" statements to look at specific bytes, i.e. 'IF
> input-field(1:1) = "A") or ... '
>
> Carrying one step further, you'd move the input to a different input
> validation field depending on the type of input entered, which would
> require a series of conditional (if / evaluate) tests.  Quite often,
> this requires tests in order to determine the type, just so you can
> then validate.  Ugh!
>
> With regular expressions you wouldn't even need to move the input to a
> new location for validation.  You could just say something like (using
> perl-esque syntax):
>
> IF (INPUT-FIELD =~ "[AaDdMm][0-9][0-9][0-9][0-9][0-9][0-9][0-9]")
> <do something>
> ELSE
> <complain>
> END-IF.
>
> -or-
>
> EVALUATE INPUT-FIELD
> WHEN "[AaDdMm][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"
> <do something>
> WHEN "[Pp][0-9][0-9][0-9]70"
> <do something>
> . . .
>
> I can't count the number of times I wish I'd been able to do something
> like this.

Do you mean
01  INPUT-FIELD.
    03  INPUT-PREFIX PIC X.
    88 VALID-PREFIX VALUES "A", "a", "D", "d", "M", "m".
    03  INPUT-NUM PIC 9(7) DISPLAY.

IF VALID-PREFIX AND INPUT-NUM NUMERIC THEN ...

If that's the sort of thing you meant, then this capability should be
available in any ANSI-85 COBOL implementation that claims to support  Level
2 of the Nucleus of the language.  Note that Level 88 items (Format 3 Data
Description Entry) are themselves Level 2 Nucleus features.    See ANSI
X3.23-1985 or ISO/IEC 1989:2002.

    -Chuck Stevens


0
1/28/2005 9:59:16 PM
> WHEN "[AaDdMm][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"

> I can't count the number of times I wish I'd been able to do
something
> like this.

You have been able to do something like that:

CLASS LICENCE-PREFIX IS "A" "a" "D" "d" "M" "m"

01  Input-Field.
03  IN-prefix      PIC X.
03  IN-base       PIC X(7).
IF ( IN-prefix LICENCE-PREFIX AND IN-base NUMERIC )

0
riplin (4127)
1/28/2005 10:20:33 PM
Sure, and I said that in my original post, i.e. "... with a series of
88-level items...".  But, consider how much work that takes!

For example, I work a lot with phone numbers, especially in doing
conversions, where the data quality coming in is usually suspect.  So I
have to identify "valid" phone numbers from invalid.  Here's some
formats I consider valid:

      *  Formats Considered Valid:
      *  -------------------------
      *  (999) 999-9999
      *  (999)999-9999
      *  999-999-9999
      *  999.999.9999
      *  999 999-9999
      *  999/999-9999
      *  9999999999

And, here's some cobol-esque ways of validating, e.g. this code
snippet:

	01  501-PHONE-VALIDATION                PIC X(15).
	01  501-PHONE-FORMAT-1 REDEFINES
	    501-PHONE-VALIDATION.
		05  501-PF1-PAREN-1		PIC X(01).
		88  501-PF1-VALID-1     		VALUE "(".
		05  501-PF1-NPA      		PIC X(03).
		05  501-PF1-PAREN-2-SPACE   	PIC X(02).
		88  501-PF1-VALID-2     		VALUE ") ".
		05  501-PF1-NXX   		PIC X(03).
		05  501-PF1-DASH-1		PIC X(01).
		88  501-PF1-VALID-3     		VALUE "-".
		05  501-PF1-NUM   		PIC X(04).


	MOVE <WHATEVER> TO 501-PHONE-VALIDATION.

	IF 501-PF1-VALID-1 AND
	   501-PF1-NPA IS NUMERIC AND
	   501-PF1-VALID-2 AND
	   501-PF1-NXX IS NUMERIC AND
	   501-PF1-VALID-3 AND
	   501-PF1-NUM IS NUMERIC
	      <YOU'VE IDENTIFIED AS FORMAT "(999) 999-9999">
	ELSE IF . . .
	 <CONTINUE THIS UMPTEEN TIMES>


Or, here's a slightly more elegant way of doing same.  Logic builds a
"mask" and them uses 88-levels to validate against that.  (Note: This
is working Microfocus Cobol code.) Two copylibs (one for procedure
code, one for data division code), called via:


           MOVE EM-ID2-K1-ACCESS-PHONE TO 501-PHONE-NUMBER-IN.
           PERFORM 501-PARSE-PHONE-NUMBER OF 500-COMMON-CODE-SECTION.

           IF 501-PHONE-NUMBER-INVALID
                 <do something>
           ELSE . . .

Here are the copylibs:


******************************************************************
      * "PHONE.DDS" - GENERIC phone number validation/analysis
routine.*
      *
*
      * Version 01.
*

******************************************************************
      *
*
      * Purpose:  Generic phone number validation/analysis routine.
*
      *
*
      * Note:  Routine is intended to perform GENERIC phone number
*
      *        analysis.  Conversion specific logic should be kept
*
      *        in the calling program.
*
      *
*
      *
*
      *  Formats Considered Valid:
*
      *  -------------------------
*
.. . .


******************************************************************

       01  501-PHONE-NUMBER-IN                 PIC X(15).
       01  501-PHONE-NUMBER-BYTES REDEFINES
           501-PHONE-NUMBER-IN.
           05  501-PHONE-NUMBER-BYTE
               OCCURS 15 TIMES                 PIC X(01).
               88  501-NUMERIC-PHONE-DIGIT                 VALUE
               "0" THRU "9".
               88  501-OTHER-VALID-PHONE-CHAR              VALUE
               "(", ")", "-", ".", "/", " ".

       01  501-IDX                             PIC 9(02) COMP.
       01  501-JDX                             PIC 9(02) COMP.
       01  501-KDX                             PIC 9(02) COMP.

       01  501-PHONE-FORMAT                    PIC X(15).
           88  501-PHONE-FORMAT-VALID          VALUE
               "(999) 999-9999"
               "(999)999-9999"
               "999-999-9999"
               "999.999.9999"
               "999 999-9999"
               "999/999-9999"
               "9999999999".

       01  501-PHONE-NUMBER-OUT                PIC X(10).

       01  501-PHONE-NUMBER-STATUS             PIC X(01).
           88  501-PHONE-NUMBER-VALID                      VALUE "V".
           88  501-PHONE-NUMBER-INVALID                    VALUE "I".

      *-------------------- END OF CAPCODE.DDS
-------------------------

and:


       501-PARSE-PHONE-NUMBER.

           MOVE ZEROS TO
               501-JDX
               501-KDX.

           MOVE SPACES TO
               501-PHONE-FORMAT
               501-PHONE-NUMBER-OUT.

           SET 501-PHONE-NUMBER-VALID TO TRUE.

      * - Parse phone number:

           PERFORM VARYING 501-IDX FROM 1 BY 1
             UNTIL 501-IDX > LENGTH OF 501-PHONE-NUMBER-IN

               EVALUATE TRUE
                   WHEN 501-NUMERIC-PHONE-DIGIT (501-IDX)
                       ADD 1 TO 501-JDX, 501-KDX
      * -             (Move "9" to Format buffer)
                       MOVE "9" TO 501-PHONE-FORMAT (501-JDX:1)
      * -             (Move actual number to Output buffer)
                       MOVE 501-PHONE-NUMBER-BYTE (501-IDX)
                         TO 501-PHONE-NUMBER-OUT (501-KDX:1)
                   WHEN 501-OTHER-VALID-PHONE-CHAR (501-IDX)
                       ADD 1 TO 501-JDX
      * -             (Move other char to Format buffer only)
                       MOVE 501-PHONE-NUMBER-BYTE (501-IDX)
                         TO 501-PHONE-FORMAT (501-JDX:1)
                   WHEN OTHER
                       SET 501-PHONE-NUMBER-INVALID TO TRUE
                       EXIT PERFORM
               END-EVALUATE

           END-PERFORM.


           IF 501-PHONE-NUMBER-VALID
               IF 501-PHONE-FORMAT-VALID
                   NEXT SENTENCE
               ELSE
                   SET 501-PHONE-NUMBER-INVALID TO TRUE
               END-IF
           END-IF.


           IF 501-PHONE-NUMBER-VALID
               IF 501-PHONE-NUMBER-OUT = ALL ZEROS OR
                  501-PHONE-NUMBER-OUT = ALL  "9"  OR
                  501-KDX < 10
                   SET 501-PHONE-NUMBER-INVALID TO TRUE
               END-IF
           END-IF.

      *-------------------- END OF CAPCODE.PDS
-------------------------


- OR - if Cobol supported regular expressions, you could do all of the
above in a single statement like this:

     IF PHONE-NUMBER-IN =~ "^(\([0-9]|[0-9])[0-9]([0-9]\)|[0-9])([
\-\.\/][0-9]|[0-9])[0-9][0-9]([\-\.][0-9]|[0-9])[0-9][0-9][0-9]"
          <phone number is valid>
          MOVE PHONE-NUMBER-IN TO . . .
     ELSE
          <phone number is NOT valid>
     END-IF.


Gosh, could it get any easier than that???

Now, THAT'S what I mean by having Cobol support regular expressions!

Now, that's a little more obtuse, but still wouldn't require any more
effort to understand than having to wade through the series of 88-level
item combinations in the Working Storage section to figure out!  If one
added a couple lines of documentation (like my list of valid patterns)
above, it would be quite self evident to the next person reviewing the
code.

And, here's a little piece of perl code that proves this works:

#!/usr/bin/perl
use strict;
#
# regexex.pl - Example of regular expression use
#
# Syntax:  regexex.pl  (or, perl regexex.pl)
#

	while ( 1 )
	{
		print "Enter a phone number (any format):";
		my $phone = <STDIN>;
		chomp $phone;

		if ( $phone eq "quit" ) {
			exit;
		}

		if ( $phone =~ /^(\([0-9]|[0-9])[0-9]([0-9]\)|[0-9])([
\-\.\/][0-9]|[0-9])[0-9][0-9]([\-\.][0-9]|[0-9])[0-9][0-9][0-9]/ )
		{
			print "That is a valid phone number\n";
		}
		else
		{
			print "That is NOT a valid phone number\n";
		}

	} # while

Note:  Above regex example may not be perfect; I threw it together
quickly, nor may it be the pentultimate "best use" of regex.
Nevertheless, you get the idea.

Kevin Arthur

0
2/4/2005 11:32:16 PM
Have you asked your "vendor of choice" when/if they plan on implementing the 
VALIDATE statement from the '02 ANSI/ISO COBOL Standard?

-- 
Bill Klein
 wmklein <at> ix.netcom.com
<j6vflbl6vy6g8o001@sneakemail.com> wrote in message 
news:1107559936.568632.319940@g14g2000cwa.googlegroups.com...
> Sure, and I said that in my original post, i.e. "... with a series of
> 88-level items...".  But, consider how much work that takes!
>
> For example, I work a lot with phone numbers, especially in doing
> conversions, where the data quality coming in is usually suspect.  So I
> have to identify "valid" phone numbers from invalid.  Here's some
> formats I consider valid:
>
>      *  Formats Considered Valid:
>      *  -------------------------
>      *  (999) 999-9999
>      *  (999)999-9999
>      *  999-999-9999
>      *  999.999.9999
>      *  999 999-9999
>      *  999/999-9999
>      *  9999999999
>
> And, here's some cobol-esque ways of validating, e.g. this code
> snippet:
>
> 01  501-PHONE-VALIDATION                PIC X(15).
> 01  501-PHONE-FORMAT-1 REDEFINES
>     501-PHONE-VALIDATION.
> 05  501-PF1-PAREN-1 PIC X(01).
> 88  501-PF1-VALID-1     VALUE "(".
> 05  501-PF1-NPA      PIC X(03).
> 05  501-PF1-PAREN-2-SPACE   PIC X(02).
> 88  501-PF1-VALID-2     VALUE ") ".
> 05  501-PF1-NXX   PIC X(03).
> 05  501-PF1-DASH-1 PIC X(01).
> 88  501-PF1-VALID-3     VALUE "-".
> 05  501-PF1-NUM   PIC X(04).
>
>
> MOVE <WHATEVER> TO 501-PHONE-VALIDATION.
>
> IF 501-PF1-VALID-1 AND
>    501-PF1-NPA IS NUMERIC AND
>    501-PF1-VALID-2 AND
>    501-PF1-NXX IS NUMERIC AND
>    501-PF1-VALID-3 AND
>    501-PF1-NUM IS NUMERIC
>       <YOU'VE IDENTIFIED AS FORMAT "(999) 999-9999">
> ELSE IF . . .
> <CONTINUE THIS UMPTEEN TIMES>
>
>
> Or, here's a slightly more elegant way of doing same.  Logic builds a
> "mask" and them uses 88-levels to validate against that.  (Note: This
> is working Microfocus Cobol code.) Two copylibs (one for procedure
> code, one for data division code), called via:
>
>
>           MOVE EM-ID2-K1-ACCESS-PHONE TO 501-PHONE-NUMBER-IN.
>           PERFORM 501-PARSE-PHONE-NUMBER OF 500-COMMON-CODE-SECTION.
>
>           IF 501-PHONE-NUMBER-INVALID
>                 <do something>
>           ELSE . . .
>
> Here are the copylibs:
>
>
> ******************************************************************
>      * "PHONE.DDS" - GENERIC phone number validation/analysis
> routine.*
>      *
> *
>      * Version 01.
> *
>
> ******************************************************************
>      *
> *
>      * Purpose:  Generic phone number validation/analysis routine.
> *
>      *
> *
>      * Note:  Routine is intended to perform GENERIC phone number
> *
>      *        analysis.  Conversion specific logic should be kept
> *
>      *        in the calling program.
> *
>      *
> *
>      *
> *
>      *  Formats Considered Valid:
> *
>      *  -------------------------
> *
> . . .
>
>
> ******************************************************************
>
>       01  501-PHONE-NUMBER-IN                 PIC X(15).
>       01  501-PHONE-NUMBER-BYTES REDEFINES
>           501-PHONE-NUMBER-IN.
>           05  501-PHONE-NUMBER-BYTE
>               OCCURS 15 TIMES                 PIC X(01).
>               88  501-NUMERIC-PHONE-DIGIT                 VALUE
>               "0" THRU "9".
>               88  501-OTHER-VALID-PHONE-CHAR              VALUE
>               "(", ")", "-", ".", "/", " ".
>
>       01  501-IDX                             PIC 9(02) COMP.
>       01  501-JDX                             PIC 9(02) COMP.
>       01  501-KDX                             PIC 9(02) COMP.
>
>       01  501-PHONE-FORMAT                    PIC X(15).
>           88  501-PHONE-FORMAT-VALID          VALUE
>               "(999) 999-9999"
>               "(999)999-9999"
>               "999-999-9999"
>               "999.999.9999"
>               "999 999-9999"
>               "999/999-9999"
>               "9999999999".
>
>       01  501-PHONE-NUMBER-OUT                PIC X(10).
>
>       01  501-PHONE-NUMBER-STATUS             PIC X(01).
>           88  501-PHONE-NUMBER-VALID                      VALUE "V".
>           88  501-PHONE-NUMBER-INVALID                    VALUE "I".
>
>      *-------------------- END OF CAPCODE.DDS
> -------------------------
>
> and:
>
>
>       501-PARSE-PHONE-NUMBER.
>
>           MOVE ZEROS TO
>               501-JDX
>               501-KDX.
>
>           MOVE SPACES TO
>               501-PHONE-FORMAT
>               501-PHONE-NUMBER-OUT.
>
>           SET 501-PHONE-NUMBER-VALID TO TRUE.
>
>      * - Parse phone number:
>
>           PERFORM VARYING 501-IDX FROM 1 BY 1
>             UNTIL 501-IDX > LENGTH OF 501-PHONE-NUMBER-IN
>
>               EVALUATE TRUE
>                   WHEN 501-NUMERIC-PHONE-DIGIT (501-IDX)
>                       ADD 1 TO 501-JDX, 501-KDX
>      * -             (Move "9" to Format buffer)
>                       MOVE "9" TO 501-PHONE-FORMAT (501-JDX:1)
>      * -             (Move actual number to Output buffer)
>                       MOVE 501-PHONE-NUMBER-BYTE (501-IDX)
>                         TO 501-PHONE-NUMBER-OUT (501-KDX:1)
>                   WHEN 501-OTHER-VALID-PHONE-CHAR (501-IDX)
>                       ADD 1 TO 501-JDX
>      * -             (Move other char to Format buffer only)
>                       MOVE 501-PHONE-NUMBER-BYTE (501-IDX)
>                         TO 501-PHONE-FORMAT (501-JDX:1)
>                   WHEN OTHER
>                       SET 501-PHONE-NUMBER-INVALID TO TRUE
>                       EXIT PERFORM
>               END-EVALUATE
>
>           END-PERFORM.
>
>
>           IF 501-PHONE-NUMBER-VALID
>               IF 501-PHONE-FORMAT-VALID
>                   NEXT SENTENCE
>               ELSE
>                   SET 501-PHONE-NUMBER-INVALID TO TRUE
>               END-IF
>           END-IF.
>
>
>           IF 501-PHONE-NUMBER-VALID
>               IF 501-PHONE-NUMBER-OUT = ALL ZEROS OR
>                  501-PHONE-NUMBER-OUT = ALL  "9"  OR
>                  501-KDX < 10
>                   SET 501-PHONE-NUMBER-INVALID TO TRUE
>               END-IF
>           END-IF.
>
>      *-------------------- END OF CAPCODE.PDS
> -------------------------
>
>
> - OR - if Cobol supported regular expressions, you could do all of the
> above in a single statement like this:
>
>     IF PHONE-NUMBER-IN =~ "^(\([0-9]|[0-9])[0-9]([0-9]\)|[0-9])([
> \-\.\/][0-9]|[0-9])[0-9][0-9]([\-\.][0-9]|[0-9])[0-9][0-9][0-9]"
>          <phone number is valid>
>          MOVE PHONE-NUMBER-IN TO . . .
>     ELSE
>          <phone number is NOT valid>
>     END-IF.
>
>
> Gosh, could it get any easier than that???
>
> Now, THAT'S what I mean by having Cobol support regular expressions!
>
> Now, that's a little more obtuse, but still wouldn't require any more
> effort to understand than having to wade through the series of 88-level
> item combinations in the Working Storage section to figure out!  If one
> added a couple lines of documentation (like my list of valid patterns)
> above, it would be quite self evident to the next person reviewing the
> code.
>
> And, here's a little piece of perl code that proves this works:
>
> #!/usr/bin/perl
> use strict;
> #
> # regexex.pl - Example of regular expression use
> #
> # Syntax:  regexex.pl  (or, perl regexex.pl)
> #
>
> while ( 1 )
> {
> print "Enter a phone number (any format):";
> my $phone = <STDIN>;
> chomp $phone;
>
> if ( $phone eq "quit" ) {
> exit;
> }
>
> if ( $phone =~ /^(\([0-9]|[0-9])[0-9]([0-9]\)|[0-9])([
> \-\.\/][0-9]|[0-9])[0-9][0-9]([\-\.][0-9]|[0-9])[0-9][0-9][0-9]/ )
> {
> print "That is a valid phone number\n";
> }
> else
> {
> print "That is NOT a valid phone number\n";
> }
>
> } # while
>
> Note:  Above regex example may not be perfect; I threw it together
> quickly, nor may it be the pentultimate "best use" of regex.
> Nevertheless, you get the idea.
>
> Kevin Arthur
> 


0
wmklein (2605)
2/5/2005 12:12:12 AM
j6vflbl6vy6g8o001@sneakemail.com wrote:
> 
> Sure, and I said that in my original post, i.e. "... with a series of
> 88-level items...".  But, consider how much work that takes!
> 
> For example, I work a lot with phone numbers, especially in doing
> conversions, where the data quality coming in is usually suspect.  So I
> have to identify "valid" phone numbers from invalid.  Here's some
> formats I consider valid:
> 
>       *  Formats Considered Valid:
>       *  -------------------------
>       *  (999) 999-9999
>       *  (999)999-9999
>       *  999-999-9999
>       *  999.999.9999
>       *  999 999-9999
>       *  999/999-9999
>       *  9999999999
> 

For this particular case, it would be just as easy to extract the
numeric characters, from right to left, placing them in a receiving
field from right to left; then examine the 3, 3, & 4 digit portions
(using REDEFINE).  The first can be blank or numeric, the other two must
be numeric.

I'm not claiming anything for this method except to say: there are
almost always several different ways to attack a problem.  

PL
0
lacey (134)
2/5/2005 2:27:28 AM
>       *  Formats Considered Valid:
>       *  -------------------------
>       *  (999) 999-9999
           ....

My phone number is +64 (9) 999-9999.  Many US sites complain about the
format and do not cater for the many different formats that do exist.

> Now, THAT'S what I mean by having Cobol support regular expressions!

You could always just call the PCRE library, or the GNU-regex, or Rx,
or ..

0
riplin (4127)
2/5/2005 2:59:20 AM
Re:

"For this particular case, it would be just as easy to extract the
numeric characters, from right to left, placing them in a receiving
field from right to left; then examine the 3, 3, & 4 digit portions
(using REDEFINE).  The first can be blank or numeric, the other two
must be numeric. "

Sure, but I don't want to accept something like "12-$j3456b_789#0"  as
valid.  I'm insisting that the original value at least look *something*
like a 'real' (U.S. for my purposes, sorry!) phone number.  Hence the
looking for the specific patterns.  ;-)

0
2/5/2005 5:13:27 AM
..    On  04.02.05
  wrote  j6vflbl6vy6g8o001@sneakemail.com
     on  /COMP/LANG/COBOL
     in  1107580407.270111.292460@l41g2000cwc.googlegroups.com
  about  Re: If you were inventing CoBOL...


j> Sure, but I don't want to accept something like "12-$j3456b_789#0"  as
j> valid.  I'm insisting that the original value at least look
j> *something* like a 'real' (U.S. for my purposes, sorry!) phone number.
j>  Hence the looking for the specific patterns.  ;-)

   Well, besides your parochial USA insularity, just scan your input,  
move all the digits, ignore the dash, brackets, slashs, dots, and  
spaces, and complain about all other characters. Use reference  
modification. Check the number of digits, and allow 7, 10 and 11  
digits.

   BTW, what is a 501 phone number? I know 501 only as a Levi's jeans  
model number.  :-)


Yours,
L�ko Willms                                     http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Als er am Kirchhofe vorbei ging, sagte er: Die da k�nnen nun sicher sein, da� sie nicht mehr geh�ngt werden, das k�nnen wir nicht. -G.C.Lichtenberg
0
l.willms1 (637)
2/5/2005 7:47:00 AM
<j6vflbl6vy6g8o001@sneakemail.com> wrote in message
news:1107559936.568632.319940@g14g2000cwa.googlegroups.com...
> For example, I work a lot with phone numbers, especially in doing
> conversions, where the data quality coming in is usually suspect.  So I
> have to identify "valid" phone numbers from invalid.  Here's some
> formats I consider valid:
>
>       *  Formats Considered Valid:
>       *  -------------------------
>       *  (999) 999-9999
>       *  (999)999-9999
>       *  999-999-9999
>       *  999.999.9999
>       *  999 999-9999
>       *  999/999-9999
>       *  9999999999

Well,  look at the bright side: at least you don't have to validate those
catchy, easy-to-remember-but-a-PITA-to-dial "words" like "1-800-BUY-THIS" or
the use of "word" exchanges as in "Hudson Three Two Seven Hundred." (Just
this week I got a new customer, who gave me his phone number as "264-BELL" )
(Never mind that I'm in a different area code!).

Even worse, I used to work for a firm where we not only used words, but
violated the 'length' rule whilst doing so: 1-800-2-DISPLAY.

MCM



0
2/5/2005 12:33:46 PM
On  4-Feb-2005, j6vflbl6vy6g8o001@sneakemail.com wrote:

> For example, I work a lot with phone numbers, especially in doing
> conversions, where the data quality coming in is usually suspect.  So I
> have to identify "valid" phone numbers from invalid.  Here's some
> formats I consider valid:
>
>       *  Formats Considered Valid:
>       *  -------------------------
>       *  (999) 999-9999
>       *  (999)999-9999
>       *  999-999-9999
>       *  999.999.9999
>       *  999 999-9999
>       *  999/999-9999
>       *  9999999999
>
> And, here's some cobol-esque ways of validating, e.g. this code
> snippet:

I hate web sites that don't understand phone numbers nor credit card numbers
unless entered the way they want.   It shouldn't be that hard to program for the
customer.
0
howard (6283)
2/7/2005 3:57:04 PM
"Howard Brazee" <howard@brazee.net> wrote in message 
news:cu8381$54o$1@peabody.colorado.edu...
>
> On  4-Feb-2005, j6vflbl6vy6g8o001@sneakemail.com wrote:
>
>> For example, I work a lot with phone numbers, especially in doing
>> conversions, where the data quality coming in is usually suspect.  So I
>> have to identify "valid" phone numbers from invalid.  Here's some
>> formats I consider valid:
>>
>>       *  Formats Considered Valid:
>>       *  -------------------------
>>       *  (999) 999-9999
>>       *  (999)999-9999
>>       *  999-999-9999
>>       *  999.999.9999
>>       *  999 999-9999
>>       *  999/999-9999
>>       *  9999999999
>>
>> And, here's some cobol-esque ways of validating, e.g. this code
>> snippet:
>
> I hate web sites that don't understand phone numbers nor credit card 
> numbers
> unless entered the way they want.   It shouldn't be that hard to program 
> for the
> customer.

Even if the way they want is not the way they should be?  I have an 
idea...why don't we let the telephone companies tell us what the number 
format should be.
I'm sure they have enough edits in their systems to want to standardize.

I could say my phone number is (202)-225-5010 + 5 which translates to 
(202)-225-5015....but then it wouldn't be my number, it would actually be 
Dubya's favourite Congresswoman....give it a ring and let her know how it 
feels to be a minority....

You have to draw the line somewhere...schools now have kids called "Antoine" 
but spelled "Anthony". (THIS IS A REAL EXAMPLE) and even in the world of 
famous athletes the "Antawn" or "Antowain" or "Dwyane" are sort of non 
phonetic variations of a name....

I'm going to have a boy called Sue (spelled 'Johnny', obviously)

JCE 


0
defaultuser (532)
2/7/2005 8:28:43 PM
On  7-Feb-2005, "jce" <defaultuser@hotmail.com> wrote:

> Even if the way they want is not the way they should be?  I have an
> idea...why don't we let the telephone companies tell us what the number
> format should be.
> I'm sure they have enough edits in their systems to want to standardize.

They can use common sense.   It is common enough to put parenthesis and dashes
in phone numbers, and dashes and spaces in credit card numbers.   Program for
these common variations.