In the April, 2003 issue of MeasureIT, we introduced a new feature - a chat room of sorts where professionals could share their thoughts on issues and technology. The first dialog focused on the new .NET architecture and related performance and security concerns. We received feedback in response to that article. We are glad to be able to share these additional thoughts with you.

Bob Johnson, Office of Personnel Management:

I didn't see any mention of the "proprietary nature" of the operating system and upward compatibility philosophy of the mainframe being considered. The security subsystem for z/OS is relatively the same as the one used for OS/390 back dozens of years. I used Top Secret in the early 1970s, and it is still going strong. I used ACF2 and RACF, and they are still going strong. What mainframe does not use one of these security systems? It is much easier to plug, and keep plugged, the security holes in the mainframe operating system.

The problem with open operating systems is that they just don't stand still. Kind of like a two-year-old, high on sugar! Coming from a vendor that tried for 6 years to write systems software for UNIX and NT systems, it was impossible. Just as my developers and QA staff got a release ready and tested, some customer put a patch on the UNIX kernel or the NT system and everything changed. My sales reps refused to sell the product because it embarrassed them. We finally pulled the plug on development. With very little secure, common operating system code, it is no wonder that "new" problems pop up with every release.

It was funny reading Mark's piece about the horse race scheme. If the scoundrels had added an edit to not get in on the bundle unless there were 2-3 others there too, we may not have this story to chuckle about! Insiders always get in.

But I'd most like to take issue with one of the premises of this chat room: "Security or Performance." To modify the old disk performance adage: "pick any two!" I don't think the open-systems environment can afford not to have security.

Jaqui Lynch (of CMG fame and fortune) often beat me up when I tried to say the mainframe was more secure than open systems. She (rightly) insisted that both can be made as secure as you want to pay for. Even TCP/IP can be made secure using secure sockets. (Who out there is NOT doing that?) Since I'm into model trains (and I just installed a sound module on my 2-8-0 steam engine), let me refer you to the light (and sound) in the tunnel. The light is not the end of the tunnel. It is Linux on z/Series. The sound is not the wind in the tunnel. It is annunciation of the death of .Net and proprietary UNIX systems unless they become secure and manageable. IBM and CA are serious as heart attacks providing for security, management, and backup/disaster recovery on Linux on z.

If open systems administrators don't "pick any two" they will find corporate C*Os moving back to the mainframe in droves. Who does that lonesome whistle call for? It calls for you, System Administrator!

Michael A. Salsburg, Ph.D., Unisys:

I'd like to go back to the original thread, which was a comment:

"That's a lot of cycles, network activity, and time."

Firstly, if the processing is splintered off into resolving a number of URIs, and they can be processed in parallel at different locations throughout the Web, the number of cycles, the network activity and the (elapsed) time are processing in parallel. Think about the impact in computing when multi-programming was first supported in the OS. That revolutionized the world of business computing.

If the work is properly structured, the delay time may only be the maximum time to get one of these tasks to complete. So, it's all relative to your perspective. From the user point of view, the delay time can be quite short. And that's all we need to worry about. On the other hand, a poor implementation for resolving the namespace can have a very negative impact.

It sure looks like we have a lot of work to do. And we're not in Kansas anymore. We have an embarrassment of abundance in CPU cycles and underutilized systems. Ethernet is quickly approaching 10 Gb/s. The new standards and protocols may not appear optimized when compared to the contortions we used to go through for that last byte/millisecond. On the other hand, it "kicks it up a notch" in the development food chain and, hopefully, goes another step to providing services to the end user that are more accessible and informative.

Editor:

I want to thank Bob and Michael for their comments. In closing, I would agree that both security and performance are important and achievable with any architecture. As Michael implied, it all comes down to how a system is designed. We can all remember mainframe applications that had terrible response time, and many very complex open applications are consistently delivering sub-second performance. It all comes down to choices.

I would also have to agree with Bob and pick two. Ask any network security analyst at major corporations how many million times a month their systems are being probed or how often it appears that someone is trying to hack into their systems. It would probably scare you. Security is not an option today - it is a part of the cost of staying in business.