| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1181.1 | This STARS article? | AIMTEC::WICKS_A | DEC Mail Works for ME sometimes | Wed Aug 05 1992 00:19 | 11 |
| Derek,
There's an article in STARS entitled
Network Update (UA) Not Updating Information From One Node In Network
Can you get to that and see if it's the same thing.
Regards,
Andrew.D.Wicks
|
| 1181.2 | STARS article on different problem | KAOFS::D_STREET | | Wed Aug 05 1992 20:26 | 16 |
| Hello,
I have looked at the STARS article, and it would not seem to be the
same problem. In that case it could not find records on the other node
to process. In my case, it finds tha same records to process every
other run.
"Looking for updates for SANDS on SANDS after "
change record obtained for HORVATHJ on SANDS
record updated successfully
change record obtained for DEFRANCOJ on SANDS
record updated successfully
The customer feels that the missing date is signifigant, in that the
run that does work, has a proper date following the "after".
Derek Street
|
| 1181.3 | put a date in there? | AIMTEC::WICKS_A | DEC Mail Works for ME sometimes | Wed Aug 05 1992 21:58 | 8 |
| Derek,
What about writing a date into the field (in NBS format) and then
trying the job again.
Regards,
Andrew.D.Wicks
|
| 1181.4 | No field to force value into | KAOFS::D_STREET | | Wed Aug 05 1992 23:13 | 7 |
| Hello,
I looked in SMNETUPDT.COM, and found it does "run oa$lib:smnetupdt"
without setting any variables prior to the RUN statement. The message
is generated within that .EXE. I don't see an oppertunity to force a
date value into the field.
Derek Street
|
| 1181.5 | I'm not as hairy as Andy, but.... | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Thu Aug 06 1992 11:42 | 4 |
| I assume Andy means force a value into "Last update" field in the
problem record in the Network.dat file.
Graham
|
| 1181.6 | You asked for ideas! | OASS::PCMIKE::lamberson_m | | Thu Aug 06 1992 13:57 | 11 |
| Derek,
Is the customer running in a "cluster" configuration? If so, have you
checked to see if the UA job is running on 1 particular node each time it
picks up the updates? The "timestamp" information from the last update from
that node should be held in OA$DATA:MNODES.DAT which would be accessed via
the ISM menu off of the MM screen. Make sure that only one copy of the file
exists, it is in the disk:[ALLIN1.DATA_SHARE] directory and that the same
"disk:" is being pointed to by each node in the cluster.
HTH
|
| 1181.8 | problem fixed, but WHY? | KAOFS::D_STREET | | Mon Aug 10 1992 16:20 | 13 |
| Hello,
The customer is not running in a cluster, and did not have multiple
copies od OA$DATA:MNODES.DAT. When they checked the node out via the MM
and ISM (on one of the days they expected it to fail, they found the
"Last update time stamp" field was all BLANKS. For whatever reason,
they filled it with all ZEROS, and since that time it has worked just
fine. That leaves us with a couple of questions.
1. Why would it alternate from a valid to invalid value in that field.
2. What is it about entering ZEROS that would fix it? (assuming we can
figure out what was causing it in the first place!!)
Derek Street.
|
| 1181.9 | The return of the blank timestamp | KAOFS::D_STREET | | Thu Sep 03 1992 21:18 | 5 |
| Sorry to report that the problem has returned. The "Last update time
stamp" returned to being all blanks. what kinds of things can I do to
isolate the problem?
Derek Street.
|
| 1181.10 | Where is the Network Profile developer? | AIMTEC::WICKS_A | It wasn't supposed to end this way | Sat Sep 05 1992 00:21 | 1 |
| Anything in the log file - if not then I don't know
|