DSXchange

This is a new one on me and I'm not seeing the solution.

Have a new server running HP-UX 11.11 with a fresh install of 7.5.2 on it for testing purposes. Trying to run a shell command from DSExecute gives the following failure:


It doesn't really seem to matter what command we execute, this little 'header' block is included in the output. When I execute a 'locale' command, I get the same output as it would give on any of our HP-UX servers, , but I'm guessing that's because it has 'forced' the use of the "C" locale:


When we execute 'locale -a' these are listed as valid selections.

Anyone seen this before? The DS Server install is 'out of the box' right now, nothing has been tweaked other than normal stuff we need for OCI that goes into dsenv. Is there somewhere in DataStage that this 'default locale' is setup that it is complaining about?

This is without NLS installed/enabled?

I've not encountered it before, but I've never played with 7.5.2 on HPUX either. Does support have anything to say?

I'll have to check on the NLS question, it shouldn't have been enabled but was installed by someone else while I was on vacation. Is there a quick way I can tell?

Haven't gotten to support yet on this, thought I would post here first.

If NLS is enabled, all the NLS tabs and command buttons are enabled. Open Administrator client - there's a button on the start page.

Or grep NLS $DSHOME/uvconfig

Hadn't found anything in uvconfig when I posted the question, the Administrator confirms it - NLS is not enabled.

Hmm. If it were parallel jobs (being C-based) I'd understand, but this one's a bit of a mystery. When you run a job, what is the locale setting reported in the job log? If it's not explicitly reported, examine the second, "environment variables", event in the job run.

The only locale reported in the Environment settings log entry is this:

LC_CTYPE=C.utf8

And that's the same on both the working and non-working servers, 7.5.1A and 7.5.2. Interesting is the fact that it is reported as "C" from the command line, but I have a User Defined Environment Variable setup via the Administrator in all server installs / projects that sets it to "C.utf8". I only thought those came into play if I added them as job parameters (like overrides), not things that would be set all the time.

Not sure if that is relevant to the issue at hand, or just something to confuse me.

Interesting. Removing the User Defined entry for this solved the problem. And I then added it back and it is still working. I'm guessing that it probably had a space at the end or something similar, as I didn't notice a typo.

Still curious about the 'all the time' thing... not what I was expecting, behaviour-wise.

No, "all the time" is correct behaviour. You add them as job parameters if you might want to override them for that job. Think about APT_CONFIG as an example.

ray.wurlod wrote:You add them as job parameters if you might want to override them for that job.

Obviously there's a disconnect somewhere, but this statement encapsulates my understanding of how they work. It also seems to be at odds with your first sentence.

The 'normal' setting of LC_CTYPE (as one example) is "C". I've setup a User Defined Environment variable for it set to "C.utf8" for use when I need it overridden in a job. And it seems to have been working, jobs that behaved incorrectly without it worked when I added it as a parameter in the job. I've done this with three variables so far. Life was good.

Now, it looks like they are actually set 'all the time'. They all show up in the second log record of any job's run, the dump of all environment variables, showing the value I've assigned them in the Administrator. Are you saying that they are available but are not actually being used by the job? The only way I can add them as job parameters is if they are already defined. And I can't... erk... um... one second...

Dang. I was under the impression that their default value as defined in the Administrator can't be changed in a job, which was the root of my confusion. I have no idea what lead me to that conclusion as it is obviously false - I just went into an existing job that uses one and changed it. [sigh]

So, proper use of an environment variable you would like to have the ability to override would be:

1) Define it in the Administrator with its current a.k.a. the 'normal' value it has per your O/S.
2) Add it to a job that needs it overridden and change the default value there.

Yes? I guess my whole experiment months ago where jobs worked correctly by 'adding it to the job' actually started working when I defined the variable in the Administrator with the override value. Adding it to the job was just a fooley step I did before running it again. [double sigh]

Hopefully this helps others out. Otherwise it's going to get a little lonely sitting over in the corner with the tall pointy hat on.

That's all good, but step back a little. Some environment variables (such as LC_LANG) have a default value set in your initial environment (login shell).

If the environment variable exists in DSParams (having been put there by the Administrator client) its default value will be overridden. This new default value will be used by all jobs.

By adding the environment variable to a job as a job parameter, you gain the ability to replace the default value with a specific value, when subimtting a run request.

It's no different than with multiple shells in UNIX or DOS; the most recently set value takes effect.

Thanks. For whatever reason, I was under the impression that adding one via the Administrator gave me the option of using it later to override a value by adding it (unchanged) to a job. Had no clue until this incident made it abundantly clear that, by adding it, you are setting it for all jobs in that project that run from that moment forward.

But now I see the way and will soon be back on The Path.

Have you read The Tao of Pooh or its sequel The Te of Piglet - both very useful books in learning how to find The Path.

No, but my wife has The Tao of Pug around here somewhere I believe. Not so useful for finding the path, but perhaps it can help with the pooh^h.