[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #VZP-575055]: 6.11.1 LDM error documentation


> 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:
> 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 

How do the decoders decide on the pathname for the .dummy directory?

> Carissa

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.