• Re: Fortress COBOL - Why?

    From pete dashwood@1:2320/100 to comp.lang.cobol on Thu Dec 15 15:21:25 2016
    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 docdwarf@1:2320/100 to comp.lang.cobol on Thu Dec 15 03:37:52 2016
    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 pete dashwood@1:2320/100 to comp.lang.cobol on Fri Dec 16 18:16:56 2016
    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 docdwarf@1:2320/100 to comp.lang.cobol on Fri Dec 16 17:05:43 2016
    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 pete dashwood@1:2320/100 to comp.lang.cobol on Sat Dec 17 21:49:14 2016
    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 Greg Wallace@1:2320/100 to comp.lang.cobol on Sun Dec 18 09:26:09 2016
    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 pete dashwood@1:2320/100 to comp.lang.cobol on Mon Dec 19 13:03:26 2016
    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 docdwarf@1:2320/100 to comp.lang.cobol on Tue Dec 20 18:24:40 2016
    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 docdwarf@1:2320/100 to comp.lang.cobol on Tue Jan 3 12:56:36 2017
    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 pete dashwood@1:2320/100 to comp.lang.cobol on Wed Jan 4 20:24:01 2017
    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 docdwarf@1:2320/100 to comp.lang.cobol on Wed Jan 4 13:34:09 2017
    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