Prev: TRUNC(OPT) vs TRUNC(BIN) on IBM z series was Re: Quicksort recursiv
Next: SPARQL Query Technology
From: Clark F Morris on 15 Jan 2008 21:18
On Tue, 18 Sep 2007 19:09:19 -0500, Robert <no(a)e.mail> wrote:

>On Tue, 18 Sep 2007 14:05:55 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz>
>wrote:
>
>>These decisions are taken at a level that couldn't care less about
>>performance, they care about having to spend a fortune developing and
>>maintaining code for an obsolete paradigm. This is the "hard part" about the
>>decline of COBOL. It simply isn't relevant or viable for large scale system
>>development any more.
>
>Management can change the platform, thus the money going out, without changing the
>paradigm. As a result, we have former mainframe shops how running on Unix that's set up to
>clone the mainframe environment. Cobol programming standards are unchanged, scripts mimic
>JCL, databases are designed to look like VSAM files. I have actually seen database tables
>with a column named FILLER CHAR(200).
>
I also have seen code like this in a shop where I was contracting. It
was interesting to see the decisions made because they went from IBM
mainframe to Unix as a part of the Year 2000 remediation. They
emulated VSAM using SQL and Oracle. As someone who was 60+ at the
time I winced at some of the things I saw. I also would like to have
seen a replacement of most of the systems I worked on. I also would
like to have seen a decent IDE. Uni-SPF wasn't even as powerful as
ISPF for the z/OS let alone what I believe the Microfocus IDE's
probably were capable of. I wonder how much of the advantage C# or
the other OO languages have is the IDEs and repositories associated
with them. If good repository tools were available for the procedural
languages, how much development time would be saved. I know that when
I was on the SHARE/Guide Language Futures Task Force, we considered
that the development of a good repository tool where information about
all the components (record descriptions, fields, programs,
subroutines, business rules, etc.) was stored, kept current and was
accessible and searchable would give major productivity improvements.
Pete's description of the environment he has available when developing
in C# bears out what we said over 20 years ago.

>Old Timers in such shops, I call them Keepers of the PERFORM THRU, are very sensitive to
>challenges to their remaining hegemony. They will viciously fire anyone they see as a
>threat. Even when the person follows their programming standards to the letter.

As someone who fervently believes standards need to keep up to date
and we need easier ways of doing things, I would hope that I would be
embracing new technology that works.
>
>This is not what management intended, but it goes on every day in countless medium sized
>companies. I haven't seen it in large (F-100) companies because .. I don't know ..
>employees are more talented, methodology is followed in spirit rather than letter, Cobol
>is a tiny player in the big IT picture.
From: Clark F Morris on 15 Jan 2008 21:27
On Wed, 19 Sep 2007 13:41:23 +1200, "Pete Dashwood"
<dashwood(a)removethis.enternet.co.nz> wrote:

>
>
>"Robert" <no(a)e.mail> wrote in message
>news:lbq0f35g00rvcfvhlf5glspmnp9p2n07f6(a)4ax.com...
>> On Tue, 18 Sep 2007 08:33:17 -0400, "Charles Hottel"
>> <chottel(a)earthlink.net> wrote:
>>
>>
>>>Thanks. They are replacing the whole system. It is too far along for it to
>>>change unless they stumble and Congress cuts off the money.
>>
>> Bureaucrats are adept at concealing stuumbles. That's their job.
>>
>> Another Cobol shop down the tubes. Why? I submit it was easier to change
>> language than to
>> battle the entrenched Cobol culture i.e. resistance to change.
>
>I don't think so. It is bigger than that. (Although that can certianly be a
>contributing factor. Not all COBOL shops are resistant to change.)
>
>Put yourself in the place of an IT Director with responsibility for a large
>budget.
>
>How can you justify keeping the organization tied to COBOL when systems are
>consistently late, fail to deliver what is needed, and cost a fortune to
>maintain?(Not only that, but even the CEO knows that COBOL has no
>credibility; he reads the airline magazines.. :-))

That is why Vista is years late and lacking many of the promised
features.
>
>The increasing computer literacy in the population means that people will
>simply build their own solutions using spread sheets and databases and
>standard software. This means the information resource is out of control and
>you are responsible for it. Without a VIABLE coherent IT plan, you have
>failed in your job.

Will all of those spreadsheets meet Sarbanes Oxley requirements for
documentation and accountability?
>
>It is very tempting to install a package (SAP, Siebel,ORACLE, etc) to handle
>(and centralize) core processing and get modern quick build applications
>running on the edges of it. Move towards SOA with Java and/or Websphere and
>start showing money is being well spent. IT responsiveness to change and
>delivery of systems can be seen to improve. Consequently, organizational
>morale improves and the Business start to see IT as an asset, rather than
>the enemy...
>
>There is no place for COBOL in such a world.
>
Since at least some in IBM are showing how COBOL code can be a part of
SOA and could be more so if IBM would ever implement the relevant
parts of the 2002 standard, I dispute that statement. I would dispute
it even more heavily if the IDE's available for Websphere provide the
same fullness of support for COBOL that they do for C/C++ and Java.

>Pete.
From: Robert on 16 Jan 2008 01:10
On Tue, 15 Jan 2008 22:18:52 -0400, Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote:

>On Tue, 18 Sep 2007 19:09:19 -0500, Robert <no(a)e.mail> wrote:
>

>>Old Timers in such shops, I call them Keepers of the PERFORM THRU, are very sensitive to
>>challenges to their remaining hegemony. They will viciously fire anyone they see as a
>>threat. Even when the person follows their programming standards to the letter.
>
>As someone who fervently believes standards need to keep up to date
>and we need easier ways of doing things, I would hope that I would be
>embracing new technology that works.

The version of Cobol in wide use has not changed in 22 years, since 1985. During that
time, the number of general purpose computers worldwide went from 30 million to 1 billion.

The 2002 Cobol Standard has been ignored, for the most part, because the 'Cobol community'
does not want change. The purpose of shop standards is to keep change out. It worked.
Problem is, it also excluded Cobol from tremendous growth in the computer industry. The
'Cobol community' was left behind.
From: Bill Gunshannon on 16 Jan 2008 08:30
In article <ur6ro3pkiku1gqohuiu4ff5rffvetqsrop(a)4ax.com>,
Robert <no(a)e.mail> writes:
> On Tue, 15 Jan 2008 22:18:52 -0400, Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote:
>
>>On Tue, 18 Sep 2007 19:09:19 -0500, Robert <no(a)e.mail> wrote:
>>
>
>>>Old Timers in such shops, I call them Keepers of the PERFORM THRU, are very sensitive to
>>>challenges to their remaining hegemony. They will viciously fire anyone they see as a
>>>threat. Even when the person follows their programming standards to the letter.
>>
>>As someone who fervently believes standards need to keep up to date
>>and we need easier ways of doing things, I would hope that I would be
>>embracing new technology that works.
>
> The version of Cobol in wide use has not changed in 22 years, since 1985. During that
> time, the number of general purpose computers worldwide went from 30 million to 1 billion.
>
> The 2002 Cobol Standard has been ignored, for the most part, because the 'Cobol community'
> does not want change.

Of course, it might also be that th4e changtes bring nothing that was
needed to get the job done. Why re-write an application because some
ivory-tower academic things you should do things differently when the
application has been doing its job for over two decades?

> The purpose of shop standards is to keep change out. It worked.

Pretty pessimistic view. The purpose of shop standards is to keep people
from using bad coding practices as a way to promote job security. Just
like the language, a local standard can be changed. the difference usually
is that when trying to change a local standard someone is going to look
at the change with an eye towards cost of implementation and advantagr
provided. The same is never true of standard bodies who rather than
trying to help the industry just want to be the one driving the bus.

> Problem is, it also excluded Cobol from tremendous growth in the computer industry. The
> 'Cobol community' was left behind.

Considering how much COBOL is still out there, that's pretty funny. We
have a professor here who is always talking about how a certain local
company with millions of lines of COBOL is "going to re-write all of it
in JAVA". Everytime I mention this to a manager in the COBOL shop they
end out rolling on the floor laughing!!

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill(a)cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
From: Alistair.J.L.Maclean on 16 Jan 2008 16:56
On 16 Jan, 02:27, Clark F Morris <cfmpub...(a)ns.sympatico.ca> wrote:
> On Wed, 19 Sep 2007 13:41:23 +1200, "Pete Dashwood"
>
>
>
>
>
> <dashw...(a)removethis.enternet.co.nz> wrote:
>
> >"Robert" <n...(a)e.mail> wrote in message
> >news:lbq0f35g00rvcfvhlf5glspmnp9p2n07f6(a)4ax.com...
> >> On Tue, 18 Sep 2007 08:33:17 -0400, "Charles Hottel"
> >> <chot...(a)earthlink.net> wrote:
>
> >>>Thanks. They are replacing the whole system. It is too far along for it to
> >>>change unless they stumble and Congress cuts off the money.
>
> >> Bureaucrats are adept at concealing stuumbles. That's their job.
>
> >> Another Cobol shop down the tubes. Why? I submit it was easier to change
> >> language than to
> >> battle the entrenched Cobol culture i.e. resistance to change.
>
> >I don't think so. It is bigger than that. (Although that can certianly be a
> >contributing factor. Not all COBOL shops are resistant to change.)
>
> >Put yourself in the place of an IT Director with responsibility for a large
> >budget.
>
> >How can you justify keeping the organization tied to COBOL when systems are
> >consistently late, fail to deliver what is needed, and cost a fortune to
> >maintain?(Not only that, but even the CEO knows that COBOL has no
> >credibility; he reads the airline magazines.. :-))
>
> That is why Vista is years late and lacking many of the promised
> features.
>
>
>
> >The increasing computer literacy in the population means that people will
> >simply build their own solutions using spread sheets and databases and
> >standard software. This means the information resource is out of control and
> >you are responsible for it. Without a VIABLE coherent IT plan, you have
> >failed in your job.
>
> Will all of those spreadsheets meet Sarbanes Oxley requirements for
> documentation and accountability?  
>

A boozy chum of mine has had to support users who enter data on
spreadsheets before feeding the files to the mainframe. The users
frequently changed the layout of the spreadsheets with the result
being that the mainframe crashed. On each occasion he was forced to
change the mainframe to accomodate the changed format. He has even
been forced to debug user spreadsheets for the clients despite the
fact that the IT department did not provide expertise or support for
spreadsheets.

One very worrying point about such spreadsheets are the horror stories
about the errors people make with them.
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: TRUNC(OPT) vs TRUNC(BIN) on IBM z series was Re: Quicksort recursiv
Next: SPARQL Query Technology