> Why would you want a CMS tool to access SMAPI when SMAPI is mostly (at > least it seems to be to me) a programmable extension of Dirmaint? Why > not just use Dirmaint, that is what SMAPI does in the end.
Two main reasons: 1) not everyone uses DIRMAINT for user and system management, and 2) the SMAPI can do more than just user directory management, so DIRMAINT doesn't cover the entire range of function. Here's a simple example case: say I write an tool that needs to manipulate a user directory entry. I run VM:Secure, you run DIRMAINT, and my friend Nick runs ACF2/VM, while Alejandro down in Mexico City might want to take advantage of the same kind of user manipulation from a Linux guest. If I have a CMS command-line utility interface to SMAPI, I don't care which directory management product you use -- my application calls the CMS utility interface to SMAPI and the right thing happens, regardless of directory management product. I maintain my application to work with SMAPI, the directory manager vendors maintain the interface between their product and SMAPI, and everyone gets what they want. If I don't use SMAPI, then I need to write separate interfaces to each possible directory management product, and maintain those interfaces, which just makes things harder. I also find that most people don't write in C on CMS -- it's far more likely the tools will be written in REXX, which has no native facility for calling LE-based C library functions without dipping into assembler -- try that sometime when you're in the mood for a challenge. I'll also comment that there is still a load of COBOL being written on the CMS side -- if you've ever tried to call a C routine from COBOL, you'll know how much easier it is to call a CMS command with a set of parameters. (no cracks on writing COBOL for this kind of thing -- I usually have to clean up the messes from people *doing* such things; if COBOL is what they know, then that's what they use.) If a simpler CMS-user-friendlier interface to SMAPI existed, it would facilitate faster adoption of this common interface -- the easier it is to use, the quicker people start to use it (although I probably should be careful what I wish for -- this sort of thinking got us MS Windows...8-)) -- thus the analogy to RXSOCKET. If something like that -- call it SMAPI -- existed, you'd have a far better chance of being able to rapidly produce applications capable of autonomically managing a VM system. As you say, you can accomplish the desired effect with existing tools, but if everyone's using the same API from user space to CP controlled resources, it makes things a lot better in terms of ease of use and integration, and as Alan pointed out, it makes it possible for CMS and non-CMS applications to manipulate resources in the same way using the same toolkits. Think about workload management, automated provisioning, stuff like that -- managed from a central service. Maybe I'm basically a lazy programmer, but why invent more complexity than necessary if the job can be accomplished by a well-designed system service interface *and small easy-to-use tools for each environment to manipulate functions via that interface*? That's what I'm after. We're halfway there -- we have the service API. Now we need the tools to exploit it, and "buy Tivoli" isn't a good answer to "how do we exploit that function?" All in all, the SMAPI is there, and it's pretty good -- if a) you have the tools to get to it and b) understand how to use it. The utility I'm asking for addresses the sites that don't have the C compiler and so can't solve a), and reduces the complexity of VM system management for newbies, thus attempting to address b). -- db David Boyes Sine Nomine Associates PS- for those of you who ever did any serious time on Digital systems, this is the approach that DEC did very well for VMS: a set of well thought out system libraries that provided service interfaces to the priviliged stuff, callable from EVERY SINGLE SUPPORTED PROGRAMMING LANGUAGE through a common interface. Sometimes the calling conventions were a little tortuous, but you could write tools that could drive any aspect of the system configuration process from something as awful as DCL or Fortran and not have to care, and you could do the same with RPCs from other systems via a small RPC agent -- the end code executing the function was exactly the same regardless of platform or initiation, local or remote.
