f



IBM "preview" of "major" (???) enhancements for mainframe COBOL

I don't know if this link will copy and work, but in this week's 
announcement from IBM there is a previow of their next release of z/OS and 
include in the announcement is a lot of talk of enhancements to the COBOL 
(with Java and DB2) "batch" environement.

Try this link,

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS211-007

Look for the paragraphs with,

"z/OS V1.13 is planned to introduce many capabilities to help write new 
applications and systems programs, and extend existing programs. Businesses 
with applications on z/OS understand the value of the quality of service, 
availability, scalability, and security of these applications and data on 
z/OS. Extending these critical applications and expanding the access to the 
z/OS data hub can drive business agility, enhance usability, and provide 
unprecedented levels of business integration. Batch is just such a critical 
business workload. According to IBM research, about 90% of respondents 
consider batch to be mission critical with the majority choosing to run it 
on System z. Central to batch processing is the COBOL programming language. 
COBOL is simple, efficient, robust, and scalable. With hundreds of billions 
of lines of code, COBOL assets are almost everywhere and capable of 
supporting billions of transactions a day. Top analysts agree COBOL can be 
modernized to help revolutionize batch processing.
With z/OS V1.13 IBM plans to deliver functionality intended to help reduce 
costs, and improve business agility and operational efficiencies of your 
COBOL batch environment, extending this powerful asset to a new realm of 
computing. A new base component, z/OS Batch Runtime, and associated new 
function are planned to be the foundation for a powerful, integrated, and 
modern batch application development, deployment, and runtime environment. 
Function planned for z/OS V1.13 is intended to be the foundation for 
"real-time batch" applications that enable concurrent batch and online data 
access."






0
wmklein1 (150)
2/16/2011 4:40:44 AM
comp.lang.cobol 4278 articles. 1 followers. Post Follow

34 Replies
781 Views

Similar Articles

[PageSpeed] 12

Bill Klein wrote:
> I don't know if this link will copy and work, but in this week's
> announcement from IBM there is a previow of their next release of
> z/OS and include in the announcement is a lot of talk of enhancements
> to the COBOL (with Java and DB2) "batch" environement.
>
> Try this link,
>
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS211-007
>
> Look for the paragraphs with,
>
> "z/OS V1.13 is planned to introduce many capabilities to help write
> new applications and systems programs, and extend existing programs.
> Businesses with applications on z/OS understand the value of the
> quality of service, availability, scalability, and security of these
> applications and data on z/OS. Extending these critical applications
> and expanding the access to the z/OS data hub can drive business
> agility, enhance usability, and provide unprecedented levels of
> business integration. Batch is just such a critical business
> workload. According to IBM research, about 90% of respondents
> consider batch to be mission critical with the majority choosing to
> run it on System z. Central to batch processing is the COBOL
> programming language. COBOL is simple, efficient, robust, and
> scalable. With hundreds of billions of lines of code, COBOL assets
> are almost everywhere and capable of supporting billions of
> transactions a day. Top analysts agree COBOL can be modernized to
> help revolutionize batch processing.  With z/OS V1.13 IBM plans to deliver 
> functionality intended to help
> reduce costs, and improve business agility and operational
> efficiencies of your COBOL batch environment, extending this powerful
> asset to a new realm of computing. A new base component, z/OS Batch
> Runtime, and associated new function are planned to be the foundation
> for a powerful, integrated, and modern batch application development,
> deployment, and runtime environment. Function planned for z/OS V1.13
> is intended to be the foundation for "real-time batch" applications
> that enable concurrent batch and online data access."

I agree that COBOL is ideal for Batch and have always said that. I can't see 
the point of concurrent batch and online data access (unless you simply 
weren't able to meet your batch requirement overnight :-))

The real question this raises is: "How relevant is batch processing in a 
modern environment?"

Personally, I don't think it is. And I think that people who DO think it is, 
think that way because that's the way they've always done it (and they are 
probably also not aware of some of the breakthroughs in data retrieval and 
processing that have been going on in non-mainframe environments for some 
years now.)

I'm happy to present my case as to why I believe there is no future in Batch 
processing  but there is a fair bit to it and it would probably require a 
separate thread.

(I'm also pressed for time right now and this would be a time consuming 
discussion...)

Nevertheless, here are some of the planks in my platform:

1. Modern technology using Objects can model the real world and as 
transactions occur in the real world they can be reflected in the data 
model.

2. Such a data model has everything anyone could want to know, including a 
timeline which mirrors the real world; The "database" (actually, it is a 
Corporate data resource) contains everything that has happened and when it 
did so. The problem then comes down to technology that can retrieve what we 
are interested in, consolidate it and summarise it, if we want that, then 
present it in a form that is easy and meaningful for Humans to assimilate. I 
contend that such technology already exists. It doesn't require sequential 
processing in Batches. It is provided by Networked objects and layers. (I 
admit it is a different concept from a centralised data repository sitting 
on a mainframe, but it works very well.)

3. Combine this concept with things like data warehouses and new and better 
ways of retrieving information (including symbolic programming  (Lambdas) 
where whole datasets may get "processed" without ever being physically 
accessed,  and what DOES get accessed only gets accessed at the last moment, 
running on one or more separate threads or processors), factor in RDB 
triggered procedures which also run in real time on separate threads or 
processors, and suddenly Batch Processing just looks like a tired and 
"quaint" way to process or provide information.

Some corporations are already embracing these approaches; others probably 
never will until their current management retires or they get forced out of 
business by smarter competitors.

A properly designed system can do whatever it needs to do in real time.

I see no future for Batch, but, in the interim, I agree COBOL is an ideal 
language to do it with.

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


0
dashwood (4370)
2/16/2011 11:34:28 AM
On 2/16/2011 6:34 AM, Pete Dashwood wrote:
> Bill Klein wrote:
>> I don't know if this link will copy and work, but in this week's
>> announcement from IBM there is a previow of their next release of
>> z/OS and include in the announcement is a lot of talk of enhancements
>> to the COBOL (with Java and DB2) "batch" environement.
>>
>> Try this link,
>>
>> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS211-007
>>
>> Look for the paragraphs with,
>>
>> "z/OS V1.13 is planned to introduce many capabilities to help write
>> new applications and systems programs, and extend existing programs.
>> Businesses with applications on z/OS understand the value of the
>> quality of service, availability, scalability, and security of these
>> applications and data on z/OS. Extending these critical applications
>> and expanding the access to the z/OS data hub can drive business
>> agility, enhance usability, and provide unprecedented levels of
>> business integration. Batch is just such a critical business
>> workload. According to IBM research, about 90% of respondents
>> consider batch to be mission critical with the majority choosing to
>> run it on System z. Central to batch processing is the COBOL
>> programming language. COBOL is simple, efficient, robust, and
>> scalable. With hundreds of billions of lines of code, COBOL assets
>> are almost everywhere and capable of supporting billions of
>> transactions a day. Top analysts agree COBOL can be modernized to
>> help revolutionize batch processing.  With z/OS V1.13 IBM plans to deliver
>> functionality intended to help
>> reduce costs, and improve business agility and operational
>> efficiencies of your COBOL batch environment, extending this powerful
>> asset to a new realm of computing. A new base component, z/OS Batch
>> Runtime, and associated new function are planned to be the foundation
>> for a powerful, integrated, and modern batch application development,
>> deployment, and runtime environment. Function planned for z/OS V1.13
>> is intended to be the foundation for "real-time batch" applications
>> that enable concurrent batch and online data access."
>
> I agree that COBOL is ideal for Batch and have always said that. I can't see
> the point of concurrent batch and online data access (unless you simply
> weren't able to meet your batch requirement overnight :-))
>
> The real question this raises is: "How relevant is batch processing in a
> modern environment?"
>
> Personally, I don't think it is. And I think that people who DO think it is,
> think that way because that's the way they've always done it (and they are
> probably also not aware of some of the breakthroughs in data retrieval and
> processing that have been going on in non-mainframe environments for some
> years now.)
>
> I'm happy to present my case as to why I believe there is no future in Batch
> processing  but there is a fair bit to it and it would probably require a
> separate thread.
>
> (I'm also pressed for time right now and this would be a time consuming
> discussion...)
>
> Nevertheless, here are some of the planks in my platform:
>
> 1. Modern technology using Objects can model the real world and as
> transactions occur in the real world they can be reflected in the data
> model.
>
> 2. Such a data model has everything anyone could want to know, including a
> timeline which mirrors the real world; The "database" (actually, it is a
> Corporate data resource) contains everything that has happened and when it
> did so. The problem then comes down to technology that can retrieve what we
> are interested in, consolidate it and summarise it, if we want that, then
> present it in a form that is easy and meaningful for Humans to assimilate. I
> contend that such technology already exists. It doesn't require sequential
> processing in Batches. It is provided by Networked objects and layers. (I
> admit it is a different concept from a centralised data repository sitting
> on a mainframe, but it works very well.)
>
> 3. Combine this concept with things like data warehouses and new and better
> ways of retrieving information (including symbolic programming  (Lambdas)
> where whole datasets may get "processed" without ever being physically
> accessed,  and what DOES get accessed only gets accessed at the last moment,
> running on one or more separate threads or processors), factor in RDB
> triggered procedures which also run in real time on separate threads or
> processors, and suddenly Batch Processing just looks like a tired and
> "quaint" way to process or provide information.
>
> Some corporations are already embracing these approaches; others probably
> never will until their current management retires or they get forced out of
> business by smarter competitors.
>
> A properly designed system can do whatever it needs to do in real time.
>
> I see no future for Batch, but, in the interim, I agree COBOL is an ideal
> language to do it with.
>
> Pete.

There likely should be no future for batch, but these discussions often 
conveniently overlook the fact that there are companies out there that 
have perhaps tens of thousands of COBOL programs and associated debris 
that DO perform useful functions in batch and none of that is documented 
well enough or understood well enough to replace in a twinkle.

Of course, new systems (whether they replace a chunk of the old stuff or 
not) likely would not include batch processing, there is a lot of it 
still in production right now. Sometimes the only solution to 25 years 
of ancient code is a timely acquisition by another company who then 
says: "by next Month/Tuesday/fortnight we won't be running any of that 
crap" - otherwise it is like Celine Dion and just goes on and on...
0
Kerry
2/16/2011 2:09:55 PM
In article <ijglr4$phv$1@news.eternal-september.org>,
	Kerry Liles <"kerry.liles[minus_the_spam]"@gmail.com> writes:
> On 2/16/2011 6:34 AM, Pete Dashwood wrote:
>> Bill Klein wrote:
>>> I don't know if this link will copy and work, but in this week's
>>> announcement from IBM there is a previow of their next release of
>>> z/OS and include in the announcement is a lot of talk of enhancements
>>> to the COBOL (with Java and DB2) "batch" environement.
>>>
>>> Try this link,
>>>
>>> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS211-007
>>>
>>> Look for the paragraphs with,
>>>
>>> "z/OS V1.13 is planned to introduce many capabilities to help write
>>> new applications and systems programs, and extend existing programs.
>>> Businesses with applications on z/OS understand the value of the
>>> quality of service, availability, scalability, and security of these
>>> applications and data on z/OS. Extending these critical applications
>>> and expanding the access to the z/OS data hub can drive business
>>> agility, enhance usability, and provide unprecedented levels of
>>> business integration. Batch is just such a critical business
>>> workload. According to IBM research, about 90% of respondents
>>> consider batch to be mission critical with the majority choosing to
>>> run it on System z. Central to batch processing is the COBOL
>>> programming language. COBOL is simple, efficient, robust, and
>>> scalable. With hundreds of billions of lines of code, COBOL assets
>>> are almost everywhere and capable of supporting billions of
>>> transactions a day. Top analysts agree COBOL can be modernized to
>>> help revolutionize batch processing.  With z/OS V1.13 IBM plans to deliver
>>> functionality intended to help
>>> reduce costs, and improve business agility and operational
>>> efficiencies of your COBOL batch environment, extending this powerful
>>> asset to a new realm of computing. A new base component, z/OS Batch
>>> Runtime, and associated new function are planned to be the foundation
>>> for a powerful, integrated, and modern batch application development,
>>> deployment, and runtime environment. Function planned for z/OS V1.13
>>> is intended to be the foundation for "real-time batch" applications
>>> that enable concurrent batch and online data access."
>>
>> I agree that COBOL is ideal for Batch and have always said that. I can't see
>> the point of concurrent batch and online data access (unless you simply
>> weren't able to meet your batch requirement overnight :-))
>>
>> The real question this raises is: "How relevant is batch processing in a
>> modern environment?"
>>
>> Personally, I don't think it is. And I think that people who DO think it is,
>> think that way because that's the way they've always done it (and they are
>> probably also not aware of some of the breakthroughs in data retrieval and
>> processing that have been going on in non-mainframe environments for some
>> years now.)
>>
>> I'm happy to present my case as to why I believe there is no future in Batch
>> processing  but there is a fair bit to it and it would probably require a
>> separate thread.
>>
>> (I'm also pressed for time right now and this would be a time consuming
>> discussion...)
>>
>> Nevertheless, here are some of the planks in my platform:
>>
>> 1. Modern technology using Objects can model the real world and as
>> transactions occur in the real world they can be reflected in the data
>> model.
>>
>> 2. Such a data model has everything anyone could want to know, including a
>> timeline which mirrors the real world; The "database" (actually, it is a
>> Corporate data resource) contains everything that has happened and when it
>> did so. The problem then comes down to technology that can retrieve what we
>> are interested in, consolidate it and summarise it, if we want that, then
>> present it in a form that is easy and meaningful for Humans to assimilate. I
>> contend that such technology already exists. It doesn't require sequential
>> processing in Batches. It is provided by Networked objects and layers. (I
>> admit it is a different concept from a centralised data repository sitting
>> on a mainframe, but it works very well.)
>>
>> 3. Combine this concept with things like data warehouses and new and better
>> ways of retrieving information (including symbolic programming  (Lambdas)
>> where whole datasets may get "processed" without ever being physically
>> accessed,  and what DOES get accessed only gets accessed at the last moment,
>> running on one or more separate threads or processors), factor in RDB
>> triggered procedures which also run in real time on separate threads or
>> processors, and suddenly Batch Processing just looks like a tired and
>> "quaint" way to process or provide information.
>>
>> Some corporations are already embracing these approaches; others probably
>> never will until their current management retires or they get forced out of
>> business by smarter competitors.
>>
>> A properly designed system can do whatever it needs to do in real time.
>>
>> I see no future for Batch, but, in the interim, I agree COBOL is an ideal
>> language to do it with.
>>
>> Pete.
> 
> There likely should be no future for batch, but these discussions often 
> conveniently overlook the fact that there are companies out there that 
> have perhaps tens of thousands of COBOL programs and associated debris 
> that DO perform useful functions in batch and none of that is documented 
> well enough or understood well enough to replace in a twinkle.
> 
> Of course, new systems (whether they replace a chunk of the old stuff or 
> not) likely would not include batch processing, there is a lot of it 
> still in production right now. Sometimes the only solution to 25 years 
> of ancient code is a timely acquisition by another company who then 
> says: "by next Month/Tuesday/fortnight we won't be running any of that 
> crap" - otherwise it is like Celine Dion and just goes on and on...

Well, ignoring the future for a moment and just looking at now....

One of the biggest businesses that I (personally) know is still being
done on IBM Mainframes in COBOL is credit cards.  There are a lot of
companies, mostly small shops, that do not have live connections to
pass credit card data in realtime and still use those little carbon
paper swipe machines.  They must enter this data somewhere later and
I would guess these all get processed as batch jobs.  And then you
have things like Payroll and printing W-2's.  Why would these not be
batch jobs? (and very likely still being done in COBOL :-)  Just as
I don;t see COBOL going away (definitely not in my lifetime) I also
don't see batch suddenly disappearing so that someone can handle these
menial tasks in realtime at a much higher cost. (Yes, I expect that
a minute of human time probably costs more than a minute of CPU time
and the human also takes much longer to do most tasks than the computer
does!)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
2/16/2011 2:42:19 PM
On Thu, 17 Feb 2011 00:34:28 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Bill Klein wrote:
>> I don't know if this link will copy and work, but in this week's
>> announcement from IBM there is a previow of their next release of
>> z/OS and include in the announcement is a lot of talk of enhancements
>> to the COBOL (with Java and DB2) "batch" environement.
>>
>> Try this link,
>>
>> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS211-007
>>
>> Look for the paragraphs with,
>>
>> "z/OS V1.13 is planned to introduce many capabilities to help write
>> new applications and systems programs, and extend existing programs.
>> Businesses with applications on z/OS understand the value of the
>> quality of service, availability, scalability, and security of these
>> applications and data on z/OS. Extending these critical applications
>> and expanding the access to the z/OS data hub can drive business
>> agility, enhance usability, and provide unprecedented levels of
>> business integration. Batch is just such a critical business
>> workload. According to IBM research, about 90% of respondents
>> consider batch to be mission critical with the majority choosing to
>> run it on System z. Central to batch processing is the COBOL
>> programming language. COBOL is simple, efficient, robust, and
>> scalable. With hundreds of billions of lines of code, COBOL assets
>> are almost everywhere and capable of supporting billions of
>> transactions a day. Top analysts agree COBOL can be modernized to
>> help revolutionize batch processing.  With z/OS V1.13 IBM plans to deliver 
>> functionality intended to help
>> reduce costs, and improve business agility and operational
>> efficiencies of your COBOL batch environment, extending this powerful
>> asset to a new realm of computing. A new base component, z/OS Batch
>> Runtime, and associated new function are planned to be the foundation
>> for a powerful, integrated, and modern batch application development,
>> deployment, and runtime environment. Function planned for z/OS V1.13
>> is intended to be the foundation for "real-time batch" applications
>> that enable concurrent batch and online data access."
>
>I agree that COBOL is ideal for Batch and have always said that. I can't see 
>the point of concurrent batch and online data access (unless you simply 
>weren't able to meet your batch requirement overnight :-))
>

There is a huge reason for concurrent batch and online data access. In
the real world of big banking (at least in North America and parts of
Europe and Asia), all processing is done in batch overnight and the
online masters reloaded.  Through various techniques, a bank can
achieve 24x7 online access save for 30 minutes while the files are
switched over.

Transactions entered online are kept, logged and processed during the
night.  The online masters are virtually thrown away and then
recreated in batch.  The reasons are two fold:  security and audit.  I
could go into a long explanation of both but this is not the forum for
that.  

This process has been in place for many, many years.  Other means have
been tried (distributed processing, online only processing using DBs
etc. etc. etc. blah, blah blah).  Some have had moderate success and
are still in use today but most failed to give the security and
auditing that is demanded by governments and internal bank
accountants.  Maybe someday another process will come along that will
be as reliable as the concurrent batch and online process, but it
ain't here yet.  And judging by the direction IBM is going both with
their OS and COBOL (it is far from dead), that's going to remain the
primary process for some time.

>The real question this raises is: "How relevant is batch processing in a 
>modern environment?"
>

See above.

>Personally, I don't think it is. And I think that people who DO think it is, 
>think that way because that's the way they've always done it (and they are 
>probably also not aware of some of the breakthroughs in data retrieval and 
>processing that have been going on in non-mainframe environments for some 
>years now.)
>

That's because you don't work in it day in, day out.  You're in the
world of servers and such.  Servers can are hacked.  Mainframe's are
not.  Simple as that.

>I'm happy to present my case as to why I believe there is no future in Batch 
>processing  but there is a fair bit to it and it would probably require a 
>separate thread.
>
>(I'm also pressed for time right now and this would be a time consuming 
>discussion...)
>
>Nevertheless, here are some of the planks in my platform:
>
>1. Modern technology using Objects can model the real world and as 
>transactions occur in the real world they can be reflected in the data 
>model.
>
>2. Such a data model has everything anyone could want to know, including a 
>timeline which mirrors the real world; The "database" (actually, it is a 
>Corporate data resource) contains everything that has happened and when it 
>did so. The problem then comes down to technology that can retrieve what we 
>are interested in, consolidate it and summarise it, if we want that, then 
>present it in a form that is easy and meaningful for Humans to assimilate. I 
>contend that such technology already exists. It doesn't require sequential 
>processing in Batches. It is provided by Networked objects and layers. (I 
>admit it is a different concept from a centralised data repository sitting 
>on a mainframe, but it works very well.)
>
>3. Combine this concept with things like data warehouses and new and better 
>ways of retrieving information (including symbolic programming  (Lambdas) 
>where whole datasets may get "processed" without ever being physically 
>accessed,  and what DOES get accessed only gets accessed at the last moment, 
>running on one or more separate threads or processors), factor in RDB 
>triggered procedures which also run in real time on separate threads or 
>processors, and suddenly Batch Processing just looks like a tired and 
>"quaint" way to process or provide information.
>
>Some corporations are already embracing these approaches; others probably 
>never will until their current management retires or they get forced out of 
>business by smarter competitors.
>
>A properly designed system can do whatever it needs to do in real time.
>
>I see no future for Batch, but, in the interim, I agree COBOL is an ideal 
>language to do it with.
>
>Pete.


Regards,
-- 

          ////
         (o o)
-oOO--(_)--OOo-

"Just remember...if the world didn't suck, we'd all fall off."
Trevor Myers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve
0
swiegand (666)
2/16/2011 4:14:41 PM
Bill Gunshannon wrote:
> In article <ijglr4$phv$1@news.eternal-september.org>,
> Kerry Liles <"kerry.liles[minus_the_spam]"@gmail.com> writes:
>> On 2/16/2011 6:34 AM, Pete Dashwood wrote:
>>> Bill Klein wrote:
>>>> I don't know if this link will copy and work, but in this week's
>>>> announcement from IBM there is a previow of their next release of
>>>> z/OS and include in the announcement is a lot of talk of
>>>> enhancements
>>>> to the COBOL (with Java and DB2) "batch" environement.
>>>>
>>>> Try this link,
>>>>
>>>> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS211-007
>>>>
>>>> Look for the paragraphs with,
>>>>
>>>> "z/OS V1.13 is planned to introduce many capabilities to help write
>>>> new applications and systems programs, and extend existing
>>>> programs. Businesses with applications on z/OS understand the
>>>> value of the
>>>> quality of service, availability, scalability, and security of
>>>> these applications and data on z/OS. Extending these critical
>>>> applications
>>>> and expanding the access to the z/OS data hub can drive business
>>>> agility, enhance usability, and provide unprecedented levels of
>>>> business integration. Batch is just such a critical business
>>>> workload. According to IBM research, about 90% of respondents
>>>> consider batch to be mission critical with the majority choosing to
>>>> run it on System z. Central to batch processing is the COBOL
>>>> programming language. COBOL is simple, efficient, robust, and
>>>> scalable. With hundreds of billions of lines of code, COBOL assets
>>>> are almost everywhere and capable of supporting billions of
>>>> transactions a day. Top analysts agree COBOL can be modernized to
>>>> help revolutionize batch processing.  With z/OS V1.13 IBM plans to
>>>> deliver functionality intended to help
>>>> reduce costs, and improve business agility and operational
>>>> efficiencies of your COBOL batch environment, extending this
>>>> powerful asset to a new realm of computing. A new base component,
>>>> z/OS Batch Runtime, and associated new function are planned to be
>>>> the foundation
>>>> for a powerful, integrated, and modern batch application
>>>> development, deployment, and runtime environment. Function planned
>>>> for z/OS V1.13
>>>> is intended to be the foundation for "real-time batch" applications
>>>> that enable concurrent batch and online data access."
>>>
>>> I agree that COBOL is ideal for Batch and have always said that. I
>>> can't see the point of concurrent batch and online data access
>>> (unless you simply weren't able to meet your batch requirement
>>> overnight :-))
>>>
>>> The real question this raises is: "How relevant is batch processing
>>> in a modern environment?"
>>>
>>> Personally, I don't think it is. And I think that people who DO
>>> think it is, think that way because that's the way they've always
>>> done it (and they are probably also not aware of some of the
>>> breakthroughs in data retrieval and processing that have been going
>>> on in non-mainframe environments for some years now.)
>>>
>>> I'm happy to present my case as to why I believe there is no future
>>> in Batch processing  but there is a fair bit to it and it would
>>> probably require a separate thread.
>>>
>>> (I'm also pressed for time right now and this would be a time
>>> consuming discussion...)
>>>
>>> Nevertheless, here are some of the planks in my platform:
>>>
>>> 1. Modern technology using Objects can model the real world and as
>>> transactions occur in the real world they can be reflected in the
>>> data model.
>>>
>>> 2. Such a data model has everything anyone could want to know,
>>> including a timeline which mirrors the real world; The "database"
>>> (actually, it is a Corporate data resource) contains everything
>>> that has happened and when it did so. The problem then comes down
>>> to technology that can retrieve what we are interested in,
>>> consolidate it and summarise it, if we want that, then present it
>>> in a form that is easy and meaningful for Humans to assimilate. I
>>> contend that such technology already exists. It doesn't require
>>> sequential processing in Batches. It is provided by Networked
>>> objects and layers. (I admit it is a different concept from a
>>> centralised data repository sitting on a mainframe, but it works
>>> very well.)
>>>
>>> 3. Combine this concept with things like data warehouses and new
>>> and better ways of retrieving information (including symbolic
>>> programming  (Lambdas) where whole datasets may get "processed"
>>> without ever being physically accessed,  and what DOES get accessed
>>> only gets accessed at the last moment, running on one or more
>>> separate threads or processors), factor in RDB triggered procedures
>>> which also run in real time on separate threads or processors, and
>>> suddenly Batch Processing just looks like a tired and "quaint" way
>>> to process or provide information.
>>>
>>> Some corporations are already embracing these approaches; others
>>> probably never will until their current management retires or they
>>> get forced out of business by smarter competitors.
>>>
>>> A properly designed system can do whatever it needs to do in real
>>> time.
>>>
>>> I see no future for Batch, but, in the interim, I agree COBOL is an
>>> ideal language to do it with.
>>>
>>> Pete.
>>
>> There likely should be no future for batch, but these discussions
>> often conveniently overlook the fact that there are companies out
>> there that have perhaps tens of thousands of COBOL programs and
>> associated debris that DO perform useful functions in batch and none
>> of that is documented well enough or understood well enough to
>> replace in a twinkle.
>>
>> Of course, new systems (whether they replace a chunk of the old
>> stuff or not) likely would not include batch processing, there is a
>> lot of it still in production right now. Sometimes the only solution
>> to 25 years of ancient code is a timely acquisition by another
>> company who then says: "by next Month/Tuesday/fortnight we won't be
>> running any of that crap" - otherwise it is like Celine Dion and
>> just goes on and on...
>
> Well, ignoring the future for a moment and just looking at now....
>
> One of the biggest businesses that I (personally) know is still being
> done on IBM Mainframes in COBOL is credit cards.

So there should be COBOL jobs at Amex, right?

http://jobs.americanexpress.com/key/Phoenix-AZ-computer-technology-jobs.html

Read some of these job descriptions (current as of February 2011) and see 
for yourself. They are a long way from Batch COBOL and are either replacing 
it or have already replaced it with networked data warehousing.

> There are a lot of
> companies, mostly small shops, that do not have live connections to
> pass credit card data in realtime and still use those little carbon
> paper swipe machines.

"A lot", huh? :-)

New Zealand is a small country but NOBODY has used that technology for 
YEARS. I can't remember the last time I saw it used. Everything is EFTPOS 
(even the smallest corner convenience store).

The "live connection to pass credit card data in real time" is called a 
telephone. It is hard to conceive of a business not having one.

It is a few years now since I was in Europe but I seem to recall that EFTPOS 
was making strides there too. I can't accept your statement that there are 
"a lot of companies, mostly small shops..." In what country are you talking 
about? Burkina Faso? (Experience here has been that "small shops" are the 
FIRST to embrace EFTPOS. It means less cash on the premises and consequently 
less risk.)

I believe you may have a mental model that needs updating, Bill.


> They must enter this data somewhere later and
> I would guess these all get processed as batch jobs.

Why would you guess that? Because that's how you would do it?

> And then you
> have things like Payroll and printing W-2's.  Why would these not be
> batch jobs? (and very likely still being done in COBOL :-)  Just as
> I don;t see COBOL going away (definitely not in my lifetime)

I'm sorry if your life is nearing its end. :-)

Depends what you mean by "going away"... I predicted it would no longer be a 
major programming language by 2015, and statistics show it is 30th in a list 
of most used programming languages as of now. (at the time I made the 
prediction it was still in the top 3...) People who actually do know COBOL 
are removing it from their CVs because it undermines their credibility when 
they go for a job.

I guess you could argue that Latin hasn't "gone away" but it receives little 
use in daily life. I see COBOL in the same terms.

Yes, I know all about the huge existing codebase of billions of lines of 
COBOL which underpins our society and without which life as we know it would 
descend into chaos, but I also observe and try to stay in touch with reality 
and what is really happening in IT. That huge codebase is being eroded at an 
ever increasing rate and this has been going on for years. You may console 
yourself with the thought that Credit Card companies, Banks, and Insurances 
are all dependent on COBOL but if you actually investigate (see the AMEX 
link above) you find it simply isn't true. I have spent  a lot of time 
working in Banks and Insurance companies. Some of them are still dependent 
on their legacy systems but it is a very high priority to remove that 
dependency.  NOBODY that I know (and I know a few people in these 
industries) is planning COBOL as part of their strategic future. The only 
reason COBOL is still kicking is because vendors like IBM and Micro Focus 
have a vested interest in keeping it alive. (To be fair, their customer base 
also resist movement and change and "require" continued support for COBOL.) 
As a new generation of IT people filter into industry the pressure to move 
off procedural processing will increase and eventually, we won't see COBOL 
being used for anything other than Batch.

Which brings me back to the point at hand. "How relevant is batch processing 
in the 21st century?"

I contend that it isn't, apart from the cases where it is already in use and 
it is not a high priority to replace it. I don't see new systems being 
designed with batch processing required, unless the design is poor or 
incompetent. (Yeah, I know... harsh words... never mind, it is what I 
actually think so I might as well say it. :-))




> I also
> don't see batch suddenly disappearing so that someone can handle these
> menial tasks in realtime at a much higher cost.

Nobody, least of all me, said "suddenly". It will take time and it will be 
phased out by attrition as new systems simply don't need it.

I don't know what planet you are living on that makes you think real time 
processing (using modern networked systems)  is a "much higher cost" than a 
mainframe grinding away through the night... It was certainly true when 
mainframes tried to do real time processing (30 years ago), today it is 
laughable. Transaction costs for the Web are a fraction of what it would 
cost to do the same transaction on a mainframe. (largely because the cost is 
distributed across an immense network, and the actual hardware costs are 
much less.)


(Yes, I expect that
> a minute of human time probably costs more than a minute of CPU time
> and the human also takes much longer to do most tasks than the
> computer does!)

Do you think? :-)

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


0
dashwood (4370)
2/16/2011 11:10:12 PM
SkippyPB wrote:
> On Thu, 17 Feb 2011 00:34:28 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>> Bill Klein wrote:
>>> I don't know if this link will copy and work, but in this week's
>>> announcement from IBM there is a previow of their next release of
>>> z/OS and include in the announcement is a lot of talk of
>>> enhancements
>>> to the COBOL (with Java and DB2) "batch" environement.
>>>
>>> Try this link,
>>>
>>> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS211-007
>>>
>>> Look for the paragraphs with,
>>>
>>> "z/OS V1.13 is planned to introduce many capabilities to help write
>>> new applications and systems programs, and extend existing programs.
>>> Businesses with applications on z/OS understand the value of the
>>> quality of service, availability, scalability, and security of these
>>> applications and data on z/OS. Extending these critical applications
>>> and expanding the access to the z/OS data hub can drive business
>>> agility, enhance usability, and provide unprecedented levels of
>>> business integration. Batch is just such a critical business
>>> workload. According to IBM research, about 90% of respondents
>>> consider batch to be mission critical with the majority choosing to
>>> run it on System z. Central to batch processing is the COBOL
>>> programming language. COBOL is simple, efficient, robust, and
>>> scalable. With hundreds of billions of lines of code, COBOL assets
>>> are almost everywhere and capable of supporting billions of
>>> transactions a day. Top analysts agree COBOL can be modernized to
>>> help revolutionize batch processing.  With z/OS V1.13 IBM plans to
>>> deliver functionality intended to help
>>> reduce costs, and improve business agility and operational
>>> efficiencies of your COBOL batch environment, extending this
>>> powerful asset to a new realm of computing. A new base component,
>>> z/OS Batch Runtime, and associated new function are planned to be
>>> the foundation
>>> for a powerful, integrated, and modern batch application
>>> development, deployment, and runtime environment. Function planned
>>> for z/OS V1.13
>>> is intended to be the foundation for "real-time batch" applications
>>> that enable concurrent batch and online data access."
>>
>> I agree that COBOL is ideal for Batch and have always said that. I
>> can't see the point of concurrent batch and online data access
>> (unless you simply weren't able to meet your batch requirement
>> overnight :-))
>>
>
> There is a huge reason for concurrent batch and online data access. In
> the real world of big banking (at least in North America and parts of
> Europe and Asia), all processing is done in batch overnight and the
> online masters reloaded.  Through various techniques, a bank can
> achieve 24x7 online access save for 30 minutes while the files are
> switched over.
>
> Transactions entered online are kept, logged and processed during the
> night.  The online masters are virtually thrown away and then
> recreated in batch.  The reasons are two fold:  security and audit.  I
> could go into a long explanation of both but this is not the forum for
> that.
>
> This process has been in place for many, many years.  Other means have
> been tried (distributed processing, online only processing using DBs
> etc. etc. etc. blah, blah blah).  Some have had moderate success and
> are still in use today but most failed to give the security and
> auditing that is demanded by governments and internal bank
> accountants.  Maybe someday another process will come along that will
> be as reliable as the concurrent batch and online process, but it
> ain't here yet.  And judging by the direction IBM is going both with
> their OS and COBOL (it is far from dead), that's going to remain the
> primary process for some time.
>
>> The real question this raises is: "How relevant is batch processing
>> in a modern environment?"
>>
>
> See above.
>
>> Personally, I don't think it is. And I think that people who DO
>> think it is, think that way because that's the way they've always
>> done it (and they are probably also not aware of some of the
>> breakthroughs in data retrieval and processing that have been going
>> on in non-mainframe environments for some years now.)
>>
>
> That's because you don't work in it day in, day out.  You're in the
> world of servers and such.  Servers can are hacked.  Mainframe's are
> not.  Simple as that.
>
>> I'm happy to present my case as to why I believe there is no future
>> in Batch processing  but there is a fair bit to it and it would
>> probably require a separate thread.
>>
>> (I'm also pressed for time right now and this would be a time
>> consuming discussion...)
>>
>> Nevertheless, here are some of the planks in my platform:
>>
>> 1. Modern technology using Objects can model the real world and as
>> transactions occur in the real world they can be reflected in the
>> data model.
>>
>> 2. Such a data model has everything anyone could want to know,
>> including a timeline which mirrors the real world; The "database"
>> (actually, it is a Corporate data resource) contains everything that
>> has happened and when it did so. The problem then comes down to
>> technology that can retrieve what we are interested in, consolidate
>> it and summarise it, if we want that, then present it in a form that
>> is easy and meaningful for Humans to assimilate. I contend that such
>> technology already exists. It doesn't require sequential processing
>> in Batches. It is provided by Networked objects and layers. (I admit
>> it is a different concept from a centralised data repository sitting
>> on a mainframe, but it works very well.)
>>
>> 3. Combine this concept with things like data warehouses and new and
>> better ways of retrieving information (including symbolic
>> programming  (Lambdas) where whole datasets may get "processed"
>> without ever being physically accessed,  and what DOES get accessed
>> only gets accessed at the last moment, running on one or more
>> separate threads or processors), factor in RDB triggered procedures
>> which also run in real time on separate threads or processors, and
>> suddenly Batch Processing just looks like a tired and "quaint" way
>> to process or provide information.
>>
>> Some corporations are already embracing these approaches; others
>> probably never will until their current management retires or they
>> get forced out of business by smarter competitors.
>>
>> A properly designed system can do whatever it needs to do in real
>> time.
>>
>> I see no future for Batch, but, in the interim, I agree COBOL is an
>> ideal language to do it with.
>>
>> Pete.
>
>
> Regards,

Thanks for the post, Steve.

I understand your points (I also have considerable background in Banking) 
but I see a wider picture.

Never mind, time will tell :-)

Pete.

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


0
dashwood (4370)
2/16/2011 11:13:13 PM
Kerry Liles" <"kerry.liles[minus_the_spam] wrote:
> On 2/16/2011 6:34 AM, Pete Dashwood wrote:
>> Bill Klein wrote:
>>> I don't know if this link will copy and work, but in this week's
>>> announcement from IBM there is a previow of their next release of
>>> z/OS and include in the announcement is a lot of talk of
>>> enhancements to the COBOL (with Java and DB2) "batch" environement.
>>>
>>> Try this link,
>>>
>>> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS211-007
>>>
>>> Look for the paragraphs with,
>>>
>>> "z/OS V1.13 is planned to introduce many capabilities to help write
>>> new applications and systems programs, and extend existing programs.
>>> Businesses with applications on z/OS understand the value of the
>>> quality of service, availability, scalability, and security of these
>>> applications and data on z/OS. Extending these critical applications
>>> and expanding the access to the z/OS data hub can drive business
>>> agility, enhance usability, and provide unprecedented levels of
>>> business integration. Batch is just such a critical business
>>> workload. According to IBM research, about 90% of respondents
>>> consider batch to be mission critical with the majority choosing to
>>> run it on System z. Central to batch processing is the COBOL
>>> programming language. COBOL is simple, efficient, robust, and
>>> scalable. With hundreds of billions of lines of code, COBOL assets
>>> are almost everywhere and capable of supporting billions of
>>> transactions a day. Top analysts agree COBOL can be modernized to
>>> help revolutionize batch processing.  With z/OS V1.13 IBM plans to
>>> deliver functionality intended to help
>>> reduce costs, and improve business agility and operational
>>> efficiencies of your COBOL batch environment, extending this
>>> powerful asset to a new realm of computing. A new base component,
>>> z/OS Batch Runtime, and associated new function are planned to be
>>> the foundation for a powerful, integrated, and modern batch application
>>> development, deployment, and runtime environment. Function planned
>>> for z/OS V1.13 is intended to be the foundation for "real-time batch" 
>>> applications
>>> that enable concurrent batch and online data access."
>>
>> I agree that COBOL is ideal for Batch and have always said that. I
>> can't see the point of concurrent batch and online data access
>> (unless you simply weren't able to meet your batch requirement
>> overnight :-)) The real question this raises is: "How relevant is batch 
>> processing
>> in a modern environment?"
>>
>> Personally, I don't think it is. And I think that people who DO
>> think it is, think that way because that's the way they've always
>> done it (and they are probably also not aware of some of the
>> breakthroughs in data retrieval and processing that have been going
>> on in non-mainframe environments for some years now.)
>>
>> I'm happy to present my case as to why I believe there is no future
>> in Batch processing  but there is a fair bit to it and it would
>> probably require a separate thread.
>>
>> (I'm also pressed for time right now and this would be a time
>> consuming discussion...)
>>
>> Nevertheless, here are some of the planks in my platform:
>>
>> 1. Modern technology using Objects can model the real world and as
>> transactions occur in the real world they can be reflected in the
>> data model.
>>
>> 2. Such a data model has everything anyone could want to know,
>> including a timeline which mirrors the real world; The "database"
>> (actually, it is a Corporate data resource) contains everything that
>> has happened and when it did so. The problem then comes down to
>> technology that can retrieve what we are interested in, consolidate
>> it and summarise it, if we want that, then present it in a form that
>> is easy and meaningful for Humans to assimilate. I contend that such
>> technology already exists. It doesn't require sequential processing
>> in Batches. It is provided by Networked objects and layers. (I admit
>> it is a different concept from a centralised data repository sitting
>> on a mainframe, but it works very well.) 3. Combine this concept with 
>> things like data warehouses and new and
>> better ways of retrieving information (including symbolic
>> programming  (Lambdas) where whole datasets may get "processed"
>> without ever being physically accessed,  and what DOES get accessed
>> only gets accessed at the last moment, running on one or more
>> separate threads or processors), factor in RDB triggered procedures
>> which also run in real time on separate threads or processors, and
>> suddenly Batch Processing just looks like a tired and "quaint" way
>> to process or provide information. Some corporations are already 
>> embracing these approaches; others
>> probably never will until their current management retires or they
>> get forced out of business by smarter competitors.
>>
>> A properly designed system can do whatever it needs to do in real
>> time. I see no future for Batch, but, in the interim, I agree COBOL is an
>> ideal language to do it with.
>>
>> Pete.
>
> There likely should be no future for batch, but these discussions
> often conveniently overlook the fact that there are companies out
> there that have perhaps tens of thousands of COBOL programs and
> associated debris that DO perform useful functions in batch and none
> of that is documented well enough or understood well enough to
> replace in a twinkle.
> Of course, new systems (whether they replace a chunk of the old stuff
> or not) likely would not include batch processing, there is a lot of
> it still in production right now. Sometimes the only solution to 25
> years of ancient code is a timely acquisition by another company who
> then says: "by next Month/Tuesday/fortnight we won't be running any
> of that crap" - otherwise it is like Celine Dion and just goes on and
> on...

Fair points Kerry.

I don't think batch will disappear overnight or suddenly and I didn't say 
that. Neither will it go away just because it is anathema to me, personally 
:-)

Rather, as new packages, systems, and different development techniques and 
procedures come in, the need for it will simply disappear.

I haven't designed a system that required batch processing for years now. 
Reporting is done by subsystems (like Crystal and Stimulsoft) that are 
designed for that and run independently on their own threads, sometimes 
triggered by RDB SPs.

I just see sequential processing in a dedicated process as obsolete.

Using objects gives a different perspective.

Pete.

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


0
dashwood (4370)
2/16/2011 11:26:36 PM
On Thu, 17 Feb 2011 12:10:12 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>I don't know what planet you are living on that makes you think real time 
>processing (using modern networked systems)  is a "much higher cost" than a 
>mainframe grinding away through the night... It was certainly true when 
>mainframes tried to do real time processing (30 years ago), today it is 
>laughable. Transaction costs for the Web are a fraction of what it would 
>cost to do the same transaction on a mainframe. (largely because the cost is 
>distributed across an immense network, and the actual hardware costs are 
>much less.)

The place where mainfames are most competitive (in new systems), is
with big, fast, secure databases.   These aren't traditional mainframe
transactions though, and don't need batch programmers.   

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
howard (6283)
2/17/2011 12:43:42 AM
Pete Dashwood wrote:

[OT while not related to enhancements for mainframe COBOL]

> Bill Klein wrote:
>> I don't know if this link will copy and work, but in this week's
>> announcement from IBM there is a previow of their next release of
>> z/OS and include in the announcement is a lot of talk of enhancements
>> to the COBOL (with Java and DB2) "batch" environement.
<...>

> I agree that COBOL is ideal for Batch and have always said that. I
> can't see the point of concurrent batch and online data access (unless
> you simply weren't able to meet your batch requirement overnight :-))
> 
> The real question this raises is: "How relevant is batch processing in
> a modern environment?"
> 
> Personally, I don't think it is. And I think that people who DO think
> it is, think that way because that's the way they've always done it
> (and they are probably also not aware of some of the breakthroughs in
> data retrieval and processing that have been going on in non-mainframe
> environments for some years now.)

Batch processing (not necessarily with COBOL) is not yet going away,
like in
- backup processing,
- log analyses,
- system updating,
- invoicing
to name some activities executed here on a regular base.
-- 
Fred Mobach
website : https://fred.mobach.nl
 .... In God we trust ....
 .. The rest we monitor ..
0
Fred
2/17/2011 1:37:42 PM
Pete Dashwood wrote:
> Bill Gunshannon wrote:
> 
>> There are a lot of
>> companies, mostly small shops, that do not have live connections to
>> pass credit card data in realtime and still use those little carbon
>> paper swipe machines.
> 
> "A lot", huh? :-)

In the US, there are.

> It is a few years now since I was in Europe but I seem to recall that EFTPOS 
> was making strides there too. I can't accept your statement that there are 
> "a lot of companies, mostly small shops..." In what country are you talking 
> about? Burkina Faso? (Experience here has been that "small shops" are the 
> FIRST to embrace EFTPOS. It means less cash on the premises and consequently 
> less risk.)

I have a colleague who works for a firm that sells, leases, and
supports small POS credit-card systems to individuals and small
companies. They have hundreds of customers. Many of their customers do
batch processing of CC transactions at the end of each business day.

We were just discussing this a couple of weeks ago.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
0
Michael
2/18/2011 7:56:40 AM
Fred Mobach wrote:
> 
> Batch processing (not necessarily with COBOL) is not yet going away,

.... and probably never will.

It doesn't matter how large the capacity of online processing gets;
someone will always find a dataset and transformation that are too
large to perform with continuous online processing, and have to be
batched. There's no end of interesting problems in NP-Complete or
other intractable classes.

Take a look at some of the work being done in the digital humanities,
for example - doing statistical language parsing of huge scanned
corpora of texts stretching back to antiquity. You don't do that online.

So while many tasks that were infeasible for online processing last
year may move out of the batch realm this year, people will just
introduce new tasks that have to be partitioned and run in batches.

Take Google. Until last year, the Google web index was updated as a
batch job - MapReduce is a massively distributed batch system. Then,
with Caffeine, they moved to an online indexing system that's
continuously updated. But they just took the freed-up batch capacity
and turned it to other tasks, like OCR and morphological stemming on
the backlog of scanned material for Google Books, the N-gram index,
improving their speech-recognition models, etc.

Thinking that batch processing will go away because of performance
improvements is a category error. Batch processing doesn't exist
because of specific performance constraints - it exists because batch
scheduling maximizes throughput, and there are always interesting
problems that are just as large as any computing capacity we can build.

We already have a healthy supply of problems that exceed any
physically possible computer - including hypothetical quantum
computers. So it's not hard to find ones that are just hard enough to
require whatever we can afford to throw at them.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
0
Michael
2/18/2011 8:09:02 AM
Michael Wojcik wrote:
> Pete Dashwood wrote:
>> Bill Gunshannon wrote:
>>
>>> There are a lot of
>>> companies, mostly small shops, that do not have live connections to
>>> pass credit card data in realtime and still use those little carbon
>>> paper swipe machines.
>>
>> "A lot", huh? :-)
>
> In the US, there are.
>
>> It is a few years now since I was in Europe but I seem to recall
>> that EFTPOS was making strides there too. I can't accept your
>> statement that there are "a lot of companies, mostly small shops..."
>> In what country are you talking about? Burkina Faso? (Experience
>> here has been that "small shops" are the FIRST to embrace EFTPOS. It
>> means less cash on the premises and consequently less risk.)
>
> I have a colleague who works for a firm that sells, leases, and
> supports small POS credit-card systems to individuals and small
> companies. They have hundreds of customers. Many of their customers do
> batch processing of CC transactions at the end of each business day.
>
> We were just discussing this a couple of weeks ago.

Thanks Michael.

Sorry to hear the US is such an IT backwater... :-)

Watch it change over time.

Pete.

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


0
Pete
2/19/2011 12:45:31 AM
Michael Wojcik wrote:
> Fred Mobach wrote:
>>
>> Batch processing (not necessarily with COBOL) is not yet going away,
>
> ... and probably never will.
>
> It doesn't matter how large the capacity of online processing gets;
> someone will always find a dataset and transformation that are too
> large to perform with continuous online processing, and have to be
> batched. There's no end of interesting problems in NP-Complete or
> other intractable classes.
>
> Take a look at some of the work being done in the digital humanities,
> for example - doing statistical language parsing of huge scanned
> corpora of texts stretching back to antiquity. You don't do that
> online.
>
> So while many tasks that were infeasible for online processing last
> year may move out of the batch realm this year, people will just
> introduce new tasks that have to be partitioned and run in batches.
>
> Take Google. Until last year, the Google web index was updated as a
> batch job - MapReduce is a massively distributed batch system. Then,
> with Caffeine, they moved to an online indexing system that's
> continuously updated. But they just took the freed-up batch capacity
> and turned it to other tasks, like OCR and morphological stemming on
> the backlog of scanned material for Google Books, the N-gram index,
> improving their speech-recognition models, etc.
>
> Thinking that batch processing will go away because of performance
> improvements is a category error. Batch processing doesn't exist
> because of specific performance constraints - it exists because batch
> scheduling maximizes throughput, and there are always interesting
> problems that are just as large as any computing capacity we can
> build.
>
> We already have a healthy supply of problems that exceed any
> physically possible computer - including hypothetical quantum
> computers. So it's not hard to find ones that are just hard enough to
> require whatever we can afford to throw at them.

Yes, those SMEs and family businesses, not to mention the Insurance 
Companies, do a fair bit of  OCR and morphological scanning, in between 
developing their speech recognition and translation facilites...:-)

I see no future in Batch Processing apart from that which already exists, 
however, I will modify my position to: COMMERCIAL operations (accounting, 
analysis, sales, etc. that which was previously referred to as EDP) and 
agree that there probably will be some specialised operations that may 
benefit from an intensive sequential approach.

Out here on the cutting edge of computer technology we sometimes forget that 
the rest of the world has some catching up to do... :-)

Time will tell.

Pete.

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


0
Pete
2/19/2011 12:54:36 AM
In article <8s8imfFataU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>Out here on the cutting edge of computer technology we sometimes forget that 
>the rest of the world has some catching up to do... :-)

Does 'catching up' include reducing its total population - and its 
associated data volume - to a quantity known in other parts of the globe 
as 'an almost-large city'?

As those who have had a couple of things dropped on their feet may have 
learned: a difference in quantity may make for a difference in quality.

DD

0
docdwarf
2/19/2011 1:03:17 AM
On Sat, 19 Feb 2011 13:45:31 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Michael Wojcik wrote:
>> Pete Dashwood wrote:
>>> Bill Gunshannon wrote:
>>>
>>>> There are a lot of
>>>> companies, mostly small shops, that do not have live connections to
>>>> pass credit card data in realtime and still use those little carbon
>>>> paper swipe machines.
>>>
>>> "A lot", huh? :-)
>>
>> In the US, there are.
>>
>>> It is a few years now since I was in Europe but I seem to recall
>>> that EFTPOS was making strides there too. I can't accept your
>>> statement that there are "a lot of companies, mostly small shops..."
>>> In what country are you talking about? Burkina Faso? (Experience
>>> here has been that "small shops" are the FIRST to embrace EFTPOS. It
>>> means less cash on the premises and consequently less risk.)
>>
>> I have a colleague who works for a firm that sells, leases, and
>> supports small POS credit-card systems to individuals and small
>> companies. They have hundreds of customers. Many of their customers do
>> batch processing of CC transactions at the end of each business day.
>>
>> We were just discussing this a couple of weeks ago.
>
>Thanks Michael.
>
>Sorry to hear the US is such an IT backwater... :-)

Part of the difference may be in the cost of online access and the
value to the organization.  How many credit card transactions are
needed to pay for the equipment, line or telephone costs, and fees?
Having said that most of the places I deal with here in Atlantic
Canada have POS credit/debit card machines so presumably they are real
time update.  

In other contexts, doing full online updating of all accounts can lead
to massive system overload.  SAP got thrown out for one of the
operations at a major Canadian grocery chain because of that problem.
Half hour response times just didn't make it.

In many cases performance matters and overhead matters.  There even
are a few new IBM z series mainframe customers.  

Clark Morris   
>
>Watch it change over time.
>
>Pete.
0
Clark
2/19/2011 2:44:43 AM
On Sat, 19 Feb 2011 13:45:31 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>> We were just discussing this a couple of weeks ago.
>
>Thanks Michael.
>
>Sorry to hear the US is such an IT backwater... :-)
>
>Watch it change over time.

Sometimes being first can be a disadvantage.   Countries that weren't
as invested in phone land-lines found it easier to move to cellular.

And the first countries to offer HDTV had analog HDTVs that weren't
nearly as good as the digital versions that came later.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Howard
2/19/2011 2:48:54 AM
docdwarf@panix.com wrote:
> In article <8s8imfFataU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>> Out here on the cutting edge of computer technology we sometimes
>> forget that the rest of the world has some catching up to do... :-)
>
> Does 'catching up' include reducing its total population - and its
> associated data volume - to a quantity known in other parts of the
> globe as 'an almost-large city'?

Tee hee... :-)

I knew there would be a few rise to the bait, but I didn't expect you to be 
one of them, Doc...

You are right, of course.

We have 4 million here and are already starting to feel crowded.

I always used to joke in England that the population of NZ was roughly the 
same as North London... :-)

Australia, on the other hand, has around 24 million and they have pretty 
much the same technology we have. I can't think offhand of an "almost-large 
city" in the United States that has 24 million people living in it. (28 
million if you bundle us in as well.) It is interesting that EFTPOS cards 
issued in NZ work fine in Australia and vice versa. I can get cash from an 
Australian ATM and my NZ account is updated in real time. I can pay for 
dinner in an Australian restaurant using my NZ EFTPOS and again my account 
is updated immediately. (This is 24/7, no batch...) I believe Australians 
visiting NZ enjoy the same facility.)

While I accept it is more difficult when you have more people, businesses 
already have telephones, and ADSL is hardly high or cutting edge technology, 
neither is it expensive, so transactions CAN be processed electronically 
without any major upheaval or increase in costs.

Draw your own conclusions as to why there is no upswing in immediate 
processing. I suspect the reason it may not be sweeping America is because 
there is a vested interest in swipe machines and carbon forms... and, you DO 
have to educate a population into thinking 21st century technology and 
getting away from paper. I understand many people in this forum are still 
getting paper Bank and Credit Card statements (to me, and the majority of 
Kiwis, that is just archaic and we haven't done it for years.) BUT, it all 
requires a change in attitude and that takes time. (For many years I was 
happy ot get a paper statement; now it just strikes me as laughable.)

In the final analysis it comes down to will and attitude. If people WANT a 
better solution, they will get one. The rising generation are very much 
aware of this and they are the business owners of tomorrow.

As I have remarked elsewhere, time will tell.

>
> As those who have had a couple of things dropped on their feet may
> have learned: a difference in quantity may make for a difference in
> quality.
>
OK, but it is no excuse to cling to the LCD...:-)

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


0
Pete
2/19/2011 7:26:22 AM
Clark F Morris wrote:
> On Sat, 19 Feb 2011 13:45:31 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>> Michael Wojcik wrote:
>>> Pete Dashwood wrote:
>>>> Bill Gunshannon wrote:
>>>>
>>>>> There are a lot of
>>>>> companies, mostly small shops, that do not have live connections
>>>>> to pass credit card data in realtime and still use those little
>>>>> carbon paper swipe machines.
>>>>
>>>> "A lot", huh? :-)
>>>
>>> In the US, there are.
>>>
>>>> It is a few years now since I was in Europe but I seem to recall
>>>> that EFTPOS was making strides there too. I can't accept your
>>>> statement that there are "a lot of companies, mostly small
>>>> shops..." In what country are you talking about? Burkina Faso?
>>>> (Experience here has been that "small shops" are the FIRST to
>>>> embrace EFTPOS. It means less cash on the premises and
>>>> consequently less risk.)
>>>
>>> I have a colleague who works for a firm that sells, leases, and
>>> supports small POS credit-card systems to individuals and small
>>> companies. They have hundreds of customers. Many of their customers
>>> do batch processing of CC transactions at the end of each business
>>> day.
>>>
>>> We were just discussing this a couple of weeks ago.
>>
>> Thanks Michael.
>>
>> Sorry to hear the US is such an IT backwater... :-)
>
> Part of the difference may be in the cost of online access and the
> value to the organization.  How many credit card transactions are
> needed to pay for the equipment, line or telephone costs, and fees?

A good try, Clark but it doesn't stand inspection.

Business ALREADY have telephones. There is NO extra charge for ADSL traffic 
on a line which is already paid for.

The EFTPOS fee is a couple of cents per transaction and is included in the 
item price.

An EFTPOS machine (which may contain its own ADSL modem) will cost around 
$300but it is a ONE-TIME cost and it means the business has less cash on the 
premises. It also means that funds are immediately available to the 
business, and that alone is worth large amounts to large businesses, who may 
place cash surpluses into overnight markets. (Small businesses are not going 
to grizzle at it, either :-))

> Having said that most of the places I deal with here in Atlantic
> Canada have POS credit/debit card machines so presumably they are real
> time update.

Yes, that is normally the case. Electronic Funds Transfer at Point of Sale 
(EFTPOS). All the major banks here support it and encourage it. As you say 
we also process Debit/Credit cards with the same terminal.
>
> In other contexts, doing full online updating of all accounts can lead
> to massive system overload.

Um.... wouldn't you then buy more hardware? If a system can't cope with the 
load, it has to be upgraded, I would've thought. You don't cut the load 
because the system can't cope. That is like the tail wagging the dog.

>SAP got thrown out for one of the
> operations at a major Canadian grocery chain because of that problem.

And yet SAP is runnning successfully all over the world in organizations 
larger and smaller than that. Perhaps a local anomaly that reflects on poor 
understanding and implementation, rather than inherent inability in the 
software/hardware? We've all seen "bad" system implementations; it doesn't 
mean the technology is crap.

> Half hour response times just didn't make it.

:-) Wouldn't you think they would've addressed the problems before it got to 
that? Maybe the organisation was politically opposed to SAP. If people don't 
want something it is very easy to make sure it doesn't perform...

I remember resistance to: High Level Languages, Virtual Storage, Relational 
Databases... and there were sniggerings in bars by programmers opposed to 
change, and urban myths of major disasters caused by disk thrashing and so 
on... And yet, today, all of these things are simply part of the background 
scenery and we can't imagine commercial data processing without them. Time 
told.

>
> In many cases performance matters and overhead matters.  There even
> are a few new IBM z series mainframe customers.

And I'm sure there will be more. If you stand back and take a much broader 
view, we are currently in a transition phase between "old" and "new" 
technology. There is much bewilderment (particularly in the "old" camp; 
"new" people don't care... if they can't get the existing technology to 
behave the way they want they simply replace it, or work round 
it...productivity in the new technology is many times what was normal for 
the old...) and people who have worked a certain way all their lives don't 
see reason for change. Gradually, as new people filter in to the 
organisation, the pressure mounts for newer solutions.

In the meantime, everybody agrees the existing systems can't be replaced 
overnight and they must keep running. There are different approaches to 
achieving this and these approaches are predicated on perceived end points. 
(And political as well as technical aspirations.)

I believe existing code (in COBOL or anything else) should be wrapped as 
objects so it can work in both the "old" and "new" environments, and a move 
should be made towards a networked architecture comprised of objects and 
layers. I believe this because I see that as the most "future proof option". 
Networks are going to be with us for a considerable time to come and the 
networks work best with layers and objects. Frameworks like .Net and Mono 
are excellent target platforms for commercial application software (BECAUSE 
they are "level development playing fields", source language is irrelevant, 
functionality is all that matters...) so I am committed to going there. Both 
the Intranet and the Internet (WWW) are going to be inextricably entwined 
into the applications of the future. They both need objects.(And objects 
gain synergy when they are "layered".)

But there are people who don't see this and believe they can continue the 
way they always have. So they buy a new mainframe and a .Net Compiler. They 
feel they are stepping in the right direction but, in fact, they eventually 
find out that the Network doesn't respond well to procedural code. No 
problem; the .Net compiler supports OO so they finally start building 
objects in COBOL. Then they find out that that is painfully slow and tedious 
compared to building objects with a language designed to do that, and so, 
eventually, after a painful and expensive journey, they swap their mainframe 
for a series of Xeon or blade servers (notice that IBM keep their feet in 
both camps and can supply either solution) and move off COBOL to a .Net 
language. They could have done this on day one and avoided going round the 
houses. No need for a .Net COBOL compiler, the time they spent could have 
been used to refactor the most salvageable parts of their legacy (you don't 
need a .Net COBOL compiler to wrap existing legacy as objects) and they 
could have been well round the OO learning curve and into new system 
development using objects and layers, IF they had been prepared to "bite the 
bullet" on day one. (You may be aware that I am completely dedicated to 
helping people bite these bullets, and provide tools to prevent you breaking 
your teeth...:-)).

I have been there myself and am well aware of the pitfalls.

I may be right or I may be wrong, but I have never regretted moving to .Net 
and leaving COBOL. Nether has anyone else who I have assisted to do the 
same.

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


0
Pete
2/19/2011 8:24:53 AM
On Feb 18, 8:09=A0am, Michael Wojcik <mwoj...@newsguy.com> wrote:
> Fred Mobach wrote:
>
> > Batch processing (not necessarily with COBOL) is not yet going away,

Surely the killer resolution is:

 Online realtime update is batch processing with a batch size of 1.
0
Alistair
2/19/2011 9:14:12 AM
On Feb 19, 7:26=A0am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> docdw...@panix.com wrote:
> > In article <8s8imfFat...@mid.individual.net>,
> > Pete Dashwood <dashw...@removethis.enternet.co.nz> wrote:
>
> > [snip]
>
> >> Out here on the cutting edge of computer technology we sometimes
> >> forget that the rest of the world has some catching up to do... :-)
>
> > Does 'catching up' include reducing its total population - and its
> > associated data volume - to a quantity known in other parts of the
> > globe as 'an almost-large city'?
>
> Tee hee... :-)
>
> I knew there would be a few rise to the bait, but I didn't expect you to =
be
> one of them, Doc...
>
> You are right, of course.
>
> We have 4 million here and are already starting to feel crowded.
>
> I always used to joke in England that the population of NZ was roughly th=
e
> same as North London... :-)
>
> Australia, on the other hand, has around 24 million and they have pretty
> much the same technology we have. I can't think offhand of an "almost-lar=
ge
> city" in the United States that has 24 million people living in it. (28
> million if you bundle us in as well.) It is interesting that EFTPOS cards
> issued in NZ work fine in Australia and vice versa. I can get cash from a=
n
> Australian ATM and my NZ account is updated in real time. I can pay for
> dinner in an Australian restaurant using my NZ EFTPOS and again my accoun=
t
> is updated immediately. (This is 24/7, no batch...) I believe Australians
> visiting NZ enjoy the same facility.)
>

I have worked for card processors and they had massive batch systems.
You can make a batch system look like online realtime by a number of
means usually involving batching a day's updates and processing at
night.
0
Alistair
2/19/2011 9:19:33 AM
On Feb 19, 8:24=A0am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> Clark F Morris wrote:
> > On Sat, 19 Feb 2011 13:45:31 +1300, "Pete Dashwood"
> > <dashw...@removethis.enternet.co.nz> wrote:
>
> >> Michael Wojcik wrote:
>
> > Part of the difference may be in the cost of online access and the
> > value to the organization. =A0How many credit card transactions are
> > needed to pay for the equipment, line or telephone costs, and fees?
>
> A good try, Clark but it doesn't stand inspection.
>
> Business ALREADY have telephones. There is NO extra charge for ADSL traff=
ic
> on a line which is already paid for.

Wrong; 20 pounds per calendar month in addition to the standard line
rental.

>

0
Alistair
2/19/2011 9:25:55 AM
Alistair Maclean wrote:
> On Feb 19, 8:24 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> Clark F Morris wrote:
>>> On Sat, 19 Feb 2011 13:45:31 +1300, "Pete Dashwood"
>>> <dashw...@removethis.enternet.co.nz> wrote:
>>
>>>> Michael Wojcik wrote:
>>
>>> Part of the difference may be in the cost of online access and the
>>> value to the organization. How many credit card transactions are
>>> needed to pay for the equipment, line or telephone costs, and fees?
>>
>> A good try, Clark but it doesn't stand inspection.
>>
>> Business ALREADY have telephones. There is NO extra charge for ADSL
>> traffic on a line which is already paid for.
>
> Wrong; 20 pounds per calendar month in addition to the standard line
> rental.

OK, so 5 quid a week... hardly going to break the bank, for a business.

Pete.

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


0
Pete
2/19/2011 10:08:34 AM
Alistair Maclean wrote:
> On Feb 19, 7:26 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> docdw...@panix.com wrote:
>>> In article <8s8imfFat...@mid.individual.net>,
>>> Pete Dashwood <dashw...@removethis.enternet.co.nz> wrote:
>>
>>> [snip]
>>
>>>> Out here on the cutting edge of computer technology we sometimes
>>>> forget that the rest of the world has some catching up to do... :-)
>>
>>> Does 'catching up' include reducing its total population - and its
>>> associated data volume - to a quantity known in other parts of the
>>> globe as 'an almost-large city'?
>>
>> Tee hee... :-)
>>
>> I knew there would be a few rise to the bait, but I didn't expect
>> you to be one of them, Doc...
>>
>> You are right, of course.
>>
>> We have 4 million here and are already starting to feel crowded.
>>
>> I always used to joke in England that the population of NZ was
>> roughly the same as North London... :-)
>>
>> Australia, on the other hand, has around 24 million and they have
>> pretty much the same technology we have. I can't think offhand of an
>> "almost-large city" in the United States that has 24 million people
>> living in it. (28 million if you bundle us in as well.) It is
>> interesting that EFTPOS cards issued in NZ work fine in Australia
>> and vice versa. I can get cash from an Australian ATM and my NZ
>> account is updated in real time. I can pay for dinner in an
>> Australian restaurant using my NZ EFTPOS and again my account is
>> updated immediately. (This is 24/7, no batch...) I believe
>> Australians visiting NZ enjoy the same facility.)
>>
>
> I have worked for card processors and they had massive batch systems.
> You can make a batch system look like online realtime by a number of
> means usually involving batching a day's updates and processing at
> night.

Except that if I do a balance enquiry immediately it shows the updated 
balance.

I'm not speculating about how "card processors" you have worked for may 
work. I believe what you say. (perhaps you might afford me the same 
courtesy?)

I am discussing EFTPOS as implemented here in NZ (and Australia), based on 
recent first hand experience.

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


0
Pete
2/19/2011 10:19:16 AM
Alistair Maclean wrote:
> On Feb 18, 8:09 am, Michael Wojcik <mwoj...@newsguy.com> wrote:
>> Fred Mobach wrote:
>>
>>> Batch processing (not necessarily with COBOL) is not yet going away,
>
> Surely the killer resolution is:
>
>  Online realtime update is batch processing with a batch size of 1.

:-)

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


0
Pete
2/19/2011 10:19:59 AM
In article <8s99l0F6klU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>docdwarf@panix.com wrote:
>> In article <8s8imfFataU1@mid.individual.net>,
>> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>>
>> [snip]
>>
>>> Out here on the cutting edge of computer technology we sometimes
>>> forget that the rest of the world has some catching up to do... :-)
>>
>> Does 'catching up' include reducing its total population - and its
>> associated data volume - to a quantity known in other parts of the
>> globe as 'an almost-large city'?
>
>Tee hee... :-)
>
>I knew there would be a few rise to the bait, but I didn't expect you to be 
>one of them, Doc...
>
>You are right, of course.

'Treating the chum (used in the sense of 
http://www.merriam-webster.com/dictionary/chum?show=2&t=1298123108 ) with 
appropriate respect' is not rising to the bait, Mr Dashwood.  Those who 
have studied such concepts as 'economy of scale' might have come to a 
similar conclusion...

.... while those with enough Data Processing experience to have learnt that 
one of the first questions asked should be 'what is the expected 
transaction volume per period?' *should* have come to a similar 
conclusion.

[snip]

>Australia, on the other hand, has around 24 million and they have pretty 
>much the same technology we have. I can't think offhand of an "almost-large 
>city" in the United States that has 24 million people living in it.

The United States of America contains fifty states, Mr Dashwood... and of 
those (according to 
http://en.wikipedia.org/wiki/List_of_United_States_states_by_population ) 
there are two exceeding that entire country.

Three hundred million and change people generate, by some standards, a 
fair chunk of data to keep track of.

[snip]

>In the final analysis it comes down to will and attitude. If people WANT a 
>better solution, they will get one. The rising generation are very much 
>aware of this and they are the business owners of tomorrow.

We might find ourselves in disagreement here, Mr Dashwood... the people 
may WANT a variety of things but when a business determines that a method 
Saves Money the struggle between desires and dollars-down might grown a 
bit intricate.

>
>As I have remarked elsewhere, time will tell.
>
>>
>> As those who have had a couple of things dropped on their feet may
>> have learned: a difference in quantity may make for a difference in
>> quality.
>>
>OK, but it is no excuse to cling to the LCD...:-)

I try to leave hardware problems to systems folks.

DD

0
docdwarf
2/19/2011 1:57:28 PM
On Fri, 18 Feb 2011 19:48:54 -0700, Howard Brazee <howard@brazee.net>
wrote:

>On Sat, 19 Feb 2011 13:45:31 +1300, "Pete Dashwood"
><dashwood@removethis.enternet.co.nz> wrote:
>
>>> We were just discussing this a couple of weeks ago.
>>
>>Thanks Michael.
>>
>>Sorry to hear the US is such an IT backwater... :-)
>>
>>Watch it change over time.
>
>Sometimes being first can be a disadvantage.   Countries that weren't
>as invested in phone land-lines found it easier to move to cellular.
>
>And the first countries to offer HDTV had analog HDTVs that weren't
>nearly as good as the digital versions that came later.

In addition, many telecom companies in Europe were subsidized by their
governments where in the US they are all private, publicly traded
industries.  

Regards,
-- 

          ////
         (o o)
-oOO--(_)--OOo-

"Just remember...if the world didn't suck, we'd all fall off."
Trevor Myers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve
0
SkippyPB
2/19/2011 5:21:03 PM
On Sat, 19 Feb 2011 23:19:16 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Alistair Maclean wrote:
>> On Feb 19, 7:26 am, "Pete Dashwood"
>> <dashw...@removethis.enternet.co.nz> wrote:
>>> docdw...@panix.com wrote:
>>>> In article <8s8imfFat...@mid.individual.net>,
>>>> Pete Dashwood <dashw...@removethis.enternet.co.nz> wrote:
>>>
>>>> [snip]
>>>
>>>>> Out here on the cutting edge of computer technology we sometimes
>>>>> forget that the rest of the world has some catching up to do... :-)
>>>
>>>> Does 'catching up' include reducing its total population - and its
>>>> associated data volume - to a quantity known in other parts of the
>>>> globe as 'an almost-large city'?
>>>
>>> Tee hee... :-)
>>>
>>> I knew there would be a few rise to the bait, but I didn't expect
>>> you to be one of them, Doc...
>>>
>>> You are right, of course.
>>>
>>> We have 4 million here and are already starting to feel crowded.
>>>
>>> I always used to joke in England that the population of NZ was
>>> roughly the same as North London... :-)
>>>
>>> Australia, on the other hand, has around 24 million and they have
>>> pretty much the same technology we have. I can't think offhand of an
>>> "almost-large city" in the United States that has 24 million people
>>> living in it. (28 million if you bundle us in as well.) It is
>>> interesting that EFTPOS cards issued in NZ work fine in Australia
>>> and vice versa. I can get cash from an Australian ATM and my NZ
>>> account is updated in real time. I can pay for dinner in an
>>> Australian restaurant using my NZ EFTPOS and again my account is
>>> updated immediately. (This is 24/7, no batch...) I believe
>>> Australians visiting NZ enjoy the same facility.)
>>>
>>
>> I have worked for card processors and they had massive batch systems.
>> You can make a batch system look like online realtime by a number of
>> means usually involving batching a day's updates and processing at
>> night.
>
>Except that if I do a balance enquiry immediately it shows the updated 
>balance.
>
>I'm not speculating about how "card processors" you have worked for may 
>work. I believe what you say. (perhaps you might afford me the same 
>courtesy?)
>
>I am discussing EFTPOS as implemented here in NZ (and Australia), based on 
>recent first hand experience.
>
>Pete.

Just because someone uses EFTPOS doesn't mean there is no batch
involved.  My own first hand experience says that balances are indeed
updated immediately from EFTPOS (we call it a memo balance), however
the transactions are logged, the memo thrown away at night and the
transactions are run through batch at night.

Regards,
-- 

          ////
         (o o)
-oOO--(_)--OOo-

"Just remember...if the world didn't suck, we'd all fall off."
Trevor Myers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve
0
SkippyPB
2/19/2011 5:25:57 PM
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message 
news:8s99l0F6klU1@mid.individual.net...

<snip>

> Draw your own conclusions as to why there is no upswing in immediate 
> processing. I suspect the reason it may not be sweeping America is because 
> there is a vested interest in swipe machines and carbon forms... and, you 
> DO have to educate a population into thinking 21st century technology and 
> getting away from paper. I understand many people in this forum are still 
> getting paper Bank and Credit Card statements (to me, and the majority of 
> Kiwis, that is just archaic and we haven't done it for years.) BUT, it all 
> requires a change in attitude and that takes time. (For many years I was 
> happy ot get a paper statement; now it just strikes me as laughable.)
>

Except for depositing checks I do my banking online and pay most of my bills 
that way as well.  However I still like to get bank statments sent in the 
mail, not because I can't do it online, but because I want to be absolutely 
certain that the bank has my correct address.  If my identity were to be 
stolen and my address changed then not receiving a statement would be a 
signal.  Yes I can check this online but I like having a backup.

I do not remember the last time any business swiped my card and gave me a 
paper receipt.  There is one doctor's office that does not accept debit 
cards so I must pay by cash or check.  While travelling all over the states 
of the western U.S. there were some gas stations that would not accept by 
debit card as a debit transaction, but they all accepted it as a credit card 
transaction.  I have even used my debit card overseas in the Philippines.

Last week I made a withdrawal at an ATM machine at my bank.  It churned for 
a while and gave me a receipt but not my money. This is the only time this 
has ever happened to me.  I went inside the bank and they called the 
department that handles this situation and the person I talked to could 
communicate with the ATM machine and check whether or not it had registered 
the problem.  It turns out it did not register it, nevertheless the 
withdrawal amount was returned to my account within a couple of hours.


<snip> 


0
Charles
2/19/2011 6:54:27 PM
"SkippyPB" <swiegand@Nospam.neo.rr.com> wrote in message 
news:75vvl697fbdkkv60fhrkeeg77v0vt452v8@4ax.com...

<snip>

> Just because someone uses EFTPOS doesn't mean there is no batch
> involved.  My own first hand experience says that balances are indeed
> updated immediately from EFTPOS (we call it a memo balance), however
> the transactions are logged, the memo thrown away at night and the
> transactions are run through batch at night.

I notice that some transactions are listed as "pending".  My salary may 
appear as a pending deposit three or four days before it it actually in my 
account.  I once worked  in payroll and implemented EFT via ACH (Automated 
Clearing House) transactions.  We transmitted the paycheck information ahead 
of time but the transaction contained a date that controlled when the bank 
could actually deposit the money. Some gas station transactions appear as 
"pending $1 withdrawal,  amount may change".  I believe this is due to 
processing by the gas station business and not my bank..  Also deposits are 
credited the same day if made before a certain time.  All of this indicates 
to be that while online posting is  being done there is also batch 
processing involved.

<snip>



0
Charles
2/19/2011 7:07:04 PM
In article <1suvl61bkcah13rcfm7v6la90jkgdr21ve@4ax.com>,
SkippyPB  <swiegand@Nospam.neo.rr.com> wrote:
>On Fri, 18 Feb 2011 19:48:54 -0700, Howard Brazee <howard@brazee.net>
>wrote:

[snip]

>>Sometimes being first can be a disadvantage.   Countries that weren't
>>as invested in phone land-lines found it easier to move to cellular.
>>
>>And the first countries to offer HDTV had analog HDTVs that weren't
>>nearly as good as the digital versions that came later.
>
>In addition, many telecom companies in Europe were subsidized by their
>governments where in the US they are all private, publicly traded
>industries.  

It reminds me of a Revelation I experienced, decades on back.  Granted 
that things have changed a bit over time but there still might be a kernel 
of accuracy to it.

There are several types of business where you can, make a lot of money for 
Doing Nothing.  The first of these is by being a bank... all ya gotta do 
is hang out a large enough sign saying 'We Are a Bank' and folks will come 
to your door and say 'Please... take my money.'

(those who recall the great Savings and Loan Fiasco (yes, I know that a 
'Savings and Loan Company' is not a bank... technically... might want to 
test this evaluation against it)

Next is insurance.  Once again, a large enough sign saying 'We Sell 
Insurance' will have folks breaking down your doors and saying 'Please... 
take my money'.

Then there's communication.  For *that* you have to do a bit of work, like 
stringing up a wire.  Then, sure enough, folks will come to your door and 
say 'Please, take my money for a bit of time on your wire'.

In older societies - such as one finds in Europe - this is all recognised 
and not spoken-of in public... and such money-making do-nothing companies 
are controlled by the *biggest* Do-Nothings of all... the State:  Bank of 
State, Insurance Company of State, Telecomm of State... all 
well-established and with folks breaking down the doors, saying 'Please... 
take my money'.

DD

0
docdwarf
2/20/2011 2:02:45 AM
>>> On 2/19/2011 at 10:25 AM, in message
<75vvl697fbdkkv60fhrkeeg77v0vt452v8@4ax.com>,
SkippyPB<swiegand@Nospam.neo.rr.com> wrote:
> On Sat, 19 Feb 2011 23:19:16 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
> 
>>Alistair Maclean wrote:
>>> On Feb 19, 7:26 am, "Pete Dashwood"
>>> <dashw...@removethis.enternet.co.nz> wrote:
>>>> docdw...@panix.com wrote:
>>>>> In article <8s8imfFat...@mid.individual.net>,
>>>>> Pete Dashwood <dashw...@removethis.enternet.co.nz> wrote:
>>>>
>>>>> [snip]
>>>>
>>>>>> Out here on the cutting edge of computer technology we sometimes
>>>>>> forget that the rest of the world has some catching up to do... :-)
>>>>
>>>>> Does 'catching up' include reducing its total population - and its
>>>>> associated data volume - to a quantity known in other parts of the
>>>>> globe as 'an almost-large city'?
>>>>
>>>> Tee hee... :-)
>>>>
>>>> I knew there would be a few rise to the bait, but I didn't expect
>>>> you to be one of them, Doc...
>>>>
>>>> You are right, of course.
>>>>
>>>> We have 4 million here and are already starting to feel crowded.
>>>>
>>>> I always used to joke in England that the population of NZ was
>>>> roughly the same as North London... :-)
>>>>
>>>> Australia, on the other hand, has around 24 million and they have
>>>> pretty much the same technology we have. I can't think offhand of an
>>>> "almost-large city" in the United States that has 24 million people
>>>> living in it. (28 million if you bundle us in as well.) It is
>>>> interesting that EFTPOS cards issued in NZ work fine in Australia
>>>> and vice versa. I can get cash from an Australian ATM and my NZ
>>>> account is updated in real time. I can pay for dinner in an
>>>> Australian restaurant using my NZ EFTPOS and again my account is
>>>> updated immediately. (This is 24/7, no batch...) I believe
>>>> Australians visiting NZ enjoy the same facility.)
>>>>
>>>
>>> I have worked for card processors and they had massive batch systems.
>>> You can make a batch system look like online realtime by a number of
>>> means usually involving batching a day's updates and processing at
>>> night.
>>
>>Except that if I do a balance enquiry immediately it shows the updated 
>>balance.
>>
>>I'm not speculating about how "card processors" you have worked for may 
>>work. I believe what you say. (perhaps you might afford me the same 
>>courtesy?)
>>
>>I am discussing EFTPOS as implemented here in NZ (and Australia), based 
> on 
>>recent first hand experience.
>>
>>Pete.
> 
> Just because someone uses EFTPOS doesn't mean there is no batch
> involved.  My own first hand experience says that balances are indeed
> updated immediately from EFTPOS (we call it a memo balance), however
> the transactions are logged, the memo thrown away at night and the
> transactions are run through batch at night.


This is exactly how we do our processing.  You can do many types of
electronic transfers (card, internet, telephone, etc.) during the day. 
These are "memo-posted" so they affect available balance immediately.  But
they do not affect ledger balance until batch posting that night.

And then there are POS authorizations, which may not post for several days. 
This is because in the "signature based" credit/debit card world most online
 transactions (in the U.S., in any case) are "authorization only"
transactions.  The actual transactions that post are based on "closing the
batch" on the merchant's ETC (Electronic Ticket Capture) machine.  Those
batches are then sent to the merchant's card processor who in turn batches
those up for their many merchants and sends them to the appropriate card
association (Visa, MasterCard, probably Amex and Discover as well).  The
card association then sends batches of transactions to each card issuer, and
only then will the issuer post them to the customer. 

Frank
 

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403

0
Frank
2/21/2011 5:51:13 PM
In article <4D6243A1.6F0F.0085.0@efirstbank.com>,
Frank Swarbrick <Frank.Swarbrick@efirstbank.com> wrote:
>>>> On 2/19/2011 at 10:25 AM, in message
><75vvl697fbdkkv60fhrkeeg77v0vt452v8@4ax.com>,
>SkippyPB<swiegand@Nospam.neo.rr.com> wrote:
>> On Sat, 19 Feb 2011 23:19:16 +1300, "Pete Dashwood"
>> <dashwood@removethis.enternet.co.nz> wrote:

[snip - I hope I kept the attributions right]

>>>I am discussing EFTPOS as implemented here in NZ (and Australia), based on 
>>>recent first hand experience.
>>>
>>>Pete.
>> 
>> Just because someone uses EFTPOS doesn't mean there is no batch
>> involved.  My own first hand experience says that balances are indeed
>> updated immediately from EFTPOS (we call it a memo balance), however
>> the transactions are logged, the memo thrown away at night and the
>> transactions are run through batch at night.
>
>
>This is exactly how we do our processing.  You can do many types of
>electronic transfers (card, internet, telephone, etc.) during the day. 
>These are "memo-posted" so they affect available balance immediately.  But
>they do not affect ledger balance until batch posting that night.
>
>And then there are POS authorizations, which may not post for several days. 
>This is because in the "signature based" credit/debit card world most online
> transactions (in the U.S., in any case) are "authorization only"
>transactions.  The actual transactions that post are based on "closing the
>batch" on the merchant's ETC (Electronic Ticket Capture) machine.  Those
>batches are then sent to the merchant's card processor who in turn batches
>those up for their many merchants and sends them to the appropriate card
>association (Visa, MasterCard, probably Amex and Discover as well).  The
>card association then sends batches of transactions to each card issuer, and
>only then will the issuer post them to the customer. 

What's this... *dare* someone imply that Common Practise - let alone Best 
Practises - might, just possibly, be different in other parts of the world 
than they are in the Antipodes?

It might be wise to remember that a difference in quantity can make for a 
difference in quality... dealing with three or four time-zones might not 
be the same as dealing with a score or more, dealing with the data 
generated by (one million transactions per unit of time) might not be the 
same as dealing with the data generated by (one thousand million 
transactions per unit of time) and approaching a table with six thousand 
rows might be done with an approach that differs from approaching one with 
sixty million.

DD

0
docdwarf
2/21/2011 9:03:12 PM
docdwarf@panix.com wrote:
> In article <4D6243A1.6F0F.0085.0@efirstbank.com>,
> Frank Swarbrick <Frank.Swarbrick@efirstbank.com> wrote:
>>>>> On 2/19/2011 at 10:25 AM, in message
>> <75vvl697fbdkkv60fhrkeeg77v0vt452v8@4ax.com>,
>> SkippyPB<swiegand@Nospam.neo.rr.com> wrote:
>>> On Sat, 19 Feb 2011 23:19:16 +1300, "Pete Dashwood"
>>> <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip - I hope I kept the attributions right]
>
>>>> I am discussing EFTPOS as implemented here in NZ (and Australia),
>>>> based on recent first hand experience.
>>>>
>>>> Pete.
>>>
>>> Just because someone uses EFTPOS doesn't mean there is no batch
>>> involved.  My own first hand experience says that balances are
>>> indeed updated immediately from EFTPOS (we call it a memo balance),
>>> however the transactions are logged, the memo thrown away at night
>>> and the transactions are run through batch at night.
>>
>>
>> This is exactly how we do our processing.  You can do many types of
>> electronic transfers (card, internet, telephone, etc.) during the
>> day. These are "memo-posted" so they affect available balance
>> immediately.  But they do not affect ledger balance until batch
>> posting that night.
>>
>> And then there are POS authorizations, which may not post for
>> several days. This is because in the "signature based" credit/debit
>> card world most online transactions (in the U.S., in any case) are
>> "authorization only" transactions.  The actual transactions that
>> post are based on "closing the batch" on the merchant's ETC
>> (Electronic Ticket Capture) machine.  Those batches are then sent to
>> the merchant's card processor who in turn batches those up for their
>> many merchants and sends them to the appropriate card association
>> (Visa, MasterCard, probably Amex and Discover as well).  The card
>> association then sends batches of transactions to each card issuer,
>> and only then will the issuer post them to the customer.
>
> What's this... *dare* someone imply that Common Practise - let alone
> Best Practises - might, just possibly, be different in other parts of
> the world than they are in the Antipodes?
>
Go fuck yourself, Doc.

> It might be wise to remember that a difference in quantity can make
> for a difference in quality... dealing with three or four time-zones
> might not be the same as dealing with a score or more, dealing with
> the data generated by (one million transactions per unit of time)
> might not be the same as dealing with the data generated by (one
> thousand million transactions per unit of time) and approaching a
> table with six thousand rows might be done with an approach that
> differs from approaching one with sixty million.
>
> DD

This is just silly and not what I said or intended.

My objections to batch processing are on philosophical grounds which nobody 
has bothered to address. (With the possible exception of Michael's post 
where he did look at some cases where you probably would need batch 
processing.)

Instead, a bunch of posts about how important batch processing is in the 
scheme of things and how it MIGHT be the processing method for certain types 
of transaction.

(I was foolish enough to get drawn into this by pointing out that we manage 
to process EFTPOS transactions here without significant batch processing, 
which serves to illustrate that you don't HAVE to do everythng in sequential 
batches. But that is really irrelevant to the underlying idea of WHY batch 
processing isn't necessary in a Networked environment.)

It's like trying to have a discussion about the colour red with a blind man.

My own fault and I blame nobody but myself.

I really don't care. There are much more important things going on here.

I won't be posting further on this, and anyone who is actually interested in 
understanding WHY I hold the position I do on Batch processing can mail me 
privately.

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


0
Pete
2/22/2011 6:05:05 AM
In article <8sh20kFfvfU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>docdwarf@panix.com wrote:
>> In article <4D6243A1.6F0F.0085.0@efirstbank.com>,
>> Frank Swarbrick <Frank.Swarbrick@efirstbank.com> wrote:
>>>>>> On 2/19/2011 at 10:25 AM, in message
>>> <75vvl697fbdkkv60fhrkeeg77v0vt452v8@4ax.com>,
>>> SkippyPB<swiegand@Nospam.neo.rr.com> wrote:
>>>> On Sat, 19 Feb 2011 23:19:16 +1300, "Pete Dashwood"
>>>> <dashwood@removethis.enternet.co.nz> wrote:
>>
>> [snip - I hope I kept the attributions right]
>>
>>>>> I am discussing EFTPOS as implemented here in NZ (and Australia),
>>>>> based on recent first hand experience.
>>>>>
>>>>> Pete.
>>>>
>>>> Just because someone uses EFTPOS doesn't mean there is no batch
>>>> involved.

[snip]

>>> This is exactly how we do our processing.

[snip]

>> What's this... *dare* someone imply that Common Practise - let alone
>> Best Practises - might, just possibly, be different in other parts of
>> the world than they are in the Antipodes?
>>
>Go fuck yourself, Doc.

Please be so kind as to follow your own advice, Mr Dashwood.

This should be placed aside; there are matters of greater importance to 
deal with in Christchurch.

DD

0
docdwarf
2/22/2011 12:36:53 PM
Reply:

Similar Artilces:

""""""""""""""""""""""ADD ME""""""""""""""""""""
Hi , Hope you are doing great. Please let me take this opportunity to introduce myself, Iam Karthik working with BhanInfo Inc, a NY based company. We have consultants on our bench on various technologies, my request is to add me to your distribution list and kindly do send me the requirements. i have the below list available 1. Mainframe 2. Java 3.. Financial Analyst 4. Data Architect If there is any vendor ship agreement which has to be signed then I would like to take an opportunity to represent my company and expect your cooperation... We look forward to build a ve...

"""""""""ADD ME""""""""""
Hi , Hope you are doing great. Please let me take this opportunity to introduce myself, Iam Karthik working with BhanInfoi Inc, a NY based company. We have consultants on our bench on various technologies, my request is to add me to your distribution list and kindly do send me the requirements. i have the below list available 1. Mainframe 2. Java 3.. Financial Analyst 4. Data Architect If there is any vendor ship agreement which has to be signed then I would like to take an opportunity to represent my company and expect your cooperation... ...

Urgent Requirement in """""""""""""NEW YORK""""""""""""""""
Hello Partners, Please find the requirement below. Please send the updated resume along with rate and contact no. REQ#1: Title : Java Developer ( Rating Project) Duration : 6 months Rate : open Location : NY strong java, WebLogic 9.2, Web Services, Oracle REQ#2: Title : Java Developer Duration : 4 months Rate : open Location : NY Strong java, SQL REQ#3: Title : VB.Net Consultant Location : NY Duration : 4 months Rate : open Primarily looking at someone who has Excel, VB.net a...

"/a" is not "/a" ?
Hi everybody, while testing a module today I stumbled on something that I can work around but I don't quite understand. >>> a = "a" >>> b = "a" >>> a == b True >>> a is b True >>> c = "/a" >>> d = "/a" >>> c == d True # all good so far >>> c is d False # eeeeek! Why c and d point to two different objects with an identical string content rather than the same object? Manu Emanuele D'Arrigo wrote: >>>> c = "/a" >>>&...

"or" and "and"
Hi, I'm just getting to discover ruby, but I find it very nice programming language. I just still don't understand how the "or" and "and" in ruby... I was playing with ruby and for example made a def to print Stem and Leaf plot (for those who didn't have a statistics course or slept on it, e.g. http://cnx.org/content/m10157/latest/) Here is the Beta version of it: class Array def n ; self.size ; end def stem_and_leaf(st = 1) # if st != (2 or 5 or 10) then ; st = 1 ; end k = Hash.new(0) self.each {|x| k[x.to_f] += 1 } k = k.sort{|a, b| a[0].to_f <=&g...

"out" and "in out"
Hi i found the following explaination: In Ada, "in" parameters are similar to C++ const parameters. They are effectively read-only within the scope of the called subprogram. Ada "in out" parameters have a reliable initial value (that passed in from the calling subprogram) and may be modified within the scope of the called procedure. Ada "out" parameters have no reliable initial value, but are expected to be assigned a value within the called procedure. What does "have no reliable initial value" mean when considering the "out" parameter? By c...

"my" and "our"
Hi, while testing a program, I erroneously declared the same variable twice within a block, the first time with "my", the second time with "our": { my $fz = 'VTX_Link'; .... ( around 200 lines of code, all in the same block) our $fz = 'VTX_Linkset'; ... } So the initial contents of the $fz declared with "my" is lost, because "our" creates a lexical alias for the global $fz, thus overwriting the previous "my" declaration. It was my error, no question. But I wonder why Perl doesn't mention this - even with "use s...

"If then; if then;" and "If then; if;"
I have a raw data set which is a hierarchical file: H 321 s. main st P Mary E 21 F P william m 23 M P Susan K 3 F H 324 S. Main St I use the folowing code to read the data to creat one observation per detail(P) record including hearder record(H): data test; infile 'C:\Documents and Settings\retain.txt'; retain Address; input type $1. @; if type='H' then input @3 Address $12.; if type='P' then input @3 Name $10. @13 Age 3. @16 Gender $1.; run; but the output is not what I want: 1 321 s. main H 2 321 s. main P Mary E 21 F 3 321 s...

about "++" and "--"
why this program snippet display "8,7,7,8,-7,-8" the program is: main() { int i=8; printf("%d\n%d\n%d\n%d\n%d\n%d\n",++i,--i,i++,i--,-i++,-i--); } > why this program snippet display "8,7,7,8,-7,-8" Ask your compiler-vendor because this result is IMHO implementation-defined. Check this out: http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.15 http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.16 Regards, Irina Marudina fxc123@gmail.com wrote: > why this program snippet display "8,7,7,8,-7,-8&q...

why "::", not "."
Why does the method of modules use a dot, and the constants a double colon? e.g. Math::PI and Math.cos -- Posted via http://www.ruby-forum.com/. On Oct 26, 2010, at 01:48 , Oleg Igor wrote: > Why does the method of modules use a dot, and the constants a double > colon? > e.g. > Math::PI and Math.cos For the same reason why inner-classes/modules use double colon, because = they're constants and that's how you look up via constant namespace. Math::PI and ActiveRecord::Base are the same type of lookup... it is = just that Base is a module and PI is a float....

Urgent Requirement for """""""""""""""INFORMATICA DEVELOPER"""""""""""""
Hello Partners, How are you ? Please find the requirements below. Title: Database/ETL Developer Duration: 6 months Location: NY Exp: 7+ Locals preferred Database/ETL requirements (Mandatory) Candidate must have worked with financial instruments, preferably Mutual Funds but, Equities are also ok. PL/SQL - packages, Stored procs, Functions, Aggregate functions, Pipelined Functions Informatica 8.6 - especially complex mappings, complex maplets, complex workflows, transformations Oracle 10g/11g Unix/Linux shell scripting ...

Urgent need """""""""""INFORMATICA DEVELOPER"""""""""""""
Hello Partners, How are you ? Please find the requirements below. Title: Database/ETL Developer Duration: 6 months Location: NY Exp: 7+ Locals preferred Database/ETL requirements (Mandatory) Candidate must have worked with financial instruments, preferably Mutual Funds but, Equities are also ok. PL/SQL - packages, Stored procs, Functions, Aggregate functions, Pipelined Functions Informatica 8.6 - especially complex mappings, complex maplets, complex workflows, transformations Oracle 10g/11g Unix/Linux shell scripting Database/ETL requirements (Optional) ...

"In" "Out" and "Trash"
I just bought a new computer and I re-installed Eudora Light on my new computer. But when I open Eudora, the "In", "Out" and "Trash" links are not on the left side of the screen the way they were on my old computer. How can I get these links back on the left side of the screen? Thank you. On 25 Mar 2007 09:49:22 -0700, "abx" <abfunex@yahoo.com> wrote: >I just bought a new computer and I re-installed Eudora Light on my new >computer. But when I open Eudora, the "In", "Out" and "Trash" links >are ...

A problem about "[ ]" "( )" "="
I want to read several images saved in a director,and give them to I1,I2 ,I3....,using the following codes: filelist=dir(['c:\MATLAB701\work\...\*.jpg']); for i=1 :length(filelist) I=imread(fullfile('c:\MATLAB701\work\...',filelist(i).name)); end; but failed. Then I used I(i)=imread... ,still failed. How could I do? "John" <mailofww@126.com> wrote in message news:ef19e12.-1@webx.raydaftYaTP... >I want to read several images saved in a director,and give them to > I1,I2 ,I3....,using the following codes: > filelist=dir(['c:\MATLAB701\work\.....

Web resources about - IBM "preview" of "major" (???) enhancements for mainframe COBOL - comp.lang.cobol

Resources last updated: 2/5/2016 11:25:47 PM