Re: Have you always dreamed of become a high payed consultant?

["Peter E. C. Dashwood" <address@hidden>]

Robert Graham <rgraham2@nycap.rr.com> wrote in message
3DE8153C.9080804@nycap.rr.com">news:3DE8153C.9080804@nycap.rr.com...
> >
> > It is my belief that anyone who appreciates poetry is capable of writing
> > great COBOL...but of course, I can't prove it...<G>
> >
> > Pete.
> >
> >
>
> I'd be glad to prove it.  If you are ever in a situation
> where you need another COBOL programmer I'm sure I can be
> available (did you say you were over in England?)  I have
> 20+ years experience - IBM mainframe mostly, with some
> MicroFocus & RM COBOL.  I'd be willing to travel.  I almost
> got an assignment in Edinburgh but mad cow / hoof in mouth /
> or something caused it to fall through.  Bummer. :(
>
> A love of poetry got me through high school.  With Hamlet
> and MacBeth causing me to be willing to actually attend
> instead of dropping out, heading to Woodstock and becoming a
> Hippie. (I was in High School in the late 60's.)  <GM> [as
> in "Groovie Man"] ;)
>
It is a cause of great sadness to me that I am currently unable even to use
COBOL on our site. (I simply can't make an effective Business Case for doing
so.) (Mind you, we don't use Java either...)

Everything is moving to Siebel (personally, I don't think this is a good
move but the decision was taken before I came.)

There is nothing wrong with Siebel on a small to medium scale, but for a
large Enterprise I have severe reservations. The Version we have is a
two-tier model and it is very rigid and unbelievably inefficient as more
terminals log in. (Each screen will generate its own DB
connections...(Horrors!)). Siebel are suggesting we upgrade to the "new"
three tier model (but it is still tied to the same rigid DB design). We are
not rushing to do this as it will cost millions...and we already spent
millions on it...

The really sad thing is that our "legacy" systems are performing fairly well
now <G>. These systems are not mainframe based (as you might expect when you
hear "legacy"; with the exception of one application which IS mainframe
based and written in PL/1, and will be decommissioned within the next 6
months...), they are all client/server and Web enabled. The heart of them is
SQL Server and ORACLE with XML transports to the presentation layer. There
is large use of components and we expect many of these to be pulled through
to the Siebel solution.

The main part of my brief is to keep the Business running while we effect
the transfer to Siebel. This means maintaining our legacy systems and really
ensuring there is a fall-back position if the Siebel implementation should
be delayed. We are trying to avoid doing major enhancements to the legacy
systems but my people are so good they can very often do stuff in a couple
of days that would take weeks using procedural code. Seeing how they do
things has really made me sit up and take notice.

The Web is king for presentation and it is XML that gets stuff there.

DB is written using stored procedures and components (we have SQL Server and
ORACLE tables with over 50,000,000 rows...it frightens me to death, but it
performs OK. We are running most of it on the top of the range COMPAQ server
with 8 processors and terabytes of storage. There are a total of 12 servers
in the Domains I manage, but that is the main one.

Data flow is accomplished with DTS (Data Transformation Services) which is
just a drag and drop tool. (This achieves moving  and connecting data
streams, sorting them, and converting their formats if required, with a few
mouse clicks... it is really awesome. Days of work with procedural code, in
seconds)

It is for all these reasons that I am on record as believing the days of
procedural code are numbered. I have talked to other managers in similar
businesses. None of them are still using procedural code and they smile at
the idea ...(Oh yes, the "good old days"...COBOL, PL/I, VB...).

I believe the role of COBOL will become more and more as maintenance for
existing legacy code and (certainly in my personal case) for the development
of Business components. I can't see major systems development being
undertaken in COBOL, or any other procedural language, in the
not-too-distant future.

That is how I perceive it at the moment. It may change. Meantime, I would
urge all of you who make a living out of COBOL to expand your skill set.

Pete.






 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com