On Thursday, 08/20/2020 at 05:40 GMT, David Boyes <[email protected]> wrote: > On 8/20/20, 12:23 PM, "CMSTSO Pipelines Discussion List on behalf of Alan > Altmark" <[email protected] on behalf of [email protected]> > wrote: > > > And I reject the "cruft" reference. The NAMEFIND command is very basic. > Not only can it look up based on the break tag, it can search based on > other values: > NAMEFIND :[email protected] :userid (BREAKTAG :dn FILE X500 > > I would invite you to look at the entry for NAMEFIND in the CMS Command > reference again. Anything that has a syntax diagram that goes on for a page and > a half is not basic or straightforward. > > > Only NAMEFIND *knows* if an entry already exists. Humans are good at > > making claims that are untrue. "It doesn't exist" is one such. > > On the contrary, if I know that I am starting with a newly created empty file > that has no entries in it, then I do know concretely an entry does not exist. > What I want to avoid is an increasing ADD time per entry if I know there is no > possibility for entries to exist or I have already done any vetting for > duplicates that needs to be done outside of the tool, I'm letting the tool know > in advance that it doesn't have to look. In the interest of KISS, I'm not > insisting on APPEND if that gets us to the point of actually coding this; it's > an advisory option to convey my intent to the process; something I would find > useful but isn't necessary.
I don't like APIs that go around the database manager. As soon as you put it in a server application, it breaks the database. Client#1 says 'append X' and client 2 says 'append X'. Both "knew" the database was empty when they appended the entry. Only one was correct. NAMEFIND is very sophisticated in how it keeps track of tags. I think as he comes across break tags, he caches the name and location. > You've just illustrated my point about cruft. NAMEFIND has a lot of old > features to deal with restrictions or scenarios in CMS that no longer exist. > You can't prune it out because it would break existing code. Useful features > are hidden in the forest of old stuff. If you only use a subset of the > functionality, then yes it's not that hard. The point is to see the trees in > the clutter of the forest of options, which is why I was suggesting a new > command instead of adding more stuff to NAMEFIND. NAMEFIND (DMSNAM) is where all the smarts are for processing a NAMES file, and that's where they need to stay, IMO. Mechanically, NAMEFIND is a MODULE, not kernel-resident, and that makes it impossible to have other commands call its entry points. Making this cheap to implement is also a consideration. And I have to say that the small number of people in the world who will benefit from this change can deal with the addition of LOOKUP, ADD, UPDATE, and DELETE subcommands. The semantics of the interface could change depending on the options (in the past, some RR track diagrams have been teased apart to show different tracks). NAMEFIND LOOKUP NAMEFIND UPDATE NAMEFIND DELETE NAMEFIND ADD Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott
