f



OFF Topic

Rock the boat!

As a long time reader of the comp.lang.cobol newsgroup the
discussions are often very redundant. I find it easy to get
ideas from their view of the subject.

What can I do that will bring out the inventiveness of these
COBOL brains? See subject above. "They" below  is aimed
at everyone who posts on a regular basis and some on
an irregular basis.


They do a great job of helping those who seek help. They
share different methods that they use which is a general
benefit to the readers,

But, there is always a but! Often they get into the mode
of "I'm smart, you're dumb."

In my view, they really are looking for something
constructive to do, and IF they were to turn their
energies to mutual development proposals for
the COBOL language specifications, it would result in
a major step forward in the direction of the goals of
COBOL.

I really feel that _had _the members of this group been
assigned the job of the short range committee,
and given COBOL '85' as a starting point, a much better
result might have easily been achieved by 2050.
If they would only debate, and demonstrate, what a difference
they could make.  (Or the only thing wrong is they won't let me
run it!)

Maybe by 2020!


Outside of washing dishes I have Nothing to do but look,
and read c.l.cobol and the world news. This takes me into
all kinds of countries.

Here is one I had not heard of, and I'm wondering if the C.L.COBOL
newsgroup has, or has discussed such tools. As it's billed as
a Business Processing Language, it seemed it might be of interest
to the "gang".

Wish I had known how to make this a url.

http://activebpel.org/info/intro.html


Warren

P.S. I also read Freshmeat daily. I have a few interesting
items from todays listing that I plan to post here next.


I hope you can tell I was being sarcastic! <VBG>

0
wsimmons5 (172)
10/7/2004 7:45:51 PM
comp.lang.cobol 4278 articles. 1 followers. Post Follow

294 Replies
2781 Views

Similar Articles

[PageSpeed] 20

Warren Simmons wrote:

Middle posting !

> Rock the boat!
>
> As a long time reader of the comp.lang.cobol newsgroup the
> discussions are often very redundant. I find it easy to get
> ideas from their view of the subject.
>
> What can I do that will bring out the inventiveness of these
> COBOL brains? See subject above. "They" below  is aimed
> at everyone who posts on a regular basis and some on
> an irregular basis.
>
>
> They do a great job of helping those who seek help. They
> share different methods that they use which is a general
> benefit to the readers,
>
> But, there is always a but! Often they get into the mode
> of "I'm smart, you're dumb."
>
> In my view, they really are looking for something
> constructive to do, and IF they were to turn their
> energies to mutual development proposals for
> the COBOL language specifications, it would result in
> a major step forward in the direction of the goals of
> COBOL.
>
> I really feel that _had _the members of this group been
> assigned the job of the short range committee,
> and given COBOL '85' as a starting point, a much better
> result might have easily been achieved by 2050.
> If they would only debate, and demonstrate, what a difference
> they could make.  (Or the only thing wrong is they won't let me
> run it!)
>
> Maybe by 2020!
>
>
> Outside of washing dishes I have Nothing to do but look,
> and read c.l.cobol and the world news. This takes me into
> all kinds of countries.
>
As a 'younger man'  :-) - may I offer the sage advice - stick with 
washing the dishes - you'll definitely get results, (even if it is 
breakages) !

2020 or 2050. Jeez ! Do YOU *really* care - buggered if I do !

Jimmy

> Here is one I had not heard of, and I'm wondering if the C.L.COBOL
> newsgroup has, or has discussed such tools. As it's billed as
> a Business Processing Language, it seemed it might be of interest
> to the "gang".
>
> Wish I had known how to make this a url.
>
> http://activebpel.org/info/intro.html
>
>
> Warren
>
> P.S. I also read Freshmeat daily. I have a few interesting
> items from todays listing that I plan to post here next.
>
>
> I hope you can tell I was being sarcastic! <VBG>
>
0
jjgavan (507)
10/7/2004 9:44:49 PM
On Thu, 07 Oct 2004 19:45:51 GMT, Warren Simmons
<wsimmons5@optonline.net> wrote:

>They do a great job of helping those who seek help. They
>share different methods that they use which is a general
>benefit to the readers,
>
>But, there is always a but! Often they get into the mode
>of "I'm smart, you're dumb."

If you know how to change human nature, your leadership skills are
valuable. I doubt it's possible. 

0
robert6624 (636)
10/8/2004 5:05:22 AM
In article <oq7cm01bco8kdhp32c51n1sn75ochcs82s@4ax.com>,
Robert Wagner  <robert@wagner.net.yourmammaharvests> wrote:
>On Thu, 07 Oct 2004 19:45:51 GMT, Warren Simmons
><wsimmons5@optonline.net> wrote:
>
>>They do a great job of helping those who seek help. They
>>share different methods that they use which is a general
>>benefit to the readers,
>>
>>But, there is always a but! Often they get into the mode
>>of "I'm smart, you're dumb."
>
>If you know how to change human nature, your leadership skills are
>valuable. I doubt it's possible. 
>


0
docdwarf (6044)
10/8/2004 9:19:08 AM
"Warren Simmons" <wsimmons5@optonline.net> wrote in message
news:41659C51.30908@optonline.net...
> Rock the boat!
>
> As a long time reader of the comp.lang.cobol newsgroup the
> discussions are often very redundant. I find it easy to get
> ideas from their view of the subject.
>

Yes, reading it gives me ideas too, Warren... That's why I've almost
stopped... It brings out the dark side in me...<G>

> What can I do that will bring out the inventiveness of these
> COBOL brains?

Lobotomy is a tried and tested process...


> See subject above. "They" below  is aimed
> at everyone who posts on a regular basis and some on
> an irregular basis.
>
>
> They do a great job of helping those who seek help. They
> share different methods that they use which is a general
> benefit to the readers,
>
> But, there is always a but! Often they get into the mode
> of "I'm smart, you're dumb."
>

What?! CLCers?! never....

I could see much of what goes on here being a repetition of the Church in
the Middle Ages.

They spent over 200 years arguing about the number of angels that could
stand on a pinhead.

(Mind you, I don't believe that would happen here... no-one could stay on
topic long enough.  Long before the first hundred years was up, the
discussion would have moved to the necessity for angels to have pins, then a
bitter argument over types of pins, whether they were being sourced by cheap
labour offshore, and whether they complied with the Heavenly Standard for
Pins laid down by St. Anne (the patron Saint of Seamstresses). There would
then be a 50 year argument between two or three contributors regarding the
details of the process of manufacturing pins, with one arguing that the
composition was all important, another that the temperature was, and the
third pointing out that both the other two were being pedantic when it was
really just a matter of style...)

Midway through the second century someone else would chime in that the whole
point was being missed, and the discussion was really about foot size, as
that was the determining factor in standing on pinheads. After a few decades
of discussion on angelic footwear and whether sandals would occupy more
space than sneakers or gumboots, someone would observe that it was a bit
unnecessary for angels to occupy pinheads anyway, and how could such a
stupid topic be occupying the brilliant minds of the group?

In the meantime, various contributors (having done their own painstaking
calculations) would have offered various numbers, and been rejected as not
understanding the nature of the problem or having a proper grasp of the
ramifications.

As the third century of discussion began, algorithms for calculating angelic
footprints would start to emerge and the whole newsgroup would split into
various camps supporting one of several approaches. A "religious War" would
then ensue with a lot of unangelic abuse and bad behaviour. Robert Wagner
would be blamed for everything and each of his posts would be carefully
shredded. Undeterred, Robert would continue in his assertion that he had
been counting angels on pinheads before any of the other contributors were
aware that there were such things as pins, and had once developed a software
engine that could instantly calculate the number of angels from the increase
in weight.At this point Richard would observe that angels have no weight,
and therefore Robert's machine was totally inaccurate and pointless and his
claim to superiority could be dismissed as trivial.

This exchange would continue for another 60 years or so, until Robert would
suddenly change his position by remembering that it wasn't the weight, it
was the mass...  (and on that very appropriate thought for a religious
discussion, I shall leave this little whimsy...)


> In my view, they really are looking for something
> constructive to do, and IF they were to turn their
> energies to mutual development proposals for
> the COBOL language specifications, it would result in
> a major step forward in the direction of the goals of
> COBOL.
>

Always assuming there WERE identified goals for COBOL... It would probably
take a century or two to get agreement on those, before anything really
started.

> I really feel that _had _the members of this group been
> assigned the job of the short range committee,
> and given COBOL '85' as a starting point, a much better
> result might have easily been achieved by 2050.

ROFL! Good one, Warren... <G>

> If they would only debate, and demonstrate, what a difference
> they could make.

On the evidence that is exhibited here, it would appear extremely doubtful
whether any difference would be made. It was "COBOL people" on J4...

 (Or the only thing wrong is they won't let me
> run it!)
>
> Maybe by 2020!
>
>
> Outside of washing dishes I have Nothing to do but look,
> and read c.l.cobol and the world news. This takes me into
> all kinds of countries.
>
> Here is one I had not heard of, and I'm wondering if the C.L.COBOL
> newsgroup has, or has discussed such tools. As it's billed as
> a Business Processing Language, it seemed it might be of interest
> to the "gang".
>

I had a look at it, Warren. It is another in a chain of such tools. At least
it is "open" and available. It is a good combination of XML and Java and
could save quite a bit of the manual effort in using these tools.

But it doesn't have a MicroSoft label on it... <G>

> Wish I had known how to make this a url.
>
> http://activebpel.org/info/intro.html
>

Well, the above sure looked like a URL to me...<G>

Regards,

Pete.




0
10/8/2004 2:49:07 PM
Pete Dashwood wrote:
> 
> I could see much of what goes on here being a repetition of the Church in
> the Middle Ages.
> 
> They spent over 200 years arguing about the number of angels that could
> stand on a pinhead.
> 
> (Mind you, I don't believe that would happen here... no-one could stay on
> topic long enough.  Long before the first hundred years was up, the
> discussion would have moved to the necessity for angels to have pins, then a
> bitter argument over types of pins, whether they were being sourced by cheap
> labour offshore, and whether they complied with the Heavenly Standard for
> Pins laid down by St. Anne (the patron Saint of Seamstresses). There would
> then be a 50 year argument between two or three contributors regarding the
> details of the process of manufacturing pins, with one arguing that the
> composition was all important, another that the temperature was, and the
> third pointing out that both the other two were being pedantic when it was
> really just a matter of style...)
> 
> Midway through the second century someone else would chime in that the whole
> point was being missed, and the discussion was really about foot size, as
> that was the determining factor in standing on pinheads. After a few decades
> of discussion on angelic footwear and whether sandals would occupy more
> space than sneakers or gumboots, someone would observe that it was a bit
> unnecessary for angels to occupy pinheads anyway, and how could such a
> stupid topic be occupying the brilliant minds of the group?
> 
> In the meantime, various contributors (having done their own painstaking
> calculations) would have offered various numbers, and been rejected as not
> understanding the nature of the problem or having a proper grasp of the
> ramifications.
> 
> As the third century of discussion began, algorithms for calculating angelic
> footprints would start to emerge and the whole newsgroup would split into
> various camps supporting one of several approaches. A "religious War" would
> then ensue with a lot of unangelic abuse and bad behaviour. Robert Wagner
> would be blamed for everything and each of his posts would be carefully
> shredded. Undeterred, Robert would continue in his assertion that he had
> been counting angels on pinheads before any of the other contributors were
> aware that there were such things as pins, and had once developed a software
> engine that could instantly calculate the number of angels from the increase
> in weight.At this point Richard would observe that angels have no weight,
> and therefore Robert's machine was totally inaccurate and pointless and his
> claim to superiority could be dismissed as trivial.
> 
> This exchange would continue for another 60 years or so, until Robert would
> suddenly change his position by remembering that it wasn't the weight, it
> was the mass...  (and on that very appropriate thought for a religious
> discussion, I shall leave this little whimsy...)

So that's what you've been up to - creative writing!  ;)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/9/2004 1:23:16 AM
top post...

I enjoyed your reply. LMAO.
On the question of things that might be done,
I know that with call and invock a lot of power has been added.
I just don't know how much. Why? I'd still like to see the
program document ion in one place. To this end, in a dream
this evening, I thought:

Subdivide the Data Division.
One sub would be the specs for an xml
another would be the specs for a css
etc.

Benefits:
Centralize documentation
Expand the ability to create for what ever is needed.

etc.


Extend the picture code to include
font, size, bold,

Specify left justify for text, or center, or right.


Surely, today, the compiler is well designed so that
the extensions would occupy the major additional effort
and give the programmer the same tools available with
text creation with editors.

These I call balloon assent ions.  I never expect them to happen
in my life time. It took me 5 years to get sort added, and it was
already a part of Flow-Matic.

Status of hardware development makes a great deal of difference.

I've cut the balance of your reply, as this is P2P.

Warren Simmons
0
wsimmons5 (172)
10/9/2004 3:37:17 AM
"Warren Simmons" <wsimmons5@optonline.net> wrote in message
news:N1J9d.26305$rh4.11097169@news4.srv.hcvlny.cv.net...
> top post...
>
> I enjoyed your reply. LMAO.

Great! (my time was well spent... :-))

> On the question of things that might be done,
> I know that with call and invock a lot of power has been added.
> I just don't know how much. Why? I'd still like to see the
> program document ion in one place. To this end, in a dream
> this evening, I thought:
>
> Subdivide the Data Division.
> One sub would be the specs for an xml
> another would be the specs for a css
> etc.
>
<<<
These are creative ideas, Warren. I hope that if I ever get to your span of
years my mind will still be as active as yours obviously is.

The fact is that XML doesn't need COBOL. And COBOL can call XML from
existing free components.

Cascading Style Sheets are an essential part of web design (well, they are
essential if you are serious about your web design and intend it to be
commercially viable.). Whether they need to be a part of COBOL is arguable.
They are subject to change and this change process is governed by a user
body that would equate COBOL with flint arrowheads and mastodons. Again, my
feeling is that this is an aspect of web design that is best kept separate
from COBOL.

> Benefits:
> Centralize documentation
> Expand the ability to create for what ever is needed.
>
> etc.
>
>
> Extend the picture code to include
> font, size, bold,
>

Now THAT makes a lot of sense to me, provided you are dealing with an edited
picture (which, by definition originally, had to be an OUTPUT field.)  It
would be pretty horrendous to implement though. There are so many attributes
for screens and printers  you would probably have to define the required
devices in the ENVIRONMENT DIVISION and then your program would be locked in
to those specific devices. Not good.

> Specify left justify for text, or center, or right.
>

This is more hopeful because it need not necessarily be device dependent.

>
> Surely, today, the compiler is well designed so that
> the extensions would occupy the major additional effort
> and give the programmer the same tools available with
> text creation with editors.
>
> These I call balloon assent ions.  I never expect them to happen
> in my life time. It took me 5 years to get sort added, and it was
> already a part of Flow-Matic.
>

And look at the controversy you have generated ever since... :-) To this day
COBOL programmers are arguing whether external or internal sorts are
"better", and some (of the more creative ones) have advocated processing
lists of pointers... very unCOBOL... :-)

> Status of hardware development makes a great deal of difference.
>
> I've cut the balance of your reply, as this is P2P.

That would be "peer to peer", right? I am exalted... :-)

Take care. And keep those creative juices flowing...

Pete.





0
10/10/2004 1:41:24 AM
"LX-i" <lxi0007@netscape.net> wrote in message
news:f4H9d.15711$VJ2.12336@fe40.usenetserver.com...
<snip>
>
> So that's what you've been up to - creative writing!  ;)
>
Very perceptive, Daniel. I'm glad it shows... :-)

Follow this link: http://tinyurl.com/ywrcc

Click the "NEWS" link, and download the newsletter...

Read the Editorial and see who wrote it... 

Then send me a Reality Check :-) (see page 8)

This invitation extends to all CLCers.

Pete.
<snip>
0
dashwood1 (2140)
10/10/2004 1:54:08 AM
..    Am  09.10.04
schrieb  dashwood@enternet.co.nz (Peter E. C. Dashwood)
    auf  /COMP/LANG/COBOL
     in  b3638c46.0410091754.731d9cb3@posting.google.com
  ueber  Re: OFF Topic

PECD> Follow this link: http://tinyurl.com/ywrcc
PECD>
PECD> Click the "NEWS" link, and download the newsletter...

   Your links don't work with Mozilla. You need a little bit more  
creative writing in Javascript .... the Javascript console tells me  
that "form1 is not defined".

   "forms" are in the object hierarchy under the document object, and  
you would have to specify "document.forms[1]" or  
'document.forms["form1"]' or "document.form1". Maybe it is still more  
complicated by using frames.



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


0
l.willms1 (637)
10/10/2004 8:34:00 AM
Pete Dashwood wrote:
> "Warren Simmons" <wsimmons5@optonline.net> wrote in message
> news:N1J9d.26305$rh4.11097169@news4.srv.hcvlny.cv.net...
> 
>>top post...
>>
>>I enjoyed your reply. LMAO.
> 
> 
> Great! (my time was well spent... :-))
> 
> 
>>On the question of things that might be done,
>>I know that with call and invock a lot of power has been added.
>>I just don't know how much. Why? I'd still like to see the
>>program document ion in one place. To this end, in a dream
>>this evening, I thought:
>>
>>Subdivide the Data Division.
>>One sub would be the specs for an xml
>>another would be the specs for a css
>>etc.
>>
> 
> <<<
> These are creative ideas, Warren. I hope that if I ever get to your span of
> years my mind will still be as active as yours obviously is.
> 
> The fact is that XML doesn't need COBOL. And COBOL can call XML from
> existing free components.
> 
> Cascading Style Sheets are an essential part of web design (well, they are
> essential if you are serious about your web design and intend it to be
> commercially viable.). Whether they need to be a part of COBOL is arguable.
> They are subject to change and this change process is governed by a user
> body that would equate COBOL with flint arrowheads and mastodons. Again, my
> feeling is that this is an aspect of web design that is best kept separate
> from COBOL.
> 
> 
>>Benefits:
>>Centralize documentation
>>Expand the ability to create for what ever is needed.
>>
>>etc.
>>
>>
>>Extend the picture code to include
>>font, size, bold,
>>
> 
> 
> Now THAT makes a lot of sense to me, provided you are dealing with an edited
> picture (which, by definition originally, had to be an OUTPUT field.)  It
> would be pretty horrendous to implement though. There are so many attributes
> for screens and printers  you would probably have to define the required
> devices in the ENVIRONMENT DIVISION and then your program would be locked in
> to those specific devices. Not good.
> 
> 
>>Specify left justify for text, or center, or right.
>>
> 
> 
> This is more hopeful because it need not necessarily be device dependent.
> 
> 
>>Surely, today, the compiler is well designed so that
>>the extensions would occupy the major additional effort
>>and give the programmer the same tools available with
>>text creation with editors.
>>
>>These I call balloon assent ions.  I never expect them to happen
>>in my life time. It took me 5 years to get sort added, and it was
>>already a part of Flow-Matic.
>>
> 
> 
> And look at the controversy you have generated ever since... :-) To this day
> COBOL programmers are arguing whether external or internal sorts are
> "better", and some (of the more creative ones) have advocated processing
> lists of pointers... very unCOBOL... :-)
> 
> 
>>Status of hardware development makes a great deal of difference.
>>
>>I've cut the balance of your reply, as this is P2P.
> 
> 
> That would be "peer to peer", right? I am exalted... :-)
> 
> Take care. And keep those creative juices flowing...
> 
> Pete.
> 
> 
> 
> 
> 
O.K. You never know. One in a hundred is better than none at all.

I get different advice from others. Mostly, a lot less charitable.

Here is another idea that has been running around in my "dish washing"
mind.

When, or until Uncle Sam and others insist on common data 
representation, ....

We will have a vendor compiler, COBOL Spec, User's Guide, and
loads and loads of Utilities created to solve problems with
the interchange of data, recovery of files, etc. The IBM
user will discuss the use of JCL, this utility, and that utility.
Other vendors have the same situation in different levels depending
upon their hardware, and software designs.

It seems to me that in the next century, a common set of these
"tools" could become a part of a COBOL SET. Even some of the
far out "needs" of some users could be supported by plug-ins
if an interface was defined. In fact, many things available now
seem ideal as possible plug ins reather than CALLs, etc.

Back to washing dishes.

Warren
0
wsimmons5 (172)
10/11/2004 12:40:42 AM
..    Am  10.10.04
schrieb  dashwood@nospam.enternet.co.nz (Pete Dashwood)
    auf  /COMP/LANG/COBOL
     in  1097451657.l73HNxSpbWhQW1bn1eZe7g@teranews
  ueber  Re: OFF Topic

>> Extend the picture code to include
>> font, size, bold,


PD> Now THAT makes a lot of sense to me, provided you are dealing with an
PD> edited picture (which, by definition originally, had to be an OUTPUT
PD> field.)

   And it would need to be only in the REPORT WRITER and SCREEN  
sections, nowhere else.

   But not as an extension to the PICTURE clause, but as an additional  
clause like PRINT-FORMAT or CHARACTER-TYPE.

   And for the REPORT SECTION I would like to see the ability to  
specify the printing position of groups and elements by tenths of  
millimeter or hundreths of inch.

PD> It would be pretty horrendous to implement though.

   I don't think so. One would use the rendering engines, the printing  
system supplied by the operating system, its printer drivers etc.

PD> There are so many attributes for screens and printers

   Four of them would be sufficient:

   - Font family name, e.g. "Arial", "Times Roman", "OCR B"
   - Font size in typographic points
   - One of the four font variants
      (how does one say that in English? Font decoration?):
      normal, bold, italic, bold-italic which are provided by the
        basic rendering systems in e.g. Windows, Postscript etc.
   - Colour

PD> you would probably have to define the required devices
PD> in the ENVIRONMENT DIVISION

   Yes, the SPECIAL-NAMES paragraph is the place to specify special  
names for the combination of those four attributes mentioned above

   but not the actual printer or other display device.

PD> and then your program would be locked in to those specific  
devices. Not good.

>> Specify left justify for text, or center, or right.
>>

PD> This is more hopeful because it need not necessarily be device
PD> dependent.

   JUSTIFIED LEFT is the default, and JUST[IFIED] RIGHT is available  
since generations. JUST CENTER might be a nice addition to the next  
standard.

   But the 2002 standard already has the COLUMN CENTER clause for the  
REPORT WRITER enabling to center a given item around a column.

   So I don't see any need to duplicate this.

   Except perhaps by providing an alternative to the COLUMN clause  
with a PRINTING-POSITION (Fujitsu) which could be specified in tenths  
of millimeter resp. hundreths of inch; whereby it would probably be  
good to specify a unit in the ENVIRONMENT DIVISION which could be a  
multiple of one of the two basic measurements. I hope I have not  
misunderstund Fujitsu's PRINTING-POSITION clause...


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)
10/11/2004 7:24:00 AM
l.willms@jpberlin.de (Lueko Willms) wrote 

> >> Extend the picture code to include
> >> font, size, bold,

> PD> There are so many attributes for screens and printers
> 
>    Four of them would be sufficient:
> 
>    - Font family name, e.g. "Arial", "Times Roman", "OCR B"
>    - Font size in typographic points
>    - One of the four font variants
>       (how does one say that in English? Font decoration?):
>       normal, bold, italic, bold-italic which are provided by the
>         basic rendering systems in e.g. Windows, Postscript etc.
>    - Colour

I've never liked building the external characteristics into the
program code. There may be times when the actual positioning, font,
etc is firmly fixed and unchangable, but then the user will want it
changed.  I consider that all output should be templated.  If I need
such fine control as you suggest then it is relatively easy to draw a
postscript template and merge the data items into it.

For Web sites there are two main processes for getting active pages:
The 'page in program' style of typical Perl and Java Servlets, where
the code emits the html and the 'program in page' of PHP, ASP and JSP,
where the html page has code scattered about it to add the data items.
 Both are abominations (IMHO).

Using templating is easy to keep the code and the presentation
completely seaparate.  Change the style only requires changes to the
template or some higher level such as a CSS sheet.  Want a .CSV
version of that html table? just have another template and a mechanism
to get the program to use it.

The same with printed reports, forms, EDI files, XML files, EMails.
Have the program write the data to a template and neither know nor
care what the final result is.

In some cases in my systems there is even a two stage process.  The
program writes out using a template which is actually formatting to a
file which is a merge data file for a proprietry form output program.

Even with simple text reports that do not use templating I allow the
user to select which printer to use and the option caters for
landscape compressed or portrait 80 column so they can make a choice
how they want to see the results.
0
riplin (4127)
10/11/2004 6:37:22 PM
Thanks for that Lueko.

(And thanks to the many people who accessed it from all over the world. You
created quite a ripple of excitement in our little group... I have to
apologise to the ones who used Netscape or Mozilla. Explanation follows.)

The site is only guaranteed with IE4 and above.

I started out testing it with Netscape and IE but it got too cumbersome to
keep detecting which Browser is being used and react accordingly.

My ISP shows that over 95% of access is with IE so that's the one I cater
for and test it with.

Currently the site is hosted on one of my ISPs but we have now obtained a
proper domain name and will be moving to a proper host, as soon as I can
find one that is cheap, reliable, supports CGI and will let me run the COBOL
runtime in it, and has a remote server for MySQL (that can support ACCESS
through ODBC).

I am aware of the document model for JavaScript, but I didn't realise it was
necessary to qualify back to the document
when it only contains one form and that form IS defined. (And it icertainly
ISN'T necessary with IE; the site works.)

I'll try adding the document qualifier to form references and see if it
makes any difference.

I'll also add a logo indicating that it is best viewed with IE.

As this is a "labour of Love" for which I do not get paid, I really can't
spend too many hours on it.

Thanks for the "heads up". In the meantime, try accessing it with IE.

If this is not available and you really want to see the newsletter, another
alternative would be to click the "archive" link on the same page and select
"current" from the table of past documents. As it doesn't use a form control
that SHOULD work.

Pete.

(Top post, nothing below the signature.)

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9IcxnTKPflB@jpberlin-l.willms.jpberlin.de...
> .    Am  09.10.04
> schrieb  dashwood@enternet.co.nz (Peter E. C. Dashwood)
>     auf  /COMP/LANG/COBOL
>      in  b3638c46.0410091754.731d9cb3@posting.google.com
>   ueber  Re: OFF Topic
>
> PECD> Follow this link: http://tinyurl.com/ywrcc
> PECD>
> PECD> Click the "NEWS" link, and download the newsletter...
>
>    Your links don't work with Mozilla. You need a little bit more
> creative writing in Javascript .... the Javascript console tells me
> that "form1 is not defined".
>
>    "forms" are in the object hierarchy under the document object, and
> you would have to specify "document.forms[1]" or
> 'document.forms["form1"]' or "document.form1". Maybe it is still more
> complicated by using frames.
>
>
>
> Yours,
> L�ko Willms
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
>
>



0
10/11/2004 8:25:24 PM
Peter E. C. Dashwood wrote:
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:f4H9d.15711$VJ2.12336@fe40.usenetserver.com...
> <snip>
> 
>>So that's what you've been up to - creative writing!  ;)
>>
> 
> Very perceptive, Daniel. I'm glad it shows... :-)
> 
> Follow this link: http://tinyurl.com/ywrcc
> 
> Click the "NEWS" link, and download the newsletter...

This doesn't seem to work with Firefox - I'll have to go over to my 
wife's machine and pull it up with IE.

> Read the Editorial and see who wrote it... 
> 
> Then send me a Reality Check :-) (see page 8)

heh - now you've got me interested!


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/11/2004 10:11:49 PM
On 11-Oct-2004, "Pete Dashwood" <dashwood@nospam.enternet.co.nz> wrote:

> The site is only guaranteed with IE4 and above.

But every other browser is "above" IE.    Just because they don't allow some
dangerous practices doesn't make them inferior.


> I started out testing it with Netscape and IE but it got too cumbersome to
> keep detecting which Browser is being used and react accordingly.

Then make your code compatible with de Jure standards.

> My ISP shows that over 95% of access is with IE so that's the one I cater
> for and test it with.

There are sites that obviously don't want my custom.    Demanding that customers
change to the vendors' ways of doing things, even to the extent of using the
most dangerous browser out there seems to be the easy way to do business.    I
didn't figure you to be one of those type of programmers.
0
howard (6283)
10/12/2004 3:02:42 PM
In article <217e491a.0410111037.1094ca7@posting.google.com>, riplin@Azonic.co.nz (Richard) writes:
> 
> I've never liked building the external characteristics into the
> program code. There may be times when the actual positioning, font,
> etc is firmly fixed and unchangable, but then the user will want it
> changed.  I consider that all output should be templated.

I agree.  Templates also make internationalization easier; the program
selects the language-appropriate set of templates at run time.  And it
makes accomodating special requirements (like access for visually-
impaired users) much easier too; in some cases that might be necessary
to make a sale (eg to comply with US government section 508 rules).

Templates also potentially provide a mechanism for users to customize
program output.  That could be very useful, eg to provide a minimal-
formatted version for machine processing.  If your templating mechanism
is documented, sufficiently technical customers don't even need to go
to you - they can do it themselves.

-- 
Michael Wojcik                  michael.wojcik@microfocus.com

Q: What is the derivation and meaning of the name Erwin?
A: It is English from the Anglo-Saxon and means Tariff Act of 1909.
   -- Columbus (Ohio) Citizen
0
mwojcik (1879)
10/12/2004 8:19:54 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:ckgrmi$e16$1@peabody.colorado.edu...
>
> On 11-Oct-2004, "Pete Dashwood" <dashwood@nospam.enternet.co.nz> wrote:
>
> > The site is only guaranteed with IE4 and above.
>
> But every other browser is "above" IE.    Just because they don't allow
some
> dangerous practices doesn't make them inferior.
>

This is not meant in the sense of relative worth, Howard. And you are living
in a fool's paradise if you really believe that "other browsers" are secure.
The minute that anything is exposed on the Internet it is subject to risk.

I have no personal preference with regard to Browsers. It is simply a matter
of how much time I can spend on this. If 95% of the traffic is via IE then,
until such time as it becomes a priority to make the site "commercial", that
is the Browser I'll support.


>
> > I started out testing it with Netscape and IE but it got too cumbersome
to
> > keep detecting which Browser is being used and react accordingly.
>
> Then make your code compatible with de Jure standards.
>

The code IS compatible with de Jure standards. I am not arguing the merit of
various Browsers, and had you bothered to read my note, you would see that a
pathway HAS been provided for people who use browsers other than IE.

(Instead of using a radio button to select the current newsletter, click the
archive link just below it on the same page. This avoids the Javascript
controls which are currently problematic, for non-IE browsers.)

I also mentioned that I will take Leuko's advice and try qualifying the
form containing the controls back to the document. Doing this may help
everything to work for all browsers. I just haven't had time to do it yet.

I think you are reacting emotionally to something that is not an issue.

> > My ISP shows that over 95% of access is with IE so that's the one I
cater
> > for and test it with.
>
> There are sites that obviously don't want my custom.    Demanding that
customers
> change to the vendors' ways of doing things, even to the extent of using
the
> most dangerous browser out there seems to be the easy way to do business.
I
> didn't figure you to be one of those type of programmers.
>

Thank you for that, and you are right... I'm not.

I don't DEMAND anything. And I am not "doing business". (If I was, I'd be
paid for my efforts and could therefore afford the time to make the site
better.)

I have flagged the fact that the site is not Mozilla/Netscape friendly. That
doesn't mean it never will be, it just isn't at the moment. Neither does it
imply a criticism of these browsers.

Now, if you're calm, why not revisit and try the archive link? If THAT
doesn't work for you, I'd really appreciate your telling me.

Thanks,

Pete.




0
dashwood1 (2140)
10/12/2004 11:43:17 PM
"Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote

> This is not meant in the sense of relative worth, Howard. And you are living
> in a fool's paradise if you really believe that "other browsers" are secure.
> The minute that anything is exposed on the Internet it is subject to risk.

The main problem with IE is that it is running on, and integrated
with, Windows. This means that many of the security problems are
_designed_into_ the browser. Some small number of the problems can
also occur with other browsers _on_Windows_, and that is because the
underlying problem is actually part of Windows.

The phishing problem, where the actual URL being visited is hidden by
IE, doesn't occur in other browsers, the drag-and-drop scroll bars
doesn't happen.

It is not just that hackers don't bother with other browsers, or they
are not significant, they just can't do what IE does.

> I have no personal preference with regard to Browsers. It is simply a matter
> of how much time I can spend on this. If 95% of the traffic is via IE then,
> until such time as it becomes a priority to make the site "commercial", that
> is the Browser I'll support.

Firefox has had 5 million downloads in a couple of weeks. Apart from
all the security issues with IE it is also completely outdated and
obsolete compared to what Opera, Firefox and Mozilla have been doing
for years.

Haven't you tried tabbed browsing ?  No popups ? Mouse gestures ?  IE
is very 'last century', and MS are not updating it for pre-XP
machines.

Of course MS want everyone to throw money at them to buy XP to 'solve'
the problem (but it won't be solved), many are hust dumping IE and
getting something better that isn't obsolete and broken (by design).
0
riplin (4127)
10/13/2004 7:28:51 AM
All fair comment, Richard.

IE supporters could make a similar case. I take your point that there are
still vulnerabliliteis in IE that may not exist in other browsers (however,
there may be as yet unexploited vulnerablilities in other browsers that
don't exist in IE. We can't know until they get the same share of the market
currently enjoyed by IE and are taking the same hammering and targeted by
the same (or similar) malcontents.)

I don't intend to debate the relative merit of browsers; I'm not qualified
to do so.

The nub of my argument is this:

1. I have a limited amount of time I am prepared to spend on the web site,
at this stage. (I spend a large amount of time on the actual Newsletter and
in other Writing activities.)

2. It is a "labour of Love" and is well received and supported. It is
certainly better than no web site.

3. The majority of access is via IE; that's the one I'll develop to. (I
don't run alternative browsers on my system at this stage as I found there
are conflicts when I do. However, I will take reasonable care to ensure that
the scripts I write for this site are as universal as possible. I just won't
guarantee it.



As I don't intend to be drawn into a religious war on this, I really have
little more to add.

I have some quick responses to your points embedded below.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410122328.2592c872@posting.google.com...
> "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote
>
> > This is not meant in the sense of relative worth, Howard. And you are
living
> > in a fool's paradise if you really believe that "other browsers" are
secure.
> > The minute that anything is exposed on the Internet it is subject to
risk.
>
> The main problem with IE is that it is running on, and integrated
> with, Windows. This means that many of the security problems are
> _designed_into_ the browser. Some small number of the problems can
> also occur with other browsers _on_Windows_, and that is because the
> underlying problem is actually part of Windows.

Fair enough. I use windows and find it OK. I'm running XP Pro and, as I may
have remarked here before, it is the first PC based OS I have had that I am
completely happy with. ( I have been developing for PCs since they were
widely available (around 1984) and I still feel very comfortable with the
DOS command line. As you know, my background before that was 20 years with
mainframe command lines. I still like Windows (or, perhaps more correctly,
GUI, better.) I am considering Linux as a possibility in the future, but
that is more curiosity than need. I am neither pro nor anti Microsoft as a
Company, but i do believe XP is a good product.
>
> The phishing problem, where the actual URL being visited is hidden by
> IE, doesn't occur in other browsers, the drag-and-drop scroll bars
> doesn't happen.

I'll take your word for it. I can usually tell when a URL is being spoofed
and I'm not sure what you mean by drag and drop scroll bars. Frames can be
resizable or scrollable (or not) irrespective of the browser, but I'm sure
you know that.

>
> It is not just that hackers don't bother with other browsers, or they
> are not significant, they just can't do what IE does.
>

Maybe I'm not ambitious enough <G>.


> > I have no personal preference with regard to Browsers. It is simply a
matter
> > of how much time I can spend on this. If 95% of the traffic is via IE
then,
> > until such time as it becomes a priority to make the site "commercial",
that
> > is the Browser I'll support.
>
> Firefox has had 5 million downloads in a couple of weeks. Apart from
> all the security issues with IE it is also completely outdated and
> obsolete compared to what Opera, Firefox and Mozilla have been doing
> for years.
>

Well, again, I accept your authority on this. When 95% of people start using
them, I'll do the hard yards...


> Haven't you tried tabbed browsing ?  No popups ? Mouse gestures ?  IE
> is very 'last century', and MS are not updating it for pre-XP
> machines.

No Popups can be easily plugged in, mouse gestures sounds interesting ... I
have used layered behaviours in JavaScript to do amusing things with mouse
overs, but I don't really know what you mean, and "tabbed browsing" is a new
one on me.

Now I find myself defending IE and I really don't want to do that... <G>

>
> Of course MS want everyone to throw money at them to buy XP to 'solve'
> the problem (but it won't be solved), many are hust dumping IE and
> getting something better that isn't obsolete and broken (by design).
>
Well, maybe we just have to differ on our perceptions here.

As always, I respect your knowledge in these things.

Pete.



0
dashwood1 (2140)
10/13/2004 10:54:36 AM
On 12-Oct-2004, "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote:

> This is not meant in the sense of relative worth, Howard. And you are living
> in a fool's paradise if you really believe that "other browsers" are secure.
> The minute that anything is exposed on the Internet it is subject to risk.

I agree.  Nor that driving with seatbelts buckled will make me secure on the
roads.   That said, I wear my seat belt, and I avoid the most dangerous browser.



> I don't DEMAND anything. And I am not "doing business". (If I was, I'd be
> paid for my efforts and could therefore afford the time to make the site
> better.)

My interest here is whenever I see someone publicly proclaim that he doesn't
support browsers other than IE, to object.   Hopefully others who have read his
statement don't decide that this is OK for them as well.    That is my only
interest in this thread.   It's not about you nor about you web page - it's
about letting ideas that I disagree with pass uncommented upon.
0
howard (6283)
10/13/2004 2:28:31 PM
On 13 Oct 2004 00:28:51 -0700, riplin@Azonic.co.nz (Richard) wrote:

>The main problem with IE is that it is running on, and integrated
>with, Windows. This means that many of the security problems are
>_designed_into_ the browser. Some small number of the problems can
>also occur with other browsers _on_Windows_, and that is because the
>underlying problem is actually part of Windows.

True. The current generation of malware doesn't exploit browser
weakness, for instance buffer overruns, it exploits legit features
that were created for ease of use. 

A virus I've been chasing for two days was using WinRAR to re-install
itself -- the same mechanism Windows Update uses to upgrade
software. The only thing resident was a hidden shortcut connected to
the Open Window class.  Download, extraction (installation),
execution, creation of an Explorer Bar, killing the firewall,  and
file deletion all occurred behind the scenes, without notification.

In other words, you can catch a virus by simply opening a Web page ..
or having a pop-up open it.

I'm using IE6 with the latest updates. The only way to prevent such an
attack *with IE* is to run with scripting and Java off
(Tools\Options\Security\Custom\High), which also stops pop-ups (a Java
feature). You must then list Yahoo, your online banking and other
sites requiring Java in Trusted Sites. 

0
robert6624 (636)
10/13/2004 5:07:14 PM
"Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote 

> IE supporters could make a similar case. I take your point that there are
> still vulnerabliliteis in IE that may not exist in other browsers (however,
> there may be as yet unexploited vulnerablilities in other browsers that
> don't exist in IE. We can't know until they get the same share of the market
> currently enjoyed by IE and are taking the same hammering and targeted by
> the same (or similar) malcontents.)

They could make 'a similar case', but they would be wrong.  For
example Apache has a much larger market share than IIS, but it is IIS
that has the significant vulnerabilities.  While both have security
'issues', it is IIS that has the damaging faults.

Most of the problems are due to Windows starting as a graphics library
on DOS and having to provide an environment that grew from there. It
has has layers added to it to give the appearance of security and
further layers to make it 'easy to use', and further layers to ... 
but the problems are at the root of the design, or the layers of
design, that allows processes to gain root access.


> I don't intend to debate the relative merit of browsers; I'm not qualified
> to do so.

You should try some to find out why others use them. Tabbed browsing,
cookie and javascript management by site, no popups, make the internet
much more accessible.
0
riplin (4127)
10/13/2004 6:39:21 PM
Pete Dashwood wrote:
<snip>
> If this is not available and you really want to see the newsletter, another
> alternative would be to click the "archive" link on the same page and select
> "current" from the table of past documents. As it doesn't use a form control
> that SHOULD work.

I don't see an "archive" link on the page.

Louis Krupp
0
lkrupp847 (386)
10/13/2004 7:39:20 PM
Hi Louis,

thanks for your post (and the lack of abuse in it... <G>)

Take the "NEWS" link.

A framed page should appear with some radio buttons (more properly, "option
buttons") to select the format for the download.

I believe it is these buttons that are not working in browsers other than
IE. They are contained in an object called "form1" and Leuko told me that
his browser says "form1" is not defined. (It IS defined, but it is not
qualified back to the document level. Apparently, while this is OK for IE,
it isn't for the others.)

If you scroll down, beneath the radio buttons and the button to activate the
download,  there is a plain link to "view archives".

This allows people to view back copies of the newsletter, as well as the
current edition.

I don't know, because I have only tested with IE, whether this works for the
other browsers, but, as it is a straight link without any form-contained
controls, I would expect it to.

In fact, I'd be grateful if, instead of getting all hot under the collar
about my scandalous use of Microsft products, someone with a different
environment could try this and let me know whether it works. If it doesn't,
I'll certainly look at fixing it.

Cheers,

Pete.



"Louis Krupp" <lkrupp@pssw.NOSPAM.com.INVALID> wrote in message
news:10mr12h7ekj4ec1@corp.supernews.com...
> Pete Dashwood wrote:
> <snip>
> > If this is not available and you really want to see the newsletter,
another
> > alternative would be to click the "archive" link on the same page and
select
> > "current" from the table of past documents. As it doesn't use a form
control
> > that SHOULD work.
>
> I don't see an "archive" link on the page.
>
> Louis Krupp
>



0
dashwood1 (2140)
10/13/2004 9:21:22 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:ckje2f$9ar$1@peabody.colorado.edu...
>
> On 12-Oct-2004, "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote:
>
> > This is not meant in the sense of relative worth, Howard. And you are
living
> > in a fool's paradise if you really believe that "other browsers" are
secure.
> > The minute that anything is exposed on the Internet it is subject to
risk.
>
> I agree.  Nor that driving with seatbelts buckled will make me secure on
the
> roads.   That said, I wear my seat belt, and I avoid the most dangerous
browser.
>

I certainly wear a seat belt, but it doesn't stop me traversing roads
considered "dangerous". The perception of what is "dangerous" is a very
personal and subjective one.

Mothers here tell their kids that jumping off a
certain bridge is "dangerous", there are signs all over the bridge telling
people not to jump off it, yet jumping off it is a teenage "rite of
passage". I jumped off it when I was 17, and kids today are still jumping
off it. The local authority has installed barbed wire to discourage it, but
the kids simply cut the wire or get over it anyway. Most of the jumpers
survive, so is it really "dangerous"?  It depends on your point of view and
your personal tolerance to risk.

Despite the assurances here that MS users will burn in Hell, I use these
products every day and don't get exploited or hijacked. (Sorry, not true, I
DID get hijacked by some adware a couple of weeks ago. It took all of 30
minutes to detect and remove it...).

I use a firewall (Sygate) and have up-to-date virus protection (Panda), and
Spam filtration on my system for the ISPs who don't provide it or where I
don't use the ISP's filter. It seems to work OK for me.

I just don't feel passionate about this one way or the other. MicroSoft have
never done me any harm, why would I attack them publicly?

(I confess to some disappointment that the only posts to this thread have
been from strongly anti-MS people. Maybe I'm the only one still using their
products... <G>)

>
>
> > I don't DEMAND anything. And I am not "doing business". (If I was, I'd
be
> > paid for my efforts and could therefore afford the time to make the site
> > better.)
>
> My interest here is whenever I see someone publicly proclaim that he
doesn't
> support browsers other than IE, to object.

Even if the reasons for it are clearly explained, and there is no suggestion
that IE is superior? Sounds to me like thundering for the sake of
thundering...


> Hopefully others who have read his
> statement don't decide that this is OK for them as well.

If they do, perhaps they'll also explain their reasoning. (although there is
no requirement to do so). It really is perfectly OK for people to support
MicroSoft or not. Just as it is perfectly OK for you to have an opinion
about it, Howard.

> That is my only
> interest in this thread.   It's not about you nor about you web page -
it's
> about letting ideas that I disagree with pass uncommented upon.

Well, you know how I feel about this forum as a place for expression and
"commenting on".  Glad to see it.

I understand your attack was not personal (I am not your enemy).

I also know that you are normally one of the "Voices of Reason" here, so
it's pretty obvious that I pushed a button.

It wasn't intentional.

Pete.




0
dashwood1 (2140)
10/13/2004 9:58:53 PM
"Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote 

> Despite the assurances here that MS users will burn in Hell, I use these
> products every day and don't get exploited or hijacked. (Sorry, not true, I
> DID get hijacked by some adware a couple of weeks ago. It took all of 30
> minutes to detect and remove it...).

I suspect that you _noticed_ that you had been hijacked. How many have
you not noticed ?  Well the answer must be 'all the others' which may,
or may not, be zero.

It is estimated that 60% of the spam comes via Windows machines that
have been loaded with spam remailers without the user being aware of
it.  In fact lists of 'owned' machines are bought and sold.  I have
seen references to prices of $30,000 per 2,000 machines.  Access may
be via 'port knocking' so that port scans will show the machine to be
completely locked up tight, but the 'owner' can still open the machine
up from outside.

> I use a firewall (Sygate) and have up-to-date virus protection (Panda), and
> Spam filtration on my system for the ISPs who don't provide it or where I
> don't use the ISP's filter. It seems to work OK for me.

See    http://www.mikx.de/scrollbar/

> I just don't feel passionate about this one way or the other. MicroSoft have
> never done me any harm, why would I attack them publicly?

I'm not sure what you would do that would 'attack them publically' ?
Would this include 'acknowleging that alternatives exist' ?
 
> (I confess to some disappointment that the only posts to this thread have
> been from strongly anti-MS people. Maybe I'm the only one still using their
> products... <G>)

You seem to think that adopting open standards that all can use is
'strongly anti-MS'.  Admittedly, MS would prefer the adoption of their
'standards', and indeed of non-standard MSisms, that it can control
and thus lock in its revenue stream.

I should point out that the internet existed long before MS discovered
it.  Initially MS tried to replace the internet with its own network
(the original MSN that was only for Win95 users, and the only thing
that Win95 would access), but that failed so it has been trying to
control the internet ever since, such as by deliberate
incompatabilities.
0
riplin (4127)
10/14/2004 4:05:35 AM
..    Am  14.10.04
schrieb  dashwood@enternet.co.nz (Peter E.C Dashwood)
    auf  /COMP/LANG/COBOL
     in  1097702489.44331oiISvWKdFEj2JMY0g@teranews
  ueber  Re: Creative Javascript writing

   about navigating in http://www.enternet.co.nz/users/dashwood/

   After selecting the link "NEWS" (bottom right)

PECD>
PECD> If you scroll down, beneath the radio buttons and the button to
PECD> activate the download,  there is a plain link to "view archives".
PECD>
PECD> This allows people to view back copies of the newsletter, as well
PECD> as the current edition.

   That page remains empty when I call the link in Mozilla 1.7

   When I do the same in MS-IE 5.0, IE tells me that there is an error  
on the page, and offers to open the debugger, pointing to an

   error in line 23 (of ActiveUI.JS, by ActiveUI Software, a "cross- 
browser" package... )
     identifier or string-literal expected

   error in line 67: "var obj = new Active.Controls.Grid;"
    'Active' is undefined


  Only when I click the link with MS-IE 6.0, I get no error and can  
see the page.

  I did not try other browsers.

  BTW: the text of the error messages above is my translation from  
German.


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

  "Nach meiner Ansicht besitzt die Presse _das_ _Recht_,
Schriftsteller, Politiker, Kom�dianten und andere �ffentliche
Charaktere zu _beleidigen_. Achtete ich [so einen Angriff gegen mich]
einer Notiz wert, so galt mir in solchen F�llen der Wahlspruch: �
corsaire, corsaire et demi [auf einen Schelmen anderthalben]."
                  - Karl Marx   17.11.1860  (Herr Vogt, Kapitel XI)
0
l.willms1 (637)
10/14/2004 8:14:00 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410132005.31cced18@posting.google.com...
> "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote
<snip>
> See    http://www.mikx.de/scrollbar/
>

 Thanks for the link, I had a look.

> > I just don't feel passionate about this one way or the other. MicroSoft
have
> > never done me any harm, why would I attack them publicly?
>
> I'm not sure what you would do that would 'attack them publically' ?
> Would this include 'acknowleging that alternatives exist' ?
>
Of course not. I actually use some of the alternatives.(Just not
browsers...)

> > (I confess to some disappointment that the only posts to this thread
have
> > been from strongly anti-MS people. Maybe I'm the only one still using
their
> > products... <G>)
>
> You seem to think that adopting open standards that all can use is
> 'strongly anti-MS'.

Nope. I have always been in favour of Open Standards and Open Systems. But
my personal preferences don't blind me to where the market place is going. I
agree that support for non-MS alternatives IS growing (especially in Europe)
but it is not yet significant enough to persuade me to change. (And, unlike
some people here, I DON'T have shares in MS <G>)

<snipped example of public attack on MS that was not just "acknowledging
that alternatives exist...<G>>

BTW, Richard, can you confirm what you posted about the Fujitsu Run Time
licence?  I'm interested to know where you got that and whether it is, in
fact, the case. I had a look through the documentation for the Version 6
licence but I can't find anything that says that. However, I know you are
meticulous in these things so I'd just like it confirmed (or not). Was it
hearsay, or do you have a document?

Thanks,

Pete.



0
dashwood1 (2140)
10/14/2004 10:40:02 AM
On 13 Oct 2004 11:39:21 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Most of the problems are due to Windows starting as a graphics library
>on DOS and having to provide an environment that grew from there. It
>has has layers added to it to give the appearance of security and
>further layers to make it 'easy to use', and further layers to ... 
>but the problems are at the root of the design, or the layers of
>design, that allows processes to gain root access.

SYSTEM on Windows is not as omnipotent as root on Unix. That can be
used against malfeasors. Suppose you have a virus that drops the same
file every time installed or executed. Here's how to stop it. Delete
the file. Log on as something other than Administrator. Copy a
zero-length file to the bad guys' file name. Go to Explorer, right
click, Security. Uncheck the Inherit box at the bottom, then uncheck
all permissions. You now have a file that cannot be overwritten or
modified in any way by SYSTEM. Next time the virus runs, you'll see an
error box or event log entries (via eventvwr) pointing to the bad guy.
In any case, the file will not be installed. 

>You should try some to find out why others use them. Tabbed browsing,
>cookie and javascript management by site, no popups, make the internet
>much more accessible.

IE has cookie, javascript and popup management by site .. if people
took the trouble to use it. It is in Security Zones. I recommend
setting the default (Internet) to High and putting your favorites in
Trusted. 

0
robert6624 (636)
10/14/2004 12:58:18 PM
On 13-Oct-2004, "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote:

> (I confess to some disappointment that the only posts to this thread have
> been from strongly anti-MS people. Maybe I'm the only one still using their
> products... <G>)

I use quite a few MS products.   But I don't use IE unless I have no choice.
0
howard (6283)
10/14/2004 2:00:03 PM
On 13-Oct-2004, "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote:

> I also know that you are normally one of the "Voices of Reason" here, so
> it's pretty obvious that I pushed a button.

Another thing that I expect to find in a CoBOL forum is a concern for standards.
  Netscape set de facto standards, IE expanded on them, and then the industry
created de jure standards.   Microsoft chose to continue developing, ignoring de
jure standards, mostly to integrate IE with Windows, and the seductive idea that
we should enjoy the power of lots of tools in an integrated environment.   
Trouble is, hackers also enjoy the power of lots of tools in an integrated
environment.

When courts determined (for other reasons) that Microsoft was wrong, Microsoft
stopped development of IE.

My e-mail program is Microsoft Outlook.    My newsgroup program is NewsRover.  
My browser of choice is Opera, although I also use FireBird.   I like freedom of
choice with standards.   I like being able to select best of breed (for my
needs).    I'd object if someone built roads designed for GM cars only.

I want OO environments to work with the best tools as well.   Use CoBOL where it
works best, Java where it works best, etc.
0
howard (6283)
10/14/2004 2:10:44 PM
"Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote 

> <snipped example of public attack on MS that was not just "acknowledging
> that alternatives exist...<G>>

So, a simple description of MS's business model is a 'public attack' ?

 > BTW, Richard, can you confirm what you posted about the Fujitsu Run
Time
> licence?  I'm interested to know where you got that and whether it is, in
> fact, the case. I had a look through the documentation for the Version 6
> licence but I can't find anything that says that. However, I know you are
> meticulous in these things so I'd just like it confirmed (or not). Was it
> hearsay, or do you have a document?

On the back of the box for version 6 is:

"""Free run times
   The rights to ship our single-user run-time are included 
   with every purchase of Fujitsu COBOL - ... """

The question is: what right do _you_ have to distribute the run-time
and is that right transferrable.

If the run-time was public domain then you, or anyone, can distribute.
 It isn't, the license (the one they issued to me) is quite clear that
Fujitsu is only selling the 'right to use' and that all material is
owned by Fujitsu and protected by Copyright etc.

In fact the license is specific in restricting the rights to a single
user on a single computer ... for its own internal data processing
operations.

"""Customers may not ... transfer, sell, assign or otherwise convey
any Program without Fujitsu's prior written consent; ..."""

The only 'prior written consent' that I have for version 6 is that on
the back of the box which grants that right to the purchaser, but the
license denies the ability to transfer or assign those rights
elsewhere. (actually I have other written words for previous
versions).

If you look at <a href="http://www.adtools.com/License/index.htm">http://www.adtools.com/License/index.htm</a>
you will see where distribution rights are granted, though I am not
sure if this page constitutes 'prior written agreement' in itself.

You may have completely different licenses and 'prior written words',
but I interpret what I have seen as meaning that only customers with
licenses have specific rights to distribute the run-times, and only
those allowed by the specific license.


NOTE: IANAL (I am not a Lawyer, I don't even play one on a TV
program).
0
riplin (4127)
10/14/2004 7:02:20 PM
"Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote 

> BTW, Richard, can you confirm what you posted about the Fujitsu Run Time
> licence?  

BTW for anyone interested a version of the license is <a
href="http://www.adtools.com/License/enduser_licagmt.pdf">here</a> in
PDF format. It is not necessarily PECD's or mine, but may be.
0
riplin (4127)
10/14/2004 7:08:20 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> Suppose you have a virus that drops the same
> file every time installed or executed. 

Suppose that _I_ have a system that doesn't make 'dropped files'
executable.

> Here's how to stop it. Delete
> the file. Log on as something other than Administrator. Copy a
> zero-length file to the bad guys' file name. Go to Explorer, right
> click, Security. Uncheck the Inherit box at the bottom, then uncheck
> all permissions. You now have a file that cannot be overwritten or
> modified in any way by SYSTEM. Next time the virus runs, you'll see an
> error box or event log entries (via eventvwr) pointing to the bad guy.
> In any case, the file will not be installed. 

Guess what, I spend _zero_ time on these sort of activities (hense I
don't feel the need to go out and get drunk I guess).


> IE has cookie, javascript and popup management by site .. if people
> took the trouble to use it. It is in Security Zones. I recommend
> setting the default (Internet) to High and putting your favorites in
> Trusted.

I suspect that it is the 'took the trouble' that stops it being widely
used. IE is just too clunky and out of date (as well as all its other
problems).
0
riplin (4127)
10/14/2004 7:24:23 PM
"Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote 

> > See    http://www.mikx.de/scrollbar/
> 
>  Thanks for the link, I had a look.

Did it 'infect' your machine ?

Has it made you think twice before using _any_ scrollbar ?
0
riplin (4127)
10/14/2004 7:30:31 PM
"Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote 

> I don't know, because I have only tested with IE, whether this works for the
> other browsers, but, as it is a straight link without any form-contained
> controls, I would expect it to.
> 
> In fact, I'd be grateful if, instead of getting all hot under the collar
> about my scandalous use of Microsft products, someone with a different
> environment could try this and let me know whether it works. If it doesn't,
> I'll certainly look at fixing it.

The link works, the page it goes to doen't.  The grid doesn't show in any of:

  Konqueror  - KDE browser
  Galleon    - Gnome browser (uses Mozilla engine)
  Mozilla    - 1.6
  Opera      - the button works fine but grid no show

The page just show the heading graphic plus:

"""    You can sort the grid by clicking on any of the headings in it... 
              CLOSE this window to return to our Home Page. 
"""
0
riplin (4127)
10/14/2004 7:55:44 PM

"Howard Brazee" <howard@brazee.net> wrote in message 
news:ckm1d3$96a$1@peabody.colorado.edu...
>
> On 13-Oct-2004, "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote:
>
>> I also know that you are normally one of the "Voices of Reason" here, so
>> it's pretty obvious that I pushed a button.
>
> Another thing that I expect to find in a CoBOL forum is a concern for 
> standards.
>  Netscape set de facto standards, IE expanded on them, and then the industry
> created de jure standards.   Microsoft chose to continue developing, ignoring 
> de
> jure standards, mostly to integrate IE with Windows, and the seductive idea 
> that
> we should enjoy the power of lots of tools in an integrated environment.
> Trouble is, hackers also enjoy the power of lots of tools in an integrated
> environment.
>

Reminds me a lot of COBOL and IBM vs ANSI in the late 60's and 70's.  There was 
a de jure Standard and there was a de facto standard (for many - but certainly 
NOT all environments).

The "problems" with Windows, IE  (and Microsoft products in general) reminds me 
a lot of how people "blamed" COBOL for Y2K, i.e the most commonly used product 
(language) was blamed for the problem.

I am *not* trying to say that Microsoft and/or Windows and/or IE is 
"blameless" - only that if they weren't so  VERY common, then
  A) people (hackers) wouldn't try and exploit their deficiencies
  B) people (users and NON-users) wouldn't blame them for widespread problems

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


0
wmklein (2605)
10/14/2004 8:50:54 PM
"Pete Dashwood" <dashwood@nospam.enternet.co.nz> wrote 

> My ISP shows that over 95% of access is with IE so that's the one I cater
> for and test it with.

Is that visitors or page hits ?  Obviously if a site doesn't work for
one visitor there will be much fewer hits from him.

Also you shouldn't assume that because a browser identifies as IE that
it is IE.  Many MS sites give different pages out depending on which
browser is identified. Opera especially will identify as IE:

""" ----------------------
Two weeks ago it was revealed that Microsoft's MSN portal targeted
Opera users, by purposely providing them with a broken page. As a
reply to MSN's treatment of its users, Opera Software today released a
very special Bork edition of its Opera 7 for Windows browser. The Bork
edition behaves differently on one Web site: MSN. Users accessing the
MSN site will see the page transformed into the language of the famous
Swedish Chef from the Muppet Show: Bork, Bork, Bork!

In October 2001, Opera users were blocked from the MSN site. The event
caused an uproar among Web users and MSN was forced to change their
policy. However, MSN continues a policy of singling out its Opera
competitor by specifically instructing Opera to hide content from
users.

"Hergee berger snooger bork," says Mary Lambert, product line manager
desktop, Opera Software. "This is a joke. However, we are trying to
make an important point. The MSN site is sending Opera users what
appear to be intentionally distorted pages. The Bork edition
illustrates how browsers could also distort content, as the Bork
edition does. The real point here is that the success of the Web
depends on software and Web site developers behaving well and rising
above corporate rivalry."
--------------- """

More recently:

""" ------------
Opera declaring itself as Opera got an apparently broken page, but was
OK if it claimed to be IE. Par for the course? For sure (there's
always something that is), but we couldn't help noticing that the
error message arrived after the browser was first fielded to this
page: http://www.playsforsure.com/MobileDefault.aspx. Now, we're just
guessing here, but that kind of looks like where a site might be
putting you if you were accessing it via a mobile phone.
---------------- """
0
riplin (4127)
10/14/2004 10:04:18 PM
Lueko,

Thank you very much for that. It is most helpful.

I appreciate your taking the time to let me know and give such a detailed
report.

I'll certainly see what I can do about improving my JavaScript.

Cheers,

Pete.
(Top post, no more)

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9IpR1DGuflB@jpberlin-l.willms.jpberlin.de...
> .    Am  14.10.04
> schrieb  dashwood@enternet.co.nz (Peter E.C Dashwood)
>     auf  /COMP/LANG/COBOL
>      in  1097702489.44331oiISvWKdFEj2JMY0g@teranews
>   ueber  Re: Creative Javascript writing
>
>    about navigating in http://www.enternet.co.nz/users/dashwood/
>
>    After selecting the link "NEWS" (bottom right)
>
> PECD>
> PECD> If you scroll down, beneath the radio buttons and the button to
> PECD> activate the download,  there is a plain link to "view archives".
> PECD>
> PECD> This allows people to view back copies of the newsletter, as well
> PECD> as the current edition.
>
>    That page remains empty when I call the link in Mozilla 1.7
>
>    When I do the same in MS-IE 5.0, IE tells me that there is an error
> on the page, and offers to open the debugger, pointing to an
>
>    error in line 23 (of ActiveUI.JS, by ActiveUI Software, a "cross-
> browser" package... )
>      identifier or string-literal expected
>
>    error in line 67: "var obj = new Active.Controls.Grid;"
>     'Active' is undefined
>
>
>   Only when I click the link with MS-IE 6.0, I get no error and can
> see the page.
>
>   I did not try other browsers.
>
>   BTW: the text of the error messages above is my translation from
> German.
>
>
> Yours,
> L�ko Willms                                     http://www.mlwerke.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
>   "Nach meiner Ansicht besitzt die Presse _das_ _Recht_,
> Schriftsteller, Politiker, Kom�dianten und andere �ffentliche
> Charaktere zu _beleidigen_. Achtete ich [so einen Angriff gegen mich]
> einer Notiz wert, so galt mir in solchen F�llen der Wahlspruch: �
> corsaire, corsaire et demi [auf einen Schelmen anderthalben]."
>                   - Karl Marx   17.11.1860  (Herr Vogt, Kapitel XI)
>



0
dashwood1 (2140)
10/14/2004 10:18:14 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410141155.754c7f68@posting.google.com...
> "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote
>
> > I don't know, because I have only tested with IE, whether this works for
the
> > other browsers, but, as it is a straight link without any form-contained
> > controls, I would expect it to.
> >
> > In fact, I'd be grateful if, instead of getting all hot under the collar
> > about my scandalous use of Microsft products, someone with a different
> > environment could try this and let me know whether it works. If it
doesn't,
> > I'll certainly look at fixing it.
>
> The link works, the page it goes to doen't.  The grid doesn't show in any
of:
>

Oh Shit!

>   Konqueror  - KDE browser
>   Galleon    - Gnome browser (uses Mozilla engine)
>   Mozilla    - 1.6
>   Opera      - the button works fine but grid no show
>
> The page just show the heading graphic plus:
>
> """    You can sort the grid by clicking on any of the headings in it...
>               CLOSE this window to return to our Home Page.
> """

Thanks for that, Richard. Between you and Lueko, I now have something I can
look at fixing. I think I may have to download Firefox just so I can test
the site with at least one non MS browser.

So, as a result of interaction here, I have been persuaded to an alternative
viewpoint <G> CLC CAN work...

Of course I could just take the line of least resistance and require MSIE
6.... (no, just teasing... I'll certainly look at it and see if I can do
better.)

Many thanks to all who accessed, apologies to those who couldn't see
anything, and special thanks to Richard and Leuko for reporting what they
could and could not see.

Pete.
>



0
dashwood1 (2140)
10/14/2004 10:24:52 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410141102.3219aea8@posting.google.com...
> "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote
>
<snip>

>  > BTW, Richard, can you confirm what you posted about the Fujitsu Run
> Time
> > licence?  I'm interested to know where you got that and whether it is,
in
> > fact, the case. I had a look through the documentation for the Version 6
> > licence but I can't find anything that says that. However, I know you
are
> > meticulous in these things so I'd just like it confirmed (or not). Was
it
> > hearsay, or do you have a document?
>
> On the back of the box for version 6 is:
>
> """Free run times
>    The rights to ship our single-user run-time are included
>    with every purchase of Fujitsu COBOL - ... """
>
> The question is: what right do _you_ have to distribute the run-time
> and is that right transferrable.
>

I never had a box. They just mailed me the CD in a jewel case.

It does say "rights to ship" and that is what I have been doing.

> If the run-time was public domain then you, or anyone, can distribute.
>  It isn't, the license (the one they issued to me) is quite clear that
> Fujitsu is only selling the 'right to use' and that all material is
> owned by Fujitsu and protected by Copyright etc.
>

That is certainly a valid interpretation, but I think it is arguable. If I
buy the rights to something (rights to ship) then it doesn't have to be
public domain for me to exercise that right. If one of my clients uses a
component that requires that runtime, then it is a necessary part of what I
have supplied. It comes down to whether "the right to ship" is transferable
and we can agree that from the literature, it doesn't appear to be.

However, I'm not sure whether it would be enforceable (or desirable from
Fujits's point of view, to enforce it). Here's my argument:

The component cannot work without the RTS, so, in order for the component to
be fit for its purpose, it MUST use the RTS.  Fujitsu give us no choice in
this; you cannot compile to Native Code. It can therefore be argued that the
component and its RTS are co-dependent and should be considered as a single
entity. (This is certainly how the user sees it.).  If I assign the rights
to that entity to a third party, then I believe I have done nothing immoral
(even though it might be technically illegal). I can't provide the component
without the RTS, and I cannot legally restrict my customer from
incorporating the component in his own software and distributing it, once he
has bought the rights to it.

I suspect that not too many people are writing COBOL components for use by
others anyway (that was were we came in on this topic) and it is possible
that Fujitsu are aware of the situation but don't take action because it
would be to their detriment to do so. (The few of us who are actually doing
it, would simply move to another language...I don't think any of the COBOL
vendors need to be putting more nails in COBOL's coffin...)


> In fact the license is specific in restricting the rights to a single
> user on a single computer ... for its own internal data processing
> operations.
>
> """Customers may not ... transfer, sell, assign or otherwise convey
> any Program without Fujitsu's prior written consent; ..."""
>

I took that to mean the compiler and ancilliary programs. It never occurred
to me that it might also include the Run Time.

> The only 'prior written consent' that I have for version 6 is that on
> the back of the box which grants that right to the purchaser, but the
> license denies the ability to transfer or assign those rights
> elsewhere. (actually I have other written words for previous
> versions).
>
> If you look at <a
href="http://www.adtools.com/License/index.htm">http://www.adtools.com/Licen
se/index.htm</a>
> you will see where distribution rights are granted, though I am not
> sure if this page constitutes 'prior written agreement' in itself.
>
> You may have completely different licenses and 'prior written words',
> but I interpret what I have seen as meaning that only customers with
> licenses have specific rights to distribute the run-times, and only
> those allowed by the specific license.
>
>
> NOTE: IANAL (I am not a Lawyer, I don't even play one on a TV
> program).
>
Hahaha!  Me neither. I guess I'll reconsider the whole deal. The problem
wouldn't arise with DotNET, of course... This might be a spur to move...

Thanks for the information and links.

Pete.



0
dashwood1 (2140)
10/14/2004 10:50:59 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410141130.998799@posting.google.com...
> "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote
>
> > > See    http://www.mikx.de/scrollbar/
> >
> >  Thanks for the link, I had a look.
>
> Did it 'infect' your machine ?

No. I didn't touch the scrollbar. I DID download the security update.
>
> Has it made you think twice before using _any_ scrollbar ?
>
Not sure... the jury's still out on that one...

Thanks for the link.

Pete.



0
dashwood1 (2140)
10/14/2004 10:57:53 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410141404.5774a045@posting.google.com...
> "Pete Dashwood" <dashwood@nospam.enternet.co.nz> wrote
>
> > My ISP shows that over 95% of access is with IE so that's the one I
cater
> > for and test it with.
>
> Is that visitors or page hits ?

That was based on page hits, so your comment is very pertinent.

They have recently moved to new visitors and returning visitors (based on
cookies), but we can still get page hits also.

Since this thread started it is amazing to see the countries where people
are coming from. Previously we had 100% NZ and Oz. Now we have Canada,
Austria, Switzerland, Germany, France, USA, UK and even Uruguay. (Thanks to
all concerned...now send me some reality checks for next month's edition <G>
Or short pieces of creative writing...)

 >Obviously if a site doesn't work for
> one visitor there will be much fewer hits from him.
>
Yes, that's right.

> Also you shouldn't assume that because a browser identifies as IE that
> it is IE.  Many MS sites give different pages out depending on which
> browser is identified. Opera especially will identify as IE:
>
> """ ----------------------
> Two weeks ago it was revealed that Microsoft's MSN portal targeted
> Opera users, by purposely providing them with a broken page. As a
> reply to MSN's treatment of its users, Opera Software today released a
> very special Bork edition of its Opera 7 for Windows browser. The Bork
> edition behaves differently on one Web site: MSN. Users accessing the
> MSN site will see the page transformed into the language of the famous
> Swedish Chef from the Muppet Show: Bork, Bork, Bork!
>
> In October 2001, Opera users were blocked from the MSN site. The event
> caused an uproar among Web users and MSN was forced to change their
> policy. However, MSN continues a policy of singling out its Opera
> competitor by specifically instructing Opera to hide content from
> users.
>
> "Hergee berger snooger bork," says Mary Lambert, product line manager
> desktop, Opera Software. "This is a joke. However, we are trying to
> make an important point. The MSN site is sending Opera users what
> appear to be intentionally distorted pages. The Bork edition
> illustrates how browsers could also distort content, as the Bork
> edition does. The real point here is that the success of the Web
> depends on software and Web site developers behaving well and rising
> above corporate rivalry."
> --------------- """
>
> More recently:
>
> """ ------------
> Opera declaring itself as Opera got an apparently broken page, but was
> OK if it claimed to be IE. Par for the course? For sure (there's
> always something that is), but we couldn't help noticing that the
> error message arrived after the browser was first fielded to this
> page: http://www.playsforsure.com/MobileDefault.aspx. Now, we're just
> guessing here, but that kind of looks like where a site might be
> putting you if you were accessing it via a mobile phone.
> ---------------- """
>
"Feedy breedy boom boom..." Always LOVED that Swedish chef... <G>

Pete.



0
dashwood1 (2140)
10/14/2004 11:49:53 PM
Peter E.C Dashwood wrote:
> 
> If you scroll down, beneath the radio buttons and the button to activate the
> download,  there is a plain link to "view archives".
> 
> This allows people to view back copies of the newsletter, as well as the
> current edition.
> 
> I don't know, because I have only tested with IE, whether this works for the
> other browsers, but, as it is a straight link without any form-contained
> controls, I would expect it to.
> 
> In fact, I'd be grateful if, instead of getting all hot under the collar
> about my scandalous use of Microsft products, someone with a different
> environment could try this and let me know whether it works. If it doesn't,
> I'll certainly look at fixing it.

It didn't work using Firefox 1.0PR under Linux...


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/15/2004 2:06:19 AM
Peter E.C Dashwood wrote:
> 
> I just don't feel passionate about this one way or the other. MicroSoft have
> never done me any harm, why would I attack them publicly?
> 
> (I confess to some disappointment that the only posts to this thread have
> been from strongly anti-MS people. Maybe I'm the only one still using their
> products... <G>)

I still use their products - I have no choice at work (and our web-based 
configuration management system is heavily reliant on ActiveX controls, 
so I have to use IE for that), and there are still a few things here at 
home (scanning, FJ5) that I haven't been able to make work under Linux 
yet.  However, I run Firefox on both Windows and Linux because of the 
features.

  - Tabbed browsing - instead of having a ton of windows opened up, you 
can open tabs.  As an example, I usually show people either a Google 
search or a list of columnists (such as the one at 
http://www.townhall.com ), and instead of just clicking the link, you 
can go down the list, right-clicking and picking "Open in New Tab". 
Then, go across the tabs, read, close, etc.  When changing to another 
application, I only have to Alt-Tab past 1 instance of that application.

  - Out-of-the-box intelligent popup blocking - The default settings (at 
least the last time I installed it from scratch) block all popups.  But, 
it's smart about it.  If you click a link that opens a new window, that 
still works.  You can tailor it by site.

  - Cookie management - I have it set to prompt me for each cookie that 
is attempted to be stored.  I have three options for each cookie - Deny, 
Accept for Session, and Accept.  There is also a box that will use that 
response for all cookies from that domain.  So, cookie "ASP_SessionID" 
from the domain I'm visiting will probably get an "Accept for Session" 
with the all cookies box checked.  A cookie from 2o7.net will get 
denied.  Once it's trained, it's great - no popups and no hassles.

I'm not particularly worried about security in IE - I've never had any 
trouble with it (although my wife has run afoul of some spyware in the 
past).  I use Firefox for the features.  :)

>>My interest here is whenever I see someone publicly proclaim that he
> 
> doesn't
> 
>>support browsers other than IE, to object.
> 
> 
> Even if the reasons for it are clearly explained, and there is no suggestion
> that IE is superior? Sounds to me like thundering for the sake of
> thundering...

I didn't have a problem with your take on it - especially in light of 
the fact that it's an volunteer effort.  :)  (Some might say I'm biased, 
though...)



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/15/2004 2:16:21 AM
Thanks Daniel.

As this correspondence was originally directed to you, I'd really like you
to see what's there. If you don't have access to MSIE6 at work, please let
me know privately  and I'll arrange a private post for you.

Pete.

"LX-i" <lxi0007@netscape.net> wrote in message
news:NgGbd.50686$VJ2.39473@fe40.usenetserver.com...
> Peter E.C Dashwood wrote:
> >
> > If you scroll down, beneath the radio buttons and the button to activate
the
> > download,  there is a plain link to "view archives".
> >
> > This allows people to view back copies of the newsletter, as well as the
> > current edition.
> >
> > I don't know, because I have only tested with IE, whether this works for
the
> > other browsers, but, as it is a straight link without any form-contained
> > controls, I would expect it to.
> >
> > In fact, I'd be grateful if, instead of getting all hot under the collar
> > about my scandalous use of Microsft products, someone with a different
> > environment could try this and let me know whether it works. If it
doesn't,
> > I'll certainly look at fixing it.
>
> It didn't work using Firefox 1.0PR under Linux...
>
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~   /   \  /         ~        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
dashwood1 (2140)
10/15/2004 5:45:35 AM
LX-i <lxi0007@netscape.net> wrote

>   - Tabbed browsing - instead of having a ton of windows opened up, you 
> can open tabs.  As an example, I usually show people either a Google 
> search or a list of columnists (such as the one at 
> http://www.townhall.com ), and instead of just clicking the link, you 
> can go down the list, right-clicking and picking "Open in New Tab". 

I use 'middle-click' or hold the Ctrl key down and left-click.
0
riplin (4127)
10/15/2004 6:02:04 AM
In article <ckje2f$9ar$1@peabody.colorado.edu>,
 "Howard Brazee" <howard@brazee.net> wrote:

> On 12-Oct-2004, "Peter E.C Dashwood" <dashwood@enternet.co.nz> wrote:
> 
> > This is not meant in the sense of relative worth, Howard. And you are 
> > living
> > in a fool's paradise if you really believe that "other browsers" are 
> > secure.
> > The minute that anything is exposed on the Internet it is subject to risk.
> 
> I agree.  Nor that driving with seatbelts buckled will make me secure on the
> roads.   That said, I wear my seat belt, and I avoid the most dangerous 
> browser.
> 
> > I don't DEMAND anything. And I am not "doing business". (If I was, I'd be
> > paid for my efforts and could therefore afford the time to make the site
> > better.)
> 
> My interest here is whenever I see someone publicly proclaim that he doesn't
> support browsers other than IE, to object.   Hopefully others who have read 
> his
> statement don't decide that this is OK for them as well.    That is my only
> interest in this thread.   It's not about you nor about you web page - it's
> about letting ideas that I disagree with pass uncommented upon.

If one is going to only support a single browser, I think Opera in 
'strict' mode would be a great choice.

If a page works on that, it ought to work on anything.

0
10/15/2004 1:02:17 PM
In article <uakqm099majoevu1sef75qis6obvlro2m2@4ax.com>,
 Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:

> On 13 Oct 2004 00:28:51 -0700, riplin@Azonic.co.nz (Richard) wrote:
> 
> >The main problem with IE is that it is running on, and integrated
> >with, Windows. This means that many of the security problems are
> >_designed_into_ the browser. Some small number of the problems can
> >also occur with other browsers _on_Windows_, and that is because the
> >underlying problem is actually part of Windows.
> 
> True. The current generation of malware doesn't exploit browser
> weakness, for instance buffer overruns, it exploits legit features
> that were created for ease of use. 
> 
> A virus I've been chasing for two days was using WinRAR to re-install
> itself -- the same mechanism Windows Update uses to upgrade
> software. The only thing resident was a hidden shortcut connected to
> the Open Window class.  Download, extraction (installation),
> execution, creation of an Explorer Bar, killing the firewall,  and
> file deletion all occurred behind the scenes, without notification.
> 
> In other words, you can catch a virus by simply opening a Web page ..
> or having a pop-up open it.
> 
> I'm using IE6 with the latest updates. The only way to prevent such an
> attack *with IE* is to run with scripting and Java off
> (Tools\Options\Security\Custom\High), which also stops pop-ups (a Java
> feature). You must then list Yahoo, your online banking and other
> sites requiring Java in Trusted Sites. 

Java will not allow such things.  Your pop-ups would be clearly labeled 
with "Warning: Applet Window" and the default security manager will not 
allow random killing of other processes or file deletion.

(Unless, perhaps, you use one of the 'enhanced' versions of Java...)

Are you sure you aren't confusing Java and JavaScript?  They are totally 
unrelated you know.

0
10/15/2004 1:08:36 PM
On Fri, 15 Oct 2004 09:08:36 -0400, Joe Zitzelberger
<joe_zitzelberger@nospam.com> wrote:

>In article <uakqm099majoevu1sef75qis6obvlro2m2@4ax.com>,
> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>
>> On 13 Oct 2004 00:28:51 -0700, riplin@Azonic.co.nz (Richard) wrote:
>> 
>> >The main problem with IE is that it is running on, and integrated
>> >with, Windows. This means that many of the security problems are
>> >_designed_into_ the browser. Some small number of the problems can
>> >also occur with other browsers _on_Windows_, and that is because the
>> >underlying problem is actually part of Windows.
>> 
>> True. The current generation of malware doesn't exploit browser
>> weakness, for instance buffer overruns, it exploits legit features
>> that were created for ease of use. 
>> 
>> A virus I've been chasing for two days was using WinRAR to re-install
>> itself -- the same mechanism Windows Update uses to upgrade
>> software. The only thing resident was a hidden shortcut connected to
>> the Open Window class.  Download, extraction (installation),
>> execution, creation of an Explorer Bar, killing the firewall,  and
>> file deletion all occurred behind the scenes, without notification.
>> 
>> In other words, you can catch a virus by simply opening a Web page ..
>> or having a pop-up open it.
>> 
>> I'm using IE6 with the latest updates. The only way to prevent such an
>> attack *with IE* is to run with scripting and Java off
>> (Tools\Options\Security\Custom\High), which also stops pop-ups (a Java
>> feature). You must then list Yahoo, your online banking and other
>> sites requiring Java in Trusted Sites. 
>
>Java will not allow such things.  Your pop-ups would be clearly labeled 
>with "Warning: Applet Window" and the default security manager will not 
>allow random killing of other processes or file deletion.
>
>(Unless, perhaps, you use one of the 'enhanced' versions of Java...)
>

Popups are described in Sun's Java 2 Standard Edition here:

http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/Popup.html

Files the applet deletes to cover its tracks were created by it. See:

http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html

You're right about an applet being unable to kill another process. It
does something that causes it to abend, like sending a packet with a
malformed header. 

0
robert6624 (636)
10/15/2004 4:49:03 PM
On 14 Oct 2004 23:02:04 -0700, riplin@Azonic.co.nz (Richard) wrote:

>LX-i <lxi0007@netscape.net> wrote
>
>>   - Tabbed browsing - instead of having a ton of windows opened up, you 
>> can open tabs.  As an example, I usually show people either a Google 
>> search or a list of columnists (such as the one at 
>> http://www.townhall.com ), and instead of just clicking the link, you 
>> can go down the list, right-clicking and picking "Open in New Tab". 
>
>I use 'middle-click' or hold the Ctrl key down and left-click.

IE6 does the same if you hold shift and left-click.
0
robert6624 (636)
10/15/2004 4:49:04 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> >>   - Tabbed browsing - ....

> >I use 'middle-click' or hold the Ctrl key down and left-click.
> 
> IE6 does the same if you hold shift and left-click.

More Wagner factoids - it looks like a fact but isn't.  

IE does not do tabbed browsing so it _cannot_ "do the same".  

Shift left-click opens a new window and annoyingly puts it on top of
what you were looking at while it loads.  Using tabbed browsing avoids
all the annoyances of new windows.  Ctrl-left-click or middle-click
put the linked page in a new tab (in the current window) and leaves it
in background while it loads so that you can select pages to load
while you continue reading and then easily change to those when you
are ready.
0
riplin (4127)
10/15/2004 11:23:00 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> >Java will not allow such things.  Your pop-ups would be clearly labeled 
> >with "Warning: Applet Window" and the default security manager will not 
> >allow random killing of other processes or file deletion.
 
> Popups are described in Sun's Java 2 Standard Edition here:

> Files the applet deletes to cover its tracks were created by it. See:
> 
> http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html

""" --------------
Can applets read or write files?

In Java-enabled browsers, untrusted applets cannot read or write files
at all. By default, downloaded applets are considered untrusted. There
are two ways for an applet to be considered trusted:
  [...]
------------------ """

While you referenced J2SE documentation, this does not mean that
everything in that is possible in Applets.

Once again you are stumbling in areas beyond your actual knowledge.
0
riplin (4127)
10/15/2004 11:41:53 PM
Peter E.C Dashwood wrote:
> Thanks Daniel.
> 
> As this correspondence was originally directed to you, I'd really like you
> to see what's there. If you don't have access to MSIE6 at work, please let
> me know privately  and I'll arrange a private post for you.

Oh, I can get to it - I can just walk a couple of paces to the left and 
sit down at my wife's computer.  :)  I'll look into it tonight - this 
has been an absolutely crazy week at work.  We deployed our 3 1/2 year 
project a few weeks ago, and our 4 or 5 test bases have found lots of 
seams we missed here!

(You know, no matter how clean your COBOL code is, how many advanced 
techniques you use, or whatever - if the code's logically wrong, it 
doesn't work!  Imagine that...)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/16/2004 1:06:54 AM
Richard wrote:
> LX-i <lxi0007@netscape.net> wrote
> 
> 
>>  - Tabbed browsing - instead of having a ton of windows opened up, you 
>>can open tabs.  As an example, I usually show people either a Google 
>>search or a list of columnists (such as the one at 
>>http://www.townhall.com ), and instead of just clicking the link, you 
>>can go down the list, right-clicking and picking "Open in New Tab". 
> 
> 
> I use 'middle-click' or hold the Ctrl key down and left-click.

[clicking Firefox shortcut on taskbar]

[typing "web log" into the Google quick-search box]

[holding down the Ctrl key and clicking on the first result]

Well - how bout that!  :)  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)
10/16/2004 1:08:39 AM
Robert Wagner wrote:
> On 14 Oct 2004 23:02:04 -0700, riplin@Azonic.co.nz (Richard) wrote:
> 
> 
>>LX-i <lxi0007@netscape.net> wrote
>>
>>
>>>  - Tabbed browsing - instead of having a ton of windows opened up, you 
>>>can open tabs.  As an example, I usually show people either a Google 
>>>search or a list of columnists (such as the one at 
>>>http://www.townhall.com ), and instead of just clicking the link, you 
>>>can go down the list, right-clicking and picking "Open in New Tab". 
>>
>>I use 'middle-click' or hold the Ctrl key down and left-click.
> 
> 
> IE6 does the same if you hold shift and left-click.

IE6 opens a tab in the same window?  :)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/16/2004 1:28:08 AM
On 15 Oct 2004 16:41:53 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Can applets read or write files?
>
>In Java-enabled browsers, untrusted applets cannot read or write files
>at all. By default, downloaded applets are considered untrusted. There
>are two ways for an applet to be considered trusted:

1. It's running on the development machine (sandbox) 
2. It presents a valid authentication certificate. 

My virus contains a certificate referencing Thwaite, CAPE TOWN1. 

An untrusted applet can acccess files two other ways:

3. By calling a trusted applet .. on an older JRE.
4. By invoking a non-Java service. 

My virus uses WinRAR (Microsoft's PKZip) to install files. The system
log contains repeated entries reading (in reverse chronological
order):

The Event log was started.
Microsoft (R) Windows 2000 (R) 5.0 2195 Service Pack 4 Uniprocessor
Free. 
The Event log was stopped.

I did not install SP4 multiple times. Something is spoofing it.



0
robert6624 (636)
10/16/2004 10:41:47 PM
In article <nfsvm0t2mib3jmfg3nmnpbfa11gtqb0oae@4ax.com>,
 Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:

> On Fri, 15 Oct 2004 09:08:36 -0400, Joe Zitzelberger
> <joe_zitzelberger@nospam.com> wrote:
> 
> >In article <uakqm099majoevu1sef75qis6obvlro2m2@4ax.com>,
> > Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
> >
> >> On 13 Oct 2004 00:28:51 -0700, riplin@Azonic.co.nz (Richard) wrote:
> >> 
> >> >The main problem with IE is that it is running on, and integrated
> >> >with, Windows. This means that many of the security problems are
> >> >_designed_into_ the browser. Some small number of the problems can
> >> >also occur with other browsers _on_Windows_, and that is because the
> >> >underlying problem is actually part of Windows.
> >> 
> >> True. The current generation of malware doesn't exploit browser
> >> weakness, for instance buffer overruns, it exploits legit features
> >> that were created for ease of use. 
> >> 
> >> A virus I've been chasing for two days was using WinRAR to re-install
> >> itself -- the same mechanism Windows Update uses to upgrade
> >> software. The only thing resident was a hidden shortcut connected to
> >> the Open Window class.  Download, extraction (installation),
> >> execution, creation of an Explorer Bar, killing the firewall,  and
> >> file deletion all occurred behind the scenes, without notification.
> >> 
> >> In other words, you can catch a virus by simply opening a Web page ..
> >> or having a pop-up open it.
> >> 
> >> I'm using IE6 with the latest updates. The only way to prevent such an
> >> attack *with IE* is to run with scripting and Java off
> >> (Tools\Options\Security\Custom\High), which also stops pop-ups (a Java
> >> feature). You must then list Yahoo, your online banking and other
> >> sites requiring Java in Trusted Sites. 
> >
> >Java will not allow such things.  Your pop-ups would be clearly labeled 
> >with "Warning: Applet Window" and the default security manager will not 
> >allow random killing of other processes or file deletion.
> >
> >(Unless, perhaps, you use one of the 'enhanced' versions of Java...)
> >
> 
> Popups are described in Sun's Java 2 Standard Edition here:
> 
> http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/Popup.html
> 
> Files the applet deletes to cover its tracks were created by it. See:
> 
> http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html
> 
> You're right about an applet being unable to kill another process. It
> does something that causes it to abend, like sending a packet with a
> malformed header. 
> 

For details on the default SecurityManager, see:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/SecurityManager.html

In an applet context -- that is, running via a browser -- the Popup 
window will be clearly labeled.

File access will be strictly limited and user prompting will occur -- 
e.g. a dialog that says "applet so and so wants to delete 
"C:\WIN32\KERNEL.EXE".  Allow?  Ok  Cancel"

Network access can be limited to the host when the applet was loaded 
from, but more likely it is wide open.  So a malformed packet would kill 
a process.  But a process that would die from receipt of such a packet 
might just be too stupid to live...

0
10/17/2004 2:11:10 AM
In article <drm2n01m1n293f7n165n7vhiaoa7b7csrn@4ax.com>,
 Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:

> 4. By invoking a non-Java service. 

This is interesting...how is the applet doing this thing.  Where, and 
how, is the non-Java service being loaded?

Are you really sure you are not using the special 'enhanced' JVM from 
Micro$oft?

0
10/17/2004 2:11:11 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> 2. It presents a valid authentication certificate. 
> 
> My virus contains a certificate referencing Thwaite, CAPE TOWN1. 
> 
> An untrusted applet can acccess files two other ways:
> 
> 3. By calling a trusted applet .. on an older JRE.
> 4. By invoking a non-Java service. 

Are these 'features' specific to IE and MS's JRE ? they won't do that
on my system.

> My virus uses WinRAR (Microsoft's PKZip) to install files. The system
> log contains repeated entries reading (in reverse chronological
> order):
> 
> The Event log was started.
> Microsoft (R) Windows 2000 (R) 5.0 2195 Service Pack 4 Uniprocessor
> Free. 
> The Event log was stopped.
> 
> I did not install SP4 multiple times. Something is spoofing it.

You are just reinforcing my view that Windows and IE are something to
avoided completely.
0
riplin (4127)
10/17/2004 6:13:27 AM
..    Am  11.10.04
schrieb  riplin@Azonic.co.nz (Richard)
    auf  /COMP/LANG/COBOL
     in  217e491a.0410111037.1094ca7@posting.google.com
  ueber  Re: Display enhancements (was: OFF Topic)

>> PD> There are so many attributes for screens and printers
>>
>>    Four of them would be sufficient:
>>
>>    - Font family name, e.g. "Arial", "Times Roman", "OCR B"
>>    - Font size in typographic points
>>    - One of the four font variants
>>       (how does one say that in English? Font decoration?):
>>       normal, bold, italic, bold-italic which are provided by the
>>         basic rendering systems in e.g. Windows, Postscript etc.
>>    - Colour

r> I've never liked building the external characteristics into the
r> program code.

  COBOLs solution for this has been the REPORT WRITER, and for many  
decades already. Unfortunately not implemented in every compiler.

  Data extraction and preparation is strictly separated from  
presentation.


r> There may be times when the actual positioning, font,
r> etc is firmly fixed and unchangable, but then the user will want it
r> changed.

   Changing that could be easy using REPORT WRITER

   Unfortunately the LINAGE, PAGE, LINE and COLUMN clauses demand  
numeric literals instead of data names. In the latter case,  
positioning on the page and character types could be read in from some  
parameter file.

r> I consider that all output should be templated.  If I need
r> such fine control as you suggest then it is relatively easy to draw a
r> postscript template and merge the data items into it.

   Well, not every printer is Postscript capable.

r> The same with printed reports, forms, EDI files, XML files, EMails.
r> Have the program write the data to a template and neither know nor
r> care what the final result is.

   I remember having read in this newsgroup, probably by you, about  
how to do it. Could you tell me (us) more about it go get a practical  
idea on how to do it?


r> In some cases in my systems there is even a two stage process.  The
r> program writes out using a template which is actually formatting to a
r> file which is a merge data file for a proprietry form output program.

   I don't like such two stage processes. If I have to use a second  
program to do the actual printing, I do not need the COBOL program in  
the first place. There are quite successful products on the market  
like Crystal Reports and similar, also components for developers using  
Delphi e.g.

   If this two-stage process means changes in the database, like when  
I produce invoices, store the invoide data in the database, and then  
call another program to print these invoice data out, I would agree.  
In such a case I definitely prefer such a two stage process.


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)
10/18/2004 2:50:00 PM
l.willms@jpberlin.de (Lueko Willms) wrote 

>   COBOLs solution for this has been the REPORT WRITER, and for many  
> decades already. Unfortunately not implemented in every compiler.
> 
>   Data extraction and preparation is strictly separated from  
> presentation.

They are both still in the program code.  Any change requires recoding
and recompiling.  In my systems if the user chooses a matrix printer
they get the report in 10cpi on fanfold, if they choose to print to a
laser they get landscape A4 at 16.67cpi.
 
>    Changing that could be easy using REPORT WRITER
> 
>    Unfortunately the LINAGE, PAGE, LINE and COLUMN clauses demand  
> numeric literals instead of data names. In the latter case,  
> positioning on the page and character types could be read in from some  
> parameter file.

Well, exactly.

> r> I consider that all output should be templated.  If I need
> r> such fine control as you suggest then it is relatively easy to draw a
> r> postscript template and merge the data items into it.
> 
>    Well, not every printer is Postscript capable.

On Linux they are, even 1980s matrix printers. If you use CUPS +
Ghostscript then Postscript is/can be used for each printer. Of course
it can be overridden so that raw text or PCL can be used instead.

But templating doesn't require it to be Postscript, that is probably
an extreme case.  Simple text templating can be quite effective, the
template can specify control codes, or pseudo control codes that get
substituted depending on the particular printer being used.

The program just builds a block of data and calls the template
program.
 
> r> The same with printed reports, forms, EDI files, XML files, EMails.
> r> Have the program write the data to a template and neither know nor
> r> care what the final result is.
> 
>    I remember having read in this newsgroup, probably by you, about  
> how to do it. Could you tell me (us) more about it go get a practical  
> idea on how to do it?

Templating is relatively easy to do, I have done it several ways in
several languages: C, Cobol, PERL, Python, Java. Some using supplied
libraries. I have also used forms programs similar to (but not
actually those) FormPrint and PwerForm.

Start with the required output.  For example it may, say, a picking
slip for the warehouse: (this is simplified and abstracted)

best viewed in fixed font

*SECTION HEADING
+---------------------------------------------------------+
| DEMONSTRATION COMPANY WAREHOUSE            PICKING SLIP |
+------------------------------+--------------------------+
|  Deliver To:                 | OrderNo:   %ORDERNO%     |
|  %DELVNAME%                  | Dated:     %DATE%        |       
|  %DELVADD1%                  | Required:  %REQUIRED%    |
|  %DELVADD2%                  | Transport: %TRANSPORT%   | 
|  %DELVADD3%                  | %INSTRUCT%               |
+------------------------------+--------------------------+ 
|Location Product   Description           Quantity Picked |
*SECTION LINE
|%LOCATN% %PRODUCT% %DESCRIPTION%         %QUANITY% |     |
*SECTION TRAILER
+---------------------------------------------------------+
| Weight:  %WEIGHT%           Total Units %TOTALQTY%      |
| Picked By:__________________                            |
| Checked By:_________________                            |
| Shipped By:_________________                            |
+---------------------------------------------------------+
*END

The program wanting to print would set up an interface area with:
   The template name which may be different for each company.
   The section name (HEADING, LINE, etc
   The function code (Open, Close, Print section, etc)
   An array of data items containg name, length, text:
        "DELVNAME"  36  "The Shop on the Corner"
        "DELNADD1"  36  "41 The High Street"
        "DELVADD2"  36  "Newton" 
        ...
        "ORDERNO"   6   "412356"
        "DATED"     9   "20 OCT 04"  
        ...
        "LOCATN"    8   "A4123"
        "PRODUCT"   12  "TX7613-A"
        "QUANTITY"  6   "     3"
    
The template program would then be CALLed to Open, Print HEADING,
Print LINE for each product line (changing items each time), Print
TRAILER and Close.

The template printing program neither knows nor cares whet the
template is nor what the data names are.

On Open: it opens the specified text file and reads it into an array
of lines and builds a table of SECTION start points.

On Print Section: it locates the section start an end and processes
those lines by: moving the line from the array to the processing area,
then stepping along looking for '%' (or whatever tag you choose).  It
picks up the characters up to the next % into a 'name' field and
blanks out the tag.  It looks for the matching name in the array
supplied and if found it moves the characters to the processing line
starting at where first % was found and stopping when a non-blank is
found (don't overwrite fixed text) or the length expires.  It keeps
doing this until the end of the line which is then sent to the printer
(or file or display or whereever).

Ob Close: throw page (if printer) and close files.

There should be just one template processing program that handles all
templates so it usually gets more sophisticated to cater for more
needs.  The program that is calling the templating just fills the
array with data items that may be wanted and doesn't care if they are
not used.

One variation is whether the data is fixed position (as here) or
variable. For example if the output is to an HTML page then the
substitution needs to be dome by chopping and refixing the parts back
together:

*SECTION HEADING
<html><head> ... </head><body>
<center>
<table border="1"><caption>PICKING SLIP</caption>
<tr><th rowspan="5" valign="top">Delivery:</th><td>%DELVNAME%</td></tr>
<tr>                                          
<td>%DELVADD1%</td></tr>
[...]
<tr><th>Order Number</th><td>%ORDERNO%</td></tr>
[...]
</table>
<table border="1">
<tr><th>Location</th><th>Product</th><th>Quantity</th></tr>
*SECTION LINE
<tr><td>%LOCATN%</td><td>%PRODUCT%</td><td> ...
*SECTION TRAILER
</table> ...
</center>
</body></html>
 
The CALLing program neither knows nor cares that this is a web page
and not a printed form, nor does the template program, it is just a
text file. In this case being sent to standard output.  A *FIXED or
*PACK line should set the actual method of substituting.  A *OUTPUT
could control where it goes.

>    I don't like such two stage processes. If I have to use a second  
> program ...

It is only 'two stage' in that one program writes an intermediate file
and then activates (CALL "SYSTEM" USING ...) another process.  This is
transparent to the user.
 
>    If this two-stage process means changes in the database, like when  
> I produce invoices, store the invoide data in the database, and then  
> call another program to print these invoice data out, I would agree.  
> In such a case I definitely prefer such a two stage process.

Exactly.
0
riplin (4127)
10/18/2004 10:55:02 PM
..     Am  18.10.04
 schrieb  riplin@Azonic.co.nz (Richard)
     bei  /COMP/LANG/COBOL
      in  217e491a.0410181455.6cfd721b@posting.google.com
   ueber  Re: Display enhancements

r> The program wanting to print would set up an interface area with:
r>    The template name which may be different for each company.
r>    The section name (HEADING, LINE, etc
r>    The function code (Open, Close, Print section, etc)
r>    An array of data items containg name, length, text:
r>         "DELVNAME"  36  "The Shop on the Corner"
r>         "DELNADD1"  36  "41 The High Street"
r>         "DELVADD2"  36  "Newton"
r>         ...
r>         "ORDERNO"   6   "412356"
r>         "DATED"     9   "20 OCT 04"
r>         ...
r>         "LOCATN"    8   "A4123"
r>         "PRODUCT"   12  "TX7613-A"
r>         "QUANTITY"  6   "     3"
r>
r> The template program would then be CALLed to Open, Print HEADING,
r> Print LINE for each product line (changing items each time), Print
r> TRAILER and Close.

   Well, this can be done easily with COBOL's REPORT WRITER --  
producing all the data with control headings and footings into a  
temporary file, and leaving the actual printing to an external program  
which merges the data with some template indicating the presentation?!

   Why should the data extraction logic care about headers and footers  
in procedural statements when these can be generated automatically by  
the REPORT WRITER?

   But nonetheless, I would like to see in the COBOL standard -- or in  
the COBOL compiler which I use -- means to enhance the presentation of  
a printout produced with the REPORT WRITER, i.e. indicating print  
positions by the millimeter, and specifying fonts.

   I am looking into COBOL just because of features like the REPORT  
WRITER, because the printing program of the data base system which I  
use for many years does not provide more then one control grops and  
not both control headings and control footings, but only either one of  
those. But I can position any element at run time, and change fonts.


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)
10/19/2004 2:50:00 PM
l.willms@jpberlin.de (Lueko Willms) wrote

>    Well, this can be done easily with COBOL's REPORT WRITER --  
> producing all the data with control headings and footings into a  

If you are producing batch processing lineflow reports with levels of
totalling and page breaks then that may be the right tool for the job.

>    Why should the data extraction logic care about headers and footers  
> in procedural statements when these can be generated automatically by  
> the REPORT WRITER?

You see things one way, I see them another.  To a hammer all problems
look like nails.  Perhaps you always look to solve problems by how you
can plug them into the various parts of RW.

>    But nonetheless, I would like to see in the COBOL standard -- or in  
> the COBOL compiler which I use -- means to enhance the presentation of  
> a printout produced with the REPORT WRITER, i.e. indicating print  
> positions by the millimeter, and specifying fonts.

While I would never want to do that, my programs neither know nor care
where stuff appears on the paper, that is controlled by the user
(though I do make up the templates for them), not the programmer.
 
>    I am looking into COBOL just because of features like the REPORT  
> WRITER, because the printing program of the data base system which I  
> use for many years does not provide more then one control grops and  
> not both control headings and control footings, but only either one of  
> those. But I can position any element at run time, and change fonts.

Many years ago I wrote my own system for printing lineflow reports. 
This works by having a standard interface which is filled by many
simple file readers, the report is controlled by a dictionary for the
files and a simple text script that specifies the selection criteria,
control breaks, print layout (or html, csv, etc layout).  The user can
set up their own reports if they wish.  Not as sophisticated as
Crystal Reports, but it does the job (and has for a couple of
decades).
0
riplin (4127)
10/19/2004 6:33:38 PM
Richard,

You referenced Crystal Reports. While Lueko sites
places he can visualize how to use such an extension.

 From my perspective, there is no connection at all as
items of extension have a way of finding homes
unexpected. Secondly, enhancing the ability of Cobol is
to provide more than just an extension, there is the
desire to place the whole solution in one description.
There are bound to be some existing products that are
in some way impacted. That's not the business of Cobol.
Extensions to Cobol reflect the learning curve of
all user needs. Cobol should not be restricted in development
to avoid tools that were built to fill needs not met.
I think of it as a new model. Sort of like a new auto year.
Some things are widely accepted, while others prove
unnecessary in the market place. However, the Cobol market
place is not designed to assist the growth of other options,
but to centralize them for better documentation and standardization.


It seems to me  that in c.l.Cobol users not vendors should propose
extensions regardless of existing means elsewhere. I'd
call it getting with the program.

Of course the above views are just mine. To each his own.

Warren Simmons


Richard wrote:
> l.willms@jpberlin.de (Lueko Willms) wrote
> 
> 
>>   Well, this can be done easily with COBOL's REPORT WRITER --  
>>producing all the data with control headings and footings into a  
> 
> 
> If you are producing batch processing lineflow reports with levels of
> totalling and page breaks then that may be the right tool for the job.
> 
> 
>>   Why should the data extraction logic care about headers and footers  
>>in procedural statements when these can be generated automatically by  
>>the REPORT WRITER?
> 
> 
> You see things one way, I see them another.  To a hammer all problems
> look like nails.  Perhaps you always look to solve problems by how you
> can plug them into the various parts of RW.
> 
> 
>>   But nonetheless, I would like to see in the COBOL standard -- or in  
>>the COBOL compiler which I use -- means to enhance the presentation of  
>>a printout produced with the REPORT WRITER, i.e. indicating print  
>>positions by the millimeter, and specifying fonts.
> 
> 
> While I would never want to do that, my programs neither know nor care
> where stuff appears on the paper, that is controlled by the user
> (though I do make up the templates for them), not the programmer.
>  
> 
>>   I am looking into COBOL just because of features like the REPORT  
>>WRITER, because the printing program of the data base system which I  
>>use for many years does not provide more then one control grops and  
>>not both control headings and control footings, but only either one of  
>>those. But I can position any element at run time, and change fonts.
> 
> 
> Many years ago I wrote my own system for printing lineflow reports. 
> This works by having a standard interface which is filled by many
> simple file readers, the report is controlled by a dictionary for the
> files and a simple text script that specifies the selection criteria,
> control breaks, print layout (or html, csv, etc layout).  The user can
> set up their own reports if they wish.  Not as sophisticated as
> Crystal Reports, but it does the job (and has for a couple of
> decades).
0
wsimmons5 (172)
10/19/2004 9:16:11 PM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message 
news:9J938HKPflB@jpberlin-l.willms.jpberlin.de...
<snip>
>
>   But nonetheless, I would like to see in the COBOL standard -- or in
> the COBOL compiler which I use -- means to enhance the presentation of
> a printout produced with the REPORT WRITER, i.e. indicating print
> positions by the millimeter, and specifying fonts.
>

Depending upon the OS and compiler that you are using, this may already be 
available.  Check out the STYLE clause available with the SPC "report writer 
add-on" available for several compilers (and operating systems).  Go to:

http://www.spc-systems.com/

Select the "Tutorial and Reference" section, then the "Report Group 
Descriptions" and then search on the "STYLE clause".

You may also want to check out the "Independent Report File Handlers" section of 
the "Special Topics" portion.


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


0
wmklein (2605)
10/19/2004 10:48:03 PM
On 18-Oct-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

>   COBOLs solution for this has been the REPORT WRITER, and for many
> decades already. Unfortunately not implemented in every compiler.

I don't think this is what we want.

Even in the old days, REPORT WRITER made things about twice as easy to write
reports as without it.   Twice as easy wasn't sufficient.

But what we want (in Mainframe land) nowadays is to have a mainframe CoBOL
program to create a report which the users can view on their PC and then decide
to print on their printers set up the way they want, and in the format they
want.    PC CoBOL has this same requirement - unless each computer has its
separately compiled copy of the main program REPORT WRITER doesn't do enough.

Often I create files that are read in by a PC spreadsheet or database.    The
users have the expertise to do whatever they want from that stage.

When one office wants to change its report, the program doesn't have to be
changed and tested by all offices.
0
howard (6283)
10/20/2004 2:03:49 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:cl5r85$ate$1@peabody.colorado.edu...
[snip]
> Even in the old days, REPORT WRITER made things about twice as easy to
write
> reports as without it.   Twice as easy wasn't sufficient.
[snip]
> Often I create files that are read in by a PC spreadsheet or database.
The
> users have the expertise to do whatever they want from that stage.

Mr Brazee, have you tried creating files using Report Writer
without the PAGE clause?

After loading some data into 'item.dat', I ran the following
program to create 'item.lst'. I then loaded the list file into
both Microsoft Excel and Microsoft Access.

Seems to work OK.
--------
       identification division.
       program-id. rpt-test.
       environment division.
       input-output section.
       file-control.
           select item-file assign to "item.dat"
               organization is indexed
               access is sequential
               record key is item-id.
           select item-list assign to "item.lst"
               organization is line sequential.
       data division.
       file section.
       fd item-file.
       01 item-record.
         05 item-id pic x(6).
         05 item-description pic x(30).
         05 item-price packed-decimal pic s9(5)v99.
       fd item-list
           report is item-report.
       01 item-list-record pic x(45).
       report section.
       rd item-report.
       01 item-detail type is detail line number is plus 1.
         05 column  1 pic x(6) source is item-id.
         05 column  7 pic x(30) source is item-description.
         05 column 37 pic +9(5).99 source is item-price.
       procedure division.
       begin.
           open input item-file
           open output item-list
           initiate item-report
           perform until exit
               read item-file
                   at end exit perform
               end-read
               generate item-detail
           end-perform
           terminate item-report
           close item-list
           close item-file
           stop run
       end program rpt-test.
-----



0
ricksmith (875)
10/20/2004 9:19:55 PM
..    On  20.10.04
  wrote  ricksmith@mfi.net (Rick Smith)
     on  /COMP/LANG/COBOL
     in  10ndln2mem78r97@corp.supernews.com
  about  Re: Report enhancements


RS>        rd item-report.
RS>        01 item-detail type is detail line number is plus 1.
RS>          05 column  1 pic x(6) source is item-id.
RS>          05 column  7 pic x(30) source is item-description.
RS>          05 column 37 pic +9(5).99 source is item-price.

   one might add alternative CSV forms:

           01 item-CSV type is detail line number is plus 1.
              05 column  1 pic x(6) source is item-id.
              05 col plus 1 pic x value ",".
              05 col plus 1 pic x(30) source is item-description.
              05 col plus 1 pic x value ",".
              05 col plus 1 pic +9(5).99 source is item-price.

           01 item-generic-CSV type is detail line number is plus 1.
              05 column  1 pic x(6) source is item-id.
              05 col plus 1 pic x source unit-separator.
              05 col plus 1 pic value '"'.
              05 col plus 1 pic x(30) source is item-description.
              05 col plus 1 pic value '"'.
              05 col plus 1 pic x source unit-separator.
              05 col plus 1 pic +9(5).99 source is item-price.


RS>        procedure division.
RS>        begin.
RS>            open input item-file
RS>            open output item-list
               accept unit-separator
RS>            initiate item-report
RS>            perform until exit
RS>                read item-file
RS>                    at end exit perform
RS>                end-read
                   IF is-wanted-CSV
                   THEN
                      generate item-CSV
                   ELSE
                      generate item-detail
                   END-IF
RS>            end-perform



    BTW, I prefer the file-input loop this way:

    OPEN INPUT input-file
    READ input-file
    IF has-reached-EOF in status-input-file
    THEN
      DISPLAY "input-file is empty"
    ELSE
      PERFORM WITH TEST AFTER
        UNTIL has-reached-EOF in status-input-file
        *> do something useful with the input record
        *>  whose presence is asserted here
        READ input-file
      END-PERFORM
    END-IF


    You see, I don't like the "AT END" phrase, because the information  
is already in the FILE STATUS. And since the COBOL file system  
requires one more READ attempt than there are RECORDs in the file, I  
prefer to use the additional READ to test if any RECORDs are in the  
file in the first place.

    In case there is some DECLARATIVES procedure for this file, the  
READ needs to be expanded, to avoid that this contingency procedure is  
executed when reaching EOF:

    READ input-file
      AT END CONTINUE
    END-READ


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

Belehrung findet man �fter in der Welt als Trost.  -G.C.Lichtenberg
0
l.willms1 (637)
10/21/2004 9:33:00 AM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9JHJrpiuflB@jpberlin-l.willms.jpberlin.de...
> .    On  20.10.04
>   wrote  ricksmith@mfi.net (Rick Smith)
>      on  /COMP/LANG/COBOL
>      in  10ndln2mem78r97@corp.supernews.com
>   about  Re: Report enhancements
[snip]
>    one might add alternative CSV forms:

Having multiple formats may require different record
lengths in the FD, which suggests variable length records;
or it may require a 'dummy' field for the shorter formats.
Have you tried it?

>     BTW, I prefer the file-input loop this way:

As I have become fond of saying, "There is no *the* way."

Here is code for tab-delimited text files with Micro Focus.

I changed the file suffix to .txt, which Excel and Access
more easily recognize and I changed the file organization to
sequential, so that tabs will not have a leading nul character.
Also, Report Writer, in this case, adds the record separator,
carriage return + line feed, for what is nominally a record
secquential file.

This importing of the file is easier.
-----
       identification division.
       program-id. rpt-test.
       environment division.
       configuration section.
       special-names.
           symbolic characters
               separator-tab is 10.
       input-output section.
       file-control.
           select item-file assign to "item.dat"
               organization is indexed
               access is sequential
               record key is item-id.
           select item-list assign to "item.txt"
               organization is sequential.
       data division.
       file section.
       fd item-file.
       01 item-record.
         05 item-id pic x(6).
         05 item-description pic x(30).
         05 item-price packed-decimal pic s9(5)v99.
       fd item-list
           report is item-report.
       01 item-list-record pic x(47).
       report section.
       rd item-report.
       01 item-detail type is detail line number is plus 1.
         05 column  1 pic x(6) source is item-id.
         05 column  7 pic x value is separator-tab.
         05 column  8 pic x(30) source is item-description.
         05 column 38 pic x value is separator-tab.
         05 column 39 pic +9(5).99 source is item-price.
       procedure division.
       begin.
           open input item-file
           open output item-list
           initiate item-report
           perform until exit
               read item-file
                   at end exit perform
               end-read
               generate item-detail
           end-perform
           terminate item-report
           close item-list
           close item-file
           stop run
       end program rpt-test.
-----



0
ricksmith (875)
10/21/2004 12:06:01 PM
On 20-Oct-2004, "Rick Smith" <ricksmith@mfi.net> wrote:

> Mr Brazee, have you tried creating files using Report Writer
> without the PAGE clause?

No.   When I go to a shop that doesn't use Report Writer, I don't even think of
using it.   And I haven't been at a Report Writer shop in 8 years.

It is an interesting idea though, I will save it, thanks.
0
howard (6283)
10/21/2004 2:49:39 PM
..    On  20.10.04
  wrote  howard@brazee.net (Howard Brazee)
     on  /COMP/LANG/COBOL
     in  cl5r85$ate$1@peabody.colorado.edu
  about  Report enhancements


>>   COBOLs solution for this has been the REPORT WRITER, and for many
>> decades already. Unfortunately not implemented in every compiler.

HB> I don't think this is what we want.

   Maybe, but it is what I would offer, albeit with some changes...


HB> Even in the old days, REPORT WRITER made things about twice as easy
HB> to write reports as without it.   Twice as easy wasn't sufficient.

   I guess there was no way to do it even easier...


HB> But what we want (in Mainframe land) nowadays is to have a mainframe
HB> CoBOL program to create a report which the users can view on their PC
HB> and then decide to print on their printers set up the way they want,
HB> and in the format they want.    PC CoBOL has this same requirement -
HB> unless each computer has its separately compiled copy of the main
HB> program REPORT WRITER doesn't do enough.

   The solution is an HTML or XML document, or a CSV file.

   So why not specifying the type of output in the RD, i.e. REPORT  
DESCRIPTION? Or do that even dynamically?

   The idea came when I looked at the code examples from CobolScript  
(http://www.cobolscript.com), where HTML tags are embedded literally  
in the string being DISPLAYed, like this:

000097  PERFORM VARYING counter FROM 1 BY 1 UNTIL counter > 8
000098    DISPLAY `<TR BGCOLOR="lightblue">`
000099    DISPLAY `<TD>TCPIP-HOSTENT-ADDRESS(`  &  counter  &  `): </TD>`
000100    DISPLAY `<TD>`  &  TCPIP-HOSTENT-ADDRESS(counter)  &  ` </TD>`
000101    DISPLAY `</TR>`
000102  END-PERFORM.

   Why not telling the compiler, or the run-time system that I want to  
have a HTML document, which would then result in prefixing every  
DETAIL group with a '<LI>', and generating an HTML table with  
'<TABLE>', '<TR></TR>', and <TD></TD>' tags, when the COBOL definition  
is subject to an OCCURS clause? Why should the source program care  
about such details as those tags? Leave that to the compiler and run- 
time system, and avoid errors.

   And why not leaving it to the compiler and run-time sytem to insert  
unit-separators between items and line-separators (LF, CR, or LF/CR)  
when I want to create a CSV file?

   This is the direction which I would like the next standad to  
enhance the REPORT WRITER. I have not yet had a look into the  
standardizing work on XML, though.

HB> Often I create files that are read in by a PC spreadsheet or
HB> database.    The users have the expertise to do whatever they want
HB> from that stage.

   Sure, so let's make it easier to create such an output using COBOL.


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

Seine B�cher waren alle sehr nett, sie hatten auch sonst wenig zu tun. -G.C.Lichtenberg
0
l.willms1 (637)
10/21/2004 4:30:00 PM
..    On  21.10.04
  wrote  ricksmith@mfi.net (Rick Smith)
     on  /COMP/LANG/COBOL
     in  10nf9km25av146a@corp.supernews.com
  about  Re: Report enhancements


LW>>    one might add alternative CSV forms:

RS> Having multiple formats may require different record
RS> lengths in the FD, which suggests variable length records;
RS> or it may require a 'dummy' field for the shorter formats.
RS> Have you tried it?

  No. As you say, this would require the definition of a variable  
length record(s) in the FD.


>>     BTW, I prefer the file-input loop this way:

RS> As I have become fond of saying, "There is no *the* way."

  Sure, there are many ways to advance, but, please excuse me, I still  
consider my way to be the best. :-))  Why? Because the additional READ  
and check for EOF-status serves an extra purpose, i.e. check if the  
input file is empty, and thus is outside of the loop which is entered  
only the same number of times as there are records available, not once  
more. Concretely, when there are 1000 records in the input-file, the  
loop processing those records and trying to get the next one is only  
entered 1000 times.

  BTW, this is different in a language like PASCAL, where the EOF- 
status is raised by a "read-ahead" even with a successful READ and by  
the OPEN (actually, a "Reset(filename)").

  The additional READ necessary in COBOL to find EOF is treated in my  
design as READ number 0 (zero), outside of the loop. The block of  
statements being executed as the loop is not interupted by checks for  
the status of the input-file. Anybody may do it as she or he pleases,  
but I think that my approach most accurately reflects the actual  
structure of the data object, i.e. the file.

   Let me add how opening the output file and similar tasks are only  
performed when there is data in the input file, and how to deal with  
an OPTIONAL file (assuming that all permanent errors on the files are  
treating by a contignecy routine supplied by the run-time system):

--------- schnipp -----------------------------------------
    OPEN INPUT input-file
    IF is-not-present-file in status-input-file
    THEN                                  *> minor filestat = '5'
      DISPLAY "input-file is not present"
    ELSE
      READ input-file
      IF has-reached-EOF in status-input-file
      THEN                                *> Major filestat = '1'
        DISPLAY "input-file is empty"
      ELSE
        OPEN OUTPUT output-file
        INITIATE output-report
        PERFORM WITH TEST AFTER
          UNTIL has-reached-EOF in status-input-file
          *> do something useful with the input record
          *>  whose presence is asserted here
          GENERATE report-detail-item
          READ input-file
        END-PERFORM
        TERMINATE output-report
        CLOSE output-file
      END-IF
    END-IF
    CLOSE input-file
    STOP RUN
    .
------------------ schnapp --------------------------------

    Coming back to your report-writer program: one can insert a line  
at the top with the column names, which can be used by importing PC  
programs, without any change in the PROCEDURE DIVISION, just by adding  
one REPORT group TYPE REPORT HEADING:


--------- schnipp -----------------------------------------
       fd item-list
           report is item-report.
       01 item-list-record pic x(47).
       report section.

       rd item-report.

       01 identification-line TYPE REPORT HEADING line plus 1.
          02 COLUMN 1 PIC X(7) VALUE "item-id".
          02 col plus 1 pic x value is separator-tab.
          02 COL PLUS 1 PIC X(16) VALUE "item-description".
          02 col plus 1 pic x value is separator-tab.
          02 COL PLUS 1 PIC X(10) VALUE "item-price".

       01 item-detail type is detail line number is plus 1.
         05 column  1 pic x(6) source is item-id.
         05 column  7 pic x value is separator-tab.
         05 column  8 pic x(30) source is item-description.
         05 column 38 pic x value is separator-tab.
         05 column 39 pic +9(5).99 source is item-price.

       procedure division.
       begin.

------------------ schnapp --------------------------------


    Thinking about these issues, the idea occured me, that the COBOL  
REPORT WRITER should be enhanced, so that the REPORT WRITER would  
insert the separator characters by itself, when I start it with a,
say

   INTIATE my-report AS CSV


or

   INITIATE my-report AS DELIMITED-FILE

or make it produce an HTML document (at least the body) when the  
report is started as

   INITIATE my-report AS HTML

which would cause compiler and/or run-time system to insert all those  
necessary HTML tags, like <BODY>, <UL>, <TABLE>, etc.

   As far as I understand my reading of the 2002 COBOL standard, one  
would specify what is called a "LINE SEQUENTIAL" file in some  
implementations by omitting a record description in the FD, and by  
specifying some "function-name" as the RECORD DELIMITER, which then  
would be CR, LF, or CR/LF for Max, Unix, or DOS/WIN operating systems.

   While the historic big iron used file systems which were all based  
on a record structure, like their punched cards and magnetic tapes,  
the creators of UNIX and all those following their lead, took rather  
great pains to hide all block structure from the logical file  
structure, presenting any file as a nearly endless STREAM of  
characters.


   For CSV files as INPUT, why couldn't that be specified in a COBOL  
program in the FD, causing a "READ input-file INTO ws-record" not only  
to transfer the content of the file from the current file pointer to  
the record separator character(s), but also to unstring the individual  
items and putting them in the fields of the record which is defined as  
the receiving group item?

  Sure, one can create and decipher CSV files with COBOL's STRING and  
UNSTRING statements, but COBOL's strength is in my humble view, that  
most things are specified in the DATA DIVISION, and do not need to be  
coded as procedural instructions, i.e. I do not need a
  printf(data, %someformat)

as in C and C++, but specify the format in the PICTURE clause. And on  
a higher level, using the REPORT WRITER to generate a report instead  
of coding all that in the procedural statements.



L�ko Willms                                     http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Er urteilt nach dem jedesmaligen Aggregatzustand seiner Empfindungen. -G.C.Lichtenberg
0
l.willms1 (637)
10/21/2004 4:56:00 PM
On Thu, 21 Oct 2004 08:06:01 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:

>Here is code for tab-delimited text files with Micro Focus.
>
>I changed the file suffix to .txt, which Excel and Access
>more easily recognize and I changed the file organization to
>sequential, so that tabs will not have a leading nul character.
>Also, Report Writer, in this case, adds the record separator,
>carriage return + line feed, for what is nominally a record
>secquential file.

>       special-names.
>           symbolic characters
>               separator-tab is 10.

Tab is 9, not 10.

You turn off inserted nulls with run option -N, not by changing the
file organization.
0
robert6624 (636)
10/21/2004 6:51:22 PM
"Rick Smith" <ricksmith@mfi.net> wrote

> .. and I changed the file organization to
> sequential, so that tabs will not have a leading nul character.

There is a run time switch 'N' which cotrols this. You could add '-N'
to the run command or to the COBSW= environment line, or change the
setting using the supplied CALL x"91" 13/14 routines.
0
riplin (4127)
10/21/2004 6:56:37 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:1ngfn0ddj297ctd0it16f3abip2dojtqfe@4ax.com...
> On Thu, 21 Oct 2004 08:06:01 -0400, "Rick Smith" <ricksmith@mfi.net>
> wrote:
[snip]
> >       special-names.
> >           symbolic characters
> >               separator-tab is 10.
>
> Tab is 9, not 10.

It may well be; but, if I used 9, it would have inserted a
backspace. The value to be used is the position in the native
character set. Note that positions are normally 1 - 256;
not 0 - 255. For Micro Focus this is controlled by the
SYMBSTART directive.

Mr Wagner, was it not clear to you that I had tested the
program and neither Excel nor Access, choked?

> You turn off inserted nulls with run option -N, not by changing the
> file organization.

Mr Wagner, there is no *the* way! Using record sequential
was *my way* for this example. Despite my obvious use of
Micro Focus extensions, it is easier to adapt such a progam
to other implementations when one does not rely on obscure,
implementation-specific options.



0
ricksmith (875)
10/21/2004 7:58:00 PM
..    On  21.10.04
  wrote  robert@wagner.net.yourmammaharvests (Robert Wagner)
     on  /COMP/LANG/COBOL
     in  1ngfn0ddj297ctd0it16f3abip2dojtqfe@4ax.com
  about  Re: Report enhancements


>>       special-names.
>>           symbolic characters
>>               separator-tab is 10.

RW> Tab is 9, not 10.

   You are right, and when I went to specify the ASCII control  
characters in the SPECIAL-NAMES paragraph, I found out that I had to  
specify 10 for TAB. Why? Because here the number 1 has to be specified  
for the first character in the alphabet being used, and this first  
character is NUL with the value ZERO. The index numbers into the  
alphabet dont start with 0, but 1.

   This here is the full set:


000010*  ACTLCHAR.CBL as ASCII ConTroL CHARacters.
000011*
000012*  This COPY element is to be included in the SPECIAL-NAMES paragraph
000013*  of the CONFIGURATION SECTION in the ENVIRONMENT DIVISION
000014*
000015     ALPHABET ASCII IS STANDARD-1
000020     SYMBOLIC CHARACTERS
000025         NUL,
000030         SOH, STX, ETX, EOT, ENQ, ACK, BEL, BS,  HT,  LF,  VT,  FF,
000040         CR,  SO,  SI,  DLE, DC1, DC2, DC3, DC4, NAK, SYN, ETB, CAN,
000050         EM,  SUB, ESC, FS,  GS,  RS,  US
000060     ARE  1,
000070          2,   3,   4,   5,   6,   7,   8,   9,  10,  11,  12,  13,
000080         14,  15,  16,  17,  18,  19,  20,  21,  22,  23,  24,  25,
000090         26,  27,  28,  29,  30,  31,  32
000100     IN ASCII
000110     .


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

Man stattete ihm sehr hei�en, schon etwas verbrannten Dank ab. -G.C.Lichtenberg
0
l.willms1 (637)
10/21/2004 8:18:00 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:1ngfn0ddj297ctd0it16f3abip2dojtqfe@4ax.com...
> On Thu, 21 Oct 2004 08:06:01 -0400, "Rick Smith" <ricksmith@mfi.net>
> wrote:
>
> >Here is code for tab-delimited text files with Micro Focus.
> >
> >I changed the file suffix to .txt, which Excel and Access
> >more easily recognize and I changed the file organization to
> >sequential, so that tabs will not have a leading nul character.
> >Also, Report Writer, in this case, adds the record separator,
> >carriage return + line feed, for what is nominally a record
> >secquential file.
>
> >       special-names.
> >           symbolic characters
> >               separator-tab is 10.
>
> Tab is 9, not 10.

It may well be; but, if I used 9, it would have inserted a
backspace. The value to be used is the position in the native
character set. Note that positions are normally 1 - 256;
not 0 - 255. For Micro Focus, this is controlled by the
SYMBSTART directive; standard COBOL has no such
directive.

Mr Wagner, was it not clear to you that I ran the program
to create the file, imported the data into both Excel and
Access, and neither choked on reading the character?

> You turn off inserted nulls with run option -N, not by changing the
> file organization.

Mr Wagner, there is no *the* way! Using record sequential
was *my way* for this example. Despite my obvious use of
Micro Focus extensions, it is easier to adapt such a progam
to other implementations when one does not rely on obscure,
implementation-specific options.

To clarify one point. When I wrote, "Also, Report Writer, in
this case, adds the record separator, carriage return + line feed,
for what is nominally a record secquential file."; I did so
because I was aware that COBOL 85 behavior is similar to,
if not the same as, the following.

FDIS, page 236, 13.3.4.3 (File description entry) General
rules "4) The report writer logical record structure of the file
associated with file-name-1 is defined by the implementor."

Thus, while I qualified the code as for "Micro Focus", I
still wrote it to be easily adapted for other implementations.



0
ricksmith (875)
10/21/2004 8:52:35 PM
Must have been Outlook Express. I closed the window and
told OE not to save; there was only one message in the
outbox. That message was not the one.

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:10ng8fnl9j3a9fe@corp.supernews.com...
>
> "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:1ngfn0ddj297ctd0it16f3abip2dojtqfe@4ax.com...
> > On Thu, 21 Oct 2004 08:06:01 -0400, "Rick Smith" <ricksmith@mfi.net>
> > wrote:
> [snip]
> > >       special-names.
> > >           symbolic characters
> > >               separator-tab is 10.
> >
> > Tab is 9, not 10.
>
> It may well be; but, if I used 9, it would have inserted a
> backspace. The value to be used is the position in the native
> character set. Note that positions are normally 1 - 256;
> not 0 - 255. For Micro Focus this is controlled by the
> SYMBSTART directive.
>
> Mr Wagner, was it not clear to you that I had tested the
> program and neither Excel nor Access, choked?
>
> > You turn off inserted nulls with run option -N, not by changing the
> > file organization.
>
> Mr Wagner, there is no *the* way! Using record sequential
> was *my way* for this example. Despite my obvious use of
> Micro Focus extensions, it is easier to adapt such a progam
> to other implementations when one does not rely on obscure,
> implementation-specific options.
>
>
>




0
ricksmith (875)
10/21/2004 9:30:53 PM
On Thu, 21 Oct 2004 15:58:00 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:

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

>> You turn off inserted nulls with run option -N, not by changing the
>> file organization.
>
>Mr Wagner, there is no *the* way! Using record sequential
>was *my way* for this example. Despite my obvious use of
>Micro Focus extensions, it is easier to adapt such a progam
>to other implementations when one does not rely on obscure,
>implementation-specific options.

Mr Smith, other compilers do not insert nulls. As far as I know, Micro
Focus is the only one. 

Other compilers do support line sequential.

0
robert6624 (636)
10/21/2004 10:50:31 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:0kegn01be205o75oogs6181jjor9j5v84o@4ax.com...
> On Thu, 21 Oct 2004 15:58:00 -0400, "Rick Smith" <ricksmith@mfi.net>
> wrote:
>
> >"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> >news:1ngfn0ddj297ctd0it16f3abip2dojtqfe@4ax.com...
>
> >> You turn off inserted nulls with run option -N, not by changing the
> >> file organization.
> >
> >Mr Wagner, there is no *the* way! Using record sequential
> >was *my way* for this example. Despite my obvious use of
> >Micro Focus extensions, it is easier to adapt such a progam
> >to other implementations when one does not rely on obscure,
> >implementation-specific options.
>
> Mr Smith, other compilers do not insert nulls. As far as I know, Micro
> Focus is the only one.
>
> Other compilers do support line sequential.

I must say, Mr Wagner, I find the change from imperative
to declarative to be remarkable.



0
ricksmith (875)
10/22/2004 12:50:33 AM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9JHMaVDuflB@jpberlin-l.willms.jpberlin.de...
> .    On  21.10.04
>   wrote  ricksmith@mfi.net (Rick Smith)
>      on  /COMP/LANG/COBOL
>      in  10nf9km25av146a@corp.supernews.com
>   about  Re: Report enhancements
[snip]
> >>     BTW, I prefer the file-input loop this way:
>
> RS> As I have become fond of saying, "There is no *the* way."
[snip]
>   The additional READ necessary in COBOL to find EOF is treated in my
> design as READ number 0 (zero), outside of the loop. The block of
> statements being executed as the loop is not interupted by checks for
> the status of the input-file. Anybody may do it as she or he pleases,
> but I think that my approach most accurately reflects the actual
> structure of the data object, i.e. the file.

Ah, but does it reflect the expected sequence
'input-process-output' found often in structured design?

[snip]
> [...] , but COBOL's strength is in my humble view, that
> most things are specified in the DATA DIVISION, and do not need to be
> coded as procedural instructions, [...]

You might wish to look at the Validate facility in 2002.
The VALIDATE statement is similar to GENERATE in
the amount of processing that may be done from descriptions
in the data division.



0
ricksmith (875)
10/22/2004 1:56:00 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> >       special-names.
> >           symbolic characters
> >               separator-tab is 10.
> 
> Tab is 9, not 10.

Another factoid.

While tab is x"09" it is the 10th character in the character set and
thus, for those who understand Cobol, it is usually specified in
symbolic characters as 10.
 
> You turn off inserted nulls with run option -N, not by changing the
> file organization.

He can do it any way he bloody well likes.

While I had already suggested that he _could_ do it in several
different ways with MF, the way that _he_ chose to do it is entirely
up to him, in this case using a perfectly standard ANS85 file type
rather than some extension.
0
riplin (4127)
10/22/2004 5:41:53 AM
..    On  21.10.04
  wrote  ricksmith@mfi.net (Rick Smith)
     on  /COMP/LANG/COBOL
     in  10ngq95a8v0666b@corp.supernews.com
  about  Re: Report enhancements


>>   The additional READ necessary in COBOL to find EOF is treated in my
>> design as READ number 0 (zero), outside of the loop. The block of
>> statements being executed as the loop is not interupted by checks for
>> the status of the input-file. Anybody may do it as she or he pleases,
>> but I think that my approach most accurately reflects the actual
>> structure of the data object, i.e. the file.

RS> Ah, but does it reflect the expected sequence
RS> 'input-process-output' found often in structured design?

   Well, in the sense that the sequence of statements executed in the  
loop begins with the valid assertion that an input record is  
available, and ends with the attempt to make the next record  
available, whose failure ends the repetition.

   That is, as I recall, as I have learned it in my first COBOL course  
26 years ago, and formed in my opinion also using other languages  
besides COBOL.

   BTW, starting the looped sequence with the attempt to READ a  
record, you have to EXIT from the loop in its middle; but then the  
loop itself should not be limited by a WHILE or UNTIL condition, but  
be executed FOREVER.

  So not

           perform until exit
               read item-file
                   at end exit perform
               end-read
               generate item-detail
           end-perform

  but

          perform
               read item-file
                   at end exit perform
               end-read
               generate item-detail
           end-perform

  or have I misunderstood some new PERFORM syntax?


>> [...] , but COBOL's strength is in my humble view, that
>> most things are specified in the DATA DIVISION, and do not need to be
>> coded as procedural instructions, [...]

RS> You might wish to look at the Validate facility in 2002.
RS> The VALIDATE statement is similar to GENERATE in
RS> the amount of processing that may be done from descriptions
RS> in the data division.

   I have seen it, but not yet grasped it in its completeness.  
Standards are standards but not necessary the best teacher.

   I have purchased the 2002 standard as a PDF, but reading it in a  
screen window is .... I think I will print it the 879 pages out on  
paper. Well, I just printed out chapter E.19 "Validate facility" from  
appendix E, "Concepts", plus the syntax description of the statement  
in a nice little 8 page booklet, and will try to understand it.

  BTW, one can build PDF files in a much better way -- have a look at  
the book on ASN.1 by Olivier Dubuisson one can download (for free)  
starting here: http://asn1.elibel.tm.fr/book

  In that book, not only the table of contents is formed as a  
hyperlink, but also footnotes, cross references, literature  
references, etc. Thus the book is much easier to read than the COBOL  
standard.


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

Nach einem drei�igj�hrigen Krieg mit sich selbst kam es endlich zu einem Vergleich, aber die Zeit war verloren. -G.C.Lichtenberg
0
l.willms1 (637)
10/22/2004 9:39:00 AM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9JLRZ5oPflB@jpberlin-l.willms.jpberlin.de...
> .    On  21.10.04
>   wrote  ricksmith@mfi.net (Rick Smith)
>      on  /COMP/LANG/COBOL
>      in  10ngq95a8v0666b@corp.supernews.com
>   about  Re: Report enhancements
[snip]
>    BTW, starting the looped sequence with the attempt to READ a
> record, you have to EXIT from the loop in its middle; but then the
> loop itself should not be limited by a WHILE or UNTIL condition, but
> be executed FOREVER.
>
>   So not
>
>            perform until exit
>                read item-file
>                    at end exit perform
>                end-read
>                generate item-detail
>            end-perform
>
>   but
>
>           perform
>                read item-file
>                    at end exit perform
>                end-read
>                generate item-detail
>            end-perform
>
>   or have I misunderstood some new PERFORM syntax?

'perform until exit' is a Micro Focus extension equivalent to
standard COBOL 'perform until 1 = 0'; thus, perform forever.
'exit perform' is standard COBOL for leaving the scope of
an inline-perform.

Your suggestion is standard COBOL; but is equivalent to
a simple begin-end block; that is, it delimits the scope of the
enclosed statements and is executed once. In C, it would be
equivalent to:

do {    /* perform */
    if (condition)
        break;    /* exit perform */
    statement;
} while (0);    /* end-perform */



0
ricksmith (875)
10/22/2004 11:51:27 AM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9JLRZ5oPflB@jpberlin-l.willms.jpberlin.de...
>
> Nach einem drei�igj�hrigen Krieg mit sich selbst kam es endlich zu einem
Vergleich, aber die Zeit war verloren. -G.C.Lichtenberg
>
Ah, sehe ich Sie die J4 leute kennengelernt haben... <L>

Pete.
(Entschuldigung, mein Deutsch ist sehr rustig...gibt's keine gelegenheit
fuer ubung hier in Neu Seeland...)



0
dashwood1 (2140)
10/22/2004 12:03:02 PM
..    On  20.10.04
  wrote  howard@brazee.net (Howard Brazee)
     on  /COMP/LANG/COBOL
     in  cl5r85$ate$1@peabody.colorado.edu
  about  Report enhancements


HB> But what we want (in Mainframe land) nowadays is to have a mainframe
HB> CoBOL program to create a report which the users can view on their PC
HB> and then decide to print on their printers set up the way they want,
HB> and in the format they want.    PC CoBOL has this same requirement -
HB> unless each computer has its separately compiled copy of the main
HB> program REPORT WRITER doesn't do enough.
HB>
HB> Often I create files that are read in by a PC spreadsheet or
HB> database.    The users have the expertise to do whatever they want
HB> from that stage.
HB>
HB> When one office wants to change its report, the program doesn't have
HB> to be changed and tested by all offices.

   I would distinguish two types of printouts:

1) Those which actually represent a transaction and are bound to a  
specific form, like invoices, bank forms, payment slips, tax forms,  
social security forms, and things like that. I would not want some  
department to tamper with the form of those documents.


2) Informational reports about, e.g. merchandise stock levels, sales  
figurs per period and region, price lists, and so on. These were at  
least in part necessary in earlier times when the whole data  
processing was done by batch runs. Nowadays I would recommend not to  
produce printed reports, but to look up those data online in the  
central database, and to print it out on one's own account and format  
as you please, and only if deemed necessary.

   Even in the old days, those reports were not always really needed.  
There are enough stories where the DP department did not produce one  
of those reports, and nobody noticed it...


   And coming back to the means that the programming language COBOL  
provices, I think that even a report presented as an HTML page could  
be produced by the REPORT WRITER feature, to which I would recommend  
an enhancement which inserts all the necessary HTML tags to structure  
the document, which can then be visualized using some CSS style sheet,  
just as you explained. And then printed, or not...


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

Da liegen nun die Kartoffeln und schlafen ihrer Auferstehung entgegen. -G.C.Lichtenberg
0
l.willms1 (637)
10/22/2004 2:54:00 PM
..    On  23.10.04
  wrote  dashwood@enternet.co.nz (Pete Dashwood)
     on  /COMP/LANG/COBOL
     in  2tsb7rF22lfadU1@uni-berlin.de
  about  Re: Report enhancements


>> Nach einem drei�igj�hrigen Krieg mit sich selbst kam es endlich zu
>> einem Vergleich, aber die Zeit war verloren. -G.C.Lichtenberg

PD> Ah, sehe ich Sie die J4 leute kennengelernt haben... <L>

  Did I? Georg Christoph Lichtenberg is one of my favorite authors. He  
was a professor for physics at G�ttingen university at the end of the  
18th century, and the beginning of the 19th. He left a huge treaure of  
aphorismu which he noted down in his "Sudelb�cher" (scrap books),  
which he did not publish in his lifetime.


PD> (Entschuldigung, mein Deutsch ist sehr rustig...gibt's keine
PD> gelegenheit fuer ubung hier in Neu Seeland...)

   That's life, but I understood it.

   BTW, I was just thinking of you and Javascript. There is a HTML and
Javascript reference website in German at http://www.selfhtml.org

   They did start an English translation, which I just looked up, but
it looked all German to me... it would be at http://en.selfhtml.org

   "selfhtml" from "teach yourself HTML".


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

Eine ganze Milchstra�e von Einf�llen. -G.C.Lichtenberg
0
l.willms1 (637)
10/22/2004 4:01:00 PM
On 21 Oct 2004 22:41:53 -0700, riplin@Azonic.co.nz (Richard) wrote:

>While I had already suggested that he _could_ do it in several
>different ways with MF, the way that _he_ chose to do it is entirely
>up to him, in this case using a perfectly standard ANS85 file type
>rather than some extension.

Tell Daniel Vidal under subject "COBOL set for AIX .." that his
sequential file is "perfectly standard ANS85".

The Cobol standard does not specify file formats. They are
implementer-defined, an euphemism for non-standard. The only standard
we have is ASCII (despite Micro Focus' attempt to screw it up by
inserting nulls). Thus, line sequential files are standardized whereas
ANS85 sequential are non-standard. 

0
robert6624 (636)
10/22/2004 4:05:01 PM
"Rick Smith" <ricksmith@mfi.net> wrote in message 
news:10nht598jo09r03@corp.supernews.com...
>
<snip>
> 'perform until exit' is a Micro Focus extension equivalent to
> standard COBOL 'perform until 1 = 0'; thus, perform forever.
> 'exit perform' is standard COBOL for leaving the scope of
> an inline-perform.
>

Trivial but true,

   Perform until 1 = 0

is also non-Standard.  To make it Standard, either "0" or "1" would have to be 
an identifier.  See "8.8.4.1.1 Relation conditions" on page 127 of the 2002 
Standard which says,

"A relation condition shall contain at least one reference to an operand that is 
not a literal."

The same restriction appears in the '85 Standard.


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


0
wmklein (2605)
10/22/2004 4:24:15 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:im6in05frv6o0k6jiedsatjall65e0b86p@4ax.com...
> On 21 Oct 2004 22:41:53 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
<snip>
> The Cobol standard does not specify file formats. They are
> implementer-defined, an euphemism for non-standard. The only standard
> we have is ASCII (despite Micro Focus' attempt to screw it up by
> inserting nulls). Thus, line sequential files are standardized whereas
> ANS85 sequential are non-standard.
>

Saying that "implementer-defined is an euphemism for non-standard"

shows a SERIOUS misunderstanding of what is and is not standard - in a COBOL 
context.  If you had said non-portable, I probably would have agreed with you, 
but non-standard (even if it isn't "non-Standard) simply is wrong.

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


0
wmklein (2605)
10/22/2004 4:25:49 PM
Robert Wagner wrote:
> On 21 Oct 2004 22:41:53 -0700, riplin@Azonic.co.nz (Richard) wrote:
> 
> 
>>While I had already suggested that he _could_ do it in several
>>different ways with MF, the way that _he_ chose to do it is entirely
>>up to him, in this case using a perfectly standard ANS85 file type
>>rather than some extension.
> 
> 
> Tell Daniel Vidal under subject "COBOL set for AIX .." that his
> sequential file is "perfectly standard ANS85".
> 
> The Cobol standard does not specify file formats. They are
> implementer-defined, an euphemism for non-standard. The only standard
> we have is ASCII (despite Micro Focus' attempt to screw it up by
> inserting nulls). Thus, line sequential files are standardized whereas
> ANS85 sequential are non-standard. 
> 

Fujitsi and MF are *both* non-standard by my definitions. Fujitsu line 
sequential files are fixed length by default.

You can get a "standard" "Line sequential" file with most Cobol's, but 
even then it is only standard according to an arbitrary definition for a 
specific platform.  It is not standard the way a text file is "standard".

Donald

0
donald_tees (563)
10/22/2004 4:43:52 PM
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Puaed.3152630$ic1.324937@news.easynews.com...
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:10nht598jo09r03@corp.supernews.com...
> >
> <snip>
> > 'perform until exit' is a Micro Focus extension equivalent to
> > standard COBOL 'perform until 1 = 0'; thus, perform forever.
> > 'exit perform' is standard COBOL for leaving the scope of
> > an inline-perform.
> >
>
> Trivial but true,
>
>    Perform until 1 = 0
>
> is also non-Standard.  To make it Standard, either "0" or "1" would have
to be
> an identifier.  See "8.8.4.1.1 Relation conditions" on page 127 of the
2002
> Standard which says,
>
> "A relation condition shall contain at least one reference to an operand
that is
> not a literal."
>
> The same restriction appears in the '85 Standard.

H'm, in that case, I need to stop calling '1 = 0' standard
COBOL and think of another means for expressing that
the code within the perform repeats indefinitely.

Thank you for the correction.



0
ricksmith (875)
10/22/2004 5:39:13 PM
"Rick Smith" <ricksmith@mfi.net> wrote in message 
news:10nihh5lh9ie9b2@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:Puaed.3152630$ic1.324937@news.easynews.com...
>> "Rick Smith" <ricksmith@mfi.net> wrote in message
>> news:10nht598jo09r03@corp.supernews.com...
>> >
>> <snip>
>> > 'perform until exit' is a Micro Focus extension equivalent to
>> > standard COBOL 'perform until 1 = 0'; thus, perform forever.
>> > 'exit perform' is standard COBOL for leaving the scope of
>> > an inline-perform.
>> >
>>
>> Trivial but true,
>>
>>    Perform until 1 = 0
>>
>> is also non-Standard.  To make it Standard, either "0" or "1" would have
> to be
>> an identifier.  See "8.8.4.1.1 Relation conditions" on page 127 of the
> 2002
>> Standard which says,
>>
>> "A relation condition shall contain at least one reference to an operand
> that is
>> not a literal."
>>
>> The same restriction appears in the '85 Standard.
>
> H'm, in that case, I need to stop calling '1 = 0' standard
> COBOL and think of another means for expressing that
> the code within the perform repeats indefinitely.
>
> Thank you for the correction.
>
>
>

How about

   Perform until 1 Zero

(not 1 = Zero - but using the "zero sign test") - If you don't think that is 
clear enough, how about

   Perform until 1 + 1 Negative

I may be mistaken here, but I do not *think* that the sign test requires an 
identifier (or at least I couldn't QUICKLY find that restriction).

Thane or Chuck, can either of you confirm (or deny) this? 


0
wmklein (2605)
10/22/2004 6:00:41 PM
"Rick Smith" <ricksmith@mfi.net> wrote 

> >
> >           perform
> >                read item-file
> >                    at end exit perform
> >                end-read
> >                generate item-detail
> >            end-perform
> >
> >   or have I misunderstood some new PERFORM syntax?

That will do one execution of the block of code.
 
> 'perform until exit' is a Micro Focus extension equivalent to
> standard COBOL 'perform until 1 = 0'; thus, perform forever.
> 'exit perform' is standard COBOL for leaving the scope of
> an inline-perform.

EXIT PERFORM is a MF extension in ANS85 compilers.

Why not use NOT AT END ?

            PERFORM UNTIL Hell-freezes-over
                READ item-file
                    AT END
                        SET Hell-freezes-over TO TRUE
                    NOT AT END
                        process record
                END-READ
            END-PERFORM
0
riplin (4127)
10/22/2004 7:10:18 PM
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:dVbed.1651997$yk.273663@news.easynews.com...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:10nihh5lh9ie9b2@corp.supernews.com...
> >
> > "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> > news:Puaed.3152630$ic1.324937@news.easynews.com...
> >> "Rick Smith" <ricksmith@mfi.net> wrote in message
> >> news:10nht598jo09r03@corp.supernews.com...
> >> >
> >> <snip>
> >> > 'perform until exit' is a Micro Focus extension equivalent to
> >> > standard COBOL 'perform until 1 = 0'; thus, perform forever.
> >> > 'exit perform' is standard COBOL for leaving the scope of
> >> > an inline-perform.
> >> >
> >>
> >> Trivial but true,
> >>
> >>    Perform until 1 = 0
> >>
> >> is also non-Standard.  To make it Standard, either "0" or "1" would
have
> > to be
> >> an identifier.  See "8.8.4.1.1 Relation conditions" on page 127 of the
> > 2002
> >> Standard which says,
> >>
> >> "A relation condition shall contain at least one reference to an
operand
> > that is
> >> not a literal."
> >>
> >> The same restriction appears in the '85 Standard.
> >
> > H'm, in that case, I need to stop calling '1 = 0' standard
> > COBOL and think of another means for expressing that
> > the code within the perform repeats indefinitely.
> >
> > Thank you for the correction.
> >
> >
> >
>
> How about
>
>    Perform until 1 Zero
>
> (not 1 = Zero - but using the "zero sign test") - If you don't think that
is
> clear enough, how about
>
>    Perform until 1 + 1 Negative
>
> I may be mistaken here, but I do not *think* that the sign test requires
an
> identifier (or at least I couldn't QUICKLY find that restriction).
>
> Thane or Chuck, can either of you confirm (or deny) this?

It might be possible to use a Boolean literal, as in,

    perform until B"0"

FDIS, page 490, 14.8.27.2 (PERFORM statement) Syntax rules
"8) Condition-1, condition-2, ... , may be any conditional expression.
(See 8.8.4, Conditional expressions.)"

FDIS, page 126, 8.8.4.1 (Conditional expressions) Simple conditions
"The simple conditions are the relation, boolean, ...."

FDIS, page 131,
8.8.4.1.2 Boolean condition
A boolean condition determines whether a boolean expression is true
or false.
8.8.4.1.2.1 General format
[ NOT ] boolean-expression-1
8.8.4.1.2.2 Syntax rules
1) Boolean-expression-1 shall reference only boolean items of length 1.
8.8.4.1.2.3 General rules
1) Boolean-expression-1 evaluates true if the result of the expression
    is 1 and evaluates false if the result of the expression is 0.
2) The condition NOT boolean-expression-1 evaluates to the reverse
    truth-value of boolean-expression-1.

FDIS, page 124, 8.8.2 Boolean expressions
"A boolean expression may be:
....
- a boolean literal,
...."

But, this does not address COBOL 85.

Wait a minute! Let me think!

H'm, yes, that's it! An indefinite loop is most useful when used
with EXIT PERFORM; but EXIT PERFORM is not in
COBOL 85. I don't need to think of a means, I only need to
stop calling it standard COBOL.

I can let J4 deal with the issue for COBOL 2014(?).
By then, I'll be retired and living in Florida.
Wait! I'm already living in Florida and not working.
This is so confusing!
<G>



0
ricksmith (875)
10/22/2004 7:15:51 PM
..    On  22.10.04
  wrote  wmklein@nospam.netcom.com (William M. Klein)
     on  /COMP/LANG/COBOL
     in  dVbed.1651997$yk.273663@news.easynews.com
  about  Re: Report enhancements


RS>>>> 'perform until exit' is a Micro Focus extension equivalent to
RS>>>> standard COBOL 'perform until 1 = 0'; thus, perform forever.
RS>>>> 'exit perform' is standard COBOL for leaving the scope of
RS>>>> an inline-perform.

   Now I understand -- I assumed that "PERFORM .... END-PERFORM" would  
specify an endless loop, but no, like in "PERFORM procedure-name-1" it  
performs only once.

   The Fujitsu compiler supports this:

   PERFORM WITH NO LIMIT
      do-something
   END-PERFORM

>>>    Perform until 1 = 0
>>>
>>> is also non-Standard.

RS>> H'm, in that case, I need to stop calling '1 = 0' standard
RS>> COBOL and think of another means for expressing that
RS>> the code within the perform repeats indefinitely.

WMK> How about
WMK>
WMK>    Perform until 1 Zero
WMK>
WMK> (not 1 = Zero - but using the "zero sign test") - If you don't think
WMK> that is clear enough, how about
WMK>
WMK>    Perform until 1 + 1 Negative
WMK>
WMK> I may be mistaken here, but I do not *think* that the sign test
WMK> requires an identifier (or at least I couldn't QUICKLY find that
WMK> restriction).

   How about PERFORM UNTIL HIGH-VALUE = LOW-VALUE
   Well, probably it won't be accepted by the compiler.


   Well, COBOL provides an EXIT PERFORM, which allows to exit the loop  
in the middle of the PERFORMed sequence of statements, but obviously  
requires in all cases some loop entry or loop exit condition to be  
specified, which then causes two evaluations of a condition to be  
executed for every cycle. That is not cute.

   When it is the will of the programmer, to exit from his loop not at  
the begin or end of the loop, but somewhere in the middle, there  
should be a FOREVER clause taking the place of the "until-phrase",  
like this:

   PERFORM FOREVER
     do-this
     IF some-condition
       EXIT PERFORM
     END-IF
     do-that
   END-PERFORM

   FOREVER is not yet a reserved word, so it can be used...


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

Der Amerikaner, der den Kolumbus zuerst entdeckte, machte eine b�se Entdeckung. -G.C.Lichtenberg
0
l.willms1 (637)
10/22/2004 8:07:00 PM
It does seem silly though to avoid a data standard. All vendors
would not have to create special parts, tape drives, or what have
you to bid on a competitors site rfb.

Warren

William M. Klein wrote:
> "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
> news:im6in05frv6o0k6jiedsatjall65e0b86p@4ax.com...
> 
>>On 21 Oct 2004 22:41:53 -0700, riplin@Azonic.co.nz (Richard) wrote:
>>
> 
> <snip>
> 
>>The Cobol standard does not specify file formats. They are
>>implementer-defined, an euphemism for non-standard. The only standard
>>we have is ASCII (despite Micro Focus' attempt to screw it up by
>>inserting nulls). Thus, line sequential files are standardized whereas
>>ANS85 sequential are non-standard.
>>
> 
> 
> Saying that "implementer-defined is an euphemism for non-standard"
> 
> shows a SERIOUS misunderstanding of what is and is not standard - in a COBOL 
> context.  If you had said non-portable, I probably would have agreed with you, 
> but non-standard (even if it isn't "non-Standard) simply is wrong.
> 
0
wsimmons5 (172)
10/22/2004 8:12:37 PM
..    On  22.10.04
  wrote  riplin@Azonic.co.nz (Richard)
     on  /COMP/LANG/COBOL
     in  217e491a.0410221110.df6cf8c@posting.google.com
  about  Re: Report enhancements


r> EXIT PERFORM is a MF

                    and Fujitsu

r>                           extension in ANS85 compilers.

   and part of the 2002 standard.

   But the 2002 standard does not have the PERFORM FOREVER.

r> Why not use NOT AT END ?

   The point was to use the AT END-condition as the exit point out of  
the middle of the loop instead of setting a condition for entering or  
leaving the loop at one of the two ends of the looped sequence. But  
since the standard COBOL syntax requires some UNTIL with a condition  
to repeat the sequence more than once, the search for a dummy  
condition to be evaluated on the loops edges, in addition to the  
"real" condition in the middle of the loop started

r>
r>             PERFORM UNTIL Hell-freezes-over
r>                 READ item-file
r>                     AT END
r>                         SET Hell-freezes-over TO TRUE
r>                     NOT AT END
r>                         process record
r>                 END-READ
r>             END-PERFORM

    If I use the AT END condition at all, it is with CONTINUE, since  
my loops are guarded by a condition provided by the FILE STATUS, like  
this:

              READ item-file
              PERFORM UNTIL major-file-status = '1'
                process record
                READ item-file
              END-PERFORM

    looks tidied up, isn't it?

    or, if a DECLARATIVES procudure is present for item-file:

              READ item-file
                AT END CONTINUE
              END-READ
              PERFORM UNTIL major-file-status = '1'
                process record
                READ item-file
                  AT END CONTINUE
                END-READ
              END-PERFORM


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

Eine ganze Milchstra�e von Einf�llen. -G.C.Lichtenberg
0
l.willms1 (637)
10/22/2004 9:08:00 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410221110.df6cf8c@posting.google.com...
[snip]
> Why not use NOT AT END ?
>
>             PERFORM UNTIL Hell-freezes-over
>                 READ item-file
>                     AT END
>                         SET Hell-freezes-over TO TRUE
>                     NOT AT END
>                         process record
>                 END-READ
>             END-PERFORM

It seems illogical to me. There are, frequently, three major
phases in computer algorithms: input, process, and output.
Within each of these are some number of minor steps.

Reading a record from a file is subordinate to the input
phase. Process steps are subordinate to the process phase.
To make the remaining steps of all phases subordinate to
the first step in the input phase, seems illogical.

I previously suggested that NOT AT END is a good place
to complete a 'virtual' record; that is, to gather data not in
the record read, but which is needed by the process phase.

Something like,

1. Input phase
  a. Make external data available
  b. Validate input
  c. Initialize work variables
2. Process phase
  a. Fist step
  ...
  z. Last step
3. Output phase
  a. Post processing checks
  b. Distribution to external locations
where 'external' means external to the algorithm



0
ricksmith (875)
10/22/2004 9:54:16 PM
Thanks Lueko,

I'll check out the links.

(I use DevGuru (in English <g>) as my JavaScript reference)

I think it would be a good exercise for me to read some of this Lichtenberg.
Is there a web site you could recommend?

Pete.

(Top post; no more below the signature)


"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9JLUE7KPflB@jpberlin-l.willms.jpberlin.de...
> .    On  23.10.04
>   wrote  dashwood@enternet.co.nz (Pete Dashwood)
>      on  /COMP/LANG/COBOL
>      in  2tsb7rF22lfadU1@uni-berlin.de
>   about  Re: Report enhancements
>
>
> >> Nach einem drei�igj�hrigen Krieg mit sich selbst kam es endlich zu
> >> einem Vergleich, aber die Zeit war verloren. -G.C.Lichtenberg
>
> PD> Ah, sehe ich Sie die J4 leute kennengelernt haben... <L>
>
>   Did I? Georg Christoph Lichtenberg is one of my favorite authors. He
> was a professor for physics at G�ttingen university at the end of the
> 18th century, and the beginning of the 19th. He left a huge treaure of
> aphorismu which he noted down in his "Sudelb�cher" (scrap books),
> which he did not publish in his lifetime.
>
>
> PD> (Entschuldigung, mein Deutsch ist sehr rustig...gibt's keine
> PD> gelegenheit fuer ubung hier in Neu Seeland...)
>
>    That's life, but I understood it.
>
>    BTW, I was just thinking of you and Javascript. There is a HTML and
> Javascript reference website in German at http://www.selfhtml.org
>
>    They did start an English translation, which I just looked up, but
> it looked all German to me... it would be at http://en.selfhtml.org
>
>    "selfhtml" from "teach yourself HTML".
>
>
> Yours,
> L�ko Willms                                     http://www.willms-edv.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> Eine ganze Milchstra�e von Einf�llen. -G.C.Lichtenberg
>



0
dashwood1 (2140)
10/22/2004 9:57:48 PM
On Fri, 22 Oct 2004 12:43:52 -0400, Donald Tees
<donald_tees@sympatico.ca> wrote:

>You can get a "standard" "Line sequential" file with most Cobol's, but 
>even then it is only standard according to an arbitrary definition for a 
>specific platform.  It is not standard the way a text file is "standard".

What's the difference between text, line sequential and ASCII? I
thought they were synonymous. 
0
robert6624 (636)
10/22/2004 10:05:34 PM
On Fri, 22 Oct 2004 16:25:49 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
>news:im6in05frv6o0k6jiedsatjall65e0b86p@4ax.com...
>> On 21 Oct 2004 22:41:53 -0700, riplin@Azonic.co.nz (Richard) wrote:
>>
><snip>
>> The Cobol standard does not specify file formats. They are
>> implementer-defined, an euphemism for non-standard. The only standard
>> we have is ASCII (despite Micro Focus' attempt to screw it up by
>> inserting nulls). Thus, line sequential files are standardized whereas
>> ANS85 sequential are non-standard.
>>
>
>Saying that "implementer-defined is an euphemism for non-standard"
>
>shows a SERIOUS misunderstanding of what is and is not standard - in a COBOL 
>context.  If you had said non-portable, I probably would have agreed with you, 
>but non-standard (even if it isn't "non-Standard) simply is wrong.

I'd say a Cobol compiler that cannot read a sequential file written by
a sort, another language and another Cobol compiler, all running on
the same platform, is using a non-standard file format.
0
robert6624 (636)
10/22/2004 10:05:34 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:ofvin01mi23u83jbjvoqhvf8mk4e5jkp8l@4ax.com...
> On Fri, 22 Oct 2004 16:25:49 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>>news:im6in05frv6o0k6jiedsatjall65e0b86p@4ax.com...
>>> On 21 Oct 2004 22:41:53 -0700, riplin@Azonic.co.nz (Richard) wrote:
>>>
>><snip>
>>> The Cobol standard does not specify file formats. They are
>>> implementer-defined, an euphemism for non-standard. The only standard
>>> we have is ASCII (despite Micro Focus' attempt to screw it up by
>>> inserting nulls). Thus, line sequential files are standardized whereas
>>> ANS85 sequential are non-standard.
>>>
>>
>>Saying that "implementer-defined is an euphemism for non-standard"
>>
>>shows a SERIOUS misunderstanding of what is and is not standard - in a COBOL
>>context.  If you had said non-portable, I probably would have agreed with you,
>>but non-standard (even if it isn't "non-Standard) simply is wrong.
>
> I'd say a Cobol compiler that cannot read a sequential file written by
> a sort, another language and another Cobol compiler, all running on
> the same platform, is using a non-standard file format.

What "standard"? And who provides the "sort" program?

Personally, I suspect that MOST (but certainly NOT all) operating systems 
provide an IMPLEMENTOR definiton of what a "text" file needs to be for that 
environment.  Therefore, I would expect that MOST products targetted at that 
specific operating system will provide at least SOME option to handle such text 
files.  On the other hand, there are so many variables, that even this is a 
stretch - and when it comes to CLAIMING that what an Operating System vendor 
defines as a text file for THEIR specific OS is "standard" that simply is a 
STETCH for any commonly used meaning of "standard" that I am aware of. 


0
wmklein (2605)
10/22/2004 10:13:40 PM
"Line Sequential" files certainly NEED NOT be ASCII.  See (for example) "Line 
Sequential" EBCDIC files for IBM mainframes:
  http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg20/1.11

As far as "line sequential" versus "text files" - many (most?) PC and Unix COBOL 
compilers allow *some* but not all "control characters" within "Line Sequential" 
files.  They certainly allow most (but probably not all) Packed-Decimal and 
Binary values for numeric fields.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:0epin0p8155dsc5eqao2d9s49fhr8cvlqt@4ax.com...
> On Fri, 22 Oct 2004 12:43:52 -0400, Donald Tees
> <donald_tees@sympatico.ca> wrote:
>
>>You can get a "standard" "Line sequential" file with most Cobol's, but
>>even then it is only standard according to an arbitrary definition for a
>>specific platform.  It is not standard the way a text file is "standard".
>
> What's the difference between text, line sequential and ASCII? I
> thought they were synonymous. 


0
wmklein (2605)
10/22/2004 10:17:17 PM
On Fri, 22 Oct 2004 17:54:16 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:

>It seems illogical to me. There are, frequently, three major
>phases in computer algorithms: input, process, and output.
>Within each of these are some number of minor steps.
>
>Reading a record from a file is subordinate to the input
>phase. Process steps are subordinate to the process phase.
>To make the remaining steps of all phases subordinate to
>the first step in the input phase, seems illogical.
>
>I previously suggested that NOT AT END is a good place
>to complete a 'virtual' record; that is, to gather data not in
>the record read, but which is needed by the process phase.
>
>Something like,
>
>1. Input phase
>  a. Make external data available
>  b. Validate input
>  c. Initialize work variables
>2. Process phase
>  a. Fist step
>  ...
>  z. Last step
>3. Output phase
>  a. Post processing checks
>  b. Distribution to external locations
>where 'external' means external to the algorithm

I agree, but point out there are four processes, each having a
beginning, middle and end:
1. the program
2. a file 
3. an input record
4. an output record

I visualize a program as a telescope (or fractal, if you prefer),
where the middle of each process contains another process with a
beginning, middle and end.

To illustrate this, I added a file and avoided inline performs.

01  file-flags value all 'n'.
     88  end-of-all-files value all 'y'.
      05  occurs 2.
            88 end-of-file value 'y'. 
     
procedure division.
process-program.
    open output output-file                         *> beginning
    perform process-file-1                           *> middle
    perform process-file-2
    close output-file                                     *>end
    stop run.

process-file-1.
    open input file-1                                    *> beginning
    perform process-record-1 until end-of-file (1) *> middle
    close file-1.                                           *> end

process-record-1.
    read file-1 into input-record                 *> beginning
        at end set end-of-file (1) to true 
        exit paragraph
    end-read  
    compute ..                                           *> middle
    compute ..
    perform process-output.                    *> end
 
process-output.
   initialize output-record                         *> beginning
   move ..                                                *> middle
   move ..
  write output-record.                             *>end
0
robert6624 (636)
10/22/2004 11:35:58 PM
On Fri, 22 Oct 2004 22:17:17 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>As far as "line sequential" versus "text files" - many (most?) PC and Unix COBOL 
>compilers allow *some* but not all "control characters" within "Line Sequential" 
>files.  They certainly allow most (but probably not all) Packed-Decimal and 
>Binary values for numeric fields.

If they disallow any control character, as they must, they have
effectively disallowed binary values. If they disallow null or tab, as
some do for tab compression, they have disallowed packed.

The essential features of this format are portability and editability.
Allowing binary stuff sabotages the Standard for Information
Interchange.
0
robert6624 (636)
10/23/2004 12:37:05 AM
Can you tell me where to find (on the web) the

 "Standard for Information  Interchange"

that you reference below?

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:t78jn0ljbdpon6kqao42td963riaf3v8rc@4ax.com...
> On Fri, 22 Oct 2004 22:17:17 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>>As far as "line sequential" versus "text files" - many (most?) PC and Unix 
>>COBOL
>>compilers allow *some* but not all "control characters" within "Line 
>>Sequential"
>>files.  They certainly allow most (but probably not all) Packed-Decimal and
>>Binary values for numeric fields.
>
> If they disallow any control character, as they must, they have
> effectively disallowed binary values. If they disallow null or tab, as
> some do for tab compression, they have disallowed packed.
>
> The essential features of this format are portability and editability.
> Allowing binary stuff sabotages the Standard for Information
> Interchange. 


0
wmklein (2605)
10/23/2004 5:27:27 AM
..    On  22.10.04
  wrote  robert@wagner.net.yourmammaharvests (Robert Wagner)
     on  /COMP/LANG/COBOL
     in  ofvin01mi23u83jbjvoqhvf8mk4e5jkp8l@4ax.com
  about  Re: Report enhancements


RW>>> The Cobol standard does not specify file formats. They are
RW>>> implementer-defined, an euphemism for non-standard.

RW> I'd say a Cobol compiler that cannot read a sequential file written
RW> by a sort, another language and another Cobol compiler, all running
RW> on the same platform, is using a non-standard file format.

   Now these are two contradictory statements. Each implementor would  
set up his own file system, which is the standard file system of his  
operating system. On Unisys' OS/1100 this is the PCIOS or Processor  
Common Input-Output-System, with processor meaning here langauge  
processor, i.e. compiler, but as the name suggests, while other file  
formats are possible, all programs produced by (standard) compilers  
are able to read and write such a PCIOS-file. Such a file consists of  
records of variable length, but the control words are normally hidden  
to user programs.

   But no one would imagine that you would take a disk pack from an  
OS/1100 machine and try to read it on an IBM machine; one would write  
a tape, and use standard formats such as the ANSI tape format for  
information interchange or the IBM tape format, as the German banking  
system decided to do.

   One gets into problems, though, when one has an operating system  
like Unix, Mac, or DOS/Windows, which does not have a file system  
based on records but on streams of bytes, and then you have several  
competing compiler vendors who have to find their own solutions on how  
to implement a record based file system on top of an operating system  
which doesn't have it on its own. This is bound to lead to  
incompatibilities.

   But I understand that "The Open Group" (formerly known as X/Open)  
has issued recommendations on compatible record file systems,  
especially ISAM files.

   It is in _this_ context alone that your previous statement:

>>> The only standard we have is ASCII (despite Micro Focus' attempt
>>> to screw it up by inserting nulls). Thus, line sequential files
>>> are standardized whereas ANS85 sequential are non-standard.

   makes some sense, but only some.

   E.g. the standard in the German banking system for transfer of  
payment data is either a tape (in EBCDIC, with packed decimal  
fields...) or a file on a floppy disk, starting with 8-inch in some  
standard format (DIN 66237 and IBM 3740) or smaller floppies in MS-DOS  
format (HD or DD), and sequential files on it.  The same standard  
applies for payment data transmitted via data communications. The  
incompatibilities between Unix, Max and PC are thrown out in favor of  
a simple sequential file without ANY record separator, but a fixed  
length of 128 bytes for record chunks. The three OS "standards" would  
require a LF, a CR or a CR/LF pair to separate lines in a text file.  
But these payment instructions are no text file...

   Talking about ASCII as a standard, the records would have to be  
separated by the RS or Record Separator character (decimal 30).


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

Hinl�nglicher Stoff zum Stillschweigen. -G.C.Lichtenberg
0
l.willms1 (637)
10/23/2004 7:55:00 AM
On Fri, 22 Oct 2004 22:13:40 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
>news:ofvin01mi23u83jbjvoqhvf8mk4e5jkp8l@4ax.com...
>> On Fri, 22 Oct 2004 16:25:49 GMT, "William M. Klein"
>> <wmklein@nospam.netcom.com> wrote:
>>
>>>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>>>news:im6in05frv6o0k6jiedsatjall65e0b86p@4ax.com...
>>>> On 21 Oct 2004 22:41:53 -0700, riplin@Azonic.co.nz (Richard) wrote:
>>>>
>>><snip>
>>>> The Cobol standard does not specify file formats. They are
>>>> implementer-defined, an euphemism for non-standard. The only standard
>>>> we have is ASCII (despite Micro Focus' attempt to screw it up by
>>>> inserting nulls). Thus, line sequential files are standardized whereas
>>>> ANS85 sequential are non-standard.
>>>>
>>>
>>>Saying that "implementer-defined is an euphemism for non-standard"
>>>
>>>shows a SERIOUS misunderstanding of what is and is not standard - in a COBOL
>>>context.  If you had said non-portable, I probably would have agreed with you,
>>>but non-standard (even if it isn't "non-Standard) simply is wrong.
>>
>> I'd say a Cobol compiler that cannot read a sequential file written by
>> a sort, another language and another Cobol compiler, all running on
>> the same platform, is using a non-standard file format.
>
>What "standard"? And who provides the "sort" program?

As far as I can tell, there is no standard defining a sequential flat
file, commonly known as fixed-length record sequential. Many people,
such as the authors of sort and other compilers, think there is a de
facto standard.

>Personally, I suspect that MOST (but certainly NOT all) operating systems 
>provide an IMPLEMENTOR definiton of what a "text" file needs to be for that 
>environment.  Therefore, I would expect that MOST products targetted at that 
>specific operating system will provide at least SOME option to handle such text 
>files.  On the other hand, there are so many variables, that even this is a 
>stretch - and when it comes to CLAIMING that what an Operating System vendor 
>defines as a text file for THEIR specific OS is "standard" that simply is a 
>STETCH for any commonly used meaning of "standard" that I am aware of. 

Cobol sequential, discussed above, is not necessarily a "text file".
The common extension "line sequential" is a text file, for which there
are standards: ISO-646 (7-bit) and ISO-8859 (8-bit), and the more
recent ISO-10646 (Unicode), which is backward-compatible with the
first two. Operating systems I've worked on in the last 20 years
followed those standards. As a result, text files were portable
between platforms.

Even EBCDIC platforms, which obviously did not comply, were compatible
enough that text files were routinely transported (by FTP or NDM),
with automatic code set translation.

0
robert6624 (636)
10/23/2004 12:40:40 PM
On 23 Oct 2004 07:55:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>.    On  22.10.04
>  wrote  robert@wagner.net.yourmammaharvests (Robert Wagner)
>     on  /COMP/LANG/COBOL
>     in  ofvin01mi23u83jbjvoqhvf8mk4e5jkp8l@4ax.com
>  about  Re: Report enhancements
>
>
>RW>>> The Cobol standard does not specify file formats. They are
>RW>>> implementer-defined, an euphemism for non-standard.
>
>RW> I'd say a Cobol compiler that cannot read a sequential file written
>RW> by a sort, another language and another Cobol compiler, all running
>RW> on the same platform, is using a non-standard file format.
>
>   Now these are two contradictory statements.

Not really. In the case of fixed-length "record sequential", there is
a de facto standard -- all data, no controls, like tape but without
blocks. The reader must know the logical record length.

> Each implementor would  
>set up his own file system, which is the standard file system of his  
>operating system. On Unisys' OS/1100 this is the PCIOS or Processor  
>Common Input-Output-System, with processor meaning here langauge  
>processor, i.e. compiler, but as the name suggests, while other file  
>formats are possible, all programs produced by (standard) compilers  
>are able to read and write such a PCIOS-file. Such a file consists of  
>records of variable length, but the control words are normally hidden  
>to user programs.

IBM mainframes have at least three formats: fixed-length QSAM,
variable-length QSAM and VSAM (ESDS).

>   But no one would imagine that you would take a disk pack from an  
>OS/1100 machine and try to read it on an IBM machine; one would write  
>a tape, and use standard formats such as the ANSI tape format for  
>information interchange or the IBM tape format, as the German banking  
>system decided to do.

In the US, we haven't used tape or floppy in years, and CD/DVD is used
only when volume is exceptionally large. Files are transferred through
networks, where it is reasonable and common to transfer a disk file in
native format. 

I say that based on my experience with large companies and government
agencies that transfer large volumes of data. I don't doubt there are
small shops still using floppies or even tapes. I wonder what they'll
do when PCs no longer come with floppy drives. 

>   One gets into problems, though, when one has an operating system  
>like Unix, Mac, or DOS/Windows, which does not have a file system  
>based on records but on streams of bytes, and then you have several  
>competing compiler vendors who have to find their own solutions on how  
>to implement a record based file system on top of an operating system  
>which doesn't have it on its own. This is bound to lead to  
>incompatibilities.

It's not much of a problem because all our 'real data' is now in
databases. Flat files are used for interchange. They're usually in
ASCII (perhaps with XML) although fixed-length 'record sequential' is
a possibility.

>   But I understand that "The Open Group" (formerly known as X/Open)  
>has issued recommendations on compatible record file systems,  
>especially ISAM files.

Too late, big shops abandoned ISAM years ago. 

>   It is in _this_ context alone that your previous statement:
>
>>>> The only standard we have is ASCII (despite Micro Focus' attempt
>>>> to screw it up by inserting nulls). Thus, line sequential files
>>>> are standardized whereas ANS85 sequential are non-standard.
>
>   makes some sense, but only some.
>
>   E.g. the standard in the German banking system for transfer of  
>payment data is either a tape (in EBCDIC, with packed decimal  
>fields...) or a file on a floppy disk, starting with 8-inch in some  
>standard format (DIN 66237 and IBM 3740) or smaller floppies in MS-DOS  
>format (HD or DD), and sequential files on it.  The same standard  
>applies for payment data transmitted via data communications. The  
>incompatibilities between Unix, Max and PC are thrown out in favor of  
>a simple sequential file without ANY record separator, but a fixed  
>length of 128 bytes for record chunks. The three OS "standards" would  
>require a LF, a CR or a CR/LF pair to separate lines in a text file. 

The German banking system is not following an ISO Standard. As a
result, they are wasting bandwidth by padding records.

The US ACH system is similar. It uses fixed-length 94-byte records
with no terminator. I suspect that was inherited from batch submission
via tape. The more modern SWIFT system uses variable-length records
terminated by CrLf. SWIFT is the choice for international and will
someday replace ACH in the US.

Translation between Lf, Cr and Cr/Lf is trivil. It's done by FTP and
other communication programs. Nearly all Unix file systems handle it,
as well. 

File format should be independent of recording media. Linking them is
a holdover from tape. 

>   Talking about ASCII as a standard, the records would have to be  
>separated by the RS or Record Separator character (decimal 30).

I'm not convinced the standard requires Record Separator. Cr and Lf
are the de facto standard.
0
robert6624 (636)
10/23/2004 2:17:11 PM
l.willms@jpberlin.de (Lueko Willms) wrote 

>    But I understand that "The Open Group" (formerly known as X/Open)  
> has issued recommendations on compatible record file systems,  
> especially ISAM files.

Yes, it was the C-ISAM file format developed by Informix and used by
them for their database system and by MicroFocus since Level II Cobol
in 1984 or so.
0
riplin (4127)
10/23/2004 5:57:20 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> On 21 Oct 2004 22:41:53 -0700, riplin@Azonic.co.nz (Richard) wrote:
> 
> >While I had already suggested that he _could_ do it in several
> >different ways with MF, the way that _he_ chose to do it is entirely
> >up to him, in this case using a perfectly standard ANS85 file type
> >rather than some extension.
> 
> Tell Daniel Vidal under subject "COBOL set for AIX .." that his
> sequential file is "perfectly standard ANS85".

That is irrelevant to the issue.  Rick had used entirely standard
ANS85 Cobol syntax and produced an entirely standard text file that
was perfectly acceptable to whatever he wanted to feed it into.

Other systems may not be able to do that and thus may need to use
non-standard (ANS85) vendor extensions, if they have those available.
 
> The Cobol standard does not specify file formats. They are
> implementer-defined, an euphemism for non-standard. The only standard
> we have is ASCII (despite Micro Focus' attempt to screw it up by
> inserting nulls). Thus, line sequential files are standardized whereas
> ANS85 sequential are non-standard.

You are confused.  'Line sequential' is also just as
'implementor-defined' as every other file format.  Fujitsu defaults to
using specified record lengths, MF defaults to null insertion, others
may not have it at all.  Terminators may be combinations of CR and/or
LF.

If Rick reliably gets the output that _he_ requires then the program
works.
0
riplin (4127)
10/23/2004 6:39:15 PM
..     Am  23.10.04
 schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
     bei  /COMP/LANG/COBOL
      in  2okkn0t8qg2c69vrgdd5pf3t15u0b0qarf@4ax.com
   ueber  Re: Standard and COBOL file formats (was: Report enhancements)


   Lots of stuff, which is, in my opinion, confusing many different  
aspects.

   When I talk about a file format, then this concerns foremost how  
the _file_ is organised, how the end of the file is recognized and  
what are the atomic elements of a file. This is certainly not  
independent of the recording medium.

   There are filesystems whose files are divided up into records, and  
there are other filesystems whose files are just streams of bytes,  
without any other subdivision. If there is a subdivision into logical  
records, this is completely up to the application to set and recognize  
it, and all knowledge about this record structure is completely and  
solely in the hands of that application.

   This is different from a record based file system, like those on  
the historic mainframe systems, where any program can read any file  
recordwise, without requiring any knowledge about the content or  
structure of the record, because the operating system or some system  
utility does provide only a record interface.

   Another question is encoding of the information contained in the  
records or the datastream, and -- as far as text is concerned -- the  
character set.

   ASCII is a character set, but does not define a record or file  
format.


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)
10/23/2004 6:53:00 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> >has issued recommendations on compatible record file systems,  
> >especially ISAM files.
> 
> Too late, big shops abandoned ISAM years ago. 

It wasn't 'too late' when the standard was developed a quarter century
ago.
 
> I'm not convinced the standard requires Record Separator. Cr and Lf
> are the de facto standard.

Carriage Return and Line Feed are 'standard' for typewriters and
derivitives, advanced models (around 1900) had a lever which would do
both together.  Their use on computers derives from teletypewriters. 
Later, 'glass teletypes' used these.

CR/LF is 'standard' for CP/M and MS-DOS. CR is 'standard' for Mac, LF
is 'standard' for Unix/Linux.
0
riplin (4127)
10/23/2004 10:03:00 PM
On 23 Oct 2004 11:39:15 -0700, riplin@Azonic.co.nz (Richard) wrote:

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

>> The Cobol standard does not specify file formats. They are
>> implementer-defined, an euphemism for non-standard. The only standard
>> we have is ASCII (despite Micro Focus' attempt to screw it up by
>> inserting nulls). Thus, line sequential files are standardized whereas
>> ANS85 sequential are non-standard.
>
>You are confused.  'Line sequential' is also just as
>'implementor-defined' as every other file format. 

No, it is not implementor-defined; it is defined by ISO-646 and
industry practice. 

> Fujitsu defaults to
>using specified record lengths, MF defaults to null insertion, others
>may not have it at all.  Terminators may be combinations of CR and/or
>LF.

When the compiler produces a non-standard file by default, we find a
way to make it deliver a standard one. In the case of MF, we turn off
null-insertion; in the case of Fujitsu, we supply the record length.

For a standards-friendly forum, I'm surprised at the amount of
resistance here to a standardized file format .. one that has been
very widely used for 30 years. 

0
robert6624 (636)
10/23/2004 10:59:30 PM
On 23 Oct 2004 18:53:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>.     Am  23.10.04
> schrieb  robert@wagner.net.yourmammaharvests (Robert Wagner)
>     bei  /COMP/LANG/COBOL
>      in  2okkn0t8qg2c69vrgdd5pf3t15u0b0qarf@4ax.com
>   ueber  Re: Standard and COBOL file formats (was: Report enhancements)
>
>
>   Lots of stuff, which is, in my opinion, confusing many different  
>aspects.
>
>   When I talk about a file format, then this concerns foremost how  
>the _file_ is organised, how the end of the file is recognized and  
>what are the atomic elements of a file. This is certainly not  
>independent of the recording medium.

Putting aside tapes, which are obsolete, file details are a function
of the file system,  not recording medium. For instance, file length
is not in the file body (there is no end-of-file mark), it is in the
file system's directory. If I copy a file from platform A to B, the
length is not copied with the file, it is recomputed and stored into
B's directory.

>   There are filesystems whose files are divided up into records, and  
>there are other filesystems whose files are just streams of bytes,  
>without any other subdivision. If there is a subdivision into logical  
>records, this is completely up to the application to set and recognize  
>it, and all knowledge about this record structure is completely and  
>solely in the hands of that application.

It is up to the standard library, in this case stdio, not the
application. Cobol could/should call it rather than reinventing the
wheel. It is readily available in a dll/so.

>   This is different from a record based file system, like those on  
>the historic mainframe systems, where any program can read any file  
>recordwise, without requiring any knowledge about the content or  
>structure of the record, because the operating system or some system  
>utility does provide only a record interface.

Yes, mainframe file systems store record length and organization in a
catalog whereas Win, Unix et al. do not. (Unless one is using
CA-Realia for JCL, which turns a PC into a z/OS mainframe). As a
result, the file system must get that information from the
application. That shouldn't be an objection in the context of Cobol
because the language was designed to REQUIRE that information, even
though it is superfluous on a mainframe. 

>   Another question is encoding of the information contained in the  
>records or the datastream, and -- as far as text is concerned -- the  
>character set.
>
>   ASCII is a character set, but does not define a record or file  
>format.

Thirty years of industry practice has defined an end-of-record mark.
It is a de facto standard (per platform).
0
robert6624 (636)
10/23/2004 10:59:31 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:4bhkn0legudbchgppo87tgeffasb204otc@4ax.com...
> On Fri, 22 Oct 2004 22:13:40 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
<snip>
> Cobol sequential, discussed above, is not necessarily a "text file".
> The common extension "line sequential" is a text file, for which there
> are standards: ISO-646 (7-bit) and ISO-8859 (8-bit), and the more
> recent ISO-10646 (Unicode), which is backward-compatible with the
> first two. Operating systems I've worked on in the last 20 years
> followed those standards. As a result, text files were portable
> between platforms.

Robert,
  You are (once again) simply NOT admiting when you are wrong - but instead 
digging yourself into deeper and deeper holes of mis-information.

ISO-646, ISO-8859, and ISO-10646 say ABSOLUTELY nothing about files (flat, 
sequential, line sequential or otherwise). Those are CHARACTER SET Standards.

Again, your claim that  "line sequential" is a "text file" also has no basis in 
fact - although a line sequentail file may (and for portability probably SHOULD) 
be limited to "text" characters, that isn't a restriction (that I am aware of). 
A "ANSI/ISO defined COBOL sequential file" certainly may (also) be limited to 
"text characters" - and in fact if the ANSI/ISO "code-set" clause is used, it 
must be composed of  USAGE DISPLAY (or in '02 National) fields - with "sign is 
separate" for numeric fields.



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


0
wmklein (2605)
10/24/2004 12:37:44 AM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:9nnln0pieo7moso3nruk7ellqjuu1hg8ki@4ax.com...
> On 23 Oct 2004 11:39:15 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
>>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
<snip>
>>You are confused.  'Line sequential' is also just as
>>'implementor-defined' as every other file format.
>
> No, it is not implementor-defined; it is defined by ISO-646 and
> industry practice.
>

Find ANY reference to "file formats" being defined in ISO-646 - and post the 
quote (and where you found it in that Standard).

PLEASE, stop making such indefensible (and erroneous) statements.


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


0
wmklein (2605)
10/24/2004 12:46:35 AM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:2okkn0t8qg2c69vrgdd5pf3t15u0b0qarf@4ax.com...
> On 23 Oct 2004 07:55:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
>
<snip>
>>RW> I'd say a Cobol compiler that cannot read a sequential file written
>>RW> by a sort, another language and another Cobol compiler, all running
>>RW> on the same platform, is using a non-standard file format.
>>
>>   Now these are two contradictory statements.
>
> Not really. In the case of fixed-length "record sequential", there is
> a de facto standard -- all data, no controls, like tape but without
> blocks. The reader must know the logical record length.
>

WRONG AGAIN !!!

What you say is true for most (not all) Windows, Unix, and Linux systems (with 
COBOL).  It isn't true for ANY "mainframe" or "mid-range" Operating system that 
I am aware of (which doesn't mean that there isn't one or two that works that 
way).

You will note that the BLOCK CONTAINS clause is still Standard (even in the '02 
Standard) - although many (again not all) PC or "workstation" compilers treat it 
as "documentary".

The current ('85 and '02) Standards even allow for sequential "spanned" recrods 
where the record size is LARGER than the block size.

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


0
wmklein (2605)
10/24/2004 1:01:28 AM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:56oln0pv7hgsl7gh7mma1jfq8euhdjiqbl@4ax.com...
> On 23 Oct 2004 18:53:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
<snip>
>
> Putting aside tapes, which are obsolete,

Robert,
   Start living in the real world - not just the environments that you know. 
Your accuracy level today is even lower than usual.



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



0
wmklein (2605)
10/24/2004 1:03:26 AM
On Sun, 24 Oct 2004 01:01:28 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
>news:2okkn0t8qg2c69vrgdd5pf3t15u0b0qarf@4ax.com...
>> On 23 Oct 2004 07:55:00 GMT, l.willms@jpberlin.de (Lueko Willms)
>> wrote:
>>
><snip>
>>>RW> I'd say a Cobol compiler that cannot read a sequential file written
>>>RW> by a sort, another language and another Cobol compiler, all running
>>>RW> on the same platform, is using a non-standard file format.
>>>
>>>   Now these are two contradictory statements.
>>
>> Not really. In the case of fixed-length "record sequential", there is
>> a de facto standard -- all data, no controls, like tape but without
>> blocks. The reader must know the logical record length.
>>
>
>WRONG AGAIN !!!
>
>What you say is true for most (not all) Windows, Unix, and Linux systems (with 
>COBOL).  It isn't true for ANY "mainframe" or "mid-range" Operating system that 
>I am aware of (which doesn't mean that there isn't one or two that works that 
>way).
>
>You will note that the BLOCK CONTAINS clause is still Standard (even in the '02 
>Standard) - although many (again not all) PC or "workstation" compilers treat it 
>as "documentary".
>
>The current ('85 and '02) Standards even allow for sequential "spanned" recrods 
>where the record size is LARGER than the block size.

When it introduced SMS/Tivoli in 1992, IBM moved buffer management
_out_ of applications and JCL. On input, it gets blocksize from the
filedef; on output, it uses SDB. 

Mainframe and AS/400 Cobol programs I've seen in the last ten years
said BLOCK CONTAINS ZERO.


0
robert6624 (636)
10/24/2004 3:51:40 AM
Neither BLOCK CONTAINS ZERO (nor DCB=BLKSIZE=0) nor SMS <sic> *changes* the way 
that blocking occurs for the actual physical file.  Again, read your original 
statement which says

"a de facto standard -- all data, no controls, "

Simply NOT true for IBM mainframe files (nor - I suspect - for most mainframes)

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:9t8mn01uadsccc2vgjm1tgo0jq8lrqd4vc@4ax.com...
> On Sun, 24 Oct 2004 01:01:28 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>>news:2okkn0t8qg2c69vrgdd5pf3t15u0b0qarf@4ax.com...
>>> On 23 Oct 2004 07:55:00 GMT, l.willms@jpberlin.de (Lueko Willms)
>>> wrote:
>>>
>><snip>
>>>>RW> I'd say a Cobol compiler that cannot read a sequential file written
>>>>RW> by a sort, another language and another Cobol compiler, all running
>>>>RW> on the same platform, is using a non-standard file format.
>>>>
>>>>   Now these are two contradictory statements.
>>>
>>> Not really. In the case of fixed-length "record sequential", there is
>>> a de facto standard -- all data, no controls, like tape but without
>>> blocks. The reader must know the logical record length.
>>>
>>
>>WRONG AGAIN !!!
>>
>>What you say is true for most (not all) Windows, Unix, and Linux systems (with
>>COBOL).  It isn't true for ANY "mainframe" or "mid-range" Operating system 
>>that
>>I am aware of (which doesn't mean that there isn't one or two that works that
>>way).
>>
>>You will note that the BLOCK CONTAINS clause is still Standard (even in the 
>>'02
>>Standard) - although many (again not all) PC or "workstation" compilers treat 
>>it
>>as "documentary".
>>
>>The current ('85 and '02) Standards even allow for sequential "spanned" 
>>recrods
>>where the record size is LARGER than the block size.
>
> When it introduced SMS/Tivoli in 1992, IBM moved buffer management
> _out_ of applications and JCL. On input, it gets blocksize from the
> filedef; on output, it uses SDB.
>
> Mainframe and AS/400 Cobol programs I've seen in the last ten years
> said BLOCK CONTAINS ZERO.
>
> 


0
wmklein (2605)
10/24/2004 3:56:32 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> >records, this is completely up to the application to set and recognize  
> >it, and all knowledge about this record structure is completely and  
> >solely in the hands of that application.
> 
> It is up to the standard library, in this case stdio, not the
> application. Cobol could/should call it rather than reinventing the
> wheel. It is readily available in a dll/so.

It is entirely up to the application using stdio whether the file is
read using fgets() or read(), the library does not make these
decisions.
 
> Thirty years of industry practice has defined an end-of-record mark.
> It is a de facto standard (per platform).

Thirty years of industry practice has defined _several_ 'end-of-record
marks'. Actually they aren't 'end-of-record' at all anyway, they are
'end-of-line'.  Typewriters/Teletypes/printers are _line_ orientated
devices, not record orientated.  The text format is based on this line
orientation.
0
riplin (4127)
10/24/2004 4:50:59 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> >You are confused.  'Line sequential' is also just as
> >'implementor-defined' as every other file format. 
> 
> No, it is not implementor-defined; it is defined by ISO-646 and
> industry practice. 

When one defines a file one does not say: ORGANIZATION ISO-646, one
says: ORGANIZATION LINE SEQUENTIAL and then one gets what the compiler
writer has implemented (also depending on compiler and run-time
options).

> When the compiler produces a non-standard file by default, we find a
> way to make it deliver a standard one. In the case of MF, we turn off
> null-insertion; in the case of Fujitsu, we supply the record length.

Or, for Fujitsu use the supplied environment variable.  In Rick's case
he got exactly the format he required by other means using entirely
standard ANS85 contructs.
 
> For a standards-friendly forum, I'm surprised at the amount of
> resistance here to a standardized file format .. one that has been
> very widely used for 30 years.

I am quite surprised that you seem to completely miss the point, once
again.  What difference is there between the file that Rick wrote and
a 'text file' ? What is it about the file that he output that doesn't
fit what you call 'standard' ?

All you seem to be objecting to is that it wasn't done _your_ way, a
way that you seem to claim is the only 'correct' way.
0
riplin (4127)
10/24/2004 4:59:23 AM
On 23 Oct 2004 21:59:23 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>> >You are confused.  'Line sequential' is also just as
>> >'implementor-defined' as every other file format. 
>> 
>> No, it is not implementor-defined; it is defined by ISO-646 and
>> industry practice. 
>
>When one defines a file one does not say: ORGANIZATION ISO-646, one
>says: ORGANIZATION LINE SEQUENTIAL and then one gets what the compiler
>writer has implemented (also depending on compiler and run-time
>options).

Whatever the semantics, users WANT it to be 'ASCII text'. When the
compiler company supplies something else, it hears complaints until it
provides an option to give users what they want.

>> For a standards-friendly forum, I'm surprised at the amount of
>> resistance here to a standardized file format .. one that has been
>> very widely used for 30 years.
>
>I am quite surprised that you seem to completely miss the point, once
>again.  What difference is there between the file that Rick wrote and
>a 'text file' ? What is it about the file that he output that doesn't
>fit what you call 'standard' ?

Nothing, but his records are all the same length. In his tab-delimited
example, description is padded with spaces. That's a waste of
bandwidth.

>All you seem to be objecting to is that it wasn't done _your_ way, a
>way that you seem to claim is the only 'correct' way.

It's not my way, it's they way millions of files are formatted every
day. 

0
robert6624 (636)
10/24/2004 10:32:36 AM
On Sun, 24 Oct 2004 03:56:32 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Neither BLOCK CONTAINS ZERO (nor DCB=BLKSIZE=0) nor SMS <sic> *changes* the way 
>that blocking occurs for the actual physical file.  

You can read about SMS here:
http://www.storage.ibm.com/software/opt/index.html

When you create a new file (open output) with no block size specified
in program nor JCL, how IS the size determined?

>Again, read your original 
>statement which says
>
>"a de facto standard -- all data, no controls, "
>
>Simply NOT true for IBM mainframe files (nor - I suspect - for most mainframes)

The discussion is about file exchange. If a record sequential file of
fixed-length records  is transferred from mainframe to another
platform, it will have "all data, no controls".

0
robert6624 (636)
10/24/2004 10:32:37 AM
On 23 Oct 2004 21:50:59 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
>
>> >records, this is completely up to the application to set and recognize  
>> >it, and all knowledge about this record structure is completely and  
>> >solely in the hands of that application.
>> 
>> It is up to the standard library, in this case stdio, not the
>> application. Cobol could/should call it rather than reinventing the
>> wheel. It is readily available in a dll/so.
>
>It is entirely up to the application using stdio whether the file is
>read using fgets() or read(), the library does not make these
>decisions.

For text files, fgets() and fputs() are not only ten times faster but
also insure the file will be compatible with others produced on the
same platform (at least). If Micro Focus and Fujitsu had used fputs(),
they wouldn't have produced the anomalies they did.
 
>> Thirty years of industry practice has defined an end-of-record mark.
>> It is a de facto standard (per platform).
>
>Thirty years of industry practice has defined _several_ 'end-of-record
>marks'. 

One per platform. It's not hard to deal with. Many/most Unix versions
of fgets() handle unconverted Win files with no problem. The only
program I've seen fail is vi, which evidently doesn't use fgets().

>Actually they aren't 'end-of-record' at all anyway, they are
>'end-of-line'.  Typewriters/Teletypes/printers are _line_ orientated
>devices, not record orientated.  The text format is based on this line
>orientation.

True but so what? The important point is having a standard terminator.
0
robert6624 (636)
10/24/2004 10:32:38 AM
Robert Wagner wrote:
> On Fri, 22 Oct 2004 12:43:52 -0400, Donald Tees
> <donald_tees@sympatico.ca> wrote:
> 
> 
>>You can get a "standard" "Line sequential" file with most Cobol's, but 
>>even then it is only standard according to an arbitrary definition for a 
>>specific platform.  It is not standard the way a text file is "standard".
> 
> 
> What's the difference between text, line sequential and ASCII? I
> thought they were synonymous. 

Text is composed of letters, perhaps on a computer, perhaps not. Line 
sequential is a Cobol term.,  Ascii is a characatrer set. They bear no 
relationship to each other (per se) what-so-ever, until someone states 
such a relationship in a sentence.

Donald


0
donald_tees (563)
10/24/2004 2:06:56 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> Nothing, but his records are all the same length. In his tab-delimited
> example, description is padded with spaces. That's a waste of
> bandwidth.

So, after all this ranting from you, the only actual criticism is that
it has a few spaces in the file.  In fact using Report Writer in that
way would give fixed length fields anyway.

This is actually an advantage, programs can read the data by using the
tabs as field separators, or, if they can't read it that way they can
use the fixed field lengths and skip the tabs.

> >All you seem to be objecting to is that it wasn't done _your_ way, a
> >way that you seem to claim is the only 'correct' way.
> 
> It's not my way, it's they way millions of files are formatted every
> day.

Your rant started when Rick used the completely ANS85 Cobol SEQUENTIAL
and created a perfectly good file exactly as required.  Your only
objection was that he didn't use the MF extension (to ANS85) of LINE
SEQUENTIAL, as you would have, to create an identical file.

Or was it just that you didn't notice how his resulting file looked.

All your whining about 'standards' is completely bogus.  The file was
completely within all you were winging about. It seems simply that you
are trying to get Rick to use LINE SEQUENTIAL.

I have great difficulty in believing that you were ever a manager of
anything, the way that you argue and rant makes you appear to be a
frustrated control freak.
0
riplin (4127)
10/24/2004 7:04:56 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:envmn0h0ga3ppmnami2927quk24p2lp460@4ax.com...
> On 23 Oct 2004 21:59:23 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
<snip>
>>When one defines a file one does not say: ORGANIZATION ISO-646, one
>>says: ORGANIZATION LINE SEQUENTIAL and then one gets what the compiler
>>writer has implemented (also depending on compiler and run-time
>>options).
>
> Whatever the semantics, users WANT it to be 'ASCII text'. When the
> compiler company supplies something else, it hears complaints until it
> provides an option to give users what they want.
>

I think that if "line sequential" produced ASCII data from an IBM mainframe 
prorgram THEN the users would complain.

Robert,
  Just admit that "line sequential" (like record sequential) is what the 
implementor WANTS it to be (in response to THEIR users - for THAT environment). 
There is nothing standard about the format (or the contents - or the separators)

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


0
wmklein (2605)
10/24/2004 7:46:31 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:qj0nn0l3kmlmgpbsgc2im1rbvtj0efifpj@4ax.com...
> On 23 Oct 2004 21:50:59 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
<snip>
>>> Thirty years of industry practice has defined an end-of-record mark.
>>> It is a de facto standard (per platform).
>>
>>Thirty years of industry practice has defined _several_ 'end-of-record
>>marks'.
>
> One per platform. It's not hard to deal with. Many/most Unix versions
> of fgets() handle unconverted Win files with no problem. The only
> program I've seen fail is vi, which evidently doesn't use fgets().
>

So, "one per platform" as the "standard"

Now, tell me how does this differ from "COBOL Standard record sequential" files? 
(Remembering tha tyour originial claim was that the COBOL types weren't 
"standard" - but "line sequential" was)


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


0
wmklein (2605)
10/24/2004 7:57:42 PM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
news:lqrmn0dcdo87pnf405beki6r2j1m21or92@4ax.com...
> On Sun, 24 Oct 2004 03:56:32 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>>Neither BLOCK CONTAINS ZERO (nor DCB=BLKSIZE=0) nor SMS <sic> *changes* the 
>>way
>>that blocking occurs for the actual physical file.
>
> You can read about SMS here:
> http://www.storage.ibm.com/software/opt/index.html
>
> When you create a new file (open output) with no block size specified
> in program nor JCL, how IS the size determined?
>
>>Again, read your original
>>statement which says
>>
>>"a de facto standard -- all data, no controls, "
>>
>>Simply NOT true for IBM mainframe files (nor - I suspect - for most 
>>mainframes)
>
> The discussion is about file exchange. If a record sequential file of
> fixed-length records  is transferred from mainframe to another
> platform, it will have "all data, no controls".
>

Certainly not always true,  See the Micro Focus VRECGEN utility. 


0
wmklein (2605)
10/24/2004 8:00:34 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> >You are confused.  'Line sequential' is also just as
> >'implementor-defined' as every other file format. 
> 
> No, it is not implementor-defined; it is defined by ISO-646 and
> industry practice. 

LINE SEQUENTIAL is implementor defined in ANS85 (ie current
compilers). There is nothing in the standard that defines LINE
SEQUENTIAL as anything, let alone as ISO-646 and whatever 'industry
practice' you think applies.


> When the compiler produces a non-standard file by default, 

... as defined by the implementor.

> we find a
> way to make it deliver a standard one. In the case of MF, we turn off
> null-insertion; in the case of Fujitsu, we supply the record length.
 
Or _we_ use other mechanisms to get the files that we require, such as
DISPLAY to stdout, or SEQUENTIAL files with CR/LF control codes.
0
riplin (4127)
10/24/2004 10:05:39 PM
On Sun, 24 Oct 2004 20:00:34 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:


>> The discussion is about file exchange. If a record sequential file of
>> fixed-length records  is transferred from mainframe to another
>> platform, it will have "all data, no controls".
>>
>
>Certainly not always true,  See the Micro Focus VRECGEN utility. 

I said fixed-length records. VRECGEN is for variable-length records. 
0
robert6624 (636)
10/25/2004 2:47:49 AM
On Sun, 24 Oct 2004 19:57:42 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message 
>news:qj0nn0l3kmlmgpbsgc2im1rbvtj0efifpj@4ax.com...
>> On 23 Oct 2004 21:50:59 -0700, riplin@Azonic.co.nz (Richard) wrote:
>>
><snip>
>>>> Thirty years of industry practice has defined an end-of-record mark.
>>>> It is a de facto standard (per platform).
>>>
>>>Thirty years of industry practice has defined _several_ 'end-of-record
>>>marks'.
>>
>> One per platform. It's not hard to deal with. Many/most Unix versions
>> of fgets() handle unconverted Win files with no problem. The only
>> program I've seen fail is vi, which evidently doesn't use fgets().
>>
>
>So, "one per platform" as the "standard"
>
>Now, tell me how does this differ from "COBOL Standard record sequential" files? 
>(Remembering that your originial claim was that the COBOL types weren't 
>"standard" - but "line sequential" was)

1a.  Cobol records can contain binary and packed fields; ASCII records
do not. Commonly used import software such as spreadsheets and
databases cannot handle binary and packed. 

1b. There is no standard format for binary and packed. 

2. The length of Cobol records is indeterminate; ASCII records have a
terminator.

3.  Because of 1., Cobol files cannot be converted from EBCDIC to
ASCII easily. The conversion program must know about record layout.
With ASCII files, the whole record can be converted without knowing
layout.

4. Cobol display numbers are usually missing decimal point and have an
'overpunch' sign. Although this is standard, it is ambiguous. ASCII
numbers contain an explicit decimal and separate sign, by de facto
convention. The receiver can read the value by sight.

5. Comma-delimited or tab-delimited make ASCII files much easier to
parse, and smaller as well. It is not required by the de facto
standard, but is very common. 





0
robert6624 (636)
10/25/2004 2:47:50 AM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:qj0nn0l3kmlmgpbsgc2im1rbvtj0efifpj@4ax.com...
[snip]
> For text files, fgets() and fputs() are not only ten times faster but
> also insure the file will be compatible with others produced on the
> same platform (at least). If Micro Focus and Fujitsu had used fputs(),
> they wouldn't have produced the anomalies they did.

Working Draft, 1997-11-21, WG14/N794 J11/97-158,
C Programming Language, page 276,
"7.13.2 Streams"

"1 Input and output, whether to or from physical devices such
as terminals and tape drives, or whether to or from files
supported on structured storage devices, are mapped into
logical data streams, whose properties are more uniform than
their various inputs and outputs. Two forms of mapping are
supported, for text streams and for binary streams.[197]"

"2 A text stream is an ordered sequence of characters
composed into lines, each line consisting of zero or more
characters plus a terminating new-line character. Whether the
last line requires a terminating new-line character is
implementation-defined. Characters may have to be added,
altered, or deleted on input and output to conform to differing
conventions for representing text in the host environment.
Thus, there need not be a one-to-one correspondence
between the characters in a stream and those in the external
representation. Data read in from a text stream will necessarily
compare equal to the data that were earlier written out to that
stream only if: the data consist only of printable characters and
the control characters horizontal tab and new-line; no new-line
character is immediately preceded by space characters; and
the last character is a new-line character. Whether space
characters that are written out immediately before a new-line
character appear when read in is implementation-defined."

"197. An implementation need not distinguish between text
streams and binary streams. In such an implementation, there
need be no new-line characters in a text stream nor any limit
to the length of a line."

Mr Wagner, I see four ways in which text files created by
different C implementations on a single platform may be
incompatible. Interestingly, the "CBL_" *byte-stream* routines
in Micro Focus (and, I beleive, Fujitsu) can be used by an
application programmer to obtain compatibility with any
of the C implementations.



0
ricksmith (875)
10/25/2004 3:02:22 AM
On 24 Oct 2004 15:05:39 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
>
>> >You are confused.  'Line sequential' is also just as
>> >'implementor-defined' as every other file format. 
>> 
>> No, it is not implementor-defined; it is defined by ISO-646 and
>> industry practice. 
>
>LINE SEQUENTIAL is implementor defined in ANS85 (ie current
>compilers). There is nothing in the standard that defines LINE
>SEQUENTIAL as anything, let alone as ISO-646 and whatever 'industry
>practice' you think applies.

Chaos, chaos. We revel in it.

>> When the compiler produces a non-standard file by default, 
>
>.. as defined by the implementor.

No, the standard is defined by CUSTOMERS.

>> we find a
>> way to make it deliver a standard one. In the case of MF, we turn off
>> null-insertion; in the case of Fujitsu, we supply the record length.
> 
>Or _we_ use other mechanisms to get the files that we require, such as
>DISPLAY to stdout, or SEQUENTIAL files with CR/LF control codes.

Last grasp. Anything to preserve chaos and avoid giving customers what
they want.

0
robert6624 (636)
10/25/2004 3:30:14 AM
In article <lqrmn0dcdo87pnf405beki6r2j1m21or92@4ax.com>,
 Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:

> On Sun, 24 Oct 2004 03:56:32 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
> 
> >Neither BLOCK CONTAINS ZERO (nor DCB=BLKSIZE=0) nor SMS <sic> *changes* the 
> >way 
> >that blocking occurs for the actual physical file.  
> 
> You can read about SMS here:
> http://www.storage.ibm.com/software/opt/index.html
> 
> When you create a new file (open output) with no block size specified
> in program nor JCL, how IS the size determined?
> 

SMS selects a block size based on the data class or storage class of the 
file or, depending upon configuration, attempts to guess an 'optimum' 
blocksize.

But the file still gets a blocksize.  And the records are stored with 
block descriptor words and all that jazz...

0
10/25/2004 5:56:16 AM
On Sun, 24 Oct 2004 23:02:22 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:

>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>news:qj0nn0l3kmlmgpbsgc2im1rbvtj0efifpj@4ax.com...
>[snip]
>> For text files, fgets() and fputs() are not only ten times faster but
>> also insure the file will be compatible with others produced on the
>> same platform (at least). If Micro Focus and Fujitsu had used fputs(),
>> they wouldn't have produced the anomalies they did.
>
>Working Draft, 1997-11-21, WG14/N794 J11/97-158,
>C Programming Language, page 276,
>"7.13.2 Streams"
>
>"1 Input and output, whether to or from physical devices such
>as terminals and tape drives, or whether to or from files
>supported on structured storage devices, are mapped into
>logical data streams, whose properties are more uniform than
>their various inputs and outputs. Two forms of mapping are
>supported, for text streams and for binary streams.[197]"
>
>"2 A text stream is an ordered sequence of characters
>composed into lines, each line consisting of zero or more
>characters plus a terminating new-line character. Whether the
>last line requires a terminating new-line character is
>implementation-defined. Characters may have to be added,
>altered, or deleted on input and output to conform to differing
>conventions for representing text in the host environment.
>Thus, there need not be a one-to-one correspondence
>between the characters in a stream and those in the external
>representation. Data read in from a text stream will necessarily
>compare equal to the data that were earlier written out to that
>stream only if: the data consist only of printable characters and
>the control characters horizontal tab and new-line; no new-line
>character is immediately preceded by space characters; and
>the last character is a new-line character. Whether space
>characters that are written out immediately before a new-line
>character appear when read in is implementation-defined."

There's a fair definition of 'ASCII text file'. But the C standard is
not a primary source, it merely describes a de facto standard that had
been in place for decades. 

This is Cobol's LINE SEQUENTIAL.

>"197. An implementation need not distinguish between text
>streams and binary streams. In such an implementation, there
>need be no new-line characters in a text stream nor any limit
>to the length of a line."
>
>Mr Wagner, I see four ways in which text files created by
>different C implementations on a single platform may be
>incompatible. 

ASCII text is not a creature of C. Both C and Cobol are dealing with a
format defined elsewhere, by the operating system. When the operating
system boots, it has to read configuration files BEFORE it loads a
file system.

>Interestingly, the "CBL_" *byte-stream* routines
>in Micro Focus (and, I beleive, Fujitsu) can be used by an
>application programmer to obtain compatibility with any
>of the C implementations.

Those routines are superfluous. Plain vanilla Cobol can read a
'byte-stream' by simply defining a SEQUENTIAL file with record length
of one byte. For a more general solution, make it a RANDOM file with
one-byte records. 

0
robert6624 (636)
10/25/2004 11:54:21 AM
On Mon, 25 Oct 2004 01:56:16 -0400, Joe Zitzelberger
<joe_zitzelberger@nospam.com> wrote:

>In article <lqrmn0dcdo87pnf405beki6r2j1m21or92@4ax.com>,
> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>
>> On Sun, 24 Oct 2004 03:56:32 GMT, "William M. Klein"
>> <wmklein@nospam.netcom.com> wrote:
>>> I wrote:

>>>>When it introduced SMS/Tivoli in 1992, IBM moved buffer management
>>>>_out_ of applications and JCL. On input, it gets blocksize from the
>>>>filedef; on output, it uses SDB. 

>> >Neither BLOCK CONTAINS ZERO (nor DCB=BLKSIZE=0) nor SMS <sic> *changes* the 
>> >way 
>> >that blocking occurs for the actual physical file.  
>> 
>> You can read about SMS here:
>> http://www.storage.ibm.com/software/opt/index.html
>> 
>> When you create a new file (open output) with no block size specified
>> in program nor JCL, how IS the size determined?
>> 
>SMS selects a block size based on the data class or storage class of the 
>file or, depending upon configuration, attempts to guess an 'optimum' 
>blocksize.

Thank you for the confirmation.

>But the file still gets a blocksize.  And the records are stored with 
>block descriptor words and all that jazz...

If all files have BLOCK CONTAINS ZERO, blocksizes are set by SMS (at
creation time). That's what I said.

0
robert6624 (636)
10/25/2004 11:54:22 AM
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:94ppn05027nkirqsk4uijab9fiu4jdv1v7@4ax.com...
> On Sun, 24 Oct 2004 23:02:22 -0400, "Rick Smith" <ricksmith@mfi.net>
> wrote:
>
> >
> >"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> >news:qj0nn0l3kmlmgpbsgc2im1rbvtj0efifpj@4ax.com...
> >[snip]
> >> For text files, fgets() and fputs() are not only ten times faster but
> >> also insure the file will be compatible with others produced on the
> >> same platform (at least). If Micro Focus and Fujitsu had used fputs(),
> >> they wouldn't have produced the anomalies they did.
> >
> >Working Draft, 1997-11-21, WG14/N794 J11/97-158,
> >C Programming Language, page 276,
> >"7.13.2 Streams"
> >
> >"1 Input and output, whether to or from physical devices such
> >as terminals and tape drives, or whether to or from files
> >supported on structured storage devices, are mapped into
> >logical data streams, whose properties are more uniform than
> >their various inputs and outputs. Two forms of mapping are
> >supported, for text streams and for binary streams.[197]"
> >
> >"2 A text stream is an ordered sequence of characters
> >composed into lines, each line consisting of zero or more
> >characters plus a terminating new-line character. Whether the
> >last line requires a terminating new-line character is
> >implementation-defined. Characters may have to be added,
> >altered, or deleted on input and output to conform to differing
> >conventions for representing text in the host environment.
> >Thus, there need not be a one-to-one correspondence
> >between the characters in a stream and those in the external
> >representation. Data read in from a text stream will necessarily
> >compare equal to the data that were earlier written out to that
> >stream only if: the data consist only of printable characters and
> >the control characters horizontal tab and new-line; no new-line
> >character is immediately preceded by space characters; and
> >the last character is a new-line character. Whether space
> >characters that are written out immediately before a new-line
> >character appear when read in is implementation-defined."
>
> There's a fair definition of 'ASCII text file'. But the C standard is
> not a primary source, it merely describes a de facto standard that had
> been in place for decades.

The point, Mr Wagner, is that using "fgets() and fputs()",
which are defined by the C standard, does not "insure the
file will be compatible with others produced on the same
platform (at least). "

> This is Cobol's LINE SEQUENTIAL.

And, LINE SEQUENTIAL is not defined by the COBOL
standard.

> >"197. An implementation need not distinguish between text
> >streams and binary streams. In such an implementation, there
> >need be no new-line characters in a text stream nor any limit
> >to the length of a line."
> >
> >Mr Wagner, I see four ways in which text files created by
> >different C implementations on a single platform may be
> >incompatible.
>
> ASCII text is not a creature of C. Both C and Cobol are dealing with a
> format defined elsewhere, by the operating system. When the operating
> system boots, it has to read configuration files BEFORE it loads a
> file system.

But, "fgets() and fputs()", which are defined by the C
standard, need not be compatible with the "differing
conventions for representing text in the host environment."

> >Interestingly, the "CBL_" *byte-stream* routines
> >in Micro Focus (and, I beleive, Fujitsu) can be used by an
> >application programmer to obtain compatibility with any
> >of the C implementations.
>
> Those routines are superfluous. Plain vanilla Cobol can read a
> 'byte-stream' by simply defining a SEQUENTIAL file with record length
> of one byte. For a more general solution, make it a RANDOM file with
> one-byte records.

Occam's razor, Mr Wagner! Superfluous or not, the
routines remove complexity born of necessity.



0
ricksmith (875)
10/25/2004 1:30:17 PM
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:dVbed.1651997$yk.273663@news.easynews.com...

> How about
>
>    Perform until 1 Zero
>
> (not 1 = Zero - but using the "zero sign test") - If you don't think that
is
> clear enough, how about
>
>    Perform until 1 + 1 Negative
>
> I may be mistaken here, but I do not *think* that the sign test requires
an
> identifier (or at least I couldn't QUICKLY find that restriction).
>
> Thane or Chuck, can either of you confirm (or deny) this?

I may be all wet, of course, but I don't see any restrictions on arithmetic
expression in either the general format or the rules for "sign condition".
Since tests for zero are considered "sign conditions (as distinct from tests
comparing against zero, which are "relation conditions"), I don't see a
problem with either of these examples offhand.  Reference ISO/IEC 1989:2002
page 134. 8.8.4.1.6, Sign condition.

    -Chuck Stevens


0
10/25/2004 6:07:00 PM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> There's a fair definition of 'ASCII text file'. But the C standard is
> not a primary source, it merely describes a de facto standard that had
> been in place for decades. 
> 
> This is Cobol's LINE SEQUENTIAL.

It may, or need not be, the LINE SEQUENTIAL of any specific
implementation (with or without compile time or run time options).  It
_isn't_ at least one implementation which you claimed was.
 
> ASCII text is not a creature of C.

Nor is it a creature of Cobol, or of any extension.

> Both C and Cobol are dealing with a
> format defined elsewhere, by the operating system. When the operating
> system boots, it has to read configuration files BEFORE it loads a
> file system.

That is bogus.  If it is reading files then it has a 'file system', no
matter how simplistic a subset of the final file system it is.

The 'format' is actually defined, not by the operating system, but by
the terminal (which may be a keyboard/printer).  The operating system
neither knows nor cares what a cr or lf is, these are passed along
with all other characters to whatever thinks it needs them, such as
the user.
 
> Those routines are superfluous. Plain vanilla Cobol can read a
> 'byte-stream' by simply defining a SEQUENTIAL file with record length
> of one byte. 

Now you are contradicting your earlier argument.  You started your
rant by saying that ORGANIZATION SEQUENTIAL was vendor implemented and
should not be used to write text files.  For example it may be that
the vendor uses headers or other devices to mark records, or requires
description files (although this wasn't the case with the system being
used).  Now you claim that Cobol (any Cobol) has no
vendor-implementation details that would stop this accessing of every
byte.

> For a more general solution, make it a RANDOM file with
> one-byte records.

Those of us who know Cobol know that RANDOM is an ACCESS MODE and this
cannot be applied to ORGANIZATION SEQUENTIAL files.

If you mean ORGANIZATION RELATIVE ACCESS RANDOM then you are
completely out of your tree.  RELATIVE files need, at least, a marker
as to whether the relative record at a given position exists or not. 
This may be done with record headers or with record terminators, such
as CR/LF for existing records and NUL/?? for non-existing records. 
Whichever the vendor implements means that you cannot access every
byte in a file declared with ACCESS RANDOM.


*BTW: 'Plain Vanilla' is a contradiction.  'Vanilla' is a flavour, it
is made from the pod of the Vanilla tree.  'Plain' implies
featureless, flavourless. You can have either 'Plain' _or_ 'Vanilla'.
0
riplin (4127)
10/25/2004 7:41:49 PM
Rick Smith wrote:
> 
> H'm, in that case, I need to stop calling '1 = 0' standard
> COBOL and think of another means for expressing that
> the code within the perform repeats indefinitely.

01  pic X value "N".
     88 no-more-electricity    value "Y".


perform until no-more-electricity
     [statements]
end-perform


;)



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/26/2004 2:42:08 AM
On 25 Oct 2004 12:41:49 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
>
>> There's a fair definition of 'ASCII text file'. But the C standard is
>> not a primary source, it merely describes a de facto standard that had
>> been in place for decades. 
>> 
>> This is Cobol's LINE SEQUENTIAL.
>
>It may, or need not be, the LINE SEQUENTIAL of any specific
>implementation (with or without compile time or run time options).  It
>_isn't_ at least one implementation which you claimed was.

If it isn't ASCII text, users will complain until it's fixed.

>> Both C and Cobol are dealing with a
>> format defined elsewhere, by the operating system. When the operating
>> system boots, it has to read configuration files BEFORE it loads a
>> file system.
>
>That is bogus.  If it is reading files then it has a 'file system', no
>matter how simplistic a subset of the final file system it is.

The term 'file system' means three different things on Unix:

1. The Unix kernel  file system

User don't see this directly, although many think they do. It is
concerned with security -- access permissions.  The kernel also
contains a rudimentary level 2-3 component (AFS), which it uses to
read config files and mount level 2 systems.

2. Mountable file systems

Unix has a zillion of them. See
http://www.aspsys.com/software/links.aspx/14.aspx
They are concerned with directory management and disk allocation. Some
also have level 3 intra-file functions a'la mainframe, most do not.
They are what most users refer to when they say 'Unix file system'.

3. 'User level' file systems

Are concerned with the internal structure of files. Examples are stdio
and Btrieve. 

>The 'format' is actually defined, not by the operating system, but by
>the terminal (which may be a keyboard/printer).  The operating system
>neither knows nor cares what a cr or lf is, these are passed along
>with all other characters to whatever thinks it needs them, such as
>the user.

The CR and LF characters first came from terminals. Level 3 file
systems adopted them as record delimiters. 
 
>> Those routines are superfluous. Plain vanilla Cobol can read a
>> 'byte-stream' by simply defining a SEQUENTIAL file with record length
>> of one byte. 
>
>Now you are contradicting your earlier argument.  You started your
>rant by saying that ORGANIZATION SEQUENTIAL was vendor implemented and
>should not be used to write text files.  For example it may be that
>the vendor uses headers or other devices to mark records, or requires
>description files (although this wasn't the case with the system being
>used).  Now you claim that Cobol (any Cobol) has no
>vendor-implementation details that would stop this accessing of every
>byte.

I didn't say there were headers on files with fixed-length records

>> For a more general solution, make it a RANDOM file with
>> one-byte records.
>
>Those of us who know Cobol know that RANDOM is an ACCESS MODE and this
>cannot be applied to ORGANIZATION SEQUENTIAL files.
>
>If you mean ORGANIZATION RELATIVE ACCESS RANDOM then you are
>completely out of your tree.  RELATIVE files need, at least, a marker
>as to whether the relative record at a given position exists or not. 
>This may be done with record headers or with record terminators, such
>as CR/LF for existing records and NUL/?? for non-existing records. 
>Whichever the vendor implements means that you cannot access every
>byte in a file declared with ACCESS RANDOM.

I've done it many times .. on IBM mainframe, Realia, Micro Focus and
Fujitsu. Are you saying I just imagined the programs were working?

>*BTW: 'Plain Vanilla' is a contradiction.  'Vanilla' is a flavour, it
>is made from the pod of the Vanilla tree.  'Plain' implies
>featureless, flavourless. You can have either 'Plain' _or_ 'Vanilla'.

From the Online Merriam-Webster dictionary:

Main Entry: plain-vanilla
Function: adjective
: lacking special features or qualities : BASIC   

0
robert6624 (636)
10/26/2004 2:42:15 AM
Rick Smith wrote:
> But, this does not address COBOL 85.
> 
> Wait a minute! Let me think!
> 
> H'm, yes, that's it! An indefinite loop is most useful when used
> with EXIT PERFORM; but EXIT PERFORM is not in
> COBOL 85. I don't need to think of a means, I only need to
> stop calling it standard COBOL.

But it is standard COBOL, if the standard to which you refer is 2002.  :)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/26/2004 2:44:42 AM
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 

> 3. 'User level' file systems
> ....
> The CR and LF characters first came from terminals. Level 3 file
> systems adopted them as record delimiters. 

_SOME_ Level 3 file systems adopted them as record delimiters.  Some
other systems used other mechanisms.  For user and program data the OS
neither knows nor cares whether the file contains line terminators or
not.  stdio is a program library not an OS system call.
  
> >Now you are contradicting your earlier argument.  You started your
> >rant by saying that ORGANIZATION SEQUENTIAL was vendor implemented and
> >should not be used to write text files.  For example it may be that
> >the vendor uses headers or other devices to mark records, or requires
> >description files (although this wasn't the case with the system being
> >used).  Now you claim that Cobol (any Cobol) has no
> >vendor-implementation details that would stop this accessing of every
> >byte.
> 
> I didn't say there were headers on files with fixed-length records

No. I used that as an example of why a SEQUENTIAL file may not be
suitable for reading or writing text files. It doesn't apply in the
particular case in point.

So why did you object to SEQUENTIAL being used ?
 
> >> For a more general solution, make it a RANDOM file with
> >> one-byte records.
> >
> >Those of us who know Cobol know that RANDOM is an ACCESS MODE and this
> >cannot be applied to ORGANIZATION SEQUENTIAL files.
> >
> >If you mean ORGANIZATION RELATIVE ACCESS RANDOM then you are
> >completely out of your tree.  RELATIVE files need, at least, a marker
> >as to whether the relative record at a given position exists or not. 
> >This may be done with record headers or with record terminators, such
> >as CR/LF for existing records and NUL/?? for non-existing records. 
> >Whichever the vendor implements means that you cannot access every
> >byte in a file declared with ACCESS RANDOM.
> 
> I've done it many times .. on IBM mainframe, Realia, Micro Focus and
> Fujitsu. Are you saying I just imagined the programs were working?

You must have.  ORGANIZATION SEQUENTIAL ACCESS RANDOM is a compile
error.

ORGANIZATION RELATIVE ACCESS RANDOM with a one byte record gives a
file-status '39' on the OPEN in Fujitsu.

With MF on Unix it does open the file but accesses every alternate
character.  That is with a file containing ABCDEFGHIJKLMNOPQ..
accessing relative records by PERFORM VARYING FROM 1 BY 1 UNTIL ..
gives records containing ACEGIK... missing the even numbered bytes. 
This is because RELATIVE files have a 'deleted' marker as record
length + 1 which it never provides to the program.

On DOS and Windows it uses 2 byte record tags which would mean you
only got every third character from the file.

I neither know nor care what mainframes or Realia did with it, but
RELATIVE does require some mechanism to know whether a record of a
particular relative key exists or not and this can be done with record
headers or trailers.

Regardless of whether you just made up that you actually used this, or
you didn't notice that it just didn't work, it was very poor advice
and shows that you have few clues about file systems and data file
organizations.



> >*BTW: 'Plain Vanilla' is a contradiction.  'Vanilla' is a flavour, it
> >is made from the pod of the Vanilla tree.  'Plain' implies
> >featureless, flavourless. You can have either 'Plain' _or_ 'Vanilla'.
> 
> From the Online Merriam-Webster dictionary:
> 
> Main Entry: plain-vanilla
> Function: adjective
> : lacking special features or qualities : BASIC

So ? They are just as wrong as you are.  It is a contradiction no
matter who uses it.
0
riplin (4127)
10/26/2004 7:26:44 AM
"LX-i" <lxi0007@netscape.net> wrote in message
news:iQifd.89624$VJ2.73106@fe40.usenetserver.com...
> Rick Smith wrote:
> >
> > H'm, in that case, I need to stop calling '1 = 0' standard
> > COBOL and think of another means for expressing that
> > the code within the perform repeats indefinitely.
>
> 01  pic X value "N".
>      88 no-more-electricity    value "Y".
>
>
> perform until no-more-electricity
>      [statements]
> end-perform

It creates an expectation, that somewhere within the loop,
there will be a test to set 'no-more-electricity' to true.
There not being any such test is an appearance of
impropriety and some software analysis tools, such as
those used in formal methods, may treat, as an error, the
absence of code to change the state of 'no-more-electricity'.

In my case, I am my own software analysis tool, and will
not, intentionally, use such a construct.



0
ricksmith (875)
10/26/2004 6:23:09 PM
"LX-i" <lxi0007@netscape.net> wrote in message
news:ISifd.89625$VJ2.30169@fe40.usenetserver.com...
> Rick Smith wrote:
> > But, this does not address COBOL 85.
> >
> > Wait a minute! Let me think!
> >
> > H'm, yes, that's it! An indefinite loop is most useful when used
> > with EXIT PERFORM; but EXIT PERFORM is not in
> > COBOL 85. I don't need to think of a means, I only need to
> > stop calling it standard COBOL.
>
> But it is standard COBOL, if the standard to which you refer is 2002.  :)

The 'it' in "... stop calling it standard COBOL" referred
to the '1 = 0' in "I need to stop calling '1 = 0' standard
COBOL" (which statement appeared in text that was
deleted). Mr Klein noted that '1 = 0' was not standard
COBOL.



0
ricksmith (875)
10/26/2004 6:38:43 PM
In response to Bill Klein's

> >    Perform until 1 + 1 Negative
> >
> > I may be mistaken here, but I do not *think* that the sign test requires
> an
> > identifier (or at least I couldn't QUICKLY find that restriction).
> >
> > Thane or Chuck, can either of you confirm (or deny) this?

I wrote

> I may be all wet, of course, but I don't see any restrictions on
arithmetic
> expression in either the general format or the rules for "sign condition".
> Since tests for zero are considered "sign conditions (as distinct from
tests
> comparing against zero, which are "relation conditions"), I don't see a
> problem with either of these examples offhand.  Reference ISO/IEC
1989:2002
> page 134. 8.8.4.1.6, Sign condition.

I was all wet, of course, for ANSI X3.23-1985.  Page VI-58 has the explicit
requirement that the arithmetic expression in a sign test must contain at
least one variable.  I still don't see a similar requirement in ISO/IEC
1989:2002, though.

    -Chuck Stevens


0
10/26/2004 7:04:22 PM
..    On  26.10.04
  wrote  ricksmith@mfi.net (Rick Smith)
     on  /COMP/LANG/COBOL
     in  10nt6gmnpu4996b@corp.supernews.com
  about  Re: Report enhancements


>> 01  pic X value "N".
>>      88 no-more-electricity    value "Y".

>> perform until no-more-electricity
>>      [statements]
>> end-perform

RS> It creates an expectation, that somewhere within the loop,
RS> there will be a test to set 'no-more-electricity' to true.

   And what if the condition-name would not be "no-more-electricity",  
but, say, "NEVER"? Like in "PERFORM UNTIL NEVER".

RS> In my case, I am my own software analysis tool, and will
RS> not, intentionally, use such a construct.

   The proper solution would be, as I pointed out already before, to  
allow an alternative to the "UNTIL phrase", namely the word "FOREVER",  
like in:

   PERFORM FOREVER
      [statements]
      IF some-condition
        EXIT PERFORM
      END-IF
      [statements]
   END-PERFORM

   Although I do not really need it. I prefer conditions being checked  
at the entry or the exit of a loop.


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

Der Mann hatte soviel Verstand, da� er zu fast nichts mehr in der Welt zu gebrauchen war. -G.C.Lichtenberg
0
l.willms1 (637)
10/26/2004 8:31:00 PM
I kinda like what seems to be legitimate 2002 COBOL syntax:
    PERFORM UNTIL ZERO IS NOT ZERO ...

    -Chuck Stevens

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9JayJGauflB@jpberlin-l.willms.jpberlin.de...
> .    On  26.10.04
>   wrote  ricksmith@mfi.net (Rick Smith)
>      on  /COMP/LANG/COBOL
>      in  10nt6gmnpu4996b@corp.supernews.com
>   about  Re: Report enhancements
>
>
> >> 01  pic X value "N".
> >>      88 no-more-electricity    value "Y".
>
> >> perform until no-more-electricity
> >>      [statements]
> >> end-perform
>
> RS> It creates an expectation, that somewhere within the loop,
> RS> there will be a test to set 'no-more-electricity' to true.
>
>    And what if the condition-name would not be "no-more-electricity",
> but, say, "NEVER"? Like in "PERFORM UNTIL NEVER".
>
> RS> In my case, I am my own software analysis tool, and will
> RS> not, intentionally, use such a construct.
>
>    The proper solution would be, as I pointed out already before, to
> allow an alternative to the "UNTIL phrase", namely the word "FOREVER",
> like in:
>
>    PERFORM FOREVER
>       [statements]
>       IF some-condition
>         EXIT PERFORM
>       END-IF
>       [statements]
>    END-PERFORM
>
>    Although I do not really need it. I prefer conditions being checked
> at the entry or the exit of a loop.
>
>
> Yours,
> L�ko Willms                                     http://www.willms-edv.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> Der Mann hatte soviel Verstand, da� er zu fast nichts mehr in der Welt zu
gebrauchen war. -G.C.Lichtenberg


0
10/26/2004 9:12:37 PM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9JayJGauflB@jpberlin-l.willms.jpberlin.de...
[snip]
>    The proper solution would be, as I pointed out already before, to
> allow an alternative to the "UNTIL phrase", namely the word "FOREVER",
> like in:

Or, perhaps, another discussed four years ago.
[snip]

On 2000/05/30,
http://groups.google.com/groups?q=+%22perform+with+no+test%22+author:ricksmi
th%40aiservices.com&hl=en&lr=&c2coff=1&selm=8h19m2%242ugp%241%40news.hitter.
net&rnum=1

In the next standard, not without some contrivance, such as
PERFORM UNTIL 1 = 0
That was the point of the last paragraph of my previous post,
[...].

Unconditional loops are provided by some vendors.

Merant / Micro Focus uses PERFORM UNTIL EXIT
but EXIT is a reserved word.

Another vendor uses PERFORM WITHOUT LIMIT
but WITHOUT is new and LIMIT is reserved.

What I may suggest to J4 is the addition to Format 2 of
PERFORM WITH NO TEST to indicate an unconditional loop.
Hence, the original example of MLE becomes,

PERFORM WITH NO TEST
    READ INPUT-FILE
        AT END
            EXIT PERFORM
    END-READ
    PERFORM RECORD-PROCESS
END-PERFORM

Very clean -- no flags -- no GO TO!
------
And, on 2001-07-22
http://groups.google.com/groups?q=+%22perform+with+no+test%22+author:ricksmi
th%40aiservices.com&hl=en&lr=&c2coff=1&selm=tlls2do3604faf%40corp.supernews.
com&rnum=2

The draft COBOL standard provides PERFORM ...
EXIT PERFORM ... END-PERFORM which may be used
to eliminate the paragraph-names that form the loop and
structure boundaries. However, the draft COBOL standard
has no syntax to identify the loop as indefinite, therefore
a condition such as UNTIL 1 = 0 is needed. I also mentioned
this, last year, and suggested PERFORM WITH NO TEST
as a means for identifying an indefinite loop.

While I discussed these issues in the newsgroup, I never
submitted a comment to J4 for their consideration.
-----



0
ricksmith (875)
10/26/2004 9:37:38 PM
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:10nth094c4u3e92@corp.supernews.com...

> What I may suggest to J4 is the addition to Format 2 of
> PERFORM WITH NO TEST to indicate an unconditional loop.

As I mentioned before, PERFORM UNTIL ZERO IS NOT ZERO already indicates to
me an extremely small likelihood that the PERFORM will ever terminate, and I
don't offhand see anything precluding it in ISO/IEC 1989:2005.

If I'm right about that, then experience leads me to believe J4 would be
more inclined to add a note along the lines of "If you want this result, do
it that way" rather than adding a new functionality that does what this
already does.

Personally, I think PERFORM WITH NO TEST is less clear about being a loop
that is infinite unless exited than PERFORM UNTIL ZERO IS NOT ZERO.

You can even do PERFORM WITH NO TEST today so long as you start the whole
compilation unit off with REPLACE == WITH NO TEST == BY == UNTIL ZERO IS NOT
ZERO == if you like.

Or better still, use PERFORM UNTIL PIGS-FLY in the context of REPLACE ==
PIGS-FLY == BY == ZERO IS NOT ZERO == if you like!

Since REPLACE is already in '85 COBOL, you can make both the source for the
PERFORM and the actual source code generated for it (about which I wouldn't
really care much) look pretty much however you want, even with 85-vintage
COBOL compilers, so long as they include Level 2 of the Source Text
Manipulation module.

    -Chuck Stevens


0
10/26/2004 11:19:43 PM
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:clmm2f$2ufk$1@si05.rsvl.unisys.com...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:10nth094c4u3e92@corp.supernews.com...
>
> > What I may suggest to J4 is the addition to Format 2 of
> > PERFORM WITH NO TEST to indicate an unconditional loop.
>
> As I mentioned before, PERFORM UNTIL ZERO IS NOT ZERO already indicates to
> me an extremely small likelihood that the PERFORM will ever terminate, and
I
> don't offhand see anything precluding it in ISO/IEC 1989:2005.
>
> If I'm right about that, then experience leads me to believe J4 would be
> more inclined to add a note along the lines of "If you want this result,
do
> it that way" rather than adding a new functionality that does what this
> already does.
>
> Personally, I think PERFORM WITH NO TEST is less clear about being a loop
> that is infinite unless exited than PERFORM UNTIL ZERO IS NOT ZERO.
>
> You can even do PERFORM WITH NO TEST today so long as you start the whole
> compilation unit off with REPLACE == WITH NO TEST == BY == UNTIL ZERO IS
NOT
> ZERO == if you like.
>
> Or better still, use PERFORM UNTIL PIGS-FLY in the context of REPLACE ==
> PIGS-FLY == BY == ZERO IS NOT ZERO == if you like!

Should I overcome my disability and return to work, it is more
likely I would use PERFORM INDEFINITELY in the context
of REPLACE ==INDEFINITELY== BY ==UNTIL B"0"==;
since the source code would more clearly state that the loop is
performed indefinitely. But, that's just me being me.

> Since REPLACE is already in '85 COBOL, you can make both the source for
the
> PERFORM and the actual source code generated for it (about which I
wouldn't
> really care much) look pretty much however you want, even with 85-vintage
> COBOL compilers, so long as they include Level 2 of the Source Text
> Manipulation module.

Not likely I would waste REPLACE in COBOL 85 to conform.
I'd fall back to the old, unambiguous, standby.

section-name SECTION.
    ...
LOOP-START.
    ...
    IF condition GO TO LOOP-EXIT.
    ...
    GO TO LOOP-START.
LOOP-EXIT.



0
ricksmith (875)
10/27/2004 1:05:13 AM
Richard wrote:
> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote 
> 
>>>*BTW: 'Plain Vanilla' is a contradiction.  'Vanilla' is a flavour, it
>>>is made from the pod of the Vanilla tree.  'Plain' implies
>>>featureless, flavourless. You can have either 'Plain' _or_ 'Vanilla'.
>>
>>From the Online Merriam-Webster dictionary:
>>
>>Main Entry: plain-vanilla
>>Function: adjective
>>: lacking special features or qualities : BASIC
> 
> 
> So ? They are just as wrong as you are.  It is a contradiction no
> matter who uses it.

So, what do you consider your defining source of the English language? 
DD has posted citations showing the term "period" being used to describe 
the dot at the end of a sentence from quite a long time ago; RW posted 
the reply quoted above.  If the dictionary doesn't fit your view, where 
would one go to view what you consider acceptable?


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/27/2004 1:40:30 AM
Rick Smith wrote:
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:iQifd.89624$VJ2.73106@fe40.usenetserver.com...
> 
>>Rick Smith wrote:
>>
>>>H'm, in that case, I need to stop calling '1 = 0' standard
>>>COBOL and think of another means for expressing that
>>>the code within the perform repeats indefinitely.
>>
>>01  pic X value "N".
>>     88 no-more-electricity    value "Y".
>>
>>
>>perform until no-more-electricity
>>     [statements]
>>end-perform
> 
> 
> It creates an expectation, that somewhere within the loop,
> there will be a test to set 'no-more-electricity' to true.
> There not being any such test is an appearance of
> impropriety and some software analysis tools, such as
> those used in formal methods, may treat, as an error, the
> absence of code to change the state of 'no-more-electricity'.
> 
> In my case, I am my own software analysis tool, and will
> not, intentionally, use such a construct.

Suit yourself.  There was that little  ;)  after it.

However, to make it more or less dummy-proof...


01  pic X value "Y".
     88  more-electricity value "Y".

perform until not more-electricity
     [statements]
end-perform


With that definition, there's no standard programmatic way to change the 
value of the variable.  You can always do it the old-school way...


001-LOOP-IT.
     [statements]
     GO TO 001-LOOP-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)
10/27/2004 1:51:59 AM
..    On  26.10.04
  wrote  charles.stevens@unisys.com (Chuck Stevens)
     on  /COMP/LANG/COBOL
     in  clmm2f$2ufk$1@si05.rsvl.unisys.com
  about  Re: Report enhancements

   on PERFORM loops which are exited by an EXIT PERFORM:

>> What I may suggest to J4 is the addition to Format 2 of
>> PERFORM WITH NO TEST to indicate an unconditional loop.

CS> As I mentioned before, PERFORM UNTIL ZERO IS NOT ZERO already
CS> indicates to me an extremely small likelihood that the PERFORM will
CS> ever terminate, and I don't offhand see anything precluding it in
CS> ISO/IEC 1989:2005.

CS> Personally, I think PERFORM WITH NO TEST is less clear about being a
CS> loop that is infinite unless exited than PERFORM UNTIL ZERO IS NOT
CS> ZERO.

   I disagree, since "NO TEST" clearly states that there is no test  
for entering the loop, while the condition "ZERO IS NOT ZERO" needs to  
be grasped and understood.

  ALSO "ZERO IS NOT ZERO" actually _does_ test a condition for  
entering the loop, where the programmer actually thought that there  
should not be a condition, but that the exit from the loop should be  
somewhere in the middle of the sequence of statements being repeated.  
Clarity of the program and performance do suffer.

  That's why I think that one of the proposals

    PERFORM FOREVER
    PERFORM INDEFINITE
    PERFORM WITH NO TEST

  does better express this concept than a dummy condition which is not  
meant seriously, and only stands there because the syntax requires a  
condition.

  I also think that the above are superiour to the extensions by  
Microfocus (PERFORM UNTIL EXIT) and Fujitsu (PERFORM WITH NO LIMITS).


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

Er liebte haupts�chlich die W�rter, die nicht in W�rterb�chern vorzukommen pflegen. -G.C.Lichtenberg
0
l.willms1 (637)
10/27/2004 8:40:00 AM
LX-i <lxi0007@netscape.net> wrote 

> >>>*BTW: 'Plain Vanilla' is a contradiction. ...

> > So ? They are just as wrong as you are.  It is a contradiction no
> > matter who uses it.
> 
> So, what do you consider your defining source of the English language? 

Are you disputing that it is a contradiction ?

> DD has posted citations showing the term "period" being used to describe 
> the dot at the end of a sentence from quite a long time ago; 

> RW posted 
> the reply quoted above.  If the dictionary doesn't fit your view, where 
> would one go to view what you consider acceptable?

I don't dispute that these terms are used.  Dictionaries report usage,
so they will have these as entries. 'Plain Vanilla' is a
contradiction, just as 'Plain Strawberry' would be.  The use of
'period' as the end-point conflicts with the other usages of period.
0
riplin (4127)
10/27/2004 8:53:12 AM
In article <217e491a.0410270053.5fc6617e@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>LX-i <lxi0007@netscape.net> wrote 
>
>> >>>*BTW: 'Plain Vanilla' is a contradiction. ...
>
>> > So ? They are just as wrong as you are.  It is a contradiction no
>> > matter who uses it.
>> 
>> So, what do you consider your defining source of the English language? 
>
>Are you disputing that it is a contradiction ?

Answering a question with a question is no answer at all, Mr Plinston.

>
>> DD has posted citations showing the term "period" being used to describe 
>> the dot at the end of a sentence from quite a long time ago; 
>
>> RW posted 
>> the reply quoted above.  If the dictionary doesn't fit your view, where 
>> would one go to view what you consider acceptable?
>
>I don't dispute that these terms are used.

You have stated, Mr Plinston, clearly and unambiguosly, that using a word 
in a fashion indicated by an definition in the OED is 'get(ting) it 
wrong'.  What was asked above was ' what do you consider your defining 
source of the English language' and 'where would one go to view what you 
consider acceptable'... both of which you seem to have dodged answering.

DD
0
docdwarf (6044)
10/27/2004 9:14:34 AM
Richard wrote:
> LX-i <lxi0007@netscape.net> wrote 
> 
> 
>>>>>*BTW: 'Plain Vanilla' is a contradiction. ...
> 
> 
>>>So ? They are just as wrong as you are.  It is a contradiction no
>>>matter who uses it.
>>
>>So, what do you consider your defining source of the English language? 
> 
> 
> Are you disputing that it is a contradiction ?

Not necessarily - but if it's written plain/vanilla, it's not.  :)  What 
I was more asking for was the source from which you derived your 
seemingly strong feelings about "wrong terms" that are defined in a 
dictionary.

>>DD has posted citations showing the term "period" being used to describe 
>>the dot at the end of a sentence from quite a long time ago; 
> 
> 
>>RW posted 
>>the reply quoted above.  If the dictionary doesn't fit your view, where 
>>would one go to view what you consider acceptable?
> 
> 
> I don't dispute that these terms are used.  Dictionaries report usage,
> so they will have these as entries. 'Plain Vanilla' is a
> contradiction, just as 'Plain Strawberry' would be.  The use of
> 'period' as the end-point conflicts with the other usages of period.

Do folks in NZ say "full stop" instead of "period" when they're 
emphasizing the finality of something?  Such as...

"That is enough!  Period!  End of Story!"
"That is enough!  Full stop!  End of Story!"


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/27/2004 1:03:48 PM
On 27-Oct-2004, LX-i <lxi0007@netscape.net> wrote:

> >>So, what do you consider your defining source of the English language?
> >
> >
> > Are you disputing that it is a contradiction ?
>
> Not necessarily - but if it's written plain/vanilla, it's not.  :)  What
> I was more asking for was the source from which you derived your
> seemingly strong feelings about "wrong terms" that are defined in a
> dictionary.

Which do you want, French Vanilla ice cream, or plain vanilla ice cream?

People who use "plain vanilla", generally think vanilla is plain.   That is they
think it is ordinary and nothing special.    Tastes vary, but apparently this is
a common belief.   Saying that they are wrong is like saying someone is wrong
for not liking pickles.
0
howard (6283)
10/27/2004 1:54:57 PM
Right you are.  I forgot that EXIT PERFORM is '02, not '85.  We added it as
an extension to our '85 (and '74) compilers, including in the context of
out-of-line PERFORM.

    -Chuck Stevens

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:10ntt52l4o1vce5@corp.supernews.com...
>
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:clmm2f$2ufk$1@si05.rsvl.unisys.com...
> >
> > "Rick Smith" <ricksmith@mfi.net> wrote in message
> > news:10nth094c4u3e92@corp.supernews.com...
> >
> > > What I may suggest to J4 is the addition to Format 2 of
> > > PERFORM WITH NO TEST to indicate an unconditional loop.
> >
> > As I mentioned before, PERFORM UNTIL ZERO IS NOT ZERO already indicates
to
> > me an extremely small likelihood that the PERFORM will ever terminate,
and
> I
> > don't offhand see anything precluding it in ISO/IEC 1989:2005.
> >
> > If I'm right about that, then experience leads me to believe J4 would be
> > more inclined to add a note along the lines of "If you want this result,
> do
> > it that way" rather than adding a new functionality that does what this
> > already does.
> >
> > Personally, I think PERFORM WITH NO TEST is less clear about being a
loop
> > that is infinite unless exited than PERFORM UNTIL ZERO IS NOT ZERO.
> >
> > You can even do PERFORM WITH NO TEST today so long as you start the
whole
> > compilation unit off with REPLACE == WITH NO TEST == BY == UNTIL ZERO IS
> NOT
> > ZERO == if you like.
> >
> > Or better still, use PERFORM UNTIL PIGS-FLY in the context of REPLACE ==
> > PIGS-FLY == BY == ZERO IS NOT ZERO == if you like!
>
> Should I overcome my disability and return to work, it is more
> likely I would use PERFORM INDEFINITELY in the context
> of REPLACE ==INDEFINITELY== BY ==UNTIL B"0"==;
> since the source code would more clearly state that the loop is
> performed indefinitely. But, that's just me being me.
>
> > Since REPLACE is already in '85 COBOL, you can make both the source for
> the
> > PERFORM and the actual source code generated for it (about which I
> wouldn't
> > really care much) look pretty much however you want, even with
85-vintage
> > COBOL compilers, so long as they include Level 2 of the Source Text
> > Manipulation module.
>
> Not likely I would waste REPLACE in COBOL 85 to conform.
> I'd fall back to the old, unambiguous, standby.
>
> section-name SECTION.
>     ...
> LOOP-START.
>     ...
>     IF condition GO TO LOOP-EXIT.
>     ...
>     GO TO LOOP-START.
> LOOP-EXIT.
>
>
>


0
10/27/2004 2:55:35 PM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9Je-jXD9flB@jpberlin-l.willms.jpberlin.de...

>   ALSO "ZERO IS NOT ZERO" actually _does_ test a condition for
> entering the loop, where the programmer actually thought that there
> should not be a condition, but that the exit from the loop should be
> somewhere in the middle of the sequence of statements being repeated.
> Clarity of the program and performance do suffer.

The relative performance of conditional expressions that always evaluate to
FALSE is dependent entirely on the ability of the compiler to recognize, at
compile time, that this is the case.  Clarity of the program is arguable,
but there is absolutely nothing in the standard that prohibits the compiler
from recognizing the unconditionality of a conditional expression and from
generating object code that reflects the constant value of that expression
(or from optimizing any test entirely out of existence in the first place).

>   That's why I think that one of the proposals
>
>     PERFORM FOREVER
>     PERFORM INDEFINITE
>     PERFORM WITH NO TEST

I personally think "PERFORM FOREVER" is much the best choice -- and it has
precedent in the "DO FOREVER" syntax of the Dijkstra-inspired SDL/UPL
compilers for the Burroughs Small System.

I don't care for the other two; I don't think they clearly indicate that the
loop will be performed until the user *explicitly* exits it nearly as well
as the first.

Whether the object code for PERFORM UNTIL ZERO IS NOT ZERO would require
less in the way of processor resources than the hypothetical examples above
while accomplishing the same results is *entirely* a matter for discussion
with your compiler vendor!

> I also think that the above are superiour to the extensions by
> Microfocus (PERFORM UNTIL EXIT) and Fujitsu (PERFORM WITH NO LIMITS).

I like the first of these better than the second, but I like FOREVER better
than either.

Point being, though, the language currently has the needed functionality;
the only argument is whether or not a particular implementation's parser is
smart enough to recognize an invariant conditional expression at compile
time and take action appropriate to its invariance.  That's really not the
*language's* business.

    -Chuck Stevens


0
10/27/2004 3:24:56 PM
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cloeka$13f0$1@si05.rsvl.unisys.com...
[snip]
> Point being, though, the language currently has the needed functionality;
> the only argument is whether or not a particular implementation's parser
is
> smart enough to recognize an invariant conditional expression at compile
> time and take action appropriate to its invariance.  That's really not the
> *language's* business.

Another argument is that aesthetically pleasing can be
more important than needed functionality. How the
intent of a program is conveyed determines how well
it will be understood. The use of identifiable structures,
meaningful names, etc., work toward that end.
Spaghetti-like structures (or no identifiable structure)
and cryptic names may supply the needed functionality
for an application but are now vehemently rejected
and despised.

Knuth suggests that computer programming is an art.
If programmers feel that PERFORM UNTIL EXIT
is "more beautiful" than PERFORM UNTIL ZERO
IS NOT ZERO, then the former will be used and the
standard be damned.



0
ricksmith (875)
10/27/2004 5:44:26 PM
In article <217e491a.0410270053.5fc6617e@posting.google.com>, riplin@Azonic.co.nz (Richard) writes:
> 
> > >>>*BTW: 'Plain Vanilla' is a contradiction. ...
> 
> Are you disputing that it is a contradiction ?

I'll dispute that.  "plain" to mean "not otherwise enhanced or
qualified" is a long-standing usage, and in that sense is perfectly
applicable to "vanilla".

-- 
Michael Wojcik                  michael.wojcik@microfocus.com

Thanatos, thanatos!  The labourer, dropping his lever,
Hides a black letter close to his heart and goes,
Thanatos, thanatos, home for the day and for ever.	-- George Barker
0
mwojcik (1879)
10/27/2004 5:50:44 PM
docdwarf@panix.com wrote 

> >Are you disputing that it is a contradiction ?
>
> Answering a question with a question is no answer at all, Mr Plinston.

Oh, I am sorry, were you expecting an answer ?  Which is strange
because I didn't see an answer to my question.

> You have stated, Mr Plinston, clearly and unambiguosly, that using a word 
> in a fashion indicated by an definition in the OED is 'get(ting) it 
> wrong'.  

The use of 'period' as full stop is contradictory to its other uses.
It should refer to all the sylabyls in the sentence to be consistent
with usage elsewhere.

> What was asked above was ' what do you consider your defining 
> source of the English language' 

You should remember that dictionaries are recording usage not creating
or advocating it.

> and 'where would one go to view what you consider acceptable'... 

You come and sit at my feet waiting for gems of wisdom, possibly.

> both of which you seem to have dodged answering.
0
riplin (4127)
10/27/2004 6:38:30 PM
l.willms@jpberlin.de (Lueko Willms) wrote

>    on PERFORM loops which are exited by an EXIT PERFORM:
> 
>    I disagree, since "NO TEST" clearly states that there is no test  
> for entering the loop, while the condition "ZERO IS NOT ZERO" needs to  
> be grasped and understood.

PERFORM NO TEST does not imply that it is to be done more than once.
It requires the use of a time qualifier such as UNTIL or WHILE, or a
count based one like PERFORM INDEFINITE TIMES.

No, wait, that is a 'time' qualifier too  ;-)
 
>   That's why I think that one of the proposals
> 
>     PERFORM FOREVER
>     PERFORM INDEFINITE
>     PERFORM WITH NO TEST
 
      PERFORM INDEFINITE TIMES

can be done now by having a variable or constant INDEFINITE with a
huge value.

>   does better express this concept than a dummy condition which is not  
> meant seriously, and only stands there because the syntax requires a  
> condition.

>   I also think that the above are superiour to the extensions by  
> Microfocus (PERFORM UNTIL EXIT) and Fujitsu (PERFORM WITH NO LIMITS).

PERFORM UNTIL EXIT describes better how the loop will terminate, the
others imply that the loop will never terminate, which is usually not
what is intended (though it can happen).
0
riplin (4127)
10/27/2004 6:56:25 PM
..    On  27.10.04
  wrote  charles.stevens@unisys.com (Chuck Stevens)
     on  /COMP/LANG/COBOL
     in  cloeka$13f0$1@si05.rsvl.unisys.com
  about  Re: Report enhancements


CS> I personally think "PERFORM FOREVER" is much the best choice -- and
CS> it has precedent in the "DO FOREVER" syntax of the Dijkstra-inspired
CS> SDL/UPL compilers for the Burroughs Small System.

   I feel encouraged to submit this to J4

CS> Whether the object code for PERFORM UNTIL ZERO IS NOT ZERO would
CS> require less in the way of processor resources than the hypothetical
CS> examples above while accomplishing the same results is *entirely* a
CS> matter for discussion with your compiler vendor!

   "My" compiler vendor, or rather its compiler says that there is a  
"relational operator missing" in that expression, and when I expand it  
to PERFORM UNTIL ZERO IS NOT EQUAL ZERO, then it complains that  
"comparison between literal and literal cannot be done in relation  
condition".

   This is Fujitsu COBOL-85 version 3.0.

   So, I feel even more encouraged to make a submission to J4.


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

Seine B�cher waren alle sehr nett, sie hatten auch sonst wenig zu tun. -G.C.Lichtenberg
0
l.willms1 (637)
10/27/2004 7:26:00 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410271056.7f867df4@posting.google.com...
> l.willms@jpberlin.de (Lueko Willms) wrote
>
> >    on PERFORM loops which are exited by an EXIT PERFORM:
> >
> >    I disagree, since "NO TEST" clearly states that there is no test
> > for entering the loop, while the condition "ZERO IS NOT ZERO" needs to
> > be grasped and understood.
>
> PERFORM NO TEST does not imply that it is to be done more than once.
> It requires the use of a time qualifier such as UNTIL or WHILE, or a
> count based one like PERFORM INDEFINITE TIMES.

PERFORM WITH NO TEST states there is "no test"
to prevent entering the loop nor any test to cause the
loop to terminate. It is the presence of WITH NO TEST
that makes the loop infinite ("unbounded or unlimited").
The availability of EXIT PERFORM makes the loop
indefinite ("without fixed limit").

Compare this with the "plain vanilla" PERFORM which
makes no mention of any test and therefore implies only
to do this once.

> No, wait, that is a 'time' qualifier too  ;-)
>
> >   That's why I think that one of the proposals
> >
> >     PERFORM FOREVER
> >     PERFORM INDEFINITE
> >     PERFORM WITH NO TEST
>
>       PERFORM INDEFINITE TIMES
>
> can be done now by having a variable or constant INDEFINITE with a
> huge value.

Having a value of any magnitude states that the loop
is finite ("having bounds or limits") or definite ("having
fixed limits").



0
ricksmith (875)
10/27/2004 7:31:14 PM
On 27-Oct-2004, riplin@Azonic.co.nz (Richard) wrote:

> > You have stated, Mr Plinston, clearly and unambiguosly, that using a word
> > in a fashion indicated by an definition in the OED is 'get(ting) it
> > wrong'.
>
> The use of 'period' as full stop is contradictory to its other uses.
> It should refer to all the sylabyls in the sentence to be consistent
> with usage elsewhere.

If you check the OED, you will find a couple of other words that have meanings
that are at least as inconsistent as this is to their other uses.

Does that mean the OED definitions are wrong?

There are some words that have absolutely opposite meanings.   (cleave)


> > What was asked above was ' what do you consider your defining
> > source of the English language'
>
> You should remember that dictionaries are recording usage not creating
> or advocating it.

I was just going to suggest the same thing to you!
0
howard (6283)
10/27/2004 7:51:44 PM
"Chuck Stevens" <charles.stevens@unisys.com> wrote 

> Right you are.  I forgot that EXIT PERFORM is '02, not '85.  We added it as
> an extension to our '85 (and '74) compilers, including in the context of
> out-of-line PERFORM.

Does the '02 standard allow EXIT PERFORM in an out-of-line performed
procedure ?

What would happen if an EXIT PERFORM was executed while not under the
control of a PERFORM ?
0
riplin (4127)
10/27/2004 7:56:51 PM
LX-i <lxi0007@netscape.net> wrote 

> Not necessarily - but if it's written plain/vanilla, it's not.  :)  What 
> I was more asking for was the source from which you derived your 
> seemingly strong feelings about "wrong terms" that are defined in a 
> dictionary.

There are many things in English which are 'wrong' (in the sense of
contradictory, logically incorrect, incorrectly derived, or misused)
but are commonly used.  Dictionaries record usage, so the appearance
of a word or phrase in them does not mean that it is not contractory
or wrongly used, but only that it is used.
 
> Do folks in NZ say "full stop" instead of "period" when they're 
> emphasizing the finality of something?  Such as...

Yes.  They may do.
 
> "That is enough!  Period!  End of Story!"
> "That is enough!  Full stop!  End of Story!"

They may use either of those, or just the 'end of story', or none. 
They are unlikely to use 'Period!' because it doesn't usually mean
'Full stop' at all, but means several other things, such as 'a school
lesson' as in 'Study period', referring to the time from the start
time to the end time.

English and American idioms are often quite different, and NZ idioms
may be different again (and not Ozzie at all).
0
riplin (4127)
10/27/2004 8:15:12 PM
In article <217e491a.0410271038.64573adb@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>docdwarf@panix.com wrote 
>
>> >Are you disputing that it is a contradiction ?
>>
>> Answering a question with a question is no answer at all, Mr Plinston.
>
>Oh, I am sorry, were you expecting an answer ?

I try to keep my expectations minimal, Mr Plinston; doing so decreases the 
probability of disappointments.

>Which is strange
>because I didn't see an answer to my question.

That sounds like a Brooklyn Bridge defense, Mr Plinston.

>
>> You have stated, Mr Plinston, clearly and unambiguosly, that using a word 
>> in a fashion indicated by an definition in the OED is 'get(ting) it 
>> wrong'.  
>
>The use of 'period' as full stop is contradictory to its other uses.

Mr Plinston, a word can be used in a variety of ways; the word 'cleave', 
when defined as 'to stick fast or adhere', is contradictory to its other 
use when defined as 'to part or divide'... English is a language where a 
word can be used as its own antonym.  

As for definitions of 'period', the OED lists several which support, 
rather than contradict, the already given definition which sets 'period' 
equal to 'full stop'.  In fact, an entire section of definitions (OED, Vol 
II, p 2134, p 699m col ii) is given the heading of 'Completion, end of any 
course'; it includes such definitions as:

5. The point of completion of any round of time or course of action or 
duration.

(ed. note: if the writing of a sentence is a 'course of action' this 
seems to directly apply)

7. A particular point in the course of anything; a point of stage or 
advance; a point of time, moment, occasion.

(ed. note: if a sentence is a thing which ends in time then this seems to 
directly apply)

8. A limit in space, appointed end (of a journey or course)

(ed. note: if a sentence is a course of words then this seems to directly 
apply)

.... in addition to the previously cited definition of 'The point or 
character that marks the end of a complete sentence; a full stop (.).'


>It should refer to all the sylabyls in the sentence to be consistent
>with usage elsewhere.

As noted above, Mr Plinston, other definitions, clearly and unambiguously, 
associate 'period' with an ending, a terminus; this would seem to be 
consonant with its definition as 'The point or character (etc.)' which the 
OED also supplies.

>
>> What was asked above was ' what do you consider your defining 
>> source of the English language' 
>
>You should remember that dictionaries are recording usage not creating
>or advocating it.

I remember that dictionaries can be used as either descriptive or 
prescriptive, Mr Plinston.

>
>> and 'where would one go to view what you consider acceptable'... 
>
>You come and sit at my feet waiting for gems of wisdom, possibly.

Were one to do so one might be disappointed, Mr Plinston; what is asked, 
now as a second request, is 'what do you consider your defining source of 
the English language?'

You see, Mr Plinston... if you extend Protagoras in this instance to 
'Plinston is the measure of all things' then definition becomes 
idiosyncratic... and a conclusion to be drawn from that invalidates your 
assertions.

DD

0
docdwarf (6044)
10/27/2004 8:42:04 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410271156.236207f0@posting.google.com...

> Does the '02 standard allow EXIT PERFORM in an out-of-line performed
> procedure ?

No.  It's an extension not only to our '74 and '85 implementations, it's an
extension beyond the '02 specification and the 2008 draft.   It's a syntax
rule (EXIT syntax rule 10 in the '02 standard, to be exact) that prohibits
the use of EXIT PERFORM outside of an inline PERFORM statement, so in
standard, unextended COBOL I'd expect a syntax error.

> What would happen if an EXIT PERFORM was executed while not under the
> control of a PERFORM ?

According to the '02 standard, it's allowed only within the scope of an
inline PERFORM in the first place, so it couldn't happen; it'd receive a
syntax error of some sort.

What happens in Unisys MCP COBOL74 and COBOL85 *extension* to standard COBOL
if an EXIT PERFORM that isn't within the compile-time scope of an inline
PERFORM is executed, and isn't within the execution-time scope of a
currently-active out-of-line PERFORM, is that execution continues with the
next statement after the EXIT PERFORM.  This execution-time determination is
quite efficient, by the way.

    -Chuck Stevens


0
10/27/2004 8:59:58 PM
"Howard Brazee" <howard@brazee.net> wrote 

> People who use "plain vanilla", generally think vanilla is plain.   

I recall when I was a child that one could have a 'plain ice-cream' or
a 'vanilla ice-cream', or possibly some other flavours.  But that may
have been before cheap artificial vanilla flavouring made 'plain' no
longer necessary as a cost saving.

> That is they
> think it is ordinary and nothing special. Tastes vary, but apparently this is
> a common belief.   

Being a 'common belief' does not indicate that it is 'correct'.

For example it is common usage to say "he said it with his tongue in
his cheek".  This is, of course, quite impossible, but it originates
when the _listeners_ actually did put their tongue in their cheeks in
an obvious way to indicate they did not believe the speaker.

> is like saying someone is wrong for not liking pickles.

I doubt that it is anything like that at all. It has nothing to do
with whether people like vanilla or prefer unflavoured. It would be
more like saying "'colourless red' is wrong".
0
riplin (4127)
10/27/2004 9:07:05 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410271038.64573adb@posting.google.com...

> The use of 'period' as full stop is contradictory to its other uses.
> It should refer to all the sylabyls in the sentence to be consistent
> with usage elsewhere.

Etymologically I don't think so.  From what I see, Medieval Latin "periodus"
is both a period of time *and* a punctuation mark.

If "period" -- and "periodus" -- can be taken to be both "the particular
form of juncture that occurs in speech between two sentences" and "the
punctuation mark in written representations of speech that indicates the
particular form of juncture ... ", I see neither conflict nor ambiguity.

If "periodus" is indeed a punctuation attested as such in Medieval Latin
("the Latin used esp. for liturgical and literary purposes from the 7th to
the 15th centuries inclusive") as the dictionaries I have available assert,
it appears far more likely that it's the use of "full stop" that's of recent
introduction.

As far as I'm concerned, a usage from Medieval Latin trumps a usage from
Modern English in terms of longevity.

And while we're on the subject of longevity:  I have heard it asserted by
several knowledgeable linguists that the English spoken in the Appalachian
Mountains is far, far closer to spoken English English of three and more
centuries ago in both grammar and pronunciation than it is to any English
spoken anywhere in the British Isles today.   In more ways than not, it's
spoken English English that's wandered from traditional usage and phonology,
considerably less so than standard American English

    -Chuck Stevens


0
10/27/2004 9:22:19 PM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9Jf5oGMuflB@jpberlin-l.willms.jpberlin.de...

>    "My" compiler vendor, or rather its compiler says that there is a
> "relational operator missing" in that expression, and when I expand it
> to PERFORM UNTIL ZERO IS NOT EQUAL ZERO, then it complains that
> "comparison between literal and literal cannot be done in relation
> condition".
>
>    This is Fujitsu COBOL-85 version 3.0.

Well, yeah, that makes sense.  "... ZERO IS NOT ZERO" is indeed expressly
prohibited by ANSI X3.23-1985 page VI-81, 6.3.1.5, Sign Condition,
explanatory paragraph after syntax diagram, last sentence:
"Arithmetic-expression-1 must contain at least one reference to a variable."

But I see no such restriction prohibiting ZERO as an arithmetic expression
in ISO/IEC 1989:2002.  The sentence above is omitted in the similar text on
page 134, 8.8.4.1.6.2, Sign condition, and I see specific indication that
ZERO is allowed as an arithmetic expression, unless something *explicitly*
states otherwise, by page 120, 8.8.1, Arithmetic expressions, introductory
paragraph, first sentence.  My opinion is that "... ZERO IS NOT ZERO" ought
to work in a COBOL-2002 environment, which your Fujitsu COBOL-85 is not.

>    So, I feel even more encouraged to make a submission to J4.

If the justification for suggesting that there's a capability that needs to
be added to 20xx COBOL because it's not in 1985 COBOL, it might be a good
idea to see if that capability exists in the *current* standard and/or the
draft of the *next* one!

You're welcome to submit it, of course, and it can certainly be added to the
Candidates list for the standard following that which is scheduled for 2008.

But it seems to me the "new way" of specifying this functionality -- be it
PERFORM WITH NO TEST, PERFORM FOREVER, or PERFORM UNTIL EXIT -- can be
accomplished with 2002-compliant COBOL through REPLACE with no adjustments
to the syntax or to the reserved word list (e.g., FOREVER).  It's my
observation that providing new syntax supporting the exact functionality
available elsewhere in the language has not historically been viewed with a
great deal of enthusiasm as a "hot new feature" that deserves high priority.
There was considerable opposition, for example, to the addition of "<>" as a
synonym for "NOT EQUAL" in the 2008 draft, and the driving force for its
acceptance was that ">=" and "<=" had already been included, and "<>" was
reluctantly accepted on the grounds of syntactic symmetry.

    -Chuck Stevens


0
10/27/2004 10:08:28 PM
In article <217e491a.0410271307.7e883bd6@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>"Howard Brazee" <howard@brazee.net> wrote 

[snip]

>> That is they
>> think it is ordinary and nothing special. Tastes vary, but apparently this is
>> a common belief.   
>
>Being a 'common belief' does not indicate that it is 'correct'.

If the standard for 'correct', Mr Plinston, is 'that which is believed 
commonly' then being a 'common belief' most certainly *does* indicate that 
it is correct.

If you've a different standard in mind for 'correct' then, by all means, 
do be so kind as to indicate it.

DD

0
docdwarf (6044)
10/27/2004 11:47:38 PM
O shit, I had promised myself to stay out of this but it's tearing me
apart... <G>

Richard's position is a very British one (although he is a New Zealander by
adoption, he wasn't born here...). It is a pity he is being forced to defend
his position so vehemently, but that is often what happens when you say
people are "wrong"...<G> Might I suggest here that all parties cut each
other a little slack and just be thankful that we are able to have these
discussions because we share a knowledge of "English" (whatever you perceive
that to be...)?

Kiwis use BOTH "period" and "full stop" and none of the people I know would
ever instigate an argument over which is "correct". There is nothing wrong
with either of them. We are influenced here by both British and American
forms of the spoken (and, to a lesser extent, written) language.

This discussion has brought out some very interesting points regarding
"period" as a punctuation mark. I didn't know it was so old and I certainly
didn't know it was used by the British/English before the Americans got hold
of it.

To answer your question, Daniel:
>
> Do folks in NZ say "full stop" instead of "period" when they're
> emphasizing the finality of something?  Such as...
>
> "That is enough!  Period!  End of Story!"
> "That is enough!  Full stop!  End of Story!"
>
 I have actually heard BOTH of these exact statements made by people here.
(I distinctly recall my Mother using the second one verbatim, on a certain
occasion when I was a child...) We are fairly laid back as a general rule
and would be unlikely to get into a heated and lengthy argument over the use
of "Americanisms" (real or perceived). People use whatever they feel
comfortable with as long as the meaning is clear.

You will have seen from my posts that I tend to prefer the English spellings
rather than the American ones but that is just the result of my background
and upbringing. I certainly don't consider either to be "wrong", and there
is no argument (at least, not from me... <G>) against the case that the
American forms are more logical and simpler.

In recent years,  largely as a result of TV and film influences, we are
seeing more young people adopting American English ("butt" in particular has
almost replaced "bum" in common usage) and there are varying degrees of
resistance to this. I have noticed that it often depends on the individuals
politics... people who are fiercely anti-American (a considerable number,
sadly) tend to avoid using Americanisms, people who are fiercely
pro-American (I'm afraid that is a much smaller number) will use
Americanisms all the time, and the rest of us (by far the majority) simply
don't care.

I am also amazed at the furore over "plain vanilla". Personally, I wouldn't
consider this to be redundant or contradictory. Neither would I consider
"plain strawberry" or "plain anything else" to be so. For me the "plain" is
simply equivalent to "pure" and indicates that whatever follows is
unadulterated.

In my capacity as Editor I would not "correct" anyone using any of the
above.

Sometimes, when I read these threads I feel like one of Oliver Goldsmith's
"gaping rustic"s.

From "The Deserted Village"  ... "The Village Schoolmaster"

"In arguing too, the parson own'd his skill,
For e'en though vanquish'd he could argue still;
While words of learned length and thund'ring sound
Amazed the gaping rustics rang'd around;
And still they gaz'd and still the wonder grew,
That one small head could carry all he knew."

Pete.








0
dashwood1 (2140)
10/28/2004 2:16:55 AM
On Wed, 27 Oct 2004 15:08:28 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:


>But it seems to me the "new way" of specifying this functionality -- be it
>PERFORM WITH NO TEST, PERFORM FOREVER, or PERFORM UNTIL EXIT -- can be
>accomplished with 2002-compliant COBOL through REPLACE with no adjustments
>to the syntax or to the reserved word list (e.g., FOREVER).  It's my
>observation that providing new syntax supporting the exact functionality
>available elsewhere in the language has not historically been viewed with a
>great deal of enthusiasm as a "hot new feature" that deserves high priority.
>There was considerable opposition, for example, to the addition of "<>" as a
>synonym for "NOT EQUAL" in the 2008 draft, and the driving force for its
>acceptance was that ">=" and "<=" had already been included, and "<>" was
>reluctantly accepted on the grounds of syntactic symmetry.

">=" could have been accomplished with REPLACE. Why were they
reluctant on "<>" but not on ">="?
0
10/28/2004 2:28:05 AM
"Rick Smith" <ricksmith@mfi.net> wrote 

> PERFORM WITH NO TEST states there is "no test"
> to prevent entering the loop

I agree with that.

>  nor any test to cause the
> loop to terminate.

I disagree with that.  There is nothing to imply that it _is_ a loop.
Let us look at the reverse and add a test:

   PERFORM IF X = Y

Where 'IF X = Y' is the test.  This is quite different from:

   PERFORM WHILE X = Y

> It is the presence of WITH NO TEST
> that makes the loop infinite ("unbounded or unlimited").
> ..
> Compare this with the "plain vanilla" PERFORM which
> makes no mention of any test and therefore implies only
> to do this once.

PERFORM alone is unconditional - ie without a test.  That is why I
think that PERFORM WITH NO TEST is equivalent to PERFORM alone.  If it
was PERFORM WITH [some test] then I would think it would be
conditional, ie done none or one time.

That is, there is no WHILE, UNTIL, or TIMES time qualifier to indicate
that it should be done more than once.
 

> Having a value of any magnitude states that the loop
> is finite ("having bounds or limits") or definite ("having
> fixed limits").

I agree that PERFORM INDEFINITE TIMES should be a special case where
INDEFINITE is a reserved word that acts as if the value is never
reached, but for all practical purposes this can be used now without
waiting for a standards change.

(and isn't ugly like UNTIL ZERO NOT EQUAL ZERO).
0
riplin (4127)
10/28/2004 3:15:33 AM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410271915.4bd9d75c@posting.google.com...
> "Rick Smith" <ricksmith@mfi.net> wrote
>
> > PERFORM WITH NO TEST states there is "no test"
> > to prevent entering the loop
>
> I agree with that.
>
> >  nor any test to cause the
> > loop to terminate.
>
> I disagree with that.  There is nothing to imply that it _is_ a loop.

There are four forms for PERFORM.
PERFORM
PERFORM ... TIMES
PERFORM ... UNTIL
PERFORM ... VARYING

The first is unqualified and is not a loop.
The remaining three are qualified by phrases and are loops.
WITH NO TEST is a phrase qualifier for PERFORM.
Therefore PERFORM WITH NO TEST is a loop.

PERFORM WITH TEST BEFORE is a loop with
a test *before* entering and a test to terminate.
PERFORM WITH TEST AFTER is a loop with
no test to enter and a test *after* to terminate.
PERFORM WITH NO TEST is a loop with no test
to enter and no test to terminate.

That PERFORM WITH NO TEST is a loop is obvious,
once it is understood how it relates to the other WITHs.
To those who do not use WITH TEST BEFORE nor
use WITH TEST AFTER it may not be obvious.

Having considered the justification for the phrasing over
four years ago, it became so clear in my mind that it did
not occur to me that justification to others was necessary.
For that, I apologize.



0
ricksmith (875)
10/28/2004 6:36:24 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote 

> > The use of 'period' as full stop is contradictory to its other uses.
> > It should refer to all the sylabyls in the sentence to be consistent
> > with usage elsewhere.
> 
> Etymologically I don't think so.  From what I see, Medieval Latin "periodus"
> is both a period of time *and* a punctuation mark.

etymonline.com wrote:

"""period - 1413, "course or extent of time," from M.L. periodus
"recurring portion, cycle," from L. periodus "a complete sentence,"
also "cycle of the Greek games," from Gk. periodos "rounded sentence,
cycle, circuit, period of time," lit. "going around," from peri-
"around" + hodos "a going, way, journey." Sense of "repeated cycle of
events" led to that of "interval of time. .. """

I particularly liked the: 'from L. periodus "a complete sentence"'.
0
riplin (4127)
10/28/2004 7:14:37 AM
On 27 Oct 2004 20:15:33 -0700, riplin@Azonic.co.nz (Richard) wrote:

>I agree that PERFORM INDEFINITE TIMES should be a special case where
>INDEFINITE is a reserved word that acts as if the value is never
>reached, but for all practical purposes this can be used now without
>waiting for a standards change.
>
>(and isn't ugly like UNTIL ZERO NOT EQUAL ZERO).

This thread is like a debate over which brand of drain cleaner is best
tasting. All choices are ugly because there's no such thing as an
infinite loop. I want to see the _normal_ exit conditions in UNTIL,
for example PERFORM UNTIL USER-RESPONDED OR TIME-EXPIRED.

If there are exception conditions that can cause a premature exit, I
have no problem with using EXIT PERFORM in those cases. 

The fact that no syntax works for  out-of-line perform should tell you
the concept is flawed. For example PERFORM FOO UNTIL EXIT is truly an
infinite loop, therefore a bug  (without a GO TO). I would expect the
compiler to diagnose it as syntax error.

Having said that, I'm surprized no one suggested this, which works on
Micro Focus today: 

  PERFORM UNTIL FALSE [AND ...]
  PERFORM UNTIL TRUE [OR ...]

They could legitimately be used in debugging, similar to IF FALSE AND
....  to temporarily comment out code and IF TRUE OR ... to make it
execute unconditionally. 



0
10/28/2004 7:22:36 AM
In article <10o14v2br09njbd@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:

[snip]

>Having considered the justification for the phrasing over
>four years ago, it became so clear in my mind that it did
>not occur to me that justification to others was necessary.
>For that, I apologize.

Apologise for what, Mr Smith... demonstrating, in a way, that...

.... 'obvious is in the mind of the beholder'?

DD

0
docdwarf (6044)
10/28/2004 9:15:41 AM
In article <2ub34uF28dv3oU1@uni-berlin.de>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:

[snip]

>Richard's position is a very British one (although he is a New Zealander by
>adoption, he wasn't born here...). It is a pity he is being forced to defend
>his position so vehemently, but that is often what happens when you say
>people are "wrong"...<G>

Well, Mr Dashwood, there seems to be little problem with Mr Plinston's 
calling something 'wrong'... what seems amiss is an inability or refusal, 
thus far that I've read, to say, when encountered with a reference such as 
the OED, 'this is wrong according to...'; it seems as though he is 
appealing to some manner of Platonic form (eidos) of English... a neat 
trick, considering how much English seems to have been observed by 
Socrates.

As for gaping rustics, slack-jawed yokels and other such savory 
bystanders... the water's fine, come on in!  If you deem the combat grows 
too fierce for direct participation there's nothing to stop you from 
indulging in that time-honored technique of standing on the sidelines and 
indiscriminately tossing in chairs and ashtrays.

DD

0
docdwarf (6044)
10/28/2004 9:25:46 AM
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:2ub34uF28dv3oU1@uni-berlin.de...
> Kiwis use BOTH "period" and "full stop" and none of the people I know
would
> ever instigate an argument over which is "correct". There is nothing wrong
> with either of them. We are influenced here by both British and American
> forms of the spoken (and, to a lesser extent, written) language.

How about the newspaper reporters in Ye Olden Dayse breathlessly phoning in
their stories?

"The curse of the bambino is dead stop with a three to nothing*  win over
saint louis the boston red sox buried it stop ....."


MCM
* 'nil' for our British friends






0
10/28/2004 11:26:03 AM
On 27-Oct-2004, riplin@Azonic.co.nz (Richard) wrote:

> I doubt that it is anything like that at all. It has nothing to do
> with whether people like vanilla or prefer unflavoured. It would be
> more like saying "'colourless red' is wrong".

Or like saying "plain red lipstick vs fancy red lipstick".

Plain does not mean "unflavored", it does not mean "colorless".   Something that
is plain is not devoid of attributes.
0
howard (6283)
10/28/2004 1:55:50 PM
On 27-Oct-2004, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:

> I am also amazed at the furore over "plain vanilla". Personally, I wouldn't
> consider this to be redundant or contradictory. Neither would I consider
> "plain strawberry" or "plain anything else" to be so. For me the "plain" is
> simply equivalent to "pure" and indicates that whatever follows is
> unadulterated.

Plain vanilla ice cream doesn't taste like strawberry vanilla ice cream nor
French vanilla ice cream.
0
howard (6283)
10/28/2004 1:59:18 PM
On 28-Oct-2004, docdwarf@panix.com wrote:

> Well, Mr Dashwood, there seems to be little problem with Mr Plinston's
> calling something 'wrong'... what seems amiss is an inability or refusal,
> thus far that I've read, to say, when encountered with a reference such as
> the OED, 'this is wrong according to...'; it seems as though he is
> appealing to some manner of Platonic form (eidos) of English... a neat
> trick, considering how much English seems to have been observed by
> Socrates.

There's a long tradition of this - how long did people believe that it was
improper to end an English sentence with a preposition?

A quick Google got me: http://www.ling.upenn.edu/~kingsbur/lingjokes.html

The next one strings together more prepositions than is usually recommended...
The speaker is the parent of a young child, inquiring about said child's choice
of a bedside story during recent vacation in Australia:

"What did you choose that book to be read to out of down under for?"

If you like strings of prepositions, note that the example sentence (the little
boy's remark) can be altered as follows:

The boy was back home in England but the book was about Australian cricket.
Accordingly:

"What did you bring the book that I didn't want to be read to out of about over
after over down in Down Under up for?"
0
howard (6283)
10/28/2004 2:03:20 PM
"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:4ga0o0t8hs2aog8ppb3g386vmepkls952r@4ax.com...

> ">=" could have been accomplished with REPLACE. Why were they
> reluctant on "<>" but not on ">="?

">=" and "<=" were added in '85.  By 2000 or so, some felt that might have
been a mistake; certainly it violates the precept "... and avoid symbolism
as far as possible. ..." (ANSI X3.23-1985 page XVII-1, first paragraph,
penultimate sentence).

    -Chuck Stevens


0
10/28/2004 2:40:52 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:clqu77$mia$1@peabody.colorado.edu...

> There's a long tradition of this - how long did people believe that it was
> improper to end an English sentence with a preposition?

I was taught that this rule came out of the perception that Latin was the
root of all civilized discourse and prose, and because it was impossible to
end a sentence with a preposition in Latin it was inappropriate to do so in
English.  The same is true for the split infinitive; an infinitive in
English should not be split because an infinitive in Latin *cannot* be
split.  Ditto for the double negative; it takes convoluted and conscious
application of artificial rules of "proper English" to conclude that a
storekeeper who states "We don't have no bananas" actually has bananas for
sale, and the conclusion would almost certainly be erroneous.  The same is
true for the largely-British shall/will conjugation ("I shall, you will, he
will" vs. "I will, you shall, he shall"); that one was invented out of whole
cloth by a self-appointed grammarian a few centuries ago.  Many of the rules
of "proper English" have little or nothing to do with English.

    -Chuck Stevens


0
10/28/2004 3:13:21 PM
On 28-Oct-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> Ditto for the double negative; it takes convoluted and conscious
> application of artificial rules of "proper English" to conclude that a
> storekeeper who states "We don't have no bananas" actually has bananas for
> sale, and the conclusion would almost certainly be erroneous.

I don't see how this one fits with your others.   There are occasions where we
certainly do want to communicate a double negative as a positive, and having a
language that allows this is useful.
0
howard (6283)
10/28/2004 3:28:46 PM
In article <clqu77$mia$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 28-Oct-2004, docdwarf@panix.com wrote:
>
>> Well, Mr Dashwood, there seems to be little problem with Mr Plinston's
>> calling something 'wrong'... what seems amiss is an inability or refusal,
>> thus far that I've read, to say, when encountered with a reference such as
>> the OED, 'this is wrong according to...'; it seems as though he is
>> appealing to some manner of Platonic form (eidos) of English... a neat
>> trick, considering how much English seems to have been observed by
>> Socrates.
>
>There's a long tradition of this - how long did people believe that it was
>improper to end an English sentence with a preposition?

This belief, Mr Brazee, was supported in commonly-accepted and 
prescriptive guides to language style; while there was no Academie Anglais 
to set Official Use there were, most likely, interchanges such as:

'Jones, you've ended this sentence with a preposition... won't do, you'll 
have to change it.'

'For what reason?'

'We here at The Flotsam use the King's English, as laid out in 'English As 
She Is Spoke' by Ivor Biggun; page 38 states 'A preposition is something 
we don't end a sentence with.'

This is not to say, of course, that Ivor Biggun is the end-all and be-all 
of English language useage rules... but that it was considered a 
commonly-accepted source of such things.  Likewise with dictionaries; 
arguments over the descriptive versus prescriptive nature of such tomes 
aside when it is stated that 'those who call 'a fixed tub for bathing' a 
'bathub' are wrong, a 'bathtub' is 'a rotary engine actuated by the 
reaction or impulse or both of a current of fluid (as water, steam, or 
air) subject to pressure and usually made with a series of curved vanes on 
a central rotating spindle'.'...

.... then it might be asked 'what is your source for this definition, 
please?'

DD
0
docdwarf (6044)
10/28/2004 3:38:17 PM
"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:kb61o0trndv8m3torop3obncpp6og8od8o@4ax.com...
> The fact that no syntax works for  out-of-line perform should tell you
> the concept is flawed. For example PERFORM FOO UNTIL EXIT is truly an
> infinite loop, therefore a bug  (without a GO TO). I would expect the
> compiler to diagnose it as syntax error.

I haven't yet seen the reasons "EXIT PERFORM" was precluded from use within
out-of-line PERFORM ranges.  As I stated before, our implementation allows
this as an extension.  Upon execution of an EXIT PERFORM, the "innermost"
active PERFORM in the program is exited, and if there isn't one, execution
proceeds to the next statement as if CONTINUE had been coded.

I agree that an out-of-line indefinite PERFORM pretty much requires either
the despised GO TO or the prohibited EXIT PERFORM, but I'm not really
opposed to relaxing the restriction on the latter, unless someone convinces
me that there's a good reason why it's there.  .

> Having said that, I'm surprized no one suggested this, which works on
> Micro Focus today:
>
>   PERFORM UNTIL FALSE [AND ...]
>   PERFORM UNTIL TRUE [OR ...]

Yes, TRUE and FALSE are reserved words as early as ANSI X3.23-1985,
introduced, I believe, in support of EVALUATE.  To this the 2002 standard
added the use of FALSE in the VALUE clause of 88-level items (WHEN SET TO
FALSE) and both values in the SET statement for 88's.   Adding "PERFORM
UNTIL FALSE" would not require new reserved words.

> They could legitimately be used in debugging, similar to IF FALSE AND
> ...  to temporarily comment out code and IF TRUE OR ... to make it
> execute unconditionally.

I'm not sure what you mean by :"IF FALSE [or TRUE] AND ..." specifically as
it relates to COBOL; these are extensions as well.  TRUE/FALSE are allowed
only in the contexts mentioned above, so far as I know, in '02 COBOL.
n-names (88's); (2) in EVALUATE; and (3) SET <condition-name>.   You can
accomplish much the same thing with directives in '02 COBOL.

Note that I do understand the point; we use "IF FALSE ..." and "WHILE FALSE
.... " constructs all the time in ALGOL and its relatives and descendants for
exactly this purpose, by the way.

    -Chuck Stevens


0
10/28/2004 3:51:50 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:clr37e$phc$1@peabody.colorado.edu...

> I don't see how this one fits with your others.   There are occasions
where we
> certainly do want to communicate a double negative as a positive, and
having a
> language that allows this is useful.

And when we do so, it's my experience, observation and training that we make
it clear by intonation and emphasis that this is the case, most typically by
emphasizing the multiple nature of the negatives e.g., "We *don't* have *no*
bananas"; failing that, one must fall back on contexts (an even number of
negatives cancel out in a philosophy class, whereas reduplication of
negatives in street speech simply leaves the result negative).  The
single-negative rule is not *native* to English; it was imposed as a mark of
"educated thinking" by those who spoke Latin, in which language the rule
does apply.

    -Chuck Stevens


0
10/28/2004 4:00:54 PM
On 28-Oct-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> I agree that an out-of-line indefinite PERFORM pretty much requires either
> the despised GO TO or the prohibited EXIT PERFORM, but I'm not really
> opposed to relaxing the restriction on the latter, unless someone convinces
> me that there's a good reason why it's there.  .

The question here is what would an EXIT PARAGRAPH do.   I was assuming it would
do the same thing as an EXIT PERFORM does in an in-line perform.

Some languages have two types of exits to their equivalents of performs.
1.   Skip the rest of this iteration of the perform-loop and go to the next
iteration
2.   Skip the rest of this iteration of the perform-loop and exit the perform
altogether.

Both of these are useful tools, and both should be considered when proposing
this change.

EXIT-CONTINUE anybody?
0
howard (6283)
10/28/2004 4:26:45 PM
..    On  27.10.04
  wrote  charles.stevens@unisys.com (Chuck Stevens)
     on  /COMP/LANG/COBOL
     in  clp68s$1jgu$1@si05.rsvl.unisys.com
  about  Re: Report enhancements


CS> If the justification for suggesting that there's a capability that
CS> needs to be added to 20xx COBOL because it's not in 1985 COBOL, it
CS> might be a good idea to see if that capability exists in the
CS> *current* standard and/or the draft of the *next* one!

   The functionality of GOBACK has long been in the COBOL standard by  
means of the EXIT statement -- so why has this duplication been added?


CS> But it seems to me the "new way" of specifying this functionality --
CS> be it PERFORM WITH NO TEST, PERFORM FOREVER, or PERFORM UNTIL
CS> EXIT -- can be accomplished with 2002-compliant COBOL through
CS> REPLACE with no adjustments to the syntax or to the reserved word
CS> list (e.g., FOREVER).

   It is not the same to specify a dummy condition test for entering a  
loop on the one hand and to specify that there is no test at all.

   That a cute compiler and optimizer can prevent that dummy-condition  
being evaluated for every cycle of the loop, does not create the  
clarity of the program for a human reader.

   I repeat what I had stated before: I don't feel an urgent need to  
have that functionality added, because I prefer loops to have their  
proper entry or exit condition at the beginning or the end, but not  
somewhere in the middle. But because the EXIT PERFORM is already in  
the standard (2002), and there _are_ situations where such a loop may  
be needed ... i.e. for the sake of completeness.


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

Er trieb einen kleinen Finsternis-Handel. -G.C.Lichtenberg
0
l.willms1 (637)
10/28/2004 4:27:00 PM
On 28-Oct-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> And when we do so, it's my experience, observation and training that we make
> it clear by intonation and emphasis that this is the case, most typically by
> emphasizing the multiple nature of the negatives e.g., "We *don't* have *no*
> bananas"; failing that, one must fall back on contexts (an even number of
> negatives cancel out in a philosophy class, whereas reduplication of
> negatives in street speech simply leaves the result negative).  The
> single-negative rule is not *native* to English; it was imposed as a mark of
> "educated thinking" by those who spoke Latin, in which language the rule
> does apply.

I didn't know it was one of those.

It *is* native to CoBOL though.
0
howard (6283)
10/28/2004 4:43:41 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:clr6k5$ra8$1@peabody.colorado.edu...
>
> On 28-Oct-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> > I agree that an out-of-line indefinite PERFORM pretty much requires
either
> > the despised GO TO or the prohibited EXIT PERFORM, but I'm not really
> > opposed to relaxing the restriction on the latter, unless someone
convinces
> > me that there's a good reason why it's there.  .
>
> The question here is what would an EXIT PARAGRAPH do.   I was assuming it
would
> do the same thing as an EXIT PERFORM does in an in-line perform.

"The execution of an EXIT PARAGRAPH statement causes control to be passed to
an implicit CONTINUE statement immediately following the last explicit
statement of the current paragraph, preceding any return mechanisms for that
paragraph."     EXIT PARAGRAPH would NOT terminate the execution of an
out=of-line PERFORM, it'd just bypass the code that might have been executed
from the point at which it occurred to the end of the perform range.

> Some languages have two types of exits to their equivalents of performs.
> 1.   Skip the rest of this iteration of the perform-loop and go to the
next
> iteration
> 2.   Skip the rest of this iteration of the perform-loop and exit the
perform
> altogether.
>
> Both of these are useful tools, and both should be considered when
proposing
> this change.
>
> EXIT-CONTINUE anybody?

For out-of-line PERFORMs, the first can be handled by proper structure of
the code and EXIT PARAGRAPH; I'd be inclined to allow EXIT PERFORM in
out-of-line PERFORMs which I'd expect to provide the second.  Again, given
all the enhancements to EXIT that went into the 2002 standard, I'm at
somewhat of a loss as to understand why this wasn't allowed in the first
place, unless it was intended as a "toe in the water" approach to the
construct to make sure it didn't fall over and break something.

Certainly I don't see a problem with allowing EXIT PERFORM in our
implementation; we were doing EXIT HERE in COBOL(68) as an extension back in
the Dark Ages (maybe mid 1970's?).  In response to complaints that we
couldn't do the same thing in COBOL74, I added EXIT PERFORM  in 1987 (using
the syntax proposed for the post-1985 standard) and haven't seen a single
indication of a failure involving it since.

    -Chuck Stevens


0
10/28/2004 5:19:48 PM
On 28-Oct-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

>    I repeat what I had stated before: I don't feel an urgent need to
> have that functionality added, because I prefer loops to have their
> proper entry or exit condition at the beginning or the end, but not
> somewhere in the middle. But because the EXIT PERFORM is already in
> the standard (2002), and there _are_ situations where such a loop may
> be needed ... i.e. for the sake of completeness.

For that I kind of like the syntax PERFORM UNTIL EXIT.    But that doesn't solve
the question on how to get out of a perform loop and restart it.

Possibly something like this:

PERFORM UNTIL EXIT
	PERFORM GET-PARM	
	EVALUATE MY-PARM
		WHEN X	
			EXIT PERFORM CONTINUE
		WHEN Y
			EXIT PERFORM
		WHEN OTHER
 			PERFORM PARM-ROUTINE
	END EVALUATE
END PERFORM
0
howard (6283)
10/28/2004 5:26:17 PM
Howard Brazee wrote:
> 
> On 28-Oct-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
> 
> > I agree that an out-of-line indefinite PERFORM pretty much requires either
> > the despised GO TO or the prohibited EXIT PERFORM, but I'm not really
> > opposed to relaxing the restriction on the latter, unless someone convinces
> > me that there's a good reason why it's there.  .
> 
> The question here is what would an EXIT PARAGRAPH do.   I was assuming it would
> do the same thing as an EXIT PERFORM does in an in-line perform.
> 
> Some languages have two types of exits to their equivalents of performs.
> 1.   Skip the rest of this iteration of the perform-loop and go to the next
> iteration
> 2.   Skip the rest of this iteration of the perform-loop and exit the perform
> altogether.
> 
> Both of these are useful tools, and both should be considered when proposing
> this change.
> 
> EXIT-CONTINUE anybody?

Seems to me you're adhering to a principle at the expense of
simplicity.  If you have two different types of your exit
paragraph/perform, and both of them are exactly equivalent to a GOTO -
why not use a GOTO?  Then there'd be no question as to which type of
exit you're doing, nor would there be any doubt as to where control
resumes.

(Disclaimer: I don't care which gets used as long as it is perfectly
clear to TPB (The Poor Bugger who does maintenance) what's happening).

PL
0
lacey (134)
10/28/2004 5:54:05 PM
"Rick Smith" <ricksmith@mfi.net> wrote 

> > I disagree with that.  There is nothing to imply that it _is_ a loop.
> 
> There are four forms for PERFORM.
> PERFORM
> PERFORM ... TIMES
> PERFORM ... UNTIL
> PERFORM ... VARYING
> 
> The first is unqualified and is not a loop.
> The remaining three are qualified by phrases and are loops.
> WITH NO TEST is a phrase qualifier for PERFORM.
> Therefore PERFORM WITH NO TEST is a loop.

That is false reasoning.  You are saying that _any_ qualifier, no
matter what it may be implies a loop, while I see it only implying a
loop only if the words actually mean something that would imply a
loop.

If thare was a PERFORM IF <condition> then your argument would have
that as a loop because there is a qualifier.

> PERFORM WITH TEST BEFORE is a loop with
> a test *before* entering and a test to terminate.
> PERFORM WITH TEST AFTER is a loop with
> no test to enter and a test *after* to terminate.

No. That is not true, it is only a loop if there is an UNTIL clause.
The WITH TEST cannot be specified without an UNTIL.

> PERFORM WITH NO TEST is a loop with no test
> to enter and no test to terminate.

But you would still need the UNTIL unless you break the current
syntax.  Taking out the UNTIL removes the loop clause.

Actually your PERFORM VARYING also requires UNTIL so the only two
looping clauses are PERORM UNTIL and PERFORM TIMES.

> That PERFORM WITH NO TEST is a loop is obvious,
> once it is understood how it relates to the other WITHs.

Yes, that it true.  Once you understand that WITH .. TEST .. requires
the UNTIL it will be obvious to you that it is the UNTIL that makes it
a loop.

> To those who do not use WITH TEST BEFORE nor
> use WITH TEST AFTER it may not be obvious.

Is that right ?
 
> Having considered the justification for the phrasing over
> four years ago, it became so clear in my mind that it did
> not occur to me that justification to others was necessary.
> For that, I apologize.

I suspect that J4 may need a little bit of justification.  Did you
submit it 4 years ago ?
0
riplin (4127)
10/28/2004 6:18:06 PM
On 28-Oct-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:

> Seems to me you're adhering to a principle at the expense of
> simplicity.  If you have two different types of your exit
> paragraph/perform, and both of them are exactly equivalent to a GOTO -
> why not use a GOTO?  Then there'd be no question as to which type of
> exit you're doing, nor would there be any doubt as to where control
> resumes.

Nothing wrong with GOTO.   It's labels and drop-thru code that causes troubles.
 Trouble is, they go together.   EXITs don't get the labels mixed up.
0
howard (6283)
10/28/2004 6:32:04 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:clr7jt$rts$1@peabody.colorado.edu...

> I didn't know it [the double negative] was one of those.
>
> It *is* native to CoBOL though.

True enough, although rather (IMHO) less ambiguously now that NOT in and of
itself qualifies an immediately-following relational operator as "extended"
rather than "simple" (see J4/03-0224)!        ;-)
    -Chuck Stevens


0
10/28/2004 6:51:15 PM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9Jj8aVw9flB@jpberlin-l.willms.jpberlin.de...

>    The functionality of GOBACK has long been in the COBOL standard by
> means of the EXIT statement -- so why has this duplication been added?

I'm not a fan of GOBACK, and would have argued against it had it been up for
discussion during my tenure, but that wasn't the case.

I don't agree that the functionality of GOBACK is directly and completely
reflected within EXIT, even in '02 COBOL.  A GOBACK executed in a
"standalone program" does a STOP RUN, not an EXIT PROGRAM (which in that
context would CONTINUE).  I do agree that GOBACK accomplishes what, in a
particular context, might be a STOP RUN, an EXIT PROGRAM, an EXIT METHOD or
an EXIT FUNCTION, but which is appropriate should be obvious from context,
and I personally prefer the explicit instruction to the "generic" GOBACK to
wherever you came from, using whatever method is appropriate to the way you
got here.

>  It is not the same to specify a dummy condition test for entering a
> loop on the one hand and to specify that there is no test at all.

Specifying no test at all for a PERFORM is also not the same as specifying
that the PERFORMed code be executed repetitively, as others have pointed
out.

> That a cute compiler and optimizer can prevent that dummy-condition
> being evaluated for every cycle of the loop, does not create the
> clarity of the program for a human reader.

REPLACE does, though.  And the execution-time evaluation of the
dummy-condition, when the condition can be shown invariate, isn't the
*standard's* business.

> I repeat what I had stated before: I don't feel an urgent need to
> have that functionality added, because I prefer loops to have their
> proper entry or exit condition at the beginning or the end, but not
> somewhere in the middle. But because the EXIT PERFORM is already in
> the standard (2002), and there _are_ situations where such a loop may
> be needed ... i.e. for the sake of completeness.

Whatever syntax can be constructed for getting into and out of a "perform
forever" should be usable and meaningful in both in-line and out-of-line
cases.  The restriction of EXIT PERFORM to in-line functionally restricts
the use of "forever perform" syntax to the in-line subset.

I think a prerequisite for providing syntax for "perform forever" should be
to ensure that we have a *single* way to get out of that "perform forever"
that doesn't involve GO TO, whether the "forever" perform is in-line or
out-of-line.   We have that syntax -- EXIT PERFORM -- but it's allowed only
on in-line performs.

Once we have that, how you describe a "perform forever" is pretty much
incidental.  Implementations that already allow EXIT PERFORM in out-of-line
performs, and which reduce invariant conditional expressions at compile time
"don't need no steenkin' syntax!", they can do it today.

     -Chuck Stevens


0
10/28/2004 7:14:40 PM
..     Am  28.10.04
 schrieb  spamblocker-robert@wagner.net (Robert Wagner)
     bei  /COMP/LANG/COBOL
      in  kb61o0trndv8m3torop3obncpp6og8od8o@4ax.com
   ueber  Re: Report enhancements

RW> Having said that, I'm surprized no one suggested this, which works on
RW> Micro Focus today:
RW>
RW>   PERFORM UNTIL FALSE [AND ...]
RW>   PERFORM UNTIL TRUE [OR ...]

   It doesn't work in Fujitsu COBOL 3.0


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)
10/28/2004 7:45:00 PM
On Thu, 28 Oct 2004 08:51:50 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
>news:kb61o0trndv8m3torop3obncpp6og8od8o@4ax.com...
>> The fact that no syntax works for  out-of-line perform should tell you
>> the concept is flawed. For example PERFORM FOO UNTIL EXIT is truly an
>> infinite loop, therefore a bug  (without a GO TO). I would expect the
>> compiler to diagnose it as syntax error.
>
>I haven't yet seen the reasons "EXIT PERFORM" was precluded from use within
>out-of-line PERFORM ranges. 

I think the reason is syntactical. EXIT FOO can be read GO TO
(nearest) END-FOO (and stop looping for perform), where END-FOO can be
explicit or implicit. An out-of-line EXIT PERFORM cannot ascertain
where the exit is by syntax alone; it must get the address from the
stack at execution time.

> As I stated before, our implementation allows
>this as an extension.  Upon execution of an EXIT PERFORM, the "innermost"
>active PERFORM in the program is exited, and if there isn't one, execution
>proceeds to the next statement as if CONTINUE had been coded.

You are using semantics rather than syntax. To this outside observer,
it seems J4 would not be receptive. 

>I agree that an out-of-line indefinite PERFORM pretty much requires either
>the despised GO TO or the prohibited EXIT PERFORM, but I'm not really
>opposed to relaxing the restriction on the latter, unless someone convinces
>me that there's a good reason why it's there.  

I can't think of a good reason.

>> Having said that, I'm surprized no one suggested this, which works on
>> Micro Focus today:
>>
>>   PERFORM UNTIL FALSE [AND ...]
>>   PERFORM UNTIL TRUE [OR ...]
>
>Yes, TRUE and FALSE are reserved words as early as ANSI X3.23-1985,
>introduced, I believe, in support of EVALUATE.  To this the 2002 standard
>added the use of FALSE in the VALUE clause of 88-level items (WHEN SET TO
>FALSE) and both values in the SET statement for 88's.   Adding "PERFORM
>UNTIL FALSE" would not require new reserved words.

But it would require TRUE and FALSE to be boolean literals, as they
are in most other languages and in Micro Focus as an extension.

While we're on the subject, it seems asymmetrical that we can say SET
CONDITION-1 TO FALSE  but cannot say

01    PIC X VALUE FALSE.
       88  CONDITION-1 VALUES 'A' 'B' 'C' FALSE 'D'. 

When the value of false changes to 'E', we must change 01 VALUE as
well as 88 VALUES. That's contrary to the spirit of 88s.

>> They could legitimately be used in debugging, similar to IF FALSE AND
>> ...  to temporarily comment out code and IF TRUE OR ... to make it
>> execute unconditionally.
>
>I'm not sure what you mean by :"IF FALSE [or TRUE] AND ..." specifically as
>it relates to COBOL; these are extensions as well.  TRUE/FALSE are allowed
>only in the contexts mentioned above, so far as I know, in '02 COBOL.
>n-names (88's); (2) in EVALUATE; and (3) SET <condition-name>.   You can
>accomplish much the same thing with directives in '02 COBOL.

Examples follow. Please explain how we can do this with '02 features.

  IF (A OR B OR C)
D    or true            *> forced true when debugging
      MOVE D TO E
      PERFORM FOO
  END-IF

  IF (A OR B OR C)
D    and false         *> bypass when debugging
      ....
  END-IF

  PERFORM UNTIL (A OR B)
D    or true             *> bypass when debugging
  ....
  END-PERFORM

0
10/28/2004 8:17:21 PM
On Thu, 28 Oct 2004 16:26:45 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>
>On 28-Oct-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>> I agree that an out-of-line indefinite PERFORM pretty much requires either
>> the despised GO TO or the prohibited EXIT PERFORM, but I'm not really
>> opposed to relaxing the restriction on the latter, unless someone convinces
>> me that there's a good reason why it's there.  .
>
>The question here is what would an EXIT PARAGRAPH do.   I was assuming it would
>do the same thing as an EXIT PERFORM does in an in-line perform.

>Some languages have two types of exits to their equivalents of performs.
>1.   Skip the rest of this iteration of the perform-loop and go to the next
>iteration
>2.   Skip the rest of this iteration of the perform-loop and exit the perform
>altogether.
>
>Both of these are useful tools, and both should be considered when proposing
>this change.

Cobol already has syntax for both, but they can be used only for
inline performs. 1. is EXIT PERFORM CYCLE; 2. is EXIT PERFORM.

EXIT PARAGRAPH in an out-of-line perform does the same as EXIT PERFORM
CYCLE, number 1.  There is no way to do number 2 (except GO TO).

0
10/28/2004 8:17:24 PM
On 28-Oct-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> Cobol already has syntax for both, but they can be used only for
> inline performs. 1. is EXIT PERFORM CYCLE; 2. is EXIT PERFORM.
>
> EXIT PARAGRAPH in an out-of-line perform does the same as EXIT PERFORM
> CYCLE, number 1.  There is no way to do number 2 (except GO TO).

I hadn't heard of EXIT PERFORM CYCLE.   It would take major pushing by IBM to
get many shops to upgrade, so I don't know if I will ever see it.

Too bad that ability isn't complete.
0
howard (6283)
10/28/2004 8:49:44 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410281018.3ee68b09@posting.google.com...
> "Rick Smith" <ricksmith@mfi.net> wrote
>
> > > I disagree with that.  There is nothing to imply that it _is_ a loop.
> >
> > There are four forms for PERFORM.
> > PERFORM
> > PERFORM ... TIMES
> > PERFORM ... UNTIL
> > PERFORM ... VARYING
> >
> > The first is unqualified and is not a loop.
> > The remaining three are qualified by phrases and are loops.
> > WITH NO TEST is a phrase qualifier for PERFORM.
> > Therefore PERFORM WITH NO TEST is a loop.
>
> That is false reasoning.  You are saying that _any_ qualifier, no
> matter what it may be implies a loop, while I see it only implying a
> loop only if the words actually mean something that would imply a
> loop.

The implication is the result of language constructs in
COBOL; not in English. There are limits as to how far one
may go in natural language to reason about an artificial
(or contrived) language. What may be implied (or inferred)
by English does not necessarily apply to COBOL.

PERFORM without any qualifier means no loop. Any
PERFORM with a qualifier means a loop; because to add a
construct where the presence of a qualifier means exactly the
same as a construct without the qualifier is absurd. [This does
not apply to "noise" words, which are intended for the reader
of the program and are, in no way, qualifiers to any statement
within COBOL]

> If thare was a PERFORM IF <condition> then your argument would have
> that as a loop because there is a qualifier.

No, it's an absurdity; no further argument need be made.

> > PERFORM WITH TEST BEFORE is a loop with
> > a test *before* entering and a test to terminate.
> > PERFORM WITH TEST AFTER is a loop with
> > no test to enter and a test *after* to terminate.
>
> No. That is not true, it is only a loop if there is an UNTIL clause.
> The WITH TEST cannot be specified without an UNTIL.

My apologies. The "UNTIL condition" was implied since
the discussion was about a replacement equivalent to
PERFORM UNTIL EXIT or PERFORM UNTIL 1 = 0
or PERFORM UNTIL ZERO IS NOT ZERO.

Are you saying that PERFORM WITHOUT LIMIT and
PERFORM WITH NO LIMITS, found in some compilers,
are not loops because they do not have UNTIL?

> > PERFORM WITH NO TEST is a loop with no test
> > to enter and no test to terminate.
>
> But you would still need the UNTIL unless you break the current
> syntax.  Taking out the UNTIL removes the loop clause.

I prefer "amend the current syntax" to remove the
requirement for "UNTIL condition," when WITH NO
TEST is used; since its presence would be absurd.

> Actually your PERFORM VARYING also requires UNTIL so the only two
> looping clauses are PERORM UNTIL and PERFORM TIMES.

That PERFORM VARYING is a loop is defined by
PERFORM statement, GR9.

> > That PERFORM WITH NO TEST is a loop is obvious,
> > once it is understood how it relates to the other WITHs.
>
> Yes, that it true.  Once you understand that WITH .. TEST .. requires
> the UNTIL it will be obvious to you that it is the UNTIL that makes it
> a loop.

That  PERFORM ... UNTIL is a loop, is defined by
PERFORM statement, GR8; not by implication from the
use of UNTIL. That WITH NO TEST is a loop would
also be defined by a general rule. It is this that preserves
the idea that a PERFORM with a qualifier is a loop.

> > To those who do not use WITH TEST BEFORE nor
> > use WITH TEST AFTER it may not be obvious.
>
> Is that right ?
>
> > Having considered the justification for the phrasing over
> > four years ago, it became so clear in my mind that it did
> > not occur to me that justification to others was necessary.
> > For that, I apologize.
>
> I suspect that J4 may need a little bit of justification.  Did you
> submit it 4 years ago ?

No, a bit more than a month earlier, I stopped trying
to work due to my disability. Let's say I had other things
on my mind.



0
ricksmith (875)
10/28/2004 8:56:32 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:clrm18$8j4$1@peabody.colorado.edu...

> I hadn't heard of EXIT PERFORM CYCLE.   It would take major pushing by IBM
to
> get many shops to upgrade, so I don't know if I will ever see it.

Not more than any other feature in the 2002 standard, and in my opinion it
wouldn't take much to provide it in an implementation that already had EXIT
PERFORM

> Too bad that ability isn't complete.

Which ability?  The ability to do an EXIT PERFORM CYCLE in an out-of-line
PERFORM?  Yeah, I think I'd argue for that, unless (again) somebody can
convince me it's a bad idea!

    -Chuck Stevens


0
10/28/2004 9:27:07 PM
Robert Wagner wrote:

> I think the reason is syntactical. EXIT FOO can be read GO TO
> (nearest) END-FOO (and stop looping for perform), where END-FOO can be
> explicit or implicit.

Not sure what this means; could you clarify?

> An out-of-line EXIT PERFORM cannot ascertain
> where the exit is by syntax alone; it must get the address from the
> stack at execution time.

This I understand.  The object code has a problem figuring out whether the
statement is executed under control of a PERFORM by examining the stack at
execution time ... exactly why?

All our compilers need to generate for out-of-line EXIT PERFORM is DUPL,
ZERO, GRTR, BRFL (continue), DLET, DBUN.  If what's on the top of the stack
at the start of *any* statement is a zero, we're not in an active
out-of-line PERFORM (unless the stack is munged, in which case we're hosed
anyway); if it isn't, we are.  Looks really simple to me.

> You are using semantics rather than syntax. To this outside observer,
> it seems J4 would not be receptive.


Not sure I understand why not.  EXIT PERFORM is *syntactically* disallowed
outside the context of an *inloine* PERFORM; I'm not convinced the
restriction is appropriate.  The proposed *semantics* of EXIT PERFORM would
be exactly analogous to those of EXIT PROGRAM when the program in question
wasn't CALLed -- CONTINUE.  I don't see what it'd *break* to provide it, and
I can certainly see the utility (of both EXIT PERFORM and EXIT PERFORM
CYCLE) in the context of an out-of-line PERFORM, not just for clarity of
syntax but for functionality otherwise unavailable (except for GO TO).

> >I agree that an out-of-line indefinite PERFORM pretty much requires
either
> >the despised GO TO or the prohibited EXIT PERFORM, but I'm not really
> >opposed to relaxing the restriction on the latter, unless someone
convinces
> >me that there's a good reason why it's there.
>
> I can't think of a good reason.

Well, there ya go.  That's my point.

> But it would require TRUE and FALSE to be boolean literals, as they
> are in most other languages and in Micro Focus as an extension.

No, not quite right.  The syntax rules can permit their use in specific
contexts.


> While we're on the subject, it seems asymmetrical that we can say SET
> CONDITION-1 TO FALSE  but cannot say
>
> 01    PIC X VALUE FALSE.
>        88  CONDITION-1 VALUES 'A' 'B' 'C' FALSE 'D'.

I think you've misunderstood.  VALUE FALSE applies *only* to 88's, and the
filler isn't an 88.

I see no inconsistency.  *ALL* the values save 'A', 'B' and 'C' would result
in CONDITION-1 being FALSE; there may be any number of FALSE values.  There
may be only one such value to which the parent item is set *when* you SET
the condition to FALSE.   "VALUE FALSE" is unnecessary as well as
meaningless on the PIC X item.

> When the value of false changes to 'E', we must change 01 VALUE as
> well as 88 VALUES. That's contrary to the spirit of 88s.

'E' is but one of probably 253 values for the PIC X item that would cause
CONDITION-1 to be FALSE.  VALUE FALSE has nothing to do with the value that
RESULTS in FALSE, it only specifies which value is used when it is
EXPLICITLY SET to FALSE.

> Examples follow. Please explain how we can do this with '02 features.

Easy.

Method 1:   Use >>DEFINE I-AM-DEBUGGING at the beginning of the program and
>>IF I-AM-DEBUGGING... >> END-IF pairs around the IFs and END-IFs.   Maybe
not quite as elegant as your examples, but functional.

Method 2:

    D77  PIC 9 VALUE 1.
    D88  ITS-TRUE VALUE 1.
    D88  ITS-FALSE VALUE 0.

    D     OR ITS-TRUE   ...
    D    AND ITS-FALSE ...

Oh.  Wait.  That works in COBOL85.  To get it up to COBOL2002 I'd have to do
something like USAGE BIT ...

    -Chuck Stevens


0
10/28/2004 10:08:50 PM
"Chuck Stevens" <charles.stevens@unisys.com> wrote 

> "The execution of an EXIT PARAGRAPH statement causes control to be passed to
> an implicit CONTINUE statement immediately following the last explicit
> statement of the current paragraph, preceding any return mechanisms for that
> paragraph."     EXIT PARAGRAPH would NOT terminate the execution of an
> out=of-line PERFORM, it'd just bypass the code that might have been executed
> from the point at which it occurred to the end of the perform range.

It certainly goes to the end of the paragraph, but this would only be
the end of the perform range if the perform was only of that
paragraph.  If it was a PERFORM section then it may continue at the
next paragraph of that section.

An EXIT SECTION would end the current perform cycle if it was a
performed section and would, potentially, make the program go berzerk
if it was a performed paragraph.
0
riplin (4127)
10/28/2004 11:38:06 PM
Peter Lacey <lacey@mb.sympatico.ca> wrote 

> Seems to me you're adhering to a principle at the expense of
> simplicity.  If you have two different types of your exit
> paragraph/perform, and both of them are exactly equivalent to a GOTO -
> why not use a GOTO?  Then there'd be no question as to which type of
> exit you're doing, nor would there be any doubt as to where control
> resumes.

This seems to be the trigger for where I do my usual discourse on "it
isn't the GOTO that is harmful, it is the label that it requires that
is the probelem", but I won't.
0
riplin (4127)
10/28/2004 11:46:19 PM
"Howard Brazee" <howard@brazee.net> wrote in message
news:clqtvl$mat$1@peabody.colorado.edu...
>
> On 27-Oct-2004, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
>
> > I am also amazed at the furore over "plain vanilla". Personally, I
wouldn't
> > consider this to be redundant or contradictory. Neither would I consider
> > "plain strawberry" or "plain anything else" to be so. For me the "plain"
is
> > simply equivalent to "pure" and indicates that whatever follows is
> > unadulterated.
>
> Plain vanilla ice cream doesn't taste like strawberry vanilla ice cream
nor
> French vanilla ice cream.
>
Exactly.

Strawberry vanilla is a mix of strawberry and vanilla. Plain vanilla is not.

Pete.
(This from someone who rarely eats ice cream anyway... <G>)



0
dashwood1 (2140)
10/28/2004 11:46:38 PM
<docdwarf@panix.com> wrote in message news:clqduq$f9i$1@panix5.panix.com...
> In article <2ub34uF28dv3oU1@uni-berlin.de>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
>
>
> As for gaping rustics, slack-jawed yokels and other such savory
> bystanders... the water's fine, come on in!
>
I am stunned by the pointlessness of this discussion. Hence I appear as a
slack jawed yokel.

Everything I wanted to say, I said in my previous post. No minds will be
changed and nothing is achieved. The only reason I entered this thread at
all is because Daniel asked a specific question that related to NZ English.

I found it very hard to ignore.

>If you deem the combat grows
> too fierce for direct participation

I stand on my record. The ferocity of combat here has never been a deterrent
to me. It's just that I value my time more now, and hence am loth to
squander it in CLC (unless something can be achieved).


> there's nothing to stop you from
> indulging in that time-honored technique of standing on the sidelines and
> indiscriminately tossing in chairs and ashtrays.
>
A delightful image... I'll give it the consideration it deserves.<G>

Pete.




0
dashwood1 (2140)
10/29/2004 12:41:15 AM
Richard wrote:
> 
> Peter Lacey <lacey@mb.sympatico.ca> wrote
> 
> > Seems to me you're adhering to a principle at the expense of
> > simplicity.  If you have two different types of your exit
> > paragraph/perform, and both of them are exactly equivalent to a GOTO -
> > why not use a GOTO?  Then there'd be no question as to which type of
> > exit you're doing, nor would there be any doubt as to where control
> > resumes.
> 
> This seems to be the trigger for where I do my usual discourse on "it
> isn't the GOTO that is harmful, it is the label that it requires that
> is the probelem", but I won't.

Good, I suppose.  Why bother composing this?  Ranting about the label
wouldn't address the subject.

PL
0
lacey (134)
10/29/2004 2:47:02 AM
"Rick Smith" <ricksmith@mfi.net> wrote 

> > > PERFORM WITH TEST BEFORE is a loop with
> > > a test *before* entering and a test to terminate.
> > > PERFORM WITH TEST AFTER is a loop with
> > > no test to enter and a test *after* to terminate.
> >
> > No. That is not true, it is only a loop if there is an UNTIL clause.
> > The WITH TEST cannot be specified without an UNTIL.
 
> My apologies. The "UNTIL condition" was implied since
> the discussion was about a replacement equivalent to
> PERFORM UNTIL EXIT or PERFORM UNTIL 1 = 0
> or PERFORM UNTIL ZERO IS NOT ZERO.

Well exactly. The question I raised was what part implies looping. 
You claimed that PERFORM WITH was what made it loop while it should be
seen that it is the UNTIL that does so.  That is PERFORM .... UNTIL is
looping (as is TIMES) regardless of whether it has WITH or VARYING.
 
> Are you saying that PERFORM WITHOUT LIMIT and
> PERFORM WITH NO LIMITS, found in some compilers,
> are not loops because they do not have UNTIL?

It seems to me that PERFORM WITH{OUT| NO} LIMIT implies continuously
while PERFORM WITH NO TEST implies [un]conditionally, but not more
than once.

This is because the existing WITH TEST only determines where the test
is done, yours adds the option {BEFORE|AFTER|NEITHER} but, to me, it
still needs the UNTIL or similar to invoke the concept of TIME[S].

After all, PERFORM 1 TIMES is a valid qualification that denies there
is a loop.

> That PERFORM VARYING is a loop is defined by
> PERFORM statement, GR9.

Do you have a form of VARYING that doesn't require an UNTIL ?
 
> That  PERFORM ... UNTIL is a loop, is defined by
> PERFORM statement, GR8; not by implication from the
> use of UNTIL. That WITH NO TEST is a loop would
> also be defined by a general rule. It is this that preserves
> the idea that a PERFORM with a qualifier is a loop.

Oh yes, I do understand that. There could be a rule that specifies the
action to be taken, that is not the point.  It shouldn't be necessary
to read the rule to understand what the program does.

If I saw PERFORM UNTIL EXIT which is MF extension then I would expect
this to execute until the code found its way to an EXIT of some sort
_without_ needing to read the rule.  However, seeing a PERFORM WITH NO
TEST, I would, based on what features are available in other languages
and what the WITH TEST {} actually does, have to look up the rule as
to what would actually happen.

I looks to _me_ to be an unconditional form of a conditional, not
continuous.

From another point of view: WITH TEST BEFORE is just noise, because
that is the default.  This may be (naievely) extended to conclude that
WITH NO TEST is just noise because it too may be the default for
unqualified PERFORM.


Obviously you do see it as meaning continuous, and that is the
problem, some may see it meaning one thing and some may see it meaning
another.  They have to look up the rule.
0
riplin (4127)
10/29/2004 3:46:20 AM
In article <1099010479.PwJDVbjoegx6vX5Qk4invA@teranews>,
Peter E.C Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:clqduq$f9i$1@panix5.panix.com...
>> In article <2ub34uF28dv3oU1@uni-berlin.de>,
>> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>>
>> [snip]
>>
>>
>> As for gaping rustics, slack-jawed yokels and other such savory
>> bystanders... the water's fine, come on in!
>>
>I am stunned by the pointlessness of this discussion. Hence I appear as a
>slack jawed yokel.

Gracious of you to inform folks of such, certainly.

>
>Everything I wanted to say, I said in my previous post. No minds will be
>changed and nothing is achieved. The only reason I entered this thread at
>all is because Daniel asked a specific question that related to NZ English.
>
>I found it very hard to ignore.
>
>>If you deem the combat grows
>> too fierce for direct participation
>
>I stand on my record.

Be careful about that... the rest of the world's going towards Compact 
Discs and such, it might be valuable some day and you mightn't want it 
scuffed.

>The ferocity of combat here has never been a deterrent
>to me. It's just that I value my time more now, and hence am loth to
>squander it in CLC (unless something can be achieved).
>
>
>> there's nothing to stop you from
>> indulging in that time-honored technique of standing on the sidelines and
>> indiscriminately tossing in chairs and ashtrays.
>>
>A delightful image... I'll give it the consideration it deserves.<G>

And most gracious of you to take the precious time to inform of such, as 
well.

DD

0
docdwarf (6044)
10/29/2004 9:10:16 AM
On 28-Oct-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> > Too bad that ability isn't complete.
>
> Which ability?  The ability to do an EXIT PERFORM CYCLE in an out-of-line
> PERFORM?  Yeah, I think I'd argue for that, unless (again) somebody can
> convince me it's a bad idea!

Yes.
0
howard (6283)
10/29/2004 1:19:29 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410281946.4921ac39@posting.google.com...
> "Rick Smith" <ricksmith@mfi.net> wrote
>
> > > > PERFORM WITH TEST BEFORE is a loop with
> > > > a test *before* entering and a test to terminate.
> > > > PERFORM WITH TEST AFTER is a loop with
> > > > no test to enter and a test *after* to terminate.
> > >
> > > No. That is not true, it is only a loop if there is an UNTIL clause.
> > > The WITH TEST cannot be specified without an UNTIL.
>
> > My apologies. The "UNTIL condition" was implied since
> > the discussion was about a replacement equivalent to
> > PERFORM UNTIL EXIT or PERFORM UNTIL 1 = 0
> > or PERFORM UNTIL ZERO IS NOT ZERO.
>
> Well exactly. The question I raised was what part implies looping.
> You claimed that PERFORM WITH was what made it loop while it should be
> seen that it is the UNTIL that does so.  That is PERFORM .... UNTIL is
> looping (as is TIMES) regardless of whether it has WITH or VARYING.

My claim was that the presence of a qualifying phrase
implies looping because COBOL would not be defined
with a PERFORM statement where the presence of a
qualifying phrase means exactly the same as its absence.

There are three distinct phrases: TIMES, UNTIL, and
VARYING. You seem to be treating VARYING as an
variation of UNTIL; it is not.

A valid complaint is that I am treating WITH NO TEST
as a variation of the UNTIL phrase; but without the
UNTIL keyword that identifies the phrase.

> > Are you saying that PERFORM WITHOUT LIMIT and
> > PERFORM WITH NO LIMITS, found in some compilers,
> > are not loops because they do not have UNTIL?
>
> It seems to me that PERFORM WITH{OUT| NO} LIMIT implies continuously
> while PERFORM WITH NO TEST implies [un]conditionally, but not more
> than once.
>
> This is because the existing WITH TEST only determines where the test
> is done, yours adds the option {BEFORE|AFTER|NEITHER} but, to me, it
> still needs the UNTIL or similar to invoke the concept of TIME[S].
>
> After all, PERFORM 1 TIMES is a valid qualification that denies there
> is a loop.

The qualification is {identifier-1 | integer} TIMES, which
is a loop by definition. This does not change because the
value is 1 or 10 or 0 or -1000000.

Similarly, just because I often feel like an outsider to the
human race does not mean I am not human, unfortunately.

> > That PERFORM VARYING is a loop is defined by
> > PERFORM statement, GR9.
>
> Do you have a form of VARYING that doesn't require an UNTIL ?

It was never a consideration, because a VARYING
phrase is not an UNTIL phrase.

> > That  PERFORM ... UNTIL is a loop, is defined by
> > PERFORM statement, GR8; not by implication from the
> > use of UNTIL. That WITH NO TEST is a loop would
> > also be defined by a general rule. It is this that preserves
> > the idea that a PERFORM with a qualifier is a loop.
>
> Oh yes, I do understand that. There could be a rule that specifies the
> action to be taken, that is not the point.  It shouldn't be necessary
> to read the rule to understand what the program does.
>
> If I saw PERFORM UNTIL EXIT which is MF extension then I would expect
> this to execute until the code found its way to an EXIT of some sort
> _without_ needing to read the rule.  However, seeing a PERFORM WITH NO
> TEST, I would, based on what features are available in other languages
> and what the WITH TEST {} actually does, have to look up the rule as
> to what would actually happen.
>
> I looks to _me_ to be an unconditional form of a conditional, not
> continuous.

Ah, there's the problem, you don't appreciate its simple
elegance, beauty, and truth. Just as PERFORM WITH TEST
BEFORE ... and PERFORM WITH TEST AFTER ...
are complements, so are PERFORM WITH TEST ... and
PERFORM WITH NO TEST complements. It is in this
completeness that its perfection lies.

> From another point of view: WITH TEST BEFORE is just noise, because
> that is the default.  This may be (naievely) extended to conclude that
> WITH NO TEST is just noise because it too may be the default for
> unqualified PERFORM.
>
>
> Obviously you do see it as meaning continuous, and that is the
> problem, some may see it meaning one thing and some may see it meaning
> another.  They have to look up the rule.

Having to look up a rule is no impediment. No doubt many
who used COBOL 74 long after COBOL 85 became
available had to look up the rules for WITH TEST AFTER,
NOT AT END, in-line perform, scope terminators, intrinsic
functions, etc., when encountering these for the first time.

When na�ve ("having a lack of information") programmers
begin seeing code for COBOL 2002, there will be a lot of
looking up to do, as well.

While I do not see WITH NO TEST as a problem, I am
not married to it. It was just something I considered as
an one option. It is far more important that something,
reflecting indefinite execution, be added to COBOL.



0
ricksmith (875)
10/29/2004 2:56:01 PM
Peter Lacey <lacey@mb.sympatico.ca> wrote 

> > This seems to be the trigger for where I do my usual discourse on "it
> > isn't the GOTO that is harmful, it is the label that it requires that
> > is the probelem", but I won't.
> 
> Good, I suppose.  Why bother composing this? 

Well that's what I thought.  Those that would agree with it already
understand the issue, those that still think that GOTO is OK to use
wouldn't agree with the discussion.

> Ranting about the label wouldn't address the subject.

Labels are very much part of the subject of out-of-line PERFORMs and
their scope. When labels can possibly exist within the scope (which
they cannot when PERFORM paragraph is all that is used), there are
potential problems that don't otherwise exist.
0
riplin (4127)
10/29/2004 6:48:56 PM
"Rick Smith" <ricksmith@mfi.net> wrote

> My claim was that the presence of a qualifying phrase
> implies looping because COBOL would not be defined
> with a PERFORM statement where the presence of a
> qualifying phrase means exactly the same as its absence.

Which is odd because the presence of WITH TEST BEFORE is identical to
its absence.

Other statements also have clauses which usually give identical result
whether they are present or absent, eg BY REFERENCE, FROM CONSOLE,
UPON CONSOLE, NEXT RECORD (sequential).

My view on this is that 'PERFORM' does not have a test.  Specifying
there is 'no test' is logically the same as not having a test, just
being specific about it.

> There are three distinct phrases: TIMES, UNTIL, and
> VARYING. You seem to be treating VARYING as an
> variation of UNTIL; it is not.

Do you have a form of VARYING that does not require the UNTIL ?

> A valid complaint is that I am treating WITH NO TEST
> as a variation of the UNTIL phrase; but without the
> UNTIL keyword that identifies the phrase.

Yes, I did make that observation.

> Similarly, just because I often feel like an outsider to the
> human race does not mean I am not human, unfortunately.

Is it unfortunate that you feel like an outsider, or that you are not
'not human', or both ?

You don't need to answer that.
 
> > Do you have a form of VARYING that doesn't require an UNTIL ?
> 
> It was never a consideration, because a VARYING
> phrase is not an UNTIL phrase.

But the point is that at 2am the programmer is not going to reading up
on these fine distinctions in the rules.  They will see:

      PERFORM 
          VARYING I BY 1 
          UNTIL I > 10
          ....
      END-PERFORM
and
      MOVE 1 TO I
      PERFORM
          UNTIL I > 10
          ....
          ADD 1 TO I
      END-PERFORM

as being exactly the same thing and not as two quite different things.
The only reason that VARYING is a separate syntax diagram and not just
an optional clause is because of the AFTER which can only exist when
there is a VARYING.  It would be too complicated to show VARYING as an
option and then show AFTER being dependent on that.  Without AFTER the
PERFORM UNTIL could be:

     PERFORM [procedure ..]
         [WITH TEST ..]
         [VARYING ... FROM ... BY ..]
         UNTIL condition-1
         ....

The point being that the condition-1 is independent of the VARYING
clause, one can have VARYING I FROM 1 BY 1 and then UNTIL EoF-set. 
The UNTIL is not subsiduary to the VARYING.

> Ah, there's the problem, you don't appreciate its simple
> elegance, beauty, and truth. 

That is correct.

> Just as PERFORM WITH TEST
> BEFORE ... and PERFORM WITH TEST AFTER ...
> are complements, so are PERFORM WITH TEST ... and
> PERFORM WITH NO TEST complements. It is in this
> completeness that its perfection lies.

And, as I said, 'PERFORM' alone has no test.  If you have:

      PERFORM X 
          WITH TEST .. UNTIL End-of-File

then the WITH TEST is superfluous if it is BEFORE.

To compliment this it _may_ be thought upon reading the code that:

      PERFORM X
          WITH NO TEST   *> there is no test here

is similarly superfluous and is therefore a specific version of:

      PERFORM X          *> there is no test here

> Having to look up a rule is no impediment. No doubt many
> who used COBOL 74 long after COBOL 85 became
> available had to look up the rules for WITH TEST AFTER,
> NOT AT END, in-line perform, scope terminators, intrinsic
> functions, etc., when encountering these for the first time.

There you go.  They always seemed to _me_ to be self explanatory.  I
may have looked them up to see how to _write_ them in the absence of
an example, for example to see if the WITH TEST goes before or after
the UNTIL, but I can't say that I would have needed to look up what
they were doing when reading some code they were in.

But the wording of those was carefully chosen, after discussions such
as this one, to specifically eliminate such confusion.

> When na�ve ("having a lack of information") programmers
> begin seeing code for COBOL 2002, there will be a lot of
> looking up to do, as well.

Mainly, I would suggest, when they need to write such code.  If they
have to look it up when reading working code then the phrasing has
failed in its task.
 
> While I do not see WITH NO TEST as a problem, I am
> not married to it. It was just something I considered as
> an one option. It is far more important that something,
> reflecting indefinite execution, be added to COBOL.

I see that there are several ways that have been added to various
implementations, such as UNTIL EXIT, WITH{OUT | NO} LIMIT, and
possibly others. Also it can be done using ugly 'UNTIL ZERO NOT EQUAL
ZERO' or similar, or with INDEFINITE TIMES (where indefinite is 10^18
- 1 or more).

All of these do the job, but I still much prefer having an actual
termination specified on the PERFORM with an UNTIL of some sort, and
dislike EXIT PERFORM. It is easy enough to have a structure that does
not require it.

Also if a PERFORM starts as an in-line but then gets too unwieldy I
will make it out-of-line by simply moving it, or parts of it, to new
paragraphs (_NOT_ sections).  In these cases the EXIT PERFORM CYCLE
would have to change to EXIT PARAGRAPH and there would be no answer to
EXIT PERFORM.  Having the termination in the UNTIL and a structure
that caters for this makes it trivial to change between in-line and
ou-of-line and is much less error-prone.
0
riplin (4127)
10/29/2004 9:07:38 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410291307.6ec067a7@posting.google.com...

>  ... Also it can be done using ugly 'UNTIL ZERO NOT EQUAL
> ZERO' or similar,

Careful, now!  "ZERO NOT EQUAL ZERO" is an *entirely* different kettle of
fish from "ZERO NOT ZERO".  The former is a *comparison*, the latter is a
*sign test*!

+or with INDEFINITE TIMES (where indefinite is 10^18
> - 1 or more).

2002 requires at least 31 digits of precision and, if standard arithmetic is
in effect, values with a magnitude of (10^1000 - 10^968).  I'm not
particularly comfortable with defining "a whole lotta times" as synonymous
with "an infinite number of times".

> All of these do the job, but I still much prefer having an actual
> termination specified on the PERFORM with an UNTIL of some sort, and
> dislike EXIT PERFORM. It is easy enough to have a structure that does
> not require it.

Hmm.  I'd have thought "EXIT PERFORM" -- go back to wherever it was that you
came from, if you came from somewhere in the first place -- would be
considered worlds better than "GO TO <somewhere>" or "EXIT the particular
paragraph or section you are in" in today's culture.

> Also if a PERFORM starts as an in-line but then gets too unwieldy I
> will make it out-of-line by simply moving it, or parts of it, to new
> paragraphs (_NOT_ sections).  In these cases the EXIT PERFORM CYCLE
> would have to change to EXIT PARAGRAPH and there would be no answer to
> EXIT PERFORM.

Which is why I have proposed allowing EXIT PERFORM CYCLE as well as EXIT
PERFORM outside the contexts of inline PERFORMs.

> Having the termination in the UNTIL and a structure
> that caters for this makes it trivial to change between in-line and
> ou-of-line and is much less error-prone.

I don't doubt that, but I can also see the argument that putting all the
termination logic at the loop level instead of internal to it makes some
sense.  I know of one language that had exactly one form of iteration
construct -- DO FOREVER.  If you discovered you were "done", you simply did
an "UNDO".  That COBOL doesn't have a similar construct strikes me as
restrictive!

And if EXIT PERFORM (or for that matter EXIT PERFORM CYCLE) is allowed
outside of the context of inline PERFORMs, I'm not sure what change you'd
have to make if the inline PERFORM got too unwieldy.

    -Chuck Stevens.



0
10/29/2004 9:39:28 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410291307.6ec067a7@posting.google.com...
> "Rick Smith" <ricksmith@mfi.net> wrote
>
> > My claim was that the presence of a qualifying phrase
> > implies looping because COBOL would not be defined
> > with a PERFORM statement where the presence of a
> > qualifying phrase means exactly the same as its absence.
>
> Which is odd because the presence of WITH TEST BEFORE is identical to
> its absence.

Apparently, my vision is quite selective and I did not
see that phrases were buried within phrases. By
"qualifying phrase," I intended the TIMES, UNTIL,
and VARYING phrases.

> Other statements also have clauses which usually give identical result
> whether they are present or absent, eg BY REFERENCE, FROM CONSOLE,
> UPON CONSOLE, NEXT RECORD (sequential).

A quick check suggests that clauses appear only outside
the procedure division--phrases only within it.

[snip]
> > There are three distinct phrases: TIMES, UNTIL, and
> > VARYING. You seem to be treating VARYING as an
> > variation of UNTIL; it is not.
>
> Do you have a form of VARYING that does not require the UNTIL ?

I have no form of VARYING that is not in the standard
and the standard specifies that VARYING and UNTIL
are separate phrases.

[snip]
> > Similarly, just because I often feel like an outsider to the
> > human race does not mean I am not human, unfortunately.
>
> Is it unfortunate that you feel like an outsider, or that you are not
> 'not human', or both ?
>
> You don't need to answer that.

[snip]
> All of these do the job, but I still much prefer having an actual
> termination specified on the PERFORM with an UNTIL of some sort, and
> dislike EXIT PERFORM. It is easy enough to have a structure that does
> not require it.

Steve McConnell, in Code Complete, 1993, writes:
"The loop-with-exit loop is a one-entry, one-exit, structured
control construct, and is the preferred kind of loop control in
Ada programming (Software Productivity Consortium 1989).
It has been shown to be easier to understand than other kinds
of loops. A study of student programmers compared this kind
of loop with those that exited at either the top or bottom
(Soloway, Bonair, and Ehrlich 1983). Students scored 25
percent higher on a test of comprehension when loop-with-exit
loops were used, and the authors of the study concluded that
the loop-with-exit structure more closely models the way
people think about iterative control than other loop structures
do."

I like loop-with-exit loops; but if I think "the way people think,"
it must mean I'm human, unfortunately.



0
ricksmith (875)
10/29/2004 11:24:09 PM
Howard Brazee wrote:
> On 27-Oct-2004, LX-i <lxi0007@netscape.net> wrote:
> 
> 
>>>>So, what do you consider your defining source of the English language?
>>>
>>>
>>>Are you disputing that it is a contradiction ?
>>
>>Not necessarily - but if it's written plain/vanilla, it's not.  :)  What
>>I was more asking for was the source from which you derived your
>>seemingly strong feelings about "wrong terms" that are defined in a
>>dictionary.
> 
> 
> Which do you want, French Vanilla ice cream, or plain vanilla ice cream?

Although I don't care for the country as a whole, I think I'd vote for 
the former.  (Maybe call it "freedom vanilla ice cream"... heh heh heh)

> People who use "plain vanilla", generally think vanilla is plain.   That is they
> think it is ordinary and nothing special.    Tastes vary, but apparently this is
> a common belief.   Saying that they are wrong is like saying someone is wrong
> for not liking pickles.

If that last sentence is true, then my pregnant wife is the most right 
person I know!  ;)

I know at Dairy Queen, you can only get one flavor of ice cream - 
vanilla.  Now, you can have it dipped in or whipped with pretty much 
whatever else you want - but the base ice cream is vanilla.  (I had a 
tough time convincing my kids that a chocolate chip or M&M Blizzard was 
almost as good as chocolate ice cream - until they tried 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)
10/29/2004 11:28:20 PM
Rick Smith wrote:
> Compare this with the "plain vanilla" PERFORM which
                          ^^^^^^^^^^^^^

heh heh heh...  :)



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/29/2004 11:39:45 PM
I believe you have several good points. If there were a show of hands,
mine would be up on yours.

Warren Simmons

Richard wrote:
> "Rick Smith" <ricksmith@mfi.net> wrote
> 
> 
>>My claim was that the presence of a qualifying phrase
>>implies looping because COBOL would not be defined
>>with a PERFORM statement where the presence of a
>>qualifying phrase means exactly the same as its absence.
> 
> 
> Which is odd because the presence of WITH TEST BEFORE is identical to
> its absence.
> 
> Other statements also have clauses which usually give identical result
> whether they are present or absent, eg BY REFERENCE, FROM CONSOLE,
> UPON CONSOLE, NEXT RECORD (sequential).
> 
> My view on this is that 'PERFORM' does not have a test.  Specifying
> there is 'no test' is logically the same as not having a test, just
> being specific about it.
> 
> 
>>There are three distinct phrases: TIMES, UNTIL, and
>>VARYING. You seem to be treating VARYING as an
>>variation of UNTIL; it is not.
> 
> 
> Do you have a form of VARYING that does not require the UNTIL ?
> 
> 
>>A valid complaint is that I am treating WITH NO TEST
>>as a variation of the UNTIL phrase; but without the
>>UNTIL keyword that identifies the phrase.
> 
> 
> Yes, I did make that observation.
> 
> 
>>Similarly, just because I often feel like an outsider to the
>>human race does not mean I am not human, unfortunately.
> 
> 
> Is it unfortunate that you feel like an outsider, or that you are not
> 'not human', or both ?
> 
> You don't need to answer that.
>  
> 
>>>Do you have a form of VARYING that doesn't require an UNTIL ?
>>
>>It was never a consideration, because a VARYING
>>phrase is not an UNTIL phrase.
> 
> 
> But the point is that at 2am the programmer is not going to reading up
> on these fine distinctions in the rules.  They will see:
> 
>       PERFORM 
>           VARYING I BY 1 
>           UNTIL I > 10
>           ....
>       END-PERFORM
> and
>       MOVE 1 TO I
>       PERFORM
>           UNTIL I > 10
>           ....
>           ADD 1 TO I
>       END-PERFORM
> 
> as being exactly the same thing and not as two quite different things.
> The only reason that VARYING is a separate syntax diagram and not just
> an optional clause is because of the AFTER which can only exist when
> there is a VARYING.  It would be too complicated to show VARYING as an
> option and then show AFTER being dependent on that.  Without AFTER the
> PERFORM UNTIL could be:
> 
>      PERFORM [procedure ..]
>          [WITH TEST ..]
>          [VARYING ... FROM ... BY ..]
>          UNTIL condition-1
>          ....
> 
> The point being that the condition-1 is independent of the VARYING
> clause, one can have VARYING I FROM 1 BY 1 and then UNTIL EoF-set. 
> The UNTIL is not subsiduary to the VARYING.
> 
> 
>>Ah, there's the problem, you don't appreciate its simple
>>elegance, beauty, and truth. 
> 
> 
> That is correct.
> 
> 
>>Just as PERFORM WITH TEST
>>BEFORE ... and PERFORM WITH TEST AFTER ...
>>are complements, so are PERFORM WITH TEST ... and
>>PERFORM WITH NO TEST complements. It is in this
>>completeness that its perfection lies.
> 
> 
> And, as I said, 'PERFORM' alone has no test.  If you have:
> 
>       PERFORM X 
>           WITH TEST .. UNTIL End-of-File
> 
> then the WITH TEST is superfluous if it is BEFORE.
> 
> To compliment this it _may_ be thought upon reading the code that:
> 
>       PERFORM X
>           WITH NO TEST   *> there is no test here
> 
> is similarly superfluous and is therefore a specific version of:
> 
>       PERFORM X          *> there is no test here
> 
> 
>>Having to look up a rule is no impediment. No doubt many
>>who used COBOL 74 long after COBOL 85 became
>>available had to look up the rules for WITH TEST AFTER,
>>NOT AT END, in-line perform, scope terminators, intrinsic
>>functions, etc., when encountering these for the first time.
> 
> 
> There you go.  They always seemed to _me_ to be self explanatory.  I
> may have looked them up to see how to _write_ them in the absence of
> an example, for example to see if the WITH TEST goes before or after
> the UNTIL, but I can't say that I would have needed to look up what
> they were doing when reading some code they were in.
> 
> But the wording of those was carefully chosen, after discussions such
> as this one, to specifically eliminate such confusion.
> 
> 
>>When na�ve ("having a lack of information") programmers
>>begin seeing code for COBOL 2002, there will be a lot of
>>looking up to do, as well.
> 
> 
> Mainly, I would suggest, when they need to write such code.  If they
> have to look it up when reading working code then the phrasing has
> failed in its task.
>  
> 
>>While I do not see WITH NO TEST as a problem, I am
>>not married to it. It was just something I considered as
>>an one option. It is far more important that something,
>>reflecting indefinite execution, be added to COBOL.
> 
> 
> I see that there are several ways that have been added to various
> implementations, such as UNTIL EXIT, WITH{OUT | NO} LIMIT, and
> possibly others. Also it can be done using ugly 'UNTIL ZERO NOT EQUAL
> ZERO' or similar, or with INDEFINITE TIMES (where indefinite is 10^18
> - 1 or more).
> 
> All of these do the job, but I still much prefer having an actual
> termination specified on the PERFORM with an UNTIL of some sort, and
> dislike EXIT PERFORM. It is easy enough to have a structure that does
> not require it.
> 
> Also if a PERFORM starts as an in-line but then gets too unwieldy I
> will make it out-of-line by simply moving it, or parts of it, to new
> paragraphs (_NOT_ sections).  In these cases the EXIT PERFORM CYCLE
> would have to change to EXIT PARAGRAPH and there would be no answer to
> EXIT PERFORM.  Having the termination in the UNTIL and a structure
> that caters for this makes it trivial to change between in-line and
> ou-of-line and is much less error-prone.
0
wsimmons5 (172)
10/30/2004 12:53:05 AM
Regarding your last paragraph, would not the construction of a full
proposal cover such problems and  highlight which of the methods would
satisfy the most users?

Warren Simmons

Chuck Stevens wrote:

> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:217e491a.0410291307.6ec067a7@posting.google.com...
> 
> 
>> ... Also it can be done using ugly 'UNTIL ZERO NOT EQUAL
>>ZERO' or similar,
> 
> 
> Careful, now!  "ZERO NOT EQUAL ZERO" is an *entirely* different kettle of
> fish from "ZERO NOT ZERO".  The former is a *comparison*, the latter is a
> *sign test*!
> 
> +or with INDEFINITE TIMES (where indefinite is 10^18
> 
>>- 1 or more).
> 
> 
> 2002 requires at least 31 digits of precision and, if standard arithmetic is
> in effect, values with a magnitude of (10^1000 - 10^968).  I'm not
> particularly comfortable with defining "a whole lotta times" as synonymous
> with "an infinite number of times".
> 
> 
>>All of these do the job, but I still much prefer having an actual
>>termination specified on the PERFORM with an UNTIL of some sort, and
>>dislike EXIT PERFORM. It is easy enough to have a structure that does
>>not require it.
> 
> 
> Hmm.  I'd have thought "EXIT PERFORM" -- go back to wherever it was that you
> came from, if you came from somewhere in the first place -- would be
> considered worlds better than "GO TO <somewhere>" or "EXIT the particular
> paragraph or section you are in" in today's culture.
> 
> 
>>Also if a PERFORM starts as an in-line but then gets too unwieldy I
>>will make it out-of-line by simply moving it, or parts of it, to new
>>paragraphs (_NOT_ sections).  In these cases the EXIT PERFORM CYCLE
>>would have to change to EXIT PARAGRAPH and there would be no answer to
>>EXIT PERFORM.
> 
> 
> Which is why I have proposed allowing EXIT PERFORM CYCLE as well as EXIT
> PERFORM outside the contexts of inline PERFORMs.
> 
> 
>>Having the termination in the UNTIL and a structure
>>that caters for this makes it trivial to change between in-line and
>>ou-of-line and is much less error-prone.
> 
> 
> I don't doubt that, but I can also see the argument that putting all the
> termination logic at the loop level instead of internal to it makes some
> sense.  I know of one language that had exactly one form of iteration
> construct -- DO FOREVER.  If you discovered you were "done", you simply did
> an "UNDO".  That COBOL doesn't have a similar construct strikes me as
> restrictive!
> 
> And if EXIT PERFORM (or for that matter EXIT PERFORM CYCLE) is allowed
> outside of the context of inline PERFORMs, I'm not sure what change you'd
> have to make if the inline PERFORM got too unwieldy.
> 
>     -Chuck Stevens.
> 
> 
> 
0
wsimmons5 (172)
10/30/2004 12:58:33 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote 

> Hmm.  I'd have thought "EXIT PERFORM" -- go back to wherever it was that you
> came from, if you came from somewhere in the first place -- would be
> considered worlds better than "GO TO <somewhere>" or "EXIT the particular
> paragraph or section you are in" in today's culture.

Oh it is far superior to those, but then I would not use those at all.
There is no place in my code for a GOTO, or more specifically, there
is no place for a label that could be a target for a GOTO.
 
> Which is why I have proposed allowing EXIT PERFORM CYCLE as well as EXIT
> PERFORM outside the contexts of inline PERFORMs.

Yes, I agree that would be useful, though I still would be unlikely to
use them, they seem unnecessary in the way that I write code.
 
> I know of one language that had exactly one form of iteration
> construct -- DO FOREVER.  If you discovered you were "done", you simply did
> an "UNDO".  That COBOL doesn't have a similar construct strikes me as
> restrictive!

Maybe. But I can't say that I have ever wanted to do it that way in
Cobol, though I do in other languages. It is a matter of using idioms
appropriate to the language.

As someone said: "A Real Programmer can write FORTRAN programmes is
_any_ language."

(here with deliberate punctuation and spellings!)

> And if EXIT PERFORM (or for that matter EXIT PERFORM CYCLE) is allowed
> outside of the context of inline PERFORMs, I'm not sure what change you'd
> have to make if the inline PERFORM got too unwieldy.

Hmm.  It may not work.  For example if I had:

      PERFORM UNTIL EXIT
          READ file NEXT RECORD
              AT END
                  EXIT PERFORM
              NOT AT END
                  IF filekey > key-limit
                      EXIT PERFORM
                  ELSE
                      ...
                  END-IF
           END-READ
      END-PERFORM

and I decided to unwield it to:

       PERFORM UNTIL EXIT
          READ file NEXT RECORD
              AT END
                  EXIT PERFORM
              NOT AT END
                  PERFORM Process-Record
           END-READ
      END-PERFORM

  Process-Record

      IF filekey > key-limit
          EXIT PERFORM
      ELSE
          ...
      END-IF
      .

It's not quite the same is it.  Whereas if I did it with:

      PERFORM WITH TEST AFTER UNTIL filekey > key-limit
          READ ...
              AT END
                  MOVE HIGH-VALUES TO filekey
              NOT AT END
              IF ...
          ..

Then it just works regardless of which bits I move out-of-line.
0
riplin (4127)
10/30/2004 3:52:18 AM
Robert Wagner <spamblocker-robert@wagner.net> wrote:

>On Thu, 28 Oct 2004 08:51:50 -0700, "Chuck Stevens"
><charles.stevens@unisys.com> wrote:

>>I agree that an out-of-line indefinite PERFORM pretty much requires either
>>the despised GO TO or the prohibited EXIT PERFORM, but I'm not really
>>opposed to relaxing the restriction on the latter, unless someone convinces
>>me that there's a good reason why it's there.  
>
>I can't think of a good reason.

One would have thought that the truly astonishing degree of mental
masturbation exhibited by those wishing to avoid either of these
simple constructs would be reason enough.

-- 
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)
10/31/2004 12:05:46 PM
Pete Dashwood wrote:
> 
> Richard's position is a very British one (although he is a New Zealander by
> adoption, he wasn't born here...). It is a pity he is being forced to defend
> his position so vehemently, but that is often what happens when you say
> people are "wrong"...<G> Might I suggest here that all parties cut each
> other a little slack and just be thankful that we are able to have these
> discussions because we share a knowledge of "English" (whatever you perceive
> that to be...)?

Heh - I don't care, one way or the other.  My continuing questions to 
Mr. Plinston were bourne out of his continuing assertion that "period = 
.." was wrong.  I was just curious as to what source he considered the 
definitive reference on the English language.

(Yes, I'm grateful that the prevailing language here is English, no 
matter how anguished that English may be at times...)

>>Do folks in NZ say "full stop" instead of "period" when they're
>>emphasizing the finality of something?  Such as...
>>
>>"That is enough!  Period!  End of Story!"
>>"That is enough!  Full stop!  End of Story!"
>>
> 
>  I have actually heard BOTH of these exact statements made by people here.
> (I distinctly recall my Mother using the second one verbatim, on a certain
> occasion when I was a child...) We are fairly laid back as a general rule
> and would be unlikely to get into a heated and lengthy argument over the use
> of "Americanisms" (real or perceived). People use whatever they feel
> comfortable with as long as the meaning is clear.

heh - and that's the context of what I was thinking, too (the 
parent/child exchange).  :)

> You will have seen from my posts that I tend to prefer the English spellings
> rather than the American ones but that is just the result of my background
> and upbringing. I certainly don't consider either to be "wrong", and there
> is no argument (at least, not from me... <G>) against the case that the
> American forms are more logical and simpler.

Although I've never been there, I prefer many English spellings as well 
(colour, travelling, etc.).  I may not use them all the time, but they 
certainly don't throw me off.

> In recent years,  largely as a result of TV and film influences, we are
> seeing more young people adopting American English ("butt" in particular has
> almost replaced "bum" in common usage) and there are varying degrees of
> resistance to this. I have noticed that it often depends on the individuals
> politics... people who are fiercely anti-American (a considerable number,
> sadly) tend to avoid using Americanisms, people who are fiercely
> pro-American (I'm afraid that is a much smaller number) will use
> Americanisms all the time, and the rest of us (by far the majority) simply
> don't care.

I don't quite understand why anti-American feelings run so strong 
abroad.  Every one of the arguments from these groups (that I've heard) 
have come directly from misinformation or just flat-out lies.  Of 
course, the exported media from this country (CNN et. al.) doesn't do a 
whole lot to bolster good feelings about this country.

<rabbit_trail>One reason Fox News Channel has become so popular here is 
that it's not just a bunch of liberals sitting around agreeing on how 
bad conservatives are - they have members of both sides.  To many, this 
amounts to Fox being a "conservative" news channel.  I tend to believe 
it's more of the message finally getting out.  Facts trump feelings, and 
that's why, when going head-to-head, conservatives trounce liberals in 
debates.

Take tax cuts - everyone likes asking "How are we going to *pay* for 
these tax cuts?"  The fact is, tax cuts often increase tax revenue, 
meaning that the question should be "How can we afford to *not* cut 
taxes?"  It's simple math...

10,000 * 25% tax rate = 2,500 for the government
11,000 * 24% tax rate = 2,640 for the government

If tax rates are cut by 1%, and the amount of business being done goes 
up by 10% (not an outlandish number - growth normally runs about 4%), 
the government has made more money by collecting a lower percentage of a 
higher number.

But no - here's where the liberals throw out their "feelings" argument. 
  "Most of the tax cut goes to the top 2%!"  In real dollars, yes, 
that's true.  I forget the exact figure, but I saw it yesterday - the 
top 5% are paying something like 80% of the total tax burden.  Of course 
a 1% rate cut across the board is going to net them more dollars than 
the average joe.  (Heck, some of these folks pay more in taxes in one 
day than others make in an entire year!)

I go into this in depth on the latest entry on my web site, linked in 
the sig block.</rabbit_trail>


> I am also amazed at the furore over "plain vanilla".
                           ^^^^^^
:)  That's a new one on me...



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/31/2004 6:45:12 PM
docdwarf@panix.com wrote:
> 
> 'We here at The Flotsam use the King's English, as laid out in 'English As 
> She Is Spoke' by Ivor Biggun; page 38 states 'A preposition is something 
> we don't end a sentence with.'

Was it Winston Churchill who said "Ending a sentence in a preposition is 
something up with which we will not put!"?


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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)
10/31/2004 6:59:10 PM
In article <qCahd.14436$I54.8122@fe40.usenetserver.com>,
LX-i  <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>> 
>> 'We here at The Flotsam use the King's English, as laid out in 'English As 
>> She Is Spoke' by Ivor Biggun; page 38 states 'A preposition is something 
>> we don't end a sentence with.'
>
>Was it Winston Churchill who said "Ending a sentence in a preposition is 
>something up with which we will not put!"?

I recall it as 'It is the height of errant pedantry, up with which I will 
not put.'

DD

0
docdwarf (6044)
10/31/2004 11:55:57 PM
On Thu, 28 Oct 2004 15:08:50 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>Robert Wagner wrote:

>> While we're on the subject, it seems asymmetrical that we can say SET
>> CONDITION-1 TO FALSE  but cannot say
>>
>> 01    PIC X VALUE FALSE.
>>        88  CONDITION-1 VALUES 'A' 'B' 'C' FALSE 'D'.
>
>I think you've misunderstood.  VALUE FALSE applies *only* to 88's, and the
>filler isn't an 88.

A SET statement puts a value into the filler. A VALUE clause likewise
puts a value into the filler. 

>I see no inconsistency.  *ALL* the values save 'A', 'B' and 'C' would result
>in CONDITION-1 being FALSE; there may be any number of FALSE values.  There
>may be only one such value to which the parent item is set *when* you SET
>the condition to FALSE.   "VALUE FALSE" is unnecessary as well as
>meaningless on the PIC X item.

All VALUEs are unnecessary. Fields could be initialized with
procedural code. But values are good documentation when used in
copybooks and with INTIIALIZE TO VALUE. Is there a good reason to
exclude fields with 88?

>> When the value of false changes to 'E', we must change 01 VALUE as
>> well as 88 VALUES. That's contrary to the spirit of 88s.
>
>'E' is but one of probably 253 values for the PIC X item that would cause
>CONDITION-1 to be FALSE.  VALUE FALSE has nothing to do with the value that
>RESULTS in FALSE, it only specifies which value is used when it is
>EXPLICITLY SET to FALSE.

Why can't VALUE use the same value as SET in the way other VALUEs use
the same value as MOVE?

>> Examples follow. Please explain how we can do this with '02 features.
>
>Easy.
>
>Method 1:   Use >>DEFINE I-AM-DEBUGGING at the beginning of the program and
>>>IF I-AM-DEBUGGING... >> END-IF pairs around the IFs and END-IFs.   Maybe
>not quite as elegant as your examples, but functional.
>
>Method 2:
>
>    D77  PIC 9 VALUE 1.
>    D88  ITS-TRUE VALUE 1.
>    D88  ITS-FALSE VALUE 0.
>
>    D     OR ITS-TRUE   ...
>    D    AND ITS-FALSE ...

If that's a good debugging solution then 'perform forever' is already
at hand:

PERFORM UNTIL ITS-FALSE

0
11/1/2004 8:35:21 AM
In article <4r7bo0pf5bqh57jfjfnfi7cshc5ojnr3dr@4ax.com>,
Robert Wagner  <spamblocker-robert@wagner.net> wrote:

[snip]

>All VALUEs are unnecessary. Fields could be initialized with
>procedural code. But values are good documentation when used in
>copybooks and with INTIIALIZE TO VALUE.

Someone with a bit of experience in a 'strict chargeback environment', Mr 
Wagner, might know that procedural initialisation is an 'eternal' source 
of unnecessary expense.

DD

0
docdwarf (6044)
11/1/2004 10:37:43 AM
docdwarf@panix.com wrote:
> In article <4r7bo0pf5bqh57jfjfnfi7cshc5ojnr3dr@4ax.com>,
> Robert Wagner  <spamblocker-robert@wagner.net> wrote:
> 
> [snip]
> 
> 
>>All VALUEs are unnecessary. Fields could be initialized with
>>procedural code. But values are good documentation when used in
>>copybooks and with INTIIALIZE TO VALUE.
> 
> 
> Someone with a bit of experience in a 'strict chargeback environment', Mr 
> Wagner, might know that procedural initialisation is an 'eternal' source 
> of unnecessary expense.
That used to be definitely true but in a shop that defaults to using any 
of the IBM mainframe compiler with the RENT option, the reverse may be 
true.  Take a look at the code generated for initializing 
WORKING-STORAGE.  This may be especially true of large constant areas 
that can't be optimized out due to partial use.  Also the speed of the 
processor probably make the issue non-existent for most purposes.
> 
> DD
> 
0
cfmtech (125)
11/1/2004 2:26:25 PM
In article <2umvc6F2c9pcmU1@uni-berlin.de>,
Clark F. Morris, Jr. <cfmtech@istar.ca> wrote:
>docdwarf@panix.com wrote:
>> In article <4r7bo0pf5bqh57jfjfnfi7cshc5ojnr3dr@4ax.com>,
>> Robert Wagner  <spamblocker-robert@wagner.net> wrote:
>> 
>> [snip]
>> 
>> 
>>>All VALUEs are unnecessary. Fields could be initialized with
>>>procedural code. But values are good documentation when used in
>>>copybooks and with INTIIALIZE TO VALUE.
>> 
>> 
>> Someone with a bit of experience in a 'strict chargeback environment', Mr 
>> Wagner, might know that procedural initialisation is an 'eternal' source 
>> of unnecessary expense.
>That used to be definitely true but in a shop that defaults to using any 
>of the IBM mainframe compiler with the RENT option, the reverse may be 
>true.  Take a look at the code generated for initializing 
>WORKING-STORAGE.

RENT or no... coding

05  PG-HDR1 PIC X(33) VALUE 'WEEKLY PAYROLL REPORT BY DIVISION'.

.... populates the field at compile-time while 

MOVE 'WEEKLY PAYROLL REPORT BY DIVISION'  TO  PG-HDR1

.... incurs run-time costs for each execution.  Blank/zero fields get 
RENTed out, true... but notice Mr Wagner's use of 'all'.

>This may be especially true of large constant areas 
>that can't be optimized out due to partial use.  Also the speed of the 
>processor probably make the issue non-existent for most purposes.

Speed was something I did not take into consideration for precisely this 
reason... things move mighty fast nowadays.  Executed instructions, 
however, have an associated cost in a strict chargeback environment and 
that is what I pointed out... and, to think of it, there'd be associated 
costs with both the compiler-generated initialisation code and then the 
procedural statements to set up one's headers and constants.

(Notice how I managed to avoid the aesthetics of the situation, too!)

DD

0
docdwarf (6044)
11/1/2004 3:16:45 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410291952.402e227e@posting.google.com...
> "Chuck Stevens" <charles.stevens@unisys.com> wrote
>
> > Hmm.  I'd have thought "EXIT PERFORM" -- go back to wherever it was that
you
> > came from, if you came from somewhere in the first place -- would be
> > considered worlds better than "GO TO <somewhere>" or "EXIT the
particular
> > paragraph or section you are in" in today's culture.
>
> Oh it is far superior to those, but then I would not use those at all.
> There is no place in my code for a GOTO, or more specifically, there
> is no place for a label that could be a target for a GOTO.
>
> > Which is why I have proposed allowing EXIT PERFORM CYCLE as well as EXIT
> > PERFORM outside the contexts of inline PERFORMs.
>
> Yes, I agree that would be useful, though I still would be unlikely to
> use them, they seem unnecessary in the way that I write code.
>
> > I know of one language that had exactly one form of iteration
> > construct -- DO FOREVER.  If you discovered you were "done", you simply
did
> > an "UNDO".  That COBOL doesn't have a similar construct strikes me as
> > restrictive!
>
> Maybe. But I can't say that I have ever wanted to do it that way in
> Cobol, though I do in other languages. It is a matter of using idioms
> appropriate to the language.
>
> As someone said: "A Real Programmer can write FORTRAN programmes is
> _any_ language."
>
> (here with deliberate punctuation and spellings!)
>
> > And if EXIT PERFORM (or for that matter EXIT PERFORM CYCLE) is allowed
> > outside of the context of inline PERFORMs, I'm not sure what change
you'd
> > have to make if the inline PERFORM got too unwieldy.
>
> Hmm.  It may not work.  For example if I had:
>
>       PERFORM UNTIL EXIT
>           READ file NEXT RECORD
>               AT END
>                   EXIT PERFORM
>               NOT AT END
>                   IF filekey > key-limit
>                       EXIT PERFORM
>                   ELSE
>                       ...
>                   END-IF
>            END-READ
>       END-PERFORM
>
> and I decided to unwield it to:
>
>        PERFORM UNTIL EXIT
>           READ file NEXT RECORD
>               AT END
>                   EXIT PERFORM
>               NOT AT END
>                   PERFORM Process-Record
>            END-READ
>       END-PERFORM
>
>   Process-Record
>
>       IF filekey > key-limit
>           EXIT PERFORM
>       ELSE
>           ...
>       END-IF
>       .
>
> It's not quite the same is it.  Whereas if I did it with:
>
>       PERFORM WITH TEST AFTER UNTIL filekey > key-limit
>           READ ...
>               AT END
>                   MOVE HIGH-VALUES TO filekey
>               NOT AT END
>               IF ...
>           ..
>
> Then it just works regardless of which bits I move out-of-line.

That's not the kind of "unwield" I was talking about:; I was referring to
the specific argument that it might prove desirable to move a sequence of
code that is currently *within* an in-line PERFORM to a context *outside*,
and PERFORM that code by specifying the explicit PERFORM range.  It is not
specified whether the resultant PERFORM range is still, or is now, beyond
what the particular user, or the particular user's manager, might regard as
suitable for a single paragraph, for whatever reasons.  In that generalized
context, EXIT PERFORM specifies the intent -- "get outta dodge" -- without
the programmer necessarily having to specify the means or the path.

    -Chuck Stevens


0
11/1/2004 6:12:05 PM
"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:4r7bo0pf5bqh57jfjfnfi7cshc5ojnr3dr@4ax.com...
> On Thu, 28 Oct 2004 15:08:50 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
> >Robert Wagner wrote:
>
> >> While we're on the subject, it seems asymmetrical that we can say SET
> >> CONDITION-1 TO FALSE  but cannot say
> >>
> >> 01    PIC X VALUE FALSE.
> >>        88  CONDITION-1 VALUES 'A' 'B' 'C' FALSE 'D'.
> >
> >I think you've misunderstood.  VALUE FALSE applies *only* to 88's, and
the
> >filler isn't an 88.
>
> A SET statement puts a value into the filler. A VALUE clause likewise
> puts a value into the filler.

Not exactly.  Last I looked, SET doesn't refer to the PIC X item, but to the
condition-name.   While one might envision some convoluted syntax like "01
PIC X VALUE FALSE FROM CONDITION-1", I'm not convinced it's worthwhile.

> >I see no inconsistency.  *ALL* the values save 'A', 'B' and 'C' would
result
> >in CONDITION-1 being FALSE; there may be any number of FALSE values.
There
> >may be only one such value to which the parent item is set *when* you SET
> >the condition to FALSE.   "VALUE FALSE" is unnecessary as well as
> >meaningless on the PIC X item.
>
> All VALUEs are unnecessary. Fields could be initialized with
> procedural code. But values are good documentation when used in
> copybooks and with INTIIALIZE TO VALUE. Is there a good reason to
> exclude fields with 88?

FALSE-ness and TRUE-ness are not characteristics of the data items to which
the 88's refer, they're associated with the 88's.  You can initialize the
unnamed PIC X item to any alphanumeric character you want, but that don't
make IT true or false regardless of the value.

> Why can't VALUE use the same value as SET in the way other VALUEs use
> the same value as MOVE?

Because the FALSE value isn't associated with the data item, it's associated
with the conditional.


> If that's a good debugging solution then 'perform forever' is already
> at hand:
>
> PERFORM UNTIL ITS-FALSE

I agree absolutely, and I argued that point originally.

The language already *has* this capability, though not in *direct, explicit*
syntax for the specific purpose.  It doesn't matter whether you call the
88-level item "ITS-FALSE" or "PIGS-FLY" or "THE-COWS-COME-HOME" or
"HELL-FREEZES-OVER".

That's why I originally argued we didn't need to add syntax, and that's why
I made  J4/04-0195, "Provide Explicit Infinite Loop Capability", a separate
proposal from J4/04-0194, "Allow EXIT PERFORM [CYCLE] in out-of-line
PERFORM".

Both documents are now available on the J4 website at
www.cobolportal.com/j4/.

My guess -- not having conferred with other J4 members on this -- is that
04-0194, unless somebody comes up with a concrete technical reason why it
won't work, will probably not have much opposition.  But I expect opposition
to 04-0195 specifically on the grounds that the capability exists today (and
has for a very long time!); the only real counter-argument I can think of is
that adding syntax notifies the *compiler* that there *is no* test to be
performed *and* that the PERFORM range is executed repeatedly until (if at
all) something in that range passes control to its terminus, or outside it
entirely.  Without the explicit syntax, no matter how simple the test, the
presumption is that some sort of test is being performed on each iteration,
and it can't be presumed that the implementor will note at compile time that
the results of the test are invariant.  That may not be enough.

    -Chuck Stevens


0
11/1/2004 6:35:15 PM
"Warren Simmons" <wsimmons5@optonline.net> wrote in message
news:4182E68F.6030904@optonline.net...
> Regarding your last paragraph, would not the construction of a full
> proposal cover such problems and  highlight which of the methods would
> satisfy the most users?

I think the last paragraph you were referring to was:

> And if EXIT PERFORM (or for that matter EXIT PERFORM CYCLE) is allowed
> outside of the context of inline PERFORMs, I'm not sure what change you'd
> have to make if the inline PERFORM got too unwieldy.

If the programmer's intent is specifically to terminate an out-of-line
PERFORM, regardless of what the beginning or end of that range was, I think
EXIT PERFORM more clearly reflects that intent than GO TO
<some-arbitrary-paragraph-name>, EXIT PARAGRAPH or EXIT SECTION.

Likewise, for the case in which the programmer intends to terminate the
current PERFORM cycle *and start a new one*, I think EXIT PERFORM CYCLE is
clearer "in situ" than GO TO <some-arbitrary-paragraph-or-section-name>
where the section or paragraph-name is the beginning of the PERFORM range.

    -Chuck Stevens.


0
11/1/2004 6:47:54 PM
To add to what Chuck said below,  it turned out that the '85 Standard had 
problems with "parsing" of

   NOT GREATER OR EQUAL
   NOT LESS OR EQUAL

(without symbols) that were NOT problems when you did use the symbols.  There 
was an ATTEMPT to fix this by the time of the Correction Amendment - but it was 
only in the '02 Standard (where NOT was explicitly prohibited with both the 
symbolic and word formats) that this was "fixed".

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message 
news:clr0dk$2r54$1@si05.rsvl.unisys.com...
>
> "Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:4ga0o0t8hs2aog8ppb3g386vmepkls952r@4ax.com...
>
>> ">=" could have been accomplished with REPLACE. Why were they
>> reluctant on "<>" but not on ">="?
>
> ">=" and "<=" were added in '85.  By 2000 or so, some felt that might have
> been a mistake; certainly it violates the precept "... and avoid symbolism
> as far as possible. ..." (ANSI X3.23-1985 page XVII-1, first paragraph,
> penultimate sentence).
>
>    -Chuck Stevens
>
> 


0
wmklein (2605)
11/1/2004 11:40:43 PM
The "GOBACK" functionality was explicitly disallowed in the '85 Standard, as

   EXIT PROGRAM
   STOP RUN

as a "sequence of statements" was explicitly illegal (and was/is the meaning of 
GoBack)

EXIT PROGRAM in a "main" program has NEVER meant "STOP RUN".

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Lueko Willms" <l.willms@jpberlin.de> wrote in message 
news:9Jj8aVw9flB@jpberlin-l.willms.jpberlin.de...
>.    On  27.10.04
>  wrote  charles.stevens@unisys.com (Chuck Stevens)
>     on  /COMP/LANG/COBOL
>     in  clp68s$1jgu$1@si05.rsvl.unisys.com
>  about  Re: Report enhancements
>
>
> CS> If the justification for suggesting that there's a capability that
> CS> needs to be added to 20xx COBOL because it's not in 1985 COBOL, it
> CS> might be a good idea to see if that capability exists in the
> CS> *current* standard and/or the draft of the *next* one!
>
>   The functionality of GOBACK has long been in the COBOL standard by
> means of the EXIT statement -- so why has this duplication been added?
>
>
> CS> But it seems to me the "new way" of specifying this functionality --
> CS> be it PERFORM WITH NO TEST, PERFORM FOREVER, or PERFORM UNTIL
> CS> EXIT -- can be accomplished with 2002-compliant COBOL through
> CS> REPLACE with no adjustments to the syntax or to the reserved word
> CS> list (e.g., FOREVER).
>
>   It is not the same to specify a dummy condition test for entering a
> loop on the one hand and to specify that there is no test at all.
>
>   That a cute compiler and optimizer can prevent that dummy-condition
> being evaluated for every cycle of the loop, does not create the
> clarity of the program for a human reader.
>
>   I repeat what I had stated before: I don't feel an urgent need to
> have that functionality added, because I prefer loops to have their
> proper entry or exit condition at the beginning or the end, but not
> somewhere in the middle. But because the EXIT PERFORM is already in
> the standard (2002), and there _are_ situations where such a loop may
> be needed ... i.e. for the sake of completeness.
>
>
> Yours,
> L�ko Willms                                     http://www.willms-edv.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> Er trieb einen kleinen Finsternis-Handel. -G.C.Lichtenberg 


0
wmklein (2605)
11/1/2004 11:45:59 PM
Chuck,
   Robert has a good point here.  I know that the '02 (and earlier) Standards 
REQUIRES that a "format 1" EXIT statement (the one that is just a "marker" for 
an exit-paragraph/section) must be the only statement in a sentence and that 
must be the only sentence in the procedure.  HOWEVER, I think there are some 
implementations that don't require this as an extension.  For those "adding" an 
EXIT PERFORM format would be a syntactic problem.  Consider (indenting for 
clarity).  I also KNOW that some implementations allow the "END-PERFORM" to be 
omitted at the end of an inline perform - before a period (similar to other 
scope delimiters).

  Para1.
     Display "Here"
     Exit
     Perform
            Display "Here too"
         .

***

Clearly, this is NOT valid for the '02 (or '85 - or any other STANDARD 
compiler).  However, I could imagine it being "confusing" to both compiler and 
programmer if coded as:

  Para1.
    Display "Here"
    Exit Perform
    Display "Here too"
       .



-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message 
news:clrqli$bda$1@si05.rsvl.unisys.com...
> Robert Wagner wrote:
>
>> I think the reason is syntactical. EXIT FOO can be read GO TO
>> (nearest) END-FOO (and stop looping for perform), where END-FOO can be
>> explicit or implicit.
>
> Not sure what this means; could you clarify?
>
>> An out-of-line EXIT PERFORM cannot ascertain
>> where the exit is by syntax alone; it must get the address from the
>> stack at execution time.
>
> This I understand.  The object code has a problem figuring out whether the
> statement is executed under control of a PERFORM by examining the stack at
> execution time ... exactly why?
>
> All our compilers need to generate for out-of-line EXIT PERFORM is DUPL,
> ZERO, GRTR, BRFL (continue), DLET, DBUN.  If what's on the top of the stack
> at the start of *any* statement is a zero, we're not in an active
> out-of-line PERFORM (unless the stack is munged, in which case we're hosed
> anyway); if it isn't, we are.  Looks really simple to me.
>
>> You are using semantics rather than syntax. To this outside observer,
>> it seems J4 would not be receptive.
>
>
> Not sure I understand why not.  EXIT PERFORM is *syntactically* disallowed
> outside the context of an *inloine* PERFORM; I'm not convinced the
> restriction is appropriate.  The proposed *semantics* of EXIT PERFORM would
> be exactly analogous to those of EXIT PROGRAM when the program in question
> wasn't CALLed -- CONTINUE.  I don't see what it'd *break* to provide it, and
> I can certainly see the utility (of both EXIT PERFORM and EXIT PERFORM
> CYCLE) in the context of an out-of-line PERFORM, not just for clarity of
> syntax but for functionality otherwise unavailable (except for GO TO).
>
>> >I agree that an out-of-line indefinite PERFORM pretty much requires
> either
>> >the despised GO TO or the prohibited EXIT PERFORM, but I'm not really
>> >opposed to relaxing the restriction on the latter, unless someone
> convinces
>> >me that there's a good reason why it's there.
>>
>> I can't think of a good reason.
>
> Well, there ya go.  That's my point.
>
>> But it would require TRUE and FALSE to be boolean literals, as they
>> are in most other languages and in Micro Focus as an extension.
>
> No, not quite right.  The syntax rules can permit their use in specific
> contexts.
>
>
>> While we're on the subject, it seems asymmetrical that we can say SET
>> CONDITION-1 TO FALSE  but cannot say
>>
>> 01    PIC X VALUE FALSE.
>>        88  CONDITION-1 VALUES 'A' 'B' 'C' FALSE 'D'.
>
> I think you've misunderstood.  VALUE FALSE applies *only* to 88's, and the
> filler isn't an 88.
>
> I see no inconsistency.  *ALL* the values save 'A', 'B' and 'C' would result
> in CONDITION-1 being FALSE; there may be any number of FALSE values.  There
> may be only one such value to which the parent item is set *when* you SET
> the condition to FALSE.   "VALUE FALSE" is unnecessary as well as
> meaningless on the PIC X item.
>
>> When the value of false changes to 'E', we must change 01 VALUE as
>> well as 88 VALUES. That's contrary to the spirit of 88s.
>
> 'E' is but one of probably 253 values for the PIC X item that would cause
> CONDITION-1 to be FALSE.  VALUE FALSE has nothing to do with the value that
> RESULTS in FALSE, it only specifies which value is used when it is
> EXPLICITLY SET to FALSE.
>
>> Examples follow. Please explain how we can do this with '02 features.
>
> Easy.
>
> Method 1:   Use >>DEFINE I-AM-DEBUGGING at the beginning of the program and
>>>IF I-AM-DEBUGGING... >> END-IF pairs around the IFs and END-IFs.   Maybe
> not quite as elegant as your examples, but functional.
>
> Method 2:
>
>    D77  PIC 9 VALUE 1.
>    D88  ITS-TRUE VALUE 1.
>    D88  ITS-FALSE VALUE 0.
>
>    D     OR ITS-TRUE   ...
>    D    AND ITS-FALSE ...
>
> Oh.  Wait.  That works in COBOL85.  To get it up to COBOL2002 I'd have to do
> something like USAGE BIT ...
>
>    -Chuck Stevens
>
> 


0
wmklein (2605)
11/1/2004 11:57:14 PM
"William M. Klein" <wmklein@nospam.netcom.com> wrote 

> The "GOBACK" functionality was explicitly disallowed in the '85 Standard, as
> 
>    EXIT PROGRAM
>    STOP RUN
> 
> as a "sequence of statements" was explicitly illegal (and was/is the meaning of 
> GoBack)

First of all GOBACK was not part of the '85 standard. It is entirely
possible to have the two statements executed in sequence:

       PROCEDURE DIVISION.
       Main.
           PERFORM All-Processing
           .
       Try-Exit.
           EXIT PROGRAM.
       Try-Stop.
           STOP RUN.

       All-Processing.  
           ...

> EXIT PROGRAM in a "main" program has NEVER meant "STOP RUN".

Though this has ugly drop throughs, which part is 'explicitly
disallowed' or doesn't execute these two in sequence, by any standard
?

In any wasn't is agreed that the restriction of EXIT (requiring to be
in a pargarph of its own) extending to EXIT PROGRAM was a mistake ?
0
riplin (4127)
11/2/2004 8:00:02 AM
..    On  29.10.04
  wrote  riplin@Azonic.co.nz (Richard)
     on  /COMP/LANG/COBOL
     in  217e491a.0410291952.402e227e@posting.google.com
  about  Re: Report enhancements


>> And if EXIT PERFORM (or for that matter EXIT PERFORM CYCLE) is allowed
>> outside of the context of inline PERFORMs, I'm not sure what change
>> you'd have to make if the inline PERFORM got too unwieldy.

r> Hmm.  It may not work.  For example if I had:
r>
r>       PERFORM UNTIL EXIT
r>           READ file NEXT RECORD
r>               AT END
r>                   EXIT PERFORM
r>               NOT AT END
r>                   IF filekey > key-limit
r>                       EXIT PERFORM
r>                   ELSE
r>                       ...
r>                   END-IF
r>            END-READ
r>       END-PERFORM
r>
r> and I decided to unwield it to:

   Better make it wieldy as the proper structure:

    READ file NEXT RECORD
    PERFORM UNTIL has-found-EOF IN FILE-STATUS-file
               OR filekey > key-limit
       do-your-processing-of-that-record
       READ file NEXT RECORD
    END-PERFORM


    and you have a much cleaner piece of code, and one which really  
reflects the data structure it is supposed to work on. You don't need  
all those other entanglements. 6 simple lines instead of 12  
complicated ones.

    Remember that for a file of n elements, you need n + 1 attempts to  
fetch the next record. This one extra fetch should be done ahead of  
the loop processing the successfully fetched record, outside of the  
loop, not in the middle of it. And, whoops, you have a clean and  
wieldy program. You can start the sequence of repeated statemens with  
the valid assertion that a valid record (or data object) is available  
for processing.

    And don't care about AT END and NOT AT END, that is taken care of  
by the File Status and the loop entry condition.

    This way you can formulate the entry condition for the loop as ONE  
and don't have to wrangle with several IFs and ELSEs and EXITs and  
this and that. Laokoon fighting with the snakes should not be the  
model of a computer program.




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

Wir wohnen in G�ttingen in Scheiterhaufen, die mit T�ren und Fenstern versehen sind. -G.C.Lichtenberg
0
l.willms1 (637)
11/2/2004 9:05:00 AM
I wouldn't mind seeing EXIT becoming archaic.   It is very easy to replace with
CONTINUE.

CONTINUE has an advantage with debugger:

 PARAGRAPH-EXIT.
     CONTINUE.
D   DISPLAY "Reached Paragraph-exit".


I don't see any disadvantage to using the word CONTINUE now that it is available
everywhere.
0
howard (6283)
11/2/2004 3:04:28 PM
..    On  29.10.04
  wrote  ricksmith@mfi.net (Rick Smith)
     on  /COMP/LANG/COBOL
     in  10o5kbsmbg43h0b@corp.supernews.com
  about  Re: Report enhancements


RS>
RS> Apparently, my vision is quite selective and I did not
RS> see that phrases were buried within phrases. By
RS> "qualifying phrase," I intended the TIMES, UNTIL,
RS> and VARYING phrases.

>>> There are three distinct phrases: TIMES, UNTIL, and
>>> VARYING. You seem to be treating VARYING as an
>>> variation of UNTIL; it is not.
>>
>> Do you have a form of VARYING that does not require the UNTIL ?

RS> I have no form of VARYING that is not in the standard
RS> and the standard specifies that VARYING and UNTIL
RS> are separate phrases.

   Sure, but VARYING does not provide a terminating condition. One  
could as well add or subtract the counter value being VARYied within  
the loop.

   Decisive is the UNTIL-clause which determines which condition  
prevents the loop being entered (WITH TEST BEFORE) or being exited  
(WITH TEST AFTER).

   So, actually there are only two ways to formulate the termination  
of a loop in COBOL:

   PERFORM ... TIMES

   (when the number of occurences is known beforehand)

and

   PERFORM UNTIL some-condition

  (when there is a finite, but yet unknown number of occurrences).


   Instead of

     READ input-record
     PERFORM UNTIL has-reached-end-of-file
       VARYING record-counter FROM 1 BY 1
       do-something-with-the-record
       READ input-record
     END-PERFORM


   one could also write:

     READ input-record
     PERFORM UNTIL has-reached-end-of-file
       ADD 1 TO record-counter
       do-something-with-the-record
       READ input-record
     END-PERFORM

   and it is functionally the same. For nested VARYINGs one might  
simply write nested loops, like this:

    MOVE ZERO TO outer-counter
    PERFORM UNTIL NOT outer-loop-entry-condition
      ADD 1 TO outer-counter
      MOVE ZERO to inner-counter
      PERFORM UNTIL NOT inner-loop-entry-condition
        ADD 1 TO inner-counter
        do-something-cute
           *> e.g. using the inner and outer counter
           *> as subscripts into a table,
      END-PERFORM
    END-PERFORM


   instead of

    PERFORM UNTIL NOT outer-loop-entry-condition
            VARYING   outer-counter FROM 1 BY 1
         AFTER VARYING inner-counter FROM 1 BY 1
           UNTIL NOT inner-loop-entry-condition

      do-something-with-it
    END-PERFORM

    Frankly, in all those years that I was programming COBOL for  
production, I always had problems figuring out what was the outer and  
inner loop of the nested VARYING.



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

Man kann wirklich nicht wissen ob man nicht jetzt im Tollhaus sitzt. -G.C.Lichtenberg
0
l.willms1 (637)
11/2/2004 3:24:00 PM
My point about PERFORM UNTIL EXIT is that I can certainly see the potential
of syntactic/semantic ambiguities that could present problems for the
implementor, which potential doesn't exist for the PERFORM UNTIL FALSE case.
I don't dispute that, upon extensive analysis, one might find that there is
no ambiguity after all, and that no implementor would have a problem
providing the syntax with no ambiguities whatever.

I thought I made it clear both in this forum and in the proposal itself that
the heart of the proposal wasn't the *syntax* but rather the
*functionality*.   If J4 decides this is worth pursuing, I have no doubt
whatever that the appropriate syntax will be debated at rather more length
than it deserves, and very little doubt that the final syntax won't be
PERFORM UNTIL EXIT.  The syntax was chosen because *I* was writing the
proposal, and *I* thought it was the best of the available choices for
stated reasons.

Can you (or Robert) demonstrate that there is no circumstance in the
standard, no individual's choice of parsing mechanism in existing compilers
and no existing implementor extension for which PERFORM ... UNTIL EXIT might
present a semantic problem?

I understand the point that he's *probably* right, but as a first "Here's a
functionality I think is useful" stab at a proposal, I don't think the
PERFORM UNTIL FALSE is so horrible a first choice as to sink the entire
ship!

    -Chuck Stevens


0
11/2/2004 5:11:28 PM
On  2-Nov-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

>    Better make it wieldy as the proper structure:
>
>     READ file NEXT RECORD
>     PERFORM UNTIL has-found-EOF IN FILE-STATUS-file
>                OR filekey > key-limit
>        do-your-processing-of-that-record
>        READ file NEXT RECORD
>     END-PERFORM

I remember people teaching that we shouldn't have multiple READ commands.   But
the above structure is so easy, so clean, and so simple that it I have ignored
them for decades.
0
howard (6283)
11/2/2004 5:31:06 PM
..     Am  02.11.04
 schrieb  howard@brazee.net (Howard Brazee)
     bei  /COMP/LANG/COBOL
      in  cm8g8q$ak0$1@peabody.colorado.edu
   ueber  Re: How to process a file (was: Report enhancements)

LW>>    Better make it wieldy as the proper structure:
LW>>
LW>>     READ file NEXT RECORD
LW>>     PERFORM UNTIL has-found-EOF IN FILE-STATUS-file
LW>>                OR filekey > key-limit
LW>>        do-your-processing-of-that-record
LW>>        READ file NEXT RECORD
LW>>     END-PERFORM

HB> I remember people teaching that we shouldn't have multiple READ
HB> commands.

   Maybe, but for reading and processing a file with n elements, one  
needs to perform n + 1 READs, but wants only to process a record n  
times. How to deal with the difference? Many COBOL programmers who  
follow the above rule: "thou shalt have only one READ statement in  
your program!" are forced to enter the loop over the file items not n  
times, the number of records in the file, but n + 1 times, and  find  
themselves in a situation where they have to treat the _processing_ of  
the items found as an exception, guarded by IFs and ELSEs, and this  
for each and every READ performed. But processing the record found  
should be the norm, the exception being that one extra READ which  
results in EOF.

   One wants the loop to run only n times, the number of records  
available for processing, and this leads to do a very first READ  
_before_ opening the loop, which then begins with the valid assertion  
that a record is available, and ends with an attempt to get a next  
item -- an attempt which may fail, and therefore create the condition  
to end the repetition.


HB> But the above structure is so easy, so clean, and so
HB> simple that it I have ignored them for decades.

   One never stops learning till the very end.


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)
11/2/2004 7:23:00 PM
On thing I like about C and "C-like" languages is that you can do something
like the following:

while (readnextrec() == true) {
    process_record();
}

If readnextrec() returns "true" then it will perform process_record().  If
it returns "false" then it will not.


>>> Howard Brazee<howard@brazee.net> 11/2/2004 10:31:06 AM >>>

On  2-Nov-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

>    Better make it wieldy as the proper structure:
>
>     READ file NEXT RECORD
>     PERFORM UNTIL has-found-EOF IN FILE-STATUS-file
>                OR filekey > key-limit
>        do-your-processing-of-that-record
>        READ file NEXT RECORD
>     END-PERFORM

I remember people teaching that we shouldn't have multiple READ commands.  
But
the above structure is so easy, so clean, and so simple that it I have
ignored
them for decades.


0
11/2/2004 9:54:04 PM
On 02 Nov 2004 19:23:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>.     Am  02.11.04
> schrieb  howard@brazee.net (Howard Brazee)
>     bei  /COMP/LANG/COBOL
>      in  cm8g8q$ak0$1@peabody.colorado.edu
>   ueber  Re: How to process a file (was: Report enhancements)
>
>LW>>    Better make it wieldy as the proper structure:
>LW>>
>LW>>     READ file NEXT RECORD
>LW>>     PERFORM UNTIL has-found-EOF IN FILE-STATUS-file
>LW>>                OR filekey > key-limit
>LW>>        do-your-processing-of-that-record
>LW>>        READ file NEXT RECORD
>LW>>     END-PERFORM
>
This is mostly a matter of style in my opinion.
I don't like the above, and I would code it as

     PERFORM UNTIL exit-loop
       read file next
         at end
            set exit-loop to true
       not at end
           if filekey > key-limit
              set exit-loop to true
           else
              do-your-processing-of-that-record
       end-read
     end-perform
             
It is for me just as easy and as clear.


One of the reasons why I don't like the first structure is that I have
it seen to many times as

p1.
  perform init.
  perform main-loop UNTIL has-found-EOF IN FILE-STATUS-file
          OR filekey > key-limit
  perform clean.

init.
  open file.
  read file1 next.
      (or  perform read-prime)

.....
  other paragraphs
.....

main-loop.
  if (all my validations)
      blabla
  end-if.
  read file1 next.


clean.
  write headers
  close files

(optional...
read-prime
  read file1 next.

And I have seen worst than this.


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
0
11/2/2004 10:30:43 PM
In article <9K6kuLpPflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
>.     Am  02.11.04
> schrieb  howard@brazee.net (Howard Brazee)
>     bei  /COMP/LANG/COBOL
>      in  cm8g8q$ak0$1@peabody.colorado.edu
>   ueber  Re: How to process a file (was: Report enhancements)
>
>LW>>    Better make it wieldy as the proper structure:
>LW>>
>LW>>     READ file NEXT RECORD
>LW>>     PERFORM UNTIL has-found-EOF IN FILE-STATUS-file
>LW>>                OR filekey > key-limit
>LW>>        do-your-processing-of-that-record
>LW>>        READ file NEXT RECORD
>LW>>     END-PERFORM
>
>HB> I remember people teaching that we shouldn't have multiple READ
>HB> commands.
>
>   Maybe, but for reading and processing a file with n elements, one  
>needs to perform n + 1 READs, but wants only to process a record n  
>times. How to deal with the difference? Many COBOL programmers who  
>follow the above rule: "thou shalt have only one READ statement in  
>your program!" are forced to enter the loop over the file items not n  
>times, the number of records in the file, but n + 1 times, and  find  
>themselves in a situation where they have to treat the _processing_ of  
>the items found as an exception, guarded by IFs and ELSEs, and this  
>for each and every READ performed. But processing the record found  
>should be the norm, the exception being that one extra READ which  
>results in EOF.
>
>   One wants the loop to run only n times, the number of records  
>available for processing, and this leads to do a very first READ  
>_before_ opening the loop, which then begins with the valid assertion  
>that a record is available, and ends with an attempt to get a next  
>item -- an attempt which may fail, and therefore create the condition  
>to end the repetition.
>
>
>HB> But the above structure is so easy, so clean, and so
>HB> simple that it I have ignored them for decades.
>
>   One never stops learning till the very end.

Ahhhhhhh, another Ancient Conflict... FIRST-TIME-IN switches or a 
'priming' READ?

On the one hand... Thou Shalt Code Only One Read Per Type Per File, on the 
other hand in 00000-HOUSKEEPING one needs to check to see if one has an 
empty driver file, eg.

OPEN INPUT INFILE.
IF NOT GOOD-INFILE-IO
    MOVE 0165 TO WS-ABEND-REASON
    GO TO 99999-BLOW-EM-UP-GOOD.

READ INFILE INTO WK-INREC
    AT END MOVE 0172 TO WS-ABEND-REASON
           GO TO 99999-BLOW-EM-UP-GOOD.

What's a coder to do?  Why, what's been done for a few decades... isolate 
all IO into its own paragraphs (preferably, of course, in the 60000- 
range) and PERFORM them as needed anywhere in the program.  To make use of 
the example above:

00000-HOUSEKEEPING.
....
    OPEN INPUT INFILE.
    IF NOT GOOD-INFILE-IO
        MOVE 0165 TO WS-ABEND-REASON
        GO TO 99999-BLOW-EM-UP-GOOD.

    PERFORM 60500-READ-INFILE-NEXT  THRU  60500-EX.
    IF NO-MORE-INFILE
        MOVE 0172 TO WS-ABEND-REASON
        GO TO 99999-BLOW-EM-UP-GOOD.

....
00000-EX.
    EXIT.

10000-MAIN-LINE.

    PERFORM 60500-READ-INFILE-NEXT  THRU  60500-EX.
    IF NO-MORE-INFILE
        PERFORM 80000-LAST-RPT-BRK  THRU  80000-EX
        GO TO 10000-EX.

....
10000-EXIT.
    EXIT.

Look at that... all caps, rigid use of A- and B-margins, no 
scope-delimiters, periods galore, PERFORM THRU -EXits...

.... and if there's a reader who looks at that and cannot almost viscerally 
grasp what is going on then I'd be willing to wager said reader has fewer 
than two year's worth of experience.  This kind of code is old enough to 
vote and then some... and there's a few reasons why it has been in 
production that long.  Sure, it may not gently stroke one's delicate sense 
of aesthetics... but, for the most part, it works.

Don't like it?  Fine... rewrite it and test the rewrite... after you 
figure out what budget-code to use, that is.

DD

0
docdwarf (6044)
11/3/2004 12:26:48 AM
On  2-Nov-2004, Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:

> This is mostly a matter of style in my opinion.
> I don't like the above, and I would code it as
>
>      PERFORM UNTIL exit-loop
>        read file next
>          at end
>             set exit-loop to true
>        not at end
>            if filekey > key-limit
>               set exit-loop to true
>            else
>               do-your-processing-of-that-record
>        end-read
>      end-perform
>
> It is for me just as easy and as clear.

My choice is to minimize switches.   I've done too much maintenance programming
to be a fan of switches.


> One of the reasons why I don't like the first structure is that I have
> it seen to many times as
>
> p1.
>   perform init.
>   perform main-loop UNTIL has-found-EOF IN FILE-STATUS-file
>           OR filekey > key-limit
>   perform clean.
>
> init.
>   open file.
>   read file1 next.
>       (or  perform read-prime)
>
> ....
>   other paragraphs
> ....
>
> main-loop.
>   if (all my validations)
>       blabla
>   end-if.
>   read file1 next.
>
>
> clean.
>   write headers
>   close files
>
> (optional...
> read-prime
>   read file1 next.
>
> And I have seen worst than this.

For various values of "worse", I would nominate your preferred code with the
switches.    While not quite what I'd do, I don't see anything particularly
objectionable with your "bad" example.   I do object to switches though.

Different strokes for different folks, I guess.
0
howard (6283)
11/3/2004 2:34:30 PM
On  2-Nov-2004, docdwarf@panix.com wrote:

> What's a coder to do?  Why, what's been done for a few decades... isolate
> all IO into its own paragraphs (preferably, of course, in the 60000- 
> range) and PERFORM them as needed anywhere in the program.  To make use of
> the example above:

I have always been amused by the solution to "only have the read at one spot",
of calling it from PERFORMs in multiple spots.    It gets one by the standards
committee without making any real difference.

Whatever theory there is about single-spot code is destroyed by obfuscating that
we are really doing it. 
0
howard (6283)
11/3/2004 2:38:23 PM
In article <cmaqgv$7m8$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On  2-Nov-2004, docdwarf@panix.com wrote:
>
>> What's a coder to do?  Why, what's been done for a few decades... isolate
>> all IO into its own paragraphs (preferably, of course, in the 60000- 
>> range) and PERFORM them as needed anywhere in the program.  To make use of
>> the example above:
>
>I have always been amused by the solution to "only have the read at one spot",
>of calling it from PERFORMs in multiple spots.    It gets one by the standards
>committee without making any real difference.

I'm not sure about a 'real' difference... but when it comes to slogging 
through the code it might be easier to find applicable occurrences of 
60520-EX instead of looking for EMP-MSTR-FIL; the former will more likely 
be referred to in PERFORM statements only whereas the latter might show up 
in comments, data-names and other non-IO related statements.

DD
0
docdwarf (6044)
11/3/2004 3:03:33 PM
William M. Klein wrote:

> The "GOBACK" functionality was explicitly disallowed in the '85 Standard, as
> 
>    EXIT PROGRAM
>    STOP RUN
> 
> as a "sequence of statements" was explicitly illegal (and was/is the meaning of 
> GoBack)

What was the logic of making the EXIT PROGRAM STOP RUN sequence illegal? 
  I think that I have used it with IBM mainframe compilers when I wasn't 
allowed to use GOBACK but that may be faulty memory.

Clark Morris cfmtech@istar.ca
> 
> EXIT PROGRAM in a "main" program has NEVER meant "STOP RUN".
> 
0
cfmtech (125)
11/4/2004 1:59:21 AM
This was an old restriction (removed in the '02 Standard).  I don't know what 
its "justification" was.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message 
news:2utgn9F2eb7esU1@uni-berlin.de...
> William M. Klein wrote:
>
>> The "GOBACK" functionality was explicitly disallowed in the '85 Standard, as
>>
>>    EXIT PROGRAM
>>    STOP RUN
>>
>> as a "sequence of statements" was explicitly illegal (and was/is the meaning 
>> of GoBack)
>
> What was the logic of making the EXIT PROGRAM STOP RUN sequence illegal? I 
> think that I have used it with IBM mainframe compilers when I wasn't allowed 
> to use GOBACK but that may be faulty memory.
>
> Clark Morris cfmtech@istar.ca
>>
>> EXIT PROGRAM in a "main" program has NEVER meant "STOP RUN".
>> 


0
wmklein (2605)
11/4/2004 3:41:40 AM
EXIT PROGRAM started out as having to be in a paragraph by itself (ANSI
X3.23-1974 page XII-8, 3.4.3, The EXIT PROGRAM Statement, syntax rule 2).

This was later relaxed, but if EXIT PROGRAM appeared in a consecutive
sequence of statements within a sentence, it had to be the last statement in
the sentence (ANSI X3.23-1985 page X-23, 5.4.3, The EXIT PROGRAM Statement,
syntax rule 1).

    -Chuck Stevens


"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
news:2utgn9F2eb7esU1@uni-berlin.de...
> William M. Klein wrote:
>
> > The "GOBACK" functionality was explicitly disallowed in the '85
Standard, as
> >
> >    EXIT PROGRAM
> >    STOP RUN
> >
> > as a "sequence of statements" was explicitly illegal (and was/is the
meaning of
> > GoBack)
>
> What was the logic of making the EXIT PROGRAM STOP RUN sequence illegal?
>   I think that I have used it with IBM mainframe compilers when I wasn't
> allowed to use GOBACK but that may be faulty memory.
>
> Clark Morris cfmtech@istar.ca
> >
> > EXIT PROGRAM in a "main" program has NEVER meant "STOP RUN".
> >


0
11/4/2004 4:33:04 PM
bottom posting

docdwarf@panix.com wrote in message news:<cmas05$q8d$1@panix5.panix.com>...
> In article <cmaqgv$7m8$1@peabody.colorado.edu>,
> Howard Brazee <howard@brazee.net> wrote:
> >
> >On  2-Nov-2004, docdwarf@panix.com wrote:
> >
> >> What's a coder to do?  Why, what's been done for a few decades... isolate
> >> all IO into its own paragraphs (preferably, of course, in the 60000- 
> >> range) and PERFORM them as needed anywhere in the program.  To make use of
> >> the example above:
> >
> >I have always been amused by the solution to "only have the read at one spot",
> >of calling it from PERFORMs in multiple spots.    It gets one by the standards
> >committee without making any real difference.
> 
> I'm not sure about a 'real' difference... but when it comes to slogging 
> through the code it might be easier to find applicable occurrences of 
> 60520-EX instead of looking for EMP-MSTR-FIL; the former will more likely 
> be referred to in PERFORM statements only whereas the latter might show up 
> in comments, data-names and other non-IO related statements.
> 
> DD

Another advantage of having a performed READ is when you want to be
able to change a file, perhaps as part of a RDBMS conversion to enable
the main part of the program to access the "file" as it always was,
while allowing new programs to be developed with the new facilities.

I would tend to use both approaches depending upon circumstances,
though not in the same program.

Robert
0
rjones0 (206)
11/4/2004 6:36:39 PM
One advantage to having separate READ for first and subsequent reads is that we
can have a bit more information with problems:

     READ  FIND-IN-FILE    INTO FIND-IN-REC.
     IF FIND-IN-STATUS-OK
         CONTINUE
     ELSE
         DISPLAY 'ERROR ' FIND-IN-STATUS
             ' READING  FIRST FIND-IN FILE'
         GO TO ABORT
     END-IF.

     PERFORM 1000-MAIN           	
         UNTIL FIND-IN-AT-END.

 1000-MAIN.
      ...
     READ  FIND-IN-FILE    INTO FIND-IN-REC.
     IF FIND-IN-STATUS-OK
         CONTINUE
     ELSE
         DISPLAY 'ERROR ' FIND-IN-STATUS
             ' READING  SUBSEQUENT FIND-IN FILE'
         GO TO ABORT
     END-IF.
0
howard (6283)
11/4/2004 6:56:28 PM
In article <6dd8322.0411041036.28a42e12@posting.google.com>,
Robert Jones <rjones0@hotmail.com> wrote:
>bottom posting
>
>docdwarf@panix.com wrote in message news:<cmas05$q8d$1@panix5.panix.com>...
>> In article <cmaqgv$7m8$1@peabody.colorado.edu>,
>> Howard Brazee <howard@brazee.net> wrote:
>> >
>> >On  2-Nov-2004, docdwarf@panix.com wrote:
>> >
>> >> What's a coder to do?  Why, what's been done for a few decades... isolate
>> >> all IO into its own paragraphs (preferably, of course, in the 60000- 
>> >> range) and PERFORM them as needed anywhere in the program.  To make use of
>> >> the example above:
>> >
>> >I have always been amused by the solution to "only have the read at one spot",
>> >of calling it from PERFORMs in multiple spots.    It gets one by the standards
>> >committee without making any real difference.
>> 
>> I'm not sure about a 'real' difference... but when it comes to slogging 
>> through the code it might be easier to find applicable occurrences of 
>> 60520-EX instead of looking for EMP-MSTR-FIL; the former will more likely 
>> be referred to in PERFORM statements only whereas the latter might show up 
>> in comments, data-names and other non-IO related statements.
>> 
>
>Another advantage of having a performed READ is when you want to be
>able to change a file, perhaps as part of a RDBMS conversion to enable
>the main part of the program to access the "file" as it always was,
>while allowing new programs to be developed with the new facilities.

I also recall something about being able to port code more easily, in that 
different compilers/platforms will have different syntaces for IO 
imperatives... truth be known, though, my experience is such that this has 
never been an actual (as opposed to theoretical or 'you never knoo-ooow!') 
consideration.

DD

0
docdwarf (6044)
11/4/2004 7:07:45 PM
Bottom posted


On 20-Oct-2004, "Rick Smith" <ricksmith@mfi.net> wrote:

> After loading some data into 'item.dat', I ran the following
> program to create 'item.lst'. I then loaded the list file into
> both Microsoft Excel and Microsoft Access.
>
> Seems to work OK.
> --------
>        identification division.
>        program-id. rpt-test.
>        environment division.
>        input-output section.
>        file-control.
>            select item-file assign to "item.dat"
>                organization is indexed
>                access is sequential
>                record key is item-id.
>            select item-list assign to "item.lst"
>                organization is line sequential.
>        data division.
>        file section.
>        fd item-file.
>        01 item-record.
>          05 item-id pic x(6).
>          05 item-description pic x(30).
>          05 item-price packed-decimal pic s9(5)v99.
>        fd item-list
>            report is item-report.
>        01 item-list-record pic x(45).
>        report section.
>        rd item-report.
>        01 item-detail type is detail line number is plus 1.
>          05 column  1 pic x(6) source is item-id.
>          05 column  7 pic x(30) source is item-description.
>          05 column 37 pic +9(5).99 source is item-price.
>        procedure division.
>        begin.
>            open input item-file
>            open output item-list
>            initiate item-report
>            perform until exit
>                read item-file
>                    at end exit perform
>                end-read
>                generate item-detail
>            end-perform
>            terminate item-report
>            close item-list
>            close item-file
>            stop run
>        end program rpt-test.
> -----

I just created some programs that downloaded data that were loaded into Oracle.
 My requirements included getting rid of extra spaces.

So after populating the output, line I needed to perform:

 8000-COMPRESS.
     PERFORM VARYING WORK-LINE-BRACE FROM WORK-LINE-size  BY -1
               UNTIL WORK-LINE-BRACE < 2
         IF WORK-LINE (WORK-LINE-BRACE:1) = SINGLE-BRACE
             PERFORM 8100-END-BRACE
         END-IF
     END-PERFORM.

 8100-END-BRACE.

     SUBTRACT 1              FROM WORK-LINE-BRACE
                           GIVING WORK-LINE-SPACE.
     MOVE WORK-LINE-BRACE      TO WORK-LINE-DEST.
     PERFORM VARYING WORK-LINE-SPACE FROM WORK-LINE-SPACE
                                         BY -1
               UNTIL WORK-LINE (WORK-LINE-SPACE:1) > SPACE
                  IF WORK-LINE (WORK-LINE-SPACE:1) = SPACE
                      MOVE WORK-LINE (WORK-LINE-DEST:)
                             TO WORK-LINE (WORK-LINE-SPACE:)
                      MOVE WORK-LINE-SPACE
                             TO WORK-LINE-DEST
                  END-IF
     END-PERFORM.

Data look like:
   03  TR-SEQUENCE          PIC 9(06)          VALUE ZERO.
   03  FILLER                       PIC X(03)          VALUE '{,{'.
   03  TR-LINE-DATE            PIC X(06)          VALUE SPACES.
   03  FILLER                       PIC X(03)          VALUE '{,{'.
   03  TR-LINE-SUBCODE     PIC X(05)          VALUE ZERO.
....
0
howard (6283)
11/5/2004 4:58:14 PM
..    On  02.11.04
  wrote  docdwarf@panix.com
     on  /COMP/LANG/COBOL
     in  cm98k8$l7v$1@panix5.panix.com
  about  Re: How to process a file


d> ... and if there's a reader who looks at that and cannot almost
d> viscerally grasp what is going on then I'd be willing to wager said
d> reader has fewer than two year's worth of experience.

   I grasp immediately is that somebody has created a complicated maze  
of trails and scents instead of drawing a simple map for an apparently  
simple data processing task.

   BTW, since you pose the question for experience credentials -- my  
COBOL experience goes back to 1978, when I learned it together with  
FORTRAN and Byte-Assembler, and ended the course as the best student  
of the year (at the Control Data Institute here in Frankfurt).

d> This kind of code is old enough to vote and then some... and
d> there's a few reasons why it has been in production that long.

  I can think of two:
  - there has never been an external requirement to change it
  - the code is so fragile that nobody dares to touch it


d> Sure, it may not gently stroke one's delicate sense of
d> aesthetics...

   It is not a question of aestetics, although elegance is the result  
of simplicity and lucidity, but of program correctness, but, well,  
that amounts to the same criterion.

d> but, for the most part, it works.

   Despite. But it should not only work for most parts, but for all.


d> Don't like it?  Fine... rewrite it and test the rewrite...

   A template for processing a file can be found in my other message  
in this thread, answering Federico Fonseca.

d> after you figure out what budget-code to use, that is.

   Maybe the budget-code for saving time, or to avoid rewriting the  
whole system in Java, and hiring a new team for that.

   Now you should retort: "Mr Willms! There is not *the* way!", and  
let me cut short the next step in our conversation, that sure, there  
are many ways to come from A to B.

   One can even walk on the hands or walk backwards, or walk on  
stilts. That has its purposes, but is mostly not appropriate when  
one's movement is geared towards getting over a certain distance in an  
optimum of minimizing time and minimising costs.

   When I want to go from Paris to London, of course I can walk to   
Calais, swim across the Channel and go on walking up to London; this  
is the best way for a sporting exercise or to get into the Guiness  
Book of Records. But when the goal is to get there quick and  
comfortable, the best bet might be to take the train from city center  
to city center, passing the channel via the tunnel.

   Or, to get from Jackson Heights in Queens (NY) to Lower Manhattan,  
one can go to La Guardia Airport and fly via some hub to Newark  
Airport, and get to Manhattan via the Newark Journal Square and the  
PATH train. But simpler and more appropriate for the task would be to  
get into the E or R subway lines...

   Having a map instead of just knowing some trails can make the  
difference of not seeing the wood for the trees.

   Questions of style like using upper or lower case letters don't  
matter here. But program structure sure does matter.


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

Der Satz mu� noch mit einem Bruch multipliziert werden. -G.C.Lichtenberg


0
l.willms1 (637)
11/6/2004 5:25:00 PM
..     Am  03.11.04
 schrieb  docdwarf@panix.com
     bei  /COMP/LANG/COBOL
      in  cmas05$q8d$1@panix5.panix.com
   ueber  Re: How to process a file

>> I have always been amused by the solution to "only have the read at
>> one spot", of calling it from PERFORMs in multiple spots.    It gets
>> one by the standards committee without making any real difference.

d> I'm not sure about a 'real' difference... but when it comes to
d> slogging through the code it might be easier to find applicable
d> occurrences of 60520-EX instead of looking for EMP-MSTR-FIL;

    Sure, 8 characters instead of 12. The search for Schrpf would be  
even faster, since this string has only 6 characters.

    But why would anybody want to search for such arbitrary strings?  
Why not search for "77 Sunset Strip" or "Pennsylvania 5000"? Why not  
simply search for READ?


d> the former will more likely be referred to in PERFORM statements

   What likelyhood? I also did not win in the lottery past saturday --  
only a chance of 1 to 14 millions for 6 out of 49. You offer 8 out of  
36, and with repetitions.

   What do I miss to understand your enigmatic words?



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)
11/6/2004 5:26:00 PM
..    On  02.11.04
  wrote  real-email-in-msg-spam@email.com (Frederico Fonseca)
     on  /COMP/LANG/COBOL
     in  b72go0humfg0921rofda5rnraipnmmpq2b@4ax.com
  about  Re: How to process a file


>> LW>>    Better make it wieldy as the proper structure:
>> LW>>
>> LW>>     READ file NEXT RECORD
>> LW>>     PERFORM UNTIL has-found-EOF IN FILE-STATUS-file
>> LW>>                OR filekey > key-limit
>> LW>>        do-your-processing-of-that-record
>> LW>>        READ file NEXT RECORD
>> LW>>     END-PERFORM

FF> This is mostly a matter of style in my opinion.

   No, it is less a matter of style, but of program correctness.

   Using upper or lower case letters or mixing both is a matter of  
style. I prefer to write the reserved words in capitals, and my user  
variables in mixed case.

FF> I don't like the above, and I would code it as

  a jagged structure which is difficult to grasp

FF>      PERFORM UNTIL exit-loop
FF>        read file next
FF>          at end
FF>             set exit-loop to true
FF>        not at end
FF>            if filekey > key-limit
FF>               set exit-loop to true
FF>            else
FF>               do-your-processing-of-that-record
FF>        end-read
FF>      end-perform
FF>
FF> It is for me just as easy and as clear.

   Not for me, and I would think for many more neither. You have a  
loop which is controlled by an additional condition called "exit- 
loop", but it is not clear in that moment, what the meaning of that  
condition is.

   The sequence being processed in the loop is jagged. You have a  
nested IF/ELSE test, first for the file-status END-OF-FILE, which  
actually _is_ a condition for not entering the loop, then for the  
record key being within the selected range. The actual processig is  
hidden in third level, behind a barrage of conditions.

   It is better to specify the EOF-status plus the range-condition as  
ONE condition for entering the loop, and not to introduce an  
_additional_ condition instead of the real condition.

   The above code suffers from clinging to the idea, that the loop  
processing n records in a file should be performed not n times, but n  
+ 1 times. I.e. when one has 10'000 records to process, one wants to  
loop to run 10'000, not more. What you propose above makes the program  
enter the loop 10'001 times, and because of that the actual processing  
of the record has to be protected by this jagged barrage of IFs and  
ELSEs.

   Do the additional READ outside of the repeated sequence of  
statements, immediately _before_ it, and you have a clean and wieldy  
code. A program whose structure reflects the actual structure of the  
data.


FF> One of the reasons why I don't like the first structure is that I
FF> have it seen to many times as

   where I don't see what would be wrong with it, except that it  
sticks to the limits imposed by the pre-1985 COBOL, and hides the  
actual processing in PERFORMed procedures instead of executing them in  
the main loop.

FF> And I have seen worst than this.

   My template for a sequential read of a file looks like this:

   This one has an OPTIONAL imput-file and generates output using  
REPORT WRITER. Serious errors (Major file status = 3 or 4) are taken  
care of contingency routines in the DECLARATIVES.


--------- schnipp -----------------------------------------
    OPEN INPUT input-file
    IF is-not-present-file in status-input-file
    THEN                                  *> minor filestat = '5'
      DISPLAY "input-file is not present"
    ELSE
      READ input-file
      IF has-reached-EOF in status-input-file
      THEN                                *> Major filestat = '1'
        DISPLAY "input-file is empty"
      ELSE
        OPEN OUTPUT output-file
        INITIATE output-report
        PERFORM WITH TEST AFTER
          UNTIL has-reached-EOF in status-input-file
          *> do something useful with the input record
          *>  whose presence is asserted here
          GENERATE report-detail-item
          READ input-file
        END-PERFORM
        TERMINATE output-report
        CLOSE output-file
      END-IF
      CLOSE input-file
    END-IF
    STOP RUN
    .
------------------ schnapp --------------------------------



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

A. Der Mann hat viele Kinder. B. Ja, aber ich glaube, von den meisten hat er blo� die Korrektur besorgt.  -G.C.Lichtenberg
0
l.willms1 (637)
11/6/2004 5:29:00 PM
In article <9KMrmw19flB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
>.     Am  03.11.04
> schrieb  docdwarf@panix.com
>     bei  /COMP/LANG/COBOL
>      in  cmas05$q8d$1@panix5.panix.com
>   ueber  Re: How to process a file
>
>>> I have always been amused by the solution to "only have the read at
>>> one spot", of calling it from PERFORMs in multiple spots.    It gets
>>> one by the standards committee without making any real difference.
>
>d> I'm not sure about a 'real' difference... but when it comes to
>d> slogging through the code it might be easier to find applicable
>d> occurrences of 60520-EX instead of looking for EMP-MSTR-FIL;
>
>    Sure, 8 characters instead of 12.

Mr Willms, the statement you interrupted at the semicolon above contains 
the phrase of 'it might be easier to find applicable occurrences', how do 
you conclude that the number of characters relates to the 'applicability' 
of occurrenct?

>The search for Schrpf would be  
>even faster, since this string has only 6 characters.

The question of speed was not addressed, Mr Willms.

>
>    But why would anybody want to search for such arbitrary strings?  
>Why not search for "77 Sunset Strip" or "Pennsylvania 5000"? Why not  
>simply search for READ?

This might be found in the rest of the sentence... which you address 
below.

>
>
>d> the former will more likely be referred to in PERFORM statements
>
>   What likelyhood? I also did not win in the lottery past saturday --  
>only a chance of 1 to 14 millions for 6 out of 49. You offer 8 out of  
>36, and with repetitions.
>
>   What do I miss to understand your enigmatic words?

Mr Willms, I have no idea whatsoever you are calling 'understanding'; I do 
know that I, personally, find it easier to make what I call 'sense' out of 
complete sentences, not fragments.  If you are interested in discussing 
the matter then I would suggest you re-quote the sentences in their 
entirety and indicate where you are having difficulties.

DD

0
docdwarf (6044)
11/7/2004 2:20:19 AM
In article <9KMrmZzuflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
>.    On  02.11.04
>  wrote  docdwarf@panix.com
>     on  /COMP/LANG/COBOL
>     in  cm98k8$l7v$1@panix5.panix.com
>  about  Re: How to process a file
>
>
>d> ... and if there's a reader who looks at that and cannot almost
>d> viscerally grasp what is going on then I'd be willing to wager said
>d> reader has fewer than two year's worth of experience.
>
>   I grasp immediately is that somebody has created a complicated maze  
>of trails and scents instead of drawing a simple map for an apparently  
>simple data processing task.

Mr Willms, how do you know 'an apparently simple data processing task' is 
being addressed without knowing 'what is going on'?

>
>   BTW, since you pose the question for experience credentials -- my  
>COBOL experience goes back to 1978, when I learned it together with  
>FORTRAN and Byte-Assembler, and ended the course as the best student  
>of the year (at the Control Data Institute here in Frankfurt).

Good... and you were able to see that 'what was going on' is 'an 
apparently simple data processing task', just as a two-year programmer 
might.

>
>d> This kind of code is old enough to vote and then some... and
>d> there's a few reasons why it has been in production that long.
>
>  I can think of two:
>  - there has never been an external requirement to change it
>  - the code is so fragile that nobody dares to touch it

There are situations I have encountered, Mr Willms, where such code has 
been the subject of many external requirement changes and so many people 
have touched it that the AUTHOR's name is now EVERYONE... but perhaps we 
have worked in different places at different times.

>
>
>d> Sure, it may not gently stroke one's delicate sense of
>d> aesthetics...
>
>   It is not a question of aestetics, although elegance is the result  
>of simplicity and lucidity, but of program correctness, but, well,  
>that amounts to the same criterion.

I have no idea what your criteria for 'program correctness' might be, Mr 
Willms.

>
>d> but, for the most part, it works.
>
>   Despite. But it should not only work for most parts, but for all.

I am not familiar with 'all' of anything, Mr Willms, so I try not to make 
comments about it.  When you are familiar with 'all' then, perhaps, you 
might be able to speak from experience.

>
>
>d> Don't like it?  Fine... rewrite it and test the rewrite...
>
>   A template for processing a file can be found in my other message  
>in this thread, answering Federico Fonseca.
>
>d> after you figure out what budget-code to use, that is.
>
>   Maybe the budget-code for saving time, or to avoid rewriting the  
>whole system in Java, and hiring a new team for that.

Maybe... or maybe not, Mr Willms; different shops allow for different 
activities.

>
>   Now you should retort: "Mr Willms! There is not *the* way!", and  
>let me cut short the next step in our conversation, that sure, there  
>are many ways to come from A to B.

Mr Willms, I do not believe that I have ever posted anything about '*the* 
way' (emphasis original) except as humor or sarcasm... and I have been 
known, at times, not to do as I 'should'.

DD

0
docdwarf (6044)
11/7/2004 2:29:33 AM
On 06 Nov 2004 17:29:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>   The sequence being processed in the loop is jagged. You have a  
>nested IF/ELSE test, first for the file-status END-OF-FILE, which  
>actually _is_ a condition for not entering the loop, then for the  
>record key being within the selected range. The actual processig is  
>hidden in third level, behind a barrage of conditions.
>
>   It is better to specify the EOF-status plus the range-condition as  
>ONE condition for entering the loop, and not to introduce an  
>_additional_ condition instead of the real condition.
>
>   The above code suffers from clinging to the idea, that the loop  
>processing n records in a file should be performed not n times, but n  
>+ 1 times. I.e. when one has 10'000 records to process, one wants to  
>loop to run 10'000, not more. What you propose above makes the program  
>enter the loop 10'001 times, and because of that the actual processing  
>of the record has to be protected by this jagged barrage of IFs and  
>ELSEs.
>
>   Do the additional READ outside of the repeated sequence of  
>statements, immediately _before_ it, and you have a clean and wieldy  
>code. A program whose structure reflects the actual structure of the  
>data.

It's refreshing to hear another voice that values clean logic over a
coding-oriented solution. The difference is designing programs
top-down rather than bottom-up.
0
11/7/2004 10:59:47 AM
..    On  06.11.04
  wrote  docdwarf@panix.com
     on  /COMP/LANG/COBOL
     in  cmk0p3$g1a$1@panix5.panix.com
  about  Re: How to process a file



d>>> I'm not sure about a 'real' difference... but when it comes to
d>>> slogging through the code it might be easier to find applicable
d>>> occurrences of 60520-EX instead of looking for EMP-MSTR-FIL;

LW>>    Sure, 8 characters instead of 12.

d> Mr Willms, the statement you interrupted at the semicolon above
d> contains the phrase of 'it might be easier to find applicable
d> occurrences', how do you conclude that the number of characters
d> relates to the 'applicability' of occurrenct?

   I can't think of any other reason  -- one can enter _any_ string  
into the search command of any editor, but I admit that entering "EMP- 
MSTR-FIL" is more difficult because it contains two dashes instead of  
one, and if I really want to have the upper case being taken into  
account, requires to operate the SHIFT key at least four times. That  
might be an additional reason that searching for 60520-EX is easier  
than this other coarse string.

   So maybe you might this time condescend to explain to the mere  
mortal as I am what other differences might make the searching for or  
the other arbitrary sequences of characters easier than the other?

   BTW, EX makes me think that this is about beer -- Ex is the popular  
abbreviation here in Germany for "Export", a kind of beer different  
from Pils or Alt or K�lsch or others.


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

Es gibt eine wahre und eine f�rmliche Orthographie. -G.C.Lichtenberg
0
l.willms1 (637)
11/7/2004 1:50:00 PM
..    On  06.11.04
  wrote  docdwarf@panix.com
     on  /COMP/LANG/COBOL
     in  cmk1ad$gi0$1@panix5.panix.com
  about  Re: How to process a file


d>>> ... and if there's a reader who looks at that and cannot almost
d>>> viscerally grasp what is going on then I'd be willing to wager said
d>>> reader has fewer than two year's worth of experience.

LW>>   I grasp immediately is that somebody has created a complicated maze
LW>> of trails and scents instead of drawing a simple map for an apparently
LW>> simple data processing task.

d> Mr Willms, how do you know 'an apparently simple data processing task'
d> is being addressed without knowing 'what is going on'?

   The word "apparently" obviously does not pretend to be based on  
_knowledge,_ but on assumptions.

   _You_ challenged the readers to "almost viscerally grasp what is  
going on", and I put my ganutlet in the ring.

  _You_ said that anybody who is not "almost viscerally" grasping  
"what is going on" must be -- in your honorable judgement -- a rookie  
in programming.

   So now you shouldn't turn and tell me that it is impossible to  
"grasp what is going on".

   And I repeat: the pieces of code which you showed reflect a habit  
of relying on descriptions of trails instead of a full map of the  
landscape. And I dare to add, that to have oversight over the  
landscape based on a map is superior to relying solely on descriptions  
of trails with lists of where to turn, und under which conditions.


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

Ein Buch ist ein Spiegel, wenn ein Affe hineinsieht, so kann kein Apostel herausgucken. -G.C.Lichtenberg
0
l.willms1 (637)
11/7/2004 5:08:00 PM
In article <9KRHsOIeflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
>.    On  06.11.04
>  wrote  docdwarf@panix.com
>     on  /COMP/LANG/COBOL
>     in  cmk0p3$g1a$1@panix5.panix.com
>  about  Re: How to process a file
>
>
>
>d>>> I'm not sure about a 'real' difference... but when it comes to
>d>>> slogging through the code it might be easier to find applicable
>d>>> occurrences of 60520-EX instead of looking for EMP-MSTR-FIL;
>
>LW>>    Sure, 8 characters instead of 12.
>
>d> Mr Willms, the statement you interrupted at the semicolon above
>d> contains the phrase of 'it might be easier to find applicable
>d> occurrences', how do you conclude that the number of characters
>d> relates to the 'applicability' of occurrenct?
>
>   I can't think of any other reason  -- one can enter _any_ string  
>into the search command of any editor, but I admit that entering "EMP- 
>MSTR-FIL" is more difficult because it contains two dashes instead of  
>one, and if I really want to have the upper case being taken into  
>account, requires to operate the SHIFT key at least four times. That  
>might be an additional reason that searching for 60520-EX is easier  
>than this other coarse string.

This has to do with 'ease of entry, Mr Willms, not 'ease of finding 
applicable occurrences'.

>
>   So maybe you might this time condescend to explain to the mere  
>mortal as I am what other differences might make the searching for or  
>the other arbitrary sequences of characters easier than the other?

Mr Willms, I got lost in your confusion in your previous posting, that is 
why I suggested 'If you are interested in discussing the matter then I 
would suggest you re-quote the sentences in their entirety and indicate 
where you are having difficulties.'

You've responded to things I have not addressed and you've not re-quoted 
anything so it might be reasonable to conclude that you have no interest 
in discussing the matter.

DD

0
docdwarf (6044)
11/7/2004 11:05:15 PM
In article <9KRHuBiPflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
>.    On  06.11.04
>  wrote  docdwarf@panix.com
>     on  /COMP/LANG/COBOL
>     in  cmk1ad$gi0$1@panix5.panix.com
>  about  Re: How to process a file
>
>
>d>>> ... and if there's a reader who looks at that and cannot almost
>d>>> viscerally grasp what is going on then I'd be willing to wager said
>d>>> reader has fewer than two year's worth of experience.
>
>LW>>   I grasp immediately is that somebody has created a complicated maze
>LW>> of trails and scents instead of drawing a simple map for an apparently
>LW>> simple data processing task.
>
>d> Mr Willms, how do you know 'an apparently simple data processing task'
>d> is being addressed without knowing 'what is going on'?
>
>   The word "apparently" obviously does not pretend to be based on  
>_knowledge,_ but on assumptions.

No, Mr Willms... the word 'apparently' is based on 'appearance', that is 
how I interpreted the use.  If you are intending a different, perhaps 
idiosyncratic, use, then please be so kind as to specify it.

>
>   _You_ challenged the readers to "almost viscerally grasp what is  
>going on", and I put my ganutlet in the ring.

I issued no challenge, Mr Willms, and it is not my habit to issue 
challenges on such things, Mr Willms.  Please do your best to address what 
I have written, not what you wished me to have written.

>
>  _You_ said that anybody who is not "almost viscerally" grasping  
>"what is going on" must be -- in your honorable judgement -- a rookie  
>in programming.

Mr Willms, I stated about my willingness to wager... nothing less, nothing 
more.  Please be so kind as to address what I have written, not what you 
wished me to have written.

>
>   So now you shouldn't turn and tell me that it is impossible to  
>"grasp what is going on".

I have not mentioned the impossibility of anything, Mr Willms; please do 
your best to address what I have written, not what you have wished me to 
have written.

DD

0
docdwarf (6044)
11/7/2004 11:11:41 PM
..    On  07.11.04
  wrote  docdwarf@panix.com
     on  /COMP/LANG/COBOL
     in  cmm9nb$dn4$1@panix5.panix.com
  about  Re: How to process a file


d> Mr Willms, I got lost in your confusion in your previous posting, that
d> is why I suggested 'If you are interested in discussing the matter
d> then I would suggest you re-quote the sentences in their entirety and
d> indicate where you are having difficulties.'
d>
d> You've responded to things I have not addressed and you've not
d> re-quoted anything so it might be reasonable to conclude that you have
d> no interest in discussing the matter.

   The point is, that I just didn't and don't understand what you are  
talking about. I read only about finding some arbitrary strings.

   "Obvious is in the mind of the beholder", you told this audience  
shortly ago. Well, it might be obvious to YOU what you were talking  
about, but obviously not to me.

   So if you would explain me what the matter is in YOUR view, and in  
a way which I can understand, a discussion might begin. .


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

Das ganze Zeitungs-All.  -G.C.Lichtenberg
0
l.willms1 (637)
11/8/2004 7:01:00 AM
In article <9KVN4k1uflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
>.    On  07.11.04
>  wrote  docdwarf@panix.com
>     on  /COMP/LANG/COBOL
>     in  cmm9nb$dn4$1@panix5.panix.com
>  about  Re: How to process a file
>
>
>d> Mr Willms, I got lost in your confusion in your previous posting, that
>d> is why I suggested 'If you are interested in discussing the matter
>d> then I would suggest you re-quote the sentences in their entirety and
>d> indicate where you are having difficulties.'
>d>
>d> You've responded to things I have not addressed and you've not
>d> re-quoted anything so it might be reasonable to conclude that you have
>d> no interest in discussing the matter.
>
>   The point is, that I just didn't and don't understand what you are  
>talking about. I read only about finding some arbitrary strings.

Mr Willms, those 'arbitrary string' were posted, I believe, in complete 
sentences which I suggested that you re-quote in their entirety and 
indicate where you are having difficulties.  I've suggested this twice, so 
far, and you have been unable or unwilling to do so.

>
>   "Obvious is in the mind of the beholder", you told this audience  
>shortly ago. Well, it might be obvious to YOU what you were talking  
>about, but obviously not to me.

This was one of the reasons, Mr Willms, that I've made my suggestion 
repeatedly and concluded from your inability or refusal to attempt to 
implement it a cause to conclude that you have no interest in discussing 
the matter.

>
>   So if you would explain me what the matter is in YOUR view, and in  
>a way which I can understand, a discussion might begin. .

I have already done this, Mr Willms, and when I did so you approached it 
in a manner - mid-sentence interruption - which I have found, at times, to 
be less conducive to an interaction of value than full-sentence 
addressing.  Third and final time then, Mr Willms: 'If you are interested 
in discussing the matter then I would suggest you re-quote the sentences 
in their entirety and indicate where you are having difficulties.'

As mentioned before, your inability or refusal to do so and your 
continuing insistence in addressing things which I have *not* stated might 
make it reasonable to conclude that you have no interest in discussing the 
matter; dialogue is best done with at least two people who have an 
interest in and courtesy about what the others have to express and it 
seems that you have neither.

DD


0
docdwarf (6044)
11/8/2004 10:17:30 AM
..    On  08.11.04
  wrote  docdwarf@panix.com
     on  /COMP/LANG/COBOL
     in  cmnh3q$n4s$1@panix5.panix.com
  about  Re: How to process a file


LW>>   So if you would explain me what the matter is in YOUR view,
LW>> and in a way which I can understand, a discussion might begin. .

d> I have already done this, Mr Willms,

   So I have to die dumb without understanding what you wanted to  
convey.


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

Das ganze Zeitungs-All.  -G.C.Lichtenberg
0
l.willms1 (637)
11/8/2004 11:59:00 AM
On  7-Nov-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

>    I can't think of any other reason  -- one can enter _any_ string
> into the search command of any editor, but I admit that entering "EMP- 
> MSTR-FIL" is more difficult because it contains two dashes instead of
> one, and if I really want to have the upper case being taken into
> account, requires to operate the SHIFT key at least four times. That
> might be an additional reason that searching for 60520-EX is easier
> than this other coarse string.

It's very useful to learn to type effectively.   I can type faster than I should
think anyway.   Typing longer words isn't anymore of a problem than saying
longer words, once I have developed a comfortable level of competence.

I do note that on my keyboard, I do not have to press SHIFT in order to type -.
0
howard (6283)
11/8/2004 4:39:12 PM
..    On  08.11.04
  wrote  howard@brazee.net (Howard Brazee)
     on  /COMP/LANG/COBOL
     in  cmo7fg$r7p$1@peabody.colorado.edu
  about  Re: How to process a file


HB> I do note that on my keyboard, I do not have to press SHIFT in order
HB> to type -.

   Normally I don't have to do it either, but when I use SHIFT-LOCK  
for typing upper case letters, I have to SHIFT to get to the dash.


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

Da liegen nun die Kartoffeln und schlafen ihrer Auferstehung entgegen. -G.C.Lichtenberg
0
l.willms1 (637)
11/8/2004 5:07:00 PM
In article <9KVOOSfeflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
>.    On  08.11.04
>  wrote  docdwarf@panix.com
>     on  /COMP/LANG/COBOL
>     in  cmnh3q$n4s$1@panix5.panix.com
>  about  Re: How to process a file
>
>
>LW>>   So if you would explain me what the matter is in YOUR view,
>LW>> and in a way which I can understand, a discussion might begin. .
>
>d> I have already done this, Mr Willms,
>
>   So I have to die dumb without understanding what you wanted to  
>convey.

Thrice asked and thrice refused, Mr Willms; as the sentence you cut off in 
your reply here stated:

--begin quoted text:

I have already done this, Mr Willms, and when I did so you approached it
in a manner - mid-sentence interruption - which I have found, at times, to
be less conducive to an interaction of value than full-sentence
addressing.  Third and final time then, Mr Willms: 'If you are interested
in discussing the matter then I would suggest you re-quote the sentences
in their entirety and indicate where you are having difficulties.'

--end quoted text

.... so it seems that your prediction of your future is predicated by your 
own actions and nobody else's.  It takes two to converse, Mr Willms, and 
it should be obvious that I am barely able to carry out my own role in 
such matters and cannot, without risk of further misunderstandings, carry 
out the one you seem unable or unwilling to assume.

DD

0
docdwarf (6044)
11/8/2004 6:18:53 PM
On  8-Nov-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

> HB> I do note that on my keyboard, I do not have to press SHIFT in order
> HB> to type -.
>
>    Normally I don't have to do it either, but when I use SHIFT-LOCK
> for typing upper case letters, I have to SHIFT to get to the dash.

Interesting.   I know that there are differences in keyboards designed for
different countries.

MY-CAPS-KEY-IS-LOCKED my-caps-key-is-not-locked.

Caps-lock does not lock special characters for me.
ABCDE1234567890-=[]\;',./`
abcde1234567890-=[]\;',./

Maybe it's a Windows setting.
0
howard (6283)
11/8/2004 8:27:40 PM
l.willms@jpberlin.de (Lueko Willms) wrote 

>    Normally I don't have to do it either, but when I use SHIFT-LOCK  
> for typing upper case letters, I have to SHIFT to get to the dash.

That Shift-Lock seems to be a different functionality than is
available on the keyboards that I commonly use where there is a
Caps-Lock that only upshifts the letters.
0
riplin (4127)
11/8/2004 11:55:38 PM
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9KVOOSfeflB@jpberlin-l.willms.jpberlin.de...
<snip
>
>    So I have to die dumb without understanding what you wanted to
> convey.
>
....or, you could just live with it, Lueko <G>. Failure to understand the Doc
in abstruse mode is something that you are not alone in. I think it has
something to do with those mushrooms Snow White keeps giving him... Life
(and the Doc) go on...

Pete.




0
dashwood1 (2140)
11/9/2004 7:00:50 AM
In article <2vb896F2hsk3rU1@uni-berlin.de>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
>"Lueko Willms" <l.willms@jpberlin.de> wrote in message
>news:9KVOOSfeflB@jpberlin-l.willms.jpberlin.de...
><snip
>>
>>    So I have to die dumb without understanding what you wanted to
>> convey.
>>
>...or, you could just live with it, Lueko <G>. Failure to understand the Doc
>in abstruse mode is something that you are not alone in.

Mr Dashwood, it is one thing to fail to 'understand' me; it might be 
another to thrice refuse a simple request to quote, in complete sentences, 
what it is that one has difficulty with in order that it might be 
discussed.  

'Understanding', as has been noted before, can be seen as a complex 
process or phenomenon; it can be documented in this forum, however, that 
Mr Willms has done nothing more than the latter and because of such his 
condition seems to be of his own making.

DD
0
docdwarf (6044)
11/9/2004 10:32:14 AM
..    On  08.11.04
  wrote  riplin@Azonic.co.nz (Richard)
     on  /COMP/LANG/COBOL
     in  217e491a.0411081555.3cea0bb2@posting.google.com
  about  Re: How to process a file

   answering me:

LW>>    Normally I don't have to do it either, but when I use
LW>> SHIFT-LOCK for typing upper case letters, I have to SHIFT
LW>> to get to the dash.

r> That Shift-Lock seems to be a different functionality than is
r> available on the keyboards that I commonly use where there is a
r> Caps-Lock that only upshifts the letters.

   This depends on the actual keyboard layout and on the language- 
dependent keyboard driver.

   This is a German keyboard with a German keyboard driver. Also, it  
behaves differently on Win98 and WinNT.

   Also, just as an aside, keys like slash ("/") or backslash ("\")  
which are being used a lot in current computer systems, and which are  
on an US-american keyboard in the bottom row, accessible unshifted,  
are accessible on a German keyboard only by pressing two or three keys  
together. Same for scare and curly brackets ("{[]}") or vertical bar  
("|"), which all require the "AltGr" key.

  And unfortunatley, Microsoft eliminated the possibility to use CTRL- 
ALT instaead of AltGr key, so that I have to move with the left hand  
into the keyboard area normally reserved for the right hand.


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

Eine einzige Seele war f�r seinen Leib zu wenig, er h�tte zwoen zu tun genug geben k�nnen. -G.C.Lichtenberg
0
l.willms1 (637)
11/9/2004 10:55:00 AM
On  9-Nov-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

>    This depends on the actual keyboard layout and on the language- 
> dependent keyboard driver.
>
>    This is a German keyboard with a German keyboard driver. Also, it
> behaves differently on Win98 and WinNT.
>
>    Also, just as an aside, keys like slash ("/") or backslash ("\")
> which are being used a lot in current computer systems, and which are
> on an US-american keyboard in the bottom row, accessible unshifted,
> are accessible on a German keyboard only by pressing two or three keys
> together. Same for scare and curly brackets ("{[]}") or vertical bar
> ("|"), which all require the "AltGr" key.
>
>   And unfortunatley, Microsoft eliminated the possibility to use CTRL- 
> ALT instaead of AltGr key, so that I have to move with the left hand
> into the keyboard area normally reserved for the right hand.

I would be surprised if someone hasn't developed a solution for these needs.  
Maybe a bigger keyboard with some programmable keys.  Maybe a software driver.

Googling, I found this discussion:
http://broken.typepad.com/b/2004/02/caps_lock.html
0
howard (6283)
11/9/2004 3:17:25 PM
docdwarf@panix.com wrote 

> Mr Dashwood, it is one thing to fail to 'understand' me; it might be 
> another to thrice refuse a simple request ..

It _might_ be another, or it might be the same.

If he fails to understand that it was a request then it is merely the
same failure to understand, or perhaps a different failure.

> 'Understanding', as has been noted before, can be seen as a complex 
> process or phenomenon; it can be documented in this forum, however, that 
> Mr Willms has done nothing more than the latter and because of such his 
> condition seems to be of his own making.

Ah, so it's _his_ fault that you are obtuse.

In many cases I just give up bothering with your posts, they so seldom
seem worth the effort of unravelling them.
0
riplin (4127)
11/9/2004 6:26:35 PM
In article <217e491a.0411091026.5c500942@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>docdwarf@panix.com wrote 
>
>> Mr Dashwood, it is one thing to fail to 'understand' me; it might be 
>> another to thrice refuse a simple request ..
>
>It _might_ be another, or it might be the same.

Hence the subjunctive, Mr Plinston... wonderful language, this English.

>
>If he fails to understand that it was a request then it is merely the
>same failure to understand, or perhaps a different failure.

If he fails to understand a request, thrice repeated, of 'If you are 
interested in discussing the matter then I would suggest you re-quote the 
sentences in their entirety and indicate where you are having 
difficulties.' and does not mention such, Mr Plinston, then I have no 
explicit way to be aware of or address his failure.

>
>> 'Understanding', as has been noted before, can be seen as a complex 
>> process or phenomenon; it can be documented in this forum, however, that 
>> Mr Willms has done nothing more than the latter and because of such his 
>> condition seems to be of his own making.
>
>Ah, so it's _his_ fault that you are obtuse.

No, Mr Plinston, it is his fault that, when it is repeatedly requested of 
him, he does not re-quote sentences in their entirety and indicate where 
it is he is having difficulties.  I have repeatedly asked that he do so 
and he has shown himself to be unable or unwilling to do so.  There is 
only so long one can put up with the equivalent of

'I don't understand this!'

'Please quote what you do not understand and indicate where you are having 
difficulties.'

'I still don't understand this!'

'You have not shown what it is that you do not understand, please quote 
what you do not understand and indicate where you have having 
difficulties.'

'You aren't making sense!'

'You have not shown what it is that you do not understand, please quote... 
etc.'

.... and, for my part, I try to follow the Classic Rule of 'Thrice asked, 
thrice refused, no more needs be said.'

>
>In many cases I just give up bothering with your posts, they so seldom
>seem worth the effort of unravelling them.

One does as one sees fit, Mr Plinston, and one gains or misses, in part, 
because of this; if there is something that you do not understand then I 
would suggest that you re-quote the sentences in their entirety and 
indicate where you are having difficulties.  In my experience genuine 
interest frequently begets genuine efforts... but what do I know?

DD

0
docdwarf (6044)
11/9/2004 7:11:27 PM
<docdwarf@panix.com> wrote in message news:cmq6be$hit$1@panix5.panix.com...
> In article <2vb896F2hsk3rU1@uni-berlin.de>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
> >
I know better than to take sides here, Doc.

But, knowing that deep down you are not ungenerous of spirit, could I offer
the following for your consideration?

1. Although Lueko demonstrates a commendable mastery of English, it is NOT
his first language... (I seem to recall some American friends using an
expression involving severance in a non-tensioned rope...?)

2. Despite my personal mastery of the English language (it being the
foremost of the four which I speak), I also could not quite get from your
post exactly what you were requiring....

I'm sure you'll give my suggestion the consideration it deserves <G>

Pete.



0
dashwood1 (2140)
11/10/2004 10:06:46 AM
In article <2ve7hrF2jibqnU1@uni-berlin.de>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:cmq6be$hit$1@panix5.panix.com...
>> In article <2vb896F2hsk3rU1@uni-berlin.de>,
>> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>> >
>I know better than to take sides here, Doc.
>
>But, knowing that deep down you are not ungenerous of spirit, could I offer
>the following for your consideration?
>
>1. Although Lueko demonstrates a commendable mastery of English, it is NOT
>his first language... (I seem to recall some American friends using an
>expression involving severance in a non-tensioned rope...?)

I am well aware of this, Mr Dashwood, and it figured into my reasoning 
behind the request I made of him.

>
>2. Despite my personal mastery of the English language (it being the
>foremost of the four which I speak), I also could not quite get from your
>post exactly what you were requiring....

Mr Dashwood, what follows is from an earlier posting in this thread, and 
is my response to one of Mr Willms statements:

--begin quoted text:

>   The point is, that I just didn't and don't understand what you are
>talking about. I read only about finding some arbitrary strings.

Mr Willms, those 'arbitrary string' were posted, I believe, in complete
sentences which I suggested that you re-quote in their entirety and
indicate where you are having difficulties.  I've suggested this twice, so
far, and you have been unable or unwilling to do so.

--end quoted text

As I read the above: Mr Willms states that he finds no coherence in what I 
have posted, just 'some arbitrary strings'.

I reply that what he responded to were, by his editing, sentence 
fragments and that I have suggested - repeatedly - that he quote the 
complete sentences in which they occurred and indicate where he is having 
difficulties.

In the next sentence I state that I have suggested this twice and that he 
has shown himself unable or unwilling to do so.

Now in my experience of the thread Mr Willms has, repeatedly, responded to 
sentence-fragments of his own creating; when it is pointed out that the 
creating of these fragments might be what is causing his confusion, and 
that this confusion might be resolved by quoting the sentences in their 
entirety and indicating where his confusion lies... he has done nothing.

I've asked three times and been refused three times; thrice asked, thrice 
refused, no more needs be said.

>
>I'm sure you'll give my suggestion the consideration it deserves <G>

My actions appear to bear our your certainty, Mr Dashwood... it can be 
seen as a world of remarkable coincidences, aye.

DD

0
docdwarf (6044)
11/10/2004 10:34:27 AM
Lueko,

The Doc has spelled it out below, but the short version is:

When you are responding to his posts, don't split his sentences, then
complain about 'incoherence'.

Wenn Sie seinen Posten antworten, teilen Sie seine S�tze nicht, und klagen
Sie dann �ber Zusammenhanglosigkeit.

(I'm not saying you did or you didn't... just something to be aware of...)

Pete.
<docdwarf@panix.com> wrote in message news:cmsqrj$5d2$1@panix5.panix.com...
> In article <2ve7hrF2jibqnU1@uni-berlin.de>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
> >
> ><docdwarf@panix.com> wrote in message
news:cmq6be$hit$1@panix5.panix.com...
> >> In article <2vb896F2hsk3rU1@uni-berlin.de>,
> >> Pete Dashwood <dashwood@enternet.co.nz> wrote:
> >> >
> >I know better than to take sides here, Doc.
> >
> >But, knowing that deep down you are not ungenerous of spirit, could I
offer
> >the following for your consideration?
> >
> >1. Although Lueko demonstrates a commendable mastery of English, it is
NOT
> >his first language... (I seem to recall some American friends using an
> >expression involving severance in a non-tensioned rope...?)
>
> I am well aware of this, Mr Dashwood, and it figured into my reasoning
> behind the request I made of him.
>
> >
> >2. Despite my personal mastery of the English language (it being the
> >foremost of the four which I speak), I also could not quite get from your
> >post exactly what you were requiring....
>
> Mr Dashwood, what follows is from an earlier posting in this thread, and
> is my response to one of Mr Willms statements:
>
> --begin quoted text:
>
> >   The point is, that I just didn't and don't understand what you are
> >talking about. I read only about finding some arbitrary strings.
>
> Mr Willms, those 'arbitrary string' were posted, I believe, in complete
> sentences which I suggested that you re-quote in their entirety and
> indicate where you are having difficulties.  I've suggested this twice, so
> far, and you have been unable or unwilling to do so.
>
> --end quoted text
>
> As I read the above: Mr Willms states that he finds no coherence in what I
> have posted, just 'some arbitrary strings'.
>
> I reply that what he responded to were, by his editing, sentence
> fragments and that I have suggested - repeatedly - that he quote the
> complete sentences in which they occurred and indicate where he is having
> difficulties.
>
> In the next sentence I state that I have suggested this twice and that he
> has shown himself unable or unwilling to do so.
>
> Now in my experience of the thread Mr Willms has, repeatedly, responded to
> sentence-fragments of his own creating; when it is pointed out that the
> creating of these fragments might be what is causing his confusion, and
> that this confusion might be resolved by quoting the sentences in their
> entirety and indicating where his confusion lies... he has done nothing.
>
> I've asked three times and been refused three times; thrice asked, thrice
> refused, no more needs be said.
>
> >
> >I'm sure you'll give my suggestion the consideration it deserves <G>
>
> My actions appear to bear our your certainty, Mr Dashwood... it can be
> seen as a world of remarkable coincidences, aye.
>
> DD
>
>



0
dashwood1 (2140)
11/11/2004 11:34:00 AM
Reply:

Similar Artilces:

Off Topic [Off Topic]
I have to admit that I somehow admire the persistance of those that can post some 250 off topic comments in a newsgroup in a two week span! -- James L. Ryan -- TaliesinSoft ...

On Topic : Cobol question.
Hi all,=20 We have been regularly using the FUNCTION CURRENT-DATE in COBOL to fetch = the runtime date and time inside the cobol programs as listed below :=20 MOVE FUNCTION CURRENT-DATE TO WS-CURRENT-DATE-TIME. However, I could not find any information related to extracting current = date in Julian format (YYDDD). Is there anything directly that can be = achieved from this FUNCTION or any other function ? My only alternative so far is = to code a logic for converting above Gregorian to Julian date format and = then use in the COBOL program.=20 Any help is ...

Slightly off-topic topic
Hi, I wanted to know how actually a database converter works. I am working on a converter from DBF to MS SQL server 2000 using Visual Basic 6.0. I wanted to know that once a legacy database is enterd in the program, how does it get normalised. I have aboout 40 tables in DBASE IV format. I want to convert them into relational database and store them on server. But on conversion, how can the converted data be normalised by itself. Awaiting the replies, Thanks Shwetabh wrote: > Hi, > I wanted to know how actually a database converter works. > I am working on a converter from DBF to MS...

Re: On Topic : Cobol question.
Your question: However, I could not find any information related to extracting current date in Julian format (YYDDD). Is there anything directly that can be achieved from this FUNCTION or any other function ? My only alternative so far is to code a logic for converting above Gregorian to Julian date format and then use in the COBOL program. ,,,,,, To get the date format of julian or gregorian ...The hpdateconvert intrinsic can be used. http://docs.hp.com/en/32650-90875/ch07s09.html Sample code for this can be found in itrc, KBRC00015373 You can also use: INTEGER-OF-DATE a...

Re: On Topic : Cobol question. #3
Thanks to everybody who responded.=20 Cathlene's suggested trick worked and now I am able to get the Julian = date in the format that I was looking for inside the cobol program itself. = Thanks again.=20 Raghu Rao Preferred Care - IS=20 -----Original Message----- From: Cathlene Mc Rae [mailto:cathlene_mcrae@HP.COM]=20 Sent: Tuesday, July 05, 2005 4:54 PM To: HP3000-L@RAVEN.UTC.EDU Subject: Re: [HP3000-L] On Topic : Cobol question. Your question: However, I could not find any information related to extracting current = date in Julian format (YYDDD). Is there ...

Re: On Topic : Cobol question. #2
Hi, Take a look at the INTEGER-OF-DAY and DAY-OF-INTEGER functions along with = the INTEGER-OF-DATE and DATE-OF-INTEGER functions. http://docs.hp.com/cgi-bin/doc3k/B3150090013.11820/126 http://d