Some companies in the past preferred to confine application programmers to CMS due to the large overhead of TSO address spaces thereby realizing savings in CPU and storage.
CMS is not as well liked as TSO/ISPF by application programmers, but given CPU price sensitivity these days, it may not be such a bad idea and, who knows, it might even convert them z/VM. Bill Munson <[email protected]> Sent by: The IBM z/VM Operating System <[email protected]> 12/10/2010 10:57 AM Please respond to The IBM z/VM Operating System <[email protected]> To [email protected] cc Subject Re: Vswitch Grant as a CMD in User's Directory? Tom, as Mike said there are a lot of companies I know of that are using "CMS" applications for day to day work and the DATA resides on "VM" they are using "FOCUS" for report generation , as well as "MAILBOOK" for e-mail and interoffice file transfers , and some are using VM:Backup and VM:Archive and the Shared File System for numerous versions of Source Code like GDG's on TSO and submitting their compiles and assembles to VM:Batch for processing. There is still a lot of WORK being done on "VM" and these companies are not running any other "OS" as a guest of these "VM" systems. They might and do have other "VM"'s for running LINUX or "VSE" . Granted it is a vast minority of what it was 10, 15, and 20 years ago. munson From: Tom Huegel <[email protected]> To: [email protected] Date: 12/10/2010 09:16 AM Subject: Re: Vswitch Grant as a CMD in User's Directory? Sent by: The IBM z/VM Operating System <[email protected]> Does anyone run applications in z/VM? Isn't the 'protected data' owned by some other OS (z/OS, z/VSE, zLINUX). It seems that the high level security effort belongs in those OS's. z/VM just needs to keep those systems isolated and NOT be able to circumvent their security procedures. On Fri, Dec 10, 2010 at 2:46 AM, Les Koehler <[email protected]> wrote: Back in the old days, I recall a finance type person saying something like: The Gold Standard is that it should take collusion between two or more people to defraud the company. If we apply that to IT, then shouldn't pswds for privileged userids that can access/change financial data be long enough that TWO sysprogs can each be given half a pswd so they both have to be present to make a change? Les Alan Altmark wrote: On Thursday, 12/09/2010 at 12:01 EST, Tom Huegel <[email protected]> wrote: Does it really matter? SOX is just another way congress has come up with to destroy the American economy, and in fact the American way of life. When you read the law, you find that SOX is "simply" a way to hold executives responsible for the financial statements issued by their companies. Assuming no ill intent (no comments, please!), that means trustworthy data. That flows downhill, as all such things must, until we start talking about access controls and audit mechanisms for financial data. That is, knowing who has the means and the opportunity to access the data, and knowing who has actually done so. (I leave it to others to talk about motive.) Who, what, where, when. Unfortunately, IT security industry consultants have mangled this laudable concept into a paranoia-inducing behemoth that has people screaming in terror as it rampages across the country, flogging every sysadmin in its path. Why? Because financial status is inferred from many other data sources and no one wants to spend the time it takes to follow all the data flows. Result: Secure Everything. With HIPAA and PCI running alongside, the "Secure Everything" policy looks even more reasonable to CEOs, CIOs, CFOs, and their lawyers. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 [email protected] IBM Endicott *************************** IMPORTANT NOTE*****************************-- The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman & Co., its subsidiaries and affiliates ("BBH"). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus. ********************************************************************************
