CA VM Product Beta test
CA Technologies is preparing to start a beta test period involving almost all of our VM products. We have new features coming soon that we hope you will find useful at your sites. If you are a current customer for a CA VM product who is interested in working with us, and would like to get an advance look at some new capabilities, please logon to support.ca.com, using your customer access ID and password. Scroll down and select CA's Enhanced Beta Program, then select the entry for CA Mainframe VM Products to view the list of upcoming enhancements. If there is a product or feature in this list that you would like to work on with us, please register for the Beta program. Thank you, Bob Bolch
Re: End of an era
I consider myself very fortunate that I am able to do REXX programming every day.. and be paid for it! My appreciation for Mike's contributions to all of us is widely shared, but we VMers got to appreciate what he has done way before anyone else. Bob Bolch
Re: Using LBYONLY
It's perfectly fine to discuss the way things should be -vs- the way things are, but when a design is more than 20 years old, as in this case, then the way it works now is, by definition, the way it should be. Making some changes is just too painful. An obvious exception has to be made when the way it works now conflicts with some new behavior, that was unanticipated by the original design, but I don't think this is one of those cases. Bob Bolch
Re: Changing DRCT size
Oh yes: with DIRMAINT there is no problem as with VM:Secure. It doesn't need to be brought down. Starting with r2.8 Service Pack 1, VM:Secure provides a new CPFMTXA command which allows you to change the allocation map on a volume containing the DRCT area, without taking VM:Secure down. It can be used to add new directory cylinders or to modify any non-directory cylinders. To remove directory cylinders, we suggest taking VM:Secure down as in previous releases. The VM:Secure CPFMTXA command works by locking out changes to the directory area, running the IBM CPFMTXA command, and then refreshing its own in-memory cache of the allocation map. Bob Bolch
Re: Changing DRCT size
I do hope the implementation *DOES* run DIRECTXA after changing the allocation map.. No, but it does issue a Diagnose 3C to bring the changed allocation online properly. Bob Bolch
Re: Secure ACTIVATE
The VM:Secure Reference Guide documents: VMSECURE MAINT MANAGE userid ACTIVATE Bob Bolch From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, February 19, 2009 1:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Secure ACTIVATE Is there any line command in VM:Secure for activating a userid that is being held, or is the MULTIPLE command the only way? Of the 4 functions of the MULTIPLE command (ACTIVATE, HOLD, NEWUSER and REMOVE), ACTIVATE and HOLD do not appear to have line mode counterparts. Regards, Richard Schuh
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
VM:Secure would also prompt for MAINT's password, using the logic that even if you had LOGONBY to a user ID, that wouldn't grant you the capability to change the directory entry for that ID. Bob Bolch - I'd say it should prompt for BUELENSC's password (I am not supposed to know MAINT's password when using LOGONBY)
Re: CMS threading, Preemption, Involuntary vs Voluntary loss of control
The CMS Multitasking dispatcher does not use preemption. A thread must block or yield, or call a CMS application programming interface which blocks or yields, before another thread is dispatched. Bob Bolch CA
Re: new VSMDCSS in z/VM 5.4
They still retain SFS as a requirement for implementing a shared logging facility for the SMAPI servers, so none of that complexity is alleviated. I suspect that the SFS based queuing had to be based on polling for a communications file, where the writable segment based CMSMT-IPC driver can use external interrupts instead of polling. (CMS multitasking allows transport services for inter-process communications to be added through a programming interface. It comes with IUCV or APPC, and folks have written other transport drivers for TCP and now writable segments. They didn't document the segment driver for customer use though.) Worse than the fact that the NAMESAVE record is inserted dynamically, is the fact that it's all a secret. All resource access control needs to be documented, so that an ESM can be used to control access instead of the native CP access control (NAMESAVE record, in this case). The SMAPI developers did the same thing for SFS, in that internal code issues SFS GRANT AUTH commands. They should have spelled that out more clearly for those with an SFS ESM interface. I don't see how this implementation passed RACF testing internally. Bob -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Monday, November 24, 2008 9:39 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: new VSMDCSS in z/VM 5.4 Bob Bolch wrote: The support for the System Management API servers is enhanced in 5.4.0 to use this writable saved segment for inter-process communications, rather than use SFS to communicate between the SMAPI request servers and the worker machines. I wonder what prompted them to do thatwas something wrong with the SFS interface? Just a guess: SFS has no direct interfaces from Linux, and probably won't ever have them because somebody would have to grovel through that code and figure out (and document) how SFS interacts with APPC and other bits of CMS. Using a segment is all CP services, and Linux already has code to deal with DCSS-based data. Makes future extensions of the SMAPI support a lot simpler if they don't have to deal with CMS programming and language restrictions (no Java, etc). Also, think about complexity. SMAPI is supposed to be the interface for management widgets to use to control VM without knowing squat about CMS or ever seeing that nasty 3270 green-screen. SFS is not trivial to set up for newbies (for anybody, IMHO). DEF SEG is one command and you're ready to rock and roll. You also get positive feedback (the rc) that it was successful and available w/o any extra programming. Seems like a reasonable choice if you take these two points as gospel. We tried to convince IBM during the 5.4.0 ESP that it was more appropriate to statically define the NAMESAVE record for this segment in the source directory entry configuration files for the SMAPI user IDs and document the use of that segment, rather than dynamically (and secretly) add it to the SMAPI user IDs whenever SMAPI was started. They disagreed. My vote's with Bob. Hard-coding stuff like this seems like a user requirement in the making -- somebody is going to want to have control over the name. Same problem in DFSMS with hard-coding VMSYS:.
Re: new VSMDCSS in z/VM 5.4
The support for the System Management API servers is enhanced in 5.4.0 to use this writable saved segment for inter-process communications, rather than use SFS to communicate between the SMAPI request servers and the worker machines. We tried to convince IBM during the 5.4.0 ESP that it was more appropriate to statically define the NAMESAVE record for this segment in the source directory entry configuration files for the SMAPI user IDs and document the use of that segment, rather than dynamically (and secretly) add it to the SMAPI user IDs whenever SMAPI was started. They disagreed. Bob Bolch -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dave Jones Sent: Saturday, November 22, 2008 9:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: new VSMDCSS in z/VM 5.4 I was taken a look around a new z/VM 5.4 install, and I've noticed that there is a new DCSS: VSMDCSSI've found that it's created when VSMWORK1 is started, but that's about it. It's not documented in the 5.4 publication library; at least a search for it from the bookcase returns 0 hits. What's it for? Thanks. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: VM Virtual CPUs and Threaded CMS Applications
All execution of CMS linkage interfaces (CMSCALL, SVC 204, SVC202, etc.) and most common direct branch interfaces to CMS services executed on a non-base CPU result in running intercept code that switches that thread back to the base CPU for execution of the service. Another way to say it is that all the code in the CMS Nucleus only runs on the base processor. Each CP service defines how it executes on a non-base processor. Things like IUCV and most Diagnose codes work just fine. In CMS Multitasking, non-base processors are intended for pure code not requiring CMS services. Bob Bolch From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gary M. Dennis Sent: Monday, October 20, 2008 8:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM Virtual CPUs and Threaded CMS Applications I appreciate your insight. When you state: If you're not invoking CMS services from non-base threads What precisely do you mean by CMS services? Are you referring specifically to the services defined in CP Programming Services OR any call to CMS?
Re: PPF question
But the SERVP2P name is hardcoded in the SERVICE and PUT2PROD EXECs, so isn't overriding SERVP2P ineffective when using those commands? Bob Bolch CA -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Carol Everitt Sent: Thursday, October 16, 2008 1:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: PPF question Jim, Yes, you can always use the SERVP2P PPF. As a matter of fact, we recommend that you use it. And if you need to create an override PPF for your site, we recommend that you override the SERVP2P PPF, rather than a base PPF.
Re: listing active user directory
While GLOBALV is useful for setting default behavior (e.g. DEFAULTS), I wouldn't propose using it as a database of directory metadata. Adding USER DIRECT metadata to the object directory seems useful and is relatively straightforward to implement. I'd want filename, file timestamp, and source mdisk. Alan Altmark z/VM Development IBM Endicott There could be a lot of timestamps and source minidisks in a cluster format source directory. Bob Bolch
Re: Moving On...
I wish I had a nickel for every time Chris has helped me over the years. She has been an outstanding contributor to the success of VM, and I will miss her expertise and insights. Bob Bolch
Re: VMRM?
Chris Casey has not retired just was at 2 MVMUA meetings this year. She CAN'T retire just yet. I have too much work for her to do. Bob Bolch
Re: Question about SMAPI
The SMAPI server requires a directory manager, and DirMaint has been enhanced to work with the new server. From IBM's perspective, there is no reason to not go there just yet. One reason might be that your provisioning product supports the RPC server but does not (yet?) support the SMAPI Socket server. One product in this situation is IBM Director (from IBM). Bob Bolch
Re: Ops privs
But isn't FORCE just shorthand for LOGON u1 HERE By u2 followed by LOGOFF? Bob Bolch I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. David Boyes [EMAIL PROTECTED] wrote :-
Re: z/VM usability
Build it and they won't come. Show them how it makes their lives easier and they WILL come -- lowering their TCO and buying more mainframe mips, too. z/VM is a collection of fabulous tools. Use the best tool for the job at hand, sometimes: CMS. Mike Walter A prime example of doing just that is the System Management Application Programming Interface server, which has been available for last few years. All of the facilities needed for creating and managing a collection of Linux application servers under VM are available to a client program running in Linux or even on Windows. The SMAPI server distributes control of your running Linux servers and allows cloning of new servers using your choice of VM:Secure or DIRMAINT directory managers. All the pieces run on CMS. It's a great place to run servers! Bob Bolch
Re: Z/VM 5.3 and VMSECURE
The CA policy is to announce support requirements for new levels of an operating system at GA of the new operating system release. Bob Bolch -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Hughes, Jim - OIT Sent: Tuesday, April 10, 2007 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Z/VM 5.3 and VMSECURE Will VMSECURE require maintenance when I move from Z/VM 5.2 to Z/VM 5.3? Will the existing Z/VM 5.2 installation instructions work for Z/VM 5.3? Jim Hughes 603-271-5586 There's no sense in being precise when you don't even know what you're talking about. John von Neumann
Re: Building NonRACF CP Module
I mis-remembered. My files show it's on the VMSECURE 192. Bob Bolch -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, March 23, 2007 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Building NonRACF CP Module We do not seem to have that command, at least not on the 176 disk. I cannot check further as our VM systems are all down due to h/w a failure that occurred at 1:00 am this morning. Regards, Richard Schuh
Re: Building NonRACF CP Module
VM:Secure has an undocumented command for this purpose. It requires that the issuer ID be authorized by having an IUCV *RPI record in its directory entry. The command is (believe it or not): VMXYZZY [ENABLE|DISABLE] to DISABLE or ENABLE VM:Secure rules processing. ACI calls are defered to CP when processing is disabled. However, LINK and LOGON commands are still processed by the VM:Secure CP code, so that encrypted passwords in the object directory are resolved properly. The module is on the VMRMAINT 176, I believe. Bob Bolch -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, March 22, 2007 12:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Building NonRACF CP Module I heartily concur. It would be nice if VM:Secure had the same capability. Regards, Richard Schuh
Re: A z/VM idea.
Both DIRMAINT and VM:Secure have the ability to store and retrieve user specified comment records in a CP Directory source entry. Each of these comments has a tag identifier for easy retrieval by tag name. Bob Bolch
Problem Reporting, was: Corrupted IPL Record
A few weeks ago we were seeing comments like this: As for the VM:Secure thing, I find that simply documenting how the product can screw up a system is not only an unacceptable answer, it borders on repugnance. A strategic product that should always be working should never violate the integrity of the system. There is no justification for it. The changed allocation on the disk must be respected. Reallocating a disk is a normal maintenance activity. I'll second this comment. This is a serious bug impacting system integrity. Documenting the bug is not an acceptable response. Yvonne then asked for any VM:Secure customers who were being impacted by this problem to call CA support and register their concern. Not one customer called in. For CA to allocate resources to customer problem resolution, the problems must be reported to CA technical support. VM:Secure has worked in the same manner, regarding the cached allocation map, for almost 25 years. One call from Mike in a quarter century does not sway management in the direction of allocating resources to do a design change in this area.. Complaining about something on the list is positive, in that it encourages discussion on issues. However, software vendors allocate resources based on submitted requirements and technical support calls. Speaking to Fran or Kitty is a very pleasant experience. It's easy to do and you'll enjoy it. Bob Bolch VM:Secure team
Re: 3270 Programming under z/VM
Dave said: Richard, I agree with you that XMENU/E was a really goodtool for doing this sort of work. However, given CA'scomplete and total understanding of the VM market, I amalmost positive it has been withdrawn frommarketing..;-) I checked, and XMENU is still being marketed and is fully supported. Bob Bolch
