Page 1 of 1
Testing User Name/Password in DS Administrator
Posted: Wed Sep 29, 2004 9:23 am
by ewartpm
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]
Posted: Wed Sep 29, 2004 3:54 pm
by ray.wurlod
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
Could it be that your PATH environment variable has been amended so that %WINNT_ROOT%\System32 isn't in it?
Posted: Thu Sep 30, 2004 1:40 am
by ewartpm
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
Posted: Thu Sep 30, 2004 6:02 am
by chulett
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.
Posted: Thu Sep 30, 2004 4:42 pm
by ray.wurlod
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.
Posted: Thu Sep 30, 2004 4:59 pm
by chulett
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.