| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3158.1 | Probably not as bad as you think | TOOK::MINTZ | Erik Mintz, dtn 226-5033 | Wed Jun 10 1992 07:51 | 13 |
| I suspect that to move the alarms MIR, you must:
1) Shut down the alarms FM
2) Remove the old alarms MIR
3) Define MCC_ALARMS_LOCATION
4) RE-ENROLL the alarms FM
If this does not work, then we have a bug.
Also, when examining the size of the MIR files, do not rely on "ls -l"
These are sparse files, which are really not as large as their apparent
size. You can use "du" to get an accurate indictation.
|
| 3158.2 | Bug ... | STRASB::EBLE | Fran�ois EBLE. EIS Strasbourg France. | Thu Jun 25 1992 07:10 | 17 |
|
Hi,
as you said we try to :
1) Shut down the alarms FM
2) Remove the old alarms MIR
3) Define MCC_ALARMS_LOCATION
4) RE-ENROLL the alarms FM by stopping the mcc_alarms_fm processus
This does not work so I think that we have a bug. I will QAR it.
About the file size. What is the real file size, I mean the real space
used ? Is it possible to reduce it with the mcc_ndbm utility ?
Fran�ois.
|
| 3158.3 | Use "du" | TOOK::MINTZ | Erik Mintz, dtn 226-5033 | Thu Jun 25 1992 09:09 | 5 |
| > About the file size. What is the real file size, I mean the real space
Use "du" to find out how much space is actually being used.
|
| 3158.4 | Bug is still there ... | STRAS4::EBLE | Fran�ois EBLE. EIS Strasbourg France. | Mon Jul 13 1992 06:19 | 8 |
| Hi,
QAR number is 448. I update it today. The bug is still there on the new
kit V1.2.0. Did you reproduce it ? Will it be solved in the official version ?
In the documentation the MCC_ALARMS_LOCATION is still not referenced...
It should be a good idea to have a table in this installation documentation
listing the file names linked to each environment variables.
|
| 3158.5 | V1.2 is as frozen as it gets | TOOK::MINTZ | Erik Mintz, dtn 226-5033 | Mon Jul 13 1992 07:37 | 7 |
| The V1.2 kit currently on the network IS the "official version".
It has been in SSB for over a week, and the documentation has
been frozen for longer than that.
I'll forward your note to the supervisor responsible for alarms.
-- Erik
|
| 3158.6 | Pb ULTRIX/Variables Length ?? | ZTOIS1::VISTA | Renato VISTA, SIS Strasbourg, France | Fri Jul 17 1992 11:22 | 50 |
| Hi,
I've tried to use MCC_ALARMS_LOCATION...
I've done an ENROLL ALARMS after having done firstly a
#setenv MCC_ALARMS_LOCATION /var/mcc_copy command... (of course, I've delete
*alarms* file in default /var/mcc directory).
When I've created a rule via iconic map, the *alarms* files are re-created in
default /var/mcc directory...
BUT, I've done another interesting tests :
1) First test :
#setenv MCC_ALARMS_LOCATION /var/mcc_copy <-- new definition for var.
#ls $MCC_ALARMS_LOCATION <-- directory via variable
Variable syntax <-- syntax error !
Please note that MCC_ALARMS_LOCATION has 19 characters long...
2) Second test :
#setenv AAAAAAAAAAAAAAAAAAA /var/mcc_copy <-- var. with 19 charac...
#ls $AAAAAAAAAAAAAAAAAAA
Variable syntax
Same problem...
3) Third test :
#setenv BBBBBBBBBBBBBBBBBB /var/mcc_copy <-- var. with 18 charac...
#ls $BBBBBBBBBBBBBBBBBB
It works !!!
4) Fourth test :
#setenv MCC_ALARMS_LOCATIO /var/mcc_copy <-- 18 char., name truncated
#ls $MCC_ALARMS_LOCATIO
It works too !!!
What do you think about that problem ? Is there any limit to environment
variables length ? Is it possible to change that limit ?
Thanks for your help.
Renato
|
| 3158.7 | a possible problem with csh in Ultrix | HERON::PATEL_A | LoLo-AQIC-I82Q-B4IP, - LMF | Tue Jul 28 1992 04:41 | 40 |
| can this problem have anything to do with the csh prob noted in the
tools notes file...
From: HERON::PATEL_A "LoLo-AQIC-I82Q-B4IP, - LMF 28-Jul-1992 0933" 28-JUL-1992 09:34:14.82
To: patel_a
CC: PATEL_A
Subj: csh prob - help for puegot
<<< NOTED::DISK$NOTES5:[NOTES$LIBRARY_5OF5]MCC-TOOLS.NOTE;1 >>>
-< MCC tools and MMs >-
================================================================================
Note 11.1 ULTRIX problems and solutions 1 of 2
RACER::dave "Attending The School of Comparative Ir" 21 lines 22-JUL-1992 09:56
-< Shell selection problem >-
--------------------------------------------------------------------------------
From Eric Mintz:
Glitch warning:
The C-shell documentation defines a shell variable as
"consisting of up to 20 letters and digits starting with a letter".
In fact, it appears that the limit is 18 characters. Variables with
longer names (eg $MCC_NOTIFICATION_FM_STACK, MCC_ALARMS_LOCATION) will
result in the error "Variable syntax" when used from csh, and
will appear undefined to a "getenv" call in code.
This restriction does not appear to be present in Bourne shell (sh, sh5)
or Korn Shell (ksh), which are supplied with ULTRIX. Nor does it appear
in tcsh (a popular unsupported shell).
Unfortunately, this makes a number of our environmental variables
useless to a large number of users. The only work-arround is for the
users to switch shells.
|
| 3158.8 | More information | TOOK::MINTZ | Erik Mintz, dtn 226-5033 | Tue Jul 28 1992 10:08 | 12 |
| The information in the cross posted note is incomplete.
"setenv" from csh works fine.
"getenv" from code works regardless of which shell is running.
Other shell commands may show the symptom described in .6 and .7.
The end result is that while you may see some odd behavior with the
long variable names, they will still work correctly when used to control
DECmcc.
-- Erik
|