Carissa, > We figured it out. Whew. And it involves a follow up to you guys. These > decoders require a .dummy directory to exist in ldm's home directory. > And in previous ldm versions you could set ldmhome variable in the > ldmadmin.pl. With the new version there is not a ldmhome variable. And > by some trickery we discovered the "ldmhome" is now datadir-path and > wasn't ldm's home directory as we expected. It appears that the decoders depend upon an implementation-detail of the LDM. Such things are risky. > In the documentation I see: > > As a consequence of the creation and use of the registry, the > following environment variables no longer work: > LDMHOSTNAME > LDMPQFNAME > > Does this mean that ldmhome variable could still work in the registry? I'm not sure what you're asking. The configure(1) script determines a value for a configuration-variable called LDMHOME. This variable is used by the configure(1) script to determine the installation directories. The value of this variable is overridden at configuration time by the environment variable LDMHOME. After configuration, this variable isn't used for anything. > It isn't a big deal to use datadir-path, it's just that we have > previously never used the ldm/var/data directory for anything. And now > we have to have a required hidden file in it. If the contents of the .dummy directory are variable and transient (i.e., meaningful only for an LDM session) then ~/var would be the canonical place for it. How do the decoders decide on the pathname for the .dummy directory? > Carissa Regards, Steve Emmerson Ticket Details =================== Ticket ID: VZP-575055 Department: Support LDM Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.