Home > Archive > Cobol > August 2006 > Re: Need for people to support operating environment was Re: COBOL - still a place fo
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Need for people to support operating environment was Re: COBOL - still a place fo
|
|
| Pete Dashwood 2006-07-31, 7:55 am |
|
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:fmqpc2501qjdkoba0nvqvnb229esih43d7@
4ax.com...[color=darkred]
> On Mon, 31 Jul 2006 00:31:57 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
>
>
> If there is any real volume you need a bevy of some kind of experts to
> decide whether a system fix should be applied and review the risks, to
> keep track of usage, to handle communications problems, etc. Some of
> these tasks are simplified by using a mainframe as the base, other by
> using other computer configurations. Things that I can ignore on my
> home computer are not an option if you are running a major operation
> on which many people depend. Little things like backups. Little
> things like making sure an operating system, database or middleware
> fix doesn't blow up the loved application. Security is a complex zoo
> regardless of platform. For many online and networking tasks, the IBM
> mainframe (also probably Unisys and any others still in business) is
> better than using networked Unix, Linux or Windows computers. For
> other tasks the reverse is probably true.
I respect your opinion as stated. I don't entirely agee with it, that's
all... :-)
I am not suggesting that all the infrastructure tasks you mention are not
necessary; but I contend most of them are automated when it comes to
networks. Your last two sentences simply state that some computers are good
for some tasks, and I wouldn't disagree with that.
My original point was that mainframe systems require people who are employed
full time (system programmers) just applying fixes to the Operating System
(PTFs) and keeping the system operational. That is not the case with PC
systems, although I grant server farms require network experts. I am NOT
anti-mainframe (made a living out of them for decades before PCs were
invented); it just annoys me that so many people working in this environment
still look superciliously on PCs as 'toy computers' that can't possibly
compete with a 'real' machine... :-)
Pete.
| |
| Clark F Morris 2006-08-01, 6:55 pm |
| On Tue, 1 Aug 2006 01:04:41 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:
>
>"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
> news:fmqpc2501qjdkoba0nvqvnb229esih43d7@
4ax.com...
>
>I respect your opinion as stated. I don't entirely agee with it, that's
>all... :-)
>
>I am not suggesting that all the infrastructure tasks you mention are not
>necessary; but I contend most of them are automated when it comes to
>networks. Your last two sentences simply state that some computers are good
>for some tasks, and I wouldn't disagree with that.
>
>My original point was that mainframe systems require people who are employed
>full time (system programmers) just applying fixes to the Operating System
>(PTFs) and keeping the system operational. That is not the case with PC
>systems, although I grant server farms require network experts. I am NOT
>anti-mainframe (made a living out of them for decades before PCs were
>invented); it just annoys me that so many people working in this environment
>still look superciliously on PCs as 'toy computers' that can't possibly
>compete with a 'real' machine... :-)
I apply fixes to both my wife's laptop and the family desktop on a
"read the description" first basis. This also makes certain that
fixes come in when we know about it and also boot up doesn't give
surprises. However, the only non-optional fix that I had put off was
the Microsoft Genuine Di vantage fix where you took the risk so they
could check your system. I put it on the desktop after they refused
to show fixes without it. This is still far more casual than I was
about a new release on a mainframe and far more casual than I would
expect any person controlling any major shop regardless of operating
system. The trust I give to Microsoft and other vendor fixes in the
home environment could be suicidal in an organizational environment.
Way back in the 1980's when I was a systems programmer, my shop had
the following:
1. Three people for the operating system plus VTAM (networking),
storage management, third party software for such things as report
management and the development environment, and customization using in
house code or public domain software.
2. One for CICS (middleware and transaction monitor).
3. One supervisor over the above two plus someone for midrange.
4. Two or three people including a supervisor for maintaining the
network of leased lines and verifying equipment. They had line
monitors, etc.
5. Two for data base and data administration plus a supervisor.
There were round the clock operators (1 per shift) plus job management
people.
Applying fixes and even installing new releases was a relatively small
part of the tasks that we had in the systems programming group. We
were responsible for monitoring the performance, tracking usage,
checking for possible problems, system backups, installing new
function and providing technical help. Although our shop was not
bleeding edge, we did have a few times where we were site of first
discovery. Customization of the IDE (more accurately fragmented
development environment) was included. We also made a pass at
security and disaster recovery planning.
Today, the reporting of errors and exceptions is more automated but as
our environments grow more complex, it can still take a lot of time.
It may also be a case of running fast to stand still. If you separate
development from production, keeping them in step is not that simple.
If a shop chooses to test out new releases first in the development
environment (operating systems, middleware, compilers, etc.) there is
the joy of making sure nothing in development takes advantage of
function not available in production before production is upgraded to
the new environment. Software installation can be time consuming.
Vendor defaults changing can drive you nuts on any platform. Fixes
that close loopholes (think SECURITY) should be installed as soon as
feasible but first someone had better test to make sure that one or
more loved applications weren't advertently or inadvertently depending
on the loophole. I remember once when IBM closed a loophole that
required the vendor of a major SORTing product to fix their code. I
still am ticked off at the cavalier attitude of the SORT vendor on not
distributing the fix generally until the IBM change was on a PUT tape
even though the IBM change was already distributed to people using a
newer form of maintenance delivery. The time consumption in applying
fixes is not so much in the actual application as it is in the
verification that they haven't gone bad, that your shop has all of the
applicable ones for its environment and as I said, in making sure they
don't cause problems. I might add that I read many systems
programmers complaining that the head count in their area is held down
while the Windows side keeps growing. For the same type of work and
the same availability requirements, I suspect that if anything the
mainframe may be slightly easier to keep going. cisco routers are
Cisco Routers. I have seen flaky on most of the platforms that I have
dealt with.
In the newer world, the keeping up with and scheduling of fixes gets
even more complicated for the 24/7 environment. A large portion of
the Windows fixes I get require a reboot. I suspect kernel fixes for
the varying flavors of Unix/Linux also require reboot. Tandem was the
only vendor where I just saw memos that operations were to perform a
simple non-disruptive procedure while the world is running to install
fixes. IBM is getting better on the mainframe by taking advantage of
being able to have multiple logical computers on a physical computer
and combining multiple logical and physical computers in a complex
(LPAR and Parallel Sysplex for the jargon interested) where online
work can be moved from one computer to another so that re-boots for
maintenance and system upgrade don't disrupt the shop. Of course it
takes work to take advantage of this and shops that aren't fully 24/7
probably haven't made the effort. In general, once the workload hits
a certain size the general rule of thumb is that a mainframe requires
fewer support people to manage the environment. My guess is that
maintaining the middleware be it Websphere, apache or CICS will
require the same number of people for the given piece of middleware
regardless of platform. Similary, database administration,
installation and upgrade should be fairly much the same for Oracle,
DB2 etc. regardless of platform. The amount of customization will
determine the number of people for operating system support. I
suspect managing the non-database data is a zoo regardless of platform
and while databases should be handling more and more of the data, they
aren't handling all of it.
Network management regardless of operating system can be another
nightmare even though the tools have gotten a lot better in all
environments than when I last had to worry about it.
Security is an interesting and time consuming area in its own right.
The requirements of various legislation regarding privacy may have a
real impact on the separation of development and production
environments.
In the rambling above, I think you could tell that the three people
assigned to operating system support when I was doing it were doing a
lot more than just applying fixes and keeping the operating system up
to date. We were also improving the tools available. Keeping up with
the changes available and scheduling their installation is only part
of the task regardless of operating system. All of these tasks are
more automated than when I was doing it. I suspect the automation for
them is ahead of the pack in some areas on the mainframe and still
woefully behind the times in others. Ironically the only operating
environment I can truly list shortcomings for in the enterprise area
is the mainframe because it is the only one I know well enough to do
so for.
>
>Pete.
>
| |
| Pete Dashwood 2006-08-02, 7:55 am |
| Interesting post Clark.
Although you make some good points I'm still not persuaded that mainframes
don't require special attention that PCs don't.
However, I would not disagree that the right tools for the job sometimes
means a mainframe.
Pete.
TOP POST nothing new below.
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:gg6vc25ob83fd4m278jhigt6gouqjsjilb@
4ax.com...[color=darkred]
> On Tue, 1 Aug 2006 01:04:41 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
> I apply fixes to both my wife's laptop and the family desktop on a
> "read the description" first basis. This also makes certain that
> fixes come in when we know about it and also boot up doesn't give
> surprises. However, the only non-optional fix that I had put off was
> the Microsoft Genuine Divantage fix where you took the risk so they
> could check your system. I put it on the desktop after they refused
> to show fixes without it. This is still far more casual than I was
> about a new release on a mainframe and far more casual than I would
> expect any person controlling any major shop regardless of operating
> system. The trust I give to Microsoft and other vendor fixes in the
> home environment could be suicidal in an organizational environment.
>
> Way back in the 1980's when I was a systems programmer, my shop had
> the following:
> 1. Three people for the operating system plus VTAM (networking),
> storage management, third party software for such things as report
> management and the development environment, and customization using in
> house code or public domain software.
>
> 2. One for CICS (middleware and transaction monitor).
>
> 3. One supervisor over the above two plus someone for midrange.
>
> 4. Two or three people including a supervisor for maintaining the
> network of leased lines and verifying equipment. They had line
> monitors, etc.
>
> 5. Two for data base and data administration plus a supervisor.
>
> There were round the clock operators (1 per shift) plus job management
> people.
>
> Applying fixes and even installing new releases was a relatively small
> part of the tasks that we had in the systems programming group. We
> were responsible for monitoring the performance, tracking usage,
> checking for possible problems, system backups, installing new
> function and providing technical help. Although our shop was not
> bleeding edge, we did have a few times where we were site of first
> discovery. Customization of the IDE (more accurately fragmented
> development environment) was included. We also made a pass at
> security and disaster recovery planning.
>
> Today, the reporting of errors and exceptions is more automated but as
> our environments grow more complex, it can still take a lot of time.
> It may also be a case of running fast to stand still. If you separate
> development from production, keeping them in step is not that simple.
> If a shop chooses to test out new releases first in the development
> environment (operating systems, middleware, compilers, etc.) there is
> the joy of making sure nothing in development takes advantage of
> function not available in production before production is upgraded to
> the new environment. Software installation can be time consuming.
> Vendor defaults changing can drive you nuts on any platform. Fixes
> that close loopholes (think SECURITY) should be installed as soon as
> feasible but first someone had better test to make sure that one or
> more loved applications weren't advertently or inadvertently depending
> on the loophole. I remember once when IBM closed a loophole that
> required the vendor of a major SORTing product to fix their code. I
> still am ticked off at the cavalier attitude of the SORT vendor on not
> distributing the fix generally until the IBM change was on a PUT tape
> even though the IBM change was already distributed to people using a
> newer form of maintenance delivery. The time consumption in applying
> fixes is not so much in the actual application as it is in the
> verification that they haven't gone bad, that your shop has all of the
> applicable ones for its environment and as I said, in making sure they
> don't cause problems. I might add that I read many systems
> programmers complaining that the head count in their area is held down
> while the Windows side keeps growing. For the same type of work and
> the same availability requirements, I suspect that if anything the
> mainframe may be slightly easier to keep going. cisco routers are
> cisco Routers. I have seen flaky on most of the platforms that I have
> dealt with.
>
> In the newer world, the keeping up with and scheduling of fixes gets
> even more complicated for the 24/7 environment. A large portion of
> the Windows fixes I get require a reboot. I suspect kernel fixes for
> the varying flavors of Unix/Linux also require reboot. Tandem was the
> only vendor where I just saw memos that operations were to perform a
> simple non-disruptive procedure while the world is running to install
> fixes. IBM is getting better on the mainframe by taking advantage of
> being able to have multiple logical computers on a physical computer
> and combining multiple logical and physical computers in a complex
> (LPAR and Parallel Sysplex for the jargon interested) where online
> work can be moved from one computer to another so that re-boots for
> maintenance and system upgrade don't disrupt the shop. Of course it
> takes work to take advantage of this and shops that aren't fully 24/7
> probably haven't made the effort. In general, once the workload hits
> a certain size the general rule of thumb is that a mainframe requires
> fewer support people to manage the environment. My guess is that
> maintaining the middleware be it Websphere, apache or CICS will
> require the same number of people for the given piece of middleware
> regardless of platform. Similary, database administration,
> installation and upgrade should be fairly much the same for Oracle,
> DB2 etc. regardless of platform. The amount of customization will
> determine the number of people for operating system support. I
> suspect managing the non-database data is a zoo regardless of platform
> and while databases should be handling more and more of the data, they
> aren't handling all of it.
>
> Network management regardless of operating system can be another
> nightmare even though the tools have gotten a lot better in all
> environments than when I last had to worry about it.
>
> Security is an interesting and time consuming area in its own right.
> The requirements of various legislation regarding privacy may have a
> real impact on the separation of development and production
> environments.
>
> In the rambling above, I think you could tell that the three people
> assigned to operating system support when I was doing it were doing a
> lot more than just applying fixes and keeping the operating system up
> to date. We were also improving the tools available. Keeping up with
> the changes available and scheduling their installation is only part
> of the task regardless of operating system. All of these tasks are
> more automated than when I was doing it. I suspect the automation for
> them is ahead of the pack in some areas on the mainframe and still
> woefully behind the times in others. Ironically the only operating
> environment I can truly list shortcomings for in the enterprise area
> is the mainframe because it is the only one I know well enough to do
> so for.
| |
| Clark F Morris 2006-08-05, 9:55 pm |
| On Wed, 2 Aug 2006 22:56:43 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:
>Interesting post Clark.
>
>Although you make some good points I'm still not persuaded that mainframes
>don't require special attention that PCs don't.
In this discussion, one of the problems is that there are a number of
ways to spilt up the work regardless of platform. Thus the group I
was a part of also took care of installing and customizing the IDE
(more accurately Fragmented Development Environment), installing the
compiler and setting the options and storage management. Installing a
new level of maintenance was a major project and was normally done
only once a year at the shop where I was a systems programmer. Fixes
for problems affecting the shop might be installed between going to
new levels. This is worth discussing in more detail because movement
to or from any given platform may be made based on inadequate
perception. Most people have very vague ideas about what their
organization's systems programming / systems administration / network
administration department does and how the time is spent. Some places
will have the IDE and middleware as the responsibility of that
department, others won't. Some will have one group responsible for
all operating systems while others will have separate departments. The
amount of testing will be different. Centralization of task should
lead to consistency of environment but one Unix shop that had
converted from the mainframe had different arithmetic options for the
online (psuedo-CICS programs in Unix from CICS) COBOL compiles than
for the batch. Since this involves intermediate results I don't know
how much difference this made in practice.
In discussing the mainframe environment, I suspect that the tool that
keeps track of fixes is much more arcane than the one for PC's. On
the other hand, use of this tool can prevent installation of fixes
already found to be bad. Some of the difference lies in scale of
system and the need for use of the tools. A large scale server
network will need a tool that keeps track of usage of various
resources, hierarchical storage managers, etc. Windows XP home
actually has a rather nice looking task monitor that would probably
completely baffle 50 percent of those using XP. There are mainframe
shops where virtually all of the systems type work is done by one
person. Volatility of the environment (changes in task, need to keep
current, variability of work load) closeness to bleeding edge, amount
of customization and similar factors probably have a greater effect on
staffing. You have shops that don't keep current on the tools that
can automate monitoring, problem determination, etc regardless of
operating system. There are organizations that will spend big dollars
to keep the Unix/Windows/etc. environment current but won't spend a
cent on the IBM / Unisys / other mainframe environment because it is
going away and has been for 10 years.
It actually would be very instructive to measure the following for
each of the environments (mainframe, Unix network, Windows network,
other):
1. Are the up time and reliability expectations the same and what are
they? This includes recovery from outage. What resources in terms of
monitoring, hardware and people are devoted to these tasks (in terms
of people, fractional numbers make sense because it may be a part time
task)?
2. How is security handled and what resources? Again are the
expectations for each of the environments (there may be valid reasons
for differences in this and the other areas)?
3. How is storage management handled including backup and what
resources?
4. How is business continuity (disaster recovery) handled? Remember
loss of the wrong logical disk can cause MAJOR problems.
5. Who is responsible for the development environment (the IDEs or
FDEs)?
6. Is development on a separate system (could be a separate logical
machine on IBM mainframes, many Unix systems, the IBM i series and I
would guess Unisys and other mainframe manufacturers), also operating
system test? Keeping separate environments in step can be
interesting.
While this is just a small sample of the questions, thorough
investigation will yield interesting answers for any of the
contenders. The various mainframe architectures (IBM z series, etc.)
will have tools in some areas that the other environments only dream
of while being behind in others. The software costs which come in
bigger chunks on the mainframe may actually be smaller for that
environment than for clustered servers. The people costs get to be
interesting because they may depend more on management policy and
expectations of service than on the particular platform. I contend
that for most places that are not 24/7 and that can tolerate
infrequent short outages (once every three months), any of the major
platforms can be managed to a more than acceptable degree of
reliability. I will leave it to others to debate the adequacy of
security tools and which environment is actually more secure although
here again, I suspect management concern and practice is more
important than the actual hardware and software. A place that makes
certain that access is cut off when people leave the organization and
that change the access available as the responsibilities change
probably is ahead of all too many places and this has nothing to do
with the particular computer environment.
Without disclosing anything organization confidential, I would be
interested in some idea of the size of the organization that you
(Pete) are consulting at, the size of the computer configuration in
terms of compute power and disk space, the sort of disaster recovery
expectations and the people assigned to various tasks such as
operating system maintenance. I realize that publishing this
information could well make your client twitchy so if you can't
respond, or it is too much work, I will understand.
>
>However, I would not disagree that the right tools for the job sometimes
>means a mainframe.
>
>Pete.
>
>TOP POST nothing new below.
>
>
>"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
> news:gg6vc25ob83fd4m278jhigt6gouqjsjilb@
4ax.com...
>
| |
| Pete Dashwood 2006-08-06, 7:55 am |
|
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:jigad2dq1s7rma8b0or816p5o14njp5gpn@
4ax.com...[color=darkred]
> On Wed, 2 Aug 2006 22:56:43 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
>
> In this discussion, one of the problems is that there are a number of
> ways to spilt up the work regardless of platform. Thus the group I
> was a part of also took care of installing and customizing the IDE
> (more accurately Fragmented Development Environment), installing the
> compiler and setting the options and storage management. Installing a
> new level of maintenance was a major project and was normally done
> only once a year at the shop where I was a systems programmer. Fixes
> for problems affecting the shop might be installed between going to
> new levels. This is worth discussing in more detail because movement
> to or from any given platform may be made based on inadequate
> perception. Most people have very vague ideas about what their
> organization's systems programming / systems administration / network
> administration department does and how the time is spent. Some places
> will have the IDE and middleware as the responsibility of that
> department, others won't. Some will have one group responsible for
> all operating systems while others will have separate departments. The
> amount of testing will be different. Centralization of task should
> lead to consistency of environment but one Unix shop that had
> converted from the mainframe had different arithmetic options for the
> online (psuedo-CICS programs in Unix from CICS) COBOL compiles than
> for the batch. Since this involves intermediate results I don't know
> how much difference this made in practice.
>
>
> In discussing the mainframe environment, I suspect that the tool that
> keeps track of fixes is much more arcane than the one for PC's. On
> the other hand, use of this tool can prevent installation of fixes
> already found to be bad. Some of the difference lies in scale of
> system and the need for use of the tools. A large scale server
> network will need a tool that keeps track of usage of various
> resources, hierarchical storage managers, etc. Windows XP home
> actually has a rather nice looking task monitor that would probably
> completely baffle 50 percent of those using XP. There are mainframe
> shops where virtually all of the systems type work is done by one
> person. Volatility of the environment (changes in task, need to keep
> current, variability of work load) closeness to bleeding edge, amount
> of customization and similar factors probably have a greater effect on
> staffing. You have shops that don't keep current on the tools that
> can automate monitoring, problem determination, etc regardless of
> operating system. There are organizations that will spend big dollars
> to keep the Unix/Windows/etc. environment current but won't spend a
> cent on the IBM / Unisys / other mainframe environment because it is
> going away and has been for 10 years.
>
> It actually would be very instructive to measure the following for
> each of the environments (mainframe, Unix network, Windows network,
> other):
>
> 1. Are the up time and reliability expectations the same and what are
> they? This includes recovery from outage. What resources in terms of
> monitoring, hardware and people are devoted to these tasks (in terms
> of people, fractional numbers make sense because it may be a part time
> task)?
>
> 2. How is security handled and what resources? Again are the
> expectations for each of the environments (there may be valid reasons
> for differences in this and the other areas)?
>
> 3. How is storage management handled including backup and what
> resources?
>
> 4. How is business continuity (disaster recovery) handled? Remember
> loss of the wrong logical disk can cause MAJOR problems.
>
> 5. Who is responsible for the development environment (the IDEs or
> FDEs)?
>
> 6. Is development on a separate system (could be a separate logical
> machine on IBM mainframes, many Unix systems, the IBM i series and I
> would guess Unisys and other mainframe manufacturers), also operating
> system test? Keeping separate environments in step can be
> interesting.
>
> While this is just a small sample of the questions, thorough
> investigation will yield interesting answers for any of the
> contenders. The various mainframe architectures (IBM z series, etc.)
> will have tools in some areas that the other environments only dream
> of while being behind in others. The software costs which come in
> bigger chunks on the mainframe may actually be smaller for that
> environment than for clustered servers. The people costs get to be
> interesting because they may depend more on management policy and
> expectations of service than on the particular platform. I contend
> that for most places that are not 24/7 and that can tolerate
> infrequent short outages (once every three months), any of the major
> platforms can be managed to a more than acceptable degree of
> reliability. I will leave it to others to debate the adequacy of
> security tools and which environment is actually more secure although
> here again, I suspect management concern and practice is more
> important than the actual hardware and software. A place that makes
> certain that access is cut off when people leave the organization and
> that change the access available as the responsibilities change
> probably is ahead of all too many places and this has nothing to do
> with the particular computer environment.
>
> Without disclosing anything organization confidential, I would be
> interested in some idea of the size of the organization that you
> (Pete) are consulting at, the size of the computer configuration in
> terms of compute power and disk space, the sort of disaster recovery
> expectations and the people assigned to various tasks such as
> operating system maintenance. I realize that publishing this
> information could well make your client twitchy so if you can't
> respond, or it is too much work, I will understand.
>
| |
| Pete Dashwood 2006-08-06, 7:55 am |
| Some quick comments below, Clark.
A very fair post. The points you raise and the questions you ask are all
very pertinent.
However, I believe the answers would be difficult to come by, and would be
coloured by perception.
At the end of the day, people form their own opinions and these are unlikely
to change. I've worked in both environments (although I accept that the
mainframe environment has changed dramatically since I was a system
programmer) and I see a need for both.
As stated previously, my objection is superciliousness, whether that be in
the form of Client/Server people despising procedural code, or mainframe
people talking about 'toy' computers...
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:jigad2dq1s7rma8b0or816p5o14njp5gpn@
4ax.com...
> On Wed, 2 Aug 2006 22:56:43 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
>
> In this discussion, one of the problems is that there are a number of
> ways to spilt up the work regardless of platform. Thus the group I
> was a part of also took care of installing and customizing the IDE
> (more accurately Fragmented Development Environment), installing the
> compiler and setting the options and storage management.
I liked 'Fragmented Development Environment'... :-) Having developed COBOL
under ROSCOE and TSO, and watched performance degrade as production came on
stream (development being the lowest priority), then having to go to SPUFI
to check out my databases (before windows were available :-)) it would seem
that maybe not so much has changed.
Nowadays I can watch my cobol component code in an Animator, see my database
being updated in a separate window, do whatever I want/need to do, on a
machine that has a processor dedicated to just me, so response time is
ALWAYS instantaneous... I would really not want to go back to SPF and TSO...
But, having said that, it took a while. I couldn't understand why PC editors
weren't like SPF, and I never thought I'd see the day when a full blown
relational database would run on a PC...
We are basically creatures of habit. As Richard has remarked here on a
number of occasions, what we are familiar with is what we consider to be
good.
> Installing a
> new level of maintenance was a major project and was normally done
> only once a year at the shop where I was a systems programmer. Fixes
> for problems affecting the shop might be installed between going to
> new levels. This is worth discussing in more detail because movement
> to or from any given platform may be made based on inadequate
> perception.
That was one of the things that bugged me about the mainframe environment.
Just when you have everything working like it should, they change the
Operating System or the DB Management facility, or there is a new version of
CICS... I know it isn't so dramatic now, but it used to bring everything to
a halt...:-)
>Most people have very vague ideas about what their
> organization's systems programming / systems administration / network
> administration department does and how the time is spent. Some places
> will have the IDE and middleware as the responsibility of that
> department, others won't. Some will have one group responsible for
> all operating systems while others will have separate departments. The
> amount of testing will be different. Centralization of task should
> lead to consistency of environment but one Unix shop that had
> converted from the mainframe had different arithmetic options for the
> online (psuedo-CICS programs in Unix from CICS) COBOL compiles than
> for the batch. Since this involves intermediate results I don't know
> how much difference this made in practice.
>
>
> In discussing the mainframe environment, I suspect that the tool that
> keeps track of fixes is much more arcane than the one for PC's. On
> the other hand, use of this tool can prevent installation of fixes
> already found to be bad. Some of the difference lies in scale of
> system and the need for use of the tools. A large scale server
> network will need a tool that keeps track of usage of various
> resources, hierarchical storage managers, etc. Windows XP home
> actually has a rather nice looking task monitor that would probably
> completely baffle 50 percent of those using XP.
I wouldn't agree 50% of the PEOPLE WHO ARE IN I.T. (Maybe the general
population, OK...) I use Task Manager every day.
> There are mainframe
> shops where virtually all of the systems type work is done by one
> person.
Yes, he is usually a very antisocial person who cannot relate to mere
mortals. You speak to him in Assembler and he reads Hex Memory dumps for
pleasure, (following control block chains with an obsession that rivals XBOX
fanaticism) before going to sleep... not that he ever sleeps, of course.
He has dark, panda like circles, around his eyes, his nails are chewed and
you are best to stay upwind unless you have a strong stomach. This is the
man who the whole IT environment revolves around. When he finally has his
nervous breakdown, he is replaced by someone who, within three months, has
attained the same state...
System Programming is best avoided...:-)
Volatility of the environment (changes in task, need to keep
> current, variability of work load) closeness to bleeding edge, amount
> of customization and similar factors probably have a greater effect on
> staffing. You have shops that don't keep current on the tools that
> can automate monitoring, problem determination, etc regardless of
> operating system. There are organizations that will spend big dollars
> to keep the Unix/Windows/etc. environment current but won't spend a
> cent on the IBM / Unisys / other mainframe environment because it is
> going away and has been for 10 years.
Yes, that is very true. And it creates chaos and highly demotivated
workforces. It's because the Senior Management never REALLY planned the
introduction of new technology, or recognised the need for transition rather
than overnight Big Bang change, or to keep legacy running while all the new
technology was being thoroughly tested and parallell run...
>
> It actually would be very instructive to measure the following for
> each of the environments (mainframe, Unix network, Windows network,
> other):
>
> 1. Are the up time and reliability expectations the same and what are
> they? This includes recovery from outage. What resources in terms of
> monitoring, hardware and people are devoted to these tasks (in terms
> of people, fractional numbers make sense because it may be a part time
> task)?
>
> 2. How is security handled and what resources? Again are the
> expectations for each of the environments (there may be valid reasons
> for differences in this and the other areas)?
>
> 3. How is storage management handled including backup and what
> resources?
>
> 4. How is business continuity (disaster recovery) handled? Remember
> loss of the wrong logical disk can cause MAJOR problems.
>
> 5. Who is responsible for the development environment (the IDEs or
> FDEs)?
>
> 6. Is development on a separate system (could be a separate logical
> machine on IBM mainframes, many Unix systems, the IBM i series and I
> would guess Unisys and other mainframe manufacturers), also operating
> system test? Keeping separate environments in step can be
> interesting.
>
> While this is just a small sample of the questions, thorough
> investigation will yield interesting answers for any of the
> contenders. The various mainframe architectures (IBM z series, etc.)
> will have tools in some areas that the other environments only dream
> of while being behind in others. The software costs which come in
> bigger chunks on the mainframe may actually be smaller for that
> environment than for clustered servers. The people costs get to be
> interesting because they may depend more on management policy and
> expectations of service than on the particular platform. I contend
> that for most places that are not 24/7 and that can tolerate
> infrequent short outages (once every three months), any of the major
> platforms can be managed to a more than acceptable degree of
> reliability. I will leave it to others to debate the adequacy of
> security tools and which environment is actually more secure although
> here again, I suspect management concern and practice is more
> important than the actual hardware and software. A place that makes
> certain that access is cut off when people leave the organization and
> that change the access available as the responsibilities change
> probably is ahead of all too many places and this has nothing to do
> with the particular computer environment.
Absolutely. I couldn't agree more. These are excellent points, and, as you
observe, it really doesn't matter what you are running. I believe many
places suffer from an uninformed senior management team who substitute what
they read in this w 's PC World for real understanding, and simply follow
fashion. Instead of getting second opinions or employing people who know
what they are doing to evaluate the situation and suggest strategies, they
decide they want to be 'over there' and lead the troops in a headlong rush
across the valley, never realising there is quicksand at the bottom of it...
>
> Without disclosing anything organization confidential, I would be
> interested in some idea of the size of the organization that you
> (Pete) are consulting at, the size of the computer configuration in
> terms of compute power and disk space, the sort of disaster recovery
> expectations and the people assigned to various tasks such as
> operating system maintenance. I realize that publishing this
> information could well make your client twitchy so if you can't
> respond, or it is too much work, I will understand.
Well, I don't think the company has anything to hide, but I certainly
wouldn't presume to give away stuff that might be commercially sensitive or
of value to a competitor.
I can say there is an Unisys mainframe which is being upgraded and run
inhouse on different hardware, for a substantial cost saving. This is
currently running the legacy core systems which are written in procedural
code (LINC and COBOL). These systems are very old, but doing the job. There
is also a state of the art core (Object Oriented) system package in the
offing which may or may not be implemented. Those would be the two major IT
concerns. In addition to those, there are a number of disparate applications
(mainly Windows based) which carry out various functions. Then there is a
fairly computer literate non-IT staff who write their own spreadsheets and
databases and have to be reined in from time to time :-) Disaster recovery
is well planned and has been tested on several occasions and found to be
adequate. All of the IT infrastructure is managed by a separate Division of
the Company. I don't know how many people are employed full time managing
the network and such, but I would estimate 15 or 20 onsite, and others
spread around various parts of the company. The full IT department is less
than 100 people, in Auckland. Across the Group (which includes Australia) it
would be much more.
The NZ Management vision is to move to a SOA and I agree with this. However,
it is not easily achieveable at the moment.
Like all sites there are things they do extremely well and other things that
are perhaps not so good, however, it is fair to say that on the whole, the
IT department tries very hard to be responsive to the Business, and are
succeeding. One part of the IT group recently won a prestigious award for
technology integration with a third party. It was an imaginative solution.
(Written mainly in Java)
It is a good place to work and the corporate 'culture' is excellent. This
probably filters down from the CEO who is a much liked and respected man. On
the few occasions when I have chatted with him I found him to be astute,
supportive, interested, and perceptive. He inspires confidence and I think
that affects everyone below.
I can't really give details of processor power and disk capacity, as you
requested but it is 'medium' sized... (where 'small' would be less than 1
terabyte...) We run a number (I won't say how many) of servers with multiple
processors, and what used to run on a Unisys A series is being ported to a
Windows environment.
BOTTOM LINE:
Irrespective of the hardware in use, there is definitely need for
specialists to take care of it.
How successful this is will be is often dependent, not on the skills or
abilities of the specialists (although this certainly helps) but on the
directions and visions established by the management. Where clear direction
to an achievable goal is set, the result is usually success. Where this is
not the case, the degrees of disaster which ensue are governed only by the
organization's tolerance for chaos...
Pete.
| |
| Clark F Morris 2006-08-06, 9:55 pm |
| Much is snipped.
On Mon, 7 Aug 2006 01:42:46 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:
>Some quick comments below, Clark.
>
>A very fair post. The points you raise and the questions you ask are all
>very pertinent.
>
>However, I believe the answers would be difficult to come by, and would be
>coloured by perception.
>
>At the end of the day, people form their own opinions and these are unlikely
>to change. I've worked in both environments (although I accept that the
>mainframe environment has changed dramatically since I was a system
>programmer) and I see a need for both.
It has changed drastically in many ways for those willing to keep up
since the time I was a systems programmer.
>
>As stated previously, my objection is superciliousness, whether that be in
>the form of Client/Server people despising procedural code, or mainframe
>people talking about 'toy' computers...
>
>
>
>I liked 'Fragmented Development Environment'... :-) Having developed COBOL
>under ROSCOE and TSO, and watched performance degrade as production came on
>stream (development being the lowest priority), then having to go to SPUFI
>to check out my databases (before windows were available :-)) it would seem
>that maybe not so much has changed.
>
>Nowadays I can watch my cobol component code in an Animator, see my database
>being updated in a separate window, do whatever I want/need to do, on a
>machine that has a processor dedicated to just me, so response time is
>ALWAYS instantaneous... I would really not want to go back to SPF and TSO...
>But, having said that, it took a while. I couldn't understand why PC editors
>weren't like SPF, and I never thought I'd see the day when a full blown
>relational database would run on a PC...
I understand there are fairly good development tools available for the
various mainframes although I haven't had the pleasure to work with
them. Many shops now have separate development machines (logical or
physical since many shops have multiple images sharing multiple CPUs
and operating as if they were standalone). I suspect there is still
more hassle in the shared environment than you have on your
development PC. Indeed one of the attractions of both Linux on X86
and Windows is that much can stay the same as one scales up from
individual test to acceptance testing and production.
>
>That was one of the things that bugged me about the mainframe environment.
>Just when you have everything working like it should, they change the
>Operating System or the DB Management facility, or there is a new version of
>CICS... I know it isn't so dramatic now, but it used to bring everything to
>a halt...:-)
And the same isn't true of both Windows and Unix? From what I have
read, major upgrades in both environments are at least as freighted
with breakage on upgrade and I know that in the HP-UX shop I
contracted at, the upgrade from 11 to 12 (or was it 10 to 11) and the
related Oracle upgrades were going to have at least as much impact as
anything I dealt with in the MVS area.
>
>
>I wouldn't agree 50% of the PEOPLE WHO ARE IN I.T. (Maybe the general
>population, OK...) I use Task Manager every day.
>
I meant the total population of Windows users. I suspect that outside
of the IT department and maybe even including some of those in it
would not relate to it. On the other hand the now retired school
psychologist down the road from me probably understands it better than
I do. I know he is more into networking than I am and he can fix
hardware.
>
>
>Yes, he is usually a very antisocial person who cannot relate to mere
>mortals. You speak to him in Assembler and he reads Hex Memory dumps for
>pleasure, (following control block chains with an obsession that rivals XBOX
>fanaticism) before going to sleep... not that he ever sleeps, of course.
>
>He has dark, panda like circles, around his eyes, his nails are chewed and
>you are best to stay upwind unless you have a strong stomach. This is the
>man who the whole IT environment revolves around. When he finally has his
>nervous breakdown, he is replaced by someone who, within three months, has
>attained the same state...
>
>System Programming is best avoided...:-)
While I probably lack some social skills, I assume that you are
exaggerating. The Unix systems people, Linux systems people and the
Windows ones who are maintaining a complex environment probably
exhibit the same characteristics of being into weird system arcane
knowledge. I enjoyed being able to get information out of the dumps
because I was solving problems for the organization (in newspeak,
taking advantage of opportunities). While I know a lot of systems
people through SHARE and have worked with them I haven't noticed lack
of personal cleanliness although we might have been a bit ripe after
24 hour sessions. It's fun recovering your data center when water
takes out the model 65 running MVT and IBM doesn't know whether MVT
can be generated for a 4341 compounded by the CE not knowing anything
about Unit Control Words.
>
>
>Absolutely. I couldn't agree more. These are excellent points, and, as you
>observe, it really doesn't matter what you are running. I believe many
>places suffer from an uninformed senior management team who substitute what
>they read in this w's PC World for real understanding, and simply follow
>fashion. Instead of getting second opinions or employing people who know
>what they are doing to evaluate the situation and suggest strategies, they
>decide they want to be 'over there' and lead the troops in a headlong rush
>across the valley, never realising there is quicksand at the bottom of it...
In terms of the amount of effort to achieve goals, each platform has
its strengths and weaknesses. While this was at least 7 years ago, I
know that I was surprised to hear a person who had just given a talk
on security in the Unix environment state that it still wasn't as
secure as the IBM mainframe with a properly administered security
system (note the properly administered). In that same era the
database people who were responsible for all file and database
management and related monitoring for both MVS and Unix felt that the
tools still were not there in the Unix environment. Thus the platform
may well determine how many people you need to provide a given level
of function. The Windows and maybe Unix environments may well make it
far easier and less people consumptive to provide a really good
development environment although IBM MAY have gotten it right with
Websphere and related products. On the other hand the add-on tools
for file and data base management as well as certain things in the
system design may make it easier to do security, data management and
recovery management.[color=darkred]
>
>Well, I don't think the company has anything to hide, but I certainly
>wouldn't presume to give away stuff that might be commercially sensitive or
>of value to a competitor.
>
>I can say there is an Unisys mainframe which is being upgraded and run
>inhouse on different hardware, for a substantial cost saving. This is
>currently running the legacy core systems which are written in procedural
>code (LINC and COBOL). These systems are very old, but doing the job. There
>is also a state of the art core (Object Oriented) system package in the
>offing which may or may not be implemented. Those would be the two major IT
>concerns. In addition to those, there are a number of disparate applications
>(mainly Windows based) which carry out various functions. Then there is a
>fairly computer literate non-IT staff who write their own spreadsheets and
>databases and have to be reined in from time to time :-) Disaster recovery
>is well planned and has been tested on several occasions and found to be
>adequate. All of the IT infrastructure is managed by a separate Division of
>the Company. I don't know how many people are employed full time managing
>the network and such, but I would estimate 15 or 20 onsite, and others
>spread around various parts of the company. The full IT department is less
>than 100 people, in Auckland. Across the Group (which includes Australia) it
>would be much more.
Here is where the fun is. I know that I have put into place various
tools for monitoring system usage that were not robust enough to be
sent to other shops. Testing of anything, be it a spreadsheet, a date
routine or an entire system can be time consuming and looking right
doesn't necessarily mean being right. There is also the question of
what data should be included or excluded. I know at one shop whether
something constituted a sale or reduction to sales depended on which
department you were talking to. I know of one fairly large sized
company that has (probably now in maintenance mode) a project to
clearly define all terms used so that a product number has the same
meaning in all departments.
>
>The NZ Management vision is to move to a SOA and I agree with this. However,
>it is not easily achieveable at the moment.
>
>Like all sites there are things they do extremely well and other things that
>are perhaps not so good, however, it is fair to say that on the whole, the
>IT department tries very hard to be responsive to the Business, and are
>succeeding. One part of the IT group recently won a prestigious award for
>technology integration with a third party. It was an imaginative solution.
>(Written mainly in Java)
>
>It is a good place to work and the corporate 'culture' is excellent. This
>probably filters down from the CEO who is a much liked and respected man. On
>the few occasions when I have chatted with him I found him to be astute,
>supportive, interested, and perceptive. He inspires confidence and I think
>that affects everyone below.
>
>I can't really give details of processor power and disk capacity, as you
>requested but it is 'medium' sized... (where 'small' would be less than 1
>terabyte...) We run a number (I won't say how many) of servers with multiple
>processors, and what used to run on a Unisys A series is being ported to a
>Windows environment.
>
>BOTTOM LINE:
>
>Irrespective of the hardware in use, there is definitely need for
>specialists to take care of it.
>
>How successful this is will be is often dependent, not on the skills or
>abilities of the specialists (although this certainly helps) but on the
>directions and visions established by the management. Where clear direction
>to an achievable goal is set, the result is usually success. Where this is
>not the case, the degrees of disaster which ensue are governed only by the
>organization's tolerance for chaos...
Whole hearted agreement.
>
>Pete.
>
>
>
|
|
|
|
|