Testing User Name/Password in DS Administrator

ewartpm · Post by **ewartpm** » Wed Sep 29, 2004 9:23 am

I log into the Administrator module and go to a project's properties. Where one can 'Test' the user name/password to see if they can schedule jobs, I get the following error:

'ATTRIB' is not recognized as an internal or external command, operable program or batch file.

Can anyone help me with this?

Thanks[/b]

ray.wurlod · Post by **ray.wurlod** » Wed Sep 29, 2004 3:54 pm

Most unusual! ATTRIB is a DOS command. Open up a CMD.EXE shell and type ATTRIB /? to find out more. It's usually located in

Code: Select all

%WINNT_ROOT%\System32\attrib.exe

Could it be that your PATH environment variable has been amended so that %WINNT_ROOT%\System32 isn't in it?

ewartpm · Post by **ewartpm** » Thu Sep 30, 2004 1:40 am

Thanks Ray...brilliant as usual!!

The %SystemRoot%\system32 portion of the path was somewhere in the middle of the PATH variable. I moved it to the beginning of the string and now all is well. :D

chulett · Post by **chulett** » Thu Sep 30, 2004 6:02 am

Interesting. That... shouldn't have mattered.

It still should have been able to find it.

Unless you've got something else called ATTRIB that it found in a directory before the system32 directory was looked in. Or there was something wrong with the syntax of that entry before you moved it, but that would have caused problems all over the place, I would think.

Still, good to see you got it fixed.

ray.wurlod · Post by **ray.wurlod** » Thu Sep 30, 2004 4:42 pm

Certain products (particularly database products) have the annoying behaviour of inserting their executables directories at the beginning of PATH, presumably to maximize their performance at the expense of everything else. (Wouldn't you, in their place?)

It's always a good plan to review PATH (and the shared libraries environment variable LD_LIBRARY_PATH/SHLIB_PATH/LIBPATH) after any installation or upgrade.

It CAN make a difference, for example if the same name is used for different things.

The same is true for library load order when compiling; for example, UniVerse (and therefore DataStage) uses an idiosyncratic malloc(); it is vital that this is loaded ahead of the "real" malloc() function. Otherwise UniVerse/DataStage simply doesn't work. This is one of the gotchas of which anyone contemplating loading GCI functions needs to be aware.

chulett · Post by **chulett** » Thu Sep 30, 2004 4:59 pm

ray.wurlod wrote:It CAN make a difference, for example if the same name is used for different things.

Yup, said that.

Didn't have a clue about the "idiosyncratic malloc" issue, will have to keep that in mind if I ever contemplate loading GCI functions.