| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 20.1 | INFO - make user app an MCC module | GOSTE::CALLANDER | | Fri Oct 06 1989 12:37 | 39 |
|
At this point in time we do not directly support what you are asking
for.
Your request was for an external user application to make an MCC$Call.
What you can do is to add a PM entry point to your application which
would allow your application to be started using MCC/MOD=xxx. Doing
this would cause MCC to initialize all interfaces and then for the PM
xxx to be started. This would make the MCC$Call interface accessible
within your application.
Example:
application filename to be used as PM: mcc$ui_myapp.exe
main startup entry point to be added to module: mcc$ui_myapp_main
mcc DCL command: MCC /MODULE=MCC$UI_MYAPP
Things to note about creating a PM. To be a good citizen within
the MCC environment you must also create a management interface
for your new PM that will allow for the user to show the version
and identification information of your module. This can be done
by copying the sample am management interface and making the
appropriate changes for your application.
Also note that with this solution your management interface will
be accessible via the standard TRM interface, but that once you
start up mcc using /module=your_pm, the TRM interface is no longer
available, and you must support your own method of request input.
If you want the TRM interface then consider making your application
a functional module. The descision must be based upon what you want
your external application to do. I suggested a PM since you stated
that if was a "user application".
/jill
|
| 20.2 | INFO - more on DECmcc access from ACMS | BRSADV::PACCO | | Mon Oct 09 1989 10:24 | 15 |
| I understand, a user application today must be seen as a subroutine
hooked to DECmcc, and ONLY accessed via the DCL MCC command.
May I suggest (or expect) that MCC could be divided in two parts:
a MCC user interface, doing DCL parsing, condition handling etc..., but
then would call MCC$KERNEL, seen as a sharabale global image, with the
requested PM as an argument, eventually with some other additional
arguments. I think that this is the only good way to be able to
combine DECmcc with ACMS, accessed from an ACMS procedure server.
In my project this approach is quite vital. I suggest this as a
requirement for DECmcc V2.0, maybe sooner.
Dominique.
|
| 20.3 | RESPONSE: thanks for the idea | GOSTE::CALLANDER | | Tue Oct 10 1989 11:25 | 9 |
|
Thank you for the suggestion. We keep a list of all requested features.
I will add your suggestion to the list so that the idea is not lost.
All items on our futures list are considered as part of the long
range planning done each year.
Please note that the solutions so far list for your problem will
work with version 1.
|
| 20.4 | Can be done | TOOK::STRUTT | Colin Strutt | Tue Oct 10 1989 21:16 | 32 |
| Generally speaking, it seems quite reasonable (and quite feasible
even today) to have an application call MCC$CALL_FUNCTION. You should
try it to see if it works!
There is no need to necessarily build a PM to do this. I presume you
are more interested in whether or not it works rather than whether
or not it is supported.
There are some things to beware of. MCC defines an operating
environment for an application - break the rules and MCC (in your
process) might not do the right thing. For example, if your application
blocks, it has effectively blocked all other threads in MCC - that may
or may not be acceptable to you.
Note also that ACMS defines ITS own operating environment - it is not
the same as MCC's. Whether the two environments are compatible or not
(and for the purposes you need) you will have to determine yourself.
If it transpires that having an ACMS application co-reside with MCC
is not acceptable, for whatever reason, then you might consider the
following alternative. Write a PM which communicates not with a user,
but with a mailbox (or IPC, or someother favourite mechanism for
inter-process communication). Then have another piece of code that
uses the same communications mechanism but resides in "the other"
environment. All the PM need do is listen to the mailbox, and when
it gets a request start a thread and formulate an MCC$CALL, and when
the replies come in, send the results across the mailbox to the
"other" piece of the application. We call this the "software PM".
Try some things out and see what works. Its all a SMOP :-}
Colin
|
| 20.5 | INFO - PM entry point must be UNIVERSAL symbol. | KETJE::PACCO | | Wed Oct 11 1989 16:39 | 3 |
| When making a user presentation module, let's say MCC$UI_APPL, with the
entry point MCC$UI_APPL_MAIN, do not forget to make MCC$UI_APPL_MAIN a
UNIVERSAL symbol.
|
| 20.6 | a LMOP | CUSPID::MCCABE | If Murphy's Law can go wrong .. | Thu Oct 12 1989 13:51 | 67 |
| Quite an interesting problem, I must say.
You have a few problems to deal with and there are some twisted
partial solutions.
You could invoke the MCC system with a DCL procedure server
and exchange the information with your server.
Sloooooooowwww! Still have to map the ASCII from TRM for the exchange
steps. (redirect the output)
You could try running MCC detached with the input and output pointing
at mailboxes. You'll have to have the server open the mailboxes as
part of their startup routines. You'll also need to insure these stay
open when your server gets terminated by ACMS. You also want to insure
only one server communicates with it at a time. (MIN server =1, MAX
server =1)
Not too hard to try. You are limited to data in ascii terminal
format. There is also a good chance it may not work.
You could write a PM. It would want to look exactly like TRM with
the exception that instead of terminal format you pass the data
in it "native format." This then needs to be mapped into your server,
then built into the ACMS environment.
It could get real interesting when ACMS starts the task, then MCC
maps the PM. A process war over who is invoking what is looming
on the horizon. ACMS mapps your server and starts it. MCC starts
then maps your XM. Who gets found first? Is everyone mapped intime
to be found? Tune in next week ...
It gets to be even more fun when ACMS decides the server can be
deleted. Think about the termination entry point. What would you call
to tell MCC via the call interface that it is about to die? Is
this a MOM function? Is there MCC clean up that needs to be done?
Not a trivial effort. Good possiblity of being fruitless too.
You could combine the features and run the MCC off to the side,
detached with your own PM. The server could interact with a mailbox
to pass the commands. You need to do the PM carefully (consider
multithreading the call if you have multiple servers!). Maintain
the mailbox. Create a startup and shutdown option. And don't forget
to invite lots of virtual memory to the party.
This is a small matter of programming for a couple of dozen people.
For one person small does not quite seem like the approperate
adjective. It would begin to look like a distributed MCC.
Oh yes. You'll also need to map the data coming back to CDD
definitions and supported data types (or to data in your server that
has corresponding defintions) if you want to do anything with the data
in a TASK.
Or we could just make a distributed MCC ...
As for Colin's assertion that it works today. If he is implying that
you can just call it with out convincing MCC to map your code into its
image, I'm lost. If you try to call the MCC$CALL from your server code
you will need to make the reference WEAK when defined and linked.
It still wont't work, but at least it will complile.
-kevin
|
| 20.7 | A clarifying thought... | KEEL::SAVAGE | Peter Savage | Fri Oct 13 1989 15:22 | 171 |
|
I believe that there is some confusion regarding the technical vision
that Colin, the technical leader of MCC, was describing. I would like
to take this opportunity to clarify the underlying implementation ideas
that make up the various alternatives. The alternatives documented in
this note are not the only ways within MCC to solve this problem.
In order to clarify this discussion we will group the ideas into three
distinct classes, or alternatives. The first alternative requires the
program wanting to interact with the MCC environment to be image
merged, where the user sees only one process. The second alternative
requires that program wanting to interact with the MCC environment,
must provide an interface into MCC's command line interface.
Alternative 1:
Dynamically merge your program with MCC environment. MCC, and it's
MMs, run in the same process as your application.
One common misconception with MCC is that all requests into the
environment must be initiated by a presentation module (PM). While for
management modules this is true, for programs that are really outside
the MCC environment PMs do not have to be involved.
+-----------------------+
| Process Space |
| +--------+ |
| | | |
| | | |
| | Your | |
| | Program| |
| | | |
| | | |
| +--------+ |
| |
| +--------+ |
| | | |
| | | |
| | | |
| | MCC | |
| | | |
| | + | |
| | | |
| | MMs | |
| | | |
| | | |
| | | |
| +--------+ |
| |
+-----------------------+
This first alternative takes the existing application and changes the
implementation to image merge the MCC environment with the application.
By using the VMS system service LIB$FIND_IMAGE_SYMBOL any VMS
application can find the globally defined entry points within MCC. The
application could then pass VEA requests to the MCC$CALL as if the
application were really a PM or FM. Also, any of the MCC common
routines documented in the SRM can be utilized in a similar manner.
The user's view of MCC is what the application that has encapsulated
MCC provides. In other words the application need not show the user
any aspects of MCC.
Alternative 2:
Augment your program, and have it run in it's own process.
+--------+
| |
| |
| Your |
| |
| Program|
| |
| |
| |
+--------+ +--------+
| | | TRM |
| +-----------+ PM |
| | | |
+--------+ +--------+
| |
| |
| |
| |
| MCC |
| |
| + |
| |
| MMs |
| |
| |
| |
| |
| |
| |
+--------+
In order to accomplish this your program must create a VMS mailbox and
then activate MCC detached with SYS$INPUT and SYS$OUTPUT pointing to
the created mailbox. Once this has been done, the application can then
pass MCC TRM ASCII commands to MCC via the mailbox. Responses to the
command passed in the mailbox will need to be parsed by the
application. The reason that this approach works is because the TRM
always displays data in a consistent format.
Alternative 3:
Augment your program, and have it run in it's own process, but in this
case you write some code that runs with MCC (as a PM).
+--------+
| |
| |
| Your |
| |
| Program|
| |
| |
| |
+--------+ +--------+
| | | S/W |
| +-----------+ PM |
| | | |
+--------+ +--------+
| |
| |
| |
| |
| MCC |
| |
| + |
| |
| MMs |
| |
| |
| |
| |
| |
| |
+--------+
We call this PM the Software PM (as it allows other software access to
the MCC$CALL.) Note that this PM does *not* already exist - you would
have to write it. You could choose the communications between your
program and the S/W PM to be either based on ascii commands (but then
it looks like alternative #2 above) or via some binary protocol - the
intent here is to remote the MCC$CALL to your program.
Conclusion:
I do NOT believe that any of these alternatives require large
implementation efforts.
If you have questions or concerns over the appropriate alternative for
your application, please do not hesitate to contact me.
Regards
Peter
MCC Implementation Leader
|
| 20.8 | PROBLEM - How to call the image activation entries? | KETJE::PACCO | | Tue Oct 17 1989 07:54 | 28 |
| In respect to alternative 1, as described by Peter, some additional
toughts.
Normally a PM, FM and AM have all 3 specific entry points,
MCC$xxx_INIT, MCC$xxx_LOG and MCC$xxx_PROBE.
I am trying to imagine what happens if an application program would
call directly MCC$CALL_FUNCTION, without beeing a PM, FM or AM.
First at enroll time of the MM (using for instance the TRM), all the
MCC$xxx_INIT points are called, and the modules becomes enrolled.
Everyting O.K. up to now.
Now the QUESTION.
If an application calls directly MCC$CALL_FUNCTION, what happens with
the the two remaining entry points (MCC$xx_PROBE and MCC$xxx_LOG).
These will not be called. However to be consistent with the actual
implementation, these should be called.
In order to achieve this, is the application obliged at image
activation time to find out which modules have been enrolled and then
call these entry points one after each other? How can the list of
MM be found? Which routines are used for the MCC$xxx_LOG logical name
translation into longword? Are there other things to do before the
standard MCC environment is reached?
Dominique.
|
| 20.9 | ? | CSEVEN::DANIELE | | Tue Oct 17 1989 17:11 | 37 |
|
Is all you will ever need simply data returned from MCC$CALL_xxxx ?
If yes, then of the choices of:
1. Image merge all of MCC into your server and call MCC$CALL
yourself
2. Run MCC detached and redirect i/o to mailboxes
3. Write an XM for communications
I heartily recommend #2. Your only job is parsing
TRM's ASCII output. (You probably want 1 MCC process per ACMS server,
started up at server initialization time.)
If no (for instance, you need to call MCC common routines),
then of the same 3 choices:
1. I don't believe works. The common routines are in
MCC$MAIN.EXE, which is not a shareable image. I don't think
you can image merge a non-shareable image with
LIB$FIND_IMAGE_SYMBOL.
2. Won't work, since the reason you need to call common
routines is that there isn't a V,E,A available that gives
you what you want.
3. Is your only current alternative. It could be an FM or AM
that provides the data you need across MCC$CALL, in which
case you still have to do 2. Or it could be a PM that
communicates with your server, avoiding 2.
Whether this is a small or large matter of programming
is somewhat subjective. It is not a trivial effort to get
an XM up and running, but you seem to have a good handle
on things...
Hope this helps,
Mike
|
| 20.10 | image activation entries are NOT called | TOOK::T_HUPPER | Need input | Wed Oct 18 1989 18:49 | 55 |
| RE: 20.8
A direct answer to your "QUESTION:"
>> Now the QUESTION.
>> If an application calls directly MCC$CALL_FUNCTION, what happens with
>> the the two remaining entry points (MCC$xx_PROBE and MCC$xxx_LOG).
>> These will not be called. However to be consistent with the actual
>> implementation, these should be called.
The MCC$xxx_PROBE and MCC$xxx_LOG entry points are called
automatically, if necessary, by the MCC$CALL_FUNCTION routine. They
can not be called explicitly by the caller of MCC$CALL_FUNCTION at any
time. The caller of MCC$CALL_FUNCTION does not have all the
required pieces of information to call the probe routine directly.
Once the MCC environment is set up the application does not have to do
anything to cause the mapping of MMs into the MCC process. The
application has no direct access to the list of enrolled MMs. When the
application calls the MCC$CALL_xxx routines it is the job of the
MCC-Kernel to map the appropriate module.
If the application wants to initiate an enrollment of a module, this
can be done in the same fashion as a PM. To get the needed details for
implementing this function I suggest that you contact Peter Savage
directly.
A clarification on alternative #1 (of note 20.7):
The capability to use alternative #1 is currently scheduled to be
available in the internal field test version of the enduser kit of MCC
(to be released 16-DEC-1989). The current MCC executables run as the
"boss", and insist on passing control to the PM. Converting your
application to a PM (suggested in note 20.1) or using one of the
mailbox schemes are methods that will currently work. The future
baselevels of MCC will permit the MCC environment to be callable by
other applications.
If you would like additional information regarding the implementation
plans for this feature please contact Peter Savage.
A few points:
There seems to be confusion as to when the MCC$xxx_INIT, MCC$xxx_PROBE,
and MCC$xxx_LOG routines of an MM are called. As stated in the SRM,
all 3 are called (in the order specified) during enrollment of the MM.
If, during an MCC$CALL_FUNCTION or MCC$CALL_ACCESS call, the target MM
is found not to be mapped by the process, the MCC$xxx_PROBE and
MCC$xxx_LOG routines are called (in the order specified) to map the
target MM into the process and make its entry points available.
The calling of all of these routines is performed automatically by MCC
kernel code, not by any MM or outside code.
Ted
|