Re: IBM mainframe and OO was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.


"Clark F Morris" <cfmpublic@xxxxxxxxxxxxxxx> wrote in message
news:544ml2dum71tqkttcal3cuhi3sv36qghdf@xxxxxxxxxx
On Sat, 11 Nov 2006 13:53:19 +1300, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:


"Clark F Morris" <cfmpublic@xxxxxxxxxxxxxxx> wrote in message
news:7ji9l2dgis531g65si0n4s6rk0tegm4bhh@xxxxxxxxxx
When I printed Peter Dashwood's response to my posting, it was 7 pages
so I decided to start a new set of postings.

Perhaps some judiciuos snippage might have been better? I now have no
contextual reference in which to continue this discussion, don't remember
what I said in response to what, or what you said in response to my
response... :-)

In my case I won't know when I have become senile because I always
have had a porous memory (although I am able to keep straight 5
passwords and variants of them).

Excellent! But don't you think it is kind of a shame that you HAVE to...?:-)
If systems need to establish who someone is, there are better ways than
passwords... If they simply need to know whether this user should be given
access to data, there are simpler ways than passwords. All-in-all, passwords
are a pretty crap way to go. I was pleased to see that Bill Gates agrees
with me on this :-)


<snip>
OO systems are probably easier to document than procedural ones (although
I
agree this arguable). Because of the encapsulation provided by Classes and
Objects, the Overview and Background documentation of the Class or Object
can be provided in a Help file and the help file can be a Method of the
Object. Some OO tools automatically generate current documentation of the
events, methods and properties in an Object (Object Browsers do this and
what they report is ALWAYS up to date.)

If the mainframe development environment had these tools, I suspect
that there would be little programmer level resistance. I have read
of various web-based and web oriented development environments but
have not seen any of them.

There is no point in using an Object Browser in a non-OO environment. The
tool analyses Objects for their Methods, Properties, Interfaces, and Events;
procedural code doesn't contain these things (and even if you wrote them
into it, they would not be in a form that was acceptable to an Object
Browser).


In the 1990's and early 2000's I don't
recall any SHARE presentations on them and there were none in the
COBOL project and none that I recall being highlighted at the Group
level which included COBOL. The expensive source management system
Endevor from Computer Associates will store the listing from a compile
but then makes getting at it non-intuitive.

Yes, I've had some really interesting brushes with Endevor ... Come back
Panvalet, all is forgiven... :-)


Indeed, if I understand some of the
descriptions of integrated development environments, the non-mainframe
world has available to it better repository tools and means of both
creating and storing documentation than does much of the IBM mainframe
world. I will let those in the Unisys arena speak for what is
commonly used there.

I don't see this as a contest between mainframe and OO... Whatever
approach
you are using, you need to consider what, why, how, and when to document.

Tools can enable and guide the approach. They can help enforce good
practice.

Yes, that's true. But then people get Evangelical about the tools and that
creates a whole lot of other problems... :-)


It isn't a contest between IBM mainframe and OO, it is that
the tools to make OO work and work well don't seem to be available on
the IBM mainframe although Websphere may have all of the tools such as
Object Browsers that you have discussed.


The tools I am talking about would be pointless in a non-OO environment. See
above. There ARE some good tools for the procedural environment, but none
that I know of actually help you document it in a way that is useful and
current, and that was where we came in on this topic.

I only have the version 1 fears of new things both from experience and
hearing horror tales including an IBM speaker describe why Data
Facility/Extended Function catalog handling code had been removed from
distribution. Even a couple of years later I ran into noticeable
problems when implementing what was by then supposed to be stable.

Many people avoid Version 1, but SOMEBODY has to use it, or else there
won't
be a version 2...

Version 1 always is a risk benefit analysis. There have been times
when I was willing to be a beta tester and of course, for code I
develop and put into production I am an alpha tester.


How would you feel if you invested thousands of hours in developing and
testing something, were satisfied it was as good as you could make it, and
then found no-one would buy it or use it because it was Version 1?

(Many software houses now start with Version 2, claiming that Version 1 was
an internal one and never released... :-))


OO
came out in the 1990's so it is now a known entity and thus would not
scare me but it still confuses me. What is especially frustrating is
that OO is providing much of what we of the SHARE/Guide (or
Guide/SHARE) Language Futures Task Force saw for the future including
checking at interfaces, use of repositories for storing code and
information about the function of the code and organizational rules.
We were interested in late binding and parameter checking so that
caller and called had the same expectations although the systems
programmer in me was more concerned about the costs than some of the
other participants. This was in the early 1980's. We also we
interested in data independence and were impressed with the then new
SQL.

Why would you be frustrated if somebody did what you were advocating?

Because the "wrong people" did it?

No, because I find that I get lost every time I try to understand it.

That is very valid comment and it made me stop and think. The problem of
keeping new
approaches simple is one that not enough time is spent on.

To be fair, I can think of occasions where I have spent many hours
developing on line help (sometimes longer than the software took to develop
:-)), because I realised it was (unavoidably) complex, and structured help
from a top down approach so that succeeding levels of detail were presented
after basic concepts had been estabished, only to find that users simply
don't read a help file. The same users, when walked through the help file
agreed that everything they needed to know was there.

It just isn't Human Nature to invest time in learning. (Unless we HAVE to,
and even then reluctantly... :-))

We simply want to know... NOW! Windows and GUI environments try to address
this, and probably succeed better than command line interfaces for the
majority of the public. (GUI is not called
"intuitive" for nothing... even though it can go much further than it has to
date.)

But the fact remains that most users get frustrated because they don't know
how something works, and how they expect it to work is usually not how it
works... :-)

IT people get even more annoyed because they feel they SHOULD know how it
works or they SHOULD be able to make it work.

RTFM is simply a last resort.



Maybe these people arrived independently at the same conclusions your
group
had. The difference is that they backed their postulates with action.

The problem here is not with what was posited, but with the mechanisms
whereby thought becomes action. (Don't start me on the COBOL standards,
but
that is the nub of my objection to the ANSI process...)

The ANSI process is non-functional because the development of new
function isn't done by producing and testing code with some protection
for those who are willing to brave the bullets.

I am so tempted... but no... I'll let it pass... :-)



I also remember in the 1980's a product called Gamma that was supposed
to revolutionize application development. The company was headed by
Fran Tarkenton of New York Giants fame. My shop bought it and I went
to one of the intro sessions. You were supposed to code up
specifications and data descriptions, etc. and the appropriate code
would be generated. You could then tweak it. However it turned out
that there was no good mechanism for regenerating all or part of an
application system. After much effort, the product quietly
disappeared. The promise was great. The concept was seemingly good
but the implementation left much to be desired including lack of
ability to keep the application code at the high level. Failures like
these both helped those who were working in the field developing
concepts like OO learn what didn't work and added to the skepticism of
management.

So, someone has a good idea, tries to implement it, fails, and gives up?

The promise was good but I suspect that having a star National
Football League quarterback as president of the company had as much as
anything to do with the willingness of management to try the product.
I suspect that there was unwillingness to follow up on why the product
failed to live up to expectation. If there had been analysis along
those lines, we might have been ready to get a better one and been
more realistic about costs and benefits.

I'm sure you're right.


<snip>

OO resistance on IBM mainframe sites was not a matter of management
skepticism. (To be blunt, most managers would have no idea whether it was
good or not...). The resistance came from the Priests of COBOL, the System
Programmers, and the innate resistance to change and learning of new
concepts (takes effort to change your mind about something, or even to
keep
it open... besides, everything I want to do I can do in COBOL) that one
finds on most IT shop floors.

THAT MAY BE TRUE IN SOME SHOPS (yes I am shouting) BUT MOST
UNWILLINGNESS TO ADOPT NEW CODE IS AT THE MANAGEMENT LEVEL.

Oh dear! Did I touch a nerve? ... :-)

The loudest person is not necessarily the rightest... :-)

It isn't a Management function to embrace "new code".

That is a tech prerogative. Managers (even informed ones like me :-)) expect
to be advised. Of course, sometimes they are ill-advised, and sometimes they
are well advised but the option is politically or fiscally unpalatable.

I have had team members suggest we purchase a certain tool (and I am very
interested in ensuring the best tools for the job are provided and my team
have everything they need to succed), but when the tool costs 25% of the
entire project budget, some soul-searching has to be done before I can say
"Yes"... Even when it isn't that bad, a tool that costs over $100,000 would
need to save many hours of work to be viable. It isn't just the working
hours, it is the time spent on the learning curve as well. (And it usually
isn't just about ONE tool... :-)

Consider the position of an IT Manager who is managing a COBOL shop and a
directive comes down from on high that migration to a server based network
and Object Oriented code should be implemented ASAP. (The Boss has been
reading Computer Weekly again, and also found out that his major competition
are already embarking on this exercise...)

All our IT man can see is risk... migration, training, new learning curves,
huge aggravation, and to top it off, a diminished budget!

Small wonder they are not leaping to the head of the queue...

Is he unwilling to adopt "new code"? You bet!!!

He'd have to be insane not to be so. If you add to this the fact that the
"shop floor" are perfectly happy with the status quo, for all the reasons I
mentioned, (and these are the people who he must listen to) it really comes
down to a rock and a hard place.

Only shops driven by extreme business need, and/or enough cash to buy the
required time for all the things mentioned above, shops with a vision of
where their business is going and the knowledge that they must change the
way they do things in order to support that business vision in the future,
shops that realise if they are not seen to be supporting the business and
capable of doing so for the foreseeable future their jobs will be outsourced
or they will be replaced by a package... in other words, shops that are
extremely motivated to stay in business, are likely to even attempt to
change.

Sadly, for most, the package and outsource options are the most attractive
to their management. Yet I have noticed that on sites where IT is engaged
with the business, where solutions are found and implemented jointly, and in
a timely manner, where IT is supportive and working with the Business on a
daily basis, there is little talk of packages and outsourcing.(In fact I
recently saw a major decison to implement a package, overturned, and IT
engaging with the business to provide individual solutions instead. While
you can certainly argue whether this was wise, it has been embraced by all
concerned.)

Instead of IT trying to control and prevent local solutions, they are happy
to work with the people concerned and ensure that data is properly shared.
Locally produced solutions are encouraged, and "best practice" is encouraged
in the development of them. (Whether IT personnel do them or the Business do
them, or it is a joint effort...) Major projects are jointly developed, and
deliver what is wanted NOW, using better methodologies than the Waterfall.

The question of what language the IT department will use is simply not
relevant; they use tools and languages that best suit the system being
developed.

For this approach to succeed it needs strong and capable IT leadership and
the support of all the business. In the instance I am thinking of, all these
things are in place and the outlook is therefore positive.

<snip>

How am I going to push OO when I can't get a product that has not only
the syntax but the support facilities such as object browsers,
repositories, etc.?

That's a bit like "Give us the job and we will finish the tools..."
(Apologies to W.S. Churchill) :-)

The tools are certainly important, but there's no sense buying a spark plug
wrench if you don't have a car...

Another turn off for many has been the complete
new set of jargon and magical hand waving when we still haven't
mastered the current set of jargon and hand-waving.

LOL!

This is a matter of perspective and perception.

One man's "jargon" is another man's "precise definitions for increased
clarity". (C.f. "tenacity" and "obstinacy")

IT has always had (and needed) jargon. The hand waving (like shouting...
:-)) is just a form of personal expression... :-) Personally, I only wave my
hands about when I'm drowning... :-)



After hearing a
presentation on OO concepts and COBOL by Steve Ryder, former manager
of the Storage Management project at SHARE, I can believe that OO can
make solving certain things easier and that it can be taught in a way
that makes sense to those in the mainframe tradition.

I've only had one shot at teaching it to those in the mainframe tradition
(apart from countless posts, dialogues, and arguments with those here, which
I won't count :-)) and it was VERY hard work. On the other hand, teaching
the same concepts to people with no such background was noticeably easier.
(I call this the ITSA syndrome... see my posts on it elsewhere in CLC...).
It CAN be done, but it isn't easy and I certainly won't be puttinjg my hand
up again for this... :-) (I would consider it, if the people who were to be
taught actually asked for it and REALLY wanted to know; otherwise, no way...
Life's too short :-))


Java is
probably the best hope because IBM has put cross-platform support into
it. The web enablement is probably one of the best places to start
because there is a need that is filled by tools that are at least
somewhat available.

Yes, I completely agree with you on this.


<snip>>
Given that the province of Nova Scotia had budgeted 4 - 5 million
dollars Canadian for a conversion of two areas of accounting to SAP
and the bill now is around 20 million dollars Canadian, most
mainframers have learned to approach major upheavals with fear and
trembling.

One swallow does not a summer make. Nova Scotia...???!!!

Forgive me, nothing personal against NS, but it wouldn't be the first place
I'd look if I needed lessons in Project Management...

In the case of the SAP upgrade, I don't know if the
problem is in the understanding of what the current system does and
the road to get all needed functionality to the new system, failure to
provide for the volume or something else. When you are running hard
to keep the current area going, it is difficult to get the time and
resources to understand a new paradigm, the ways it can address
current or future needs, and then get a way to move to brave new
world.

It certainly is. I was (not so long ago) given the responsibility to keep
everything ("Legacy") running while a new (Siebel) package was installed at
a major UK utility. The team were dispirited because they weren't being
trained in the new stuff, and the people who were, were having a great time.
Furthermore, there were no funds for any new development and all of their
work was essential maintenance of existing systems...

Nevertheless, we managed to not only keep everything going, but also improve
the turnaround on bug fixes and actually have fun as well...

An analogy is available in the railroad industry. The current
coupling mechanism used in North America (and I believe in Australia
and New Zealand) will allow coupling of cars by just pushing them
together. However it does not also link up the braking system. I
believe the Russian coupler does this as do couplers that are used on
subways and many commuter electric cars.

Ive seen freight yards here with freightcars being pushed into each other
and continuing to move.

It seems to work OK.

Why are synchronized brakes important for this?

However, these solutions are
incompatible with the existing system and no one has figured out a way
to get from current to future without massive disruption of service
and at an affordable cost. To make any major paradigm shift is a
massive investment and the short term outlook of many organizations
precludes making the up front investment.

It isn't ALWAYS a massive investment, but it is certainly likely to be
expensive. I'm not sure that the expense is always the main factor that
stops it... sometimes inertia is the real reason and cost is just an excuse
(whatever option you take in IT, it will cost you...)

<snip>

One final thing that I will elaborate on in a separate posting is that
many COBOL programmers came / come from the user side of the business
or were / are on a rotation through departments. This means that many
of us are not professional programmers and have a noticeably different
orientation than say people with computer science degrees.

EVERYBODY has a different orientation from people with computer science
degrees! :-)

Nerdland is unreal to most people. Fascinating to visit, but you wouldn't
want to live there... ( a bit like Fry's in California :-))

BOTTOM LINE:

1. The world has embraced OO.

The world has embraced packages and not doing development. It would
be interesting to find out how many of the major packages such as SAP
are OO. I would assume most current versions of the desktop packages
are OO but even there it would be interesting to verify that
assumption.

SAP is pushing ABAPS OO currently, as the solution for the future (despite
it having been available for some time now). They are certainly committed to
OO, if not completely at present, definitely for the future.


Siebel claims to use a component based approach. (Whether their components
are OO or not I don't have enough in-depth knowledge to say...)

<snip>

Pete.


.

Relevant Pages

  • Re: OT but ...
    ... -- would it be anyone's business what my passwords are? ... and Facebook, certainly. ... All of which are, in my opinion, none of their business. ... An employer has a reasonable interest in how an employee treats ...
    (alt.usage.english)
  • Re: OT but ...
    ... would it be anyone's business what my passwords are? ... and Facebook, certainly. ... All of which are, in my opinion, none of their business. ... An employer has a reasonable interest in how an employee treats ...
    (alt.usage.english)
  • Re: different passwords inside and outside?
    ... Well just as he runs his business the way he sees fit, ... > The client likes simple passwords. ... > convince him that simple passwords are a bad idea for OWA (that's the only ... >>> could the password for OWA be different than the password to logon to ...
    (microsoft.public.windows.server.sbs)
  • Re: OT but ...
    ... would it be anyone's business what my passwords are? ... and Facebook, certainly. ... All of which are, in my opinion, none of their business. ... An employer has a reasonable interest in how an employee treats ...
    (alt.usage.english)
  • Re: OT but ...
    ... would it be anyone's business what my passwords are? ... and Facebook, certainly. ... All of which are, in my opinion, none of their business. ... An employer has a reasonable interest in how an employee treats ...
    (alt.usage.english)
Loading