Cobol - Hard Copy reports (was: Regular Expressions and Standard COBOL

Author

Hard Copy reports (was: Regular Expressions and Standard COBOL

William M. Klein

2007-07-07, 7:55 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5f8o2sF3amt6qU1@mid.individual.net...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:23vs83hk665ks484ctf7vdcsspi79erhaq@
4ax.com...
<snip>[color=darkred]
>
> That's the nub of it. Until people start to realise that paper reports are
> really not as valuable as they have been any more, there will continue to be
> managers who demand them. These days it is about INFORMATION. It needs to be
> timely (up to the millisecond), easily digestible (graphic and summarised,
> with drill down capabilities) and it should only be committed to paper as a
> last resort.

Pete,
As I don't work (much less in "Fortune 500-type companies", I am curious
whether current "big company" requirements by Auditors - and especially (in the
US) with new "regulatory requirements" allows for 'non-hard-copy solutions.
This really is a question on my part and not intended to argue with what you
posted.

It seems to me that for "day-to-day" buiseness needs - having "real time access
to information" is the critical requirement of much of IT. On the other hand,
for "tracking and auditor and regulation" purposes, it seems to me that the need
for (remarkly frequently changing) hard-copy reports is growing, not
diminishing.

As a COBOL report writer fan, these types of reports can EASILY be produced and
modified in COBOL. As a "Workstaion-attached PDF and 'graphic' report fan, I
would think that COBOL is not a good (much less the best) tool for the job.>

P.S. "Monthly" hard-copy (or soft - but looks like hard copy) bills are anoterh
place where "batch COBOL-type" processing works well - IMHO. Again, although
many/most "customers" like real-time online access to the current state of their
accounts/bills, at least in the US, I still see that most such buisness still
provide a hard-copy (or looks like hard-copy) version of monthly
bills/statements. We (CLC) have discussed such things before, however, I know of
few "large companies" that have converted their "traditional procedural"
applications for such bill/statement processing to OO - even if they DO provide
"real time" versions of the information via OO applications.

Are you (Pete or anyone else) aware of any large companies that still produce
monthly (or quarterly or year-end) bills/statementes that have converted such
procesisng to any OO solution? I would think there must be SOME somewhere, but
I certainly haven't heard of this being common.

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

Pete Dashwood

2007-07-07, 6:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:DRKji.112754$Xu1.100559@fe07.news.easynews.com...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5f8o2sF3amt6qU1@mid.individual.net...
> <snip>
>
> Pete,
> As I don't work (much less in "Fortune 500-type companies", I am curious
> whether current "big company" requirements by Auditors - and especially
> (in the US) with new "regulatory requirements" allows for 'non-hard-copy
> solutions. This really is a question on my part and not intended to argue
> with what you posted.
>

Auditors here require reports, BUT they are pleased to accept them in
computer sensible form. Random checks can be made online and only
hard-copied if there is something untoward or needing further investigation.

Obviously, it may be different in the US.

> It seems to me that for "day-to-day" buiseness needs - having "real time
> access to information" is the critical requirement of much of IT. On the
> other hand, for "tracking and auditor and regulation" purposes, it seems
> to me that the need for (remarkly frequently changing) hard-copy reports
> is growing, not diminishing.

I haven't seen that. Most places I have worked are committed to cutting down
on paper rather than increasing it. Spreadsheets and databases seem to be
replacing what used to be reports in many cases. This means users can
manipulate the data into whatever format they want and filter the stuff they
are not interested in. Kind of like a flexible report format... Only when it
is organised how they want it, MIGHT they then print it, although this is
generally discouraged in the places I've worked here.

It is certainly true that this is becoming more the norm, as more users
become "computer literate" and deal with spreadsheets and databases as a
matter of course. Previously, (before PCs and people growing up with them)
it wasn't possible, as the user was not capable of extracting data himself
and had to go to the IT department to get anything done. This is changing,
and it is PC technology ( and the network) which has empowered it.

>
> As a COBOL report writer fan, these types of reports can EASILY be
> produced and modified in COBOL. As a "Workstaion-attached PDF and
> 'graphic' report fan, I would think that COBOL is not a good (much less
> the best) tool for the job.>

In some places they will have no choice other than to do them in COBOL. If
the data is in VSAM or ISAM files it is not easily interchangeable to other
software and needs to have programs written to extract it. If it is on a
database, ODBC means that the whole network has access to it (given the
appropriate permissions, of course) and so there is no need for Report
Writer.

>
> P.S. "Monthly" hard-copy (or soft - but looks like hard copy) bills are
> anoterh place where "batch COBOL-type" processing works well - IMHO.

Yes, it does. And has done so for many years. But the world is changing, and
so are the people in it. Many people (self included) DON'T want "monthly"
bills and statements. Rather they want to see all their transactions for a
period they can call off themselves. My bank offers this facility and has
done for a number of years now. I believe the percentage of customers using
it is over 60% and increasing. The bank has saved a fortune by encouraging
people to move off paper statements. But it does mean smarter systems and
more transaction processing power. Coincidentally, the same bank moved off
their mainframes about 5 years ago. It was very hard for them and cost a
fortune. They had a project in Sydney that cost several hundred million
dollars (I know a couple of the people who worked on it). It was almost a
disaster and was only salvaged by rescoping and increasing the budget. The
point is that they didn't get to the very desirable state they have now,
without considerable pain. But their systems are modern and effective, and I
think if you asked them, they would say the cost was worth it.

I've noticed that more and more organisations are offering "do-it-yourself"
accounts of this nature... American Express and my London Bank are just two
that have moved to it comparatively recently.

> Again, although many/most "customers" like real-time online access to the
> current state of their accounts/bills, at least in the US, I still see
> that most such buisness still provide a hard-copy (or looks like
> hard-copy) version of monthly bills/statements. We (CLC) have discussed
> such things before, however, I know of few "large companies" that have
> converted their "traditional procedural" applications for such
> bill/statement processing to OO - even if they DO provide "real time"
> versions of the information via OO applications.
>

Yes, they are giving people options. Eventually it will be phased out
because the demand for it will dry up... "You get paper statements from your
bank? How quaint..."

It is still possible to get black and white TV. Do you know of anyone who
has one? In the U.K. of course the license fee is cheaper for B/W so that
will encourage some people.

> Are you (Pete or anyone else) aware of any large companies that still
> produce monthly (or quarterly or year-end) bills/statementes that have
> converted such procesisng to any OO solution? I would think there must be
> SOME somewhere, but I certainly haven't heard of this being common.
>

I can't confirm for sure, so I can't comment. Certainly a bank that is
running a completely networked system that uses objects locally and
remotely, along with web services and web based accounting, probably
qualifies. I know a few of these, but I can't confirm that they don't also
still use batch processing for their back office. This comes back to the
discussion we had a while ago about the blurring of front and back office
processing. Eventually, there will only be processing and it will be
transactional. I know of a number (more than 6, less than a dozen) of large
organizations which are moving that way (including my own bank, mentioned
above) but iI cannot confirm that they are there yet.

I think that as the world changes its mind about batch processing and hard
copies, so will the systems. It won't be next w

:-)

Pete.

tlmfru

2007-07-08, 7:55 am

> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5f8o2sF3amt6qU1@mid.individual.net...
> <snip>
are[color=darkred]
to be[color=darkred]
to be[color=darkred]
summarised,[color=darkred]
as a[color=darkred]
>

I would question this. Suppose you have a on-line project status report.
It is up to the second as of 9a.m. but a whole swag of updates and
corrections come by at 9:03a.m. Therefore you must re-query the report at
9:04a.m. And that'll go on all day. If you're going to take action based
on the information that you have available, it by definition is the
information that you have at that point in time, regardless of whether it's
been updated 3 seconds later or not. Sooner or later you have to drop out
of real time and decide what you're going to do. Sooner or later you're
going to have to live with the fact that the decisions you've made may have
been based on slightly out-of-date information. Otherwise you will reread
and reread... ad infinitum and never do anything! Either that or you wait
until some time when you KNOW there aren't going to be any updates for a
while - or mandate it that no updates will occur for an hour or so - which
means that it won't be real time any more anyway.

PL

Pete Dashwood

2007-07-08, 6:55 pm

"tlmfru" <lacey@mts.net> wrote in message
news:kiZji.12420$aP2.11947@newsfe16.lga...
>
> are
> to be
> to be
> summarised,
> as a
>
> I would question this. Suppose you have a on-line project status report.
> It is up to the second as of 9a.m. but a whole swag of updates and
> corrections come by at 9:03a.m. Therefore you must re-query the report
> at
> 9:04a.m. And that'll go on all day. If you're going to take action based
> on the information that you have available, it by definition is the
> information that you have at that point in time, regardless of whether
> it's
> been updated 3 seconds later or not. Sooner or later you have to drop out
> of real time and decide what you're going to do. Sooner or later you're
> going to have to live with the fact that the decisions you've made may
> have
> been based on slightly out-of-date information. Otherwise you will reread
> and reread... ad infinitum and never do anything! Either that or you wait
> until some time when you KNOW there aren't going to be any updates for a
> while - or mandate it that no updates will occur for an hour or so - which
> means that it won't be real time any more anyway.
>
> PL
>

OK, some further clarification...

The on-line status report (under the ideal scenario, which was the basis of
my post and is still being sought by many organizations) would not be "up to
the second as of 9:00 am". It would be in either of two states:

1. As of a specific time which you request. (Could be yesterday, could be
last w

, could be as of 5 minutes ago...)

2. (By default) as of right now.

And yes, you are quite correct that a bunch of events could happen a few
minutes (or seconds) after you looked at it, that invalidate it. BUT,
provided you know the point on the timeline that your information reflects,
you are no worse off than you would be with a batch report dated yesterday.
And at least you CAN re-query (right now) if you suspect something
extraordinary may have happened.

Obviously, to be able to achieve this, the information processing capability
has to be outstanding. The techniques currently employed may not be up to
it (any form of sequential processing, unless it is across a limited result
set on very powerful hardware, is unlikely to do it).

Although this type of information retrieval is already in place in some
organizations, (using conventional data access, but with carefully designed
and networked databases that can leverage parallel processing, and usually
summarized (pivot table or cube)) levels of the data warehouse), it is
limited to only certain applications.

Organizations going down this path will be looking to emerging techniques
for data handling and increases in processor and data storage power, in
order to implement it fully.

This means Query Syntax (which generates Lambda functions that can be
deferred and parallel processed, against any kind of data -not just
Relational -
http://weblogs.asp.net/scottgu/arch...ery-syntax.aspx -
it looks like SQL, and SQL can be easily converted to it, but it is MUCH
more powerful in its execution than existing SQL could ever hope to be),
functional programming, deferred evaluation, and use of multiple cores. This
is without considering new breaktrhroughs in storage technology that mean
much more data can be accessed much faster, and the coming of age of content
addressable stores that will completely change the way data is stored and
accessed.

In fact, I believe the goal of "outstanding information processing
capability" mentioned above will be achieved by 4 factors, some of which are
already here and the others are not more than 10 years away (already
established "proof of concept"...):

1. Query Syntax. (Enabling Lambda functions and deferred processing on
multiple simultaneous cores)
2. New (possibly molecular) storage capability which will pack large amounts
of data into very small spaces so enabling faster access to it.
3. Increased CPU processing power with multiple cores.
4. Exponential increase in Network bandwith, with wireless replacing fiber.

We have the software approaches, can evolve "what we do now" fairly easily
into "what we are gonna do...", and the new technology is hardware
independent; it runs on what we have now, and will run on what we can see in
the medium future.

It won't happen overnight, but there are already organizations who are
moving towards a complete transactional processing model. (I already my
mentioned my Bank, and I know an insurance company who are going completely
to web services and transactional processing, using the network. Currently,
they still use a mainframe as well, but their long term plan is to phase out
and refactor the COBOL based systems on it. The tools outlined above will
make it possible.)

Obviously, Client/Server networks are really not interested in Batch
processing and would much rather see this sidelined to an "offline"
mainframe, or, better still, eliminated altogether.

When you think about it, from the time we first saw green 3270 screens being
driven in 32K from Foreground 1, on a partitioned DOS mainframe, many of us
just wanted ALL processing to work like that...:-)

On-line processing is more fun to write, provides a more timely, more
interactive experience for the user, and enables a far better model of the
real world to be maintained by the system. The only thing that stopped us
doing it long ago was that we simply didn't have the resources to update
everything within a two second envelope. So, we wrote transaction files and
batch processed them later. The batch process can join tables, filter, sort,
do whatever is necessary and (provided it doesn't exceed the Holy Overnight
Batch Window) we are ready to go again the following morning. For data
retrieval we could tolerate it taking a few more seconds, but it would be a
whole lot more pleasant if it didn't.

Try and imagine a Data Warehouse with asynchronous "agents" runnning on
different servers that are constantly consolidating, organizing, building
pivots and cubes, as real time transactions are processed across the
network. As fast as events occur they are processed, and the data model is
accurate to within milliseconds. (Every item timestamped and available to
other reporting agents that can extract data in parallel and asynchronously
bring it to a presentation layer. Then top it off with still further
processes that archive everything.)

It takes a lot of processor power, network capability, and very fast data
storage. Previously, we didn't have it, now we are on the threshold of it.

Within a few years it will be freely available.

Pete.

Howard Brazee

2007-07-09, 9:55 pm

On Mon, 9 Jul 2007 01:44:12 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>1. As of a specific time which you request. (Could be yesterday, could be
>last w

, could be as of 5 minutes ago...)
>
>2. (By default) as of right now.

I haven't had to worry about this - but for some applications "right
now" has to be adjusted to mean "the point of time that this
transaction started". A report that takes 5 minutes to compile in
a real time environment might have some unacceptable blurring.

Sponsored Links