Code Comments
Programming Forum and web based access to our favorite programming groups.
Re: Need for people to support operating environment was Re: COBOL - still a place for it..."Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message news:fmqpc2501qjdkoba0nvqvnb229esih43d7@ 4ax.com... > 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.
Post Follow-up to this message
Re: Need for people to support operating environment was Re: COBOL - still a place for it...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 goo d >for some tasks, and I wouldn't disagree with that. > >My original point was that mainframe systems require people who are employe d >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 environmen t >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 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. > >Pete. >
Post Follow-up to this message Re: Need for people to support operating environment was Re: COBOL - still a place for it...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... > 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 Di
Post Follow-up to this message Re: Need for people to support operating environment was Re: COBOL - still a place for it...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... >
Post Follow-up to this message Re: Need for people to support operating environment was Re: COBOL - still a place for it..."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. 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. >
Post Follow-up to this message Re: Need for people to support operating environment was Re: COBOL - still a place for it...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.
Post Follow-up to this message Re: Need for people to support operating environment was Re: COBOL - still a place for it...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 unlikel y >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 databas e >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 editor s >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 o f >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 XBO X >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
Post Follow-up to this message
Sponsored Links
Powered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.
