I loved CMS many years ago. I no longer work for a company with z/VM. Haven't for years. Using CMS and RSCS to submit jobs to MVS (yes, that long ago - MVS 3.8!) was so much better than TSO it wasn't even funny. Now I'm using a Linux desktop and writing code which allows me to use it for some things instead of TSO. OpenSSH is really helping on that. But I'm getting off-topic.
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[email protected]] On Behalf Of George Henke/NYLIC > Sent: Friday, December 10, 2010 10:53 AM > To: [email protected] > Subject: Re: Vswitch Grant as a CMD in User's Directory? > > 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] <mailto:[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] <mailto:[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 > <http://ibm.com/systems/services/labservices> office: 607.429.3323 > [email protected] <mailto:[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. > ************************************************************** > ****************** > >
