Structure of ^XTMP("XPDI",rec #,"KRN",19,rec #,-1) piece definition

[grzeis...@gmail.com]

I am in the process of debugging an issue where the target system has the same option defined as an EDIT type option (forgive me is some terms are off; I am trying t recall from memory.) So the target system's option has the fields DIC, DIE and FLDS defined.

In my development account, I changed the option from type 'Edit' to type 'Run Routine'. You can see the basic structure of the option below: there are no definitions for DIC, DIE or FLDS. Just a bare bones run routine option type.

I export the option using KIDS. I specify SEND TO SITE as the action to be taken on the target system.

I EXPECT the option being exported to replace (purge the option on the target system and lay in the option fro the development system) the same option on the target system.

Cutting to the chase the proble is that SEND TO SITE acts like a MERGE on the target system. The target system is updated: TYPE ('R') and RUN ROUTINE (EN^ZZROU) are filed on the target system.

The problem is that the fields DIC, DIE and FLDS remain as they were defined before the installation of the KIDS build. My assumption is that "0^3" is being treated as a MERGE ('3') as opposed to a SEND TO SITE ('0').

I am not sure why that would be.

Any ideas are welcomed.

Thanks!



^XTMP("XPDI",rec #,"KRN",19,rec #,-1)="0^3"

^XTMP("XPDI",rec #,"KRN",19,rec #,0)="option name^option text^^R^^^^^^^^"

^XTMP("XPDI",rec #,"KRN",19,rec #,1,0)="19.06^2^2^3161209^^^"

^XTMP("XPDI",rec #,"KRN",19,rec #,1,1,0)="line one of option description"

^XTMP("XPDI",rec #,"KRN",19,rec #,1,2,0)="line two of option description"

^XTMP("XPDI",rec #,"KRN",19,rec #,25)="EN^ZZROU" <-- run routine option type

^XTMP("XPDI",rec #,"KRN",19,rec #,"U")="OPTION TEXT"

[Steven McPhelan]

The problem is your assumption.  You assume a delete and replace would be done at the target site.  When KIDS exports an OPTION it does a merge as you noticed.  The KIDS utility for OPTIONS is not a pure merge.  There are some multiple fields in the OPTION file which are deleted at the target location and replace that multiple with the one exported.

Steve

But a Constitution of Government once changed from Freedom, can never be restored. Liberty, once lost, is lost forever. - John Adams

[grzeis...@gmail.com]

Ok, I am looking here Kernel Developer's Guide and see on page 222 that SEND TO SITE is defined as:

"Menu, option, or protocol is installed at the site; any existing version already at the site is completely purged beforehand,
except those options that are currently marked as “Out of Order” (OoO)"

emphasis mine

It is because of this explanation that I expect a purge and replace action to occur.

[Steven McPhelan]

Apparently something is amiss.  I am wondering.  What version of VistA (more specifically KIDS patch level) are you running?  Your experience does not jibe with that documentation. The behavior I mentioned is what KIDS did for many years.  KIDS may have issued a patch somewhat recently.  I have not looked at this issue recently.  I had similar problems in the past.

[Steven McPhelan]

I was using a 2015 version of the FOIA Cache.dat file.  The KIDS Install option has been rewritten since I last looked at.  It does not appear that KIDS does a purge and delete of OPTION file entries.  So the documentation does not appear to jive with the programming.

Brief technical details in case what I was looking at is an older version of KIDS:

Install real work starts at EN^XPDIJ

D IN^XPDIJ1

     D COMP

             D KRN^XPDIK

At this point you would have to look at the how the transport global was constructed.  Installation actions are obtained from FILES+17^XPDE

D KRN^XPDIK eventually executes Q:$$ACT(EPRE).  EPRE is one of those install actions where EPRE="OPTE1^XPDIA".  $$ACT will execute D @EPRE.  I could not see where OPTE1^XPDIA purges the option.  It does what I stated previously.  I does purge components of an OPTION file entry if they exist but does not delete the entire pre-existing entry.  Thus you get what you observed which is a MERGE.

The Kernel documentation may not be inaccurate, just terse in its information.  There are about some 20 or so Kernel files possibly processed.  Perhaps some of those others Kernel file entries are purged and then replaced,  I do not know as I did not investigate that.  I might expect that the Fileman Template files, Edit, Print, Sort, might be purged and replaced if a pre-existing entry exists.

[grzeis...@gmail.com]

Thanks Steve... We were instructed that the documentation need a tweak. At this point we will send out the option clean (run type) but when installed at the target site some of the chaff (field values like DIC, DIE) from the old edit type definition will remain.