| The MCC_EVENT_POOL.DAT file is obsolete.
For V1.1, we figured out how to implement Global Sections without
having a file "on disk", so to speak. The installation kit tries to
delete it, if it finds one hanging around. If you use the V1.1 MCC
Kernel, it knows nothing of the file, and the file is totally ignored.
Have you read the V1.1 SRM on Events? Requesting events thru the call
interface require that certain encoding rules be followed (both on
request and response).
Kernel release notes are in the MCC Toolkit (MCCTK011.*).
-Matt.
|
| > I work on the decmcc v1.1 ssb version, and I have some problem with
> events. Running new msl definitions with a configuration event
> partition cause a "Bad ILV mode" error immediatly after the mcc_call on
> the fcl-pm ! I think perhaps it is the format of the
> MCC_EVENT_POOL.dat file which is no more compatible with this version.
> But looking into kits there is not any clues of this file for this
> version.....and in the release_notes nothing is said about its
> disparition in this kit, so ??? Another question why in the directory
> keel::dua1:[public.userkit.v1_1.ssb] is there no release_notes on the
> Director precised into the release_notes added files chapter ?
> Thank for help.
> Pascale.
Hi, Pascale.
I don't think that the event pool has anything to do with this.
The event pool did change form (I forget when), but the old event pool
went away when you installed a DECmcc that creates and uses the new form.
From what you say, the Input Parameters & Arguments are not going anywhere:
" "Bad ILV mode" error immediatly after the mcc_call". I think that your MSL
is not quite right: "Running new msl definitions with a configuration event
partition cause a ..." Are you defining some request arguments (in_p) to
be of type attrib_list? Attrib_list is for attributes only, and request
arguments are not attributes.
Also, have you tried setting the FCL_PM logical to dump the ILV encodings?
(For directions, ask Pete Ditmars or scan the keywords for this conference--
I'm not sure of the name or the settings) I don't know if this would work,
but it might let you know how far you are getting in the ILV process.
> But looking into kits there is not any clues of this file for this
> version.....and in the release_notes nothing is said about its
> disparition in this kit, so ???
I'm afraid I don't understand this question, could you try again?
>Another question why in the directory keel::dua1:[public.userkit.v1_1.ssb]
>is there no release_notes on the Director precised into the release_notes
>added files chapter ?
Again, I'm not sure I can interpret the question correctly, but this time
I have a guess. There are no Director kit release
notes on KEEL:: because the BMS kit is a superset of the Director kit, and
the BMS release notes are a superset of (include) the Director kit release
notes. So, look in the BMS kit release notes. If you installed the v1.1 BMS
kit, the release notes are in the usual place (sys$help).
Ruth
|
| 1- with the 1.1 kit/srm there was the addition of a new directive type called
EVENT
2- the getevent command DOES require that a partition be passed in the Partition
field of the VEP tuple, but unlike examine directives (where you can not
qualify specific attributes for a partition) the EVENT directive allows
you to pass an event_id_list argument
3- events are returned as the value of an argument on the response. An example
is the response (this is ficticious by the way) getevent_success, with an
argument of data type event_report called event_data.
[1] ( getevent_success
[1] ( event_data of datat type event_report
ilv encoded arguments from
event definition
)
)
Hope this helps a littel
|