We have a system which is Blade machine ( not sure what blade really
means here, Itanium?)
And today when I was trying cp command, I got below error
/home/william: cp fileA fileB
cp: fileA: Guardian or User Defined Error 3503
The same error 3503 occurs when I was trying on other commands which
will cause an I-O action
This error only happens on OSS platform, system info is J06 10 NSE-M
Appreciate your advice.
Thanks
@will
A correction - the command I show above should be-
/home/william: cp fileA fileB
cp: fileB: Guardian or User Defined Error 3503
Well this is a little odd. I expected to find error 3503 in the Guardian Procedure Errors and Message Manual. I do find an error 3502, but no other error numbers near that one. The closest preceding error is 1163 and the closest number following is that the range 4000 through 4999 are Open System Services errors. This was in the version of the manual retrieved today via the J-Series documentation page. It seems odd to me that there is just that one error, 3502, defined in that large unused span. I wonder whether a large number of error number descriptions got lost somewhere along the way.
Try entering the command ERROR 3503 from a TACL prompt and see whether it gives any explanation for that error number.
Have you tried checking the system log to see whether there are any messages that seem to be reporting problems about the OSS environment? Also check for any errors displayed by the commands that start up the OSS environment, if they output from them gets saved. I have a feeling that this has something to do with some failure or misconfiguration of the OSS environment, but no evidence to support that.
Is this problem happening with all OSS users or just this one? Was this user able to work normally for a while, then the error started happening, or is the user newly created and has had this problem from the start? If so, check the attributes given the user when it was created.
Do other OSS commands, ls, cat, and other commands that do not create files work okay? Do other commands that create files also fail?
Please disregard this post.
Your problem is related to accessing virtual SMF volumes. One
possibility is that all prerequisite SPRs have not all been
installed. Another, more easily checked, is that you are trying to
use a virtual volume. Are you really trying 'cp fileA fileB' or
perhaps are you trying something like 'cp fileA /G/vol/subvol/fileB'?
> Have you tried checking the system log to see whether there are any messages that seem to be reporting problems about the OSS environment? Also check for any errors displayed by the commands that start up the OSS environment, if they output from them gets saved. I have a feeling that this has something to do with some failure or misconfiguration of the OSS environment, but no evidence to support that.
Agree, but I'm not allowed to access system log.
>
> Is this problem happening with all OSS users or just this one? Was this user able to work normally for a while, then the error started happening, or is the user newly created and has had this problem from the start? If so, check the attributes given the user when it was created.
>
All uses, all time. Even Super.Super
> Do other OSS commands, ls, cat, and other commands that do not create files work okay? Do other commands that create files also fail?
Yes & Yes ( rm, rmdir works, mkdir also works)
I get more info as below -
There are several directories under OSS, any I-O actions under these
directories will cause 3503 error. The only exception is /home I
can do I-O actions under this directory
Thanks
@will
Sorry for my short knowledge, but what are SMF/ SPRs ? How could I
check/fix them?
I only did copy command on OSS.
Thanks
@will
SMF is the software product that provides virtual discs, that is, logical volumes that are not identical to physical disks. Storage Management Foundation is the formal name for the product if I remember correctly.
SPR is the term for a software update -- Software Product Revision, I think.
I think this indicates an incompatibility between two system software components on your system. "dialect" is a term Tandem system software developers use for the version of the messages exchanged between system processes. The system managers probably need to review recent software updates they have installed and make sure all the dependencies for those updates have also been installed.
Your report below that creating and deleting directories works but creating files does not work is probably an important clue to help identify the components that are incompatible.
I should have mentioned this: I imagine the reason mustlearntandem mentioned SMF is that OSS and SMF do not work together, or at least they have not in the past. The issue has been mentioned here a number of times. It is possible that it has been fixed recently, but I have not heard that it was fixed.
I know that OSS processes could not access Guardian files that were on virtual discs. That is the issue that usually arises and has been mentioned here. I do not know what error occurred when such access was attempted. I suppose it might be the 3503 error that you are getting now, but it easily could be some other error.
I imagine that the discs on which OSS files are stored also cannot be virtual discs, but I do not believe that has been discussed here. In any case, that is something your system managers would be responsible for, not you, and I think they would have been adequately warned if there is such a restriction.
Error 3503 indicates that the addressee does not support the dialect
of a received request.
I am suspecting that disk process could have detected a invalid
dialect while creating fileB. Hence, file system error 3503 is
propagated to cp utility.
Can you check one thing, get the guardian name of file A (from oss
type gname <filename>) and create a one temporary file from TACL on
the same disk. See whether you can create the file or not.
Thank you now I have a beiref concept of what SMF and SPRs are.
Today our system team has solved this issue , what they did is
"running diagnose on root file set"
However, I'm still insterested in what does "running diagnose on root
file set" mean, any gentlemen know this?
Thanks
@will
Good point - that's what I was thinking about before
System team has solve this issue today, so I cannot try this for a
meaningful resut
Thank you all the same
@will
According to KBNS this utility is employed to fix a corrupted OSS file
system. It is funny that the last time I saw a corrupted file system
was when I worked on Unix where it was pretty common!!!.
That's interesting. I wonder how the error 3503, whose description is:
Server does not support this dialect.
could be caused by a corrupted filesystem. How could a corrupted OSS filesystem cause one of the system processes either start sending messages in the wrong dialect or stop recognizing messages in a valid dialect? There are many ways software can fail, including sending the wrong error number for the condition that happens. We probably never will know what happened with this one, but thanks, will, for telling us how this got resolved.
I'm not surprised at all. When the Tandem box got opened to support
all kind of ported stuff... well...
Actually, from what I remember hearing at the time, the OSS filesystem is not ported code. I am pretty sure it was implemented from scratch by Tandem developers, and works significantly differently than a Unix-like filesystem works. It presents nearly the POSIX interface to programs, but the way it works internally is rather different. I don't know anything about the details of the implementation, so I have no idea how it can become corrupt or how it can be repaired. That would be interesting to know.
It is an interesting error message that appears to be unrelated to the
solution. This is why I was steering towards SMF because the dialect
issue is directly related.
I just took a short look at KBNS and error 3503 seems to be related to
SMF volumes. In my opinion it does not make any sense to create OSS-
files on virtual volumes, files on virtual volumes are mapped to
physical volumes, And that is very similar to OSS files which are
mapped to Guardian files.
So have a look at your fileset and if you find virtual volumes you
have to delete them from the configuration.