On 8/17/20, 5:09 PM, "CMSTSO Pipelines Discussion List on behalf of Rob van
der Heij" <[email protected] on behalf of [email protected]> wrote:
On Mon, 17 Aug 2020 at 22:46, David Boyes <[email protected]> wrote:
>> If not, I’d like to suggest a stage or stages that lets you both read and
>> update a CMS NAMES format file.
> Correct, there isn't. I don't think there's an API to operate on NAMES
> files.
The format is described in the entry on NAMEFIND in the CMS Command Reference.
I'd agree it's probably not an officially designated GPI, but it's a pretty
detailed description in an official publication (it's been there since VM/SP3
at least).
AFAICT, the XEDIT macro X$NAME$X SXEDIT and compiled friends that do the work
for CMS NAMES command handle changes by finding the :nick.FOO entry and
deleting everything to the next occurrence of :nick., then add a new entry with
the changed content at the bottom of the file. Adding a totally new record
works by just appending the new entry to the bottom of the file. Not great for
performance, but given that you as the application author probably can be
assumed to know what the valid tags are in the NAMES file in question,
arranging them could be :nick in column 1, other tags start any point beyond
column 1 and value is everything after the period signaling end of tag.
I think NAMES uses the format:
:nick.<search target>
:tag.value
:tag.value
:tag.value
<-- blank line
:nick.<next search target>
combining multiple tag/value lines, allowing value to be of arbitrary length.
> Considering the various restrictions, I have some doubts about leveraging it
> as a
> generic registry.
It's been used that way forever because that’s what NAMEFIND knew how to do,
GLOBALV had even more restrictions, everybody had it, and everything else cost
real money. The VMLINK and VM TCPIP configuration code are examples of using it
that way. We're not really talking about more than a few hundred objects, so
I'm not sure performance is an issue.
> Would it help if CMS Pipelines were able to make sense of JSON data? I would
> expect a stream of JSON documents where you can extract, modify or remove
> objects.
> The stream could come from a CMS file as well as from the Internet.
I think a JSON stage might be interesting in the future, but there's so much
existing CMS code that uses NAMEFIND to do NoSQL-like datastore stuff that
there would still need something to manipulate NAMES files. I'd be ok with
having an explicit "end entry" tag, a la GML, if that makes it easier to parse,
and having to construct a full entry in a stem before writing data to a :nick.
identifier, so it basically wrote the whole stem as the new entry.
Would also make replacing NAMES and friends a lot easier, too. __
