| Acutally what you are trying to do can be done.
It looks like you are trying to get around the inavailability of the
callable MCC by making your module a PM. How to do this isn't
documented any where, but since I'v done it before...your problem
looks like your entry point is wrong.
The kernel expects the following of presentation modules.
filename = SOME_NAME.EXE
universal entry point = SOME_NAME_MAIN
One argument is passed in to all PMs this is an integer value. This
value is the hex evaluation of the logical named: SOME_NAME_LOG
My guess is you .EXE and your entry point are the same name, if
this is the case the kernel won't find your entry point.
Now if this wasn't what you were trying to do, then ask again.
jill
|
| You want to make sure in your main code module that you use the
#MODULE command to give the coding module a name. It is this name that
you use when you invoke MCC.
Also, MCC attempts to map in the module_name.exe by using LIB$ routines
for finding symbols, etc. These routines expect to find an installed
module_name.exe in sys$share. So one possibility is that you do not
have your .exe installed in the correct location.
Suggestion - name your .c, .exe, and module name as MCC$SCC and use
MCC$SCC_MAIN as your entry point (and as the value for the UNIVERSAL
statement). Install MCC$SCC.EXE into sys$share (typically the
sys$common:[syslib] directory) with the following install command
INSTALL ADD module_name.exe /SHARED/HEADER.
Then issue the MANAGE/ENTERPRISE/PRESENTATION=MCC$SCC command.
Hope this helps.
By the way, are you in the same group as Phil Tamer? I used to be in
correspondance with him concerning detached mcc processes since I used
one to write the DECnet Phase IV event sink.
Cindy
|