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 that....was 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:.
