From Newsgroup: comp.lang.cobol

On 28/08/2016 6:01 a.m., Norman Worth wrote:

Peter E.C. Dashwood wrote:

"William M. Klein" <wmklein@ix.netcom.com> wrote in message
news:beif33$87e$1@slb3.atl.mindspring.net...

I'll respond in more detail, but it seems to me that there is SOME

confusion

in Pete's note between his use of

"mainframe"
versus
"IBM mainframe"

I have MINIMAL experience outside the IBM MVS-OS/390-z/OS
environments (a
little VM, but no VSE - much less NON-IBM mainframes). Whether all of
Pete's note is INTENDED to apply to all "proprietary mainframes" or JUST >>> IBM's - isn't clear to me.

Would it make any difference, Bill <G>?

It is an attitude of mind that I refer to as Fortress COBOL. It is almost
like a "siege mentality"...

I have found it to be prevalent on IBM installations but they are not
exclusive in their use of it.

Neither am I looking for "exclusions" on the basis of "Well, that can't
apply to us because we're <whatever>"

The goal here is to try and isolate the factors that lead to the
development
of the Fortress Mentality.

Understand WHY it is so.

Pete.

(Sorry about delayed response to this; I have had a lot on my plate and
little time for CLC. Hope to remedy that in the coming year.)

COBOL is still around because it makes a certain class of computing
problems much easier for the programmer and the solutions much more
reliable and portable for the user.

I don't think so.

It makes a certain class of problems easier for people who are COBOL programmers. COBOL is no more reliable and/or portable than most other languages.

>Things like built in indexed files,

An obsolete form of data storage that means you have to write a COBOL
program every time you need to access the data, and your data resource
is not available to other standard software and packages. Hardly
surprising the world voted with its feet and went for something with a standard interface that is accessible (RDBMS).

BTW, after many years of developing expertise in various RDBMS I have
come to realize that Embedded SQL is not much better than using an
indexed file, in terms of accessibility. ESQL locks you in, just as
indexed datasets do. The best solution, in my opinion, is a data access
layer (DAL) where all of the data management nonsense proceeds apart
from the business logic, and data requirements, structures, and formats
can be changed without impacting your existing applications.

(I am SO persuaded by this idea that I spent a couple of years
developing code that can generate this layer automatically, from the
existing COBOL source book definitions (SELECTs/FD/01s...)

If you manage this layer with generated LINQ (rather than ESQL) you can
get something elegant, fast and virtually future proof. And it is a
mouse click to build it. (Aside: These days I use LINQ to access
ANYTHING that needs to be searched or accessed: RDBs, in memory tables
and collections, external XML datasets... the syntax is the same and is
a universal data manipulation language. I could join in-memory tables
with an XML file and a RDB, if I wanted to. It is simple, efficient, and incredibly powerful; a quantum leap above ESQL...)

Access to the repository is open to anything that can instance a DAL
object (and has the necessary permissions, of course).

guaranteed numeric precision even when converting between several
different numeric representations, and business oriented numeric
formatting simply do not exist in other languages.

Sorry, that statement shows a woeful lack of knowledge of "other
languages". Sure, it may be necessary to access extended Classes,
libraries or functions, but the languages that support Object
Orientation make that very easy. For example, everything you mentioned
is easily available in C# by the use of standard or extended classes
designed to deal with it.

For someone who

understands the language, programs can be very clearly written and
followed, making for better reliability and easier maintenance. (If the writer doesn't not truly understand the language, heaven help the maintainer.)

Back in the 1960s, when computer programming was the domain of computer programmers, Salesmen sold COBOL to nervous bean counters based on its "English-like" propensity. "Look, you can read it like English; you can
see what they're doing..."

ANY computer programming language that is well understood by the writer
can be "very clearly written and followed". Good programmers document
what they do in ANY language. I don't understand APL, for instance; to
me it is incomprehensible, but to an APL programmer it is an open book.

If you want to maintain code in a certain language, a wise step might be
to learn that language before you start... True for COBOL; true for
anything.



I remember a very long time ago when I was in graduate

school taking a computing theory class. We would frequently be
discussing some fairly common data problem that would get really hairy
in LISP or Algol (sometimes we would even consider FORTRAN), but COBOL offered a very simple construct to solve the problem - like IF NUMERIC (A).

Yes, COBOL DOES have some really nice features in it, but I don't
believe the reason it is still in use is because of those features.

COBOL is "still around" because of a number of factors, most of which
have little to do with the language intrinsically.

Here are just some of them:

1. People get emotionally tied to COBOL after using it for a while. I am
no exception; I have a "soft spot" for COBOL :-) but I don't let that
blind me to the realities of the world.

2. COBOL is ideally suited as a language for batch processing (which is
all there was when it was invented.). Many Corporations find batch
processing a good way to handle huge transaction volumes so COBOL makes perfect sense for them. (By contrast, smaller organizations rely on a networked data driven model that is reacting in real time with little requirement for batch processing. The repository models the business at
any given moment. The only "batch" requirement would be reporting, and
that is done by background tasks which crawl the repository much like
spiders and bots do on the Web. I can't remember the last time I
designed a system that had batch processing in it...)

3. There is inertia and fear of change in many organizations. ("We've
always done it in COBOL, why fix something that isn't broken?" or
"Everything we need to do we can do in COBOL..."). The vision is
limited, the world changes and ways of doing business change. Suddenly,
COBOL is NOT the best choice any more. And programmers who failed to
expand their skill sets beyond COBOL are out of a job.

4. Compiler vendors have a very large vested interest in keeping COBOL
alive and they are doing a very good job of it. (This industry of "COBOL support" is multi-billion dollar even though it is declining as people
wake up and leave the traditional carousel. COBOL will be with us for
some time yet, but only in limited niches. Meanwhile, vendors will talk
up COBOL as the panacea for all commercial programming and there is some
truth in the points they make.)

5. Management generally don't care what language is used. Their concern (correctly...) is being able to get people who can maintain it and the perception is that all the COBOL programmers are dying off. (Some of us
reckon we ain't, but y' know what lyin' bastards them COBOL programmers are...) They stick with COBOL in the interim and devise strategies for
moving off it long term, largely driven by the price differential
between Networked systems and mainframes. It is interesting to me to
note that over the years this differential has slowly been reduced and
it is true that the current cost of maintaining a mainframe site in real terms, is probably no more than it was 30 years ago. Ironically, this
has been brought about by other options being available where once they
never were.

OK, the above is an arguable, on-topic post.

I coined the term "Fortress COBOL" because of the distrust and suspicion
that anything which threatened the use of COBOL was viewed with during
the last years of the previous century. There was a certain arrogance
amongst some programmers also, and I heard phrases like: "How do they
expect to run a business with toy computers?" "We've seen it all before; Object Oriented programming is just modular programming re-invented.
It's a fad and it'll pass...".

They watched from the ramparts of their fortresses as the Barbarians on
their lighter and fleeter ponies swept past them and made them obsolete.

There is no progress without change.

Pete.
--
I used to write COBOL; now I can do anything...

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

In article <ebed1bFp2jpU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

[snip]

Many Corporations find batch
processing a good way to handle huge transaction volumes so COBOL makes >perfect sense for them. (By contrast, smaller organizations rely on a >networked data driven model that is reacting in real time with little >requirement for batch processing. The repository models the business at
any given moment. The only "batch" requirement would be reporting, and
that is done by background tasks which crawl the repository much like >spiders and bots do on the Web. I can't remember the last time I
designed a system that had batch processing in it...)

You've stated sentiments like these before, Mr Dashwood, and they've been demonstrated to be incorrect. Remember a story about a truck being
dispensed to deliver a single loaf of bread?

A ship-load is a batch. Pipeline flow over time is a batch. A dollar
bill is a batch. If one processes hours as seconds - an hour is a batch -
the results might be less than edifying.

Consider an organisation as an organism. All organisms use energy
constantly (if only to maintain their structures) but only the simplest organisms consume food constantly; a meal is a batch of fuel. All
organisms need periods of rest; sleep is batch-resting.

'Everything is real-time' is as facile - and as wrong - as 'everything is batch'.

'He who thinks all fruits ripen the same time as strawberries knows
nothing of grapes.' - Paracelsus

DD

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 15/12/2016 4:37 p.m., docdwarf@panix.com wrote:

In article <ebed1bFp2jpU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

[snip]

Many Corporations find batch
processing a good way to handle huge transaction volumes so COBOL makes
perfect sense for them. (By contrast, smaller organizations rely on a
networked data driven model that is reacting in real time with little
requirement for batch processing. The repository models the business at
any given moment. The only "batch" requirement would be reporting, and
that is done by background tasks which crawl the repository much like
spiders and bots do on the Web. I can't remember the last time I
designed a system that had batch processing in it...)

You've stated sentiments like these before, Mr Dashwood, and they've been demonstrated to be incorrect.

I don't think so. Perhaps we simply agreed to disagree.

Remember a story about a truck being

dispensed to deliver a single loaf of bread?

Spoken as one who truly has never grasped interrupt driven systems.

The whole paradigm between batch and online processing is different.

Fundamentally, if the program controls what happens, usually through a processing loop, then it's batch.

1. Get something.
2. process it.
3. go to 1 and see if we've finished... etc.

So the NUMBER of loaves (as in your truck example), is irrelevant.

"Hey Joey, load your truck with as much of this bread as you can carry,
take it over to Louie's, and they will be waiting to unload it. Repeat
until all the bread is delivered."

Joey takes his load to Louie's, where Louie is waiting in the dock.
Louie's life revolves around Joey's deliveries; he does nothing else...


The process continues until all the loaves have been delivered and it is controlled by the truck being programmed to deliver loaves until there
aren't any more.

However, if the program does NOT control what happens, but instead, is
aroused as events occur, then it ISN'T batch.

"Hey Louie, a truck just pulled up outside..."
"OK, guess we better get the bread off it, then get back to watching TV..."

A ship-load is a batch.

It can be...

Pipeline flow over time is a batch.
It can be...
A dollar

bill is a batch.

Not if you only have one of them...


If one processes hours as seconds - an hour is a batch -

"If you call a tail a leg, how many legs does a horse have..." Honest Abe.

the results might be less than edifying.

Certainly true for both batch and non-batch processing that is poorly
designed and implemented.

Consider an organisation as an organism. All organisms use energy
constantly (if only to maintain their structures) but only the simplest organisms consume food constantly; a meal is a batch of fuel. All
organisms need periods of rest; sleep is batch-resting.

Too obtuse to comment on...

'Everything is real-time' is as facile - and as wrong - as 'everything is batch'.

I don't recall ever saying, anywhere, that "everything is <whatever>" I
am well aware of the logical fallacy surrounding sweeping statements.

'He who thinks all fruits ripen the same time as strawberries knows
nothing of grapes.' - Paracelsus

Not sure of your point.

Perhaps we better agree to disagree again... :-)

Pete.
--
I used to write COBOL; now I can do anything...

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

In article <ebhbmbFg8fsU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 15/12/2016 4:37 p.m., docdwarf@panix.com wrote:

In article <ebed1bFp2jpU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

[snip]

Many Corporations find batch
processing a good way to handle huge transaction volumes so COBOL makes
perfect sense for them. (By contrast, smaller organizations rely on a
networked data driven model that is reacting in real time with little
requirement for batch processing. The repository models the business at
any given moment. The only "batch" requirement would be reporting, and
that is done by background tasks which crawl the repository much like
spiders and bots do on the Web. I can't remember the last time I
designed a system that had batch processing in it...)

You've stated sentiments like these before, Mr Dashwood, and they've been
demonstrated to be incorrect.

I don't think so. Perhaps we simply agreed to disagree.

What you think, Mr Dashwood, is made bvious by your incorrect statement;
it is not my habit to agree with such.

Remember a story about a truck being

dispensed to deliver a single loaf of bread?

Spoken as one who truly has never grasped interrupt driven systems.

Mr Dashwood, when you can truly grasp your own graspings it might be more
fit to speak of those of others.

The whole paradigm between batch and online processing is different.

Fundamentally, if the program controls what happens, usually through a >processing loop, then it's batch.

This is incorrect, Mr Dahwood, and it indicates a cause-by-definition for further incorrect conclusions.

A batch is more-than-one of something. Keep this firnly in mind.

1. Get something.
2. process it.
3. go to 1 and see if we've finished... etc.

This is online processing as well, Mr Dashwood. Have you never seen the data-entry girls entering orders?

Each order is an occurrence. A stack of orders is a batch.

So the NUMBER of loaves (as in your truck example), is irrelevant.

"Hey Joey, load your truck with as much of this bread as you can carry,
take it over to Louie's, and they will be waiting to unload it. Repeat
until all the bread is delivered."

This is not my example, Mr Dashwood. It is no wonder irrelevance is found
in it.

[snip]

However, if the program does NOT control what happens, but instead, is >aroused as events occur, then it ISN'T batch.

Programs interact with the world around them, Mr Dashwood, and vice-versa. Events drive code which drives events which drivve code, just as Art
imitates Life imitates Art imitates Life. The machine is part of he
world, not a world of its own.

[snip]

A ship-load is a batch.

It can be...

Someone participating in this newsgroup wrote a system for cargo-control
in MicroFocus COBOL and this was what I had in mind. How can it be
proposed to load or unload a ship-load otherwose.

Pipeline flow over time is a batch.
It can be...

This is equally as incorrect, Mr Dashwood, and unseemly for a greybeard.

A dollar

bill is a batch.

Not if you only have one of them...

Is there no room in this view for... evven small change?

[snip]

Consider an organisation as an organism. All organisms use energy
constantly (if only to maintain their structures) but only the simplest
organisms consume food constantly; a meal is a batch of fuel. All
organisms need periods of rest; sleep is batch-resting.

Too obtuse to comment on...

What do you not see clearly? Name a function of an organisation and let
us consider it.

[snip]

'He who thinks all fruits ripen the same time as strawberries knows
nothing of grapes.' - Paracelsus

Not sure of your point.

My point is that batch processing is as necessitated by the functions of a business as transactional processing

Perhaps we better agree to disagree again... :-)

We never agreed to such a thing previously, Mr Dashwood. Your view is incorrect and it has been clearly and unambiguously demonstrated as such; plaints of 'maybe it isn't' and 'this is hard to understand' don't
buttress your argument.

DD

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 17/12/2016 6:05 a.m., docdwarf@panix.com wrote:

In article <ebhbmbFg8fsU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 15/12/2016 4:37 p.m., docdwarf@panix.com wrote:

In article <ebed1bFp2jpU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

[snip]

Many Corporations find batch
processing a good way to handle huge transaction volumes so COBOL makes >>>> perfect sense for them. (By contrast, smaller organizations rely on a
networked data driven model that is reacting in real time with little
requirement for batch processing. The repository models the business at >>>> any given moment. The only "batch" requirement would be reporting, and >>>> that is done by background tasks which crawl the repository much like
spiders and bots do on the Web. I can't remember the last time I
designed a system that had batch processing in it...)

You've stated sentiments like these before, Mr Dashwood, and they've been >>> demonstrated to be incorrect.

I don't think so. Perhaps we simply agreed to disagree.

What you think, Mr Dashwood, is made bvious by your incorrect statement;
it is not my habit to agree with such.

Remember a story about a truck being

dispensed to deliver a single loaf of bread?

Spoken as one who truly has never grasped interrupt driven systems.

Mr Dashwood, when you can truly grasp your own graspings it might be more
fit to speak of those of others.

The whole paradigm between batch and online processing is different.

Fundamentally, if the program controls what happens, usually through a
processing loop, then it's batch.

This is incorrect, Mr Dahwood, and it indicates a cause-by-definition for further incorrect conclusions.

A batch is more-than-one of something. Keep this firnly in mind.

1. Get something.
2. process it.
3. go to 1 and see if we've finished... etc.

This is online processing as well, Mr Dashwood. Have you never seen the data-entry girls entering orders?

Each order is an occurrence. A stack of orders is a batch.

So the NUMBER of loaves (as in your truck example), is irrelevant.

"Hey Joey, load your truck with as much of this bread as you can carry,
take it over to Louie's, and they will be waiting to unload it. Repeat
until all the bread is delivered."

This is not my example, Mr Dashwood. It is no wonder irrelevance is found
in it.

[snip]

However, if the program does NOT control what happens, but instead, is
aroused as events occur, then it ISN'T batch.

Programs interact with the world around them, Mr Dashwood, and vice-versa. Events drive code which drives events which drivve code, just as Art
imitates Life imitates Art imitates Life. The machine is part of he
world, not a world of its own.

[snip]

A ship-load is a batch.

It can be...

Someone participating in this newsgroup wrote a system for cargo-control
in MicroFocus COBOL and this was what I had in mind. How can it be
proposed to load or unload a ship-load otherwose.

Pipeline flow over time is a batch.
It can be...

This is equally as incorrect, Mr Dashwood, and unseemly for a greybeard.

A dollar

bill is a batch.

Not if you only have one of them...

Is there no room in this view for... evven small change?

[snip]

Consider an organisation as an organism. All organisms use energy
constantly (if only to maintain their structures) but only the simplest
organisms consume food constantly; a meal is a batch of fuel. All
organisms need periods of rest; sleep is batch-resting.

Too obtuse to comment on...

What do you not see clearly? Name a function of an organisation and let
us consider it.

[snip]

'He who thinks all fruits ripen the same time as strawberries knows
nothing of grapes.' - Paracelsus

Not sure of your point.

My point is that batch processing is as necessitated by the functions of a business as transactional processing

And mine is that that MAY be so for SOME businesses.

(Be careful before you respond; you don't really want to say that ALL businesses need both batch and transactional processing... You might
struggle to do batch processing on an iPhone, for example, and yet it
has the capability to access vast stores of information...)

Perhaps we better agree to disagree again... :-)

We never agreed to such a thing previously, Mr Dashwood. Your view is incorrect and it has been clearly and unambiguously demonstrated as such;

No, it hasn't. You saying it is so, does not make it so.

However, as I see no minds will be changed here or compromises reached,
I'm happy to let you have the last word and move on to more important things...

Merry Xmas!

Pete
--
I used to write COBOL; now I can do anything...

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On Saturday, 17 December 2016 18:49:19 UTC+10, pete dashwood wrote:

On 17/12/2016 6:05 a.m., docdwarf@panix.com wrote:

In article <ebhbmbFg8fsU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 15/12/2016 4:37 p.m., docdwarf@panix.com wrote:

In article <ebed1bFp2jpU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

[snip]

Many Corporations find batch
processing a good way to handle huge transaction volumes so COBOL makes >>>> perfect sense for them. (By contrast, smaller organizations rely on a >>>> networked data driven model that is reacting in real time with little >>>> requirement for batch processing. The repository models the business at >>>> any given moment. The only "batch" requirement would be reporting, and >>>> that is done by background tasks which crawl the repository much like >>>> spiders and bots do on the Web. I can't remember the last time I
designed a system that had batch processing in it...)

You've stated sentiments like these before, Mr Dashwood, and they've been >>> demonstrated to be incorrect.

I don't think so. Perhaps we simply agreed to disagree.

What you think, Mr Dashwood, is made bvious by your incorrect statement;
it is not my habit to agree with such.

Remember a story about a truck being

dispensed to deliver a single loaf of bread?

Spoken as one who truly has never grasped interrupt driven systems.

Mr Dashwood, when you can truly grasp your own graspings it might be more fit to speak of those of others.

The whole paradigm between batch and online processing is different.

Fundamentally, if the program controls what happens, usually through a
processing loop, then it's batch.

This is incorrect, Mr Dahwood, and it indicates a cause-by-definition for further incorrect conclusions.

A batch is more-than-one of something. Keep this firnly in mind.

1. Get something.
2. process it.
3. go to 1 and see if we've finished... etc.

This is online processing as well, Mr Dashwood. Have you never seen the data-entry girls entering orders?

Each order is an occurrence. A stack of orders is a batch.

So the NUMBER of loaves (as in your truck example), is irrelevant.

"Hey Joey, load your truck with as much of this bread as you can carry,
take it over to Louie's, and they will be waiting to unload it. Repeat
until all the bread is delivered."

This is not my example, Mr Dashwood. It is no wonder irrelevance is found in it.

[snip]

However, if the program does NOT control what happens, but instead, is
aroused as events occur, then it ISN'T batch.

Programs interact with the world around them, Mr Dashwood, and vice-versa. Events drive code which drives events which drivve code, just as Art imitates Life imitates Art imitates Life. The machine is part of he
world, not a world of its own.

[snip]

A ship-load is a batch.

It can be...

Someone participating in this newsgroup wrote a system for cargo-control
in MicroFocus COBOL and this was what I had in mind. How can it be proposed to load or unload a ship-load otherwose.

Pipeline flow over time is a batch.
It can be...

This is equally as incorrect, Mr Dashwood, and unseemly for a greybeard..

A dollar

bill is a batch.

Not if you only have one of them...

Is there no room in this view for... evven small change?

[snip]

Consider an organisation as an organism. All organisms use energy
constantly (if only to maintain their structures) but only the simplest >>> organisms consume food constantly; a meal is a batch of fuel. All
organisms need periods of rest; sleep is batch-resting.

Too obtuse to comment on...

What do you not see clearly? Name a function of an organisation and let
us consider it.

[snip]

'He who thinks all fruits ripen the same time as strawberries knows
nothing of grapes.' - Paracelsus

Not sure of your point.

My point is that batch processing is as necessitated by the functions of a business as transactional processing

And mine is that that MAY be so for SOME businesses.

(Be careful before you respond; you don't really want to say that ALL businesses need both batch and transactional processing... You might struggle to do batch processing on an iPhone, for example, and yet it
has the capability to access vast stores of information...)

Perhaps we better agree to disagree again... :-)

We never agreed to such a thing previously, Mr Dashwood. Your view is incorrect and it has been clearly and unambiguously demonstrated as such;

No, it hasn't. You saying it is so, does not make it so.

However, as I see no minds will be changed here or compromises reached,
I'm happy to let you have the last word and move on to more important things...

Merry Xmas!

Pete
--
I used to write COBOL; now I can do anything...

As someone who has progressed from Batch to Interactive, I still seem to see batch processing as part of the picture. So if you can upload a batch (file) of
transactions from say a CSV file then this is batch processing and can be very modern. At the same time, one has real time or interactive transactions. So I don't like the idea of batch processing being limited to the very older idea where all input was by Batch.
Merry Christmas
Greg

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 19/12/2016 6:26 a.m., Greg Wallace wrote:

On Saturday, 17 December 2016 18:49:19 UTC+10, pete dashwood wrote:

On 17/12/2016 6:05 a.m., docdwarf@panix.com wrote:

In article <ebhbmbFg8fsU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 15/12/2016 4:37 p.m., docdwarf@panix.com wrote:

In article <ebed1bFp2jpU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

[snip]

Many Corporations find batch
processing a good way to handle huge transaction volumes so COBOL makes >>>>>> perfect sense for them. (By contrast, smaller organizations rely on a >>>>>> networked data driven model that is reacting in real time with little >>>>>> requirement for batch processing. The repository models the business at >>>>>> any given moment. The only "batch" requirement would be reporting, and >>>>>> that is done by background tasks which crawl the repository much like >>>>>> spiders and bots do on the Web. I can't remember the last time I
designed a system that had batch processing in it...)

You've stated sentiments like these before, Mr Dashwood, and they've been >>>>> demonstrated to be incorrect.

I don't think so. Perhaps we simply agreed to disagree.

What you think, Mr Dashwood, is made bvious by your incorrect statement; >>> it is not my habit to agree with such.

Remember a story about a truck being

dispensed to deliver a single loaf of bread?

Spoken as one who truly has never grasped interrupt driven systems.

Mr Dashwood, when you can truly grasp your own graspings it might be more >>> fit to speak of those of others.

The whole paradigm between batch and online processing is different.

Fundamentally, if the program controls what happens, usually through a >>>> processing loop, then it's batch.

This is incorrect, Mr Dahwood, and it indicates a cause-by-definition for >>> further incorrect conclusions.

A batch is more-than-one of something. Keep this firnly in mind.

1. Get something.
2. process it.
3. go to 1 and see if we've finished... etc.

This is online processing as well, Mr Dashwood. Have you never seen the >>> data-entry girls entering orders?

Each order is an occurrence. A stack of orders is a batch.

So the NUMBER of loaves (as in your truck example), is irrelevant.

"Hey Joey, load your truck with as much of this bread as you can carry, >>>> take it over to Louie's, and they will be waiting to unload it. Repeat >>>> until all the bread is delivered."

This is not my example, Mr Dashwood. It is no wonder irrelevance is found >>> in it.

[snip]

However, if the program does NOT control what happens, but instead, is >>>> aroused as events occur, then it ISN'T batch.

Programs interact with the world around them, Mr Dashwood, and vice-versa. >>> Events drive code which drives events which drivve code, just as Art
imitates Life imitates Art imitates Life. The machine is part of he
world, not a world of its own.

[snip]

A ship-load is a batch.

It can be...

Someone participating in this newsgroup wrote a system for cargo-control >>> in MicroFocus COBOL and this was what I had in mind. How can it be
proposed to load or unload a ship-load otherwose.

Pipeline flow over time is a batch.
It can be...

This is equally as incorrect, Mr Dashwood, and unseemly for a greybeard. >>>

A dollar

bill is a batch.

Not if you only have one of them...

Is there no room in this view for... evven small change?

[snip]

Consider an organisation as an organism. All organisms use energy
constantly (if only to maintain their structures) but only the simplest >>>>> organisms consume food constantly; a meal is a batch of fuel. All
organisms need periods of rest; sleep is batch-resting.

Too obtuse to comment on...

What do you not see clearly? Name a function of an organisation and let >>> us consider it.

[snip]

'He who thinks all fruits ripen the same time as strawberries knows
nothing of grapes.' - Paracelsus

Not sure of your point.

My point is that batch processing is as necessitated by the functions of a >>> business as transactional processing

And mine is that that MAY be so for SOME businesses.

(Be careful before you respond; you don't really want to say that ALL
businesses need both batch and transactional processing... You might
struggle to do batch processing on an iPhone, for example, and yet it
has the capability to access vast stores of information...)

Perhaps we better agree to disagree again... :-)

We never agreed to such a thing previously, Mr Dashwood. Your view is
incorrect and it has been clearly and unambiguously demonstrated as such; >>

No, it hasn't. You saying it is so, does not make it so.

However, as I see no minds will be changed here or compromises reached,
I'm happy to let you have the last word and move on to more important
things...

Merry Xmas!

Pete
--
I used to write COBOL; now I can do anything...

As someone who has progressed from Batch to Interactive, I still seem to see

batch processing as part of the picture. So if you can upload a batch (file) of
transactions from say a CSV file then this is batch processing and can be very modern. At the same time, one has real time or interactive transactions. So I don't like the idea of batch processing being limited to the very older idea where all input was by Batch.

Merry Christmas
Greg

Hi Greg,

For me (and many other people who work with networked systems) it comes
done to "interrupt driven" (non-batch) as opposed to "program driven"
(batch). As I stated, they are different programming paradigms with the interrupt driven stuff being generally supported by OO code (mostly so
that separate interrupts can be serviced simultaneously by separate
instances of shared code), and the batch stuff being coded as normal procedural code, with one copy processing everything.

However, I'm not really bothered by whether people use either or both paradigms; I recognize in passing that there IS a difference and they
are best served by treating them as "different", that's all.

Processing a file of CSV transactions may be "modern" to some, but you
have to ask why they were "batched" in the first place. For
communication between systems (including mainframe and networked) I
would see XML as a better choice, but I agree this is arguable and it
most certainly depends on the full circumstances.

(I may have become biased to XML because I can manipulate it easily
using LINQ, just as if it was a database, and I can't do that with .csv...)

Cheers,

Pete.

--
I used to write COBOL; now I can do anything...

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

In article <ebkcgdF7tofU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 17/12/2016 6:05 a.m., docdwarf@panix.com wrote:

[snip]

My point is that batch processing is as necessitated by the functions of a >> business as transactional processing

And mine is that that MAY be so for SOME businesses.

(Be careful before you respond; you don't really want to say that ALL >businesses need both batch and transactional processing... You might >struggle to do batch processing on an iPhone, for example, and yet it
has the capability to access vast stores of information...)

I've atttempted to exercise a bit of caution, Mr Dashwood, and I've named
a few businesses categories - insurance, retail food and banking, among others, which support my assertions and conclusions.

Might you be able to give a few cites as counterexamples? These might be examined with enlghtening results.

[snip]

However, as I see no minds will be changed here or compromises reached,
I'm happy to let you have the last word and move on to more important >things...

Holding one's hands over one's ears and chanting 'I WON"T HEAR YOU' is not conducive to reasoned discourse, Mr Dashwood. Should this attitude change
I'd be more than happy to assist in reasoning together.

Merry Xmas!

To your and yours as well, old boy, and a happy, healthy, sweet and
prosperous New Year.

DD

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

In article <ebomegF9guhU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 19/12/2016 6:26 a.m., Greg Wallace wrote:

On Saturday, 17 December 2016 18:49:19 UTC+10, pete dashwood wrote:

On 17/12/2016 6:05 a.m., docdwarf@panix.com wrote:

In article <ebhbmbFg8fsU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 15/12/2016 4:37 p.m., docdwarf@panix.com wrote:

[snip]

Remember a story about a truck being

dispensed to deliver a single loaf of bread?

Spoken as one who truly has never grasped interrupt driven systems.

[snip]

For me (and many other people who work with networked systems) it comes
done to "interrupt driven" (non-batch) as opposed to "program driven" >(batch). As I stated, they are different programming paradigms...

Mr Dashwood, it seems that this is the source of your error. Would you be
so kind as to provide a source for definition of the terms 'interrupt
driven' and 'program driven' that is drawn from a commonly-accepted
source?

I ask because according to
http://en.wikipedia.org/wiki/Programming_paradigm there are no such
paradigms as 'interrupt driven' or 'program driven'.

According to http://www.google.com/#q=%22interrupt+driven+programming%22
there was something called 'interrupt-driven programming' proposed by a Mr Zelkowitz in 1970... is this what you are referring to?

DD

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 4/01/2017 1:56 a.m., docdwarf@panix.com wrote:

In article <ebomegF9guhU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 19/12/2016 6:26 a.m., Greg Wallace wrote:

On Saturday, 17 December 2016 18:49:19 UTC+10, pete dashwood wrote:

On 17/12/2016 6:05 a.m., docdwarf@panix.com wrote:

In article <ebhbmbFg8fsU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 15/12/2016 4:37 p.m., docdwarf@panix.com wrote:

[snip]

Remember a story about a truck being

dispensed to deliver a single loaf of bread?

Spoken as one who truly has never grasped interrupt driven systems.

[snip]

For me (and many other people who work with networked systems) it comes
done to "interrupt driven" (non-batch) as opposed to "program driven"
(batch). As I stated, they are different programming paradigms...

Mr Dashwood, it seems that this is the source of your error. Would you be
so kind as to provide a source for definition of the terms 'interrupt
driven' and 'program driven' that is drawn from a commonly-accepted
source?

No. People who do it understand what it is.

I ask because according to
http://en.wikipedia.org/wiki/Programming_paradigm there are no such
paradigms as 'interrupt driven' or 'program driven'.

Well, I guess if the Internet doesn't recognize them then they can't
possibly exist...

According to http://www.google.com/#q=%22interrupt+driven+programming%22 there was something called 'interrupt-driven programming' proposed by a Mr Zelkowitz in 1970... is this what you are referring to?

No. (Although I remember when this paper was first released...)

A search on "interrupt driven programming" returns around 3500 hits. I'm
sure if you go through them you'll get the idea, and possibly even find
the definition you are searching for...

I note you picked ONE out of the 3500 that is dated 1970; there are
other much more current articles, documents and comments about this
paradigm. (I recommend Stack Overflow as a much more useful programming resource than Wikipedia, but both are valuable.)

I don't see any point in continuing this, Doc.

No further responses from me.

It isn't that important, and I'll continue to use an event driven
paradigm no matter what you or Wikipedia may say about it.

I'll also use batch programming with a standard procedural paradigm when
that is appropriate. (I do still write COBOL occasionally...)

Pete.
--
I used to write COBOL; now I can do anything...

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

In article <ed3m8kFjae2U1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 4/01/2017 1:56 a.m., docdwarf@panix.com wrote:

In article <ebomegF9guhU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 19/12/2016 6:26 a.m., Greg Wallace wrote:

On Saturday, 17 December 2016 18:49:19 UTC+10, pete dashwood wrote:

On 17/12/2016 6:05 a.m., docdwarf@panix.com wrote:

In article <ebhbmbFg8fsU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 15/12/2016 4:37 p.m., docdwarf@panix.com wrote:

[snip]

Remember a story about a truck being

dispensed to deliver a single loaf of bread?

Spoken as one who truly has never grasped interrupt driven systems.

[snip]

For me (and many other people who work with networked systems) it comes
done to "interrupt driven" (non-batch) as opposed to "program driven"
(batch). As I stated, they are different programming paradigms...

Mr Dashwood, it seems that this is the source of your error. Would you be >> so kind as to provide a source for definition of the terms 'interrupt
driven' and 'program driven' that is drawn from a commonly-accepted
source?

No. People who do it understand what it is.

This seems less science and more religion.

I ask because according to
http://en.wikipedia.org/wiki/Programming_paradigm there are no such
paradigms as 'interrupt driven' or 'program driven'.

Well, I guess if the Internet doesn't recognize them then they can't >possibly exist...

No, Mr Dashwood. You've used terms that you have not defined and I'm
trying to establish common ground. Reticence to establish common
definitions often indicates a reluctance to discuss.

According to http://www.google.com/#q=%22interrupt+driven+programming%22
there was something called 'interrupt-driven programming' proposed by a Mr >> Zelkowitz in 1970... is this what you are referring to?

No. (Although I remember when this paper was first released...)

A search on "interrupt driven programming" returns around 3500 hits. I'm >sure if you go through them you'll get the idea, and possibly even find
the definition you are searching for...

I'm searching for the definition you are using, Mr Dashwood.

I note you picked ONE out of the 3500 that is dated 1970; there are
other much more current articles, documents and comments about this >paradigm. (I recommend Stack Overflow as a much more useful programming >resource than Wikipedia, but both are valuable.)

I don't see any point in continuing this, Doc.

The point is to learn, Mr Dashwood. Both of us need to keep doing so and
the first step towards learning is establishing definitions. Your
repeated refusal to do so is both telling and saddening.

Despite the Legal Mandate of Entropy, however, I still have hope.
Sometime again!

DD

SEEN-BY: 154/30 2320/100 0 1 227/0