graeme@ccu1.aukuni.ac.nz (Graeme Moffat) (03/11/91)
The rs6000 error messages are preceded by fancy looking 7 digit numbers, but when these are looked up in Info, I am invariably dumped into the man pages for the command which produced the error, which is not much help in determining the cause of it. Also several are not listed at all. The text of many of the messages is no help, either. My favourite is: umount: a device is already mounted (I know, else I wouldn't be trying to unmount it) or cannot be unmounted (which is what it is really trying to say). Are there better error explanations anywhere, or does IBM intend to improve this in the future? (I am used to getting verbose explanations from VM/SP manuals) I am aware that helpful error messages in Unix are considered bad form *B^) PS. In the umount error above, just how do I determine who or what has open files or current directories in the affected filesystem? Thanks -- Graeme Moffat g.moffat@aukuni.ac.nz \ Time wastes us all, Computer Aided Design Centre, Fax: +64-9-366-0702 / our bodies & our wits School of Engineering, Ph: +64-9-737-999 x8384 / But we waste time, University of Auckland, Private Bag, Auckland, NZ \ so time & we are quits
kstailey@wookumz.gnu.ai.mit.edu (Kenneth Stailey) (03/24/91)
In article <1991Mar11.085414.2650@ccu1.aukuni.ac.nz> graeme@ccu1.aukuni.ac.nz (Graeme Moffat) writes: Path: mintaka!olivea!uunet!comp.vuw.ac.nz!waikato.ac.nz!aukuni.ac.nz!graeme From: graeme@ccu1.aukuni.ac.nz (Graeme Moffat) Newsgroups: comp.unix.aix Date: 11 Mar 91 08:54:14 GMT Organization: University of Auckland, New Zealand. Lines: 18 The rs6000 error messages are preceded by fancy looking 7 digit numbers... Gee, doesn't POSIX 1003.2 require that most error messages are precisely specified in terms of the printf string that must be used to produce them. The idea is that programs can grep for error strings, so they must be exact. This means that close to 100% of the error strings must be changed. I can't wait to see what happens when the government bids can't be won without this because "designed to be POSIX compliant" isn't good enough. ("designed to be" is IBMspeak for "isn't") -- @-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@ Disclaimer: This message is sold by weight not volume; | contents may have settled during shipment. @ @ replys to kstailey@gnu.ai.mit.edu or kstailey@leidecker.gsfc.nasa.gov | NBCS: B4 f m w- c(+) p+ k+ s+ why jack off when you can jack in? @-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@
mbrown@testsys.austin.ibm.com (Mark Brown) (03/25/91)
kstailey@wookumz.gnu.ai.mit.edu (Kenneth Stailey) writes: |graeme@ccu1.aukuni.ac.nz (Graeme Moffat) writes: | The rs6000 error messages are preceded by fancy looking 7 digit numbers... | | Gee, doesn't POSIX 1003.2 require that most error messages are | precisely specified in terms of the printf string that must be used to | produce them. The idea is that programs can grep for error strings, | so they must be exact. This means that close to 100% of the error | strings must be changed. If one were to read IEEE POSIX 1003.2 Draft 11 Sec. 2.11.6.1 and 2.11.6.2, one would see that this assertion is baseless. I respectfully suggest that one *read* the draft standard, and avoid speculation (although getting copies *is* expensive and difficult for the average person)? Mark Brown IBM PSP Austin, TX. (512) 823-3741 VNET: MBROWN@AUSVMQ MAIL: mbrown@testsys.austin.ibm.com OR uunet!testsys.austin.ibm.com!mbrown The nice thing about standards is that there are so many to choose from! DISCLAIMER: Any personal opinions stated here are just that.
jerry@heyman.austin.ibm.com (Jerry Heyman) (03/25/91)
In article <1991Mar11.085414.2650@ccu1.aukuni.ac.nz> graeme@ccu1.aukuni.ac.nz (Graeme Moffat) writes: |> |> Path: mintaka!olivea!uunet!comp.vuw.ac.nz!waikato.ac.nz!aukuni.ac.nz!graeme |> From: graeme@ccu1.aukuni.ac.nz (Graeme Moffat) |> Newsgroups: comp.unix.aix |> Date: 11 Mar 91 08:54:14 GMT |> Organization: University of Auckland, New Zealand. |> Lines: 18 |> |> The rs6000 error messages are preceded by fancy looking 7 digit numbers... |> The fancy looking 7 digit numbers only occur when the LANG environment variable is set to something other than C. echo $LANG, and reset it to C if you don't want to see the 7 digit number, and are more interested in seeing the 'normal' Unix error message(s). jerry -- Jerry Heyman Internet : jerry@ajones.austin.ibm.com PSP Development Environment Tools VNET : HEYMAN at AUSTIN Austin, TX 78758 IBM T-R : jerry@heyman.austin.ibm.com *** All opinions expressed are exactly that - my opinions and NOT IBM's
jfh@greenber.austin.ibm.com (John F Haugh II) (03/26/91)
In article <KSTAILEY.91Mar24102207@wookumz.gnu.ai.mit.edu> kstailey@wookumz.gnu.ai.mit.edu (Kenneth Stailey) writes: >Gee, doesn't POSIX 1003.2 require that most error messages are >precisely specified in terms of the printf string that must be used to >produce them. The idea is that programs can grep for error strings, >so they must be exact. This means that close to 100% of the error >strings must be changed. The error message produced when you select "LANG=C" is supposed to be the same traditional error message you get when you don't have NLS. There are a number of commands which don't support "terse" (or "traditional" - you make the value judgement) messages, and those commands should be APAR'd as they are encountered. >I can't wait to see what happens when the government bids can't be won >without this because "designed to be POSIX compliant" isn't good >enough. ("designed to be" is IBMspeak for "isn't") NLS is a fantastic idea. It allows =other= languages to be supported by changing the "LANG" variable. It also allows for two sets of "English" messages - one which says "%s not found" and one which says "The file %s could not be found. Please check file permissions." The "I" in "IBM" stands for "International", and users in Germany would prefer to get their errors auf Deutsche, nicht English. The fancy 7 digit number allows for a consistent reporting mechanism between different languages. -- John F. Haugh II | I've Been Moved | MaBellNet: (512) 838-4340 SneakerNet: 809/1D064 | AGAIN ! | VNET: LCCB386 at AUSVMQ BangNet: ..!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)
sja@sirius.hut.fi (Sakari Jalovaara) (03/28/91)
> "The file %s could not be found. Please check file permissions." Preferably only if the problem _is_ file permissions... I prefer ~ (sirius) 4265> cat /etc/ypbind.lock cat: /etc/ypbind.lock: Permission denied over ~ (leka) 302> cat /etc/security/passwd cat: cannot open /etc/security/passwd though if I wrote "cat" it would say cat: can't open file "/etc/security/passwd" for reading: Permission denied (program - object - operation - reason.) > users in Germany would prefer to get their errors auf Deutsche, nicht > English. Ja - aber nicht alle. I wouldn't want messages in my native Finnish. Translations of technical texts are often bad, the terminology is less stabilized (often non-existent), program names and input to programs is based on English and 3rd party programs will still speak English for a long time to come. These show painfully well on the Macintosh. $LANG is ok; it gives a choice. ++ "NO INFORMATION IN THIS SENTENCE." - TELL-A-GRAF ++sja
schan@minnie.cs.su.OZ.AU (Stephen Chan) (05/09/91)
I'm new to Fortran and would like some help with on the following error messages. I would like to know what they mean (using MIPS F77): 1. common misalignment of "lprint" 2. Declaration error declaration among executables 3. Execution error unclassifiable statement Thanks in advance. Stephen.