| Title: | POLYCENTER Console Manager |
| Notice: | Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS: |
| Moderator: | CSC32::BUTTERWORTH |
| Created: | Thu Aug 06 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1541 |
| Total number of notes: | 6564 |
I've been through all the notes relating to the "feeder" modules that
are part of PSW, and most of the answers are "buy something else."
At my current customer site, that's not accepted as a real solution.
I've tried to implement the SNS$FEED_PCM.C code, and I'm getting
absolutely nothing to either ENS or any node icon changes. From the
number of "success" messages, it would seem that this is a simple
trick. Agreed, the description of the steps to bring this up is
kinda sketchy at best (from the "instructions" in the code).
Here's what I have done:
compiled and linked SNS$FEED_PCM
created a startup file to kick it off as a detached process
added in the mailbox set to the profile in PSW
added in the mailbox set to this site's "class"
restarted the consolidator on this node
As I said, from the simple instructions, these seem to be the steps
required to get this working. The customer doesn't want to buy
anything else, they don't want fancier hooks and louder whistles. I'm
cross-posting this to the SNS/PSW conference in the hope that someone
can point me to the missing piece of this puzzle.
SNS Version:
image name: "SNS$CONSOLIDATOR"
image file identification: "V2.2-07"
image file build identification: ""
link date/time: 9-AUG-1996 12:47:42.67
PCM version:
image name: "CONSOLE$C3"
image file identification: "V1.6-201"
image file build identification: ""
link date/time: 3-MAR-1996 14:36:08.18
Oh, yes. No errors at all in any of the SNS logfiles.
bob
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1384.1 | WOTVAX::WATSONR | Lambs... so cute... but so tasty ! | Wed Sep 18 1996 04:29 | 22 | |
Bob,
I have done quite a bit of work with an SNS->PCM 'feeder' at a customer
site, and, other than the problem described in note 1203, it all seemed to work
(well, as well as it was going to). Having said that, I wrote my own
SNS$FEED_PCM code, so that it hibernated and sent opcom messages as well.
The steps you listed are correct,
o create a mailbox set (using same mbx name as the sns$feed_pcm code)
o assign the mailbox to the events for a class
o assign that class to a node
o start the feeder.
Going by my experiences with this (see 1203), I'd check quotas, and failing
that, I'd try reading the mailbox from DCL and see what happens. Of course, if
you're running your feeder as a detached process, it's kind of tricky to debug,
so run it from a terminal with debug. See if the read from the mailbox
completes.
Hope this helps,
Ross
| |||||
| 1384.2 | PCM events defined? | STKAI1::MALM | My God! It's full of stars... | Wed Sep 18 1996 11:23 | 18 |
Hi! > Here's what I have done: > > compiled and linked SNS$FEED_PCM > created a startup file to kick it off as a detached process > added in the mailbox set to the profile in PSW > added in the mailbox set to this site's "class" > restarted the consolidator on this node > Did you define some PSW-events in PCM? I think that You have to do that before the events are shown in the PCM/ENS windows. If the customer buy the OSCint package, he/she will get a PSW->PCM feeder and some scan profiles as well. /Staffan | |||||
| 1384.3 | Run/detach cmd also inherited... | CRLRFR::BLUNT | Wed Sep 18 1996 13:41 | 7 | |
re .-1
Thanks, Ross! That at least gives me an area to look. Yes, I'm
running it detached, but I'll have to check the "setting" for BYTLM,
betting that it's probably really low. I'll check back after giving
that a try
Bob
| |||||
| 1384.4 | COMICS::JOLLEYD | Mon Sep 23 1996 05:59 | 9 | ||
Bob, I was caught out with the mailbox name being entered in lowercase when It needed to be in uppercase. You could also check the logfile from the detached process. If you don't supply one look for sys$output.; /Darren | |||||
| 1384.5 | FEED_VCS was easier | CRLRFR::BLUNT | Fri Oct 11 1996 08:22 | 13 | |
Given some of the problems that I heard/read/found with the use of
CMUserSend Event that SNS$FEED_PCM.C uses, I felt that this production
site was better off monitoring Watchdog events with SNS$FEED_VCS.
I'm not 100% sure, but I think that the latter actually records events
into the logs, where the former "just send it to ENS." The other added
bonus was that I could get SNS$FEED_VCS working more easily that the
other.
I will, however, check into your suggestion, and double check how I
have things setup.
bob
| |||||